Diagnosing link problems

Turn traces on for the appropriate lines from either the IMS master terminal or, if you are using type-2 commands, from the Operations Manager (OM) API. Trace all terminals on a line.

For example, use either of the following commands:

/TRACE SET ON LEVEL 4 MODULE ALL LINK or UPDATE MSLINK NAME(linkname|linkname*|*) START(TRACE)
Note: The type-2 command UPDATE MSLINK NAME(linkname) START(TRACE) uses the same level and module settings that were used the last time the /TRACE SET (ON) LINK command was issued. If a /TRACE SET (ON) LINK command has not been issued since the last cold start, this command defaults to MODULE=ALL and LEVEL=4.
/TRACE SET OFF LINK x or UPDATE MSLINK NAME(linkname) STOP(TRACE)

Two report types are generated:

Summary: Contains the average response time, in milliseconds (msec), of the total number of send and receive data values for each link trace.
Detail: Contains the individual response times, in milliseconds (msec), for every send and receive data value for each MSC link that has been traced.

The formatting of this record is available only if the IMS input log contains X'6701' records that are generated by the /TRACE SET ON LINK command or the type-2 command UPDATE MSLINK NAME(linkname).

For diagnosing link problems, the trace records with the following identifiers are helpful.

AM01 RECEIPT OF DATA FROM PARTNER SYSTEM

This entry is invoked because the link is stopped (using either the /PSTOP command, the UPDATE MSLINK linkname STOP command, or because of an I/O error.

Assemble a copy of DFSADSCT and refer to the BUFMS DSECT in the listing.

I TP BUF: Contains the segments received.
BUFTFLAG: Indicates more about what was received (that is, first segment).
O TP BUF: Contains the data set last sent to the partner.
Q BUF: Contains the segments received so far.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

AM02 ERROR - CHECK LAST OUTPUT OPERATION

I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

AM03 MSC ANALYZER 'WHAT NEXT'

If this entry is invoked from a device-dependent module, it is because the device-dependent module has nothing else to do.

Example: EOT received to ACK. Neither side sending; therefore, let the analyzer decide what to do.

Example: A data block containing only the message prefix was received (no segment could fit in the remaining buffer space). The device-dependent module goes to AM03 because there might be output that can be sent. Data response to data is okay.

If this entry is invoked from another analyzer entry point, it is because that function is complete.

Example: After the dequeue of an output message, ENTRY 6 goes to AM03 to see if more output can be initiated.

CLBCNTQB: Is a QCB for a destination that has messages queued to be sent across the link.
CLB3INP and/or CTBAINP: Indicates that the device-dependent module is not able to send any output data.
CTBAERR: Indicates that an error message is to be sent to the partner.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

AM05 MSC ANALYZER ENTRY 5

This entry is invoked from the device-dependent module to send a message.

O TP BUF: Contains the data last sent to the partner.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

AM06 LAST OUTPUT OPERATION SUCCESSFUL

This entry is invoked from the device-dependent module when the previous output was successful.

CTBAEOM=1: Indicates that the previous output included the last piece of the message, and that the message is to be dequeued.
CTBAEOM=0: Indicates that the last piece of the message has not been sent. No dequeue is to take place. The device-dependent module is dispatched at DM01 to attempt to continue transmitting.

AM08 CANCEL MESSAGE ENQUEUE OPERATION

There is a probable contention situation, and this partner must yield. The output message in progress is returned (washed back) to the queues to be sent later.

O TP BUF: Contains the data that the device-dependent module was attempting to transmit.

AM09 GENERATE AN ERROR MESSAGE

I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

AM10 LINK SHUTDOWN: OPERATOR INTERVENTION REQUIRED

This entry is invoked because the link is PSTOPPED (either using the /PSTOP command, the UPDATE MSLINK NAME(linkname) STOP(COMM) command, or because of an I/O error). Find the previous device-dependent module interrupt entry (DM02, DM04 or DM07) to determine why the device-dependent module went to AM10.

General cleanup is performed: Queue buffers and I/O buffers are released.

AM12 NORMAL 'LINK IDLE' CONDITION

This entry is invoked when the device-dependent module has nothing else to do under normal conditions.

Example: MTM link is attention driven. There is no outstanding READ as with BSC. When the device-dependent module has no more data to send and no pending acknowledgment, it becomes idle to wait for a POST by either the enqueue of output or an attention from the partner. This entry is different from AM10 because the analyzer does not complete a general cleanup.

CM00 GET A WORK BUFFER

This analyzer entry is called when the device-dependent module needs additional space to perform message editing. An example is the collecting of all pieces of a SPA.

CM01 REPOSITION QUEUE BUFFER

This analyzer entry is called when the device-dependent module wants to ensure that the queue buffer is in storage. This entry is currently not used.

CM02 GET NEXT

This analyzer entry is called when the device-dependent module needs the next output segment of a message.

CM03 DEQUEUE MESSAGE

This analyzer entry is called when the device-dependent module wants to dequeue a message (rather than let the analyzer do it). An example is the emergency restart of a link. The device-dependent modules exchange message sequence numbers. If one device-dependent module determines that a message in its queues has already been received by the partner, the message is dequeued to prevent it from being sent twice.

CM04 WASH OUTPUT MESSAGE

This analyzer entry is called when the device-dependent module wants to return an in-process message to the queues. An example is a permanent I/O error. The device-dependent module washes any output in progress and is sent again after the error recovery sequence completes.

CM05 DETERMINE IF QUEUED OUTPUT IS PRESENT ON A LINK

This analyzer entry is called when it must be determined if there is any (more) queued output to be sent across the link emergency restart processing. If one device-dependent module determines that a message in its queue has already been received by the partner, the device-dependent module issues a get unique (GU) call (for positioning) followed by a DEQUEUE (CM03) to get rid of the message.

CM06 GET NEW MESSAGE

The system issues a get unique (GU) call to get a new output message.

CM07 FREE INPUT QUEUE BUFFER

This analyzer entry is called when the device-dependent module wants to cancel an input queue buffer. An example is permanent I/O error. The device-dependent module discards all input segments that, up to the point of failure, have been collected in queue buffers. The message is lost on this system, and the ABORT sequence sent to the partner tells the partner that the message must be sent again later.

CM08 FREE A WORK BUFFER

This analyzer entry is called when the device-dependent module wants to free an extra work buffer. This entry is currently not used because the buffer mentioned in the CM00 description is automatically freed by the analyzer.

CM09 GET A PREFIX/WORK BUFFER

The system obtains a prefix or work buffer.

CM10 FREE A PREFIX/WORK BUFFER

The system frees a prefix or work buffer.

CM11 QUEUE ERROR

The system processes a QMGR message queue error and issues message DFS082.

CM12 GLOBAL WASH

The system issues a CANCEL OUTPUT call to clear the global queue in a shared-queues environment.

CM13 INSERT MESSAGE

The system inserts an input message to the message queue.

CM14 ENQUEUE A MESSAGE

The system enqueues an input message to the message queue.

CM15 REREAD MESSAGE

The system reads an output message from the shared queues again.

CM16 GET MESSAGE BY DRRN

The system gets the message with the specified device relative record number (DRRN).

CM17 GET LINK INPUT/OUTPUT BUFFERS

The system obtains link I/O buffers.

CM18 FREE LINK INPUT/OUTPUT BUFFERS

The system frees link I/O buffers.

DM01 WRITE SETUP

The device-dependent module is entered here when the MSC analyzer finds output to be sent and the link is available (CLB3INP off).

Assemble a copy of DFSADSCT and refer to the BUFMS DSECT in the listing.

Q BUF: Contains the segments to be sent.
O TP BUF: Contains the data stream ready to be sent.
I TP BUF: Contains any data received from the partner.

DM02 WRITE INTERRUPT

The device-dependent module is entered here at the completion of a logical write operation.

DECSDECB: Contains the completion code.
BUFTYPE: Contains more information about the type of completion (MTM).
O TP BUF: Contains the data stream sent to the partner.
I TP BUF: Contains any data received from the partner.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

DM03 READ SETUP

The device-dependent module is entered here when the MSC analyzer determines there is no output that can be sent. MTM and CTC are attention driven, and no I/O is initiated here.

DM04 READ INTERRUPT

The device-dependent module is entered here at the completion of a logical read operation.

DECSDECB: Contains completion code.
BUFTYPE: Contains more information about the type of completion (MTM).
DECTYPE: Indicates the type of the last operation.
I TP BUF: Contains the data just read.
O TP BUF: Contains any data sent to the partner in response to a previous read completion.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

DM07 RESTART

The device-dependent module is entered here from the MSC analyzer whenever the link is not active (CRB1ACT is not equal to X'11').

DECTYPE: Indicates the type of the last operation attempted.
DECSDECB: If I/O is completed, this indicates status.
I TP BUF: Contains the last data read.
O TP BUF: Contains the data to write or the data last written.
I WP BUF: Contains the MSC prefix/work buffer.
O WP BUF: Contains the MSC prefix/work buffer.

DM0I ENTRY TO ACCESS METHOD

This record is traced at entry to the access method from the device-dependent module.

DECTYPE: Indicates the type of operation.
O TP BUF: If output, contains data to be written.