Chris: It WORKS ! with TN3270. I use the Logmode SNX32702 ( RUSIZES=X'87F8' ).So, the SLU can send a maximum of 1024 bytes. I can resume:
IF ETHERNET AND APPN AND LU0 ( Local terminal ): The session hang. Any other combination: Subarea, TokenRing, LU2.. works fine. best regards, Norbert. > Norbert > > > MAXDATA is not showed in subarea connections, nor in ANNC. > > Well, I confirmed this by "searching" the SNA Operation and SNA Messages > manuals for "MAXDATA". The MAXDATA value is provided only in message > IST956I which appears only in the output of the DISPLAY NET,ID command for > a named resource representing an adjacent link station in a node presenting a > type 2.1 node appearance over that link where the media is or appears to be > a LAN.[1] > > > My question is: how calculates VTAM the MAXDATA ? > > You must have missed this paragraph from my first response: > > <quote> > > 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. > > </quote> > > So the answer is that VTAM doesn't *calculate* MAXDATA, rather it extracts > the number from the XID frame received from the adjacent type 2.1 node link > station. If you run Wireshark for the time when contact is first made, the > time > of your VARY NET,DIAL command, you will see the value at displacement 21 > (origin 0) for 2 bytes of the XID frame according to the layout given in the > SNA Formats manual.[2] > > The information comes from the logic of whatever represents the adjacent link > station. Originally this was the 3172 channel-attached device. It is replaced > by the OSA feature port in OSE mode and, presumably, the "Emulated I/O from > the 7060". The "adapter" "knows" what the limitations of the media - and, > maybe, the adapter "software" - are and so can provide a suitable value for > the maximum SNA "Basic Transmission Unit" (BTU) which can be received. The > value presented in the XID takes account of the headers - and trailers - > required by the media protocol. Thus, if there is a maximum imposed by the > media, say 1500 for Ethernet, the size of any headers - and trailers - > lying "outside" the SNA headers will be subtracted. > > Note that, in checking on the "MAXDATA" field in the SNA Formats manual, I > managed to remind myself that MAXDATA would not be applicable in the case > of the "multi-path channel" (MPC) definitions since MPC uses a different XID > format. > > Now the question is can the value sent by the "adapter software" be changed. > In the case of the OSA feature, there is a tempting SET PARAMETERS OSA/SF > command. However there is no explanation of what parameters may be > available and I suspect it is mainly there for ATM use. > > Something else interesting appeared when Googling on IST956I in order to see > if anything could be found anywhere regarding the "MAXDATA" value when the > media was Ethernet. APAR OW49531 indicated that - up to 2001 - the > MAXDATA value in message IST956I was incorrect. But - what did I say? - it > is supposed to take the defined MAXDATA value, compare it to > the "MAXDATA" value received in the XID from the adjacent node and use the > lesser value. > > <quote> > > VTAM compares the XID3MBTU value, received at XID exchange to the > current MAXDATA value. VTAM then sets the MAXDATA for this device to the > lesser of the two values. > > </quote> > > Incidentally, what I was trying to explain about my worries over your 1498 > value is also explained in the description of the APAR you mentioned, OA02722 > for z/OS from 2003: > > <quote> > > Too many bytes sent over ETHERNET XCA connection. At connection time, > the device indicated the max allowed LPDU size was 1500 bytes. For > ETHERNET, the LPDU includes 1-byte DSAP, 1-byte SSAP and 1- or 2-bytes > Control Field - > in addition to the Information Field (TH/RH/RU). VTAM is not accounting for > additional 3-4 bytes when sending data. > > </quote> > > Interestingly enough, the effect is to cause a disconnection rather than a > session "hang". > > However, since APING works with a request unit size of 1920, implying a BTU > size of 1929 which is larger than 1498, this "MAXDATA" issue would appear not > be the problem. > > I'm glad you have such a range of possible configurations at your disposal > but > I'm getting rather confused about some of them. I can explain neither the > 1498 nor the 1516. All I can say is that they are in the neighbourhood of > 1500 > but, if the old Ethernet limit of 1500 is supposed to apply, the values > should > always be less rather than greater. If there is some "emulation" going on - > and > traffic does not actually pass over Ethernet media - then the 1500 limit may > not apply but rather some parameter defined with the "emulation" logic. > > Since you have also tried Token Ring, I am reminded that there is in this > case > a header used to deal with bridges which contains a code defining a maximum > frame size. > > But, as I said, we should look for another reason for the "hang" and traces > are > going to be needed. And when you do trace you can look for the "MAXDATA" > field in the XID exchanges. > > Could you confirm that the secondary end of the TSO session is defined with a > LOCAL statement? If so, that would indicate an LU type 0 session. This is > somewhat different from the APING test session which is necessarily LU type > 6.2. This may matter. > > It might be interesting to try an LU type 2 session to TSO. That you could > contrive by using TN3270 - assuming you have a TN3270 server available on > the secondary side, possibly the Communications Server IP TN3270 server. If > you can manage to use a TN3270E-capable client, you will, by default, be > using a mode table entry which uses LU type 2. > > Finally I recall you said you were deliberately not using HPR because of the > eventual VSE system. I see that VTAM on VSE 4.2 is also - still - 4.2 and has > no HPR support, which explains why you were testing your configurations > without HPR. I needed to check because that's an enhancement that is > looooong overdue! > > Chris Mason > > [1] And again in the SNA Messages manual in reference to an explanation for > failure to load an NCP when using the MODIFY LOAD command. > > [2] "2122 Maximum BTU length that the XID sender can receive:" > > On Mon, 27 Apr 2009 23:58:13 +0200, Norbert Alfred Müller > <[email protected]> wrote: > > >Chris, > > > >There is no Netview installed. Is only two smalls z/OS 1.5 for testing, > >running > under VM. > >MAXDATA is not showed in subarea connections, nor in ANNC. > >I install Token Ring adapters in my IBM 7060. And, of course, works! > >Maxdata was 4442. > >Then, I IPL the system in a 2096. In the z/9, we have of course OSA > Adapters, no > >this Emulated I/O from the 7060. MAXDATA was..1516, not 1498 ! > >And again, the same results as with 1498. Dead. > > > >So, the problem is: > >APPN, only ETHERNET, only Switched connection. > >Subarea, ANNC, Token Ring, works. > > > >I tested also with VM, but I have an old VM VTAM and I have the problem > (solved > >in APAR VM63436) , " PROBLEM DESCRIPTION: XCA connection INOPs when > using Ethernet connection" > >mmm... very similar to our problem in z/OS. Look at : > >http://www-01.ibm.com/support/docview.wss?uid=swg1VM63436 or in the > related z/OS APAR info. > >In VM/VTAM, the session after a fullscreen data does not > >hang, it disconnect with an INOP. I will install the PTF tomorrow. > > > >My question is: how calculates VTAM the MAXDATA ? why this 18 Bytes > difference between the > >7060 and the OSA Adapter ? > >Well, It make no sense playing around the z/OS 1.5 for testing. I will test > >in > the > >operating environment planned: z/OS 1.10 connected with VSE 4.2. And then > will see of the problem > >occurs or is solved ! I keep you informed. > >For me is very important to confirm that the configuration was ok!I guess is > it ? :-) > >Many thanks for your support ! > >Norbert. > > > > > >> Norbert > >> > >> > ... also with 16384. > >> > >> Testing with D NET,APING at sizes larger than 1920 doesn't show us > anything > >> new regarding the *size* of data units since 1920 is the request unit size > >> imposed by the RUSIZES operand of the MODEENT macro used to generate > >> the #INTER mode table entry which is the default and, I assume, the one > you > >> are using. It does, however, show us that sending more than one frame at > a > >> time can be successful. > >> > >> It looks like we need tracing. The cleanest way to "see" session traffic > >> is to > >> use NLDM with the CPIU option but, since you have not responded to my > >> suggestion you use this, I assume you have not installed NetView or, if you > >> have, you have not enabled Session Monitor. > >> > >> You need to trace the traffic when the TSO session hangs so that we can > see > >> the last data sent by TSO that does not get delivered. Wireshark could be > >> handy in showing what flows on the LAN I believe - I have never actually > used > >> it. It may be useful, at the same time to use a VTAM buffer trace so that > we > >> can see whether something that has passed over the VTAM API from TSO > >> actually appears as an Ethernet frame. > >> > >> As a comparison, you could do the same, that is, a VTAM buffer trace and > >> running Wireshark, with D NET,APING,SIZE=1920,ITER=1. (ITER=1 for the > least > >> amount of data to trace.) > >> > >> Wireshark shows all the protocol headers (and trailers) I believe. I will > >> be > >> interested to see how the 802.2 protocol fields are supported with a Basic > >> Transmission Unit size of 1498. > >> > >> Have you had any success with looking for the "MAXDATA" value with other > >> types of "cross-domain" connections? > >> > >> Chris Mason > >> > >> On Mon, 27 Apr 2009 09:59:51 +0200, Norbert Alfred Müller > >> <[email protected]> wrote: > >> > >> >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 > __________________________________________________________________________ Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele ausländische Netze zum gleichen Preis! https://produkte.web.de/webde_sms/sms ---------------------------------------------------------------------- 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
