Episode 32 was, as always a slow train coming. I think it’s a fun one – as well as being informative.
It was really good to have Scott back, and we recorded in the Poughkeepsie studio, just after SHARE Atlanta, March 2023.
Talking of which, the aftershow relates to SHARE. It’s a classic example of “today’s crisis is tomorrow’s war story”.
Anyhow, we hope you enjoy the show. We enjoyed making it.
And you can get it from here.
Episode 32 “Scott Free” Long Show Notes
Our guest for two topics was Scott Ballentine of z/OS Development, a veritable “repeat offender”. Hence the “Scott Free” title.
What’s New
Preview of z/OS 3.1
Mainframe – SMFLIMxx Parmlib Member
We discussed SMFLIMxx with Scott.
SMFLIMxx is a parmlib member, as a IEFUSI exit replacement. Its function is related to storage and specifying limits. Functions are delivered as continuous delivery. Two examples are
- The SAF check
- Number of shared pages used
In z/OS 3.1 customers will be able to specify Dedicated Real Memory Pools to assign memory to a specific application, like zCX. You will be able to use all frame sizes – 4KB, 1MB, and 2GB.
Performance – Open Data Sets, Part 1
This, the first of two topics on open data sets, was also with Scott. He’s very much the Development expert on this.
The main use for having very many open data sets (think “100s of thousands”“) is for middleware, most notably Db2.
Most of the constraint relief in this area is moving control blocks above the 2GB bar.
In ALLOCxx you have to code SWBSTORAGE with a value of ATB to put SWB (Scheduler Work Block) control blocks above the bar.
Applications need to exploit the service – or it has no effect.
Monitoring virtual storage is key here, and remains important: Factors such as the number of volumes for a data set affects how much memory is needed, so virtual storage estimation is difficult to do.
You can probably guess what Part 2 will be about.
Topics – Evolution of a Graph
Martin explored the large improvements he’s made with his custom graphing programs. (He already posted about what he sees with one of them here.) But this topic wasn’t about the technical subject of the graph, more the evolution from something “meh” to something much better. The evolution process was:
- Start with a query that naively graphs database table rows and columns, with labels generated by the database manager and fixed graph titles. Not very nice, not succinct, not very informative.
- Generating the titles with REXX, giving them more flexibility and allowing additional information to be injected.
- Using REXX to drive GDDM directly – which enabled a lot of things:
- REXX was able to generate many more data points and to plot them directly. (In particular the code is able to show what happens at very low traffic rates whereas previously it had had to be restricted to the higher traffic rates.)
- REXX could generate the series names, making them friendlier and more informative.
The purpose of including this item, apart from it being a fun one, is Martin encourages everybody to evolve their graphs, to tell the story better, to run more efficiently, and to deal with underlying technological change. Don’t put up with the graphing you’ve always had!
Customer Requirement
ZOSI-2195 “Extended GDG causes space issues”, has been satisfied: IGGCATxx’s GDGLIMITMAX with OA62222 on V2.3.
On The Blog
Marna’s NEW blog location is here. There are three new posts:
- Home advantage for installing PTFs
- Let’s revisit a PSP bucket
- Easy access to fantastically important service level Information
Martin has quite a few new blog posts here:
- WLM-Managed Initiators And zIIP
- Coupling Facility Structure Versions
- Heading Back Into Db2- Architecture Part 1
- When Good Service Definitions Turn Bad
- Aforementioned A Very Interesting Graph
So It Goes.
Mainframe, Performance, Topics 