Re: Vtam question
- From: chrismason@xxxxxxxxxxxx (Chris Mason)
- Date: 13 Jun 2006 11:53:04 -0700
Carlos,
You'll have to explain what you mean by "Interentreprise license". Neither
the search facility of "www.ibm.com" nor Google (excepting your post)
understand what it means either.
I hope this ignorance is not going to ruin the rest of my response.
I have to assume that the question mark at the end of your second sentence
means that you are asking "Is it possible to get communication between vtam
at my host to another vtam in a different host with different network id´s
using Cross-Domain feature?"
I further have to assume that "cross-domain feature" refers to *subarea*
cross-domain. I have to apologise for having a blank spot in my pursuit of
VTAM in that, I missed the first two releases of ACF/VTAM - and ACF/NCP -
which introduced subarea cross-domain and I got started with that use of
VTAM and NCP program products only with Release 3 which introduced many
enhancements. However I seem to remember the initials MSNF, meaning
"Multisystem Networking Feature" - or something like that - being applied to
subarea cross-domain. This is all in an attempt to work out why you use the
word "feature" and what, precisely, you might mean. By the time I started
working closely with the latest VTAM, the term MSNF was hardly ever used.
It is quite possible to communicate between two VTAM applications in
different domains having different network identifiers (NetIDs) but only
using either SNI (SNA Network Interconnection), or "type 2.1 node
appearances".
In case you don't understand what I mean by "type 2.1 node appearances" -
and you are quite entitled to be puzzled by that description - it means
where the VTAMs are connected by a link where the VTAM nodes are defined so
that they appear to be type 2.1 nodes to each other.
SNI is, in principle, the closest to subarea cross-domain in that it is an
extension of subarea cross-domain specifically to deal with the business
requirement for two networks with autonomous routing designs to be able to
communicate between themselves. However, one component you haven't mentioned
is NCP and it is necessary to have at least one NCP involved because an SNI
network boundary must lie within an NCP. In order to support NCP today
you'll need to have a Linux on System z image available on which you can run
Communication Controller for Linux - or you may still have a 3745.
At its most basic, "type 2.1 node appearances" is a Low Entry Networking
(LEN) connection. When this was first introduced for connections between
VTAM domains, it was called "casual connect". The NetID of one of the VTAMs
can be different from that of the other VTAM and, in the case of "type 2.1
node appearances", in contrast to the case with SNI, the network boundary
lies on the link between the (apparently) type 2.1 nodes.
Normally, it's handy just to examine the structure of a networking
configuration without worrying about the actual media that may be used to
create the necessary links. In the case of a connection between VTAMs, the
most obvious media is the channel media and, unfortunately, this media is
not available for a purely LEN connection between VTAMs. However, I will
qualify this limitation shortly. Of course, some may say that a channel link
is unlikely if the NetID has to change. The response to this can be that
there are so many "tricks" available these days that "remote" channel
connections are not unusual.
There is another limitation on a LEN connection in that any session must be
initiated by the primary side of the session. If the session you want is
indeed a session between two VTAM applications, this will very probably be
the case and so the LEN connection will be suitable. Please post again if a
LEN connection meets your requirements and you need help with the
definitions required.
If both of the VTAMs are enabled for APPN, then you have the same level of
flexibility as with SNI - but without the need for at least one NCP. In
addition, the channel limitation I mentioned above with LEN is no longer
there.
The least complicated choice here is to define one or both VTAMs as End
Nodes. If one VTAM is defined as an End Node and the other VTAM is defined
as a Network Node, they can have different NetIDs and yet the full range of
session setup possibilities are present in the configuration. There are
nevertheless limitations in this configuration, the chief of which is not
allowing the End Node to act as a routing node. However, your problem, as
specified, did not include this requirement.
If both VTAMs are defined as End Nodes, you will be able to have a channel
link between the VTAMs but you will need to use LEN protocols between the
VTAMs. (I am excluding the possibility that there is yet another VTAM
present in the configuration defined as a Network Node and connected to both
of the VTAM End Nodes. Incidentally, this VTAM could have yet another
NetID.) Thus you would have APPN enabled in both VTAMs but, at least over
the link between the VTAMs, APPN functions would not be being used. It may
be that you would like to use this configuration but do not want the
uncertainties of having untested APPN functions present in the rest of the
networks associated with the two VTAMs. This can easily be done by
preventing any CP to CP sessions or by allowing CP to CP sessions to be
established only over selected links.
If both VTAMs need to be APPN Network Nodes, then you will need to use the
APPN border node function. VTAM implements the "Extended Border Node" (EBN)
function and you can implement this with just one side being defined as an
EBN or both sides defined as an EBN with no limitations on your session
setup. Assuming your VTAMs have had all the adjustments necessary for
supporting APPN, merely defining one or both of the adjacent VTAMs as EBNs
will probably be sufficient. That is, the defaults for EBN operation will
allow any session setups you need. There may be mode name and COS name
problems but, if so, please post again - assuming this is your solution.
Having got all that explained I see your final sentence is discussing
"gateways" and "back-to-back" by which I assume you are referring to SNI -
and again there is some confusion over the presence or otherwise of a
question. Anyhow, if you want to have a change of NetID and you wish to
retain a purely subarea configuration, you need SNI. I'm still assuming that
when you say "cross-domain" you mean subarea cross-domain and - if I
understand what you are asking - SNI will be required whatever sort of
gateway configuration you may wish to construct, the "single NCP gateway",
with one or two gateway SSCPs (VTAMs), or the minimally two gateway NCPs and
two gateway SSCPs "back-to-back" configuration.
Chris Mason
----- Original Message -----
From: "Bodra - Pessoal" <cbodra@xxxxxxxxxxxx>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@xxxxxxxxxxx>
Sent: Saturday, 10 June, 2006 12:30 AM
Subject: Vtam question
What is the difference between VTAM Cross-Domain and Interentreprise
license?
It´s possible to get communication between vtam at my host to another vtam
in a different host with different network id´s using Cross-Domain
feature?
Or Cross-Domain is used just for Single gateway, not back-to-back
connections?
Thanks
Carlos
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- References:
- Vtam question
- From: Bodra - Pessoal
- Vtam question
- Prev by Date: Re: What's your favorite ASCII and EBCDIC code pages?
- Next by Date: Re: z/OS HTTP Web Server
- Previous by thread: Vtam question
- Next by thread: Re: Vtam question
- Index(es):
Relevant Pages
|
