Chris, Thanks a million. Your examples helped. We now see the APPN connection being made between the LPARs.
Regards, John -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, May 19, 2009 12:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Configuring APPN using Hipersockets John Here's some samples to get you started taken from some definitions I set up for a customer last year: Sample Enterprise Extender Major Node ------------------------------------- VBUILD TYPE=XCA name PORT MEDIUM=HPRIP, enterprise extender * HPREELIV=YES, HPR liveness reduction for EE * IPPORT=12000, first of 5 IP port numbers * IPRESOLV=0, no resolver timeout * IPTOS=(20,40,80,C0,C0), types of service * LIVTIME=(20,60), LDLC inoperative timer * SRQRETRY=4, short request timer retry count * SRQTIME=3 short request timer interval name GROUP IPADDR=aaa.aaa.aaa.aaa, VIPA for enterprise extender * AUTOGEN=(nn,prel,prep), =< nn simultaneous connections * ANSWER=ON, allow incoming connections * CALL=INOUT, use for outgoing and incoming connections * DIAL=YES, switched procedures required * DYNPU=YES, dynamic link station control blocks * KEEPACT=YES, reactivate automatically after failure * TGP=FICONEXP, transmission group characteristics * UNRCHTIM=20, allowance for IP network repair * VNNAME=name.name virtual routing node name Relevant start options: DYNVNPFX=prec dynamic connection network PU prefix UNRCHTIM=(,2) threshold for virtual routing node EE PU and PATH for initiating connections ----------------------------------------- VBUILD TYPE=SWNET name PU CPNAME=name, name of adjacent SSCP * DISCNT=NO, no automatic disconnection * DWACT=YES, connect on activation * DWINOP=YES, reconnect after INOP * LIMRES=NO, no automatic deactivation of LU 6.2 * TGP=FICONEXP, transmission group characteristics PATH IPADDR=aaa.aaa.aaa.aaa, IP address of adjacent node * GRPNM=name, name of enterprise extender XCA group * CALL=INOUT, allow incoming and outgoing calls * REDDELAY=30, interval between reconnect retries * REDIAL=FOREVER retry automatic reconnection Relevant start options: CONNTYPE=APPN APPN is to be supported CPCP=YES request CP-CP sessions DYNLU=YES dynamic creation of CDRSCs EE PU model for accepting connections ------------------------------------- VBUILD TYPE=MODEL EEMODEL PU DYNTYPE=EE, enterprise extender dynamic link station * DISCNT=NO, no automatic disconnection * TGP=FICONEXP transmission group characteristics Relevant start options: CPCP=YES request CP-CP sessions DYNADJCP=YES accept adjacent node without check DYNLU=YES dynamic creation of CDRSCs DYNPUPFX=pred dynamic incoming connection PU prefix EE PU model for connections over a connection network ----------------------------------------------------- VBUILD TYPE=MODEL VNMODEL PU DYNTYPE=VN, virtual routing node dynamic link station * DISCNT=NO no automatic disconnection Start Options: DYNADJCP=YES accept adjacent node without check DYNLU=YES dynamic creation of CDRSCs RTP PU model ------------ VBUILD TYPE=MODEL RTPMODEL PU DYNTYPE=RTP, RTP model * DISCNT=(DELAY,,10), disconnect after time value * LIMRES=YES automatically deactivate LU 6.2 Relevant start options: CPCP=YES request CP-CP sessions DYNLU=YES dynamic creation of CDRSCs Comments: If you do *not* want to set up connection network with a virtual routing node to represent the IP network for the purpose of establishing connections between nodes which do not have permanent connections, you should remove the TGP, UNRCHTIM and VNNAME from the XCA GROUP statement. The DYNVNPFX and UNRCHTIM start options and the DYNTYPE=VN model PU also become irrelevant. If you are going to use a connection network because you have nodes which do not have permanent connections between them, you should understand the mechanism behind the UNRCHTIM operand and start option and set appropriate values for your configuration. Also note that, I have set DISCNT=NO in the DYNTYPE=VN model so that, when a connection is established dynamically on demand, it is *not* disconnected after use, this being sensible behaviour for a small number of nodes but not necessarily for a large number of nodes with infrequent internode traffic over the connections established dynamic. It is very highly recommended to specify the TGP operand so a possibly appropriate profile name has been suggested wherever it is relevant. The value of the CAPACITY characteristic strongly affects the start-up performance of Rapid Transport Protocol (RTP) connections. The LIVTIME operand shown does not have the default values. The values given may be considered as they exploit the possibility to reduce the frequency of connectivity testing over the connectionless IP network. The SRQRETRY and SRQTIME operands shown also do not have the default values. The values given are more appropriate for short distances over fast media with few or no intervening router nodes. Note that DWACT and DWINOP operands have been set to YES in order automatically to initiate connections and maintain connections, where possible. In addition REDIAL operand has been set to FOREVER so that the attempt to establish a connection is continuous with the interval given by the value of the REDDELAY operand. The RTP model is relevant because Enterprise Extender necessarily uses High Performance Routing (HPR) and, hence, RTP connections. The only relevant operands have been shown with defaults for the DISCNT and LIMRES operands. These defaults can be discerned only with some difficulty in the manuals! Of the relevant start options shown, CONNTYPE and DYNADJCP have the default setting but CPCP and DYNLU do not and therefore need to be specified in order to match the minimal definitions in these samples. - Chris Mason On Tue, 19 May 2009 11:04:24 -0700, John Au <john...@paccar.com> wrote: >Chris, > >Thanks for the info. I'll direct my attention to setting up Enterprise >Extenders for both LPARs. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Chris Mason >Sent: Monday, May 18, 2009 11:17 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: Configuring APPN using Hipersockets > >John > >Yes, it's confusing but then it's IBM! > >The DYNAMICXCF parameter of the IPCONFIG statement was originally set up > >as a way of creating an interface connected to a sort of "LAN switch" >managed by the sysplex logic so that an interface in a Communications >Server >(CS) IP instance in one sysplex member LPAR can connect to a CS IP >instance >in another sysplex member LPAR using just one IP address per instance. >However it has been extended to cover two other situations: > >1. Interfaces to connect a CS IP instance to another CS IP instance >running >within the same LPAR (IUTSAMEH)[1] >2. Interfaces to connect a CS IP instance running within the one LPAR to > >another CS IP instance running within another LPAR within the same >physical >machine aka Central Electronic Complex (CEC) (HiperSockets) > >In neither of these cases is the "XCF" part of the name "DYNAMICXCF" >relevant, hence the confusion. > >Continuing with the "LAN switch" concept: in 1 the "switch" is managed >by the >CS IP instances working together with the z/OS image within the LPAR; in >2 >the "switch" is managed by the HiperSockets logic. > >You can confirm the various uses of the DYNAMICXCF parameter of the >IPCONFIG statement in the following CS IP Configuration Guide sections: > >- "HiperSockets concepts and connectivity" in Chapter 2, "IP >configuration >overview" > >- "Dynamic XCF" in Chapter 8, "TCP/IP in a sysplex" > >You should go carefully through the whole of the second reference in >order to >find examples of exactly what the DYNAMICXCF parameter of the IPCONFIG >statement does in various configurations. It is only at the end of this >section >that HiperSockets is covered. > >- > >The CS SNA component, that is VTAM, has remained true to the strict >meaning of XCF, as it were, since allows for the automatic creation of >connections only within a sysplex. > >Thus, in order to get the benefit of HiperSockets, you are obliged to >set up >SNA connections using Enterprise Extender definitions. > >Chris Mason > >[1] Actually this may not have been so much an "extension" as also >having >been provided originally. Perhaps some alert participant can confirm or >deny >this. > >On Mon, 18 May 2009 16:51:15 -0700, John Au <john...@paccar.com> >wrote: > >>Chris, >> >>I thought dynamicxcf would not work when connecting from 2 separate >base >>sysplexes. I been attempting to connect using TRLE definitions via MPC >>and local major nodes for each LPAR without any luck. >> >> >>-----Original Message----- >>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >>Behalf Of Chris Mason >>Sent: Monday, May 18, 2009 12:59 PM >>To: IBM-MAIN@bama.ua.edu >>Subject: Re: Configuring APPN using Hipersockets >> >>John >> >>Yes - you are obliged to use Enterprise Extender. In the Communications >>Server IP component, you should rely on the IPCONFIG statement >>DYNAMICXCF parameter in order to establish IP interfaces to >>HiperSockets. >> >>If you need sample for setting up Enterprise Extender, please post >>again. >> >>If you do post again, please say more about your configuration. >> >>Chris Mason >> >>On Mon, 18 May 2009 12:43:59 -0500, John Au <john...@paccar.com> >>wrote: >> >>>Is there a way to connect APPN Network Nodes on separate LPARs and >>>separate base sysplexes within the same CEC using Hipersockets? If >so, >>are >>>there some sample configurations, I can take a look at. Everything >>I've tried >>>gets me to a status of "Pending request connections". Any info on >this >>would >>>be most appreciated. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
