Admin Alert: Another Way to Move Devices Between Systems

In a recent column, I discussed how to move printer devices and output queues between systems. While that article showed you how to migrate objects by using save and restore techniques, reader Bill Bremerman wrote in to remind me that you can also use the Retrieve Configuration Source command (RTVCFGSRC) to capture CL source code, which can be used to easily recreate devices, controllers, line descriptions, and several other i5/OS objects on any system.

Here is how it works.

My earlier article focused on migrating device objects to a new partition by using the i5/OS Save Configuration command (SAVCFG) to save objects on one system, move the saved objects to a second system, and then restore the objects on the new system by using the Restore Configuration command (RSTCFG). That technique was based on creating actual copies of objects on a different system, and then tweaking the restored objects to make them work in the new environment.

Bill’s technique uses a different approach. Rather than restoring an exact copy of the physical objects on the new system, this technique involves a two-step process where you perform the following steps to move configuration objects between systems:

1. Use the Retrieve Configuration Source command (RTVCFGSRC) to retrieve and save the Control Language (CL) source code that was originally used to create the configuration objects that you want to move.
2. Transfer, modify, and run the retrieved source code on your target system to recreate the object from scratch, with the exact parameters that you want the new device to have. The source code can be run from a command line or it can be run as part of a compiled CL program.

The benefit of Bill’s technique is that you are not limited to restoring an exact copy of the object you are recreating. Before creation, you can modify the retrieved source code and use it to create a similar object with any needed parameter changes. By using the source code for recreation, you can do more than just copying objects between systems; you can use the original object’s CL code as a template for creating other objects that meet different system needs. This technique not only works on i5/OS V5 systems, it also works on OS/400 V4 systems, as well.

The RTVCFGSRC technique can not only be used to recreate objects on different systems, it can also be used to recreate damaged devices on your source system. This is important because any backups that you have for a damaged device may themselves be damaged. Having source code backup also allows you to recreate devices that were accidentally deleted.

Another benefit is that you can retrieve the source code for and recreate a large number of devices at one time on a new system, including network server descriptions; line, controller, and device descriptions; and mode and class-of-service descriptions. Finally, by recreating devices between systems from CL source code–rather than by saving and restoring them from media–it’s easier to recreate devices on systems that are on different operating versions, which might avoid any minor issues that occur when moving objects to down-level systems.

Backing Up Configuration Object Source

The first step in moving objects this way is to use the Retrieve Configuration Source command (RTVCFG) to save the source code for recreating your target devices. A typical RTVCFGSRC command looks like this:

RTVCFGSRC CFGD(configuration_object) CFGTYPE(configuration_object_type) SRCFILE(library_name/cl_source_file_name)

Where the following values are in effect:

The Configuration Description parameter (CFGD) describes the names of the configuration objects that you want to retrieve the source code for. This parameter works in conjunction with the Type (CFGTYPE) parameter to define which objects you are working with. You can elect to save all configuration objects of the specified type (*ALL), generic objects that start with a specific string delimited by an asterix (ex., ABC*), or all objects with a specific name (ex; TAP01).

The Type parameter (CFGTYPE) specifies the type of configuration objects that you are retrieving source code for. There are many different object types whose source code can be retrieved, including devices (*DEVD), controllers (*CTLD), line descriptions (*LIND), and Connection Lists (*CNNL). You can retrieve source for all configuration objects that match the name listed in the CFGD parameter by specifying *ALL under CFGTYPE.

The Source File and Library parameters (SRCFILE) specify the i5/OS source file to save the retrieved source code to. By default, RTVCFGSRC will save the source code to the first QCLSRC source file it finds in your library list, under a source member name with the same name as the value in your CFGD parameter. If you specified *ALL under CFGD or used a generic CFGD value, all the source for each configuration object will be saved under the CFGD member in your source file.

Once you run the RTVCFGSRC command, all the source code for the designated objects will be saved to your source file. Inside your source member, there will be one Create command (CRTxxxxxx) present for every configuration object that you specified in your parameters. If you retrieved the source code for recreating a tape drive name TAP01, your retrieved CL code might look like this:

CRTDEVTAP DEVD(TAP01) RSRCNAME(TAP01) ONLINE(*YES) ASSIGN(*YES)
UNLOAD(*YES) MSGQ(QSYS/QSYSOPR) TEXT(‘CREATED BY
AUTO-CONFIGURATION’)

The nice thing about RTVCFGSRC is that it can be inserted into your daily or weekly backup routine so that your configuration object source is always backed up and current. If you ran the following command at the beginning of your backup:

RTVCFGSRC CFGD(*ALL) CFGTYPE(*ALL) SRCFILE(QGPL/QCLSRC)

All your current configuration object source would be saved to the QCLSRC source file in QGPL every night, under the CFGD source member. Not only would this source code be written to disk, it would also be saved to media every time you back up the QGPL library. This enables you to go back and retrieve older configuration object source code, if needed.

Recreating Your Objects

After your source code is saved, the drill to recreate objects is easy. Go into the source member containing your configuration object source and make any necessary changes to the CL object creation source. These changes could include changing object parameters or deleting source code for objects that you don’t need. After making your changes, you can compile the source member and run the compiled program, which will then recreate the objects. You could also copy any desired commands from your source code member to a command line and execute each command directly from the green screen.

Is there anything you would not want to recreate?

If you are retrieving the source code for a large number of objects, you may want to review and remove specific create commands before you recreate all the configuration objects included in your source member. In general, you will want to skip recreation for any objects that would normally be created through your system’s Autoconfiguration function. This includes devices that were created as part of a PC5250 session, as well as any QPADEV* devices that were created when a user starts a generic Telnet session. If Autoconfiguration is turned on, these devices will automatically be created on your target system the first time the system senses the device.

Many Roads, Same Destination

As you can see, the RTVCFGSRC command presents a viable option for easily moving objects between two systems. It has several advantages over using save and restore techniques, with the primary advantage being its’ flexibility in selecting, changing, and restoring devices to any other i5/OS or OS/400 system.

RELATED STORIES

RTVCFGSRC (Retrieve Configuration Source) Command Description, iSeries Information Center, IBM

Moving Printer Devices and Remote Outqs Between Systems