Need CPSM auto affinity for LOCK/TASK similar to LOCK/UOW that extends the affinity to the entire task.

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

This requirement has been re-evaluated. Looking at current plans, it is not likely that this would be implemented in the next two CICS TS releases, so correspondingly this requirement is being rejected. You have an opportunity to resubmit in eighteen months time if you wish it to be considered then.

The initiating of multiple mirror tasks along with multiple allocations of MRO sessions is unecessary overhead.

Thanks,
Charlie

The creation of unecessary mirror task in multiple AORS along with unecessary allocation of MRO session is just added and unecessart overhead.

Thanks,
Charlie

The creation of unecessary mirror task in multiple AORS along with unecessary allocation of MRO session is just added and unecessart overhead.

Thanks,
Charlie

Hi Charlie - so are you running with MROFSE already? Or are you thinking that this new affinity will have the same effect - the default is that the mirror does not outlive the UOW so there's always a new route selection at the first opportunity in a UOW.

The IPCONN does not come into play here. Our tasks are routed to application regions where the task runs. From there we have processes that route to other application regions for various functions. This is where we run into issues with multiple tasks being spawned across multiple AORs and all of these AORs have DB2 threads. This all means that we are doing a lot of routing requestsas well as task initialization and DB2 thread creation. Some of these functions are very short in duration and the overhead in task initialization and management of the DB2 thread creation can be significant. We could manage these things via the application by putting these functions withing the originating AOR but sometimes this is not our decision to make. The LOCK/UOW works fine for multiple DPL requests to another AOR as long as the originating task does no syncpoints. But if the originating task does syncpoints like it probably should, then we have multiple task initiations and multiple DB2 thread creations. This request simply ask that the LOCK/UOW be extended to the lifetime of the task instead of just the UOW. As long as we are having to route these DPL requests, it seems like it would be more efficient to keep these mirror task active and reuse the same mirror tasks for DPL request for the same task instead of the multiple task creation.

Thanks,
Charlie

The Unit-of-work affinity was a means to prevent the creation of overly complex distributed transactions if routing decisions spread the work across multiple back-ends unnecessarily. This avoided the use of too many sessions and the additional syncpoint flows.

This case sounds a bit different. Mirror tasks will only survive a syncpoint if MROFSE=YES (specified in the SIT of the front-end region) or MIRRORLIFE=TASK (on the IPCONN) are in effect. Otherwise the sessions and the mirrors are freed at syncpoint, and we have the freedom to make new routing decisions in the new unit-of-work.

Affinities are normally seen in a bad light when considering overall efficiency - the freedom to make routing decisions according to current workload is a good thing in general, and having long-lived affinities which inhibit that freedom are bad (in general).

To be honest, I would have much preferred that we hadn't even exposed the UOW affinity as an option - we could have just made routing work to not create complex distributed transactions. Similarly here we have a choice to just infer that re-using an allocated session and mirror that survived the syncpoint due to MROFSE=YES is better than making a new routing decision. BUT it seems to me that the use of MROFSE is more appropriate to a static routing environment (ie non-CPSM WLM) since it's implying assumptions about session usage which seem at odds with a dynamic routing environment. New/different routing decisions were inappropriate within a UOW because they would complicate the syncpoint. Creating an affinity across a syncpoint boundary but within a task, for the case of MROFSE, does not make as much sense to me.

I would welcome your thoughts though.