ID-INFO blog

Let’s launch a SAVE21!

Do you need to centralize all your IBM i system data in a single backup? It’s easy: let’s launch a SAVE21!

Everyone in the IBM i community is familiar with this term, which is derived from a menu option: log on to the native backup management menu (GO SAVE), select option n°21, and simply follow the on-screen instructions.

On the other hand, you don’t have the resources to stay in front of a screen all night? Easy: submit this backup as a batch file! How? It’s easy! Follow this article and we’ll show you how to prepare your SAVE21 in batch.

What does SAVE21 save?

This includes the firmware, the system (including security and configuration data), all libraries and the entire IFS (including the QDLS directory, the famous “DLO”). We also hear the term “ALL system backup” used, as opposed to the simple “system backup”, which actually refers to a SAVSYS, or option 22 of the SAVE menu.

Nor are the two terms entirely independent. In fact, SAVE21 includes a SAVSYS, to which it adds a full backup of user data, equivalent to option 23 of the SAVE menu.

For all the commands listed in this article, <device> refers to the drive in which <volume>, the backup media used, is inserted. The SAVE21 includes the following backup commands:

Firmware and system backup :

SAVSYS DEV(<device>)
VOL(<volume>)
ENDOPT(*LEAVE)

Backing up the rest of the libraries (“non-system” libraries) :

SAVLIB LIB(*NONSYS)
DEV(<device>)
VOL(<volume>)
ENDOPT(*LEAVE)

Saving “DLOs” (contents of /QDLS) :

SAVDLO DLO(*ALL)
DEV(<device>)
VOL(<volume>)
ENDOPT(*LEAVE)

Backup of the entire IFS (except /QDLS and /QSYS.LIB, which have already been backed up) :

SAV DEV(‘/qsys.lib/<device>.devd’)
OBJ((‘/*’)
(‘/QSYS.LIB’ *OMIT)
(‘/QDLS’ *OMIT))
VOL(<volume>)
ENDOPT(*REWIND)

 

When should I submit my SAVE21?

SAVE21 must save EVERYTHING. This means that all objects on the system must be available for the backup job. To ensure this, IBM has restricted access to SAVE21 to the period when the system is in restricted mode, i.e. when all jobs and subsystems are stopped.

However, this restricted mode has serious consequences: the IBM i is inaccessible, and only one job can run on your system: the backup job. All your applications will be down, and the system will be inaccessible, manageable only via a console (HMC or LAN).

Timing is therefore of the utmost importance: we need to find the interval when such an operation has the least possible impact. In addition, check the system scheduler to see if any jobs are scheduled during the restricted mode period, so that they can be restarted (if necessary) at the end of the backup.

 

How do I submit a backup?

The “how?” question is indeed the most complex to answer, in the context of SAVE21. Since the restricted mode prevents you from reacting once the backup has started, you need to anticipate any possible cause of interruption before submission: Make sure the backup cartridge is in the drive and ready for use:

CHKTAP DEV(<device>) ENDOPT(*REWIND)

 

Always make sure that the tape is properly installed in the drive beforehand. This command also releases the message ” CPC6778 “, in which the name of the volume mounted in the drive can be retrieved via an RCVMSG.

In the case of a tape library or VTL, this means you don’t have to enter the name of the hard-coded backup volume in the source code. Please note, however, that the CHKTAP command does not work directly on a tape library; the CPF415A message is sent. In this case, start by finding the desired band. Use option 5 to check the category (and system if applicable) of this cartridge.
Install the cartridge, then use the command :

SETTAPCGY DEV(<device>) OPTION(*MOUNTED) CGY(<category> <system>)

 

<system> is only required if the category is *NOSHARE. It usually refers to the name displayed in DSPNETA. You must also be careful to initialize the belt before using it:

INZTAP DEV(<device>) CHECK(*NO)

 

Next, you need to make sure that the job will be submitted correctly and that the restricted mode is possible.

 

During restricted mode, only the control subsystem will be active, with only one job inside. Moreover, entry into restricted mode is achieved by shutting down all subsystems, and exit from this mode is achieved by restarting the control subsystem, which triggers a startup program execution job.

The control subsystem is indicated in the system value QCTLSBSD. On most systems, the control subsystem is QSYS/QCTL, and the session running inside QSYS/DSP01. Make sure these are started. The start-up program is indicated in the system value QSTRUPPGM. It can be customized as required. You therefore need to make sure that it starts the entire application. We also need to make sure that the JOBQ attached to the control subsystem is released and that the session to which the job is connected is free.

Finally, you need to take into account the performance of the system you’re working on. Don’t hesitate to insert DLYJOBs, for example, to prevent SAVSYS from being launched until restricted mode is reached. You can also wait for message CPF0968 to be released before starting the backup.

On the other hand, some orders can wait for a result before allowing work to continue on the next order. This waiting time for a result can be modified if performance is poor:

CHGJOB DFTWAIT(<duration_in_seconds>)

 

Finally, the overall performance of the job is even taken into account in the batch start command of the system’s restricted mode:

ENDSBS SBS(*ALL) OPTION(*IMMED) BCHTIMLMT(<max_restricted_mode_time_in_minutes>)

 

In fact, the value specified in the BCHTIMLMT parameter defines the maximum duration for which the restricted mode will last, even if the job is blocked in one way or another.

Care must be taken not to set this time too short for the job to finish normally, but not too long either, as this could result in the system not being able to recover when users need to log on.

Once this time has elapsed, the control subsystem will restart whether or not the job has been completed. If you plan to create a program that works both interactively and in batch mode, you’ll need to condition this command: if *NOMAX is specified (or the parameter is left at its default value), then the command won’t work in batch mode. If a value other than *NOMAX is specified, then the command will not work interactively.

 

Other backup parameters :

The save commands can be performed in any order, except for SAVSYS, which must be performed first in order to have the microcode at the start of the save to be able to launch an IPL from this source.

The ENDOPT parameter must then be adapted according to this order to indicate *LEAVE for successive backups and *REWIND or *UNLOAD (as required) at the end of the backup. In fact, *LEAVE saves a lot of time when rewinding the tape.

Does your backup work fine, but no spool is present after restoring a queue? If spools are important to your application, it is essential to specify an additional parameter whose default value does not allow spool files to be saved. In this case, SPLFDTA(*ALL) must be specified. The same applies to the contents of *DTAQs: QDTA(*DTAQ).

Finally, if the status of backups is to be monitored by a team, it may be advantageous to modify the OUTPUT parameter.

*PRINT retrieves a spool file, which can then be “filed” in a specific OUTQ.

*OUTFILE allows you to store the result of a backup in an external file. OUTFILE and OUTMBR must then be indicated with *OUTFILE to specify the file location. It is possible, for example, to have one time-stamped member per backup to keep a history. The output information is then set by the INFTYPE parameter. For the IFS backup SAV command, the *OUTFILE option is not available for the OUTPUT parameter.

Warning: for the SAVLIB command LIB(*NONSYS) […] OUTPUT(*OUTFILE) OUTFILE(<library>/<outfile>), SAVE21 will systematically count an unsaved object, the famous output file <library>/<outfile>. The backup job may end up with a fine code other than 0, which can cause problems for monitoring and reporting.

 

How to benefit from a SAVE21?

The main disadvantage of a SAVE21 is that it puts the system into restricted mode. But any disadvantage can be exploited to become a strength. In fact, we can take advantage of the need for restricted mode to submit orders that are not possible in “normal mode”.

For example, you can take advantage of restricted mode to launch a reclaim storage (RCLSTG), a hardware operation, or operations that work better without activity (stopping logging, modifying a subsystem, modifying the connection pattern, “reorganizing” the most frequently used files, applying PTFs, etc.).

 

Do you have questions about a particular IBM i topic? Then contact us on 04 30 96 97 32, or via the contact form.

Partager cet article