content_image/993110.jpg
– 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” logic 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, so 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. 

In Figure 3-13, the CPC on the left 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/993110.jpg'>

The LPAR processing weights are used to define how much processor capacity each CF image can include. The capped option can also be set for a test CF image to protect the production environment. 

