ATCV

Explanation

An application attempted an operation on a logical unit, but was not in the correct mode for one of the following reasons:

  1. When issued by DFHZARQ, CICS cannot perform the current request because another request is outstanding (EIBSYNC is set). This holds for APPC or non-APPC systems

  2. When issued by DFHETL, the application is communicating with an APPC system, and is not in the correct state to perform the attempted operation. This holds for APPC systems only

  3. When issued by DFHZISP, a TCTTE free was requested, and there is an outstanding sync point request. This holds for non-APPC systems only

  4. When issued by DFHZISP, a TCTTE free was requested, the TCTTE is in receive mode, and RAQ=NO was specified in the installed profile definition. This holds for non-APPC systems only.

System action

The transaction is abnormally terminated with a CICS transaction dump.

User response

The response depends on the reason for the error as follows:

  1. Issue a sync point and then issue the request.

  2. Issue the free request and reallocate the session.

  3. Either change the application to issue receives until EIBRECV is not set, or specify RAQ=YES in the installed profile definition. (If you specify RAQ=YES in the installed profile definition, ensure that all input messages are read before the transaction is terminated.)

  4. See the CICS documentation where rules for the correct use of commands are given. Then correct the application.

The application program has attempted an operation on a logical unit that is invalid, because the program's current status on the session with that logical unit does not permit it. An investigation of the TCTTE (that is, Session), status bytes, and TCA type of request bytes will reveal which of the above problems are relevant.

When the cause of the problem has been ascertained, the application program should be changed to ensure that the session-oriented information is acted upon before any further requests are sent across that session. The session status information is made available to the application program in the exec interface block (EIB) immediately following the execution of RECEIVE, CONVERSE, or RETRIEVE requests across the session. The relevant bytes must be tested, strictly in the order shown, and acted upon, before any further operations are attempted on the session. In addition, the status information bytes themselves are necessarily volatile in that they are reset before the execution of every EXEC CICS... statement. Thus it is good programming practice to save them into application user storage after a RECEIVE, CONVERSE, or RETRIEVE for later testing. The states are:

1. EIBSYNC

the application must take a syncpoint

2. EIBFREE

the application must free the session (or terminate when the session will be freed automatically)

3. EIBRECV

the application must continue receiving data by issuing further RECEIVE commands; by definition, data cannot be sent while in this state.

Some of these status tests can sometimes be omitted (for example, testing of the EIBSYNC status is not essential if it is known that the application program on the remote system never issues sync point requests itself). However, the tests should always be carried out, particularly if the remote application might be amended at a future date, in which event the session handling logic may well be altered. Also, it may be that the remote transaction itself causes an unsuspected flow on the session. For example, if the remote program issues EXEC CICS SEND..... LAST across the session, followed by RETURN, a syncpoint request (RQD2) will be added onto the transmitted data. (The application programmer is referred to the CICS documentation for a discussion of this topic). As a result of this addition, an unsuspected syncpoint request is received by the local application, which abend if the session is freed without the sync point request being honored.

Note:

An ATCV abend is also raised by module DFHETL if a state error occurs during processing of an APPC mapped application (that is, the program attempts to perform an operation while in the wrong state). The handling of APPC mapped applications is described in the CICS Diagnostics reference. Some commands are processed by DFHZARQ, as above, and others by various other modules invoked by DFHETL. Rules for using commands for APPC are given in the CICS documentation. Reference to this guide should reveal the programming error.

Problem determination

Register 12 addresses the current TCA. Register 10 and field TCAFCAAA address TCTTE. The terminal byte TCTTECRE has bit TCTEUCOM (X'02') set if sync point is required, and TCTEUFRT (X'04') set if Free Session is required; TCTESMDI has TCTEUSMD (X'02') set if the application is in SEND mode. TCTERCVI has TCTEURCV (X'01') set if the application is in RECEIVE mode. Bit TCTESRAQ (X'80') in byte TCTEIRAQ indicates that read-ahead queuing is coded on the installed profile definition for this transaction.

The type-of-request bits in the TCA are set as follows:

  • TCATPOS1 TCATPIS (X'01') Signal requested.

    • TCATPFRE (X'03') Free TCTTE.

  • TCATPOS2 TCATPORR (X'10') Receive requested.

    • TCATPOWR (X'01') Send requested.

Analysis: 



Number   Label     Description


DFHZARQ
1.       TCZAQW8   Attempting to receive
                   when sync point or Free
                   Session outstanding.
2.       TCZAQ2W   Attempting to send while
                   in receive mode.
3.       ZARQNOPG  Issuing SIGNAL while in
                   send mode.

DFHZISP
4.       ZISPVTCK  Attempting to free session
                   while sync point request is
                   outstanding.

Module

DFHETL, DFHZARQ, DFHZISP