Pat, Well, you have a point regarding the baggage that the ACTPU[1] may carry. So you're right that you should check any proposed candidate in order to be sure it isn't just a "fix" for the benefit of "external" DLUR, for example, managing the adjacent link station.
[1] I think the DACTPU - hitherto - is baggage-free. Let us look at the three operands I identified. a. The F/NF value in the second suboperand of the DISCNT parameter This is an indicator which - according to the VTAM description[2] - is for consideration by the remote node. In architectural terms, it is for the PU to pass to the PUCP of the remote node - as an internal signal as the developers with an eye to architecture would say - to initiate "discontact" of the adjacent link station. Whether the type 2 PU bothers or not is an implementation option. However I think it's fair to say that the F/NF indicator does involve the architectural PU. [2] <quote> If you code F or use the default, "final-use" status is indicated and the connection can be ended. If you code NF, "not-final-use" status is indicated and the connection should not be ended. Each device has its own requirements regarding "final-use" status. To determine whether to code F or NF for a given device, consult the appropriate installation publication for the device. </quote> Of course, it has come to our notice that one implementation of the boundary function for nodes which can support type 2 PUs *may* (I have not found any formal documentation for this) pick up the "final-use" indicator and act on it. This is SNASw. b. The LUGROUP operand This causes the PU to learn that whatever local means to support SSCP-dependent LUs exist on activation should be signaled to the SSCP and that a local configuration change involving the addition of the means to support an SSCP-dependent LU should also be signaled to the SSCP. Again by means of internal processes, the PU learns that an "LU"[3] is available or becomes available to the node and it sends an NMVT which provides a range of parameters, including the machine type, to the SSCP over the SSCP-PU session. VTAM takes this information and drives the ISTEXCSD exit. The standard supplied, and apparently supported, exit uses the machine type to map to a model LU statement. [3] For example, for a 3174, this can be a coax connector to a display device in one of the coax ports. Again I think it's fair to say that the LUGROUP operand involves the architectural PU. c. The INCLUD0E operand This operand has been introduced since I had extensive testing and tracing facilities to hand so I have to rely on documentation for how it works. This is what "SNA Formats" says happens when YES is specified: <quote> 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. </quote> Thus it seems it is an instruction carried in the ACTPU to the boundary function requiring it to add the CV to the ACTPU when it is passed on and ACTLU requests as they fly by. This is a network management "thing" and so necessarily involves the PU as the architectural entity responsible for local node management. Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 28 April, 2006 7:23 AM Subject: Re: Need Help defining an AS400 with an IP address to the mainframe > On Thu, 27 Apr 2006 03:35:32 +0200, Chris Mason <[EMAIL PROTECTED]> wrote: > > >... > >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. ... > > A very persuasive argument ... if you accept that an ACTPU/DACTPU has > anything to do with a PU rather than a linkstation, or that the data in > the ACTPU/DACTPU are used by the PU. > > 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
