(Originally posted 2007-10-13.)
APAR OA21635 is one of a rare breed: A change to the thresholds for z/OS’s automatic CF Request conversion. (I’m told this has only happened once before.)
If you recall z/OS Release 2 (in 2001) introduced a very nice function that automatically converts Coupling Facility requests from Sync to Async, based on thresholds. The purpose of this is to minimise the CPU cost for a coupled z/OS system, while still providing reasonable request response times:
- With a synchronous request the requesting z/OS CPU (engine) actively spins, waiting for the request to complete. So a longer request service time would lead to a higher CPU cost for the coupled z/OS system.
- With an asynchronous request the requester does not spin. But the response time is longer.
When I say response time I mean CF request response time, which may have little to do with actual application response times. But the two aren’t totally divorced.
(Requests that were originally Async don’t get converted to Sync, by the way.)
The big change came, as I say, in z/OS Release 2 where XES introduced a new algorithm, measuring response times and, based on thresholds, deciding whether to convert Sync requests to Async. This measurement is not done for every request, but rather once in a while. So we don’t have “nervous kitten” syndrome here. 🙂 I like algorithms that are responsive. I don’t like algorithms that are overly jumpy.
So, back to the thresholds:
Technology changes, so it’s appropriate to revisit the thresholds from time to time. APAR OA21635 is a result of this. To quote Development:
The synch/asynch thresholds have been recalibrated to better reflect current z/OS and processor technology. After installing the APAR, installations may see some asynchronous CF activity shift back to synchronous operations resulting in slightly improved performance for applications sensitive to these CF operations.
What you’ll see when you install this PTF varies, depending on your situation:
- For requests using an IC link – obviously to the same-footprint – nothing’s going to change as all requests are going to be Sync unless the request was explicitly Async. Requests using an ICB link (to a nearby footprint are probably broadly similar.
- For long-distance requests again nothing’s likely to change as the new thresholds would again suggest Async conversion as the norm.
- For middle-distance (say less than 2km) links (ISC) there may be some change: More requests are likely to go Sync rather than Async. For some customers this category has been of concern. The shift in thresholds is meant to address it.
An interesting game I like to play is to compare request types to “local” and “remote” CFs, particularly with Duplexing. And, obviously, the response times seen. The simple case is without duplexing where “local” requesters get Sync requests in the main – at perhaps less than 50ms. And “remote” requesters get essentially Async requests, with a much higher response time, especially at distance.
Distance discussions are well informed by such analysis. As are Duplexing discussions. Which is, perhaps, the essential “take home” message of this post.
When implementing the threshold changes I would form a view of such things before and after applying the PTF. And I’d be interested to know how well it worked for you.
And remember there’s nothing essentially good or bad about Sync or Async. It all depends on whether the behaviour is appropriate for your scenario.
But I’m pleased that, once in a while, the thresholds are revisited. So I think this is a good APAR.