IBM Mainframe Forum

by **mandor** » Thu Aug 23, 2012 6:09 pm

Hello!

Short question EXCI call Batch_CICS with NOSYNCONRETURN returns EXCI-DPL-RESP = 16 and EXCI-DPL-RESP2 = 21 - WHY?
With SyncOnReturn works fine.

Long version:
I have a problem with External CICS Interface call from batch.
We are calling the CICS transaction with

Select all

CALL 'DFHXCIS' USING VERSION-1
EXCI-RETURN-CODE
BLINE-USER-TOKEN
DPL-REQUEST
BLINE-PIPE-TOKEN
BLINE-TARGET-PROGRAM
BLINE-DFHCOMMAREA
BLINE-COMM-LENGTH
BLINE-DATA-LENGTH
BLINE-TARGET-TRANSID
NULL-PTR
NULL-PTR
EXCI-DPL-RETAREA
NOSYNCONRETURN

We get EXCI-DPL-RESP = 16 and EXCI-DPL-RESP2 = 21.
I can't find the reason code.
Here I see some strange codes none of which are 2.digit.
http://publib.boulder.ibm.com/infocente ... fhtmfb.htm

Thank you!

by **Robert Sample** » Thu Aug 23, 2012 6:31 pm

What your code calls EXCI-RETURN-CODE is supposed to be defined as (from the External Interfaces Guide manual):

3.2.9 Return area for the EXCI CALL interface

The format of the 5-word return area for the EXCI CALL interface is as follows:

1-word response field.

1-word reason field.

Two 1-word subreason fields--subreason field-1 and subreason field-2.

1-word CICS message pointer field. This is zero if there is no message present. If a message is present, this field contains the address of the storage area containing the message, which is formatted as follows:

A 2-byte LL field. LL is the length of the message plus the length of the LLBB field.

A 2-byte BB field, set to binary zero.

A variable length field containing the text of the message.

so you should be able to find the reason code pretty easily by displaying the second field in EXCI-RETURN-CODE -- that will tell you more about why your CALL did not work.

by **mandor** » Mon Aug 27, 2012 3:52 pm

OK, now I know why it didn't work. We had an old exci version in our libraries.

BUT, we have another problem.
What we do is, insert a record in a batch program and we call existing CICS transaction which is part of a CICS application. The CICS transaction then wants to update this record inserted in batch. We thought the solution was to control the unit-of-work from batch.
We get the -911 (deadlock) sqlcode. Is there something missing or those managars don't communicate.

I read this, not sure what should i try.
http://publib.boulder.ibm.com/infocente ... c0063.html

by **dick scherrer** » Mon Aug 27, 2012 9:10 pm

Hello,

You need to post your new question in the DB2 part of the forum. . .

I suspect the batch job still has the row(s) locked.

IBM Mainframe Forum

EXCI reason codes for response 16

EXCI reason codes for response 16

Re: EXCI reason codes for response 16

Re: EXCI reason codes for response 16

Re: EXCI reason codes for response 16