Admin Alert: Tips on Running RCLSTG

by Joe Hertvik

Every once in a while, OS/400 system administrators should run a Reclaim Storage (RCLSTG) command on their system in order to fix and validate damaged objects. But the unfortunate thing about RCLSTG is that people sometimes don't understand how best to use it. This week, I'll look at what RCLSTG is and provide some tips on the best way to run it.

True to its name, RCLSTG attempts to validate and reclaim orphaned, damaged, and incompletely updated objects on an iSeries or AS/400 box. It also deletes unusable objects or fragments, so it's helpful for a system cleanup. But IBM isn't quite as enthusiastic about recommending RCLSTG as you might think. Big Blue states in its technical document on RCLSTG that the command should not be run "unless there is a warranted reason." While IBM may be a little dramatic with its verbiage here, you might want to think hard about using RCLSTG, because, among other things, it does the following for an auxiliary storage pool:

• It checks every single object in the auxiliary storage pool and validates all the headers and pointers used by that object.
  
  
• It locates orphaned objects and isolates them.
  
  
• Whenever possible, it corrects objects that were incompletely updated.
  
  
• It deletes any unusable objects or fragments.

The problem is that RCLSTG could produce some unpredictable results after it runs, and that's probably why IBM is more conservative in recommending it.

RCLSTG is easy to run, but the real trick lies in knowing how to set up your iSeries machine or partition for running it and then knowing what to do after it has run. Here's a sequence of commands I put together for successfully running RCLSTG.

Before Running the Command

1. If you're reclaiming storage from the system and basic auxiliary storage pools, RCLSTG requires that your iSeries or AS/400 be in restricted mode in order to run the command. For an example of how to put your system into restricted mode, see "Getting In and Out of Restricted State." Since you have to run in restricted mode, you'll have to schedule RCLSTG to run during off-hours, when no production is running. There isn't a way to estimate how long it will take for RCLSTG to run, and sometimes it can run for very long time. Generally, the more often you run RCLSTG, the quicker it will complete. But if you've run RCLSTG before, you may be able to check the results of the last run by viewing the QRCLSTG data area in library QUSRSYS. QRCLSTG contains the start and stop times of the last RCLSTG run, your system name and serial number, and some messages about the last run.
2. In addition to running in restricted mode, IBM also suggests that, if possible, you perform an IPL before running RCLSTG. With V5R1 and later versions of OS/400, you could satisfy this requirement and the restricted mode requirement by IPLing your system directly into restricted state. To learn how to do this, see "You Can Re-IPL into Restricted State."
3. If you don't IPL your iSeries or AS/400 very often, you may want to take a snapshot of your system, in case you run into trouble after the command finishes. A large number of companies never take down their iSeries, and after they inevitably IPL the box, their administrators may find that many critical server jobs were not started after the IPL. To provide some hints in case of trouble, run the Work with Active Jobs (WRKACTJOB) command before you run RCLSTG and redirect the WRKACTJOB output to a printer file. (This printout can be helpful in pin-pointing what servers may need to be restarted after you run the system's startup program.) Do this by running WRKACTJOB in the following way:

WRKACTJOB OUTPUT(*PRINT)

Running the Command

RCLSTG is shipped with *EXCLUDE authority for public users, so sign on to your iSeries as a security-officer-equivalent user to run the command. If you're running RCLSTG on the primary auxiliary storage pool, go to the operator's console after the system enters restricted mode and type in the following command:

RCLSTG

For the primary auxiliary storage pool, it's fine to use the default parameters. But if you're running the command to reclaim storage on a non-system auxiliary storage pool, see IBM's technical note on running RCLSTG.

As I mentioned, it's impossible to estimate how long it will take to run RCLSTG. The unfortunate part is that, because it runs in restricted mode, you can't remotely check the command's progress, because all communications are shut down while RCLSTG is running. This means you'll have to be on-site to monitor this command (so bring lunch and a portable TV, especially if it's football season).

During the command execution, there are a few scenarios to be aware of. First, if the command detects a damaged user library, RCLSTG processing will stop. To recover, you'll need to restore a clean copy of the library from a previous successful save and then run the command again.

You should also understand that IBM says that you can cancel RCLSTG processing by using system request option 2. However, if RCLSTG is cancelled or can't be restarted after an error--such as trying to process a damaged user library--the database cross-reference files associated with the auxiliary storage pool you ran RCLSTG on may also be damaged. You can fix these files by running RCLSTG again with the database cross-reference table reclaim function, as follows:

RCLSTG SELECT(*DBXREF)

This will fix your cross-reference tables so you can restart your system without problems.

After Running the Command

Check for messages in the operator console job log, the history log, and in the QSYSOPR message queue. Correct any errors.

If RCLSTG finds any incomplete updated objects, OS/400 puts these objects in the following places: OS/400 library-based objects go into the QRCL library, and AS/400 Integrated File System (IFS) objects go into the /QReclaim or /QopenSys/Qreclaim directory.

You should examine these locations after running RCLSTG and deal with the items they contain as needed. IBM has some tips for handling items in the QRCL library in its technical document. If needed, you should also make a backup copy of the QRCL library and the /Qreclaim and /QopenSys/Qreclaim folders, in case you need to reference these objects later.

If RCLSTG finds any objects that were secured by an authorization list that was damaged or destroyed, OS/400 assigns those objects to a new authorization list called QRCLAUTL. You can obtain a list of objects secured by QRCLAUTL by using the Display Authorization List Object (DSPAUTLOBJ) command:

DSPAUTLOBJ AUTL(QRCLAUTL)

For orphaned objects where the user profile is damaged or destroyed, RCLSTG will assign object ownership to QDFTOWN, the default owner. RCLSTG generates messages when it transfers object ownership to another user. To display and manipulate all objects owned by QDFTOWN, you can use the Work with Objects by Owner (WRKOBJOWN) command, as follows:

WRKOBJOWN USRPRF(QDFTOWN)

If RCLSTG encounters any duplicate objects, it will rename those objects. The original object name can be found in the text description.

When you restart your system by using the OS/400 startup program, carefully check the QSTRUPJD job log to see if there are any messages that may have resulted from missing fixed or relocated objects. For more information on viewing the QSTRUP job log, see "Where's My QSTRUP Job Log?" and "Readers' Insights on Inactive Jobs and QSTRUPJD Job Logs."

So you can relax, because RCLSTG isn't as intimidating as it seems if you follow IBM's directions and some of the common-sense suggestions I have listed here.

Sponsored By BYTWARE

David's company knew they were at risk, and thought PC-based scanning would be enough. Problem was, PC-based solutions kept missing locked files. The iSeries kept reinfecting the network. David made sure they were covered by going native with StandGuard Anti-Virus, now with mail scanning. Get Carol Woodbury's FREE white paper "Top Security Issues for the IFS" and Get Protected. Get StandGuard Anti-Virus. www.bytware.com/security_special.html