WTO from CICS Event Processing adapter

We have assessed this requirement. We have no current plans for this to be implemented and so 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.

I believe this is something that many customers could benefit from this capability and most will want to avoid the need for more code to maintain. Even though it would be very straightforward coding, it would still be yet another artifact of customization needing to be maintained.

Using the TS model expirations as a comparison, practically every shop had to create their own version several decades before IBM provided the capability. Then, the customers that are excited to get rid of custom code (like us!) need to migrate to IBM's implementation. Simply having a migration creates the risk of bumps in the road, just like keeping the custom version is a risk by virtue of being something to support that may break long after the primary implementers have retired.

This is going to be especially pertinent as less experienced sysprogs are expected to provide support at a quicker pace of change. Additionally, this support will grow in value as additional event types become supported.

Having you considered to following ways to achieve this:
1) Write a XMEOUT GLUE to re-route the msg to console. Needs assembler skill but should work for all CICS messages sent to a TDQ

2) Use the existing MESSAGE system rule together with a very simple user written start transaction adapter. User could easily code a rule for each message they are interested and define the EVENT action for the rule. The specified EP Adapter would be configured to start a user task to get the CICS container that contains the first 1024 bytes of a CICS /CPSM message text (as emitted by ME domain) and write it to the console using an EXEC CICS WRITE OPERATOR command. The EXEC CICS WRITE OPERATOR command already supports messages up to 690 characters which are split into multiple line WTO's when message greater than 113 characters (see https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/reference/commands-api/dfhp4_writeoperator.html).

There are two existing ways to achieving this:
1) Write a XMEOUT GLUE to re-route the msg to console. Needs assembler skill but should work for all CICS messages sent to a TDQ

2) Use the existing MESSAGE system rule together with a very simple user written start transaction adapter. User could easily code a rule for each message they are interested and define the EVENT action for the rule. The specified EP Adapter would be configured to start a user task to get the CICS container that contains the first 1024 bytes of a CICS /CPSM message text (as emitted by ME domain) and write it to the console using an EXEC CICS WRITE OPERATOR command. The EXEC CICS WRITE OPERATOR command already supports messages up to 690 characters which are split into multiple line WTO's when message greater than 113 characters (see https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/reference/commands-api/dfhp4_writeoperator.html).