INFO-VAX Sun, 16 Sep 2007 Volume 2007 : Issue 505 Contents: Re: despair Re: despair Re: despair RE: despair Re: despair RE: despair Re: despair Re: despair OT: SCO files for chapter 11 bnkrupcy protection Re: TCP/IP Re: TCP/IP VMS as hypervisor ? Re: VMS as hypervisor ? RE: VMS as hypervisor ? Re: VMS as hypervisor ? Re: VMS as hypervisor ? Re: VMS as hypervisor ? ---------------------------------------------------------------------- Date: Sat, 15 Sep 2007 11:14:08 -0700 From: AEF Subject: Re: despair Message-ID: <1189880048.456268.306890@r29g2000hsg.googlegroups.com> On Sep 15, 1:35 pm, Ron Johnson wrote: > On 09/15/07 11:59, JF Mezei wrote: > > >>> $ ON ERROR THEN CONTINUE > >>> in front of a ALLOCATE command, that is just plain wrong. No debate. > > > You are perfectly right. One should use $ SET NOON instead. This would > > ensure the command procedure always completes succesfully. :-) :-) :-) > > Or allow the DCL writer to grab $STATUS and handle it as he sees fit. > > > AEF wrote: > > >> Please tell me what error from the ALLOCATE command would screw things > >> up and how. > > > Say this runs on the SYSTEM account (with allmighty privileges). Someone > > else has allocated the drive but is otherwise not being used. The > > allocate will fail, but other commands may succeed due to the fact that > > this account has all mighty privileges. First of all, maybe it's not run under the SYSTEM account. If ALLOCATE fails, then either INIT or BACKUP will fail and the code will exit. Additionally, ALLOCATEing a non-existent drive is a warning ($SEVERITY == "0"), not an error, and the code would continue even without the ON ERROR THEN CONTINUE. > > Of course, the command would then write the backup to whatever tape was > > physically in the drive, and it could be someone else's tape. Could it be that at this site no one else uses the tape drive? If that's the case, this won't happen and is therefore not a problem. > > Really? It won't hang on the ALLOCATE? > > Even if it didn't, how could it INIT a tape loaded by another process? What do you mean? A process does not load a tape. A human or robot does. But this gets back to my point that the devil is in the details. Could it be that at this site no one else loads tapes? If so, this is nothing to worry about. > > Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it > isn't necessary) and the job would have to hang there, sending > occasion OPCOM messages. > > -- > Ron Johnson, Jr. > Jefferson LA USA > [same old sig omitted] AEF ------------------------------ Date: Sat, 15 Sep 2007 13:45:12 -0700 From: AEF Subject: Re: despair Message-ID: <1189889112.251650.264200@n39g2000hsh.googlegroups.com> On Sep 15, 3:32 pm, Ron Johnson wrote: > On 09/15/07 13:14, AEF wrote: > > > On Sep 15, 1:35 pm, Ron Johnson wrote: > >> On 09/15/07 11:59, JF Mezei wrote: > > >>>>> $ ON ERROR THEN CONTINUE > >>>>> in front of a ALLOCATE command, that is just plain wrong. No debate. > >>> You are perfectly right. One should use $ SET NOON instead. This would > >>> ensure the command procedure always completes succesfully. :-) :-) :-) > >> Or allow the DCL writer to grab $STATUS and handle it as he sees fit. > > >>> AEF wrote: > >>>> Please tell me what error from the ALLOCATE command would screw things > >>>> up and how. > >>> Say this runs on the SYSTEM account (with allmighty privileges). Someone > >>> else has allocated the drive but is otherwise not being used. The > >>> allocate will fail, but other commands may succeed due to the fact that > >>> this account has all mighty privileges. > > > First of all, maybe it's not run under the SYSTEM account. Second of all, that would be a bad practice in and of itself! > > If ALLOCATE fails, then either INIT or BACKUP will fail and the code > > will exit. > > > Additionally, ALLOCATEing a non-existent drive is a warning ($SEVERITY > > == "0"), not an error, and the code would continue even without the ON > > ERROR THEN CONTINUE. > > >>> Of course, the command would then write the backup to whatever tape was > >>> physically in the drive, and it could be someone else's tape. > > > Could it be that at this site no one else uses the tape drive? If > > that's the case, this won't happen and is therefore not a problem. > > Assuming that the system will be the same two years after you've > left is irresponsible. Those Who Remain will curse you, your > children and your children's children. So I should assume that while it's currently being used to back up recipes, I should pretend that its next mission will be to run a nuclear power plant? C'mon. You do what's appropriate for the job and add some safety factor. If the mission of the system changes, it's up to the crew converting the system to take care of these things. You don't put your food in a safe because there might be a famine tomorrow and hoodlums will be stealing everyone's food. > Besides, it's just plain Bad Programming. I said I didn't recommend it. Yes, it's not a good example of programming. But it's not as bad as the OP is making it out to be, especially since he can't tell us anything else about the site. Maybe it's backing up vital data. Maybe it's backing up a scratch disk. > >> Really? It won't hang on the ALLOCATE? > > >> Even if it didn't, how could it INIT a tape loaded by another process? > > > What do you mean? A process does not load a tape. A human or robot > > Sloppy terminology. I meant "mounted". Fine. Then the person who MOUNTed the tape should have ALLOCATEd the drive first, no? And set the write-protect feature if no writing was to be done to the tape. > > does. But this gets back to my point that the devil is in the details. > > Could it be that at this site no one else loads tapes? If so, this is > > nothing to worry about. > > >> Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it > >> isn't necessary) and the job would have to hang there, sending > >> occasion OPCOM messages. > -- > Ron Johnson, Jr. > Jefferson LA USA > [...same old sig omitted again...] AEF ------------------------------ Date: Sat, 15 Sep 2007 13:53:12 -0700 From: AEF Subject: Re: despair Message-ID: <1189889592.628681.249960@50g2000hsm.googlegroups.com> On Sep 15, 4:45 pm, AEF wrote: > On Sep 15, 3:32 pm, Ron Johnson wrote: > > > On 09/15/07 13:14, AEF wrote: > > > > On Sep 15, 1:35 pm, Ron Johnson wrote: > > >> On 09/15/07 11:59, JF Mezei wrote: > > > >>>>> $ ON ERROR THEN CONTINUE > > >>>>> in front of a ALLOCATE command, that is just plain wrong. No debate. > > >>> You are perfectly right. One should use $ SET NOON instead. This would > > >>> ensure the command procedure always completes succesfully. :-) :-) :-) > > >> Or allow the DCL writer to grab $STATUS and handle it as he sees fit. > > > >>> AEF wrote: > > >>>> Please tell me what error from the ALLOCATE command would screw things > > >>>> up and how. > > >>> Say this runs on the SYSTEM account (with allmighty privileges). Someone > > >>> else has allocated the drive but is otherwise not being used. The > > >>> allocate will fail, but other commands may succeed due to the fact that > > >>> this account has all mighty privileges. > [...] > > >> Really? It won't hang on the ALLOCATE? > > > >> Even if it didn't, how could it INIT a tape loaded by another process? > > > > What do you mean? A process does not load a tape. A human or robot > > > Sloppy terminology. I meant "mounted". > > Fine. Then the person who MOUNTed the tape should have ALLOCATEd the > drive first, no? And set the write-protect feature if no writing was > to be done to the tape. And second: What kind of place is allowing users to mount tapes on drives used for system backups? I find it a bit odd to find fault with one thing by saying that some other stupid thing could happen, which in and of itself has its own problems. We're not going to get system backups done if users are using the same drive, regardless of the dopiness of the DCL code snippet, are we now? By the same logic: Building a house is a bad idea because it might burn down! :-) > > > does. But this gets back to my point that the devil is in the details. > > > Could it be that at this site no one else loads tapes? If so, this is > > > nothing to worry about. > > > >> Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it > > >> isn't necessary) and the job would have to hang there, sending > > >> occasion OPCOM messages. > > -- > > Ron Johnson, Jr. > > Jefferson LA USA > > [...same old sig omitted again...] > > AEF ------------------------------ Date: Sat, 15 Sep 2007 16:26:31 -0500 From: "Paul Raulerson" Subject: RE: despair Message-ID: <000b01c7f7df$15b32c60$41198520$@com> > And second: What kind of place is allowing users to mount tapes on > drives used for system backups? I find it a bit odd to find fault with > one thing by saying that some other stupid thing could happen, which > in and of itself has its own problems. We're not going to get system > backups done if users are using the same drive, regardless of the > dopiness of the DCL code snippet, are we now? > Well, I don't know about VMS, but it certainly isn't a problem in the mainframe world. That is what tape libraries and enterprise backups systems like (grrrrr) Tivoli are for. Doesn't VMS have equivalent tape management and backup systems? I haven't looked because it is way overkill for what I need, but surely it exists? Not that the issue under discussion is using one, mind you... -Paul ------------------------------ Date: Sat, 15 Sep 2007 17:56:13 -0500 From: Ron Johnson Subject: Re: despair Message-ID: On 09/15/07 16:26, Paul Raulerson wrote: >> And second: What kind of place is allowing users to mount tapes on >> drives used for system backups? I find it a bit odd to find fault with >> one thing by saying that some other stupid thing could happen, which >> in and of itself has its own problems. We're not going to get system >> backups done if users are using the same drive, regardless of the >> dopiness of the DCL code snippet, are we now? >> > > Well, I don't know about VMS, but it certainly isn't a problem in the > mainframe world. > That is what tape libraries and enterprise backups systems like (grrrrr) > Tivoli are for. > > Doesn't VMS have equivalent tape management and backup systems? I haven't > looked because it > is way overkill for what I need, but surely it exists? Sure. ABS and (my favorite, because ABS hasn't supported Rdb in many years) SLS. MRU for direct robot control. There is also a Veritas(?) client for VMS. Sadly, SLS was not ported to Itanium. > Not that the issue under discussion is using one, mind you... -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sun, 16 Sep 2007 01:44:09 +0000 From: "Main, Kerry" Subject: RE: despair Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: September 15, 2007 6:56 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: despair > > On 09/15/07 16:26, Paul Raulerson wrote: > >> And second: What kind of place is allowing users to mount tapes on > >> drives used for system backups? I find it a bit odd to find fault > with > >> one thing by saying that some other stupid thing could happen, which > >> in and of itself has its own problems. We're not going to get system > >> backups done if users are using the same drive, regardless of the > >> dopiness of the DCL code snippet, are we now? > >> > > > > Well, I don't know about VMS, but it certainly isn't a problem in the > > mainframe world. > > That is what tape libraries and enterprise backups systems like > (grrrrr) > > Tivoli are for. > > > > Doesn't VMS have equivalent tape management and backup systems? I > haven't > > looked because it > > is way overkill for what I need, but surely it exists? > > Sure. ABS and (my favorite, because ABS hasn't supported Rdb in > many years) SLS. MRU for direct robot control. > > There is also a Veritas(?) client for VMS. > > Sadly, SLS was not ported to Itanium. > > > Not that the issue under discussion is using one, mind you... > A few examples of other backup alternatives: ISE Enterprise backup (OpenVMS): http://www.i-s-e.com/Products/EnterpriseBACKUP/index.html TapeSys for OpenVMS: http://www.softwarepartners.com/products/ Netbackup V6 client for OpenVMS: ftp://ftp.emea.support.veritas.com/pub/support/Products/NetBackup_OpenVMS HP Data Protector for OpenVMS: http://h18006.www1.hp.com/products/storage/software/dataprotector/index.htm= l Tivoli Backup option for OpenVMS: http://storsol.com/main.cfm?menu=3D3&submenu=3D3&detail=3Dinclude/abcovervi= ew.cfm Legato (EMC) Networker for OpenVMS: http://software.emc.com/products/software_az/networker.htm?hlnav=3DT Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 15 Sep 2007 19:47:44 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189910864.530819.280140@w3g2000hsg.googlegroups.com> On Sep 15, 10:39 am, AEF wrote: > Please tell me what error from the ALLOCATE command would screw things > up and how. True, attempting to allocate an already-owned device results in a warning. Clearly, instead of $ ON ERROR THEN CONTINUE the handler should state $ ON WARNING THEN GOTO ABORT_THIS_JOB > What error from INIT would screw things up? My experience is that when > INIT fails, it's an F error. Obviously, the message is %SYSTEM-F-DEVMOUNT, device is already mounted and, has been pointed out to you already, a severe error (-F-) will be trapped by an ON ERROR handler. > Relax, dude! The world is not going to end because of this command > procedure. I never said that. It's wrong, and your slacker attitude is exactly why it's wrong. Who are you to _not_ do your best work? You clearly have a decent grasp on this subject, yet you're trying to argue that it makes a difference whether the tapes get changed daily. WHAT THE HELL DOES THAT MATTER? It's a command procedure and should be written as best you can, in anticipation of things going wrong, because things *will* go wrong. I'm not talking about wild, extremely unlikely acts. I'm talking about "someone left the wrong tape in" or "someone else is using the drive and in fact allocated it" or "someone else is the operator now and is using the tape drive in a different manner than when this command procedure was coded". I'm upset that someone could have written this correctly but didn't, because there's no excuse. I'm not going to relax. I'm going to educate, if the culprit is willing to learn, or rant, if he is not. I've seen too much sloth and ignorance over the years to be complacent about it. >>> Maybe it was written by a BOFH! >> Nah, the Bastard always knows exactly what he's doing. > Sorry, I disagree or missed your point (about BOFH). Then you aren't very familiar with him. His competence is very high. > I find it interesting that you get all upset over this code snippet > yet you can't even tell me if the tape is changed daily! You appear to > know nothing at all about this environment except this code snippet. I fail to see how that matters in regard to the quality of this code. Nothing you can learn about the environment can justify that mistake. > How did you come across this code in the first place? What is your > role at this place that you have access to this code but still don't > know if the tape is ever changed? Because I saw this in the logfile: %SYSTEM-W-DEVALLOC, device already allocated to another user followed by the inevitable %SYSTEM-F-DEVMOUNT, device is already mounted and immediately thereafter %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK; -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP controller I certainly hope you do not regard this as an acceptable outcome. I certainly hope you agree that the INIT and BACKUP commands should not have been executed at all. > At my current job no one but me loads tapes. No one but me uses DCL on > the system. The tape drives are in the data center which is locked. > Only people who need access to the room are allowed in. So a command > procedure that would be okay at my site would not be okay at others. Well I think it's safe to say that my site is not as self-contained as yours, because the "impossible" did in fact happen. Good luck to you and your co-workers when it happens to you. > For example, you complained that the code didn't have a DEALLOCATE > command. Why is this a big problem? Could it not be, maybe, that no > one else ever uses this tape drive, in which case the lack of a > DEALLOCATE command is not a problem? Because it's simple decent programming. You allocate a resource, you deallocate it when you're done. You open a file, you close the file. You reserve an event flag, you free the event flag. You release the virtual memory you've grabbed when you're through with it. You don't *rely* on the operating system to do it for you via LOGINOUT.EXE. Why do I have to explain this to you? Nothing personal, since I have no idea who you are, but I wouldn't want you near any code I'm involved in, if you have such a slacker attitude towards cleaning up. You either have good habits or you're going to screw up . . . and from the number of posts I've seen from you arguing this point, I'm afraid it's the latter. ok dpm ------------------------------ Date: Sat, 15 Sep 2007 22:29:06 -0500 From: Ron Johnson Subject: Re: despair Message-ID: <6q1Hi.3288$OD5.806@newsfe22.lga> On 09/15/07 21:47, David P. Murphy wrote: [snip] > > Because it's simple decent programming. You allocate a resource, you > deallocate it when you're done. You open a file, you close the file. > You reserve an event flag, you free the event flag. You release the > virtual memory you've grabbed when you're through with it. You don't > *rely* on the operating system to do it for you via LOGINOUT.EXE. > Why do I have to explain this to you? I totally agree with you about the badness of slacker programming. However... why shouldn't I rely on LOGINOUT.EXE to deallocate my tape drives or free my VM? (Note that I did not comment on your other examples.) -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 15 Sep 2007 16:34:20 -0400 From: JF Mezei Subject: OT: SCO files for chapter 11 bnkrupcy protection Message-ID: http://www.news.com/8301-13580_3-9778778-39.html SCO having lost its big lawsuit against Novell has decided to file for chapter 11 bankrupcy protection before the judge decides on the financial penalties. This way, SCO is protected from having to pay Novell. This is not unexpected and I guess a bit welcome since SCO really had no business suing left and right. If VMS were allowed to be marketed, it might be able to benefit from this, adding stability despite constantly changing owners who don't want VMS :-) ------------------------------ Date: Sat, 15 Sep 2007 18:17:13 -0400 From: "Richard B. Gilbert" Subject: Re: TCP/IP Message-ID: <46EC59E9.1010707@comcast.net> David Goodwin wrote: > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. > > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? I believe that all three were derived from the BSD code. Multinet and TCPware are far older than UCX a/k/a TCP/IP Services for VMS and were mature products while DEC was still trying to get UCX to work. All three , AFAIK, are available at no/minimal cost to hobbyists. All three work (this wasn't always true of UCX ;-) ) Version 4.1 or 4.2 of UCX were the earliest versions that I would classify as useable. Anything before that, particularly v2.7--v3.3, was an absolute nightmare!! Virtually all my experience has been with UCX or TCP/IP Services for VMS as it is now called (or was the last time I looked). ------------------------------ Date: 15 Sep 2007 17:29:51 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: TCP/IP Message-ID: In article <46ebd015.2461449@news.clear.net.nz>, dgsoftnz@gmail.com (David Goodwin) writes: > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. The two were not originally made by the same company, so they have internal and management differences that are worth preserving for the respective installed bases of customers. But Process Software would be equally happy regardless of which one chooses, so there is no particular reason to distinguish the two sets of web pages. > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? Multinet provides the most secure method of doing DECnet over IP because it's PhaseIP facility supports DECnet Phase IV and the SET EXECUTOR DEFAULT ACCESS NONE capability. No doubt others will come up with other distinctions. ------------------------------ Date: Sat, 15 Sep 2007 20:40:35 -0400 From: JF Mezei Subject: VMS as hypervisor ? Message-ID: OK, So HP has made HP-UX capable of hosting multiple OS instances. (glorifided VM from IBM). Out of curiosity, would VMS be well suited for such a task ? What are the traits of a good OS to become a hypervisor ? In the case of IO, is it correct to state that VMS , as a hypervisor, would not actually be performing IO on bealf of the instances it hosts and that the later would have direct access to their disk drives ? Does HP-UX have advantages over VMS in terms of process switching, priority and general multi-tasking, or is VMS up to par on that aspect ? ------------------------------ Date: Sat, 15 Sep 2007 19:47:39 -0500 From: Ron Johnson Subject: Re: VMS as hypervisor ? Message-ID: On 09/15/07 19:40, JF Mezei wrote: > OK, So HP has made HP-UX capable of hosting multiple OS instances. > (glorifided VM from IBM). > > Out of curiosity, would VMS be well suited for such a task ? What are > the traits of a good OS to become a hypervisor ? > > In the case of IO, is it correct to state that VMS , as a hypervisor, > would not actually be performing IO on bealf of the instances it hosts > and that the later would have direct access to their disk drives ? > > Does HP-UX have advantages over VMS in terms of process switching, > priority and general multi-tasking, or is VMS up to par on that aspect ? ISTM that a hypervisor needs to be very "light", in order to minimize overhead. VMS is a lot of great things, but light it's not. Then again, if a VM is a single VMS process then whether process creation is quick or not shouldn't be a problem. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sun, 16 Sep 2007 01:06:02 +0000 From: "Main, Kerry" Subject: RE: VMS as hypervisor ? Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: September 15, 2007 8:48 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS as hypervisor ? > > On 09/15/07 19:40, JF Mezei wrote: > > OK, So HP has made HP-UX capable of hosting multiple OS instances. > > (glorifided VM from IBM). > > > > Out of curiosity, would VMS be well suited for such a task ? What are > > the traits of a good OS to become a hypervisor ? > > > > In the case of IO, is it correct to state that VMS , as a hypervisor, > > would not actually be performing IO on bealf of the instances it > hosts > > and that the later would have direct access to their disk drives ? > > > > Does HP-UX have advantages over VMS in terms of process switching, > > priority and general multi-tasking, or is VMS up to par on that > aspect ? > > ISTM that a hypervisor needs to be very "light", in order to > minimize overhead. VMS is a lot of great things, but light it's not. > > Then again, if a VM is a single VMS process then whether process > creation is quick or not shouldn't be a problem. > > -- > Ron Johnson, Jr. > Jefferson LA USA > > Give a man a fish, and he eats for a day. > Hit him with a fish, and he goes away for good! A hypervisor is typically a OS with a number of services disabled and speci= fic processes optimized for a particular task. Case in point is VMware which us= es a modified Linux kernel. OpenVMS has always been a pretty good real time OS, so I do not know why it= could not be optimized for something like this. Course, one needs to be careful of licensing issues e.g. VMware and Linux a= re having some interesting IP "discussions" these days. http://www.venturecake.com/the-vmware-house-of-cards/ Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 15 Sep 2007 22:06:36 -0500 From: "Lee K. Gleason" Subject: Re: VMS as hypervisor ? Message-ID: "JF Mezei" wrote in message news:dd217$46ec7b84$cef8887a$24782@TEKSAVVY.COM... > OK, So HP has made HP-UX capable of hosting multiple OS instances. > (glorifided VM from IBM). > > Out of curiosity, would VMS be well suited for such a task ? What are > the traits of a good OS to become a hypervisor ? > > In the case of IO, is it correct to state that VMS , as a hypervisor, > would not actually be performing IO on bealf of the instances it hosts > and that the later would have direct access to their disk drives ? > > Does HP-UX have advantages over VMS in terms of process switching, > priority and general multi-tasking, or is VMS up to par on that aspect ? This while virtualization movement is a bit of a puzzle to me. When I question it, the PC types at work tell me it's great, since you can run lots of different things on the same machine, and can buy fewer servers. Since VMS already has a decent scheduler and excellent inter-process memory protection and resource allocation, I'm always left wondering, why couldn't they just use an operating system that can allow you to "run lots of different things on the same machine", each in their own process? That way you don't have to drag the overhead of a whole copy of Windows along with each separate thing you want to do. As they try to explain, I often feel like President Not Sure, listening to his cabinet tell him about the electrolytes in Brawndo (if you;'ve seen Idiocracy...). -- ------------------------------ Date: Sat, 15 Sep 2007 22:11:24 -0500 From: Ron Johnson Subject: Re: VMS as hypervisor ? Message-ID: On 09/15/07 20:06, Main, Kerry wrote: [snip] > > A hypervisor is typically a OS with a number of services disabled and specific > processes optimized for a particular task. Case in point is VMware which uses Well, duh. > a modified Linux kernel. And the source code to the modified kernel *is* available. http://www.vmware.com/download/vi/open_source.html > OpenVMS has always been a pretty good real time OS, so I do not know why it could > not be optimized for something like this. > > Course, one needs to be careful of licensing issues e.g. VMware and Linux are > having some interesting IP "discussions" these days. How can a corporation have "discussions" with a piece of software? > http://www.venturecake.com/the-vmware-house-of-cards/ Interesting blog post. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 15 Sep 2007 22:38:19 -0500 From: Ron Johnson Subject: Re: VMS as hypervisor ? Message-ID: On 09/15/07 22:06, Lee K. Gleason wrote: > "JF Mezei" wrote in message > news:dd217$46ec7b84$cef8887a$24782@TEKSAVVY.COM... >> OK, So HP has made HP-UX capable of hosting multiple OS instances. >> (glorifided VM from IBM). >> >> Out of curiosity, would VMS be well suited for such a task ? What are >> the traits of a good OS to become a hypervisor ? >> >> In the case of IO, is it correct to state that VMS , as a hypervisor, >> would not actually be performing IO on bealf of the instances it hosts >> and that the later would have direct access to their disk drives ? >> >> Does HP-UX have advantages over VMS in terms of process switching, >> priority and general multi-tasking, or is VMS up to par on that aspect ? > > This while virtualization movement is a bit of a puzzle to me. When I > question it, the PC types at work tell me it's great, since you can run lots > of different things on the same machine, and can buy fewer servers. Since > VMS already has a decent scheduler and excellent inter-process memory > protection and resource allocation, I'm always left wondering, why couldn't > they just use an operating system that can allow you to "run lots of > different things on the same machine", each in their own process? That way I've made that same comment myself... > you don't have to drag the overhead of a whole copy of Windows along with > each separate thing you want to do. In the Windows world, the answer is obvious, because Windows Sucks, and can't be trusted with more than one running process. In the Linux world, the only answers I can think of are: (a) If the box hits capacity, then moving one of the VMs to a new box is trivial. (b) Upgrading one app might require an upgrade to, for example, libc. That would entail certifying all of the (possibly many apps on the box. With VMs, only that one VM would need libc6 upgraded and so only that single app would need to be certified. > As they try to explain, I often feel > like President Not Sure, listening to his cabinet tell him about the > electrolytes in Brawndo (if you;'ve seen Idiocracy...). -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ End of INFO-VAX 2007.505 ************************