Pat, Comments are embedded.
Incidentally what is this web interface with which you are having so much trouble? Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 26 April, 2006 5:34 PM Subject: Re: Need Help defining an AS400 with an IP address to the mainframe ... > > This is my 4th attempt to reply to this posting. Please forgive me if one > or more of the previous copies show up. > ... > > If you have a copy of that I'd strongly recommend you hold onto it. > But I even more strongly recommend you let me keep it safe for you. > I haven't seen a copy for about 15 years. I checked my basement to see if this manual was among the horded items and I'm afraid it is not. The oldest I found was "SNA Environment - Logical Data Flow", Modules 1-5, 6, 7, 8 and 9, an independent Study Program from 1977. (Module 9: 3274 and 3276, 1979). But I also found "SNA Technical Overview", GC30-3073-04, January 1994, which might help us with what follows. > The old FAPs and other (redundantly named) SNA Architecture manuals > indeed mention CPs, but those are SSCP, NCP, and (the seldom mentioned) > PUCP. I'm pretty These manuals predated the APPN CP. CP belongs only to an APPN node or a LEN node. In the description of SSCP, there's no mention of CP so I guess we need to keep the understanding that the "CP" in VTAM is an SSCP when it's dealing with subarea matters and a CP when it's dealing with APPN matters - and also keep in mind that a supposedly pure VTAM End Node or Network Node always has a single node subarea "network" inside it ruled by an SSCP. NCP means "Network Control *Program*" so there's not supposed to be any hint in the name NCP that it has "CP" capabilities. Of course an NCP does have the architectural PUCP entity contained within it. The PUCP is interesting. In strict architectural terms, any subarea or peripheral node - that is, a node not tainted by these new-fangled ideas that started with LEN nodes - needs to have either an SSCP or a PUCP. An SSCP is apparently the source of all activations but, logically, it can't be. Who, anthropomorphising, is going to be responsible for activating the link and adjacent link station inside a peripheral node? In architectural terms, it is the PUCP inside the peripheral node. We need never worry about this other than acknowledging that it must - logically - exist. When we come to type 4, NCP, nodes, it becomes a little more interesting. I'm not precisely sure when the PUCP inside the NCP needed to become acknowledged. Clearly the same issue arises that, in order for the first SSCP to be able to activate resources inside the NCP, it must have an active route to the NCP PU and its subordinate resources. This can happen only when the PUCP has activated the link and adjacent link station *towards* the type 5, VTAM, node containing this first SSCP. This activation was assumed for NCP channel resources until channels were defined as GROUP/LINE/PU. It was a requirement to define this activation by means of the MONLINK operand for, initially, SDLC links. With the MONLINK operand came the recognition that the PUCP exists. When the MONLINK operand could specify CONTINUOUS, that is, the PUCP ownership was not given up when an SSCP also activated the link and adjacent link station, it was even important that the status of the PUCP was recognised as being the equal of an SSCP. Thus, if MONLINK=CONTINUOUS somewhere, the BUILD statement MAXSSCP operand needed to take the PUCP into account. Having got that out of the way - based on my lecture notes, I turned to the "SNA Technical Overview" manual. Here the PUCP is given a very lowly role. It is not acknowledged in the Glossary but does appear, as "physical unit control point", in the Index. Looking up where it is mentioned it appears in small print as a footnote in the section on "Hierarchy of Subarea Network Activation" - although it's right there in the middle of each box representing a type 4, NCP, node and, what luck!, tucked away at the bottom of each box representing a type 2.0 peripheral node, where, in the box alongside representing a type 2.1 node, CP appears - which takes us neatly to the next point. > I think the point Chris was making about the PU type is that a PUCP was > never an architected part of a T-2.1 node so any PU emulator running on > a T_2.1 node is, by definition, emulating a T_2.0 PU. Absolutely, there's no need for a PUCP in a type 2.1, LEN or APPN, node since they necessarily have a CP to do all the activation work and, in fact, all the functions that were previously performed by the PU except, of course, having to be activated by an SSCP prior to the SSCP activating the LU resources. What functions might those be? Well, I can only think now of the management function where traffic on sessions rooted in the CP are used to report to focal point CPs. You'll note that, by separating the management function in a type 2.0 node off into a PUCP, you leave the way free for it to be replaced by a CP in a type 2.1 node and yet still have the node support an SSCP-dependent PU and SSCP-dependent LUs without having to change anything. Incidentally, this "SNA Technical Overview" manual is a bit wobbly on the matter of the separation of SSCP and CP in a type 5, VTAM, node. Since you can't put a piece of paper between them I doubt this matters very much. > I'm pretty sure Chris is right, but he unfortunately has a world of > implementations and documentation arrayed against him. (Sort of like > trying stamp out misuse of "USS" as the name of Unix on z/OS.) Every > PU-type parameter I've ever seen allows (and ignores) the meaningless > .0 or .1 qualification. And VTAM displays of PUs show the node type > rather than PU type. When the author is paying attention - and possibly software implementations such as the common code I believe provides APPN etc. support in CS for Windows and CS for AIX when last I played with them (Windows was NT) (maybe CS for Linux as well) - I think you'll find they are sound on architecture such as in this "SNA Technical Overview" manual - and, in the case of programs, on mapping the program objects to architecture. You won't find such diligence in VTAM or NCP. Part of the problem is that architecture has had to catch up with VTAM and NCP developing subarea SNA and then trying to keep subarea, LEN, APPN and HPR balls in the air at the same time. All that earlier discussion over MONLINK and PUCP is, in some ways, an example of this. > This misuse seems to fit, though. Almost every parm on almost every PU > definition has nothing to do with a PUCP. They are almost all parms > for linkstations, not PU. Since almost every other description of a > PU is bogus, why should PY-type be an exception? (I say "almost" > because Chris has almost convinced me that a couple of the VTAM and NCP > parms on a PU definition actual relate to the PU. Almost. I'd check > that if I only had a copy of the FAP.) The only operands that have anything to do with the PUCP and MONLINK and XMONLNK and, the former sits on a LINE statement, for goodness sake! The test over whether a parameter/operand really relates to the PU entity rather than the adjacent link station or to the boundary function or to some function with VTAM is whether it affects a byte or a bit in the ACTPU or the DACTPU. According to this test, the following qualify: a. The F/NF value in the second suboperand of the DISCNT parameter since this causes the value of byte 1 of the DACTPU to be set to a corresponding value. b. Whether the LUGROUP operand is specified or not since, if it is, it causes bit 0 of byte 2 of the X'80', "PU Capabilities", control vector to be set to 1, rather than 0, meaning "Sending node supports unsolicited NMVTs for PSID" which is required for support of the "Dynamic Definition of Dependent LUs" function. c. The value of the INCLUD0E operand maps to bit 1 of byte 2 of the X'80', "PU Capabilities" control vector; YES maps to 1 and NO maps to 0. When this bit is set to 1 it means "Sending node requests the DLUR or NCP boundary function to include Network Name control vectors on ACTPUs and ACTLUs for this PU and its associated LUs" and when 0 "Sending node does not ...". The name of this operand can be expanded to "include control vector X'0E', 'Network Name'". Oh horror! In checking this last item I found the following in the description of the ACTPU request in the "SNA Formats" manual: "PU T2.0|2.1" in the text alongside the X'0E' control vector. The gangrene is spreading into the vital organs! PU T2.0 does actually appear in two other places in the "SNA Formats" manual. PU 2 is mentioned in very many places and one of the places where PU T2.0 appears, note 8 at the bottom of section 6.1, "Introduction to Request Units", is actually to explain that it may as well be PU T2. I suspect that PU T2.0 is mentioned because of the earlier rule that a node always has a PU of the same type. Thus when the type 2 node became the type 2.0 node, the architects felt that they were obliged, very, very strictly - as opposed to only very strictly :-) - to call the PU a type 2.0 PU quite unnecessarily really since it requires that explanatory note in section 6.1. The poor deluded author who wrote up the explanation for control vector X'0E' in the ACTPU description didn't pay attention to that note and so specified "PU T2.0|2.1" in place of simply "PU T2". This reminds me of another instance where the designers got it right but when it came to writing it up a mess was made. It should be well known - but generally isn't - that the CP is a perfectly good LU and can be used for business sessions as well as "protocol" traffic; it's just a matter of which mode name in use. Unfortunately APPN (and LEN) architecture documents describe the CP and LU as separate communicating entities and have to make a fuss about saying what I just said, namely that the CP may be used as an LU. How much easier to say that there is only one communicating entity, namely the LU, and that the CP entity communicates using an LU with the same name. > Pat O'Keefe ---------------------------------------------------------------------- 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
