N3V_HPR_Conn_Path_Switch
A number of path switches have occurred with one or more of the following
path switch triggers:
- TGINOP : The link of the first (or only) hop of
the HPR RTP pipe is not functioning and triggers a path switch.
- SRT (Short Request Timer) Retries: The end point
has repeatedly not responded within the specified time interval to timing-sensitive
packets sent to it. Therefore, the existing path is assumed to be unusable
and triggers a path switch.
- No NCB (Network Control Block): The DLC associated
with the HPR RTP connection can no longer be accessed. The first hop of the
RTP pipe is therefore no longer usable and triggers a path switch.
- Modify RTP Command
- Auto Path Switch
- Partner Initiated
Note:
The default definition for this situation only tests for the No NCB value.
This is probably because of lost connectivity to the remote endpoint or
constrained CPU in the remote z/OS Communications server address space.
To determine this, the following metrics in the HPR connections table are
used:
- Path switches
- Path switch trigger
This situation occurs when the path switches value is greater than zero
for 3 consecutive intervals and the path switch trigger value is one of the
following in the third interval:
- TGINOP
- SRT retries
- No NCB
This is probably because of lost connectivity to the remote endpoint or
constrained CPU in remote VTAM address space. To resolve this problem, use
the following procedures:
- Issue a trace route command to determine the most probable routing path.
- Determine if this path is using a secondary or backup routing path. If
it is, identify and fix the problem with the primary path.
- Query the routing interfaces on the routing path to determine the number
of packets dropped.
- Identify the routers along the routing path with the highest numbers of
packets dropped.
- Validate the router configuration parameters.
- Check the OSA adapter metrics to determine if adapter constraints (such
as excessive processor utilization or discards at the receive side) exist.
- Confirm that the CPU utilization is high for the remote system (that is,
the receive side) Communications Server for z/OS address space.
- Redistribute the Communications Server for z/OS workload on the remote
system (receive side) of the HPR RTP connection.
By default, this situation does not start automatically and must be manually
started to run.