.-HPRPSDLY--=--value_of_hprpsdly_start_option-.
>>-+---------------------------------------------+-------------><
'-HPRPSDLY--=--+-ps_delay-+-------------------'
'-EEDELAY--'
statements: |
GROUP |
dependencies: |
Enterprise Extender connection
network connections only |
range: |
0 - 240 (in seconds) |
Specifies the time that elapses before RTP pipes enter
the path switch state.
The ARB flow control algorithm is sensitive to minor variations
in the round-trip time and to unpredictable response times from the
partner. This sensitivity might cause RTP endpoints to prematurely
enter the path switch state. Although this situation does not affect
availability, it does consume CPU cycles and it also causes a significant
number of path switch messages to be written to the console log.
The HPRPSDLY operand is valid only for RTP pipes that
are directly attached to the Enterprise Extender (EE) connection network
that is defined by this group. This operand affects only path switches
that are the result of an unresponsive partner (path switches that
generate the message IST1818I PATH SWITCH REASON: SHORT REQUEST
RETRY LIMIT EXHAUSTED). The HPRPSDLY operand does not control
path switches that are initiated as a result of a TG INOP, F RTP commands,
or the PSRETRY function. If you do not code this operand, VTAM® uses the value that you coded
on the HPRPSDLY start option.
- HPRPSDLY=ps_delay
- Specifies the number of seconds that RTP pipes must delay prior
to entering the path switch state. During this time, the RTP endpoint
periodically tries to contact the partner in an effort to avoid switching
paths. The value 0 indicates that the RTP nodes enter the path switch
state when a predetermined number of retry attempts have been unsuccessful.
- HPRPSDLY=EEDELAY
- Specifies that VTAM calculates
the number of seconds that RTP pipes must delay prior to entering
the path switch state. The value that is calculated allows enough
time for the Enterprise Extender (EE) keep-alive mechanism to cause
the EE connection to become inoperative if connectivity to the partner
is lost. Unnecessary path switches are avoided while EE determines
whether there is a loss of connectivity to the partner.
For predefined EE connections, define this parameter on
the PU definition in the switched major node. For dial-in EE connections
with associated PUs that are dynamically created, define this parameter
on the model major node (DYNTYPE=EE) PU definition statement.
Results: - When the EEDELAY value is specified, the value that is calculated
for the HPR path-switch delay might be as long as 253 seconds.
- If a predefined EE connection is established between two EE endpoints
before the VRN connection is established (using the same VIPA addresses),
the VRN connection uses the established predefined EE connection.
In this case, to control the HPRPSDLY value associated with the EE
VRN, you must specify the HPRPSDLY operand on the EE PU definition
statement (for example, on the switched PU definition). Optionally,
you can specify the HPRPSDLY value as a VTAM start
option.
Tips: - This operand can be useful when the RTP partner is on a node that
is CPU-constrained or that is running in a virtualized environment.
In both of these situations, allowing additional time for the RTP
partner to respond might avoid unnecessary processing associated with
a path switch.
- If alternate routes exist, specifying a long delay time might
cause unnecessary delays for the sessions that are using this RTP
pipe.