Subject: RE: Commands from TCP/IP (CSI) Menus
From: Wakser, David (David.Wakser@infocrossing.com)
Date: Wed Nov 04 2009 - 07:50:42 EST
Chris:
Thanks, again, for some ideas to consider. And thanks, also,
for a refresher course in some of the VTAM commands I have not used in
many years.
We are an outsourcer for the mainframe only; the LAN aspects
are entirely out of our jurisdiction and we have no access to the
client's network. In my experience, I find when different parts of the
network solution belong to different entities, it's difficult to get
things accomplished, and even more difficult to trouble-shoot (each side
typically blames the other one).
To my knowledge, the CTCs are, indeed, virtual.
One of the tricky parts of supporting this client is that
they are adamantly opposed to change. Thus, if I could leave the
IP-based menu in place, and merely route the connections differently
(under the table, so to speak, so the client would not even know the
difference), I have a much better chance of getting their approval.
Otherwise, I don't see them approving any changes to the method of
system entry or the "look and feel" of movement between systems and
applications.
I'm still attempting to brainstorm this problem, so I'll let
you know what we end up with.
David Wakser
________________________________
From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf
Of Chris Mason
Sent: Wednesday, November 04, 2009 6:18 AM
To: VSE Discussion List
Subject: Re: Commands from TCP/IP (CSI) Menus
David
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 <mailto:David.Wakser@infocrossing.com>
To: VSE Discussion List <mailto:vse-l@Lehigh.EDU>
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
<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 : Sat Nov 21 2009 - 23:35:06 EST