Hello Chris ! Yes I confirm that I use LU0. There are LOCAL NO SNA terminals, i.e.: Dialed terminals to z/OS guest ( we are under VM). So, I will configure and test with TCPIP. I have the same problem with VSE and VM, but the terminals are also dialed ( local! ). Stay tuned :-) Thank You, 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 > __________________________________________________________________________ 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
