Reclaim Storage (RCLSTG) command

You can use the RCLSTG command to recover the addressability of lost or damaged objects. This allows you to identify and then restore those objects that were damaged.

If an authorization list is found damaged during reclaim storage, the objects secured by the damaged authorization list are associated with the system authorization list QRCLAUTL.

The RCLSTG command has four parameters. These parameters allow you to perform reclaim functions in the following ways:

SELECT: Specifies all or a subset of the reclaim functions that are performed.

OMIT: Specifies the subset of the reclaim functions that are omitted.

ASPDEV

Reclaim the system auxiliary storage pool (ASP) and all basic ASPs. The system ASP has an ASP number of 1. Basic ASPs have ASP numbers of 2 through 32.
Reclaim a specific independent ASP. Independent ASPs have a device name and a number greater than 32.

ESTIMATE: Estimates the amount of time that a RCLSTG command will take to run. The estimate is calculated by using statistics collected during previous RCLSTG operations. The statistics are contained in data area QRCLSTG in library QUSRSYS.

Note: The RCLSTG procedure requires auxiliary storage. If you are already using a very high percentage of auxiliary storage, the RCLSTG procedure might not complete successfully.

What happens when you reclaim storage: The purpose of the RCLSTG command is to ensure the following states:

Objects that reside permanently in auxiliary storage can be accessed.
All auxiliary storage either is used properly or is available for use.

The system checks every object that resides permanently in auxiliary storage for loss or damage.

If an object does not address a library or directory, it is placed in an IBM-supplied library or directory based on the object type. The system might not be able to retrieve description information for the object, such as:
- Program temporary fix (PTF) status.
- Save and restore information.
- Object attributes and text description.
For objects that normally reside in libraries (the QSYS.LIB file system), the system performs the following tasks:
- If a lost object with the same name and object type is already in the Recovery (QRCL) library, the system gives the object that it has just encountered a new name. The name has the format QRCLnnnnn, where nnnnn is a unique number. The original object name is placed in the text description for the object in the QRCL library.
  Note: You cannot rename journals and journal receivers. If the system encounters two journals (or journal receivers) with the same name and they both need to be placed in the QRCL library, the system renames one of them. You cannot rename that journal or journal receiver back to its original name. You must restore a previous version with the correct name or re-create the journal or journal receiver. For this reason, you should use a naming convention for journals and journal receivers that is unique for the entire system, not just for a library.
- If data exists for a lost physical file, the system attempts to rebuild the file and place it in the QRCL library. To use the physical file, create it again in the correct library with the correct attributes. Then copy the data from the rebuilt file in the QRCL library to the new physical file. The data in the file might not be complete.
- Independent ASPs have their own unique QRCL library, QRCLnnnnn where nnnnn is the number of the primary ASP. The text description for the object in the QRCL library indicates that it has been rebuilt.
- A user domain object can be placed in the QRCL library only if the QALWUSRDMN system value includes QRCL or specifies *ALL. Otherwise, a lost user domain object is deleted. Most objects are system domain objects. User domain objects have type *USRSPC, *USRIDX, or *USRQ.
- If an object does not have an owner, it is assigned to an IBM-supplied user profile based on the object type. Most objects are assigned to the QDFTOWN user profile.
- If descriptions for objects in a library cannot be accessed, the library is rebuilt.
- If an object is secured by a damaged authorization list or authority holder, the system makes QRCLAUTL the authorization list for the object. You can use the Display Authorization List Objects (DSPAUTLOBJ) command to determine which objects are secured by the QRCLAUTL authorization list.
If a lost object was in the "root" (/) file system, the object is placed in the /QReclaim directory.
If a lost object was in the QOpenSys file system, the object is placed in the /QOpenSys/QReclaim directory.
If an object in a directory is damaged to the extent that it is unusable, the system deletes it. The RCLSTG command does not attempt to rebuild damaged objects.
If a lost object was in a user-defined file system (UDFS), it is placed in the QReclaim directory located in the "root" (/) directory of the UDFS.
If a lost object that was in a directory cannot be placed in the proper QReclaim directory based on its original location, then it is placed into the "root" (/) directory of a special file system within the ASP in which the object resides. This special file system is created by RCLSTG when needed. The file system is named '/dev/QASPxx/QReclaimFS.udfs' where 'xx' is the number for system and basic ASPs. The file system is named '/dev/iasp-name/QReclaimFS.udfs' where iasp-name is the name of the independent ASP.
For objects in the "root" (/) directory, QOpenSys, or UDFS, the system takes actions for duplicate names or for unidentified object owners similar to the actions taken for objects in the QSYS.LIB file system.

What to do after running the rclstg procedure: Table 1 describes both where to look for problems that the RCLSTG procedure detects and how to correct the problems:

Table 1. Resolving problems detected by the RCLSTG procedure
Where to look for problems	How to fix the problem
Type `DSPMSG QSYSOPR` to display the QSYSOPR message queue. Look for messages about damaged objects.	Type `DSPLOG QHST` to display the history log. Look for messages about either damaged objects or rebuilt files. Delete unusable objects by using the appropriate DLTxxx command. Restore them by using the Restore Object (RSTOBJ) or Restore Object (RST) command. Copy data from rebuilt files to new files by using the Copy File (CPYF) command. Note: You might see a message indicating that objects were deleted by the reclaim storage procedure. These are internal system objects that are no longer needed.
Type `DSPLIB QRCL` to display the QRCL library. Note: If the reclaim storage procedure did not place any objects in the QRCL library, you might receive a message that the library is not found. Ignore the message and continue with the next step.	Move objects from the QRCL library to the correct library by using the Move Object (MOVOBJ) command. Note: If IBM-supplied objects are in the QRCL library, contact software support for assistance. If you are unsure what to do with objects in the QRCL library, use the Save Library (SAVLIB) command to save the library to save media. Mark the media volume in case you need the objects later.
Display the /QReclaim directory by using the Display Link (DSPLNK) command. Note: If the reclaim storage procedure did not place any objects in the /QReclaim directory, you might receive a message that the object is not found. Ignore the message and continue with the next step.	Move objects from the /QReclaim directory to the correct directory by using the Move (MOV) command.
Display the /QOpenSys/QReclaim directory by using the Display Link (DSPLNK) command. Note: If the reclaim storage procedure did not place any objects in the /QOpenSys/QReclaim directory, you might receive a message that the object is not found. Ignore the message and continue with the next step.	Move objects from the /QOpenSys/QReclaim directory to the correct directory by using the MOV command.
Type `DSPMSG QSYSOPR` to display the QSYSOPR message queue. Look for CPFA0D7 messages. For each CPFA0D7 message that contains a directory name beginning with '/dev/QASPxx/' (where 'xx' is the number of a system or basic ASP) or '/dev/`iasp-name`' (where `iasp-name` is the name of an independent ASP), perform the action specified in the "How to fix the problem" column.	Use the Add Mounted File System (ADDMFS) command to mount the UDFS specified in the CPFA0D7 message over a directory of your choice. Then use the Display Link (DSPLNK) command to view the contents of this UDFS. You might see objects with names beginning with 'QRCL' or you might see a directory named 'QReclaim'. If you see the 'QReclaim' directory, look inside it to find the object names beginning with 'QRCL'. These objects were previously lost but have been relocated by the RCLSTG command. Use the Move (MOV) command to move these objects back to their original location. The original object names can be specified in the CPFA0D7 message. If the original names are not available, use the "Display Attributes" option in DSPLNK to view an object's attributes in order to attempt to identify it.
Type `WRKOBJOWN QDFTOWN` to display objects that are owned by the QDFTOWN user profile.	Use option 9 (Change owner) from the Work with Objects by owner display to transfer ownership to the correct user profile.
Type `DSPAUTLOBJ QRCLAUTL` to display objects that are secured by the QRCLAUTL authorization list. Note: If the reclaim storage procedure did not assign any objects to the QRCLAUTL authorization list, you might receive a message that the authorization list is not found. Ignore the message.	If necessary, assign the object to the correct authorization list by using the Edit Object Authority (EDTOBJAUT) command.