One thing I forgot to mention.  CMS minidisks in EDF format have four
possible block sizes: 512, 1024, 2048, and 4096.
(Oh dear, I've introduced another undefined acronym.  EDF stands for
Enhanced Disk Format.  It is the only format of CMS minidisk that is
currently supported.  There is an older format called
CDF, which stands for Conventional Disk Format, which had a block size of 800.  
But VM dropped support for CDF long before Linux was ported to
the mainframe.)

For CKD devices, the block size is the size of the
physical blocks on disk.  For FBA devices, it appears that the physical
blocks are grouped to form logical blocks.  For example, with a block size
of 4096, there are eight physical blocks per logical block
(4096 / 512 = 8).  However, for FBA devices, the CMS label record is
always the second 512-byte block on the disk, regardless of the logical
block size.  For CKD devices, the CMS label record is always the third
physical block.  However, since the physical blocks can be of varying
sizes, the byte offset from the beginning of the device varies depending
on the block size.  The block size is specified in the label record;
so that is a sanity check.  The byte offset OF the label record should
be three times the block size size specified IN the label record.

The block size is in the fourth word of the record.  (On the mainframe,
a "word" is 4 bytes, or 32 bits.  Also, the mainframe is a "big-endian"
machine, not a "little-endian" machine, meaning that binary integers
are stored left to right from the most significant bits to the least
significant bits.  On the IBM PC, a "word" is 2 bytes, or 16 bits.  And
the PC is a "little-endian" machine, meaning that it stores the least
significant byte first, followed by the most significant byte.)
I trust that the C compiler sorts all of this out for you and you won't
have to worry about it, but I'm not a C programmer; so I don't know.

By the way, you might want to take a look at the source code for the
kernel modules that support DASD to get an idea of how the Linux kernel
itself distinguishes an FBA DASD from a CKD DASD, how it recognizes
a CMS minidisk, and how it determines where the partition (for example,
/dev/dasda1) starts as opposed to the device itself (for example, /dev/dasda).  
The CMS label record is part of the overhead that occurs
in the device itself (for example, /dev/dasda) BEFORE the partition
starts.  The file system will be
made in the partition (for example, /dev/dasda1).  A CMS minidisk always
has only one partition and does not need to be processed by the fdasd
utility (indeed it CANNOT be) to create partitions.

The kernel source modules to look at are dasd.c, dasd_eckd.c, dasd_fba.c, and 
dasd_diag.c.  These correspond to kernel modules dasd_mod,
dasd_eckd_mod, dasd_fba_mod, and dasd_diag_mod, respectively.  They are
found in directory

/usr/src/linux-source-2.6.24/drivers/s390/block

if you have installed the kernel source code.

Incidentally, you have a good mainframe name.  TSO is a mainframe
acronym for Time Share Option.  That is the subsystem under MVS which
allows a user to logon to MVS from a terminal, as opposed to submitting
a batch job via the card reader.  TSO is an integral part of MVS now,
but at one time it was an optional feature.  The subsystem is still
called TSO for historical compatibility.  Mainframers say the letters
(tee es oh), they don't try to pronounce it as a word.  With a good
mainframe name like that, I'm sure you'll do just fine!  :-)



      



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to