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 > ____________________________________________________________________ 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
