Also, when a latch is released, the specific latch’s latch waiter queue is used to transfer  ownership of the latch directly to the next request in line (or multiple requests, in the case  of a shared latch), and make that task (or tasks) ready to run, with the transferred latch  already held. No possibility of any unfairness or “cutters” in  line between the time the latch  is released versus when is reobtained. For managing latches properly for structures that are System-Managed (SM) synchronous  duplexing, it is now important for the CF to understand which of the duplexed pair of  requests operates as the “master” versus “slave” from a latching perspective, requiring  more SM duplexing setup information from z/OS z/OS XCF/XES toleration APAR support for z15 is required to provide this enhancement. When a z/OS system IPLs, message paths are supposed to be deactivated by using  system reset, and their SYIDs are supposed to be cleared in the process. During the IPL,  z/OS then reactivates the message paths with a new SYID that represents the new  instance of z/OS that is using the paths. On rare occasions, a message path might not be deactivated during system reset or IPL  processing, which leaves the message path active with the z/OS image’s OLD,  now-obsolete SYID. Because the path erroneously remained active, z/OS does not see  any need to reactivate it with a new, correct SYID. From the CF’s perspective, the incorrect SYID  persists, and prevents delivery of signals to  the z/OS image that is using that message path.  With z15, CFCC provides a new resiliency mechanism that transparently recovers for this  “missing” message path deactivate (if and when that situation ever occurs). The CF provides more information to z/OS about every message path that appears active;  namely, the current SYID with which the message path is registered in the CF. Whenever  z/OS interrogates the state of the message paths to the CF, z/OS checks this SYID  information for currency and correctness. If an obsolete or incorrect SYID exists in the  message path for any reason, z/OS performs the following steps: This enhancement requires z/OS XCF/XES exploitation APAR support for z15. The CF operates with the following Dynamic Dispatching (DYNDISP) models: Chapter 3. Central processor complex design  119 – DYNDISP=THIN: An interrupt-driven model in which the CF processor is dispatched in  response to a set of events that generate Thin Interrupts and runs until it runs out of  things to do, then gives up control voluntarily (until the next interrupt causes it to get  dispatched again). This model is the most efficient sharing, best shared-engine  performance. – DYNDISP=ON: An optimization over pure LPAR timeslicing, in which the CFCC code  judiciously sets timer interrupts to give LPAR initiative to redispatch it, and the CF  sometimes voluntarily gives up control of the shared processor when it runs out of work  to do. The result is more efficient sharing, better shared-engine performance. This  setting is the default setting for CF LPAR running on z15. – DYNDISP=OFF: LPAR time-s licing completely controls the CF processor; the  processor polls the entire time it is dispatched by LPAR, and it is idle (not dispatched)  when undispatched by LPAR. The result is least efficient sharing, worst shared-engine  performance. GLYPH<SM590000> Shared-Engine CF Default is changed to “DYNDISP=THIN” ii. Reactivates the message path with the correct SYID for the current z/OS image to  seamlessly correct the problem i. Requests non-disruptive gathering of diagnostic information for the affected  message paths and CF image GLYPH<SM590000> Message Path SYID Resiliency Enhancement