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
