Discussion:
Devtype 3767
(too old to reply)
Jean-Marie BODIN
2006-11-08 22:47:44 UTC
Permalink
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
Mike Schwab
2006-11-08 23:22:04 UTC
Permalink
http://www.mail-archive.com/ibm-main-***@public.gmane.org/msg16778.html
references this device type. SNA line mode LU1. When I was a
computer programmer for the Illinois State Police, we had an odd
pre-existing network of lots of Western Union teletypes upgraded to
have a seperate 16 line 64 character monitor/keyboard that would
buffer for the teletypes used as a printer over BSC. Came from the
era before the 3270 came out.
Post by Jean-Marie BODIN
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
--
Mike A Schwab, Springfield IL USA http://geocities.com/maschwab/ for
software links
Dave Wade
2006-11-08 23:40:25 UTC
Permalink
----- Original Message -----
From: "Jean-Marie BODIN" <jeanmarie.bodin-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Wednesday, November 08, 2006 10:47 PM
Subject: [hercules-390] Devtype 3767
Post by Jean-Marie BODIN
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 ?
Jean,

Not sure what exactly you are asking, howver :-

1. You can't create a device type of TTY or 2741 in the hercules config.
2. You can't physically attach a serial port to Hercules and directly attach
a TTY terminal.
3. You can connect real TTY that is connected to a LINUX (or other box that
supports shell for TTY) via TELNET to Hercules. However it will look like a
1052 or 3215 to any program running on the host.

I am not a developer but I don't think any updates to Hercules are planned
to imlement real TTY support.

Dave
Post by Jean-Marie BODIN
Thanks
JM Bodin
Jean-Marie BODIN
2006-11-09 21:53:47 UTC
Permalink
Post by Dave Wade
----- Original Message -----
Sent: Wednesday, November 08, 2006 10:47 PM
Subject: [hercules-390] Devtype 3767
[snip]
Post by Dave Wade
Jean,
Not sure what exactly you are asking, howver :-
1. You can't create a device type of TTY or 2741 in the hercules config.
Infortunately my guess is confirmed
Post by Dave Wade
2. You can't physically attach a serial port to Hercules and
directly attach a TTY terminal.

I was not aware of that. However, being in the country of
the "Minitel", I think that using this sort of emulation :
http://www.pcastuces.com/logitheque/telechargement.asp?num=186
one can connect to an IP port of the PC host, as well as we do for
the 3270 emulator.
Post by Dave Wade
3. You can connect real TTY that is connected to a LINUX (or other
box that supports shell for TTY) via TELNET to Hercules. However it
will look like a 1052 or 3215 to any program running on the host.

I understand that using Hercules under Linux, I can connect a
physical Minitel via the RS232 plug of the PC. (12 or 13 years ago,
I made an electronic adaptor to connect my PC (Win 3.1) to the
Videotex services via that Minitel's modem ; was before Internet for
me).
Does looking like a 1052 or 3215 means that the only usage of this
terminal is Console ? Or once the 009 devnum of Turnkey being
connected (for example), another devnum 3215 can be used for another
purpose ?
Post by Dave Wade
I am not a developer but I don't think any updates to Hercules are
planned to imlement real TTY support.
Post by Dave Wade
Dave
Thank You

JM Bodin
Post by Dave Wade
Post by Jean-Marie BODIN
Thanks
JM Bodin
Norman
2006-11-09 22:03:13 UTC
Permalink
If I recall correctly, the 3767 looked like a 3284. At least in MVS that's
how

it was genned. I recently saw 2 of them at a customer site in their relics
room.





_____

From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of Jean-Marie BODIN
Sent: Thursday, November 09, 2006 SYSN PM 1:54
To: hercules-390-***@public.gmane.org
Subject: [hercules-390] Re: Devtype 3767
Post by Dave Wade
----- Original Message -----
yahoogroups.com>
Post by Dave Wade
Sent: Wednesday, November 08, 2006 10:47 PM
Subject: [hercules-390] Devtype 3767
[snip]
Post by Dave Wade
Jean,
Not sure what exactly you are asking, howver :-
1. You can't create a device type of TTY or 2741 in the hercules config.
Infortunately my guess is confirmed
Post by Dave Wade
2. You can't physically attach a serial port to Hercules and
directly attach a TTY terminal.

I was not aware of that. However, being in the country of
the "Minitel", I think that using this sort of emulation :
http://www.pcastuce
<http://www.pcastuces.com/logitheque/telechargement.asp?num=186>
s.com/logitheque/telechargement.asp?num=186
one can connect to an IP port of the PC host, as well as we do for
the 3270 emulator.
Post by Dave Wade
3. You can connect real TTY that is connected to a LINUX (or other
box that supports shell for TTY) via TELNET to Hercules. However it
will look like a 1052 or 3215 to any program running on the host.

I understand that using Hercules under Linux, I can connect a
physical Minitel via the RS232 plug of the PC. (12 or 13 years ago,
I made an electronic adaptor to connect my PC (Win 3.1) to the
Videotex services via that Minitel's modem ; was before Internet for
me).
Does looking like a 1052 or 3215 means that the only usage of this
terminal is Console ? Or once the 009 devnum of Turnkey being
connected (for example), another devnum 3215 can be used for another
purpose ?
Post by Dave Wade
I am not a developer but I don't think any updates to Hercules are
planned to imlement real TTY support.
Post by Dave Wade
Dave
Thank You

JM Bodin
Post by Dave Wade
Post by Jean-Marie BODIN
Thanks
JM Bodin
[Non-text portions of this message have been removed]
Dave Wade
2006-11-09 23:28:32 UTC
Permalink
Post by Dave Wade
Post by Dave Wade
1. You can't create a device type of TTY or 2741 in the hercules
config.
Infortunately my guess is confirmed
Post by Dave Wade
2. You can't physically attach a serial port to Hercules and
directly attach a TTY terminal.
I was not aware of that. However, being in the country of
http://www.pcastuces.com/logitheque/telechargement.asp?num=186
one can connect to an IP port of the PC host, as well as we do for
the 3270 emulator.
I am not sure if current MiniTel gives 80 character lines. I assume it does.
However if it will TELNET to Hercules there is a chance it will work. Note
howver that Hercules does set some Telnet options that some Telnet programs
don't like. You would have to try it and see...
Post by Dave Wade
Post by Dave Wade
3. You can connect real TTY that is connected to a LINUX (or other
box that supports shell for TTY) via TELNET to Hercules. However it
will look like a 1052 or 3215 to any program running on the host.
I understand that using Hercules under Linux, I can connect a
physical Minitel via the RS232 plug of the PC. (12 or 13 years ago,
I made an electronic adaptor to connect my PC (Win 3.1) to the
Videotex services via that Minitel's modem ; was before Internet for
me).
Does looking like a 1052 or 3215 means that the only usage of this
terminal is Console ? Or once the 009 devnum of Turnkey being
connected (for example), another devnum 3215 can be used for another
purpose ?
I don't use MVS so at this point my knowledge becomes sketchy and at this
point the honest answer I don't know if you can use a 3215 as a TSO
terminal. I would expect some one to answer on here. If not try the
H390-MVS group. Certainly on on VM/370 you can have as many 3215s as want,
and you can run them on any user, but VM/370 does not use VTAM..
Post by Dave Wade
Post by Dave Wade
I am not a developer but I don't think any updates to Hercules are
planned to imlement real TTY support.
Post by Dave Wade
Dave
Thank You
JM Bodin
Post by Dave Wade
Post by Jean-Marie BODIN
Thanks
JM Bodin
Gerhard Postpischil
2006-11-10 04:39:18 UTC
Permalink
Post by Dave Wade
I don't use MVS so at this point my knowledge becomes sketchy and at this
point the honest answer I don't know if you can use a 3215 as a TSO
terminal. I would expect some one to answer on here. If not try the
H390-MVS group. Certainly on on VM/370 you can have as many 3215s as want,
and you can run them on any user, but VM/370 does not use VTAM..
To the best of my knowledge, a 3215 is limited to being used as
a console. However, this does not preclude someone patching VTAM
and the appropriate IKT modules to make them look like TWX
terminals (TTYs). But it wouldn't be easy (I remember having a
lot of fun implementing a 3495 one release before IBM supported
it, and supporting an IBM 2741 before IBM supported it by
patching IBM 2740 code in BTAM).

You might have better luck supporting them in special code using
EXCP, e.g., by patching Wylbur, if we ever get that off the ground.

Gerhard Postpischil
Bradford, VT
scott
2006-11-10 04:52:33 UTC
Permalink
Post by Gerhard Postpischil
Post by Dave Wade
I don't use MVS so at this point my knowledge becomes sketchy and at this
point the honest answer I don't know if you can use a 3215 as a TSO
terminal. I would expect some one to answer on here. If not try the
H390-MVS group. Certainly on on VM/370 you can have as many 3215s as want,
and you can run them on any user, but VM/370 does not use VTAM..
To the best of my knowledge, a 3215 is limited to being used as
a console. However, this does not preclude someone patching VTAM
and the appropriate IKT modules to make them look like TWX
terminals (TTYs). But it wouldn't be easy (I remember having a
lot of fun implementing a 3495 one release before IBM supported
it, and supporting an IBM 2741 before IBM supported it by
patching IBM 2740 code in BTAM).
You might have better luck supporting them in special code using
EXCP, e.g., by patching Wylbur, if we ever get that off the ground.
Gerhard Postpischil
Bradford, VT
Wouldn't TCAM be better suited to using TTYs? Seems to me that in
order to use VTAM you have to have a FEP with EP, or a combination of
PEP, NCP, and EP.

Scott
Gerhard Postpischil
2006-11-10 05:24:09 UTC
Permalink
Post by scott
Wouldn't TCAM be better suited to using TTYs? Seems to
me that in
Post by scott
order to use VTAM you have to have a FEP with EP, or a combination of
PEP, NCP, and EP.
On the current Turnkey system I've only used VTAM, so didn't
consider that as an option. MVS support the 2703 (and 2701?), so
anything that supports those could be used. Belatedly it
occurred to me that an IBM 1050 might be a better device type to
patch, as it's already an EBCDIC device. I don't know when IBM
dropped support for it, though.

Gerhard Postpischil
Bradford, VT
Harold Grovesteen
2006-11-10 13:12:18 UTC
Permalink
The various line types supported by 270x (and emulated by EP or PEP) had
a variety of channel protocols that would have to be supported by
Hercules as device types coded in the Hercules configuration file.
Currently only a non-polled 270x BSC device type is emulated by Hercules
over a TCP connection. Once the device type is supported, any program
using EXCP or the various telecommunications accesss methods (BTAM,
QTAM, TCAM) in the various operating systems of this era could
communicate with them. TSO at this point supports these devices, if
memory isn't failing, using TCAM. The NCP, and hence VTAM, support of
these devices has an order of magnitude more complexity. Hercules has
no NCP device type nor is there a program that emulates NCP processing.

Harold Grovesteen
Post by scott
Wouldn't TCAM be better suited to using TTYs? Seems to
me that in
order to use VTAM you have to have a FEP with EP, or a combination of
PEP, NCP, and EP.
On the current Turnkey system I've only used VTAM, so didn't
consider that as an option. MVS support the 2703 (and 2701?), so
anything that supports those could be used. Belatedly it
occurred to me that an IBM 1050 might be a better device type to
patch, as it's already an EBCDIC device. I don't know when IBM
dropped support for it, though.
Gerhard Postpischil
Bradford, VT
rhtatum
2006-11-10 15:14:48 UTC
Permalink
As an aside, yes, TSO/TCAM under MVT Rel. 21 (IIRC) did support a whole menagerie of terminal types; but the support was problematical in some cases. To wit, I was trying to use a TI Silent 733 (a truly strange beast) and was told by the TSO service provider that they could support me as a TTY Model 33. No problem, I thought, the 733 supposedly worked just like a rattle box, only 3 times faster. But I very quickly found out that the TSO system "just knew" that a TTY couldn't make certain characters. Instead of giving errors/flagging the chars in question, it blithely turned them into blanks as though everything was AOK. The folks at the TSO shop said they'd fix the translate tables at the next scheduled maintenance, which was a month or so away. I wound up having to change the scantabs in the compiler I was using. Wasn't pretty; so if the gentleman wanting to use a TTY with Hercules runn
ing whatever flavor of OS wishes to use the thing (whatever device he winds up saying the terminal is) for any kind of program development, he would be well advised to have either the source for the tran. tables his TSO or TCAM uses or the source for any compilers he tries to use. This probably applies to all the terminals mentioned so far ... at one time I had a copy of the BTAM manual(s) that had the tran. tables for all the terminals one could use, and there were a bunch of IBM-manufactured data terminals with the strangest encodings - some EBCDIC, some BCD, some with the old ASCII, and some with codes I never could identify (in fact some terminals I'd never heard of, but IBM supposedly made them).

Good luck.

Regards,
Ron Tatum
----- Original Message -----
From: Harold Grovesteen
To: hercules-390-***@public.gmane.org
Sent: Friday, November 10, 2006 7:12 AM
Subject: Re: [hercules-390] Re: Devtype 3767


The various line types supported by 270x (and emulated by EP or PEP) had
a variety of channel protocols that would have to be supported by
Hercules as device types coded in the Hercules configuration file.
Currently only a non-polled 270x BSC device type is emulated by Hercules
over a TCP connection. Once the device type is supported, any program
using EXCP or the various telecommunications accesss methods (BTAM,
QTAM, TCAM) in the various operating systems of this era could
communicate with them. TSO at this point supports these devices, if
memory isn't failing, using TCAM. The NCP, and hence VTAM, support of
these devices has an order of magnitude more complexity. Hercules has
no NCP device type nor is there a program that emulates NCP processing.

Harold Grovesteen
Post by scott
Wouldn't TCAM be better suited to using TTYs? Seems to
me that in
order to use VTAM you have to have a FEP with EP, or a combination of
PEP, NCP, and EP.
On the current Turnkey system I've only used VTAM, so didn't
consider that as an option. MVS support the 2703 (and 2701?), so
anything that supports those could be used. Belatedly it
occurred to me that an IBM 1050 might be a better device type to
patch, as it's already an EBCDIC device. I don't know when IBM
dropped support for it, though.
Gerhard Postpischil
Bradford, VT
[Non-text portions of this message have been removed]
Jean-Marie BODIN
2006-11-11 15:24:30 UTC
Permalink
Thank you all for the answers.

Dave, since the release of 1B model, one can configure the "minitel"
in 80 char lines (ASCII)

I realize that the path to the working connection is long ...
(Waiting for TK4 2703 communication controller into IOGEN before
trying)


JM Bodin
Post by rhtatum
As an aside, yes, TSO/TCAM under MVT Rel. 21 (IIRC) did support a
whole menagerie of terminal types; but the support was problematical
in some cases. To wit, I was trying to use a TI Silent 733 (a truly
strange beast) and was told by the TSO service provider that they
could support me as a TTY Model 33. No problem, I thought, the 733
supposedly worked just like a rattle box, only 3 times faster. But I
very quickly found out that the TSO system "just knew" that a TTY
couldn't make certain characters. Instead of giving errors/flagging
the chars in question, it blithely turned them into blanks as though
everything was AOK. The folks at the TSO shop said they'd fix the
translate tables at the next scheduled maintenance, which was a
month or so away. I wound up having to change the scantabs in the
compiler I was using. Wasn't pretty; so if the gentleman wanting to
use a TTY with Hercules running whatever flavor of OS wishes to use
the thing (whatever device he winds up saying the terminal is) for
any kind of program development, he would be well advised to have
either the source for the tran. tables his TSO or TCAM uses or the
source for any compilers he tries to use. This probably applies to
all the terminals mentioned so far ... at one time I had a copy of
the BTAM manual(s) that had the tran. tables for all the terminals
one could use, and there were a bunch of IBM-manufactured data
terminals with the strangest encodings - some EBCDIC, some BCD, some
with the old ASCII, and some with codes I never could identify (in
fact some terminals I'd never heard of, but IBM supposedly made
them).
Post by rhtatum
Good luck.
Regards,
Ron Tatum
----- Original Message -----
From: Harold Grovesteen
Sent: Friday, November 10, 2006 7:12 AM
Subject: Re: [hercules-390] Re: Devtype 3767
The various line types supported by 270x (and emulated by EP or PEP) had
a variety of channel protocols that would have to be supported by
Hercules as device types coded in the Hercules configuration
file.
Post by rhtatum
Currently only a non-polled 270x BSC device type is emulated by Hercules
over a TCP connection. Once the device type is supported, any program
using EXCP or the various telecommunications accesss methods
(BTAM,
Post by rhtatum
QTAM, TCAM) in the various operating systems of this era could
communicate with them. TSO at this point supports these devices, if
memory isn't failing, using TCAM. The NCP, and hence VTAM,
support of
Post by rhtatum
these devices has an order of magnitude more complexity.
Hercules has
Post by rhtatum
no NCP device type nor is there a program that emulates NCP
processing.
Post by rhtatum
Harold Grovesteen
Post by scott
Wouldn't TCAM be better suited to using TTYs? Seems to
me that in
order to use VTAM you have to have a FEP with EP, or a
combination of
Post by rhtatum
Post by scott
PEP, NCP, and EP.
On the current Turnkey system I've only used VTAM, so didn't
consider that as an option. MVS support the 2703 (and 2701?), so
anything that supports those could be used. Belatedly it
occurred to me that an IBM 1050 might be a better device type to
patch, as it's already an EBCDIC device. I don't know when IBM
dropped support for it, though.
Gerhard Postpischil
Bradford, VT
[Non-text portions of this message have been removed]
Ivan Warren
2006-11-11 16:12:09 UTC
Permalink
Post by Jean-Marie BODIN
Thank you all for the answers.
Dave, since the release of 1B model, one can configure the "minitel"
in 80 char lines (ASCII)
I realize that the path to the working connection is long ...
(Waiting for TK4 2703 communication controller into IOGEN before
trying)
JM Bodin
Jean Marie,

Unfortunately, the current 2703 support is IBM-1 only (not TELE-2) -
read : BSC not Async..

I don't really see how a minitel (ahh.. the good ole minitel) could talk
BSC..

This would require the current 2703 code base to be extended to support
TELE-2 - which is not *trivial* - not only because of the translation
that must be performed (Tele 2 had a weird bit inverted code) but also
because some of the I/O command codes have an inherent different
behavior ('prepare' alone is a nightmare !)

...However... there is no reason to rule out 2703 async support in the
future.. I would just need to find some time (and maybe some
documentation).. Also, any 2703 Async emulation would be TCP/IP based
(but nothing prevents doing a Serial-Port <-> TCP/IP program to handle
that)..

--Ivan
Jean-Marie BODIN
2006-11-11 22:53:40 UTC
Permalink
Ivan

More than 20 years ago, I was working with a "Videotex monitor". The
path was :
Monitor (CICS app) <-> VTAM (3767) <-> 3705 (NCP) <-(X25)-> PAV
(Videotex Access Point) <-(phone switched line)-> Minitel (at home)

It was used for business applications

This is why I thought that, if we had the possibility to connect
a "3767", .....

JM Bodin
Post by Ivan Warren
Post by Jean-Marie BODIN
Thank you all for the answers.
Dave, since the release of 1B model, one can configure
the "minitel"
Post by Ivan Warren
Post by Jean-Marie BODIN
in 80 char lines (ASCII)
I realize that the path to the working connection is long ...
(Waiting for TK4 2703 communication controller into IOGEN before
trying)
JM Bodin
Jean Marie,
Unfortunately, the current 2703 support is IBM-1 only (not TELE-
2) -
Post by Ivan Warren
read : BSC not Async..
I don't really see how a minitel (ahh.. the good ole minitel)
could talk
Post by Ivan Warren
BSC..
This would require the current 2703 code base to be extended to support
TELE-2 - which is not *trivial* - not only because of the
translation
Post by Ivan Warren
that must be performed (Tele 2 had a weird bit inverted code) but also
because some of the I/O command codes have an inherent different
behavior ('prepare' alone is a nightmare !)
...However... there is no reason to rule out 2703 async support in the
future.. I would just need to find some time (and maybe some
documentation).. Also, any 2703 Async emulation would be TCP/IP based
(but nothing prevents doing a Serial-Port <-> TCP/IP program to handle
that)..
--Ivan
Ivan Warren
2006-11-11 23:13:23 UTC
Permalink
Post by Jean-Marie BODIN
Ivan
More than 20 years ago, I was working with a "Videotex monitor". The
Monitor (CICS app) <-> VTAM (3767) <-> 3705 (NCP) <-(X25)-> PAV
(Videotex Access Point) <-(phone switched line)-> Minitel (at home)
It was used for business applications
This is why I thought that, if we had the possibility to connect
a "3767", .....
JM Bodin
That looks like good ole GTM.. But you had to use the 3767 device type
because you were SNA based..

I used to work on a concurrent solution which was EP based (either
through a Comten or through a 37XX running an X.25 EP enabler made by a
company named Comm-Pro) - so we had no need for NCP or NPSI.. We were VM
based - and that time - VTAM on VM wasn't really readily available !

The solution would present the minitel as a 2703 (which was then handled
by an host based emulation program to then present it as a 3270 - but I
disgress)..

--Ivan
chris_john_mason
2006-11-13 01:16:16 UTC
Permalink
Ivan

GTM didn't use CICS as I recall. It supported a GATE CTCP to NPSI.

I don't really follow "VTAM not readily available". One moment it
wasn't there and one moment it was like any product announcement[1]
or possibly you refer to a period of a relatively short 3 months or
so during an Early Support Program.

[1] Well, I seem to remember that the first TCP/IP for MVS was only
available on special request.

Incidentally if you can tweak the Hercules environment to take a
Minitel connection and pass the data stream to a program running
BTAM - or, probably better, EXCP driving CCWs - which then appears as
a secondary logical unit to VTAM (LU type 2 or LU type 0) with a 3270
data stream then this is a solution. How you do the Minitel data
stream to 3270 data stream could be similar to the way protocol
converters such as the 3708 or 7171 do it. The trouble is that
the "protocol conversion" requires "echoplexing" which is sensible
only if *not* encapsulated in something such as X.25 or (TCP/UDP)/IP.

There's an interesting function in the follow-on product to GTM,
namely "Communication Subsystem for Interconnection" (CSFI). One of
the options of PAD Emulation Services (PES) is to emulate a VT100 so
that, for example, you can run SMIT on AIX from a 3270. The 3270
display is logged on to CSFI PES and PES is instructed to perform a
TELNET connection to AIX on the RS/6000. PES performs the mapping
between the 3270 data stream and the VT100 data stream and vice versa
but in the sense where the client is 3270 and the server is VT100
rather than what is wanted in this thread which is where the client
is VT100 and the server is 3270.

Chris Mason
Post by Ivan Warren
Post by Jean-Marie BODIN
Ivan
More than 20 years ago, I was working with a "Videotex monitor". The
Monitor (CICS app) <-> VTAM (3767) <-> 3705 (NCP) <-(X25)-> PAV
(Videotex Access Point) <-(phone switched line)-> Minitel (at home)
It was used for business applications
This is why I thought that, if we had the possibility to connect
a "3767", .....
JM Bodin
That looks like good ole GTM.. But you had to use the 3767 device type
because you were SNA based..
I used to work on a concurrent solution which was EP based (either
through a Comten or through a 37XX running an X.25 EP enabler made by a
company named Comm-Pro) - so we had no need for NCP or NPSI.. We were VM
based - and that time - VTAM on VM wasn't really readily available !
The solution would present the minitel as a 2703 (which was then handled
by an host based emulation program to then present it as a 3270 - but I
disgress)..
--Ivan
chris_john_mason
2006-11-13 00:58:15 UTC
Permalink
Jean-Marie

Do you recall that the CICS application was specifically written to
handle the Minitel "block" mode ASCII data stream translated to
EBCDIC? No other product did except perhaps GTM/GTMOSI/CSFI - which I
used to use in a trivial way for the "PAD Emulation Services"
function in support of X.25 classes and thus never with Minitel
devices or emulators.

You may recall having to add TERM=TWX to and specifying the SSCPFM
operand as USSNTO on the LU statement representing the 3767 which, in
turn, represented the Minitel connection through NPSI - some letters
missing from your diagram. Those two operands inform respectively the
application - by means of the INQUIRE DEVTYPE macro - and VTAM - as a
parameter to Unformatted System Services (USS) processing - that the
data stream is not SCS but a translation into EBCDIC of an ASCII data
stream with CRLF replacing NL as I mentioned before.

Incidentally, are you sure you hadn't progressed to a 3725 by 1986?

It occurs to me that a fundamental question needs to be asked so that
responders can focus on the problem to be solved. I have assumed that
cheap access to MVS running in a Hercules environment is desired but
perhaps it is an overriding requirement that access is from a Minitel
device (or Minitel emulator). So does the access have to be from a
Minitel device or will anything do?

If anything will do, it seems Kees Verruijt has provided the "missing
piece of the puzzle" by showing how X3270 can be supported on
Windows. It looks like it may be a sledgehammer but I dare say it's a
tough nut.

Chris Mason
Post by Jean-Marie BODIN
Ivan
More than 20 years ago, I was working with a "Videotex monitor". The
Monitor (CICS app) <-> VTAM (3767) <-> 3705 (NCP) <-(X25)-> PAV
(Videotex Access Point) <-(phone switched line)-> Minitel (at home)
It was used for business applications
This is why I thought that, if we had the possibility to connect
a "3767", .....
JM Bodin
Jean-Marie BODIN
2006-11-13 21:41:26 UTC
Permalink
Post by Dave Wade
Jean-Marie
Do you recall that the CICS application was specifically written to
handle the Minitel "block" mode ASCII data stream translated to
EBCDIC?
Yes

No other product did except perhaps GTM/GTMOSI/CSFI - which I
Post by Dave Wade
used to use in a trivial way for the "PAD Emulation Services"
function in support of X.25 classes and thus never with Minitel
devices or emulators.
You may recall having to add TERM=TWX to and specifying the SSCPFM
operand as USSNTO on the LU statement representing the 3767
Yes

which, in
Post by Dave Wade
turn, represented the Minitel connection through NPSI - some
letters
Post by Dave Wade
missing from your diagram. Those two operands inform respectively the
application - by means of the INQUIRE DEVTYPE macro - and VTAM - as a
parameter to Unformatted System Services (USS) processing - that the
data stream is not SCS but a translation into EBCDIC of an ASCII data
stream with CRLF replacing NL as I mentioned before.
Incidentally, are you sure you hadn't progressed to a 3725 by 1986?
I began with a 3705 (old I presume), and continued with 3725
Post by Dave Wade
It occurs to me that a fundamental question needs to be asked so that
responders can focus on the problem to be solved. I have assumed that
cheap access to MVS running in a Hercules environment is desired but
perhaps it is an overriding requirement that access is from a
Minitel
Post by Dave Wade
device (or Minitel emulator). So does the access have to be from a
Minitel device or will anything do?
My questioning was ; Having a Minitel, and knowing that in ancient
times, I worked with a MVS application connecting to Minitels, is it
possible to theorically connect one to Hercules.
I knew that it was not possible to use it as a full-screen terminal
(like 3270). But if someone had tinkered with classic TTYs once with
Hercules, it'll be possible for me to dialog with this Minitel from
3.8J.
Unfortunately, as we've seen before, this not the possible, athe
time.

Thank you all for those explanations.
Post by Dave Wade
If anything will do, it seems Kees Verruijt has provided
the "missing
Post by Dave Wade
piece of the puzzle" by showing how X3270 can be supported on
Windows. It looks like it may be a sledgehammer but I dare say
it's a
Post by Dave Wade
tough nut.
Chris Mason
Post by Jean-Marie BODIN
Ivan
More than 20 years ago, I was working with a "Videotex monitor".
The
Post by Jean-Marie BODIN
Monitor (CICS app) <-> VTAM (3767) <-> 3705 (NCP) <-(X25)-> PAV
(Videotex Access Point) <-(phone switched line)-> Minitel (at home)
It was used for business applications
This is why I thought that, if we had the possibility to connect
a "3767", .....
JM Bodin
David Wade
2006-11-13 23:00:43 UTC
Permalink
Post by Jean-Marie BODIN
My questioning was ; Having a Minitel, and knowing that in ancient
times, I worked with a MVS application connecting to Minitels, is it
possible to theorically connect one to Hercules.
I knew that it was not possible to use it as a full-screen terminal
(like 3270). But if someone had tinkered with classic TTYs once with
Hercules, it'll be possible for me to dialog with this Minitel from
3.8J.
Well strictly speaking that’s not quite true. You can use it as a console, or you could write your own code to talk to it using EXECP, but you can’t use it as a TSO terminal. You could also use it on VM/CMS but that’s not TSO...
Post by Jean-Marie BODIN
Unfortunately, as we've seen before, this not the possible, athe
time.
Only if you want to connect to TSO...
Post by Jean-Marie BODIN
Thank you all for those explanations.
Post by Jean-Marie BODIN
It was used for business applications
Hercules does not really do "business apps" well either on "free" OS's as no CICS...
Post by Jean-Marie BODIN
Post by Jean-Marie BODIN
This is why I thought that, if we had the possibility to connect
a "3767", .....
When I looked in the VM announcement letter I see it only supports these as 2741, which is odd because I didn't think a 2741 was an SNA device and every one else said these were SNA so I am now puzzled... The 2741 I used at Newcastle University was surely on 2708 or similar, The 360/67 did not have an FEP....

I know this has been discussed before but how hard would it be to tweak VTAM to allow a program to act as terminal....
Post by Jean-Marie BODIN
Post by Jean-Marie BODIN
JM Bodin
Dave.
David Wade
2006-11-13 23:36:17 UTC
Permalink
One more question RFC 377 (ftp://ftp.rfc-editor.org/in-notes/rfc377.txt) describes using TSO via a line mode TTY. Any one any ideas on how this worked?

Dave Wade
Illegitimi Non Carborundum
Andrew H. Derbyshire
2006-11-14 00:14:46 UTC
Permalink
Post by David Wade
One more question RFC 377
(ftp://ftp.rfc-editor.org/in-notes/rfc377.txt) describes using TSO via
a line mode TTY. Any one any ideas on how this worked?

August 1972. Oh boy. The ARPANet didn't even run TCP/IP then.

Two words: "Custom Support".

Probably looked like serial lines to the IBM (when it still supported
them), and could have easily been before the IBM world went more 3270
oriented.

-ahd-
chris_john_mason
2006-11-22 13:52:37 UTC
Permalink
Andrew

1972 was just about when the 3270 (BSC and pre-SNA channel attached)
was announced.

Chris Mason
Post by David Wade
Post by David Wade
One more question RFC 377
(ftp://ftp.rfc-editor.org/in-notes/rfc377.txt) describes using TSO via
a line mode TTY. Any one any ideas on how this worked?
August 1972. Oh boy. The ARPANet didn't even run TCP/IP then.
Two words: "Custom Support".
Probably looked like serial lines to the IBM (when it still
supported
Post by David Wade
them), and could have easily been before the IBM world went more 3270
oriented.
-ahd-
Tony Harminc
2006-11-14 00:45:37 UTC
Permalink
Post by David Wade
One more question RFC 377 (ftp://ftp.rfc-editor.org/in-notes/rfc377.txt) describes using TSO via a line mode TTY. Any one any ideas on how this worked?
Hmmm... 1972. I'd guess that someone built/wrote a telnet to channel
box of some sort, or possible just an Arpanet to async port box
(reverse multiplexer) that they plugged into a 270x or 370x.

There's a lot of stuff being mixed together in this long series of
posts, and I'm not sure about the heat to light ratio...

Let me add a bit of one or the other.

First, if we are talking about MVS 3.8 era, line mode TSO with TTYs
(ASCII) and 2741s is fully supported by the mainframe software, i.e.
TSO + TCAM. (I am fairly sure that the non-ACF versions of VTAM
contain nothing that would usefully support any such connection.)
What's missing from the picture with hercules is the 270x emulation
for async lines, and though there's been talk, to my knowledge no one
has written anything like this. I'm not sure if there's really any
270x doc out there other than the source code for TCAM and VM/370, and
conceivably the 370x EP source code.

If we are talking a modern (z/OS style) OS, getting an arbitrary
TTY-like device to talk to TSO is probably not that hard. You connect
your TTY to the serial port on a UNIX/Linux box, login, and then
telnet (not TN3270) to the TCP/IP running on z/OS. You are presented
to VTAM in a 3767-like session, and you log on to line-mode TSO.
Although the 3767 interface doesn't support a lot of control
functions, there is no reason various in-stream characters can't be
translated (in the Linux box, perhaps, or in a proxy that could easily
be written in Java or Rexx or whatever) to perform the TTY (read
Minitel) functions.

Tony H.
Phil Dickinson
2006-11-14 06:20:28 UTC
Permalink
Tony has raised an interesting option for future Hercules development..

If we implement an SNA PU type 2 in Hercules, with the necessary channel
support to appear as a Local SNA 3274 to the host OS, then we could glue on
the existing Hercules telnet and tn3270 server code, telnet for LU type 1
sessions, and tn3270 for LU type 2 sessions. This would give us several
advantages.... one channel address could be used for 255 sessions, and we
would be using the SNA code in VTAM for our LU type 2 sessions with tn3270
and this should solve some of the 3270 problems that Greg Price has been
working on to support large screen sizes and large inbound messages, which I
suspect are unique to non SNA local 3270 devices.

The major missing piece is an implementation of a PU Type 2.

However, the original author of Hercules just happens to have this code on a
shelf, I believe, because of a product he developed some years ago. Since
SNA no longer has any real commercial value, maybe we could convince him to
integrate this code into Hercules.

The VTAM supplied with MVS 3.8J would certainly be able to support this
configuration, as would any more modern ACF/VTAM.

Phil.
Post by Tony Harminc
....
If we are talking a modern (z/OS style) OS, getting an arbitrary
TTY-like device to talk to TSO is probably not that hard. You connect
your TTY to the serial port on a UNIX/Linux box, login, and then
telnet (not TN3270) to the TCP/IP running on z/OS. You are presented
to VTAM in a 3767-like session, and you log on to line-mode TSO.
Although the 3767 interface doesn't support a lot of control
functions, there is no reason various in-stream characters can't be
translated (in the Linux box, perhaps, or in a proxy that could easily
be written in Java or Rexx or whatever) to perform the TTY (read
Minitel) functions.
[Non-text portions of this message have been removed]
Phil Dickinson
2006-11-14 06:26:56 UTC
Permalink
For those that would like to read more about Roger Bowler's other products...

http://perso.orange.fr/rbowler/index.htm
Post by Phil Dickinson
Tony has raised an interesting option for future Hercules development..
If we implement an SNA PU type 2 in Hercules, with the necessary channel
support to appear as a Local SNA 3274 to the host OS, then we could glue on
the existing Hercules telnet and tn3270 server code, telnet for LU type 1
sessions, and tn3270 for LU type 2 sessions. This would give us several
advantages.... one channel address could be used for 255 sessions, and we
would be using the SNA code in VTAM for our LU type 2 sessions with tn3270
and this should solve some of the 3270 problems that Greg Price has been
working on to support large screen sizes and large inbound messages, which I
suspect are unique to non SNA local 3270 devices.
The major missing piece is an implementation of a PU Type 2.
However, the original author of Hercules just happens to have this code on a
shelf, I believe, because of a product he developed some years ago. Since
SNA no longer has any real commercial value, maybe we could convince him to
integrate this code into Hercules.
The VTAM supplied with MVS 3.8J would certainly be able to support this
configuration, as would any more modern ACF/VTAM.
Phil.
Post by Tony Harminc
....
If we are talking a modern (z/OS style) OS, getting an arbitrary
TTY-like device to talk to TSO is probably not that hard. You connect
your TTY to the serial port on a UNIX/Linux box, login, and then
telnet (not TN3270) to the TCP/IP running on z/OS. You are presented
to VTAM in a 3767-like session, and you log on to line-mode TSO.
Although the 3767 interface doesn't support a lot of control
functions, there is no reason various in-stream characters can't be
translated (in the Linux box, perhaps, or in a proxy that could easily
be written in Java or Rexx or whatever) to perform the TTY (read
Minitel) functions.
chris_john_mason
2006-11-22 14:21:08 UTC
Permalink
Phil

The missing piece is the channel support which has to match SNA 3174
channel support. SNA PU support is trivial. In any case I expect you
really mean *node* type 2 support. This isn't so complicated since,
as you hinted, there's a multiplexing function which is implemented
in the SNA transmission header.

It's interesting to propose supporting LU type 1 (3767) as one of the
LUs supported under a PU in a channel-attached type 2 node. This is
perfectly sensible and happens to correspond to the way the 3270 LUs
converse with the SSCP.

I don't see a connection between large screen support and SNA.
There's large screen support, by which I assume you mean other than
24x80 model 2 size, in non-SNA 3270 controllers.

Another "missing piece" you appear to have overlooked is the session
discipline. Existing Hercules supports pass-through of 3270 data
stream in full-duplex mode - which is trivial. SNA 3270 - and 3767 -
LU types require much greater sophistication since the session is
half-duplex and is more tightly controlled.

Chris Mason
Post by Phil Dickinson
...
If we implement an SNA PU type 2 in Hercules, with the necessary channel
support to appear as a Local SNA 3274 to the host OS, then we could glue on
the existing Hercules telnet and tn3270 server code, telnet for LU type 1
sessions, and tn3270 for LU type 2 sessions. This would give us several
advantages.... one channel address could be used for 255 sessions, and we
would be using the SNA code in VTAM for our LU type 2 sessions with tn3270
and this should solve some of the 3270 problems that Greg Price has been
working on to support large screen sizes and large inbound
messages, which I
Post by Phil Dickinson
suspect are unique to non SNA local 3270 devices.
The major missing piece is an implementation of a PU Type 2.
...
Phil Dickinson
2006-11-22 20:14:19 UTC
Permalink
responses imbedded...
Post by chris_john_mason
Phil
The missing piece is the channel support which has to match SNA 3174
channel support. SNA PU support is trivial. In any case I expect you
really mean *node* type 2 support. This isn't so complicated since,
as you hinted, there's a multiplexing function which is implemented
in the SNA transmission header.
Chris,

For Node Types I regularly use terminology circa 1980, which is still
recognised by most SNA experts.

By implementing SNA I mean all the FSMs to support all FM and TS profiles
supported by all
LU typres.

It's interesting to propose supporting LU type 1 (3767) as one of the
Post by chris_john_mason
LUs supported under a PU in a channel-attached type 2 node. This is
perfectly sensible and happens to correspond to the way the 3270 LUs
converse with the SSCP.
You couldn't really describe the LU-SSCP session as lu type 1. Anyway... I
don't see the point of your comment since the architecture allows for any LU
type within a PU type 2 node (or node type 2, if you want to use the more
modern terms).

I don't see a connection between large screen support and SNA.
Post by chris_john_mason
There's large screen support, by which I assume you mean other than
24x80 model 2 size, in non-SNA 3270 controllers.
Indeed, but not in VTAM 2, the VTAM we have in MVS3.8J. It will only
support 24x8, with limited inbound message sizes for non-sna 3270 devices.
No such restriction exists for SNA sessions.


Another "missing piece" you appear to have overlooked is the session
Post by chris_john_mason
discipline. Existing Hercules supports pass-through of 3270 data
stream in full-duplex mode - which is trivial. SNA 3270 - and 3767 -
LU types require much greater sophistication since the session is
half-duplex and is more tightly controlled.
I have not overlooked it. As I used to tell my customers...it is simply a
matter of programming. Anyway this is not relevant at the DLC layer, as in
the proposed channel support, and you get it as part of the bundle when you
code up all the FSMs from the FAP anyway. What's the problem?

Phil



Chris Mason
[Non-text portions of this message have been removed]
Greg Price
2006-11-14 08:18:10 UTC
Permalink
Post by Tony Harminc
First, if we are talking about MVS 3.8 era, line mode TSO with TTYs
(ASCII) and 2741s is fully supported by the mainframe software, i.e.
TSO + TCAM.
Yes. In the 70s and 80s where I worked our "TTY" TSO terminals
were DECWriters connected via TCAM (as were our graphics
Tektronix terminals (used for IGGS), while our 3270s were
connected via VTAM.
chris_john_mason
2006-11-22 14:15:40 UTC
Permalink
Tony

Comments are embedded.

Chris Mason
Post by Tony Harminc
Post by David Wade
One more question RFC 377 (ftp://ftp.rfc-editor.org/in-
notes/rfc377.txt) describes using TSO via a line mode TTY. Any one
any ideas on how this worked?
Post by Tony Harminc
Hmmm... 1972. I'd guess that someone built/wrote a telnet to channel
box of some sort, or possible just an Arpanet to async port box
(reverse multiplexer) that they plugged into a 270x or 370x.
A 270X would have been 2701, 2702 or 2703 and 370X would have been a
3705 or 3704 running (270X) emulation program (EP). However I'm not
sure the 370X had appeared as early as 1972.
Post by Tony Harminc
First, if we are talking about MVS 3.8 era, line mode TSO with TTYs
(ASCII) and 2741s is fully supported by the mainframe software, i.e.
TSO + TCAM. (I am fairly sure that the non-ACF versions of VTAM
contain nothing that would usefully support any such connection.)
Pre-program product VTAM (pre-ACF) had support for "basic" mode, non-
SNA, which VTAM supported before SNA was announced, and "record"
mode, meaning SNA. The basic mode API interacted with "start-stop"
and BSC support in NCP (in a 3705). Thus pre-ACF VTAM could just
about support all the "start-stop" devices you see mentioned in the
NCP manuals today. However I believe, as you mention, the TSO
application required TCAM until ACF/VTAM release 1 when VTAM support
was provided.
Post by Tony Harminc
What's missing from the picture with hercules is the 270x emulation
for async lines, and though there's been talk, to my knowledge no one
has written anything like this. I'm not sure if there's really any
270x doc out there other than the source code for TCAM and VM/370, and
conceivably the 370x EP source code.
VTAM no longer supports "basic" mode and so there may not be too much
point in providing support for the 270X channel interface. Again
however I'm at a disadvantage in not being a Hercules specialist and
I may be putting too much emphasis on current products rather
than "functionally stabilised" products which I see Hercules folk
mentioning in these posts.

If you can't use VTAM "basic" mode, then you may need to use BTAM. I
guess you may be able to find a TCAM which supports 270X/EP rather
than NCP if you can get hold of it but I'd have to mention a phrase
involving sledgehammers and nuts.
Post by Tony Harminc
If we are talking a modern (z/OS style) OS, getting an arbitrary
TTY-like device to talk to TSO is probably not that hard. You
connect
Post by Tony Harminc
your TTY to the serial port on a UNIX/Linux box, login, and then
telnet (not TN3270) to the TCP/IP running on z/OS. You are presented
to VTAM in a 3767-like session, and you log on to line-mode TSO.
Yes, it's not TN3270 but it is the TN3270 server which supports the
line-by-line mode of TELNET, a very confusing naming issue I got
caught with in the IBM-MAIN list not so long ago.
Post by Tony Harminc
Although the 3767 interface doesn't support a lot of control
functions, there is no reason various in-stream characters can't be
translated (in the Linux box, perhaps, or in a proxy that could easily
be written in Java or Rexx or whatever) to perform the TTY (read
Minitel) functions.
The "3767 interface" is the SNA character string (SCS) which
allows "formatting" with a "new line" (NL) character and that's it.

What you are proposing here - I think - is that applications could be
written under TSO in order to use the VT100 data stream in order to
exploit Minitel capabilities. This would not need any intervention
from the TELNET client since you need only code with the EBCDIC
equivalent to the appropriate ASCII characters.

There's still a doubt - until somebody tests it and shows otherwise -
that the Minitel. as a Videotex box, may not like working in line-by-
line mode with, say, TSO. The Videotex box I tried this with seemed
to be restricted to block mode - or possibly insisted on a
special "erase screen" character sequence. Minitel may be similarly
restricted.
chris_john_mason
2006-11-22 13:51:09 UTC
Permalink
Dave

That RFC is just instructions on how a particular site (UCLA-CCN)
accessed TSO in 1972 - what a waste of an RFC number! This will have
been accessing TSO through TCAM I expect. There was a cut-down
TSO/TCAM so that the overhead of TCAM was minimised. Then the support
got transferred to VTAM. Unfortunately I can't recall the time scale
since I was a VS1/VM person at the time TSO was introduced. I recall
working with TSO/VTAM first using ACF/VTAM Release 1 in the Autumn
(Fall) of 1978.

TCAM depended on writing/creating message handlers in a manner
similar to QTAM.

Chris Mason
Post by David Wade
One more question RFC 377 (ftp://ftp.rfc-editor.org/in-
notes/rfc377.txt) describes using TSO via a line mode TTY. Any one
any ideas on how this worked?
Post by David Wade
Dave Wade
Illegitimi Non Carborundum
chris_john_mason
2006-11-22 13:48:52 UTC
Permalink
Dave

Comments are embedded.

Chris Mason
Post by David Wade
Post by Jean-Marie BODIN
My questioning was ; Having a Minitel, and knowing that in ancient
times, I worked with a MVS application connecting to Minitels, is it
possible to theorically connect one to Hercules.
I knew that it was not possible to use it as a full-screen
terminal
Post by David Wade
Post by Jean-Marie BODIN
(like 3270). But if someone had tinkered with classic TTYs once with
Hercules, it'll be possible for me to dialog with this Minitel from
3.8J.
Well strictly speaking that’s not quite true. You can use it as a
console, or you could write your own code to talk to it using EXECP,
but you can’t use it as a TSO terminal. You could also use it on
VM/CMS but that’s not TSO...

It's probably my ignoranace of Hercules, but I don't see how a
Minitel can be used as a console or with VM. What means is used to
connect to what? What are the requirements on the data stream?
Post by David Wade
When I looked in the VM announcement letter I see it only supports
these as 2741, which is odd because I didn't think a 2741 was an SNA
device and every one else said these were SNA so I am now puzzled...

Maybe the VM announcement letter describes the 3767 as an SNA LU type
1 (and strictly it should have described a qualification to the LU
type 1 that function management headers (FMHs) were not supported).

The 2741 is definitely not an SNA device. Since I have used the
term "asynchronous ASCII" for a type of device, more a class of
device, I could use the term asynchronous EBCDIC for the 2741 -
although the character set may have been a precursor to EBCDIC. The
point is that asynchronous ASCII devices use a very simple 'start-
stop" protocol as does the 2741 (compared to the 1050, and the 2740
models, for example).
Post by David Wade
The 2741 I used at Newcastle University was surely on 2708 or
similar, The 360/67 did not have an FEP....

In 1968/9 the IBMers who looked after the Newcastle University 360/67
were my colleagues. I was once invited to visit your machine hall and
observed the gallery where I was told the 2741s were lined up for the
students.

I've a vague memory that your 2741 was connected through a 2703.

The 2703, if indeed it was a 2703, *was* the "Front End Processor"
(FEP).[1] In the IBM time-line, the 2701[2], 2702 and 2703 were
replaced, early '70s, by the 3705 (or 3704) running the Emulation
Program - guess what it was *emulating*, the 2701/2/3 of course! The
3705 then got the Network Control Program (NCP) which, when it was
combined functionally with what the EP did, was called the
Partitioned Emulation Program (PEP). the 2701/2/3 worked with Basic
Telecommunications Access Method (BTAM) or Queued Telecommunications
Access Method (QTAM), the standard IBM software, or something clever
like the Michigan Terminal System (MTS). NCP was first created to
work with Telecommunications Access Method (TCAM), a replacement for
QTAM. (I believe pre-SNA VTAM worked with NCP also but I never played
with that combination.) With the announcement of SNA, 1975, VTAM
gained more prominence as the replacement for BTAM and definitely
became symbiotically connected to NCP. The 3705 was eventually
replaced by the 3725, and then the 3720 and, finally, the 3745, 1988
to 2005, RIP.[3]TCAM, incidentally, faded away somewhat when it was
required to talk to the outside world through VTAM.

[1] Note that, when the 3705 was driven by NCP, it no longer deserved
to be called a "Front End Processor" because, as well as
being "channel-attached", it could also be "link-attached" initially,
with ACF/NCP releases 1 and 2, in configurations which could be
compared to a pendant necklace but, with ACF/NCP release 3 and later
(part of SNA 4.2), as the saying went, "If you can draw it, we can
build it".

[2] Around 1970, I used to joke that a "telecommunications"
specialist was someone who could configure a 2701 without referring
to the Sales Manual.

[3] Just because the 3745 has disappeared it doesn't mean that NCP
disappears. There is a product running under Linux for z Series which
emulates the 3745 and so supports NCP for the foreseeable future.
Post by David Wade
I know this has been discussed before but how hard would it be to
tweak VTAM to allow a program to act as terminal....

Given that you can establish so-called U-shaped SNA sessions, You
need only create a program to handle non-SNA data streams on one side
and an SNA data stream on the other to achieve your objective. This
is the way the Communications Server IP TN3270 server works after
all. Tweaking VTAM is never necessary; a clever program using the
VTAM API is necessary - and the glory is you are using a supported
interface - if that matters to Hercules users!
Tony Harminc
2006-11-22 22:15:26 UTC
Permalink
Post by chris_john_mason
The 2741 is definitely not an SNA device. Since I have used the
term "asynchronous ASCII" for a type of device, more a class of
device, I could use the term asynchronous EBCDIC for the 2741 -
although the character set may have been a precursor to EBCDIC.
The 2741 uses a 6-bit code that is nothing much like EBCDIC. (Actually
there are multiple mappings of characters to codepoints, along the
lines of 3270 CECPs.) It was, however, indeed often referred to as an
EBCDIC device in contrast to ASCII devices like TTYs (real or glass),
but this distinction was more one of protocol and mechanics than
codeset.

A 2741 can mechanically execute a linefeed, a newline, a shift up or
down, and a backspace (and each of these is a single control character
in the line code), but not a carriage return. There is no linefeed
key, however, so software must interpret some other key (usually ATTN)
to mean linefeed if this function is needed on input. If the carriage
return function is needed, it must be simulated with multiple
backspaces. There is also a mechanical tab facility, such that each
tab character in the datastream causes movement directly to the next
tabstop, which can be set arbitrarily by the user. Some programs
provided datastream optimization that was quite a treat to see in
operation; getting the best timing might involve tabbing to a known
point, and backspacing to the desired print position.

A TTY can execute a linefeed or a carriage return, but the newline
function requires two characters, with appropriate timing to ensure
that one is done before the next is attempted. And there is no
mechanical backspace on many TTY models, so carriage return plus
forward space (blank) is used.

Using "EBCDIC" to refer to a 2741 is akin to the way some people talk
of "ASCII files" when they mean plain text files vs binary or
formatted, regardless of character coding.
Post by chris_john_mason
The point is that asynchronous ASCII devices use a very simple 'start-
stop" protocol as does the 2741 (compared to the 1050, and the 2740
models, for example).
The 2741's protocol is perhaps slightly more complex than the TTY's,
but not much. Most of it has to do with the inherently half-duplex
nature of the beast.

Tony H.
David Wade
2006-11-23 00:13:27 UTC
Permalink
Lots of trimming done... just a couple fo comments...
Post by chris_john_mason
It's probably my ignoranace of Hercules, but I don't see how a
Minitel can be used as a console or with VM. What means is used to
connect to what? What are the requirements on the data stream?
Any terminal that can act as a Linux TTY console, and can run Telenet can be used as a 3210 console. I would expect a Minitel program can
Post by chris_john_mason
The 2703, if indeed it was a 2703, *was* the "Front End Processor"
(FEP).[1] In the IBM time-line, the 2701[2], 2702 and 2703 were
replaced, early '70s, by the 3705 (or 3704) running the Emulation
Program - guess what it was *emulating*, the 2701/2/3 of course!
But its not a "processor" it’s a hard wired box. I see its described as a
"transmission control unit" in the IBM Archives...

Dave.
chris_john_mason
2006-11-22 12:06:05 UTC
Permalink
Jean-Marie

So the answer to the "What do you *really* want to do?", a question
that should be on every consultant's lips, is as follows:

"I want to run the Minitel with operating systems supported by
Hercules as an asynchronous ASCII device running in line-by-line
mode."

Thus the original question could be rephrased as:

"How can one run an asynchronous ASCII device with operating systems
supported by Hercules ."

It seems allowing for protocol conversion so that the asynchronous
ASCII device, assuming it has the necessary "smarts" to support a
3270 application, like a 3101 or VT100, is *not* being requested.

But the modifications to the Minitel from a pure VT100 may prevent it
from working satisfactorily as a line-by-line device as I discovered
when trying to connect a Videotex device to MVS through a PAD
connection and an X.25 network.

It's all negative, isn't it? :-(

Chris Mason
Post by Jean-Marie BODIN
Post by chris_john_mason
...
It occurs to me that a fundamental question needs to be asked so
that
Post by chris_john_mason
responders can focus on the problem to be solved. I have assumed
that
Post by chris_john_mason
cheap access to MVS running in a Hercules environment is desired
but
Post by chris_john_mason
perhaps it is an overriding requirement that access is from a
Minitel
Post by chris_john_mason
device (or Minitel emulator). So does the access have to be from a
Minitel device or will anything do?
My questioning was ; Having a Minitel, and knowing that in ancient
times, I worked with a MVS application connecting to Minitels, is it
possible to theorically connect one to Hercules.
I knew that it was not possible to use it as a full-screen terminal
(like 3270). But if someone had tinkered with classic TTYs once with
Hercules, it'll be possible for me to dialog with this Minitel from
3.8J.
Unfortunately, as we've seen before, this not the possible, athe
time.
...
Ivan Warren
2006-11-22 12:58:23 UTC
Permalink
Post by chris_john_mason
But the modifications to the Minitel from a pure VT100 may prevent it
from working satisfactorily as a line-by-line device as I discovered
when trying to connect a Videotex device to MVS through a PAD
connection and an X.25 network.
FYI :

A minitel connects to a X.25 network via a PAV which is not a standard
X.3 PAD.. Most notably, the difference is that the default profile is
different and there is no X.28 access (that is, a terminal cannot talk
to the PAD control entity by using an escape character except for the
input of the destination X.75/X.121 address).

Now.. I am surprised by the assertion. 2703 TELE 2 can be mapped quite
nicely with any line by line TTY, TWX or glass TWX.. It is the role of
the FEP to perform the necessary adjustments to the PAD parameters
(through the use of X.29 - which basically involves sending X.25 packets
with the Q bit set). I am also confident it is possible to map a SNA LU0
unit this way.

Now.. The minitels (and notably the Minitel 1B/10B[1] which can run 80
columns) also has the possibility to be connected directly without the
use of a PAV or X.25 network. This can be achieved either through a
direct modem connection (this, however requires a V.23 capable DCE) or
through the direct serial port (which requires a custom DIN-DB9/DB25 cable).

So really, the only missing piece as far as hercules is concerned is a
2703 TELE2 emulator ! If there is really some interest in this, I could
look into implementing it.

The various documentations relating to this are : (STU means
Specifications Techniques d'Utilisation which can be roughly translated
to Technical Use Specifications)
STUM 1B : Minitel 1B manual
STUPAV : PAV (Point D'acces Videotex) manual
STUR : Transpac (France's PDN) network manual

--Ivan

[1] The 1 vs 10 difference is that the 1 is only a terminal while the 10
series also includes a phone.
Jean-Marie BODIN
2006-11-22 23:24:19 UTC
Permalink
Hi Chris

Exact rephrasing I think (with better english than mine).

But I read with interest the post from Ivan (msg 48873) describing
what is to do in Hercules (if someone decides to do it).

I don't regret the posting of my question. I know now tenfold what I
knew before, about the connectivity of the terminals. (I was an app
programmer, not a sysprog).

I remember now, that some customers used to use BTAM, a translation
table somewhere, and a 3805 from ITT to make CICS and that Minitel
to speak together. I will try to look for some document in my
archives (no warranty).

Thanks all of you


JM Bodin



JM Bodin
Post by Dave Wade
Jean-Marie
So the answer to the "What do you *really* want to do?", a
question
Post by Dave Wade
"I want to run the Minitel with operating systems supported by
Hercules as an asynchronous ASCII device running in line-by-line
mode."
"How can one run an asynchronous ASCII device with operating
systems
Post by Dave Wade
supported by Hercules ."
It seems allowing for protocol conversion so that the asynchronous
ASCII device, assuming it has the necessary "smarts" to support a
3270 application, like a 3101 or VT100, is *not* being requested.
But the modifications to the Minitel from a pure VT100 may prevent it
from working satisfactorily as a line-by-line device as I
discovered
Post by Dave Wade
when trying to connect a Videotex device to MVS through a PAD
connection and an X.25 network.
It's all negative, isn't it? :-(
Chris Mason
Post by Jean-Marie BODIN
Post by chris_john_mason
...
It occurs to me that a fundamental question needs to be asked so
that
Post by chris_john_mason
responders can focus on the problem to be solved. I have
assumed
Post by Dave Wade
Post by Jean-Marie BODIN
that
Post by chris_john_mason
cheap access to MVS running in a Hercules environment is
desired
Post by Dave Wade
Post by Jean-Marie BODIN
but
Post by chris_john_mason
perhaps it is an overriding requirement that access is from a
Minitel
Post by chris_john_mason
device (or Minitel emulator). So does the access have to be
from
Post by Dave Wade
a
Post by Jean-Marie BODIN
Post by chris_john_mason
Minitel device or will anything do?
My questioning was ; Having a Minitel, and knowing that in
ancient
Post by Dave Wade
Post by Jean-Marie BODIN
times, I worked with a MVS application connecting to Minitels,
is
Post by Dave Wade
it
Post by Jean-Marie BODIN
possible to theorically connect one to Hercules.
I knew that it was not possible to use it as a full-screen
terminal
Post by Dave Wade
Post by Jean-Marie BODIN
(like 3270). But if someone had tinkered with classic TTYs once
with
Post by Jean-Marie BODIN
Hercules, it'll be possible for me to dialog with this Minitel from
3.8J.
Unfortunately, as we've seen before, this not the possible, athe
time.
...
Ivan Warren
2006-11-23 21:54:29 UTC
Permalink
Post by Jean-Marie BODIN
I remember now, that some customers used to use BTAM, a translation
table somewhere, and a 3805 from ITT to make CICS and that Minitel
to speak together. I will try to look for some document in my
archives (no warranty).
Thanks all of you
Those customers were probably using the most infamous 'PA1-NORD' SCS 50
modification. PA1 was the term used for the SCS 50 (Comten 3650 or ITT
3805 Operating system) feature to allow relating PAD X.3 initiated X.25
SVCs to 270X TELE2 devices. The PA1NORD modification (which I believe
was originated by the "Crédit du Nord" bank) effect was to discard the
1st write CCW buffer so that the CICS logon procedure would be hidden
from the end user. Another feature of this modification was, I think, to
allow the application to retrieve the calling X.25 DCE X.121 address so
that you could determine how charges would to be applied (or if the user
was entitled to a service).

Incidently, I found out (and modified the patch consequently for my
peruse) that the caller address, even though it was an interesting piece
of information, wasn't the real thing to look for - especially when
determining if the caller was using a Pay for use PAV (3615, 3616,
3617), a regular charge PAV (3614) or a reverse charging PAV (3613)..
The appropriate measure was to make X.25 call facilities available to
the application (Close user group originator and reverse charging were
the X.25 call facilities that held the right information!).

Very off topic trivia.. Sorry !

--Ivan
Jean-Marie BODIN
2006-11-27 22:01:37 UTC
Permalink
Hi,

To focus on the topic, I found some stuff about this BTAM config
(reading the manual):

1 - A software, which name was PAX25, had to be set up on the 3805,
and options of this soft set to Videotex ; another software which
name was PA1V had also to be set up. (Maybe they came from Crédit du
Nord, I don't know).

2 - BTAM had to have an async mode (not standard with DOS). In the
latter case, you had to create a BTMOD macro

3 - Modify "Terminal Control Program" to ensure EBCDIC <---> ASCII
Videotex translation. To do that :

3.1 - Cursor positioning :
Macro DFTRMLST, label TCRCTL, change ID count from 5 to 1

3.2 - Modify "TWX output translate table", label IECTSCT2 (modifying
source) or :
VER 37C0
FF5C5CB128905CFF5C5C5CD030B070F05C88485C285010FF5C985C5C5C5C78F8
REP 37C0
FF815CB128905CFF5C5C5CD030B070F05C8848C8285011FF18985C5C5C5C78F8
etc ... in order to ZAP module DFHTCP (8 lines)

3.3 - Modify "TWX input translate table", label IECTRASA (modifying
source) or :
VER 5170 3F3F7C7C4040
REP 5170 00007C7C404079791010D7D7F0F09797
etc ... in order to ZAP module DFHTCP (16 lines)

4 - On the CICS side, some parameters for the TCT were
TYPE=SDSCI,DEVICE=TW35,CU=2703, and
TYPE=LINE,ACCMETH=BTAM,TRMTYPE=TWX


I don't know if this help (in case we have in the future a 2703
implementation)


JM Bodin
Post by Ivan Warren
Post by Jean-Marie BODIN
I remember now, that some customers used to use BTAM, a
translation
Post by Ivan Warren
Post by Jean-Marie BODIN
table somewhere, and a 3805 from ITT to make CICS and that
Minitel
Post by Ivan Warren
Post by Jean-Marie BODIN
to speak together. I will try to look for some document in my
archives (no warranty).
Thanks all of you
Those customers were probably using the most infamous 'PA1-NORD' SCS 50
modification. PA1 was the term used for the SCS 50 (Comten 3650 or ITT
3805 Operating system) feature to allow relating PAD X.3 initiated X.25
SVCs to 270X TELE2 devices. The PA1NORD modification (which I
believe
Post by Ivan Warren
was originated by the "Crédit du Nord" bank) effect was to discard the
1st write CCW buffer so that the CICS logon procedure would be
hidden
Post by Ivan Warren
from the end user. Another feature of this modification was, I
think, to
Post by Ivan Warren
allow the application to retrieve the calling X.25 DCE X.121
address so
Post by Ivan Warren
that you could determine how charges would to be applied (or if the user
was entitled to a service).
Incidently, I found out (and modified the patch consequently for my
peruse) that the caller address, even though it was an interesting piece
of information, wasn't the real thing to look for - especially
when
Post by Ivan Warren
determining if the caller was using a Pay for use PAV (3615, 3616,
3617), a regular charge PAV (3614) or a reverse charging PAV
(3613)..
Post by Ivan Warren
The appropriate measure was to make X.25 call facilities available to
the application (Close user group originator and reverse charging were
the X.25 call facilities that held the right information!).
Very off topic trivia.. Sorry !
--Ivan
Tony Harminc
2006-11-08 23:52:34 UTC
Permalink
Post by Jean-Marie BODIN
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 ?
These seem like two separate issues...

The 3767 is a basic, line-mode, SNA device. Connecting it to an OS
running on hercules is not really different from connecting e.g. a
3276; you need to somehow connect a synchronous line, and drive it
with something. Non trivial, to say the least.

There was an early, async version of the 3767 (1974 or so) that
emulated a 2741, I believe. I seem to remember our IBM salseman at the
time bringing one around, and pointing out a slot in the back for some
cartridge that would provide the SNA support, and saying "*That* is
the future...".

Supporting a 2741-like device would be not much different from
supporting async ASCII devices like teletypes. I don't think there is
any code in Herc to do this, but I may be wrong. Certainly an ordinary
PC async port can drive either one quite easily.

Tony H.
chris_john_mason
2006-11-12 06:01:11 UTC
Permalink
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
Kees Verruijt
2006-11-12 19:28:10 UTC
Permalink
Post by chris_john_mason
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/ )
A free and excellent solution under Microsoft Windows is ... x3270 via
Cygwin!

http://www.cygwin.com
--
Kind regards/Vriendelijke groeten,

Kees


[Non-text portions of this message have been removed]
chris_john_mason
2006-11-13 01:11:23 UTC
Permalink
Here's the promised description of 3708 "protocol conversion".

---

3708 Protocol Conversion Notes

A 3270 data stream is received from the SNA application.

This is mapped into a display image within the protocol converter
storage.

An ASCII data stream is constructed which will reproduce the image on
the display screen of the Asynchronous ASCII terminal.

The ASCII data stream might include the ASCII character sequence
necessary to

- clear the screen,
- set the location for the next string of characters to be displayed,
- set the highlighting or colour of the next characters to be
displayed, depending on the 3270 field definition.

The action taken by the protocol converter as keys on the keyboard
are used falls into four categories.

- The character is a graphic character.
-- If the current location on the display surface corresponds to an
unprotected field, the character is echoed back to the Asynchronous
ASCII terminal. If the current highlighting or colour setting is
different from the one required for that field, the character is
preceded by the ASCII sequence necessary to set the highlighting or
colour correctly.
-- If the current location on the display surface corresponds to a
protected field, the ASCII "bell" character, BEL, is normally echoed
and the keyed character does not appear on the display. This is a
major reason why protocol converters require the Asynchronous ASCII
terminal to use echoplexing.

- The character or character sequence generated by the key
corresponds to the function of an AID character, that is, a function
which causes data to be sent to the application. The display image is
analyzed and a 3270 data stream is sent to the application.

- The character or character sequence generated by the key
corresponds to the function of a cursor movement. An ASCII character
sequence is sent to the display of the Asynchronous ASCII terminal
which positions the cursor as required and the logical cursor
position is noted by the protocol converter.

- The character or character sequence generated by the key
corresponds to a function which does not affect communication to the
application or the display image, a "local" function. An example of
such a function is "refresh". This function causes the protocol
converter to clear the display of the Asynchronous ASCII terminal and
construct an ASCII data stream which reproduces the display image
held by the protocol converter on the surface of the display.
The "refresh" function is useful when line errors have distorted
characters sent by the protocol converter.

Support for a particular display under Protocol Conversion depends on
being able to map ASCII character strings to 3270 functions and vice
versa.

- The 3708 technique follows a strict table-driven approach which
makes it easy to define terminal tables but which will not
necessarily handle any terminal.

- The 7171 technique also follows a table-driven approach but
contains branching functions. This makes terminal definition more
difficult but means that a terminal definition can almost certainly
be created for any Asynchronous ASCII display terminal.

3708 Terminal Table Structure

The structure of the 3708 terminal table will serve to illustrate how
the process of mapping input and output sequences to 3270 functions
is accomplished.

The 3708 terminal table consists of a header section for general
definitions such as whether the terminal can support use of sequences
to place and update the status line in line 25 of the terminal
display.

There follows an input table of 160 positions which contains function
numbers corresponding to 3270 functions and "local" functions. There
are currently 62 3270 and "local" functions defined so there is scope
for many more "local" functions to be handled, if necessary.

The 160 position input table corresponds to 32 ASCII control
characters and 128 ASCII characters which were preceded by a "control
sequence introducer" character. The "control sequence introducer"
character is defined in the header section if it is not the "escape",
ESC, character. The header section can also define a character which
may or may not appear between the "control sequence introducer"
character and the, effectively, "lookup" character. This is
the "internal control sequence character".

An example of this input mapping function is the use of the ENTER key
on the 316X display (assigned the "Send Line" function). This key
generates ESC ! 8 CR (assuming CR has been designated as
the "turnaround" character). Thus the "control sequence introducer"
is the default ESC character and ! is the "internal control sequence
character". The input table location for character 8 preceded by the
"control sequence introducer" character, address 00005E, contains the
code for the 3270 ENTER function, 1F. Well, in fact, it contains 9F
since the function code 1F is added, hexadecimally, to 80 in order to
take account of the presence of the following turnaround character,
CR.

Looking at the IBM-supplied table for the 3164, say, it can be seen
that the code for the PF 8 function, 07, is in position 00005E. The
designers of the table have chosen to assign ESC followed by the PF
key number, actually the keys in the numerics row on the keyboard, as
an alternative for using the "F" keys to emulate the 3270 PF keys.
Since this will select the same table position as the use of the
ENTER key (assigned either the Send Line - or - the Send Page
function), this design decision removed the possibility to use the
ENTER key for its obvious function!

This little discussion illustrates neatly the potential complexities
of 3270 emulation design with Asynchronous ASCII display terminals,
at least with the 3708 table-driven terminal definition technique.

The input table is followed by the output table which is relatively
straight-forward.

The output table consists of 19 sets of 6-byte areas which define
ASCII character sequences for output functions.

Each 6-byte area consists of an initial byte which defines the length
of the following ASCII character string. Thus the maximum character
string length is 5.

The fact that only 5 character ASCII sequences can be specified is
also a potential limitation on the Asynchronous ASCII display
terminals which can be supported by the 3708 in Protocol Conversion
mode.

The functions are

- Erase EOF
- Clear Screen
- Cursor Up
- Cursor Down
- Cursor Left
- Cursor Right
- Set Cursor Address

This defines the characters which map into the sequence which defines
the location of the next character when the position needs to be
changed from left to right placement. The general format is described
in the header section as one of six which the 3708 supports. The
format number also describes how the column and row numbers are to be
converted into ASCII characters.

- Highlight On
- Highlight Off
- Alarm or Bell
- Set Colour for unprotected and normal intensity (green)
- Set Colour for unprotected and high intensity (red)
- Set Colour for protected and normal intensity (blue)
- Set Colour for protected and high intensity (white)
- Status Line On - Characters to precede the status line character
string.
- Status Line Off - Characters to follow the status line character
string.
- Activate Status - Actually any sequence which is required initially
to prepare the terminal logic for following character strings. In
early 3708 microcode releases, it was necessary to prepare the 3164
logic to accept the ASCII sequences which set colour, so-
called "enable program colour".
- Start Printer - Cause following data to be directed to the
auxiliary, printer, port.
- Stop Printer - Stop following data being directed to the auxiliary,
printer, port.

An example of an output function character string as coded in the 6-
byte area is 051B34202240, ESC 4 SP (space) " @, which is found in
location 0000E2 of the table for the 3164.

The output function corresponds to "Set Colour for Input and Normal
Intensity". The string will be inserted into the outbound data stream
in echoed data whenever the cursor enters an unprotected, normal
intensity data field or the following characters in outbound data
appear in such a field.

In full the string means

- "set character attribute response (that is, outbound)" with
parameters
-- allow display (that is, not non-display)
-- normal intensity
-- no blinking
-- no underline
-- no reverse video
-- green foreground
-- black foreground

Note that 031B3440, ESC 4 @, could also be specified since "green
foreground" and "black background" are defaults and default parameter
values need not be given.

Since the table ends here, there is space to add additional output
function ASCII character strings in the future.
Gerhard Postpischil
2006-11-13 06:28:57 UTC
Permalink
Post by chris_john_mason
Here's the promised description of 3708 "protocol conversion".
I don't recall which is which, and there were number of non-IBM
imitators (Renex TM-3 comes to mind), but one of these supported
terminals that did not have direct character addressing, but
only worked by line address.

Also neat was the pass-through function - anything after some
code (I seem to remember EBCDIC 2B or 2D?) got passed to the
terminal as is. My preferred device was a Wyse-50, and the
pass-through function allowed me to write memos, invoices, and
other small documents to an attached serial printer (Swintec,
with a daisy wheel, still in use after 26 years)

Gerhard Postpischil
Bradford, VT
Dominika Plucińska
2006-11-13 15:32:28 UTC
Permalink
Hi,

I'm trying to stop hercules from script
(script is started using DIAGNOSE command)

and hercules hung-up
don't send any message, no end - just do nothing

any suggesion ?

Gregor Plucinski
Martin
2006-11-13 18:08:50 UTC
Permalink
Gregor,

Is this 3767 related?

If no- I might be able to answer- but please leave this thread
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
Grzes Plucinski
2006-11-13 17:58:45 UTC
Permalink
Hi,

I'm trying to stop hercules from script
(script is started using DIAGNOSE command)

and hercules hung-up
don't send any message, no end - just do nothing

any suggesion ?

Gregor Plucinski
Grzes Plucinski
2006-11-13 18:23:55 UTC
Permalink
Hi,

I'm trying to stop hercules from script
(script is started using DIAGNOSE command)

and hercules hung-up
don't send any message, no end - just do nothing

any suggesion ?

Gregor Plucinski
Martin
2006-11-13 21:31:12 UTC
Permalink
Gregor,

am doing something similiar....

first thing- get the latest CVS version.

I have had difficulties with W/98 but Fish did a great job to fix these
(hence above advise)

I am now having difficulties with DIAG to shutdown/POWEROFF as well...
it does hung up. It could be timing issue.

Could you insert delays/sleep for a second or so?

But to get things going I would first upgrade to latest version.
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
Andrew H. Derbyshire
2006-11-13 18:49:44 UTC
Permalink
Post by chris_john_mason
Here's the promised description of 3708 "protocol conversion".
I'd ask if the question is does the originator of the topic want to
support the 3767 in line mode (ala MVT TSO) for the fun of it or as a
full screen device (to get rid of the need for a c3270 emulator).

I mention this because ...

The TTY mode is going to be ugly when used in any TSO environment
expecting only 3270 terminals. For example, that ugly (sorry) full
screen help command on the TK system may do not line mode real well.
VM won't be so bad, it liked line mode devices a lot more.

(Wylbur was great for line mode devices, but "was" != "is" at the
present moment. ROSCOE 4.x worked for ttys, more or less. But I
digress.)

The 3270 mode coverter would be an entire software project of its own,
and would be hard to do it well from scratch. I would suggest writing
a pure ASCII -> TN3270 protocol converter server, rather than any
attempt to couple it directly to Hercules.

As an aside, I wonder if the old 16 bit OS/2 3270 emulators run under
Windows (if they ever did)? :-)

-ahd-
David Wade
2006-11-13 19:28:16 UTC
Permalink
-----Original Message-----
On Behalf Of Andrew H. Derbyshire
Sent: 13 November 2006 18:50
Subject: [hercules-390] Re: Devtype 3767
Post by chris_john_mason
Here's the promised description of 3708 "protocol conversion".
I'd ask if the question is does the originator of the topic want to
support the 3767 in line mode (ala MVT TSO) for the fun of it or as a
full screen device (to get rid of the need for a c3270 emulator).
If he wants a boxed 3270 emulator these pop up often on E-Bay. E.g.

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=330048038336

and

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=150056582075

are currently available. Not sure about PCOMMS but smart term does come with all languages available...
I mention this because ...
The TTY mode is going to be ugly when used in any TSO environment
expecting only 3270 terminals. For example, that ugly (sorry) full
screen help command on the TK system may do not line mode real well.
VM won't be so bad, it liked line mode devices a lot more.
In general VM will be fine as its support for 3270 is "minimal". I keep thinking about using MVS just for the better full screen support....
(Wylbur was great for line mode devices, but "was" != "is" at the
present moment.
Isn't the Wylbur for TSO around some where..
ROSCOE 4.x worked for ttys, more or less. But I
digress.)
I also found ROSCOE limiting, not sure why, perhaps I never got really used to it...
The 3270 mode coverter would be an entire software project of its own,
and would be hard to do it well from scratch. I would suggest writing
a pure ASCII -> TN3270 protocol converter server, rather than any
attempt to couple it directly to Hercules.
But that already exists. Its called TN3270 and it runs on any Linux box. As I have said before I am pretty sure you could build a "virtual" 7171 using a few scripts and TN3270. I bet it would also run under CYGWIN on Windows...
As an aside, I wonder if the old 16 bit OS/2 3270 emulators run under
Windows (if they ever did)? :-)
As far as I know support for the OS/2 subsystem was dropped in XP. I also think there may be issues with IP stack. I don't think the Windows OS/2 system supports IP access...
-ahd-
Dave
Andrew H. Derbyshire
2006-11-14 00:35:13 UTC
Permalink
Post by David Wade
Post by Andrew H. Derbyshire
(Wylbur was great for line mode devices, but "was" != "is" at the
present moment.
Isn't the Wylbur for TSO around some where..
I've got the real thing downloaded, but not onto MVS yet (much less
running).
Post by David Wade
Post by Andrew H. Derbyshire
ROSCOE 4.x worked for ttys, more or less. But I
digress.)
I also found ROSCOE limiting, not sure why, perhaps I never
got really used to it...
That's because it WAS limiting.

The ROSPROC script language in 4.x (~1979) was the closest you could
get to a Turing machine and still try to get work done. ADR more or
less fixed it in 5.x (~1984) with a new language called RPF, which had
real logic, and could do full screen I/O for programs. There was also
good 3270 editing support in the 5.x versions and more powerful
commands in general.

Even compared to ROSCOE 5.x, Wylbur is far more expressive, both
interactively and in scripts. Wylbur lost its edge when full screen
editing came of age and you didn't need command line search and
replace commands from hell so much. (Later versions did full screen
editing on 3270's of course, but all 3270 editor screens sort of look
the same.)

-ahd-
chris_john_mason
2006-11-22 12:10:52 UTC
Permalink
Dave

I don't see the 7171 being supported quite as easily as you suggest
here. Having taken apart, as it were, how the 3708 achieves the
protocol conversion function, I can see that it would need a
dedicated program which copied the 3708 or the 7171 technique. The
channel appearance logic could perhaps use the channel appearance
logic from the TN3270 server.

Chris Mason
Post by David Wade
-----Original Message-----
On Behalf Of Andrew H. Derbyshire
Sent: 13 November 2006 18:50
Subject: [hercules-390] Re: Devtype 3767
...
The 3270 mode coverter would be an entire software project of its own,
and would be hard to do it well from scratch. I would suggest writing
a pure ASCII -> TN3270 protocol converter server, rather than any
attempt to couple it directly to Hercules.
But that already exists. Its called TN3270 and it runs on any Linux
box. As I have said before I am pretty sure you could build
a "virtual" 7171 using a few scripts and TN3270. I bet it would also
run under CYGWIN on Windows...
chris_john_mason
2006-11-14 05:42:14 UTC
Permalink
Andrew

In my Mon Nov 13, 2006 1:58 am post to Jean-Marie I pose just the
question you mention.

Chris Mason
Post by Andrew H. Derbyshire
I'd ask if the question is does the originator of the topic want to
support the 3767 in line mode (ala MVT TSO) for the fun of it or as a
full screen device (to get rid of the need for a c3270 emulator).
chris_john_mason
2006-11-22 11:39:51 UTC
Permalink
Andrew

Comments are embedded.

Chris Mason
Post by Andrew H. Derbyshire
I'd ask if the question is does the originator of the topic want to
support the 3767 in line mode (ala MVT TSO) for the fun of it or as a
full screen device (to get rid of the need for a c3270 emulator).
The originator of the topic specified interest in line-by-line only
and not really a 3767 but an asynchronous ASCII device of which a
Minitel happens to be an example. However it may be that the Minitel
insists on working only with an application which "understands" the
VT100 type of full-screen data stream.
Post by Andrew H. Derbyshire
The TTY mode is going to be ugly when used in any TSO
environment ...

My experience with a Videotex device trying to use line-by-line TSO
was indeed "ugly".
Post by Andrew H. Derbyshire
The 3270 mode coverter would be an entire software project of its own,
and would be hard to do it well from scratch. I would suggest
writing
Post by Andrew H. Derbyshire
a pure ASCII -> TN3270 protocol converter server, rather than any
attempt to couple it directly to Hercules.
I think perhaps what you have in mind is *not* TN3270 but simply 3270
so that you are proposing an ASCII data stream <-> 3270 data stream
protocol converter which presents the pre/non-SNA 3270 channel-
attached controller appearance to the operating system. In other
words behaves like a 7171.
Andrew H. Derbyshire
2006-11-23 01:18:43 UTC
Permalink
If the user wants an easy line mode experience, we would want to
provide a WYLBUR (or similar strong line mode support) environment
and perhaps TCAM, which from my limited reading seems to have been
more async device friendly.

Not this week's project.

-ahd-
pfg504
2006-11-23 06:30:10 UTC
Permalink
I just read some FLEX-OS marketing stuff and they do support ASCII
TWX devices for local attached, telnet or modem attached.

Does MVS 3.8 still support TWX devices? The VM/370 R6 code has
support for them?

Paul
Post by Andrew H. Derbyshire
If the user wants an easy line mode experience, we would want to
provide a WYLBUR (or similar strong line mode support) environment
and perhaps TCAM, which from my limited reading seems to have been
more async device friendly.
Not this week's project.
-ahd-
Tony Harminc
2006-11-23 15:49:15 UTC
Permalink
Post by pfg504
Does MVS 3.8 still support TWX devices? The VM/370 R6 code has
support for them?
Yes, and Yes. But of course there is still the need for Hercules
support of some sort to provide a 270x-like device for the OS and/or
its applications to talk to.

To be more specific, VM/370 supports TWX devices both for console
access (i.e. to logon to a virtual machine), and as devices that can
be attached to guest machines. MVS supports such devices via BTAM and
TCAM (and possibly very early versions of VTAM?). MVS TSO uses TCAM.
And of course you can write your own access method using EXCP, as do
such programs as Milten/Wylbur, Sharp APL, and so on.

Tony H.
pfg504
2006-11-23 17:46:28 UTC
Permalink
Looking through the VM/370 code (DMKCNS) it looks like a very minimum
set of CCWs are needed for TWX support, but the data arrives at the
host bit backwards. That is if the controller received a CR with even
parity, a x'B1' is in the buffer.

As far as I can tell from the VM code, the CCWs needed are:

X'2F'- Disable
X'27'- Enable
X'13', X'17', X'1B' or X'1F' - SETADDR (I'm not sure yet which one)
X'01'- Write
X'03'- NOP
X'0A'- READ INHIBIT
X'02'- READ

We could also add support for 2741 and 1050s. These appear to be hung
off a 270x like the TTY (TWX) devices.

And 3210, 2150 and 7412 devices. These are almost identical to the
current 3215 and 1052 support.

Paul
Post by Tony Harminc
Post by pfg504
Does MVS 3.8 still support TWX devices? The VM/370 R6 code has
support for them?
Yes, and Yes. But of course there is still the need for Hercules
support of some sort to provide a 270x-like device for the OS and/or
its applications to talk to.
To be more specific, VM/370 supports TWX devices both for console
access (i.e. to logon to a virtual machine), and as devices that can
be attached to guest machines. MVS supports such devices via BTAM and
TCAM (and possibly very early versions of VTAM?). MVS TSO uses TCAM.
And of course you can write your own access method using EXCP, as do
such programs as Milten/Wylbur, Sharp APL, and so on.
Tony H.
Tony Harminc
2006-11-23 20:50:59 UTC
Permalink
Post by pfg504
Looking through the VM/370 code (DMKCNS) it looks like a very minimum
set of CCWs are needed for TWX support, but the data arrives at the
host bit backwards. That is if the controller received a CR with even
parity, a x'B1' is in the buffer.
The definition of "backwards" wrt bit order of bytes on the wire has
been the topic of much argument over the decades - much along the
lines of big- vs little- endian storage of bytes within a word.
Post by pfg504
X'2F'- Disable
X'27'- Enable
X'13', X'17', X'1B' or X'1F' - SETADDR (I'm not sure yet which one)
X'01'- Write
X'03'- NOP
X'0A'- READ INHIBIT
X'02'- READ
I'm fairly sure all the SAD commands above are only for 2702
compatibility, and are ignored on a 2703 or 370x EP.

There is actually a 2703 manual on bitsavers.org, and it lists in good
detail all those commands and their functions. Don't let the fact that
it lists them all in binary only (with parity) bother you!
Post by pfg504
We could also add support for 2741 and 1050s. These appear to be hung
off a 270x like the TTY (TWX) devices.
Yes, except that, as I said earlier, handling of attn/break is a bit
different. But both are described in the 2703 book.
Post by pfg504
And 3210, 2150 and 7412 devices. These are almost identical to the
current 3215 and 1052 support.
Yup - all essentially the same line-mode console device, with no
control at all. :-)

What I'd like to write at some point is 3066 support for Herc. There's
enough evidence in VM and MVT/MVS to see how to program it, and it's
really a very simple device. Of course what you put on the outboard
end is a question; since there is no real possibility of finding a
real one out there, I think tn3270 would be the thing to map to it.

Tony H.
chris_john_mason
2006-11-22 14:46:51 UTC
Permalink
Update to Summary

It has been established that the Jean-Marie Bodin, the original
poster, was not proposing the use of protocol conversion. Thus use of
an asynchronous ASCII device, assuming it has the necessary "smarts"
like a 3101 or VT100, in order to support a 3270 application was
*not* actually being requested.

Two topics have been addressed here:

1. Use of Minitel in order to run 3270 applications on the operating
system supported by Hercules.

2. Use of an asynchronous ASCII device, of which Minitel is an
example, in order to run line-by-line applications on the operating
system supported by Hercules.

2a. Not to miss all options: use of Minitel in order to run
specialised applications, which are written to manage Minitel
(essentially VT100) data streams but where ASCII is translated into
EBCDIC, on the operating system supported by Hercules. This is in
practice no different from unqualified case 2, that is, as far as
CICS, say, VTAM and anything running underneath is concerned, this
still appears to be a line-by-line application.

Just to reiterate, as far as Jean-Marie is concerned, topic
1, "3270", is not of interest.

-

However, I expect, the idea having been mooted, that topic 1, "3270",
is still an interesting topic to discuss.

I am not a Hercules specialist. I lurk for when SNA topics arise -
and this was one - also NCP, X.25 and some related topics - largely
Jurassic stuff.

As far as I can see 3270 support comes in the shape of a TN3270
server mapping to a pre/non-SNA 3270 channel-attachment appearance
from the Hercules environment. Thus the responsibility for driving
the 3270 data stream is in the TN3270 client and is never the
responsibility of anything to do with Hercules.

I think there is a consensus that topic 1, "3270", can be handled
with protocol conversion using 7171-like (or 3708-like) logic with a
7171-like pre/non-SNA 3270 channel-attached appearance. The
connection to the PC would be through an asynchronous adapter.
Real "V.24", typically dial, modems could be used or a "null" modem.
Because of the need to use "echoed" characters, X.25 and IP transport
options are not practical.

The use of the pre/non-SNA 3270 channel-attached appearance for the
above solution is appropriate because it exploits the existing
support used for the Hercules TN3270 server and the support is there
because console support is needed.

-

Topic 2, "line-by-line", is tricky because there is no channel-
attached appearance support for other than the 3270 data stream.
However, IP connectivity is provided to the supported operating
system through Hercules, for example, 3172 LCS emulation. This can be
exploited - I expect - so that a basic TELNET client can be
implemented in Hercules code which maps to driving an asynchronous
adapter over which ASCII data streams flow. This would then support a
real Minitel with real or "null" modems. I say "real Minitel" since
running Minitel emulation code on a PC would generally be pointless
given that it's likely that the IP connectivity extends to the PC so
that the PC could run the TELNET client. The only exception where
Minitel emulation on a PC would be sensible is where the operating
system application actually understood the EBCDIC translation of
the "cleverer", "full-screen", aspects of the Minitel data stream.

There is however a "fly in the ointment": based upon some experience
I had trying to make a Videotex device work line-by-line with TSO, I
discovered it didn't really work. Minitel is a type of Videotex
device, I believe.

Chris Mason
Post by chris_john_mason
Here's my summary of what's been going on in this thread.
...
harrywahl2000
2006-11-13 21:27:08 UTC
Permalink
The 3708 is attached to the mainframe using a synchronous, SDLC link
and is defined as an SNA PU. It is not a good candidate for Hercules
connection since it required an NCP or integrated ICA to connect to
the mainframe and because the TN3270 terminal server in Hercules
uses a non-SNA protocol. I don't think Hercules has a mechanism (I'm
not saying the guest operating systems don't, e.g. using VTAM and
downstream PUs via TCP/IP) to emulate SNA 3270 terminals.

The AEA on some 3174s is a possibility if one configured to run
local non-SNA mode were emulated. This could be an extension to the
TN3270 server intrinsic to Hercules to accept serial modem (NULL or
not) RS-232 connection in addition to TCP/IP TN3270 connections. A
real or emulated (ProComm, FTTERM) ASCII terminal (such as a VT100)
could dial or connect to a serial port. I think the difficulty of
coding this would be the differences in implementation of serial
port programming between the various machines and operating systems
that host Hercules.

If this were implemented, a 7171 would be the best candidate for
emulation. It appeared to be channel attached 3270 terminals, just
like Hercules presents TCP/IP TN3270 connections to the operating
system and it has a commonly used and fully described "transparent"
mode to allow VTAM or CICS to communicate easily to serial devices,
even using BMS.

VSE never natively supported 7171s, they did however work under VSE
and many enterprises used them under VSE.

As for the 3767: it is an SNA device and must be defined to the
operating system as an LU. If your goal is to attach a real 3767 you
should consider getting a 3174 with a token ring or Ethernet feature
and attach it to it. Otherwise it may be necessary to code something
that emulates a downstream SNA 3174 under TCP/IP and further
emulation code up to the device you are actually using.

As for teletypes: they belong in another era, being more a primitive
messaging system than a terminal type to connect to a mainframe.
They date to 1907. Asking for Teletype support on Hercules would be
like asking for fax support or maybe Morse code telegraph
connectivity? The only mainframe users of teletypes I've ever seen
or heard about front-ended them with Series/1 computers or special
code in an NCP and they were either message routing or transitioning.
David Wade
2006-11-13 23:00:43 UTC
Permalink
Post by harrywahl2000
If this were implemented, a 7171 would be the best candidate for
emulation. It appeared to be channel attached 3270 terminals, just
like Hercules presents TCP/IP TN3270 connections to the operating
system and it has a commonly used and fully described "transparent"
mode to allow VTAM or CICS to communicate easily to serial devices,
even using BMS.
A 7171 was a complex beast. It had a large number of configuration options. Emulating the terminal part of a 7171 is a non-trivial option....
Post by harrywahl2000
VSE never natively supported 7171s, they did however work under VSE
and many enterprises used them under VSE.
I don't recall any OS "natively" supporting the 7171. I am pretty sure we always gened ours as a 3174 to VM....
Post by harrywahl2000
As for the 3767: it is an SNA device and must be defined to the
operating system as an LU. If your goal is to attach a real 3767 you
should consider getting a 3174 with a token ring or Ethernet feature
and attach it to it. Otherwise it may be necessary to code something
that emulates a downstream SNA 3174 under TCP/IP and further
emulation code up to the device you are actually using.
That would be great, but we don't have the levels of VTAM that support the Token Ring card on the 3174...
Post by harrywahl2000
As for teletypes: they belong in another era, being more a primitive
messaging system than a terminal type to connect to a mainframe.
They date to 1907. Asking for Teletype support on Hercules would be
like asking for fax support or maybe Morse code telegraph
connectivity? The only mainframe users of teletypes I've ever seen
or heard about front-ended them with Series/1 computers or special
code in an NCP and they were either message routing or transitioning.
But Hercules lives in the 70's. VM/370R6 dates from 1979. I used a 2741 in 1972 to 1976 on a 360/67 and later a 370 both running MTS. Later on when I worker for Salford University, even in the late 80's and early 90's we still had many users using line mode support in VM. Yes they did come in via Series/1 which provided the X.25 interface, but we hijacked the SNA line mode CCS support to present the screens to CP, either as TTY or 3101. This support was continually enhanced by IBM through VM/SP R4, R5 and R6 so I can only assume others used it. I think the original "FAL" TCP-IP product used the same interface to get stuff into VM.

Personally I am slightly shocked that you can't use a TTY or 2741 as a TSO terminal. When the original TSO TCP/IP product appeared how did that present terminals to TSO? Did it rely on ACF VTAM function to where a program acts as a terminal?

Dave.
chris_john_mason
2006-11-22 12:24:03 UTC
Permalink
Dave

Comments are embedded

Chris Mason
Post by David Wade
Post by harrywahl2000
If this were implemented, a 7171 would be the best candidate for
emulation. It appeared to be channel attached 3270 terminals, just
like Hercules presents TCP/IP TN3270 connections to the operating
system and it has a commonly used and fully
described "transparent"
Post by David Wade
Post by harrywahl2000
mode to allow VTAM or CICS to communicate easily to serial
devices,
Post by David Wade
Post by harrywahl2000
even using BMS.
A 7171 was a complex beast. It had a large number of configuration
options. Emulating the terminal part of a 7171 is a non-trivial
option....

So now emulating the 7171 is complex. <g>

Maybe limiting support to the VT100 would cater for most users.
However, unless there's support in the VT100 similar to the support
found in the IBM range of devices such as the 3101 and its
successors, you won't be able to support protocol conversion to the
3270 data stream. I'm not saying such support isn't there. Other OEM
device types were supported by the 3708 and very probably the 7171.
Even so support for Videotex terminals such as the Minitel may not be
possible if the "Videotex" version of the VT100 includes only "block
mode" support for full screen control.

I'm starting to get pessimistic. It may be that the Minitel can
support neither line-by-line access nor 3270 full-screen access to a
Hercules-supported operating system.
Post by David Wade
Post by harrywahl2000
VSE never natively supported 7171s, they did however work under VSE
and many enterprises used them under VSE.
I don't recall any OS "natively" supporting the 7171. I am pretty
sure we always gened ours as a 3174 to VM....

Although I never actually had one to play with, it is also my
understanding that the 7171 was designed to appear identical to a
channel-attached 3270 controller to the operating system.
Post by David Wade
... but we don't have the levels of VTAM that support the Token
Ring card on the 3174...

I thought myself a VTAM specialist but I don't recognise what the
support problem might be here. I presume you are speaking of non-SNA
channel attached 3174. What aspect of the token ring support is it
that VTAM might need to be enhanced to support? I suspect you may
have "downstream PUs" in mind. Isn't the support there to have each
node (loosely referred to as "PU") appear on a separate channel
address? I could be wrong since I think I only ever played
with "remote" 3174s and "downstream PUs".
Post by David Wade
But Hercules lives in the 70's. VM/370R6 dates from 1979. I used a
2741 in 1972 to 1976 on a 360/67 and later a 370 both running MTS.

That'll be Newcastle(-upon-Tyne) University - which you mention in a
later post.
Post by David Wade
Personally I am slightly shocked that you can't use a TTY or 2741
as a TSO terminal.

You can use a 2741 or an asynchronous ASCII device (substituted for
TTY) to access TSO. I've used both and taught hands-on class using
the later. You needed the NTO add-on product to NCP.
Post by David Wade
When the original TSO TCP/IP product appeared how did that present
terminals to TSO?

When you say TSO TCP/IP I expect you mean TCP/IP for MVS. Since we
are talking about TCP/IP, I expect you mean TELNET. In TCP/IP for
MVS, in the earliest version I used which I think was so early that
IBM had to grant access to the product on an individual basis, this
was, and still is, defined as LINEMODE. In the TELNET server
(confusingly called the TN3270 server) a simple line-by-line TELNET
connection is concatenated to an SNA session with a mode table entry
which defines the presentation layer protocols as those used by the -
you got it - 3767, TSO being the primary end of the session and the
TELNET server being the secondary end of the session.
Post by David Wade
Did it rely on ACF VTAM function to where a program acts as a
terminal?

No.
Gerhard Postpischil
2006-11-22 15:06:34 UTC
Permalink
Post by chris_john_mason
Maybe limiting support to the VT100 would cater for most users.
However, unless there's support in the VT100 similar to the support
found in the IBM range of devices such as the 3101 and its
successors, you won't be able to support protocol conversion to the
3270 data stream.
The VT100 is an awful device to consider for anything other than
line mode. The VT100+, VT101, and later versions offered a
better choice of control commands (byte addressing, etc.). I
also fondly recall a Wyse-50 that allowed me (with some tweaks
in Wylbur) to run in mode 4, with line 44 for status information
(and a Wyse-300 that let me build my own characters, so I
actually had a not sign and cent sign on the screen).

The basic support I'd like to see is for 2701/2703 asynch,
connecting either to telnet, or to a physical serial port with a
terminal plugged into it (might even get a Hydra type beast
and connect up to 32 terminals?). Some of the early terminals
required a constant data stream (don't remember the command;
might have been Prepare to Read?) to stay connected - I consider
that beyond the scope of a minimum request. With the exception
of attention/break (and line drop), the connection was logically
half-duplex. I used Wylbur with various device types, and
preferred entering new assembly code using the tab key - it's
much faster than groping around a CRT (I know about logical
tabs, but don't like them, as they don't reflect the final product).

Unless a physical terminal is involved, or someone lacks access
to tn3270(e), protocol conversion is overkill. However, if we
implement it at all, it should be parameterized. It takes
several different methods for converting screen addresses each
way, but the remaining commands are mostly straight-forward. I
have a table of the outbound commands somewhere, and may be able
to find the others (I should have manuals for the Wyse-75/VT10n,
Wyse-50, Esprit, and a few others around).

I would like to suggest that if we do this, it would require
some tweaking in Hercules to support dropping and reconnecting a
terminal. This feature seems lacking (when I lose a tn3270e
session, I never seem to be able to reconnect, and wind up
restarting the system - perhaps I'm missing something?).

Gerhard Postpischil
Bradford, VT
Ivan Warren
2006-11-22 15:33:19 UTC
Permalink
Post by Gerhard Postpischil
I would like to suggest that if we do this, it would require
some tweaking in Hercules to support dropping and reconnecting a
terminal. This feature seems lacking (when I lose a tn3270e
session, I never seem to be able to reconnect, and wind up
restarting the system - perhaps I'm missing something?).
A little bit more details would help here.

Especially what do you mean by 'not able to reconnect' (connection
refused, not detected by guest program, garbled display, etc, etc..) ?

Also, what version of hercules are you talking about ?

Thanks,

--Ivan
Gerhard Postpischil
2006-11-22 19:51:47 UTC
Permalink
Post by Ivan Warren
A little bit more details would help here.
Especially what do you mean by 'not able to reconnect' (connection
refused, not detected by guest program, garbled display, etc, etc..) ?
The session gets disconnected (erroneously, or due to some
software problem. For instance changing the status of either a
cable or wireless connection knocks out the Hercules/BlueZone
sessions). BlueZone tries to reconnect, and gets a different
CRT. The original CRTs, especially the console, never get
reconnected no matter what I try.
Post by Ivan Warren
Also, what version of hercules are you talking about ?
All I've tried (first the original turnkey version, then a
Cygwin and a Windows version I downloaded about a month or so ago).

Gerhard Postpischil
Bradford, VT
Phil Dickinson
2006-11-22 20:28:49 UTC
Permalink
I've always thought the use of tn3270 for OS consoles is a flawed idea. I
have given up and no longer use 3270 consoles on my mvs38j system, I now use
the embedded console support within the hercules console for my mvs
copnsole.

As a slightly off topic request... I would prefer to see an option on the
tn3270 telnet support that didn't take any action on a disconnect, that
allow MVS to continue sending messages to the 3270 screen even if there is
no tn3270 session in existence. That way, when we reconnect we just need to
press the clear key and the master console will redisplay and all will be
fine.

The hercules tn3270 support seems to work ok for TSO sessions, and using
logon reconnect works fine when I pick up a different subchannel address
after losing a tn3270 session. Well most of the time anyway.

Phil
Post by Gerhard Postpischil
Post by Ivan Warren
A little bit more details would help here.
Especially what do you mean by 'not able to reconnect' (connection
refused, not detected by guest program, garbled display, etc, etc..) ?
The session gets disconnected (erroneously, or due to some
software problem. For instance changing the status of either a
cable or wireless connection knocks out the Hercules/BlueZone
sessions). BlueZone tries to reconnect, and gets a different
CRT. The original CRTs, especially the console, never get
reconnected no matter what I try.
Post by Ivan Warren
Also, what version of hercules are you talking about ?
All I've tried (first the original turnkey version, then a
Cygwin and a Windows version I downloaded about a month or so ago).
Gerhard Postpischil
Bradford, VT
[Non-text portions of this message have been removed]
pfg504
2006-11-23 06:35:42 UTC
Permalink
The VM/370 R6 code had the same problem where sessions would become
unavailable after any type of disconnect. The problem was corrected
with proper handling of an unsolicited interrupt. I have not heard
any more complaints from the VM/370 people.


Paul
Post by Phil Dickinson
I've always thought the use of tn3270 for OS consoles is a flawed idea. I
have given up and no longer use 3270 consoles on my mvs38j system, I now use
the embedded console support within the hercules console for my mvs
copnsole.
As a slightly off topic request... I would prefer to see an option on the
tn3270 telnet support that didn't take any action on a disconnect, that
allow MVS to continue sending messages to the 3270 screen even if there is
no tn3270 session in existence. That way, when we reconnect we just need to
press the clear key and the master console will redisplay and all will be
fine.
The hercules tn3270 support seems to work ok for TSO sessions, and using
logon reconnect works fine when I pick up a different subchannel address
after losing a tn3270 session. Well most of the time anyway.
Phil
Post by Gerhard Postpischil
Post by Ivan Warren
A little bit more details would help here.
Especially what do you mean by 'not able to reconnect'
(connection
Post by Phil Dickinson
Post by Gerhard Postpischil
Post by Ivan Warren
refused, not detected by guest program, garbled display, etc, etc..) ?
The session gets disconnected (erroneously, or due to some
software problem. For instance changing the status of either a
cable or wireless connection knocks out the Hercules/BlueZone
sessions). BlueZone tries to reconnect, and gets a different
CRT. The original CRTs, especially the console, never get
reconnected no matter what I try.
Post by Ivan Warren
Also, what version of hercules are you talking about ?
All I've tried (first the original turnkey version, then a
Cygwin and a Windows version I downloaded about a month or so ago).
Gerhard Postpischil
Bradford, VT
[Non-text portions of this message have been removed]
pfg504
2006-11-22 16:07:28 UTC
Permalink
What problem are we creating to which the ASCII devices (VT100,
VT101, etc.) are the solution?

Having written and marketed a FT/TERM (SOFT/3270) replacement for
many years, I can not see the value in going this direction.

At AMS where Gerhard and I worked, we were using TTY support with
Wylbur and Milten via a Memorex 270x emulator.

Why are we taking a giant leap backward?

The 7171 behaved as a 3274-1D channel attached non-sna 3270 crt
controller. The 3708 was a simular device, but was linked attached
like a 3274-1C. The 3708 also provided a protocal enveloping
function. When used as a 3274 controller it also provided a split
stream function allowing the use of both a 3270 and 3287 session via
the same port. There was also a YALE Series-1 OS that provided 3270
emulation. The 7171 configuration and data stream was modeled after
the Yale OS.

Having said all that, again, what problem are we creating to which
the Glass-twx devices are the solution.

Paul
Post by Gerhard Postpischil
Post by chris_john_mason
Maybe limiting support to the VT100 would cater for most users.
However, unless there's support in the VT100 similar to the
support
Post by Gerhard Postpischil
Post by chris_john_mason
found in the IBM range of devices such as the 3101 and its
successors, you won't be able to support protocol conversion to the
3270 data stream.
The VT100 is an awful device to consider for anything other than
line mode. The VT100+, VT101, and later versions offered a
better choice of control commands (byte addressing, etc.). I
also fondly recall a Wyse-50 that allowed me (with some tweaks
in Wylbur) to run in mode 4, with line 44 for status information
(and a Wyse-300 that let me build my own characters, so I
actually had a not sign and cent sign on the screen).
The basic support I'd like to see is for 2701/2703 asynch,
connecting either to telnet, or to a physical serial port with a
terminal plugged into it (might even get a Hydra type beast
and connect up to 32 terminals?). Some of the early terminals
required a constant data stream (don't remember the command;
might have been Prepare to Read?) to stay connected - I consider
that beyond the scope of a minimum request. With the exception
of attention/break (and line drop), the connection was logically
half-duplex. I used Wylbur with various device types, and
preferred entering new assembly code using the tab key - it's
much faster than groping around a CRT (I know about logical
tabs, but don't like them, as they don't reflect the final product).
Unless a physical terminal is involved, or someone lacks access
to tn3270(e), protocol conversion is overkill. However, if we
implement it at all, it should be parameterized. It takes
several different methods for converting screen addresses each
way, but the remaining commands are mostly straight-forward. I
have a table of the outbound commands somewhere, and may be able
to find the others (I should have manuals for the Wyse-75/VT10n,
Wyse-50, Esprit, and a few others around).
I would like to suggest that if we do this, it would require
some tweaking in Hercules to support dropping and reconnecting a
terminal. This feature seems lacking (when I lose a tn3270e
session, I never seem to be able to reconnect, and wind up
restarting the system - perhaps I'm missing something?).
Gerhard Postpischil
Bradford, VT
Gerhard Postpischil
2006-11-22 19:23:59 UTC
Permalink
Post by pfg504
Having said all that, again, what problem are we creating to which
the Glass-twx devices are the solution.
1) It will give me an excuse to dig out my Wyse-50 and hook it
up <G>

2) With the above or telnet, it will allow running Wylbur (both
a TSO version and a Milten/Wylbur system will be available, with
at least the former lacking full-screen support).

3) (expensive) dial-in support?

4) Because they're there ?

Cheers,

Gerhard Postpischil
Bradford, VT
Tony Harminc
2006-11-22 17:44:18 UTC
Permalink
Post by pfg504
What problem are we creating to which the ASCII devices (VT100,
VT101, etc.) are the solution?
My interest in this, and I believe the original poster's interest too,
is support of legacy hardware. The "problem" is just that right now it
isn't possible to connect e.g. a Minitel, or in my case my real 2741,
to an operating system hosted on Hercules.

We aren't solving a current, real-world, business problem.

Tony H.
Dave Wade
2006-11-22 20:48:28 UTC
Permalink
----- Original Message -----
From: "Tony Harminc" <tharminc-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Wednesday, November 22, 2006 5:44 PM
Subject: Re: [hercules-390] Re: Devtype 3767
Post by Tony Harminc
Post by pfg504
What problem are we creating to which the ASCII devices (VT100,
VT101, etc.) are the solution?
My interest in this, and I believe the original poster's interest too,
is support of legacy hardware. The "problem" is just that right now it
isn't possible to connect e.g. a Minitel, or in my case my real 2741,
to an operating system hosted on Hercules.
What sort of interface does it have? Can you connect it to anything?
Post by Tony Harminc
We aren't solving a current, real-world, business problem.
nope, this is fun fun fun
Post by Tony Harminc
Tony H.
Dave.
Ivan Warren
2006-11-22 16:54:44 UTC
Permalink
Post by pfg504
Having said all that, again, what problem are we creating to which
the Glass-twx devices are the solution.
Solutions in the emulation world do no pre-require a problem !

If a user wants to do something he could do with the original stuff,
then it is (IMHO) legitimate to probe the lot for an emulation of it.

As far as hercules itself is concerned, how an emulated facility is used
is fairly irrelevant (besides the fact that something that used to work
should still work - otherwise the facility implementation is probably
buggy).

hercules as an emulator could possibly provide an ASCII port interface
such as was provided by either the 270X, the 37XX (in EP mode) or the
4361/9370 ICA (all that is needed is to interpret the CCWs properly and
match that with read/write/control to some data/control channel).. The
terminal/program sink used afterwards is of no direct concern to
hercules.. (attach a 3101, a minitel, a serial printer, a telnet
program, a modem.. use your imagination). Providing an NCP and/or
NCP+NPSI implementation would be another subject altogether !

Also, whether the guest program supports such device is, in itself, not
an hercules issue.. hercules only provides an infrastructure.

--Ivan
chris_john_mason
2006-11-22 11:57:07 UTC
Permalink
Harry

Comments are embedded.

Chris Mason
Post by harrywahl2000
The 3708 is attached to the mainframe using a synchronous, SDLC link
and is defined as an SNA PU. It is not a good candidate for
Hercules
Post by harrywahl2000
connection since it required an NCP or integrated ICA to connect to
the mainframe ...
I talk about the 3708 only because it indicates the sort of technique
that would be needed if a Minitel were to be presented by Hercules to
the supported operating system as a 3270 display device. It's a shame
I couldn't have described what a 7171 does/did but I only had the
3708 to play with many years ago and I still have the notes on the
techniques used.

Even if you could still locate 3708s I am *not* proposing that
Hercules should support the attachment of the 3708.
Post by harrywahl2000
... and because the TN3270 terminal server in Hercules
uses a non-SNA protocol.
Only the 3270 channel interface of the Hercules TN3270 server has
relevance to the "protocol conversion" solution.
Post by harrywahl2000
I don't think Hercules has a mechanism (I'm
not saying the guest operating systems don't, e.g. using VTAM and
downstream PUs via TCP/IP) to emulate SNA 3270 terminals.
Emulating 3270 displays is something performed only by PC (or UNIX)
programs including TN3270 clients and special boxes such as the 7171.
As you mention later, the 7171 is the closest device for emulation
because it handles both the channel interface and the line interface
with the protocol conversion logic in between.
Post by harrywahl2000
The AEA on some 3174s is a possibility if one configured to run
local non-SNA mode were emulated. This could be an extension to the
TN3270 server intrinsic to Hercules to accept serial modem (NULL or
not) RS-232 connection in addition to TCP/IP TN3270 connections. A
real or emulated (ProComm, FTTERM) ASCII terminal (such as a VT100)
could dial or connect to a serial port. I think the difficulty of
coding this would be the differences in implementation of serial
port programming between the various machines and operating systems
that host Hercules.
Only the 3270 channel interface of the Hercules TN3270 server has
relevance to the "protocol conversion" solution.

It's a consequence of my ignorance of Hercules that I hadn't realised
the port used to connect the asynchronous ASCII device would be a
problem.

The original poster mentioned only Minitel (and actually didn't have
a protocol conversion solution in mind) but, of course, any solutions
should be generalised as much as possible.

Because FTTERM has been mentioned I've added an appendix from my
lecture notes on the protocol conversion topic.
Post by harrywahl2000
If this were implemented, a 7171 would be the best candidate for
emulation. It appeared to be channel attached 3270 terminals, just
like Hercules presents TCP/IP TN3270 connections to the operating
system and it has a commonly used and fully described "transparent"
mode to allow VTAM or CICS to communicate easily to serial devices,
even using BMS.
I think your "transparent" mode may be a function of what I describe
in my lecture on the topic as "protocol enveloping" rather
than "protocol conversion". This is also what I, anyhow, have been
describing as "line-by-line" mode since that is the mode a human
operator sees entering commands and receiving responses. Typically
data is subject only to translation between ASCII and EBCDIC when
accessing the host operating system via NCP and there can be very
many applications. The operation with a 7171 which needs to use a
pre/non-SNA 3270 channel-attached appearance to the operating system
restricts use to something like the CICS environment.

"VTAM *or* CICS" - surely that's CICS using VTAM - or are you
suggesting writing directly to the VTAM API - where, of course,
anything is possible?
Post by harrywahl2000
VSE never natively supported 7171s, they did however work under VSE
and many enterprises used them under VSE.
I don't think there should be a problem over defining an appearance
that happens to allow the 7171 channel appearance since this should
be identical to the channel appearance of, for example, a 3272.
Post by harrywahl2000
As for the 3767: it is an SNA device and must be defined to the
operating system as an LU. If your goal is to attach a real 3767 you
should consider getting a 3174 with a token ring or Ethernet
feature
Post by harrywahl2000
and attach it to it. Otherwise it may be necessary to code
something
Post by harrywahl2000
that emulates a downstream SNA 3174 under TCP/IP and further
emulation code up to the device you are actually using.
I don't believe the original poster ever actually had the idea that a
3767 should be attached to an operating system supported by Hercules
as a 3767. He has been misled by recalling that a VTAM mode table
entry which was appropriate for a 3767 was used when a Minitel is
supported via an X.25 network and NCP/NPSI and appeared as an LU by
the agency of the NPSI LU simulator logic.

I don't see how a 3174 with LAN support helps with a 3767. A 3767,
whether natively or supporting 274X emulation, is connected only
using a "V.24" interface.
Post by harrywahl2000
As for teletypes: they belong in another era, being more a
primitive
Post by harrywahl2000
messaging system than a terminal type to connect to a mainframe.
They date to 1907. Asking for Teletype support on Hercules would be
like asking for fax support or maybe Morse code telegraph
connectivity? The only mainframe users of teletypes I've ever seen
or heard about front-ended them with Series/1 computers or special
code in an NCP and they were either message routing or
transitioning.

Probably when talk turns to "teletypes", what is really in mind is
devices supporting asynchronous ASCII such as are supported by the
X.28 (and X.3) recommendations, otherwise called Packet
Assembler/Disassembler (PAD) devices connected to an X.25 network -
or - a vast number of other attachment points to computing devices.

-

PC/HOST File Transfer and Terminal Emulator Program (PC/FTTERM)

PC/FTTERM is a PC program, running under DOS, consisting of two
cooperating parts:

1, a 3101 emulation program with extensions for more effective
working with the 3708 Protocol Conversion mode:

- highlighting (mono display) or colour (colour display),
- line 25 status display,
- automatic printer support (the 3101 requires manual intervention).

2. file transfer functions which interface with the host 3270 file
transfer programs, collectively known as IND$FILE.

The 3101-like emulation part of PC/FTTERM may be used as a basic
Asynchronous ASCII terminal and hence attach to networks supporting
Asynchronous ASCII terminals. It may also operate through the 3708
using Protocol Enveloping mode to access applications in an SNA host.

PC/FTTERM is supported by the 3708 as a modified 3101 and two special
terminal tables defined for it,

- one for a monochrome display and
- one for a colour display.

PC/FTTERM operates with two PC sessions,

- one using the terminal emulation and hence able to be in
communication with
either an SNA or a non-SNA host and
- another running PC programs.

PC/FTTERM permits various types of "file" transfer. File transfers
can run together with the PC session, concurrent mode, or can take
all the PC processing resource, non-concurrent mode. Many file
transfer can be grouped together as defined by a "batch" file.

Function keys allow switching between the two PC sessions, a file
transfer menu and a display showing the progress of file transfer
operations.
Loading...