Freelance Graphics - S12 - IBM WWW PageFILE/S3622_S12_EEMGT.pdfITM/NP V2.1), which can give you a...

Aug. 21 - Aug. 26, 2005

© IBM Corporation 2004, 2005

SHARE in Boston, Massachusetts

Survival Guide for the z/OS Networker: Managing Enterprise Extender in z/OS

(Part 2 of 2)Gwen Dente ([email protected])

Washington Systems Center, Gaithersburg, MD

S3622

Friday (Aug. 26, 2005) 11:00 AM - 12:15 PMRoom 310

Gwen Dente, Washington Systems Center, Gaithersburg, MD

Survival Guide for the z/OS Networker: Survival Guide for the z/OS Networker: Managing Enterprise Extender in z/OSManaging Enterprise Extender in z/OS(Part 2 of 2)(Part 2 of 2)

© 2005 IBM Corporationn

1. There are a number of network management tools available for monitoring and problem diagnosis with TCP/IP and SNA. However, no existing single operator command provides access to Enterprise Extender specific network management and problem diagnosis information.

2. These sessions provide detail on useful commands for monitoring this environment, especially if you are not using one of the Network Management tools based on the Communications Server Network Management API introduced in z/OS V1R4 ( like ITM/NP V2.1), which can give you a composite view of what is happening in an EE network.

© 2004, 2005 IBM Corporation

In recent years the explosive growth of the internet has motivated customers to consolidate their SNA and IP networks to achieve cost and administrative savings, begging the question as to how to support both SNA and IP users and applications over a single network protocol: IP. The implementation of Enterprise Extender (EE) has become the strategic response to this question.

There are many sessions that explain the implementation of EE. This particular set of sessions focuses on how to MANAGE Enterprise Extender, using working examples from the z/OS and Cisco platforms. Part 1 (of 2) begins with a very brief introduction to Enterprise Extender but quickly turns to practical examples of how to understand what is happening with your EE environment using some simple tools available to us today. You will hear some design and coding tips for EE; and then you will be exposed to basic commands and displays from SNA and from TCP/IP that shed light on what is really occurring in your Enterprise Extender network. Part 2 continues with the examination of displays that show how to understand path topology with EE, performance situations with EE, and how to simplify configuration in order to avoid typical problems with performance and operation.

Displays from Tivoli NetView NLDM, from the Cisco SNASWITCH vantage-point and from IBM's Personal Communications (PCOMM) will round out the management views.

ACKNOWLEDGEMENTS: Thanks to several people who have given me ideas for this presentation: Josef Killmeyer of IT Austria, Matthias Burkhard of IBM Germany, Sam Reynolds of IBM Communications Server Development in Raleigh, NC, Art Eisenhour of IBM Advanced Technical Support in Gaithersburg, MD., and the following IBM IGS members: Chuck Rausch, Steve Naftzger, Mike Parrish, Pat Anderson, Jim Maloney, Mark Peters, Ramon W Georges, Dawn Greenwald. Thanks to Johnathan Harter of IBM Development in Raleigh, N.C. for a summary of VTAM hints for LOGMODE and COS/APPNCOS resolution I extracted from one of his presentations. Matthias Burkard, IBM Germany, allowed me to include his Reference Card, "Network Operation in HPR Networks."

Many thanks are also owed to the following people for their help in providing equipment and technical expertise for Cisco routers and switches and for IBM PCOMM: Ray Romney and Mike Blair of Cisco Systems in Raleigh, NC; Johnny Chi, Joe Consorti, and Kenneth Morse of Advanced Technical Support in Gaithersburg, MD; Jim Quigley and Prasad Kumar of IBM PCOMM Development in Raleigh, NC; Mike Law of IBM Integrated Marketing and Solutions Test in Raleigh, NC.

Abstract

1. Announcement letter 902-040 (2/26/02)2. Effective September 27, 2002, for Machines and December 31, 2002, for MESs IBM will withdraw from marketing all models of

the IBM 3745 Communication Controller and IBM 3746 Nways® Multiprotocol Controller plus selected features and MESs. 3. After February 26, 2002, you will only be able to obtain these products on an as-available basis, directly from IBM or authorized

IBM Business Partners. 4. For new orders the customer-requested arrival date (CRAD) must be no later than October 31, 2002, for machines and January

31, 2003, for MESs. 5. IBM maintenance and other related services, if still available for the product, are not affected by this announcement. IBM will

continue to provide service for the 3745 and 3746 controllers consistent with normal IBM Technical Services service plans and guidelines. Typically IBM will provide service for a minimum of five years from the date of marketing withdrawal. All existing contractual service agreements will be honored. Before committing dates or service periods the geography service planning representative should be contacted.


AgendaEnterprise Extender: Quick ReviewWhat tips should I follow in setting up my EE definitions?MTU and SNA RUsizeSNA Naming and TG Numbering ConventionsGeneral APPN Recommendations -- Model Major NodesHow do I know my IP network will work for Enterprise Extender?How do I know my SNA network will work for EE?How do I know what the APPN path is for a session over EE and why it

was chosen?VTAM and SNASwitch CommandsTIVOLI Netview NLDM ViewsHow do I know what the IP path is between two EE endpoints?Trace the route -- z/OS and SNASwitchOMPRoute RTTABLE Command

How do I know if a session is using Enterprise Extender?How do I know what the current performance characteristics of an EE

connection or session are?Why are EE Components Going Up and Down?RTP Pipe PUsEE PUsAppendices: EE Background; EE and Policy Agent IDS for UDPAppendix: Quick Reference Cards for IBM and CISCO Commands

Part 1

Part 2

1. The advantages of Enterprise Extender include features you have heard about 1. SNA transport over native IP network - EE allows SNA resources to access each other using an underlying IP network,

eliminating the need to provide two different networks, one for SNA and one for IP, as many customers do today.2. No changes to SNA applications - the use or implementation of EE nodes in the network is transparent to the SNA

applications. They can participate in sessions (all kinds -- APPC, LU2, LU1, LU0, etc.) without change because the underlying IP network just looks like an APPN/HPR TG to the SNA network.

3. Fully enables parallel sysplex - the SNA Parallel Sysplex functions are dependent upon using APPN and HPR within the Parallel Sysplex. As compared with HPR just within the Parallel Sysplex, implementing EE in the network can provide higher availability since HPR can be exploited to route around additional node/link failures.

4. End-to-End failure protection - because EE uses the underlying HPR technology, there is much more end-to end failure protection as compared with older SNA technologies, such as subarea networking, DLSw, etc..

5. End-to-End data prioritization -- EE by default implements setting of different PORTs and different Type of Service (TOS) bits based on the APPN Class of Service being used (network, high, medium, or low priority).

6. Can reduce complexity - because EE exploits use of underlying IP network alternate routing technologies, there is reduced need to implement a lot of network nodes and links between them in the SNA portion of the network. EE can also be combined with Branch Extender technology, allowing routers to appear as ENs, rather than NNs, thereby simplifying the APPN network design.

7. SNA traffic can exploit OSA Gigabit Ethernet -- the OSA Gigabit Ethernet, which has produced impressive throughput benchmark results, does not support SNA (only TCP/IP) connections. With use of EE, the SNA traffic can exploit the very high speed connectivity provided by the OSA Gigabit Ethernet adapter as well as any zSeries IP network connection -- channel attached router, OSA, etc.. Since many customers are currently building fast, redundant IP networks for the Web and client/server applications running in the S/390, EE provides the advantage of being able to use any of these high-speed IP connections for SNA traffic, as well.

8. Connection network can be defined along with EE allowing nodes to bring up dynamic links between them to support direct routes for sessions.

9. EE works with IPSEC (Virtual Private Networking). If use of NAT with EE is desired, address administration is required; EE Connection Network and Global Connection Network do not work with NAT.


How Do I Track Down SNA Session Problems with EE?

The same way you always did for SNASNA Commands

D NET,ADJSSCPS,CDRSC=...D NET,SESSIONS,SID=...D NET,TOPO,...D NET,RTPS,...D NET,E,ID=...D NET,APING,...

Tivoli NetView NLDMTemporarily enabling more messages to aid in problem determination

Message capture at all OLU, DLU, and intermediate VTAMSSFIRFMSG=ALLSSCP, FSIRFMSG=ALLSSCP, LSIRFMSG=ALLSSCP, RSIRFMSG=ALLSSCP (V1R7),etc.

Temporarily revoking z/OS Message Suppression for VTAM messages while you are re-creating problem

SYS1.PARMLIB(MPF....)The same way you always did for IP

IP CommandsNETSTATPINGTRACERTESNMPSMF Records

Use REXX EXECS to simplify operationsAnd there are new tools coming!

Look for Following Presentations on IBM and SHARE websites:

Logmode & COS Resolution EE Nuts and Bolts APPN ConfigurationsSearching in Mixed Networks APPN/HPR Top Ten Hints

Look on IBM website:

z/OS CS TCP/IP Hints & Tips TCP/IP Performance Tuning

1. The presentations listed can be found from the main IBM website (www.ibm.com) by searching for the titles; some of the presentations are available with the appropriate userid and password from the SHARE website at www.share.org.

2. You may display the settings for the VTAM Message Options by issuing the command: D NET,VTAMOPTS,FUNCTION=MESSAGES. There are many such start options for managing message displays: ASIRFMSG, DSIRFMSG, ESIRFMSG, LSIRFMSG, et al.

3. FSIRFMSG: A VTAM Start Option that controls how the SSCPs issue messages IST894I, IST895I, IST1704I, and IST1705I when a session initiation request fails because VTAM is unable to locate the destination LU by using an adjacent SSCP table. The default setting is "ALLSSCP" but many shops have chosen to limit such messages due to the extensive output.

4. SIRFMSG: A VTAM Start Option that controls how the SSCPs issue IST663I, IST664I, IST889I, and subordinate messages when a session initiation request fails. The default setting is "ALLSSCP" but many shops have chosen to limit such messages due to the extensive output.

5. LSIRFMSG: A VTAM Start Option (introduced at V1R6) that controls how the network nodes issue messages IST663I, IST664I, IST889I, and subordinate messages when APPN locate searches fail to locate the target resource. The default setting is "NONE" but you might need to enable this to indicate "ALLNNS" if you are tracking down an APPN LOCATE problem. The ESIRFMSG and FSIRFMSG start options can be used in conjunction with LSIRFMSG to generate additional messages as part of this message group.

6. ESIRFMSG: A VTAM Start Option that controls how the SSCPs issue IST891I, IST892I, and IST893I. These messages are issued when a session initiation request fails and extended sense data exists. The default is ALLSSCP.

7. RSIRFMSG: A VTAM Start Option introduced in z/OS V1R7 that displays the APPN route (RSCV) that was used when a session failed to establish. The default is ALLSSCP. To receive the RSIRFMSG messages you must also have coded SIRFMSG and/or DSIRFMSG as either ALLSSCP or OLUSSCP.


Tips for Working with EE


Avoiding Gotcha's in Planning for EE ...Plan properly for an APPN/HPR implementation in at least one Subarea Node

IBM Training and Education Services Course G3945 (also G39S0) "VTAM/APPN Concepts and Implementation" - or - obtain equivalent experienceAssign appropriate TG weights for the APPN Enterprise Extender connections

ARB Mechanism, Route Selection (Topology & Routing Services - TRS)Attend relevant SHARE pitches on APPNCOS, LOGMODE, SEARCHING

Use large SNA RUs for streaming traffic in EE (see Performance Measurements)V1R7 Enhancement: D NET,SESSIONS,SID=... indicates RU Sizes for PLU and SLU

Establish SNA Naming Conventions to allow use of WILDCARDS in OperationsEstablish TG Numbering Conventions to allow quick recognition of session paths and to permit filtering by TG number in OperationsDon't use DYNPU=YES until V1R5 Model for EE is available or unless you implement ISTEXCCS.

Use Connection Network to limit administration stepsUse Model Major Nodes to influence defaults for RTP, VN, and EE where necessary

Possible differences in LIMITED RESOURCE or DISCONNECT ProcessingDon't attempt to implement EE Connection Network across a NAT'd IP network until z/OS V1R5

Standard EE across a NAT'd network is fine Use ENHADDR=YES at VTAM although only required for APPN LUs and parallel session APPLs Work with MVS, VTAM, and TCP/IP capacity planning personnel

Monitor for changed traffic patterns and resource utilization within the subsystems and across different channel subsystems; Monitor VTAM TI-, T1-, T2BUFs, and NAUs.

1. Items with a bullet of "X" are ones that you will hear more about in this presentation or items that bear mentioning, because you may not have heard them in another presentation.

2. Plan properly for an APPN/HPR implementation in at least one Subarea Node1. Attend IBM Training and Education Services Course G3945 "VTAM/APPN Concepts and Implementation" - or - obtain equivalent experience2. Use the recommendations from Johnathan Harter of IBM Development in Raleigh, N.C.. They may be reviewed in any of his SHARE or NSTC presentations on

"LOGMODE and COS RESOLUTION in a MIXED APPN/SUBAREA ENVIRONMENT." Alternatively, the subject is discussed in the SNA Networking Implementation Guide.

3. Ensure that the TG weights for the APPN Enterprise Extender connections are appropriate in both directions (at both endpoints) so that Adaptive Rate-Based Congestion control works and so that APPN route selection occurs as expected.1. NN-NN Links must be same for correct Route Selection from each direction; EN view of TG characteristics is used for NN-EN Route Selection.

4. Avoid segmentation of SNA and Network Layer Packets (NLPs) by setting the IP MTUsize larger than 7681. Don't use IP defaults for MTU at IP or in OMPROUTE (Path MTU Discovery is not used for EE)2. To ensure optimal performance, the TCP/IP maximum transmission unit (MTU) size should be greater than or equal to the RTP Network Layer Packet (NLP) size.

VTAM will query TCP/IP for its MTU size when establishing an RTP connection (for a CP-CP session, to transport ROUTE_SETUP GDS variables, or for an LU-LU session). If the connection is within the node starting the RTP connection, VTAM sets the maximum packet size equal to the lesser of the MTU size or the VTAM maximum data size. If the connection is within an intermediate node or destination node, VTAM sets the maximum packet size equal to the lesser of the MTU size, VTAM maxiumum data size for the next hop, or the value received on the ROUTE_SETUP GDS variable.

3. Note: If the MTU size is below 768 bytes, VTAM sets the maximum packet size to 768 (this is the smallest maximum packet size allowed by VTAM). This limitation can cause TCP/IP to fragment if the MTU size is set below 768 bytes, but exists because the RTP layer can not allow the HPR header to be segmented in the RTP layer.

5. Performance measurements at V1R2 show that large SNA RUs (8K) are optimal for streaming traffic over EE, even when the MTU size is 1500. 3. SNA Naming and TG Numbering conventions will help you in operations and problem determination. You will see that in our network we have certain prefixes we can use

wildcards against to determine what is active; you will also see that we have assigned TGN=13 to EE connections between z/OS nodes and TGN=3 to EE connections to SNASWitch routers.

4. Use either Connection Network or use predefined SWNET members for EE Partners -- Don't use DYNPU=YES until V1R5 Model for EE is available or unless you implement ISTEXCCS.

5. Don't attempt to implement EE Connection Network across a NAT'd IP network until z/OS V1R51. Standard EE across a NAT'd network is fine

6. Use Model Major Nodes to influence defaults where necessary7. Beware of differences in LIMITED RESOURCE or DISCONNECT Processing at each end of EE Connection; consult with vendors and implementers of non-zSeries EE

platforms.8. If not already doing so, start using VTAM Start Option of ENHADDR=YES.

1. If you specify ENHADDR=NO all element addresses that VTAM obtains for resources in this subarea come out of the 64k element pool. This includes each active (connectable) APPL (two if PARSESS=YES), each activated local LU and PU, each dynamically defined LU and PU (once connected). We must also obtain a session partner element address for each session in which we are the endpoint or intermediate routing point (unless the session path to that partner is over a FID_4 link - because, in this case, the element address will originate from another subarea's address space). APPN session partner element addresses come out of this subarea's 64K element address pool if you specify ENHADDR=NO. Finally, certain types of elements come out of the high-order pool whether or not you specify ENHADDR=YES: DLUS-served LUs (OS/390 V2R5); EE Lines and PUs (z/OS V1R4); RTP PUs and DLUS-served PUs (z/OS V1R6).

2. ENHADDR=YES Specifies that you can use high-order element addresses for application programs.9. Always keep an eye on capacity: Use RMF reports -- consider VTAM Buffer usage changes -- consider VTAM Network Addressable Unit utilization, and so on.


Avoiding Gotcha's in Planning for EEWork with IP Router Networking Infrastructure groups

Stay on high level of IOS Code (e.g., Cisco IOS 12.3.5A and CIsco IOS 12.2.17 both have performance enhancements in them)Where possible try to keep RTP & EE Timers the same at both ends of an EE link. Ensure that EE Ports are opened in both directions on any Firewalls! Ensure that IP TOS is being honored in router network. In a congested network or with bursty traffic, results can be unpredictable.Assign a LOOPBACK address to be the SNASwitch EE Endpoint to avoid reconfiguration if network attachments later change. Ensure that router convergence takes place within EE timeout valuesMonitor Router Queue lengths and buffers

For SNASwitch, use IOS 12.3.1 or higher to avoid a restriction on the length of the LOCATE vector -- limits use of predefined connectionsReview issues and tips in EE Information APAR II12223.

Performance APARs and PTFs like OA04393, UA00131, AEEPERF Design restriction APARs (for sessions crossing Subarea at an ICN and adjacent to HPR-only TG like EE in pre-V2R10 - OW44611; for sessions crossing Subarea at an ICN and adjacent to HPR-only Connection Network like EE in pre-V1R4)

Learn a bit about timers for EEMay need to expand if using RIP or network is typically congested.

Consider implementing a DSME for tighter cross-net APPN SearchingRemember that VR Pacing not used with EE; may need to adjust session pacing.

Stay abreast of enhancements to EE in the areas of usability and diagnostics by reviewing IP and SNA Migration manuals for each new release, by attending or reviewing conference presentations, and by continuing to follow Info APAR II12223.

1. Items with a bullet of "X" are ones that you will hear more about in this presentation or items that bear mentioning, because you may not have heard them in another presentation.

2. Work with IP Router Networking Infrastructure groups to monitor for increased traffic across the router network1. Router Queue lengths and buffers2. Ensure that IP TOS is being honored in router network.3. Maintain same timers at both ends of an EE connection.4. Try to use a LOOPBACK address in SNASwitch for your EE Configuration.

3. Work with MVS, VTAM, and TCP/IP capacity planning personnel at your site to monitor for changed traffic patterns within the subsystems and across different channel subsystems

4. For SNASwitch, use IOS 12.3.1 or higher to avoid a restriction on the length of the LOCATE vector5. Review issues and tips in EE Information APAR II12223.6. Performance APARs and PTFs like OA04393, UA00131, AEEPERF

1. Design restriction APARs 1. for sessions crossing Subarea at an ICN and adjacent to HPR-only TG like EE (pre-V2R10) - OW44611 2. for sessions crossing Subarea at an ICN and adjacent to HPR-only Connection Network like EE (pre-V1R4). If you are at

V2R10 or V1R2, do not implement EE Connection Network at Interchange Nodes if there is the potential of sessions with routing paths that exit an ICN subarea into an HPR-only connection network like EE.

7. Expand XCA timers to accommodate delays in the router netwrk if necessary, but only if timers expanded on both sides of EE connection (Usually only with RIP); if timers are changed, adjust PSRETRY and HPRPST also.1. HPRPST specifies the maximum time that VTAM tries a path switch before ending a connection, when HPR=RTP. The value

can be expressed as nS, nM, or nH. If you do not specify an S, M, or H, seconds are assumed. When a high performance routing RTP node determines that it is necessary to switch paths for the RTP logical connection, it starts a path switch timer.

8. Consider using a Directory Services management Exit (DSME) to provide tighter controls for cross-net session setup. Review previous notes in this presentation about the DSME: "If you are already controlling functions with an SME, then you will surely want to implement a DSME. If you are not currently using an SME, you still might want to consider the implementation of a DSME to control cross-net searches. A DSME controls all session setups that use DSME. The DSME cannot control sessions that start or enter or leave VTAM through subarea; if APPN is entered and the DSME rejects the session, APPN returns a "not found" to subarea and subarea continues searching. "

9. Stay abreast of enhancements to EE in the areas of usability and diagnostics by reviewing IP and SNA Migration manuals for each new release, by attending or reviewing conference presentations, and by continuing to follow Info APAR II12223.


Example Network

SKIP TO PAGE 15Example Network is included here as in Part 1

for your reference.


IP Network: Physical View

USIBMWZ.S100CDRM

Public Addresses

Static Routes

CISCO 3825C CISCO 3825D

GBE-QDIO172.17.0.x/24

CISCO 3825B

USIBMWZ.CPREE4Loopback

192.168.135.182

192.168.25.34 VLINK1

TCPIPB

CISCO 3750 SwitchFEE0

.10.12

.1

172.18.0.x/24

E1.12

.13

CISCO 3825A


192.168.135.181

E1/1 E0

E0

172.19.0.x/24

.10

.11

Tr0 .12

.11Tr0

E1.10

.13

172.21.0.x/24

E1/0

E1

E1/23

E1/2

E1/3

172.22.0.x/24

Cisco 2950 Switch staticstatic

192.82.135.209 VLINK1

USIBMWZ.S192CDRM

TCPT11.2

172.16.2.121 VLINK1

USIBMWZ.S193CDRMDLUSNNS

TCPT21CISCO 3750 Switch

Private Addresses

OSPF Routes

static192.168.128.0/19

1. Due to addressing constraints in the lab building, and due to a mixture of static and dynamic (OSPF) routing in the building, I was forced to create two private networks between two isolated lab networks.

2. For IP Network:3. Routers in Intranet have only subnet routes4. TCPIPB should be able to ping public addresses in TCPT11 and TCPT215. Enterprise Extender Links can be established to either one or both TCPT11 and TCPT21 depending on EE IP Addresses used6. TCPIPB will not be able to ping public addresses in any of the Cisco Routers because host routes could not be added in time to

reach the disjointed addresses coded as loopback addresses in the routers.7. TCPT11, TCPT21 will be able to ping public addresses in TCPIP1 as long as a public source IP Address is used8. Enterprise Extender Links can be established to TCPIP1 from either one or both TCPT11 and TCPT21 depending on EE IP

Addresses used9. TCPT11, TCPT21 will be able to ping depicted routers with either their public or private addresses, since OSPF routing has

provided for correct pathing10. The Routers will not be able to ping TCPIPB, even if they use the public address as the source, since the static routing in the

building will not permit it.


USIBMWZ.S100CDRM

IP Network: Logical View

GBE-QDIO


192.168.135.181


192.168.135.182

Private Addresses

OSPF Routes

192.168.25.34 VLINK1

TCPIPB

P R I V A T E1

192.168.135.209 VLINK1

USIBMWZ.S192CDRMUSIBMWZ.S193CDRM

DLUSNNSIsolated

AddressesStatic Routes

TCPT11 TCPT21

172.16.2.121 VLINK1

PRIVATE2

CISCO 3825C CISCO 3825D

CISCO 3825BCISCO 3825A

1. This is a simpler view of what we are dealing with in the IP network when compared with the previous visual.2. The next few pages will include some of the definitions for EE in these notes. They are for your reference, as a prerequisite for

this topic is that you already know how to code for Enterprise Extender.3. Definition at S192CDRM to Connect to S193CDRMEE2SEC2 VBUILD TYPE=SWNET * * CHANGE RECORD WHO? WHEN? * --------------------------------- ------ ----* ADDED NEW IN V1R4: DWINOP, REDDELAY, REDIAL GJD 01/19/04 * * FOR TESTING OMIT DWACT=YES ON PU GJD 01/19/04 * * ------------------------------------------------------------- * * EEPUSEC2 PU ADDR=04,NETID=USIBMWZ,TGN=13, CONNTYPE=APPN,CPCP=YES,CPNAME=S193CDRM, ANS=CONTINUE,TGP=EEXTCAMP,CAPACITY=100M, DWINOP=YES * EEPHSEC2 PATH IPADDR=172.16.2.121,GRPNM=EEGRPL1, REDDELAY=30,REDIAL=3

1. Definition at S193CDRM to Connect to Router "CPREE4"

EE006BMN VBUILD TYPE=SWNET * EEPU006B PU ADDR=04,NETID=USIBMWZ,TGN=3, CONNTYPE=APPN,CPCP=YES,CPNAME=CPREE4, ANS=CONTINUE,TGP=EEXTCAMP,CAPACITY=100M, DWINOP=YES EEPH006B PATH IPADDR=172.19.0.11,GRPNM=EEGRPL1, REDDELAY=30,REDIAL=3


SNA Network: Logical View

DLUR

-DLU

SCP

- CP


192.168.135.181

EN,BEX

SNA over LAN:CSSNET.CPGWPCOM

DLU

R-D

LUS

CP

- CP


192.168.135.182

EN,BEX

DLUR


NN TCPT21

172.16.2.121 VLINK1

EE L

ink

Tg 3

EE L

ink

Tg 3

USIBMWZ.S100CDRM

192.168.135.209 VLINK1

USIBMWZ.S192CDRM

NN NN

IP Network192.168.25.34 VLINK1

TCPIPB TCPT11

CP-CP CP-CPEE LinkTg 13

EE LinkTg 13


1. For SNA Network:2. As long as EE links are available, SNA connections can be set up across all SNA routers and all VTAMs depicted.3. This is the PU definition at S100CDRM to connect to S192CDRMEE2SYSB VBUILD TYPE=SWNET * ADDED NEW IN V1R4: DWINOP, REDDELAY, REDIAL GJD 01/19/04 * * -- FOR TESTING OMIT DWACT=YES ON PU GJD 01/19/04 * * -- VTAMOPTS: CPCP=YES GJD 01/19/04 * * -------------------- * 0EEPUSYSB PU ADDR=04,NETID=USIBMWZ,TGN=13, CONNTYPE=APPN,CPCP=YES,CPNAME=S100CDRM, ANS=CONTINUE,TGP=EEXTCAMP,CAPACITY=100M, DWINOP=YES * EEPHSYSB PATH IPADDR=192.168.25.34,GRPNM=EEGRPL1, REDDELAY=30,REDIAL=3

1. This is the XCA definition at S193CDRM; it defines Connection Network.

EEXCA VBUILD TYPE=XCA *------------------------------------------------------------------- * * CHANGE RECORD WHO? WHEN? * * ADDED KEEPACT=YES (DEFAULT) ON EEGRPL1 (V1R4) GJD 01/16/04 * * CHANGE CONNECTION NETWORK TO HPRIP1 GJD 01/16/04 * *---------------------------------------------------------------- * * EEPORT PORT MEDIUM=HPRIP, IPTOS=(20,40,80,C0,C0),LIVTIME=25,IPPORT=12000, SAPADDR=4,SRQRETRY=3,SRQTIME=15, TGP=EEXTCAMP,CAPACITY=100M, VNNAME=HPRIP1,VNGROUP=EEGRPL1,VNTYPE=LOCAL EEGRPL1 GROUP DIAL=YES,AUTOGEN=(10,EL1,EP1),DYNVNPFX=V1, DYNPU=NO,KEEPACT=YES, CALL=INOUT,ISTATUS=ACTIVE


Connection Network: Logical View


IP Network


192.168.135.182

EN,BEX

DLUR

Connection NetworkHPRIP1

192.168.25.34 VLINK1

USIBMWZ.S100CDRM

NN

IP Network

TCPIPB

192.168.135.209 VLINK1


DLUSNNS

NN NNTCPT11 TCPT21

172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1

Tg 1


192.168.135.181

EN,BEX

Tg 1


1. However Connection Network is available only in the Private IP Network depicted on the right. As a result, all sessions between CSSNET.CPGWPCOM and any application in USIBMWZ.S100CDRM will need to hop through S192CDRM. At least two EE Links will be used for such sessions: one EE link/PU over Connection Network and one over the predefined EE connectin between S100CDRm and S192CDRM.

2. This is the XCA Definition without Connection Network that has been coded at S100CRM:EEXCA0 VBUILD TYPE=XCA *-------------------------------------------------------------- * * XCA FOR ENTERPRISE EXTENDER -- NO CONNECTION NETWORK * *-------------------------------------------------------------- * * CHANGE RECORD WHO? WHEN? * --------------------------------- ------ ---------- * * ADDED KEEPACT=YES (DEFAULT) ON EEGRPL1 (V1R4) GJD 01/16/04 * * AT V1R5: SYNTAX ERROR IF SPECIFY TGP OR * * CAPACITY AND NO VNNAME SPECIFIED GJD 01/20/04 * *-------------------------------------------------------------- * * EEPORT PORT MEDIUM=HPRIP, IPTOS=(20,40,80,C0,C0),LIVTIME=25,IPPORT=12000, SAPADDR=4,SRQRETRY=3,SRQTIME=15 EEGRPL1 GROUP DIAL=YES,AUTOGEN=(10,EL1,EP1),DYNPU=NO, KEEPACT=YES, CALL=INOUT,ISTATUS=ACTIVE


LU - LU Session Flow: S100... to CPREE4

Depending on SLU APPNCOS, TG Characteristics, and Route Calculation with

appropriate NN APPN Costable,

One LU-LU Session might flow over many APPN nodes.Another LU-LU Session might flow over the Connection Network.IP Routing Tables determine the IP Route through network

USIBMWZ.S100CDRM

NN

IP Network

IP Network


192.168.135.181

EN,BEX


192.168.135.182

EN,BEX

DLUR




DLUSNNS

NN NNTCPIPB TCPT11 TCPT21

172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1

Tg 1

Tg 1

192.168.25.34 VLINK1 192.168.135.209 VLINK1


1. However Connection Network is available only in the Private IP Network depicted. As a result, all sessions between CSSNET.CPGWPCOM and any application in USIBMWZ.S100CDRM will need to hop through S192CDRM. At least two EE Links will be used for such sessions: one EE link/PU over Connection Network and one over the predefined EE connectin between S100CDRm and S192CDRM.

2. The Model Major Nodes with "DYNTYPE=..." that have been used at z/OS are:MODRTP VBUILD TYPE=MODEL RTPPU PU DYNTYPE=RTP,DISCNT=(DELAY,,60) <<<or>>> DISCNT=NO

MODVN VBUILD TYPE=MODEL VNPU PU DISCNT=(DELAY,,60),DYNTYPE=VN <<<or>>> DISCNT=NO

MODXCF VBUILD TYPE=MODEL XCFT* PU TRLE=XCFP*,CAPACITY=160M,DYNTYPE=XCF <<<or>>> DISCNT=NO

MODEE VBUILD TYPE=MODEL EEMODEL PU DYNTYPE=EE,CAPACITY=100M,DISCNT=NO,DWINOP=YES, REDIAL=30,REDDELAY=60 <<<or>>> DISCNT=(DELAY,,60)

1. The SNASWITCH definitions used at CPREE4 are: snasw pdlog informationsnasw dlctracesnasw cpname USIBMWZ.CPREE4snasw dlus USIBMWZ.S193CDRMsnasw port ETH1 Ethernet1snasw port HPRIP hpr-ip Loopback0 vnname USIBMWZ.HPRIP1 no-limres ldlc 25 15 3snasw link UPL4006B port HPRIP ip-dest 172.16.2.121


Which Sessions Are Using Enterprise Extender?


How Do I Display Which CP-CP Sessions are Up?

First display from host that should have a certain number of CP-CP sessions and make sure that session count of conwinner/loser is equalRecall that "D NET,STATS,TYPE=VTAM" also shows you # of CP-CP sessions

D NET,SESSIONS,LIST=SUMMARY,SCOPE=ALL IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = SESSIONS 429 IST924I -------------------------------------------------- IST878I NUMBER OF PENDING SESSIONS = 0 IST924I -------------------------------------------------- IST878I NUMBER OF ACTIVE SESSIONS = 12 IST1162I LU-LU = 6 IST1162I CP-CP CONWINNER = 3 IST1162I CP-CP CONLOSER = 3 IST924I -------------------------------------------------- IST878I NUMBER OF QUEUED SESSIONS = 0 IST924I -------------------------------------------------- IST878I NUMBER OF TOTAL SESSIONS = 12 IST924I -------------------------------------------------- IST1161I SSCP SESSIONS IST1162I SSCP-LU = 9 IST1162I SSCP-PU = 3 IST1162I SSCP-SSCP = 0 IST314I END

D NET,SESSIONS,LIST=SUMMARY,SCOPE=ALLUSIBMWZ.S193CDRM

DLUSNNS

NN TCPT21

172.16.2.121 VLINK1

1. This display can reveal to you if all anticipated CP-CP sessions are up and running. Of course, you would have to know your network and understand the required CP-CP sessions that this node needs to be engaged in.



D NET,E,ID=S193CDRM,IDTYPE=CP IST097I DISPLAY ACCEPTED IST075I NAME = USIBMWZ.S193CDRM, TYPE = HOST CP 454 IST486I STATUS= ACT/S, DESIRED STATE= ACTIV ...IST171I ACTIVE SESSIONS = 0000000011, SESSION REQUESTS = 0000000000 IST206I SESSIONS: IST634I NAME STATUS SID SEND RECV VR TP NETID IST635I S192CDRM ACTIV/CP-S D87F747AA6E2284E D54C 0001 0 0 USIBMWZ IST635I S100CDRM ACTIV/SV-S D87F747AA6E22832 0011 001C 0 0 USIBMWZ IST635I CPREE4 ACTIV/SV-S D87F747AA6E2281C 0003 0003 0 0 USIBMWZ IST635I CPREE3 ACTIV/CP-S D87F747AA6E22806 000C 0001 0 0 USIBMWZ IST635I CPREE4 ACTIV/CP-S D87F747AA6E22804 000A 0001 0 0 USIBMWZ IST635I S192CDRM ACTIV/CP-P D87F780AAA3B001D 0001 D65B 0 0 USIBMWZ IST635I CPREE4 ACTIV-P C6FFA31F6EEAFBAB 0003 0004 0 0 USIBMWZ IST635I CPREE3 ACTIV-P C6E3A31F46C11D7F 000A 000D 0 0 USIBMWZ IST635I CPREE3 ACTIV/SV-P C6E3A31F46C11D7D 0001 0001 0 0 USIBMWZ IST635I CPREE3 ACTIV/CP-P C6E3A31F46C11D7B 0001 000C USIBMWZ IST635I CPREE4 ACTIV/CP-P C6FFA31F6EEAFB9A 0001 0010 USIBMWZ IST314I END

If number on previous page is not correct, display this command and check names of all ADJCPs with which you are supposed to have CP-CP sessions

Status of ACTIV/CP-S, ACTIV/CP-P

D NET,E,ID=<your_sscpname>,IDTYPE=CP


NN TCPT21

172.16.2.121 VLINK1

1. This display shows a lot of information. It identifies the names of all CPs with which SOME KIND of session exists. Note that only the ones marked ACTIV/CP-S or ACTIV/CP-P represent CP-CP sessions in this display. Other types of sessions exist with the CPs as well: CNOS sessions (ACTIV/SV-x) and LU-LU sessions (ACTIV-P).



D NET,E,ID=ISTADJCP IST097I DISPLAY ACCEPTED IST075I NAME = ISTADJCP, TYPE = ADJCP MAJOR NODE 297 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1100I ADJACENT CONTROL POINTS FROM MAJOR NODE ISTADJCP IST1102I NODENAME NODETYPE CONNECTIONS CP CONNECTIONS NATIVE IST1103I USIBMWZ.S192CDRM NN 1 1 *NA* IST1103I USIBMWZ.CPREE3 EN 1 1 *NA* IST1103I USIBMWZ.CPREE4 EN 1 1 *NA* IST1103I WZ1CDRM *NA* 0 0 *NA* IST1103I USIBMWZ.HPRIP1 VN 1 0 *NA* IST1493I RTP SUMMARY FOR USIBMWZ.S192CDRM COUNT = 2 IST1493I RTP SUMMARY FOR USIBMWZ.CPREE3 COUNT = 1 IST1493I RTP SUMMARY FOR USIBMWZ.CPREE4 COUNT = 1 IST314I END

This command looks promising, but it can be misleading. In reality it simply shows you the Adjacent CPs that have been learned about and placed in the Major Node ISTADJCP. "CP Connections" column only tells you how many are CPCP- capable.

It may not tell you anything about actual CP-CP sessions! See next visual.

D NET,E,ID=ISTADJCP at S193CDRM


NN TCPT21

172.16.2.121 VLINK1

1. This command shows you a column called "Connections" and another called "CP Connections." "Connections" indicates the number of connections to the adjacent Control Point. "CP Connections" indicates the number of those connections that are CP-CP-capable, but it does not necessarily show you that the CP-CP sessions are flowing over a particular connection.

2. Therefore, this display is not so useful in telling you that the connections are actually carrying CP-CP sessions. The next display (next page) is better for this knowledge.



D NET,ADJCP,ID=S192CDRM,SCOPE=ALL IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = ADJACENT CONTROL POINT 304 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1197I ADJCP MAJOR NODE = ISTADJCP IST1101I ADJCP DISPLAY SUMMARY FOR USIBMWZ.S192CDRM IST1102I NODENAME NODETYPE CONNECTIONS CP CONNECTIONS NATIVE IST1103I USIBMWZ.S192CDRM NN 1 1 *NA* IST1104I CONNECTION SUMMARY FOR USIBMWZ.S192CDRM IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS IST1106I EEPUSEC1 AC/R 13 YES 989A0000000000000000017100808080 IST1500I STATE TRACE = OFF IST1493I RTP SUMMARY FOR USIBMWZ.S192CDRM COUNT = 2 IST1486I RTP NAME STATE DESTINATION CP MNPS TYPE IST1487I CNR0002C CONNECTED USIBMWZ.S192CDRM NO CPCP IST1487I CNR0002B CONNECTED USIBMWZ.S192CDRM NO CPCP IST314I END D NET,ADJCP,ID=S192CDRM,SCOPE=ONLY IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = ADJACENT CONTROL POINT 307 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1197I ADJCP MAJOR NODE = ISTADJCP IST314I END

You may choose this command after seeing the RTP Summary available with the D NET,E,ID=ISTADJCP command from the previous page.

D NET,ADJCP,ID=<sscpname>,SCOPE=ONLY|ALLUSIBMWZ.S193CDRM

DLUSNNS

NN TCPT21

172.16.2.121 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

19.82.135.209 VLINK1

1. Another display -- D NET,ADJCP,<othersscpname>,SCOPE=ONLY|ALL displays the attributes of the specific adjacent node and the connection in which it is currently involved. 1. Note: With high performance routing (HPR), a control point does not have to be physically adjacent to be displayed by this

command. Each endpoint of an RTP connection considers the other endpoint an adjacent control point, even though there may be intermediate ANR-capable nodes between the two endpoints.

2. This command is valid only when it is issued at an APPN node (network node, end node, interchange node, or migration data host).

2. At least this display does tell you that you are using HPR for the CP-CP Sessions, But it does not tell you that the HPR pipe is flowing over EE. to see that, you must display the individual CNR Pipe. (See next page.)


How Do I Know the CP-CP Sessions Use EE? (1)

D NET,E,ID=CNR0002C IST097I DISPLAY ACCEPTED IST075I NAME = CNR0002C, TYPE = PU_T2.1 310 IST1392I DISCNTIM = 00060 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV--LX-, DESIRED STATE= ACTIV IST1043I CP NAME = S192CDRM, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = CPSVCMG IST1476I TCID X'31F6C51700000050' - REMOTE TCID X'31F5D15F0000007B'IST1481I DESTINATION CP USIBMWZ.S192CDRM - NCE X'D400000000000000' IST1587I ORIGIN NCE X'D400000000000000' IST1477I ALLOWED DATA FLOW RATE = 9800 KBITS/SEC IST1516I INITIAL DATA FLOW RATE = 4900 KBITS/SEC IST1841I ACTUAL DATA FLOW RATE = 0 KBITS/SEC IST1511I MAXIMUM NETWORK LAYER PACKET SIZE = 1461 BYTES IST1478I NUMBER OF UNACKNOWLEDGED BUFFERS = 0 IST1479I RTP CONNECTION STATE = CONNECTED - MNPS = NO IST1855I NUMBER OF SESSIONS USING RTP = 1 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 13 USIBMWZ.S192CDRM APPN RTP IST875I ALSNAME TOWARDS RTP = EEPUSEC1 IST1738I ANR LABEL TP ER NUMBER IST1739I 800C001C01000000 *NA* *NA* IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFFIST1500I STATE TRACE = OFF IST355I LOGICAL UNITS: IST080I S192CDRM ACT/S----Y IST314I END

D NET,E,ID=CNR0002CUSIBMWZ.S193CDRM

DLUSNNS

NN TCPT21

172.16.2.121 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

192.168.135.209 VLINK1

TG Number

Naming Convention can indicate EE Hop

Sessions on this RTP Pipe

1. The TG Number from this display tells you that the Pipe is flowing over Enterprise Extender -- but this is only because we have established a convention that indicates that TGN of 13 is for EE hops between z/OS nodes; TGN of 3 is for EE hops between a z/OS node and another EE Endpoint.

2. As you see from the display the Adjacent LinkStation (ALSname) name is indicated - since our naming convention uses the prefix of "EE" for Enterprise Extender Connections, we could assume that this connection is using EE. However someone else might have created a definition misusing our naming convention - so there has to be a more certain way of determining that this is using an EE hop.

3. Is there another way to determine this? But to verify this, you would display the EEPUSEC1 to see if the connection identifies IP address endpoints.


How Do I Know the CP-CP Sessions Use EE? (2)

D NET,E,ID=EEPUSEC1 IST097I DISPLAY ACCEPTED IST075I NAME = EEPUSEC1, TYPE = PU_T2.1 313 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1043I CP NAME = S192CDRM, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS IST1106I EEPUSEC1 AC/R 13 YES 989A0000000000000000017100808080 IST1482I HPR = RTP - OVERRIDE = N/A - CONNECTION = YES IST1510I LLERP = NOTPREF - RECEIVED = NOTALLOW IST1680I LOCAL IP ADDRESS 172.16.2.121 IST1680I REMOTE IP ADDRESS 192.168.135.209 IST136I SWITCHED SNA MAJOR NODE = EE2SEC1 IST081I LINE NAME = EL1009, LINE GROUP = EEGRPL1, MAJNOD = EEXCA IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST1657I MAJOR NODE VTAMTOPO = REPORT IST172I NO LOGICAL UNITS EXIST IST314I END

D NET,E,ID=EEPUSEC1


NN TCPT21

172.16.2.121 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

192.168.135.209 VLINK1

LIne Name is from EEXCA

IP Addresses Idenfitied

1. And you already know this trick: display the Adjacent Link Station and see if it associated with any IP addresses. 2. Here you see that it is -- therefore this is truly an Enterprise Extender link.


How to Discover whether DLUR/DLUS Pipes are Up (1)

D NET,DLURS IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = DLURS 832 IST1352I DLUR NAME DLUS CONWINNER STATE DLUS CONLOSER STATE IST1353I USIBMWZ.CPREE4 ACTIVE ACTIVE IST314I END

Cisco_4006B#sh snasw dlus Number of Dependent LU Servers 1 SNA Dependent LU Servers DLUS Name Default? Backup? Pipe State PUs ----------------- -------- ------- ---------------- ------- 1> USIBMWZ.S193CDRM Yes No Active 1

DLU

R-D

L US

CP

- CP

CISCO 4500


192.168.135.182

EN,BEX

DLUR


NN TCPT21

172.16.2.121 VLINK1

EE L

ink

Recall that "D NET,STATS,TYPE=VTAM" also tells you the number of DLUR/S sessions at a VTAM Node.

1. The z/OS command and the CISCO command both show you whether there are active DLUR/DLUS sessions or not. Even the D NET,STATS,TYPE=VTAM command that you saw earlier shows you whether there are active DLUS/DLUR sessions.



Adjacent Link Station is depicted as an RTP PipePU supported by the DLUR node displayed with IST1355I

D NET,E,ID=CPREE4 IST097I DISPLAY ACCEPTED IST075I NAME = USIBMWZ.CPREE4, TYPE = ADJACENT CP 852 IST486I STATUS= ACT/S----Y, DESIRED STATE= ACTIV ...IST934I DLOGMOD=CPSVCMG USS LANGTAB=***NA*** IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT NONE IST231I CDRSC MAJOR NODE = ISTCDRDY IST1184I CPNAME = USIBMWZ.CPREE4 - NETSRVR = ***NA*** IST1044I ALSLIST = ISTAPNPU ...IST171I ACTIVE SESSIONS = 0000000005, SESSION REQUESTS = 0000000000 IST206I SESSIONS: IST1081I ADJACENT LINK STATION = CNR00006 IST634I NAME STATUS SID SEND RECV VR TP NETIDIST634I NAME STATUS SID SEND RECV VR TP NETID IST635I S193CDRM ACTIV/DL-S C6FFA31F6EEAFB9D 000A 0000 0 0 USIBMWZ IST635I S193CDRM ACTIV/SV-P D87F747AA6E2281C 0002 0002 0 0 USIBMWZ IST635I S193CDRM ACTIV/DL-P D87F747AA6E22815 0000 0008 0 0 USIBMWZ IST1081I ADJACENT LINK STATION = CNR00001 IST634I NAME STATUS SID SEND RECV VR TP NETID IST635I S193CDRM ACTIV/CP-S C6FFA31F6EEAFB9A 0007 0001 USIBMWZ IST635I S193CDRM ACTIV/CP-P D87F747AA6E22804 0001 0004 0 0 USIBMWZ IST1355I PHYSICAL UNITS SUPPORTED BY DLUR USIBMWZ.CPREE4 IST089I EEDLP1 TYPE = PU_T2.1 , ACTIV IST924I ------------------------------------------------------------- IST075I NAME = USIBMWZ.CPREE4, TYPE = DIRECTORY ENTRY IST1186I DIRECTORY ENTRY = REGISTERED EN IST1184I CPNAME = USIBMWZ.CPREE4 - NETSRVR = USIBMWZ.S193CDRM IST314I END

DLU

R-D

L US

CP

- CP

CISCO 4500


192.168.135.182

EN,BEX

DLUR


NN TCPT21

172.16.2.121 VLINK1

EE L

ink

1. This command is particularly useful, because it even tells you the names of the PUs supporting Dependent LUs that are supported by a specific DLUR node.

2. Not ethe special type of Status Code that is reserved for the CPSRVRMGR Pipe that is established for DLUR/DLUS connectivity: ACTIV/DL-S or ACTIV/DL-P.



Cisco3825B>sh snasw dlus detail Number of Dependent LU Servers 1 1> DLUS name USIBMWZ.S193CDRM Is this the default DLUS Yes Is this the backup default DLUS No Pipe state Active Number of active PUs 1 DLUS pipe statistics: REQACTPUs sent 1 REQACTPU responses received 1 ACTPUs received 1 ACTPU responses sent 1 DACTPUs received 0 DACTPU responses sent 0 REQDACTPUs sent 0 REQDACTPU responses received 0 ACTLUs received 2 ACTLU responses sent 2 DACTLUs received 0 DACTLU responses sent 0 SSCP-PU MUs sent 0 SSCP-PU MUs received 0

sh snasw dlus detail

DLU

R-D

LUS

CP

- CP

CISCO 4500


192.168.135.182

EN,BEX

DLUR


NN TCPT21

172.16.2.121 VLINK1

EE L

ink

1. This shows you the DLUS/DLUR Pipe from the Cisco perspective.


How to Discover Which Sessions Use DLUR/DLUS

Cisco3825B>sh snasw session Number of local endpoint sessions 5 SNA Local Endpoint Sessions PCID (hex) Partner LU Name Link/RTP Mode COS ---------------- ----------------- --------- -------- ------- 1> D87F747AA6E2281C USIBMWZ.S193CDRM @R000086 SNASVCMG SNASVCMG 2> D87F747AA6E22815 USIBMWZ.S193CDRM @R000086 CPSVRMGR SNASVCMG 3> C6FFA31F6EEAFB9D USIBMWZ.S193CDRM @R000086 CPSVRMGR SNASVCMG 4> D87F747AA6E22804 USIBMWZ.S193CDRM @R000085 CPSVCMG CPSVCMG 5> C6FFA31F6EEAFB9A USIBMWZ.S193CDRM @R000085 CPSVCMG CPSVCMG Number of intermediate sessions 1 SNA Intermediate Sessions PCID (hex) Primary LU Name Secondary LU Name Mode COS ---------------- ----------------- ----------------- -------- ------- 1> D87F747AA6E22821 USIBMWZ.S193CDRM CSSNET.CPGWPCOM SNASVCMG SNASVCMG Number of intermediate DLUR sessions 2 SNA DLUR Assisted Intermediate Sessions PCID (hex) Primary LU Name Secondary LU Name Mode COS ---------------- ----------------- ----------------- -------- ------- 1> D87F780AAA3B0004 USIBMWZ.F1920001 CSSNET.EEDL13 #CONNECT 2> D87F747AA6E2281B USIBMWZ.F1930002 CSSNET.EEDL12 #CONNECT

sh snasw dlus session

EEDL12EEDL13

CISCO 4500


192.168.135.182

EN,BEX

DLUR


192.168.135.209 VLINK1


DLUSNNS

NN NNTCPT11 TCPT21

172.16.2.121 VLINK1

EE LinkTg 13

Tg 21 Tg 21

Tg 1

Tg 1

1. This is a very helpful command to show you what is being supported with DLUR/DLUS. Note that it displays not only the Session IDs (PCIDs) supported between the CISCO APPN Node and other nodes with the logmode used to establish the sessions, but it also shows the Intermediate Sessions -- in this case an intermediate APPN CNOS session between the CP in the downstream PU.

2. It also shows you two downstream dependent LU sessions being supported through DLUR/DLUS.


How to Discover Which LUs Use DLUR/DLUS

Cisco3825B>sh snasw puNumber of DLUR PUs 1

SNA DLUR PUs PU Name PU ID State DLUS Name -------- -------- --------------- ----------------- 1> EEDLP1 05D02481 Active USIBMWZ.S193CDRM

Cisco3825B>sh snasw lu Number of DLUR LUs 2 SNA DLUR LUs LU Name PU Name DLUS Name PLU Name -------- -------- ----------------- ----------------- 1> EEDL12 EEDLP1 USIBMWZ.S193CDRM USIBMWZ.F1930002 2> EEDL13 EEDLP1 USIBMWZ.S193CDRM USIBMWZ.F1920001

sh snasw pu / lu

EEDL12EEDL13

CISCO 4500


192.168.135.182

EN,BEX

DLUR


192.168.135.209 VLINK1


DLUSNNS

NN NNTCPT11 TCPT21

172.16.2.121 VLINK1

EE LinkTg 13

Tg 21 Tg 21

Tg 1

Tg 1

1. These commands give you another snapshot to see information about DLUR/DLUS from the perspective of the SNASwitch node.

2. You may also execute these commands with the "detail" operand to see more information.


How to Know an LU-LU Session Uses EE over a VN (1)

D NET,E,ID=EEDL12 IST097I DISPLAY ACCEPTED IST075I NAME = CSSNET.EEDL12, TYPE = CDRSC 640 IST486I STATUS= ACT/S----Y, DESIRED STATE= ACTIV IST1447I REGISTRATION TYPE = NO IST977I MDLTAB=***NA*** ASLTAB=***NA*** IST1333I ADJLIST = ***NA*** IST861I MODETAB=ISTINCLM USSTAB=***NA*** LOGTAB=***NA*** IST934I DLOGMOD=#CONNECT USS LANGTAB=***NA*** IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT NONE IST231I CDRSC MAJOR NODE = ISTCDRDY IST479I CDRM NAME = S100CDRM, VERIFY OWNER = NO IST1184I CPNAME = USIBMWZ.CPREE4 - NETSRVR = ***NA*** IST082I DEVTYPE = INDEPENDENT LU / CDRSC IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST228I ENCRYPTION = NONE , TYPE = DES IST1563I CKEYNAME = EEDL12 CKEY = PRIMARY CERTIFY = NO IST1552I MAC = NONE MACTYPE = NONE IST171I ACTIVE SESSIONS = 0000000001, SESSION REQUESTS = 0000000000 IST206I SESSIONS: IST1081I ADJACENT LINK STATION = CNR0003A IST634I NAME STATUS SID SEND RECV VR TP NETID IST635I F1000002 ACTIV-P D81B8F2A73BC7792 0000 0001 0 0 USIBMWZ IST924I ------------------------------------------------------------- IST075I NAME = CSSNET.EEDL12, TYPE = DIRECTORY ENTRY IST1186I DIRECTORY ENTRY = DYNAMIC LU IST1184I CPNAME = USIBMWZ.CPREE4 - NETSRVR = USIBMWZ.S193CDRM IST484I SUBAREA = ****NA**** IST1703I DESIRED LOCATE SIZE = 1K LAST LOCATE SIZE = 16K IST314I END

D NET,E,ID=<luname in session> at S100CDRM

VN = Virtual Node (i.e., Connection Network, AKA Virtual Routing Node-VRN)You cannot tell from this display that the session is using EE over Connection Network.

Display the Session ID

192.168.25.34 VLINK1

USIBMWZ.S100CDRM

NN

IP Network

IP Network

CISCO 2610


192.168.135.181

EN,BEX CISCO 4500


192.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1


DLUSNNS


172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1Tg 1

1. VN stands for Virtual Node, or for a Connection Network.2. If the Connection Network link terminates on the node at which you are displaying the commands, you may use D

NET,RSCLIST,ID=<DYNVNPFX*> to obtain the connection network punames. 3. If the Connection Network link does not terminate on the node from which you are executing the commands, you must execute

commands to view the routing path to determine if Connection Network is in use.4. If we can trust our naming convention, you could assume that the session is flowing over Enterprise Extender. But you cannot

always trust the naming convention. 1. However, you know how to display the PUs and the RTP Pipes that the lu is using -- so that could tell you that this is indeed

over Enterprise Extender.5. Now, how do you know that it is using Connection Netowrk?6. You can display the RTP Pipe and see if a Connection Network Name shows up in the routing path. 7. Or ... you could display the PU for the session and see if is using the prefix assigned to Connection Network. In our case that

prefix would be "V1" set by DYNPUPFX in the XCA Major Node Group statement. But this trick won't work unless the connection network pu terminates on the node from which you are taking the display.



D NET,SESSIONS,SID=D81B8F2A73BC7792 IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = SESSIONS 643 IST879I PLU/OLU REAL = USIBMWZ.F1000002 ALIAS = CSSNET.F1000002 IST879I SLU/DLU REAL = CSSNET.EEDL12 ALIAS = USIBMWZ.EEDL12 IST880I SETUP STATUS = ACTIV IST875I ADJSSCP TOWARDS SLU = ISTAPNCP IST875I ALSNAME TOWARDS SLU = CNR0003A IST933I LOGMODE=SNX32703, COS=*BLANK* IST875I APPNCOS TOWARDS SLU = #CONNECT IST1635I PLU HSCB TYPE: FMCB LOCATED AT ADDRESS X'1A422158' IST1635I SLU HSCB TYPE: BSB LOCATED AT ADDRESS X'19F18678' IST1636I PACING STAGE(S) AND VALUES: IST1644I PLU--STAGE 1-----|-----STAGE 2--SLU IST1638I STAGE1: PRIMARY TO SECONDARY DIRECTION - ADAPTIVE IST1639I PRIMARY SEND: CURRENT = 0 NEXT = 7 IST1640I SECONDARY RECEIVE = 7 IST1641I STAGE1: SECONDARY TO PRIMARY DIRECTION - ADAPTIVE IST1642I SECONDARY SEND: CURRENT = 1 NEXT = 1 IST1643I PRIMARY RECEIVE = 32767 IST1638I STAGE2: PRIMARY TO SECONDARY DIRECTION - ADAPTIVE IST1639I PRIMARY SEND: CURRENT = 0 NEXT = 7 IST1641I STAGE2: SECONDARY TO PRIMARY DIRECTION - ADAPTIVE IST1643I PRIMARY RECEIVE = 128 IST1713I RTP RSCV IN THE DIRECTION OF THE SLU IST1460I TGN CPNAME TG TYPE HPR IST1461I 13 USIBMWZ.S192CDRM APPN RTP IST1461I 21 USIBMWZ.HPRIP1 APPN RTP IST1461I 1 USIBMWZ.CPREE4 APPN RTP IST314I END

D NET,SESSIONS,SID=... at S100CDRM

VN = Virtual Node (i.e., Connection Network)

next page

192.168.25.34 VLINK1

USIBMWZ.S100CDRM

NN

IP Network

IP Network

CISCO 2610


192.168.135.181

EN,BEX CISCO 4500


192.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1


DLUSNNS


172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1Tg 1

1. VN stands for Virtual Node, or for a Connection Network.2. Now, if you display the Session ID (SID) of the session, the output depicts the APPN routing path for you. There you see the

Connection Network Name of HPRIP1 that was assigned in the XCA Major Node with "VNNAME." 3. Note that a display using an "EE TG" of 13 or 3 doesn't help us with Connection Network even if we are displaying from the VN

endpoint node -- that's because Connection Network at z/OS dynamically assigns TGN of 21 (or 2n) to the EE connection. And, in fact, even with Model Major Nodes, there is no way to hardcode a TGN for connection network, so the TG number of 21 becomes meaningless in and of itself, because it could be representing a native APPN connection or it could be EE. The only way to hardcode a TG number for Connection Network is to use the Configuration Services XID Exit (ISTEXCCS) -- the provided sample in SYS1.SAMPLIB provides only a stub definition for Connection Network, so you would have to figure that one out for yourself!1. By the way, Connection Network at other platforms -- e.g., SNASwitch -- provides a TGN of 1 to the VN Link.


D NET,E,ID=CNR0003A IST097I DISPLAY ACCEPTED IST075I NAME = CNR0003A, TYPE = PU_T2.1 651 IST1392I DISCNTIM = 00010 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV--LX-, DESIRED STATE= ACTIV IST1043I CP NAME = CPREE4, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = #CONNECT IST1476I TCID X'323543610000007D' - REMOTE TCID X'0000000077000000' IST1481I DESTINATION CP USIBMWZ.CPREE4 - NCE X'80' IST1587I ORIGIN NCE X'D000000000000000' ...IST1855I NUMBER OF SESSIONS USING RTP = 1 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 13 USIBMWZ.S192CDRM APPN RTP IST1461I 21 USIBMWZ.HPRIP1 APPN RTP IST1461I 1 USIBMWZ.CPREE4 APPN RTP IST875I ALSNAME TOWARDS RTP = EEPUSEC1 IST1738I ANR LABEL TP ER NUMBER IST1739I 800C003001000000 *NA* *NA* IST1739I 801B002201000000 *NA* *NA* IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST355I LOGICAL UNITS: IST080I EEDL12 ACT/S----Y IST314I END

D NET,E,ID=CNR0003A at S100CDRM

VN = Virtual Node (i.e., Connection Network)Display taken at S100CDRM

There is no Connection Network in this Node, so the Connection Network Naming Convention for VN PUs Does not help us here!


192.168.25.34 VLINK1

USIBMWZ.S100CDRM

NN

IP Network

IP Network

CISCO 2610


192.168.135.181

EN,BEX CISCO 4500


192.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1


DLUSNNS


172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1Tg 1

1. VN stands for Virtual Node, or for a Connection Network.2. Also recall that displaying the CNR pipe associated with the session also gives you the routing path information, indicating that

Connection Network is in use.


How to Know Which LUs Are Using an RTP Pipe

D NET,E,ID=CNR0003A IST097I DISPLAY ACCEPTED IST075I NAME = CNR0003A, TYPE = PU_T2.1 651 IST1392I DISCNTIM = 00010 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV--LX-, DESIRED STATE= ACTIV IST1043I CP NAME = CPREE4, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = #CONNECT IST1476I TCID X'323543610000007D' - REMOTE TCID X'0000000077000000' IST1481I DESTINATION CP USIBMWZ.CPREE4 - NCE X'80' IST1587I ORIGIN NCE X'D000000000000000' ...IST1855I NUMBER OF SESSIONS USING RTP = 1 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 13 USIBMWZ.S192CDRM APPN RTP IST1461I 21 USIBMWZ.HPRIP1 APPN RTP IST1461I 1 USIBMWZ.CPREE4 APPN RTP IST875I ALSNAME TOWARDS RTP = EEPUSEC1 IST1738I ANR LABEL TP ER NUMBER IST1739I 800C003001000000 *NA* *NA* IST1739I 801B002201000000 *NA* *NA* IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST355I LOGICAL UNITS: IST080I EEDL12 ACT/S----Y IST314I END

D NET,E,ID=CNR0003A at S100CDRM

This is the same view as on the previous page!

You can display a specific RTP Pipe and also see which LUs are using it!You can display the LU itself to see if there are multiple sessions for it.

192.168.25.34 VLINK1

USIBMWZ.S100CDRM

NN

IP Network

IP Network

CISCO 2610


192.168.135.181

EN,BEX CISCO 4500


192.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1


DLUSNNS


172.16.2.121 VLINK1


EE LinkTg 13

Tg 21 Tg 21

Tg 1Tg 1

1. VN stands for Virtual Node, or for a Connection Network.


And at V1R5 of z/OS

Various filters, like CPNAME, already existed on the D NET,RTPS command prior to V1R5. At V1R5 "firsttg," "firstcp," and "alsname" were added.Adjacent Link Station is depicted as an RTP Pipe if a session is flowing and session endpoint is in the node from which you are displaying!Otherwise use previous commands and filter on recognizable EE Endpoint names, PUnames, or on recognizable TG Numbers

e.g., TGN=3e.g., TGN=13

May still need to display individual RTP.

D NET,RTPS,FIRSTTG=13 ...IST1695I PU NAME CP NAME COS NAME SWITCH CONGEST SESSIONS IST1696I CNR0003A USIBMWZ.CPREE4 #CONNECT NO NO 1 IST1696I CNR00039 USIBMWZ.S192CDRM RSETUP NO NO 0 IST1696I CNR00038 USIBMWZ.S192CDRM CPSVCMG NO NO 2 IST1454I 3 RTP(S) DISPLAYED D NET,RTPS,FIRSTCP=S192CDRM ...IST1695I PU NAME CP NAME COS NAME SWITCH CONGEST SESSIONS IST1696I CNR0003A USIBMWZ.CPREE4 #CONNECT NO NO 1 IST1696I CNR00039 USIBMWZ.S192CDRM RSETUP NO NO 0 IST1696I CNR00038 USIBMWZ.S192CDRM CPSVCMG NO NO 2 IST1454I 3 RTP(S) DISPLAYED D NET,RTPS,CPNAME=USIBMWZ.* ...IST1695I PU NAME CP NAME COS NAME SWITCH CONGEST SESSIONS IST1696I CNR0003A USIBMWZ.CPREE4 #CONNECT NO NO 1 IST1696I CNR00039 USIBMWZ.S192CDRM RSETUP NO NO 0 IST1696I CNR00038 USIBMWZ.S192CDRM CPSVCMG NO NO 2 ...

D NET,RTPS,FIRSTTG=... | FIRSTCP=... | CPNAME=... | ALSNAME=...

1. The new displays in V1R5 show you where sessions are -- they do not show you that you are using an EE Connection explicitly, since many of these pipes could have been established over non-EE links.1. If you have a TG numbering convention, however, this could tell you that you have at least predefined EE connections/TGs, as

in the first example depicted.2. However you must also be aware of the fact that the Connection Network TG number at z/OS defaults to 21 (or 2n), and could

thus be confused with other native APPN TGs if you filtered using 'FIRSTTG=21.'2. Therefore you may still need to display the CNR pipes to determine whether they are using EE TGs, including Connection

Network.3. Restriction: The CPNAME and FIRSTCP operands of the D NET,RTPS operator command allow a very restricted use of the

asterisk. Their use of the asterisk may only be of the form netid.*, and is not governed by the DSPLYWLD start option. ALSNAME allows no wildcard at all.1. Following are two examples of the use of the asterisk for the D NET,RTPS operands:

1. CPNAME=NETA.*1. Only HPR pipes whose destination CP is in the netid of NETA are displayed.

2. FIRSTCP=NETB.*


And at V1R5 of z/OS ...

The filters can be combined to provide even more granularity. At V1R6 the column "STALL" was added to the displays to indicate that the pipe is stalled and a retransmit request from a partner is ignored.

Underlying DLC is performing poorly, or pathswitch in progress

D NET,RTPS,ALSNAME=EEPUSEC1 IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 574 IST1695I PU NAME CP NAME COSNAME SWITCH CONGEST STALL SESS IST1960I CNR00010 USIBMWZ.CPREE4 #INTER NO NO NO 1 IST1960I CNR0000B USIBMWZ.S193CDRM SNASVCMG NO NO NO 1 IST1960I CNR0000A USIBMWZ.S192CDRM RSETUP NO NO NO 0 IST1960I CNR00009 USIBMWZ.S192CDRM CPSVCMG NO NO NO 1 IST1960I CNR00008 USIBMWZ.S192CDRM CPSVCMG NO NO NO 1 IST1454I 5 RTP(S) DISPLAYED

D NET,RTPS,APPNCOS=#INTER IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 582 IST1358I NO QUALIFYING MATCHES IST1454I 0 RTP(S) DISPLAYED IST314I END

D NET,RTPS,ALSNAME=EEPUSEC1,APPNCOS=#INTER IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 630 IST1695I PU NAME CP NAME COSNAME SWITCH CONGEST STALL SESS IST1960I CNR00018 USIBMWZ.CPREE4 #INTER NO NO NO 1 IST1960I CNR00017 USIBMWZ.S192CDRM #INTER NO NO NO 0 IST1960I CNR00016 USIBMWZ.S193CDRM #INTER NO NO NO 0 IST1454I 3 RTP(S) DISPLAYED IST314I END


V1R6

IST1955I STALL DETECTED FOR RTP puname TO cpnameIST1955I STALL CONTINUES FOR RTP puname TO cpnameIST1955I STALL ALLEVIATED FOR RTP puname TO cpname

V1R6

1. Here you see in the third display that you can combine the filters for more granularity.2. At V1R6 the displays and additional unsolicited messages show whether an RTP pipe is stalled/hung or not.



If you receive calls about performance problems, you can look at the "CONGEST" or the "STALL" column or you might combine the "CONGEST=YES" parameter with another filter, as you see here.NOTE: If an RTP pipe is in the process of a path switch, it will appear as "congested."

D NET,RTPS,CPNAME=CPREE4 IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 665 IST1695I PU NAME CP NAME COSNAME SWITCH CONGEST STALL SESS IST1960I CNR0001C USIBMWZ.CPREE4 #INTER NO NO NO 1 IST1454I 1 RTP(S) DISPLAYED IST314I END

D NET,RTPS,CONGEST=YES,FIRSTCP=S192CDRM IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 668 IST1358I NO QUALIFYING MATCHES IST1454I 0 RTP(S) DISPLAYED IST314I END

D NET,RTPS,ALSNAME=EEPUSEC1,CONGEST=YES IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 676 IST1358I NO QUALIFYING MATCHES IST1454I 0 RTP(S) DISPLAYED IST314I END


V1R6



There are a number of network management tools available for monitoring and problem diagnosis with TCP/IP and SNA. However, no existing single operator command provides access to Enterprise Extender specific network management and problem diagnosis information.

"D NET,EE" provides more information than a single other command does.

IST097I DISPLAY ACCEPTEDIST350I DISPLAY TYPE = RTPSIST1695I PU NAME CP NAME COSNAME SWITCH CONGEST STALL SESSIST1960I CNR00007 NETA.SSCPAA #INTER NO NO NO 1IST1454I 1 RTP(S) DISPLAYEDIST314I END

D NET,RTPS,TCID=14AB300100010020

D NET,EE,IPADDR=9::67:1:1,HOSTNAME=(,VIPA16.SSCP2A.TCP.RALEIGH.IBM.COM)IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = EE IST2001I ENTERPRISE EXTENDER CONNECTION INFORMATION IST924I ------------------------------------------------------------- IST1680I LOCAL IP ADDRESS 9::67:1:1 IST1910I LOCAL HOSTNAME VIPA16.SSCP1A.TCP.RALEIGH.IBM.COM IST1680I REMOTE IP ADDRESS 9::67:1:2 IST1909I REMOTE HOSTNAME VIPA16.SSCP2A.TCP.RALEIGH.IBM.COM IST2022I EE CONNECTION ACTIVATED ON 09/12/03 AT 09:27:15 IST2023I CONNECTED TO LINE LNEE1000 IST2024I CONNECTED TO SWITCHED PU SWEE2A1 IST2025I LDLC SIGNALS RETRANSMITTED AT LEAST ONE TIME = 0 IST2026I LDLC SIGNALS RETRANSMITTED SRQRETRY TIMES = 0 IST2009I RTP PIPES = 7 LU-LU SESSIONS = 6 IST2027I DWINOP = NO REDIAL = *NA* REDDELAY = *NA* IST2028I KEEPACT = NO IST2029I MTU SIZE = 1232 IST924I ------------------------------------------------------------- IST2035I TOTALS FOR ALL PORT PRIORITIES IST2036I NLPS SENT = 95182 ( 095K ) IST2037I BYTES SENT = 10787917 ( 010M ) IST2038I NLPS RETRANSMITTED = 0 ( 000K ) IST2039I BYTES RETRANSMITTED = 0 ( 000K ) IST2040I NLPS RECEIVED = 95227 ( 095K ) IST2041I BYTES RECEIVED = 9756692 ( 009M ) IST2042I 1 OF 1 EE CONNECTIONS DISPLAYED IST314I END

D NET,EE,...

1. The DISPLAY RTPS command is expanded in z/OS V1R6 to include the new TCID= operand, which allows an RTP PU to be found and displayed by its Local TCID.1. TCIDs are only guaranteed to be unique within the host that generated them. Therefore, only the Local TCID is guaranteed to

be unique within the local host, so only the Local TCID can be specified on the TCID= operand of the DISPLAY RTPs command.

2. Because the DISPLAY RTPS,TCID= command always identifies (at most) a single RTP PU, the TEST= operand (to request an HPR Route Test) can now be specified with either the ID= or TCID= operand (but not both).

2. A new VTAM display command, DISPLAY EE, has been provided in z/OS V1R6 to better manage Enterprise Extender networks. Various formats of the new display give the operator the ability to obtain:1. ENTERPRISE EXTENDER GENERAL

1. D NET,EE,LIST=SUMMARY2. D NET,EE,LIST=DETAIL

2. ENTERPRISE EXTENDER INDIVIDUAL and AGGREGATE CONNECTION INFORMATION1. D NET,EE,NAME=<line or puname>,LIST=SUMMARY|DETAIL2. D NET,EE,IPADDR=<ipaddr of EE endpoint --" local" and/or ",remote">,LIST=SUMMARY|DETAIL3. D NET,EE,HOSTNAME=<hostname of EE endpoint -- "local" and/or ",remote">,LIST=SUMMARY|DETAIL

1. The hostname that represents the EE Endpoint as known to the DNS4. Various combinations of above parameters


And at V1R7 of z/OS: RTPS Summary

LIST=SUMMARYProvides a Count of CPSVCMG RTP Pipes, vs. CPSVCMG RTP Pipes, vs. RTP Pipes used for LU-LU session pipes, etc.

D NET,RTPS,FIRSTCP=NETA.SSCP2A,LIST=SUMMARYIST097I DISPLAY ACCEPTEDIST350I DISPLAY TYPE = RTPSIST2075I DISPLAY RTPS SUMMARY INFORMATIONIST2076I TOTAL MATCHING PIPES = 5IST2077I CPSVCMG PIPES = 2IST2078I RSETUP PIPES = 1IST2079I LU-LU PIPES = 2IST2080I PATH SWITCHING PIPES = 0IST2081I CONGESTED PIPES = 0IST2082I STALLED PIPES = 0IST2083I SESSIONS = 4IST314I END

D NET,RTPS,FIRSTCP=NETA.SSCP2A,LIST=SUMMARY

1. The D RTPS command has been enhanced at V1R7 to add a LIST=DETAIL | SUMMARY option. The default will be LIST=DETAIL and will display the same information as it does currently. The new LIST=SUMMARY option will provide a summary of the matching RTP pipes.


Where to Filter by TGNDisplay a specific TG or TGs:

DISPLAY NET,TOPO ,ORIG=... ,DEST=... ,TGN=nn[,APPNCOS=...]

Display CNR Pipes whose first hop is over a specific TG:

D NET,RTPS,ID=...,FIRSTTG=nn

Modify the TGP of a specific Transmission Group / Link

F procname,TGP,TGPNAME=BATCH,ID=...,TGN=..

Delete a TG or Modify the status of a TG to influence route calculation:

F <vtamproc>,TOPO,ORIG=... ,DEST=... ,TGN=nn,TYPE=FORCE

F <vtamproc>,TOPO,FUNCTION=QUIESCE|NORMAL,ORIG=... ,DEST=... ,TGN=nn

1. This page simply shows you that there are a number of commands for which you can use a TG number to filter by. That's why you might want to consider using different TGNs for different types of connections.1. I tend to use different TGs only for different types of EE connectiions, but you might even expand on this idea by assigning

different TG numbers for different types of native APPN connectivity. The only problem with this approach is that when the technology changes, the TG number could become meaningless.


Summary: Discovering that a TG is using Connection Network?

D NET,RSCLIST,ID=V1* IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RSCLIST 792 IST1417I NETID NAME STATUS TYPE MAJNODE IST1418I USIBMWZ V1000382 ACTIV---X- PU_T2.1 ISTDSWMN IST1454I 1 RESOURCE(S) DISPLAYED FOR ID=V1*

D NET,RTPS,FIRSTCP=HPRIP1 IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = RTPS 379 IST1358I NO QUALIFYING MATCHES IST1454I 0 RTP(S) DISPLAYED IST314I END

D NET,RSCLIST,ID=<dynvnpfx*>Look for Connection Network Name in displays of RTP pipes that the session is flowing over

e.g., "HPRIP1"Look for PUnames that follow Connection Network Naming Convention:

DYNVNPFX in VTAM Start OptionsDYNVNPFX in XCA Major Node

If you know the prefix and are at a node attached to a Connection Network, issue:

D NET,RSCLIST,ID=<dynvnpfx*>

At V1R5: "FIRSTCP=<VNname> on D NET,RTPS

D NET,RTPS,FIRSTCP=<vnname>

1. Prefix for the name of a Link-Station PUs to reach a Connection Network may have defaulted to: 1. DYNVNPFX in the VTAM Start Options2. DYNVNPFX on the GROUP statement of the XCA Major Node********************************* Top of Data ***************************EEXCA VBUILD TYPE=XCA * ------------------------------------------------------------------- * * XCA FOR ENTERPRISE EXTENDER WITH CONNECTION NETWORK * * ------------------------------------------------------------------- * * CHANGE RECORD WHO? WHEN? * ...* EEPORT PORT MEDIUM=HPRIP, X IPTOS=(20,40,80,C0,C0),LIVTIME=25,IPPORT=12000, X SAPADDR=4,SRQRETRY=3,SRQTIME=15, X TGP=EEXTWAN,CAPACITY=100M, X VNNAME=HPRIP1,VNGROUP=EEGRPL1,VNTYPE=LOCAL EEGRPL1 GROUP DIAL=YES,AUTOGEN=(10,EL1,EP1),DYNVNPFX=V1, X DYNPU=NO,KEEPACT=YES, X CALL=INOUT,ISTATUS=ACTIVE


Performance

At V1R6Messages

New messages for Stalled PipesUnsolicited Messages

Enhancements to displays with HPRDIAG=YESAt V1R7

Display Enhancements and New "D NET,EEDIAG"


How to Know Performance Characteristics of an RTP Pipe (1)

D NET,E,ID=CNR00371,HPRDIAG=YES IST097I DISPLAY ACCEPTED IST075I NAME = CNR00371, TYPE = PU_T2.1 964 IST1392I DISCNTIM = 00060 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV--LX-, DESIRED STATE= ACTIV IST1043I CP NAME = CPREE4, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = #CONNECT IST1476I TCID X'31F5D13400000089' - REMOTE TCID X'000000005B000000' IST1481I DESTINATION CP USIBMWZ.CPREE4 - NCE X'80' IST1587I ORIGIN NCE X'D000000000000000' IST1477I ALLOWED DATA FLOW RATE = 798 KBITS/SEC IST1516I INITIAL DATA FLOW RATE = 4900 KBITS/SEC IST1841I ACTUAL DATA FLOW RATE = 1 KBITS/SEC IST1511I MAXIMUM NETWORK LAYER PACKET SIZE = 1447 BYTES IST1478I NUMBER OF UNACKNOWLEDGED BUFFERS = 0 IST1479I RTP CONNECTION STATE = CONNECTED - MNPS = NO IST1855I NUMBER OF SESSIONS USING RTP = 1 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 21 USIBMWZ.HPRIP1 APPN RTP IST1461I 1 USIBMWZ.CPREE4 APPN RTP IST875I ALSNAME TOWARDS RTP = V100036F IST1738I ANR LABEL TP ER NUMBER IST1739I 8010002001000000 *NA* *NA* ...

D NET,E,ID=<rtpname>,HPRDIAG=YES at S192CDRM

IP Network

CISCO 4500

USIBMWZ.CPREE4Loopback1

92.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

Connection Network PU

Monitor VTAM TIBUF Buffer allocations and expansionsUse D NET,SESSIONS,SID= at V1R7 to in/outbound RUsizes!

1. IST1477I ALLOWED DATA FLOW RATE = allowed units1. allowed is the allowed rate at which data can be sent over the RTP connection at the instant in time this message is displayed.2. units is the units of measure for the rate and is displayed in bits, kilobits, or megabits per seconds (BITS/SEC, KBITS/SEC, or

MBITS/SEC).3. The data flow rate is updated approximately every second while data is flowing.

2. IST1516I INITIAL DATA FLOW RATE = initial units 1. initial is the initial data flow rate for this Rapid Transfer Protocol (RTP) connection.2. units is the units of measure for the rate and is displayed in bits, kilobits, or megabits per seconds (BITS/SEC, KBITS/SEC, or

MBITS/SEC).3. IST1841I ACTUAL DATA FLOW RATE = actual units

1. If no data is flowing, this could indicate that there is truly no data flowing at this point in time due to the application behavior, or ... it could mean that the pipe is hung. If the pipe is hung, then you would usually see message IST1478I (Number of unacknowledged buffers) with a non-zero value. 1. This situation can occur if jumbo frames are used on one side of the connection and not on another, causing packets to be

dropped or lost in transit. 4. IST1511I Maximum Network Layer Packet Size

1. size is the maximum size of a network layer packet (NLP) that can be sent over this Rapid Transfer Protocol (RTP) connection in bytes.

2. For Enterprise Extender, VTAM's maximum BTU length the sender can receive is calculated as follows:3. Max_Receive_Size= 4. MAX((MIN(TCP/IP MTU SIZE -3),32767),768)

1. Because excessive segmenting can occur in the effort to conform to maximum data size requirements, you should optimizethe maximum received data size. Failure to do so can result in the following:

2. Inefficient TIPAC (I/O) buffer allocation. (TIBUF is a storage pool for TIPACs)3. Excessive TIPAC (I/O) buffer pool expand operations, (TIBUF is a storage pool for TIPACs)4. Degraded data transmission performance


How to Know Performance Characteristics of an RTP Pipe (2)

...IST1860I NUMBER OF NLPS SENT = 298 - OVERFLOW = 0 IST1861I NUMBER OF NLPS RECEIVED = 347 - OVERFLOW = 0 IST1842I NUMBER OF NLPS RETRANSMITTED = 0 IST1843I NUMBER OF NLPS ON WAITING-TO-SEND QUEUE = 0 IST1847I NUMBER OF NLPS ON WAITING-FOR-ACKNOWLEDGEMENT QUEUE = 0 IST1862I ARB MAXIMUM SEND RATE = 15974 KBITS/SEC IST1844I ARB MODE = GREEN IST1846I CURRENT RECEIVER THRESHOLD = 37000 MICROSECONDS IST1846I MAXIMUM RECEIVER THRESHOLD = 37000 MICROSECONDS IST1846I MINIMUM RECEIVER THRESHOLD = 17000 MICROSECONDS IST1848I SEND BYTE COUNT = 39847 RECEIVE BYTE COUNT = 2662 IST1849I LARGEST NLP SENT = 1362 BYTES IST1850I LARGEST NLP RECEIVED = 178 BYTES IST1851I SMOOTHED ROUND TRIP TIME = 11 MILLISECONDS IST1852I LIVENESS TIMER = 0 SECONDS IST1853I NUMBER OF NLPS ON OUT-OF-SEQUENCE QUEUE = 0 IST1854I NUMBER OF NLPS ON INBOUND SEGMENTS QUEUE = 0 IST1855I NUMBER OF SESSIONS USING RTP = 1 IST924I ------------------------------------------------------------- IST1857I BACKPRESSURE REASON COUNTS: IST1858I PATHSWITCH SEND QUEUE MAX STORAGE FAILURE IST1859I 0 0 0 IST924I ------------------------------------------------------------- IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST355I LOGICAL UNITS: IST080I EEDL13 ACT/S----Y IST314I END

D NET,E,ID=<rtpname>,HPRDIAG=YES (cont.)

V1R5 enhancements to resequencing should reduce this behavior

Related to ARB: If at least 250K of data backed up, VTAM stops appls from sending

IP Network

CISCO 4500


92.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

No significant nework congestion

1. IST1842I 1. This message is issued if HPRDIAG=YES is specified. 2. retransmitted is the number of Network Layer Packets (NLPs) that have been retransmitted for this Rapid Transfer Protocol

(RTP).2. IST1843I

1. This message is issued if HPRDIAG=YES is specified. 2. waitsend is the number of network layer packets (NLPs) currently on the waiting-to-send queue.

3. IST1844I 1. This message is issued if HPRDIAG=YES is specified. 2. mode is the current Adaptive Rate-Based pacing (ARB) mode. The value is one of the following:

1. Green Data transmission is being performed without significant network congestion.2. Yellow Data transmission is being slowed down because network congestion has been detected.3. Red Data transmission is being affected by severe network congestion which might result in packet loss.

4. IST1849I 1. This message is issued if HPRDIAG=YES is specified. 2. size is the number of bytes contained in the largest network layer packet (NLP) sent on this Rapid Transfer Protocol (RTP).

5. IST1850I 1. This message is issued if HPRDIAG=YES is specified. 2. size is the number of bytes contained in the largest network layer packet (NLP) received on this Rapid Transfer Protocol (RTP).

6. IST1853I 1. This message is issued if HPRDIAG=YES is specified. 2. outofsequence is the number of network layer packets (NLPs) on the out-of-sequence queue.

7. IST1854I 1. This message is issued if HPRDIAG=YES is specified. 2. inboundsegs is the number of network layer packets (NLPs) on the inbound segments queue.

8. IST1859I 1. This message is issued if HPRDIAG=YES is specified. It displays the number of times that this Rapid Transfer Protocol (RTP)

has gone into backpressure (holding up outbound data transmission) for each of the following reasons: 2. pathswitch is the number of times that this RTP has gone into backpressure due to path switch. 3. sendqmax is the number of times that this RTP has gone into backpressure due reaching the send queue maximum limit. 4. storfail is the number of times that this RTP has gone into backpressure due to a failure to obtain storage.


And at V1R7 of z/OS: EEDIAG D NET,EEDIAG,REXMIT=5,IP=9::67:1:1,LIST=DETAILIST097I DISPLAY ACCEPTEDIST350I DISPLAY TYPE = EEDIAGIST2065I ENTERPRISE EXTENDER CONNECTION REXMIT INFORMATIONIST2067I EEDIAG DISPLAY ISSUED ON 08/27/04 AT 13:31:05IST924I -------------------------------------------------------------IST1680I LOCAL IP ADDRESS 9::67:1:1IST1910I LOCAL HOSTNAME IP.SSCP1AV6IST1680I REMOTE IP ADDRESS 9::67:1:6IST1909I REMOTE HOSTNAME IP.SSCP2AV8IST2024I CONNECTED TO SWITCHED PU SWIP2A1IST924I -------------------------------------------------------------.....-------------------------------------------------------------IST2032I PORT PRIORITY = HIGHIST2036I NLPS SENT = 134 ( 000K )IST2038I NLPS RETRANSMITTED = 67 ( 000K )IST2068I NLP RETRANSMIT RATE = 50%IST924I ..... -------------------------------------------------------------IST2035I TOTALS FOR ALL PORT PRIORITIESIST2036I NLPS SENT = 590 ( 000K )IST2038I NLPS RETRANSMITTED = 67 ( 000K )IST2068I NLP RETRANSMIT RATE = 11%.....

Performance information

Retransmitted packets?

Examine status of IP network/nodesExamine status of target EE node.

Exceeding 5% Retransmit

1. Provides performance information about retransmitted packets.2. Assists in diagnosing underlying IP network or node problems or problems with the destination EE SNA Endpoint itself.


An Interesting Problem with Jumbo Frames and EE

DISPLAY NET,ID=CNR00024,SCOPE=ALL IST075I NAME = CNR00024 , TYPE = PU_T2.1 IST486I STATUS= ACTIV--LX-, DESIRED STATE= ACTIV IST1043I CP NAME = MYCP1 , CP NETID = MYNET , DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = #CONNECT IST1476I TCID X'32E32AF90000002F' - REMOTE TCID X'32E1E64E0000006E' IST1481I DESTINATION CP MYNET.MYCP1 - NCE X'D000000000000000' IST1587I ORIGIN NCE X'D000000000000000' IST1477I ALLOWED DATA FLOW RATE = 12 MBITS/SEC IST1516I INITIAL DATA FLOW RATE = 14 MBITS/SEC IST1841I ACTUAL DATA FLOW RATE = 0 KBITS/SEC IST1511I MAXIMUM NETWORK LAYER PACKET SIZE = 8961 BYTES IST1478I NUMBER OF UNACKNOWLEDGED BUFFERS = 16 IST1479I RTP CONNECTION STATE = CONNECTED - MNPS = NO IST1855I NUMBER OF SESSIONS USING RTP = 1 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 3 MYNET.MYCP1 APPN RTP IST075I NAME = CNR00024 , TYPE = PU_T2.1 IST875I ALSNAME TOWARDS RTP = MYEEPU IST1738I ANR LABEL TP ER NUMBER IST1739I 8006001001000000 *NA* *NA* IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST355I LOGICAL UNITS: IST080I TCPP0032 ACT/S----Y IST314I END

D NET,E,ID=<rtpname>,SCOPE=ALL

IP Network

CISCO 4500


92.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

1. IST1842I 1. This message is issued if HPRDIAG=YES is specified. 2. retransmitted is the number of Network Layer Packets (NLPs) that have been retransmitted for this Rapid Transfer Protocol

(RTP).2. IST1843I

1. This message is issued if HPRDIAG=YES is specified. 2. waitsend is the number of network layer packets (NLPs) currently on the waiting-to-send queue.

3. IST1844I 1. This message is issued if HPRDIAG=YES is specified. 2. mode is the current Adaptive Rate-Based pacing (ARB) mode. The value is one of the following:

1. Green Data transmission is being performed without significant network congestion.2. Yellow Data transmission is being slowed down because network congestion has been detected.3. Red Data transmission is being affected by severe network congestion which might result in packet loss.

4. IST1849I 1. This message is issued if HPRDIAG=YES is specified. 2. size is the number of bytes contained in the largest network layer packet (NLP) sent on this Rapid Transfer Protocol (RTP).

5. IST1850I 1. This message is issued if HPRDIAG=YES is specified. 2. size is the number of bytes contained in the largest network layer packet (NLP) received on this Rapid Transfer Protocol (RTP).

6. IST1853I 1. This message is issued if HPRDIAG=YES is specified. 2. outofsequence is the number of network layer packets (NLPs) on the out-of-sequence queue.

7. IST1854I 1. This message is issued if HPRDIAG=YES is specified. 2. inboundsegs is the number of network layer packets (NLPs) on the inbound segments queue.

8. IST1859I 1. This message is issued if HPRDIAG=YES is specified. It displays the number of times that this Rapid Transfer Protocol (RTP)

has gone into backpressure (holding up outbound data transmission) for each of the following reasons: 2. pathswitch is the number of times that this RTP has gone into backpressure due to path switch. 3. sendqmax is the number of times that this RTP has gone into backpressure due reaching the send queue maximum limit. 4. storfail is the number of times that this RTP has gone into backpressure due to a failure to obtain storage.


Enterprise Extender and Multipath

IPCONFIG ... Multipath Perconnection ...

UDP is treated as Multipath Perpacket by the IP Stack regardless of the TCPCONFIG specification!

Becomes Per Packet for UDP

1. From the VTAM Network Implementation Guide:1. Load-balancing Enterprise Extender traffic across multiple interfaces is achieved by specifying either IPCONFIG MULTIPATH

PERCONNECTION or IPCONFIG MULTIPATH PERPACKET in the TCP/IP profile. However, with Enterprise Extender, the datagram routing behavior deviates from the way IP datagrams are routed by the TCP/IP stack. Enterprise Extender will round-robin APPN send requests across each of the equal-cost routes to the APPN end-point, regardless of whether PERCONNECTION or PERPACKET was specified on the IPCONFIG MULTIPATH statement.


How to Know Performance Characteristics of EE from IP Viewpoint

...D TCPIP,TCPT21,N,BYTEINFO,CLIENT=NET IEF196I IEF237I C134 ALLOCATED TO SYS00060 EZZ2500I NETSTAT CS V1R4 TCPT21 087 MVS TCP/IP REAL TIME NETWORK MONITOR USER ID B OUT B IN L PORT FOREIGN SOCKET STATE NET 0000666619 0000996104 12001 *..* UDP NET 0002696590 0002697070 12000 *..* UDP NET 0000006493 0000007471 12002 *..* UDP NET 0000000000 0000000000 12004 *..* UDP NET 0000571074 0000181687 12003 *..* UDP 5 OF 5 RECORDS DISPLAYED

D TCPIP,TCPT21,N,CONN,PORT=12000 EZZ2500I NETSTAT CS V1R4 TCPT21 093 USER ID CONN LOCAL SOCKET FOREIGN SOCKET STATE NET 00000009 172.16.2.121..12000 *..* UDP 1 OF 1 RECORDS DISPLAYED

NETSTAT BYTEINFO with 'CLIENT' Filter

; FROM PROFILE.TCPIP;PORT ... 12000 UDP NET ; LDLC 12001 UDP NET ; NETWORK PRIORITY 12002 UDP NET ; HIGH PRIORITY 12003 UDP NET ; MEDIUM PRIORITY 12004 UDP NET ; LOW PRIORITY

12000 (LDLC) 12001 (Network)12002-4: Data Traffic

1. Expect lots of activity on 12000 (LDLC) and 12001 (Network)1. Timers2. CP-CP Session Activity

2. Monitor other ports to see if you have optimized APPNCOS distribution


Tips for Easier Operations

ClistsFor Output SummariesFor Command Syntax Simplification

Existing Network Management Tools (Tivoli, etc.)IBM Tivoli Monitoring for Network PerformanceIBM Tivoli NetView's NLDM

z/OS CS Instrumentation API (V1R4)AWM

1. There are so many useful commands, and sometimes the output is quite lengthy. Is there a way to obtain information without overwhelming yourself?

2. The answer is: Yes.1. Use REXX Execs or CLIST language to summarize command output information or to cut through the sometimes complex

syntax of certain commands.2. Watch for Network Management Tools from IBM Tivoli and other vendors.3. Use Application Workload Monitor to measure your own installation's response time and throughput.


How Can I Use REXX CLISTS to Summarize Information? Tivoli NetView N3P2 GDENTE 01/29/04 13:48:07 EESNASW ** CHECK CP-CP STATUS OF ALL SNASWITCH AND OTHER APPN ROUTERS ** DSI082I AUTOWRAP STARTED USIBMWZ.CPREE3 PRIMARY CP-CP SESSIONS -------------------------------- *** NO CP-CP SESSIONS FOUND FOR USIBMWZ.CPREE3 *** *** VERIFY THAT USIBMWZ.CPREE3 IS A VALID RESOURCE *** USIBMWZ.CPREE4 PRIMARY CP-CP SESSIONS -------------------------------- *** NO CP-CP SESSIONS FOUND FOR USIBMWZ.CPREE4 *** *** VERIFY THAT USIBMWZ.CPREE4 IS A VALID RESOURCE *** CSSNET.CP2216D PRIMARY CP-CP SESSIONS -------------------------------- CSS2 ACTIV/CP-S SEND=0031 , RCV=0001 CSS2 ACTIV/CP-P SEND=0001 , RCV=002F CSSNET.CP2216E PRIMARY CP-CP SESSIONS -------------------------------- CSS2 ACTIV/CP-S SEND=0035 , RCV=0001 CSS2 ACTIV/CP-P SEND=0001 , RCV=0035 ***************************************** * CHECKING FOR CP-CP SESSIONS COMPLETE * *****************************************

REXX Code in Notes

This is the REXX Coding used for the output you see above; the original REXX code id did not use Pipes; I would recommend rewriting this to take advantage of pipes. /* CHECK CP-CP STATUS OF ALL SNASWITCH AND OTHER APPN ROUTERS */ SAY '** CHECK CP-CP STATUS OF ALL SNASWITCH AND OTHER APPN ROUTERS **' 'AUTOWRAP 5' /* TRACE E */ /* SNASW.13=CPNAME */ SNASW.1=USIBMWZ.CPREE3 SNASW.2=USIBMWZ.CPREE4 SNASW.3=CSSNET.CP2216D SNASW.4=CSSNET.CP2216E /* CYCLE THRU THE SNASWITCH ROUTERS */ DO X = 1 TO 4 'TRAP AND SUPPRESS MESSAGES IST*' CPCP='N' 'D NET,ID='SNASW.X',E' 'WAIT 1 SECONDS FOR MESSAGES' SELECT WHEN (EVENT()='T') THEN DO SAY 'TIMEOUT TRYING TO CHECK STATUS OF ' SNASW.X END /* EVENT = T */ WHEN EVENT() = 'M' THEN DO 'MSGREAD' 'WAIT CONTINUE' 'MSGREAD' 'GETMSIZE NUMLINES' SAY ' ' SAY ' 'SNASW.X' PRIMARY CP-CP SESSIONS' SAY ' --------------------------------' DO I = 1 TO NUMLINES 'GETMLINE RECORD' I 'PARSEL2R RECORD MSGID SN ST SID SD RV REST' /*REPORT ONLY PRIMARY CP-CP SESSIONS WITH S193CDRM NOTHING ELSE */ IF MSGID=IST635I & SN=CSS2 & SUBSTR(ST,7,1)='C' THEN DO CPCP='Y' SAY SN ST 'SEND='SD ', RCV='RV END /* DO */ /*REPORT STRANGE SESSIONS */ IF MSGID=IST635I & SUBSTR(ST,1,5)<>ACTIV THEN DO SAY '--->' SN ST SID 'IS IN A STRANGE STATE <---' END /* DO */ END /* I= NUMLINES */ IF CPCP='N' THEN DO SAY '*** NO CP-CP SESSIONS FOUND FOR' SNASW.X' ***' SAY '*** VERIFY THAT 'SNASW.X' IS A VALID RESOURCE ***' END END /* EVENT = M */ OTHERWISE SIGNAL BADINPUT END /* SELECT */ END /* DO X= */ 'TRAP NO MESSAGES' 'FLUSHQ' SAY '*****************************************' SAY '* CHECKING FOR CP-CP SESSIONS COMPLETE *' SAY '*****************************************' EXIT NOSNASW: SAY '*****************************************' SAY '* 'SNASW.X ' IS NOT A VALID RESOURCE *' SAY '*****************************************' RETURN BADINPUT: SAY '*----------------------------------------------------------------*' SAY '* ERROR IN CLIST PLEASE CHECK INDIVIDUAL CP NAMES MANUALLY *' SAY '*----------------------------------------------------------------*' EXIT


How Can I Use REXX CLISTS to Summarize Information?

Tivoli NetView N3P2 GDENTE 01/29/04 13:49:56 EEAPPN DSI082I AUTOWRAP STARTED USIBMWZ.S192CDRM PRIMARY CP-CP SESSIONS -------------------------------- *** NO CP-CP SESSIONS FOUND FOR USIBMWZ.S192CDRM *** *** VERIFY THAT USIBMWZ.S192CDRM IS A VALID RESOURCE *** USIBMWZ.S100CDRM PRIMARY CP-CP SESSIONS -------------------------------- *** NO CP-CP SESSIONS FOUND FOR USIBMWZ.S100CDRM *** *** VERIFY THAT USIBMWZ.S100CDRM IS A VALID RESOURCE *** CSSNET.CSS1 PRIMARY CP-CP SESSIONS -------------------------------- CSS2 ACTIV/CP-S SEND=0012 , RCV=0001 CSS2 ACTIV/CP-P SEND=0001 , RCV=0013 ***************************************** * CHECKING FOR CP-CP SESSIONS COMPLETE * ***************************************** REXX Code in Notes

This is the REXX Coding used for the output you see above; the original REXX code id did not use Pipes; I would recommend rewriting this to take advantage of pipes. /* CHECK CP-CP STATUS OF ALL ZOS HOSTS */ 'AUTOWRAP 5' /* TRACE E */ /* SNASW.13=CPNAME */ ZOSAPPN.1=USIBMWZ.S192CDRM ZOSAPPN.2=USIBMWZ.S100CDRM ZOSAPPN.3=CSSNET.CSS1 /* CYCLE THRU THE ZOS APPN CP-CP SESSIONS */ DO X = 1 TO 3 'TRAP AND SUPPRESS MESSAGES IST*' CPCP='N' 'D NET,ID='ZOSAPPN.X',E' 'WAIT 1 SECONDS FOR MESSAGES' SELECT WHEN (EVENT()='T') THEN DO SAY 'TIMEOUT TRYING TO CHECK STATUS OF ' ZOSAPPN.X END /* EVENT = T */ WHEN EVENT() = 'M' THEN DO 'MSGREAD' 'WAIT CONTINUE' 'MSGREAD' 'GETMSIZE NUMLINES' SAY ' ' SAY ' 'ZOSAPPN.X' PRIMARY CP-CP SESSIONS' SAY ' --------------------------------' DO I = 1 TO NUMLINES 'GETMLINE RECORD' I 'PARSEL2R RECORD MSGID SN ST SID SD RV REST' /*REPORT ONLY PRIMARY CP-CP SESSIONS WITH S193CDRM NOTHING ELSE */ IF MSGID=IST635I & SN=CSS2 & SUBSTR(ST,7,1)='C' THEN DO CPCP='Y' SAY SN ST 'SEND='SD ', RCV='RV END /* DO */ /*REPORT STRANGE SESSIONS */ IF MSGID=IST635I & SUBSTR(ST,1,5)<>ACTIV THEN DO SAY '--->' SN ST SID 'IS IN A STRANGE STATE <---' END /* DO */ END /* I= NUMLINES */ IF CPCP='N' THEN DO SAY '*** NO CP-CP SESSIONS FOUND FOR' ZOSAPPN.X' ***' SAY '*** VERIFY THAT 'ZOSAPPN.X' IS A VALID RESOURCE ***' END END /* EVENT = M */ OTHERWISE SIGNAL BADINPUT END /* SELECT */ END /* DO X= */ 'TRAP NO MESSAGES' 'FLUSHQ' SAY '*****************************************' SAY '* CHECKING FOR CP-CP SESSIONS COMPLETE *' SAY '*****************************************' EXIT NOSNASW: SAY '*******************************************' SAY '* 'ZOSAPPN.X ' IS NOT A VALID RESOURCE *' SAY '*******************************************' RETURN BADINPUT: SAY '*----------------------------------------------------------------*' SAY '* ERROR IN CLIST PLEASE CHECK INDIVIDUAL CP NAMES MANUALLY *' SAY '*----------------------------------------------------------------*' EXIT


What's New for EE Network Management

New network management instrumentation APIs built for performance in z/OS V1R5 and APARed to V1R4 (APAR II13699):

Real-time packet tracing and formattingTCP connection initiation and termination notificationsAPIs:

TN3270 server and FTP event dataTCP listeners TCP connections UDP endpointsCS storage usageEnterprise Extender management data

CS z/OS and components

Remote monitor

Local monitor

PresentationPrivate protocol

APIs

Commands/Utilities

Exit points

SNMP

SMF and SyslogD

Exit point

I n s t r u m e n t a t i o n

IBM Tivoli Monitoring for Network Performance" Software or other Network Management vendor

SNMP

z/OS

z/OS V1R5APAR for V1R4

EE Data

3714 (9:30am on Tuesday): "What is new in IBM Tivoli Monitoring for network performance"3715 (11am on Tuesday): "Update & Installing IBM Tivoli Monitoring for Network Performance: New Features, New Functions, A Whole New Look"3716 (1:30pm on Tuesday): "IBM Tivoli Monitoring for Network Performance: Best Practices for Performance Management"

1. New network management instrumentation APIs in z/OS V1R5 and APARed to V1R4 built for performance:1. Real-time packet tracing and formatting2. TCP connection initiation and termination notifications3. API for real-time access to TN3270 server and FTP event data4. APIs to poll information about currently active5. TCP listeners (server processes)6. TCP connections (detailed information about individual connections)7. UDP endpoints8. CS storage usage9. API to receive and poll for Enterprise Extender management data

2. For more information, please see APAR II13699, "INFORMATION APAR FOR Z/OS COMMUNICATION SERVICE NETWORK MANAGEMENT API" for detail on the individual APIs and PTFs available to z/OS V1R4.

3. Session being held at SHARE in New York (August 2004) on the IBM Tivoli Monitoring for Performance V2R1 offering are:1. Paul Smith, session 3714 (9:30am on Tuesday). It is named 'What is new in IBM Tivoli Monitoring for network performance'.2. Dean Butler, session 3715 (11am on Tuesday). It is named 'Update and Installing IBM Tivoli Monitoring for Network

Performance: New Features, New Functions, A Whole New Look'.3. Jason Brown, session 3716 (1:30pm on Tuesday). It is named 'IBM Tivoli Monitoring for Network Performance: Best

Practices for Performance Management'.1. The session numbers are SHARE sessions from the August, 2004 SHARE held in New York City. The presentations are

available with the appropriate userid and password from the SHARE website at www.share.org. Most of these or similar sessions are repeated at other user conferences, albeit with different session numbers.


IBM Tivoli Monitoring for Network Performance V2R1

Enterprise Extender Link Availability and Response View

View HPR and EEHPR Availability and Response ViewHPR Throughput and Traffic ViewEE Availability and Response ViewEE Throughput and Traffic View

1. This screen capture shows you how Tivoli Monitoring for Network Performance V2R1 can pull many pieces of IP and SNA information together to reveal the performance characteristics of the Enterprise Extender network. It is based upon the Network Management API that was introduced in the base of z/OS V1R4 and added via APAR to the z/OS V1R4 code. Note that there are four major areas of Enterprise Extender Monitoring provided by the product; note also that there are many other management views available as well outside the Enterprise Extender Arena. (See left-hand column above.)

2. The GUI is an enhancement to the management provided by the existing SNA and IP commands available for monitoring Enterprise Extender.

3. IBM Tivoli Monitoring for Network Performance 2.1 is a new release of Monitoring software that became Generally Available on June 18, 2004. During the Early Support Program, multiple external customers and IBM-internal customers worldwide installed and tested the code in their environments. 1. Product ID number: 5698-FNP 2. PSP Bucket APAR: II3882 3. PSP Documentation Updates: II3883

4. The IBM Software Announcement was released on 15 June 2004 as 204-127 (US) and ZP04-0224 (EMEA), and is available in PDF-format at:1. US: http://w3-3.ibm.com/sales/ssi/rep_ia/7/897/ENUS204-127/ENUS204-127.PDF 2. Europe, Middle East, Africa: http://www-306.ibm.com/common/ssi/rep_ca/4/877/ENUSZP04-0224/ENUSZP04-0224.PDF


IBM Tivoli Monitoring for Network Performance V2R1

HPR RTP Connections Availability and Response View

1. This is another screen capture of the informationn that the Tivoli Montoriing for Network Performance V2R1 can provide to you.2. ITM NP V2R1 provides the following features :-

1. CS/390 Network Management Interface Exploitation - ITM NP V2.1 exploits a new network management interface provided by CS/390 to gather key pieces of information. This dramatically improves the scalability, performance, and RAS compared to the command-parsing techniques of the ITM NP V1 product.

2. New GUI Interface - The new product includes a completely revised user interface. The new interface is role-based, with a separate Administrator and Operator GUI. The new user interface is consistent with Tivoli strategy and provides better control over the level of detail on the screen (sorting, filtering and column selection/ordering) than the existing product. The V2 GUI is based on the WebSphere platform, which is the strategic direction for Tivoli products.

3. DB2 Exploitation - ITM NP V2 uses DB2 as its store for the performance and monitoring data it gathers, and as a store for the configuration information entered by administrators. Use of DB2 in this way is in line with the strategic direction for Tivoli products.

4. Improved Usability/Performance - The updated technology base of ITM NP V2 provides improved usability and performance by :-1. Installing and configuring ONE monitor per z/OS system regardless of the number of TCP/IP stacks being monitored2. Utilising architected interfaces to retrieve data rather than using "screen scraping" techniques3. Populating one consolidated data store as opposed to multiple VSAM files scattered across the environment4. One consolidated store for configuration information, allowing much 're-use' of definitions amongst monitors, compared to

multiple configuration locations with no re-use for the V1 product.5. Improving the method for generating reports by including a more complete batch reporting mechanism based on TDW and

Crystal reports, the strategic reporting solution for Tivoli products.5. Event Management - The V2 product generates events directly to TEC or NetView For z/OS, rather than simply issuing WTOs

as the V1 product does.


Application Workload ModelerA workload simulation tool for measuring the performance of networks, applications, and systems

Formerly internal performance tool called NetMarksMulti-protocol support including SNA and TCP/IP

TN3270, WEB, SMTP, FTP, DNS, VTAM RAPI and APPC, etcRuns stand-alone, providing its own client and server

Used for testing infrastructure needed for new workloads or modified workloadsMultiple platforms supported

OS/390, z/OS, z/Linux and Intel LinuxProvides clients for many server applications, including FTP, TN3270, WEB, etc.

Used for testing infrastructure and performance of application subsystems

Network

Server

CommunicationStack

AWM Client

CommunicationStack

AWM Client

CommunicationStack

AWM Client

CommunicationStack

AWM Client

CommunicationStack

Server

CommunicationStack

CommunicationStack

SNA or TCP/IP

SNA or TCP/IP

Real server: (FTP,TN3270, WEB, etc) Server

CommunicationStack

Server

CommunicationStack

CommunicationStack

AWM server

Measuring Network Performance in zSeries

1. For more information on AWM, please consult the AWM website: 1. http://www-3.ibm.com/software/network/awm/

2. A presentation that you may download can be found at:1. http://www-3.ibm.com/software/network/awm/library/index.html


Why Are EE PUs and RTP PUs Going Up and Down?


Common Reasons for Frequent PU Recycling

Inconsistent APPNCOS tables at NNs ISTACST2 vs. COSAPPN

Can cause RTP path switching because each endpoint thinks it has found a better route, especially if PSRETRY is non-zero.

DISCNT= coding or defaults on PU (HPR PU or EE PU)Unstable Network or slow router convergence, esp. with RIP or if OSPF Dead Router Interval is long or if OSPF neighbors are lostTimer Values

RTP PathSwitch Timers may not be optimal, forcing a search for better pathsLDLC Timers for EE Link might be too Low for platform or network conditions

Make both ends of EE Connection specify same timers snasw port HPRIP hpr-ip Loopback0 vnname USIBMWZ.HPRIP1 no-limres ldlc 25 15 3

EEXCA VBUILD TYPE=XCA EEPORT PORT MEDIUM=HPRIP, X IPTOS=(20,40,80,C0,C0),LIVTIME=25,IPPORT=12000, X SAPADDR=4,SRQTIME=15,SRQRETRY=3, X TGP=EEXTWAN,CAPACITY=100M, X VNNAME=CSSNET.HPRIP,VNGROUP=EEGRPL1,VNTYPE=LOCAL * EEGRPL1 GROUP DIAL=YES,AUTOGEN=(10,EL1,EP1),DYNVNPFX=V1, X DYNPU=NO, CALL=INOUT,ISTATUS=ACTIVE

liveness timerretry timerretry count

1. You need to be concerned about two types of timers with Enterprise Extender: the timers for HPR Path Switch and the timers for the EE TG (PU) or Connection.

2. If your APPNCOS tables are inconsistent on the network nodes throughout the network, you could run into the following scenario:1. Two network nodes, NN1 and NN2 are connected by parallel TGs. The definitions for the links are not consistent: NN1 has a weight of

30 for TG 21 and a weight of 210 for TG 22, whereas NN2 has a weight of 210 for TG 21 and a weight of 30 for TG 22. When Appl1(on NN1) wants to get in session with Appl2 (on NN2), NN1 calculates a route and chooses TG 21 as the least-weight route. Since no RTP pipe exists yet over TG 21, one is created.

2. NN2 has PSRETRY enabled. When the PSRETRY timer pops, NN2 calculates a route for the existing pipe. From NN2’s perspective, the best choice of route is TG 22, so NN2 path switches the pipe onto TG 22.

3. Shortly thereafter, Appl1 starts another session with Appl2. NN1 once again calculates a route, and again discovers that TG 21 is the best route. Since no RTP pipe exists over TG 21 (remember that the previous pipe was path switched to TG 22), a new pipe is created.

4. The next time the PSRETRY timer expires in NN2, NN2 will path switch that pipe that was just created. This process will then continue indefinitely, resulting in wasted path switches, and an increasing number of redundant pipes.

3. About the LDLC Times: 4. The syntax for the snasw port statement in IOS is:

1. HPR-IP Ports2. snasw port port-name hpr-ip interface-name [no-limres ldlc [liveness-time t1-retry-time t1-retry-count]]3. [maxbtu max-btu-size] [vnname virtual-node-name] [nostart]

5. There are two timers that can affect Enterprise Extender connections, the Logical Data Link Control (LDLC) timer and the disconnect timer. The LDLC timer controlling keywords specified on the PORT macro are LIVTIME, SRQTIME and SRQRETRY. The disconnect timer is controlled through the DISCNT keyword on the PU macro in VTAM and with "no-limres" on the SNASW PORT with vnname coded on it.1. The LDLC timer provides LDLC with a mechanism to wait for an interval after which LDLC may consider an Enterprise Extender

connection inoperative. The disconnect timer works independently of the LDLC timer, and determines the time interval during which Enterprise Extender monitors for data transfer before disconnecting the link (if no data transfer occurs).

2. The following describe when an Enterprise Extender link may be disconnected:1. The interval determined by LIVTIME + (SRQTIME*(SRQRETRY+1)) expires if required signal responses are not received.2. The DELAY value specified by DISCNT expires if no data transfer occurs.3. "no-limres" in the CISCO coding specifies that the Connection Network Link is not to time out due to inactivity. It is documented in:4. http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017cf40.html#wp10949

78


How is APPN Route Chosen? (Review)

#INTER APPNCOS PRIORITY=HIGH LINEROW WEIGHT=20, NUMBER=1, ... CAPACITY=(100M,MAXIMUM), ... LINEROW WEIGHT=40, NUMBER=2, ... CAPACITY=(10M,MAXIMUM), ... LINEROW WEIGHT=60, NUMBER=3, ... CAPACITY=(1M,MAXIMUM), ...

ISTACST2

#INTER APPNCOS PRIORITY=HIGH,NUMBER=12 LINEROW WEIGHT=30, NUMBER=1, ... CAPACITY=(4M,MAXIMUM), ...

COSAPPN

Class of Service for Session Causes weights to be assigned to nodes and TGs along SNA session pathPath with lowest cumulative weight is preferred path

COS Table 'ISTACST2' provides more granularity, but ...

All NNs must assign weights in same fashionOtherwise, an RTP endpoint of a session could start a Path Switch, believing that the path assigned is not optimal!NN1 chooses Path#1; NN2 switches to Path#2

COSAPPN ISTACST2

weight=30

weight=30

weight=40

weight=20

NN1 NN2#1 #1

#2 #2100Meg

10Meg

1. You have seen this visual before. It is repeated to point out the need to ensure that route calculation is subject to the same definitions or defaults at both ends of an RTP pipe -- otherwise you could see many otherwise unexplainable path switches taking place, particularly if you have coded PSRETRY to a non-zero value.

2. Generally speaking the NNS of the OLU performs the route calculation in an APPN network. But there are many factors involved in route selection, so I urge you to read up on this subject using various redbooks and by reviewing the presentations on Logmode and COS Resolution in Mixed APPN/Subarea networks by Johnathan Harter of IBM in Raleigh, NC.

3. VTAM chooses a route by comparing the actual characteristics of the available nodes and TGs to the allowed characteristic ranges specified in the requested CoS. For each APPN CoS entry, there are 1-12 LINEROW operands and 1-8 NODEROW operands. These operands give up to 12 acceptable sets of characteristics for the lines and up to 8 for the nodes in each CoS. The WEIGHT parameter on the NODEROW and LINEROW operands is coded to indicate the desirability of that set of characteristics. The lower the value of the WEIGHT parameter, the higher the desirability of a node or TG that fits that set of characteristics.

4. Note: The IBM-supplied CoS definitions in COSAPPN are made up of 8-row LINEROW and NODEROW entries for all Classes of Service. The minimum weight in APPNCOS is 30 and is used for connections with a minimum capacity of 4MB. There are two exceptions to this: #BATCH and #BATCHSC will provide a minimum weight of 30 if a connection has a minimum capacity of 56K.

5. The IBM-supplied CoS definitions in ISTACST2 are made up of 8-row LINEROW entries for all Classes of Service except #BATCH, #BATCHSC, #INTER, #INTERSC, and #CONNECT (which are made up of 12-row LINEROW entries), and 8-row NODEROW entries for all Classes of Service. In ISTACST2 the minimum linerow weight is 20, as you see in the visual above. 1. Note: If you activate the set of definitions with 12-row LINEROW entries, you should have a set of definitions with 12-row LINEROW

entries activated on each network node in the network for optimal routing in networks that include ATM native connections. 2. Not all HPR APPN products support CoS definitions with 12-row LINEROW entries. This could affect your ability to optimally use

native ATM connections among the nodes in your network. Consult technical representatives for the HPR APPN products in your network to determine if those products support CoS definitions with 12-row LINEROW entries.

6. For each of the LINEROW and NODEROW operands, an acceptable range is coded. For each potential line or node in a route, VTAM compares the node or TG characteristics to the LINEROW or NODEROW operand values in the requested Class of Service. For an entire route to be acceptable for a given Class of Service, all nodes and TGs for that route must be acceptable for the requested Class of Service.

7. If more than one route fits the required characteristics of the Class of Service, VTAM chooses the one with the least total weight, and therefore the most desirable characteristics. If no route matches the required characteristics of the Class of Service, the session fails (for example, if the Class of Service requires a secure route and VTAM cannot find a complete route using only secure TGs). If two routes have the same low weight characteristics, VTAM randomly chooses one of them.

8. In the example, if NN1 selected the route labelled #1 because it chose randomly between two routes with equally low-weighted characteristics, then NN2 would think that a suboptimal route had been chosen and it would pathswitch to the route labelled #2.


IST680I CONNECTION REQUEST DENIED - ID = S193CDRM PU GEN NOT SUPPORTED IST1394I CPNAME = USIBMWZ.S193CDRM STATION ID = 0200FFFF5675 IST081I LINE NAME = EL1009 , LINE GROUP = EEGRPL1 , MAJNOD = EEXCA IST314I END

Effect of dynpu=no at S192CDRM after Dialin from S193CDRM

PUnames and Timers with DYNPU=NO

If coding "dynpu=no," you must have a predefined Switched PU unless you are using Connection Network.

EEXCA VBUILD TYPE=XCA * EEPORT PORT MEDIUM=HPRIP,... X ...*EEGRPL1 GROUP DIAL=YES,AUTOGEN=(10,EL1,EP1),DYNVNPFX=V1, X DYNPU=NO,CALL=INOUT,ISTATUS=ACTIVE

With DYNPU=NO and a predefined SWnet PU, you have control of PU Parameters!

1. There is more administrative overhead involved with dynpu=no, but you can at least control the EE connection better with predefinition than with the dynamics of dynpu=yes. Note: z/OS V1R5 introduces a Model DYNTYPE=EE that makes the use of dyntype=yes more effective.


DISCONNECT Defaults in SNA and with EE

DISCNTIM in VTAM

Start Options

DISCNT for Predefined

PUsDISCNT for DYNPU=YES

DISCNT for Connection

Network PUsDISCNT for RTPs

(CNRnnnnn)

DISCNT for MODEL

Definitions (DYNTYPE=xx)

DISCNTIM=(15,0) DISCNT=NODISCNT=(YES,F)

meaning ... =(YES,F,discntim)

DISCNT=(YES,,10) DISCNT=(YES,,10) DISCNT=NO

You may want to implement Model Major Nodes for an EE Implementation in order to influence the following on EE PU definitions, Connection Network PUs, RTP PUs ...

DISCNT values -- recommended to code with a timer and not DISCNT=NOTG characteristicsV1R4 EE PU operands like ...

DWINOPNote: Naming conventions cannot be changed for DYNTYPE=EE, DYNTYPE=VN, DYNTYPE=RTP via a Model Major Node. However, naming conventions for XCF TRLEs can be changed for DYNTYPE=XCF via a Model Major Node.

1. For many reasons you may want established EE connections and RTP pipes to remain up whether or not session traffic is flowing over them. This is why you might code DISCNT=NO or DISCNT=(YES,,timevalue) on certain definitions. DISCNT with a timer is better because you don't get a proliferation of unused RTP Pipes hanging around. The timer value may be critical prior to z/OS V1R6, because at earlier releases, RTP PUs consume element addresses in the low order range; at V1R6, the element addresses are taken from the high order range. This chart shows you the existing defaults that affect EE.

2. DISCNTIM specifies the amount of time VTAM delays deactivation of an SSCP-PU session when there are no LU-LU session requests. For Subarea and Non-HPR APPN Sessions: DISCNTIM is valid only for PU types 2 and 2.1 that have DISCNT=DELAY specified on the PU definition statement.1. time_period1 specifies the amount of time VTAM delays deactivation of an SSCP-PU session after all LU-LU sessions

terminate. IMMED specifies the SSCP-PU session will be terminated immediately when the last LU-LU session terminates.2. time_period2 specifies the amount of time after establishment of an SSCP-PU session, VTAM delays deactivation of the

session if no LU-LU sessions have been established. When 0 is specified, VTAM will not deactivate the line if no LU-LU session is established after the line is connected.

3. Model Major Nodes1. Specifies when VTAM should terminate its SSCP-LU and SSCP-PU sessions and when DISCNT=YES or DISCNT=DELAY,

whether to indicate "final-use" status in the DACTPU request unit when it deactivates a PU.2. Common models for an EE environment would be DYNTYPE=VN, DYNTYPE=RTP, and -- in z/OS V1R5 -- DYNTYPE=EE.

There is also a DYNTYPE=XCF for coupling facility dynamic links, but this is not relevant to EE.4. A limited resource allows you to limit the use of some network connections. It also causes any sessions that traverse the

resource to be deactivated if no conversation is active. A session can also be deactivated if the time limit you specify for the LIMQSINT operand on the APPL definition statement expires. The coding of the LIMRES operand applies only to LU 6.2 conversations and PU types 1 and 2.

5. Resources will stay up as long as they have not been identified as a "limited resource" or have not been subjected to a disconnect timer.1. by the SNA session BIND processing (e.g., CICS LU6.2 conversations are often identified as using limited resources causing

underlying network resources to be dropped when a conversation ends)2. by resource definition with LIMRES operand on EE predefined PUs3. by architectural convention (e.g., a Connection Network PU is a limited resource, but a CNOS session pipe (SNASVCMG) is

not unless a VTAM Start Option of LIMINTCP has been coded and the CNOS pipe is over a limited resource. )


Messages with Inactivation of Connection Network PUs

04040 12:47:14.24 STC11105 00000010 IST590I CONNECTOUT ESTABLISHED FOR PU V100039A ON LINE EL1002

IST1086I APPN CONNECTION FOR USIBMWZ.CPREE4 IS ACTIVE - TGN = 21

IST1488I ACTIVATION OF RTP CNR0039B AS ACTIVE TO USIBMWZ.CPREE4

04040 16:09:44.54 STC11105 00000010

IST259I INOP RECEIVED FOR V100039A CODE = 01 IST619I ID = V100039A FAILED - RECOVERY IN PROGRESS

IST129I UNRECOVERABLE OR FORCED ERROR ON NODE V100039A - VARY INACT SCHED IST1196I APPN CONNECTION FOR USIBMWZ.CPREE4 INACTIVE - TGN = 21

IST590I CONNECTION TERMINATED FOR PU V100039A ON LINE EL1002 IST1488I INACTIVATION OF RTP CNR0039B AS PASSIVE TO USIBMWZ.CPREE4

Based upon DISCNT default or Coding

Session Inactivity and DISCNT timer cause EE PU to deactivate.

Equivalent Disconnect coding in CISCO is available with the "no-limres" parameter on the EE Port with the keyword "vnname" coded on it.

IP Network

CISCO 4500


92.168.135.182

EN,BEX

DLUR

Connection Network

192.168.135.209 VLINK1

USIBMWZ.S192CDRM

NN TCPT11

1. This Display shows the console log for the activation and later inactivation of an EE PU that was built dynamically across a Connection Network.

2. If RTP Pipes are still in use over a Connection Network PU, the PU perceives that it is still needed and will not be inactivated based upon your coding of the DISCNT timers. (The one exception to this is the RSETUP RTP Pipe, for which no timers or status queries are driven; therefore it is not responsible for making it look as if activity is still flowing over the pipe.) When RTP pipes are no longer required because there is no activity over them, the Connection Network PU is taken down, even if this means taking down an RSETUP pipe with it.

3. The console log shows you that the sessions (and their associated RTP pipes) must have been terminated sometime before 16:09:44 in the afternoon, because at that tie the Connection Network PU is inactivated.

4. The naming convention with the prefix of "V1" was established with the DYNVNPFX parameter on the Group of the XCA Major Node. This has overridden the DYNVNPFX in the VTAM Start Options.


1. You may experience frequent setups and takedowns of the EE TG/Link because default is DISCNT=(YES,F).

2. Dynamic PU Naming convention can make operations confusing

3. You are assigned Default TG characteristics, thus affecting at the very least the ARB algorithm for initial flow "ramp-up."

1. If default capacity is large enough, "ramp-up" velocity may be unnoticeable.

2. Route selection itself to an EN is not affected since the TG Characteristics for RSCV calculation are sent in by the EN.

Effect of dynpu=yes pre-V1R5 without EE Model Major Node

PUnames and Timers with DYNPU=YES

If coding "dynpu=yes" prior to the new DYNTYPE=EE Model in z/OS V1R5 or without ISTEXCCS exit,

understand these ramifications:

VTAM Start Option DYNPUFX: CN00000n

1. There is less administrative overhead involved with dynpu=yes, but you cannot control the EE connection characteristics as much as you might like unless you implement the ISTEXCCS exit for switched PUs. For example, 1. A PU created by the DYNPU operand will use the switched major node PU operand defaults, except for the following

operands which will use the values noted:1. ¤ MAXOUT=82. ¤ ANS=CONT3. ¤ DISCNT=(YES,F) 4. ¤ DYNADJCP=YES5. ¤ CPCP=YES

2. DISCNT is problematic because the EE connection will break seconds after the last SNA session using it ends. The number of seconds is controlled by the VTAM "discntim" start option or by a value overriding the discntim if DELAY may be specified. In V1R5 the new EE Model offers an opportunity to override DISCNT.


New Ways to Manipulate Some Switched Values

Code Model Major Node for ...DYNTPE=RTPDYNTYPE=VN DYNTYPE=XCF

DYNTYPE=EE (V1R5 only: for EE PUs otherwise generated with DYNPU=YES)

Doesn't require Switched Connection Exit (ISTEXCCS) to apply definitions in Model as was always the case prior to this enhancement.

APAR OW57263/UW96454 to enable coding of CPCP=YES for RTP Pipe.

MODRTP VBUILD TYPE=MODEL RTPPU PU DYNTYPE=RTP,DISCNT=(DELAY,,60) <<<or>>> DISCNT=NO

MODVN VBUILD TYPE=MODEL VNPU PU DISCNT=(DELAY,,60),DYNTYPE=VN <<<or>>> DISCNT=NO

MODXCF VBUILD TYPE=MODEL XCFT* PU TRLE=XCFP*,CAPACITY=160M,DYNTYPE=XCF <<<or>>> DISCNT=NO

MODEE VBUILD TYPE=MODEL EEMODEL PU DYNTYPE=EE,CAPACITY=100M,DISCNT=NO,DWINOP=YES,

REDIAL=30,REDDELAY=60 <<<or>>> DISCNT=(DELAY,,60)

1. DYNTYPE=EE is available beginning with z/OS V1R5.2. DYNTYPE=RTP | VN | XCF have been available since OS/390 V2R10. Allows you to override the DISCONNECT options

(DISC=YES|NO) and other options for various dynamically built entities. 3. The <puname> specified in this type of Model Major Node with DYNTYPE=<value> does not influence the naming of the

dynamically built PUs with the exception of DYNTYPE=XCF. PUnames for DYNTYPE=RTP | VN | EE are built based upon the prefix values assigned with the VTAM options of DYNHPPFX, DYNVNPFX, and DYNPUPFX.

4. The ISTEXCCS exit may be used as well to inflouence parameters for EE connections and Virtual Routing Node Connections.


D NET,E,ID=CNR0001E IST097I DISPLAY ACCEPTED IST075I NAME = CNR0001E, TYPE = PU_T2.1 990 IST1392I DISCNTIM = 00060 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV---X-, DESIRED STATE= ACTIV IST1043I CP NAME = S192CDRM, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST875I APPNCOS TOWARDS RTP = #INTER ...IST1511I MAXIMUM NETWORK LAYER PACKET SIZE = 4065 BYTES IST1478I NUMBER OF UNACKNOWLEDGED BUFFERS = 0 IST1479I RTP CONNECTION STATE = CONNECTED - MNPS = NO IST1855I NUMBER OF SESSIONS USING RTP = 0 IST1697I RTP PACING ALGORITHM = ARB RESPONSIVE MODE IST1480I RTP END TO END ROUTE - RSCV PATH IST1460I TGN CPNAME TG TYPE HPR IST1461I 21 USIBMWZ.HPRIP1 APPN RTP IST1461I 21 USIBMWZ.CPREE4 APPN RTP IST875I ALSNAME TOWARDS RTP = V100001B IST1738I ANR LABEL TP ER NUMBER IST1739I 8016003401000000 *NA* *NA* IST231I RTP MAJOR NODE = ISTRTPMN IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST172I NO LOGICAL UNITS EXIST

Overridden with Model for DYNTYPE=RTP

Display from S193CDRM of RTP over VRNDefault DISCNTIM of 10 overridden with 60

1. Note that message IST1392I shows the DISCNTIM that is in effect. The default for an RTP pipe is 10 seconds, so you can see that the Model Major Node with DYNTYPE=RTP overrode this value to 60 seconds.

2. The Model Major Node could also have been coded to provide for DISCNT=NO. 3. Note that some customers like DISCNT=NO behavior since no time/network overhead is wasted to take down/re-establish the

pipes as needed. The pipes are simply always there. The DISCNT=NO strategy is probably a good one with all of the performance maintenance available on V1R4 systems, but each customer must monitor CPU and storage to determine if this is a feasible solution at a particular installation. It is possible that installations that are still at pre-V1R4 may wish to use the DISCNT=(YES,<delay>) style of coding.

4. Sample:1. MODRTP VBUILD TYPE=MODEL 2. RTPPU PU DYNTYPE=RTP,DISCNT=(DELAY,,60) <<<or>>> DISCNT=NO


D NET,E,ID=V100001B IST097I DISPLAY ACCEPTED IST075I NAME = V100001B, TYPE = PU_T2.1 993 IST1392I DISCNTIM = 00060 DEFINED AT PU FOR DISCONNECT IST486I STATUS= ACTIV---X-, DESIRED STATE= ACTIV IST1043I CP NAME = S192CDRM, CP NETID = USIBMWZ, DYNAMIC LU = YES IST1589I XNETALS = YES IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS IST1106I V100001B AC/N 21 NO **** NA **** IST1482I HPR = RTP - OVERRIDE = N/A - CONNECTION = YES IST1510I LLERP = NOTPREF - RECEIVED = NOTALLOW IST1680I LOCAL IP ADDRESS 192.168.135.209 IST1680I REMOTE IP ADDRESS 192.168.135.182 IST136I SWITCHED SNA MAJOR NODE = ISTDSWMN IST081I LINE NAME = EL1001, LINE GROUP = EEGRPL1, MAJNOD = EEXCA IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1500I STATE TRACE = OFF IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST1657I MAJOR NODE VTAMTOPO = REPORT IST172I NO LOGICAL UNITS EXIST IST314I END

Overridden with Model for DYNTYPE=VN

Display from S193CDRM of EE PU over VRN

Default DISCNTIM of 10 overridden with 60

1. Note that message IST1392I shows the DISCNTIM that is in effect. The default for a Connection Network PU is 10 seconds, so you can see that the Model Major Node with DYNTYPE=VN overrode this value to 60 seconds.

2. Sample:1. MODVN VBUILD TYPE=MODEL 2. VNPU PU DISCNT=(DELAY,,60),DYNTYPE=VN <<<or>>> DISCNT=NO


Path Switch Timers for RTP Pipes

HPRPST The maximum time that VTAM tries a path switch before ending a connection. You might increase the

value for NETWRK if changes in your network require higher convergence times as, for example, is the case with RIP or if OSPF Dead Router Interval is high. You might consider HPRPST=(8M,4M,2M,2M) to ensure that network priority RTPs can survive an EE link inop/recovery.

PSRETRYProbably OK to leave default of 0 unless you have an unstable network or a network in which the better

paths activate later than the poorer paths. Alternatively, use automation to force a path switch with F NET,RTP,ID=<rtpname>.

PSWEIGHTdefault is to switch to better path if available

D NET,VTAMOPTS,FUNCTION=APPNCHAR IST097I DISPLAY ACCEPTED IST1188I VTAM CSV1R4 STARTED AT 10:43:07 ON 01/29/04 416 IST1349I COMPONENT ID IS 5695-11701-140 IST1348I VTAM STARTED AS NETWORK NODE ...IST1189I HPRPST = LOW 480S HPRPST = MEDIUM 240S IST1189I HPRPST = HIGH 120S HPRPST = NETWRK 60S ...IST1189I PSRETRY = LOW 0S PSRETRY = MEDIUM 0S IST1189I PSRETRY = HIGH 0S PSRETRY = NETWRK 0S IST1189I PSWEIGHT = LESSTHAN RESUSAGE = 100 ...IST314I END

D NET,VTAMOPTS,FUNCTION=APPNCHAR from z/OS

If you change, then ...Change at other end as well!

snasw rtp pathswitch-timers low-priority medium-priority high-priority network-priority

120S

1. If you are not likely to have alternate SNA routes available -- e.g., with EE everything looks like one hop away and alternate paths are controlled by IP routing protocols and not by SNA -- then PSRETRY doesn't really buy you anything. Therefore, the 0s value for PSRETRY is probably fine in this scenario.

2. However, path switch in general is valuable even when IP controls the underlying routes and even if there is only one "SNA Path" through the network, because basic HPR Path Switch code can preserve the sessions while an underlying IP link or network recovers. The path switch recovery depends on the setting of HPRPST in the VTAM Start Options.

+-HPRPST=(8M,4M,2M,1M)----------------------------------+ >>--+-------------------------------------------------------+->< +-HPRPST=(low_limit,med_limit,high_limit,network_limit)-+

range: | 5 secs-24 hours (low, medium, and high limits) | 5 secs-2 minutes (network limit)

+-PSRETRY=(0,0,0,0)---------------------------------------+ >>--+----------------------------------------------------------+->< +-PSRETRY=(low_tp_int,med_tp_int,high_tp_int,network_tp_int)--+ +-------------+----------------------------------------------------+| range: | 1 min-24 hours (expressed as nS, nM, or nH) | +-------------+----------------------------------------------------+

1. PSRETRY specifies the interval between attempts to switch a rapid transport protocol (RTP) session to another path which may be equal to or better than the current path. If you do not specify an S, M, or H, seconds are assumed.

2. You can specify different time limits for low, medium, high, and network transmission priority connections. For example, you might want a batch connection to wait longer intervals than an interactive connection before looking for another path which may be equal to or better than the current path.

3. Specifying too short an interval might have a negative effect on network performance, especially if there are a large number of RTP connections.4. Note: When using the function provided with PSRETRY, it is very important to ensure that the nodes in the network have a consistent and symmetrical view of the

weights of the paths involved, as indicated by way of APPNCOS tables.5. You can change the value of PSRETRY with the MODIFY VTAMOPTS command while VTAM is running.

+-PSWEIGHT=LESSTHAN-------+ >>--+-------------------------+----------------------------------------->< +-PSWEIGHT=-+-EQUAL----+--+ |-LESSTHAN-| +-SAMEROUT-+

1. Specifies the weight comparison between an old route and a newly calculated route before a path switch is attempted.2. Note: When using the function provided with PSWEIGHT, it is very important to ensure that the nodes in the network have a consistent and symmetrical view of

the weights of the paths involved, as indicated by way of APPNCOS tables.3. PSWEIGHT=EQUAL Indicated that a path switch is desired between equal weight routes.4. PSWEIGHT=LESSTHAN Indicates that a path switch is desired only if the newly calculated route is less than the current weight.5. PSWEIGHT=SAMEROUT Indicates that PSRETRY will attempt to switch a rapid transport protocol (RTP) session even if the path switch results in the selection of

the same route. This option will allow for a route to be switched to a more desirable VR within a VR-TG with multiple VRs.1. If you change values at one end of the pipe, you should consider changing them at the other end as well. The visual shows you how to set PSRETRY on a CISCO

router with the "snaswitch rtp pathswitch-timers."


Appendix A:Enterprise Extender Review


Enterprise Extender Overview (1)

EE Link is between two IP addresses (IP@) and looks like an APPN Transmission Group (TG)

It may carry SNA Sessions over RTP Connections that terminate on the EE Endpoints

CP-CP (if required)LU-LU, etc.

APPN/HPR RTP Connection is between SNA CPNames

RTP Connectionover IP

SNA Application

RTP

IP

DLC

API

IBM

IP Network

SNA Application/DLUR

RTP

IP

DLC

API

Fast UDP

Fast UDP

IUTSAMEH

z/OS

IP@ IP@CPName CPName

EE TG

x xRTP Pipe ('CNRnnnnn') for CPSVCMG

CP-CP Sessions x xRTP Pipe ('CNRnnnnn') for #BATCH

LU-LU Sessions

1. This diagram conceptually shows an EE connection between a zSeries LPAR and a DLUR node. Native SNA nodes are attached to the DLUR router using the normal LAN or link connections that they've used previously. Note that both CS in the zSeries and the HPR DLUR functions in the router are providing the HPR Rapid Transport Protocol (RTP) endpoint functions in addition to the ability to transform the SNA data into UDP IP packets to send across the underlying IP network. The applications in each EE node work as usual and communicate with the RTP endpoint which then uses UDP packets to send the data through the IP layer out through the DLC (Data Link Control). UDP, rather than TCP, has been used for EE, since the RTP endpoints already contain all the functions needed to acknowledge and recover frames, to provide flow control, etc..

2. The nodes use native IP routing, rather than requiring the routers to use encapsulation techniques such as that used with DLSw, which maximizes the throughput of the routers in the IP network. As shown in the diagram, pure IP routing directly into the S/390 is possible, although not required if the customer prefers to use a channel attached APPN node that provides the EE functions. Because native IP routing is used, the SNA network and applications can take advantage of the advances that are being made in IP routing and networking. There may also be an advantage to those customers who wish to use a single network transport, rather than different network transports for their IP network versus their SNA network.

3. The HPR function in each EE node provides error detection and selective retransmission of HPR data frames which are in error. HPR also allows non-disruptive rerouting around node or link failures. In addition to the alternate routing provided in the IP network shown in the diagram, if for some reason, the connection between the two EE endpoints goes down and there were another route (either pure SNA or another EE connection) between the nodes, the sessions using the failed EE connection could be non-disruptively rerouted around the failure. HPR also provides congestion control, allowing the sending node to dynamically adjust its sending rate based on the rate at which the receiving node is receiving the data. HPR also provides prioritization of the frames based on the SNA transmission priority of the data within the frame. In the IP network, the IP routers provide packet forwarding and can also prioritize the EE frames based on the PORT or Type of Service (TOS) bit settings associated with each packet. The EE nodes automatically associate different PORTs and TOS settings with the SNA data based on the APPNCOS transmission priority associated with each session.

4. In z/OS Communication Server the SNA components connect with the IP stack (address space) by means of a special IP device named "IUTSAMEH." The EE endpoint is identified by means of an IP address associated with a VIPA.

5. In a SNASwitch Router the EE endpoint is identified with a "snaswitch" definition that points to an Interface -- preferably a LOOPBACK interface -- whose IP address is used as the EE endpoint.

6. In IBM Personal Communications the EE endpoint is identified by a Link definition that is associated with EE. The IP address associated with that link is used as the EE endpoint address.



APPN/HPR RTP Connection may flow over a single APPN/HPR hop (previous page)

APPN/HPR RTP Connection may flow over multiple APPN/HPR hops

EE hop plus separate EE hop(s)Two EE hops (each in separate IP networks)

for LU2 - LU5 & LU2 - LU4 sessions

z/OS


SNA Application

RTP

IP

DLC

API

IBM

Private IP Network


RTP

IP

DLC

API

Fast UDP

Fast UDP

IUTSAMEH



Public IP Network


RTP

IP

DLC

API

Fast UDP

IP@CPName

EE TGEE TG

z/OSSNA Subarea or APPN

z/OS

Native SNA TG

x xRTP Pipe ('CNRnnnnn') for #INTER

LU1 LU2 LU3 LU4 LU5

LU2 to LU5 using #INTER

x xRTP Pipe ('CNRnnnnn') for #CONNECT

LU2 to LU4 using #CONNECT

x xRTP ('CNR...') for CPSVCMG

CP-CP Sessions

RTP ('CNR...') for CPSVCMG

CP-CP Sessions

x

1. This diagram shows you that the underlying path for the SNA HPR Session could be comprised of one EE TG (as with the case for the CP-CP sessions using CPSVCMG).

2. Or the underlying path for the RTP Pipe might be comprised of multiple links, as is the case with the LU-LU sessions, both of which are using two separate EE TGs, because the two IP networks are separated from each other: one is private and one is a public network and there is no Network Address Translation being performed in between the two. For all practical purposes, oneof the EE TGs could have been a native APPN TG.

3. In z/OS Communication Server the SNA components connect with the IP stack (address space) by means of a special IP device named "IUTSAMEH." The EE endpoint is identified by means of an IP address associated with a VIPA.

4. In a SNASwitch Router the EE endpoint is identified with a "snaswitch" definition that points to an Interface -- preferably a LOOPBACK interface -- whose IP address is used as the EE endpoint.

5. In IBM Personal Communications the EE endpoint is identified by a Link definition that is associated with EE. The IP address associated with that link is used as the EE endpoint address.



Sessions across APPN/HPR may also terminate and/or originate in Subarea, or APPN (no HPR), or LEN

APPN/HPR RTP Connection may flow over multiple APPN/HPR hops

EE hop plus separate EE hop(s)EE hop plus native APPN/HPR DLC

LU1 - LU5, LU2 - LU4Any combination of appropriate hops

z/OS


SNA Application

RTP

IP

DLC

API

IBM

IP Network


RTP

IP

DLC

API

Fast UDP

Fast UDP

IUTSAMEH


IP or SNANetwork


RTP

API

CPName

EE TGEE or APPN/HPR TG


z/OS

Native SNA TG

LU1 LU2 LU3 LU4 LU5

x xRTP Pipe ('CNRnnnnn') for #INTER

LU1 to LU5 using #INTER

x xRTP Pipe ('CNRnnnnn') for #CONNECT

LU2 to LU4 using #CONNECT


CP-CP Sessions

RTP ('CNR...') for CPSVCMG

CP-CP Sessions

x

1. This diagram expands on the previous diagram to show you that the sessions traversing EE TGs could also traverse a native APPN network or even a subarea network.



CP-CP Sessions not always required (nor possible) across an EE TGEnd Nodes (ENs) must have CP-CP sessions with 'Network Node Server'

Network Nodes must have CP-CP sessions where required for Topology and Search flowsCP-CP Sessions may not flow across Connection Network links

z/OS


SNA Application

RTP

IP

DLC

API

IBM

IP Network


RTP

IP

DLC

API

Fast UDP

Fast UDP

IUTSAMEH



IP Network


RTP

IP

DLC

API

Fast UDP

IP@CPName

EE TGEE TG


z/OS

Native SNA TG

LU1 LU2

LUX

LU4 LU5


CP-CP Sessions

RTP ('CNR...') for #CPSVCMG

CP-CP Sessions

x

z/OS

LU3

No CP-CP Session Required

LUX - LU4 Session

x RTP ('CNR...') for CPSVCMG

x xRTP ('CNR...') for #INTER

1. This diagram reminds you that an EE TG need not carry a CP-CP session at all. Therefore you might display an EE TG and never see any sessions flowing over it. Or you might see only LU-LU sessions flowing over it.

2. The diagram also reminds you that CP-CP sessions cannot flow over Connection Network links.


Appendix B:Monitoring EE Performance -

D NET,BFRUSE & z/OS Policy Agent


VTAM Buffer Usaged net,bfruse,buffer=short IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = BUFFER POOL DATA 648 IST632I BUFF BUFF CURR CURR MAX MAX TIMES EXP/CONT EXP IST633I ID SIZE TOTAL AVAIL TOTAL USED EXP THRESHOLD INCR IST356I IO00 338 110 109 110 18 0 36/----- 55 IST356I BS00 298 24 24 24 0 0 12/----- 12 IST356I LP00 2032 64 61 64 5 0 22/----- 4 IST356I XD00 697 5 5 5 0 0 4/----- 5 IST356I LF00 120 120 116 120 4 0 33/----- 30 IST356I CRPL 144 200 198 200 2 0 10/----- 25 IST356I SF00 112 64 62 64 2 0 10/----- 32 IST356I SP00 176 42 42 42 0 0 1/----- 21 IST356I AP00 56 56 56 56 0 0 3/----- 56 IST356I TI00 632 60 60 60 0 0 29/----- 60 IST356I CRA4 4080 12 10 12 2 0 2/----- 6 IST356I CRA8 8176 12 12 12 0 0 2/----- 6 IST924I ------------------------------------------------------------- IST449I CSALIMIT = NOLIMIT, CURRENT = 1698K, MAXIMUM = 1698K IST790I MAXIMUM CSA USED = 1698K IST1667I SYSTEM CSA LIMIT=1887436K IST449I CSA24 LIMIT = NOLIMIT, CURRENT = 56K, MAXIMUM = 56K IST790I MAXIMUM CSA24 USED = 57K IST595I IRNLIMIT = NOLIMIT, CURRENT = 0K, MAXIMUM = 0K IST981I VTAM PRIVATE: CURRENT = 691K, MAXIMUM USED = 698K IST924I ------------------------------------------------------------- IST1565I CSA MODULES = 1456K IST1565I CSA24 MODULES = 32K IST1565I PRIVATE MODULES = 5823K IST314I END

TIBUFsT1BUFsT2BUFs

1. Monitor IOBUFFERS2. Monitor TIBUFFERS:1.TIBUF: Used to perform input/output operations for CSM-capable protocols. This pool is in

31-bit storage. IBM-supplied values are appropriate for most systems. For HPR/IP defining more initial buffers and larger buffer extents may help increase throughput. Defining too few may cause an IP retransmit.

3.Monitor T1BUFFERS and T2BUFFERS:1.T1BUF: Similar to the TIBUF but larger. Used as a packing buffer by HiperSockets

acceslerator and qdio. Also used to contain the HPR headers and the media, IP and UPD headers for an Enterprise Extender connection. T1BUFs reside by default in Fixed storage. The IBM supplied values are appropriate for most systems. For HPR/IP defining more initial buffers and larger buffer extendts might helop incdrease thorughput. Defining too few might cause an IP retransmit.

2.T2BUF: Similar to the T1BUF but larger. T2BUFs are used exclusively for HiperSocets accelerator and QDIO when the T1BUF is perceived to be of insufficient size to pack all the headers and data. Also used by HPR for all retransmissions over HiperSockets and QDIO. T2BUFs reside by default in Fixed storage. The IBM supplied values are appropriate for most systems. For Enterprise Extender connections using QDIO/iQDIO device drivers, defining more initial buffers and larger buffer extends might help increase throughput. Definingt too few ight cause an IP retransmit.


Policy Agent, Windows, TOS Reset

At V2R7 and higher:Set MAXRATE to influence the Congestion Window set by the sender or influence TOS (precedence bits) for individual TCP connections.

For UDP, lower TOS (precedence bit) settings

At V2R8 and higher:Set RSVP Policy for Max and Minrate per flow. Use SNMP Subagent to Monitor

At V2R10 and higher:Set Differentiated Services parameters to influence the Congestion Window, TOS, and Packet Discards for an Aggregate set of data including EE!

Allowed for TCP, UDP, or EEUtilizes "Random Early Slowdown (RES)"If parameters exceeded, the connection

Can send "Best Effort" with change of TOS orCan "Drop" packets, which means

If TCP, lower congestion windowEach connection gets its "fair share" of bandwidthNo connection cut below "min rate"

If UDP, discard packetsIf EE, enter ARB slowdown EE!

1. UDPQUEUELIMIT in UDPCONFIG of the TCPIP PROFILE does not apply to EE, since EE uses Fast UDP. Fast UDP means that outbound UDP packets go from UDP to the IF layer (bypassing the IP layer) for efficiency. Likewise, inbound UDP packets for EE go from the IF layer to VTAM, bypassing regular UDP. Therefore, Policy Agent and the IDS UDP policies introduced in z/OS V1R2 to handle inbound UDP queues do not apply to EE either. However, Policy Agent may be used to regulate the EE bandwidth by making use of the token bucket policies introduced in z/OS V2R10. Token Bucket policies are what we begin introducing on this page.

2. QOS Introduced in V2R7Allowed policing of traffic by administrative policy (Differentiated Services) for a given:

1. Interface2. IP Address/Port range3. Time/date

1. Policed traffic on a TCP connection basis1. Max connections per policy2. Maxrate, minrate per connection3. Updating TOS byte if desired

2. Policed UDP traffic only via updated TOS 3. QOS Enhanced in V2R8

1. Added Resource Reservation Protocol (RSVP)2. Allowed reserving bandwidth in addition to policing (Integrated Services)3. Implemented by an RSVP Agent4. OS/390 UNIX RSVP Agent 5. Traffic reserved via RSVP API (RAPI)6. Service Policies updated to allow policing of RSVP reservations

1. Max reserved flows per policy2. Max rate, token bucket, service type per flow

7. Added ability to monitor performance with Service Level Agreement Subagent and SLAPM Experimental MIB -- In the interest of time, we do not discuss either the RSVP function or the SLA Subagent function in this presentation.

4. Enhancements in V2R101. Aggregate Congestion Window and TOS control2. The new traffic parameters are the mean rate, peak rate, burst size, max pkt size, excess traffic treatment, and out of profile transmitted TOS. Thus, instead of

policing each connection, you are policing the current number of active connections against an allowed bandwidth, always allowing full utilization of the bandwidth.

3. Random Early Slowdown simply means that that connection that will be policed is whichever one happened to send the packet at the time traffic for the aggregate was exceeded. Theoretically, over time, the connections that are sending too much will be the ones that are slowed down.

4. When a TCP connection is policed, it will only be allowed to send 1/x amount of data, where x is the currently active number of connections. 5. The new traffic parameters actually "apply" to both Differentiated Services (administratively defined policies implemented in CS/390 via the Policy Agent

Configuration) and RSVP, as follows:6. Differentiated Services - the 6 new parameters are coded on the PolicyAction statement, and anytime TCP, UDP, or EE connections come up that fit the

parameters of the policy rule pointing to this action, they will be policed by these parameters.


PolicyRule DiffServ_Rule1 { OutboundInterface 192.168.116.98 DestinationAddressRange 211.40.100.0-211.40.100.255 DestinationPortRange 5000:9999 SourcePortRange 20-21 PolicyActionReference DiffServ_Action1 ApplicationName FTP* DayOfMonthMask 1111111111000000000000000000000 DayOfWeekMask 0111110 TimeOfDayRange 06:00-20:00 } PolicyAction DiffServ_Action1 { PolicyScope DataTraffic OutgoingTOS 01000000 MaxDelay 50 MaxConnections 100 Permission Allowed DiffServInProfileRate 256 # 256 Kbps DiffServInProfileTokenBucket 512 # 512 Kbits DiffServInProfilePeakRate 512 # 512 Kbits DiffServInProfileMaxPacketSize 120 # 120 Kbits DiffServOutProfileTransmittedTOSByte 00000000 DiffServExcessTrafficTreatment BestEffort }

}{

If Drop - UDP: discards packetsTCP: lowers congestion windowEE: advise RTP to enter ARB slowdown

If BestEffort - Send but change TOS byte

Defining Aggregate Performance

EE!

1. This sample shows you how to deploy Policy Agent in order to control aggregate flow for all connections that satisfy the rule and action you see here.2. Note the use of the DiffServ... parameters.3. These rates mean the following:4. DiffServInProfileRate is the average or mean rate that is desired to be transmitted over time. This is useful to specify. For example, 1 megabyte

(8000 Kbits per second). Unlike MaxRate/MinRate which applies on a per TCP connection basis, these DiffServ parameters apply to aggregated flows (multiple TCP connections can be mapped to a single policy action). Also, it is important to note that when DiffServ parameters are enforced against TCP traffic, the TCP minimum rate will determine whether the DiffServ parameters are enforceable, as described in the attribute MaxRate. This is due to an optimization provision where TCP is forced to slow down when it attempts to send beyond the committed bandwidth specified with DiffServ parameters in the policy action with DiffServExcessTrafficTreatment specified as Drop. TCP cannot slow down beyond the TCP minimum rate, even if a violation occurs.

5. DiffServInProfileTokenBucket is the burst size.This is useful to specify. How much data is allowed to be sent from TCP/IP into the network and still be allowed to be transmitted at the mean rate above.

6. DiffServInProfilePeakRate is the highest rate that is allowed to be transmitted for a shorter interval of time. For example, though a customer may only want on average 1 megabyte of data per second, he/she may allow a 2 megabyte rate for 1/2 second.

7. DiffServInProfileMaxPacketSize is the amount of data that will be policed at the peak cell rate For example, if the peak rate is 2 megabytes per second, and the max pkt size is 1492, TCP/IP will only allow one packet to be transmitted every 3/4 of a millisecond (1492/2meg). Again, if an application is "dumping data", TCP/IP will enforce the peak rate, and anytime more than one packet is sent at one time, TCP/IP will begin to slow this TCP connection. The peak rate can be achieved over a longer period of time if the maxpktsize is entered in multiples of packets. For example, if the maxpacketsize is entered as 14920 in the example above, TCP/IP will allow 10 pkts in a 7.5 millisecond range before enforcing slowdown.

8. A peak or mean rate of 0 means no policing of that rate.9. Peak rate cannot be enforced without mean rate policing. However, you can enforce mean rate without peak rate. 10. DiffServExcessTrafficTreatment: Specifies what action to take when traffic exceeds its profile. Two values can be specified with this attribute: Drop

or BestEffort. The default is BestEffort. 11. When the DiffServExcessTrafficTreatment is BestEffort, the excess packets are still sent; however, they are sent with the

DifServOutProfileTransmittedTOSByte value. (The default for TOS value is 0.) This is specified on the DiffServOutProfileTransmittedTOSByte. NOTE: "BestEffort" treatment for Enterprise Extender would not be applicable, because the TOS bytes must remain throughout the effort as they originate to provide for the proper treatment of network layer and ldlc traffic.

12. When the DiffServExcessTrafficTreatment is Drop, the results are:1. For UDP discards packets2. For TCP lowers congestion window3. For EE enters ARB slowdown because stack informs RTP to enter ARB slowdown.

13. DiffServOutProfileTransmittedTOSByte1. Specifies the TOS/DS value to send with the excess traffic (if action is to send excess traffic as best effort instead of dropping). BestEffort wold

not be used for EE, so this parameter about the TOSByte is irrelevant for EE.


References


RedbooksSG24-4656 Subarea to APPN Migration: VTAM and APPN ImplementationSG24-5291 SNA and TCP/IP IntegrationSG24-5957 Migrating Subarea to an IP Infrastucture

Parallel Sysplex Test Report, GC28-1963-11Standard z/OS Publications:

IP Migration (SC31-8773) IP Configuration Guide (SC31-8775) IP Configuration Reference (SC31-8776) SNA Migration (SC31-8774)SNA Network Implementation Guide (SC31-8777)SNA Resource Definition Reference (SC31-8778)

User Technical ConferencesSHARENetworking Solutions Technical Conference (NSTC)

References


Handy Quick Reference Cards

VTAM Topology CommandsD NET,TOPO,ORIG=cp1,DEST=cp2,APPNCOS=#INTERD NET,TOPO,DEST=cp1,ORIG=cp2,APPNCOS=#INTER

Shows the WEIGHT of a TG for a given APPNCOSin each direction

D NET,TOPO,ID=cp1,APPNCOS=#INTERShows the WEIGHT of a Node for a APPNCOS

F NET,TGP,ID=cp1,TGPNAME=ESCONAssign different TG characteristics

D NET,TOPO,ORIG=cp1,DEST=cp2,TGN=21,FUNCTION=QUIESCE

Stop calculating Routes over this linkD NET,TOPO,ORIG=cp1,DEST=cp2,TGN=21,FUNCTION=NORMAL

Consider this link in Route CalculationF NET,VTAMOPTS,ROUTERES=255,ID=host-cp

Move all intermediate sessions awayD NET,COS,TYPE=APPN

Shows the currently used APPNCOS TableCOSAPPN is outdated! ISTACST2 should be used if possible at all NNs

D NET,TGPSShows the currently used TG ProfilesProfiles and Capacities

ISDNSWTD TGP CAPACITY=10K =X'30'EEXTWAN TGP CAPACITY=56K =X'43'

SDNNSWT TGP CAPACITY=64K =X'45'TOKNRING TGP CAPACITY=4M =X'75'ETHERNET TGP CAPACITY=10M =X'80'TRING16M TGP CAPACITY=16M =X'85'XCF TGP CAPACITY=25M =X'8A'CHANNEL TGP CAPACITY=36M =X'8E'ESCON TGP CAPACITY=200M =X'A2'

D NET,VTAMOPTS,FUNCTION=APPNCHARShows APPN relevant VTAM Startoptions

HPR Quick Reference Card (VTAM) - 1VTAM HPR CommandsD NET,RTPS,CPNAME=dest_cp,APPNCOS=#INTER

Shows all pipes to a destination for agiven APPNCOS. Ideally only 1.

D NET,RTPS,CONGEST=YESShows all pipes that are congested

D NET,RTPS,SWITCH=YESShows all pipes that are being pathswitched

D NET,ADJCP,ID=dest_cp,EShows all linkstation PUs and the HPRpipes traversing this PU

D NET,RTPS,ID=cnr_pu00067,TEST=YESTest the responsetimes of a pipeNot all platforms support this!

D NET,ID=cnr_puShows basic HPR Information and APPN PathAllowed ARB Sendrate, Maximum NLP size

D NET,ID=cnr_pu,HPRDIAG=YESShows detailed HPR Informationactual ARB Sendrate, Retransmissions etc...

F NET,VTAMOPTS,PSWEIGHT=EQUALAllow pathswitch to alternate path with same weight

F NET,RTP,ID=cnr_puSwitch a Pipe to an alternate path

F NET,VTAMOPTS,PSRTRY=(60,60,60,60)Switch all Pipes to an alternate pathimmediately (... and every 60 secs)

F NET,VTAMOPTS,PSRTRY=(0,0,0,0)Turn off automatic pathswitching

F NET,VTAMOPTS,PSWEIGHT=LESSTHANOnly pathswitch to alternate path with lower weight

V NET,INACT,ID=cnr_pu,TYPE=FORCEBrings down a pipe.

1. Thanks go to Matthias Burkhard of IBM Germany for allowing me to include a copy of this Quick Reference card: Network Operation in HPR Networks.

2. Network Operationin HPR Networks1. Matthias Burkhard2. IBM Global Services Germany3. ITS EMEA NW SW Support4. Technical Leader5. [email protected]

3. Reference:1. z/OS Communication Server2. Quick Reference3. SX75-0124-02

Enterprise Extender CommandsD NET,ADJCP,ID=dest_cp,E

Shows all linkstation PUs & HPR pipes traversing this PUD NET,ID=linkstation_pu

Shows the IP address of the remote EE host D NET,EE,IPADDR=<ipaddr>,HOSTNAME=...

V1R6 command to obtain EE connection informationTSO PING ip addr ( SRCIP ee-vipa COUNT 10 LENGTH 1460

Test IP connectivity (FW Filter must allow ICMP!)TSO TRACERTE ip addr

Check the IP path (FW Filter must allow ICMP!)

APPN SearchingD NET,SRCHINFO,LIST=ALL

Shows outstanding APPN LOCATESD NET,APING,ID=dest_cp,LOGMODE=#INTER

Use a #INTER HPR PipeD NET,APING,ID=dest_cp,LOGMODE=ISTCOSDF

Use a #CONNECT HPR PipeD NET,APING,ID=dest_cp,LOGMODE=#BATCH

Use a #BATCH HPR PipeD NET,APING,ID=dest_cp,ITER=25,CONSEC=4,SIZE=1440,ECHO=NO

Send 100 packets of 1440 bytes in one direction only

HPR Quick Reference Card (VTAM) - 2APING CommandsF NET,RESOURCE,ID=dest_lu,SRCLEAR=YES

Deletes Search Reduction EntryD NET,DIRECTRY,ID=dest_lu,SCOPE=NSEARCH

Initiates an APPN LOCATED NET,ADJCLUST,NETID=dest_netid

Shows the external BNs, that should be searchedV NET,INACT,ID=adj_cp,IDTYPE=CP,I

Brings down CPCP Sessions and cancelsV NET,ACT,ID=adj_cp,IDTYPE=CP

Activates CPCP Session againF NET,RESOURCE,ID=dest_lu,SRCLEAR=YES

Deletes Search Reduction Entry

VIT To Dataspace and DumpF NET,TRACE,TYPE=VTAM,SIZE=999,DSPSIZE=5-> OPT=(CIA,HPR),SUBTRACE=ARBP

Should be running before a problem occursBest via ATCSTR00 TACE TYPE=VTAM,...

If problem occurs ...F NET,CSDUMP

Takes a dump of VTAM and VIT Dataspace immediatelyF NET,CSDUMP,SENSE=08400002

Takes a dump of VTAM and VIT Dataspacewhen a sensecode is generated in this VTAM

F NET,CSDUMP,MESSAGE=IST663ITakes a dump of VTAM and VIT Dataspacewhen a message is generated in this VTAM

F NET,VTAMOPTS,INOPDUMP=YESTakes a dump of VTAM and VIT Dataspacewhen an INOP is generated in this VTAM

External VITS GTF.GTF (BLOK=8M, 200 Cyls)ww,TRACE=USRPxx,USR=FE1yy,ENDzz,UWhen GTF is runningF NET,TRACE,TYPE=VTAM,DSPSIZE=0

turn off Dataspace TraceF NET,TRACE,TYPE=VTAM,MODE=EXT,BFRNUM=0,-> OPT=(HPR,CIA,SSCP,PIU),SUBTRACE=ARBP

For time sensitive HPR problemsF NET,TRACE,TYPE=VTAM,MODE=EXT,BFRNUM=8,-> OPT=(HPR,CIA,SSCP,PIU),SUBTRACE=ARBP

For other HPR problemsWhen Problem occurredP GTFF NET,NOTRACE,TYPE=VTAM,MODE=EXT,OPT=ENDF NET,TRACE,TYPE=VTAM,DSPSIZE=5

HPR Quick Reference Card (VTAM) - 3Session DiagnosisD NET,SESSIONS,SCOPE=Q,LIST=ALL

Shows all sessions in a temporary setup statusD NET,SESSIONS,SCOPE=PEND,LIST=ALL

Shows all sessions in a temporary setupstatus

D NET,SESSIONS,LU1=luname,LIST=ALLShows all sessions of a LU

D NET,SESSIONS,SID=fq_pcidShows information about a session

V NET,TERM,SID=fq_pcidBring down a session

D NET,TABLE,ID=modetab,TYPE=MODETAB, ->LIST=ALL

Shows all LUs using a LOGMODE TableF NET,TABLE,ID=lu,OPT=ASSOC,OLDATB=*, ->-> NEWTAB=modetab,TYPE=MODETAB

Assign a new MODETAB to an existing LUF NET,VTAMOPTS,DYNMODTB=modetab

Assign a new MODETAB to new dynamic CDRSCs

May also specify 'detail" with most of these

May also specify | include <name> to filter

Ping sna <netid.cpname> Sh snasw pdlogSh snasw class-of-service Sh snasw portSh snasw connection-network Sh snasw puSh snasw directory Sh snasw rtpSh snasw dlctrace Sh snasw sessionSh snasw dlus Sh snasw statisticsSh snasw ipstrace Sh snasw summary-ipstraceSh snasw link Sh snasw topologySh snasw lu Ping <ipaddr> in extended command

mode: give source IPaddrSh snasw mode Traceroute <ipaddr> in interactive mode:

give source IPaddrSh snasw node Sh ip route

Sh ip route ospf

Quick Reference to Useful Commands at CISCO For Enterprise Extender Management

Ping <ipaddr or hostname> (srcip <ipaddr>

D TCPIP,<tcpname>,N,ROUTE

Tracerte <ipaddr or hostname> (srcip <ipaddr>

D TCPIP,<tcpname>,OMPR,RTTABLE

D TCPIP,<tcpname>,N,BYTEINFO,CLIENT=NET D TCPIP,<tcpname>,N,HOME D TCPIP,<tcpname>,N,DEV[,INTFNAME=<linkname>]

Quick Reference to Useful Commands at z/OS TCP/IP for Enterprise Extender Management


End of Topic

Freelance Graphics - S12 - IBM WWW PageFILE/S3622_S12_EEMGT.pdfITM/NP V2.1), which can give you a...

Documents

Transcript of Freelance Graphics - S12 - IBM WWW PageFILE/S3622_S12_EEMGT.pdfITM/NP V2.1), which can give you a...