Martin > I did find notes indicating MTU size can affect performance when messages have to be fragmented.
If it's SNA, MTU has nothing to do with it - and neither does "fragmenting". The approximately equivalent mechanisms to IP "fragmenting" is SNA "segmenting". I guess you found this in connection with the use of an IP network with Enterprise Extender. - Very often 087D0001 is, in effect, a "summary" sense code, showing that a number of possible destinations were tried and all failed - with other sense codes - but the attempts to find a route continued to the end of the list of SSCPs. It may be that there is, for example, in a network supposedly converted to APPN, still some traces of subarea definitions including an adjacent SSCP table. VTAM will faithfully try each of the entries as listed, giving up on each one because the requisite CDRM-CDRM session is not in place and report an 087D0001 when the "retrying" process is complete. There may well be a "jump into APPN" at some point in the scan of the logical adjacent SSCPs, indicated by the pseudo-SSCP ISTAPNCP. In a configuration which has supposedly been completely converted to APPN, this is the only one which matters. Thus it is very probably that the sense code which matters is 80140002 and 087D0001 is a complete "red herring"! If this is the case, I recommend performing the final "clean up" stage in "migrating to APPN" which is to flush out the remaining subarea definitions from the system starting with converting the SACONNS start option from the default YES to NO[1]. Having performed this "clean up", problem determination of problems such as this one will be much simplified. A hint: when you need to check on any module which needs to be assembled and linkage edited, you must start with what is actually in VTAMLIB and edit it with "hex on" particularly if you were not responsible for the assembling and linkage editing. I made it a rule - probably picked up from the "giants" on whose "shoulders I stood" - always to have an exact correspondence between the source of the mode table or USS table or whatever always stored in VTAMLST - although never loaded by VTAM from VTAMLST, of course - and the object of the mode table or USS table or whatever necessarily stored in VTAMLIB from where, of course, VTAM loads it for use. Now that you are "in charge" of VTAM, in the interests of sanity, you might like to adopt an identical policy, starting with a "reverse engineering" of the content of the modules on which you rely in VTAMLIB. > Has anyone else run into this issue? No - but I have run into this effect as a "problem", namely at the customer with whom I have been working from time to time lately. Finding the source of the mode tables and USS tables was an uncertain process, not least because the responsibility was split between "network system programmers" and "application system programmers". I remember well sitting down with the relevant "application system programmer" and having a "bonfire" of the mode table entries. Interestingly enough, the "bonfire" happened because we had just suffered an 80140002 - when someone tried NetView FTP I think. Also we had suffered it on a system which was still configured as an interchange node, so we had to follow up on the IST895I messages, the list of failing "SSCPs", in the IST663I message group. Fortunately, I was on hand when it happened and I knew that we had to find the log containing the IST663I message group, that the "SSCP" which mattered was - at this point in the "migration" - ISTAPNCP and hence the sense code which mattered was that alongside ISTAPNCP, well, well: 80140002. Another "fortunate" - which also applied in your case, dare I say by neglect rather than deliberate policy? - was that my first revision to the start options removed APPNCOS=#CONNECT which had been specified before as "maybe a good thing" or "because the standard class suggested it". My reasoning was/is that there was no reason why any system should have to compensate for not knowing the APPN COS names in use. That is, if an APPN COS name is specified, all systems should know about it. What was happening in my case, and probably happened in your case, is that - unusually for my customer - there was a *subarea* COS specified and, because of the rules governing the selection of an APPN COS name - and, unlike subarea, an APPN COS name *must* be available - VTAM used the subarea COS name as the required APPN COS name. VTAM then discovered that, actually, there's no APPN COS defined with the same name as the old subarea COS entry, hence 80140002. <quote> Sense code 8014 No path exists to the destination node: Route selection services in the CP has determined from the topology database that no path exists to the destination node. ... 0002 COS name received is not valid. VTAM hint: The most common reasons for this error are: - The requested APPN class-of-service (COS) definition is not found in the COS database at the node issuing this sense code. - The requested mode name for the session does not map to an APPN class of service known by this node. Examine the mode definition to determine the APPN COS name. Verify that this definition exists in a VTAMLST member at the nodes which resolve the mode to an APPN class of service. Activate the member to ensure that the definition is active. If APPN COS substitution has been enabled by specifying the APPNCOS start option, verify that the COS it specifies has been activated. </quote> These "VTAM hints" can be very handy but this one has a gaping hole. There should be another bullet saying the following: - If you are migrating from subarea and you have constructed subarea class- of service with COS names specified in your mode table entries, do be sure that you actually specify the APPNCOS operand in the affected mode table entries. Yea - got the t-shirt! Chris Mason [1] You could always remove the HOSTSA start option in order to cause VTAM to consider the node a "pure" APPN node rather than being an interchange node or a migration data host. Be aware that there is a lot of residual documentation in many parts of the VTAM manuals which the poor lambs of authors failed to update when the SACONNS start option was introduced. Naturally, this erroneous text still swears blind that the only way to shed subarea function is to sunset the HOSTSA start option. On Wed, 7 Oct 2009 08:29:14 -0500, Martin Kline <martin.kl...@yrcw.com> wrote: >We've had a long-standing issue with a particular VTAM logmode not working >across systems. The logmode is ALTMOD45 used by 3270-type LUs with a >primary screen size of 43x80 and alternate of 27x132. This logmode works fine >for TSO and for CA-TPX on each system. However, when the user connects >to system A and tries to access TSO or TPX on system B using this logmode, >they get the SNA sense code of 087D0001, indicating routing was exhausted. >VTAM also issues messages including IST895I with sense code 80140002 >indicating an invalid APPN COS name. > >The same user can use a another logmode, ALTMOD25, with the >same 'INTERACT' class of service, and connect just fine across systems, so >routing and COS are not the issues. I opened a problem with IBM about this. >While they ponder the issue, I thought I'd bring it to the masses, in hope I >will >receive enlightenment. > >The differences between the logmode entries are the primary screen sizes and >the RUSIZES. ALTMOD45 specifies RUSIZES=X'87F8'. ALTMOD25 specifies >RUSIZES=X'87C7'. Just so no one has to look them up, the values correspond >as follows: X'87'= 1024, x'C7' = 1536, and X'F8' = 3840, and the first byte is >the maximum size the SLU can send, and the second byte is the maximum size >the PLU can send. > >So, I changed the RUSIZES on ALTMOD45 to match those on ALTMOD25. That >works. Huh? That's not what the error codes indicated. > >My assumption is that something in the network routing stuff must limit the >maximum RU size. Something important like that is surely documented, right? >Not so. At least not that I found. I checked all of the standard IBM manuals >for Communications Server, and found nothing indicating any relationship >between maximum RU size and some other limiting factor. I did find notes >indicating MTU size can affect performance when messages have to be >fragmented. I infer from that little nugget of information that the network can >handle large messages just fine. > >Has anyone else run into this issue? Can anyone point me to the IBM >documentation that explains this phenomenon? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
