Troubleshooting
Problem
This document discusses SAVE operations in a Cluster environment.
Resolving The Problem
When performing a backup, cluster jobs should not be active during the SAVE operation due to the fact that they hold temporary locks on cluster objects. Observe the following:
For CIO and CRGM Objects in QSYS
- A SAVSYS runs in a restricted state, therefore end the device CRG and end the cluster node before restricting the system using the ENDCRG and ENDCLUNOD commands.
- A SAVCFG can be run in non-restricted state, therefore end the device CRG and end the cluster node before performing the save by using the ENDCRG and ENDCLUNOD commands.
CRG Objects in QUSRSYS
- Objects of type *CRG reside in library QUSRSYS.
The following operations save *CRG objects:
- SAVLIB LIB(*NONSYS or *ALLUSR or QUSRSYS)
- SAVOBJ LIB(QUSRSYS)
- SAVCHGOBJ LIB(*ALLUSR or QUSRSYS)
- Use of the QSRSAVO API
- Locks are held on cluster objects during the save of library QUSRSYS or during the Save While Active until the object is checkpointed.
End the device CRG and end the cluster node (ENDCRG / ENDCLUNOD) prior to the save operation or set the omit object parameter to exclude *CRG objects during the save operation.
Objects in IFS
- There are objects in the IFS that get locked as soon as a cluster node is made active. One example would be '/QIBM/UserData/HASM/hads/HASVR*' and again it is recommended to end the device CRG and end the cluster node before performing the save.
Important Note:
It should be noted that having a cluster node in an Active state, it can have an impact on the saving of objects. The same goes for having an Active cluster and a user initiating a save operation without thinking about how it will affect cluster operation. As a best practice, if a save operation is going to include QSYS, QUSRSYS, a SAVCFG or a save of the IFS, the cluster CRGs (including Admin Domain) should be ended, followed by the ending of the backup cluster nodes and finally the ending of the primary cluster node. When the cluster is ended, the save operation can successfully get the object locks and complete.
It should be noted that having a cluster node in an Active state, it can have an impact on the saving of objects. The same goes for having an Active cluster and a user initiating a save operation without thinking about how it will affect cluster operation. As a best practice, if a save operation is going to include QSYS, QUSRSYS, a SAVCFG or a save of the IFS, the cluster CRGs (including Admin Domain) should be ended, followed by the ending of the backup cluster nodes and finally the ending of the primary cluster node. When the cluster is ended, the save operation can successfully get the object locks and complete.
If QSYS, QUSRSYS, configuration objects or IFS are not being saved, then the only real consideration to keep in mind is whether the save operation will be in a restricted condition or not. Anytime a restricted state save is going to take place, the CRGs and Cluster nodes should always be ended before restricting the system. The reason for this is to avoid an accidental failover from occurring.
[{"Type":"SW","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CGgAAM","label":"High Availability"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Version(s)"}]
Historical Number
465737232
Was this topic helpful?
Document Information
Modified date:
09 April 2021
UID
nas8N1014067