Chip Davis wrote:
Oh, I vividly remember the joys of DMKSNT and managing DCSSes, and of
trying to squeeze everything below the 16Meg line yet above the
VMSIZE. It seemed that the very users who needed access to the most
packages also had to have the largest VMs.
Things are *MUCH* better now that nearly everything can be changed on
the fly and you don't even need an IPL, much less assembly and
re-gen. These new kids today don't know how good they have it...
<wheeze> <cough> <hack> ...
I would think it would have been sometime in the early 70's, so I
guess it might have been in the first release of VM/370, but I'm
having trouble tracking it down.
-Chip-
Well, things sure are easier to manage today !
However, there is *one* thing that became more difficult with VM/XA : If
you were unfortunate enough to have to use RMODE 24 code (that is, code
sitting below the 16MB line) and/or were restricted to a S/370 virtual
machine, then the XA requirement of 1M segments (compared to 64K
segments for S/370) meant that you were pretty limited in the number of
segments that you could bring up at any one time in a virtual machine.
This is something I had to tackle when I started playing with VM/XA
SP2.1 - and still had a lot of 24 bit code sitting around (for example,
the CMS VSAM code - with its 3 required segments (CMSDOS, CMSBAM,
CMSVSAM) PLUS the CMS segment meant a virtual machine running VSAM code
had to have a virtual machine size of no more than 10MB or so. More than
that, at that time, we were doing a lot of storage optimization work (my
4381 only had 32MB of real storage) so we were putting a lot of stuff in
shared segments. So if you wanted to share anything - you were going to
eat up 1 ou of the 16 available MBs in a virtual machine.
Of course, nowadays, this is quite a moot point since most of the code
is now RMODE 31 (and S/370 mode VMs don't exist anymore) - and doesn't
have those restrictions (or rather, the constraint is to eat up 1 ou of
2048 MBs.. something I could have done with at that time !)
--Ivan
