z/OS MVS Planning: Global Resource Serialization
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Ring disruption recovery

z/OS MVS Planning: Global Resource Serialization
SA23-1389-00

In a global resource serialization ring, communication and connectivity errors are often associated with the following messages:
  • ISG177E
  • ISG178E
For information about ISG177E and ISG178E disruption messages, see ISG177E and ISG178E recovery.
During a ring disruption and the ensuing recovery, the status of the systems should to change from:
  • ACTIVE (before the disruption)
  • INACTIVE (during the disruption)
  • QUIESCED
  • ACTIVE

As the ring is rebuilt, the systems will be returned to ACTIVE status one at a time. One of the systems in the complex is charged with bringing a QUIESCED system back into the ring. This system will be indicated by a status of ACTIVE+VARY.

Even in the best tuned complexes, ring disruptions periodically occur, especially if there are systems with small LPAR percentages or single processor machines that might become unresponsive due to other error conditions (a large system dump). After the error condition is corrected, the complex should automatically return to normal operation.

If these messages appear frequently, it is likely that there is a configuration error, either:
  • The specified TOLINT value is too small

    TOLINT (Toleration Interval) is the maximum amount of time that the system will wait for the RSA to arrive before indicating an error condition and disrupting the ring. The default is TOLINT(180), which is 180 seconds or 3 minutes. You need to ensure that the TOLINT value is not too low, causing false error indications or too high, causing an excessive delay in recognizing a ring disruption situation. Use the SETGRS TOLINT= command to increase the value. You can use the ROUTE *ALL command to effect the change on all systems in the sysplex at the same time.

  • XCF communication is not responsive

    Check your XCF signalling configuration to ensure that messages for the SYSGRS group are being serviced without excessive delay. Use data from RMF™ (or another performance monitor) to ensure that XCF signalling is optimized for the SYSGRS group. For more information on how to tune XCF signalling, see Tuning a Sysplex in z/OS MVS Setting Up a Sysplex.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014