> -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams > Sent: Thursday, March 15, 2007 10:23 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Historical curiousity question. > > Just a guess. > The CP Directory has information for each user. At logon time, > the information about a single user is available very quickly.
This makes sense to me. IIRC, the VM directory is memory resident so all this information is "instantly" available, making for a very fast logon. > If the information about how a disk was divided into minidisks was > stored in a "VTOC", do you remove it from the Directory, or do you > keep the information in two places? (Since there is a small VTOC on > CP volumes, it really could have been in the VTOC, probably with > different DSCB formats) I guess that I was thinking that the Directory would have something like z/OS "dataset name" for each minidisk. For example, instead of: MDISK 191 3390 10 199 UVOL01 WR RPASS WPASS MPASS something like: MDISK 191 3390 UVOL01 LVOL WR Where LVOL is the "dataset name" in the "VTOC" of volume UVOL01 which describes the extents of this minidisk allocation. > > If you remove it from the directory, then you greatly slow down logon > processesing, and lead to situations where if a volume is offline, > the system would not know that something was missing for the user. In the above example, if UVOL01 were offline, you could do the same thing as is now done by VM. > > If you keep it both places, which is the authoritative source? > I'd have to check the history, but I bet that the source Directory > was kept by hand originally, in a flat file, leading to even more > difficulties is keeping them in sync. Yes, I did that on VM/370. USER DIRECT and I had all the "old tools" where every volume had a pseudo-guest which "owned" all the "unused" space that could be used for minidisks. And if I needed to make a minidisk bigger - what a pain. IBM has greatly helped in this area since the 1980s. I am not having a problem at all with how things are done. I was just curious about why the original developers made "DASD management" such a burden on the sysprog. Especially in the early days. But performance could very well be the reason. Especially if they did not expect the system to be such a hit with users. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
