Neal What do you mean by "we" - "in a previous life" or indeed "Previous lives"?
If, as might be implied, this is the same installation which presumably continued to support applications based on SNA communications, how did the installation manage to use channels for communication and then stop doing so without also stopping running the applications? - and now feels the need to use some sort of technology offering the same capabilities previously provided by channels? I am now relying on your title line for some insight on your problem *not* really reinforced by the content of your post. This implies that the applications running in your LPARs use the VTAM API and need to communicate with each other. Since this is, by definition, VTAM/SNA communication between different VTAMs, necessarily supported each within its own LPAR, it is/has been well known to be described as "cross-domain" in traditional subarea SNA. Thus it may be inferred that the VTAMs support/have supported only the subarea flavour of SNA or possibly do not currently rely upon any communication to other subarea SNA nodes. In general I expect that it is not so well-known that different APPN nodes can also be described as constituting a domain/cross-domain structure in that each APPN node is its own domain. It is a further embellishment of this structure that APPN network nodes in effect incorporate "served" APPN end nodes within the domain of the APPN network node. It can also be inferred that this point is *not* understood when a query concerning VTAM doesn't explain whether the VTAMs under discussion have or have not been enabled for APPN. So we have a very general query about which we can deduce that the communication problem involves communication between VTAM applications - in separate LPARs - *not* involving sysplex facilities and *not* involving pro tem channels where the VTAMs involved may or may not be enabled for APPN, probably the latter. - The customer where I have been working from time to time may be able to shed some light on this problem. In fact, the customer used sysplex facilities but had a number of them. That being so I can rely on what was continuing to be in use when I started and what we did to migrate to, in fact, a pure APPN environment as it concerned the connections *between* LPARs which were members of *different* sysplexes. I didn't pay much attention to what the technology was which supported the active connections which could be displayed when the DISPLAY NET,STATIONS (subarea) command was entered in those LPARs which were supporting subarea communications. I thought it was the same technology as we additionally set up in order to support the connections which are displayed when the DISPLAY NET,CLSTRS (APPN[1]) command was entered in those LPARs which eventually supported APPN communications - finally all of them exclusively. Either way the technology was some sort of fibre which the lady who massaged the "hardware" definitions was able to conjure up to support any pairing of addresses happened to fit our hardware addressing scheme for channel-to-channel connections[2] between the two Central Electronic Complexes (CECs) (separated by a main road) supporting the multitude of sysplexes. So my first suggestion is to check whether or not there really is no channel-to- channel capability and, if not, why not. As I mention later - this being a point added in review - to the extent to which your LPARs reside within the same CEC, you, in effect, have "channel-to-channel" technology - when using IP communication. Note that, if you are having to migrate to VTAMs enabled for APPN and want to eliminate all subarea connections - as I was tasked to do - you cannot "reuse" the channel-to-channel connections set up for subarea use (DISPLAY NET,STATIONS). Those needed only one path. You need to set up minimally duplexed connections so that one "channel" supports "read" and another "channel" supports "write". These hardware definitions can map to VTAM definitions which are capable of supporting APPN (DISPLAY NET,CLSTRS) [3]. If your LPARs supporting the SNA component of z/OS Communications Server (CS) - I assume you are interested in z/OS rather than z/VM or z/VSE which is yet another point not clearly stated in your post (?) - (namely VTAM) also are configured with appropriate hardware to support the IP component and those IP nodes are contained within the same typically intranet, you may - as Mark Zelden pointed out - set up Enterprise Extender (EE) as the connections which show up when you enter the DISPLAY NET,CLSTRS command. If you need to use EE as your connections between the VTAMs in your LPARs, each VTAM will need to be enabled for APPN. Note that this can be a risky process - it used regularly to confuse and defeat experienced system programmers from the mid-'90s when the possibility first arose and, while the few LPARs which were added as pure APPN VTAM nodes did manage to communicate at the customer where I was working most of the time, the responsible guys realised that even the education they had had was still not adequate to solve all the mysteries that were sneaking up on them from time to time - hence the consultancy project! If all your LPARs lie within one CEC, then the "technology" Mark Pace mentioned, HiperSockets, can be used for the IP-based connections. It didn't occur to him to mention the key requirement that HiperSockets applies *only* within one CEC - or I've missed an announcement! Do not at all be put off by the fact that you "invoke" HiperSockets by calling it XCF all the time. This is just the CS developers indulging their usual practice of trying to confuse you with "misused" - possibly better explained as "recycled" - definition structures. If your LPARs rely on OSA features in order to communicate between each other and the rest of the intranet/Internet, they could also be used to set up SNA communication unsullied by having to "piggyback" over IP. However, the OSA features are probably configured as channel type OSD (QDIO mode) and they would need to be configured as channel type OSE in order to support both IP-based and SNA-based connections. This would mean that the many benefits of QDIO would be lost and so is a suggestion included only in order to try to be comprehensive. > Can TCPIP be used? The strict answer to this is "No"![4] If you had asked - can IP be used? - or - better - although nobody would ever bother to ask this question quite so precisely I guess - can UDP/IP be used?, the answer would be a resounding "Yes"! This is because EE uses UDP as its transport protocol. Please post again if you need more help on exactly what to do and provide a bit more background over what your *real* problem is, where you are today and where you would like to be tomorrow. For example, Mark Pace has managed to assume that the applications you support which use the VTAM API can be reconfigured in order to use a CS IP API. The application he cited is NJE. If all your applications can be so reconfigured that could be indeed another option. If you do feel the need to post again, you may care to use the IBMTCP-L list, where the folk who have experience with EE tend to keep watch. <quote> For IBMTCP-L subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBMTCP-L </quote> Chris Mason [1] Plus subarea boundary function peripheral if any - none in the case of my customer. [2] Which bore a remarkable similarity to the scheme I used to use for connections between my guest MVS systems running under VM for my hands- on classes! [3] And *not*, as a rather artificial limitation, Low Entry Networking (LEN). [4] In the past the answer could have been "Yes" but the AnyNet IP over SNA "products" - which used TCP - have been withdrawn. On Wed, 14 Jul 2010 09:02:41 -0500, Neal Eckhardt <[email protected]> wrote: >In previous lives, we used a CTCA to provide the communications link between >LPARS. My current employer no longer has a CTCA connection. > >What other choices do I have to set up a path between LPARS (no coupling >facility here either)? Can TCPIP be used? > >Thanks, >Neal ---------------------------------------------------------------------- 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
