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
