Access TACB Fields

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Thank you! We don't have CICS/TS 5.2 but we are downloading the CICS/TS 5.2 beta and will use this new feature while testing the beta.

This requirement is satisfied by CICS TS 5.2 which is generally available from June 13th 2014.
The ASSIGN command has been enhanced to provide ERRORMSG and ERRORMSGLEN parameters.

This requirement is satisfied by CICS TS 5.2 which was announced 7th April 2014 with a planned general availability date of June 13th 2014. For more information see the IBM CICS Transaction Server for  z/OS, V5.2 announcement letter

http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS214-107

The ASSIGN command has been enhanced to provide ERRORMSG and ERRORMSGLEN parameters.

This requirement is satisfied by CICS TS 5.2 which was announced 7th April 2014 with a planned general availability date of June 13th 2014. For more information see the IBM CICS Tools for  z/OS, V5.2 announcement letter

http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS214-107

The ASSIGN command has been enhanced to provide ERRORMSG and ERRORMSGLEN parameters.

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status.  Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion.   Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

The way to solve this longer term is to provide an ASSIGN command and the requirement will be marked as a candidate for a future release on that basis. No, access via the TCA is not a supported mechanism. With the re-organisations of the TCA that have taken place during the last few releases of CICS the code that is used to obtain the message from the TACB would almost certainly had to be re-assembled for each release for it to work. In the future I suspect that we are more likely to change TCAPCACB to a 64-bit address then remove it from the TCA. If this were to happen the assembler code would have to change.

Actually what I really need is access to the error message provided back to the TOR after a DPL link. I wanted to use the session TIOA but it is freemained before the application gets control back. The only "supported" place where I have found this message is in the TACB, hence this requirement. I'd like to reword this requirement as follows:

1) Provide the error message sent back from the AOR to the DPL requester. The error message can be the same message available in the session tioa, for example:
DFHAC2001 05/17/2012 12:08:47 TCISDT31 Transaction 'xxxx' is not recognized. Check that the transaction name is correct.
DFHAC2033 12:18:23 TCISDT31 You are not authorized to use transaction XM48. Check that the transaction name is correct.

The message can be provided similar to what is done with an EXCI link request (RETCODE), or as another option on the DPL LINK (RETMSG), or as an option on an ASSIGN command that we execute after a DPL link error.


2) If this message is only available in the TACB, then we would want a supported method to access the TACB. If using field TCAPCACB is considered a supported method and will continue to be supported, then I have no problem continuing to use it to get access to the TACB fields. If at some point in the future you decide to remove this ability, then I would like to have an API instead. We are only using the first TACB, and we are only using the message field.


Here's the code we use today:
* Check if there is a TACB
DFHKERN FUNCTION=INQUIRE_TASK,TCAADDRESS=R15,STACK_AVAIL=NO
USING DFHTCADS,R15
ICM R3,B'1111',TCAPCACB R3=> TACB
DROP R15
JZ REQERR00 None, exit
USING DFHABND,R3
CLC ABNDSAAL(4),=CL4'TACB' Valid tacb?
JNE REQERR00 No, just exit
TM ABNDIMSG,ABNDMSGI Is there a message?
JNO REQERR00 No, exit
* MVCL using ABNDMLEN and ABNDAMSG

Please can you clarify what is being requested. Is a a pointer to the TACB or just the message within the TACB ? I think we would be reluctant to return the TACB put specific fields via commands like assign could be possible. Are there other fields besides the message? Are you interested in just the first TACB, or do you chain through TACBs ?

I vote yes.