Allow Association data to pass named areas to allow multiple applications to use association data.

Whilst this requirement is valid, based on our current plans and priorities, it is not likely that this could be implemented in the next 12 months, or in the next CICS TS release. Correspondingly this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Update: We've taken the step to add a DFHTRANSACTION container and write a TRUE syncpoint exit in the remote CICS regions to get the container and issue an EMP call. We had a problem with the DFHTRANSACTION container because our primary application had commareas over 30k, which caused an abend after we added DFHTRANSACTION, so we had to back it out of production. We're still waiting until we can put it back, but after we do, we'll enable the TRUE exit in the remote regions that we're trying to track. So, as I said below, it's a solution, but a long way around. Ideally, we can identify a User EMP as being "origin like", so that it moves with the origin data. Or I can steal a field like DFHAPPL that moves automatically. My current plan is to use DFHAPPL and split my 10 byte field into two parms (4 bytes and 6 bytes) because that's how DFHAPPL is architected. Another solution is to increase DFHAPPL, or provide another DFHAPPL like field for our use.

Update: We've taken the step to add a DFHTRANSACTION container and write a TRUE syncpoint exit in the remote CICS regions to get the container and issue an EMP call. We had a problem with the DFHTRANSACTION container because our primary application had commareas over 30k, which caused an abend after we added DFHTRANSACTION, so we had to back it out of production. We're still waiting until we can put it back, but after we do, we'll enable the TRUE exit in the remote regions that we're trying to track. So, as I said below, it's a solution, but a long way around. Ideally, we can identify a User EMP as being "origin like", so that it moves with the origin data. Or I can steal a field like DFHAPPL that moves automatically. My current plan is to use DFHAPPL and split my 10 byte field into two parms (4 bytes and 6 bytes) because that's how DFHAPPL is architected. Another solution is to increase DFHAPPL, or provide another DFHAPPL like field for our use.

I'm not the originator of this requirement and my needs are probably different, but since I expressed interest, here's my two cents.. The requirement for us is to write this data to SMF. Putting it into DFHTRANSACTION means we need a means to read the container and write to a user EMP in every region where these transactions run. So DFHTRANSACTION will work, but it's not the ideal solution.

I think, if I understand the request correctly, the DFHTRANSACTION channel allows this capability.
The DFHTRANSACTION channel can be created in XPI functions as well as programs.
It also goes from region to region in DPLs irrespective of whether they are channel or commarea based.
Note however if region to region capability is required, the DFHTRANSACTION channel must have been created in the first region.

Woul this satisfy your requirement ?

I have the same requirement. We have data that is passed in an HTTP header that we would like to "stamp" into all 110 records that are spawned (CWXN to CWBA, DPL link to AOR, possible other DPL links). I tried to use XAPADMGR but it was invoked too early in CWXN to have access to HTTP fields. With the new optimized task structure (bypassing CWXN), the CWBA task is directly invoked and XAPADMGR is able to access HTTP fields, so I'm able to populate the adapter user correlation field and that will be carried to all systems and is accessible by INQUIRE ASSOCIATION. The problem for us is that we still need CWXN for some messages, so we still need an alternative. For now, I'm writing a DFHTRANSACTION container with the data I want to pass, and plan to write an exit (like XPCRES) to get the container and then issue a monitor to push the data to SMF in each remote region. If/when applications also need this data, they can issue their own GET CONTAINER.