Re: Historical curiousity question.
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 minidisk makes it intrinsically impossible to save hypervisor-related information on the physical pack that's being virtualised - there's nowhere to put it! Remember - one is virtualising HARDWARE - so there's no scope for, agreement with the (software running in the) guests to not use par t of the pack - at best this would lead to a less-than-complete virtualisation. CP-OWNED volumes are a different kettle of fish - they are specifically reserved for use by (and ownership of) CP itself - not guests. The fact that CP is generous enough to allow (guest) minidisk allocation of the parts that it does not wish to use itself (the, I'm not using these cylinders generally being flagged as, 'PERM' in the Allocation Table) - and even allow minidisk mapping of the parts that it DOES use - is a bonus. (This bonus is one that definitely fits in with VM's philosophy of only expecting grownups to play at system level - gun-bullet-foot - but, if you survive, a great way to learn!) Jeff (These opinions are entirely personal) Gribbin
Re: Historical curiousity question.
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 under VM unless also major parts of the HMC were virtualized (unlikely, at best you would have an option to deal with multiple VM images). 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 at a lower level of awareness of its surroundings. So we design CP to exist in an environment where he may be frustrated by the lack of underlying hardware functionality. When we reach a point that doing that becomes too expensive and can no longer tolerate missing function, we declare a new Architectural Level Set (ALS) and the Great Wheel begins another revolution. Further, you can rest assured that we will adjust CP to virtualize the new ALS so that we may continue with VM under VM. (We couldn't develop z/VM without it! :-) ) Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
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 at a lower level of awareness of its surroundings. I did not mean to say that imperfect virtualization is bad. It's an obvious trade-off and in most cases goodness because for virtualization to make sense you do not want to be bothered with the obligations that come with having all the bits in place. Virtualization works because you *can* abstract from details. What I tried to explain is that in-band controls means that CP takes part of the resources for itself, and hands out the rest to the guests. With out-of-band controls CP requires some other technology (outside the architecture) that it does not virtualize for a guest. At that point you're unable to stack. And the built-in 3270 that you bring up is indeed one of those, because CP does not virtualize it for the guest (unlike the line mode system console with VINPUT and friends). Fortunately we don't need that to be virtualized to run VM because we have something else that works. Rob
Re: Historical curiousity question.
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. The CMS minidisk structure is very efficient and very forgiving with crashes. It is very rare that a crash would corrupt a minidisk. And when CMS was put with CP, the only concern was being able to have multiple smaller minidisks mapped to a larger volume as efficiently as possible. Back in the early '70s, a programmer might cost you $10k. A MB of main memory might cost you $1M. With that type of cost difference, you solved what problems you could, with manpower. Most of us laughed when VSAM was announced. Buffersin memory? Forget that garbage! We are paging too much as it is. In '79 with the R*star white paper (when relational database concept was defined). Never going to work! Direct I/O! Now that works! I laugh at a lot of things we use to believe. And in 10 years, I will laugh at what I believe nowG Tom Duerbusch THD Consulting LOREN CHARNLEY [EMAIL PROTECTED] 3/15/2007 10:30 AM 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 INCLUDE LINKS#DIRECTXA (EDIT Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 7043 (704) 708-7043 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, March 15, 2007 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Historical curiousity question. 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 it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- 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. - NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Historical curiousity question.
Perhaps an FST?
Re: Historical curiousity question.
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 security. (Duck, I see Chuckie heading this way!!) ___ James Vincent Systems Engineering Consultant Nationwide Services Co., Technology Solutions Mainframe, z/VM and z/Linux Support One Nationwide Plaza 3-20-13 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5547Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 03/15/2007 10:46:54 AM: IBMVM@LISTSERV.UARK.EDU Perhaps an FST?
Re: Historical curiousity question.
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 VOLSER=22 and restored from tape. 4) Now whatever was wrong with access to VOLSER=11 is fixed and it is brought back online. The VTOC on 11 reflects the old minidisks and their locations, while the CP Object directory reflects the valid locations. Confusion abounds (likely because someone was not told what ensued - how good are YOUR communications?). My questions are, what is the problem and what are you trying to solve/improve? Most questions are inspired by something that happened. What happened in this case? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. McKown, John [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/15/2007 09:42 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Historical curiousity question. 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 it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- 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. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Historical curiousity question.
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 INCLUDE LINKS#DIRECTXA (EDIT Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 7043 (704) 708-7043 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, March 15, 2007 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Historical curiousity question. 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 it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- 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. - NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Historical curiousity question.
-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.
Re: Historical curiousity question.
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 systems have historically been smaller and lighter, and been relatively resource-poor compared to their OS-based siblings. Consider the original purpose of VM was to be a *migration aid* from OS/360 to later releases; it wasn't intended to be a permanent thing (at least not until real customers got their hands on it) so there wouldn't have been a lot of VM disk to manage. 2) Same with memory. Building a in-core table for all the possible minidisks would have been prohibitively expensive on a 2M machine (if I remember correctly, CP-67 would run on even smaller systems than that). The disk-based approach could handle small-memory machines and bigger ones with roughly equal performance.
Re: Historical curiousity question.
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 more akin to a partition table on a PC disk. It just seems that it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. Just curious. -- 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. .. For: [EMAIL PROTECTED] -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com
Re: Historical curiousity question.
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 information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
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 directory is memory resident so all this information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott Alan, isn't the CP directory entirely stored in a CP dataspace nowadays? -- Kris Buelens, IBM Belgium, VM customer support
Re: Historical curiousity question.
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 of the directory is resident. David From: The IBM z/VM Operating System on behalf of Alan Altmark Sent: Thu 3/15/2007 4:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Historical curiousity question. 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 information is instantly available, making for a very fast logon. Actually, it isn't. When a user logs on and a VMDBK is created for them, SOME of the information in the directory is cached in memory. Other things, such as LINK, require a trip to DASD. Since reading the user's directory entry is a relatively rare event, that's ok. Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
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 space (I think) and is paged in on demand, so a second reference might find the needed parts of the directory already in memory. I don't know all the gory details. Alan Altmark z/VM Development IBM Endicott
Re: Historical curiousity question.
--- 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 it would be easier to maintain if there was something on the physical disk which contained information about the minidisks on it. Perhaps with information such as: start cylinder, end cylinder, owning guest, read password, etc. CP owned volumes have an allocation map, this seems to me to be an extention of that concept. I don't know the answer, but in the historical context, putting directories on the DASD starts to get complex when running VM under VM using minidisks , not full-pack dasd. Historically you didn't have many DASD so you probably needed to do this for tested etc. How could the second level VM update the master directory on the front of the pack as all it can see is the extent defined as a minidisk?. And if it couldn't but it used second level mini disks, i.e. it subdivided its mini-disks into mini-mini disk you would not be able to (easily) migrate these back to the first level VM. It used to be quit common to have L2MAINT defined in your first level system, but using the same extents as minidisks as the L2 MAINT used I hope you follow this, as I am not sure I have explained it very well Dave. Just curious. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
Re: Historical curiousity question.
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 reason. 1) Back then, there *wasn't* much DASD to manage. VM systems have historically been smaller and lighter, and been relatively resource-poor compared to their OS-based siblings. Consider the original purpose of VM was to be a *migration aid* from OS/360 to later releases; it wasn't intended to be a permanent thing (at least not until real customers got their hands on it) so there wouldn't have been a lot of VM disk to manage. Was it? I was taught by some of the people that worked at Lincoln Labs that VM was a CE/SE training aid. That is why it was designed to so closely emulate a 360 Mod 50. You could break things and the CE/SE would learn how to detect what was broken and how to fix it. Lloyd User of VM and its cousin VP/CSS since 1975.
