Peter, I tried your scenario and it works as you say. I can use a CMS
minidisk, RESERVEd or non-RESERVEd, as a /boot partition. I can even use
the dasd_diag driver against it, provided I don't run zipl. (If I need
to run zipl, I can switch to the dasd_eckd driver, then run zipl, then
switch back to the dasd_diag driver. If the /boot partition is a separate
partition, I can switch drivers dynamically. If the /boot directory is
included in the / partition, then I must use the dasd_eckd driver all the
time, since one cannot umount /.)
The problem is that the IPL records (other than the first two) are being
written, architecturally speaking, to the wrong place. I don't know where
zipl is writing its IPL records, other than the first two, but I am
assuming that they are written to the "CMS metadata" somewhere or else
to a special file in the filesystem in the first partition. (Please tell
me where they are being written!) Perhaps it would be good to review the
general format of a CMS minidisk. I am assuming a CKD device:
----- /dev/dasdb -----
starting block #: 1 number of blocks: 2 contents: the first two IPL records
starting block #: 3 number of blocks: 1 contents: volume label
----- /dev/dasdb1 -----
* The first partition starts here if the minidisk is not RESERVEd.
starting block #: 4 number of blocks: 2 contents: file directory
starting block #: 6 number of blocks: * contents: pointer blocks for
allocation map
starting block #: next number of blocks: * contents: allocation map
starting block #: next number of blocks: * contents: allocation map backup
starting block #: next number of blocks: * contents: file pointer blocks
----- /dev/dasdb1 -----
* The first partition starts here if the minidisk is RESERVEd.
starting block #: next number of blocks: * contents: file data blocks
----- /dev/dasdb2 -----
* The optional second partition starts here if there is a RECOMP area.
* For a CKD device, the RECOMP area always begins on a cylinder boundary.
starting block #: next number of blocks: * contents: RECOMP area
* The minidisk ends here.
The above is the general format of a CMS minidisk. Architecturally
speaking, there is nothing that prevents a minidisk from being both
RECOMPed and RESERVED. The minidisk is RECOMPed if ADTCYL < ADTMCYL.
The minidisk is RESERVED if ADTOFFST > 0. These two do not conflict
with each other. (I'll have more to say about that later.)
Architecturally, the "right" place for a bootable program to reside on
a CMS minidisk is the RECOMP area. I know of two examples of this in
the CMS world. The first is CMS itself, which is a bootable operating
system for a virtual machine. Normally, CMS is IPLed by a virtual machine
via a Named Saved System (NSS). This allows multiple virtual machines
to share the same physical read-only pages of the CMS operating system.
However, it is also possible to IPL by device number, which gives the
user a private copy of CMS which is not shared by any other user.
When CMS is IPLed by device number, the nucleus is read from the RECOMP
area.
>From a running CMS system, enter the command
QUERY DISK S
This is a CMS command. It will tell you, among other things, the number
of cylinders used by the CMS filesystem for the system disk (filemode S).
On my z/VM 5.2.0 system, this is 100 cylinders (3390 device type).
This number corresponds to ADTCYL in the volume label. Now issue the
command
CP QUERY VIRTUAL 190
This is a CP command. It will tell you, among other things, the actual
size of the minidisk in cylinders. On my z/VM 5.2.0 system, this is
107 cylinders. This number corresponds to ADTMCYL in the volume label.
The difference is the size of the RECOMP area (7 cylinders), which is
at the end of the minidisk and is where the CMS nucleus resides --
OUTSIDE the CMS filesystem. When you issue the command
CP IPL 190
A private copy of CMS is loaded into your virtual machine from the RECOMP
area of device number 190, provided your virtual machine has enough
virtual storage to load a private copy.
The second example is the Stand-Alone Program Loader, or SAPL. Like zipl,
SAPL is a boot loader. It was originally designed to load CP, but it can
also load some other stand-alone programs, such as ICKDSF and DDR.
In normal production use, the SAPL is IPLed from a CP-formatted volume
(i.e. a volume formatted by the CPVOLUME FORMAT command of ICKDSF).
However, for testing purposes, The SAPL can also be IPLed from a CMS
minidisk. The SAPL program is written out either by using the line-mode
SALIPL MODULE utility under CMS or by using the full-screen IPL SALIPL
utility, which runs stand-alone.
Here is a sample console session in which the SAPL is written to
a CMS minidisk using SALIPL MODULE.
cp define t3390 192 3
DASD 0192 DEFINED
Ready; T=0.01/0.01 12:42:06
format 192 d ( blksize 4096
DMSFOR603R FORMAT will erase all files on disk D(192). Do you wish to continue?
Enter 1 (YES) or 0 (NO).
1
DMSFOR605R Enter disk label:
tmp192
DMSFOR733I Formatting disk D
DMSFOR732I 3 cylinders formatted on D(192)
Ready T=0.01/0.01 12:45:00
query disk d
LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL
TMP192 192 D R/W 3 3390 4096 0 7-01 533 540
Ready; T=0.01/0.01 12:47:30
salipl 192 ( module CPLOAD origin 2000 iplparms FN=SYSTEM
HCPSAL6794E NO RECOMP AREA DEFINED ON CMS FORMATTED DISK
Ready(06794); T=0.01/0.01 12:47:45
format 192 d 2 ( recomp
LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL
TMP192 192 D R/W 2 3390 4096 0 7-02 353 360
Ready; T=0.01/0.01 12:56:53
salipl 192 ( module CPLOAD origin 2000 iplparms FN=SYSTEM
HCPSAL6798I VOLUME ID IS TMP192
HCPSAL6797I MINIDISK VOLID AT OFFSET 0 IS TMP192
Ready; T=0.01/0.01 12:59:11
As you can see, the first time SALIPL was invoked, it had a freshly-
formatted CMS minidisk to work with, but it did not have a RECOMP area.
The attempt to write out the boot records failed because there was no
RECOMP area to write to. After creating a RECOMP area and trying again,
the second attempt succeeded. (Note: the number of cylinders specified in
the FORMAT command with the RECOMP option is the desired size of the
filesystem, not the desired size of the RECOMP area. In this case,
the filesystem size requested was 2 cylinders. The RECOMP area size
is therefore 1 cylinder (3 - 2 = 1).
The minidisk is now bootable, as we can now verify:
#CP TERMINAL CONMODE 3270#IPL 0192 LOADPARM 0009
This assumes that you are logged on to z/VM via a 3270 terminal, and
that your virtual console is device number 0009.
You will see the SAPL screen displayed. Don't press PF10 because
(a) you have not copied CPLOAD MODULE to this disk and (b) because you
don't really want to start up a second-level VM system anyway.
To boot CMS again, do the following:
(1) Press PA1 (to get a CP READ).
(2) Type "TERMINAL CONMODE 3215" (without the quotes) and press Enter.
(3) Type "IPL CMS" (without the quotes) and press Enter.
(4) Press Enter again at the VM READ.
When you are finished playing around with the temporary disk, get rid
of it with
cp detach virtual 192
So, after all that, I guess my revised enhancement request would be:
"Provide support for the RECOMP area of CMS minidisks."
As I envision it, this support would consist of the following:
(1) The DASD driver must recognize a CMS minidisk which has a RECOMP area.
(2) When a RECOMP area is detected, it must be excluded from the first
partition (i.e. /dev/dasdb1) and a second partition must be defined
(i.e. /dev/dasdb2) for the RECOMP area.
(3) With this improved kernel support, none of the file system code
(mke2fs, mkreiserfs, etc.) should need to change.
(4) zipl will need to be enhanced to recognize when the /boot
partition resides on a CMS minidisk with a RECOMP area and write
its IPL records to the RECOMP area. If there is no RECOMP area, then
zipl should behave as it does today for forward compatibility.
I suggest you look at the source code for DMSINI ASSEMBLE (which writes
the CMS nucleues to the RECOMP area) and HCPSAL ASSEMBLE (which writes
the SAPL to the RECOMP area) for ideas on the
proper, architecturally pure way to write out a bootable program to
the RECOMP area of a CMS minidisk. If you do it right, maybe zipl
will even work with the dasd_diag driver! That would be a nice
fringe benefit.
I said earlier that I would have more to say about a minidisk being
both RECOMPed and RESERVEd; so here it is. The only thing that prevents
a minidisk from being both RECOMPed and RESERVEd is the current
patronizing attitude of the RESERVE command. The RESERVE command assumes
that you would never want a minidisk to be both RESERVEd and RECOMPed;
so it automatically undoes the effect of any previous RECOMP, whether
you want it to or not. I suppose this assumption makes sense in a pure
CMS environment. You wouldn't want the CMS system disk to be RESERVEd;
since it must hold multiple files. And you wouldn't want the CP PARM
disk to be RESERVEd either; since the CP PARM disk must also hold
multiple files. But in a Linux environment, there is an advantage to
having a minidisk be both RECOMPed and RESERVEd. What to CMS is a
single file is to Linux an entire filesystem, with multiple files in it.
And a RECOMP area is the proper way to make a CMS minidisk bootable.
Fortunately, the current behavior of the CMS RESERVE command is very easy
to change. In DMSRSV ASSEMBLE, at label RSV0007, you will find the
following instruction sequence:
CLC ADTCYL,ADTMCYL IS IT A "RECOMP" DISK?
BNE RECOMP ...YES, PROCESS
Change the "BNE" extended mnemonic to the "NOP" extended mnemonic.
Use the official procedures for local modifications, of course.
If you're not the system programmer and you want to play around with this,
you can use the following ZAP:
LCL0015 ZAP:
NAME RESERVE
VER 0220 D503,A0A4,A0A8
VER 0226 4770
REP 0226 4700
LOG LCL0015 ZAPLOG * Respect RECOMP area
END
Apply the zap as follows:
copyfile reserve module s = = a
zap module ( noprint input lcl0015
You now have a copy of RESERVE MODULE on your A disk which will
respect the RECOMP area. On second thought, don't copy it to your A
disk. Copy it to a temporary disk. Otherwise, you may forget about it.
And years later, you'll be reporting a problem with the RESERVE command
that will eventually be traced to an out-of-date RESERVE MODULE from
a back-level release of CMS on your A disk. That makes system programmers
mad. ;-)
The above ZAP works on my z/VM 5.2.0 system. I haven't tried it on any
other releases of CMS.
Having the above support in Linux for CMS minidisks with a RECOMP area,
plus the modification above to the CMS RESERVE command (which I can do
myself) meets all of my goals. Those goals are as follows:
1. The minidisk is completely usable under CMS, with no CMS file system
corruption.
2. The minidisk is completely usable under Linux, with no Linux file
system corruption.
3. The minidisk is being used by both systems according to its
architectural design. An IPL-able program, if any, is in the RECOMP
area (plus the first two IPL records), The Linux data is in the CMS
RESERVEd file, and all the CMS metadata is completely correct according
to CMS' definitions.
This will allow me to leverage existing z/VM tools for CMS disk
administration, such as backup and recovery, incremental backups, etc.
at a logical backup level (CMS files) or a physical backup level (disk
images).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
