Virtual Storage Loses Mind Share

Last week, I taught a class on DB2 for z/OS data sharing recovery and restart to a group of people from a large Asia-based financial institution. The students appeared to be relatively young - I'd guess that most were in their 20s or 30s. At one point, I was explaining that a rebuild of the DB2 lock structure (an area of coupling facility storage used for global lock contention detection and for the recording of currently held data-change locks) is a fast operation because information required for the rebuild is in virtual storage on the z/OS systems on which the DB2 members of the data sharing group are running. A woman on the front row furrowed her brow and asked, "When you say that the needed data is in virtual storage, do you mean that it is in server memory?" I started to explain that data in virtual storage is not necessarily in server memory (aka "real" storage), owing to things like demand paging and auxiliary storage, but I ended up going pretty much with "Yes" as my answer. At that moment, I was struck by how irrelevant the concept of virtual storage is getting to be among people who are coming of age as IT professionals in a world of 64-bit addressing.

Now, don't get me wrong here. I know that virtual storage is still very important in some respects - particularly as it relates to software development. To make efficient use of server memory, an operating system has to be able to place chunks (4KB blocks, for example) of related code and/or data here and there in real storage in a non-contiguous fashion; otherwise, you'd have a lot of "holes" in server memory that would amount to a lot of wasted space. Programmers, on the other hand, need to be able to refer to areas of memory in which, for example, variable values are held, without worrying about where those areas of memory might physically be located in server memory. Virtual storage gives a developer a uniform, non-fragmented canvas on which to create software, while enabling the operating system to get maximum bang from real storage bucks through virtual-to-real address translation that makes the developer's view of memory compatible with the server resource as managed by the operating system. This is not what I'm talking about when I say that virtual storage is losing mind share. I refer instead to the way in which virtual storage can make a server memory of size X appear to be much larger.

There was a time when this "objects in mirror appear large than they really are" function of virtual storage was VERY important. When I started my IT career in 1982, IBM's MVS operating system (forerunner of z/OS) had 24 bits to work with as far as addressing is concerned, and that allowed for a 16 MB virtual storage address space (and support for 16 MB of real storage on a mainframe). The thing is, there were lots of active address spaces on a typical production mainframe system (every logged-in TSO user and every batch initiator had one, and there were also plenty of IMS message regions and CICS application-owning regions), and if you added up all the virtual storage being used in those address spaces you'd get an amount that was WAY bigger than the real storage resource on the server. To give users the impression that all of their in-memory stuff actually was in memory, MVS would shovel not-very-recently-referenced pages of code or data out of real storage and into auxiliary storage (so-called page data sets on disk), and bring said pages back into real storage when needed, to the tune of maybe several hundred per second during periods of peak workload. Whole address spaces (especially of TSO users) would get swapped out (i.e., paged out to auxiliary storage en masse) when they weren't active. We would tweak parameters used by the MVS System Resource Manager in an effort to fine-tune paging and swapping operations. In extreme cases we would "fence" certain address spaces to ensure that the amount of related in-memory data actually in real storage would not go below some minimum amount. Page data set I/O performance was monitored very closely. All this analysis and tuning of virtual and real storage occupied a good bit of a lot of people's time.

The move, in the late 1980s, to 31-bit addressing and 2GB address spaces (and servers that could be configured with 2GB of real storage) made a difference, for sure, but from the DB2 perspective it still wasn't enough. Pretty soon, we got expanded storage on mainframes (page-addressable versus byte-addressable), and exploitation of same via DB2 hiperpools. Even with 2000 megabytes of real storage available versus the 16 megabytes of old, we still used a second tier of storage (expanded) to enable a buffer pool configuration to sort of grow beyond the limit imposed by 31-bit addressability (I say "sort of" because only "clean" pages - those either not updated or updated and subsequently externalized to disk - could be written to a hiperpool, and a page in a hiperpool had to be moved back to a "regular" DB2 buffer pool before a program could access it). Lesson learned: an extra 7 bits of addressability can get used up pretty quickly. How about another 33 bits, taking the total available for address representation to 64 bits? Now, we're talking.

Do you know what an exabyte is? It's one quintillion bytes. One million terabytes. One billion gigabytes. 64-bit addressing can support 16 exabytes of byte-addressable memory. Already, you can get an IBM z10 mainframe with up to 1.5 terabytes of central storage, and you know it's going to go up from there. Want to configure a 4 GB DB2 buffer pool? Go ahead. 20 gigabytes? No big deal. 40 gigabytes? Why not, if you have the memory? We are entering an era in which people will still have page data sets on disk, just for insurance purposes, but they'll have enough server memory so that paging to auxiliary storage will basically be nil. In-virtual will in fact mean in-real, even for very large, very busy DB2 data-serving systems. No more having to make a real resource of size X appear to be size 2X (or whatever). The real resource of size X will be big enough for everything that needs to be in virtual storage. At a number of DB2-using organizations, this is true already.

And I'll update a slide in a presentation to read, "Lock structure rebuild is fast because all the required information is in server memory on the systems on which the DB2 members of the data sharing group are running..."