Sheila
You're right and I was wrong!
I wasn't sufficiently diligent with my research of these rather tattered
manuals - which is what happens when text was first written more than 30
years ago and revised continuously ever since.
I looked only into Table 18 which is where I spotted the DYNPU=YES horror.
The text at the head of this table specifies "Table 18. External
communication adapter major node-LAN, ATM LAN emulation, or Enterprise
Extender connections, peripheral node" and LAN is what applies to your use
of the XCA major node. In other words Table 18 is the source of the error.
I really should know by now not to trust anything in these manuals with
cross-checking wherever possible. In the case of DYNPU I would have seen a
default of NO in the "Full Syntax" text and in the description of the DYNPU
operand - with nary a word about the default being YES for Enterprise
Extender by the way. Indeed under "Enterprise Extender predefined
connections" and "Enterprise Extender connection network connections" under
"Full Syntax", DYNPU is shown as DYNPU=NO.
So I guess you must have discovered that it applied to Enterprise Extender
from somewhere else in the Resource Definition Reference manual.
DYNPU=YES will be a problem only when the switched major nodes are activated
*after* the XCA major node.
Considering your problem from another angle, when your PCOMM end-users fail
to get connections, you should perform some connectivity tests.
In the days when I used to assist a colleague teach DLSw with hands-on
exercises, he had a very useful little program he ran on the PC, as a DOS
command I seem to remember. It was a sort of LAN PING which used the TEST
frame. It was possible to specify a MAC address and a SAP address and it
reported on the expected TEST response.
This was written in order to check that the bridge configuration used for
interconnecting Token Ring segments was correct. It would even indicate
which multiple routes over the set of segments was available. Since DLSw
simulates a Token Ring segment over the IP network, it was clearly also
useful for testing DLSw.
If you don't have such a program available, maybe someone reading this knows
where such a program can be found.
Note that, if such a program shows that there is no path for the Test frame,
then your problem is definitely not with VTAM definitions.
A bit of Googling confirmed that the program is called OS2PING but I can't
see it being provided anywhere. Perhaps there is an equivalent program for
Windows - or MAC or Linux ...
Chris Mason
----- Original Message -----
From: "Sheila Weissborn" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Friday, August 17, 2007 6:44 PM
Subject: Re: OSA-Express2 and SNA Pcomm - loss of connectivity
Chris,
Thank you for your input on the use of DYNPU=YES in the XCA major node.
The SNA Resource Definition Reference has a statement that DYNPU defaults
to YES for Enterprise Extender. I find it unclear on whether this is the
default
for other uses of the XCA. I will definitely schedule a change to code
DYNPU=NO. Then, there will be no question on what value is being used!
Since the current configuration works most of the time, it's hard to say if
the
DYNPU thing is a factor. We have had two outages. The first one happened
in the beginning of June in the middle of the business day.
Sheila Weissborn
Ohio Casualty Insurance Group
----------------------------------------------------------------------
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
