Mainframe Performance Topics Podcast Episode 33 “These Boots Were Made”

I hope you can tell that Marna and I had a lot of fun making this episode.

I can’t recall which of us came up with the cultural reference. But it sort of developed – until the aftershow was sort of inevitable.

Anyhow here are the show notes for Episode 33. The podcast series is here and on all good podcasting services.

Episode 33 “These Boots Were Made” long show notes.

This episode is about our Mainframe Topic.

Since our last episode, Martin was at the Munich Z Resiliency Conference, and IntelliMagic zAcademy Where Are All The Performance Analysts? – A Mainframe Roundtable.

What’s New

• Preliminary 3.1 upgrade materials can be found in APAR OA63269 . Another APAR will be done closer to GA.

• Python 3.11 zIIP enablement, for certain modules only, up to 70%. This is available back to z/OS V2.4 with APAR OA63406 and PH52983.

Mainframe – z/OS Validated Boot

• This function is only on latest hardware and software: z/OS V2.5 or later, IBM z16 A01 or A02 May 2023 microcode level and another follow-on level.

• The point is to ensure IPLs are from known, unmodified, validated in-scope artefacts, so that you can initiate a system with known objects. This is needed for Common Criteria Evaluation.

• Good for an organisation concerned about security.

• Two pieces to the solution: Front end and back end.

1. Front-End first:

   • Sign in-scope IPL time artefacts, done by the customer with their own private key.

     • You could choose to do this at an initial product install: Eg z/OS 2.5 -> 3.1. Note that z/OSMF workflows delivered with ServerPac can help.

     • Note z/OS V2.5 is requirement for driving system.

     • Also you would need to do this signing post-PTF installation, as applying PTFs leads to artifacts becoming unsigned.

     • You can sign now and validate later, as this portion does not have a requirement on the IBM z16 HW.

     • The Certificate you signed with, needs to be exported (via RACF, for instance), which will have the public key in it.

     • The in-scope artifacts that must be signed for z/OS Validated Boot is: IPL text, nucleus, standalone dump text, LPA.

     • A helpful utility IEAVBPRT can be used to report on what in a data set has been signed or not. Use this as possibly a best practice after applying maintenance, before IPL with Audit.

2. Now Back-End:

   • Signatures validated during IPL time , and this is when you have the IBM z16 HW requirement. You must import the certificate (from the Front-End) into the IBM z16 HMC.

   • IPL time has additional requirements:

     • IPL with CLPA. CLPA is building the Link Pack Areas in virtual memory. CLPA enforced for Validated Boot IPL.

     • LPAR has to have Virtual Flash Memory. Specific requirement for Validated Boot is to allow PLPA to page to somewhere secure. You might have other users of VFM, so size for both. Probably other users are much larger.

   • You have a choice of IPL type: CCW and List Directed.

     • Channel Command Word (CCW) has been around forever. A CCW IPL is compatible with signed load modules.

     • List Directed (LD) is new. This type of IPL does signature validation in two modes: Audit and Enforce.

       • Audit is used just for reporting.

       • Enforce is used for validation and potential failure. Failure is one of a few wait states with a message. Wait state indicates the first problem.

     • Do an Audit first, fix any problems, then do Enforce. Go round the loop when applying maintenance.

• You need to revise IPL procedures, in particular deciding when to do Audit versus Enforce. Reminder: Maintenance would bias you towards Audit followed by Enforce. Be careful when selecting mode for an emergency IPL.

Performance – Db2 Open Data Sets

• Follows on from Episode 32 Performance Topic – which we’ll call Part 1. This time we don’t have Scott Ballentine with us. Recall he’s a z/OS developer and here in Part 2 we’re concentrating on Db2.

• In Part 1 we were talking about physical Open and Close. That is Open data sets as z/OS would see it.

• Db2 has an additional notion of logically Open and Closed data sets. We’ll discuss both in this follow up topic. And try to keep them straight.

Physical Open And Close

• If a data set is needed – for the portion of an index space or table space – the Db2 transaction will experience a delay if the underlying data set is physically closed. To minimise this Db2 uses a deferred close process – keeping data sets open beyond end of use. It also minimises the CPU used for opening and closing data sets by keeping a pool of them open.

• Of course, as mentioned in Part 1, a lot of this is about managing the virtual storage for the open data sets

• The DSMAX Db2 subsystem parameter was mentioned in Part 1. It controls the number of physically open data sets for the subsystem. When DSMAX is approached Db2 starts physically closing data sets. First, page sets or objects that are defined with the CLOSE YES option are closed. The least recently used page sets are closed first. When more data sets must be closed, Db2 next closes page sets or partitions for objects that are defined with the CLOSE NO option. The least recently used CLOSE NO data sets are closed first.

• Db2 Statistics Trace documents the number of open data sets and the open and close activity. So you can see if your DSMAX is set sufficiently high. But, as we saw in Part 1, virtual storage comes into play and ultimately limits what a safe DSMAX value would be.

• Two recent APARs are of interest: PH33238 and PH27493. In addition to the CLOSE YES vs CLOSE NO distinction, Data sets opened exclusively for Utility access will be pre-emptively closed after 10 minutes and will be at the front of the queue to be closed when DSMAX is approached. Fixes for both APARs are required for this to work right.

Logical Open And Close

• Usually known as Pseudoclose – is a switch from R/W to R/O. It’s not a physical close at all.

• Its main role is to manage inter-Db2 read/write interest, for Datasharing efficiency purposes; It’s expensive to go in and out of Group Buffer Pool (GBP) dependency.

• When there is at least one updater and maybe one reader there is read/write interest and Db2 has to do more work in Datasharing. While flipping in and out of Inter-Db2 read/write is not a great idea there is an efficiency gain in dropping out of this state judiciously.

• Two Db2 subsystem parameters have traditionally been used to control pseudoclose: PCLOSET and PCLOSEN. “T” for Time and “N” for number of checkpoints. PCLOSEN is gone in V12 with APAR PH28280, as part of a DSNZPARM simplification effort. (DSNZPARM is the general term for subsystem-level parameters.) So PCLOSET would need adjusting down to whatever mimics PCLOSEN – in anticipation of this APAR or V13.

• Sidebar: Putting Db2 maintenance on is an inevitability. Another example if this is the changed Db2 DDF High Performance DBATs’ behaviour.

Open Data Set Conclusion

• So we have two different concepts for Db2: Physical open & close. And logical open and close aka Pseudoclose.

• And you’ll note the interplay – at least for physical open and close – between z/OS and Db2. Hence the Part 1 – primarily z/OS. And this Part 2 – primarily Db2.

Topics – Messing With Digital Electronics

• Martin had discussed his various Raspberry Pi efforts, mainly for software. But note he uses breadboards for his electronics projects as his soldering has become atrocious.

• Martin has used various commercial input devices before:

  • Streamdecks (lots of them!). Started off with 6 button Mini. Then 15 button Stream Deck, then 32 button XL.

    • Now Stream Deck Plus, with 4 knobs and only 8 buttons.

    • But he doesn’t have the Stream Deck Pedal – so not playing with a full deck. 😀

  • Xencelabs Quick Keys. This is portable, with only one knob.

• All rather expensive, but at this point a sunk cost, and is most of what he uses “In Production”.

• But then there was interest in building his own input devices.

  • Some things he’s not interested in building his own: keyboards, mice, touch screens and voice assistants. (There is a community of people who do like to build their own keyboards.)

  • However, interested in other things that trigger actions. Action which might be simple, or might be complex, automations.

• At Christmas, got a Pi Hut Maker Advent Calendar, which was pretty cheap.

  • 12 projects, one per day. From very simple to quite complex, driven by Raspberry Pi Pico.

    • Raspberry Pi Pico is not a computer – like Pi. It is a microcontroller

    • Microcontroller has a runtime but no operating system that we’d recognise

    • You load in a Micropython or CircuitPython interpreter or you standalone C program

    • Pico W is a wifi variant – and highly recommended as it’s only slightly more expensive than the non-wifi variant.

  • Lots of digital and analogue inputs and outputs, and under $10.

• Then Martin bought a Pico W. which was also under $10. It has Wifi, and now has Bluetooth support. Still no soldering required – as he buys the “H” (pre-soldered headers) variant.

• First actual project – with Pico W

  • RFID cards kick off automations. Tap on RFID detector with credit card sized card. Actual credit cards usually work.

    • On iOS with Shortcuts via Pushcut. Creates a new Drafts draft with a date and time stamp for meeting notes

    • On Mac OS via Keyboard Maestro. This automation opens apps and arranges them on his second screen.

    • Both these are Swiss Army knife affairs for building automations. Above automations were just a proof of concept – but they are used regularly as they have inherent value to Martin.

• Second project – with Pico W

  • Using Rotary Encoders, otherwise known as twirly knobs, but not the same as a potentiometer or “pot”.

  • They’re good for adjusting things like font sizes – as opposed to push buttons, which aren’t.

  • Difficult to program but there are samples on the web. Martin only did this project to prove it could work.

  • There was a lesson in the importance of physical considerations: He had some trouble fitting into a plastic case he bought – because of the clearance above the Pico W and below the rotary encoders.

• Third project – with Adafruit Macropad

  • It’s a kit comprising a Pico plus light up keypad plus small status screen plus a twirly knob. It acts as a Human Interface Device (HID). (The USB standard divides devices into mass storage devices and human interface devices, plus more obscure device classes.)

  • Uses CircuitPython – as that has HID support and MicroPython doesn’t yet. (It’s not difficult to convert code between these two python variants.)

  • Automated a bunch of functions of his personal Mac Studio. With his programming each key lights up when pressed, and the small OLED screen says what the function is.

  • At present the twirly knob just moves the text cursor in his text editor. (BBEdit and Sublime Text but any text field would work the same.)

• Most of the projects were just for fun, and there was a lot of fun in it.

  • Some practical stuff: Text automation, RFID to kick off stuff, e.g. a “good morning” routine.

  • There is lots of potential for practical applications, and as a hobby it’s pretty cheap. So is open source software. And the field is evolving fast. For example, Pico W just got Bluetooth support without new hardware.

Out and about

• Marna will be at SHARE New Orleans,the week of August 14th, and is waiting to hear about IBM TechXchange week of September 11, 2023.

• Martin (and Marna) will be at the GSE UK Annual Conference – Oct 30th – Nov 2nd, 2023.

On the blog

• Marna has published these blogs since the last podcast episode:

  • Sign Of Times

  • How a z/OS Portable Software Instance can help you prepare for the “front end” of z/OS Validated Boot

• Martin has published these blogs since the last podcast episode:

  • Like You Know?

  • CF LPARs In The GCP Pool?

  • Reporting For Duty?

So It Goes