As with each IBM Mainframe announcement, the IBM Z15 server is no stranger to innovative features. This article gives a perspective on two exciting features of IBM’s latest mainframe technology, the IBM Z15.
The first feature is known as Compression Acceleration and made possible by way of a new on-chip accelerator known as the Nest Acceleration Unit or NXU. The NXU is the functional replacement of a formerly priced feature known as the zEDC (Enterprise Data Compression). This means the zEDC adapters you may have invested in on prior mainframe servers will not carry forward; the NXU will become the functional replacement of that capability. That is actually a good thing! An image of the NXU is found in Figure 1, complements of IBM.
FIGURE 1: Nest Acceleration Unit on the Z15
Figure 1 reveals the IBM Z15 chip with twelve (12) cores listed; cores are your processor. That which is circled in red is the NXU, the NXU is shared by all processor cores on the chip. Unlike the zEDC Feature that was restricted in use by up to 15 LPARs, the NXU can be shared by all LPARs on the server, up to 85.
When you compare the two features, you soon realize the raw compression throughput possible on the zEDC is 1 GB/second per zEDC adapter. Prior Z System servers allowed you to purchase up to 16 adapters per server, providing an architectural throughput rate of 16 GB/second. The actual rate on those cards is ½ that value, in that for every card you placed into production, you invested in a backup card just in case the primary card failed. The raw thruput of the NXU is 26 GB per Z15 core. Based on IBM benchmarks, the largest IBM Z15 with this integrated compression accelerator compresses up to 260 GB per second1.
Mainframe clients use this feature to compress large files. Doing so actually reduces the amount of time spent moving data via I/O operations and that, in turn, lowers their IBM Software Costs. Not a bad trade-off when you think about it and the feature is a no-cost part of the Z15 server now.
System Recovery Boost
The second feature is known as System Recovery Boost. This feature offers faster system shutdown, restart and workload catchup. Instant Recovery is an alternate name for this offering.
System Recovery Boost is where the operating system brings on an additional capacity to speed up OS Shutdown, OS Restart and the catch up of work that may be queued due to the scheduled or unscheduled outage. System Recovery Boost is capable of taking your sub-capacity General Purpose CPs and run them at full speed. This is known as a Speed Boost.
System Recovery Boost is even capable of allowing General Purpose workload to run on zIIP engines. This is known as a zIIP Boost and provides additional capacity and parallelism to accelerate processing during the boost periods. IBM refers to this as blurring the CPs and zIIPs together.
Find out more about this capacity from IBM at System Recovery Boost and through the IBM z15 Redpiece.
Understanding Sub-capacity CP Speed Boost
IBM’s Speed Boost only applies to sub-capacity Servers, e.g. 4xx, 5xx and 6xx models. Client LPARs that are running in a boost period access their engines as 7xx models. Other remaining LPARs on the same server run at their sub-capacity setting as purchased by the client. By way of example, consider Figure 2.
FIGURE 2: Speed Boost example.
Looking at the preceding figure, when LPARs enter a boost period, work that is dispatched from LPiD3 runs at CP7 (full capacity). Other LPARs continue to be dispatched at CP5 (sub-capacity). One boost period is started at LPiD3 shutdown and a new boost period started at re-IPL of LPiD3.
Now, you might be asking “How does the operating system know you are shutting down LPiD3 and the shutdown boost period of thirty (30) minutes should start?” It’s quite simple. Operations staff will issue a START command against Started Procedure IEASDBS (Shut Down Boost Start).
Upon re-IPL of LPiD3, Boost would be “On by Default” for that image, offering up sixty (60) minutes of boosted capacity to get the operating system and subsystems up along with allowing workload to continue processing at an accelerated pace for the duration of the Boost period.
Understanding zIIP capacity Boost (zIIP Boost)
For those familiar with this platform, you know that zIIPs traditionally only host DRDA, IPSec and IBM Db2 Utility workloads along with Non-IBM Software solutions that have chosen to leverage the zIIP API. During System Recovery Boost, if you have at least 1 zIIP engine available to the LPAR, it can run both traditional zIIP only eligible workload as well as General Purpose CP Workload. Earlier in this article, IBM dubbed this capability CP Blurring. Just like Speed Boost, zIIP Boost will last thirty (30) minutes on shutdown and sixty (60) minutes on restart.
So, What run’s on the zIIP during the Boost Period? The short answer – Any Program!2
Understanding zIIP Turbo Boost
Unlike IBM’s System Recovery Boost, which is a no-charge feature. The zIIP Turbo Boost is a priced feature consisting of:
- FC 9930 a no charge entitlement feature code.
- FC 6802, a temporary pre-paid zIIP boost records, effectively providing to you on an annual basis 20 additional zIIP engines that you can activate during Boost Periods. You are allowed to activate this feature up to thirty (30) times per year.
What is vital is you must remember to activate the boost record (FC 6802) before your boost event (shutdown and subsequent restart). In addition, you must have at least one zIIP already online to the LPAR that will be boosted.
When you are planning out how many physical zIIPs you will add to your server out of the maximum 20, and how many reserved zIIPs you will define, Evolving Solutions recommends that you work with us. We will use an IBM supplied tool to better understand the impact on your server and the LPAR topology when you add the additional physical zIIPs.
This same tool will even warn you if adding the additional physical zIIPs may cause an LPAR to cross a drawer boundary on a CPC that could lead to performance irregularities. Weights can be adjusted if you know about them in advance to ensure this exposure is mitigated.
Platform positioning is pretty straight forward. First, you must invest in a Z15 processor and you were going to do that anyway. At the same time, you must be running on either z/OS V2R3 or V2R4 with the following APARs applied: OA57849 (z/OS), OA57552(CPM), OA57478 (CIM), and OA56683(RMF). The latter can be easily positioned beforehand as you will be installing Device Support maintenance.
For zIIP Boost, you also need to have one or more zIIPs defined in the Image Activation Profile, either as initial or reserved processors, have physical zIIPs installed, have HiperDispatch enabled (defaults “on”), and be running with shared, not dedicated processors. Pretty straight forward for those that know this platform.
Initial System Setup
As mentioned earlier in this article, System Recovery Boost is enabled by default and can be controlled via the BOOST= parameter in your IEASYSxx parmlib member. The z/OS V2R4 Initialization and Tuning Reference has been updated to reflect this new keyword, see Figure 3.
FIGURE 3: BOOST keyword in IEASYSxx
You should also review the Image Profile Settings for those LPARs that will be boosted, looking to ensure at least one (2) zIIPs is available and the weights you have specified are reasonable. Keep in mind that any RESERVED CPs and/or zIIPS that are also physically available on the processor will be brought online automatically as part of the Boost Period and take back offline automatically at the conclusion of the Boost period.
Lastly, you must update your LPAR Shutdown Procedures to include “START IEASDBS” at the start of the shutdown process.
IBM has introduced a new operator command, “DISPLAY IPLINFO, BOOST”. This command tells you what the BOOST System Parameter specification for the LPAR. Also, you can go to the HMC and double-click on the Image Details Panel. When you do, you see a new value: System Recovery Boost: On|OFF.
There are also a pair of new Catalog Procedures. Earlier in this article, we told you about IEASDBS (Shut Down Boost Start). There is also IEABE (Boost End) if you want to end the boost period early for some reason. These would be placed in the appropriate PROCLIB concatenation on your system.
It comes as no surprise, there are automation considerations. For example, at this URL: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izsb100/sysrb_automationconsiderations.htm there are several new messages to consider.
Two messages are worth calling out in this article, message IEA676I and IEA678I. Both signal the end of the Boost period. What automation changes might you consider? Consider this shortlist for starters:
- Activating your purchased zIIP Turbo Boost Temporary Capacity Record before shut down, and then deactivating it after the boost period is complete.
- Dynamically changing LPAR weights as required during a shutdown or startup boost, to avoid Vertical Low zIIPS.
- Add the starting of the IEASDBS proc to your existing shutdown automation.
- Changing the level of parallelism present in the workload at startup and shutdown. The odds are high your automation solution paces these activities today; with Boost, more parallelism will be desired.
IBM has also published a very information System Recovery White Paper. When you study the credits on this white paper, you quickly realize the authors are the Who’s Who from IBM Poughkeepsie that genuinely know this platform!
A couple of key takeaways:
- IBM System Recovery Boost will benefit IPL and those clients that are sub-capacity. Once the Operating System switches, both Speed and zIIP boost will benefit clients.
- During IPL, remember the boost period is for sixty minutes. You should make sure Boost is focused on meaningful activities. One example of the wrong activity is known as IPL Device Enumeration. Excessive time spent on this activity means less time in support of workload catchup.
- The White Paper goes further by recommending a classic Redbook to reconsider, the publication number is SG24-7816-00 and centers on Z Systems shutdown and restart resiliency.
- System Recovery Boost will significantly reduce the time required to shut down z/OS Images. At the same time, your Restart process is greatly improved especially when zIIP engines are present.
- From an Evolving Solutions perspective, justifying software currency for your enterprise is a bit easier in that rolling IPL’s for maintenance changes complete much faster with this capability.
- IBM’s zIIP Boost and Turbo Boost are worth evaluating as well. Consider for a moment that a zIIP costs approximately 145K per year with Maintenance. The 3-year cost for the Turbo Boost will be $500K, the 3-year cost of 20 zIIPs is $3M. The odds are high you can find $ ½M USD worth of value by investing in the Turbo Boost feature.
If you are interested in learning more about the IBM Z15 server, or even consider Platform Services that promote software currency, feel free to reach out to the author via LinkedIn or send the author an email at Jim.F@evolvingsol.com . For more on Evolving Solutions mainframe services here.
1 IBM z15 On Chip Compression
2 See IBM’s zIIP Authorized Use Table for a description on what workload is allowed to run on zIIP processors ftp://public.dhe.ibm.com/systems/support/warranty/pdfs/aut/Authorized_Use_Table_09-2019_en_US.pdf