Hi Chris! tests are ongoing , but here some results:
- I read in the manual about MAXDATA in a node 2.1. AND I tested, also. Without results: MAXDATA is always 1498 :-( - D NET,APING, xxxx works with all sizes, also with 16384. - If MAXDATA 1498 is an absolute NO, the question is: how is getting VTAM this size ? from Network definition ? or is the size correct and the display no ? What do you thing about a trace with wireshark ? Regards, Norbert. > Von: "Chris Mason" <[email protected]> > Gesendet: 26.04.09 13:34:02 > An: [email protected] > Betreff: Re: APPN Connection z/os - AHHC / LLC2. > 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 > ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 ---------------------------------------------------------------------- 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
