Expert Advice

N3V_HPR_Conn_Path_Switch  
Situation Description
Suggested Actions
Situation Description

HPR RTP connection with path switch due to error

 

Suggested Actions

A number of path switches have 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: By default, this situation only tests for No NCB.

This situation is probably triggered by losing 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(R) 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(R) address space.
  • Redistribute the Communications Server for z/OS workload on the remote system (receive side) of the HPR RTP connection.

 

Copyright IBM Corp. 2006 All Rights Reserved US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contact IBM