Vous êtes sur la page 1sur 4

A Simple Save While Active Backup Program

The problem with 24x7 environments is that it's difficult to make time to run complete system
backups. Modern processing needs dictate that you can rarely, if ever, take down your
machine to back up the entire system. This week, I'll look at a hybrid backup scheme that lets
you achieve the dual goal of performing occasional full system backups while still saving all
your critical system and user data.

A Simple Strategy

The following is a simple save strategy that you may be able to use in your shop. It consists of
two system backup elements that allow you to occasionally perform a complete system backup
while maintaining nightly backups of your most important data.

1. A full system backup that can be taken weekly, monthly, or even quarterly during off-
hours. This backup provides a baseline copy of your system that can be used for
restoring all system objects in the event of a disaster.
2. An intermediate backup program that saves all the changed objects on your system
since the last full backup, without taking your system down. This backup uses IBM's
save-while-active technology to save all your critical system objects and user files
without disrupting processing. It can be run in between your full system backups and
it will save data and configurations that are changed between backups.

While this scheme does not provide complete 24x7 availability because you still need to run
occasional full system backups, it does provides most of the tools you'll need to backup your
system with minimal disruption.

The Full System Backup

i5/OS full system backups are performed by running option 21 off the Save menu (GO SAVE).
A full system backup provides a baseline picture of your system that can be used to restore
the entire system in the event of a disaster. To perform a full system backup, simply select
option 21, Entire System, off the Save menu and the operating system will prompt you for all
the parameters it needs to take a complete snapshot of your entire system.

Between the Full Backups

The problem with an option 21 save is that you may not be able to save your entire system
every night, due to processing commitments. To fill in the gaps and to make sure that I can
restore most objects that are changed between full system backups, I wrote the following CL
program that saves all critical and changed objects every night. The name of the program is
NGHTLYBKP and this is the code I use to back up the system on off-nights.


0005.00 VALUE('/QSYS.LIB/')
0007.00 VALUE('.DEVD')
0010.00 &TAPDEV *TCAT &TAPDEVEND) /* set up +
0011.00 parameter for saving to tape device in +
0012.00 the SAV command */
0014.00 CLRMSGQ MSGQ(QUSRSYS/SAVEMSGQ) /* Clear out old save +
0015.00 messages before starting */
0017.00 SAVSECDTA DEV(&TAPDEV) ENDOPT(*LEAVE) /* Save user +
0018.00 profiles, private authorities, and other +
0019.00 security data */
0021.00 SAVCFG DEV(&TAPDEV) ENDOPT(*LEAVE) /* Save all +
0022.00 current configurations */
0028.00 QDTA(*DTAQ) +
0029.00 OUTPUT(*OUTFILE) +
0031.00 /* Save all library objects that were +
0032.00 changed since the last backup */
0033.00 MONMSG MSGID(CPF3778) /* Ignore message CPF3778 - +
0034.00 Not all objects saved from all libraries */
0039.00 SAVACT(*YES) SAVACTWAIT(60) /* Save all +
0040.00 Document Library objects changed since +
0041.00 last backup */
0044.00 SAV DEV(&TAPDEVLNG) OBJ(('/*') ('/QSYS.LIB' +
0045.00 *OMIT) ('/QDLS' *OMIT)) SAVACT(*SYNC) +
0049.00 /* Save all IFS objects except for the +
0050.00 QSYS.LIB folder and the DLO objects */
0051.00 MONMSG MSGID(CPF3837)
0053.00 DSPJOBLOG OUTPUT(*PRINT) /* Print out the joblog for +
0054.00 review later on */
0058.00 Display tape contents for review, if +
0059.00 needed */
0061.00 ENDPGM

Here's what each piece of code does.

Line 1.00--The calling user passes in the name of the backup media device to use in the
&TAPDEV parameter. By passing in the device name, I can easily change the media save
device name by changing the program call statement, instead of changing and recompiling the

Lines 3.00-12.00--Program variables are defined for the media device name (&TAPDEV), as
well as for the AS/400 Integrated File System (AS/400 IFS) name of the media device name
(&TAPDEVLNG). An AS/400 IFS name consists of a specific designation that pinpoints exactly
where in the IFS the device is located. Lines 9.00-12.00 build the AS/400 IFS name of the
device where I will be saving the data.

Lines 14.00-15.00--Clears out the message queue that will contain any messages arising from
the programs save commands. In this CL, all messages are saved to the SAVEMSGQ message
queue in library QUSRSYS. Saving messages to a separate message queue allows you to view
the messages apart from messages in other public message queues on the system, such as
QSYSOPR. Before attempting to run this program, make sure to create the SAVEMSGQ
message queue.

Lines 17.00-22.00--These commands save critical system data that may change from day to
day. Lines 17.00-18.00 save all the system security data (user profiles, private authorities,
etc.) by using the Save Security Data (SAVSECDTA) command, while lines 21.00-22.00 save
all the device configuration data (display devices, printer devices, RF devices, etc) by using
the Save Configuration (SAVCFG) command. Since user profiles and devices can be created on
the system every day, you need to back them up between your full system backups.

Lines 24.00-32.00--The Save Changed Objects (SAVCHGOBJ) command saves all the user
library objects (*ALLUSR) that have changed since the last time those objects were saved
during the full system backup. Furthermore, this command will save objects while they are in
use. All of the objects and the libraries saved by this command reach their save checkpoints
together and they are saved in a consistent state in relationship to each other (they are saved
as a set). Here's how each of the SAVCHGOBJ parameters affect command execution:

• The Objects (OBJ) and Library (LIB) parameters tell the command to save all of the
changed objects (*ALL) in each user library (*ALLUSR) that match the rest of the
parameters in the command. By default, the command will save all of the objects that
have been changed or added since the last running of the Save Library (SAVLIB)
command over these libraries (which occurs during the full system backup).
• The Device (DEV) parameter tells the command to save these objects to the media
device listed in the &TAPDEV parameter.
• The Journaled Objects (OBJJRN) parameter is set to *YES, which means the command
will save objects that are currently being journaled or have been journaled since the
date and time specified in the Reference Date (REFDATE) and Reference Time
(REFTIME) parameters.
• The End of Media Option (ENDOPT) parameter is set to *LEAVE, which means that the
command should not rewind the backup save media the objects are being saved to
after the command completes.
• The Update History (UPDHST) parameter is set to *NO, which means that after an
object is saved, the command will not update that object's history flag. This makes
changed objects eligible to be saved every time this program is run, until the object's
flag is reset when you run another option 21 save. The only issue this creates is that
more objects will be added to your backup media each time you run this program
(making your backup tape bigger every day), until you reset all the object history flags
during the next full system backup.
• The Save Active (SAVACT) parameter is set to *SYNCLIB, which means that all the
objects saved by the command will reach a community checkpoint and be saved in a
consistent state with each other (i.e., as a set). In addition, the Save Active Wait Time
(SAVACTWAIT) parameter tells the command to wait 60 seconds for any objects that
are exclusively being used before giving up and moving on to the next object. Objects
that are held with an exclusive lock cannot be saved by this command.
• The Save Active Message Queue (SAVACTMSGQ) parameter designates the message
queue that any command messages are sent to. This is the same message queue that
was cleared after the program starts.
• The Save AccessPpaths (ACCPTH) parameter tells the command to save certain logical
file access paths that are dependent on physical files being saved. The Queue Data
(QDTA) parameter value of *DTAQ tells the command to save both the description and
the physical contents of all standard data queues during the save.
• The Output (OUTPUT) parameter value of *OUTFILE combined with the Type of Output
Information (INFTYPE) parameter tell the command to save abbreviated result
information to the file name specified in the File to Receive Output (OUTFILE)
parameter. In my case, INFTYPE is set to *ERR, which means that the command will
write one entry to the OUTFILE for each library the command processed and a
separate entry for each object that was not successfully saved. This file can be queried
later to determine any problems in saving objects.

Line 33.00-35.00--Contains a Monitor Message (MONMSG) command that tells the program to
ignore message CPF3778 (not all objects saved from all libraries) if that message is issued as
a result of the SAVCHGOBJ command. CPF3778 is an informational message that has no effect
on command processing.

Lines 37.00-41.00--Using the Save Document Library Object (SAVDLO) command, this code
saves all the changed Document Library Object (DLO) objects that were updated or added
since the last backup. It designates that it should save all newly changed objects by
designating *SEARCH in the Document Library Object (DLO) parameter and *SAVDLOALL in
the Last Changed Date (REFCHGDATE) parameter. *SAVDLOALL tells the command to save all
objects that have been added or updated since the last backup. This command also saves
objects while they are active (Save Active parameter = *YES) and it will give up trying to save
held objects after 60 seconds (Save Active Wait Time parameter = 60).

Line 42.00--The program uses another MONMSG command to prevent the CPF906B message
(No document library objects saved) from holding up program execution, if it is generated by
the SAVDLO command.

Lines 44.00-50.00--The Save (SAV) command is used to save AS/400 IFS objects that have
changed since the last full system backup. It does this by setting the Time Period for Last
Change (CHGPERIOD) parameter to *LASTSAVE, which tells the command to save any object
that was changed since the last time the object had its Update History parameter turned on.
In addition, this command synchronizes the backup so that all changed objects are saved even
if they are in use; that all saved objects reach their save checkpoint at the same time (Save
Active parameter = *SYNC); and that all messages are sent out to the message queue
specified in the Save Active Message Queue (SAVACTMSGQ) parameter.

Line 51.00--Like the other save commands, the program monitors the SAV command to ignore
message CPF3837 (&1 objects saved, &2 not saved) if it is issued, so that the program does
not stop if that message is displayed.

Lines 53.00-59.00--These lines output the job's job log information, through the Display Job
Log (DSPJOBLOB) command, to a printer file. They also output the Save Restore information
on the tape to a spooled file, through the Display Tape (DSPTAP) command. These reports
allow the operator to review the results of the save whenever he wishes.

Line 61.00--The End Program (ENDPGM) command ends program processing.

By running the NGHTLYBKP program on a daily basis, you can save most updated
configuration and user objects to media on a save-while-active basis without disrupting
system processing. With the option 21 save and this save-while-active backup shell, you have
two different sets of backup media that contain a baseline of your system along with any
database or configuration changes that were made after the option 21 media was created.
This minimizes the amount of downtime you need to securely back up your system while other
people are using it.