Pat > While true, there isn't much need for it, either.
You're using the wrong tense; try "was" for "is". In the days when AnyNet Sockets over SNA was created, the mid-90s, there was an golden opportunity not to scrap SNA network infrastructure in favour of IP network infrastructure but simply to benefit from IP-based applications and interface to existing IP network infrastructure while preserving all the benefits of maintaining the existing SNA network infrastructure. Sadly the suits were taken in by the bigots and we got lumbered with IP infrastructure with all its myriad disadvantages - sad for all except for the vendors of that infrastructure of course who no doubt congratulated themselves wildly on their successful "hustle". > It's rare to find 2 devices with SNA connectivity that don't have IP connectivity. I used to work in an education centre - as you anyhow know. A new internal application was brought in from the US. It had "training" in the title to which I vociferously objected since I - together with my colleagues - was offering "education"[1] The application was built on an UNIX base and so employed sockets communication. The introduction struggled miserably in its European test sites, my and other education centres being the client sites with a server site near the Black Forest. The reason was that the production networks at the time were (still) built on SNA infrastructure while IP infrastructure had very limited bandwidth. Fortunately a guy in the in the introducing team remembered I had mentioned running sockets programs over SNA in a meeting a short while before. So I was obliged to come to the rescue of this demeaning system with AnyNet Sockets over SNA access nodes and gateways, sacrificing my and a "Freundins" 2217s[2] to the cause. Eventually the IP infrastructure was upgraded and the "purity" of the application was restored. > AnyNet SNA over IP ... made an appl-to-appl connection. EE makes an APPN node-to-node connection. Pat, there's a hole in your education! AnyNet SNA over IP constituted a Low Entry Networking (LEN) link just like any other LEN link, SDLC, frame relay, X.25, 802.2 LAN etc. The only difference is that you couldn't set the bits in the XID which offered APPN services - and CP LU to CP LU sessions - in the case of AnyNet SNA over IP. There's a hole in my education which I'm not going to bother to repair - unless some post prompts it (unlikely) - in not knowing about TCP62 or any other of the "etc." which are/were not strict MPTN AnyNet SNA over TCP/UDP/IP. AnyNet over IP implementing a LEN link is then strictly replaced by Enterprise Extender (EE) implementing an APPN/HPR link. AnyNet over IP cannot be enhanced to be an APPN/HPR link and EE cannot be downgraded to be a LEN link. That's the difference. > ... there is more to setting up the connection if the nodes are not already APPN nodes. Indeed, this is where I usually say something like "and, by the way, you need to ensure that your VTAM is enabled for APPN if not already done which is typically not a trivial task." Setting up LEN links with a traditional subarea VTAM also needed a few novel concepts to be taken on board, the "same- domain" CDRSC being one. > And, of course, the EE connection can automatically handle any other SNA sessions you care to add once you have it in place. may apply to "implementations" such as TCP62 but not in comparison with fully developed AnyNet SNA over IP. > Wasn't TCP62 just the name of the non-VTAM AnyNet SNA over IP LU6.2 component? Dunno - although GC34-6889-00 does imply that. The manual seems just to discuss LU type 6.2 so I guess that LU type 6.2 was all that TCP62 could handle - which is fine if that was the mission the product was given. > The manual may have been terrible, ... It may be that the manuals which describe TCP62 by itself do their job very well. It is only this ridiculous "migration" manual created in order to deal with the demise of AnyNet SNA over IP in VTAM to which I object. It pretends that Enterprise Extender is the solution when, as soon as you bother to digest what the manual actually covers, you see that the function supplied by TCP62 is replaced by a concatenation of "Remote API Client" over IP and an SNA link to VTAM - of any type whatsoever. The "middle" box is shown as running "Communications Server for Linux on zSeries" but it could be any non- VTAM Communications Server.[3] > Was anything other than than LU6.2 support implemented using AnyNet SNA over IP? SSCP-dependent LUs of any type were also supported - eventually. And this was a significant exception to the rule that the DLUR-DLUS "pipe" sessions had to pass over a concatenation of links all capable of supporting APPN flows with CP LU to CP LU connectivity existing between the DLUR and DLUS nodes. Reflect on the text of sense code 0877 0056 <quote> Sense code 0877 Resource mismatch: The receiver of a request has detected a mismatch between two of the following: (1) its definition of an affected resource, (2) the actual configuration, and (3) the definition of the resource as implied in the request. Bytes 2 and 3 following the sense code contain sense-code-specific information. 0056 A CPSVRMGR session cannot be established over a LEN connection that is not of type TCP. </quote> > I know PComm supported AnyNet as a "protocol", but I thought it used APPC3270. I'm pretty sure PCOMM used fully fledged AnyNet SNA over IP. I seem to recall that PCOMM/2 absorbed parts of CM/2 which related to an "end-user" rather than an SNA "router" and that will have included the AnyNet SNA over IP "access" - as opposed to "gateway" - component. These recollections all date from the time of the CM/2 to CS/2 redesign of the mid-90s. Here's what I found in "Personal Communications for Windows, Version 5.7 Administrators Guide and Reference"[4] <quote> The AnyNet function in Personal Communications enables SNA applications to communicate over an IP network. This includes the Personal Communications emulators, both 3270 and 5250, as well as APPC and CPI-C applications. </quote> However - to my surprise - it appears that APPC3270 is also supported: <quote> APPC3270 Emulation over a TCP/IP Network AnyNet also enables APPC3270 emulation over a TCP/IP network. See Figure 10 on page 116. Configuration instructions for this example are given in Quick Beginnings. </quote> The "also" is important. In "Personal Communications for Windows, Version 5.7 Quick Beginnings" I found no configuration advice regarding APPC3270 but I did find the following as the only reference to APPC3270: <quote> The API client interface lets you make the following attachments: - 3270 emulation LUA - LU 0, 1, 2 or 3 via the WinRUI interface. This lets you have normal display or printer sessions. - APPC3270 This provides 3270 display sessions (not printer) over an LU 6.2 connection to the host. - 5250 emulation This provides 5250 display and printer sessions through APPC. </quote> AnyNet SNA over IP "sits" under the first bullet as a (LEN) link. I'm happy that PCOMM is supporting regular full function AnyNet SNA over IP including, obviously, SSCP-dependent LU support. If you want to know more there are references to other manuals available on that IBM page [4]. Incidentally, it's a shame that all these functions in PCOMM needing a VTAM counterpart have had that VTAM counterpart withdrawn! Lastly, I should, of course, have included PCOMM in the list of products supporting Enterprise Extender - as I discovered electronically leafing through these PCOMM manuals. Chris Mason [1] Even if I did try to remember the precepts of an army instructor regarding "training": First I tells 'em what I'm going to tell 'em, then I tells 'em it, then I tells 'em what I've told 'em! Probably the task was disassembling and reassembling a Lee-Enfield rifle. [2] The 2217 was the "AnyNet" box. [3] This reminds me of a time I was a trainee and a third line manager asked me to draw a flip-chart page for him. I mentioned that, given the nature of the data, it should not be a line graph but a bar chart. After a glance which reminded me of the hierarchy which happened to apply here, I drew a line graph! So I guess I have to sympathise with the authors of GC34-6889-00. [4] http://www-01.ibm.com/software/network/pcomm/library/ On Thu, 25 Jun 2009 16:00:28 -0500, Patrick O'Keefe <patrick.oke...@wamu.net> wrote: >On Thu, 25 Jun 2009 14:53:46 -0500, Chris Mason ><chrisma...@belgacom.net> wrote: > >>... Regrettably there is no replacement for the >>brilliant AnyNet Sockets over SNA function. > >While true, there isn't much need for it, either. It's rare to find 2 >devices with SNA connectivity that don't have IP connectivity. > >>... >>There are a number of platforms where you can install Enterprise >>Extender precisely to replace AnyNet SNA over IP. ... > >It's worth noting a significant difference between the 2 configs. >AnyNet SNA over IP (TCP62, etc.) made an appl-to-appl >connection. EE makes an APPN node-to-node connection. The >application does not care, of course, but there is more to setting >up the connection if the nodes are not already APPN nodes. > >On the other hand, setting up a connection with another node is >trivial once everything in the SNA world is using APPN. And, of >course, the EE connection can automatically handle any other >SNA sessions you care to add once you have it in place > >>... >>Mention of TCP62 raises an alarm. ... > >Wasn't TCP62 just the name of the non-VTAM AnyNet SNA over IP >LU6.2 component? The manual may have been terrible, but the >"client" implementation had to be written to some spec, and TCP62 >was that spec (I assumed). > >Was anything other than than LU6.2 support implemented using >AnyNet SNA over IP? I know PComm supported AnyNet as a >"protocol", but I thought it used APPC3270. (I don't have a clue >what the PComm 5250 AnyNet support used.) > >Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
