Sheila
I was going to say - not that I can see nothing wrong with your
definitions - I couldn't see why your definitions should not at least work -
as indeed you said they do some of the time.
However I checked your definitions more precisely and - most importantly -
checked for what you had *not* specified, namely the default values.
I was actually flabbergasted at what I spotted. And I'm not sure whether or
not it is true. The standard of precision in VTAM documentation has gone
down-hill in the last decade or so.[1]
What I spotted was that the default value for the DYNPU operand of the XCA
major node GROUP statement is YES. I checked my presentation notes which
cover the topic and I found that the default when the operand was introduced
in the early '90s was NO - as it jolly well ought to be! How it has managed
to get changed - if indeed it has changed - I obviously haven't a clue.
All that follows assumes that the default value for the DYNPU operand of the
GROUP statement in the XCA major node really is YES.
The answer to your question over whether or not anyone has experienced your
problem is, possibly, also "yes"! I have had to resolve this problem
before - about 10 years ago - but then the problem was that DYNPU had
actually been coded as DYNPU=YES. The poor IBM systems engineer had made the
gross error of copying parameters from a redbook example without
understanding what each one did - as had, of course, the redbook authors -
and their advisor - and any possibly savvy reviewers also hadn't spotted the
danger.
What may have happened from when your definitions worked to when they no
longer worked is that you activate the OSA port using the XCA major node
***before*** you activate the switched major nodes. This is very probably a
matter of the order of specification of the names of major node members in
your ATCCONxx member.
The effect of this is that, as a PCOMM node tries to connect to the newly
initiated VTAM, the request to connect is satisfied dynamically and, in
effect, a default switched PU definition is assigned to the PCOMM node. This
default definition will have only the SSCP-independent LU with the same name
as you defined for the CP within PCOMM assuming you have CPCDRSC=YES, not
the default, in your VTAM start options. The name given to the dynamically
created PU statement will begin with "CN" since you have not specified the
DYNPUPFX operand to have a value other than the default.
Once the switched major nodes become active, the individual PU minor node
definitions will sit there quietly in CONCT status, there being no reason
for them ever to become connected. Or maybe they'll be in RELSD status - or
something like that - since for them to become active would imply an
identification conflict. I'm afraid I'm not in a position to test out my
conclusions these days.
So, if the default value for DYNPU is indeed YES these days and you do *not*
want to use the default dynamic PU statement definition for your PCOMM
connections - which you clearly don't, you should specify DYNPU=NO on the
GROUP statement of the XCA major node.
You could simply position the switched major node names earlier in the
sequence of names in the ATCCONxx member so that they appear before the name
of the XCA major nodes - but that's living dangerously! Who knows what the
next person to respecify the names in ATCCONxx might decide to do?
Reviewing you post again, the problem is not that a connection fails to take
place. A connection does take place, it's just not the connection you want.
Strictly, I would expect that "bouncing the XCA" would fix the problem.
Maybe either OSA port will accept the perpetual connection attempts from the
PCOMM nodes and you did not "bounce" both XCA major nodes at the same time.
The point is that, after the "bounce", the switched PU definitions will be
waiting, as it were.
---
If all this does not turn out to be the solution, please follow up on my
other request and indicate more about the configuration of nodes - and
protocols - from the OSA port to the PC running PCOMM.
Also please be sure to note what connections may be taking place and whether
or not the PCOMM nodes show a connection - even if the PU entity and the LU
entities are not active (excluding the LU with the same name as the CP which
may be able to initiate sessions anyhow).
---
Regarding "not that I can see nothing wrong with your definitions", I'll try
to post again with some observations on the definitions you supplied with a
view to reducing them to essentials and possibly introducing some
improvements in, for example, performance and dynamism!
---
Perhaps your comments about Cisco related to Eric's comments about the
relative "solidity" of Cisco routers and 3745s. This is actually an unfair
comparison. What is different between Cisco routers and the 3745 is the
suitability of the underlying technology. For reliable business-oriented
applications, "connection-oriented" will always knock the spots off
"connectionless". One must hope that, when a customer decides to replace the
SNA network, with emphasis on the actual *physical* connections, with fancy
protocol soups based on IP, the loss of "solidity" is considered acceptable
in comparison with the anticipated benefits.
Well, that's what's supposed to happen! Of course, you will get no help from
Cisco types in making such an assessment - nor indeed from IBM types these
days, they've had a revised hymn sheet forced on them!
Chris Mason
[1] Witness the specification for the GROUP statement DIAL operand in table
18. How is it logically possible to have a default value for a *required*
operand?
----- Original Message -----
From: "Sheila Weissborn" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Wednesday, August 15, 2007 6:18 PM
Subject: Re: OSA-Express2 and SNA Pcomm - loss of connectivity
I want to clarify something so there is no misunderstanding. I do not mean
to
imply that this is a problem with Cisco's equipment or any other component
for
that matter.
The OSAs are connected to a Cisco 6500 switch which in turn connects to a
core router.
Here are sample definitions in VTAM for the XCA member and the switched PU
definition:
XCA04B00 VBUILD TYPE=XCA
OSAFENT1 PORT MEDIUM=CSMACD,
ADAPNO=0,
CUADDR=0B00,
SAPADDR=04
*
GROUP1 GROUP ISTATUS=ACTIVE,
DIAL=YES,
CALL=IN,
AUTOGEN=(2000,OSAL,OSAP)
<remainder snipped>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
