Norbert
Thanks for the information.
I misunderstood what you meant by "before the whole screen comes". This
implied that you session stopped for a while and then continued. Perhaps you
should have said "before the whole screen would have come, if it had
continued working". So it really is a permanent "hang".
The evidence is building up that the reported "MAXDATA" value is wrong so
you were right to suspect it. With a BTU size of 1498, there's no room for the
802.2 connection-oriented LLC header inside the old Ethernet limit of 1500. It
then makes sense that the first large request unit is going to need segmenting
and that the segment worked out as a BTU size of 1498 will be dropped by the
Ethernet adapter resulting in a hang.
When support for LANs was introduced for subarea connections, segmenting
was introduced also for subarea links - previously it had been used only for
peripheral links. Is there DISPLAY command output which shows a MAXDATA
value for the case where you use subarea connections with XCA major nodes?
Perhaps you could show that value.
Also, the ANNC link is a type 2.1 connection. Is there DISPLAY command
output which shows a MAXDATA value for this type of connection?
I would suggest trying to limit the request unit size used over the type 2.1
node connection. I expect you are using non/pre-SNA 3270, that is, defined
with LOCAL statements, so using the RUSIZES operand of the mode table
entry definition will not be effective. You could use TN3270 as a test perhaps
with a mode table entry which specifies, say, RUSIZES=X'8787' for a request
unit size in both directions of 1024.
According to APPN architecture, you should be able to impose a maximum
request unit size by means of a mode table entry associated with the CDRSC
definition in the "other" VTAM node where that CDRSC definition represents
the secondary LU in the session. I have never tried this but you might like to
try it. The point is that segmenting is supposed to apply session stage by
session stage between Intermediate Session Routing (ISR) staging points. You
are avoiding using High Performance Routing (HPR) - and rapid Transport
Protocol (RTP) - but actually this doesn't change this principle since the RTP
end-points incorporate ISR architecture.
Incidentally, I asked for DISPLAY NET,BFRUSE output only because there was
an outside chance that your "performance" problem was related to VTAM
buffers. Since it really is a "hang" rather than an excessive delay, that is
not
so relevant. In fact, I can see you are hardly touching default basic buffer
allocations.
A way of testing the idea that it is when a request unit needs to be passed
over the connection which requires segmenting, we can try using DISPLAY
APING in order to send different request unit sizes. You should perform
a "binary search" starting with, since we may as well use the default mode
name #INTER which has RUSIZES=X'F7F7' which maps to a request unit size of
1920 in both directions, SIZE=1920[1] and then 960 and so on. If all the
theory is correct, 1920 should fail. If it doesn't fail that's the end of the
test
and it's back to the "drawing board".
Incidentally, if you happen to have NetView Session Monitor, aka NLDM,
active, you can report what a primary trace with CPIU specified shows. In the
past, it was axiomatic that all SNA installations would have NLDM active and
NLDM was used immediately there was any suspicion of a problem with a
session - as here. Sadly this appears no longer to be the case, so problem
solving requires the so tedious use of GTF and VTAM buffer traces. Ideally I
would like to see what the request unit that gets sent by TSO but does not
arrive looks like, especially its size.
Getting back to the MAXDATA value: I invariably encourage not specifying the
MAXDATA operand when defining a PU statement for an adjacent link station
in a type 2.1 node since the adjacent link station logic will supply a value.
However it is always possible that the logic supporting the resource
representing the adjacent link station could respond to the MAXDATA value in
the control vector prepared by VTAM in a standard way from the PU
statement operand values. If the logic did respond to these control vector
values, it *could* modify the value it obtains from the XID frame sent by the
adjacent node. Such a modification would be to select the lower of the two
values.
When you said that MAXDATA is ignored in the case of link stations in type
2.1 nodes, were you stating what you had read in the manuals or knew from
education courses - or - did you actually try a value lower than 1498 - on the
TSO application side to be precise? If there were any effect, it would, of
course, show in the DISPLAY command output message IST956I.
-
I see from the output of DISPLAY NET,BFRUSE that you have a reasonably
recent VTAM. That being so I can recommend removing some useless antique
clutter from your definitions. It doesn't affect the problem but clearing away
the dead wood can help quite a bit in understanding your definitions.
The VBUILD TYPE=XCA major node is fine.[2]
On the other hand, the VBUILD TYPE=SWNET major node needs a bit of
pruning.[3] All the irritating "MAXes" were thankfully discarded ages ago. Thus
you do not need MAXNO, MAXGRP and MAXPATH.
>From the CS SNA Resource Definition Reference manual:
<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>
This isn't a "restriction", it's a "liberation"!
Despite the manual saying it is required, the PU statements I recommended to
a customer recently did not contain the ADDR operand and I do not recall any
complaints. This was always useless for LAN connections and a developer
promised me he would stop making it required ages ago. It seems he was true
to his word - eventually - but this fact just hasn't got through to the manual
authors.
There are a number of operands here for which you may have set defaults
using the start options. These are CONNTYPE, DYNLU, CPCP, NETID and HPR.
You may have your reasons for wanting to specify the operands differently on
the PU statement - as you mentioned for the HPR operand - although I didn't
quite follow the reasoning.
DWACT=YES is a very handy way not to have to enter a VARY NET,DIAL
command in the case of connections between APPN nodes which use switched
procedures.
Chris Mason
[1] This isn't strictly logical since, to the request unit size of 1920, will
be
added the request header size of 3 and transmission header size of 6.
However, since we are initiating a "binary search", the starting value can be
approximate.
[2] Checking the Communications Server (CS) SNA Resource Definition
Reference manual to be sure about the XCA major node definitions, I saw that
the default for DYNPU is described as YES in the summary Table 18 which
could have caused difficulties. That can't be I thought and, checking with the
operand description, I see it isn't - par for the accuracy course for the
manual
authors!
[3] I was also going to suggest "training of old growth" but I can't see any
description anywhere that the DLCADDR operand is actually understood by
VTAM itself on behalf of XCA major node resources supporting LAN media. The
CS SNA Network Implementation Guide continues to use the DIALNO operand
in its examples. Ideally you should be able to replace the old DIALNO operand
by a much neater way of specifying the "signaling information" required to
make contact over a variety of data link control types than the distorted use
of the "dial number" operand so oriented to the "public switched telephone
network". In the case of 802.2 Ethernet, your DIALNO would be replaced with
something like the following:
DLCADDR=(1,C,ETHERNET)
DLCADDR=(2,D,1)
DLCADDR=(3,X,04)
DLCADDR=(4,X,40000E060040)
It's very odd that the OSA feature logic can handle the DLCADDR operand
when it comes to supporting ATM but not when it comes to older stuff like
Ethernet. If I had the right sort of "sandbox" facilities to hand, I'd be
checking
this out right now!
On Sat, 25 Apr 2009 20:13:37 +0200, Norbert Alfred Müller
<[email protected]> wrote:
>Hello Chris !
>
>first of all, thank you for your detailed answer !!!
>The nodes are defined as NN and with HPR=NO, is a simulation and after that
we must connect a VSE with z/OS, this is the reason for HPR=NO.
>I guess in my problem is irrelevant, because the same nodes work ok with
ANNC connections.
>Maxdata is 1498 ! is not misreported, you can see this below, in a display
command.
>Regarding 7060: I mean the mainframe IBM 7060, Multiprise 3000, this
mainframe has a Emulated I/O very similar to the p/390, my point was that I
have the same problems with a z/9 ( Osa Adapter).
>The sequence of logon is: Normally we have, after the initial logon screen
from TSO:
>
>ICH70001I P390A LAST ACCESS AT 18:11:38 ON FRIDAY, APRIL 24, 2009
>IKJ56455I P390A LOGON IN PROGRESS AT 11:57:25 ON APRIL 25, 2009
>IKJ56951I NO BROADCAST MESSAGES
>
**********************************************************
********
> * *
> * WELCOME TO THE P390 SYSTEM *
>and blah, blah, here comes description from IBM...a full screen of data.
>***
>
>In my logon "cross domain"....
>
>ICH70001I P390A LAST ACCESS AT 18:11:38 ON FRIDAY, APRIL 24, 2009
>IKJ56455I P390A LOGON IN PROGRESS AT 11:57:25 ON APRIL 25, 2009
>IKJ56951I NO BROADCAST MESSAGES
>
>and X SYSTEM.
>Dead.
>
>Here the XCA definition: The same in both systems:
>
> XCAE40E VBUILD TYPE=XCA
> XPE40E PORT
CUADDR=E40,ADAPNO=1,SAPADDR=4,MEDIUM=CSMACD, -
> DELAY=0,TIMER=30
> XGE40E GROUP DIAL=YES,CALL=INOUT,ANSWER=ON,ISTATUS=ACTIVE
> XGEL00 LINE
> XGEP00 PU
> XGEL01 LINE
> XGEP01 PU
>
>
>And the Switchad major node:
>
>SWAPPN VBUILD TYPE=SWNET,MAXNO=5,MAXGRP=5
>SWPU01 PU MAXPATH=5,CONNTYPE=APPN,DYNLU=YES, *
> PUTYPE=2,ADDR=C1,CPNAME=XSC6, *
> NETID=LLLNET1,CPCP=YES,DWACT=NO,HPR=NO, *
> TGP=ETHERNET
>PATHSW PATH DIALNO=010440000E060040,GRPNM=XGE40E
>
>The node 2 has the same definition, of course another MAC Adress, and
CPNAME.
>
>Resulst fron the vary dial:
>
>V NET,DIAL,ID=SWPU01
>IST097I VARY ACCEPTED
>IST590I CONNECTOUT ESTABLISHED FOR PU SWPU01 ON LINE XGEL00
>IST1086I APPN CONNECTION FOR LLLNET1.XSC6 IS ACTIVE - TGN = 21
>IST241I VARY DIAL COMMAND COMPLETE FOR SWPU01
>IST1096I CP-CP SESSIONS WITH LLLNET1.XSC6 ACTIVATED
>
>And in system 2 we see:
>
>IST590I CONNECTIN ESTABLISHED FOR PU SWPU02 ON LINE XGEL00
>IST1086I APPN CONNECTION FOR LLLNET1.XSC1 IS ACTIVE - TGN = 21
>IST1096I CP-CP SESSIONS WITH LLLNET1.XSC1 ACTIVATED
>
>
>here the results fron D NET,BFRUSE: the same in both systems, and I not
attached after the Hung, because values are quite the same.
>
>IST920I IO00 BUFF SIZE 590 EXP INCREMENT 6
>IST921I TIMES EXP 0 EXP/CONT THRESH 20 / *NA*
>IST922I CURR TOTAL 402 CURR AVAILABLE 402
>IST923I MAX TOTAL 402 MAX USED 5
>IST989I EXP LIMIT 32676 BUFFS REQUESTED 0
>IST924I -------------------------------------------------------------
>IST920I BS00 BUFF SIZE 260 EXP INCREMENT 14
>IST921I TIMES EXP 0 EXP/CONT THRESH 14 / *NA*
>IST922I CURR TOTAL 28 CURR AVAILABLE 28
>IST923I MAX TOTAL 28 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I LP00 BUFF SIZE 2032 EXP INCREMENT 2
>IST921I TIMES EXP 0 EXP/CONT THRESH 1 / *NA*
>IST922I CURR TOTAL 64 CURR AVAILABLE 62
>IST923I MAX TOTAL 64 MAX USED 3
>IST924I -------------------------------------------------------------
>IST920I XD00 BUFF SIZE 697 EXP INCREMENT 10
>IST921I TIMES EXP 0 EXP/CONT THRESH 4 / *NA*
>IST922I CURR TOTAL 60 CURR AVAILABLE 60
>IST923I MAX TOTAL 60 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I LF00 BUFF SIZE 120 EXP INCREMENT 30
>IST921I TIMES EXP 0 EXP/CONT THRESH 1 / *NA*
>IST922I CURR TOTAL 120 CURR AVAILABLE 116
>IST923I MAX TOTAL 120 MAX USED 4
>IST924I -------------------------------------------------------------
>IST920I CRPL BUFF SIZE 144 EXP INCREMENT 25
>IST921I TIMES EXP 0 EXP/CONT THRESH 16 / *NA*
>IST922I CURR TOTAL 225 CURR AVAILABLE 224
>IST923I MAX TOTAL 225 MAX USED 2
>IST924I -------------------------------------------------------------
>IST920I SF00 BUFF SIZE 112 EXP INCREMENT 32
>IST921I TIMES EXP 0 EXP/CONT THRESH 1 / *NA*
>IST922I CURR TOTAL 192 CURR AVAILABLE 190
>IST923I MAX TOTAL 192 MAX USED 2
>IST924I -------------------------------------------------------------
>IST920I SP00 BUFF SIZE 176 EXP INCREMENT 21
>IST921I TIMES EXP 0 EXP/CONT THRESH 1 / *NA*
>IST922I CURR TOTAL 21 CURR AVAILABLE 21
>IST923I MAX TOTAL 21 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I AP00 BUFF SIZE 56 EXP INCREMENT 56
>IST921I TIMES EXP 0 EXP/CONT THRESH 3 / *NA*
>IST922I CURR TOTAL 56 CURR AVAILABLE 56
>IST923I MAX TOTAL 56 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I TI00 BUFF SIZE 632 EXP INCREMENT 60
>IST921I TIMES EXP 0 EXP/CONT THRESH 120 / *NA*
>IST922I CURR TOTAL 360 CURR AVAILABLE 360
>IST923I MAX TOTAL 360 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I T100 BUFF SIZE 1004 EXP INCREMENT 32
>IST921I TIMES EXP 0 EXP/CONT THRESH 15 / *NA*
>IST922I CURR TOTAL 16 CURR AVAILABLE 16
>IST923I MAX TOTAL 16 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I T200 BUFF SIZE 2028 EXP INCREMENT 32
>IST921I TIMES EXP 0 EXP/CONT THRESH 7 / *NA*
>IST922I CURR TOTAL 8 CURR AVAILABLE 8
>IST923I MAX TOTAL 8 MAX USED 0
>IST924I -------------------------------------------------------------
>IST920I CRA4 BUFF SIZE 4080 EXP INCREMENT 10
>IST921I TIMES EXP 0 EXP/CONT THRESH 20 / *NA*
>IST922I CURR TOTAL 50 CURR AVAILABLE 47
>IST923I MAX TOTAL 50 MAX USED 3
>IST924I -------------------------------------------------------------
>IST920I CRA8 BUFF SIZE 8176 EXP INCREMENT 6
>IST921I TIMES EXP 0 EXP/CONT THRESH 2 / *NA*
>IST922I CURR TOTAL 12 CURR AVAILABLE 12
>IST923I MAX TOTAL 12 MAX USED 0
>IST924I -------------------------------------------------------------
>IST449I CSALIMIT = 21787K, CURRENT = 5742K, MAXIMUM = 5742K
>IST790I MAXIMUM CSA USED = 5742K
>IST1667I SYSTEM CSA LIMIT = 24208K
>IST1831I 42% OF SYSTEM CSA STORAGE REMAINING = 10337K
>IST449I CSA24 LIMIT = NOLIMIT, CURRENT = 63K, MAXIMUM = 63K
>IST790I MAXIMUM CSA24 USED = 63K
>IST595I IRNLIMIT = NOLIMIT, CURRENT = 0K, MAXIMUM = 0K
>IST981I VTAM PRIVATE: CURRENT = 837K, MAXIMUM USED = 1043K
>
>
>Here the display of the PU! In the second system:
>
>D NET,ID=SWPU02,E
>IST097I DISPLAY ACCEPTED
>IST075I NAME = SWPU02, TYPE = PU_T2.1 295
>IST486I STATUS= ACTIV--L--, DESIRED STATE= ACTIV
>IST1043I CP NAME = XSC1, CP NETID = LLLNET1, DYNAMIC LU = YES
>IST1589I XNETALS = YES
>IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS
>IST1106I SWPU02 AC/R 21 YES 98800000000000000000014C00808080
>IST1482I HPR = NONE - OVERRIDE = N/A - CONNECTION = NO
>IST956I PU SAP= 4 MAC=40000E060080 MAXDATA= 1498
>IST136I SWITCHED SNA MAJOR NODE = SWAPPN
>IST081I LINE NAME = XGEL00, LINE GROUP = XGE40E, MAJNOD = XCAE40E
>IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
>IST1500I STATE TRACE = OFF
>IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
>IST1657I MAJOR NODE VTAMTOPO = REPORT
>IST355I LOGICAL UNITS:
>IST080I A01TSO02 ACT/S----Y XSC1 ACT/S----Y
>IST314I END
>
>
>The connection is not dropped after the "hung", I cancel the user P390A,
logon again, the same results.
>
>Thank you again!
>Norbert.
>
>
>> Norbert
>>
>> Note that from the time of support for MPC CTC in devices such as the
2216,
>> the term AHHC was formally changed to ANNC, that is, "host to host"
>> became "node to node" for obvious reasons.
>>
>> Have you defined both your APPN nodes as Network Nodes? The simplest
>> configuration is to have one Network Node and one End Node.[1]
>>
>> You had better define "hung". As far as I can see everything "works". It is
just
>> that when using LSA (3172 SNA channel protocol) Ethernet adapters using
>> OSA features, which I know about, or these 7060 "internal cards" which I
do
>> not, and a type 2.1 connection as opposed to a subarea connection, you
>> have a performance problem or some sort shortly after the SNA session is
>> established, specifically a TSO session.
>>
>> As - I think - you have managed to work out, the MAXDATA operand of the
>> PU statement representing the adjacent link stations is irrelevant with type
>> 2.1 node connection definitions. This is because a type 2.1 node obtains
the
>> value of the size of the maximum "basic transmission unit" (BTU) which can
be
>> *sent* - which is what MAXDATA, in the absence of other information,
>> defines - from the adjacent node which supplies the size of the
>> maximum "basic transmission unit" (BTU) which can be *received* using
>> the "exchange identification" (XID) message.
>>
>> Note that there never has been nor never will be an entity which can
logically
>> be described as a "PU 2.1", there is a node type 2.1, a node type 2(.0)
and a
>> PU type 2. A node type 2(.0) *will* contain a PU type 2 and a node type
2.1
>> *can* contain a PU type 2 - but it may not.[2]
>>
>> I think you may have misreported the 1498 number. 1500 is the maximum
size
>> of a frame on an old-fashioned Ethernet LAN. You now need to introduce
the
>> 802.2 connection-oriented headers. These take up 4 bytes, two for SAP
and 2
>> for control. I think your number should be 1496.
>>
>> Incidentally, I am always for keeping discussions "on the list". That way
>> someone with a similar problem searching the archives can find his/her
solution
>> without having to rely on responses from active subscribers on the list -
who
>> may be taking a well-earned rest over a weekend!
>>
>> The two sets of XCA definitions shouldn't be too large. We need only one
LU
>> statement and associated operands in case you have coded many. If
anyone
>> following this can think of other needed definitions, he/she can request
them.
>> After all, time is not critical since what you want does work - eventually,
>> as
>> far as I can tell.
>>
>> You had also better describe more precisely the sequence of the
appearance
>> of messages and an estimate of the delays.
>>
>> In case this is problem with VTAM buffers, you can post the D NET,BFRUSE
>> output before and after your TSO logon attempt on both systems. Note
that
>> only type 2.1 connections using switched procedures - which uniquely
>> distinguishes your problem case(s) from the others - use the XDBUF buffer
>> pool.
>>
>> Chris Mason
>>
>> [1] In a sense, simpler still would have been to define two Low Entry
>> Networking (LEN) nodes which wouldn't require you to have enabled APPN in
>> your VTAM definitions at all. However you would then need to create hand-
>> coded directory entries in the shape of LEN-style CDRSCs - and - forcing
me
>> to convert this comment to a footnote when I remembered! - you couldn't
>> start a session which required to be initiated by the secondary logical unit
>> (LU), which would include a TSO logon!
>>
>> [2] Since you are a German-speaker I assume I could state these rules
as "A
>> node type 2(.0) *muss* contain a PU type 2 and a node type 2.1 *muss
>> nicht* contain a PU type 2." but then I'd confuse all the non-German
>> speakers! Some years ago I took over as an instructor in an education
centre
>> from a colleague who had German as his mother-tongue. Listening to one of
>> his lectures I caught him saying "must not" when he meant "need not" in
>> connection with some VTAM statement coding. Who knows what confusion
he
>> must have sowed in his previous three years of lecturing?
>>
>> On Sat, 25 Apr 2009 01:58:34 +0200, Norbert Alfred Müller
>> <[email protected]> wrote:
>>
>> >Hi all!
>> >I hope this is a trivial question for the SNA gurus :-)
>> >I have two nodes with z/OS ( 1.5, ADCD) , NN, linked with MPC CTC, TRL,
>> and so on. Very Easy, I access from the system B to TSO in system A,
>> everything is Ok.
>> >When I make the same with XCA ( Ethernet ) and Sw Major Node, The
>> Logon form TSO "hung" after 2 o 3 RACF and TSO Messages, before the
whole
>> screen comes... I have a deja vu with this MAXDATA and buffers
problems...
>> This ocurrs always , no matter that I use a 7060 with internal cards or a
z/9
>> with OSA. So,APPN with CTC ok, with LLC not ok. But, in the SAME
system, I
>> activate Subarea connection, ( so, interchange node ) with XCA, LLC but
>> FID4, no MPC CTC, and it works !.
>> >Resumee: the sames MVS, the same applications, but: AHHC Conection
OK,
>> XCA APPN not OK, XCA with Subarea OK. What's happen ? I revised the
PU'S
>> many times.
>> >MAxdata can be coded in the Pu 2.1 but is ignored. It shows 1498.
>> >I will not disturb the list with the configurations, but perhaps a guru
>> >have
a
>> Idea or can contact me out the list ?
>> >Thank you very much !
>> >Norbert.
----------------------------------------------------------------------
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
