Troubleshooting
Problem
This document is a mini-guide for troubleshooting ObjectConnect.
Resolving The Problem
Troubleshooting Objectconnect
Always ensure the SNA or Enterprise Extender connection works because that is the major cause of problems with ObjectConnect. Use the following command:
APING RMTLOCNAME(netid.remote_location) MODE(QSOCCT)
where netid is the Local Network ID (found by typing DSPNETA on the remote system) and remote_location is the (the Local Location name in DSPNETA on the remote system).
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:
Always ensure the SNA or Enterprise Extender connection works because that is the major cause of problems with ObjectConnect. Use the following command:
APING RMTLOCNAME(netid.remote_location) MODE(QSOCCT)
where netid is the Local Network ID (found by typing DSPNETA on the remote system) and remote_location is the (the Local Location name in DSPNETA on the remote system).
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 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(DAGGITY2) LIB(MYLIB) RMTLOCNAME(netid.remote_location)
Press the Enter key.
Examining the joblogs
Joblogs are important. On the source side there should be a joblog of the user or job that issued an ObjectConnect command (for example, SAVRSTOBJ and so on). It will look similar to the following:
SAVRSTOBJ OBJ(DAGGITY) LIB(USERIB) RMTLOCNAME(TARGET)
Job 755207/QUSER/SOURCE started on system TARGET.
1 objects saved from library USERLIB.
Object TXIDQ in QTEMP type *USRQ deleted.
Object RESPQ in QTEMP type *USRQ deleted.
Following messages are from remote location TARGET.
Library QSR added to library list.
Saved file or member level ID not same as file DAGGITY.
FILE DAGGITY not restored to USERLIB.
No objects saved or restored for library USERLIB.
An error occurred during the SAVRSTOBJ operation.
Underlined in bold, above is the name of the job that was started on the target system. Look for this joblog on the target system. It will look similar to the following:
CPF3283 Diagnostic 50 05/26/06 09:38:59.264048 QDBRSPRE QSYS 0F84 QDBRSPRE QSYS 0F84
From user . . . . . . . . . :
Message . . . . : Saved file or member level ID not same as file DAGGITY.
Cause . . . . . : The restore operation of file DAGGITY in library USERLIB was not done because the member level identifier (ID) for the file that presently exists on the system is not the same as the member level ID for the file on the save media. If the level identifier that is not the same is for a specific member, the member name is *N.
Recovery . . . : Either delete the existing file (DLTF command), or remove the member (RMVM command). Then try the restore request again.
CPF3756 Diagnostic 20 05/26/06 09:38:59.264176 QSRRSOBJ QSYS 1125 QSRRSLIB QSYS 0112
From user . . . . . . . . . :
Message . . . . : FILE DAGGITY not restored to USERLIB.
Cause . . . . . : See previously listed messages to determine the error.
Recovery . . . : Correct the error. Then try the request again.
If there no joblogs on the target side, examine the job description used for QUSER. Ensure it is set for the correct logging level.
History Log
On the target system, look for message ID CPF1269:
DSPLOG MSGID(CPF1269)
CPF1269 messages are generally authorization or security errors. Get the first error code and use the following Rochester Support Center knowledgebase document to debug it:
CPF1269 Reason Codes
Authority Issues
Library QSR must exist on the target systems that ObjectConnect runs to. Objects in this library must have the correct authority. If you are unsure, you could try re-installing the Object Connect licensed program, or ask support to check with the Save and Restore team.
SNA Sense Code 08640000
An SNA sense code of rc08640000 means a function abort occurred. This is normally not a communications problem but rather an application issue. In this case, the application is part of ObjectConnect. Follow the data collection procedures (in the next section) to collect data for analysis.
| Note: This type of problem may be worked by the Communications and Save/Restore teams to determine if this is an ObjectConnect or a communications issue. |
Data Collection Guide
Gather the following data:
1 A communications trace that is run on both sides.
2 The joblogs from both the source and target systems.
3 The History log from around the time frame for the problem from both the source and target systems. (This is usually collected for a time starting half an hour before the problem occurred.)
4 In extreme cases, a job trace of the source and target job
Speak to support for further details on data to collect, and how to collect it
Performance Expectations
It seems to be a common misconception that ObjectConnect is a performance enhancement product. It is not and never has been a performance enhancement product.
ObjectConnect was designed to provide a direct migration path between IMPI and RISC systems to eliminate the need for intermediate save files. Whether it uses OptiConnect or Com lines for the link is irrelevant, although it will choose OptiConnect first when it is available. ObjectConnect was continued after the introduction of RISC systems because it has a simple to use (one command SAVRSTxxx) operation.
There are no claims of performance gains to be achieved by using ObjectConnect. While the transfer capability of OptiConnect is quite high, in terms of performance that same level of improvement can not be expected of ObjectConnect just because it is capable of using OptiConnect.
There is an inherent bottleneck in ObjectConnect because it is doing a simultaneous SAVE and RESTORE operation without an intermediate save file (SAVF). Without any intermediate storage, the SAVE operation (transferring data from the source system to the target system across OptiConnect or Com lines) can proceed only as fast as the RESTORE operation on the target system.
Example 1: Using a SAVF with independent SAVxxx and RSTxxx commands:
| 1 | The user issues the SAVLIB command to save a library to a dasd SAVF. Because this is a direct write operation to dasd, the SAVF is created quickly on the dasd. |
| 2 | After the SAVF is created, the user sends it across a Com line via FTP or some other manner to a SAVF on the target system. While transmission rates will vary depending on the link medium, a relatively high transfer rate will probably be seen because the data is being written directly into a SAVF on the target system with little intervening overhead. |
| 3 | After the SAVF is received, the user issues a RSTLIB command on the target system to extract the data from the transmitted SAVF. The actual time for the extraction will vary because the RSTLIB operation must prepare the receiving library, consolidate, and allocate space for each object. However, the user's perception of high data transfer is satisfied because the SAVF has already been sent directly to intermediate storage on the target system before the RSTLIB command is even started. Their measure of performance is how quickly the SAVF moved across the link. |
Example 2: Using ObjectConnect SAVRSTxxx commands (with OptiConnect as the medium):
| 1 | The user issues the SAVRSTLIB command to transfer a library. Because there is no intermediate storage (a SAVF), the actual transfer of the SAV portion of the data on the source system cannot begin until a complete link has been established with the target system. |
| 2 | After the link is established, the data prepared by the SAVLIB operation is sent to the target system using OptiConnect or Com. However, because there is no intermediate storage being used, the transfer of data can occur only one block at a time (limited to 32K). ObjectConnect must wait until the currently transmitted block has been handled on the target machine; in other words, it must be restored with the RSTLIB command on the target system before it can process the next block of data. The reason for this is that there is no place (no SAVF) set aside on the target system to save and "hold" the incoming data until the RSTLIB command is prepared to handle it. |
| 3 | As mentioned in the first scenario, the RSTLIB command must prepare space for the incoming library, consolidate, and allocate space for the new objects contained in the library. The information needed to prepare this space is contained within the blocks of data being sent. Each block that contains data for a new object can result in a delay of the next block being transferred and processed because the RSTLIB command processes the data contained in that block to prepare to receive the new object defined by the block. This, of course, does not impact the data transfer rate when the data has already been received on the target system in the form of a SAVF, but it has a very detrimental effect on the transfer rate when each block is being transferred in conjunction with the RSTxxx command processing. It is this time delay while the RSTxxx command prepares to receive the next object that manifests itself as apparent poor utilization of OptiConnect. While the ability to transfer data across the optical bus is extremely high, the fact that it is actually transferring small blocks of data separated by long time delays between each request depicts this as very low utilization of the bus capability. |
NOTES:
As STRPASTHR uses a passthru server job and not communications entries in a subsystem, It is worth mentioning, if STRPASTHR is working fine, there still may be subsystem problem on the remote system.
If SAVRSTLIB fails with CPF8911 rc 080F6051, Look on the target side for a CPF1269.
As STRPASTHR uses a passthru server job and not communications entries in a subsystem, It is worth mentioning, if STRPASTHR is working fine, there still may be subsystem problem on the remote system.
If SAVRSTLIB fails with CPF8911 rc 080F6051, Look on the target side for a CPF1269.
A common CPF1269 error is as follows:
Target side is logging CPF1269 RC715,0. QCMN is started and contains the correct communications entry, but it's not QCMN logging the CPF1269 RC715 message.
Another subsystem, either QBASE, or user created subsystem has allocated the device, but doesn't contain a valid Communications entries or a Remote Location name entry. Resolution is to either add the relevant subsystem COM or Remote Loc entry to that subsystem, or end the "invalid" subsystem, and vary off/on the APPC controllers on each system.
Device allocation to a subsystem as follows:
1. Specific communications device name with the specific mode from CPF1269.
2. Specific communications device name with *ANY for the mode column.
3. Remote location name entry with the specific mode from CPF1269.
4. Remote location name entry with *ANY for the mode column.
5. *APPC entry under device column with the specific mode from CPF1269.
6. *APPC entry under device column with *ANY for the mode column.
7. *ALL entry under device column with the specific mode from CPF1269.
8. *ALL entry under device column with *ANY for the mode column.
Any changes to a subsystem, relating to device allocation, require that the source and target
controllers are varied off at the same time.
Additional Information
For additional information, refer to the following publication:
Knowledge Center : ObjectConnect function
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CLgAAM","label":"Communications->ObjectConnect"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Version(s)","Line of Business":{"code":"LOB57","label":"Power"}}]
Historical Number
416075044
Was this topic helpful?
Document Information
Modified date:
27 May 2020
UID
nas8N1018989