0 INFO-VAX	Mon, 21 Jan 2002	Volume 2002 : Issue 39      Contents:- : Re: LIB$INITIALIZE image_info record layout - : Re: LIB$INITIALIZE image_info record layout 1 Re: : Re: LIB$INITIALIZE image_info record layout  Re: A position statement Re: A position statement Re: A position statement9 Re: Bill Gates admits security "non-existent" in windows! 9 Re: Bill Gates admits security "non-existent" in windows! 4 Re: Bill Gates: No Trustworthy Platform exists today Re: Buffer Overflows7 Re: building a vms box as a project.. is this possible? / Re: Capellas wants IBM model, but does reverse! / Re: Capellas wants IBM model, but does reverse!  Re: Change quorum disk question  Re: ClipArt of VAX equipment Re: DECwindows autologin Re: DECwindows autologin Re: DECwindows autologin Re: DECwindows autologin Re: DECwindows autologin' Re: DS20 PCI bus configuration question  How to set up MOP boot server." Re: How to set up MOP boot server." Re: How to set up MOP boot server.* Netscape not loading security certificates RE: Newbie Help on Security  Re: Newbie Help on Security  Re: Newbie Help on Security  Re: Newbie Help on Security ( Re: Purveyor is superior for VMS - proof( Re: Purveyor is superior for VMS - proof( Re: Purveyor is superior for VMS - proof( Re: Purveyor is superior for VMS - proof Re: triple boot  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  Re: TYPE suggestion  RE: Veritas Client for VMS7 Re: VMS missing features (was how to do deamons on VMS) ? Re: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D ? RE: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D ? RE: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D B Re: Younger recruits versus experienced veterans ( was Re: The dem9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories   F ----------------------------------------------------------------------  + Date: Sun, 20 Jan 2002 19:21:45 +0000 (UTC) , From: "Richard Maher" <maher_rj@hotmail.c0m>6 Subject: : Re: LIB$INITIALIZE image_info record layout. Message-ID: <a2f5c8$6a$1@paris.btinternet.com>   Hi,   > Thanks to the replies for an other note (Mark London and BrianK Schenkenberger) I've been able to map the first 288 bytes of image-info but F am having trouble finding a macro that deciphers the list of activatedJ images that is lurking in the remaining bytes. To the best of my knowledgeK my initialization routine receives the $EIHDDEF data that points to all the L interesting stuff at EIHD$L_IMGIDOFF that maps according to to $EIHIDEF. ButK where I would expect a mapping of $EISDDEF at EIHD$_ISDOFF I'm getting what C appears to be a header followed by a list off images that have been H activated upto and including the image that my initialization routine isI responsible for. (If the image was run from DCL you get the current image I followed by loginout.exe. If the image was run detached tehn  loginout is G leftout. I'm sure if my image was a shareable then it would be my image > plus and preceeding shareables plus the main image and finally loginout.exe.)  , Does this construct ring a bell with anyone?  L The confusing bit is that most macros limit image name to 40 bytes and theseL counted ASCII strings exceed 40 bytes. Brian mention IAC$GL_IMAGE_LIST queue@ is there a macro for this? Linked list? Is this what I'm seeing?  J Anyway I looked thru this news group via google and Compaq's Ask interfaceL but could not find anything that describes "image-info".  So if you can help then please do.    Regards Richard Maher    identification division.+ program-id.    init_test with ident "V1.0".  *  data division. working-storage section.& 01  sys_status          pic 9(9) comp. procedure division.  00.      display "In Main".
     stop run.  *  end program init_test. identification division. program-id.    init_rtn. *  data division. working-storage section.J 01  ss$_normal          pic 9(9)        comp    value external ss$_normal.- 01  sys_status          pic 9(9)        comp.  * - 01  ws_int              pic 9(9)        comp. ! 01  ws_string           redefines !     ws_int              pic x(4).  01  eihidef.-     03  eihi$l_majorid  pic 9(9)        comp. -     03  eihi$l_minorid  pic 9(9)        comp. -     03  eihi$q_linktime pic 9(11)v9(7)  comp.      03  eihi$s_imgnam.         05  imgnam_len  pic x."         05  imgnam_str  pic x(39).     03  eihi$s_imgid.          05  imgid_len   pic x."         05  imgid_str   pic x(15).     03  eihi$s_linkid.         05  linkid_len  pic x."         05  linkid_str  pic x(15).     03  eihi$s_imgbid.         05  imgbid_len  pic x."         05  imgbid_str  pic x(15). *  01  fao_ctl.5     03                  pic x(22)               value  '!_image name: "!AC"!/'.5     03                  pic x(36)               value ' '!_image file identification: "!AC"!/'. 5     03                  pic x(25)               value  '!_link date/time: "!%D"!/'.5     03                  pic x(32)               value # '!_linker identification: "!AC"!/'.   # 01  out_buff            pic x(512). - 01  out_len             pic 9(4)        comp.  *  linkage section.- 01 init_coroutine       pic 9(9)        comp. - 01 cli_routine          pic 9(9)        comp.  01 image_info.-    03 majorid           pic 9(9)        comp. -    03 minorid           pic 9(9)        comp. -    03 eihd_size         pic 9(9)        comp. -    03 isdoff            pic 9(9)        comp. -    03 activoff          pic 9(9)        comp. -    03 symdbgoff         pic 9(9)        comp. -    03 imgidoff          pic 9(9)        comp. -    03 patchoff          pic 9(9)        comp. $    03 the_rest          pic x(2048). *  procedure division         using   init_coroutine,                  cli_routine,                 image_info.  00. @     display "eihd_size"         eihd_size       with conversion.@     display "isdoff"            isdoff          with conversion.@     display "activoff"          activoff        with conversion.@     display "symdbgoff"         symdbgoff       with conversion.@     display "imgidoff"          imgidoff        with conversion.@     display "patchoff"          patchoff        with conversion.       display " ".'     display "Fixed Header Information".      display " ".C     display "    image format major id: ", majorid with conversion, 3             " minor id: ", minorid with conversion.   4     move image_info ((imgidoff + 1):104) to eihidef.       display " "./     display "Image Identification Information".      call "sys$fao"'         using   by descriptor   fao_ctl '                 by reference    out_len (                 by descriptor   out_buff-                 by reference    eihi$s_imgnam ,                 by reference    eihi$s_imgid/                 by reference    eihi$q_linktime -                 by reference    eihi$s_linkid          giving  sys_status. "     if sys_status not = ss$_normal1        call "lib$stop" using by value sys_status.       display out_buff(1:out_len).       display " ".$     display image_info(1:eihd_size).     exit program.  *  end program init_rtn.    .TITLE INIT_TEST  < .EXTRN LIB$INITIALIZE         ; Cause library initialization7                               ; Dispatcher to be loaded   J .PSECT LIB$INITIALIZE, NOPIC, USR, CON, REL, GBL, NOSHR, NOEXE, RD, NOWRT, LONG  A .ADDRESS INIT_RTN             ; Contribute entry point address of 7                               ; initialization routine.      .END   ------------------------------  + Date: Sun, 20 Jan 2002 21:50:30 +0000 (UTC) , From: "Richard Maher" <maher_rj@hotmail.c0m>6 Subject: : Re: LIB$INITIALIZE image_info record layout1 Message-ID: <a2fe35$7dn$1@knossos.btinternet.com>    Hi,   > Thanks to the replies for an other note (Mark London and BrianK Schenkenberger) I've been able to map the first 288 bytes of image-info but F am having trouble finding a macro that deciphers the list of activatedJ images that is lurking in the remaining bytes. To the best of my knowledgeK my initialization routine receives the $EIHDDEF data that points to all the L interesting stuff at EIHD$L_IMGIDOFF that maps according to to $EIHIDEF. ButK where I would expect a mapping of $EISDDEF at EIHD$_ISDOFF I'm getting what C appears to be a header followed by a list off images that have been H activated upto and including the image that my initialization routine isI responsible for. (If the image was run from DCL you get the current image I followed by loginout.exe. If the image was run detached tehn  loginout is G leftout. I'm sure if my image was a shareable then it would be my image > plus and preceeding shareables plus the main image and finally loginout.exe.)  , Does this construct ring a bell with anyone?  L The confusing bit is that most macros limit image name to 40 bytes and theseL counted ASCII strings exceed 40 bytes. Brian mention IAC$GL_IMAGE_LIST queue@ is there a macro for this? Linked list? Is this what I'm seeing?  J Anyway I looked thru this news group via google and Compaq's Ask interfaceL but could not find anything that describes "image-info".  So if you can help then please do.    Regards Richard Maher    identification division.+ program-id.    init_test with ident "V1.0".  *  data division. working-storage section.& 01  sys_status          pic 9(9) comp. procedure division.  00.      display "In Main".
     stop run.  *  end program init_test. identification division. program-id.    init_rtn. *  data division. working-storage section.J 01  ss$_normal          pic 9(9)        comp    value external ss$_normal.- 01  sys_status          pic 9(9)        comp.  * - 01  ws_int              pic 9(9)        comp. ! 01  ws_string           redefines !     ws_int              pic x(4).  01  eihidef.-     03  eihi$l_majorid  pic 9(9)        comp. -     03  eihi$l_minorid  pic 9(9)        comp. -     03  eihi$q_linktime pic 9(11)v9(7)  comp.      03  eihi$s_imgnam.         05  imgnam_len  pic x."         05  imgnam_str  pic x(39).     03  eihi$s_imgid.          05  imgid_len   pic x."         05  imgid_str   pic x(15).     03  eihi$s_linkid.         05  linkid_len  pic x."         05  linkid_str  pic x(15).     03  eihi$s_imgbid.         05  imgbid_len  pic x."         05  imgbid_str  pic x(15). *  01  fao_ctl.5     03                  pic x(22)               value  '!_image name: "!AC"!/'.5     03                  pic x(36)               value ' '!_image file identification: "!AC"!/'. 5     03                  pic x(25)               value  '!_link date/time: "!%D"!/'.5     03                  pic x(32)               value # '!_linker identification: "!AC"!/'.   # 01  out_buff            pic x(512). - 01  out_len             pic 9(4)        comp.  *  linkage section.- 01 init_coroutine       pic 9(9)        comp. - 01 cli_routine          pic 9(9)        comp.  01 image_info.-    03 majorid           pic 9(9)        comp. -    03 minorid           pic 9(9)        comp. -    03 eihd_size         pic 9(9)        comp. -    03 isdoff            pic 9(9)        comp. -    03 activoff          pic 9(9)        comp. -    03 symdbgoff         pic 9(9)        comp. -    03 imgidoff          pic 9(9)        comp. -    03 patchoff          pic 9(9)        comp. $    03 the_rest          pic x(2048). *  procedure division         using   init_coroutine,                  cli_routine,                 image_info.  00. @     display "eihd_size"         eihd_size       with conversion.@     display "isdoff"            isdoff          with conversion.@     display "activoff"          activoff        with conversion.@     display "symdbgoff"         symdbgoff       with conversion.@     display "imgidoff"          imgidoff        with conversion.@     display "patchoff"          patchoff        with conversion.       display " ".'     display "Fixed Header Information".      display " ".C     display "    image format major id: ", majorid with conversion, 3             " minor id: ", minorid with conversion.   4     move image_info ((imgidoff + 1):104) to eihidef.       display " "./     display "Image Identification Information".      call "sys$fao"'         using   by descriptor   fao_ctl '                 by reference    out_len (                 by descriptor   out_buff-                 by reference    eihi$s_imgnam ,                 by reference    eihi$s_imgid/                 by reference    eihi$q_linktime -                 by reference    eihi$s_linkid          giving  sys_status. "     if sys_status not = ss$_normal1        call "lib$stop" using by value sys_status.       display out_buff(1:out_len).       display " ".$     display image_info(1:eihd_size).     exit program.  *  end program init_rtn.    .TITLE INIT_TEST  < .EXTRN LIB$INITIALIZE         ; Cause library initialization7                               ; Dispatcher to be loaded   J .PSECT LIB$INITIALIZE, NOPIC, USR, CON, REL, GBL, NOSHR, NOEXE, RD, NOWRT, LONG  A .ADDRESS INIT_RTN             ; Contribute entry point address of 7                               ; initialization routine.      .END   ------------------------------  # Date: Sun, 20 Jan 2002 23:07:21 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) : Subject: Re: : Re: LIB$INITIALIZE image_info record layout0 Message-ID: <00A08565.C4F16629@SendSpamHere.ORG>  ] In article <a2f5c8$6a$1@paris.btinternet.com>, "Richard Maher" <maher_rj@hotmail.c0m> writes:  >Hi, > ? >Thanks to the replies for an other note (Mark London and Brian L >Schenkenberger) I've been able to map the first 288 bytes of image-info butG >am having trouble finding a macro that deciphers the list of activated K >images that is lurking in the remaining bytes. To the best of my knowledge L >my initialization routine receives the $EIHDDEF data that points to all theM >interesting stuff at EIHD$L_IMGIDOFF that maps according to to $EIHIDEF. But L >where I would expect a mapping of $EISDDEF at EIHD$_ISDOFF I'm getting whatD >appears to be a header followed by a list off images that have beenI >activated upto and including the image that my initialization routine is J >responsible for. (If the image was run from DCL you get the current imageJ >followed by loginout.exe. If the image was run detached tehn  loginout isH >leftout. I'm sure if my image was a shareable then it would be my image? >plus and preceeding shareables plus the main image and finally  >loginout.exe.)  > - >Does this construct ring a bell with anyone?  > M >The confusing bit is that most macros limit image name to 40 bytes and these M >counted ASCII strings exceed 40 bytes. Brian mention IAC$GL_IMAGE_LIST queue A >is there a macro for this? Linked list? Is this what I'm seeing?   H IAC$GL_IMAGE_LIST points to a queue (double linked list) of I(M)CB data G structures (They are called ICBs on VAX, IMCBs on Alpha).  I(M)CB$L_IHD G should point to an image header you can decipher.  You'll need to be in " exec mode to access a lot of this.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Sun, 20 Jan 2002 23:54:09 GMT * From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: A position statement A Message-ID: <BMI28.14491$jd7.1325006@bin6.nnrp.aus1.giganews.com>   > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C4AABCE.8A7E22BB@swissonline.delete.ch...     F Here's my response.  I apologise for its length but I hope you find it interesting.   John     Bill Todd wrote: > K > > 1.  Compaq's transfer of Alpha made short-term financial sense.  In the H > > circumstances that they had created for themselves, removing a largeH > > part of an expense of roughly $400 million per annum is a fair call. > J > Where did you come up with $400 million per annum?  Winkler's figure was the C > highest I've heard, at $300 million annually (which would includeu
 completionJ > of EV7, so the actual short-term savings will be less) - and the EETimesF > Marcello interview pegged Alpha development expenses at $150 million > annually.   F The $400 million - and please note I said "large part of .roughly $400G million" - comes from the statements about the cost of developing AlphasG made when Compaq bought Digital and again in the Annual Report for thattC year.  Corresponding figures were given by Compaq shortly after thex announcement on June 25.   *** H If those figures are what I suspect they are, you don't understand them.K The 1999 (and 2000) Annual Reports listed on-going development expenses forVF bringing yet-unrealized DEC products to market at a fairly steady $500I million annually, from something like 1998 - 2003 (before, of course, the K Alphacide changed them).  A separate section of one of them stated that the E largest single contributor to those expenses was storage development.eJ Therefore, the Alpha-specific contribution was at most something like $200J million annually - and while that could exclude server development if thatI was broken out separately, their combination still couldn't have exceededVH about $300 million (given that storage expenses were higher than either)H even if those were the only three significant contributors to the total.  J I've cited the Winkler and Marcello interviews from which the $300 millionL and $150 million figures for Alpha development costs came several times.  IfG you wish to contest them, come up with an equally specific and crediblee source.S ***1   >aK > This means that the actual short-term savings realized will be at most int  > the $100 - $200 million range.  G So, you know the level of saving better than Compa's own accountants ??e   ***vK No, but I appear to understand it better than you do.  You should note thatoI (at least AFAIK) Compaq has made *no* statement about what it expected toi: save, only about what 'Alpha development' supposedly cost. ***r  - >  If one accepts Compaq's statement that 80%oH > of its customers plan to hang around despite the Alphacide, the annual loss+ > of profit in VMS alone from the other 20%0  D You often quote the profits of VMS to be about $800 million but that refers to 1999 figures   ***rK Indeed it does - and since Terry reported that VMS sales increased modestly K through 2000 (and there certainly were no visible corresponding significanteH promotional efforts that would have soaked up the additional profit) theD situation more recently (indeed, right up until June 25th, since theL quarterly statements suggested that Alpha business was holding up relativelyF well during the downturn - until that date) was probably a tad better. ***t  ,  and I believe that at that time any storageA associated with VMS was grouped with VMS for accounting purposes.F   ***tK I have suspected that this was possible, but never had any confirmation oneeI way or the other (and service revenue - see next comment - was sufficientsF that it's certainly conceivable that storage was *not* included in theC figure).  If you indeed 'believe' this, could you cite your source?o ***t     ThetH true figure is somewhere lower but I have no information as to its exact value.   *** J Even under the assumption that the figure included associated storage, theG 'true' figure would only be lower if one could assume that the customeriJ would have purchased the same storage from Compaq for some other OS if VMSH were not an option:  otherwise, VMS was responsible for that revenue and profit.t  F Compaq's recent rebuttal to the Gartner report stated that VMS serviceJ revenues *alone* amounted to $2 billion annually.  Service margins are, asH you know, very good - so the stated profit level, even in the absence of5 associated storage, is not that difficult to believe.  ***   L > But the only circumstances when it's at all rational to limit one's visionL > to the short term are when short-term survival is at stake (i.e., when you? > won't be around later if you don't make drastic changes now).a  C Sorry, no.  We are dealing with a situation where the short-term issG reasonably well understood - potential savings being the major entity -    ***tH The main problem with that statement is that it completely fails to takeE into account short-term *costs* (in loss of revenue or loss of margin K required to attempt to maintain revenue).  If even 10% loss in Alpha system C profit occurs (increased existing-customer attrition plus decreased K new-customer sales) due to the Alphacide, there will almost certainly be no. net savings at all.s ***i  + but the longer term is entirely conjecture.m   *** L Only to the degree that the future is always at least potentially uncertain.  C We have quite definite time-line, chip-area, power, and performanceiJ estimates for both Itanic and Alpha (assuming EV8 had survived - but POWERJ will offer somewhat comparable competition) through 2004, right from thoseL people most qualified to make such projections.  If you're not familiar withG them, I suggest you become so before venturing further opinions in thisiD area:  they are key to any estimate of Itanic's medium-term success.  K We also have at least anecdotal information that Intel was at somewhat of a'C loss to know where to try to take Itanic after that date (e.g., theiJ Madison/Deerfield family members were originally *supposed* to be the nextK design generation but got demoted to mere process-shrinks of McKinley (plus.G more cache), suggesting that whatever the 'next' design might have been  wasn't going well).   H And we know *for sure* that VMS is now condemned to at least a couple ofF years of availability only on a declared-dying platform (and Tru64 nowL appears to be stranded there for the entirety of whatever life it has left).D These are hardly steps likely to improve sales during these periods. ***e     Among these conjectures arecF things like probable demand for VMS and Tru64, the ability of Intel toA create processors that are at least comparable and deliverable on H schedule.  Compaq - or anyone - can do no more than make a best estimate! of how these things may play out.    ***aF That's akin to saying "We might as well get rid of our research group,K because it costs money *today* and there's really no guarantee that it will A produce anything useful."  Oh, wait:  Compaq actually did that...   H Refusing to act on the best predictions available means you look only inK your rear-view mirror to anticipate the future.  Oh, wait:  Compaq has beendF doing that too for the past few years, which is how it got where it is today.  ! Guess you and Compaq think alike.f ***:  G (It does appear some of Compaq's assumptions may have been already castoC into doubt.  Events of Sep 11 could not be forseen but they are nowtH reflected in demand for systems with high security and high availabilityC emphasise, as stated in the Q4 financials.  Had this demand for VMS = appeared early this year, the decision on Alpha may have beenn otherwise.)l   *** L Hmmm.  I must have missed the statement in the Q4 financials that VMS demandK was significantly up.  What I remember is that Enterprise Computing revenueyJ was down 34% from 2000Q4, though it was up 15% sequentially over the truly disasterous 2001Q3.i  I The Storage portion of EC was up 14% over Q3, so that was about a wash inEH the overall average rise.  Non-Stop business was up 19% over Q3, so thatI helped raise the overall average (and the statement that demand for these I *fault-tolerant* systems increased may be where you got the idea that VMS I sales were up...).  And Tru64 sales were reported (in Capellas' "remarks" H that accompanied the 'financial discussion') to be up a full 60% over Q3G (some have opined that a few supercomputer and/or military sales causedrI this), so they *certainly* made a significant contribution to the overalle	 15% rise.a  I That leaves VMS and ISSG as the only elements that could have dragged theoI overall EC performance *down* to 15% sequential growth.  ISSG was already E pretty depressed through Q3, and the 'remarks' indicated that it grewhL sequentially by 9% in Q4 - so while it was a drag on the overall average, itE certainly couldn't have held it down to 15% if VMS had been *way* up.e  L The 'remarks' specifically broke out BCSG revenues and said they were up 31%K sequentially.  Now, if NonStop revenue was up 19%, and Tru64 revenue was upD; 60%, and we use the rough 2:3:4 ratio stated last March forfK NonStop:Tru64:VMS revenue, that means that VMS revenue was up less than 20%eH over a truly bad Q3.  One might say, "Well, that's about the same as theG NonStop increase" - but that would ignore the fact that NonStop did nottL suffer the Q3 disaster that the other systems did (rather, it was what savedJ Q3 from being even worse) hence was not rebounding from the free-fall that VMS had had.  G Given the fairly robust growth that both Tru64 and NonStop systems havenG enjoyed of late, a 2:4:4 ratio might be more accurate these days, whichaH would mean that VMS revenue grew well under 10% over Q3.  Then again, ifL 'high performance servers' equate to all Alpha sales, the 'remark' that theyI were up 39%, coupled with Tru64's 60% increase (and some modest fudge foraL Linux impact) indicates that VMS may have grown closer to 20%.  At any rate,E these figures, while far from exact, certainly justify my request foroJ specific sources if you still wish to contend that some kind of sea-changeJ in VMS demand occurred in Q4 rather than just a modest rebound from a very low point in Q3. ***   I >  And from all appearances the Alphacide decreased rather than increasedo) > Compaq's chances of being around later.s  D Your statement "all appearances" is unsupportable by evidence.  SureF there are people adopting a wait-and-see approach but this is no clear7 indicator that they will move away from VMS (or Tru64).o   ***1J Methinks you have difficulty understanding that when customers change fromL platform acceptance to 'wait and see' this *itself* constitutes a measurableE change in both current sales and the probability of future sales.  Or G perhaps you just don't see logic that does not fit your preconceptions.n  L My statement was not that the Alphacide prophesied certain death for Compaq,K simply that it decreased Compaq's chances.  Unless you can come up with anynG credible evidence that the Alphacide was *good* for Compaq's chances, I  suggest that you're confused.  ***5  
   From what I A have observed and heard, the reaction of most companies - and not D individuals - is that the change will be similar to the Vax to AlphaD transition and they have confidence that Compaq's VMS folk will make life as easy as possible.(   *** J So what?  As I mentioned earlier, if even as few as 10% of Alpha sales areI lost (which would still certainly be consistent with your suggestion that_K *most* companies won't bail out), that will wipe out the supposed Alphacide K savings - and decrease market share in the process.  Can you really suggestr9 with a straight face that this will be *good* for Compaq?0 ***o  -   (One should also be suspicious of companiesiH that have stated they will look elsewhere.  They might well be trying toH get some concessions out of Compaq.  That is an entirely dfferent matter. to having no confidence in the future of VMS.)   *** J Actually, it's quite relevant.  If Compaq has to cut margins to make salesH that it otherwise would have made more profit on, this too is an expenseL that must be chalked up to the Alphacide (and weighed in estimating Compaq's chances for survival). ***   I > The only obvious benefit was to make Compaq a more attractive take-overc< > target to another company equally uninterested in fieldingI > 'non-industry-standard' solutions.  Aside from that, it appears to haves been- > at best fiscally neutral in the short term,   G Here's your assumption about the costs and the potential savings again.e   *** C Which I'll stand by until someone comes up with credible figures to + challenge it.  You haven't even started to.o ***o  # > .. a significant loss medium-term > > (the period when VMS and Tru64 will be available only on the declared-dyingI > Alpha platform), and a disaster long-term unless the Alpha team pulls ai" > miracle out of its hat for Intel  D You seem to have ignored the trade-in/trade-over kinds of deals that/ Compaq is now offering its new Alpha customers.y   ***nH You seem to be ignoring the fact that such deals *cost* Compaq profit itE would not have had to forsake if Alpha itself were still considered aiL long-term-viable platform.  They're also a clear indication that Compaq seesH the need to stem an exodus (do you really believe that Compaq has simply- become overwhelmed by Christmas generosity?).b ***u     This will probably putG them in a slightly advantageous position compared to those who have hadiD Alphas for several years and would in the normal course of events be paying for new hardware anyway.   F You have also ignored any overlap period when VMS is available on both Alpha and Intel.   ***T6 No I haven't:  it's just not pertinent to what I said. ***   6   Many customers would an Alpha now and be looking forH new hardware before the end of this overlap period.  (In my opinion thisH would be a smart move - never be first with any upgrade or major change, but never be last either.)    J > > 2.  Compaq's handling of the announcement of the transfer was poor andH > > their justifications were weak.  Various announcements about methodsJ > > which will reduce the customers' costs of change of platform have doneL > > something to redress the balance.  Personally I would chalk it up as yet7 > > another failure in their "external communications".n >lF > Failure to justify an unjustifiable decision is not a communicationsK > failure.  Perhaps you're just saying that their lies could have been lesst > transparent.  E Perhaps if you had more accurate information about the annual savings / you might be able to make this kind of comment.g   ***aK I welcome all credible information.  So far, it appears that you're the onepL who lacks it, but if you have sources you have not yet revealed by all means do so.  B Meanwhile, as by all appearances I *do* have sufficiently accurate> information to make such comments, I'll continue to make them. ***I     Perhaps also it wouldLB help if you knew where Compaq were directing these savings and theD income that was generated by this money in the next few years ratherE than be sunk into development of something which just might produce a ' profitable return in 3 or 4 years time.u   *** K Actually, it wouldn't.  Not only are the net savings illusory (feel free toiL offer up real evidence to the contrary:  so far, you have not), but even theK gross savings claimed by Compaq (at most $300 million annually, more likelyrK half that) will in all probability be offset *in the short term* by loss ofsI confidence in Alpha and/or Compaq (and resulting loss of sales that wouldeC otherwise have occurred:  remember, as little as a 10% loss will beaJ sufficient to offset any claimed saving, and when you couple the AlphacideE with the subsequent screwing of Tru64 by the merger antics this seems  absolutely inevitable).   K So it really doesn't matter what any supposed 'savings' will be applied to:oB Compaq would have been better off borrowing the money for any suchA activities (if they're truly worthwhile) rather than 'saving' it.2 ***   H We are talking here of a thing called "business risk".  Perhaps when youB are the CEO of a good sized company - not necessarily one with $24? billion in assets and about 64,000 employees - you will be moret$ qualified to speak on these matters.   ***BL Perhaps when you learn how to understand the material you presume to commentL upon you will become more qualified to comment upon it.  Of course, you willG still not be noticeably more qualified than I am, unless you also first L become CEO of a good-sized company yourself and thus at least nominally in a9 position to offer those insights that you suggest I lack.a ***l  L > > 3.  Compaq appears to be run as four separate competing companies - VMS,H > > NSK, Tru64 and NT - and this kind of attitude is a major obstacle toB > > income growth.  These subcompanies never mention each other inK > > advertising and, even worse, the sales philosophy seems to be to dividesJ > > the range of possible markets into four sectors - VMS being sandwichedJ > > between NSK and Unix - and that the given platform will ONLY advertiseC > > to that sector.  To put it very politely, I just cannot see anyi/ > > reasonable justification for this approach.n >gH > Any statement that suggests (as yours does above) that VMS competes onE > anything like equal footing in the corporation is flat-out blind tos reality.  ; I am saying no such thing.  You have it wrong just like JF.t   ***eJ No, you again prefer to dispute a comment based on what you may have meantG to say rather than what you actually said.  I referred to your specific L statement above (and explicitly limited it to that), where you claim "CompaqD appears to be run as four separate competing companies".  My commentE indicated that they are neither separate nor do they compete on equalgG footing:  this is the kind of lie by omission that I'd more expect fromp@ Compaq's spinners, but then again you appear to be becoming one. ***'  
   As I sayD later in my post, the PC faction appears to have greatest influence.F The playing ground is far from level; the niche market concept ensures this..  E FWIW, I believe that this is the greatest single failing of Compaq, alH marketing strategy that does not allow them to reap maximum profits fromD the entire range of IT activities.  I am trying to discover why thisF notion exists and who are the people with sufficient influence to haveH the idea adopted.  I have tried to bypass them with a argument direct toC Michael Capellas.  I don't know if it will work but it is certainlyn worth a try.   ***uE It was.  We did (and it's hard to see how you'll be more effective or I eloquent on your own trying to do exactly the same thing than more than a  dozen of us were).  It failed. ***e  G > The most charitable interpretation I can come up with (of your entireoF > approach, not just this point) is that you've completely given up onK > challenging Compaq's handling of its assets and are willing to grovel for $ > whatever crumbs that might produce  H I don't grovel for crumbs.  If I am going to bash my head against a wallA I like to know that it is the right wall to be bashing.  Compaq'sr! OpenVMS people are not that wall.o   ***iH Not unless they choose to associate themselves with it.  Which is what I said.t ***i  I > > 4.  The OpenVMS division within Compaq seems to be enthusiastic about J > > the platform and certainly want to improve sales.  The obstacles trulyJ > > seem to be elsewhere.  Given that only the VMS people in Compaq appearL > > to read this newsgroup, any criticism here - constructive or otherwise - > > is misdirected.u >sL > If your premise were correct, your conclusion would be as well.  But sinceH > both customers and the competition also read what transpires here (you even' > say so in your next point), it's not.   C Please give us the conclusive proof that the OpenVMS people are thee@ major obstacle and that the obstacle does not exist elsewhere in Compaq.e   ***rE Please cite specifically where you got the absurd idea that I believetH anything of the kind.  You clearly need to devote some of the energy you1 expend on writing to understanding what you read.e ***o  ?   From what I have seen the OpenVMS people are enthusiastic andh> helpful but clearly they are sometimes constrained by what the" greater-Compaq permits them to do.   ***sK Aside from the occasional propensity of one or two of them to try to defendnH Compaq's to-all-appearances completely indefensible actions (but withoutC providing any solid information to back up their defense), I agree.t ***o  D >  > ..I know that Compaq's VMS people are the "face of the company"I > > from our perspective but when all of us are in violent agreement with F > > our aims - but maybe not method! - it really makes little sense to > > harangue them.)t >kF > I haven't noticed anyone haranguing them except when they attempt to support J > Compaq's lies (in which case confrontation is entirely appropriate, even ifI > one can also sympathize with the position they're in:  if they *really*y haveK > credible evidence that we lack on these matters, let them produce it - ori2 > convince higher-ups that doing so is important).  E I am sure that they have tried to convince those higher-ups but oftena without success.   *** L I'd certainly hope so, but that would actually reflect even more dismally on# the situation than if they had not.  ***r  2   As for the nature of Compaq's "lies" you seem to forget a few things.   ***sJ No, not really:  this is a matter I've made it a point to keep pretty well	 aware of.  ***e  C The first thing is that they have more information than you on manyvD matters and while you may be peerlessly correct on some issues there. other major factors that you are not aware of.   ***hA A meaningless generalization absent specific *relevant* examples.o ***      Do you for example knowiE exactly how many VMS machines are now on maintenance contracts ?  HowrG many compiler licenses are out there ?  How many systems are being solda4 because of Oracle, of Rdb, of software package XYZ ?   ***tJ Nope.  Nor is there any reason to believe that such *exact* details are at, all important to the conclusions I've drawn.  D For example, Compaq just stated that VMS systems bring in $2 billionL annually in services revenue.  Just how that breaks down between maintenanceJ contracts, new-installation hand-holding, etc. is of only secondary (whichE is not to say negligible) interest compared with the magnitude of then revenue itself.   I How many VMS systems are being sold because of Oracle is also interestingdH but mostly simply as an indication of how important Oracle support is toE VMS.  A far more important question (unless you're only interested ineJ life-support for VMS) is how many VMS systems are *not* being sold because' of the *lack* of some popular packages.n  J To suggest that no conclusions can be drawn without *complete* informationK is disingenuous.  If you want to be at all credible, you'll need to providerL credible information that calls into question my assertions, not just try toB dismiss them because there *might* be other information out there. ***   E Now I admit, I cannot be sure if the Compaq employees who support thenF company statements are doing so because they understand and agree withF the basis for certain decisions, they have first hand knowledge of theH factors, they understand the consequences of some decision and know thatG it is insignificant, or they just want to keep their jobs.  You are far D too willing to criticise them when if you were in their position you# might do exactly as they have done.y   ***gI You are far too willing to assume that just because *you* might have done I exactly what they have done anyone else might as well.  I would not - I'dtC keep my mouth shut if I couldn't contribute any additional relevant L information, or address directly the points I could (rather than ignore them# as Compaq and its apologists have).3 ***o  K > > 5.  In regard to the previous point, it seems that Compaq's competitorsiL > > have been using information from this newsgroup that criticizes Compaq'sH > > actions as regards VMS.  This can only have a negative affect on VMSI > > sales and so it plays directly into the hands of the people in Compaq + > > who believe that VMS should be ignored.h > J > So what?  It's abundantly clear that these people already have the upper& > hand, so matters won't be any worse. >dK > VMS is not so much owned by Compaq (and these people who run it) as it ishF > held hostage by it.  "Watch out!", you seem to be saying:  "If we do= > anything to make them mad, they'll only make things worse!"i  = Is this the only exercise you get ?  Jumping to conclusions ?h   ***gK From one who is so ready himself to jump to conclusions without even havinglK bothered to understand the material he's responding to, this is a laughableh observation. ***%  E I am saying that any undermining of Compaq's VMS sales by postings tolF this newsgroup will not result in a positive adjustment of policy fromG Compaq.  They are far more likely to reduce their resources and effortsiF for VMS and at least most of us here would regard this as a BAD THING.   ***wL I'd be interested in seeing exactly how you differentiate your new statementG above from your original statement a bit farther above, and from my own F rendition of it.  While there are differences in emphasis - e.g., yourJ original statement, and the portion my response most reacted to, specifiedL explicitly the leverage that decreased VMS sales would give to VMS's enemiesJ in Compaq, whereas your rephrasing eliminates the suggestion that Compaq'sK response would be anything more than a simple, non-political reaction - thef5 actual content of all three is pretty much identical.  ***a  J > Well, things already *are* worse, and they got that way by following the( > course of action you're promoting now.  B Another wild assertion.  This course of action did NOT create this	 response.(   ***eH For once you've caught me in a slightly ambiguous statement (rather thanH simply failed to parse it correctly yourself).  I did not mean to assertL that the course of action you're promoting *caused* the problem, merely thatH it was the same course that had, consistently, failed to correct it overA time (and hence had little likelihood of doing better now).  BotheB interpretations are legitimate, so I could have phrased it better. ***s   ...n  & >  A new course is indicated, one thatK > will either make them sit up and take notice or result in their expulsiona byJ > the BoD or the stockholders.  Yes, it *feels* risky, but Compaq has doneK > such a good job of marginalizing VMS already that there's really not thathI > much *actual* down-side risk left - and the potential up-side, as we'vef said > for so long, is huge.n  B As I said before, most of us would regard further reduction in VMS resources as a bad thing.g   *** K But if the *threat* of revenue loss causes an *increase* in resources, most I would consider that a *good* thing.  So it really depends on which aspectnF (the risk, or the reward) one chooses to emphasize - in a manner aptlyH opposite to Compaq's own attitude toward VMS (take no risks, because the presumed reward is nil). ***s  /   You might like to take the RISK of a completenE termination of VMS but judging by the lack of posted support for yourA< attitude you do not speak for the majority of the folk here.  H I took it upon myself to post the original document and this response toG your response because I do not believe that a small number of outspoken 6 critics should act against the wishes of the majority.   ***aK It's Spiro Agnew's 'silent majority' come back to life!  Isn't it wonderfulnK how one can call upon it to support whatever position one may wish to take!i  K As for me, I'll act as I see fit, whether in the majority or not (and whichuJ may be the case this time is far from clear).  And I expect others will doC likewise, hopefully with at least some attempt to develop some real  understanding of the issues. ***   ! >   What needs to be done in this L > > group (when we are not dealing with technical questions) is to encourageA > > the growth of VMS sales and to show its advantages over other K > > platforms.  (In regard to the former, reports of sales into new marketsnJ > > are always interesting and for the latter, just how difficult is it to2 > > show the security advantages that VMS enjoys?) > I > JF answered this more than adequately.  I suggest that you consider his J > points carefully (especially the issue of how ethical it is to encourageK > others to adopt an at-risk platform without notifying them of said risks,pC > simply in the hope that their presence will improve its chances).o  @ I believe that Compaq will be properly informing their potential	 customers    *** H You mean, as they did about Alpha's long-term future right up until JuneG 25th?  Or as they did about NT on Alpha's future right up until August,sG 1999?  Or as they did about Tru64's future on Itanic until they changedr their minds?  I If Compaq had 'properly informed' their customers on a reliable basis, weo# wouldn't be having this discussion.  ***n  =  and unlike you, they will be explaining the trade-in/tade-upp< scheme which will take Alpha buyers onto the Intel platform.  D I suggest that you consider how ethical it is for you to assume that this is not being done   ***eI See above.  It hasn't been done in the past, and they've chosen to lie tooI try to justify it rather than come clean.  If it's unethical to call thishK behavior to the attention of people who might be affected by it, then so bes it.s  L Of course, your ethics may be very different from mine:  as I said, you seem  to think a lot like Compaq does. ***   +  and to take it upon yourself to make thesel/ assertions without validating your assumptions.n   ***iI Just how much more validation do you feel is necessary?  Compaq's actionsoE pretty much speak for themselves, but as long as people like you feelpK inclined to spin them otherwise people like me will be around to set thingsc	 straight.  ***      Ignorance is no excuseC is a statement that commonly applies to law; perhaps it should also  apply to newsgroup postings.   ***V4 I sincerely hope that you take it to heart yourself. ***h  D > > 6.  In a broader picture we need to do what we can to reduce theK > > influence of those people in Compaq who appear to have relegated VMS to = > > the "second division" of platforms (along with NSK).  ...a< > > We need to work with Compaq's VMS people to convince theD > > decision-makers that there are very good reasons to increase theH > > publicity of VMS.  When that action results in greater VMS sales andH > > hence greater income, we will have clearly demonstrated that it is aF > > platform which deserves rather more attention than it is currently > > receiving. > I > That's *exactly* what we tried 20 months ago, John.  It didn't work, ath all.  G And as you showed recently you seem completely unaware that things have ! changed for IT in that 20 months.e  B - According to April 2001 figures, in 1999 PCs made a loss of $386F million.  In 2000 they improved and made a profit of $145 million, butH last year they made a loss of $587 million.  The enthusiasm for PCs that3 Compaq had in July 2000 can no longer be justified.    *** K And you suggest that this wasn't equally apparent 20 months ago?  I seem toiJ remember that it was apparent within the discussions our group had leadingJ up to the presentation we made, and (as you're so fond of pointing out) ifK the numbers were evident to us Compaq certainly had even better informationt	 to go on.r  L The difference between a modest loss in 1999 and a modest profit in 2000 was hardly decisive.  C Of course, even if Compaq deemphasize PCs that doesn't mean they'lleF recognize the value of their non-'industry-standard' offerings.  TheirL current favorite appears to be services, for example, though they're willingH to consider licensing HP/UX (since Tru64 is such a dog) to bolster their non-industry-standard line-up.  J Face it, John:  Compaq's management is terminally screwed up, and the onlyC question is how much of the company they'll destroy before they areg	 replaced.t ***c  F -  According to a number of reports PC users are becoming reluctant toE upgrade their systems just because of a new release of Windows.  ManyeH are saying that the market has reached saturation and that new sales areH only replacements.  Both factors say that PC growth is likely to be very" low, unlike the period up to 1999.   ***oI Could be.  But Dell's sales (not just market share) are up significantly,iK and so are those of lower-tier companies:  it's mostly the other first-tiersK vendors that are experiencing major sales losses.  So Compaq may still haveoH hope (which I'd normally think was a *good* thing, but in this case...). ***o  G - September 11 caused a new awareness of the need for secure systems of 4 high availability.  This is perfectly suited to VMS.   ***sF If this actually occurs, it's most likely yet another opportunity that Compaq will pass up. ***d  F - VMS was late catching the e-software bandwaggon and in 2000 that wasE the area of biggest demand.  That demand has substantially diminishedN> and the emphasis of IT has returned to a more general outlook.   ***oI You're really starting to sound like a marketdroid, John.  Come back whentJ you can point to some significant VMS sales increases and I'll be happy to change my opinions.t ***r  > - System consolidation is increasing and this requires greaterB reliability than before.  The loss of one system out of 10 runningH separate applications was a minor issue, but the loss of a single serverH running all 10 applications is a major problem.  Again, VMS is perfectly suited to the task.    ***hI Well, not unless *all* the applications people want to run on that serverc are supported on VMS.  ***a  H These are all factors that have changed the emphasis of the IT market inC the last few years.  Many have created new opportunities for VMS orq1 diminished the opportunities for other platforms.n   *** ? New opportunities?  Possibly.  Unfortunately, VMS had plenty ofaF opportunities *already* and Compaq reliable passed them up, so why oneA should expect it to sit up and take notice now is far from clear.g ***s  G These are all good reasons why VMS should be unleashed from its niches.    *** G Indeed they are, not that any additional reasons were needed.  We don'tdK disagree nearly as much on what *should* happen with VMS as we do on what'sn/ *likely* to happen and how best to change that.p  L If you choose to respond again, I ask only that each point you make add someL identifiable item of information to the discussion and/or specifically use aI supportable fact to refute something I've said:  otherwise, it's just hot  air.   - bill   ------------------------------  % Date: Sun, 20 Jan 2002 23:47:06 -0500t% From: JF Mezei <jfmezei@videotron.ca>p! Subject: Re: A position statement , Message-ID: <3C4B9D43.9B3A8E9C@videotron.ca>   Bill Todd wrote:E > emphasise, as stated in the Q4 financials.  Had this demand for VMS ? > appeared early this year, the decision on Alpha may have been.
 > otherwise.)   K I am not sure about that.  When Compaq euthanised NT on Alpha, I think thatbI Compaq had already decided that Alpha would not make it. The fact that ittG called its 8086 business "industry standard" and said it would focus oniN industry-standard solutions for a long time was a clear indication that Compaq was not interested in Alpha.    N It is a bit ironic that those of us who were complaining for a long time aboutN lack of Alpha visibility and were speculating on Compaq's true intentions wereD labeled as "whiners". But now that it is a done deal, they refuse to@ acknowledge all the warnings that the "whiners" had been making.  K What is more important is that the same type of warnings have and are beingvC made about the future of VMS, and again, we are labeled as whiners.n  L The same type of comments are being (and have been) made about VMS, yet manyM choose to ignore those complaints because they come from the same whiners whoeE kept complaining about the future demise of Alpha.  (a complain whichc materialised on June 25).o  G It is no secret that Compaq came very close to axing VMS in June 2000.  M Marcello was able to convince  the PC crowd that VMS's profits were essential M to the survival of Compaq and that VMS should in fact be given some marketing 3 budget to stop its decline (yes, it was declining).o  M Marcello's deeds probably also extended Alpha's life since it would have beendM logical for Compaq to kill Alpha at the same time as VMS (with Tru64 going tor Itanium).  a   ---   J Marcello was able to reverse a downturn with a token marketing budget, yetO Compaq turned around, asphyxiated the VMS marketing budget and murdered Alpha. u    H Compaq didn't take the Alpha decision overnight. When it stopped the VMSJ renaissance, it would have known already that Alpha was on its way out. IfL they had been serious about VMS, they would have increased the VMS marketing0 to help smooth the bad news of Alpha's homicide.           >  > ***rN > Hmmm.  I must have missed the statement in the Q4 financials that VMS demandM > was significantly up.  What I remember is that Enterprise Computing revenue.L > was down 34% from 2000Q4, though it was up 15% sequentially over the truly > disasterous 2001Q3.  > K > The Storage portion of EC was up 14% over Q3, so that was about a wash in J > the overall average rise.  Non-Stop business was up 19% over Q3, so thatK > helped raise the overall average (and the statement that demand for thesetK > *fault-tolerant* systems increased may be where you got the idea that VMShK > sales were up...).  And Tru64 sales were reported (in Capellas' "remarks"oJ > that accompanied the 'financial discussion') to be up a full 60% over Q3I > (some have opined that a few supercomputer and/or military sales caused*K > this), so they *certainly* made a significant contribution to the overallS > 15% rise.  > K > That leaves VMS and ISSG as the only elements that could have dragged the K > overall EC performance *down* to 15% sequential growth.  ISSG was alreadyXG > pretty depressed through Q3, and the 'remarks' indicated that it grew N > sequentially by 9% in Q4 - so while it was a drag on the overall average, itG > certainly couldn't have held it down to 15% if VMS had been *way* up.s > N > The 'remarks' specifically broke out BCSG revenues and said they were up 31%M > sequentially.  Now, if NonStop revenue was up 19%, and Tru64 revenue was upe= > 60%, and we use the rough 2:3:4 ratio stated last March foroM > NonStop:Tru64:VMS revenue, that means that VMS revenue was up less than 20%oJ > over a truly bad Q3.  One might say, "Well, that's about the same as theI > NonStop increase" - but that would ignore the fact that NonStop did nottN > suffer the Q3 disaster that the other systems did (rather, it was what savedL > Q3 from being even worse) hence was not rebounding from the free-fall that > VMS had had. > I > Given the fairly robust growth that both Tru64 and NonStop systems haverI > enjoyed of late, a 2:4:4 ratio might be more accurate these days, whichsJ > would mean that VMS revenue grew well under 10% over Q3.  Then again, ifN > 'high performance servers' equate to all Alpha sales, the 'remark' that theyK > were up 39%, coupled with Tru64's 60% increase (and some modest fudge for N > Linux impact) indicates that VMS may have grown closer to 20%.  At any rate,G > these figures, while far from exact, certainly justify my request fornL > specific sources if you still wish to contend that some kind of sea-changeL > in VMS demand occurred in Q4 rather than just a modest rebound from a very > low point in Q3. > ***r > K > >  And from all appearances the Alphacide decreased rather than increasedt+ > > Compaq's chances of being around later.  > F > Your statement "all appearances" is unsupportable by evidence.  SureH > there are people adopting a wait-and-see approach but this is no clear9 > indicator that they will move away from VMS (or Tru64).  >  > ***nL > Methinks you have difficulty understanding that when customers change fromN > platform acceptance to 'wait and see' this *itself* constitutes a measurableG > change in both current sales and the probability of future sales.  OrnI > perhaps you just don't see logic that does not fit your preconceptions.i > N > My statement was not that the Alphacide prophesied certain death for Compaq,M > simply that it decreased Compaq's chances.  Unless you can come up with any I > credible evidence that the Alphacide was *good* for Compaq's chances, Ie > suggest that you're confused.y > ***  >  >   From what I C > have observed and heard, the reaction of most companies - and not F > individuals - is that the change will be similar to the Vax to AlphaF > transition and they have confidence that Compaq's VMS folk will make > life as easy as possible.t >  > *** L > So what?  As I mentioned earlier, if even as few as 10% of Alpha sales areK > lost (which would still certainly be consistent with your suggestion that M > *most* companies won't bail out), that will wipe out the supposed AlphacidelM > savings - and decrease market share in the process.  Can you really suggeste; > with a straight face that this will be *good* for Compaq?e > ***e > / >   (One should also be suspicious of companies J > that have stated they will look elsewhere.  They might well be trying toJ > get some concessions out of Compaq.  That is an entirely dfferent matter0 > to having no confidence in the future of VMS.) >  > ***eL > Actually, it's quite relevant.  If Compaq has to cut margins to make salesJ > that it otherwise would have made more profit on, this too is an expenseN > that must be chalked up to the Alphacide (and weighed in estimating Compaq's > chances for survival). > ***  > K > > The only obvious benefit was to make Compaq a more attractive take-overg> > > target to another company equally uninterested in fieldingK > > 'non-industry-standard' solutions.  Aside from that, it appears to have  > been/ > > at best fiscally neutral in the short term,l > I > Here's your assumption about the costs and the potential savings again.f >  > ***oE > Which I'll stand by until someone comes up with credible figures toh- > challenge it.  You haven't even started to.t > ***, > % > > .. a significant loss medium-termi@ > > (the period when VMS and Tru64 will be available only on the > declared-dyingK > > Alpha platform), and a disaster long-term unless the Alpha team pulls au$ > > miracle out of its hat for Intel > F > You seem to have ignored the trade-in/trade-over kinds of deals that1 > Compaq is now offering its new Alpha customers.b >  > ***aJ > You seem to be ignoring the fact that such deals *cost* Compaq profit itG > would not have had to forsake if Alpha itself were still considered a,N > long-term-viable platform.  They're also a clear indication that Compaq seesJ > the need to stem an exodus (do you really believe that Compaq has simply/ > become overwhelmed by Christmas generosity?).* > ***o >  >   This will probably putI > them in a slightly advantageous position compared to those who have had F > Alphas for several years and would in the normal course of events be! > paying for new hardware anyway.  > H > You have also ignored any overlap period when VMS is available on both > Alpha and Intel. >  > ***n8 > No I haven't:  it's just not pertinent to what I said. > ***  > 8 >   Many customers would an Alpha now and be looking forJ > new hardware before the end of this overlap period.  (In my opinion thisJ > would be a smart move - never be first with any upgrade or major change, > but never be last either.) > L > > > 2.  Compaq's handling of the announcement of the transfer was poor andJ > > > their justifications were weak.  Various announcements about methodsL > > > which will reduce the customers' costs of change of platform have doneN > > > something to redress the balance.  Personally I would chalk it up as yet9 > > > another failure in their "external communications".s > >eH > > Failure to justify an unjustifiable decision is not a communicationsM > > failure.  Perhaps you're just saying that their lies could have been lessa > > transparent. > G > Perhaps if you had more accurate information about the annual savings 1 > you might be able to make this kind of comment.  >  > ***tM > I welcome all credible information.  So far, it appears that you're the onelN > who lacks it, but if you have sources you have not yet revealed by all means > do so. > D > Meanwhile, as by all appearances I *do* have sufficiently accurate@ > information to make such comments, I'll continue to make them. > ***  >  >   Perhaps also it wouldiD > help if you knew where Compaq were directing these savings and theF > income that was generated by this money in the next few years ratherG > than be sunk into development of something which just might produce al) > profitable return in 3 or 4 years time.  >  > ***sM > Actually, it wouldn't.  Not only are the net savings illusory (feel free to N > offer up real evidence to the contrary:  so far, you have not), but even theM > gross savings claimed by Compaq (at most $300 million annually, more likely M > half that) will in all probability be offset *in the short term* by loss oftK > confidence in Alpha and/or Compaq (and resulting loss of sales that would.E > otherwise have occurred:  remember, as little as a 10% loss will betL > sufficient to offset any claimed saving, and when you couple the AlphacideG > with the subsequent screwing of Tru64 by the merger antics this seems  > absolutely inevitable).t > M > So it really doesn't matter what any supposed 'savings' will be applied to: D > Compaq would have been better off borrowing the money for any suchC > activities (if they're truly worthwhile) rather than 'saving' it.e > ***n > J > We are talking here of a thing called "business risk".  Perhaps when youD > are the CEO of a good sized company - not necessarily one with $24A > billion in assets and about 64,000 employees - you will be morei& > qualified to speak on these matters. >  > ***eN > Perhaps when you learn how to understand the material you presume to commentN > upon you will become more qualified to comment upon it.  Of course, you willI > still not be noticeably more qualified than I am, unless you also firsttN > become CEO of a good-sized company yourself and thus at least nominally in a; > position to offer those insights that you suggest I lack.t > ***r > N > > > 3.  Compaq appears to be run as four separate competing companies - VMS,J > > > NSK, Tru64 and NT - and this kind of attitude is a major obstacle toD > > > income growth.  These subcompanies never mention each other inM > > > advertising and, even worse, the sales philosophy seems to be to divideoL > > > the range of possible markets into four sectors - VMS being sandwichedL > > > between NSK and Unix - and that the given platform will ONLY advertiseE > > > to that sector.  To put it very politely, I just cannot see any 1 > > > reasonable justification for this approach.a > >aJ > > Any statement that suggests (as yours does above) that VMS competes onG > > anything like equal footing in the corporation is flat-out blind too
 > reality. > = > I am saying no such thing.  You have it wrong just like JF.m >  > ***eL > No, you again prefer to dispute a comment based on what you may have meantI > to say rather than what you actually said.  I referred to your specific N > statement above (and explicitly limited it to that), where you claim "CompaqF > appears to be run as four separate competing companies".  My commentG > indicated that they are neither separate nor do they compete on equaleI > footing:  this is the kind of lie by omission that I'd more expect fromaB > Compaq's spinners, but then again you appear to be becoming one. > ***a >  >   As I sayF > later in my post, the PC faction appears to have greatest influence.H > The playing ground is far from level; the niche market concept ensures > this.h > G > FWIW, I believe that this is the greatest single failing of Compaq, a J > marketing strategy that does not allow them to reap maximum profits fromF > the entire range of IT activities.  I am trying to discover why thisH > notion exists and who are the people with sufficient influence to haveJ > the idea adopted.  I have tried to bypass them with a argument direct toE > Michael Capellas.  I don't know if it will work but it is certainlyi > worth a try. >  > ***hG > It was.  We did (and it's hard to see how you'll be more effective oryK > eloquent on your own trying to do exactly the same thing than more than a*  > dozen of us were).  It failed. > ***  > I > > The most charitable interpretation I can come up with (of your entire H > > approach, not just this point) is that you've completely given up onM > > challenging Compaq's handling of its assets and are willing to grovel foro& > > whatever crumbs that might produce > J > I don't grovel for crumbs.  If I am going to bash my head against a wallC > I like to know that it is the right wall to be bashing.  Compaq'su# > OpenVMS people are not that wall.t >  > ***nJ > Not unless they choose to associate themselves with it.  Which is what I > said.g > ***  > K > > > 4.  The OpenVMS division within Compaq seems to be enthusiastic aboutnL > > > the platform and certainly want to improve sales.  The obstacles trulyL > > > seem to be elsewhere.  Given that only the VMS people in Compaq appearN > > > to read this newsgroup, any criticism here - constructive or otherwise - > > > is misdirected.  > >yN > > If your premise were correct, your conclusion would be as well.  But sinceJ > > both customers and the competition also read what transpires here (you > even) > > say so in your next point), it's not.n > E > Please give us the conclusive proof that the OpenVMS people are thetB > major obstacle and that the obstacle does not exist elsewhere in	 > Compaq.n >  > ***rH > Please cite specifically w here you got the absurd idea that I believeJ > anything of the kind.  You clearly need to devote some of the energy you3 > expend on writing to understanding what you read.u > ***f > A >   From what I have seen the OpenVMS people are enthusiastic ande@ > helpful but clearly they are sometimes constrained by what the$ > greater-Compaq permits them to do. >  > *** M > Aside from the occasional propensity of one or two of them to try to defendoJ > Compaq's to-all-appearances completely indefensible actions (but withoutE > providing any solid information to back up their defense), I agree.  > ***  > F > >  > ..I know that Compaq's VMS people are the "face of the company"K > > > from our perspective but when all of us are in violent agreement with H > > > our aims - but maybe not method! - it really makes little sense to > > > harangue them.)l > >eH > > I haven't noticed anyone haranguing them except when they attempt to	 > support L > > Compaq's lies (in which case confrontation is entirely appropriate, even > ifK > > one can also sympathize with the position they're in:  if they *really*  > haveM > > credible evidence that we lack on these matters, let them produce it - ord4 > > convince higher-ups that doing so is important). > G > I am sure that they have tried to convince those higher-ups but often  > without success. >  > ***eN > I'd certainly hope so, but that would actually reflect even more dismally on% > the situation than if they had not.i > ***l > 4 >   As for the nature of Compaq's "lies" you seem to > forget a few things. >  > ***iL > No, not really:  this is a matter I've made it a point to keep pretty well > aware of.t > ***i > E > The first thing is that they have more information than you on manyoF > matters and while you may be peerlessly correct on some issues there0 > other major factors that you are not aware of. >  > ***rC > A meaningless generalization absent specific *relevant* examples.k > ***  >  >   Do you for example knoweG > exactly how many VMS machines are now on maintenance contracts ?  How I > many compiler licenses are out there ?  How many systems are being soldn6 > because of Oracle, of Rdb, of software package XYZ ? >  > ***cL > Nope.  Nor is there any reason to believe that such *exact* details are at. > all important to the conclusions I've drawn. > F > For example, Compaq just stated that VMS systems bring in $2 billionN > annually in services revenue.  Just how that breaks down between maintenanceL > contracts, new-installation hand-holding, etc. is of only secondary (whichG > is not to say negligible) interest compared with the magnitude of thee > revenue itself.l > K > How many VMS systems are being sold because of Oracle is also interesting J > but mostly simply as an indication of how important Oracle support is toG > VMS.  A far more important question (unless you're only interested inmL > life-support for VMS) is how many VMS systems are *not* being sold because) > of the *lack* of some popular packages.  > L > To suggest that no conclusions can be drawn without *complete* informationM > is disingenuous.  If you want to be at all credible, you'll need to provideuN > credible information that calls into question my assertions, not just try toD > dismiss them because there *might* be other information out there. > ***t > G > Now I admit, I cannot be sure if the Compaq employees who support the H > company statements are doing so because they understand and agree withH > the basis for certain decisions, they have first hand knowledge of theJ > factors, they understand the consequences of some decision and know thatI > it is insignificant, or they just want to keep their jobs.  You are farsF > too willing to criticise them when if you were in their position you% > might do exactly as they have done.s >  > ***mK > You are far too willing to assume that just because *you* might have done K > exactly what they have done anyone else might as well.  I would not - I'dcE > keep my mouth shut if I couldn't contribute any additional relevantpN > information, or address directly the points I could (rather than ignore them% > as Compaq and its apologists have).  > ***i > M > > > 5.  In regard to the previous point, it seems that Compaq's competitorshN > > > have been using information from this newsgroup that criticizes Compaq'sJ > > > actions as regards VMS.  This can only have a negative affect on VMSK > > > sales and so it plays directly into the hands of the people in Compaqt- > > > who believe that VMS should be ignored.  > >SL > > So what?  It's abundantly clear that these people already have the upper( > > hand, so matters won't be any worse. > >wM > > VMS is not so much owned by Compaq (and these people who run it) as it ishH > > held hostage by it.  "Watch out!", you seem to be saying:  "If we do? > > anything to make them mad, they'll only make things worse!"b > ? > Is this the only exercise you get ?  Jumping to conclusions ?  >  > *** M > From one who is so ready himself to jump to conclusions without even havingtM > bothered to understand the material he's responding to, this is a laughablee > observation. > ***i > G > I am saying that any undermining of Compaq's VMS sales by postings towH > this newsgroup will not result in a positive adjustment of policy fromI > Compaq.  They are far more likely to reduce their resources and effortsuH > for VMS and at least most of us here would regard this as a BAD THING. >  > ***oN > I'd be interested in seeing exactly how you differentiate your new statementI > above from your original statement a bit farther above, and from my ownmH > rendition of it.  While there are differences in emphasis - e.g., yourL > original statement, and the portion my response most reacted to, specifiedN > explicitly the leverage that decreased VMS sales would give to VMS's enemiesL > in Compaq, whereas your rephrasing eliminates the suggestion that Compaq'sM > response would be anything more than a simple, non-political reaction - theo7 > actual content of all three is pretty much identical.e > ***  > L > > Well, things already *are* worse, and they got that way by following the* > > course of action you're promoting now. > D > Another wild assertion.  This course of action did NOT create this > response.v >  > ***yJ > For once you've caught me in a slightly ambiguous statement (rather thanJ > simply failed to parse it correctly yourself).  I did not mean to assertN > that the course of action you're promoting *caused* the problem, merely thatJ > it was the same course that had, consistently, failed to correct it overC > time (and hence had little likelihood of doing better now).  BothtD > interpretations are legitimate, so I could have phrased it better. > ***i >  > ...t > ( > >  A new course is indicated, one thatM > > will either make them sit up and take notice or result in their expulsionr > byL > > the BoD or the stockholders.  Yes, it *feels* risky, but Compaq has doneM > > such a good job of marginalizing VMS already that there's really not thateK > > much *actual* down-side risk left - and the potential up-side, as we've  > said > > for so long, is huge.r > D > As I said before, most of us would regard further reduction in VMS > resources as a bad thing.  >  > ***tM > But if the *threat* of revenue loss causes an *increase* in resources, mostcK > would consider that a *good* thing.  So it really depends on which aspectuH > (the risk, or the reward) one chooses to emphasize - in a manner aptlyJ > opposite to Compaq's own attitude toward VMS (take no risks, because the > presumed reward is nil). > ***g > 1 >   You might like to take the RISK of a completepG > termination of VMS but judging by the lack of posted support for youre> > attitude you do not speak for the majority of the folk here. > J > I took it upon myself to post the original document and this response toI > your response because I do not believe that a small number of outspokenp8 > critics should act against the wishes of the majority. >  > *** M > It's Spiro Agnew's 'silent majority' come back to life!  Isn't it wonderfulaM > how one can call upon it to support whatever position one may wish to take!n > M > As for me, I'll act as I see fit, whether in the majority or not (and which L > may be the case this time is far from clear).  And I expect others will doE > likewise, hopefully with at least some attempt to develop some reall > understanding of the issues. > ***r > # > >   What needs to be done in thishN > > > group (when we are not dealing with technical questions) is to encourageC > > > the growth of VMS sales and to show its advantages over otherlM > > > platforms.  (In regard to the former, reports of sales into new markets L > > > are always interesting and for the latter, just how difficult is it to4 > > > show the security advantages that VMS enjoys?) > >oK > > JF answered this more than adequately.  I suggest that you consider hishL > > points carefully (especially the issue of how ethical it is to encourageM > > others to adopt an at-risk platform without notifying them of said risks,rE > > simply in the hope that their presence will improve its chances).s > B > I believe that Compaq will be properly informing their potential > customerse >  > *** J > You mean, as they did about Alpha's long-term future right up until JuneI > 25th?  Or as they did about NT on Alpha's future right up until August,dI > 1999?  Or as they did about Tru64's future on Itanic until they changed  > their minds? > K > If Compaq had 'properly informed' their customers on a reliable basis, we % > wouldn't be having this discussion.p > ***t > ? >  and unlike you, they will be explaining the trade-in/tade-upn> > scheme which will take Alpha buyers onto the Intel platform. > F > I suggest that you consider how ethical it is for you to assume that > this is not being done >  > ***eK > See above.  It hasn't been done in the past, and they've chosen to lie totK > try to justify it rather than come clean.  If it's unethical to call thisuM > behavior to the attention of people who might be affected by it, then so beo > it.o > N > Of course, your ethics may be very different from mine:  as I said, you seem" > to think a lot like Compaq does. > ***x > - >  and to take it upon yourself to make thesei1 > assertions without validating your assumptions.s >  > ***rK > Just how much more validation do you feel is necessary?  Compaq's actionsnF > pretty much speak for themselves, but as log as people like you feelM > inclined to spin them otherwise people like me will be around to set things  > straight.l > ***b >  >   Ignorance is no excuseE > is a statement that commonly applies to law; perhaps it should alsoa > apply to newsgroup postings. >  > *** 6 > I sincerely hope that you take it to heart yourself. > ***  > F > > > 6.  In a broader picture we need to do what we can to reduce theM > > > influence of those people in Compaq who appear to have relegated VMS tor? > > > the "second division" of platforms (along with NSK).  ... > > > > We need to work with Compaq's VMS people to convince theF > > > decision-makers that there are very good reasons to increase theJ > > > publicity of VMS.  When that action results in greater VMS sales andJ > > > hence greater income, we will have clearly demonstrated that it is aH > > > platform which deserves rather more attention than it is currently > > > receiving. > >uK > > That's *exactly* what we tried 20 months ago, John.  It didn't work, ato > all. > I > And as you showed recently you seem completely unaware that things havet# > changed for IT in that 20 months.: > D > - According to April 2001 figures, in 1999 PCs made a loss of $386H > million.  In 2000 they improved and made a profit of $145 million, butJ > last year they made a loss of $587 million.  The enthusiasm for PCs that5 > Compaq had in July 2000 can no longer be justified.s >  > ***lM > And you suggest that this wasn't equally apparent 20 months ago?  I seem tonL > remember that it was apparent within the discussions our group had leadingL > up to the presentation we made, and (as you're so fond of pointing out) ifM > the numbers were evident to us Compaq certainly had even better information  > to go on.a > N > The difference between a modest loss in 1999 and a modest profit in 2000 was > hardly decisive. > E > Of course, even if Compaq deemphasize PCs that doesn't mean they'llmH > recognize the value of their non-'industry-standard' offerings.  TheirN > current favorite appears to be services, for example, though they're willingJ > to consider licensing HP/UX (since Tru64 is such a dog) to bolster their  > non-industry-standard line-up. > L > Face it, John:  Compaq's management is terminally screwed up, and the onlyE > question is how much of the company they'll destroy before they areN > replaced.k > ***a > H > -  According to a number of reports PC users are becoming reluctant toG > upgrade their systems just because of a new release of Windows.  ManyoJ > are saying that the market has reached saturation and that new sales areJ > only replacements.  Both factors say that PC growth is likely to be very$ > low, unlike the period up to 1999. >  > ***eK > Could be.  But Dell's sales (not just market share) are up significantly,iM > and so are those of lower-tier companies:  it's mostly the other first-tieroM > vendors that are experiencing major sales losses.  So Compaq may still haveiJ > hope (which I'd normally think was a *good* thing, but in this case...). > ***  > I > - September 11 caused a new awareness of the need for secure systems ofa6 > high availability.  This is perfectly suited to VMS. >  > ***lH > If this actually occurs, it's most likely yet another opportunity that > Compaq will pass up. > ***c > H > - VMS was late catching the e-software bandwaggon and in 2000 that wasG > the area of biggest demand.  That demand has substantially diminished @ > and the emphasis of IT has returned to a more general outlook. >  > ***fK > You're really starting to sound like a marketdroid, John.  Come back when*L > you can point to some significant VMS sales increases and I'll be happy to > change my opinions.l > ***r > @ > - System consolidation is increasing and this requires greaterD > reliability than before.  The loss of one system out of 10 runningJ > separate applications was a minor issue, but the loss of a single serverJ > running all 10 applications is a major problem.  Again, VMS is perfectly > suited to the task.h >  > ***eK > Well, not unless *all* the applications people want to run on that serverb > are supported on VMS.t > ***  > J > These are all factors that have changed the emphasis of the IT market inE > the last few years.  Many have created new opportunities for VMS or'3 > diminished the opportunities for other platforms.n >  > ***cA > New opportunities?  Possibly.  Unfortunately, VMS had plenty ofeH > opportunities *already* and Compaq reliable passed them up, so why oneC > should expect it to sit up and take notice now is far from clear.o > ***y > I > These are all good reasons why VMS should be unleashed from its niches.o >  > ***oI > Indeed they are, not that any additional reasons were needed.  We don't M > disagree nearly as much on what *should* happen with VMS as we do on what'si1 > *likely* to happen and how best to change that.e > N > If you choose to respond again, I ask only that each point you make add someN > identifiable item of information to the discussion and/or specifically use aK > supportable fact to refute something I've said:  otherwise, it's just hoty > air. >  > - bill   ne   ------------------------------  # Date: Mon, 21 Jan 2002 06:53:05 GMTo* From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: A position statementuA Message-ID: <lVO28.21640$jd7.1724544@bin6.nnrp.aus1.giganews.com>m  2 "JF Mezei" <jfmezei@videotron.ca> wrote in message& news:3C4B9D43.9B3A8E9C@videotron.ca... > Bill Todd wrote:G > > emphasise, as stated in the Q4 financials.  Had this demand for VMStA > > appeared early this year, the decision on Alpha may have beenl > > otherwise.)o  C Actually, I didn't - John did.  But Outhouse Express doesn't indentnJ responses normally for some messages (which is why I identified my own new comments inside *** pairs).   L I should, however, have added in responding to the above that VMS apparentlyB did considerably better in 2000Q4 than it did in 2001Q4, so if theK performance a year ago (coupled with Tru64's 30% annual growth rate at thatmL time) didn't sufficiently impress Compaq to save Alpha there's little reasonE to expect the last quarter's performance to have had any more effect.   G I don't know where John's head is, and his feet clearly are not plantedbJ firmly in reality.  Whether he has any interest in rectifying that (ratherF than continuing to blunder ahead following his instincts with his eyes  firmly shut) remains to be seen.   - bill   ------------------------------  % Date: Sun, 20 Jan 2002 18:40:13 -0500m' From: Glenn Everhart <Everhart@gce.com> B Subject: Re: Bill Gates admits security "non-existent" in windows!' Message-ID: <3C4B555D.B981F776@gce.com>   K The term "engineer" started as 'one who operates an engine'. This is how itoJ happened to be applied to the person who drove the railroad engine. It hasN come to mean other things in other areas, and has been made a partial monopolyL by civil and mechanical engineers apparently as a way to add to their incomeH by imposing a control on the use of the term. However the original usageI is entirely appropriate to one who operates an engine where the operation H requires some skill and the laws in question have only very questionableI justification. A person who claims he is a software engineer is in littleoJ or no danger of convincing anyone he knows civil or mechanical engineeringI (and is likely not to know much electrical engineering either). Ditto ands, even more so for the guy who drives a train.  L Claiming that only the P.E. is a "true" engineer is an unwarranted intrusionH onto everyone's freedom of speech. The "justification" that others might9 be confused as P.E. holders is a pretty transparent ploy.l  + The term has a much broader usage history..     
 cjt wrote: >  > Bob Koehler wrote: > >th > > In article <dyW18.213924$pa1.58000065@news3.rdc1.on.home.com>, "John Smith" <a@nonymous.com> writes:E > > > In the US, the term 'Engineer' can be, and is used, in a rather R > > > fast-'n'-loose way. Generally accepted to be somebody who designs or createsJ > > > something in traditional engineering disciplines, or in the field ofI > > > software development, someone who deals with numerical methods [not Q > > > accounting :-) ] in the financial services field, or the guy who drives thetN > > > train. Only the person who has P.E. after their name is a true engineer. > > >mI > > > The term 'Engineer' is a legally protected concept/title in Canada.s > >eJ > >    Would cause great difficulty with the sanitational engineer's union > >    in the states.s > J > It is probably one of the leading ways to keep engineering salaries low.   ------------------------------  # Date: Mon, 21 Jan 2002 03:14:41 GMTo0 From: John Santos <john.santos@post.harvard.edu>B Subject: Re: Bill Gates admits security "non-existent" in windows!> Message-ID: <MPG.16b551a95f72c21b989690@news.bellatlantic.net>  @ In article <3C4B555D.B981F776@gce.com>, Everhart@gce.com says...M > The term "engineer" started as 'one who operates an engine'. This is how itiL > happened to be applied to the person who drove the railroad engine. It hasP > come to mean other things in other areas, and has been made a partial monopolyN > by civil and mechanical engineers apparently as a way to add to their incomeJ > by imposing a control on the use of the term. However the original usageK > is entirely appropriate to one who operates an engine where the operationeJ > requires some skill and the laws in question have only very questionableK > justification. A person who claims he is a software engineer is in little L > or no danger of convincing anyone he knows civil or mechanical engineeringK > (and is likely not to know much electrical engineering either). Ditto and . > even more so for the guy who drives a train.  A I believe this to be false history.  An engineer was someone who  C designed and built engines, not someone who operated them.  Engines)@ were any mechanical contrivance, including things like roads and> bridges as well as things with moving parts.  These terms longF predate the invention of the steam engine.  Civil engineers (designersF of roads, bridges, aqueducts, ports, etc.) are one of the oldest types@ of engineers, dating back to Roman times.  This term was used in< contrast to military engineers, who designed fortifications,  encampments, siege engines, etc.  + Mechanical engineering is much more recent.w  N > Claiming that only the P.E. is a "true" engineer is an unwarranted intrusionJ > onto everyone's freedom of speech. The "justification" that others might; > be confused as P.E. holders is a pretty transparent ploy.o  > I think the licensing of engineers occurred because of variousB disasters and near-disasters perpetrated by unqualified engineers.  - > The term has a much broader usage history..n  
 Yes, it does.    > cjt wrote: > >  > > Bob Koehler wrote: > > > j > > > In article <dyW18.213924$pa1.58000065@news3.rdc1.on.home.com>, "John Smith" <a@nonymous.com> writes:G > > > > In the US, the term 'Engineer' can be, and is used, in a rather T > > > > fast-'n'-loose way. Generally accepted to be somebody who designs or createsL > > > > something in traditional engineering disciplines, or in the field ofK > > > > software development, someone who deals with numerical methods [noteS > > > > accounting :-) ] in the financial services field, or the guy who drives theeP > > > > train. Only the person who has P.E. after their name is a true engineer. > > > > K > > > > The term 'Engineer' is a legally protected concept/title in Canada.r > > >tL > > >    Would cause great difficulty with the sanitational engineer's union > > >    in the states.u > > L > > It is probably one of the leading ways to keep engineering salaries low.     -- o John   ------------------------------    Date: 21 Jan 2002 07:47:38 +0800, From: Paul Repacholi <prep@prep.synonet.com>= Subject: Re: Bill Gates: No Trustworthy Platform exists today - Message-ID: <87r8okwpnp.fsf@prep.synonet.com>T  ? wayne@tachysoft.xxx.120519.killspam.00c7 (Wayne Sewell) writes:   F > Unless the contract specified that billy could only sell the product? > and could make *absolutely no changes* to the code, the wholenE > exercise would be pointless.  After about three days, the pollutionrE > caused by microshit "developers" would reduce the once powerful andiA > stable vms code to the level of the rest of the billy software.d@ > After all, NT started with a very vmslike kernel and look whatE > happened to it.  All the layers of billyshit on *top* of the kernel 9 > made it useless.  Billy would do the same thing to vms.d  H Anyone else remember SE 3.51? Mind, there is not much $150 a pop revinue: in a secure, solid OS. No atraction to billygoat at all...       --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.p@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 21 Jan 2002 08:43:10 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Buffer Overflowse- Message-ID: <87n0z8wn35.fsf@prep.synonet.com>-  / Kilgallen@SpamCop.net (Larry Kilgallen) writes:t  = > In article <a29p58$1hh$1@milo.mcs.anl.gov>, "Tony Scandora"n  > <scandora@cmt.anl.gov> writes:  tC > > Think of using descriptors as flying the helium-filled GoodyearhA > > blimp, and having to find the null terminator of every string = > > before using it as flying the hydrogen-filled Hindenberg.p   A > According to PBS it was not the hydrogen inside that caused the E > Hindenberg explosion, but rather a flamable coating on the outside.t  B I saw a report that someone had found a pile of old paperwork whenA this issue was floated. Including the lab report, and an order ton8 replace the envelope as soon as it returned from the US.   -- a< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Mon, 21 Jan 2002 04:42:28 GMTi4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>@ Subject: Re: building a vms box as a project.. is this possible?0 Message-ID: <3C4B9B51.E24ABD0A@blueyonder.co.uk>   Herb Asher wrote:t > 1 > On Sat, 19 Jan 2002 22:30:11 GMT, Tim Llewellyno) > <tim.llewellyn@blueyonder.co.uk> wrote:M > I > >> Also, any uk vms people who can recomend a retailer for decommisoneduK > >> boxes? I have had a scan of the net, including ebay and it doesnt looki > >> that good.  > >eV > >www.prodec.co.uk used to , but they don't seem to have the Digital section anymore. > >e: > >How about a new low cost alpha from www.islandco.co.uk? >  > Tim,G > Are you sure about that islandco.co.uk link? There is an islandco.com C > in the States but I need to look into import costs. Is there a UKi > division of that company?i >  > Herb >   J sorry, I meant www.islandco.com. I have some posting problems with the ISPA to me, I thought  I'd corrected and canceled the post with .co.uk       o   -- n Tim.Llewellyn@cableinet.co.uk  a  C Standard disclaimer applies. My views in no way represent those of a! my employers or service provider.i   ------------------------------  # Date: Sun, 20 Jan 2002 20:01:47 GMTI1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o8 Subject: Re: Capellas wants IBM model, but does reverse!' Message-ID: <3C4B232F.FF9B622C@fsi.net>'   JF Mezei wrote:p >  > "David J. Dachtera" wrote:K > > Important thing to remember about IBM: IBM is *NOT* a computer company!uI > > IBM is a *MARKETING* company that designs, builds and sells computerso0 > > and many other office and business machines. > P > I think that IBM started off as a marketing company, evolved (devolved ?) intoO > a brainwashing company, but I think that since the mid 1990s when IBM startedlN > to awaken to other people's technologies (ethernet, tcpip, unix and even NT)) > and improved its mentality quite a bit.t > M > No longer the closed shop with such a strong "NIH" syndrome it used to havenN > ("If IBM didn't invent it, then it could not possibly exist"). The fact thatP > IBM went into outsourcing also helped because they needed to have the image of3 > being able to run any system, not just their own.g > N > Yeah, they are still strong in marketing, but you need that for any computerJ > company. But IBM has become more agressive with its prices  and isn't as. > snobbish with its attitude as it used to be.  H Agreed. An example that OpenVMS and the related hardware areas of Compaq would do well to follow.   -- o David J. Dachtera  dba DJE Systemsv http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/V   ------------------------------  % Date: Sun, 20 Jan 2002 21:08:44 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch>s8 Subject: Re: Capellas wants IBM model, but does reverse!5 Message-ID: <3C4B23CB.EF608979@swissonline.delete.ch>*   "David J. Dachtera" wrote: >  > JF Mezei wrote:t > >, > > "David J. Dachtera" wrote:M > > > Important thing to remember about IBM: IBM is *NOT* a computer company!iK > > > IBM is a *MARKETING* company that designs, builds and sells computers 2 > > > and many other office and business machines. > >e ...o > >fP > > Yeah, they are still strong in marketing, but you need that for any computerL > > company. But IBM has become more agressive with its prices  and isn't as0 > > snobbish with its attitude as it used to be. > J > Agreed. An example that OpenVMS and the related hardware areas of Compaq > would do well to follow.    G And of course they don't appear to use niche marketing.  They are happy D to sell any platform to anyone for anything.  The customer makes theE choice; it's not the seller who chooses what to sell to the customer.i  @ No major obstacles in their marketing approach...unlike Compaq !     John McLeanC   ------------------------------  % Date: Sun, 20 Jan 2002 22:40:56 -0000t= From: "David McKenzie" <david.mckenzie@spitfire0.demon.co.uk>i( Subject: Re: Change quorum disk questionB Message-ID: <1011566539.26181.0.nnrp-01.c1edba74@news.demon.co.uk>  @ Not true, the quorum disk vote(s) are always taken into account.  K Note that a quorum disk will lead to longer cluster transition times as the L cluster will have to wait (N+1)Qdiskinterval before it can safely assume the- last access to the quorum disk has been made.   J Quorum disk is almost always of no use unless you have a two node cluster.K Note also, it is not much use if it is not directly connected to all nodes.h  - "Hans Vlems" <hvlems@iae.nl> wrote in messagea, news:inf28.7247$E82.20632@typhoon.bart.nl...I > In a three node cluster where all nodes have VOTES set to 1 there is no  > need'D4 > for a quorum disk to survive the loss of one node.6 > A quorum disk is useful in the following situations:K > - in a two-node cluster, provided that the quorum disk is visible to boths > nodes;< >   AFAIK that was the original reason for a "quorum device"L > - in a multi node cluster where you always want to have one group of nodesH >   avoid hanging in a cluster transition state. Usually there are other ways
 > of doing	 >   that. G > IIRC  quorum disk votes are not taken into the computation as long asn theret > is quoruml > delivered by system votes. >a > Hans >hH > Robert DiRosario <robert.j.dirosario.1@gsfc.nasa.gov> wrote in message) > news:3C483E22.34235FB0@gsfc.nasa.gov...n > >  > >n > > Hans Vlems wrote:s > >r0 > > > P.Young@unsw.EDU.AU (Patrick Young) wrote:C > > > >Robert DiRosario <rdirosario@starpower.net> wrote in message*+ > news:<3C4773C9.E4851B5E@starpower.net>...e > > > >>H > > > >> The system disk is the quorum disk, and I see now that I should haveH > > > >> changed that before I added the second system.  How do I changeJ > > > >> that now?  Can I copy the quorum.dat file to the new quorum disk,J > > > >> take one node down, edit modparms.dat and run autogen on the nodeC > > > >> that's up, take it down and do the same on the other node?  > > > >> > > > > K > > > >I'm not sure QUORUM.DAT contains any data that needs to be preservedrH > > > >between reboots so I don't think you need to worry about making a > > > >copy of it... > > > >hC > > > > 00010002 454C4946 20204D55 524F5551 QUORUM  FILE.... 000000 C > > > > 00A0831A 2A8798BD 00A08319 06E9CA08 ........*.... 000010 C > > > > 00A0831A 09C50480 00A0831A 2B298FD8 .)+........... 000020tC > > > > 04010000 00000404 00030002 00010002 ................ 000030hC > > > > 00000000 00000000 3DA38CAA 00000000 .....=........ 000040* > > > > @ > > > >Simply shut down one computer (disk watcher), modify your
 MODPARAMS.DAT*L > > > >on the other (disk watcher), autogen, and reboot. Boot the other then > do > > > >the same thing. > > > >oK > > > >The cute thing about this is the first time you mount the new quorumoJ > > > >disk you will notice it will automagically get a QUORUM.DAT created$ > > > >on it right before your eyes. > > > >iH > > > >Make sure you mount the (new non system disk) QUORUM disk on bothA > > > >nodes (disk watchers) on startup when all done - this is a  > > > >requirement. I > > > You are quite right but OTOH it is possible to define a quorum diskmB > > > on a node that has no direct connection to that quorum disk.H > > > In fact in an NI cluster you can have two nodes, each with votes=1J > > > and each have its own quorum disk (i.e. two different quorum disks).I > > > I know of a heavily used NI cluster that operated like that for twof > years.H > > > before we found out that it was not only unsupported but also very > dangerouse< > > > because of possible disk corruption. Don't try this at? > > > home, but it just shows how flexible a VAXcluster can be.e > > >(
 > > > Hans > > >t > > > http://www.zfree.co.nz > >*F > > I have one more system to add to the cluster that will have direct access" > to the system disk, a 4000/105A.K > > After I add that system this weekend I don't think the quorum disk willi be > useful.  With or without aK > > quorum disk it looks like I need to have two of the three systems up tol# > have a quorum, unless there is ans< > > undocumented method of giving the quorum disk two votes. > >h
 > > Robert > >h >f >    ------------------------------  % Date: Sun, 20 Jan 2002 22:33:58 +0100n, From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: ClipArt of VAX equipmentt& Message-ID: <3C4B37C5.C67929F9@gmx.ch>   Steven Whatley wrote:- > 	 > Hi all,- > F > I'm putting together a configuation diagram of our VAX setup.  I wasH > wonder if there is a source for clip art images of VAX equipment.  I'm> > looking one of an InfoServer 150.  BTW, I'm using Visio 6.0. > 	 > Thanks,e > Steven  N There is (was?) a DEC internal VISIO library with all equipments inside. MaybeJ this library file could be made available on the next OpenVMS freeware CD?   D. -- eH   ----------------------------------------------------------------------E MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.html E Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670e/ 19, chemin de la Butte, 31400 Toulouse, France.m  H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais Man spricht Deutsch se habla Castellano English spoken   ------------------------------  % Date: Sun, 20 Jan 2002 22:34:48 +0100e, From: Didier Morandi <Didier.Morandi@gmx.ch>! Subject: Re: DECwindows autologint& Message-ID: <3C4B37F7.A9786CD5@gmx.ch>   "Stanley F. Quayle" wrote: > ; > When a workstation boots, is there a way to have the tubes, > automatically log in as a particular user?  	 What for?s   D. -- rH   ----------------------------------------------------------------------E MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.html<E Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670m/ 19, chemin de la Butte, 31400 Toulouse, France.n  H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais Man spricht Deutsch se habla Castellano English spoken   ------------------------------  % Date: Sun, 20 Jan 2002 17:56:20 -0500t* From: "Stanley F. Quayle" <stan@stanq.com>! Subject: Re: DECwindows autologin - Message-ID: <3C4B04C4.1540.47BD470@localhost>   / On 20 Jan 2002, at 22:34, Didier Morandi wrote:e  = > > When a workstation boots, is there a way to have the tuber. > > automatically log in as a particular user? >  > What for?W  ? When the machine boots, we'd like it to automatically start up  D DECwindows and run a particular Motif application without requiring  any user input.g    
 --Stan Quayle-! President, Quayle Consulting Inc.e  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671j1 8572 North Spring Ct. NW, Pickerington, OH  43147i= Preferred address:  stan@stanq.com       http://www.stanq.coml   ------------------------------  # Date: Mon, 21 Jan 2002 03:16:57 GMTy1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r! Subject: Re: DECwindows autologin & Message-ID: <3C4B8929.DBE0DCB@fsi.net>   "Stanley F. Quayle" wrote: > 1 > On 20 Jan 2002, at 22:34, Didier Morandi wrote:a > ? > > > When a workstation boots, is there a way to have the tubep0 > > > automatically log in as a particular user? > > 
 > > What for?e > @ > When the machine boots, we'd like it to automatically start upE > DECwindows and run a particular Motif application without requiringk > any user input.   H I wonder if you could do it via a .COM file as a detached process. MaybeG use an arbitrary WAIT until it's safe to assume that the window managernF has started, then SET DISPLAY to the local IP address and kick-off theA program. You can establish the user id. of the process on the RUNr, command used to create the detached process.  ) Dunno for sure, but may be worth a try...e   --   David J. Dachterae dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/d   ------------------------------  # Date: Mon, 21 Jan 2002 04:37:53 GMTn- From: "John E. Malmberg" <wb8tyw@qsl.network>d! Subject: Re: DECwindows autologinc* Message-ID: <3C4B9F85.2090405@qsl.network>   David J. Dachtera wrote:   > "Stanley F. Quayle" wrote: > 1 >>On 20 Jan 2002, at 22:34, Didier Morandi wrote:r >> >>= >>>>When a workstation boots, is there a way to have the tubeg. >>>>automatically log in as a particular user? >>>E@ >>When the machine boots, we'd like it to automatically start upE >>DECwindows and run a particular Motif application without requiringu >>any user input.  >> > J > I wonder if you could do it via a .COM file as a detached process. MaybeI > use an arbitrary WAIT until it's safe to assume that the window managereH > has started, then SET DISPLAY to the local IP address and kick-off theC > program. You can establish the user id. of the process on the RUNe. > command used to create the detached process.     There are two other steps.   1. Disable the login prompt.  F 2. Enable the security for the DECWindows Server process to allow the  application to be displayed.  H I do not recall the exact commands off the top of my head, but a search J of the archives of this list for http://www.google.com should reveal them.   -John  wb8tyw@qsl.network Personal Opinion Onlyn    :   ------------------------------  # Date: Mon, 21 Jan 2002 04:56:55 GMT 4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>! Subject: Re: DECwindows autologin 0 Message-ID: <3C4B9EB2.6550A094@blueyonder.co.uk>   "Stanley F. Quayle" wrote: > 1 > On 20 Jan 2002, at 22:34, Didier Morandi wrote:o > ? > > > When a workstation boots, is there a way to have the tubeb0 > > > automatically log in as a particular user? > > 
 > > What for?  > @ > When the machine boots, we'd like it to automatically start upE > DECwindows and run a particular Motif application without requiringa > any user input.   < I seem to remember posts from some years back on doing this.= I can't remember the solution or more details offhand, sorry.l  ? My solution, post-it the password and username to the terminals D if you really do want to trust security to something other than VMS./ Start the application using the session managere     regards  >  > --Stan Quayle # > President, Quayle Consulting Inc.u >  > ----------I > Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671t3 > 8572 North Spring Ct. NW, Pickerington, OH  43147e? > Preferred address:  stan@stanq.com       http://www.stanq.comt   -- p Tim.Llewellyn@cableinet.co.uk  s  C Standard disclaimer applies. My views in no way represent those of .! my employers or service provider.p   ------------------------------  % Date: Sun, 20 Jan 2002 05:02:17 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>C0 Subject: Re: DS20 PCI bus configuration question1 Message-ID: <A5H28.229$PZ4.4398@news.cpqcorp.net>   I I don't know anything about the KZPAC, but the graphics cards will run onaJ any PCI bus.  But if the card will be the console, *that* card may have toJ be in the bus that contains the ISA bridge (depending on the graphics cardL in question).  Any other restrictions on graphics boards would only exist toH work around hardware bugs in the graphics option (I've seen cards in theL past that, for instance, didn't handle config cycles correctly when behind a PCI-PCI bridge).      > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:$jXggV9sRdmP@malvm6.mala.bc.ca... >dJ >   I recently had a problem with a DS20 wherein data on a KZPAC would getE > silently corrupted ( no errors logged but the data read back wasn't ( > always the same as the data written ). >i= >   It appears that the reason this was happening was becausee? > the controller was on PCI bus 0 and it only works properly onrA > PCI bus 1.  I also understand that the graphics cards only workd? > properly on bus 0, not bus 1. I had the graphics card and the 8 > KZPAC in adjacent slots on bus 0, I don't know if this: > contributed to the problem or not ( ie does a KZPAC work3 > ok on bus 0 if there's no graphics card there? ).  >s? >    All this led me to wonder if these configuration rules are @ > all collected anywhere or if there is a rule-of-thumb to apply: > when setting up a DS20. Anyone know somehere this wisdom& > is available in a consolidated form? >m: >    I'd also like to understand how the data got silently; > mangled. I could understand errors being logged if thingsA> > are misconfigured but not how it could get perverted without7 > anything noticing. I presume it was getting corruptedu> > during the transfer on the PCI bus, but shouldn't there have: > been parity errors logged in that case? ( it appears the5 > corruption was typically single bit errors ). Is iti= > supposed to work like this or is there some console settingy= > that might be messed up? I notice in the ARC console theresa7 > an option to turn off PCI bus parity, is there an SRM " > option that does the same thing? >o? >   ps. It would also be nice if the firmware would whine if itd> > finds PCI widgets in unsupported slots ( like it appears the; > PWS systems do if you put unsupported stuff in the 64 bitI
 > slots ). >i   ------------------------------  % Date: Sun, 20 Jan 2002 14:20:52 +0000p1 From: Robert DiRosario <rdirosario@starpower.net>l' Subject: How to set up MOP boot server.l- Message-ID: <3C4AD244.3A147778@starpower.net>y  E I'm trying to add a VAX Station to my VAX cluster to allow me to readeE the VMS Documentation CD, so I can figure out what I'm doing with thep network stuff.  C How do I start a boot server?  I think I need DECnet MOP.  I have 24D 4000/106A's with DSSI and ethernet.  I have DECnet phase IV running.  H Can I use LANCP?  I used cluster_config to setup my cluster.  (I thoughtH that cluster_config_lan was for LAVC clusters, which shows just how long it's been since I've used VMS!)o  < Is there any difference between starting DECnet with "submit1 sys$manager:startnet" and "start/network decnet"? 4 (Other than the fact that one runs has a batch job.)   Thanks Robert   ------------------------------  % Date: Sun, 20 Jan 2002 22:44:44 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>+ Subject: Re: How to set up MOP boot server.i& Message-ID: <3C4B3A4C.5D23E6FC@gmx.ch>   Robert DiRosario wrote:  > G > I'm trying to add a VAX Station to my VAX cluster to allow me to read G > the VMS Documentation CD, so I can figure out what I'm doing with the  > network stuff. > E > How do I start a boot server?  I think I need DECnet MOP.  I have 2 F > 4000/106A's with DSSI and ethernet.  I have DECnet phase IV running.  N Run cluster_config again and answer Yes when it asks if your current mode will be a boot server or not.   > Can I use LANCP?  N Yes you can. Run cluster_config and answer Yes when it asks if you want to use LANCP instead of DECnet.  M To add your node, run cluster_config and tell it that you wish to add a node.yM Give its root directory the name SYS1 (for example) and be ready to enter its:K Ethernet MAC address. This is how the satellite will be "recognized" by the: server when trying to MOP boot.e  L Then follow the instructions. The procedure will remote reboot the satellite- with autogenerated parameters to do MOP boot.   N Should be easy. If it's not, come back here. I did it successfully a few weeks! ago (without reading the FAQ :-)    > > Is there any difference between starting DECnet with "submit3 > sys$manager:startnet" and "start/network decnet"?e6 > (Other than the fact that one runs has a batch job.)  L No. But do not forget to edit systartup_vms.com to remove the comment on the line which starts DECnet.c   > Thanks You're welcome   > Robert Didier   -- uH   ----------------------------------------------------------------------E MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmlnE Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670m/ 19, chemin de la Butte, 31400 Toulouse, France.   H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais Man spricht Deutsch se habla Castellano English spoken   ------------------------------  % Date: Sun, 20 Jan 2002 23:16:47 +0000 1 From: Robert DiRosario <rdirosario@starpower.net>f+ Subject: Re: How to set up MOP boot server.m- Message-ID: <3C4B4FDF.9AD94015@starpower.net>.   Didier Morandi wrote:o >  > Robert DiRosario wrote:m > > I > > I'm trying to add a VAX Station to my VAX cluster to allow me to read I > > the VMS Documentation CD, so I can figure out what I'm doing with theQ > > network stuff. > >nG > > How do I start a boot server?  I think I need DECnet MOP.  I have 2rH > > 4000/106A's with DSSI and ethernet.  I have DECnet phase IV running. > P > Run cluster_config again and answer Yes when it asks if your current mode will > be a boot server or not. >  > > Can I use LANCP? > P > Yes you can. Run cluster_config and answer Yes when it asks if you want to use > LANCP instead of DECnet. > O > To add your node, run cluster_config and tell it that you wish to add a node.nO > Give its root directory the name SYS1 (for example) and be ready to enter itsiM > Ethernet MAC address. This is how the satellite will be "recognized" by the"! > server when trying to MOP boot.  > N > Then follow the instructions. The procedure will remote reboot the satellite/ > with autogenerated parameters to do MOP boot.a > P > Should be easy. If it's not, come back here. I did it successfully a few weeks" > ago (without reading the FAQ :-) > @ > > Is there any difference between starting DECnet with "submit5 > > sys$manager:startnet" and "start/network decnet"?e8 > > (Other than the fact that one runs has a batch job.) > N > No. But do not forget to edit systartup_vms.com to remove the comment on the > line which starts DECnet.r > 
 > > Thanks > You're welcome > 
 > > Robert > Didier >  > --J >   ----------------------------------------------------------------------G > MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmlmG > Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670 1 > 19, chemin de la Butte, 31400 Toulouse, France.e > J > Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseJ > On parle franais Man spricht Deutsch se habla Castellano English spoken  H OK, I ran cluster_config and changed node A to be a boot server, did an ( autogen and reboot and that worked.  :-)   Thanks.a Robert   ------------------------------  % Date: Sun, 20 Jan 2002 15:10:01 -0500M. From: Lyndon Bartels <lbartels@pressenter.com>3 Subject: Netscape not loading security certificates0. Message-ID: <3C4ADDC9.522D8A03@pressenter.com>   Alpha OpenVMS 7.21 Netscape 3something2      G On my workstation, I'm nolonger able to surf the net. Whenever I try to = hit any site outside our network I get the following message:   2 The server's certificate has an invalid signature.6 You will not be able to connect to this site securely.    = A new firewall stuff was invoked. I think we're using our own F certificates. I was given new certificates to load, but surfing aroundF the the menu options within Netscape, I can't find any way to import a certificate.   Any help would be appreciated.     Thanks in advance,   Lyndon --  G My opinions are mine and mine alone. They seldom align with those of myr	 employer.l    H The only good thing about putting the cart before the horse is you don't have to look at the horse's butt.   ------------------------------  % Date: Sun, 20 Jan 2002 16:06:07 -0500 + From: "Main, Kerry" <Kerry.Main@compaq.com>o$ Subject: RE: Newbie Help on SecurityT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1BAF@kaoexc01.americas.cpqcorp.net>   Robin,  * re: setting up tight security for OpenVMS:  & A few references: Long urls may wrap -C http://www.openvms.compaq.com:8000/index.html#ovmsdocset OS doc setp  9 By the way, the complete OpenVMS doc set can be found at:t- http://www.openvms.compaq.com:8000/index.html    Guide to System SecurityC http://www.openvms.compaq.com:8000/73final/6346/6346pro.html (html) H http://www.openvms.compaq.com:8000/73final/documentation/pdf/ovms_73_sys _sec.pdf    The OpenVMS FAQ can be found at:5 http://www.openvms.compaq.com/wizard/openvms_faq.htmlW   Regards,    
 Kerry Main Senior Consultant  Compaq Canada Corp.  Professional Servicesl Voice: 613-592-4660l Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----& From: Robin [mailto:rlb@austin.rr.com] Sent: January 20, 2002 11:11 AM, To: Info-VAX@Mvb.Saic.Comn  Subject: Newbie Help on Security    @ We have a DS10 running OpenVMS 7.3 with Compaq TCP/IP 5.1.  WhenC this server was originally installed I was told there would need to > be no access thru the firewall to this machine -- local accessC only.  Now, they want certain users in remote offices to be able top
 telnet in.  B I know that VMS is considered "unhackable" but I'm sure that comes2 with the caveat that security is set up correctly.  @ Can someone point me in the direction of some documentation thatD might be helpful to make sure this machine's security is tight?  I'dC like to be able to restrict access by IP address if at all possible-' and any other restriction I can set up.e  B The documentation on Compaq's site seems to be very general or, asD might be the case, just flying over my head since my experience with? VMS system management is new.  I've ordered a system managementt? guide for OpenVMS but it hasn't been published yet so I'm stille waiting.   Thanks,l Robink   ------------------------------    Date: 20 Jan 2002 18:06:23 -0800( From: bob@instantwhip.com (Bob Ceculski)$ Subject: Re: Newbie Help on Security= Message-ID: <d7791aa1.0201201806.4cad09bb@posting.google.com>F  T Robin <rlb@austin.rr.com> wrote in message news:<3C4AEC17.2D6719E1@austin.rr.com>...B > We have a DS10 running OpenVMS 7.3 with Compaq TCP/IP 5.1.  WhenE > this server was originally installed I was told there would need to-@ > be no access thru the firewall to this machine -- local accessE > only.  Now, they want certain users in remote offices to be able to5 > telnet in. > D > I know that VMS is considered "unhackable" but I'm sure that comes4 > with the caveat that security is set up correctly. > B > Can someone point me in the direction of some documentation thatF > might be helpful to make sure this machine's security is tight?  I'dE > like to be able to restrict access by IP address if at all possibleo) > and any other restriction I can set up.c > D > The documentation on Compaq's site seems to be very general or, asF > might be the case, just flying over my head since my experience withA > VMS system management is new.  I've ordered a system managementbA > guide for OpenVMS but it hasn't been published yet so I'm stilla
 > waiting. > 	 > Thanks,o > Robin   L The last time I was on version 4. something of ucx, it didn't support packetK filtering ... that is one advantage of TCPware for vms, you can set up your1H own filtering files, or create what are called "outgoing" and "incoming"O access restrictions from within "$ NETCU", the TCPware management interface ...-: by packet filter you would create a file and put in it ...  4 permit tcp xxx.xxx.xxx.xxx 255.255.255.255 0 0 eq 23 deny tcp 0 0 0 0 eq 23  I the permit could be done for multiple ip addrs or a range of ip addrs ...2M this is also possible using multinet but tcpware we proved to be the crispestsD ip stack for vms as it is the only stack based on the vms kernel ...   ------------------------------  # Date: Mon, 21 Jan 2002 04:52:02 GMTl4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>$ Subject: Re: Newbie Help on Security0 Message-ID: <3C4B9D37.B2C99F66@blueyonder.co.uk>   Bob Ceculski wrote:M > V > Robin <rlb@austin.rr.com> wrote in message news:<3C4AEC17.2D6719E1@austin.rr.com>...D > > We have a DS10 running OpenVMS 7.3 with Compaq TCP/IP 5.1.  WhenG > > this server was originally installed I was told there would need tosB > > be no access thru the firewall to this machine -- local accessG > > only.  Now, they want certain users in remote offices to be able to  > > telnet in.  J so, it sounds like a job for your firewall management team, they should beE able to open up access to your intranet for specific hosts/subnets or ( whatever the other side of the firewall.  F If you are running UCX/TCP/IP Services then you can restrict access onM a per service level to individial IP addresses/subnets, but thats more usefuly< if you don't trust other users on YOUR side of the firewall.   regards>     > >nF > > I know that VMS is considered "unhackable" but I'm sure that comes6 > > with the caveat that security is set up correctly. > >sD > > Can someone point me in the direction of some documentation thatH > > might be helpful to make sure this machine's security is tight?  I'dG > > like to be able to restrict access by IP address if at all possible + > > and any other restriction I can set up.s > >hF > > The documentation on Compaq's site seems to be very general or, asH > > might be the case, just flying over my head since my experience withC > > VMS system management is new.  I've ordered a system management C > > guide for OpenVMS but it hasn't been published yet so I'm stillE > > waiting. > >f > > Thanks,d	 > > Robinp > N > The last time I was on version 4. something of ucx, it didn't support packetM > filtering ... that is one advantage of TCPware for vms, you can set up yourtJ > own filtering files, or create what are called "outgoing" and "incoming"Q > access restrictions from within "$ NETCU", the TCPware management interface ...0< > by packet filter you would create a file and put in it ... > 6 > permit tcp xxx.xxx.xxx.xxx 255.255.255.255 0 0 eq 23 > deny tcp 0 0 0 0 eq 23 > K > the permit could be done for multiple ip addrs or a range of ip addrs ...iO > this is also possible using multinet but tcpware we proved to be the crispest F > ip stack for vms as it is the only stack based on the vms kernel ...   -- n Tim.Llewellyn@cableinet.co.uk  t  C Standard disclaimer applies. My views in no way represent those of c! my employers or service provider.r   ------------------------------  % Date: Sun, 20 Jan 2002 21:11:02 -0800 % From: Dean Woodward <deanw@rdrop.com>a$ Subject: Re: Newbie Help on Security) Message-ID: <3C4BA2E6.3681C941@rdrop.com>m   Tim Llewellyn wrote: > H > If you are running UCX/TCP/IP Services then you can restrict access onO > a per service level to individial IP addresses/subnets, but thats more useful > > if you don't trust other users on YOUR side of the firewall.  G And the sufficiently paranoid will have *no* users on the same firewall H interface as the server(s) that aren't explicitely trusted, i.e., systemC managers. And no matter what IP stack, platform or OS, the firewalldE should be a separate box from the application server. With luck, youreG f/w can scream for help when it realizes it's been breached, and before2E it can be silenced.  If it's all on one box, that scream for help mayo well be too late.:   Sufficiently Paranoid,   ------------------------------    Date: 20 Jan 2002 17:44:59 -0800( From: bob@instantwhip.com (Bob Ceculski)1 Subject: Re: Purveyor is superior for VMS - proof = Message-ID: <d7791aa1.0201201744.1d844ac3@posting.google.com>   [ Arne Vajhj <arne.vajhoej@gtech.com> wrote in message news:<3C4B05E5.BA8F366A@gtech.com>...r > Bob Ceculski wrote: _ > > Arne Vajhj <arne.vajhoej@gtech.com> wrote in message news:<3C49B575.37BA876B@gtech.com>...tA > > > Any web-server that supports DCL can run scripts written inw- > > > any language (including java and Perl).D > > > B > > > But performance usually sucks with that approach. ActivatingA > > > the JVM or the Perl interpreter for each script call is note' > > > a solution for high-volume stuff.c > > O > > wrong ... we tested cgi scripting performance from every angle and it workstP > > best to pass the www symbols/logicals to another executable (dibol) from dclQ > > and handle everything from there ... performance is terrific on alpha vms ...l > J > Why do you think that stuff like NSAPI, ISAPI/ASP, servlets/JSP, OSU MST > etc. has been invented ? > I > Because everybody knows that CGI with a heavy image activation per call  > is not efficient enough. > F > It works OK for low and medium volume. It does not work for high and > very high 
 > volumes. > C > That is why everybody in the web-server business tries to develope% > way to avoid that image-activation.s > ; > Even you beloved Purveyor supports ISAPI for that reason.e >  > Arne  C except you are forgetting this is vms, not unix ... it is a processeF based os, and spawning processes on vms on a well tuned system is like a hot knifee9 cutting butter ... found this on another vms web site ...t  F > VMS stands for Virtual Memory System. It is an operating system thatG > Digital Equipment Corporation developed after the RSX system that raneH > on the PDP series of computers (circa late 70's early 80's - hence VMSD > post-dates Unix -- more history here). VMS is process heavy ratherH > than process light so programs load quite slowly - once loaded howeverE > they make for reasonable real time perfomance despite the fact that E > VMS was never designed to be a real time OS. Indeed this ability tofE > "run real time" is why VMS is not merely a good daemon platform but 2 > the daemon platform - yup even better than Unix.  A and to speed up that loading, just use a little utility called "$, INSTALL"& on your web script execs and they fly!   ------------------------------    Date: 20 Jan 2002 17:54:28 -0800( From: bob@instantwhip.com (Bob Ceculski)1 Subject: Re: Purveyor is superior for VMS - proofA= Message-ID: <d7791aa1.0201201754.5e9c922f@posting.google.com>c  [ Arne Vajhj <arne.vajhoej@gtech.com> wrote in message news:<3C4B05E5.BA8F366A@gtech.com>...k > Bob Ceculski wrote:h_ > > Arne Vajhj <arne.vajhoej@gtech.com> wrote in message news:<3C49B575.37BA876B@gtech.com>... A > > > Any web-server that supports DCL can run scripts written inr- > > > any language (including java and Perl).j > > > B > > > But performance usually sucks with that approach. ActivatingA > > > the JVM or the Perl interpreter for each script call is nott' > > > a solution for high-volume stuff.t > > O > > wrong ... we tested cgi scripting performance from every angle and it worksaP > > best to pass the www symbols/logicals to another executable (dibol) from dclQ > > and handle everything from there ... performance is terrific on alpha vms ...c > J > Why do you think that stuff like NSAPI, ISAPI/ASP, servlets/JSP, OSU MST > etc. has been invented ? > I > Because everybody knows that CGI with a heavy image activation per calle > is not efficient enough. > F > It works OK for low and medium volume. It does not work for high and > very high 
 > volumes. > C > That is why everybody in the web-server business tries to develop % > way to avoid that image-activation.  > ; > Even you beloved Purveyor supports ISAPI for that reason.n >  > Arne  O secondly, we use a c dll routine that makes calls to dibol external subroutinesaN and system services, just like a single dibol cgi scripts does ... both run asO processes on vms, so how is the single c dll any faster than a single dibol cgin2 script?  again, remember this is vms, not unix ...   ------------------------------  % Date: Sun, 20 Jan 2002 22:00:03 +0100t2 From: martin@radiogaga.harz.de (Martin Vorlaender)1 Subject: Re: Purveyor is superior for VMS - proof ; Message-ID: <3c4b2fd3.524144494f47414741@radiogaga.harz.de>c  > Arne =?iso-8859-1?Q?Vajh=F8j?= (arne.vajhoej@gtech.com) wrote:; > Even you beloved Purveyor supports ISAPI for that reason.y  ? Process Software does not only support ISAPI, they developed it  (together with Microsoft).   cu,)   Martin -- nB                         | Martin Vorlaender | VMS & WNT programmer1  OpenVMS: Where do you  | work: mv@pdv-systeme.deeD  want to BE today?      |   http://www.pdv-systeme.de/users/martinv/8                         | home: martin@radiogaga.harz.de   ------------------------------  % Date: Sun, 20 Jan 2002 23:54:09 -0500 % From: JF Mezei <jfmezei@videotron.ca>71 Subject: Re: Purveyor is superior for VMS - proof , Message-ID: <3C4B9EEA.6CD88674@videotron.ca>   Bob Ceculski wrote:pQ > secondly, we use a c dll routine that makes calls to dibol external subroutines A > and system services, just like a single dibol cgi scripts does 0  F I didn't know that dibol was available to run on windows as dll files.  M if your cgi runs as a shared image that is linked to the web server (eg: runsiN in the process of the web server), then having multiple languages would have aI performance impact because each language also comes with its own run timetL shareable image, hence greater virtual memory space being used and increased chances of paging.  L If your application uses the same language as the web server, then you share@ the run time library that is already loaded with the web server.    V Calling a shareable image a "dll" is like an IBM employee calling a disk drive "DASD".   ------------------------------  % Date: Sun, 20 Jan 2002 04:50:56 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t Subject: Re: triple boot1 Message-ID: <XWG28.228$PZ4.4312@news.cpqcorp.net>o    Also remember to do a SET OS VMS or UNIXt  + The console naming of devices is different.    ------------------------------  # Date: Sun, 20 Jan 2002 20:08:46 GMTc1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: TYPE suggestion' Message-ID: <3C4B24D2.D0DCFFE3@fsi.net>t   Guy Peleg wrote: >  > I really like this idea.K > Since OpenVMS V7.3-1 release is closed, I will do my best to have this ins( > OpenVMS V7.3-2 or maybe in future ECO.  D How 'bout an ECO then, and backport it all the way to V6.2 Alpha and V5.5-2 VAX?    -- a David J. Dachtera  dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sun, 20 Jan 2002 05:05:03 -0500r5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>i Subject: Re: TYPE suggestion1 Message-ID: <c8H28.230$PZ4.4404@news.cpqcorp.net>-  I $ SET TERM/NOWRAP will eliminate the wrapping of lines, and will truncateh them.     < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3C4B24D2.D0DCFFE3@fsi.net...0 > Guy Peleg wrote: > >  > > I really like this idea.J > > Since OpenVMS V7.3-1 release is closed, I will do my best to have this in* > > OpenVMS V7.3-2 or maybe in future ECO. > F > How 'bout an ECO then, and backport it all the way to V6.2 Alpha and
 > V5.5-2 VAX?t >d > -- > David J. Dachteras > dba DJE Systems- > http://www.djesys.com/ >a* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/.   ------------------------------  # Date: Mon, 21 Jan 2002 03:25:26 GMT31 From: "David J. Dachtera" <djesys.nospam@fsi.net>. Subject: Re: TYPE suggestion' Message-ID: <3C4B8B2A.F7090998@fsi.net>    Fred Kleinsorge wrote: > K > $ SET TERM/NOWRAP will eliminate the wrapping of lines, and will truncatev > them.i  F Oh, yeah, fer sure - but he wants to be able to display only a certain/ range of bytes in each record. As he put it, "$k* TYPE/WINDOW=(start_col,end_col) filespec".  H Not to be confused with the /WINDOW qualifier of the SEARCH command. Has a somewhat different meaning.   G Actually, now that I think about it, you can (sort of) do what he wants  with SEARCH/PAGE for "":   $ SEARCH filespec ""/PAGEi  H ...and scroll "sideways" with the left/right arrow keys. Not real usefulG for capturing a subset of the output, of course, which may be more whate he had in mind.h   -- b David J. Dachtera- dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/:   ------------------------------  % Date: Sun, 20 Jan 2002 19:45:11 -08001% From: Dean Woodward <deanw@rdrop.com>o Subject: Re: TYPE suggestion) Message-ID: <3C4B8EC7.C66D730A@rdrop.com>o   "David J. Dachtera" wrote: >  > Fred Kleinsorge wrote: > >#M > > $ SET TERM/NOWRAP will eliminate the wrapping of lines, and will truncate 	 > > them./ > H > Oh, yeah, fer sure - but he wants to be able to display only a certain1 > range of bytes in each record. As he put it, "$l, > TYPE/WINDOW=(start_col,end_col) filespec". > J > Not to be confused with the /WINDOW qualifier of the SEARCH command. Has > a somewhat different meaning./ > I > Actually, now that I think about it, you can (sort of) do what he wantsq > with SEARCH/PAGE for "": >  > $ SEARCH filespec ""/PAGE  > J > ...and scroll "sideways" with the left/right arrow keys. Not real usefulI > for capturing a subset of the output, of course, which may be more what, > he had in mind.S  H Am I missing something, or is this a no-brainer with a few lines of DCL?   $ OPEN /READ InFile 'P1' $ Loop: ( $ READ InFile DataLine /END_OF_FILE=Done< $ OutLine = F$EXTRACT( 'P2', ( 'P3' - 'P2' + 1 ), DataLine ) $ WRITE SYS$OUTPUT 'OutLine' $ GOTO Looph $ Done:e $ CLOSE InFile   ------------------------------  # Date: Mon, 21 Jan 2002 04:31:22 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>a Subject: Re: TYPE suggestion' Message-ID: <3C4B9A9E.9FE6003B@fsi.net>e   Dean Woodward wrote: >  > "David J. Dachtera" wrote: > >  > > Fred Kleinsorge wrote: > > >IO > > > $ SET TERM/NOWRAP will eliminate the wrapping of lines, and will truncate  > > > them.t > > J > > Oh, yeah, fer sure - but he wants to be able to display only a certain3 > > range of bytes in each record. As he put it, "$i. > > TYPE/WINDOW=(start_col,end_col) filespec". > > L > > Not to be confused with the /WINDOW qualifier of the SEARCH command. Has! > > a somewhat different meaning.  > >sK > > Actually, now that I think about it, you can (sort of) do what he wants8 > > with SEARCH/PAGE for "": > >C > > $ SEARCH filespec ""/PAGEe > > L > > ...and scroll "sideways" with the left/right arrow keys. Not real usefulK > > for capturing a subset of the output, of course, which may be more whatm > > he had in mind.0 > J > Am I missing something, or is this a no-brainer with a few lines of DCL? >  > $ OPEN /READ InFile 'P1'	 > $ Loop: * > $ READ InFile DataLine /END_OF_FILE=Done> > $ OutLine = F$EXTRACT( 'P2', ( 'P3' - 'P2' + 1 ), DataLine ) > $ WRITE SYS$OUTPUT 'OutLine'
 > $ GOTO Loop 	 > $ Done:a > $ CLOSE InFile  : Fine - so long as "DATALINE" never exceeds 510 characters.  E I think he may have been looking for something "standard" (comes withoB future versions of VMS, not "home brew") and documented/supported.   -- s David J. Dachtera  dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/c   ------------------------------  # Date: Mon, 21 Jan 2002 04:48:02 GMTs- From: "John E. Malmberg" <wb8tyw@qsl.network>  Subject: Re: TYPE suggestion* Message-ID: <3C4BA1E6.6090205@qsl.network>   David J. Dachtera wrote:   > Fred Kleinsorge wrote:  pH > Oh, yeah, fer sure - but he wants to be able to display only a certain1 > range of bytes in each record. As he put it, "$d, > TYPE/WINDOW=(start_col,end_col) filespec". > J > Not to be confused with the /WINDOW qualifier of the SEARCH command. Has > a somewhat different meaning.     ! So a better syntax would be like:t  * $TYPE/SELECT=(POSITION=10,SIZE=40) foo.txt       or  + $TYPE/EXTRACT=(POSITION=10,SIZE=40) foo.txti  7 To be more consistent with existing commands like SORT?e   -Johny wb8tyw@qsl.network Personal Opinion Onlyo   ------------------------------  % Date: Sun, 20 Jan 2002 21:05:43 -0800 % From: Dean Woodward <deanw@rdrop.com>  Subject: Re: TYPE suggestion) Message-ID: <3C4BA1A7.3AC46975@rdrop.com>m   "David J. Dachtera" wrote: > Dean Woodward wrote: > > "David J. Dachtera" wrote:L > > > Oh, yeah, fer sure - but he wants to be able to display only a certain5 > > > range of bytes in each record. As he put it, "$e0 > > > TYPE/WINDOW=(start_col,end_col) filespec". > > >.L > > Am I missing something, or is this a no-brainer with a few lines of DCL?
 [DCL snipped]g > >V< > Fine - so long as "DATALINE" never exceeds 510 characters.  D When I've got a display that'll display 510 lines w/o wrapping, I'll3 think about writing something that'll deal with it.y  G > I think he may have been looking for something "standard" (comes withtD > future versions of VMS, not "home brew") and documented/supported.  G Not to bring up the thread that should not be named, but what's the usebH of a decent scripting language if people won't use it?  In this case, ifD he needs chars 200-600 out of a file, he's probably doing some other processing anyway...  E There are features that it would be nice to have included in some DCL F commands, and there are features that someone should be able to cobble3 up themselves.  This is probably one of the latter.    ------------------------------  % Date: Mon, 21 Jan 2002 00:59:41 -0500o% From: JF Mezei <jfmezei@videotron.ca>t Subject: Re: TYPE suggestion, Message-ID: <3C4BAE40.9EDA404C@videotron.ca>   Dean Woodward wrote:I > Not to bring up the thread that should not be named, but what's the useeJ > of a decent scripting language if people won't use it?  In this case, ifF > he needs chars 200-600 out of a file, he's probably doing some other > processing anyway...  M No. i just want a quick look at certain log files in an easy to read format.  J Or type data files to see parts of it (for instance to ensure that a fieldP somewhere in the middle or towards the end if properly filled by the application   ------------------------------  % Date: Sun, 20 Jan 2002 15:51:28 -0500g+ From: "Main, Kerry" <Kerry.Main@compaq.com> # Subject: RE: Veritas Client for VMSrT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1BAE@kaoexc01.americas.cpqcorp.net>   Andrew,g  H Fwiw - Veritas does support OpenVMS as a client. Their official platform support page is at:tH http://support.veritas.com/dsl/lists/nbu_os_ddProduct_NETBACKUPDC_prod1_ NBUDC34.htmt   (one long url will likely wrap)s  A From above, the web site stats VMS V7.2-1 is the highest officialbE supported version, but from an offline message, they did not perceivehG any issues with VMS V7.3. Apparently, OpenVMS V7.3 is in the process of. being certified as well.  C They apparently had a number of issues with earlier versions of the F OpenVMS client, but according to them, more recent versions have fixed= all of them. Course, the standard "test yourself" applies.=20   H As others have stated, what many folks tend to do for the system disk isH a regular online image backup to a saveset on a different drive (often aF local drive, but could be on SAN as well). That saveset is then backed by by the Veritas client.t  E If they ever did lost the system disk, they could boot the OpenVMS OSwB Distribution CDrom and do a restore from that original system disk" saveset that is on the other disk.   Regards,  
 Kerry Main Senior Consultanty Compaq Canada Corp.o Professional Servicesp Voice: 613-592-4660r Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----( From: Nobody [mailto:nowhere@nobody.com] Sent: January 19, 2002 2:32 PM To: Info-VAX@Mvb.Saic.Coml Subject: Veritas Client for VMS      Hi everyone,  H I am tasked with testing the Veritas Client for VMS and I was wondering:  + - Has anyone had success implementing this?i) - What kind of gotchas have you run into? G - Have you had problems restoring data during a data recovery exercise?oF - Have you tried using the freeware VMS TAR to recover data from tape?  6 Any input you might have would be greatly appreciated.  3 Please direct any feedback to arobert@townisp.com .e   Thanks, 
 Andrew Robert3 Principal Systems Analyst ( Enterprise Technology Services - OpenVMS  Massachusetts Financial Services Phone: (617) 954-5882a Fax:     (617) 954-7999    ------------------------------  % Date: Sun, 20 Jan 2002 15:35:25 -0500 ' From: John Sauter <J_Sauter@Empire.Net>a@ Subject: Re: VMS missing features (was how to do deamons on VMS)* Message-ID: <3C4B2A0D.FD103970@Empire.Net>  ! Paul Repacholi wrote (excerpted):e  ; Am I right that there was only one Full Moby (256K) PDP-6? l One of the Stanford ones?e   John Sauter responded:  9 As far as I know, Stanford had only one PDP-6, and it wasi5 among the last ones manufactured.  Before the arrivalM2 of SAIL's KA10 I believe it had only 64 K words.  5 After the KA10 was installed we ran a two-CPU system l1 (KA10 and 166, with the 166 operating as a slave)o1 and I think the memory was increased after that, a3 but a system that includes a KA10 is not, strictly b speaking, a PDP-6 any more.s%     John Sauter (J_Sauter@Empire.Net)    ------------------------------  # Date: Sun, 20 Jan 2002 20:06:27 GMTa1 From: "David J. Dachtera" <djesys.nospam@fsi.net> H Subject: Re: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D' Message-ID: <3C4B2447.71C2206C@fsi.net>    Guy Peleg wrote: >  > Carl,f > J > This problem was solved by VMS Engineering. Please contact your favorite  > support center to get the fix.  4 Will "the fix" appear in the public patch tree soon?   -- t David J. DachteraP dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sun, 20 Jan 2002 15:39:39 -0500d+ From: "Main, Kerry" <Kerry.Main@compaq.com>iH Subject: RE: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0DT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CE86F@kaoexc01.americas.cpqcorp.net>   JF -  * >>> Does consoleworks run on windows ? <<<  @ ConsoleWorks server can be OpenVMS (VAX aor Alpha), UNIX (Tru64,) Solaris, AIX, Linux) or Windows based.=20   = The fact that these folks offer this selection is a big plus.a   You pick.=20  E Note - This might be a good use for a VAX that might be still kickingr around.s   Check out their FAQ:7 http://www.tditx.com/services_support_faqs.html#consolee  A Also - their product started on OpenVMS as well. They are also an<D excellent OpenVMS partner ie. attend all the trade shows, Ambassador meetings etc.=20  + They also have online demo's if interested.8   :-)c  
 Kerry Main Senior Consultantt Compaq Canada Corp.r Professional Services  Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----, From: JF Mezei [mailto:jfmezei@videotron.ca] Sent: January 20, 2002 10:58 AM  To: Info-VAX@Mvb.Saic.ComhH Subject: Re: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D     "Main, Kerry" wrote: >=20 > John,t >=20F > >>> I had also installed a bunch of ECO's at once, but the system isG > about 100 miles from me and I had to talk an operator through doing a  > minimal reboot, ..>> >=20G > Sounds like a secure remote console capability requirement brewing ..n >=20 > Reference:1 > http://www.tditx.com/products_consoleworks.htmli    " Does consoleworks run on windows ?  E If so, wouldn't that be a problem in certain coorporations to allow ai windows F box to be attached to a dial-up modem at one end and a serious machine at the other ?e   ------------------------------  % Date: Sun, 20 Jan 2002 20:21:01 -0500e  From: John Santos <JOHN@egh.com>H Subject: RE: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D6 Message-ID: <1020120201858.19335A-100000@Ives.egh.com>  ' On Sun, 20 Jan 2002, Main, Kerry wrote:u   > John,s > F > >>> I had also installed a bunch of ECO's at once, but the system isG > about 100 miles from me and I had to talk an operator through doing a- > minimal reboot, ..>> > G > Sounds like a secure remote console capability requirement brewing ..e >  > Reference:1 > http://www.tditx.com/products_consoleworks.html3 > F > This would allow you to be at the console ">>>" prompt from home. InJ > addition, a full log of all those patches and any errors would be in the) > ConsoleWorks log file for later review.d >  > :-)y > 
 > Regards, >  > Kerry Main  2 Thanks for the tip, Kerry...  I'll check this out.   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Mon, 21 Jan 2002 00:20:25 GMT 0 From: geoffm@spam.hormel.com ("Geoff McCaughan")K Subject: Re: Younger recruits versus experienced veterans ( was Re: The dem-1 Message-ID: <d9J28.902$Lv.126886@news.xtra.co.nz>m  * Charles Richmond (richmond@ev1.net) wrote:  > > Like my old Daddy used to say:  "You'd complain if they hung  > you with a new rope!!!"  (;-))  B Hereabouts it was always: "You'd complain if your arse was on fire" and I pissed on it to put it out!"   ------------------------------  # Date: Mon, 21 Jan 2002 00:19:40 GMT * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: [Q] Why is there the limit of 8 levels of directoriesA Message-ID: <w8J28.23816$TC1.1952039@bin5.nnrp.aus1.giganews.com>   7 "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in messageb# news:3C4B0023.9F63627F@gtech.com...i > Bill Todd wrote:; > > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in messagea# news:3C49D924.BF0483F5@gtech.com...f > > > Bill Todd wrote:E > > > > > A good guess would be that each level adds a small overheadyH > > > > > to accessing a file. It is nothing on an EV6 Alpha. But it mayL > > > > > actually have been noticable on VAX 7xx's. I think VMS engineering7 > > > > > tried to protect people from bad performance.0 > > > > J > > > > It's almost exactly the same performance hit on an EV6 Alpha as it was on aF > > > > uVAX I, since virtually all the perceivable overhead is in the
 additionalF > > > > disk accesses (well, disks have gotten faster too, but nowhere	 nearly as- > > > > much so).a > > >2@ > > > 1)  Disks has become a lot faster from VAX 7xx's to EV6's.D > > >     Maybe "just" a factor 20-100, but that may be noticeable ! > >uK > > IIRC hard disk seek times (the dominating factor in perceived deep-patheL > > look-up performance) have improved by about a factor of 10 over the past two 6 > > decades (and I did mention such improvement above, >tC > 1)  Disk seek time would have been the only relevant factor for ayF >     PC running MS-DOS. On a multi-user OS the relevant factor is theE >     time the average IO takes to complete (in which seek time is an . >     important factor, but not the only one).  K Arne, you're as stubborn as I am and I'm not going to continue wasting time L arguing something this silly.  I will suggest that since I was around DEC atE the time and have at least *some* recollection of the reasons for theJH 8-level directory limit you either take my word for it or come up with a> counter-assertion from someone else who was there at the time.   - bill   ------------------------------    Date: 21 Jan 2002 07:01:36 +0800, From: Paul Repacholi <prep@prep.synonet.com>B Subject: Re: [Q] Why is there the limit of 8 levels of directories- Message-ID: <87zo38wrsf.fsf@prep.synonet.com>   / "John E. Malmberg" <wb8tyw@qsl.network> writes:y  ; > I am not aware of the specific reasoning behind the older/ > limitations.  B If you have an entry that points to a directory below, you have anE infinite loop of directories. Ugly experience with some unixs (systemjE crashing on an ls :( ) meant that it was considered a thing to avoid!r   -- n< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.e@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 21 Jan 2002 07:07:41 +0800, From: Paul Repacholi <prep@prep.synonet.com>B Subject: Re: [Q] Why is there the limit of 8 levels of directories- Message-ID: <87vgdwwria.fsf@prep.synonet.com>y  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:   ; > >if you have both [.FABIOCARTOONS] and [.FABIOCARTRIDGES]d > >i$ > >which one will it set default to? > K > If you set the default string with a wildcard, you might find the results K > rather amusing.  Of course, you'll have to write your own program to pokeu4 > PIO$GT_DDSTRING with the wildcard default context.  / Just what you got with TOPS-10 for some things;s> "Ambiguous File Spec" So if you typed 'Fondle *' then it couldB only be an error if there was more than one file of the fondleableG extention, and fondle would only take one file. This enabled you to useh. a wildcard * as a short cut and memory crutch.   -- n< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Mon, 21 Jan 2002 06:42:27 GMTd* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: [Q] Why is there the limit of 8 levels of directoriesB Message-ID: <nLO28.596817$C8.42666856@bin4.nnrp.aus1.giganews.com>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in message ' news:87zo38wrsf.fsf@prep.synonet.com...D1 > "John E. Malmberg" <wb8tyw@qsl.network> writes:X >C= > > I am not aware of the specific reasoning behind the olderu > > limitations. > 8 > If you have an entry that points to a directory below,   Rather, above.    you have anG > infinite loop of directories. Ugly experience with some unixs (systemTG > crashing on an ls :( ) meant that it was considered a thing to avoid!   H This is indeed a good reason to have a recursion limit (unless there areF enforceable restrictions on creating such loops - e.g., I believe NT'sJ kernel performs a synchronized check before allowing directory creation orJ rename), but does not explain why a limit as low as 8 would be set (though> to be fair 8 actually seemed like a *lot* two decades ago...).   - bill   ------------------------------   End of INFO-VAX 2002.039 ************************