Unable to telnet from OS/400 to Hyperion (hercules)

[bencz]

I am performing connection tests from an OS/400 to a Mainframe. In tests, I succeeded in connecting to a real mainframe via telnet on OS/400, but when I test the OS/400 telnet connection to emulated z/OS, I receive the following error in the Hyperion terminal:

HHC02910E client 2 COMM: Unsupported terminal type: IBM-3477-FC

The telnet command executed on OS/400 is:

TELNET RMTSYS(< IP ADDRESS >) PORT(XXXX) RMTVRTDSP(NULL)

The same command works well when I try to connect to real mainframe.

[Fish-Git]

@bencz

Hi Alexandre!

The comments and associated code in Hyperion's negotiate_ttype telnet function indicates that Hyperion currently only supports a small set of display terminal types:

/* Valid display terminal types are "IBM-NNNN", "IBM-NNNN-M", and    */
/* "IBM-NNNN-M-E", where NNNN is 3270, 3277, 3278, 3279, 3178, 3179, */
/* or 3180, M indicates the screen size (2=25x80, 3=32x80, 4=43x80,  */
/* 5=27x132, X=determined by Read Partition Query command), and      */
/* -E is an optional suffix indicating that the terminal supports    */
/* extended attributes. Displays are negotiated into tn3270 mode.    */

I would like to fix this function to support any valid IBM display terminal type if possible. You can help me by providing me more information about the IBM-3477-FC:

• Does it behave as an ordinary model -2, -3, -4 or -5 display terminal?
• Does it support the Read Partition Query command?
• Does it support extended attributes?

Once I have this information then I can update the code to support your terminal type.

In the mean time, if OS/400 supports it, is it possible to specify the "terminal type" on your TELNET command? If you can specify a custom terminal type, you might try specifying one of the above IBM models instead (e.g. "IBM-3279-2", etc). This would allow your terminal to connect until I can fix the code.

p.s. I did some development on an AS/400 over 30 years ago and I always thought it was a very nice machine! The idea of "Single-level store" was really cool!

---

Can anyone help me compile a list of IBM display terminal types (models) and what modes/features each of them supports? To fix this issue I would like to change the code to be table driven so we can perform a table lookup on the passed terminal-type to determine what mode that type behaves as. I don't like the idea of having only a small list of hard-coded terminal types. I'd like to "genericize" the code as much as possible to prevent this type of problem from occurring again in the future. Thanks!

[MarkSWaterbury]

Hi, David,

An IBM 3477 is not a 3270 family terminal; it is one of the 5250 family used with AS/400 -> iSeries -> IBMi platforms. So, I don't think you want to add that to the list of valid devices.

What happens when connecting to a real mainframe z/OS, OS/390 or VM/ESA etc., is that the host will try several different alternatives, in the "negotiation" of terminal type, between the TN3270 or TELNET client and the host TELNET server. But, Hercules-390 appears not to do that. It just "gives up" immediately if it does not recognize the device type.

See here for additional info. about how z/OS negotiates the telnet terminal type: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz001/telnetdevicestatement.htm

From the OS/400 side, this is how the TELNET client tries to determine terminal type: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzaiw/rzaiwemultypetrouble.htm

I agree with your comment to make it "table driven" rather than just hard-coded in an if statement. And, then, the console.c code can work down the list of possible terminal types, until the telnet client replies with a favorable response, or if the end of the list is reached, then Hercules can "give up" (with an error message, as you have in Hyperion.)

I hope this helps,

Mark S. Waterbury

[Fish-Git]

So, I don't think you want to add that to the list of valid devices.

Why not? If it supports TN3270, then it's a 3270 from Hercules's point of view! Yes?

Your "OS/400 Workstation type negotiations and mappings" reference is precisely the type of information I was looking for! Thank you!

[Fish-Git]

...the host will try several different alternatives, in the "negotiation" of terminal type, between the TN3270 or TELNET client and the host TELNET server. But, Hercules-390 appears not to do that. It just "gives up" immediately if it does not recognize the device type.

Okay, I get what you're saying. Hercules's negotiation logic needs to be enhanced so if it is passed a terminal-type it doesn't like, it should tell the client "Try again".

In other words, Hercules is not fully implementing RFC 1091. It's giving up on the first attempt instead of asking the client to send its next terminal-type.

I'll try to get that fixed as soon as I can, but please understand I am very busy working on others things at the same time (I don't have a team of developers! It's just me doing all this sh*t!) so it may be a while before I can "get a round tuit". :)

[bencz]

Hi David! Do not worry!! We are not charging you! :)

[Fish-Git]

@bencz

Alexandre,

Commit fd92ebac6f55bd64289ee5198316011a1e2c4d8c hopefully fixes this issue. I was unable to thoroughly test the new logic since I didn't know how to configure my client (Tom Brennan's Vista TN3270) to cycle through a list of terminal types.

Note too, that terminal type "IBM-3477-FC" is now in Hercules's list of acceptable TN3270 terminal types as a model 5 terminal (27 rows, 132 columns) as per the information on the IBM web page you provided, so the connection should be accepted on the first attempt.

If you want to test my new retry logic (please!), simply comment out that line in the table (source file console.c, line 2261) and rebuild Hercules.

Then try TELNET'ing again from your AS/400. The first terminal type sent by your OS/400 ("IBM-3477-FC") should then be rejected, and Hercules should ask your OS/400 client for its next terminal type.

As long as the next terminal type that your OS/400 sends to Hercules is one of the other ones in the table, then Hercules should accept the connection.

Doing this would verify that my new logic is working correctly.

Thanks!

(I would do it myself but I don't know how!)

[bencz]

David! Thanks! It's worked really well!!

[Fish-Git]

David! Thanks! It's worked really well!!

Great! I am glad to hear that.

Have you attempted the "retry test" that I suggested?

[Peter-J-Jansen]

I suspect that the recent changes to the telnet negotiation have broken something.

Using x3270 to emulate 3270's under Linux Ubuntu 16.04, I use two terminal types: IBM-3279-5-E and IBM-DYNAMIC. Both used to work very fine for many years. But as of this change (I suspect), the IBM-3279-5-E no longer connects.

From a recent Hercules log:

16:28:06 HHC01413I Hercules version 4.0.0.0-SDL-g0a484d6-modified (4.0.0.0)
[...]
16:28:07 HHC02204I LOADPARM       set to 0A82XLM
16:38:15 HHC02260I Script 1: begin processing file hercules.rc
16:38:15 HHC01603I sh ./hercules_x3270
[...]
16:38:15 HHC02264I Script 1: file hercules.rc processing ended
16:38:15 HHC02915I client 0 COMM: Connection received
16:38:15 HHC02910W client 0 COMM: Unsupported terminal type: IBM-3279-5-E
16:38:15 HHC02908E client 0 COMM: Connection closed during negotiations
16:38:15 HHC02915I client 1 COMM: Connection received
16:38:15 HHC02914I 0:0021 COMM: client 1 negotiations complete; ttype = 'IBM-DYNAMIC'
16:38:15 HHC01018I 0:0021 COMM: client 127.0.0.1 devtype 3270: connected
[...]

I thought to perhaps find and fix the problem myself, but the changes this commit introduces, plus my unfamiliarity with this code, made me fail my attempts.

Can you help please?

Thanks,

Peter

[Peter-J-Jansen]

Fish,

The following change fixed my problem:

hercules@ubuntu:~$ diff SDL-hyperion/console.c Qsync/Source/Originals/SDL-hyperion/console.c 
2261,2262d2260
<     {  "IBM-3279-5",      '5',   FALSE  },
<     {  "IBM-3279-5-E",    '5',   TRUE   },
hercules@ubuntu:~$

Cheers,

Peter

[Fish-Git]

Both used to work very fine for many years. But as of this change (I suspect), the IBM-3279-5-E no longer connects.

The following change fixed my problem:

< { "IBM-3279-5", '5', FALSE }, < { "IBM-3279-5-E", '5', TRUE },

What about IBM-3279-4 and IBM-3279-4-E? ;-)

You are of course correct Peter, and I will make the change right away.

I based my table entries on the information in the web page that Mark Waterbury provided, as well as the official IANA.org list of telnet terminal types:

• "OS/400 Workstation type negotiations and mappings"
• IANA.org "Terminal Type Names"

Having done yet more research (intensive Googling) however, it appears I am indeed missing some entries in my table:

• z/OS 2.3 TELNETDEVICE statement

Furthermore, Mark Waterbury was also right to say I should not add a table entry for the 3477, as he correctly pointed out it is a TN5250 type terminal and not a 3270 type terminal (and the two protocols are not the same):

• IBM 5250 (Wikipedia):

Historical origins: ... The 5250 is a block-oriented terminal similar to the IBM 3270 but is not compatible with the 3270.

I am also seriously considering removing all of the table entries from IBM-5251-11 onward too (5251, 5291, 5292, and 5555), since I suspect (but am not 100% certain about it) that they too are probably 5250-type terminals too (and Hercules does not currently support the TN5250 data stream protocol, only the TN3270 data stream protocol).

I'll add the missing 3279 table entries right away.

And I think I'm going to remove the 3477 and 5xxx table entries too (since Hercules's previous logic didn't support such terminal types anyway).

Hang loose. I'll get it fixed!

(and sorry about all this!)

[Fish-Git]

(am temporarily re-opening this issue until I can commit the change to fix this most recent bug pointed out by Peter...)

[Peter-J-Jansen]

Thanks Fish!

And yes, you are correct in that IBM-3279-4 and IBM-3279-4-E also should be added. (So far I've not used these.)

Cheers,

Peter

[Fish-Git]

Fixed by commit 781d98cca18f4a7ea2a97330644e44cb422fca74.