Problem determination sample
This appendix provides an example of the steps to follow when you need to determine why a z/OS system will not connect to the IBM zAware application.
Diagnosing System Logger connection errors
This sample provides an example of a problem whereby System Logger was unable to connect to the IBM zAware application. The sample illustrates the key messages to look for, and explains which documents provide the information you need to address this problem.
In our sample, when attempting to connect to IBM zAware, System Logger failed and displayed the message shown in Example D-1.
Example D-1 System Logger error message
IXG372I ZAI LOGSTREAM CLIENT MANAGER ERROR 758
FOR LOGSTREAM SYSPLEX.OPERLOG
FUNCTION=BPX1CON ERRNO=00000467 ERRNOJR=76630291
The error indicates that the function experiencing the failure was BPX1CON (FUNCTION=BPX1CON). It also provides two sets of error codes, namely ERRNO=00000468 ERRNOJR=76630291.
To connect to IBM zAware, System Logger uses UNIX System Services Assembler callable services. These callable services are described in z/OS UNIX System Services Programming: Assembler Callable Services Reference, SA22-7803.
The BPX1CON service is the equivalent of a socket connection call (trying to establish a connection between two sockets). In this case, the call would be between System Logger and IBM zAware.
The error and reason codes are described in z/OS V1R13.0 UNIX System Services Messages and Codes, SA22-7807. The return code ERRNO=00000468 (hex value) indicates ECONNREFUSED = The attempt to connect was rejected.
The reason code ERRNOJR=76630291 (hex value) is actually 7663 (reason code qualifier) and 0291 (reason code). Researching the reason code qualifier shows us that it is z/OS TCP/IP-related. The reason code indicates JrTcpError (TCP returned an error identified by the return code).
So, the error is revealed to be a socket connection error. We follow these steps to determine why the error occurred:
1. We need to know the endpoint connections. On the system that was experiencing the problem, IEASYS sets IXGCNF=00.
2. IXGCNF sets the SERVER value to 10.1.110.3. So we are trying to reach the IBM zAware server using this IP address. This means that we have to have some route to this IP address.
3. Trying to ping 10.1.110.3 from this system times out. This indicates a routing issue.
Now we have to discover why we cannot reach this address (routing issue). For a useful guide to resolving TCP/IP routing issues, see “Diagnosing network connectivity problems” in z/OS Communications Server Diagnosis Guide, GC31-8782.
4. Next we display the routes on the system by using the D TCPIP,,NETSTAT,ROUTE command. We are looking for something with an 10.X.X.X IP address range. The output from the command is shown in Example D-2.
Example D-2 Output from D TCPIP,,NETSTAT,ROUTE command
EZZ2500I NETSTAT CS V1R13 TCPIP 714
DESTINATION GATEWAY FLAGS REFCNT INTERFACE
DEFAULTNET 9.12.4.1 UGS 0000000000 OSA2100LNK
DEFAULTNET 9.12.4.1 UGS 0000000000 OSA2120LNK
9.12.4.0/22 0.0.0.0 US 0000000001 OSA2100LNK
9.12.4.0/22 0.0.0.0 US 0000000000 OSA2120LNK
9.12.4.59/32 0.0.0.0 UH 0000000000 OSA2100LNK
9.12.4.77/32 0.0.0.0 UH 0000000000 OSA2120LNK
9.12.9.162/32 0.0.0.0 H 0000000000 CTC4A21
127.0.0.1/32 0.0.0.0 UH 0000000001 LOOPBACK
192.168.50.4/32 0.0.0.0 H 0000000000 EZASAMEMVS
192.168.50.4/32 0.0.0.0 UH 0000000000 EZAXCF$A
192.168.50.6/32 0.0.0.0 UHS 0000000000 EZAXCF$A
201.2.10.12/32 0.0.0.0 UH 0000000000 VIPLC9020A0C
5. The output does not show any 10.x.x.x addresses. This indicates that we have no network interface with 10.x.x.x. However, that address might be reachable through our default gateway. So we try to ping 10.1.110.3 from somewhere else in the 9.x.x.x network (my workstation). The ping times out.
It appears that no router in the network knows how to get to the subnet where 10.1.110.3 resides.
6. However, we know that one of the other systems in the same sysplex is able to successfully connect to the IBM zAware LPAR using that address. So on that system we display its routing table using the D TCPIP,,NETSTAT,ROUTE command. The output is shown in Example D-3.
Example D-3 Output from D TCPIP,,NETSTAT,ROUTE command on the other system
EZZ2500I NETSTAT CS V1R13 TCPIP 021
DESTINATION GATEWAY FLAGS REFCNT INTERFACE
DEFAULTNET 9.12.4.1 UGS 0000000000 OSA2040LNK
DEFAULTNET 9.12.4.1 UGS 0000000000 OSA2060LNK
9.12.4.0/22 0.0.0.0 US 0000000000 OSA2040LNK
9.12.4.0/22 0.0.0.0 US 0000000000 OSA2060LNK
9.12.4.58/32 0.0.0.0 UH 0000000000 OSA2040LNK
9.12.4.110/32 0.0.0.0 UH 0000000000 OSA2060LNK
9.12.9.164/32 0.0.0.0 H 0000000000 CTC4A31
10.1.110.0/24 0.0.0.0 US 0000000001 IUTIQDF4LNK
10.1.110.2/32 0.0.0.0 UH 0000000000 IUTIQDF4LNK
127.0.0.1/32 0.0.0.0 UH 0000000018 LOOPBACK
192.168.50.0/24 0.0.0.0 US 0000000000 IQDIOLNKC0A83206
192.168.50.4/32 0.0.0.0 UHS 0000000000 EZAXCF$2
192.168.50.6/32 0.0.0.0 H 0000000000 EZASAMEMVS
192.168.50.6/32 0.0.0.0 UH 0000000000 IQDIOLNKC0A83206
192.168.50.6/32 0.0.0.0 UH 0000000000 EZAXCF$2
201.2.10.13/32 0.0.0.0 UH 0000000000 VIPLC9020A0D
201.2.10.200/32 0.0.0.0 UH 0000000000 VIPLC9020AC8
7. On this system, we see that there is a route to the 10.1.110.0/24 network and the interface is IUTIQDF4LNK. So we display this interface on using the D TCPIP,,NETSTAT,DEVLINKS,INTFN=IUTIQDF4LNK command. The output is shown in Example D-4.
Example D-4 Output from D TCPIP,,NETSTAT,DEVLINKS,INTFN=IUTIQDF4LNK command
EZZ2500I NETSTAT CS V1R13 TCPIP 039
DEVNAME: IUTIQDF4 DEVTYPE: MPCIPA
DEVSTATUS: READY CFGROUTER: NON ACTROUTER: NON
LNKNAME: IUTIQDF4LNK LNKTYPE: IPAQIDIO LNKSTATUS: READY
IPBROADCASTCAPABILITY: NO
ARPOFFLOAD: YES ARPOFFLOADINFO: YES
ACTMTU: 8192
VLANID: NONE
READSTORAGE: GLOBAL (2048K)
SECCLASS: 255 MONSYSPLEX: NO
IQDMULTIWRITE: DISABLED
ROUTING PARAMETERS:
MTU SIZE: 8192 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT SRCFLTMD
----- ------ --------
224.0.0.1 0000000001 EXCLUDE
SRCADDR: NONE
LINK STATISTICS:
BYTESIN = 298990
INBOUND PACKETS = 3559
INBOUND PACKETS IN ERROR = 0
INBOUND PACKETS DISCARDED = 0
INBOUND PACKETS WITH NO PROTOCOL = 0
BYTESOUT = 2536839
OUTBOUND PACKETS = 4708
OUTBOUND PACKETS IN ERROR = 0
OUTBOUND PACKETS DISCARDED = 0
8. Knowing that system has a connection, we check the TCP PROFILE data set for that system. The TCPIP JCL points to SYS1.#@$A.TCPPARMS(PROFILE).
Checking this member for the LNKNAME listed in the output (IUTIQDF4LNK), we find the following:
DEVICE IUTIQDF4 MPCIPA NOAUTORESTART
LINK IUTIQDF4LNK IPAQIDIO IUTIQDF4
9. We look up this statement in “DEVICE and LINK - MPCIPA HiperSockets devices statement” of the z/OS Communications Server IP Configuration Reference, SC31-8776. Here we find the following information about the statement:
DEVice--device_name--MPCIPA
device_name
The name of the device must use the following convention:
Prefix is IUTIQD.
Suffix xx [hexadecimal value (00x - FFx) of the corresponding IQD CHPID]. This value cannot conflict with the IQD CHPID used for dynamic XCF.
10. We now know that F4 is the HIPERSOCKETS CHPID being used by the system that is able to connect. Using a D M=CHP(F4) command on the system that cannot connect, we see that F4 is not defined to that system, as shown in Example D-5.
Example D-5 Output from D M=CHP command
IEE174I 10.54.03 DISPLAY M 747
CHPID F4: TYPE=00, DESC=UNKNOWN, OFFLINE
DEVICE STATUS FOR CHANNEL PATH F4
CHP=F4 DOES NOT EXIST
************************ SYMBOL EXPLANATIONS ************************
+ ONLINE @ PATH NOT VALIDATED - OFFLINE . DOES NOT EXIST
* PHYSICALLY ONLINE $ PATH NOT OPERATIONAL
11. Checking the IBM zAware HMC firmware definition, we see that it has a channel definition for F4. But when checking the HMC, we realize that the system that is able to connect is on the same CPC as the IBM zAware partition, but that the other system is on a different CPC. Therefore, the other system could not use a Hipersocket connection (unless it was extended through the IEDN network).
12. To connect the system with the problem to an IBM zAware partition, we have to use an OSA connection from this LPAR to the IBM zAware OSA interface.
In this case, the problem turned out to be that both systems were using the same IXGCNFxx member, but the SERVER value in that member was not valid for the failing system.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.