Time For Action On Virtual Storage?

I wrote How I Look At Virtual Storage in 2014.

But since then my stance has shifted somewhat. A recent study I was part of made me realise my tone on z/OS virtual storage should probably be a little more strident. In that post I was somewhat even handed about the matter, just describing my method.

This study also involved the CICS Performance team. They pointed out that some of this customer’s CICS regions had substantial use of 24-Bit virtual storage. If those CICS regions were to be able to scale (individually) a limiting factor might be 24-Bit virtual storage.

Obviously working on CICS regions’ use of virtual storage is the correct way forward under these circumstances.

But it got me thinking, and doing a little investigating.

Why Virtual Storage Matters

Almost 35 years ago a sales rep in my branch suggested selling a customer more virtual storage. 🙂 (Yes, he really did.)

Joking apart, if you want more virtual storage you can’t buy it; You have to work for it.

But why would you want more 24-Bit virtual storage anyway?

• Older applications might well be 24-Bit and converting them to 31- or even 64-Bit might be difficult or not economically viable.
• Some things, such as access method buffers, might well be in 24-Bit virtual storage. (To be fair, high level languages’ support for buffers above the 16MB line is good.)

I raise the subject of access method buffers because one of the ways of tuning I/O performance is to increase the number of access method buffers. To optimally buffer a single QSAM data set, for example, takes a substantial proportion of an address space’s 24-Bit region – unless the buffers have moved above the 16MB line. So one is sparing of buffers under these circumstances, perhaps sacrificing some performance. (You would choose high I/O data sets to buffer, obviously.)

My own code – at least the bits I have the excuse of having inherited – is probably predominantly 24-Bit. I might fix that one day, though it doesn’t seem like a good use of time. (It would probably be coupled with removing SIIS (Store Into Instruction Stream) horrors.)

What’s New?

When my CICS colleagues mentioned managing the use of 24-Bit virtual storage within the CICS regions a thought occurred to me: I could examine whether the 24-Bit region size could be increased. Both are useful approaches – reducing the demand and increasing the supply.

The same is probably true of 31-Bit, of course. For 64-Bit I’m more concerned with getting MEMLIMIT set right.

I think I’ve observed something of a trend: It seems to me many customers have the opportunity to increase their 24-Bit region – probably by 1MB but sometimes by 2MB. This would be a handy 10 – 20% increase. I doubt many customers have examined this question in a while – though most have SMF 78-2 enabled all the time. It’s rare to get a set of customer data without it in – and we always pump out the report outlined in How I Look At Virtual Storage.

Examining And Adjusting Virtual Storage

In what follows I’m describing 24-Bit. Similar actions apply for 31-Bit.

1. Check that your SQA definition is small enough that there is little or no SQA free. SQA can overflow into CSA but not vice versa – so overspecifying SQA is a waste of virtual storage.
2. Check how much CSA is free.
3. Adjust SQA and CSA so that there is generally 1MB CSA free but little if any SQA free, but so that you are raising the private boundary by an integer number of MB – probably 1MB, possibly 2MB.
4. Monitor the resulting 24-bit virtual storage picture.

You need to do the analysis with data over a reasonable amount of time. I’d say at least a week. You want to know if SQA and CSA usage are volatile. In most customer situations I’ve seen they are relatively static, but you never know.

One of the key points is that the boundary between common and private is a segment boundary i.e. 1MB. There is therefore no point trying to claw back, say, half a megabyte. (The “generally keep 1MB free” above is not related to this; It’s just a reasonable buffer.)

For 24-Bit I said “adjust SQA and CSA so that there is generally 1MB free”. For 31-Bit I’ve generally said “keep 100MB free”. I think that’s fair but 200MB might be better. Most middleware and applications that use Below The Bar virtual storage have substantial amounts of 31-Bit. If their use is volatile – again when viewed over a reasonable period of time – then that might guide you towards 200MB free or more. The “100MB” is not structural; That’s 100 segments and is just a reasonable rule of thumb. At least for 31-Bit the 1MB segment boundary doesn’t seem nearly so coarse grained as it does for 24 Bit, so adjustment needn’t be in 100MB increments.

Talking of 31-Bit virtual storage, one of the biggest users of ECSA usage has been IMS. Until a few years ago the biggest users of 31-Bit private were Db2 and MQ. Db2 is now almost all 64-Bit and MQ has done lots of 64-Bit work.

Conclusion

I would urge customers to examine their virtual storage position. In particular, 24-Bit might well contain good news. 31-Bit might also, but there I’m more inclined to check there’s enough left. It’s not difficult to examine this, even if all you do is run off an RMF Virtual Storage Activity report.

I, for one, will make a point of examining the virtual storage reports we produce. Generally I do, anyway. Else I wouldn’t be seeing this trend.

Finally, a sobering thought: If, as has been said, customers are using 1 bit of addressability a year we are 21 years into a 33-year 64-Bit lifespan. I’m pre-announcing nothing by saying this. And the “1 bit a year” thing might not actually hold. But it does make you think, doesn’t it.