As one more example, VSAM enjoys a 64-bit buffer pool when you configure a monoplex or multiplex with a Coupling Facility, even if you're not otherwise taking advantage of VSAM Record Level Sharing (RLS) features. With a 64-bit buffer pool you could see VSAM-related performance improvements even in the "simplest" environment with a single z/OS instance.
However, to oversimplify slightly, the biggest, broadest category of business benefits when implementing at least one Coupling Facility (even on the same physical machine) is that a CF opens up myriad opportunities to reduce or eliminate both planned and unplanned service interruptions.(*) Even the most basic CF configuration, a z/OS monoplex with a CF, is enough to run VSAM RLS and/or Transactional VSAM (DFSMStvs), for example. Those technologies make it possible for multiple batch and online transactional programs to access the same VSAM files concurrently, and that means reducing or eliminating distinctions between "nighttime" and "daytime" so that online systems can continue processing user requests (from the Internet, mobile devices, etc.) around the clock instead of just during "online hours." Do you need to reduce or eliminate both planned and unplanned service interruptions? That threshold question should not be considered in isolation, by the way. I've seen many customers who think the answer is "no," but then, sometimes even without the IT department's knowledge, they have elaborate but "clunky" caching, message holding, file holding, and other workarounds surrounding their core application and information systems. That's just bad architecture, very expensive, and at least awkward for the business users. I should also point out that everybody with a z/OS license should be able to implement one or more CFs any time they wish without even contacting IBM. If you're running z/OS you have general purpose processors (CPs), and CPs can run anything including the Coupling Facility control code provided with every IBM z System machine at no additional charge. Especially with CF thin interrupts enabled (recommended), you can forge ahead, now -- and assuming also you can allocate a bit of memory to a CF LPAR. Your z/OS license also includes many, many CF exploiters, and I cannot think of any occasion when IBM's license doesn't include CF exploitation. (A very few non-IBM software vendors require an additional license for their CF exploiters.) If the exploitation technically exists, you should be licensed for it already. However, if your CF workloads are "non-trivial," it is financially prudent (though not technically required) to invest in one or more CF engines (ICFs) to run your CF instance(s) instead of using your CP capacity. You do not need cabling unless you're adding a physically separate machine. The connections on the same machine are via IC links. Server Time Protocol (STP) is optional, though I recommend STP for just about everyone with or without a CF. It wouldn't be surprising, Gadi, if you have a score or more of z/OS and middleware technologies that could exploit a CF. Exactly which ones you turn on, and why, and in support of which particular business application services, will vary, of course. (*) In the recent past there was also often a financial benefit if you implemented at least one CF. At least one CF was a prerequisite if (a) you had two or more physical machines, (b) you ran workloads on two or more machines during normal operations, (c) those machines were physically located "close enough" to form a Parallel Sysplex, and (d) you wanted to take advantage of aggregated Sysplex software pricing. However, this year (2015) IBM introduced Country Multiple Pricing (CMP). The Sysplex aggregation rules no longer apply if you switch to CMP. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
