Question & Answer
Question
If you use VTAM Common Management Information Protocol (CMIP) services, you may encounter the following alternative performance issues:
excessive CPU cycles are being consumed
resources hung in transient states are not being discovered soon enough
.
Answer
When you set VTAM's OSIMGMT start option to load and activate VTAM CMIP Services and the VTAM topology agent (OSIMGMT=YES), VTAM's UPDDELAY start option specifies the maximum time the VTAM topology agent waits between checking the list of resources in transient states (such as PENDING ACTIVE and PENDING INACTIVE). Sixty seconds is the default value for UPDDELAY. If the resources have been in transient states long enough for updates on those resources' topology, status will be sent to the topology manager.
Sixty seconds may be too short an interval between checks if excessive CPU cycles are being consumed to send resource updates. Excessive CPU consumption indicates that resource updates are being sent too frequently. On the other hand, sixty seconds may be too long an interval between checks if resources hung in transient states are not being discovered soon enough. If such resources are not being discovered soon enough, that indicates that resource updates are not being sent frequently enough.
The range of permitted values for UPDDELAY is 5-65535 seconds.
You should:
increase the value of UPDDELAY if excessive CPU cycles are being consumed.
decrease the value of UPDDELAY if resources hung in transient states are not being discovered soon enough
You can modify the UPDDELAY value while VTAM is running by using the MODIFY VTAMOPTS command.
For more information on tuning UPDDELAY, see the discussion of UPDDELAY in the z/OS Communications Server: CMIP Services and Topology Agent Guide. For more information on CMIP and topology agent in general, see the z/OS Communications Server SNA Network Implementation Guide.
Product Synonym
ZOSCS COMMSERVER
Was this topic helpful?
Document Information
Modified date:
04 January 2016
UID
dwa1246427