Security officers have the backup process high on their list of priorities and normally keep a close eye on it. We, for instance, have spent time working out drills to do full system restores in the event of a catastrophic loss. Often, however, we neglect another valid reason for backups, namely the easy and timely restoration of individual objects from regularly scheduled backup tapes.

If you've been around the OS/400 for any length of time, you are already familiar with all of the information you need to know before you can do a successful individual object restore. It is not enough to know just the name of the object, but you must also know the library it was saved from, the tape file label and in some cases, the sequence number on the tape. The more information you can provide to the OS/400 restore function, the quicker it will run.

More Information Changing attributes of an object

Automated disaster recovery -- revisited Testing resource security

For some, getting the right information may necessitate running a DSPTAP operation with the *SAVRST option to verify the object you want is on the tape. This also gives you all of the information you'll need for your restore, but running the DSPTAP command is painfully slow on most systems and tape media.

You can, however, easily make this chore much easier by simply implementing the OUTFILE parameter on your SAVOBJ (or SAVLIB) command. The OUTFILE parameter generates a file that contains more than you will ever need to know about every object processed during the save operation. When the time comes to restore an individual (or set of) object(s), you can simply reference the appropriate OUTFILE and, voila, you have the information right at your fingertips.

To simplify the process and reduce the amount of storage required for all this information, I have created a simple set of DDS (data description specifications) that subset the fields on the OUTFILE down to just those you really need when looking to do a restore. The DDS consists of a flat file (PF) for the data and a logical view (LF) that indexes the information by library, object name, object type and member name. After a backup operation completes, all you need to do is run a CPYF command from your outfile into the subset using the *MAP *DROP options on the CPYF and you will save the relevant information. To simplify things, I recommend creating a different member in the file for each backup. This also simplifies purging data from the file when your backup tapes expire and are recycled. You just need to delete the associated member and you're in business. (Note: Using a separate file also insulates you from changes in the OUTFILE that can happen during OS/400 release upgrades.)

To find information about a backup, you can take several approaches. If you know which backup set you want to work with, add a logical file member to the logical view and use the UPDDTA command to find and display the information from the view. If you're not sure which backup set has your object, you can create a view that encompasses all of the members in the file and get a look at all of the copies of the object you want that exist in your full backup library.

I have used this approach for a long time on our system and can always find objects for restore very quickly. If this has been an issue in your shop, you should consider making some minor changes to the way you take your backups. The results will be rewarding in saved time and ease of object restoration processing.

An interesting side benefit you can also gain from the OUTFILE data is you can run a quick report that lists objects processed during the backup where errors occurred. The OUTFILE captures a yes/no field about the success of the save along with an error message code if the object failed to be saved. A quick Query/400 listing after every backup gives you a better understanding regarding any problems that may have occurred during the save.

If you would like a copy of the DDS referred to in this tip or if you have any questions about this topic, you can reach me at rich@kisco.com, I'll give it my best shot. All e-mail messages will be answered.

---------------------------------------

About the author: Rich Loeber is president of Kisco Information Systems Inc.s in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.