INFO-VAX Sun, 30 Nov 2008 Volume 2008 : Issue 640 Contents: Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO Re: Good example of C and MACRO HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Re: search list, surprising error, inconsistent behavior ucx Re: ucx Re: VMS SIG Tape released (last from me) Re: VMS, HP and the recession Re: VMS, HP and the recession RE: VMS, HP and the recession ---------------------------------------------------------------------- Date: Sun, 30 Nov 2008 03:13:49 -0800 (PST) From: johnwallace4@yahoo.co.uk Subject: Re: Good example of C and MACRO Message-ID: On Nov 29, 3:32=A0pm, Johnny Billquist wrote: > johnwalla...@yahoo.co.uk skrev: > > > > > On Nov 28, 12:54 am, Roger Ivie wrote: > >> On 2008-11-27, johnwalla...@yahoo.co.uk wro= te: > > >>> Now if you'd said the National > >>> Semiconductor NS16000 had been inspired by VAX with the additional > >>> design goals of modernisation, removal of cruft, and simple support > >>> for ROMable code, I'd have agreed with that. > >> Pfft. I've never understood how people can say that when the NS16000 > >> doesn't even have the PC as a general-purpose register. > >> -- > >> roger ivie > >> ri...@ridgenet.net > > > NS16000 wasn't a VAX clone (the Russians did those, right?), it wasn't > > even trying to be VAX compatible, but chunks of it might well have > > been VAX-inspired. Anyway, if you can still achieve all the relevant > > addressing modes using PC-relative addressing, module pointers, etc, > > which iirc the NS16000 could, what do you actually lose by not having > > the PC as a general register? (or is it my turn for a sense of humour > > failure?) Obviously you can't do the usual party tricks like MOV - > > (R7), -(R7) like some PDP11s could, but so what? Anyway, history has > > shown that a nice instruction set architecture is not necessarily > > guarantee of, or even a prerequisite for, market success. Not then, > > not now. > > The big point of having the PC as a general register is that you don't ne= ed > special opcodes for the instructions when you want to address things > PC-relative. It's just a normal addressing mode, with a general register. > It makes a lot of things easier. But sure, you can accomplish the same th= ing > without that feature. But it makes life more difficult. > > Let me give you an example: > The 68K are pretty inspired by the PDP11 and VAX. But they don't have the= PC as > a general register. Instead you have specific opcodes for variations of t= he > instruction. Take CMP (compare) - in the 68K you have compare, and you ha= ve > compare immediate. > In an assembler, you'd write > > =A0 =A0 =A0 =A0 CMP.B =A0 #'A,D0 > > for instance. And the assembler would know that that's actually a special > version of CMP.B, which takes one immediate argument, and one (data) regi= ster. > If you instead wrote > > =A0 =A0 =A0 =A0 CMP.B =A0 D0,D1 > > it would assemble to another opcode. > > And you might say "so what". That's all the responsobility of the assembl= er, and > I as a programmer don't have to worry or think about it. And it causes th= e same > end result as if you would have programmed on a PDP11 or a VAX. > > All very true. But consider this. On a PDP11 or a VAX, you could also hav= e > written this: > > =A0 =A0 =A0 =A0 CMPB =A0 =A0R0,#'A > > and you just can't do that on a 68K. The immediate mode argument can only= be the > first argument, since it's actually a different opcode, and not a generic > argument to the CMPB instruction (or CMP.B as it would be called on a 68K= ). > > And no, it's not the same. While one can be replaced by the other, they w= ill > cause different results in the condition codes, and code following it wil= l have > to be adjusted accordingly. And if you write in assembler, you would prob= ably > prefer the code to reflect your through instead of having to be adjusted = to fit > into what can be expressed by the instruction set. > > There are a whole bunch of variations that can't be expressed because the= 68K > have several different opcodes for CMP which caters to various special > situations. It's all a *mess*! > > > I think Ritchie's in-depth history of C (http://cm.bell-labs.com/cm/cs/ > > who/dmr/chist.html) says the auto-increment/auto-decrement stuff came > > from PDP7. > > I doubt it. The PDP7 don't stuff like that, and besides, C wasn't designe= d until > they had moved to the PDP-11. The first few versions of Unix on the PDP-1= 1 was > still written in assembler before they moved to C. > > But Ritche have also been very clear that the autoincrement and autodecre= ment > elements in C were *not* inspired by the PDP-11. > > =A0 =A0 =A0 =A0 Johnny > > -- > Johnny Billquist =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| "I'm on a bus > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0||= =A0on a psychedelic trip > email: b...@softjar.se =A0 =A0 =A0 =A0 =A0 =A0 || =A0Reading murder books > pdp is alive! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 || =A0tryin' to sta= y hip" - B. Idol Thank you for that. As luck would have it, I'm personally well aware that the 68K didn't/doesn't do PC-relative addressing of any form, which as you point out can be considered a bit of a limitation. But the NS16000 isn't a 68K, it had few of the sillinesses of the 68K and much of the goodness of the VAX. My recollection is that anything you could do with PC-relative addressing, you could do on the NS16000 (eg position-independent ROMable code, and more). Iirc the NS16000 did PC- relative addressing transparently to the user, without needing special instructions and without needing the PC as a typical general register, it did it by using a dedicated PC-relative addressing mode, but I can't be sure without digging out my books. In addition to the PC- relative addressing mode it definitely also had something called (iirc) a module pointer, which could be used to achieve similar results. Wrt the relationship between PDP7 and C: I'm not going to attempt to summarise the relevant bit of a long story in Ritchie's article again. If you disagree with bits of my previous summary, please read what Ritchie wrote (it's compatible with most of what you wrote, apart perhaps from the PDP7 bit). ------------------------------ Date: Sun, 30 Nov 2008 14:16:04 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Good example of C and MACRO Message-ID: =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >Richard B. Gilbert wrote: >> A six bit >> code is sufficient to give you the alphabet, the decimal digits, and >> common punctuation with a few characters left over. > > It's not clear to me that there is any point in packing six characters > > into a "REAL*4". >There are not room for 6 codes of 6 bit in 4 byte either. >That only gives 5.33 bit per character. RAD50 gives a character set of 40 characters (50 octal). That's the letters A-Z uppercase, digits 0-9, space, two other punctuation characters and one code which I think was never defined. I believe this is how PDP-11 operating systems stored file names (a 6.3 name with an implicit period could be stored as 3 words/6 bytes). ------------------------------ Date: 30 Nov 2008 14:46:30 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-o3F974HdWwBP@rikki.tavi.co.uk> On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com (Michael Moroney) wrote: > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > > >Richard B. Gilbert wrote: > > >> A six bit > >> code is sufficient to give you the alphabet, the decimal digits, and > >> common punctuation with a few characters left over. > > > > It's not clear to me that there is any point in packing six characters > > > into a "REAL*4". > > >There are not room for 6 codes of 6 bit in 4 byte either. > > >That only gives 5.33 bit per character. > > RAD50 gives a character set of 40 characters (50 octal). That's the > letters A-Z uppercase, digits 0-9, space, two other punctuation characters > and one code which I think was never defined. I believe this is how PDP-11 > operating systems stored file names (a 6.3 name with an implicit period > could be stored as 3 words/6 bytes). I said there'd be a pedant along in a minute! Arne is being the pedant - saying that it's not ASCII without a full character set... Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored filenames in RAD50. And I think MACRO-11 stored symbols like that. -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Sun, 30 Nov 2008 09:54:59 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <4932a941$0$90274$14726298@news.sunsite.dk> Michael Moroney wrote: > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Richard B. Gilbert wrote: >>> A six bit >>> code is sufficient to give you the alphabet, the decimal digits, and >>> common punctuation with a few characters left over. > >>> It's not clear to me that there is any point in packing six characters >>> into a "REAL*4". > >> There are not room for 6 codes of 6 bit in 4 byte either. > >> That only gives 5.33 bit per character. > > RAD50 gives a character set of 40 characters (50 octal). That's the > letters A-Z uppercase, digits 0-9, space, two other punctuation characters > and one code which I think was never defined. I am able to lookup RADIX-50. The point is that 2^5.33 is 40.2 (I think it is 40.3 without the two decimal rounding). So the 40 characters matches exactly with the requirement to store 6 characters in 4 bytes. Arne ------------------------------ Date: 30 Nov 2008 15:17:27 GMT From: "Bob Eager" Subject: Re: Good example of C and MACRO Message-ID: <176uZD2KcidF-pn2-1nZCS4GdICTm@rikki.tavi.co.uk> On Sun, 30 Nov 2008 14:54:59 UTC, Arne Vajhj wrote: > Michael Moroney wrote: > > =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > >> Richard B. Gilbert wrote: > >>> A six bit > >>> code is sufficient to give you the alphabet, the decimal digits, and > >>> common punctuation with a few characters left over. > > > >>> It's not clear to me that there is any point in packing six characters > >>> into a "REAL*4". > > > >> There are not room for 6 codes of 6 bit in 4 byte either. > > > >> That only gives 5.33 bit per character. > > > > RAD50 gives a character set of 40 characters (50 octal). That's the > > letters A-Z uppercase, digits 0-9, space, two other punctuation characters > > and one code which I think was never defined. > > I am able to lookup RADIX-50. > > The point is that 2^5.33 is 40.2 (I think it is 40.3 without > the two decimal rounding). > > So the 40 characters matches exactly with the requirement to > store 6 characters in 4 bytes. Yes...DEC did that calculation about 40 years ago! -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 30 Nov 2008 15:30:03 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pfprrF7rqi0U1@mid.individual.net> In article <4931cb5a$0$90270$14726298@news.sunsite.dk>, Arne Vajhøj writes: > Bill Gunshannon wrote: >> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>, >> Arne Vajhøj writes: >>> Bill Gunshannon wrote: >>>> OK. But what about storing 6 ASCII characters packed into one REAL*4 >>>> variable? :-) >>> Not possible in general. There are 128^6 possible combinations >>> of bits in 6 ASCII characters and 256^4 possible combinations of >>> bits in a REAL*4. >> >> Not possible? I really expected someone to recognize RAD50 (aka RADIX-50) >> when I posted this. :-) > > What does ASCII have to do with RADIX-50 ? It's all about ASCII. DUMP /X : Output RAD50 characters SYSLIB CALLS: IRAD50 - n = IRAD50(icnt,input,output) Converts ASCII characters to RAD50, returning the number of characters conerted. R50ASC - CALL R50ASC(icnt,input,output) Converst RAD50 characters to ASCII. RAD50 - n = RAD50(input) Converts six ASCII characters, returning a REAL*4 result which is the 2-word RAD50 value. Think RT-11 Filenames...... Or, just lookup RADIX-50 on wiki. Sometimes it's fun being a dinosaur. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 30 Nov 2008 15:34:30 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pfq46F7rqi0U2@mid.individual.net> In article <4931cc41$0$90272$14726298@news.sunsite.dk>, Arne Vajhøj writes: > Bill Gunshannon wrote: >> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>, >> Arne Vajhøj writes: >>> Bill Gunshannon wrote: >>>> Ah yes, Ada. I remember hearing about all the bad things that C does >>>> that Ada doesn't, which is what made Ada so superior. Until you look >>>> at the last chapter of the Ada textbook they used here that basicly >>>> showed how to get around all that string typecasting stiff. :-) And >>>> all kinds of other dirty little tricks that someone decided really were >>>> necesary writing programs in the real world. >>> There is a big difference between allowing the dirty stuff by >>> special means and allowing it generally. >>> >>> C++ asm and C# unsafe is not bad in my book, because they >>> are clearly identifiable as dirty. >> >> My point was that the Ada advocates (and we used to have a real big >> one here) were constantly talking about all the bad features of C and >> similar languages. But then, when it came time to get real, Ada had >> to include all those "bad" things in order for the language to do the >> things it was intended for like twiddle with real hardware. If there >> is a way to apply the term hypocrite Ada fits the bill. :-) > > As long as it is clearly identifiable as bing the dirty stuff, then > I don't see a problem or any hypocracy. > > But without you explaining what Ada tricks you are talking about, > then it is hard to tell. > > I have given two examples from C++ and C# of what I mean. > > My Ada skills are not good enough to guess what you are talking > about. Probably I have only learned the nice Ada (and what I > did learn looked very nice indeeed). Anything that can be done in C can be done in Ada. Including things like pointer arithmetic, character arithmetic and shifting data between data types. The main point being that while people complained about the dangers of a language that could do these things when it came down to real world (and, especially real time) programming, they wre necessary evils. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 30 Nov 2008 10:38:47 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Good example of C and MACRO Message-ID: <4932b384$0$90268$14726298@news.sunsite.dk> Bill Gunshannon wrote: > In article <4931cb5a$0$90270$14726298@news.sunsite.dk>, > Arne Vajhøj writes: >> Bill Gunshannon wrote: >>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>, >>> Arne Vajhøj writes: >>>> Bill Gunshannon wrote: >>>>> OK. But what about storing 6 ASCII characters packed into one REAL*4 >>>>> variable? :-) >>>> Not possible in general. There are 128^6 possible combinations >>>> of bits in 6 ASCII characters and 256^4 possible combinations of >>>> bits in a REAL*4. >>> Not possible? I really expected someone to recognize RAD50 (aka RADIX-50) >>> when I posted this. :-) >> What does ASCII have to do with RADIX-50 ? > > It's all about ASCII. > > DUMP /X : Output RAD50 characters > > SYSLIB CALLS: > > IRAD50 - n = IRAD50(icnt,input,output) > Converts ASCII characters to RAD50, returning the number of characters > conerted. > R50ASC - CALL R50ASC(icnt,input,output) > Converst RAD50 characters to ASCII. > RAD50 - n = RAD50(input) > Converts six ASCII characters, returning a REAL*4 result which is the > 2-word RAD50 value. > > Think RT-11 Filenames...... > > Or, just lookup RADIX-50 on wiki. > > Sometimes it's fun being a dinosaur. :-) The fact that RADIX-50 characters can be converted to and from ASCII does not make them ASCII. Arne ------------------------------ Date: Sun, 30 Nov 2008 15:51:13 GMT From: "Tim E. Sneddon" Subject: Re: Good example of C and MACRO Message-ID: John Reagan wrote: > "Michael Kraemer" wrote in message > news:ggljto$85k$00$2@news.t-online.com... >> Richard B. Gilbert schrieb: >> >>> Assembler language programming is just about dead. The only time it's >>> really necessary is when you are bootstrapping a new hardware platform. >>> Even device drivers are now written in C. >> Not every CPU instruction has an equivalent HL construct. >> Think of byte swapping or "compare & swap" and friends. >> >> > > Our C compiler (and BLISS and Pascal) have builtins to let you access such > atomic sequences. You don't need asm() and you don't need to write in > assembler. > > On I64, the only place where assembler makes sense is where you are way > outside the Calling Standard doing argument shuffling. VMS' exception > handling comes to mind. > So does the internal jacketing done by TIE when going from the VAX or Alpha to Itanium environments and back the other way. Tim. ------------------------------ Date: Sun, 30 Nov 2008 10:58:42 -0500 From: "Richard B. Gilbert" Subject: Re: Good example of C and MACRO Message-ID: <1r2dnVpZ-e90Kq_UnZ2dnUVZ_obinZ2d@giganews.com> Bill Gunshannon wrote: > In article <4931cc41$0$90272$14726298@news.sunsite.dk>, > Arne Vajhøj writes: >> Bill Gunshannon wrote: >>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>, >>> Arne Vajhøj writes: >>>> Bill Gunshannon wrote: >>>>> Ah yes, Ada. I remember hearing about all the bad things that C does >>>>> that Ada doesn't, which is what made Ada so superior. Until you look >>>>> at the last chapter of the Ada textbook they used here that basicly >>>>> showed how to get around all that string typecasting stiff. :-) And >>>>> all kinds of other dirty little tricks that someone decided really were >>>>> necesary writing programs in the real world. >>>> There is a big difference between allowing the dirty stuff by >>>> special means and allowing it generally. >>>> >>>> C++ asm and C# unsafe is not bad in my book, because they >>>> are clearly identifiable as dirty. >>> My point was that the Ada advocates (and we used to have a real big >>> one here) were constantly talking about all the bad features of C and >>> similar languages. But then, when it came time to get real, Ada had >>> to include all those "bad" things in order for the language to do the >>> things it was intended for like twiddle with real hardware. If there >>> is a way to apply the term hypocrite Ada fits the bill. :-) >> As long as it is clearly identifiable as bing the dirty stuff, then >> I don't see a problem or any hypocracy. >> >> But without you explaining what Ada tricks you are talking about, >> then it is hard to tell. >> >> I have given two examples from C++ and C# of what I mean. >> >> My Ada skills are not good enough to guess what you are talking >> about. Probably I have only learned the nice Ada (and what I >> did learn looked very nice indeeed). > > Anything that can be done in C can be done in Ada. Including things > like pointer arithmetic, character arithmetic and shifting data between > data types. The main point being that while people complained about > the dangers of a language that could do these things when it came down > to real world (and, especially real time) programming, they wre necessary > evils. I think that the difference between Ada and C in this regard, is that Ada requires that, if you must do "bad" things, you do them in a disciplined and documented way. In C, anything goes. You can do the same things in C and Ada and your C code can be as clear and well documented as in Ada. Sadly, a lot of people do not write C in that fashion. "Man rated" software, that is software that can get someone killed if it's wrong, is frequently written in Ada because Ada makes it difficult to write poor code. I doubt that Ada can be written as quickly as C, but when you're done, you can have a great deal more confidence that it's done right. ------------------------------ Date: Sun, 30 Nov 2008 16:10:18 GMT From: "Tim E. Sneddon" Subject: Re: Good example of C and MACRO Message-ID: Bill Gunshannon wrote: > In article <176uZD2KcidF-pn2-Ygioq8GMIEPI@rikki.tavi.co.uk>, > "Bob Eager" writes: >> On Sat, 29 Nov 2008 16:42:31 UTC, billg999@cs.uofs.edu (Bill Gunshannon) >> wrote: >> >>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>, >>> "Bob Eager" writes: >>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj wrote: >>>> >>>>> Bill Gunshannon wrote: >>>>>> In article , >>>>>> Glen Herrmannsfeldt writes: >>>>>>> Arne Vajhj wrote: >>>>>>> >>>>>>>> C Kermit is from around 1989-1990. I believe that it >>>>>>>> took a few years until C-Kermit was stable enough to replace >>>>>>>> the old VMS Kermit. >>>>>>> Unix C kermit is older than that. For other than unix, >>>>>>> that might be about right. >>>>>>> >>>>>> The BLISS version worked just fine as far as I was concerned. >>>>> The Bliss version was rock solid. >>>>> >>>>> But if I remember correctly, then the C version had >>>>> better performance (due to ability to use larger >>>>> buffers or something like that). >>>> And sliding windows....allowing overlap between send and acknowledge. >>> Too bad there was no one to just add those features to the Bliss >>> version. Hmmmm... Might be fun to try. Especially for someone >>> like me who's only experience with Bliss is knowing it's reputation. >> The definitions are all in the Kermit protocol book. Probably still >> available used. > > I don't think knowledge of Kermit is the problem. Experience with Bliss > is another matter entirely. :-) > I disagree. I am a BLISS programmer. I'm sure I'm about to be shot down by somebody, but it's my prefered language. I found it quite easy to use when I started playing with it. I am aware of it's reputation. However, I don't think it it is deserved. It's all about the task you want to tackle. BLISS is incredibly flexible and allows for a very large degree of control by the programmer. It also has a brilliant macro language (which has already been pointed out before :-). Tim. ------------------------------ Date: Sun, 30 Nov 2008 16:28:13 GMT From: "Tim E. Sneddon" Subject: Re: Good example of C and MACRO Message-ID: Richard B. Gilbert wrote: > Bob Koehler wrote: >> In article , Glen Herrmannsfeldt >> writes: >>> Yes, but C descended from BCPL and B, which were older >>> than the PDP-11. >> >> Did BCPL or B have ++ and -- operators? Did they assume byte >> addressable memory and a built in stack? >> > > I suspect that the ONLY way to find out at this point would be to catch > Kernighan or Plauger and ask them. I'm not sure that either language > ever escaped from the research laboratories! B had the auto increment/decrement operators, like C. From what I've seen I think it was byte addressable on the PDP-11. It was word addressable on the Honeywell 6070. Tim. ------------------------------ Date: 30 Nov 2008 17:01:51 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Good example of C and MACRO Message-ID: <6pfv7uF7scc8U1@mid.individual.net> In article <1r2dnVpZ-e90Kq_UnZ2dnUVZ_obinZ2d@giganews.com>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article <4931cc41$0$90272$14726298@news.sunsite.dk>, >> Arne Vajhøj writes: >>> Bill Gunshannon wrote: >>>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>, >>>> Arne Vajhøj writes: >>>>> Bill Gunshannon wrote: >>>>>> Ah yes, Ada. I remember hearing about all the bad things that C does >>>>>> that Ada doesn't, which is what made Ada so superior. Until you look >>>>>> at the last chapter of the Ada textbook they used here that basicly >>>>>> showed how to get around all that string typecasting stiff. :-) And >>>>>> all kinds of other dirty little tricks that someone decided really were >>>>>> necesary writing programs in the real world. >>>>> There is a big difference between allowing the dirty stuff by >>>>> special means and allowing it generally. >>>>> >>>>> C++ asm and C# unsafe is not bad in my book, because they >>>>> are clearly identifiable as dirty. >>>> My point was that the Ada advocates (and we used to have a real big >>>> one here) were constantly talking about all the bad features of C and >>>> similar languages. But then, when it came time to get real, Ada had >>>> to include all those "bad" things in order for the language to do the >>>> things it was intended for like twiddle with real hardware. If there >>>> is a way to apply the term hypocrite Ada fits the bill. :-) >>> As long as it is clearly identifiable as bing the dirty stuff, then >>> I don't see a problem or any hypocracy. >>> >>> But without you explaining what Ada tricks you are talking about, >>> then it is hard to tell. >>> >>> I have given two examples from C++ and C# of what I mean. >>> >>> My Ada skills are not good enough to guess what you are talking >>> about. Probably I have only learned the nice Ada (and what I >>> did learn looked very nice indeeed). >> >> Anything that can be done in C can be done in Ada. Including things >> like pointer arithmetic, character arithmetic and shifting data between >> data types. The main point being that while people complained about >> the dangers of a language that could do these things when it came down >> to real world (and, especially real time) programming, they wre necessary >> evils. > > I think that the difference between Ada and C in this regard, is that > Ada requires that, if you must do "bad" things, you do them in a > disciplined and documented way. In C, anything goes. You can do the > same things in C and Ada and your C code can be as clear and well > documented as in Ada. Sadly, a lot of people do not write C in that > fashion. You are still missing the point. The anti-C crowd (and I see a lot of in the academic environment) don't attack the ease of use for those functions, they specifically att6ack the functions. Reality is that the functions are necessary for many tasks. > > "Man rated" software, that is software that can get someone killed if > it's wrong, is frequently written in Ada because Ada makes it difficult > to write poor code. One can write poor code in any language and no language prevents or even hinders it. Bad code starts long before one reaches the coding phase of SE. But then, there really isn't much SE in the business anymore. It should also be noted that although the USAF was the originator of the idea for Ada and a strong member of the committee that developed it when it was done and DOD tried to mandate it they were the first to refuse. To the best of my knowledge, Wright-Patterson is still using JOVIAL. :-) > > I doubt that Ada can be written as quickly as C, but when you're done, > you can have a great deal more confidence that it's done right. I can write Ada as quickly as I can write C. But then, for most real programming projects I get nvolved in the actual coding is only a small percentage of the time I spend. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 30 Nov 2008 14:41:33 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Message-ID: This is a long post involving the nitty-gritty of HBVS of a system disk. I hope I've included all relevant details. I'm really stumped! After that, perhaps related, are some questions about ANA/DISK/REPAIR. My standard procedure for installing patches: o Download the patches. o Unpack the patches onto the system disk. o Set VAXcluster to 0. (This is because, early in the startup sequence, I check for cluster membership and if the node is not in a cluster, I don't mount any disks except the system disk (most of which are on other nodes anyway), don't start TCPIP etc. First, I want to make sure that the patch installation had no obvious problems before re-entering the cluster and second, since I reboot after patch installation, it's not worth it to join the cluster just for the time of the patch installation. Of course, I don't mount the system disk explicitly.) o Shutdown. o Physically remove one member of the system-disk shadow set, so that I have a clean backup which I can boot from. (This is the important stuff---see below.) o Reboot. o Install the patches. (I have now added ANA/DISK/REPAIR at this stage.) o Set VAXcluster to 2. o Reboot (and re-enter the cluster). I am practically 100% certain that I have always followed this procedure when installing patches and that it has always worked. In particular, I don't recall changing the value of SHADOW_SYSTEM_DISK. Today, everything worked except the last step. After the first reboot, as expected, there was a console message about a missing shadow-set member and that a 1-member shadow set was being formed. So far, so good. This is an important feature of shadowing: if all members of the shadow set aren't there at boot time, boot from one which is there. When I tried the second reboot, the system hung right after joining the cluster. After about 8 minutes, a console message appeared saying that not all members of the shadow set were available! Then a memory dump was written and the system booted again (resulting in the same error, so I then halted it via the console switch). Some details. The node is a VAXstation 4000 90A with 80 MB RAM running 7.3. All shadowing patches are installed. In fact, all patches are installed except the ones I wanted to install: VAXMONT01_073 VAXSMGRMUP01_073 VAXTZ02_073 (Actually, I don't think any of these need a reboot, but that is beside the point: I like to follow the same procedure, an occasional reboot is necessary to change non-dynamic system parameters after AUTOGEN etc and since I have to reboot once anyway to be able to remove one member of the system-disk shadow set, I might as well reboot twice. Also, I don't want to be in the cluster if something goes wrong with the installation, since that might lead to strange side effects.) Both members of the system-disk shadow set are RZ28 SBBs in a BA-353 (pizza box). Inside the VAXstation, there is an RZ23L. In another expansion box, there are two further disks and a tape drive. (The second expansion box and the stuff in it is all non-DEC but a) I have been using it for years with no problem, b) all show up properly at the console SHOW DEVICE and c) the devices aren't mounted until the basic part of the startup is done.) At the console, BOOT is set to DKA100,DKA600, i.e. both members of the system-disk shadow set. Again, the idea is that if one is missing, it will boot from the other one. I believe it normally boots from the first in the list, DKA100. After the first shutdown, I pulled out DKA100. The system wouldn't boot from DKA600 (see above), whether specified explicitly or not. I tried going into SYSBOOT and setting SHADOW_SYSTEM_DISK to 0. Still coulnd't boot into the cluster. (Different error, though: "error mounting device" instead of "not all members found".) I tried the newer disk (patches applied) in the slot of the other disk (i.e. gave it the 100 address instead of 600). (I didn't try changing the address with the switches on the back of the BA353, but I'm sure that would have the same effect.) This gave an error that the disk was not part of the shadow set. (In all cases, all the errors came, after a few minutes, after the message that the cluster had been joined.) I then decided to bite the bullet and put both disks back where they were and reboot. This worked, booting from DKA100, but VAXCLUSTER was set to 0. I then changed it via SYSBOOT. Still wouldn't join the cluster: error mounting device. I then went into SYSBOOT, changed VAXcluster back to 0 and booted. As happened the first time I rebooted with both disks in place, only DKA100 went into the shadow set. I then mounted DKA600 back into the shadow set, causing a full copy (and getting me back to the original state, before patch application). I then set VAXcluster to 2 and this time it worked---I booted into the cluster. But, I was back where I started. Would things have been different had I removed DKA600 instead of DKA100, keeping in mind that the system normally boots from DKA100 since it is first in the list? On the other hand, if my only choice is to remove DKA600, then I couldn't boot at all if DKA100 happened to go bad (either from DKA600 or after changing the address of the DKA600 disk to 100). I think HBVS is more robust than that. I also don't think that, in the past, I always removed the second disk in the BOOT list. Should I have set SHADOW_SYSTEM_DISK to 0 before the first shutdown? However, the first reboot DID work and resulted in a single-member shadow set. Again, since one of the advantages of shadowing is that things will still work if a member goes bad, then they should also work if I physically remove a member after shutdown and before reboot. Summary: After removing one disk of the system-disk shadow set, DKA100, I installed patches and did ANA/DISK/REPAIR on DKA600, now a single-member shadow set. After a shutdown, I could not boot from DKA600 at all, whether or not VAXcluster was 0 or 2 and also not after moving it to the DKA100 slot. The ONLY way to boot was a) from the DKA100 disk (i.e. my "backup copy") and b) with VAXcluster set to 0. Only by then allowing a full copy DKA100 --> DKA 600 could I then boot into the cluster (i.e. with VAXcluster set to 2). I only tried it from DKA100, but I'm sure it would have booted from DKA600 as well. (I've certainly booted explicitly from the second device in the list before.) At the beginning of SYLOGICALS.COM, I write some output to the console. The startup sequence didn't get even that far. The last message was that the cluster had been joined. Additional question: ANA/DISK reported many messages such as: %ANALDISK-W-DELHEADER, file (709,2,0) DECW$TRANSPORT_COMMON.EXE;1 marked for delete ANA/DISK/REPAIR got rid of these. Also a few messages like: %ANALDISK-I-BADHIGHWATER, file (2449,1,0) SWAPFILE.SYS;1 inconsistent highwater mark and EFBLK which ANA/DISK/REPAIR did NOT change. Before the first reboot, there were only these messages (several of each type) and some additional single messages (see below). After the events described above, these original messages are there (again) (to be expected, since I am back to the backup copy of the disk before the first shutdown), but there are additional messages of the form: -ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy" in index file bitmap After having nearly gotten burned, I am hesitant to do ANA/DISK/REPAIR on a live system. Since I make a single-member shadow set when applying patches anyway (at least, that's what I've done several times and what I want to do again), I might as well do ANA/DISK/REPAIR on that after installing the patches. Later, the backup disk will re-enter the shadow set. What could cause the DELHEADER_BUSY messages (several of them)? Is it clear why ANA/DISK/REPAIR repairs DELHEADER but not BADHIGHWATER? Should it repair DELHEADER_BUSY? Also, there were %ANALDISK-W-BADDIRENT, invalid file identification in directory entry [SYSEXE]SYSBOOT.EXE;1 -ANALDISK-I-BAD_DIRFIDSEQ, invalid file sequence number in directory file ID and %ANALDISK-W-BADHEADER, file (11809,3,0) invalid file header but ANA/DISK/REPAIR repaired these. I don't think that ANA/DISK/REPAIR had anything to do with the booting problem. On the other hand, I've never done ANA/DISK/REPAIR during a patch installation before, so today's odyssey is not completely comparable to previous experience. All nodes in the cluster now show for the system-disk shadow set in question zero errors on the shadow set and on both members. ------------------------------ Date: Sun, 30 Nov 2008 16:11:40 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > This is a long post involving the nitty-gritty of HBVS of a system disk. > I hope I've included all relevant details. I'm really stumped! After > that, perhaps related, are some questions about ANA/DISK/REPAIR. Some related questions: There is no explicit mount command for the system-disk shadow set. If this mount implicitly does something like /INCLUDE with all members specified, then that would explain some things, but, again, I'm sure I have booted successfully (in a cluster) when only one member of the system-disk shadow set was available. If I shut down the cluster and remove one of the disks of the system-disk shadow set, then I should have a bootable disk, right? Should I be able to boot from it regardless of whether it has its original SCSI address? Should I be able to boot from it on another system (at least one with identical hardware)? Should I be able to boot from it even if the other member is not present? In general, in doing what I am doing (shutdown; remove one disk of the system-disk shadow set; reboot with VAXCLUSTER=0; install patches, do ANA/DISK/REPAIR on the remaining disk, perhaps make an /IMAGE backup of it (which would involve booting from still another disk or a CD or doing it on another machine); reboot with VAXCLUSTER=2), even if both are supposed to work, would folks here recommend setting SHADOW_SYS_DISK to 0 before the first shutdown and setting it back to 1 before the second shutdown? (Surprisingly, it is a dynamic parameter. Can I really create a system-disk shadow set without a reboot?) ------------------------------ Date: Sun, 30 Nov 2008 17:13:04 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: HBVS on system-disk shadow set, VAXcluster, reboot, ANA/DISK/REPAIR Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > This is a long post involving the nitty-gritty of HBVS of a system disk. > I hope I've included all relevant details. I'm really stumped! After > that, perhaps related, are some questions about ANA/DISK/REPAIR. Problem solved! The clue is actually in my long post; it took me a while to realise it. Just reading the post provides the information as to the cause of the problem. ANOTHER hint: I mentioned everything I did which was relevant. However, there is something which I forgot to do, and hence didn't mention. If you can guess what this is, then that will solve the problem as well. Answer is below, but as a "pillow problem", as Lewis Carroll would have said, see if you can solve the problem based only on my original post in this thread. SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer SPOILER ALERT --- scroll down for the answer Here's the answer: The system-disk shadow set on the node I was working on was still mounted on the other nodes in the cluster, since I had forgotten to dismount it there. As expected, it went into mount verification on those nodes. When the node I was working on came back up, there was only one member in the system-disk shadow set, whereas the other nodes remembered that there were two. Thus, an inconsistency. (Interesting is that a couple of weeks ago I mentioned that, after an unplanned dirty reboot, a system-disk shadow set (as it happens, on the same node I was working on today) WAS inconsistent in the cluster, showing two members on a two nodes and just one on another. Apparently this was a by-product of the dirty reboot and, in more or less normal circumstances, such inconsistency is avoided. A better error message would be helpful, though, and/or an OPCOM from the nodes which detect the inconsistency.) ------------------------------ Date: Sun, 30 Nov 2008 14:23:42 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: search list, surprising error, inconsistent behavior Message-ID: I believe it is documented that for a search list to work correctly, the entire directory tree must be present and the same for all segments of the search list. That is why you may see several empty directories in the SYS$SYSROOT:[*] tree. Therefore, if you create the directory disk:[sys0.sysmgr.sue], you should create disk:[vms$common.sysmgr.sue] even if you don't intend to use it, if you intend for the SYS$SYSROOT search list to work correctly with it. ------------------------------ Date: Sun, 30 Nov 2008 17:38:21 +0100 From: "nierveze" Subject: ucx Message-ID: <001301c9530a$123659e0$04000005@pc> hello everyone,does tcpip5.2 support client dhcp?can it be upgraded from 5.1?can it be installed on a vax with vms 7.2 or should I upgrade also vms to vms7.3 thanks very much Alain Nierveze web:www.radio-astronomie.com email:nierveze@radio-astronomie.com ------------------------------ Date: Sun, 30 Nov 2008 12:23:39 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: ucx Message-ID: <08113012233989_2020048A@antinode.info> From: "nierveze" > hello everyone,does tcpip5.2 support client dhcp? I don't know. (I don't use DHCP on any of my VMS systems.) > can it be upgraded from 5.1? Probably depends on your VMS version. > can it be installed on a vax with vms 7.2 or should I upgrade also vms > to vms7.3 I don't know which TCPIP versions work with which VMS versions. The TCPIP installation documents should say. I seem to have TCPIP V5.1 on my VMS V7.3 system, but that may be only because TCPIP V5.1 is what was on the VAX Hobbyist CD-ROM. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sun, 30 Nov 2008 10:35:41 -0800 (PST) From: IanMiller Subject: Re: VMS SIG Tape released (last from me) Message-ID: <0e496504-703f-4aec-9568-6ed04ef7da14@f20g2000yqg.googlegroups.com> Glenn, thank for all your work with the tapes over the decades, Do you know if this collection will appear on mvb.saic,com ? ------------------------------ Date: Sun, 30 Nov 2008 09:03:31 -0500 From: JF Mezei Subject: Re: VMS, HP and the recession Message-ID: <001e7a6c$0$12270$c3e8da3@news.astraweb.com> John Smith (not the one @ HP) wrote: > Or is HP fearful of another disaster of EPIC proportions in announcing what > features VMS has coming? In fairness, modern vendors such as Sun, Apple, Microsoft then to leak information about desired/upcoming features, but you don't see them make comittments. VMS has a roadmap in a .PDF file. Yes, it can be changed and you can't trust it, but at least it does show what current budgets think can be accomplished. Alpha's published roadmaop as of June 24 2001 is a very good example of what a roadmap is good for. In terms of the secret plans for VMS that are available only under NDA, I can see the need to keep certain aspects secret, especially with regards to VMS supporting hardware which HP is developping. For instance, the decision to have VMS support the IA64 blades was probably made well before HP publically announced it would have a new c-class cabinet for blades and also support IA64 blades. So VMS folks wouldn't publically start talking about blades at that point in time. In terms of VMS specific features, since VMS no longer competes in the marketplace, there is no strategic loss in announcing they want to implement feature X. I think that the NDAs for thos probably have more to do with the uncertainty that budgets would be allocated for those features and VMS management can't make any public announcements until there is a reasonable degree of certainty that work would be approved. ------------------------------ Date: 30 Nov 2008 14:49:41 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS, HP and the recession Message-ID: <6pfng5F7tlalU1@mid.individual.net> In article <001e7a6c$0$12270$c3e8da3@news.astraweb.com>, JF Mezei writes: > John Smith (not the one @ HP) wrote: > >> Or is HP fearful of another disaster of EPIC proportions in announcing what >> features VMS has coming? > > In fairness, modern vendors such as Sun, Apple, Microsoft then to leak > information about desired/upcoming features, but you don't see them make > comittments. > > VMS has a roadmap in a .PDF file. Yes, it can be changed and you can't > trust it, but at least it does show what current budgets think can be > accomplished. Alpha's published roadmaop as of June 24 2001 is a very > good example of what a roadmap is good for. > > In terms of the secret plans for VMS that are available only under NDA, > I can see the need to keep certain aspects secret, especially with > regards to VMS supporting hardware which HP is developping. Why? Afraid someone will bneat them to the punch with new features for VMS? I would think that at this stage of the game you would want to make anything that increased the value/usability of VMS as public and widespread as was humanly possible because no one is paying attention anyway and if you keep it a secret more customers will have migratd away before you finally decided to tell them about it. > For > instance, the decision to have VMS support the IA64 blades was probably > made well before HP publically announced it would have a new c-class > cabinet for blades and also support IA64 blades. > So VMS folks wouldn't publically start talking about blades at that > point in time. And just how did that help VMS? Seems to me that not knowing that HP was going to support VMS on those blades would have resulted in people having plans to migrate to an OS that did support them so far in motion by the time the announcement was made that there was little liklihood of those customers reversing track and sticking with VMS. Result: Another win for Uncle Billy. > > In terms of VMS specific features, since VMS no longer competes in the > marketplace, there is no strategic loss in announcing they want to > implement feature X. I think that the NDAs for thos probably have more > to do with the uncertainty that budgets would be allocated for those > features and VMS management can't make any public announcements until > there is a reasonable degree of certainty that work would be approved. In an industry so full of vaporware, no one would even notice if HP made an announcement and then was late bringing it to market. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 30 Nov 2008 16:07:52 +0000 From: "Main, Kerry" Subject: RE: VMS, HP and the recession Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593EDA7A2C98@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: steel_and_alum_engr [mailto:middie1975@gmail.com] > Sent: November 22, 2008 10:09 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS, HP and the recession > > On Nov 20, 8:31 am, "Main, Kerry" wrote: > > .. snip ... > > > VMware (and other OS virt technologies) certainly have a place, but > are a > > temporary solution that saves some $'s related to space, maint and > other > > HW type things, but that is only a small part of the overall IT > budget. > > Temporary solution? You're entitled to that opinion, but I couldn't > disagree more. > In our company's case, using VMware's ESX server software, we've > collapsed over 100 servers to less than 10 physical boxes. > Aside from the huge benefit of maintaining far fewer hardware > platforms, the real benefit to us was improved disaster recovery. > And, the "V-motion" technology, allowing VMs to transparently (on the > fly) move from one server to another, is very nice. > We've been running both Microsoft and Linux servers in this > environment for a couple of years now, and it's paying large > dividends. > While one can not paint every Cust with the same brush, let me see if the following is true of your environment: 1. You have more OS instances today than you did before you started with VMware. Likely quite a few more. Especially in Dev/QA 2. While the HW, DC space and electrical costs have decreased, your staffin= g has not decreased and in fact, may have increased to support the additional OS instances. 3. Your App license costs have increased to cover the additional instances Of the various third party and support products required. 4. Once a VM is created, it almost never gets taken down or reclaimed once its primary reason for creation goes away. I will bet that at least 3 out of the 4 points are true in your shop. > > Unfortunately after implementing OS virtualizing technologies like > VMware, > > many Cust's end up with many more OS's to manage than they had before > i.e. > > if you thought x86 servers used to populate like rabbits, wait until > you > > see how fast VM's populate. > > Your VM rabbit analogy might be true in some settings, but that is not > our experience. > I've heard some say that it's "too easy" to create new virtual > machines, and that might be correct. However, I'd rather something > be "too easy" than so difficult that it doesn't happen. No question > that it's very simple to create/clone a virtual machine. We use this > to our advantage for offline testing, OS and/or application version > upgrades, etc. Much easier to create a VM than to buy/find an unused > hardware box and start from scratch. Virtualization absolutely has benefits. No question about it. Unfortunately, it does not reduce staffing and in most cases, App sw licensing costs. Due to the ease of creating VM's, both of these costs will likely increase. And since IT staffing is usually 60-70% of most IT budgets, virtualization does not address the 800lb gorilla of most IT budgets when it comes to reducing overall IT costs. Now, what will your CIO's answer be when the CEO asks "its great that you have now completed most of the virtualization you had planned, but now tell me how you plan to further reduce IT costs by an additional 15% next year." Imho, VM consolidation with a focus on IT staffing and overall license costs reduction is going to be the "next big thing". And that's when the real tough decisions are going to have to be made. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ End of INFO-VAX 2008.640 ************************