Request for Native SNA support #348
Comments
|
Hi Vincent! We currently have no plans to add SNA support to Hercules, but that's probably only because we're short on manpower and already have more "To Do" items on our list than is possible to finish in a lifetime! Nevertheless, we will keep your request open. You can never know when someone might come around and decide to take a crack at it. Thanks for the enhancement request and enjoy your personal mainframes! |
Fish-Git
added
the
Enhancement
|
You're very welcome. I will definitely provide any information I need, SNA related or not. |
|
I made a mistake in the adapter classification I suppose I should correct it. As stated before I said OSC that is an error that's like the current 3270 emulation that's done by Hercules. What I meant was OSE which is OSA non-QDIO which is capable of doing SNA traffic. And for reference OSD would be QDIO mode if anyone wanted to know. |
This comment has been minimized.
This comment has been minimized.
|
Hello Vincent,
This matches exactly my goal, and thus I'm highly interested in getting in touch with you! My AS/400 model 150 runs V4R5 (no license keys needed in this particular combination). Since Hercules doesn't support 802.2 DLC, and EE was first available on the iSeries platform with V5R3 or V5R4, there's no direct way to connect Hercules and my 150. What exactly is the Cisco (Router?) supposed to do? I know some images (or licenses on newer hardware) provide a SNAsw branch extender node support. Depending on the scenario being built, this is a serious limitation of using NNs on both sides of the logical SNAsw ports (EE, and 802.2 DLC). Currently I'm using this feature to tinker with VTAM and OS/400. Details on Request. You can find my mail address on my Github profile page. :wq! PoC |
|
Nice work! I sent an email with my system details. If you don't get it, my AS/400 system is a 9406-270 running V5R4 and my Cisco Router is a 2811 with a SNAsw image loaded on it. I plan on making a links to other systems on the internet and want to use the Cisco router to handle the SNA traffic coming in over DMVPN links. If you want to join when the network is rebuilt, let me know. |
|
Hello Patrik, A couple of questions. Firstly, are you in the process of doing the changes for SNA on LCS? Secondly, how did you manage to make VTAM use the LCS? As a result of your interest I've been looking at the config code for LCS, with the intention of firstly allowing SNA LCS's to be defined without using the OAT, and secondly to allow the OAT to specify preconfigured tap interface names. I made the changes to LCS to support preconfigured interfaces ages ago, but decided to leave the OAT until there appeared to be some demand. I'm attempting to reproduce the results you have achieved. I have an XCA (I copied the one you published in one of the H390-MVS messges) which activated successfully, but does nothing with the LCS. Do I need other VTAM definitions, e.g. an SWNET? My understanding is that an XCA simply defines the hardware to be used for a connection, but the hardware isn't used until a connection is started. Is that correct? I know next to nothing about VTAM resource definition, so any help would be greatly appreciated. Ian |
|
Hello Ian, Thanks for participating!
I'd love to do, if I only knew what needs to be changed. :-)
Thanks a lot! Do I understand right that a preconfigured interface includes the need to provide a MAC address for the interface by facilities of the hosting OS, because can't set the MAC via OAT anymore? And, does your change permit a possible mixed mode between SNA and IP via LCS?
This is the sole, and full member I'm using for my tests. I've only commented out the minor nodes 01..06.
Honestly, I don't know for sure. I've enabled VTAM to be APPN aware, by setting To my understanding (with a heavy bias towards APPN), activating the XCA40E resource must prepare the hardware to accept incoming connections, even if there's no switched major node for an outbound connection.
Welcome to the club of the clueless. ;-) I have been reading these manuals, at least in parts:
Probably also helpful:
My finding so far is that understanding VTAM needs SNA expertise, and understanding SNA needs VTAM expertise. I have not yet managed to break this tie. There is an awful lot of general SNA documentation available. Because SNA has come a long way, documentation is plentiful. I don't know yet it it's of any help to read all from oldest to newest for getting a better understanding about the development taking place over decades. :wq! PoC |
|
My first introduction to SNA was Communication Tools for AS/400. Now I have started to learn about the zSeries VTAM system, so it's a process I need to get OSA/SF working to activate my non-QDIO OSE adapters apparently. But so far I've gotten SNA on OS/2 AS/400 Cisco SNAsw and Windows SNA server. But yes, it makes it easier when you have Hercules to work with SNA so I don't have to run my 2KW z114 system to test the routing. Keep up the good work, and if you need any information from my system, please let me know. I will try my best to provide all I can. |
Yes. The following are the commands (from a script) I use to set up a preconfigured tap interface on a Fedora host for use with Hercules:
Yes and no. If you want to use a single tap interface for both IP and SNA via LCS, you would have to use the OAT to define the IP and SNA devices, all with the same port number, just like today. However, if you specify a single device LCS for SNA, it would use a tap interface that was exclusively for its use, just like a two device LCS for IP does today.
Thanks, I'll try later. Ian |
|
Hello Ian,
Okay, thanks for clarification.
I see. That's no big deal for me.
Understood: Because IP needs two devices.
I'm looking forward to what you've found! :wq! PoC |
|
Hello Vincent,
Good luck! See my answer to Ian above: VTAM is a huge beast to tame. I gave up to do this as a second task running with low priority. It's just too much and I need to dedicate a lot more energy into it.
I can't help you with that, unfortunately. But see my list of IBM documents above. There is a lot of helpful content regarding VTAM configuration.
Congrats!
Indeed! And I bet, the time needed between "start Hercules" and "system has finished all IPL related work" is a lot less than "switching on power" and "system has finished all IPL related work" on your z114. Even though the z114 is a lot more cool, in a 2 kW heating way. ;-)
Thanks! Unfortunately, I can't see how a real z114 with an OSE might help. But then, Ian wrote that an OSE isn't too different to an LCS. So maybe this could be a way. Ian, your comment? :wq! PoC |
|
Yes. I am just saying if you need any packet captures or anything of that nature. Also, apparently, while reading an OSA/SF manual, a LCS is the name for the TCPIP operating mode and an LSA is the type for a SNA operating mode, which I found interesting, but they all use the same controller base type of OSE. I'm working on transferring VTAM from VM/ESA to zVM and Dumping OS/390 for MVS VTAM to work with. I have VSE VTAM up already, but just haven't started defining SNA links yet. |
|
Hi Patrik, thanks, your definition works for me too. Ian |
|
I can also put my machine in service mode and collect service data about the operation of the adapters, if that can be of some use. I've found out a little bit on how to do operations like this poking around in the SE menus. They definitely take a while to come up. Faster than the OS/2 SE machines, but the Primary takes significantly longer than the alternate. I assume that's because the primary is spinning up more services. |
|
Hello Vincent,
Thank you for your kind offer. Unfortunately, I'm not really skilled enough in Mainframe Terms to know how and if your possibilities could help in enhancing the LCS driver. Hopefully, the other devs maybe can shed some light? :wq! PoC |
|
Possibly. I'm open to anything that may help in some way shape or from. |
|
Hello, In case someone missed: Yesterday I reworked my findings post. :wq! PoC |
Just out of curiosity, what "findings post" would that be? |
AbstractThese are the collected findings as Documented in the groups.io Mailing List H390-MVS at the end of January 2021 regarding Implementation of SNA support in Hercules-Hyperion to use 802.2 DLC on Ethernet via TAP device. They have been updated on Jan 30, 2021. Consent between all devs so far was: There is no SNA support in Hercules. This wasn't sufficient for me. Documentation for the LCS device hinted to partial SNA support, because the OAT file might contain a SNA directive. Looking at the Ian states:
So I didn't bother to even look at QETH. Testbed configuration includes
Thanks to (in no particular Order) Fish, Harold Grovesteen, and Ian Shorter for helping to shed some light on that issue. Hercules configuration detailsHercules has been configured with a stock LCS device. Only one, because according to Ian, only TCP/IP support needs two devices: One for reading from and one to write into. E40 is documented as AWS3172, VTAM 3172 emulation in the original P390 configuration file, so I assume the HCD configuration of the guest OS is correct for that type of device also.
The OAT file provides a means to route packets to the available ports of the virtual 3172. After the start of Hercules, a virtual device tap0 is automatically created. I bridge this device to an unused NIC in my test equipment: Maybe the link state settings are not necessary, because they are handled by STP. STP is off by default. Guest OSBefore trying anything, I applied the change regarding a missing interrupt handler as laid out in the New User's Cookbook accompanying the distribution. MIHIt required changing the parmlib member IECIOS00:
I verified successfully that it works after the next IPL, with
Note: I have added the same configuration change to the E20-E21 devices (CTCI), used solely for IP connectivity before I tried to get E40 running. So far, I've not observed adverse effects. VTAMVTAM configuration is mainly unchanged from the original file in sys1.local.vtamlist(xcae40e). The comment in that file states: 3172 (LSAPLAN) ETHERNET ADAPTER1 (E40). Definition:
Note: In the original member, this line is split to fit in one line. The OAT documentation mentions ports starting with 0, while the VTAM configuration mentions ADAPNO=1 by default. It is not yet clear if this is an off-by-one glitch, or another error condition/inconsistency. Further testing might be necessary. FindingsTrying to activate this major node in VTAM immediately raises an error in the guest OS console:
The LCS debug output revealed, that VTAM sends a command frame which is not recognized by the command handler:
I extended the code for ctc_lcs.c and the header file defining the commands, so command 0x41 is redirected to a TCP/IP Start LAN command handler, and 0x42 to the accompanying Stop LAN command handler. See attached diffs: With help from Ian and Fish, I managed to get some debugging output, including a CCW trace (type This is the output while IPL was progressing. Obviously some guest OS driver probing or even initializing the hardware: The activation of the XCAE40E resource yields the following output: After three minutes, a timeout value was reached for minor nodes of XCAE40E: This console message is accompanied by this debug output of Hercules: The inactivation of the resource yields no more channel communication to the LCS. There never was one single frame visible in a tcpdump running on the associated tap interface. Forcing an AS/400 to send XID frames to the MAC of the LCS unsurprisingly yielded no reaction, neither from Hercules Tracing, nor from VTAM. Summary
|
Ah yes! I remember seeing that post! I wonder what happened to it? Did you delete it? In any case, I guess it's not that important anymore, since you've now posted a more current version of it. Thank you for that. |
Question: for documentation purposes and for the benefit of others who might be interested, do you have the direct URL available? Thanks. |
Shorter. His name is Ian Shorter. |
|
|
Hello Fish,
No, it's just hidden.
You're welcome! :wq! PoC |
|
Hello Fish,
Thanks. Corrected. :wq! PoC |
|
Dear Devs, Does one of you have the expertise to guide Vincent "@vinatron" through enabling a CCW trace on real hardware? With his OSA card in non-QDIO-Mode and with tracing active while he's activating a XCA major node in VTAM, if we then see the command 41 show up, we'd achieve a huge step forward, by proving that the channel communication words are most likely the same for OSA-non-QDIO, and LCS. Opinions, anybody? :wq! PoC |
That certainly sounds like an excellent idea, Patrick! Unfortunately I myself have zero experience with modern mainframe hardware. The last mainframes I had hands-on experience with with System/370's and 4300's! Hopefully someone else who does have hands-on experience will read this and provide some instruction to help us out. Or maybe this question should be asked on the main Hercules list/forum? Maybe someone there might know? (I'm not sure how many members read GitHub Issues so we might have better luck asking the question to a wider audience.) |
|
Hello Vincent, Apparently GTF is what we need to utilize. Do you want to read and learn yourself, or do you require a ready-made action plan? For the latter, I'd also need to read about it. Do not hesitate to ask questions, if they arise. @Fish-Git: IBM provides a lot of documentation. It's most often the question what to search for. :wq! PoC |
|
Jeff, a question. Truncation occurs under Hercules when you 3270 into OS/390 and attempt to logon to VM. Does truncation occur if you 3270 into VM and attempt to logon to OS/390? Similarly on the R390, is the link disrupted if you 3270 into VM and attempt to logon to OS/390? I don't have any VM 2.4 manuals, and have yet to find a manual the might describe the VM equivalent of GTF trace. If the truncation/disruption occurs from VM to OS/390 the search can end, and a GTF trace on OS/390 should illustrate what Hercules' LCS needs to do. |
|
Ian, Here are traces of VM to OS/390 traffic. Again, two copies for comparison, one R/390(VM) to Hercules(OS/390) and the other Hercules(VM) to Hercules(OS/390). In the R390-VM trace, after bringing up the APPN link, I connected to a terminal on VM, dialed into VTAM and then connected outbound to the OS/390 image running on Hercules. Note: you'll see in the trace, the first time I tried connecting to a non-existent APPLID, ML05TSO. Don't be distracted. When I connected to A06TSO, I was successful. This OS/390 system generates a full screen of line mode messages before invoking ISPF. After I put in my password and was logged into TSO, I then went into a wait (x-system), waiting for those messages. Eventually, I hit reset and enter and I went into another wait (x-wait) with no additional output. In reviewing the network trace, I see the "SCREEN ERASURE CAUSED BY ERROR RECOVERY" message, but that never made it to the terminal. In the Hercules to Hercules trace, I activated the APPN link and connected to the VM system. I dialed into VTAM and logged in to the JS95TSO APPLID on OS/390. This system does not generate all the line mode messages, just a couple and then it invokes ISPF. I saw the messages on the terminal and the got 3 asterisks and "input inhibited" when it invoked ISPF. I have limited experience with VM, but I've been told that the trace command there only captures the I/O instructions and CCWs, with none of the data being transferred. If you think that would be helpful we could try that. |
|
Sorry, forgot to mention... No disruption to APPN or the link between the systems in either of the scenarios above. Also, I've got a bunch of VM/ESA 2.4 manuals. If you're interested, contact me off list and I'll send them to you. (jsnyder1369 at gmail) They zip up to 60+ MB, so probably a little big for email but we'll find a way. |
|
Jeff, We need to repeat the r390 exercise of 3270 to VM then logon to OS390 while a GTF trace is running on OS390. Are you au fait with running GTF traces, and the parameters which are needed (they have been mentioned several times in this very long issue!). Where is this r390, is it at Marco's? Ian |
yes, it‘s the same setup where you took the traces. Hercules is running on the linux vm, where the mirror port is connected. Marco |
|
Ian, Here's the trace you requested. I started the trace before I brought up the APPN link, so you've got all the activity up to the point where the session hung. To confirm, once the link was up, I connected a 3270 session to VM on the R/390 and dialed into VTAM. I then logged on to APPLID A06TSO on the OS/390 on Hercules. One note, this time the session included more of the line mode messages at the beginning of the TSO session before it hung, approximately 1/3 of a screen on a mod 4. Editor's Note: as a courtesy, here's the same thing as a .pdf file: |
|
Well now I'm completely confused, nothing unexpected or unexplainable occurred between OS/390 VTAM and the 3172. Once Jeff had logged on to applid A06TSO the following outputs from VTAM to the 3172 were seen. At 23:59:23.394101 TH sequence 10 was output which did a 3270 Erase Write Alternate to display on row 1 the message:- At 23:59:23.517952 TH sequence 11 was output which did a 3270 Write to display on row 2 the message:- At 23:59:25.170004 TH sequence 12 was output which did a 3270 Write to display on row 3 the message:- At 23:59:26.152871 TH sequence 13 was output which did a 3270 Write to display on rows 4 to 14 the messages starting with:- Whatever happened next was internal to VTAM because no TH sequence 14 was output, the next output was TH sequence 15. At 23:59:26.175103 TH sequence 15 was output which did a 3270 Erase Write Alternate to display on rows 1 and 2 the messages:- At 23:59:26.189519 TH sequence 16 was then output which again did a 3270 Erase Write Alternate to display on rows 1 and 2 the messages:- All of the above outputs received a response TH/RH from the remote end. At this point the 3270 session is hung. The next activity was at 00:00:26.594691 when VTAM polled the 3172 to check it was still active. The trace was stopped shortly after that. I guess this is an example of cross-domain 3270 sessions hanging, which have been mentioned several times here and elsewhere. Jeff, have you tried a cross-domain session using a 3270 without extended features? I have NT4 with SNA Server, and using its 3270 client I can only logon to OS/390 when extended features are disabled. |
|
Hi Ian, I think I've found a way for us to get I/O traces from VM. Could you take a look at the attached file and see if it is useful? I thinks it's got pretty much the same data as the MVS traces, but one thing is different. Apparently the data buffers do not get cleared when new data is written to them and the formatting program just prints the whole buffer, so residual data from previous I/Os show up in the output after the actual data transferred. I set the data buffer size to 2048 because I know some of the I/Os that have been truncated by Hercules have been 1500+ bytes. I'm hoping you can get the length of the data that was transferred from the CCW and just ignore the rest of the buffer. In the trace, you should see the APPN link being brought up and then a logon attempt from the OS/390 system to APPLID JS94VM on VM. This was done on my local images, running on Hercules. If this looks like you can use it, I can try doing this again after a fresh IPL of the VM system, to clear the data buffers and maybe make it more readable. Unfortunately, I won't be able to IPL the VM on the R/390 if we want to try this there. Hopefully, we can get what we need on the first take if we need to go that way. FYI, in response to your question, no I haven't tried a cross-domain session without extended features. I tried turning off extended data stream support in WC3270 using the S: prefix on the IP address and got the "screen erasure caused by error recovery" logging on to OS/390 from a local terminal, when it tried to go into ISPF full screen. I'm pretty sure I'd have to find or create a "non EDS" logmode for that test to be successful and I haven't found one yet. (To be honest, I got side tracked looking at the I/O trace and didn't look very long...) |
|
Hi Jeff, Excellent, the trace is exactly what is required. As you say, pita it traces the whole input buffer rather than just the input, but the input does contain the lengths we need, so not a big deal. When you get to do the real trace, can you please do a concurrent packet trace, to tie everything together. Cheers, Ian |
|
Hi Ian, Here are the traces you requested. In the zip file, I've included the console logs from OS/390 and from VTAM on VM as well as the VM IO trace and the packet capture. I've got to apologize, I was having a bad night. I tried to dial up the APPN link (twice!) from VM before I had activated the XCA on OS/390. Normally, I'd have started over so you'd have a clean trace, but I wanted to capture the VM IO buffers before they had been reused, so you'll see those attempts in the trace. |
|
Hi Jeff, Thanks for your efforts getting the traces, and no need to apologize, we all have bad nights! I have just done commit 261bb51 to the develop branch to make Hercules handle the oversized output correctly. Can you please check that it produces the same results as the R390? I would do it myself, but I don't have the environment available. At least not yet. Of course, the change won't make cross-domain 3270 work, but Hercules' LCS emulation should now make it break it in the same way as the R390's LCS3172 emulation makes it break! Ian |
|
Hey Ian, Good news, you're close. It fails on the VM side, like it did on the R/390. Hooray, it's broken! Bad news, the OS/390 side did not fail as well, like it did with the R/390 <-> Hercules scenario. Darn, it's not broken! So, it looks like the link lasted long enough to tell the peer what was going on and close the link (gracefully?) on the R/390. In the attached zip files, I have console logs, a packet trace and an IO trace, if you want to take a look. |
|
Hi Jeff, Sorry, I had made a typo which caused the wrong return code to be returned to VTAM (0x7656 instead of 0x7657). Hopefully the correct return code will cause the failure to be properly propagated to the partner. Commit 7c7fc9c to the develop branch has the correct return code. Can you please re-test? Ian |
|
Hey Ian, I see in the console log that the 0x7657 return code was returned by the LCS this time, but still no response from the other side. I cloned after Fish applied his commit (96fa94b-Fix TIMERINT DEFAULT to conform to documentation/design) to the branch. It didn't look related, so I didn't rebuild after I discovered the difference, but if you think it might be significant, I can do that and retest. Here are the traces. FYI, I forgot and left the packet trace running while I shut things down, so you've got probably 6 - 8 extra packets in there. |
|
Having studied the R390 traces again, I think I misunderstood what happened. I believed that the over long data sent by VM resulted in the VM LCS doing something, which further study proved not to be the case, the VM LCS simply ignores the over long data. The connection being terminated is initiated by the OS/390 end, 12 seconds after the VM end has ignored the over long data. It took me a while to almost completely understand what happened, greatly hampered by the clocks on the various systems not being synchronized, and the VM console messages having no time stamps. I say almost because I'm still not certain of the timing of packets arriving/departing relative to actions between VM and LCS. I intend to revert the changes made in commit 7c7fc9c, and instead produce a message when the over long data arrives but otherwise ignore the data. |
|
Would it help to have another R/390 in this setup for tracing a connection between two "real" emulations? |
If you have spare P/390 R/390 cards, I am happy to take one! |
|
;) |
|
(@vinatron. @PoC-dev, @mcisho, @wrljet, @Peter-J-Jansen, @wably, @jeff-snyder, @ocram-zz, @jmaynard, etc...) ALL: Should this issue maybe be closed at this point in time now? It seems to be mostly done now. (completely done?) Besides, we can always re-open it again (or better, open a NEW issue) if any new bugs are ever discovered. Just asking! Thanks. |
|
From what I've done so far I haven't seen any issues. |
|
I think we can close it. Once we get SNA networking runinng in general on the P/390, and if the same techniques don't work on Hercules, then we can revisit this. |
|
Please close. New bug reports can be filed individually, with the required additional information. |
|
A friend of mine and I had OS/390 talking to a workstation over SNA we also had it talking to SNASw but that's not as useful as if you had full APPN support. However when directly connecting to OS/390 from PCOMM the connection worked flawlessly as far as I can tell I should probably test zOS to see if o can get APPN HPR working however non HPR works ok it's just nice to have HPR I enjoy having it on my AS/400. |
|
Your posting is confusing. Please make shorter sentences. Are you having a Hercules issue or what do you want to tell us? I'm deliberately not using HPR, but just plain APPN in conjunction with (older) AS/400's like my model 150. I've read that APPN traffic is handled by the IOA's IOP, while HPR traffic needs to be handled by the main CPU. |
|
Fair enough I mean to be fair all the problems I've had so far were known issues with the vtam version I was dealing with. Also I have a 270 running V5R3 and HPR doesn't seem to cause me any issues there either. Anyway as far as I can tell from my limited testing I have found no issues with Hercules itself but mainly my own implementations inside VTAM to be the issue of any exist. I guess what I'm trying to say is I think the communication adapter is working perfectly it's just my VTAM skills that aren't that great yet. |
|
Thank you for clarification. |
|
I have no opinion on this one. I know absolutely nothing about SNA. |
Thanks guys. Closing. |
Fish-Git
removed
the
Ongoing
Hello,
I have been a community member for a few years and now have some hardware of my own. This really isn't an issue, however I would like to have SNA support in Hercules to be able to test SNA typologies without having to keep my frame online.
I am interested in assisting with adding support in any way I can because the original system had an OSA adapter defined in OSC mode for SNA console access. If I can help contribute any data to help with the addition of SNA into Hercules, please let me know.
I don't however have a communications controller. If I did, I would give data on those as well to have Native SNA on the 370 as well. My end goal is to have a Cisco and IBM SNA network going between a client node and my AS/400 and Mainframe systems, and use Communication Tools MVS/VM bridge on the AS/400 to setup NJE connections over SNA because that's how the manual explains the connection process.
Thanks for the continued development on the software. It is greatly appreciated. Also, any additional data you may need, my machine isn't the newest, however I can give any data that you may need. It's a z114-M05 with 2 CPs and 8GB of storage "RAM". I also have plans to try and connect my ESCON tape device and see if I can transfer data to real tapes.
Kind Rearguards,
Vincent
The text was updated successfully, but these errors were encountered: