Good questions, Paul.
Copying the Linux-390 discussion list because it seems relevant.

I'll discuss the filesystem driver ("cmsfs.o" below) in a separate note,
but the CMSFS utility was written for maximum portability. Got an update
from Dan Horák a year or five ago, and that should be in the github
source. Otherwise, it has been stable. Credit the fine folks at Endicott
for making rock-solid sub-systems.


On 08/25/2017 07:58 AM, Paul Flint wrote:
>> So ... all I/O on z is done in this uniform hexadecimal space. Very
>> nice. (And forgive me if I'm telling you things you already know.)
>
> Yea but you make it sound so easy...

SMOP, and systems like Linux have the device drivers, so it /is/ easy.


>
>> Disks ... virtual machine gotta have disks just like a real machine.
>> CMS has some standard addresses: 190 is the system disk, 191 is
>> your personal disk. CMS also uses 181 for your personal tape drive.
>> There's a progression: 18x, 19x, 1Ax, 1Bx. The 1A0 and 1A1 disks
>> might be used for your own VM-on-VM (that's a whole nutha story),
>> so I put NORD at 1B0 and 1B1.
>
> This is good stuff.

There used to be more.
CMS has 19E and "we" used to put Linux /usr at 1BE.
But the KISS principle trumps trickery and simpler is sweeter.


>
>> 1B1 is nothing more or less than your root disk when you IPL NORD.
>> As configured at Dave's place, NORD uses a shared segment for the op
>> sys, so you don't strictly need the 1B0. But it's there and gets used
>> when doing maint.
>
> Since this is all about volumes I will mention my bumbling in this
> area here and my bumbling on the network front in another note.

It's all good.
(And for the rest, know that Paul is online. Just a little NAT action by
The Generous and FLINT flies fine.)


> The good news:
> #
> CP Q V DASD
> DASD 0190 3390 M01RES R/O        214 CYL ON DASD  2002 SUBCHANNEL = 0004
> DASD 0191 3390 USR006 R/W        500 CYL ON DASD  1006 SUBCHANNEL = 000B
> DASD 019D 3390 M01RES R/O        292 CYL ON DASD  2002 SUBCHANNEL = 0005
> DASD 019E 3390 M01RES R/O        500 CYL ON DASD  2002 SUBCHANNEL = 0006
> DASD 019F 3390 USR001 R/O        150 CYL ON DASD  1000 SUBCHANNEL = 0007
> DASD 01B0 3390 USR00A R/W       2000 CYL ON DASD  1009 SUBCHANNEL = 0009
> DASD 01B1 3390 USR00B R/W       2000 CYL ON DASD  100A SUBCHANNEL = 000A

Standard set. Looks good.


> From your 2000 github:
>
>         'cmsfsvol' ---- report on a CMS volume in CMS 'Q DISK' format
>         'cmsfslst' ---- list CMS files in CMS 'LISTFILE' format
>         'cmsfscat' ---- conCATenate one or more CMS files to stdout
>         'cmsfsck' ----- filesystem check for CMS vols (aka: fsck.cmsfs)
>         'cmsfscp' ----- copy CMS files, preserving time stamps
>         libcmsfs.a ---- "archive" library for user space (utility) mode
>         cmsfs.o ------- the FS driver, for 'mount -t cms' to work
>
> Shear guesses as to how to use the first in the list:
>
>  cmsfsvol
>  /usr/bin/cmsfslst /dev/dasdb1
>  /usr/bin/cmsfsvol dev/dasdb1
>  /usr/bin/cmsfsvol 1b1
>  /usr/bin/cmsfsvol 01b1
>  /usr/bin/cmsfsvol 01B1
>
> Maybe?

Ah! To partition or not to partition. That is the question.
In Linux parlance, the trailing "1" indicates "partition one". But CMS
minidisks are not partitioned, so the FS goes on "the whole disk".

But also, the CMSFS commands are useless against your 1Bx disks. You
need CMS format minidisks, the 19x range. Also, your 191 will not beyour
present /dev/dasda or /dev/dasdb. Aaaaand  they're not explicitly
online. Let's fix that.

Finally, you're on NORD which doesn't have UDEV (or at least doesn't
have UDEV yet). So there are manual steps for bringing the 191 online.
(This is /not/ rocket surgery.) Bear with me ...

    echo 1 > /sys/bus/ccw/devices/0.0.0191/online
    # to bring your 191 online

    /etc/nordblks.sh
    # to fudge for lack of UDEV and create the device file(s)

    ls -lat /sys/bus/ccw/devices/0.0.0191/block
    # to know where the kernel slotted your 191

    cmsfsvol /dev/dasdq
    # to see the CMS  'q disk a'  equivalent


And there you have it!
The above steps are scripted in /etc/init.d/cmsfsrun on your guest, but
it has its own purpose, not general.

If you had 190-19F in your boot parms, they'd be online from the get-go,
and you could rely on /dev/dasdq (or whatever, probably /dev/dasdr in
that case) always bein there.


> # /usr/bin/cmsfsvol USR00A
> LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT 
> BLK TOTAL
>
> open(): No such file or directory
> cannot open 'USR00A'
> 'USR00A' is not a CMS volume.
>
> Could use a hint...

If "USR00A" was a plain file (with a CMS FS disk image) or a device file
(of a CMS minidisk) or a sym-link to either, then it would work. The
utility does not care if the "file" it reads is an actual block device
or just a plain file. That's the Unix way.

The utility should run fine on Linux (any hardware), USS, OpenVM,
Solaris, AIX, HP-UX, Darwin / Mac OS X, *BSD. If you just happen to have
a 'dd' image of your CMS "A" disk on your Mac, then you can use the
utility to copy files from it. (using either 'cmsfscp' or 'cmsfscat')


> Kindest Regards,
>
>
>
> ☮ Paul Flint

This could probably use a good tech writer. Know of one?


-- R; <><




----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to