Here's my summary of what's been going on in this thread.
(I see there have been some additions since I started to get this
reply ready. I'll have a look at those next.)
What - I think - is really needed:
Problem: Use a PC as a means to appear as an SNA (display) device
(for TSO, CICS, etc. access) for MVS running in Hercules.
Solution: TN3270 client in PC, Hercules configured to allow external
IP access and Communications Server (or TCP/IP for MVS and VTAM)
configured to support TN3270.
BUT
Further problem: TN3270 client programs in Widows costs money whereas
Minitel client program (i-Timtel Flash, requiring Windows, which is
what the quoted URL downloads) is free.
Proposed solution: Minitel emulator accesses Hercules - somehow 1 -
and, in turn, is connected - somehow 2 - through to MVS.
Possible realistic solution: The solution above using X3270 as the
TN3270 client. However, a Windows solution was anticipated. If the
possibility to run a system which supports X Window is accepted, e.g.
Linux or Mac OS X (also UNIX machines) then the *free* X3270 TN3270
client could be used. ( http://x3270.bgp.nu/ )
-
It is imagined that "somehow 2" in the "proposed solution" is
achieved by Hercules presenting a 3767 appearance to MVS, hence the
title of the thread.
Presumably this is because Hercules presents a 3270 display device
appearance to MVS so why not a 3767?
Unfortunately this is an apples and oranges comparison.
Exceptionally, because of the importance of allowing channel-attached
3270 display devices to be supported as a VTAM "terminal", VTAM
supplies emulation transforming 3270 pre/non-SNA channel support to a
secondary logical unit (LU) capable of supporting the 3270 data
stream.
In addition the pre/non-SNA channel-attached 3270 is also supported
as a console.
As noted, this is exceptional; there is no such support for the 3767.
The 3767 device can appear to MVS applications only as
a) a secondary LU capable of supporting the SNA character string
(SCS), essentially EBCDIC characters with *no* formatting other
than "new line" (NL), a combination of the functions found with
ASCII "carriage return" (CR) and "line feed" (LF)), in other words
there are no "full screen" capabilities.
b) "start-stop" (asynchroous) emulation for the 2741 and some,
possibly all, models and options of the 2740.
In both cases "a" and "b", connection to Hercules would need to be by
a serial line.
In case "a", the data link protocol is required to be SDLC which
implies a relatively expensive adapter I believe. And then there's
the nightmare of how to continue the connection through to MVS since
the only existing support requires passage through an NCP.
In case "b", the data link protocol is "start-stop" (asynchronous)
and so can be handled by a cheap PC adapter, maybe a "built-in" one.
It's conceivable that Hercules could support the adapter side but
there's no appearance possible to MVS. The 2741 could be made to
appear to MVS as an SNA 3767 - as it happens - but requiring direct
support for the "start-stop" (asynchronous) attachment using
adapters in a 3705, 3720, 3725 or 3745 and NCP and emulation for the
3767 with the NTO product in NCP.
I think we can drop both these ideas since making the connection is
just about impossible and the end result will probably not offer the
level of function expected, for example, under TSO there will only be
line command support, no ISPF etc..
There is no channel-attached capability and so the 3767 is also never
a console.
It's a bit of a mystery how the idea emerged that a 3767 appearance
could be used to solve the problem. Perhaps it was the knowledge that
NTO also supported asynchronous ("start-stop") ASCII devices and that
such a device appeared, as the 2741 support mentioned above, as a
3767 to VTAM.
Let us assume that we have managed to connect a PC to say TSO as a
VTAM session supporting an LU type 1 (without function management
headers), in other words the way a 3767 maps to SNA presentation
layer protocols, If the PC were running a Minitel emulation,
essentially a VT100 data stream, could this data stream be
supported by TSO? The answer is "No". It's possible that it is
imagined that Minitel "full-screen", essentially VT100 "full-screen",
is the same as 3270 "full-screen". I'm afraid not; they are quite
different.
-
Just to add an interesting tangent to the discussion. The sort of
transformation that is being sought here is to use a "clever"
asynchrous ASCII device as a 3270.
From my presentation on the topic, last given in 1991, I find that
the sort of protocol conversion I am about to outline was supported
by a number of configurations. These included the 7171, the 3708, the
7426 and even the 3174. I had a 3708 to play with and I learned how
that performed protocol conversion. I believe the others behaved
similarly if not identically.
Given that the 7171 was a channel-attached machine which gave the
appearance of a pre/non-SNA 3270 controller, this might provide the
required function within the environment created by a Hercules.
Perhaps the thread title should have been "7171" rather than "3767".
<g>
I believe the sort of "full-screen" seen by users of Minitels and
users of the non-windows (I forget quite how properly to decribe
this) displays connected to UNIX machines such as the RS/6000 with,
for example, SMIT - and also PCs in the days before Windows -
is "block" mode. "Block" mode can be compared very approximately to
the way the 3270 works in that input data flows only when the "Enter"
key or equivalent is pressed. "Block" mode cannot be used by these
protocol converters. Instead "character" mode is used where each
character entered is sent to the protocol converter and characters
appear on the display only under control of the protocol converter,
in other words, so-called "echoplexing" is required.
Although the protocol converter logic is generalised, it was
important to be sure that the way a particular asynchronous ASCII
device performed its "character" mode functions could be mapped into
the generalised approach. It certainly covered the IBM devices, the
3101, 3161 and 3164 because I played with those. Probably it
supported the 3151 and another 316x device. I can't recall whether
non-IBM asynchronous ASCII devices could be supported. The 3164 was
the one I worked with most because it had colour.
I was so fascinated by this protocol conversion trick in the 3708 I
studied it in some detail and the results of that appear in my notes
which may be of interest so I'll "publish" them as a separate post. I
obliged myself to teach the subject and I never felt comfortable
teaching a subject unless I was on top of it.
-
And another possibly relevant tangent is the following:
Thinking about using a Minitel to access TSO reminds me of a little
exercise I once tried with a Videotex terminal - which I believe also
uses a modified VT100 data stream probably in much the same way that
the Minitel does. The configuration was dial-up to an X.25 PAD
service - much as is the expected environment for a Minitel - then an
X.25 network through to a connection to a 3725 running NCP and NPSI.
Finally the connection appeared to VTAM and TSO as an SNA session to
a 3767 with the necessary CRLF in place of the 3767 NL[1].
This didn't really work. I did achieve a TSO logon for line command
use but there seemed to be no way I could induce clearing the display
surface and when characters just piled up on the display, it became
useless.
From this I expect that, even if a connection was established and
accepting that, for example, use of ISPF was going to be impossible,
it may well be that even line command use becomes impossible.
[1] The 37XX instruction set did not include an MVC, "move characters
within storage", so, while characters could be translated they could
not - efficiently - be moved.
-
Other comments on the thread:
(Mike Schwab)
Imagine my surprise when I discovered that the reference was to an
IBM-MAIN post for which I was responsible!
-
(Dave Wade)
As I suggested above, the most logical way to support what I call
asynchronous ASCII - but Dave calls TTY - is to simulate the 7171 in
performing protocol conversion of asynchronous ASCII devices
with "smarts" in "character" mode equivalent to the IBM 3101 or 316X
and where the appearance to the operating system supported by
Hercules is the pre/non-SNA 3270 channel-attached controller.
I think Dave is suggesting that a PC running TELNET and
supporting "block" mode ASCII can be made to behave as a console to
the operating system supported by Hercules. It will at least be
interesting to try this if the Minitel support can also be used
within a TELNET client environment.
-
(Tony Harminic)
It was interesting to see the comment that the 3767 preceded SNA
using only 2741 emulation. (This probably included emulation of
various models of 2740 since that was certainly also a feature of the
machine when I first encountered it.) It was always my belief that
the 3767 along with the 3770 range and the addition of the SDLC
capability to the 3270 was the first set of SNA-enabled devices to be
announced. (The 3790 may have also have come out at approximately the
same time.) Because I was taking a "sabatical" in Vienna and points
East from 1974 to 1976, I missed the details of the SNA announcements.
As I described above, getting an asynchronous ASCII device connected
to the Hercules environment may be easy. The problem is what can you
do when it comes to presenting something useful to the operating
system supported by Hercules.
-
(Jean-Marie Bodin)
Jean-Marie is going to be very successful with guesses if the guesses
are that something out of the blue is *not* supported. <g>
Jean-Marie should also be aware that the only standard which the
Minitel represents is the Minitel standard. It is not even compatible
with the VT100 which is a "de facto" standard for "block" mode
asynchronous ASCII devices - as I believe. If an asynchronous ASCII
device is used in "character" mode restricted to line-by-line
operation, any old asynchronous ASCII device will probably work -
this being what X.28/X.3 (two of the X.25 PAD "standards", strictly
CCITT "recommendations") anticipate. I would expect that the
only "applications" which a Minitel can use in "block" mode are
applications specifically written for the Minitel. It is also
possible, as I experienced with the Videotex device, that the Minitel
doesn't handle line-by-line "character" mode well - but I could be
wrong.
In order to gain access to a program such as TSO on the mainframe,
you need to consider what external communication the program can
have. In the recent past this has been exclusively via Communications
Server SNA (VTAM) or IP. In the more distant past this has been via a
variety of "access methods" nearly always relying on spcialised
truly "front-end" devices - as some posts have mentioned. The only
exception to this is the pre/non-SNA channel-attached 3270 which VTAM
internally "brings into line", as it were.
All this to say that having a spare 1052 or 3215 isn't going to help.
-
(Norman)
A 3284 is purely a printer. I expect it could appear in a system
generation as a device connected to a pre/non-SNA channel-attached
3270 controller.
-
(Gerhard Postpischil)
What Gerhard is proposing is somewhat ambitious. In effect, he is
proposing that something equivalent to the support I mentioned for
pre/non-SNA channel-attached 3270 support is added to VTAM. This is
one enormously tall order - both in the first instance and in terms
of support since it would use unsupported interfaces. However, having
said that, I can think of a way to do it which did involve a
supported interface. A separate program which behaves like the TN3270
server program in that it presents the "3767" appearance to VTAM
could be used. Note that we are still talking of support only for
line commands - no ISPF.
Patching BTAM code to support a 2741 from 2740 code would be
massively easier than what is being proposed here. That was surely
just some minor "tweaking" once you had got your hands on the source
for the 2740 support modules - as I vaguely remenber the *basic* 2740
and the 2741.
-
(Scott Vetter)
TCAM used to require NCP with whom, as I used to say, it had a
symbiotic relationship. I think Scott has these dependencies the
wrong way round. VTAM, during its heyday, accumulated more and more
ways in which is was *not* dependent on NCP culminating in the 3172
and, more recently, the Open System Adapter (OSA).
For "start-stop" (asynchronous) device support in VTAM you need
specifically NCP (not EP or the EP "side" of PEP) together with the
Network Terminal Option (NTO).
EP and the EP "side" of PEP are needed for BTAM and - I expect but I
really forget now - QTAM and any code that could drive the 270X
control unit channel appearances at the EXCP level.
-
(Harold Grovesteen)
As a matter of interest, Harold, what partner is supported by the non-
polled 270x BSC device type emulated over a TCP connection? - only
another Hercules with the same support perhaps possibly for NJE use?
TSO was supported by a cut-down TCAM when TSO was introduced. VTAM
support was added for TSO support and the cut-down TCAM support was
eventually taken away - and I hope I've got all of that right since
it's all very much covered with cobwebs! Actually I seem to remember
that NTO was the excuse to remove the cut-down TCAM support - but
you're dealing with dead neurons here. No, one jumped into life, it
was the removal of "basic" mode ("start-stop" and BSC) support in
VTAM - which may have been around the same time, the early '80s.
I'm not quite sure what you mean by "emulating NCP processing" but be
aware that there is a program which supports NCP without needing a
3705, 3725, 3720 or 3745. This is Communications Controller for Linux
on System z (CCL). With CCL you will need OSA emulation.
-
(Ron Tatum)
All I think I can add to Ron's contribution is that when I became
acquainted with IBM teleprocessing as it was called in 1969, there
was indeed a wonderful array of "start-stop" (asynchronous) devices
of which the 1050 cluster of devices was the system most commonly
used for education purposes and the 2260 (later the multipoint BSC
3271) was the system most often used by customers.
-
Finally "the country of the Minitel[1]" reminds me to congratulate
Jean-Marie on the foresight of the French government in promoting the
Minitel throughout the population as a way to "jump start" the entry
of the French into the age of "informatique". As I indicated above,
it relied on another "resource" which the French governement
encouraged, namely the national X.25 network. The popularity of the
Minitel was reponsible for extremely heavy use of the X.25 network -
but the "application" which caused the extremely heavy use was, in
effect, the oldest profession becoming a very modern profession -
although limited to verbal interaction ("messageries roses"). Just
one example of the law of unintended consequences.
[1] Médium Interactif par Numérotation d'Informations TÉLéphoniques.
Chris Mason
Hi,
I have looked for this devtype in the RefCard for the Console
Commands
written by Axel Schwarzer (Command "devnum"), and did not find it.
There are 3270|3287 for terminals|printers and 1052|3215 for
consoles.
I also have browsed the messages from the group without success.
My question is : Is it possible to connect devices such as
teletypes
to Hercules ? If not, is this feature in the schedule of the
Hercules
Project ?
Thanks
JM Bodin