Mainframe Performance Topics Podcast Episode 34 “Homeward Bound”

We started planning this one quite a while ago. Thankfully our topics tend to be evergreen – in that they’re still topical for quite a while. In that vein I know we are gaining new listeners and they aren’t all starting with the latest episode.

Anyway, our schedules have been their usual hectic selves – but in a good way.

Actually, recording happened over quite a short timespan – when we got to it.

So, enjoy!

Episode 34 “Homeward Bound” long show notes.

This episode is about our Performance Topic.

Since our last episode, Martin was in Istanbul twice, Copenhagan, and Nottingham. Martin and Marna were both in GSE UK, which was the best GSE UK ever! Marna was in GSE Germany, which was also a fabulous event with a great technical agenda.

Mainframe – z/OSMF Software Management UUID

• What it is:

  • Knowing what SMP/E CSI “covers” a specific active z/OS system hasn’t been possible, at least in any official programmatic way. This information is always just known by the z/OS System Programmer, usually by having naming standards. Making it not automatic, and so not robust.

  • In z/OS 3.1, we now have the capability to correlate a UUID with a running z/OS system, which can then programmatically retrieve the SMP/E CSI which represents the running system when used as directed.

• UUID details:

  • Universally Unique Identifier. Sometimes known as Globally Unique Identifier (GUID)

  • A long string of hex digits, separated by dashes, which is actually a 128-bit label. Usually in 8-4-4-4-12 format.

  • Always unique by design. Doesn’t use a central registration authority and no coordination between parties.

• Requirement to use this capability:

  • This function is limited to the z/OS operating system Software Instance only. Separately deployed program products and middleware are not applicable. Only for z/OS because we know an LPAR or VM guest can only have one operating system.

  • You must have an SMP/E CSI that accurately reflects your z/OS system in the first place. If you have no SMP/E CSI that is specific to that running z/OS system, this capability is not applicable. We’ve always strongly recommended that you deploy z/OS with its own CSI so that you always have an accurate CSI that represents what was deployed!

  • You must install a provided usermod during deployment, which contains the UUID. We’ll provide the SMP/E usermod and UUID when using z/OSMF Software Management, with the PostDeploy Workflow. That usermod leads to UUID being in LPA.

• Some practical things:

  • Re-deployment, with a different CSI would mean the UUID must be updated. For example, from Test into Production. Otherwise we have a “ringer”.

  • You must be using z/OSMF Software Management to generate the Software Instance UUID. z/OS 3.1 z/OSMF Software Management will go through your inventory and automatically assign UUIDs.

  • z/OSMF Software Management keeps track of the UUID-Software Instance, which then gives us the CSI(s).

• Value of using the new function:

  • For any programmatic usage to find out what is installed on the running system, with confidence. REST API used to retrieve UUID as part of a JSON response. Also displayable with a D IPLINFO command.

  • Use the UUID in z/OSMF Software Management queries. These REST APIs return JSON, which is widely understood, and able to used by popular modern programming languages such as python, node.js, PHP, Go, PERL, etc.

  • Ties very nicely by finding active z/OS system information in a software inventory that has a lot of inactive software. It’s a solution to an age old problem.

Performance – Engineering Part Umpteen – Logical Processor Home Addresses

• Marna and Martin likely already talked about home addresses and SMF 99 Subtype 14. This is a continuation of that discussion.

• Logical Processor Home Addresses are the LPAR’s preferred physical location for a specific logical processor to be dispatched. This would be the drawer, DCM, chip, core. Also degrees of meaning are for VH, VM, VL, Dedicated.

• With z16 support it’s now in SMF 70-1, cut by Data Gatherer which everybody has.

• Better in some ways than SMF 99-14. In that is it likely collected by all installations, collected for all LPARs, including non-z/OS and all z/OS.

• It is useful because:

• It contains an analysis of the effect of PR/SM Weights & HiperDispatch, drawers, DCMs, chips. SMF 113 is good for z/OS cache effects, etc.

• It can verify the location of ICF and IFL LPARs in the top drawer, which are separated from z/OS, but sometimes impossible to usefully achieve. IFLs include IDAA and VM. Concurrent Drawer Maintenance complicates things. It’s difficult to predict what PR/SM will do. LPAR Design, though, is important.

• Keep in mind a few health warnings:

  • Logical processors not always dispatched on their home addresses. True of VM and VL logical processors. VH and Dedicated WILL always be dispatched on home processor.

  • Location of memory is not included. SMF 113 gives hints, sort of.

  • z/OS as a VM guest not supported. SMF 70-1 doesn’t report MVS guests under VM, just the LPAR. It does flag “this MVS is in a virtual machine”.

• Provided in z16 Exploitation support, with OA62064, and is in the z16 Exploitation Support and SMF SMP/E FIXCAT.

• Also in SMF 74-4 CPU Section:

  • One for each Coupling Facility logical processor

  • Completes the picture by addressing External CFs’ logical processors

• You might need SMF 99-14 in addition:

  • SMF 99-14 has affinity nodes, whereas SMF 70-1 doesn’t. In practice not much you can do about affinity nodes.

• All in all a very useful advancement in the instrumentation, and now available for many of you. Martin has basic code to process this – so it is already featuring in engagements.

Topics – Some Useful Tips For Debugging An DFSORT E15 Exit

• E15, E35, E32 are popular DFSORT exits, which enhance DFSORT processing. Martin uses E15 to flatten records and enhance filtering.

• It is specified in control statement – OPTION MODS. Usually written in Assembler, can be COBOL or PL/I, though. Mostly pre-existing, so E15’s might need maintenance.

  • Example: Flattening SMF records

  • Example: Unpacking JSON or XML

• Anyone trying to add function to DFSORT, or anyone trying to maintain DFSORT E15 exits might need some advice. Martin uses them as DFSORT can do the record I/O. It is fast, no messy Assembler, and the flattening and filtering is powerful.

• Martin’s tips are:

  • Use exits to do the I/O for you

  • Do A COPY First

  • Stop After 1 Record To Begin With

  • Write Diagnostic Data Into Output Records

  • Forcing An Abend Can Help

  • Code A SYSUDUMP DD

  • Maintain A DFSORT Symbols Convention

  • GETMAIN Your Working Storage

  • Write To The SPOOL

• In conclusion:

  • As a sysprog you might not have come across E15 exits but they’re valuable

  • Almost all the techniques would work with COBOL or PL/I

Out and about

• Marna will be at SHARE Orlando. March 3-7.

• Martin is working on lots of customer situations, destinations to be revealed at a later date

On the blog

• Marna has published no blogs since the last podcast episode.

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

  • z16 ICA-SR Structure Service Times

  • In My Estimation

  • Tips For Debugging A DFSORT E15 Exit

  • Bursty Batch

  • Bursty Batch – Small Reprise

  • Reduced To A Single Tap

So It Goes