Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

I need some advice for an CICS ATCV abend

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging
View previous topic :: :: View next topic  
Author Message
zOS_Uber_Geek

New User


Joined: 29 Sep 2006
Posts: 4
Location: Van Buren, AR

PostPosted: Fri Sep 29, 2006 4:12 am    Post subject: I need some advice for an CICS ATCV abend
Reply with quote

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:

-------------------------------------------------------------------------------------

@PEP001E S231-SCFTT229 TERM=102T CODE=ATCV ABEND :CICS0001-TCP00013

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.

zOS_Uber_Geek icon_pray.gif
Back to top
View user's profile Send private message

UmeySan

Active Member


Joined: 22 Aug 2006
Posts: 755
Location: Germany

PostPosted: Fri Sep 29, 2006 1:51 pm    Post subject:
Reply with quote

Hi there !


First of all:

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.


Regards, UmeySan
Back to top
View user's profile Send private message
zOS_Uber_Geek

New User


Joined: 29 Sep 2006
Posts: 4
Location: Van Buren, AR

PostPosted: Fri Sep 29, 2006 5:33 pm    Post subject: Thanks for the help
Reply with quote

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?

Thanks

sterb050.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Date and time format in CICS Chandru3183 CICS 2 Sat Mar 18, 2017 12:46 pm
No new posts IMS region inactive - User abend code... gthmrj IMS DB/DC 5 Tue Mar 07, 2017 12:29 pm
No new posts Asynchronous CICS Processing Question moezbud CICS 0 Mon Mar 06, 2017 6:13 pm
No new posts CICS Question RE: Browse, Readnext an... moezbud CICS 7 Sun Mar 05, 2017 5:45 am
No new posts how to send just 10 rows in a CICS sc... Megha Gupta CICS 5 Thu Feb 23, 2017 6:57 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us