Allow update to origin data (User Correlation Data) via a call in addition to XAPADMGR

Support for this is provided via a new SET ASSOCIATION USERCORRDATA command in CICS TS 6.1 which is generally available from 17th June 2022.

For more information see https://www.ibm.com/docs/en/cics-ts/6.1?topic=whats-new

Support for this is provided via a new SET ASSOCIATION USERCORRDATA command in CICS TS 6.1 which is announced today April 5th and will GA June 17th 2022.

See Announcement letter https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS222-092/index.html&request_locale=en

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.

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.

With CICS/TS 5.3, I am able to use the XPI SET TRANSACTION TRACKING flag to record that a transaction is MOBILE, so this support is a great first step - thank you! Ideally we would like to record the origin device type header field, so that we store the actual device with SMF, such as "APPLE", "ANDROID", or with IOT, devices like "TOASTER" and "FITBIT". So we still have a need for this requirement to store character data as part of Origin Data.

Another solution is to write a DFHTRANSACTION container that has the appropriate headers, and allow a down stream AOR task to read the container and use a MONITOR command to write this data to SMF. We could use a SYNCPOINT TRUE, but I'm not sure if DFHTRANSACTION is available to that TRUE? Without a SYNCPOINT TRUE, we could be missing data for tasks that issue multiple syncpoints.

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

Please note that with CICS/TS 5.3 and single transaction support, we may need to eliminate the analyzer program, so that could affect any solution expecting to use the analyzer to set the value. Another good use of this enhancement would be to identify via SMF those transactions that are eligible for mobile pricing. We plan to pass the device type as one of the HTTP headers, and that could be stored via this technique as well.

- Assuming we would implement this in our analyzer programs, the API we use is the Wbra_Request_header_ptr address, and then we parse through each header field.

- Yes, our analyzer currently does exactly that - extracts the header fields and issues a MONITOR command to write the contents of the headers to a user EMP. We've thought about passing a container, but that's difficult for a number of reasons. For one, some applications pass data via commarea, so we can't pass a commarea and container at the same time. Also, we would need an exit program on the other side of the mirror to get the container and issue the MONITOR, in each AOR/FOR that the AOR connects to. We are also concerned about the overhead because we would need to add this processing to virutally every task.

- Updating all associated tasks in the TOR and AOR, so starting with CWXN, then CWBA, then the DPL AOR mirror, then any DPL task associated with the AOR mirror (FOR, other AORs, etc.).

Thank you!
Mike Giaquinto

The requirements is understood, however, it would be good to clarify a few issues
- What API is being used to extract the HTTP header information, is it the WEB READ HTTPHEADER command?
- Has the use of the monitor COMMAND been investigated to add additional user fields to the monitoring records, perhaps with a specific container to flow the information to the AOR
- Does the requirement include updating all associated tasks in the TOR and AOR with the extracted metadata, or just the tasks in the AOR?