Mark > XCF is oriented to sysplexes and, as you say, your two LPARs do not belong to a sysplex.
This is not quite as clear as it should be. I should have said "do not belong to the *same* sysplex". You did say that the LPARs belonged to sysplexes, just different sysplexes. While I'm here again, I may as well add that you might be able to survive with the default values for the related VTAM definitions but you should be *aware* that you are relying on those related VTAM definitions even if the default values work with your configuration. Chris Mason On Tue, 21 Apr 2009 15:59:47 -0500, Chris Mason <[email protected]> wrote: >Mark > >As Lionel Dyck pointed out, the key characteristic of an HiperSockets >connection is that it is between two LPARs on the same Central Electronic >Complex (CEC). Since you mentioned that the two LPARs you want to connect >using an HiperSockets connection share an OSA feature, you imply thereby >that the two LPARs belong to the same CEC. The fact that you share an OSA >feature in itself is not significant for an HiperSockets connection. > >Here is a technical presentation designed to introduce you to HiperSockets >with z/OS: > >http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3120 > >If you need help with another operating system, z/VM or z/Linux, try the IBM >pages search box - as I just did. > >I'm a little bit familiar with the z/OS use of HiperSockets and, if it's z/OS >that >interests you, you should go to section "HiperSockets concepts and >connectivity" under "Considerations for networking hardware attachment" >under Chapter 2, "IP configuration overview" in the Communications Server IP >Configuration Guide. > >You will quickly see that you are encouraged to establish your HiperSockets >connections using the IPCONFIG statement DYNAMICXCF parameter. This is, >of course, the second source of confusion with HiperSockets - assuming that >some imagined association with OSA features was the first! XCF is oriented to >sysplexes and, as you say, your two LPARs do not belong to a sysplex. This is >a case of IBM trying to be helpful - and saving themselves the need to create >new definition structures - but ending up causing quite understandable >confusion. > >So just grit your teeth and use the DYNAMICXCF parameter anyhow! > >Be aware that there are two VTAM start options which relate directly to >HiperSockets, IQDCHPID and IQDIOSTG. Also the use of HiperSockets can >affect the VTAM buffer pools so the usual monitoring of VTAM buffer pool >usage will be called into play. > >I see at least one responder has eschewed using the DYNAMICXCF parameter >in favour of specifying all the bits and pieces individually. All the while >continuing with the confusion caused by associating HiperSockets with >sysplexes and XCF, you will find assurance in specifying the bits and pieces in >the section "HiperSockets" under "Dynamic XCF" under "Connectivity in a >sysplex" under Chapter 8, "TCP/IP in a sysplex" in the Communications Server >IP Configuration Guide. You will need to read the earlier sections >under "Dynamic XCF" to appreciate that suitable statements for DEVICE, LINK, >ROUTE and START and suitable statement entries for HOME and >BSDROUTINGPARMS are all created for you when you use the DYNAMICXCF >parameter. This being so you may not need to bother with your own ROUTE >statements or the OMPROUTE address space. However, you will, as always, >need to consider the routing implications for the rest of your IP network as >necessary. > >You didn't actually say you were interested in SNA traffic - but then you >didn't specifically say you were interested in IP traffic either! Allan >Staller's >point that HiperSockets connections cannot be defined for use directly with >SNA - as can be the similar but different XCF connections - may be important >for you. If SNA does interest you, as Allan says, you will need to implement >Enterprise Extender and you *will* be using APPN, and the HPR flavour of >APPN, and not what Allan calls "xDomain" by which I assume he means subarea >SNA. > >You are *not* using QDIO with HiperSockets but rather *i*QDIO, >aka "internal" QDIO. QDIO involves OSA features whereas iQDIO comes "at no >extra charge" with the CEC hardware. > >Finally John McKown's suggestion to search the manuals with "IQD" as a >search word turns up another important reference and a poorly labeled >appendix. In Appendix D, "Using HCD", of the Communications Server IP >Configuration Guide you will see a discussion of how to define your >HiperSockets to the "hardware" - and only that as far as I can see with a >quick glance! I have never had actually to do this so I might have missed the >reference without John's prompt. Otherwise the only hits for "IQD" are in the >sections I mentioned already. > >Chris Mason > >On Tue, 21 Apr 2009 09:34:59 -0700, Mark Yuhas ><[email protected]> wrote: > >>We would like to configure the linkage between two LPARs and >>Hipersockets. The LPARs are members of two different sysplexes. >>However, these LPARs are utilizing the same OSA card. >> >>If this configuration is feasible and/or possible, where is this >>documented and are there examples? >> >>TIA. ---------------------------------------------------------------------- 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
