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
