Configuration of Objectconnect

Resolving The Problem

Note: Before proceeding, make sure that license program option 22 Object Connect is installed on both systems.

DSPSFWRSC or Display Software Resources

This should show you the following:

5722SS1 22 5050 OS/400 - ObjectConnect
5722SS1 22 2924 OS/400 - ObjectConnect

Ensure that Library QSR exists on the target systems that ObjectConnect runs to.

Step 1. Get the Local Control Point Name, Local Location Name, Local Network ID from each system using the DSPNETA command. If the Local Network IDs are different on each system, refer to Rochester Support Center knowledgebase document New, Object Connect with Different Net IDs:

Step 2. On the command line, have the customer issue the STRPASTHR command, prompt and specify the Remote Location name and Remote Network ID, and press Enter.

(STRPASTHR Parameters)

         Remote location  . . . . . . . . SYSTEMB
         Mode . . . . . . . . . . . . . .   BLANK
         Local location . . . . . . . . .   *LOC        

If the customer gets a sign on to the remote system, have them sign in and do an ENDPASTHR, then test STRPASTHR in the other direction. If this works, we know we have at least part of the underlying communication configuration (Lines, Controllers and Devices) needed for Object Connect to function. Because Object Connect uses the sub-system Communication Entries whereas Passthrough uses Passthrough Server Jobs, just because Passthrough works does not mean Object Connect will function. So if Passthrough works, proceed to Step 4 to test the subsystem communication entries. If Passthrough fails, you should review the entire communications configuration before proceeding.

Step 3. On the command line, have the customer issue the command CALL QCMD and then issue the APING command and specify the Remote Location and Mode QSOCCT which is the mode used by Object Connect and press Enter.

(APING Parameters)

Remote location  . . . . . . . . SYSTEMB          
Mode . . . . . . . . . . . . . .   QSOCCT
Remote user ID . . . . . . . . .   *NONE
Remote password  . . . . . . . .   *NONE  

APING RMTLOCNAME(netid.remote_location) MODE(QSOCCT)

If the APING command completes, this would indicate that the communication configurations and communication entries are in place to support Object Connect functionality

If this step fails, proceed to Step 5.

If this step is successful; you should have the customer issue the Object Connect command they are using again and, if a failure occurs, look for joblog. In the source joblog, it should state whether a remote job was started. If possible, you should find that remote joblog and see if any errors are occurring and what errors they are. If you see errors indicating there is a problem with restoring a library or an error indicating this is something other than a communications issue, you should involve the Save/Restore team for assistance.

Step 4. ObjectConnect uses the mode QSOCCT. On the system which is acting as the target for the Object Connect function, issue the WRKSBSD SBSD(QCMN) command and take Option 5 to Display and Option 8 to Work with Communication Entries. You should see something like the following:

Job Default Max Device Mode Description Library User Active *ALL QSOCCT *USRPRF QUSER *NOMAX

If there is no entry for the mode QSOCCT, it must be added and the APPC devices on both systems varied off and back on so the mode is negotiated between systems. Then attempt the Object Connect command again.

ObjectConnect uses the IBM-supplied default mode description QSOCCT. There are two parameters which, if altered from the default settings, will cause these messages CPF8911 and CPI5906. To check, issue the following command from an operating system command line:

WRKMODD QSOCCT
Press the Enter key.

MAXINPAC should be *CALC and MAXLENRU should be 32767.

To add a communication entry for mode QSOCCT to the QCMN subsystem on the systems, you will run ObjectConnect to (the target systems):

ADDCMNE SBSD(QCMN) DEV(*ALL) DFTUSR(QUSER) MODE(QSOCCT)
and press the Enter key.

Ensure that QCMN subsystem is started.

Note: If the QCMN subsystem is not started on the target system, the target system will log message CPF1269 RC715. The controller on the target system must be varied off and back on after QCMN is started.

The reason for adding this entry is that the communication device is allocated to QCMN and it uses QUSER on the target system. If it still fails, go to Step 6.

Step 5. On the target system, issue a DSPLOG command, prompt and search for message identifier CPF1269 message posted at the time of failing Object Connect job:

DSPLOG MSGID(CPF1269)

If one is found, obtain the first Reason Code. For an explanation of the reason codes, refer to Rochester Support Center technote: CPF1269 Reason Codes

Example
                                                                               
  Message ID . . . . . . :   CPF1269       Severity . . . . . . . :   00        
  Message type . . . . . :   Information                                        
  Date sent  . . . . . . :   05/05/98      Time sent  . . . . . . :   10:37:56  
                                                                               
  Message . . . . :   Program start request received on communications device  
    RCHASLQL was rejected with reason codes 502, 1506.                          
  Cause . . . . . :   The program start request was rejected in job            
    026715/QSYS/QCMN. The device belongs to remote location RCHASLQL. If the    
    device is an advanced program-to-program communications (APPC) device, the  
    program start request was received on mode BLANK with unit-of-work          
    identifier APPN.RCHASLQL-B067BC195469-0001. The first reason code means:    
    Output queue was not found. The second reason code means: S/36 Procedure or
    library name is greater than 8 characters.                                  
  Recovery  . . . :   See the job log for more information about the problem.


Notes:
1. Another common misconception is when a SNA sense code of 08640000 (Function Abort)is issued. This sense code does not necessarily indicates a problem with communication, but often is caused because at the application level an error has occurred causing the session to be aborted.

2. If these steps fail to resolve the issue it may be necessary to take a communication trace on the target system or involve a senior member of the PEER Communications team.

Note: If the systems are in different Network IDs, the SAVRSTOBJ command (or whichever ObjectConnect command is used) must include the Network ID of the remote system, for example:
SAVRSTOBJ OBJ(TESTFILE) LIB(MYLIB) RMTLOCNAME(RMTnetid.RMTlocNAME)

Possible SNA Communications configurations that OBJECTCONNECT may use:

1. NATIVE LAN SNA
Ethernet IBM OS/400-to-OS/400 SNA/APPN Configuration with Matching Parameters

2. IBM ANYNET
It is not suggested to use ANYNET, as a communications configuration.

Important Note: Starting in i 7.1, AnyNet (a method used to run SNA communications traffic over IP) is no longer supported. Users of AnyNet are encouraged to migrate to Enterprise Extenders as a replacement. For information about migrating to Enterprise Extenders from AnyNet, see the Migrating from AnyNet to Enterprise Extender topic in the IBM i Information Center. If one of the systems is at r710, ANYNET will have unpredictable results and is not supported.

3. ENTERPRISE EXTENDER
This is the preferred method, to configure a communications link.
Configuring EE (Enterprise Extender) between Two IBM System i Systems

4. OPTICONNECT
Enabling Virtual and HSL Opticonnect Using HMC Version 7