Chris, Your assessment is correct. We have private mode tables built without the correct COS parameters. We will go through the process of cleaning up our old definitions and add the proper COS definition so we don't rely on the default APPNCOS start option per your suggestion. Thanks for the advice.
Regards, John Au -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Mason Sent: Tuesday, June 09, 2009 12:33 PM To: [email protected] Subject: Re: CL/Supersession and APPN John I'm glad you've got over the problem. > It might be best if each specific problem is presented, sense codes and all. is what I said last time. I am very well aware of the problem which is solved by specifying a value for the APPNCOS start option. Why? Because I had to solve the identical problem myself a few months ago - actually - and you may find some encouragement in this - the *only* problem that I had to solve in the migration. Incidentally, the product just happened to be NetView FTP trying to set up a session with another NetView FTP with the problem showing itself when there was an attempt to set up a file transfer. The reason you - for now - solved your problem by specifying the APPNCOS start option is that you - or some predecessor - had a "rush of blood" perhaps long ago and actually set up a private mode table entry with a subarea COS name - having first, of course, set up a subarea COS table and stored it in VTAMLIB. If one's assessment of a customer site is that they are unlikely to have been sufficiently adventurous to establish COS entries - as it was in my case having seen some private mode table entries which lacked COS operands - it doesn't seem necessary to worry about the APPNCOS start option. Another excuse not to have changed the APPNCOS start option value from NONE, the default, to something like #CONNECT, is to leave a trap for just the problem about which we would have read had you actually described your problem in detail. Having detected such a problem the change to the private mode table entry could then be made in order to ensure that an APPNCOS operand was added which had the same significance as the existing subarea COS operand. I could guess that the subarea COS operand that caused your problem mapped to a virtual route number which you - or your predecessor - intended always to be used for interactive traffic - I'm relying here on the fact that the application was Supersession - and also to a transmission priority of 2, the highest of the subarea transmission priorities. All that being so, I would advise that you locate the offending private mode table entry in the source of the private mode table - wherever it is! - add an appropriate APPNCOS operand such as #INTER, assemble and linkage edit the table overriding the existing mode table in your VTAMLIB. You can then reset the APPNCOS start option to NONE ready for the next similar problem - with which you now know how to deal. Let's see if I can reconstruct the problem you were having - and what you should have presented as your problem. If I remember correctly, we first had to track down a log of the VTAM where the problem in the NetView FTP was manifest and check messages at the appropriate time. There was one of those message sequences where the SSCPs tried in the subarea serial search are listed with the sense code returned from each. One of the SSCPs, a pseudo-SSCP, was ISTAPNCP which indicates the point at which the search entered the APPN part of the network at that particular VTAM node. The sense code returned was 80140002, essentially, "APPN COS not found". This was caused because there was a(n unexpected) subarea COS specified as COS=WHATEVER on the MODEENT macro for the mode table entry used by NetView FTP. Since there was no APPNCOS operand specified on the MODEENT macro for this mode table entry, VTAM obliges itself to assume that the name to use for the APPNCOS operand is the same as the name used for the COS operand.[1] Since there is no APPN COS table entry WHATEVER, VTAM is about to give up when it remembers there is one last chance, namely the name specified in the APPNCOS start option put there as what in English schoolboy cricket is the "long stop" fielding position for when the wicket keeper makes a mess of things - he might be excused as a very fine "third man" if the title "long stop" was considered too undignified! Seriously, the APPNCOS start option is obviously a very crude tool to employ in order to select a route and set transmission priority since there is no distinction between different types of session with different requirements. I have already indicated that you probably would want to use #INTER for sessions involving Supersession. If you also had had the same problem that I did with NetView FTP, I would then have advised you to specify #BATCH as the value of the APPNCOS operand - horses for courses - what's sauce for the goose is not necessarily sauce for the gander ... Checking now with the description of the APPNCOS start option, I see that the manual authors also warn against relying on this start option: <quote> If a requested Class of Service cannot be found, the value you specify in APPNCOS is substituted for it, and there is a possibility that the characteristics of the substitute Class of Service are not the ones you intended for the route. For example, a secure Class of Service might have been intended, but the substitution provided in APPNCOS might offer a Class of Service that uses unsecured links. </quote> The example I would have used would be the following: For example, a secure high transmission priority might have been intended, but the substitution provided in APPNCOS might offer a low transmission priority so that the performance of interactive traffic is destroyed by batch traffic. Thanks anyhow for letting us know - in a roundabout way - what your problem was and that it can now be solved. That so infrequently happens with the problems with which I try to assist. Chris Mason [1] Extracted from the Communications Server SNA Network Implementation Guide > Chapter 13. Network routing > Network routing and resource location for APPN nodes > APPN Class of Service > What is the APPN Class of Service default in a user-coded logon mode table? <quote> If the APPNCOS operand is not coded on the MODEENT macroinstruction, VTAM checks the COS operand value. - If the COS operand value is coded, VTAM checks for an APPNCOS definition by the same name as the COS name. If VTAM does not find an APPNCOS definition by the same name as the COS, it fails the session request, unless the APPNCOS start option is defined with a substitute APPN Class of Service name. - If the COS operand is not coded, VTAM defaults APPNCOS to #CONNECT, regardless of the setting for the APPNCOS start option. </quote> On Tue, 9 Jun 2009 11:56:11 -0500, John Au <[email protected]> wrote: >PAT, > >We included a default COS definition in our startup options >(APPNCOS=#CONNECT) and now everything is working great! The information >you provided was very helpful. Thanks a million. > >Regards, > >John Au ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
