Joined: 29 Sep 2006 Posts: 4 Location: Van Buren, AR
At work we have been getting a lot of ATCV abends lately. From what I've read, this type of abend is a communication error and can be caused by the user closing their emulator while a task is still running, rather than wait for the task to complete and logoff properly. I have checked the offset where the error has been occurring in different programs, and they all point to SEND MAP. Here is the information on one of these ATCV errors:
CEE3250C The system or user abend ATCV was issued. From compile unit SCFTT229 at entry point SCFTT229 at
compile unit offset +0000683A at address 108E4ACA.
CEE3DMP V2 R10.0: Condition processing resulted in the unhandled condition. 09/28/06 3:57:11 PM
DFHAC2236 09/28/06 15:57:12 CICS0001 Transaction S231 abend ATCV in program SCFTT229 term 102T backout
successful.
DFHZC2467 E 09/28/06 15:57:12 CICS0001 102T CSNE Invalid communications ID (CID) detected. VTAM
RETURN CODE 1413 ((1)
Module name: DFHZLEX)
-------------------------------------------------------------------------------------
If anyone has any ideas on how to handle this error, that would be great. I thought about adding a RESP option to the SEND MAP command and then checking the response code, but I'm not sure which response code to check for. Also, is there a way to test the terminal signal, before issuing the SEND MAP command? Thanks in advance.
An application attempted an operation on a logical unit, but was not in the correct mode. Reason coul be:
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 empted
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.
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.
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/ESA Distributed Transaction Programming Guide,
where rules for the correct use of commands are given.
Then correct the application.
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.
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.
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/ESA
Diagnosis 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/ESA Distributed Transaction Programming Guide, and reference to this Guide should reveal the programming error.
Involved Modules are DFHETL, DFHZARQ, DFHZISP
For testing the terminal, you could issue an EXEC CICS INQUIRE command.
Joined: 29 Sep 2006 Posts: 4 Location: Van Buren, AR
I left out the following line of information by mistake:
DFHDU0207I 09/28/06 15:57:12 CICS0001 Transaction and system dumps for dumpcode: ATCV were suppressed by the DUMP TABLE
OPTION FOR THIS DUMPCODE.
This information goes above the DFHAC2236 line.
I also found the following ABEND code: ABEND code: C1E3C3E5 Reason code: 40404040
I will check out the EXEC CICS INQUIRE command and see if I can used that.
I did not see any of the DFH modules listed in my error messages. For instance, I do not see a DFHETL module. Where do I look to find out which DFH module issued the error message?
