none
Telnet to HIS = TCP or UDP? RRS feed

  • Question

  • I'm not entirely sure I understand the problem we're experiencing at the moment but I've hit a brick wall and really have no idea where to go from here.

    We have an HIS that has some (telnet?) sessions on it. When we connect in with a terminal emulator called WinVV (closed source developed back in the day by British Rail) we get a session that was specified inside the WinVV config and hey presto it talks to the 3270 mainframe.

    I'd like to use an open source telnet client rather than the WinVV one, and my problem is that they don't seem to work. To investigate this I tried a simple telnet to the HIS server, expecting an error back stating it couldn't understand 3270 streams, but the telnet connection simply times out. This seems really odd because I thought that anything that connected to a (telnet?) session needed to use telnet.

    Investigating further I captured the packets sent whilst connecting with WinVV. It seems they are UDP packets with a destination port of 22102. I'm really puzzled as to where to go from here.

    Thursday, July 29, 2010 1:25 PM

Answers

  •  No problem James - it may well take that long if the systems are outsourced/partially outsourced!   ATOS aren't particularly worse than
     any of the others with that -  it will depend how many of the original staff are still with them that may understand the system end
     to end.
     
     You could do, with older versions of HIS/SNA, something called distributed link services, which allows HIS servers to connect
     to other HIS servers.  Sounds like that is probably what's in use.  It's removed from the latest version as I recall - I only
     ever used it once back in the mid-late 1990's.  Modern networks don't really need it.
     
     Personally I would recommend trying to cut HIS out of the loop altogether if that is possible - would require the NR mainframe to be
     accessible via TN3270 directly, which most are these days.
     
     On the java front there's also the WebConnect product, the client and library for which is java based.  Excellent support from OpenConnect
     the vendors of that one.  Not used Jagacy myself, but am sure it's fine.
     
     Depending on what adapter you did the network trace on, the UDP could well have been the VPN encapsulation.  If you run Wireshark/Netmon
     locally on the client you should be able to trace the traffic before it goes into the VPN tunnel.  Or use tcpview from www.sysinternals.com
     that will show you the tcp connections.  Or the winsock tracing tool from www.sstinc.com
     
     However, unless the VPN client is configured to route/tunnel traffic based on the application name, a telnet to port 23 should have worked/
     connected, at least at the basic tcp-ip level, just the same as a WinVV connection, assuming it is doing a TN3270 connection to port 23.
     
     
     

    Neil Pike
    Friday, July 30, 2010 6:02 AM

All replies

  • HIS includes a TN3270 service to allow TN3270 emulators to connect to IBM mainframes to access 3270 (green screen) sessions. TN3270 is not the same as plain telnet. TN3270 allows IBM 3270 display data over a telnet session. One place to read about this is in the following TN3270 RFC:

    http://www.faqs.org/rfcs/rfc1576.html

    If you are interested in open source TN3270 emulators, you might just want to search (I use Bing <g>) for "open source tn3270".

    HIS also includes a 3270 Client that can be used in TN3270E (TN3270E was an RFC that extended TN3270 to include some additional features) mode to conenct to the TN3270 service in HIS.

    Thanks... 


    Stephen Jackson - MSFT
    Thursday, July 29, 2010 3:01 PM
  • Hi Stephen,

    Thanks very much for your reply. I wasn't aware that TN3270E was the mode required to HIS. The emulator that I downloaded had this option and when it was selected it required a LU/Device ID - is this the same as a session id?

    I had a quick look at the link you sent over but I think the problem is more to do with the config on the HIS server as opposed TN3270 itself, although it was interesting to read about EBCDIC.

    From what you say it sounds like the data can only be displayed over a telnet session. This would therefore mean that the emulator that works correctly (WinVV) must be using telnet, and would suggest that the reason none of the other 3270 emulators I've tried is config on the client rather than the server. I'm just not sure how this can be the case, I've tried every combination of the config from winvv in other emulators with no success.

    The only difference that I can see between winvv and the others is that winvv uses UDP and other emulators seem to use TCP.

    I appreciate you may never have used WinVV, but is there any chance you understand the fields in these WinVV connection params:

    [STK8]
    SUBSID=0x15
    TYPE=0x2
    [SERVER]
    SESSIONS=STK8
    INACTIVE=        
    ENCAP1=10.224.23.31
    ENCAP2=10.224.23.31
    XID=020606011026

    STK8 is the available session on the HIS (which is located at 10.224.23.31)

    Thanks again,

    James

    Thursday, July 29, 2010 3:59 PM
  • Odd.  It sounds like there is a.n.other service running on the HIS box that is perhaps acting as a gateway.
     
    On the server run a "netstat -ano" command and see which process is listening on UDP port 22102.
     
    The same command will also tell you whether the HIS TN3270 service, if running, is listening on tcp-23 or not.
    That's the default port for it, but it can be configured to listen on any port.
     
    > I'm not entirely sure I understand the problem we're experiencing at the moment but I've hit a brick wall and really have no idea where to go from here.
    >
    > We have an HIS that has some (telnet?) sessions on it. When we connect in with a terminal emulator called WinVV (closed source developed back in the day by British Rail) we get a session that was specified inside the WinVV config and hey presto it talks to the 3270 mainframe.
    >
    > I'd like to use an open source telnet client rather than the WinVV one, and my problem is that they don't seem to work. To investigate this I tried a simple telnet to the HIS server, expecting an error back stating it couldn't understand 3270 streams, but the telnet connection simply times out. This seems really odd because I thought that anything that connected to a (telnet?) session needed to use telnet.
    >
    > Investigating further I captured the packets sent whilst connecting with WinVV. It seems they are UDP packets with a destination port of 22102. I'm really puzzled as to where to go from here.
     
     
     
     

    Neil Pike
    Thursday, July 29, 2010 4:14 PM
  • As Neil indicated, this doesn't look like a TN3270 application. Those connection parameters aren't familiar to me. With a TN3270 Emulator, you typically only enter the IP Address (or name) of the TN3270 Server, the port that it is listening on (default is port 23 just like regular telnet), and possibly the Device (TN3270 session) that you want to connect to.

    It may be that there is another application running on STK8 that is acting as a middleware application to interface with HIS on the other side as Neil surmised.

    TN3270 does operate over TCP, so if WinVV uses UDP that also points to it connecting to somethign other than the TN3270 service on HIS.

    BTW - The TN3270 service in HIS does not require TN3270E mode. It can accept either TN3270 or TN3270E (unless the TN3270 mode only option is enabled). The 3270 Client that we include with HIS only support TN3270E so it cannot connect to the TN3270 service if the "TN3270 mode only" option is enabled.


    Stephen Jackson - MSFT
    Thursday, July 29, 2010 7:09 PM
  • James,
     
    Forget about WinVV - that's going to be some proprietary local thing
    someone wrote donkeys years ago.  No doubt to handle very slow network
    links out to outlying stations!  (No personal knowledge of this but as
    a commuter on BR/Network Rail for donkeys years I know that most of
    their systems, including the ones behind the fancy new ticket machines,
    are mainframe CICS/IMS based and use HIS/SNA - I've seen them crashed
    occasionally and recognise the error messages!!!)
     
    Configure up your HIS server to listen on TN3270 and then use Session
    Integrator (Microsoft HIS), or WIP (MS HIS again) or Jagacy or Zephyr
    or OpenConnect or Attachmate or any other terminal
    emulator/scraping/scripting product as the API of choice.
     
    You'll need to find out what the underlying mainframe app is best
    connected to with - i.e. is it LU6.2 or LU2 CICS pseudo conversational
    - in which case WIP may be the best method.  Or is it raw LU2 in which
    case one of the others might be better.  Or is it something really old
    and nasty like LU0 in which case you might have to resort to something
    even lower level...
     
    There's probably going to be several options - I'd strongly recommend a
    detailed conversation with the mainframe folks that actually understand
    the app(s), and the HIS folks and anyone else involved there at the
    technical/infrastructure level in integrating it all together.  Spend
    time working out the best way before ploughing into the coding.
     
    Hopefully there are still folks there that support all the relevant
    bits and it's just a case of you finding them.
     
     
     
     

    Neil Pike
    Thursday, July 29, 2010 10:49 PM
  • Hi Guys,

    Thanks so much for your advice. I've been reluctant so far to get in touch with Atos Origin to find out how it all works, albeit it only takes 5 mins to explain it takes about 3 weeks to find the person that knows the answer! I think I might have to, it's beginning to sound a bit more complicated than I was expecting.

    Regards the config their end, I know the ibm mainframe is hosted at Network Rail, there is an HIS server hosted by Atos Origin, the train operators VPN into ATOS but also have another HIS server hosted their side. Have you ever seen this before, like an HIS-HIS bridge kinda thing? Atos allocate the train operator a number of sessions, currently 15 I believe (STK1 to STK15).

    Regard the choice of client, I've decided on Jagacy - it seems to be the only screen scraping library in Java (although unfortunately not open!).

    Something that might be causing ambiguity is that I've been using Cisco VPN to get to the train operators HIS server. I realised tonight that the VPN was configured to allow clients to operate through a NAT device using UDP encapsulation. This might explain the packets going down the tunnel as UDP. I might have to see if I can go visit their office rather than adding additional confusion.

    Thanks again to both of you, I really didn't know where to go next, you've been a god send.

    James

    Thursday, July 29, 2010 11:58 PM
  •  No problem James - it may well take that long if the systems are outsourced/partially outsourced!   ATOS aren't particularly worse than
     any of the others with that -  it will depend how many of the original staff are still with them that may understand the system end
     to end.
     
     You could do, with older versions of HIS/SNA, something called distributed link services, which allows HIS servers to connect
     to other HIS servers.  Sounds like that is probably what's in use.  It's removed from the latest version as I recall - I only
     ever used it once back in the mid-late 1990's.  Modern networks don't really need it.
     
     Personally I would recommend trying to cut HIS out of the loop altogether if that is possible - would require the NR mainframe to be
     accessible via TN3270 directly, which most are these days.
     
     On the java front there's also the WebConnect product, the client and library for which is java based.  Excellent support from OpenConnect
     the vendors of that one.  Not used Jagacy myself, but am sure it's fine.
     
     Depending on what adapter you did the network trace on, the UDP could well have been the VPN encapsulation.  If you run Wireshark/Netmon
     locally on the client you should be able to trace the traffic before it goes into the VPN tunnel.  Or use tcpview from www.sysinternals.com
     that will show you the tcp connections.  Or the winsock tracing tool from www.sstinc.com
     
     However, unless the VPN client is configured to route/tunnel traffic based on the application name, a telnet to port 23 should have worked/
     connected, at least at the basic tcp-ip level, just the same as a WinVV connection, assuming it is doing a TN3270 connection to port 23.
     
     
     

    Neil Pike
    Friday, July 30, 2010 6:02 AM