Further to the comments regarding sharing of DASD between CMS users and OS - this was routine behaviour at a former employer of mine (back when
DASD was always in short supply). We would format the DASD on the OS side , allocate a dataset covering the back end - and then zap the VTOC to flag the dataset as password-protected, but never put a password into the password dataset (RAC-who? <grin>). This effectively rendered the, "CMS" cylinders unreadable from OS. On VM we would allocate a dummy minidisk that mapped the OS part of the disk (to keep DISKMAP and the such happy) and then simply allocate CMS minidisks on the, "CMS portion" in the usual manner. Never a problem in many years of operation. As Tom said, "As long as everyone agrees to what's being done ...". In this particular setup, V M and OS ran on separate machines with a fully-shared DASD farm. Reading CMS minidisks from OS is not, "difficult". Again, at a different former employer, this was routine behaviour - we had a utility that serve d as a kind-of poor man's RSCS by reading JCL stored on a specified CMS minidisk and submitting it into the internal reader. The writing of code of this kind was considered a training exercise for junior sysprogs - onc e they'd successfully done something like this you could confidently expect them to understand a whole raft of basic functionality from BDAM through DYNALLOC and the internals of the CMS File System and the CP Object Directory. It also helped to break down the barriers between the VM Bigot s and the OS Bigots (not that, other than in the sense of gentle rivalry, I've ever found this to exist among real systems programmers - who seem eager to take apart anything and everything to find out how it works - or was that, "worked" <oops>). Regards Jeff Gribbin
