Every now and again System i Administrator should look to run a Reclaim Storage (RCLSTG) on the system. If you’ve got limited experience of the platform, the system or even the command itself, then you may not be aware of what it does and how best to schedule it.
Look at the RCLSTG as a “spring clean” for your system. The process checks the headers and pointers on all objects in the Auxiliary Storage Pool (ASP), attempts to validate and reclaim orphaned, damaged and incorrectly updated objects.
As the RCLSTG also deletes unusable object or fragments it’s especially relevant after a sudden power failure or system crash.
This is very difficult to estimate but probably the best way to estimate this is to check how long it ran for the last time it ran. Display the data area QUSRSYS/QRCLSTG using the command:
In our example it shows that the RCLSTG ran from 1740-1911hrs on 9th February 2009.
As the RCLSTG could (albeit unlikely) impact the day to day running of the system it’s advisable to perform a full system backup and if possible an IPL prior to running the command.
You’ll need to sign on using a QSECOFR or an equivalent profile before bringing the system to a restricted state (all jobs need to be ended apart from the system console). After ensuring that all users have signed off and that all batch processes are complete a restricted state can be achieved by using the command;
ENDSBS SBS(*ALL) OPTION(*IMMED)
The system is in a restricted state when you see the CPF0968 message on the QSYSOPR message queue.
Once the system is ready use the command;
As you can appreciate the above is a very manual and somewhat dated process so why not schedule the whole process using Halcyon’s Restricted Task Manager?
Decide when you want to run it.
Then decide how you’d like to achieve a restricted state by automatically notifying the online users (or not).
Next decide what you want to run - in our example a SAVSYS, *NONSYS, SAVDLO and a SAV followed by RCLSTG, all with inbuilt error recovery and SMS task completion capabilities.
Informational status messages will be sent to the session running the RCLSTG but when complete it’s good practice to check the QSYSOPR message queue for any anomalies.
Any objects found to be secured by damaged or missing authorization lists are assigned to the QRCLAUTL authorization and should be reviewed by using the command:
Any objects discovered that are owned by a damaged or deleted user profile, or any objects that have no owners as assigned to QDFTOWN. These objects should be reviewed by using the command:
Any objects that are lost from their original specified location are placed in QRCL for qsys.lib objects and /QReclaim or /QOpenSys/QReclaim for IFS objects. These can be review by using the commands below:
Still have questions? We can help. Submit a case to Technical Support.