Transferring objects with ObjectConnect and Enterprise Extender

Last Updated on 22 October 2021 by Roberto De Pedrini

It is often necessary to transfer objects from one system to another (files, programs, etc.) to align software (between systems in HA, for example) or to distribute it (between development, testing, and production systems). Usually, this activity is accomplished by transferring save files via FTP, but it is also possible to use the “old” ObjectConnect with the Enterprise Extender support. Let’s see how.

Enterprise Extender

Enterprise Extender, available from i5/OS V5R4, is IBM’s replacement for AnyNet support. It is used to encapsulate SNA traffic over an IP link to allow APPN traffic to flow between systems over a TCP/IP network (thus avoiding the use of special SNA routers and controllers).

ObjectConnect

ObjectConnect is a set of CL commands included with the IBM i operating system (5770SS1 Option 22) for moving objects between systems easily and efficiently.

When you use an ObjectConnect command, the system moves the object directly to the target system without using save files or distribution queues. ObjectConnect provides better performance than other methods for moving objects between systems, and it does not require additional disk space to store an intermediate copy of the object that is being moved.

ObjectConnect commands are closely related to the save and restore commands. The ObjectConnect commands support most of the same parameters.

ObjectConnect commands	IBM i save and restore commands
Save/Restore Integrated File System (SAVRST)	Save (SAV), Restore (RST)
Save/Restore Object (SAVRSTOBJ)	Save Object (SAVOBJ), Restore Object (RSTOBJ)
Save/Restore Changed Object (SAVRSTCHG)	Save Changed Object (SAVCHGOBJ), Restore Object (RSTOBJ)
Save/Restore Library (SAVRSTLIB)	Save Library (SAVLIB), Restore Library (RSTLIB)
Save/Restore Document Library Object (SAVRSTDLO)	Save Document Library Object (SAVDLO), Restore Document Library Object (RSTDLO)
Save/Restore Configuration (SAVRSTCFG)	Save Configuration (SAVCFG), Restore Configuration (RSTCFG)

Up to IBM i V7R3, ObjectConnect uses SNA data communication architecture to operate (even when SNA traffic is encapsulated on an IP link).

Note. In IBM i V7R4 with PTF SI73777 (“add native TCP support to ObjectConnect CL commands”) ObjectConnect has been made compatible with TCP/IP (new *OBJC TCP/IP server) freeing it from Enterprise Extender.

---

Target operating system: from i5/OS V5R4 to IBM i V7R4 (see previous note).

---

Enabling Enterprise Extender with HPR in IBM i and configuring it to connect two IBM i systems

To set up Enterprise Extender between two IBM i systems we just had to configure the network attributes and create a controller on each system.

Changes to system values (CHGSYSVAL)

Enterprise Extender will create (if not already present on the system) and use a controller QAPENDxxxx on the IBM i when it communicates with remote Enterprise Extender systems. It will also create APPC devices under this controller when the communication is established the first time. For the system to automatically create the necessary controller and devices the first time, the following system values need to be changed:

QAUTOCFG: Set value to “1” (Auto-configuring of devices is on):

CHGSYSVAL SYSVAL(QAUTOCFG) VALUE('1')

QAUTORMT: Set value to “1” (Allow auto-configure of remote controllers):

CHGSYSVAL SYSVAL(QAUTORMT) VALUE('1')

QAUTOVRT: Set value to “*NOMAX” (There will not be a limit on the number of virtual devices to be created):

CHGSYSVAL SYSVAL(QAUTOVRT) VALUE('*NOMAX')

Note. These values can be set back to their original settings as soon as Enterprise Extender is up and running.

Configuring network attributes (CHGNETA)

Display the Network Attributes (DSPNETA) of each system and gather the following information:

• Local Network ID (LCLNETID) and Local Control Point Name (LCLCPNAME). This is the fully qualified control point (CP) name. It is divided into two parts. The first part is called NETID of a Systems Network Architecture (SNA) network, and the second part is the CP name of this node.

• Node type (NODETYPE). The APPN Node type to be configured. In this scenario, the IBM i will be an APPN End Node.

Notes.

1. Even though the APPN Network Node (*NETNODE) function is available, the IBM i should be configured as an APPN End Node (*ENDNODE) or, if downstream APPN End Nodes must be served, as an APPN Branch Extended Nodes (*BEXNODE). APPN Network Nodes must participate in APPN Broadcast searches and Topology Database Updates and those node roles should be concentrated in the APPN backbone only.
2. Changing the node type will require you to vary off all APPC controllers and devices before changes are made.

• Allow HPR transport tower (ALWHPRTWR). Enable HPR transport tower support for APPN session traffic.

• HPR path switch timers (HPRPTHTMR). The HPR path switch timers define how long the RTP endpoint will wait for a successful path switch before terminating the HPR pipe.

To change the values:

CHGNETA LCLNETID(netid) LCLCPNAME(sys_name) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

Notes.

1. Parameters that use default values are in italics.
2. Changing the value of the LCLNETID parameter is optional. You can leave the default value (“APPN”), or you can set a different NETID on both systems (usually when the two systems belong to the same organization), or you can set a different NETID per system (usually when the two systems belong to different organizations).

A CPC0909 message (“Network attribute &1 changed to &2 by &3/&4/&5.”) is sent for each modified network attribute. Changing these values should not require a system reboot.

On SystemA, change network attributes as follows:

CHGNETA LCLNETID(NETIDA) LCLCPNAME(SYSTEMA) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

On SystemB, change network attributes as follows:

CHGNETA LCLNETID(NETIDB) LCLCPNAME(SYSTEMB) NODETYPE(*ENDNODE) ALWHPRTWR(*YES) HPRPTHTMR(1 2 4 8)

Configuring Advanced Peer-to-Peer Communication (APPC) controllers (CRTCTLAPPC)

Display the Network Attributes (DSPNETA) of each system and gather the following information:

• Local Network ID (LCLNETID)
• Local Control Point Name (LCLCPNAME)

View the local interfaces for each system using CFGTCP, Option 1, or WRKTCPSTS OPTION(*IFC) and select the IP addresses you wish to use for this connection.

Create the APPC controller (CRTCTLAPPC):

CRTCTLAPPC CTLD(ctl_name) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('remote_ipa') LCLINTNETA('local_ipa') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(remote_netid) RMTCPNAME(remote_control_point) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('controller_description')

Notes.

1. Parameters that use default values are in italics.
2. Local and remote Internet addresses are the IP addresses used by the local IBM i system and the remote IBM i system, respectively, to communicate via Enterprise Extender.
3. If you want to use host names instead of IP addresses, these host names must be resolved in IP addresses either by DNS or by appropriate entries in the hosts tables of the two systems by adding the host entry for SystemA to the hosts table of SystemB and vice versa.
4. If there is a NAT firewall between the two systems, the LCLINTNETA will always be an IP address that has been configured in CFGTCP Opt 1 and the RMTINTNETA will be the public IP address of the remote, not the private address that has been configured in CFGTCP Opt 1.
5. When using Enterprise Extender across a network that traverses firewalls, ensure UDP ports 12000 through 12004 are open between both IP addresses in both directions to successfully establish a connection (it is recommend that you also allow ICMP ECHO traffic between the two IP addresses to use the ping command to test connectivity). In addition, if this was a migration from IBM AnyNet to Enterprise Extender, ensure that you remove the remote configuration list entries from the Anynet configuration.
6. To learn more about the meaning of the parameters, I refer you to the IBM manual (see references at the end of the post).

On SystemA, create an APPC controller to SystemB:

CRTCTLAPPC CTLD(SYSTEMB) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('b.b.b.b') LCLINTNETA('a.a.a.a') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(NETIDB) RMTCPNAME(SYSTEMB) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('EE to SystemB')

On SystemB, create an APPC controller to SystemA:

CRTCTLAPPC CTLD(SYSTEMA) LINKTYPE(*HPRIP) ONLINE(*YES) APPN(*YES) RMTINTNETA('a.a.a.a') LCLINTNETA('b.b.b.b') LDLCTMR(3 15 10) LDLCLNKSPD(*MAX) LDLCTMSGRP(0 0 *NONSECURE *LAN) MAXFRAME(*LINKTYPE) RMTNETID(NETIDA) RMTCPNAME(SYSTEMA) DSAP(04) SSAP(04) CPSSN(*YES) NODETYPE(*ENDNODE) HPR(*YES) TMSGRPNBR(1) TEXT('EE to SystemB')

On SystemA, activate APPC controller:

VRYCFG CFGOBJ(SYSTEMB) CFGTYPE(*CTL) STATUS(*ON)

APPC controller goes in “Vary On Pending” state (“CPC2609: Vary on completed for controller &1.”).

On SystemB, activate APPC controller:

VRYCFG CFGOBJ(SYSTEMA) CFGTYPE(*CTL) STATUS(*ON)

On both systems, APPC controllers go in “Varied On” state (“CPF5908: Controller &1 contacted on line &2.”).

Because the QAPENDxxxx controller will not get created until you do something to initiate an Enterprise Extender connection between the two systems, On SystemA start pass-through session to SystemB (or vice versa):

STRPASTHR RMTLOCNAME(SYSTEMB) LCLLOCNAME(*NETATR) RMTNETID(NETIDB)

On both systems, a virtual APPN controller called QAPENDxxxx and an APPC device, named as the controller, are created (the APPC device is attached to APPN controller just created):

CPC2623: Description for controller &1 created.

CPC2609: Vary on completed for controller &1.

CPC2622: Description for device &1 created.

CPC2605: Vary on completed for device &1.

On SystemA, change APPC device description as follows:

CHGDEVAPPC DEVD(SYSTEMB) ONLINE(*YES)

On SystemB, change APPC device description as follows:

CHGDEVAPPC DEVD(SYSTEMA) ONLINE(*YES)

Parameter relationships:

Now that the systems are connected with Enterprise Extender let’s see how to use ObjectConnect to transfer objects.

Using ObjectConnect to replicate objects between IBM i systems

Using FTP to transfer objects such as files, programs, etc. between IBM i systems is a bit cumbersome because FTP cannot handle objects directly. To be able to transfer them, you must first save them in a save file on the local (or source) system, then transfer the save file on the remote (or target) system and, finally, restore the contents of the save file on the remote system. As mentioned above, the process isn’t exactly that simple.

By configuring Enterprise Extender on IBM i systems and using ObjectConnect, the task of transferring objects becomes much easier because it is now possible to transfer objects with a single command to run on the source system.

Let’s see some examples.

To transfer (save and restore) objects from SystemA to SystemB, you can use the SAVRSTOBJ command on SystemA:

SAVRSTOBJ OBJ(objects) LIB(library) RMTLOCNAME(NETIDB.SYSTEMB) RSTLIB(targetlib)

Similarly, to transfer a library from SystemB to SystemA, you can use the SAVRSTLIB command on SystemB:

SAVRSTLIB LIB(library) RMTLOCNAME(NETIDA.SYSTEMA) RSTLIB(targetlib)

Restrictions:

1. The user profile used to execute SAVRST* commands must be defined on both systems involved. The passwords for the two user profiles do not have to be the same.
2. QSR/SAVRST* commands are issued with *PUBLIC *EXCLUDE authorization so the user profile used to run them must be explicitly authorized or must have *ALLOBJ special authority.
3. On the target system, the user profile must be authorized to the recovery commands that will be used (SAVRST* -> RST*, for example: SAVRSTOBJ -> RSTOBJ, SAVRSTLIB -> RSTLIB, …).
4. The user profile used to execute SAVRST* commands must have either the special authority *SAVSYS specified in the user profile by the SPCAUT parameter or have (a) object existence authority for each object specified and (b) read authority for the specified library. If you do not have the necessary authority to a specified object, all objects except that one are saved and restored.
5. Both systems intended to participate in the save and restore operation must be connected to the interworking ethernet network or, the same APPN network, or if the OptiConnect for IBM i option is to be used, both systems must be joined by the OptiConnect for IBM i hardware and software.

Recommendations:

As always when saving and restoring, it is necessary to pay attention to the permissions of the objects and libraries involved on both systems and to the owner of the objects.

Hint.

If you don’t want to have authorization problems when transferring files, you can do the following:

1. On SystemA, create the user profile that will be used to run the object transfer with special authorization *SAVSYS and authorize it to the ObjectConnect SAVRST… commands to be used:

CRTUSRPRF USRPRF(user) SPCAUT(*SAVSYS)
GRTOBJAUT OBJ(QSR/SAVRST…) OBJTYPE(*CMD) USER(user) AUT(*USE)

2. On SystemB, create the same user profile with special authorization *SAVSYS and authorize it to the IBM i recovery commands associated with the ObjectConnect commands used on SystemA:

CRTUSRPRF USRPRF(user) SPCAUT(*SAVSYS)
GRTOBJAUT OBJ(QSYS/RST…) OBJTYPE(*CMD) USER(user) AUT(*USE)

---

References:

Configuring EE (Enterprise Extender) between Two IBM System i Systems

ObjectConnect function

Change Network Attributes (CHGNETA)

Create Ctl Desc (APPC) (CRTCTLAPPC)