How I Look At Virtual Storage

(Originally posted 2014-12-07.)

I thought I’d write about how I begin looking at virtual storage, occasioned by a customer who had a 24-bit virtual storage (878–10) ABEND[1] . Most of this is in our code, so easy for me to do. I hope you’ll find it similarly easy.

You’ve had hints of this in How Many Eggs In Which Baskets? and Broker And SMF 30.

The game is really to use product-neutral instrumentation first. Then use the product-specific instrumentation (where available) only where you really need it.

This post won’t talk about the latter; It’s reasonably well documented.

Almost everything I’m about to say is equally true of 24-bit and 31-bit virtual storage; Just the field names are different in the records.

I divide the analysis into two parts:

• System Virtual Storage
• Address Space Virtual Storage

The data for the former comes entirely from RMF’s SMF Type 78 Subtype 2. For the latter it’s in the SMF Type 30 record (though you can also get SMF 78–2 information for a small number of suitably-chosen specific address spaces.

System Virtual Storage

Here we establish how the Common areas are defined and used, together with the size of the Private area.

This is easy to do. In this example the data is all 24 Bit.

The highest level view looks like this:

This is a static picture.

The first thing to notice is that the Common Boundary is at 9MB.[2]

In case you need a larger Private Area examine the largest allocated area of Common Storage and it is, in this case, CSA.[3]

Here’s how I begin to drill down into CSA usage (rather than allocation):

(You might want to pop it out into a different tab – as it’s quite wide.)

Each line, except the first two, represents a different time range. In this case I’m summarising at the half-hourly level. [4]

The first two lines are maxima and minima. In this case they show only slight variation through the day, which is good to know.

The first thing I notice about this is there is some SQA free (and in the 31-bit case I print a “SQA Overflow Into CSA” column instead – as that’s what’s happening with this set of data). SQA can overflow into CSA but not vice versa – so this is wasted virtual. I recommended decreasing the SQA size by, say, 250KB [5]

That’s not strictly necessary as the Minimum CSA free (rightmost column) is over 2.5MB. So an easy way to get a 10MB region is to decrease the CSA size by 1MB. 2MB would be pushing it – as the customer wants to allow the whole of Key 7 to be duplicated. [6]

Talking of which, you can work out which Storage Protection Keys represent the bulk of the CSA usage. In this case it’s Key 0, Key 7 and Key 8+. [7]

But you can go further. Look at this:

It’s Subpool 241 Key 0 that’s the biggest, then Subpool 228 for Key 8+, then evenly split Subpools 231 and 241 for Key 7.

I’ve deliberately summarised this table over a “shift” – to avoid having to make the table 3-dimensional 🙂 . But the conclusion is still clear.

If you had to tune CSA usage you’d use this information and drill down further.

For completeness, here’s the Subpool breakdown for SQA:

It’s obvious Subpool 245 dominates.

Two things to note:

• You don’t get either the CSA or the SQA Subpool breakdown for 31-bit (as it’s not in the data).

• You can’t break down the SQA Subpool usage by Storage Protection Key.

But you can see a good breakdown of Common Storage can be had from RMF 78–2 data.

Fortunately, we can already do enough with just a CSA reduction (and perhaps with a SQA reduction) to get us at least 1MB more 24-bit Private.

Address Space Virtual Storage

Here we examine Private Area Allocated [8] Virtual Storage for individual address spaces.

While it’s possible to examine Private Area virtual storage with SMF 78 Subtype 2 data most customers don’t set up monitoring of individual address spaces.

Instead SMF 30 Interval records tend to be readily available. So from these you can get 24- and 31-Bit “Low Private” and “High Private” numbers.

In the example customer’s case their IMS DL/I SAS (address space) takes almost the whole of the 24-bit Private Area. About half is Low Private and half is High Private.[9]

Interval-on-interval there is little change is Private Area usage (but I don’t have data from the day the ABEND happened – yet). It’s just clear this address space is always “close to the edge”.

So, working on the 24-bit virtual storage usage by this address space is strongly indicated. But having a 1MB bigger 24-bit region can’t hurt either. So I’ve advised doing both.

Conclusion

I hope you can see it’s quite easy to analyse virtual storage with SMF 78–2 and SMF 30 Interval records.

I’d say that – with a few exceptions – you shouldn’t obsess over virtual storage. What you should do is consider setting up some “light touch” monitoring; Perhaps CSA Free and SQA Free (24- and 31-bit) and Virtual Allocated for some key address spaces. That way the usual applies:

• You get to know how your systems operate.
• You can spot impending problems.

And I’m going to make sure in future we always pump out this sort of reporting – assuming the data’s there. And generally it is: You’re collecting it so use it.