Pat Yes, I suspected that this peculiar TCP62 implementation could have distorted your vision of AnyNet SNA over IP.
It would appear that TCP62 behaves as a LEN node with just one single logical link end-point implemented as the TCP (and UDP) sockets program following AnyNet SNA over IP protocols. Being a LEN node it identifies itself with a Control Point name in the logical XID exchanges. Thereafter, SSCP- independent LUs can communicate with SSCP-independent LUs in the partner node following the usual LEN rules that, from the perspective of the LEN node, the partner LU "resides" in an adjacent node and, since there can only be one link to the adjacent node, there is no question of having to select a path over which to send the BIND request to start the session. SSCP-dependent LU sessions get to be supported - exceptionally - using DLUR/DLUS "pipes". However TCP62 will not have been extended to support SSCP-independent LU sessions since I expect LU type 6.2 was all it ever needed to support. It's because LEN just "does" SSCP-independent LU sessions and because the SNA link actually is program-to-program over TCP/UDP/IP[1] that you might assume something like the "trick" of running APPC flows over IP is in operation - which, I believe, is what the "Remote API Client" is all about. In architectural terms, the LEN node contained an PUCP and PU (just like a type 4 node, NCP, or a type 2 peripheral node) which is responsible for managing the activation of links and adjacent link stations. I was reminded of this by noticing one of the pairs of SNA entities over which a CONNOUT request flows in researching for another thread. A PUCP is never "seen" outside its node[2] and, in the case of a LEN node, a PU is never "seen" outside its node.[3] As regards whether an SSCP is around to direct the SNA protocol orchestra, there are "tricks" where an SSCP is architecturally required but can be difficult to find. The old AIX SNA products had a supposedly SSCP-dependent primary LU implementation with nary a regular SSCP in sight. However there must have been a subset of flows officially being managed by a very limited function SSCP somewhere in the product. Chris Mason [1] UDP is there - using the same port as TCP - in case the programs perceive the regular TCP flow as blocked. UDP is then used to try to kick the partner program into life. [2] Well, as Captain Corcoran of Her Majesty's Ship Pinafore was eventually prompted to say in answer to "What, never?", "Hardly ever!". There is a limitation on the coding of the NCP BUILD statement MAXSSCP operand which specifies that the PUCP needs to be taken into account when MONLINK=CONTINUOUS is specified on any subarea adjacent link station definition. [3] In principle this applies to APPN nodes also and could be used to argue that, just because a LEN or APPN node does not have a "visible" PU, it still has a PU and that the PU could be used to characterise the type 2.1 node! Nobody has ever used that argument to refute my insistence that there is no such animal as a "PU 2.1" and it may be that you are the only person who can see the irony here - or indeed follow what I am talking about! On Fri, 26 Jun 2009 14:42:05 -0500, Patrick O'Keefe <[email protected]> wrote: >Just one small comment on one very small excerpt: > >On Fri, 26 Jun 2009 07:07:15 -0500, Chris Mason ><[email protected]> wrote: > >>... >>Pat, there's a hole in your education! ... > >Chris, >This definitely not the first time you've discovered that! :-) >Nor the first time I've displayed that on this list (and others). > >>... AnyNet SNA over IP constituted a Low Entry Networking (LEN) >>link just like any other LEN link, ... > >Actually, I didn't have any education (or training) on AnyNet. I just >picked up some manuals and started cobbling together something >that would allow a CICS to talk with a TCP62 application on some >remote device. Perhaps if the that remote device had implemented >an SSCP I would have seen beyond the APPL-APPL connection. > >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
