Re: Historical curiousity question.

2007-03-16 Thread Jeff Gribbin, EDS
Chris Langford has already stated the fundamental answer to the original question - I'll re-state it for emphasis before we fly off on too many tangents and it gets lost: To allow complete virtualisation of minidisks of any size up to and including full-pack. Virtualising a full-pack

Re: Historical curiousity question.

2007-03-16 Thread Alan Altmark
On Friday, 03/16/2007 at 10:32 CET, Rob van der Heij [EMAIL PROTECTED] wrote: Suppose IBM would come up with something on the HMC to maintain the CP directory. An easy-to-use GUI application that talked to CP through some new hack in the SCLP area. That would make it impossible to run VM

Re: Historical curiousity question.

2007-03-16 Thread Rob van der Heij
On 3/16/07, Alan Altmark [EMAIL PROTECTED] wrote: Sir, let's not throw the baby out with the bathwater, eh? There are all sorts of places where the underlying hardware does *not* shine through to the guest. Example: the integrated 3270 console. VM continues to run under VM just fine, albeit

Re: Historical curiousity question.

2007-03-16 Thread Tom Duerbusch
Why, is easy CMS was developed in the '60s. There was no concept of PCs or their disk structure at that time. Memory was very expensive (hence the 512 byte blocks) and disk was too expensive to waste. Most of what was going to be under CMS was files like we xedit with. Not data files.

Re: Historical curiousity question.

2007-03-15 Thread Dave Hansen
Perhaps an FST?

Re: Historical curiousity question.

2007-03-15 Thread Jim Vincent
It sounds like he is looking for something at the Volume level - more than just the contents of a single MDISK. He would like a mapping on the volume to show where all the mdisks are, owners, passwords, etc. The concept is interesting but it opens a few cans of worms, one of which being

Re: Historical curiousity question.

2007-03-15 Thread Mike Walter
Hmmm. I don't know the history, but can imagine some problems. 1) VOLSER=1 has n minidisks, defined in CP Object directory. 2) Now imagine that the disk is taken offline, perhaps for some DASD service. 3) And the CP Object directory is updated, re-allocating those minidisks to a new

Re: Historical curiousity question.

2007-03-15 Thread LOREN CHARNLEY
John, I have a PFKEY set up in MAINT to list mdisks in different ways, one of which might be what you are looking for. I actually run this every time I up date the directory and run an edit on it, I can spot an overlap on files easily this way also. PF06 DELAY DISKMAP USER#DIRMAP USER(GAPFILE

Re: Historical curiousity question.

2007-03-15 Thread McKown, John
-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

Re: Historical curiousity question.

2007-03-15 Thread David Boyes
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. 1) Back then, there *wasn't* much DASD to manage. VM

Re: Historical curiousity question.

2007-03-15 Thread Chris Langford
To support minidisks that already have a VTOC embedded i.e 'MDISK cuu devt 0 END volser' McKown, John wrote: This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be

Re: Historical curiousity question.

2007-03-15 Thread Alan Altmark
On Thursday, 03/15/2007 at 10:55 EST, McKown, John [EMAIL PROTECTED] wrote: 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

Re: Historical curiousity question.

2007-03-15 Thread Kris Buelens
2007/3/15, Alan Altmark [EMAIL PROTECTED]: On Thursday, 03/15/2007 at 10:55 EST, McKown, John [EMAIL PROTECTED] wrote: 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

Re: Historical curiousity question.

2007-03-15 Thread David Kreuter
um, at the risk of the wrath of Chuckie, not quite. The directory is treated as CP virtual storage. So some of it is usually resident (at least the index pages) and the rest is treated as nice preferred page i/o to the drct area. With storage sizes what they are these days, I'm thinking a lot

Re: Historical curiousity question.

2007-03-15 Thread Alan Altmark
On Thursday, 03/15/2007 at 10:01 CET, Kris Buelens [EMAIL PROTECTED] wrote: Alan, isn't the CP directory entirely stored in a CP dataspace nowadays? Well, sort of, but the parts of CP that want to read the directory don't know that. :-) The directory is memory mapped into the CP execution

Re: Historical curiousity question.

2007-03-15 Thread Dave Wade
--- McKown, John [EMAIL PROTECTED] wrote: This is not important, but I just have to ask this. Does anybody know why the original designers of VM did not do something for minidisks akin to a OS/360 VTOC? Actually, it would be more akin to a partition table on a PC disk. It just seems that

Re: Historical curiousity question.

2007-03-15 Thread Lloyd Fuller
On Thu, 15 Mar 2007 12:48:15 -0400, David Boyes wrote: 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