[Info-vax] show sys command output

[Stephen Hoffman]

On 2017-07-14 09:07:07 +0000, Sergejus Zabinskis said:

> Maybe somebody knows exactly the meaning of last column (Pages) for 
> this command:

Others have provided the technical answer.

Some history...

The pragmatic answer is that the designers had their heads... 
constrained.   Instead of returning a value such as the total number of 
bytes, they saved some memory and returned the count of hardware pages. 
 Saving memory was a big part of VAX.   VAX pages are 512 bytes, same 
as a VAX-era disk sector — what OpenVMS calls a block, and what may end 
up a blocklet given the end of 512-byte disk sectors with the 
advanced-format disks.  When Alpha arrived, designers were faced with 
breaking compatibility (EVIL! BAD! NEVER!) and with the use of VAX 
pages, so the concept of pagelets was created.   This instead of 
admitting a design mistake and moving to human-oriented display units, 
and relegating the existing API to legacy support, they invented the 
term pagelets (VAX pages) and Alpha pages (8192).

This whole morass of legacy API compatibility would have gotten more 
complex as Alpha page size changes were planned (then Itanium 
happened), and will soon get more interesting as the x86-64 page size 
is likely going to be either 4096 (4 KiB) and maybe adding 2MiB page 
sizes.   Like the old English halfpenny, will we soon have halfpages or 
hapages, just to add to the confusion, complexity and consternation?   
Or if there's eventually a mix of different memory page sizes active on 
a system in parallel?   Or are developers to always be expected to code 
the page size retrieval and multiplication themselves, rather than the 
(replacement) API always returning... bytes.   That seems... hostile.

Then there's that nobody documented what that display field actually 
contains ("Pages-The number of CPU-specific pages in physical memory 
that the process is currently occupying."), so there have been various 
discussions over the years of how OpenVMS calculates that number for 
display, and inevitably including the discussions around system page 
sizes.   All this rather than documenting the contents of the field and 
migrating to a unit such as bytes.   This because we have 64-bit 
storage now, and stretching that field to 64-bits or even to 128-bits, 
or longer-term to an OO API design and dispensing with the field length 
drivel.   We're not dealing with VAX systems where five or eight 
megabytes of memory was huge.

Be that as it may, in the favor of continuing the current API hackery 
and confusion and the current 
pages-pagelets-what-the-heck-is-a-VAX-and-why-do-I-care design is that 
DCL itself can't currently deal with integers past 32-bits nor with 
unsigned integers (and fixing that'll be "interesting", see other CLI 
discussions here in the comp.os.vms newsgroup), which potentially means 
returning the memory usage values biased by megabytes or such and 
that's an approach that's somewhat less than future-resistant as memory 
configurations and memory usage increases, or by returning the 
not-biased data as bytes using strings or other ugliness.

Then there's the whole discussion of displaying ginormous byte-count 
fields using human-readable units such as MiB or GiB and separators, 
something that the OpenVMS APIs and command tools just aren't all that 
good at providing.

Welcome to upward-compatibility, and to the trade-offs and compromises 
inherent in stretching old designs and old APIs past what might be 
appropriate or preferred; of valuing old code over new.




-- 
Pure Personal Opinion | HoffmanLabs LLC