Admin Alert: A Much Quicker Way to Move System i Objects Between Partitions
March 12, 2008 Joe Hertvik
In a recent article, I detailed how to use common i5/OS commands to easily transfer System i objects between partitions. After publication, several readers wrote to say that if you have a working SNADS network between your target and source partitions, transferring objects is incredibly easy if you just use the commands that come with IBM‘s free ObjectConnect licensed program. And you know something, they’re right! ObjectConnect is easier.
This week, I’ll review what ObjectConnect does for i5/OS object movement between systems, how to make sure that you have it installed on your machine, and how to use it for extremely quick object transfers between System i, iSeries, and AS/400 boxes. If you have a SNADS network set up, ObjectConnect can be a time-saving godsend that will quickly become your technique of choice for moving objects between systems.
The Hard Part: Do You Have ObjectConnect and a SNADS Environment?
ObjectConnect is an i5/OS licensed program that enables automated object distribution between any System i, iSeries, and AS/400 machines. Packaged as product option 22 under the i5/OS operating system (5722SS1), ObjectConnect is available in all recent and prior versions of i5/OS and OS/400, going all the way back to OS/400 V3R1M0.
Although ObjectConnect can be used with other operating system products and features, such as Distributed Data Management (DDM) architecture or OptiConnect (5722SS1, option 23), the product is incredibly easy to use with IBM’s System Network Architecture Distribution Service (SNADS). SNADS is an operating system application that uses Advanced Program-to-Program Communications (APPC) to talk to and exchange objects with other systems in the SNADS network, and SNADS has been a mainstay of the i5/OS and OS/400 world for decades. As such, many i5/OS shops already have a SNADS network configured for all of their partitions.
So the first step in using ObjectConnect is to make sure that it’s installed on your system and to verify that you have a working SNADS network between your partitions. To verify that OptiConnect is installed on your partitions, go to each partition and start the “Work with Licensed Programs” menu by using the following “Go to Menu” command (GO).
On the Work with Licensed Programs menu, select option 10=Display installed licensed programs. The “Display Installed Licensed Programs” screen that appears will display all the licensed programs and options that are available on your partition. Press the F11=Display Status key twice to make the screen display all the Product Options that are installed for each licensed program. Look for option 22, OS/400 – ObjectConnect, under the 5722SS1 licensed program. If you find ObjectConnect in this list, the program is installed and ready to be used. If option 22 isn’t installed, ObjectConnect is not present on your machine, and you will need to load it from your installation media in order to get started.
Next, make sure that SNADS is configured on both the source system (where the objects you want to transfer exist) and on your target system (the system that you want to transfer the objects to). If you need to set up a SNADS network to accomplish these transfers, consult IBM’s Configure SNADS and Setting Up SNA Distribution Servicesdocument on the subject.
The Easy Part: Using ObjectConnect
Once the hard part is finished and you’re sure that ObjectConnect is installed on your system and you know that your SNADS network is up and working, you can get to the easy work of using the package to transfer objects between your systems. Here’s my four step process for using ObjectConnect to transfer objects between systems. Note that all commands shown here can be used in either interactive or batch mode, so you can perform manual or automated transfers, as you wish.
Step #1: Make sure that SNADS is Up and Running
To double-check that SNADS is available, simply check that the QSNADS subsystem is up and running on the systems that you want to transfer objects between. You can do this by running the following Work with Active Jobs (WRKACTJOB) command.
If QSNADS isn’t running, you’ll need to start it before proceeding.
Step #2: Start APPC Mode Communication Between Your Systems
An APPC mode is associated with the two paired logical units (LUs) that talk to each other through SNADS on your source and target systems. APPC modes determine the session properties for your LU pairs, which in turn determine what can and cannot be done when the two partitions communicate with each other. In order to make ObjectConnect work across partitions, you need to start all associated APPC modes that your source i5/OS location needs to communicate with the target partition that it wants to send files to. To do that, run the following Start Mode (STRMOD) command.
The remote_location_name is the SNADS remote location name of the system that you want to send objects to. You can find the remote location name of your target partition by looking in your partition’s distribution queues configuration. To get to that screen, run the following Configure Distribution Service (CFGDSTSRV) command.
This command will show you the Configure Distribution Queues screen, which lists out all the various distribution queues that you can send objects to on your system. Each queue is associated with a remote location name that the queue uses to direct object distributions to various systems in your network. Although each queue can provide a different type of distribution protocol service (including document library services, VM/VMS bridge queues, and SystemView distribution services), for our purposes you will want to find the correct SNADS entry for your target system. Look at the list and pick out the *SNADS queue that directs distributions to your target partition. Write down the Remote Location Name associated with that queue and use that name in the STRMOD command listed above.
Once you run STRMOD for your remote location, you should receive a message stating that “Command STRMOD completed successfully for mode BLANK device remote_location_name.” At this point, you are ready to save and restore different objects between your source and your target systems.
Step #3: Save and Restore an Object to Your Target System
Where steps 1 and 2 opened the highway for high-speed object distribution between systems, step 3 loads up the truck and sends it roaring down the road. Sending files, libraries, objects, and configurations between systems using ObjectConnect is easy. All you have to do is use one of the following commands to restore an object from one system to another.
These commands should look familiar to you. They are all combinations of various Save (SAVxxx) and Restore (RSTxxx) commands that you have probably run hundreds of times before. For ObjectConnect over a SNADS network, the combined SAVRSTxxx commands do an amazing thing. In one step, they save i5/OS objects from your source system and quickly restore those saved objects to your target system through SNADS. These objects contain many of the same parameters as their SAVxxx and RSTxxx predecessors, and you can do most of the same things with the SAVRSTxxx commands that you can do with their SAV and RST counterparts.
If you’re familiar with basic i5/OS and OS/400 save and restore procedures, you should be able to figure out which parameters to use for each command. To help get you started with these commands, here’s a sample Save Restore Object (SAVRSTOBJ) command that saves a single object from the source system and restores it to the target system.
SAVRSTOBJ OBJ(object_name) LIB(object_lib) RMTLOCNAME(remote_location_name) MBROPT(*ALL) ALWOBJDIF(*ALL)
Like its Restore Object (RSTOBJ) command counterpart, there are options to overwrite existing objects in the target machine library (the MBROPT and ALWOBJDIF parameters), as well as other options to control which libraries you are restoring to, as well as other save and restore parameters.
My recommendation is to start small and try transferring a single object between systems by using the appropriate SAVRSTxxx command. Once you see how easy it is, you’ll probably want to use these commands for all your cross-system transfers.
Step #4: Clean Up After Yourself
Once your transfers are complete, you’ll want to shut down the APPC modes that you activated in step 1. This is easily done by using the following End Mode (ENDMOD) command.
The remote_location_name is once again the distribution queue name of the system that you sent the objects to. This is the logical end of an ObjectConnect distribution session as it disconnects the SNADS distribution queue from the target system.
Much Easier Than Other Procedures
After setting up and running ObjectConnect transfer, I found that it was much easier to use it to transfer objects than it was to use my previously published Five Minutes to Moving System i Objects Between Partitions. Once you have your SNADS network set up, it’s a no-brainer to send objects between two systems. The nice thing about this technique is that it can be used in interactive and batch jobs, so that you can use it in both automated and manual transfer situations.
About Our Testing Environment
Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Most of the commands shown here are also available in earlier and later versions of the operating system running on iSeries or AS/400 machines. If a command or function is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release.
Special thanks to reader J. Green and Loek Maartens who introduced me to ObjectConnect. As always, I appreciate reader feedback and use it to improve upon any techniques that I presented in earlier columns.