When i5/OS Backups Keep You Waiting

Published: December 16, 2009

Hey, Joe:

We recently watched our month-end backup drag on forever. Occasionally, a job log message would appear saying that an object was in use and couldn't be opened. Do the i5/OS backup commands "wait" on locked objects? Does that mean if several objects are in use, the backup wastes time waiting, or does it save other objects until it times out waiting for the locked items?

--Mike

Mike went on to say that he understood his system shouldn't be locking objects when he's performing a month-end backup, but his suspicion is that the locked objects are log files from various third-party software products. He is considering performing an End Subsystem (ENDSBS) command with the *ALL option to ensure the system was quiet before backup.

To answer Mike's questions, i5/OS backups will pause when waiting to backup a locked object. The SAVxxx commands will not backup other objects and then come back to the locked objects later. The backup will just stop on a locked object, and it will wait until either the object comes free or the command's wait time parameter times out. So IMHO, if he's trying to run a backup while the system is active and several critical i5/OS objects are locked and cannot be backed up, that could very well be why his month-end backups are taking so long. For each locked object, the backup routine would need to wait for its time out parameter to expire before it can move on to the next object, resulting in a fairly long cumulative backup time.

Mike has a few different options for improving this situation, including:

1. Check the Save Active Wait Time (SAVACTWAIT) parameters associated with his SAVxxx commands. One of the SAVACTWAIT list values is a timer for how long the command should wait for locked objects before skipping the object and moving on to the next object to save. By default, this parameter is set to 120 seconds, which means that the backup operation could wait up to two minutes before deciding it can't backup the object and move on to the next object. If Mike doesn't care whether these objects are backed up or not, he can reduce the SAVACTWAIT wait time down to something more reasonable (say 10 seconds) to improve his backup speed. Looking at IBM's documentation, it's unclear whether this parameter is only in use for Save While Active backups or whether it's used for all backups, but I suspect it's the main culprit behind Mike's long backup times.

2. Mike can change his backup to a Save While Active backup. This may sidestep some of the issues with objects in use, though he would still have to deal with setting his SAVACTWAIT parameter correctly. If you've never worked with a Save While Active back up, read my article on creating a simple Save While Active backup program.

3. Ending all subsystems will free up Mike's locked objects, but that may not be compatible with the processing goals of his shop. Mike could perform some research to figure out exactly which active jobs are locking the log files that are holding up the backup, and then selectively turn off and turn back on those jobs while performing his backup. To do this, Mike would need to change his backup routine to segment the backup steps this way.

• Backup all objects that typically do not have locked files, ignoring objects in the libraries where the locked files reside. On the Save Library (SAVLIB) command, for example, Mike can specify any libraries to omit from a multi-library backup by entering those library names in the Libraries To Omit (OMITLIB) parameter.
• After all the libraries without locked objects are saved, Mike can automatically end any jobs that traditionally lock the objects that hold up his backup.
• Backup the libraries that usually have locked objects.
• Restart the jobs that were ended.

4. Similar to how we discussed omitting libraries in step three, Mike could set up his SAVxxx commands to omit problem objects, skipping those objects that are generally locked during the backup. He can specify the names of objects to omit in the Objects To Omit (OMITOBJ) parameter on each of his SAVxxx commands. If he decides to skip backing up any objects that are locked when his system is active, he would then have to ensure that he performs full system backups on a semi-regular basis so that he can get periodic backups of his locked objects.

5. Mike could restructure his month-end backup routine so that he takes full system backups (FSB) during his month-end save. A FSB puts the system in restricted state, allowing the system to backup all objects without having to worry about object locks. The only problem is that many (if not most) shops are requiring 24x7x365 system access so it may be difficult to take the system down for an FSB even once a month. However, if he can perform a full system backup, it would definitely be worth his while if only to save a complete snapshot of the system at least once a month.

Performing one of these options should solve his problems.

--Joe

RELATED STORY

A Simple Save While Active Backup Program

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot