Pat, It's interesting that the "independent study" material I dug out of my basement, dating from 1977, keeps using descriptions such as PU.Tx node, where x is 1, 2, 4 or 5. This seems to show that back in the early days of SNA there was a tight association between the PU type and the node type which, probably only had to be broken when the clever folk who dreamed up LEN and APPN decided to base the new architecture on the type 2 node and the associated transmission header format identifier (FID) 2[1] path information units.
[1] Those reading this who are not died-in-the-wool SNA folk should know that the fact that the node type number is 2 and the FID number is 2 is coincidental since, in essence, both belong to different number ranges running in opposite directions which happen to cross at the number 2. Reflecting on the issue of what is "hardware" and what is "software", I remind myself that there's nothing "real" that cannot become "virtual" by the application of the right "smoke and mirrors". I thought I'd look through whatever documentation I had on this matter of the type 1 PU being housed not in the type 1 node but in the boundary function (only the type 4 node, NCP, boundary function in practice as you said). All I found was my "Subarea SNA Concepts" presentation originally put together in 1985 in order to force-feed SNA into VM folk who were going to have to deal with the then new VM VTAM. However the last change date was 1996 so it could have been modified at any time in over 10 years. It's clear from some of the diagrams and notes that I was firmly of the opinion that the type 1 PU was handled completely within the NCP - and I had to squirm a little to explain why the PUCP and the PU itself were not co-resident in, say, a 3767. <quote> Logically there is a PUCP function in peripheral nodes so that the resources representing the link to the subarea node may be activated. SNA architecture is a little distorted in that a Type 1 node does not contain a PU (the attached subarea node performs PU functions on the node's behalf) but the initial activation of the link to the subarea node is logically required. Perhaps the architectural "bypass" is to postulate that the PU function is transferred to the adjacent subarea node after the link resources become active. The PUCP function in peripheral nodes is not significant for definition purposes. </quote> and later <quote> If the peripheral node were a Type 1 node, the activation request for the PU would not be propagated to the peripheral node. In fact, there are no longer any actual devices marketed today which implement a Type 1 node. The only implementation is in special programming in the NCP ... . </quote> Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 27 April, 2006 9:57 PM Subject: Re: Need Help defining an AS400 with an IP address to the mainframe > On Thu, 27 Apr 2006 18:42:18 +0200, Chris Mason <[EMAIL PROTECTED]> > wrote: > > >... > >... Thus making the description of the node depend upon > >the type of the PU it contains, as is implied by "... it is the PU that > has > >a type designation and that 'type i node' is an alias for 'PU_Ti node'" > >obviously breaks down. In the new world where the "PU" entity is optional, > >the type designation has to go with the "node" entity - and there's no > need > >to drag the type designation of the "PU" entity along with it when the > type > >designation of the "node" entity require sub-designations. > >... > > Actually, I think it never held up. As far as I know a node has always > been hardware and a PU has always bee a program (as described in a FAP > and probably originally desiged using FAPL). The PU never had to match > the node type (although each non-APPN node had a PU based on the node's > capabilities). For example, a PU_T1 never ran in a node T_1, as far as I > know. (I think a PU_T1 was by definition the PU code supporting a device > too dumb to have executable code.) It always ran on something else - > a T_4 (or maybe T_5, but I never heard of that implementation). > > 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
