content_image/993125.jpg
GLYPH<SM590000> On the z/OS side: 

– CF signal is received by a shared-engine z/OS image (arrival of a List Notification signal). 

– An asynchronous CF operation completes. 

The interrupt causes the receiving partition to be dispatched by an LPAR, if it is not dispatched. This process allows the request, signal, or request completion to be recognized and processed in a more timely manner. 

After the image is dispatched, “poll for work” lo gic in CFCC and z/OS can be used largely as is to locate and process the work. The new interrupt expedites the redispatching of the partition. 

LPAR presents these Coupling Thin Interrupts to the guest partition; therefore, CFCC and z/OS both require interrupt handler support that can deal with them. CFCC also changes to relinquish control of the processor when all available pending work is exhausted, or when the LPAR undispatches it off the shared processor, whichever comes first. 

## CF processor combinations 

A CF image can have one of the following combinations that are defined in the image profile: 

GLYPH<SM590000> Dedicated ICFs 

GLYPH<SM590000> Shared ICFs 

GLYPH<SM590000> Dedicated CPs 

GLYPH<SM590000> Shared CPs 

Shared ICFs add flexibility. However, running only with shared coupling facility PUs (ICFs or CPs) is not a preferable production configuration. It is preferable for a production CF to operate by using dedicated ICFs. With CFCC Level 19 (and later; z14 ZR1 servers run CFCC level 22), Coupling Thin Interrupts are available, and dedicated engines continue to be recommended to obtain the best coupling facility performance. 

The CPC on the left side of Figure 3-9 has two environments that are defined (production and test), and each has one z/OS and one coupling facility image. The coupling facility images share an ICF. 

<img src='content_image/993125.jpg'>

