Subject: RE: Commands from TCP/IP (CSI) Menus
From: Wakser, David (David.Wakser@infocrossing.com)
Date: Wed Nov 04 2009 - 04:17:08 EST
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 <mailto:David.Wakser@infocrossing.com>
To: VSE Discussion List <mailto:vse-l@Lehigh.EDU>
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
Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
This archive was generated by hypermail 2b25 : Sun Nov 22 2009 - 01:05:05 EST