Mainframe Performance Topics Podcast Episode 32 “Scott Free”

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:

Martin has quite a few new blog posts here:

So It Goes.

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: