Sheila
And now for the comments on your VTAM definitions.
First, why bother about some of these seemingly relatively trivial matters?
If you do not have a full understanding of what you are working with then
you are in a bad position to try to work out what is really happening when
there is a problem - such as now.
I suggest always to specify relevant operands and, perhaps after there has
been a change in the configuration, remove irrelevant operands.
-
The MAXGRP and MAXNO operands of the VBUILD TYPE=SWNET statement are
obsolete as is the MAXPATH operand of the PU statement under the VBUILD
TYPE=SWNET statement.
If you search the Resource Definition Reference for them, you find the
following:
<quote>
Restriction: The MAXDLUR, MAXGRP, and MAXNO keywords on the VBUILD
definition statement and the MAXPATH keyword on the PU definition statement
are obsolete. If these keywords are defined, the values are not checked and
the keywords are ignored. No messages are issued.
</quote>
These "accounting" operands have always been very irritating and I was very
pleased to see the back of them - quite a long time ago actually.
-
I suggest that you adopt the standard of selecting the switched PU statement
on the CP name, the CPNAME operand, rather than the IDBLK and IDNUM
operands. The CP name must be administered as an unique name anyhow so it's
one less administrative job having to maintain unique IDBLK/IDNUM
combinations.
These days the only role for the IDBLK and IDNUM operands of the switched PU
statement is for the logical switched connections to nodes supporting the
DLUR function.
-
The IRETRY operand of the switched PU statement is something of an anomaly -
along with the PASSLIM operand which I am happy you and/or your predecessors
did not think appropriate to specify. Both these operands relate to
multipoint operation, an SDLC capability not permitted on switched
connections. However, perhaps we should credit the designers of the switched
PU statement with amazing prescience. The statement was designed around 1977
or so but the multipoint operands actually became relevant to the provision
of parameters to multipoint lines when the 3746-9x0 machines became
available in the mid-90s as a consequence of external DLUR support!
The Resource Definition Reference manual imagines that these operands are
relevant only for NCP when, in fact, they really cannot be said to have any
role for NCP.
-
The MAXDATA operand of the switched PU statement is not relevant when the
adjacent node - that is, logically adjacent in SNA terms - is PCOMM. That is
because PCOMM, as all current SNA type 2.1 node platform software for some
years now, supports the format 3 XID frame for the purposes of making
contact with its adjacent type 2.1 node or, strictly in the case of an OSA
feature port supported by an XCA definition, a type 5 node behaving as a
type 2.1 node.
There is a field in the format 3 XID which supplies the value of the
parameter which, when older formats of XID were used, needed to be specified
using the MAXDATA operand. When a format 3 XID is used the value of the
MAXDATA operand is ignored.
Here's the rather clumsy way the point is made in the Resource Definition
Reference manual:
<quote>
3. MAXDATA is ignored for type 2.1 nodes attached through an NCP, an IBM
3172 Nways Interconnect Controller, or through an IP network for Enterprise
Extender. The type 2.1 node supplies the actual value used when the
connection is established.
</quote>
The way you are using your OSA feature it is behaving like a 3172.
-
For performance reasons I could suggest a larger value for the MAXOUT
operand value. If this were a pure 802.2 connection, I would recommend
something like 20. When I had a 3 or 4 segment 16M token-ring LAN available
to me, by using NTuneMON for the purposes of examining NCP control blocks, I
generally observed 11 or 12 as the number of frames pending acknowledgement.
20 is safely above that value but without allowing too large a number. It's
important to be able to set MAXOUT to a value larger than the natural window
size for the configuration so that sending frames will not generally have to
wait for acknowledgements to frames already sent over the link connection.
However having DLSw in the configuration may result in a quite different
natural value and the fact that DLSw "spoofs" acknowledgements may need to
be taken into account.
Note that you can specify any value up to 128 but there's no point is being
much larger than the "natural" limit.
-
Normally, when taking advantage of being able to specify LU operands on the
PU statement, you specify them there and leave them off the LU statement. If
an operand is specified, where relevant, on all LU statements which can use
it, specifying the same operand on the PU statement is redundant. This goes
for SSCPFM and USSTAB (relevant only where SSCPFM is specified as USSxxx, in
this case, USSSCS).
-
LOCADDR=0 is a definition disaster area as VTAM developers will readily
admit. What happens with an LU statement with LOCADDR=0 specified is that it
needs to be converted by VTAM into, effectively, a CDRSC statement. It's
potentially less confusing if the SSCP-independent LU is actually defined
this way.
A further possibility is to have the SSCP-independent LU which is using the
same name as the CP - as in your case - defined dynamically using the
CPCDRSC=YES start option.
If you did allow your SSCP-independent LU with the same name as the CP to be
defined dynamically, you should ensure that the necessary mode table name is
specified with the DYNMODTB start option and any necessary default mode
table entry name with the DYNLGMD start option.
-
The RESSCB operand is significant only when the SSCP-independent LU requires
the services of boundary function support in NCP. I expect this is a relic
from when you used NCPs.
-
It's odd that you are using LOCADDR=2 for an SSCP-dependent LU 6.2 session -
as I judge it to be from the default mode table entry name. It's not wrong,
of course, simply unusual.
Note that you could have specified SSCPFM=USSSCS on the PU statement and
then overridden that specification only on the LOCADDR=2 LU statement with
SSCPFM=FSS. You could still simply specify USSTAB=USSSNAT on the PU
statement. The USSTAB operand is ignored if SSCPFM=FSS is in effect.
Similar observations could be made regarding the DLOGMOD operand so that the
LUs with LOCADDR=3 to 8 need only specify the LOCADDR operand making for a
much neater set of statements.
-
Generally, rather than using a mode table entry which implies fixed
presentation space dimensions, I would suggest a mode table entry which
allowed the presentation space dimensions to be determined dynamically by
the application. Thus in the PCOMM specifications you can define whatever
dimensions are felt to be convenient by the end users. However this depends
on what the end users are doing and whether the application(s) can exploit
such flexibility.
-
Another function you could use is to have the SSCP-dependent LUs defined
dynamically. Never having done it, I'm unsure about whether this is possible
for your single SSCP-dependent LU which participates in LU 6.2 sessions.
However, it is certainly possible for the remaining SSCP-dependent LUs using
a function supplied by PCOMM to provide a code which can be used to select a
*model* LU definition.
-
Regarding your pacing specifications, it's unusual ever to use pacing with
3270 display sessions so I find the VPACING=10 specification somewhat odd.
3270 LU 2 is nearly always self-paced with definite responses. Insisting on
pacing responses simply introduces ineffective additional traffic.
However you may have special reasons for your pacing values.
-
Another point independent of your definitions: you said you're OSA looked
fine "in VTAM". I don't expect the problem has got anything to do with your
OSA features but, when you are uncertain of the health of your OSA features,
you should pull off the comprehensive "QUERY CHPID" report from OSA/SF. It's
probably a good idea, as always with problem diagnosis, to get familiar with
this report when things are working normally.
Chris Mason
----- Original Message -----
From: "Sheila Weissborn" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
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)
VBUILD MAXGRP=1,MAXNO=1,TYPE=SWNET
PUTECH0 PU ADDR=50,IDBLK=05D,IDNUM=99990,
DISCNT=NO,NETID=(,NOXNETLS),
ANS=CONT,
IRETRY=YES,
PUTYPE=2,
MAXDATA=1033,
MAXOUT=7,
MODETAB=MODETBL,DLOGMOD=T3278M2,
USSTAB=USSSNAT,
SSCPFM=USSSCS,
PACING=0,
VPACING=10,
MAXPATH=4,CPNAME=LUTECH00
LUTECH00 LU LOCADDR=00,DLOGMOD=IBMRDB,RESSCB=10
LUTECH02 LU LOCADDR=02,DLOGMOD=IMWKLU62,SSCPFM=FSS,ENCR=OPT
LUTECH03 LU LOCADDR=03,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH04 LU LOCADDR=04,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH05 LU LOCADDR=05,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH06 LU LOCADDR=06,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH07 LU LOCADDR=07,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
LUTECH08 LU LOCADDR=08,DLOGMOD=T3278M2,
SSCPFM=USSSCS,USSTAB=USSSNAT
----------------------------------------------------------------------
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
