Mainframe Performance Topics Podcast Episode 18 "What We Won't Have In Common Anymore" (Mainframe Performance Topics with Martin Packer)

Mainframe Performance Topics Podcast Episode 18 "What We Won't Have In Common Anymore"

MartinPacker Visits (2319)

”… And then two come along at once.”

Unlike Billboards or London Buses, only two here folks.

So, we had ideas (and somehow time) to record two episodes almost back to back. So we did.

But we have no chance of recording together for a while, sadly. Which is a bit of a shame as we have quite a lot we could talk about. Maybe some of mine will come out in other ways. After all it’s been quite a busy few weeks, bloggingwise. The really neglected medium has been screencasting, but I have an idea for something to do with video. ANd a little time on my hands.

Anyhow, I hope you enjoy this episode.

Episode 18 “What we won’t have in common anymore”

Here are the show notes for Episode 18 “What we won’t have in common anymore”. The show is called this because our Mainframe topic is about some removals in common storage planned for the release after z/OS V2.3.

Where we’ve been

This episode was completed right after Episode 17, so we haven’t been anywhere special:

Marna has been to home and to the office. Several times.
Martin has been travelling up and down stairs a lot.

Mainframe

Our “Mainframe” topic discusses a future planned removal coming in the release after z/OS V2.3.

Four items actually form what we’ve titled “User Key In Common Storage Removal”. This has been outlined in a Statement of Direction, and is documented in the z/OS V2.3 Migration Workflow and book.
1. ALLOWUSERKEYCSA in DIAGxx will be treated as NO.
2. Removal of support for obtaining User Key CSA
3. Can’t change ESQA storage to User Key
4. Can’t create a SCOPE=COMMON Dataspace in User Key.
New capabilities with OA53355, which is at z/OS 2.1 and above:
1. SMF 30 has been enhanced to identify jobs/steps that use user key common storage. There is a new set of bits whose names begin with SMF30_USERKEY*, specific to each disallowed item after z/OS V2.3.
2. SLIP Trap Capability. Single slip trap covering the removed items. Provides relief from “not multiple PER Type SLIPs” constraint.
3. A new z/OS Health Checker for z/OS health check, ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM. Issues an exception message when use of user key common storage is detected.
An important point is that when this happens CICS users will have to be at CICS V5.2 or later. CICS V5.1 will be out of service by that time, on July 1, 2019. Laggard regions will need to be upgraded. The SMF 30 record’s Usage Data Section helps you - across your estate - check CICS levels. (Product Version is correctly filled in for CICS regions.)

Performance

Martin talked about what’s in a data set name and this topic is about getting insight by parsing data set names. His reporting code, which processes SMF 14 (OPEN for read) and SMF 15 (OPEN for write) records, bolds data set qualifiers (or segment names) if they match any of a bunch of criteria. Now, new criteria have been added to investigating data set names.

The purpose of bolding in the reporting is to alert the specialist and the customer to significant portions of a data set name.

Previously, the only criterion was job name, which most notably show up in temporary data sets.

Also previously, the code played formatting games with GDG generations - converting to relative generations - and listed all the generations seen in each running of the job.

The new criteria are job step name, dates (in lots of formats), job step program name, “SORT” in the qualifier, and system SMFID.

While the code doesn’t see “partner” job names (for instance, where one writes to a data set and the partner reads from the data set),
those could be detected using the Life Of A Data Set (LOADS) technique, which we can talk about more one day.

And surely there will be more interesting finds in other customers’ data set names. As they are stumbled upon the code can be enhanced to learn these new tricks - as Martin refactored it to make it easier to add new criteria.

For example, in the “real life” example in the cited blog post (What’s In A Name? - Revisited) “PR” might very well mean production. and the low level qualifier “T1700” might or might not mean a time. These he considers tenuous parsings right now.

Topics

Our podcast “Topics” topic is about two cheap and fun pieces of hardware Martin has been playing with: Raspberry Pi and Arduino

Arduino is more hardware oriented. It is an open source hardware board. It is a microcontroller you download small programs to from e.g. a PC, written in a flavour of C. It is optimised for driving electronics, e.g. on a breadboard (which you can plug components into) and boards you plug into the top of the Arduino (called shields).

Martin has three Arduino shields: An SD Card reader/writer, a 7-segment display, and graphical LCD display.
Raspberry Pi is more for software. It is a small cheap computer on a card.

Martin’s has 4 USB ports, HDMI, Ethernet, Wifi, and runs Raspbian (a flavour of Linux (Debian)). You can run other builds. He bought an HDMI monitor for it (HP 27es).

He also found a Logitech K780 keyboard and a Logitech M720 mouse. Both of these can be switched instantaneously between 3 computers, connected via Bluetooth or USB. They can be used with Windows or Linux or Mac, and others.
Spending on accessories can add up considerably, with three shields, and lots of electronic components. He had to work out how a switch worked, for example, bringing him back to his youth. Resistor bands came back to him quickly. Soldering was difficult then and now . Martin considered electronics to be more like following recipes. One learning point is he was more interested in software in his youth. He cut his “assembler teeth” programming the Z80 processor then (in the early 1980s). Also the Z80 support chips - PIO, SIO, CTC etc. His first computer was a Z80-based Amstrad CPC 464.) Raspberry Pi fits the bill now.
He hasn’t discovered many practical uses. But it’s something to practice things like SSH with. However, it’s feasible to run “jobs” on the Raspberry Pi, “submitted” from iOS that can’t actually run on iOS.
Raspberry Pi has captured Martin’s heart more than Arduino, but he’s intrigued at the idea of combining the two.