Mike Your "guess" would be entirely incorrect as a general principle and nearly always incorrect in particular cases. There can be cases of one product showing how to interface with another product over a formal interface but rarely. The one that comes to mind is how RACF is always mentioned in many z/OS product documents when, strictly, they should address themselves to the "SAF product".
Note that "formal interface" covers networking protocols, such as IP and its related protocols as well as SNA, as well as application programming interfaces. If both proposed communication partner products support a particular set of protocols, you just need to understand the protocols in order successfully to configure the products based on the documentation specific to each product. What you are asking is very much the territory which redbooks inhabit. Note that DLSw, possibly run on products supported by Cisco but possibly not, is a "fiddle" imposed on top of other protocols at the data link control layer. If there were protocol suites other than SNA using 802.2 LANs and SDLC at the data link control level, DLSw wouldn't care that the higher level protocol suites were other than SNA. Of course such a fine distinction would not trouble redbook projects which concentrate on what customers actually do. However, it is important to recognise the existence of protocol boundaries - and just as much when working with protocols in the IP arena as the SNA arena. Having said all of that, I recall the immense gratitude shown to some systems engineer who put together a sort of "white paper" entitled "Multiplatform APPC Configuration Guide". Checking I see that it did get taken up as a redbook: http://www.redbooks.ibm.com/abstracts/gg244485.html Note I am showing this only as a comment on your assertion about documentation rather than recommending it for the project with which you have been lumbered. In case the solution you eventually adopt involves the use of Enterprise Extender, there is a redbook which shares some of the characteristics of that old "multiplatform guide": Enterprise Extender Implementation Guide http://www.redbooks.ibm.com/abstracts/SG247359.html > ... how to connect the CS as an APPN node ... Since we are providing redbook references, you should be aware that enabling APPN is *not* a trivial process. You will need the following two redbooks - even if you actually get some education: Subarea to APPN Migration: VTAM and APPN Implementation http://www.redbooks.ibm.com/abstracts/sg244656.html Subarea to APPN Migration: HPR and DLUR Implementation http://www.redbooks.ibm.com/abstracts/sg245204.html Note that it is *not* required that your VTAM is enabled for APPN in order to communicate over SDLC or 802.2 LAN with Communications Server for Windows or any other of these "distributed" platform products. If they support APPN, they will also support "Low Entry Networking" (LEN) and LEN is supported by a VTAM not enabled for APPN. > ... better yet, how I could continue to use the DLSW\CISCO connectivity already there. It is arguable whether it is "better" to continue to use DLSw when you do not need to do so. You can always continue to use DLSw when the communicating partners are duped into imagining that they are using 802.2 LAN or SDLC - whether or not using DLSw - as their data link control protocol. DLSw is even clever enough to mimic SDLC at one side of the IP network and 802.2 LAN at the other. It's an underlying feature of DLSw that it is based on Token Ring architecture so that the, typically, "left", "middle" and "right" components of the communication path pretend to be Token Ring segments. Chris Mason On Tue, 7 Jul 2009 14:25:01 -0500, Ward, Mike S <[email protected]> wrote: >The communications server is an IBM product so I would have guessed that >on the z/os side a guide would show me how to connect the CS as an APPN >node or better yet, how I could continue to use the DLSW\CISCO >connectivity already there. It's not an issue as much as it's what >should I do first and how. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Hal Merritt >Sent: Tuesday, July 07, 2009 1:32 PM >To: [email protected] >Subject: Re: Communications Server > >Sounds like you have Windows issues, not z/os. Also sounds like you also >have some serious political issues in insisting on spending a lot of >money just so you can use Windows servers. Not too sure we can be of >much help. > >Doesn't make much business or technical sense when everything you need >is available for free. > >Anyway, the doc you will be needing would be furnished with the Windows >Communications Server V6 product and not any IBM site. That would >include any and all VTAM or TCP/IP configuration options needed to make >their product work. > >HTH and good luck (you are going to need it). > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Ward, Mike S >Sent: Tuesday, July 07, 2009 12:52 PM >To: [email protected] >Subject: Communications Server > >Hello all, I have been tasked to move our old sna\sdlc communications >controllers to a Windows communications server environment. We currently >have z\os V1.7 with VTAM and TCP\IP. We will be getting Windows >Communications Server V6 for the windows server that will take the place >of the old LU0 controllers at remote locations. I'm not sure where to >start in setting up communications from our VTAM environment to this >Windows environment. We currently use DLSW and Cisco routers to do the >sna/polling of the old controllers. Are there any books red or otherwise >that can help me with this? I have searched the IBM site for Windows >Communications server and LANDP, but I mostly get z/os communications >server books there. Any help will be appreciated. Thank you in advance. ---------------------------------------------------------------------- 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
