> Come on Rick. That isn't true with CMS either. Provided you save
Well ... I admit, you got me there:
CMS is locked in to 190, 19E, with a fondness for 191
and mild affinity for 19D and 192.
> the NSS early enough it will be before the kernel finds out the
> virtual machine size etc. If you would not include the dasd= in
> the NSS you would require each Linux guest to have that on the
> IPL statement in the CP directory or in the PROFILE EXEC which is
> not fun either.
No no. You misunderstood. This is more fun, not less fun.
Better for Linux, better for VM, does not harm LPAR mode and is
terribly easy to do. ("So why haven't you done it?" they ask.)
What I'm suggesting is that the STM-style parms
be an override for whatever is stamped in with the IPL text.
Presumably there would be a default "dasd=" parm there.
You would simply have the ability to override with
ipl linux parm dasd=1b0-1bf root=1b1
or some such.
I never said we should stop using the other method.
And, no, Linux has not locked in at that point.
The candidate stopping point is 0x10000, where the IPL text
has completed loading and the kernel has not yet begun to execute.
It's the perfect place to do an STM to a sacred chunk of low core
with easy later logic to merge that in with the "other" parm string.
