Q: When does the typical person think seriously about saving data?

A: Unfortunately, when a disaster happens and data is lost.

The save/restore articles I offer this month and next are meant to joggle the minds of systems administrators to explore these questions:

"Do I have a sufficient backup in the event of loss of data?"

"Can I perform my backup in a more efficient way?"

I'll explore the commands and strategies to backing up an AS/400. First, I'll examine the things that you should back up most frequently: configurations, security data, and the user data.

Configuration objects allow different ways of connecting to an AS/400. If you connect via twinax to a display station, for example, that twinax display station has a name-a device name. That device name (the system calls it a device description) contains not only the name, but the model of the device, which controller and port number it uses, a default printer, and many other things that the system requires for it to identify that display station to the AS/400. If you connect via an ASCII Work Station Controller, that device has the same information about it. No matter how you connect (SDLC, display station pass-through [DSPT], Ethernet, etc.), each device description has similar characteristics.

Examples of other configuration objects are controllers (such as twinax, ASCII, and Ethernet), line descriptions (used with modem connections), virtual devices (those devices that are created via Client Access or Pass-Through), and APPN controllers.

If your disk were to crash or your configuration data were somehow destroyed, could you rebuild from memory? Chances are that the answer to this question is "no." Other questions to think about are "How often are configuration devices changed?" and "How often should I back up these devices?" In most shops, there is no definite time that you would add or change a device. In

my opinion, the answer to the second question is, "At every opportunity."

To save these configuration objects, you would have to use the Save Configuration (SAVCFG) command. At a command line (or in a CL program), type the following:

SAVCFG DEV(TAP01)
This is assuming that TAP01 is your tape device. However, you may save it on any tape device you have.
One restriction of the SAVCFG command is that the user must have *SAVSYS authority in his user profile,
as is the case with most Save and Restore commands. (If there is any question, see your system security
officer or the person who issues new user profiles.) Another restriction that you must consider is
diskette devices cannot be used for a configuration save.

To restore configuration objects, use the Restore Configuration (RSTCFG) command:
RSTCFG OBJ(*ALL) DEV(TAP01)

This will restore all objects saved to the tape mounted on device TAP01. If individual objects need to
be restored, list those objects in the place of *ALL.

A secondary way to save your configuration objects is by using the Retrieve Configuration Source (RTVCFGSRC) command. This command creates a CL source member that can be compiled, and the devices are
created by running that CL program. RTVCFGSRC has four important parameters. First is the configuration
description (CFGD), which can be either a single device or *ALL devices. For save and restore
operations, *ALL is the only choice. Second is the configuration type (CFGTYPE). You can create a
source member for any of the AS/400 device types, but I suggest using a value of *ALL. Third is the
source member you want to create (SRCFILE), and fourth is the source member name (SRCMBR). You can take
the default value *CFGD, which creates a source member named CFGSRC, or you can supply a member name.
Another top priority item that you should regularly protect via magnetic media is the security data,
which consists of all authorization lists, authority holders, and user profiles. The user profiles are
objects that allow a user to sign on to the AS/400 and give the user a password, special authorities
(such as *SAVSYS), the initial program to call upon sign-on, and a default menu upon sign-on.

Again, rebuilding this information would be an unachievable task. These objects change frequently. So
the value of the object if lost is great. By using the Save Security Data (SAVSECDTA) command, you can
easily ensure that profiles and authorization lists are not lost. At a command line or in a CL program,
type in the following:
SAVSECDTA DEV(TAP01)

Just as in saving configuration objects, you must have *SAVSYS authority in your user profile to
perform this command.

Restoring user profiles is done through the Restore User Profile (RSTUSRPRF) command:
RSTUSRPRF DEV(TAP01) USRPRF(*ALL)

Again, to restore individual profiles, list them in place of *ALL.
Restoring authorization lists requires another command, Restore Authority (RSTAUT). This command has no
required parameters. However, you can restore only the authorities to individual user profiles by
specifying USRPRF() on the command. Restore user profiles and authorization lists in this order:
RSTUSRPRF first and then RSTAUT.

Virtually any AS/400 object can be saved to magnetic media by using the Save Object (SAVOBJ) command.
SAVOBJ OBJ(

Suppose you need to save program MYPROGRAM in library MYLIB. You could save that object using code like
this:
SAVOBJ OBJ(MYPROGRAM) LIB(MYLIB) DEV(TAP01)

Or maybe you need to make changes to a database file and want to ensure that you have a clean copy
before you make those changes. If that file is in the same library but named MYFILE, you can save it
also.

SAVOBJ OBJ(MYFILE) LIB(MYLIB) DEV(TAP01)
You can even save an individual file member. As an example, suppose that you have a CL source file
(QCLSRC) and want to save one member, MYSRC.

SAVOBJ OBJ(QCLSRC) LIB(MYLIB) DEV(TAP01) FILEMBR((QCLSRC (MYSRC)))
Theoretically, you could save all objects in a library, but that is best handled with another command,
which we will explore later in this article. To restore objects saved with the SAVOBJ command, use the
Restore Object (RSTOBJ) command.

The best use of SAVOBJ is just that, objects, not an entire library.
Several types of objects are restored empty: output queues, job queues, data queues, and message
queues. When these objects are restored, only the description is restored. The contents of these queues
are not restored.

The Save Library (SAVLIB) command is tailored for saving entire libraries, as opposed to certain
objects within that library. If you were to keep all of your data files in a library, such as MYFILES,
you could save that library, using the SAVLIB command.

SAVLIB LIB(MYFILES) DEV(TAP01)
Note that, in this example, all objects in that library are saved to magnetic tape. There are some
exceptions to this rule. The following system libraries cannot be saved via the SAVLIB command: QSYS,
QSRV, QTEMP, QSPL, QDOC, QRPLOBJ, QRECOVERY.

The SAVLIB command has some unique features. It can save either all objects in a library or certain
"set" of libraries. These sets are *IBM, *ALLUSR, and *NONSYS.

o The *IBM "set" of libraries contains all IBM-created libraries with the exception of the following
libraries: QDOC, QRCL, QSYS, QUSRSYS, QDSNX, QRECOVERY, QS36F, QGPL, QRPLOBJ, QTEMP, QGPL38, QSPL,
QUSER38, QPFRDATA, QSRV, QUSRINFSKR.

There is an old saying, "All rules are made to be broken," and the SAVLIB command holds true to that
old saying. The *IBM "set" of libraries also includes the following libraries if they exist on your
system: #CGULIB, #DSULIB, #SEULIB, #COBLIB, #RPGLIB, #DFULIB, #SDALIB.

o The *ALLUSR library "set" contains all user-created libraries on the system. With each library
created, there's an attribute for that library object that tells the system whether the library is
created by *IBM or a user (when displaying the object, look for the Created By User field). In
addition, libraries that begin with the letter Q, which can contain user-specific data, are saved:
QDSNX, QPFRDATA, QUSER38, QGPL, QRCL, QUSRINFSKR, QGPL38, QS36F, QUSRSYS.

Note that this list includes some libraries that were excluded from the *IBM set of libraries.
o The last unique set of IBM libraries is the *NONSYS set. This set consists of both the *IBM and the
*ALLUSR sets of libraries, but this save must be done on a dedicated system.

When deciding on your save-and-restore strategy, you need to consider a couple more items. First,
remember that when you restore, you must use the same command structure you used when you saved. If you
save libraries with a *NONSYS option, they must be restored with a *NONSYS option. Likewise with *IBM
and *ALLUSR. You cannot save with one method and restore with another. Individual libraries and objects
can be individually restored. Second, if you are running the QSNADS subsystem, you must end that
subsystem during the *ALLUSR option. If you don't, the QAO* files in the QUSRSYS library will not be
saved.

Objects saved with the Save Library (SAVLIB) command can be restored via the Restore Library (RSTLIB)
command (which restores the entire library) or the Restore Object (RSTOBJ) command (which restores
individual objects).

The Save Changed Object (SAVCHGOBJ) command is another command in the arsenal of magnetic media
options. This command is similar to SAVOBJ but with one major difference: SAVCHGOBJ saves only the
objects that have changed since the last SAVLIB command.

Each object in the library has several attributes. One of them is the date and time of the last save;
another is the date and time of last change. Many other attributes for each object exist, but, for the
purpose of save and restore, these are the most important.

Suppose you saved a library called MYLIB using SAVLIB. As time progresses, objects in that library
change. If they are files, data is added, modified, or changed. If it is a source file, the same types
of changes have been made to the members of that source file. If the library contains program objects,
those objects are new once they're recompiled. What if you could save only those things that have
changed? With SAVCHGOBJ, you can do just that. The command looks for objects that have been changed
since the last complete library save.

Saving only those objects that have changed decreases the save time but increases the restore time. The
save time is cut because only changed objects will be saved. However, in the event of data corruption
or a disk crash, two restore operations must take place to bring the library up to its current
condition. First, use RSTLIB to restore the last full library save. Then, use RSTOBJ to restore the
changed objects. The timing of the restores is crucial and must be performed in this order.

One nice feature of SAVCHGOBJ is that you can save changed objects for a single library, a series of
libraries, or all of the user libraries. To save the changed objects in all of the user set of
libraries (see the Saving Libraries section of this article for the discussion on *ALLUSR), use the
following code:
SAVCHGOBJ OBJ(*ALL) LIB(*ALLUSR) DEV(TAP01)

To save changed objects in an individual library, substitute that library name for *ALLUSR. And to save
the changed objects in a series of libraries, substitute those library names for *ALLUSR.

You might expect that there would be a Restore Changed Objects command, but there's not. Use RSTOBJ
when restoring changed objects.

The Integrated File System (IFS), folders, and OfficeVision require a separate save operation-the Save
Document Library Objects (SAVDLO) command. Also, Client Access users should frequently use this
command. To save all folders and all documents in those folders, use the following SAVDLO command:
SAVDLO DLO(*ALL) FLR(*ANY) DEV(TAP01)

This will safeguard all folders and any documents within those folders and place a copy of them on
tape. If you have particular documents or folders that need to be copied on magnetic tape, replace *ALL
and *ANY with the names of the documents and folders.

SAVDLO has some unique options. You may *SEARCH the objects for combinations of owners, change date and
time, and create date and time.

Restoring objects saved with SAVDLO requires using the Restore Document Library Object (RSTDLO)
command.

If you are blessed with disk space but do not have the luxury of being able to take down a system to do
a backup, you can save data to a save file (this save file resides on the disk as opposed to residing
on tape). You can place the save file on magnetic tape later. Saving objects to save files saves time
(operations to disk are faster than operations to tape), but please be sure you have sufficient disk
space to do save operations to save files.

Just as you must initialize a blank tape-via the Initialize Tape (INZTAP) command-you must create a
save file before you can save data to that save file. To do that, you must use the Create Save File
(CRTSAVF) command. Save files can reside in any library, but for this example, I will use the general-
purpose library QGPL.

CRTSAVF FILE(QGPL/MYSAVF)
Once you have a save file, you can save data in it. Suppose you want to save library MYLIB in a save
file. You would use the Save File option (which resides in the same place as the Device parameter on
Save commands) instead of a tape device. We also have to specify where the save file resides.
SAVLIB LIB(MYLIB) DEV(*SAVF) SAVF(QGPL/MYSAVF)

After this operation is complete, the save file must eventually be copied to a save medium. You do this
with the Save Save File Data (SAVSAVFDTA) command.

SAVSAVFDTA SAVF(QGPL/MYLIB) DEV(TAP01)
One common mistake users make is forgetting to save the save file to tape after the save-to-save-file

operation. If a user forgets this step, the data contained in the save file is as volatile as other
data when it comes to data corruption or disk crashes. If your system crashes between the save-to-save-
file operation and the save-file-to-tape operation, you still have only the last save operation on tape
to go back to. An option that some shops use is to separate their disk into separate auxiliary storage
pools (ASPs), dedicating one or more to save file operations. This is a good strategy-if you have the
disk to spare for a separate ASP.

The save file is another object, and it will be saved with the SAVLIB command, which is not the
preferred option. A better option is to use a good CL program that can save everything except database
files (this option is used by those 24/7 IS shops that cannot afford down time for saves). Then, when
it's time to save database files, you can get the users off the system, save the database files to a
save file, resume normal operations, and then process the save file to tape.

Here's a simplified example: Assume you have only three libraries on your AS/400. They are MYSOURCE
(your programming source files), MYPGMS (program objects), and MYFILES (your database files). First,
you would save the source and program objects (which are not usually in use in a 24/7 operation) with
the SAVLIB command.

SAVLIB LIB(MYSOURCE) DEV(*SAVF) SAVF(QGPL/MYSAVF)
SAVLIB LIB(MYPGMS) DEV(*SAVF) SAVF(QGPL/MYSAVF)
You'll need exclusive access to the data, so make sure none of your users are using the database files.
If your users are unwilling to sign off voluntarily, you may have to end their jobs and vary the
devices off. Alternatively, if they work in a separate subsystem, you can end that subsystem. Then, you
can save as follows:
SAVLIB LIB(MYFILES) DEV(*SAVF) SAVF(QGPL/MYSAVF)

At this point, you can allow your users access to the system. Finally, save the save file data to tape:
SAVSAVFDTA SAVF(QGPL/MYSAVF) DEV(TAP01)

Most Save commands offer many useful options. An end-of-tape option (denoted by the ENDOPT parameter)
is often useful. With most new tape drives, all of these options work as specified. There are three
basic flavors: leave (*LEAVE), rewind (*REWIND), and force the tape to eject (*UNLOAD).

By choosing to leave the tape at the point of the last save, you can save time in multiple save
operations. Suppose that in the save library and save file example above, I entered this code:
SAVLIB LIB(MYSOURCE) DEV(TAP01) ENDOPT(*LEAVE)

SAVLIB LIB(MYPGMS) DEV(TAP01) ENDOPT(*LEAVE)
SAVLIB LIB(MYFILES) DEV(TAP01) ENDOPT(*UNLOAD)
The tape device will simply stop when the save operation is complete on the library MYSOURCE. Likewise,
on the MYPGMS library, it will start at the place where MYSOURCE left off. For library MYFILES, it will
pick up where the save of MYPGMS left off and eject the tape after the save.

The Eject option is very valuable, especially on the last Save command. One morning I found my system
off, with an SRC code on the front panel. My first thought was, "Did the save operation complete?"
Fortunately, I had used the Eject option on the last save operation, so I was assured that even in the
event of a disk crash, the data was safely on tape. I could see that my 8mm tape had ejected. Luckily,
the SRC code had nothing to do with the disk, and no restore was needed. However, if I hadn't used the
Eject option, I would not have been sure without looking at the tape if it had completed or not.

In my shop, I do periodic saves of physical file data before making wholesale changes to that physical
file. The Eject option on the last operation here is valuable also; I know that I can proceed.
Finally, the Rewind option is the default option. Make sure that if you need a different option, you
specify it. Otherwise, after each save operation, the tape will rewind to the beginning. This excessive
amount of tape positioning could add time to your save process.

When saving objects, you can put an expiration date on them. This can be especially helpful if you
rotate a series of tapes.

You can either save them with a permanent expiration date EXPDATE(*PERM) or specify the date of
expiration. By making the objects permanent, the tape will have to be reinitialized in order to reuse
it.

By using a date, you can overwrite the objects in a cyclic fashion. Suppose you rotate one week (seven
days) worth of tapes, and today is March 1, 1998. If your save operation specifies the expiration date
as March 8, 1998, then as of March 8, 1998, you can overwrite those objects without reinitializing the
tape.

Remember, when specifying the expiration date, it must be in accordance with your system date format
system value. If you are using a date format of *MDY, you would specify EXPDATE(030898) in the above
example.

If you need an auditing tool to ensure that a tape operation completed and to ensure what was on that
tape, you could print to either a database file or a spooled file. The OUTPUT keyword allows for three
flavors: no output (*NONE is the default), print, and place the data in an output file.

To create a spooled entry, be sure to specify OUTPUT(*PRINT) on the Save commands. If you prefer output
to a database file, choose OUTPUT(*OUTFILE) OUTFILE(QGPL/SAVEDATA) to create data in a database file.
As I stated in the SAVCHGOBJ discussion, the system keeps a date of the last save operation to that
object. Updating that date of last save is up to you.

There are only two options to the UPDHST keyword: *NO and *YES. In my opinion, you should always update
the date of last save if you intend to keep permanent tapes of that data. This could include most
SAVLIB commands.

If you choose to use SAVCHGOBJ, update the history on the complete library saves, not the history on
the changed object save. This will allow you to restore with only two operations. If the date of last
save is changed on each changed object save, all tapes between the library save and the current changed
object save will be required for a restore.

Another reason to not update the history is that you may want to make a copy on tape of database files
before major changes to the file. Most times, these are kept for a short time, and they're not kept in
a series of save and restore tapes.

One of the more recent enhancements of OS/400 (as of V2R3) is the ability to save while an object is

active. An analogy to running a yellow light is appropriate here: It is all right if you know the risks
involved, but it can be disastrous if you do not.

The default parameter for save-while-active SAVACT is *NO. This does not allow any other user access to
that object except the save operation. Ideally, if your shop can handle this scenario, I strongly
suggest you use it. With this, there can be little or no confusion about the state of the data when put
on tape. However, if this is not a possibility, then save-while-active becomes a necessity.

The SAVLIB command has three keywords that concern save-while-active: save-while-active (SAVACT), save-
while-active wait time (SAVACTWAIT), and save-while-active message queue (SAVACTMSGQ). If the save-
while-active keyword has any value other than *NO, then both of the other keywords should have values.
The save-while-active message queue simply records the checkpoints in a message queue. This queue
should be a workstation message queue as opposed to a user message queue. If your shop does an IPL
between the time your backup programs finish and time the first user comes in, an IPL will clean out
user message queues, such as QSYSOPR. Workstation message queues are not emptied until a user specifies
it. This way, all error messages will be detected, unless ignored in that workstation message queue.
The save-while-active wait time keyword has values that "depend" on situations. If there is a user
monitoring a save operation while that operation is going on, using a number of seconds (such as 120,
the default) should work just fine. If no user monitors the save operation, use *NOMAX. This value
forces the system to wait until a point is reached in which a segment of that object can be saved to
tape.

Save-while-active comes in three types. The least preferable value is *LIB. This value causes all
objects in that library to come to a point between nonsave usage and save usage, and the objects being
used in the whole library are "frozen" while the save occurs. This option is not slated to be used with
more than 1,000 objects. The problem with this is that, while the save operation is happening, the jobs
using those objects are suspended until that library is saved. If you have a job that needs one object
in a library, you could be in trouble; all objects in that library are frozen to the save operation
while the library save is running. For active jobs, this defeats the purpose of saving while the object
is active. However, for a good, clean save, it is ideal.
*LIB is at the bottom of the totem pole of save-while-active options, and *SYNCLIB is barely above
that. *SYNCLIB works similarly to *LIB, but it is able to handle larger numbers of objects in a
library. At the top of the totem pole is *SYSDFN. This allows objects in use to reach a frozen point at
differing points during the save. If for example, you were saving MYFILE in MYLIB, the object MYLIB
would be periodically frozen during the save of that object, alone. Once the save operation has
completed that item, it is freed up from the overhead of that save operation.

This article is intended for those of you who run saves frequently, such as daily or biweekly. A sound
plan is to save all IBM and user libraries on weekends and save changed objects during the week. Saving
all IBM and user libraries every night is a sounder plan, but it may not be a possibility.

At any rate, make sure the first two saves you do-even before the IBM and user libraries-are the
security data and configuration saves. In the event of a complete disk crash, they are the two most
important. Likewise, make sure the first things that are restored are the user profiles, authorization
lists, and configuration objects. The user profiles and authorities are integral when recovering from a
disk crash. As an example, if the configurations are restored before the security data, the user
profile QDFTOWN owns all the configuration objects. Without all of the profiles, the system does not
have a user to own the configuration objects.

Also, in the event of a disk crash, restore the user profiles and authorities in one pass, and restore
the configuration objects in a second pass.

In the next article, I will discuss the less-frequent saves, such as the system, licensed programs, and
storage.

Stay tuned....
Tim Johnston is the manager of information systems at Hapco, a Division of Kearney National, Inc. in
Abingdon, Virginia. Tim can be reached via the MC Discussion forums on the MC Web site or by email at
This email address is being protected from spambots. You need JavaScript enabled to view it..

CL Reference, V3R1 (SC41-3722-00, CD-ROM QBKAUP00)