Re: Volume with minidisks has no allocation information
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
Re: Volume with minidisks has no allocation information
Actually, writing DSORG PS or DA from CMS is also not too bad if you know what you are doing. There used to be a product offered by Adessa called Write OS (WOS). We used it for several years back in the late '80s and early '90s. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Gribbin, EDS Sent: Tuesday, June 27, 2006 12:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: Volume with minidisks has no allocation information 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
Re: Volume with minidisks has no allocation information
Only slightly off topic, but long ago, just to see what would happen, we allocated an MVS dataset, and then mapped a CMS minidisk over the dataset's allocation, and everyone was still happy and running. As long as everyone agrees to what's been done, there shouldn't be any fussing. -- Robert P. Nix Mayo Foundation RO-OC-1-13 200 First Street SW 507-284-0844Rochester, MN 55905 - In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: Volume with minidisks has no allocation information
Works fine, for now. Just overlaying minidisks (or a minidisk over a full pack minidisk), will work just fine, until the other side tried to write on it. In this case, if you do a CMS Format, your MVS file will be wiped out. If the mdisk doesn't overlay the MVS VTOC, MVS will still report the file exists. But when you open the file to read it, there will be a suprise for you. If you are using an automated tool, such as Dirmaint, (well, it wouldn't let you define overlapping mindisks in the first place), but if you force it, it may do a CMS Format for you. SOL Also, if the MVS volume was a dedicated volume, trying to put a minidisk on it, would do anything. If you try to link to it (or logon if it is defined to a user), you will get a message that the volume wasn't available. No harm, no foul. OTOH, if you map the entire MVS volume and link it to yourself, you can still ACCESS xxx Z, and use CMS utilities to read the datasets. LISTDS Z (EXTENT to see what is out there. Use FILEDEF or DLBL as JCL. And then use CMS programs to read (not write) the data. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 6/26/2006 4:45 PM Only slightly off topic, but long ago, just to see what would happen, we allocated an MVS dataset, and then mapped a CMS minidisk over the dataset's allocation, and everyone was still happy and running. As long as everyone agrees to what's been done, there shouldn't be any fussing. -- Robert P. Nix Mayo Foundation RO-OC-1-13 200 First Street SW 507-284-0844Rochester, MN 55905 - In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: Volume with minidisks has no allocation information
I remember hearing about a site that had ALL of its VM volumes available to its MVS system and had MVS datasets for every minidisk defined. They had all of the CP areas listed as minidisks too (Checkpoint, Directory, Page, Spool, etc). I think they did FDR backups and were able to restore full minidisks. /Tom Kern --- Nix, Robert P. [EMAIL PROTECTED] wrote: Only slightly off topic, but long ago, just to see what would happen, we allocated an MVS dataset, and then mapped a CMS minidisk over the dataset's allocation, and everyone was still happy and running. As long as everyone agrees to what's been done, there shouldn't be any fussing. -- Robert P. Nix Mayo Foundation RO-OC-1-13200 First Street SW 507-284-0844 Rochester, MN 55905 - In theory, theory and practice are the same, but in practice, theory and practice are different. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Volume with minidisks has no allocation information
Tom Cluster wrote: Hello, VM experts, I'm preparing myself for teaching the mysteries of VSE and VM systems work and I'm reminded that when one prepares to teach something one discovers many holes and uncertainties in one's own knowledge. Today I thought I'd educate myself about IPL bootstrap records in case one of my students asks about them. My theory, which I wanted to test, was that they're written by ICKDSF whenever an INIT is done (for MVS and VSE volumes) or a CPVOL FORMAT is done (for VM volumes). Based on what I've seen today, this seems to be true. But while looking around our system I discovered a volume that had originally been created for VSE use as a full-pack minidisk. In other words, it had been prepared using ICKDSF INIT (which would have created a vtoc). However, somewhere along the way it was decided that this volume would have several minidisks on it. In other words, it was no longer to be a full-pack minidisk. CPVOL FORMAT was never used on this volume, so cylinder 0 was left unchanged, with no allocation information. (If it were to have allocation information, it would have been PERM for the whole volume.) My initial reaction was surprise, but then I figured that possibly CP can tolerate a volume without allocation information as long as its sole use is PERM. It sure seems to be true that such a volume needs only a VOL1 label to make CP happy. My question is this: is there any reason to be concerned about such a volume not having an allocation map? - Tom P.S. The IPL bootstrap records are different between VSE and VM, but since we're not IPLing using this volume, that isn't an issue. Tom Cluster County of Sonoma Santa Rosa, CA (707) 565-3384 (Tuesdays and Wednesdays only) Do not be concerned. The CP Owned volumes are the only ones that need the allocation map. As for the ipl bootstrap records, they are written by the SALIPL process for VM. It has been too many years for me to remember how they are written on the MVS based systems. Even if I remembered, it would probably still on it be current. Suffice it to say that they are written only on volumes that are explicitly intended to be IPL volumes, not on every volume. As long as a volume has been initialized with a volser that CP can read, the volume can be attached to SYSTEM and have minidisks on it. When a volume is changed from being OS or VSE format to one housing minidisks, it is probably advisable to format cylinder 0 with CPFMTXA (ICKDSF under the covers) to insure that it is not usable by that other platform as that could lead to data integrity problems if a dataset were to be allocated and written on the volume by mistake. While formatting cyl. 0, change the volume serial, also, as an extra measure of caution..
