Subject: Re: Commands from TCP/IP (CSI) Menus
From: Chris Mason (chrismason@belgacom.net)
Date: Wed Nov 04 2009 - 06:18:01 EST
Commands from TCP/IP (CSI) MenusDavid
It's good to know that there is an instance of the TN3270 server available on each VSE system. That would make implementing the design where the "menu" is supported by the TN3270 client - as opposed to the TN3270 server - so much easier to introduce. I can't really see any disadvantages in that approach - perhaps you can - since it's so much more logical than connecting to a VSE system (at random?) and then connecting to an application which might reside on another VSE system. Why not break any existing TN3270 connection and start again?
However you didn't seem interested in that idea.
I'm not sure why the customer "owning" the LAN makes any difference. I thought the whole configuration was "owned" by the customer and you were acting in some sort of consultant capacity for your customer.
I suggested using the LAN for the connections to support an APPN configuration since I guessed this might be easier than using CTC connections. The difficulty with CTC when "migrating" from "subarea" to APPN is that you have to set up at least two CTC paths with the APPN definitions where only one was needed with the "subarea" definitions. That was why I thought using the LAN might be easier.
You didn't say but I guess it's possible that these 4 VSE "machines" are "virtual machines" and so the CTC connections are virtual CTC connections thus making setting up APPN CTCs quite a trivial exercise - but then *virtual* CTC connections shouldn't break independently of the systems they are connecting so maybe it's all real!
Incidentally, the way to check connectivity in any flavour of interconnected VTAMs these days is to use the DISPLAY APING command in case that command is new to you. Also you have only 4 VSE systems to check so you should easily find any broken "subarea" links with a DISPLAY STATIONS command entered at each system.
A further thought is that you really ought to have some redundancy in the 4 system configuration so that a single link failure can be tolerated. With "subarea" VTAM that needs slightly more than trivial route planning. Perhaps you might need some help there. Some time ago I provided some help on those lines to one of your VSE list colleagues.
Chris Mason
----- Original Message -----
From: Wakser, David
To: VSE Discussion List
Sent: Wednesday, November 04, 2009 10:17 AM
Subject: RE: Commands from TCP/IP (CSI) Menus
Chris:
Thanks for the posting. Indeed, no one answered this post (until now), and you have described the scenario correctly - except that each VSE does, indeed, already run a TCP/IP stack. And the trouble with the current setup is that, when something gets "broken" (e.g. a CTC link has failed), finding the problem becomes a ridiculous effort. My thought was that, if the TCP/IP menu would allow specification of an IP address/port (instead of just a VTAM application name), the entire scenario would become simpler to maintain. I would not get rid of VTAM in each of the VSE guests, merely dismantle all of the CTCs, CDRMs, and subareas involved at present. Oh, and by the way, at present the original connection to the system is via IP to any one of the VSE guests - and each one provides the same looking menu to maneuver to any of the other VSEs or applications (CICS or FAQS).
Since, however, the LAN "belongs" to the client, and we have no access to it, I don't think that an APPN solution would be the answer. And TUBES (a session manager) would be a good solution (since it allows IP addresses as the target), but that would introduce too many "new" things to the client (including a cost), which they would not go for. So, I am still looking at some sort of solution.
David Wakser
------------------------------------------------------------------------------
From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf Of Chris Mason
Sent: Wednesday, November 04, 2009 4:02 AM
To: VSE Discussion List
Subject: Re: Commands from TCP/IP (CSI) Menus
David
I see nobody has responded.
I "lurk" in this list looking out for VTAM/SNA topics. I haven't been a VSE (DOS) specialist for getting on for 40 years now so you'll have to excuse my ignorance of the VSE of today. I know a bit about IP and its related protocols but nothing about the VSE implemenentation(s).
With all these caveats, your post still looks a bit confused. As far as I can tell - to some extent, guess - you have applications which are supporting access via VTAM using 3270 data streams. That will require VTAM on every system with such an application. Thus you can't get rid of VTAM itself.
That leaves the SNA networking between systems supported, it would appear, using CTCs. For that you need an SNA architecture.
I'm assuming that you have one TN3270 server on one of your systems which supplies this so-called "TCP/IP menu" identifying the SNA applications to which the TN3270 server is prepared to set up an SNA session, either "same-domain" or "cross-domain", to which to concatenate the TN3290 server to TN3270 client TCP connection.
The fact that you are bemoaning the need for these "VTAM connections" indicates that you are using unreconstructed *subarea* networking between your systems with all the attendant worries of having to rely on obscure PATH statements, CDRMs, COS tables and maybe some more VTAM definition members such as adjacent SSCP tables and CDRSCs if nobody bothered keeping these VTAMs up to date 20 year ago with the streamlining enhancements of the '80s.
What you appear to want is some IP-based software which enables redirection of TN3270 connections to different VSE systems.[1] What you could quite easily do is simply set up a TN3270 server on each of your VSE systems and access each system based on the name entered at your TN3270 client. I expect the TN3270 client software has some sort of selection list available. I see my FileZilla has a "Site Manager" and there is also a "History" under "Quickconnect".[1]
However, additional TN3270 servers may cost money!
What will *not* cost money, and probably could also quite easily be done, is to shake off the SNA subarea networking with APPN networking. I expect you have a LAN infrastructure connecting the systems. That LAN infrastructure could support the SNA APPN connections using the "connection-oriented" 802.2 LAN protocol and hence the CTC connections could "go".
Please post again if you need more assistance.
Chris Mason
[1] Is this what TUBES does? The "IP connection to the application" will still need a TN3270 server function on each VSE system since the applications don't change and they need VTAM.
[2] I was thinking of suggesting using the name server in order to support name to IP address mapping but reasonable clever TN3270 clients bypass this possible approach.
----- Original Message -----
From: Wakser, David
To: VSE Discussion List
Sent: Wednesday, October 28, 2009 11:24 PM
Subject: Commands from TCP/IP (CSI) Menus
All:
In a CSI stack, can a menu "command" be something other than a VTAM application name? For example, can it either be an IP address or a TELNET xxx.yyy.zzz command?
I am in the midst of "cleaning up" a client's system and I would LOVE to get rid of all the VTAM connections between the 4 VSE machines. However, they do not have a session manager (like TUBES, which allows IP connections to applications), but they use the TCP/IP menu to choose which CICS in which VSE (or which FAQS in which VSE system) they want to access. If I could utilize an IP connection from the menu instead of a VTAM application, I could get rid of all the VTAM CTCs and all the things that go along with them. Any ideas? Or am I stuck with the VTAM and CTC connections?
David Wakser
This archive was generated by hypermail 2b25 : Sat Nov 21 2009 - 22:35:06 EST