A very slow train coming, due to Marna’s and my commitments. But, again, I’d rather prepare well for when we do record. I think this one – as usual – says exactly what we mean to say.
I’m hoping you’ll listen to the aftershow; It’s more of a bonus topic really. This one is about the modern podcasting environment. At least the bits about podcast clients might provide some useful tips.
Enjoy! And, as always, feedback is appreciated.
Episode 37 “Watts Up?” – Long Show Notes
“Manual Of The Moment” is really “Webpage Of The Moment”: Java dependencies for z/OS elements and components, the location where we are documenting all our Java dependencies and changes, including the move to Semeru 25. Good to have it consolidated.
Under “What’s New”: z17 ME2 / MER Single Frame & Rack Mount (9176) GA August 12 with the usual 3 FIXCATs.
Mainframe – Item in z/OS 3.2 Announcement
Six enhancements to System Recovery Boost (SRB) in OA66837:
- Add to message IEA687I the following: procname, step-ID, and jobstep-program-name for middleware startup boosts. Displayed after recovery process boost start (IEA675I and/or IEA681I) and recovery process boost extend (IEA686I).
- Add to SMF record type 90 subtype 40 the following: Boost start and end timestamps, timezone and leap-second offsets, and procname, step-ID, and jobstep-program-name for middleware startup boosts.
- Add to SMF record type 89 the recovery process boost total duration for the life of the IPL (cumulative / “so far”, in both Subtype 1 and 2).
- Transient zIIP: When configuring a transient (boost) zIIP online via a CONFIG CPU|CORE command, result in the zIIP becoming a normal online zIIP, which will remain online after the end of the boost period.
- Provide a new API to allow a program to identify transient (online) zIIPs.
- Provide infrastructure for a new Recovery Process Boost for Dynamic I/O Activate.
Dynamic I/O Activate Processing as a new RP Boost:
- We now have 8 recovery process boosts on z16 & z17 (up from 4 on z15). This one is only on z16 and z17.
- Basis of use: with certain internal criteria, for larger I/O changes, on systems with few processors.
- Duration: Intended duration is 2 minutes; total recovery process boost in a day is limited to 30 minutes per LPAR.
- Reminder boosts: Speed & zIIP.
- Typical scenarios: IODF changes, adding devices, deleting devices, changing attributes of devices (e.g. onlining).
Also available for z/OS 3.1.
Performance – z17 Sustainability Metrics
Power consumption supported by z/OS Data Gatherer (PTFs for 3.1, built into 3.2; z/VM also collects these statistics):
- SMF 70-1 CPU Control Section: Info available at both Machine and LPAR levels.
- Machine level: Infrastructure (e.g. fans), Unassigned (resources xnot deployed to any LPAR), and Total (LPAR total obtained by subtracting the other two).
- LPAR level: CPU (no distinction between GCP and zIIP), Memory, and I/O.
- Need to pro-rate to get workload level (CPU easy, Memory and I/O more difficult).
- CPU Control Section LPAR fields only relate to this LPAR. Collect data from all z/OS LPARs; subtracting known LPARs from total LPARs rolls up other LPARs (including Coupling Facility LPARs), but cannot break down into CPU, Memory, and I/O.
- Early observations: LPAR consumption is largely driven by CPU (varies by CPU used, measured at chip level). Memory and I/O power consumption are relatively small. Substantial non-LPAR power consumption (infrastructure).
- Presentation with John Baker: “Modern Machines, Modern Metrics” covers Martin’s evolving experience.
- Power outside the CEC (e.g. network, disk) is not part of this.
Topics – Restarting things
Discussion on when and why systems and middleware restart, and how long they take to warm up:
- IPLs (planned vs unplanned): Planned IPLs usually follow a set schedule for maintenance (should not need therapeutic IPLs; Rare nowadays for Daylight Savings). Unplanned IPLs are usually driven by security maintenance. Plan carefully to avoid workload peaks and “warming up” effects.
- Middleware restarts: Forced at IPL (Db2, MQ, IMS usually start soon after IPL), middleware maintenance (RSUs, Db2 function levels), or application requirements (cycling CICS or IMS regions around batch windows to pick up new dataset versions). Modern middleware and z/OS reduce the need for habitual restarts.
- Performance point of view: Settling down after a restart (“mature IPL” / “mature Db2” vs “warming up”). Buffer pools maturing can take weeks; thread populations establish quicker. Memory usage increases and levels off, application performance settles down (visible in Db2 Accounting Trace).
- System Programmer point of view: Opportunity to change configuration, exploit new functions, or prepare for upcoming service refreshes.
- Instrumentation:
- IPL time: SMF 70-1 documented field (SMF70_IPL_TIME in TOD format, GMT); SMF 30 Master Scheduler Reader Start Time.
- Middleware: Reader Start Time and Stop Time in SMF 30 across address spaces (TCP/IP, VTAM, JES2, SMSVSAM, Data Gatherer, Db2, IRLM, MQ, IMS, CICS). Gantt charting starts/stops reveals architectural patterns and quiescing periods.
- Sysplex restarts do not necessarily mean a service outage.
Customer requirements
Satisfied on 16 October, 2025:
- SECINT in RECEIVE ORDER: automated access to IBM Z Security Portal HOLDDATA needed
- Over 10-year-old requirement, one of the highest voted requirements in z/OS!
- Delivers SECINT information to you if you are permitted to the IBM and LinuxONE Security Portal. Not z/OS release sensitive.
On the blog
Martin’s recent blog posts:
- Mainframe:
- Performance:
- Topics:
Marna’s recent blog posts:
- Sneak Peek: Simplification changes on the horizon
- Another cup of coffee (Java)
- Never give up hope: Automat(able) acquisition of SMP/E SECINT information arrives
- Calling out for all configs!
- You CAN take it with you!
So It Goes
Mainframe, Performance, Topics 