Admin Alert: Moving Libraries Between i5/OS Partitions, Part 1

For i5, iSeries, and AS/400 administrators, it’s common to move libraries between partitions or machines. Library duplication is necessary when you’re creating or updating data in a test partition, moving software libraries between machines, or migrating information from an existing partition to a new machine in advance of an upgrade. Whatever your migration situation, there are definite steps for easily transferring libraries between environments.

When performing library duplication, you generally need to perform the following five steps for a successful transfer.

1. Prepping the data to be moved
2. Saving the library to be moved
3. Transferring the saved library to the new partition or machine
4. Restoring the saved library to the target machine
5. Checking your results

These steps are fairly intuitive and easy to follow, as long as you avoid a few pitfalls. This week, I’ll cover the first two steps–prepping the data to be moved and saving the library to be moved–with the remainder of the procedure to follow in my next article. These instructions apply to i5/OS V5 and below (including earlier OS/400 V4 systems) but you may find that some command parameters are not available in the earlier versions.

Step One: Prepping the Data to Be Moved

Data can be transferred between i5 partitions by using media (tapes, DVDs, etc) or by using i5/OS Save files. For the purposes of this article, let’s assume that we are going to save our source library to a save file and then FTP that save file to our target machine, where it will be restored.

Before we can save our data, we may have to do some prep work. This involves performing a quick examination of the library we are saving on our source machine and then comparing it to the library that we are going to restore it to on the target machine. If the two libraries names are the same (source=target), you can skip reading the next three paragraphs.

If you are going to restore your source library data to a different library on your target machine, you may want to use the Copy Library command (CPYLIB) to create the exact same library name and data on your source machine that you are going to transfer to your target machine. This can avoid confusion with the RSTLIB command, which can sometimes restore logical files over the wrong physical member when the Saved library (SAVLIB) and Restore to library (RSTLIB) parameters on the command are different.

To make sure the restore comes off cleanly in these situations, you can use the following CPYLIB command to create a copy of your source library and data that resides in the same target library name that you will be restoring to.

CPYLIB FROMLIB(source_lib_name) TOLIB(target_lib_name)

By doing this, you will be creating the exact library and data that will be restored on the target system, and there should be no confusion about which physical file objects the logical files in the restored library will be created over.

The second step in prepping data to be transferred is to remove the garbage from the library to be saved. Do this by examining the library objects, deleting any garbage objects that you have in the library (saved versions of different files, one-time programs that aren’t needed, test objects, etc) and reorganizing any files that have a large number of deleted records. By doing this, you avoid transferring garbage to a new system, and it will minimize the amount of storage needed for the new library on the target system.

Step Two: Saving the Library to Be Moved

Once you have prepped the data, you are now ready to save it to a save file on the source system. Save files are special i5/OS objects that contain packed saved data that can be used for a one object transfer between systems.

The first step in saving an entire library to a save file is to ensure that your target save file exists on the source system, and that it has been cleared of any save file data it may have previously contained. If you wanted to save the library to an existing save file, you can use the Clear Save File command (CLRSAVF) to clear the file:

CLRSAVF FILE(save_file_library_name/save_file_name)

If the save file does not exist on the system, you can easily create a new empty save file by executing the following Create Save File command (CRTSAVF):

CRTSAVF FILE(save_file_library_name/save_file_name)

Once your save file is ready to accept library data, you can now save your library data to that file by using this Save Library command (SAVLIB).

SAVLIB LIB(source_lib_name) DEV(*SAVF)
SAVF(save_file_library_name/save_file_name) SAVACT(*SYNCLIB)
SAVACTMSGQ(message_queue_name)

The Device parameter (DEV) of *SAVF specifies that you will be saving data to a save file and the Save file name and library parameter (SAVF) specifies the name and location of your file.

Notice that we use the save while active features (the SAVACT and SAVACTMSG parameters) of the SAVLIB command while we are saving this library. Using these parameters accomplishes two things:

• The Save active parameter (SAVACT) value of *SYNCLIB ensures that all objects can be saved, even when they are being used by another job. *SYNCLIB also sets a checkpoint for the library objects, so that all objects are saved in a consistent state with one another, allowing you to save a complete set of library objects where the data is in sync.
• The Save active message queue parameter (SAVACTMSGQ) tells the SAVLIB command where to write any messages that are associated with the save while active function.

By doing this, you can insure that the save file will contain a complete synchronized set of library data for our target machine restore.

If both the source and target i5/OS partitions are at the same operating system level, you can stop here and run this SAVLIB command. But if you are saving the source library data at an i5/OS or OS/400 operating system level that is higher than the operating system level of the machine you will be restoring to, you will need to add a Target Release parameter (TGTRLS) parameter to your SAVLIB command, like this:

SAVLIB LIB(source_lib_name) DEV(*SAVF) TGTRLS(*PRV)
SAVF(save_file_library_name/save_file_name) SAVACT(*SYNCLIB)
SAVACTMSGQ(message_queue_name)

In this example, the Target release parameter (TGTRLS) value of *PRV indicates that this library is being saved for restoration to a target library that is running on the previous version of the i5/OS or OS/400 software. If addition to *PRV, TGTRLS can be set to save the library objects to several other previous releases, depending on the version of the operating system you are currently running on the source partition.

There is only one trick to keep in mind when restoring to earlier versions. If your source library contains programs that will be transferred to a lower version of the operating system, the programs should be recreated using the earlier target release, otherwise they may not be able to run on the lower version. For other types of library objects that are being saved–such as files and data areas–SAVLIB will automatically save them in a format that can be used by the lower operating system version.

Half Way There

At this point, we now have a save file on our source system that contains all the objects and data that we want to restore to our target system. In my next column, I’ll show you the best techniques for insuring that library can easily be transferred to and restored on your target system.