1 INFO-VAX	Tue, 24 Jul 2001	Volume 2001 : Issue 407       Contents:0 Re: Adding an Alpha processor - any VMS changes?( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate1 Re: Alpha:  ostriches and sheep (financials part) 1 Re: Alpha:  ostriches and sheep (financials part) 1 Re: Alpha:  ostriches and sheep (financials part) 7 Re: AlphaServer GS Series (was Re: IA64 Rocks My World) 1 Re: Another reason to READ THOSE RELEASE NOTES... 1 Re: Another reason to READ THOSE RELEASE NOTES...  Re: Basic VMS Question* Re: Best file spec for incremental backup?* Re: Best file spec for incremental backup?$ Re: Can a "White Alpha" box run VMS?$ RE: Can a "White Alpha" box run VMS?$ Re: Can a "White Alpha" box run VMS?& Re: Compaq FUD and lack of information& Re: Compaq FUD and lack of information& Re: Compaq FUD and lack of information& Re: Compaq FUD and lack of informationF Re: DEC 2000 and OpenVMS Support (was: Re: Upgrade PAGEFILE.SYS error)& DFWCUG Announcement regarding DEFCON 9) Re: Does my file has an extension header? , DS20e's 667Mhz in Stock - Waiting for a home  Re: Full port of VMS to Itanium.? Re: IA-64 has Little-Endian (was: Re: No chance for OpenVMS...)  Re: IA64 Rocks My World  Re: IA64 Rocks My World : Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)L Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker festL Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker fest Re: Just one possible future!!I LG06 Line Printer; Manual?; Vibrates with SHTL error when printing starts " Re: LPs on the Web (Was: Re: DCPS) Re: No chance for OpenVMS  Re: No chance for OpenVMS  Re: No chance for OpenVMS ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? RE: Now we're cooking with gas. (was:  Wailing and moaning....)  Re: OT: Dr Who.  Re: OT: Dr Who.  Re: OT: Dr Who.  Re: Process adopts Itanium5 RE: SMS on VMS [was RE: Full port of VMS to Itanium.]  SMTP and distribution lists  Re: SMTP and distribution lists $ Re: Terry Shannon Tech Talk on IA-641 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated P Re: Triggering tasks from network file arrival - Was Re: Basic VMS Questio Quest Re: Upgrade PAGEFILE.SYS error7 Will a DEC Alpha XL300 300 MHz Workstation run OpenVMS? ; Re: Will a DEC Alpha XL300 300 MHz Workstation run OpenVMS?  Re: Your reply on GSDFULL  Re: Your reply on GSDFULL  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll 5 RE: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ? 5 RE: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ? ' Re: [TCPIP V5.1] Still no TFTP client ?   F ----------------------------------------------------------------------  # Date: Mon, 23 Jul 2001 19:10:06 GMT   From: jlsue <jlsuexxxz@home.com>9 Subject: Re: Adding an Alpha processor - any VMS changes? 8 Message-ID: <vdloltgo2hrkna0gd05tmeumnhog2ionfh@4ax.com>  ' Hans... that was my point to Mr. Greig. 4 But it was just a little (very little) bit if humor.  @ On Fri, 20 Jul 2001 22:22:24 +0200, "Hans Vlems" <hvlems@iae.nl> wrote:  D >Nope, for 4.6 you needed a special kit to turn multi-processing on.? >At least that's what I remember from 4.6 and 4.7 on a VAX8350. B >In fact the second cpu was turned on only since we installed V5.0 >  >Hans  > , >jlsue <jlsuexxxz@home.com> wrote in message3 >news:r7nglts4qr3cpb9v5a5fqu1aqsdp7sb521@4ax.com... # >> Um... even if it's MicroVMS 4.6?  >> ;-)F >> On Fri, 13 Jul 2001 16:22:44 +0100, Alan Greig <a.greig@virgin.net>	 >> wrote:  >>G >> >On Fri, 13 Jul 2001 09:49:48 -0400, "Tom Steuver" <steuver@nku.edu> 
 >> >wrote: >> >K >> >>If I have the license, is that all I need?  Will OpenVMS automatically  >seeG >> >>the new processor and adjust accordingly?  The reason why I ask is  >becauseM >> >>on other platforms (NT and Linux), the kernel needs to be recompiled for  >theG >> >>other processor.  Do I need to do something like this for OpenVMS?  >> > >> >Hey, this is VMS :-) >> >F >> >With VMS you can take a system image from any old single processorF >> >Alphastation and boot  a 32 processor GS320 with it. A MicroVAX IIA >> >image can boot a VAX 9000. Great for simple single boot image % >> >clustering and Disaster Recovery.  >> >    ------------------------------  # Date: Mon, 23 Jul 2001 19:10:07 GMT   From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Alpha:  an invitation to communicate 8 Message-ID: <nfnoltsjmokguv29sb305742g1k2d3ddc6@4ax.com>  E On Fri, 20 Jul 2001 06:34:09 -0400, "Bill Todd" <billtodd@foo.mv.com>  wrote:     > H >3.  Compaq demonstrated absolutely no indication that it feels that itsE >'commitments' to customers are in the least way binding.  Instead of J >consulting with its customers about changing them, it did so unilaterallyI >(and hardly for the first time).  And instead of offering even a hint of G >apology for this, it attempted to bullshit them into accepting it as a  >positive step.   E Exactly what committments are you talking about?  Certainly you don't E mean the Alpha Roadmap?  Roadmaps certainly aren't to be construed as F something to be  followed come-hell-or-highwater.  If business climateC changes enough, then the company must do something else in order to  survive.  E Look, at first I was shocked and disturbed by the turn of events with E Alpha.  It was a continued source of pride to work for a company with F such good engineers as those around the Alpha architecture, compilers,4 and OpenVMS (and, of course, Tru64 and NSK as well).  D But in no way did I ever see any committment to any long-term futureF for Alpha.  And, in the real world, I don't expect that you'd ever seeD such a committment that you could really depend upon.  It just isn't* possible in the business world to do that.  C I have confidence that this decision was made for good reasons, and @ that it can and will work out to our benefit.  For the (Open)VMSE operating system, it can lead to a much larger market and improve its E chances for survival.  Will it?  Heck, I don't know for sure if it'll % happen, but neither does anyone else.    ------------------------------  % Date: Mon, 23 Jul 2001 15:14:54 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B5C77A6.629A17BF@videotron.ca>   Hamlyn Mootoo wrote: > F > Have you ever considered running for public office?  I don't believeG > I have EVER encountered that many disclaimers in one piece of writing I > with the possible exception of the use of Olestra by Frito-Lay on a bag < > of their fat-free potato chips ("may cause anal leakage").  J For as much as I dislike and distrust Compaq, I respect that employees whoL post here do so on their own behalf and as such must protect themselves fromG their employer. It is to be expected to see disclaimers, and I actually A appreciate very much when an employee admits he doesn't know yet.   K As a matter of fact, admitting lack of knowledge in one area often provides 9 more information about what is really going on at Compaq.    ------------------------------  % Date: Mon, 23 Jul 2001 14:55:58 -0500 ' From: Greg Pfister <pfister@us.ibm.com> 1 Subject: Re: Alpha:  an invitation to communicate * Message-ID: <3B5C814E.D40751F8@us.ibm.com>   JF Mezei wrote:  >  > Peter Hancock wrote:G > > I though VM was the underlying thing, and MVS was one of the things  > > VM could host? > O > This was the "old way".  But MVS-only shops can run multiple instances of MVS M > on a 390 or higher without the presence of VM. This saves a lot of overhead $ > since IO is not intercepted by VM.  @ What you're talking about is LPAR - Logical PARtitioning. It's a? closer-to-the-hardware way of splitting of a given machine into @ smaller ones. Two levels of sort-of-virtualization: LPAR, inside; of which you can run MVS or VM or (others less known). Then A inside that VM system you can run many more multiple systems than A LPAR can do: thousands, vs. a max of 256 (I think that's the LPAR  limit, anyway).   N > I did hear that VMS was making a comeback to run multiple instances of Linux > on IBM mainframes though.   > I think you meant VM, right? In that case, sort of. VM is much? more talked about in these latter days of hosting 100s of Linux ; machines on a single LPAR, but it never did fade away. It's > always been used, at least to debug new releases of MVS if not for other reasons.   Greg Pfister   ------------------------------  # Date: Mon, 23 Jul 2001 21:05:45 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com> 1 Subject: Re: Alpha:  an invitation to communicate * Message-ID: <wkd76rjr6g.fsf@earthlink.net>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:    > O > This was the "old way".  But MVS-only shops can run multiple instances of MVS M > on a 390 or higher without the presence of VM. This saves a lot of overhead $ > since IO is not intercepted by VM. > N > I did hear that VMS was making a comeback to run multiple instances of Linux > on IBM mainframes though.   F i think that if you look closely ... LPARS are essentially a whole lot= of VM moved into the "microcode" of the hardware with various A options/features simplified. it basically started out as hardware B accelerater for VM kernel (by incorporting significant performanceF parts of vm kernel into the microcode of the hardware) ... and at some> point enuf of the VM kernel functions had been migrated to theC hardware of the machine that it was possible to provide a subset of B the VM kernel functions w/o even running the full-blown vm kernel.  @ if you look at the LPAR documentation with regard to performanceD planning, there is still some amount of "vm" overhead still involvedA (it just that it is somewhat less because it is being done in the A hardware w/o ..at least.. the overhead of a context switch into a / different address space & software processing).   B a subset of the VM commands is still seen on the console for doingE LPAR configurations. Also, the hardware console/service processor may < or may not still be a VM system (aka all 3090s contained twoD "embedded" 4361s running a modified version of vm/370 release 6 that; were the service processor and hardware console interface).    random refs:2 http://www.garlic.com/~lynn/subtopic.html#360mcode   --  E Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/    ------------------------------  % Date: Mon, 23 Jul 2001 20:54:28 -0400 ( From: Bill Gunshannon <bill@cs.uofs.edu>1 Subject: Re: Alpha:  an invitation to communicate K Message-ID: <Pine.LNX.4.10.10107232048510.2646-100000@triangle.cs.uofs.edu>   ! On Mon, 23 Jul 2001, jlsue wrote:    > G > Exactly what committments are you talking about?  Certainly you don't G > mean the Alpha Roadmap?  Roadmaps certainly aren't to be construed as H > something to be  followed come-hell-or-highwater.  If business climateE > changes enough, then the company must do something else in order to 
 > survive. >  <snip> > F > But in no way did I ever see any committment to any long-term futureH > for Alpha.  And, in the real world, I don't expect that you'd ever seeF > such a committment that you could really depend upon.  It just isn't, > possible in the business world to do that.  > And yet, when people here apply the same logic to VMS they get% accused of spreading FUD.  Go figure.    bill    --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Tue, 24 Jul 2001 03:02:27 GMT . From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Alpha:  an invitation to communicate E Message-ID: <7z577.11383$Xn.1355405@newsread1.prod.itd.earthlink.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B55AF03.2813A8F3@videotron.ca...G > UNLESS, Compaq is convinced that VMS is a short/medium term source of  profitH > and that eventually everyone will be running NT, in which case, Compaq would G > not want to place all its eggs in the VMS basket since eventually VMS  would beL > replaced by NT. In that case, Compaq will do what it takes to maintain VMSJ > profits but won't want to grow nor focus its business on that product if it2 > doesn't think VMS has a bright long term future. > I > So far, I have not seen anything which makes me beleive that Compaq has  long* > term intentions to develop VMS's market. > ? Five years ago the expectation was that VMS sales would decline I significantly in the face of "superior" unix and windows technology; that D the only unique VMS feature, clusters, would be standard on unix and, windows, leaving no reason to stay with VMS.  F The sales, while declining, with marketing being set on the basis of aG decline, have far exceeded expectations.  Hey, they were supposed to be  virtually zero by now.  F The COE-DII efforts were under taken on the basis of development for aA decade (several years are past) and then 15 years of maintenance.   J It is likely that VMS will continue to exceed expectations and continue toH be neglected.  Everyone knows that you can't sell a new operating systemJ into a mature market.  Well, everyone knows that only Microsoft can sell aJ new operating system into a mature market.  Well, everyone knows that onlyE when a new technology comes along and Microsoft is sleeping can a new I operating system be introduced, but Microsoft will eventually win.  Well, F everyone knows that the only way that an operating system can gain anyB market share is by being free, but it will never have an impact onF Microsoft.  Everyone knows that VMS would never have a chance, becauseL everyone who is in position to give it a chance knows that they can't figure3 out how to invest more money without taking a risk.    ------------------------------  # Date: Tue, 24 Jul 2001 03:17:17 GMT . From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Alpha:  an invitation to communicate E Message-ID: <1N577.9326$Px1.1067430@newsread2.prod.itd.earthlink.net>   6 "Dennis O'Connor" <dmoc@primenet.com> wrote in message' news:9j6sbv$4no$1@nnrp2.phx.gblx.net... C > My commentary below will serve as a primer on how to read through B > typical USENET BS.  In summary, it shall be shown that Bill ToddD > took one current cost number, and a revenue and profit figure thatE > is over a year (and one dot.com bubble-burst) old (and therefor may L > be completely irrelevant to the current market conditions), and then spinsC > a bunch of self-serving assumptions and "imaginings" to create an E > argument to support his pre-conceived conclusion.  Really bad form.   > Don't try this at home, kids !  G This must be arguing that VMS sales were boosted by the dot.com market!   ) Man, everyone seemed to have missed that?   L Were we feed mis-information about all those web servers and contrary to theF noise they weren't running either iis/windows or apache/unix, but wereG instead running apache/vms - but wait, apache was only released for vms  within the past year or so.    ------------------------------  # Date: Tue, 24 Jul 2001 03:43:17 GMT . From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Alpha:  an invitation to communicate E Message-ID: <p9677.9349$Px1.1076047@newsread2.prod.itd.earthlink.net>   * "Magnus M" <mmad@tips.se> wrote in message- news:NIS57.749$Ta.1921@news3.global-ip.net... < > I personally think the "IPF-VMS" port is a good thing ,,,,I > represents a good opportunity for the folks in Nashua to do some needed:H > changes to the current exec, filesystem and concurrency areas, just as! > Wildfire was with its NUMAisms.i  H If changes are made to "fix problems" instead of get things running, theH project will fail.  Time to profit is critical and time to profit is notK just for VMS, but also for what remaining Compaq VMS software there is, butuL especially for ISVs and VARs.  Maybe current Alpha sales can be sustained atJ some level for a year or two, but after that, there needs to be signficantF milestones reached and clearly visible to customers.  VMS and a lot ofI software needs to be on the streets in two years, maybe not of productionlJ quality, but it needs to be available to developers and people who will be6 decided whether to stay with VMS or to move elsewhere.  I The port to Alpha was done with a lot of compromises with the expectationAE that there would be an opportunity to fix things later.  The level ofaI investment in the past 7 years has not allowed that to happen.  Still, if L VMS hadn't been delivered on Alpha until 1995 or 1996, we wouldn't be havingE this discussion at all since neither VMS nor Alpha would exist today.o   ------------------------------  # Date: Tue, 24 Jul 2001 03:48:24 GMT . From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Alpha:  an invitation to communicateeE Message-ID: <ce677.11466$Xn.1372621@newsread1.prod.itd.earthlink.net>   7 "Alexis Cousein" <al@brussels.sgi.com> wrote in messager) news:3B580E6A.8080700@brussels.sgi.com...  > JF Mezei wrote:  >V? > > I.E., the yields on IA64 would be much lower than on Alpha.o >pG > Given identical design styles (and tools used to layout transistors),oC > probably. But in this case, I'd say it's probably anyone's guess,g/ > as design methodologies are really different.e  2 All things being equal, die size determines yield.  F All indications are that Alpha has an advantage in a smaller die size.  K Don't know what steps Intel has been taking to improve effective yield, buteL Alpha was incorporating extra memory with options to configure out defective- memory as well as implementing ecc and so on.n  H If Intel didn't have similar capability, then that further biases things
 toward Alpha.g   ------------------------------  % Date: Mon, 23 Jul 2001 21:51:11 -0600i+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca>s1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B5CF0AF.F2475901@jetnet.ab.ca>   mulp wrote: M > Don't know what steps Intel has been taking to improve effective yield, but[N > Alpha was incorporating extra memory with options to configure out defective/ > memory as well as implementing ecc and so on.lL They could blame the crashes on use of Nameless brand name software and save $$$ on memory. ! Ben. -- e> "We do not inherit our time on this planet from our parents...!  We borrow it from our children."d< "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.   ------------------------------  # Date: Tue, 24 Jul 2001 03:59:22 GMTo. From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Alpha:  an invitation to communicate E Message-ID: <uo677.11480$Xn.1358127@newsread1.prod.itd.earthlink.net>   6 "Dennis O'Connor" <dmoc@primenet.com> wrote in message' news:9jbd1j$dqj$1@nnrp2.phx.gblx.net... 7 > "Brannon Batson" <Brannon_Batson@yahoo.com> wrote ...-I > >  It has been suggested that this deal was technically motivated.  I'mu. > > an Alpha architect, and I claim otherwise. >o@ > In all fairness, Brannon, it's entirely possible for competent; > senior engineers to have different opinions as to whethers4 > a product can be built within the usual real-world9 > constraints (staffing, delivery date, cost, etceteras). 0 > Until the product _has_ been built, of course. > 6 > Whether this was the case with Alpha, I do not know.  F Curious that you can flame someone who has been soliciting and gettingH information, who has been researching data and analyzing it, and who hasH some lengthy experience with DEC, Alpha, VMS, etc. for making judgementsJ about the Alpha decision, yet you admit that you don't know anything about+ the basis for the decision to cancel Alpha.    ------------------------------  % Date: Tue, 24 Jul 2001 01:20:46 -04002- From: JF Mezei <jfmezei.spamnot@videotron.ca>e1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B5D059E.4501E5DF@videotron.ca>   mulp wrote:tA > Five years ago the expectation was that VMS sales would decline K > significantly in the face of "superior" unix and windows technology; thatmF > the only unique VMS feature, clusters, would be standard on unix and. > windows, leaving no reason to stay with VMS.  G Be careful. That prediction may have failed 5 yeasr ago becauise it waseN premature. But today, that prediction *might* be correct because VMS's edge is; no longer as big compared to competitors, especially tru64.g  N Also, consider that in the case of clustering, the mainstream systems may haveH clustering features that, while inferio to VMS, would still be more than' adequate for the majority of customers.     H > The COE-DII efforts were under taken on the basis of development for aC > decade (several years are past) and then 15 years of maintenance.r  L And Alpha was to have an active lifetime of over 25 years. It will die afterF 15 years. Also, I am not sure if the DII-CEO stuff is targetted at allL customers or only a contractual obligation to only a few select customers inL the military who require this. Marcello gave the impression that DII-CEO was "for those who need it".  L > It is likely that VMS will continue to exceed expectations and continue toJ > be neglected.  Everyone knows that you can't sell a new operating system > into a mature market.   M When expectations are very low, it is very easy to exceed those expectations.rM When expectations are very high (NT) it is very easy to disapoint. But in the N end, while VMS may exceed and NT may not meet expectations, it is still likely- that NT will still advance far more than VMS.u   ------------------------------  % Date: Mon, 23 Jul 2001 22:23:27 -0700n+ From: "Dennis O'Connor" <dmoc@primenet.com>n1 Subject: Re: Alpha:  an invitation to communicate - Message-ID: <9jj0pp$q4k$1@nnrp2.phx.gblx.net>   2 "mulp" <michaelpettengill@earthlink.net> wrote ...4 > All things being equal, die size determines yield.   All things are never equal, and ( the world is not as simple as you think. --3 Dennis O'Connor                   dmoc@primenet.comw. Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------   Date: 23 Jul 01 12:19:02 MDT" From: ivie@cc.usu.edu (Roger Ivie): Subject: Re: Alpha:  ostriches and sheep (financials part)% Message-ID: <5owmu5jXxUSu@cc.usu.edu>   S In article <3B5C61EF.A0852006@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:0B > - In the Annual Report for 2000 (ie. December) Compaq says aboutG > Commercial Personal Computing, "Costs for processors, memory and hard.I > drives for desktops and portables declined during the year.", and aboutrA > Consumer PC's "Higher component costs also contributed to lowernE > operating income."  The contradiction is not impossible but it doesl > deserve an explanation.l  K Microsoft? Rumor has it the OS is now the most expensive component of a PC. L Since the OS is neither processor, memory, nor hard drive yet is a componentJ whose cost must be paid, increased OS costs could satisfy both statements. -- eN -------------------------+---------------------------------------------------- Roger Ivie               | n ivie@cc.usu.edu          | http://cc.usu.edu/~ivie/ |   ------------------------------  % Date: Mon, 23 Jul 2001 16:47:27 -0400a! From: pw@panix.com (Paul Wallich)a: Subject: Re: Alpha:  ostriches and sheep (financials part)/ Message-ID: <pw-2307011647420001@192.168.1.100>f  D In article <3B5C61EF.A0852006@dplanet.ch>, mcleanj@dplanet.ch wrote:  	 >Hi Bill,3 >8A >Interesting comments you made about Compaq financials.  They canrI >sometimes be a goldmine of information. You are quite right about the PCgD >market (personal and commercial) being a consistent money loser and >dragging Compaq down. >c >A couple of brief comments: >wF >- In a GOOD quarter PC's seem to return a profit about 1 or 2% of theH >money spent on them; in most quarters they lose money and have done forB >the last few years.  By contrast Dell are returning about 6-10%. : >Enterprise stuff from Compaq regularly returns about 14%. >iA >- In the Annual Report for 2000 (ie. December) Compaq says aboutoF >Commercial Personal Computing, "Costs for processors, memory and hardH >drives for desktops and portables declined during the year.", and about@ >Consumer PC's "Higher component costs also contributed to lowerD >operating income."  The contradiction is not impossible but it does >deserve an explanation. > C What this probably means (from someone who has had to decipher thissL stuff on and off for 20 years or so) is that the first "cost" is the amount F they spent overall, while the second is the cost per unit. Which wouldA imply that volume purchased (and shipped) declined substantially.-  H There seems to be a Gresham's law in the computer biz: when floundering,J cannibalize your profitable prospects to save the unprofitable ones (whichD of course makes sense, because no one would pay you to buy one large& money-losing commodity PC business...)   paul   ------------------------------  % Date: Mon, 23 Jul 2001 22:21:55 -0700h+ From: "Dennis O'Connor" <dmoc@primenet.com>o: Subject: Re: Alpha:  ostriches and sheep (financials part)- Message-ID: <9jj0ms$q4i$1@nnrp2.phx.gblx.net>n  ' "Paul Wallich" <pw@panix.com> wrote ...f* > "John McLean" <mcleanj@dplanet.ch> wroteC > >- In the Annual Report for 2000 (ie. December) Compaq says aboutiH > >Commercial Personal Computing, "Costs for processors, memory and hardJ > >drives for desktops and portables declined during the year.", and aboutB > >Consumer PC's "Higher component costs also contributed to lowerF > >operating income."  The contradiction is not impossible but it does > >deserve an explanation. > > E > What this probably means (from someone who has had to decipher this M > stuff on and off for 20 years or so) is that the first "cost" is the amount H > they spent overall, while the second is the cost per unit. Which wouldC > imply that volume purchased (and shipped) declined substantially.s  > Uh, no.  It means nothing of the sort, as anyone whose thought@ about what goes into a PC BOM (bill-of-materials) already knows.= Go wander around any computer retailer and look around first.e3 Then, and I'm not speaking for Intel BTW, consider:,  7 Sure, the components called out (processors, memory andi; hard drives) have declined in cost.  But quite a few things60 have not.  Let's think about it a bit, shall we:  @ Sheet metal : yeah, the basic case would probably cost the same,C since metal gauges haven't quite shrunk as fast as chip geometries. 8 Design considerations, however, have led to more stylish6 (and therefor more expensive) cases in the mainstream.  < Cooling solutions: hey, that processor sure is cheap, but at8 70W power dissipation, you need a bigger heatsink and/or a more powerful fan.  ; Power delivery: all that heat came from somewhere, and thatu9 somewhere is the case power supply and the on-motherboardh@ voltage regulators.  Plus there's all those nifty new sleep-mode< power requirements.  Probably a cost increase there as well.  > Additional I/O interfaces: USB and Firewire ports aren't free,? but you didn't used to need them, or at least, so many of them.i$ And unfortunately most of the market  8 More sophisticated I/O devices: DVD-ROM and CD-RW drives? are all over the place: both cost more than a CD-ROM drive. Buto> people want them; however, they won't pay much more  for them.  C Now come on: isn't it obvious that processor, memory and hard drived? aren't the only components in a PC ? Didn't that occur to you ?   D Feh: foolish naive amateurs, pretending to have clues they don't ...@ and these people have the gall to denigrate Compaq's decisions ?" They don't even know the _basics_. --3 Dennis O'Connor                   dmoc@primenet.com . Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------  # Date: Mon, 23 Jul 2001 19:24:38 GMTe2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)@ Subject: Re: AlphaServer GS Series (was Re: IA64 Rocks My World)3 Message-ID: <WR_67.1122$rc5.73646@news.cpqcorp.net>e  I   Since references here are to OpenVMS features, the follow-ups have been    set to comp.os.vms.3  o In article <4495ef1f.0107231020.478dfce9@posting.google.com>, Brannon_Batson@yahoo.com (Brannon Batson) writes: E :Wildfire is NOT a clustered system (at least not by my definition). qG :It is a single system running a single coherence protocol and a singlea! :OS with a single system image.  T  H   The AlphaServer GS series can be configured to operate as a cluster inI   a box, or as a single system image, or as combinations of clusters and      single-system images in a box.  % :It is a ccNUMA system, which by it'stD :very nature places some of the burden on the programmer to maximize :performance.  m  K   Most any current processor places similar constraints on the application iJ   code and particularly on the application programmer's tools.  Obviously.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 24 Jul 2001 07:43:35 +0930 / From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>a: Subject: Re: Another reason to READ THOSE RELEASE NOTES.../ Message-ID: <3B5CA18F.1BFF3546@wasd.vsm.com.au>   H Ghostview/GhostScript is an excellent solution.  The version on the V7.3D Freeware disks also allows the viewing of Adobe PDF documents, a big? plus (also with the number of PDF VMS documents on the doc CD).n  > I had difficulties with the [GHOSTSCRIPT.GS-6_01.LIB]FONTMAP.;3 configured in this distribution and had to copy thee7 [GHOSTSCRIPT.GS-6_01.LIB]FONTMAP.GS over the top of it.n  H You need to install the [GHOSTVIEW] and [GHOSTSCRIPT] kits.  Works well.   Peter LANGSTOEGER wrote: > i > In article <3b5c2c3c.323896812@news.ksc.nasa.gov>, stephend@pdms99.ksc.nasa.gov (Dave Stephens) writes: F > >Looks like I just upgraded myself out of viewing Polycenter graphs. >  > Not really...- > F > >This one slipped in under the radar. In my exuberance to test driveB > >the new VMS version, I installed it on my DEC 3000 workstation.I > >Oopsie! Now I can't view our CPU reports. A quick Google check of thisnI > >group shows me why - no more support for Display PostScript with Motif.D > >v1.2-6. And do I understand correctly that I can't revert back toD > >Motif v1.2-5 with VMS 7.3? Ouch! Anyone else out there viewing PS+ > >files via DECwindows Mail? I am annoyed.r > A > Install GHOSTSCRIPT and display postscript on every X11 displayoF > (like X-terminals, PC with X11-Software) and not only on x11 serversA > with DPS (like Q's workstations up to DECwindows-MOTIF V1.2-5).v > L > In other words, don't rant for DPS, rant for Q prepackaged GHOSTSCRIPT kit > on the VMS CD instead... >  > --> > Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651= > Network and OpenVMS system manager  Fax.    +43 1 81111-888e> > <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netJ > A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   -- i Illegitimis nil carborundum.   ------------------------------  # Date: Mon, 23 Jul 2001 23:06:03 GMT - From: goathunter@goatley.com (Hunter Goatley)-: Subject: Re: Another reason to READ THOSE RELEASE NOTES...1 Message-ID: <3b5cadba.177991788@news.process.com>c  M On Tue, 24 Jul 2001 07:43:35 +0930, Mark Daniel <Mark.Daniel@wasd.vsm.com.au>@ wrote:  I >Ghostview/GhostScript is an excellent solution.  The version on the V7.3sE >Freeware disks also allows the viewing of Adobe PDF documents, a bigP@ >plus (also with the number of PDF VMS documents on the doc CD). > H An even newer version (Ghostscript V7.0) can be found on Mark Berryman's) FTP server: MVB.SAIC.COM in [.PCSI-KITS].i   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/a9 goathunter@goatley.com     http://www.goatley.com/hunter/r   ------------------------------  % Date: Mon, 23 Jul 2001 07:48:16 -0400 " From: "Hal Kuff" <kuff@tessco.com> Subject: Re: Basic VMS Question O Message-ID: <8D878D0628C2AF22.EF93CBD799203689.38DE43866729058B@lp.airnews.net>o  4     There is a sleep statement available in DBL ....    7 "Andrew Robinson" <arobinson@hspg.com> wrote in messagefG news:CDA4BAD1E10ED41181AC00508B6051D3C3E2E7@grumpy.internal.hspg.com...o. > Please could anyone help with the following: >pG > I have a procedure running on one of my VMS boxes which is constantlylI > checking a directory for a file which can be FTPed into it. If the filexK > appears it then runs another routine to process and remove the file readylL > for the next one. I have a simple routine at the moment written in Diabold# > which runs as a detached process.aF > The problem I have is that to make this process work, it is a simple loopingV3 > check, which eats CPU and slaughters the disk IO.-E > Is there anything in VMS which you can utilize which you can use toh triggerg4 > an event if a file appears in a specific location.4 > I using an Alpha 1200 running OVMS 7.2-1 + patches >s > Thank you in advance >t > Andrew Robinsoni   ------------------------------    Date: 23 Jul 2001 15:05:30 -0700- From: afeldman@gfigroup.com (Alan E. Feldman).3 Subject: Re: Best file spec for incremental backup?p= Message-ID: <af1e4ce6.0107231405.6ce77f38@posting.google.com>y  m hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<qoX67.1099$rc5.72576@news.cpqcorp.net>...ee > In article <793af3df.0107200921.72861d7f@posting.google.com>, tadamsmar@aol.com (Tom Adams) writes:h< > :We had been using [*...] as the file spec for incremental0 > :backups that might be used to recover a disk. > :y' > :Is [000000...] a better choice? Why?  > L > http://www.openvms.compaq.com/doc/73final/6017/6017pro_044.html#6017backupN > http://www.openvms.compaq.com/doc/73final/6017/6017pro_048.html#inc_disk_sec >   F In the manual referenced above, for an incremental restore, it says to
 start with  D BACKUP/IMAGE device:save-set-specifier[/SAVE_SET] output-specifier    ? followed by appropriate BACKUP/INCREMENTAL commands. However, I1? noticed that the image backup command above doesn't contain the F /RECORD qualifier. Is that an omission in the manual or is /RECORD nowF the default for BACKUP/IMAGE for recent-enough versions of VMS BACKUP?C IOW, shouldn't the /RECORD qualifier be added to the above command?f TIA.   Disclaimer: JMHO   &-) Alan E. Feldmanm afeldman@gfigroup.com    ------------------------------  # Date: Mon, 23 Jul 2001 23:04:59 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)3 Subject: Re: Best file spec for incremental backup? - Message-ID: <v4277.1$Yx2.78@news.cpqcorp.net>2  m In article <af1e4ce6.0107231405.6ce77f38@posting.google.com>, afeldman@gfigroup.com (Alan E. Feldman) writes:o  G :In the manual referenced above, for an incremental restore, it says tok :start withn : E :BACKUP/IMAGE device:save-set-specifier[/SAVE_SET] output-specifier  . :.@ :followed by appropriate BACKUP/INCREMENTAL commands. However, I@ :noticed that the image backup command above doesn't contain theG :/RECORD qualifier. Is that an omission in the manual or is /RECORD nowaG :the default for BACKUP/IMAGE for recent-enough versions of VMS BACKUP?nD :IOW, shouldn't the /RECORD qualifier be added to the above command? :TIA.i    D   /RECORD is only valid on save and copy operations, not on restore 
   operations.i   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 23 Jul 2001 07:46:22 -0400o" From: "Hal Kuff" <kuff@tessco.com>- Subject: Re: Can a "White Alpha" box run VMS? O Message-ID: <F010DBF1DA831C35.5F4FD0EF37764A6E.A7000EE7CAD100A7@lp.airnews.net>o       No... NT ROMS only  - "Hans Vlems" <hvlems@iae.nl> wrote in message5" news:9jgsv2$bko$1@news.IAEhv.nl...: > A friend of mine has an unused Alpha sitting on a shelf.: > It's a white box Alpha, and IIRC it was sold to run WNT.@ > Is it possible to boot VMS on it, and if so what modifications
 > are needed?d >  > Hans Vlems >a >    ------------------------------  % Date: Mon, 23 Jul 2001 12:01:13 -0700o! From: Tom Linden <tom@kednos.com>i- Subject: RE: Can a "White Alpha" box run VMS?o9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEJGDAAA.tom@kednos.com>g   or Linux, using Milo   > -----Original Message-----) > From: Hal Kuff [mailto:kuff@tessco.com]m% > Sent: Monday, July 23, 2001 4:46 AMf > To: Info-VAX@Mvb.Saic.Como/ > Subject: Re: Can a "White Alpha" box run VMS?m >  >  >  >     No... NT ROMS only > / > "Hans Vlems" <hvlems@iae.nl> wrote in messagee$ > news:9jgsv2$bko$1@news.IAEhv.nl...< > > A friend of mine has an unused Alpha sitting on a shelf.< > > It's a white box Alpha, and IIRC it was sold to run WNT.B > > Is it possible to boot VMS on it, and if so what modifications > > are needed?l > >o > > Hans Vlems > >t > >y >  >    ------------------------------  % Date: Mon, 23 Jul 2001 21:49:49 -0400s9 From: "D.B. Turner, islandco.com" <dbturner@islandco.com>i- Subject: Re: Can a "White Alpha" box run VMS?o/ Message-ID: <tlpkkobt5a5c06@news.supernews.com>w  ! With the right Flash Eeprom - Yes   H Now I can't say that I have done this but if you should happen to have aI friend with the blue box version of your system - you can easily copy the)I flash eprom on a flash burner (be careful - these are a special type thatTK are quite hard to come by) and I can 100% guarantee it will work (in theoryr
 of course)   DT   -- David Turner   We sell Alpha's & Alpha Parts  http://www.islandco.comm sales@islandco.com Island Computers US Corp.c 2700 Gregory Streeti Savannah GA 31404t Tel: 912 447 6622j Fax: 912 201 0096.  , Tom Linden <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIKEJGDAAA.tom@kednos.com...d > or Linux, using Milo >n > > -----Original Message-----+ > > From: Hal Kuff [mailto:kuff@tessco.com]s' > > Sent: Monday, July 23, 2001 4:46 AM. > > To: Info-VAX@Mvb.Saic.Comw1 > > Subject: Re: Can a "White Alpha" box run VMS?- > >  > >  > >l > >     No... NT ROMS only > >s1 > > "Hans Vlems" <hvlems@iae.nl> wrote in messagea& > > news:9jgsv2$bko$1@news.IAEhv.nl...> > > > A friend of mine has an unused Alpha sitting on a shelf.> > > > It's a white box Alpha, and IIRC it was sold to run WNT.D > > > Is it possible to boot VMS on it, and if so what modifications > > > are needed?" > > >o > > > Hans Vlems > > >h > > >  > >s > >d   ------------------------------  % Date: Mon, 23 Jul 2001 19:08:01 -0400'- From: JF Mezei <jfmezei.spamnot@videotron.ca>o/ Subject: Re: Compaq FUD and lack of informationn, Message-ID: <3B5CAE4E.498D6FDA@videotron.ca>   Warren Spencer wrote:mG > >Can you please urge the people responsible in Compaq to start making ' > >some confidence-building statements?  > >  > J > I can do without the hummer, but like you, I'm anxiously awaiting facts.  L What more hard facts do you need that you could realistically hope Compaq to have available ?  M Technocal aspects of the port of VMS to Intel's chip were just begun a coupleiK weeks ago. This is a big project and you can't expect VMS engineers to have0 all the answers now.    L Compaq sent a clear message by the fact that it announced the death of AlphaX before knowing what was really involved in the porting of VMS to a replacement platform.  M Compaq visited its valued customers but doesn't care about informing the resto4 of its VMS customer base. Draw your own conclusions.  J Alpha will live on for quite a few years. It just won't move forwards pastO EV7. IA64 will eventually move ahead of Alpha since Alpha will stay put at EV7.u  H Compaq broke its commitment it had made to customers about the future ofL Alpha. Why would you beleive any commitment Compaq would made on how long itK intends to keep producing Alphas or VMS ? The market will decide and CompaqtL will steer the market where it wants to. Compaq cannot know what will happenI in 3-4 years with regards to demand for Alpha , performance of IA64, Bill L Gate's love affairs and the relationship between Monica Lewisnky and USB. ItM would be stupid for Compaq to make commitments for something it doesn't know.c  N What we do know is that Alpha is being retired, we don't know how long it willL take, but we know it will take at least 4-5 years, maybe up to 10 before new& Alpha servers are no longer available.  J The information Compaq doesn't give you is just as valuable , if not more,K than the information it gives you. It lets you draw your own conclusions onwJ whether the product you rely on is part of Compaq's long term strategy forL growth or whether it is just a legacy product that Compaq is keeping because1 killing it would generate too much bad publicity.f    N Palmer didn't openly say he wanted to kill VMS during his tenure. But the lackL of information about the future of VMS as well as the wording in some of theN few ads that were made let us make some pretty good conclusions about what theK intentions were. And these conclusions were later proven right since Palmer K supposedly did admit that he was out to kill VMS and that it was a mistake.m    L VMS is Compaq's product, not yours. It does with VMS what Compaq wants to doM with VMS. Compaq is not stupid and Compaq is fully aware of the sensitivities J of VMS customers. If it chose actions that stirred those sensitivities andK spread some fear about the future of VMS, it is no different nor worse thans) the Digital ads that called VMS "legacy".i  N The message is there. You may wish to ignore it before you do not like it, but it is there.   ------------------------------  # Date: Tue, 24 Jul 2001 03:28:13 GMTf4 From: "Terry C. Shannon" <terryshannon@mediaone.net>/ Subject: Re: Compaq FUD and lack of informationh= Message-ID: <hX577.17937$N21.5875070@typhoon.ne.mediaone.net>   5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messageo% news:3B58D397.CDDA69E7@bigfoot.com...oF > What I would like to know is when the True64 and/or Linux teams knewF > about the port(s) and when THEY started, and how far along THEY are. >   H The Tru64 and Linux rank-and-file apparently knew nada until the 24th or
 25th of June.o  J The Tru64 team allegedly started dusting off the Bravo port on the 26th or1 27th. They have Blazer hardware in-house already.w   ------------------------------  # Date: Tue, 24 Jul 2001 05:31:26 GMTi. From: "mulp" <michaelpettengill@earthlink.net>/ Subject: Re: Compaq FUD and lack of informationrE Message-ID: <OK777.11676$Xn.1406711@newsread1.prod.itd.earthlink.net>m  7 "Glenn C. Everhart" <Everhart@GCE.com> wrote in messages! news:3B5B2C36.2B44A250@GCE.com...o@ > If the VMS engineering group has a reputation for anything, it; > is for great skill in doing things right...where they aree= > given time. Evidence in the form of some hints as to things = > BEING DONE right should quiet worries, and quiet suspicions B > that Compaq is not "really" funding anything more than a holding > operation.  H But VMS engineering has been given zero time - VMS has a small window toJ deliver VMS on a new platform because it will take another year or two forG ISVs to get their software on VMS.  That's a long time to not be makinge	 progress.    ------------------------------  # Date: Tue, 24 Jul 2001 05:56:26 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>/ Subject: Re: Compaq FUD and lack of informatione= Message-ID: <e6877.18115$N21.5971629@typhoon.ne.mediaone.net>f  9 "mulp" <michaelpettengill@earthlink.net> wrote in message.? news:OK777.11676$Xn.1406711@newsread1.prod.itd.earthlink.net...? >h9 > "Glenn C. Everhart" <Everhart@GCE.com> wrote in message # > news:3B5B2C36.2B44A250@GCE.com...yB > > If the VMS engineering group has a reputation for anything, it= > > is for great skill in doing things right...where they ared? > > given time. Evidence in the form of some hints as to thingse? > > BEING DONE right should quiet worries, and quiet suspicions3D > > that Compaq is not "really" funding anything more than a holding > > operation.  & I have hwaed some of the same concens.   >tJ > But VMS engineering has been given zero time - VMS has a small window toL > deliver VMS on a new platform because it will take another year or two forI > ISVs to get their software on VMS.  That's a long time to not be making  > progress.a >n  I That's true... but if CPQ VMS reveues tank over the coupla quarters (e.g.eJ tank far in excess of Marketing Expectatoins), VMS may be euthanized... or> purchased.  At least some insiders are concerned about this...   ------------------------------  # Date: Mon, 23 Jul 2001 22:51:21 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)O Subject: Re: DEC 2000 and OpenVMS Support (was: Re: Upgrade PAGEFILE.SYS error)p3 Message-ID: <JT177.1134$rc5.73804@news.cpqcorp.net>n  W In article <C2256A92.00780C41.00@jklh21.valmet.com>, norm.raphael@jamesbury.com writes:-  G   Argh.  I've been bagged by a courtesy copy of a posting once again... :   Now off to dig up my email response, and post it here...E   Retitled to better reflect the discussion of the DEC 2000 series...a   :R U saying: :r6 :the DEC 2000 model 300 will no longer be supported by+ :OpenVMS releases after OpenVMS Alpha V7.3?   3   From the V7.3 Software Product Description (SPD):a   "...I OpenVMS Alpha Version 7.3-1 is the last version to support the following:.        DEC 2000 Models 300/500	      ..."s  =   For pointers to the SPD server, please see the OpenVMS FAQ.a  8 :the version of this hardware that was running Microsoft9 :Windows NT (and that hardware only supported Windows NT)d8 :[that] was known as the DECpc AXP 150 will no longer be7 :supported by OpenVMS releases after OpenVMS Alpha V7.3 6 :<If "that hardware only supported Windows NT" how can :this be at all?>?  C   The DECpc 150 AXP has never been officially supported by OpenVMS.   D   The DEC 2000 series was the name of the "universal version" of theE   "Jensen" system, the variant of the system that was able to and wasLI   supported with OpenVMS and Tru64 UNIX and Windows NT, as differentiatedoF   from the DECpc 150 AXP series system, the Jensen variant system thatD   ran and was supported (only) with Windows NT.  EISA configurations
   did differ.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 23 Jul 2001 22:31:10 +0100 - From: John Wisniewski <wisniewski@vmsone.com>S/ Subject: DFWCUG Announcement regarding DEFCON 9(* Message-ID: <3B5C979D.B35F6A42@vmsone.com>  & --------------9458CF1FDAE42CF46EB187BE* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit.  F The Dallas Ft Worth Compaq User Group (The DFWCUG) has an announcement
 regarding the  recent DEFCON 9 Convention:   A July 12-14th  2001, a team of DFWCUG members took an Alphastationa running OpenVMS-G 7.2-1h1 with a standard installation and OpenVMS Hobbyist PAKs, Apache, 
 and TCP/IPC services for OpenVMS 5.0a to the DEFCON 9 Hackers Convention in Las,	 Vegas NV.1  F The Alphastation was placed in competition during the Capture the Flag Hacking Game that wasAF held on the floor of  DEFCON 9during the convention as a member server of the GREEN team.  H The Alphaserver provided WEBservices and inbound telnet.   The Community was invited to telnettF to a public account that automatically created non-prived accounts and webservice for any of theoC Hackers on the floor.  An additional public account hosted terminalm based games such as VAXtrek,H Moria 4.81, Hack, Rogue, Battlestar, ZK and Doomsday 2000 (for those who got bored just trying  to hack;-).i  F The Green Team took 3rd place in the competition for Capture the Flag." After three long days on the floorB of Defcon 9 the Alphatation was deemed virtually unhackable by the! Defcon judges.  During the Awards C on Sunday July 14th the winning Team acknowledge the prowess of the ) green team's servers and systems managers0C and the CTF Judge declared the "VAX" Cool for it's content and it'se- continuous service during the worst that 4300 5 hackers could throw at it over the three day contest.0  F Congratulations and a sincere "Thank You" to the DFWCUG team for their& success and  reminding all of us  justF how secure and functional OpenVMS really is, even in the most security" hostile environment on the planet.  & The DFWCUG Steering Committee  7/23/01       --  C The DFWCUG is proud of member's accomplishments in the face of suchh" Hacking adversity and look forwardA to the security white paper that will be presented at CETS2001 ins- September once all the logs and data recordedrB by the Alphastation during the various attacks have been analyzed.  F In the meantime we invite you to read more about our Member's activity at DEFCON 9uB in our current QUADWORDS newsletter available in PDF format on our WEBpage.   DFWCUG HOMEPAGEu http://www.dfwcug.org/  $ DFWCUG QUADWORDS NEWSLETTER FOR JULY< http://www.montagar.com/dfwcug/DFWCUG_newsletters/200107.pdf   DEFCON HOMEPAGE7 http://www.defcon.org/  ! CETS 2001 CONVENTION IN SeptemberR http://www.cets2001.comr   DECUS/Encompass WEBpageD http://www.decus.org/6      & --------------9458CF1FDAE42CF46EB187BE) Content-Type: text/html; charset=us-asciis Content-Transfer-Encoding: 7bitw  > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html>F The Dallas Ft Worth Compaq User Group (The DFWCUG) has an announcement
 regarding thel <br>recent DEFCON 9 Convention:sI <p>July 12-14th&nbsp; 2001, a team of DFWCUG members took an Alphastationo running OpenVMS K <br>7.2-1h1 with a standard installation and OpenVMS Hobbyist PAKs, Apache, 
 and TCP/IPG <br>services for OpenVMS 5.0a to the DEFCON 9 Hackers Convention in Lasn	 Vegas NV. I <p>The Alphastation was placed in competition during the Capture the FlagK Hacking Game that wastH <br>held on the floor of&nbsp; DEFCON 9during the convention as a member server of the GREEN team.vG <p>The Alphaserver provided WEBservices and inbound telnet.&nbsp;&nbsp; # The Community was invited to telnetnF <br>to a public account that automatically created non-prived accounts and webservice for any of the?L <br>Hackers on the floor.&nbsp; An additional public account hosted terminal based games such as VAXtrek,H <br>Moria 4.81, Hack, Rogue, Battlestar, ZK and Doomsday 2000 (for those who got bored just trying4 <br>to hack;-).oU <p>The Green Team took 3rd place in the competition for Capture the Flag.&nbsp;&nbsp; " After three long days on the floorF <br>of Defcon 9 the Alphatation was deemed virtually unhackable by the& Defcon judges.&nbsp; During the AwardsG <br>on Sunday July 14th the winning Team acknowledge the prowess of then) green team's servers and systems managers G <br>and the CTF Judge declared the "VAX" Cool for it's content and it's.- continuous service during the worst that 4300o9 <br>hackers could throw at it over the three day contest.aI <p>Congratulations and a sincere "Thank You" to the DFWCUG team for theirn0 success and&nbsp; reminding all of us&nbsp; justJ <br>how secure and functional OpenVMS really is, even in the most security" hostile environment on the planet.. <p>The DFWCUG Steering Committee&nbsp; 7/23/01
 <br>&nbsp;
 <br>&nbsp; <p>--eF <p>The DFWCUG is proud of member's accomplishments in the face of such" Hacking adversity and look forwardO <br>to the security white paper that will be presented at CETS2001 in September-# once all the logs and data recordednF <br>by the Alphastation during the various attacks have been analyzed.H <p><b><font size=+1>In the meantime we invite you to read more about our( Member's activity at DEFCON 9</font></b>I <br><b><font size=+1>in our current QUADWORDS newsletter available in PDFb= format on our WEBpage.</font></b><b><font size=+1></font></b>0 <p>DFWCUG HOMEPAGEM <br><b><A HREF="http://www.dfwcug.org/">http://www.dfwcug.org/</A></b><b></b>e' <p>DFWCUG QUADWORDS NEWSLETTER FOR JULY. <br><b><A HREF="http://www.montagar.com/dfwcug/DFWCUG_newsletters/200107.pdf">http://www.montagar.com/dfwcug/DFWCUG_newsletters/200107.pdf</A></b><b></b>t <p>DEFCON HOMEPAGEM <br><b><A HREF="http://www.defcon.org/">http://www.defcon.org/</A></b><b></b>-$ <p>CETS 2001 CONVENTION IN SeptemberH <br><b><A HREF="http://www.cets2001.com">http://www.cets2001.com</A></b> <p>DECUS/Encompass WEBpageD <br><b><A HREF="http://www.decus.org/">http://www.decus.org/</A></b> <br><b></b>&nbsp;i <br><b></b>&nbsp;</html>  ( --------------9458CF1FDAE42CF46EB187BE--   ------------------------------  % Date: Mon, 23 Jul 2001 21:47:14 -0500R1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Does my file has an extension header?' Message-ID: <3B5CE1B2.B96D3E8F@fsi.net>k   Matthias Maisenbacher wrote: >  > Hello, > 8 > our disk ran into the problem that we still had enough; > file entries "Maximum # files" in indexf.sys, but alreadyo. > filled up the space with additional headers. >  > Read:  > 8 > Maximum # files: 733725 (according DFU report command)8 > Free headers:  1000 (yes, we already was at zero here)1 > Number of files on disk is no more than 530000.c  E The difference is this: Maximum number of files indicates the size ofb< the INDEXF.SYS internal bitmap allocated when the volume wasG INITIALIZEd. There can only be as many file headers total in INDEXF.SYS D as there are bits in the INDEXF.SYS bitmap to indicate each header's status (in-use or free). n  H As displayed, the "number of files" remark is misleading. What it reallyE means is the maximum number of header blocks that can be mapped to ansA existing INDEXF.SYS file, regardless of the number of extents thepH INDEXF.SYS file may have. Except for certain other data structures (suchE as the INDEXF.SYS bitmap), each block of INDEXF.SYS is a file header.0  C The INDEXF.SYS file CAN be extended, and CAN be non-contiguous. TheLD limitation is that INDEXF.SYS cannot have more than one file header.  O8 > The documentation says that this extension headers are	 > used if $ > a) the disk is quite fragmented or > b) ACLs are heavily used.o >   7 > Fragmentation is at 1,005 (according to DFU) and, yes - > we do use many ACLs (in average 8 per file)   D Well, understand: fragmentation is only an issue for files which areE allocated dynamically; that is, they are built at the default minimum F size and extended by writing to the file and adding records beyond theA file's then-current allocation. Existing files do not increase orsA decrease in fragmentation, unless you intentionally defragment bysF backup/restore or running an on-line defragmenter or unless you extend
 the files.  @ When you run DFU, look the freespace fragmentation, as this will6 indicate the likelihood of new files being fragmented.  AA > While we have to wait for a timeslot to increase the indexf.syse( > (which cost 3 days of backup and back)< > we have to live with this free blocks as long as possible.   You need to look at:  3 $ DUMP/HEADER/BLOCK=COUNT=0 ddcu:[000000]INDEXF.SYSm  : ...to see how fragmented the INDEXF.SYS file currently is.  " Of course, DFU will tell you this:  : INDEXF.SYS fragments/ map_in_use :  4 /10 words ( 6% used)  E ..., for example. As I understand it, the percentage is the amount ofeE space left in the extent map portion of the INDEXF.SYS file header totF map additional extents. When that reaches 98% or so (I don't know thatD you'd ever see any higher than that, but y'never know), you've about
 max'd it out.v  H When you do go to zero free headers, and then need another header (for aF new file, to extend a file by adding a header for additonal extent mapF space, to add an ACE to an existing file's ACL, etc.), the system willH attempt to extend INDEXF.SYS. The operation fails when the extent map inB INDEXF.SYS's file header is full or when all the available bits inG INDEXF.SYS's bitmap have been assigned. That's when you get the dreaded  "header file is full" message.  h6 > So we try to remove some ACLs. But for testing this,7 > we need to know, WHEN our ALCs are less enough to fitn > in one header. > 5 > So, is there a way to find out whether a given filee? > uses just one header or jumps over the boundary and uses two.U  
 Again, ...  7 $ DUMP/HEADER/BLOCK=COUNT=0 ddcu:<dir>filename.ext;verso   ...will do it.   -- o David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/v  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.r   ------------------------------  % Date: Mon, 23 Jul 2001 21:58:14 -0400u9 From: "D.B. Turner, islandco.com" <dbturner@islandco.com> 5 Subject: DS20e's 667Mhz in Stock - Waiting for a homei/ Message-ID: <tlpl4f1iptkqbc@news.supernews.com>f   We have two left  I These are as new as used can be - on-site warranty until February 24 2001yJ (verified through Compaq's online reference site and Compaq Field Service)  K They have never actually been used, the E. User took delivery and then wentl belly up    Anyhoo, here's the configuration   DY-56PAA-FA  VMS System  667Mhz EV67/667 CPU ! High Speed CD-ROM + 1.44MB Floppyq 1GB RAM (4x256)d 4 Slot Disk drive cage 18GB Hot Plug 10KRPM DiskS SN-KZPCA-AA U2SCSI Card PCIn( Elsa GLoria Synergy (or 3DLabs VX1 32MB) LK46W-A2 VMS Style Keyboardr MouseS
 Power Cord> EIP License Kit (Includes VMS Base, Multi User lIc. TCPIP etc)  2 Includes Rackmount Kit - Add $200 for Pedestal Kit   Asking $19,000     -- David Turner   We sell Alpha's & Alpha Parts- http://www.islandco.comu sales@islandco.com Island Computers US Corp.< 2700 Gregory Street. Savannah GA 31404C Tel: 912 447 6622o Fax: 912 201 0096s   ------------------------------  % Date: Mon, 23 Jul 2001 15:11:33 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>3) Subject: Re: Full port of VMS to Itanium.w, Message-ID: <3B5C76DD.CDB5218B@videotron.ca>   Fred Kleinsorge wrote:L > protocol handler.  It remains to be seen *exactly* what we will want addedF > to the console, if anything.  And what we will move into the O/S (as= > appropriate).  We are working on these questions right now.o  
 Questions:  N Is "console" just some ROM chip that sits next to the CPU, or is that embedded into the CPU ?  L For instance, if MOP were considered essential, would the computers destinedG to boot VMS simply be designed with a special ROM chip that allowed MOP1N booting, or would you guys have to go to Intel and beg for them to include MOP support in their architecture ?e   Also:3  H From the information you have been given so far, have you been given anyM indication on whether Intel would be willing to modify its chip to accomodateiN VMS, or have you already been told that it is the VMS engineers that will haveL to implement VMS on a "vanilla" IA64 ? Or is that still something that is to be decided ?  J I realise that IA64 may in the future be modified to support stuff such as> Wildfire style systems. But that isn't VMS specific, correct ?   ------------------------------  % Date: Mon, 23 Jul 2001 19:28:52 -0500M1 From: "David J. Dachtera" <djesys.nospam@fsi.net> H Subject: Re: IA-64 has Little-Endian (was: Re: No chance for OpenVMS...)' Message-ID: <3B5CC144.8B6723BD@fsi.net>m   Hoff Hoffman wrote:R > U > In article <3B5A89E0.6C170D2B@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:i@ > :No not at all.  I am talking about using the recovered files. > 5 >   BACKUP will be available, and will be compatible.h > J > :Exectuable images for VMS on Alpha may be unusable on IPF and trying to) > :rebuild a scenario will be impossible.t > G >   That is nothing different than the present VAX to Alpha operations.s > J >   I know that we have been receiving at least a little feedback and someG >   questions around any plans for binary translation and/or for binary,K >   emulation, but I'll have to defer an answer to those questions for now.   D Well, I can only speak for myself, but I should think that an "AEST"F (Alpha-environment translator) would be expected. I could be wrong, as always.o  ) ...and also as always, YMMV considerably.w   -- e David J. Dachterao dba DJE Systemse http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/e  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------    Date: 23 Jul 2001 11:20:55 -0700/ From: Brannon_Batson@yahoo.com (Brannon Batson)e  Subject: Re: IA64 Rocks My World= Message-ID: <4495ef1f.0107231020.478dfce9@posting.google.com>j  b andrew harrison <andrew.nospam@uk.sun.com> wrote in message news:<3B5C1637.B5489DE3@uk.sun.com>... > Fred Kleinsorge wrote: > > K > > OK.  I'm, not a database expert, but why is this a bad thing?  If TPC-CrJ > > truly measures relative performance that could be expected in the realK > > world - and if partitioning the system gets you this performance - thenpJ > > what's the big deal?  Tru64 clusters do provide a single system image,L > > making it relatively easy to administer.  On the other hand, if TPC-C isO > > just another meaningless benchmark number - then lets stop talking about itv- > > altogether - or define a meaningful test.n > >  > 3 > What would you say if a vendor did the following t > with a standard benchmark. > 9 > 1. Pretend that a clustered system with multiple nodes e? > and multiple database instances is equivalent to a similarly <0 > performing single node/single instance system.  1 It's the database that's clustered, not Wildfire.e  D Wildfire is NOT a clustered system (at least not by my definition). F It is a single system running a single coherence protocol and a singleD OS with a single system image.  It is a ccNUMA system, which by it'sC very nature places some of the burden on the programmer to maximizeAA performance.  Maybe the programs are not yet sophisticated to thep@ point where the messiness is transparent to the user or database6 admin, but it's just a matter of time before they are.  > > 2. Pretend that they have non clustered system when in fact > > they have a single system image but with multiple instances 9 > because without multiple instances the system does not  
 > perform.  F That's argumentative.  1) You are assuming that Wildfire's performance8 would be pathetic without running the clustered databaseE instances--which is an assumption based on facts not in evidence.  2) C You are assuming that people who buy $10 million systems don't known@ the difference between a single instance database and a multipleD instance database.  3) You are assuming that there are not customers> who will run the multiple instance versions to get the maximum performance.  ? > 3. Compare favourably this system with an equally performant F; > system which used one system image and one DBMS instance.   9 Wildfire is a single system image!  Say that three times.e  D If a customer is truley limited to a single DBMS instance, then theyF should ask their vendors to produce benchmarks accordingly before theyD purchase.  If it is true that everybody is limited this way (which I2 doubt), then the rules of TPC-C should be changed.  A > The fact that your employer has done all three of these things u9 > tends to inject a note of unintentional irony into yourb= > "just another meaningless benchmark number" comment. Compaq 4 > has hardly done TPC-C any favours in this respect.  E Look, I'm not a huge Wildfire fan or a database expert, but I do know F that there are no 'good' companies or 'bad' companies when it comes to@ benchmarking.  You lay down the rules of the contest and you let9 companies compete.  If the benchmark restrictions are not F representative of every customer's workload, then that is the fault of the benchmark.  ? As it stands, the Wildfire numbers are valid under the rules ofn submission for TPC-C.e  F Don't pretend that Sun or HP (or Intel) are any more moral than CompaqE when it comes to benchmarking.  I would love for you to try and arguer this point.h   > [...snip...rest of thread]   Brannoni not speaking for Compaqe   ------------------------------    Date: 23 Jul 2001 15:04:56 -07000 From: ruemmler@cello.hpl.hp.com (Chris Ruemmler)  Subject: Re: IA64 Rocks My World) Message-ID: <9ji728$igf@cello.hpl.hp.com>l  = In article <4495ef1f.0107231020.478dfce9@posting.google.com>,20 Brannon Batson <Brannon_Batson@yahoo.com> wrote:c >andrew harrison <andrew.nospam@uk.sun.com> wrote in message news:<3B5C1637.B5489DE3@uk.sun.com>...  >> Fred Kleinsorge wrote:E >> > iL >> > OK.  I'm, not a database expert, but why is this a bad thing?  If TPC-CK >> > truly measures relative performance that could be expected in the realrL >> > world - and if partitioning the system gets you this performance - thenK >> > what's the big deal?  Tru64 clusters do provide a single system image,/M >> > making it relatively easy to administer.  On the other hand, if TPC-C isoP >> > just another meaningless benchmark number - then lets stop talking about it. >> > altogether - or define a meaningful test. >> > 2 >> o4 >> What would you say if a vendor did the following  >> with a standard benchmark.A >> 4: >> 1. Pretend that a clustered system with multiple nodes @ >> and multiple database instances is equivalent to a similarly 1 >> performing single node/single instance system.o > 2 >It's the database that's clustered, not Wildfire. >aE >Wildfire is NOT a clustered system (at least not by my definition). 1G >It is a single system running a single coherence protocol and a single.! >OS with a single system image.  a >OA Correct.  The database is "clustered" and this is where the issueSE arises.  Unfortunately, I believe the multiple Oracle instances mightpB be considered as "partitions" by TPC-C definitions given the TPC-CC probably was not thinking about people running a clustered databasehF on a single instance.   In fact, the "cluster" area in the results wasD just recently done and no where in the executive summary do you have& do disclose that a "cluster" was used.  & > It is a ccNUMA system, which by it'sD >very nature places some of the burden on the programmer to maximizeB >performance.  Maybe the programs are not yet sophisticated to theA >point where the messiness is transparent to the user or databasem7 >admin, but it's just a matter of time before they are.h >;D Only if the ccNUMA has bad memory characteristics as the GS320 does.F HP's Superdome is ccNUMA as well (some memory is accessed at different= latencies than others), but it does not have problems runningcD a single instance of the database.  Customers running on a SuperdomeD don't have to partition their data or worry about NUMA issues.  OnlyC the GS320 seems to need to worry about this.  I believe SGI's firstc> NUMA boxes had the same problem as the GS320, but current onesE don't (from what I've heard).  Given SGI doesn't run commercial testst( on the Origin, it's hard to really tell.  ? >> 2. Pretend that they have non clustered system when in fact  ? >> they have a single system image but with multiple instances e: >> because without multiple instances the system does not  >> perform.g >mG >That's argumentative.  1) You are assuming that Wildfire's performanceo9 >would be pathetic without running the clustered database D >instances--which is an assumption based on facts not in evidence.   >pA There was evidence, but Compaq withdrew the number.  Compaq did arE single instance GS320 number that was really bad and shortly followedy@ it up (I believe within a month) with an OPS number that was 18%B better.  They then followed that up with another number later that@ was 27% better (same OS, database, processors), so I assume they+ found more ways to make the ccNUMA look OK.+  D >You are assuming that people who buy $10 million systems don't knowA >the difference between a single instance database and a multipleSE >instance database.  3) You are assuming that there are not customers_? >who will run the multiple instance versions to get the maximums
 >performance.p >/C I'm sure there are some customers willing to do this, but not many..F IT costs are too high to be doing dumb stuff to get around performanceD problems when the customer could just buy a box that performs better$ without having all of the headaches.   --Chrisb My own views   ------------------------------  # Date: Mon, 23 Jul 2001 20:39:06 GMT>2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)03 Message-ID: <KX%67.1126$rc5.73754@news.cpqcorp.net>.  h In article <9jhvmm$tgh$1@milo.mcs.anl.gov>, "Scandora, Anthony \(35048\)" <scandora@cmt.anl.gov> writes:  G :As an ISV, I would want to support as many customers as I could for ashK :little investment on my part as is reasonable.  If I could multi-boot somefE :collection of Windows, Linux, VMS, and Tru64 on the same development K :machines, I might be more motivated to make my stuff work on VMS and Tru64eK :than I would if I had to support my own Alpha systems for my VMS and Tru64 
 :products.  J   I expect to have a way to bootstrap a specified disk device, among thoseL   disks that are present on the system.  (I'll check with the engineer that I   was looking at this area, as I'm not immediately aware of the specificse   of that.)t  I   The EFI (the IPF console) and the MBR-like stuff out on the disk is an  K   area that is quite interesting, and a subject of discussions.  (Andy and nJ   I had a conversion on this area just last week.  We know what we have toI   do here for the EFI MBR, and we know of at least two potentially useful    extensions to OpenVMS here.)  G   MBR: Master Boot Record, a structure that is located at disk logical YH   block zero, and that describes the locations of other disk structures.  H   EFI reads the MBR as part of a process to locate required structures, F   akin to the Alpha SRM console's use of the disk bootblock to locate 0   the OpenVMS primary bootstrap image (APB.EXE).  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 23 Jul 2001 20:00:18 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)U Subject: Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker feste3 Message-ID: <mn%67.1125$rc5.73744@news.cpqcorp.net>n  e In article <mVG67.6333$eY6.299639@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:fM :I wonder if OpenVMS systems will still be this solid once they're running ony= :IA-64? (with inferior memory management hardware protection)   7   Some details of these problem(s) (via email), please?o  N   Is this a reference to the lack of URKW, NA, and a few other modes expected I   by OpenVMS?  If so, the engineers working on memory management here in tH   OpenVMS do not presently believe the (lack of) these page protections I   will be a constraint on the OpenVMS port to IPF.  For details on this, eK   please take a look at the protection key mechanism, and please also take lC   a look at how the page tables and even the page table design are sI   interestingly implemented almost entirely in the host operating system  J   software.  (This stuff is covered in detail in the Intel IA-64 manuals.)  L   If this is a reference to something else, then I would definitely be quiteD   interested in (email with) any available details and any pointers.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 24 Jul 2001 01:49:28 GMTe From: LBohan@dbc.spam_less..comnU Subject: Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker fest 8 Message-ID: <4kkpltsdcckihnvnkrbdniefbti4pvimii@4ax.com>  E On Mon, 23 Jul 2001 20:00:18 GMT, hoffman@xdelta.zko.dec.nospam (Hoffw Hoffman) wrote:   f >In article <mVG67.6333$eY6.299639@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:N >:I wonder if OpenVMS systems will still be this solid once they're running on> >:IA-64? (with inferior memory management hardware protection) >.8 >  Some details of these problem(s) (via email), please? > O >  Is this a reference to the lack of URKW, NA, and a few other modes expected oJ >  by OpenVMS?  If so, the engineers working on memory management here in I >  OpenVMS do not presently believe the (lack of) these page protections sJ >  will be a constraint on the OpenVMS port to IPF.  For details on this, L >  please take a look at the protection key mechanism, and please also take D >  a look at how the page tables and even the page table design are J >  interestingly implemented almost entirely in the host operating system K >  software.  (This stuff is covered in detail in the Intel IA-64 manuals.)M >EM >  If this is a reference to something else, then I would definitely be quite E >  interested in (email with) any available details and any pointers.l >GO > ---------------------------- #include <rtfaq.h> -----------------------------oO >      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    cO > --------------------------- pure personal opinion --------------------------- M >   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.coms  4 Do the mem mgmt folks forsee making "improvements"  @ (ie, copy-on-write),  or would that be too risky, given the time8 frames involved.    (just asking out of curiousity ...)    ------------------------------  % Date: Mon, 23 Jul 2001 21:47:51 -0000o- From: wspencer@ap.nospam.org (Warren Spencer)1' Subject: Re: Just one possible future!!:/ Message-ID: <tlp6s7fg6v9sb8@news.supernews.com>c  , bill@cs.uofs.edu (Bill Gunshannon) wrote in @ <Pine.LNX.4.10.10107211333430.1150-100000@triangle.cs.uofs.edu>:  C >If you have a minute (and a sense of humor) make a quick visit to:"/ >              http://www.cs.uofs.edu/~bill/VMS  >,0 >              This web page is browser safe!!  7 >            No cookies.  No Java.  No Javascript.  :-)   I I drove by that sign 6 weeks ago - still there - but no computer room in   sight.     ws  G Bill - you've got a typo on that page ("sedcurity") but the photos are r great!   -- i   Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------    Date: 23 Jul 2001 16:28:02 -07003 From: mjnews@wildernesscomputing.com (Matt Jenkins)SR Subject: LG06 Line Printer; Manual?; Vibrates with SHTL error when printing starts= Message-ID: <797d2369.0107231528.7b368af5@posting.google.com>c  F We have an LG06 line printer in one of our buildings.  It was recently; moved and I suspect may have gotten "bumped" by the movers.5  B When I begin printing on it the printer vibrates and I believe the error code it gave was SHTL.   Any ideas what this means?  D The ribbon and paper are moving freely with no problems.  I can turnF the printer on and advance the paper fine with the LF, FF, and up/down arrow buttons.  C Also, does anyone have the manuals in PDF for this printer?  We had B them long ago in PDF but the floppys it was stored on failed and I could not retrieve them.  A Thanks in advance.  PS:  Can you cc replies to my e-mail address.l   Matt   ------------------------------  % Date: Mon, 23 Jul 2001 21:10:37 -0500p1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i+ Subject: Re: LPs on the Web (Was: Re: DCPS)u' Message-ID: <3B5CD91D.53DA6FAD@fsi.net>l   Robert Deininger wrote:  > [snip]K > If Rich Marcello could discover the MORON at Compaq who's responsible fora > this kind of pricing, ...I  F Careful, there! That may be part of Richard's job - and we don't wanna piss *HIM* off now, do we?   -- o David J. Dachteraa dba DJE Systemsd http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/g  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.t   ------------------------------  % Date: Mon, 23 Jul 2001 14:59:16 -0500-: From: "Scandora, Anthony \(35048\)" <scandora@cmt.anl.gov>" Subject: Re: No chance for OpenVMS+ Message-ID: <9jhvmm$tgh$1@milo.mcs.anl.gov>-  3 "John McLean" <mcleanj@dplanet.ch> wrote in message # news:3B5886BB.4E0525C@dplanet.ch...u >o$ > "Scandora, Anthony (35048)" wrote: > >@ > >...  Compaq appears tonL > > be living up to its promise to deliver competitive Alpha systems for theE > > full lifespan of EV6 and EV7.  How many of us are making tacticalb	 decisionsi8 > > today for what will happen at the end of EV7's life? >oC > Would you go out today and make a very substantial purchase of andF > Alpha-based system ?  The picture is still very murky and in 3 yearsG > time you will almost certainly be up to additional costs of undefinedh > magnitude.  L Isn't that true of any system?  I paid a lot of my own money at the time forH a slot 1 Celeron and a genuine Intel BX motherboard.  When the prices ofG Pentium III CPUs came down, I found out that that motherboard cannot gopL beyond a 600 MHz Katmai; it won't support a Coppermine.  We upgraded our VAXK 6220 to a 6320 to a 6420, but stopped there because the 6520 required a newcG backplane.  Will a SPARC or PowerPC system bought today have a CPU-swapnI upgrade three years from now?  Would an EV6 Wildfire bought today have anoD EV7 CPU-swap upgrade three years from now according to the old Alpha	 schedule?b  ; > You also know that any applications that you have now for C > VMS will most likely have to be recompiled for an IA64 processor.t  D Based on Digital's track record of PDP-11 F4P and F77 to VAX FortranK migration, and the more recent VAX to Alpha migration, I think it's safe totC bet that recompiling an Alpha VMS program written in any of the GEMeL languages to a future Itanium running VMS will be easier than recompiling itI for SPARC Solaris or PowerPC AIX, or even a future Itanium running Linux.s   > ThisH > means that you must be damn sure that you can find the source code and3 > have the necessary acument to be able to do this.f  L Correct.  There are applications out there that are not recompilable for oneL reason or another, but many of them were put out of our misery in the VAX toI Alpha transition or the Y2K remediation.  We have until a few years after B the end of EV7's life to find the sources for or replace the rest.   > Will a commercialeG > application currently available on VMS on Alpha also be available for  > VMS on IA64 ?  Who knows ??n  F As an ISV, I would want to support as many customers as I could for asJ little investment on my part as is reasonable.  If I could multi-boot someD collection of Windows, Linux, VMS, and Tru64 on the same developmentJ machines, I might be more motivated to make my stuff work on VMS and Tru64J than I would if I had to support my own Alpha systems for my VMS and Tru64	 products.t   >  ...H > Correction "A future Itanium might" or even "A future Itanium should";G > this is in a future with far too many unknowns at this point in time.d  G Academic articles have claimed EPIC to have the potential to outperform L RISC.  If a resonable EPIC chip and compilers can do what the academics say,F VMS, Tru64, and NSK will have an advantage over Solaris and AIX.  I doG respect the combined resources of Intel, HP, and Compaq.  Remember RISCcC being denounced because it could never surpass the power of the VAXtJ architecture?  And if EPIC crashes and burns, Compaq will still own Alpha.   > ...rI > Getting the ISV's on board will be critical for the future of VMS.  TheIG > other critical factor is the strength of marketing for this platform.oH > Neither has been a strong point for Compaq and as someone in the groupJ > has nicely stated, let's hope they use a decent amount of the money from8 > Intel to do what they should have been doing ages ago.  J True, and that has nothing to do with architecture.  It might be easier toF sell ISVs on Itanium than on Alpha.  Whether running on VAX, Alpha, or= Itanium, somebody needs to sell VMS to ISVs and to end users.c  1 Tony Scandora, Argonne National Lab, 630-252-7541m scandora@cmt.anl.gov   ------------------------------  % Date: Mon, 23 Jul 2001 21:48:45 +0100>+ From: "antonio.carlini" <arcarlini@iee.org>s" Subject: Re: No chance for OpenVMS' Message-ID: <3B5C8DAD.703DCE34@iee.org>o   Duane Sand wrote:e= > operating systems and applications.  (Alpha belatedly addedi? > this about five years ago.)  Besides Cray, the now-redirectedo  $ I didn't realise it was not in there' from day one - but looking at the AARMsO% issued in 1992 and 1995 you appear tos be correct.n  ; > port of NonStop Himalaya from Mips onto Alpha was also to>E > be big-endian.   HP's port of its legacy OS onto IPF is big-endian. @ > The restarted port of NonStop Himalaya onto IPF is big-endian.  " Another useful set of data-points. Thanks.e   Antonioi   -- e   --------------- - Antonio Carlini             arcarlini@iee.org    ------------------------------  # Date: Tue, 24 Jul 2001 02:40:01 GMTa. From: "mulp" <michaelpettengill@earthlink.net>" Subject: Re: No chance for OpenVMSE Message-ID: <5e577.11323$Xn.1346699@newsread1.prod.itd.earthlink.net>e  C "Scandora, Anthony (35048)" <scandora@cmt.anl.gov> wrote in messageo% news:9jhvmm$tgh$1@milo.mcs.anl.gov... J > > Correction "A future Itanium might" or even "A future Itanium should";I > > this is in a future with far too many unknowns at this point in time.v >tI > Academic articles have claimed EPIC to have the potential to outperformsI > RISC.  If a resonable EPIC chip and compilers can do what the academics  say,H > VMS, Tru64, and NSK will have an advantage over Solaris and AIX.  I doI > respect the combined resources of Intel, HP, and Compaq.  Remember RISCrE > being denounced because it could never surpass the power of the VAXoL > architecture?  And if EPIC crashes and burns, Compaq will still own Alpha.  E I don't recall anyone claiming that RISC couldn't match or exceed VAX C performance.  The major issue was whether there would be sufficientmC resources to make VMS and VMS apps perform as well as the same appse performed on VAX.a  G Bob Supnik justified switching to RISC because it would deliver a given J level of performance in a given technology 1-2 years earlier than it couldI be done with a CISC implementation.  The primary reason was that RISC washG relatively easier to implement.  He didn't argue that you couldn't keepb# making faster CISC implementations.0  B IA64 is more complex than Alpha, plus it includes an IA32 core forL compatibility.  To me this says that IPF chips will deliver a given level ofL CISC performance at least 1-2 years later than the CISC implementation used,D and it will likely deliver EPIC performance 1-2 years later than the comparible RISC implementation.>  K IA64 is the only alternative going forward, unless Intel decides to restartfF Alpha development.  Compaq won't have anyone left to even recruit chipJ engineers by the time such a decision might be made.  This is particularlyK one case where "technology" means "people".  For example, VAX clusters havecH been shipping for 15 years and the only close implementations of the VMS4 cluster model has been done by former VMS engineers.  H And VMS will not be the OS that kills IA64; VMS customers value a lot ofG things more than performance; the lack of performance relative to unix,mK either tru64 or linux, has not prevented people from continuing to buy VMS. D If IA64 doesn't make it in the market place, VMS will be in the same position as VMS on Alpha.    ------------------------------  % Date: Mon, 23 Jul 2001 18:58:37 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)* Message-ID: <3B5C65CD.DA57978C@uk.sun.com>   John Santos wrote: > E > In article <3B5BF0D0.DEEE63E5@uk.sun.com>, andrew.nospam@uk.sun.comt	 > says...e > > Larry Kilgallen wrote: > > >dc > > > In article <3B56A150.8B23833D@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:  > > > >m > > > > Fred Kleinsorge wrote: > > > >>S > > > >> A quick check of the source listings seems to indicate that I am.  And theDL > > > >> hot air you blow seems to be the only indication of what you do ;-) > > > >> > > > >r< > > > > Really, I would suggest that since the 25th your own5 > > > > contributions have had an element of warm airu5 > > > > polluting what is normally relatively factualb5 > > > > content :):):) hence my re-evaluation of yours
 > > > > role.n > > > M > > > Andrew, given Fred's position, we look to him for authoritative answers L > > > on what VMS Development engineers want to do.  That is not necessarilyK > > > what the company management will end up doing, but even in the Compaq < > > > environment, it is a powerful influence on management. > > >y > > = > > Really, note that I said since the 25th. Your point abouta> > > "powerful influence" before that date might well have been$ > > defensible, since then it isn't. > F > The quote is "powerful influence on management."  In another thread,= > aren't you currently denying that you tell us what Compaq'so< > management's plans are without any documentation?  Can you= > provide us with documentation for that "fact" that what VMSuD > development engineers want to do is no longer a powerful influence > on management? >   + What do you understand a roadmap to be ??? r  : In the computer industry its generally a set of technical 8 milestones which have sales related activity associated 6 with them. The development test, debug and release of : a new system followed by the sales and marketing campaign.  6 Now Compaq have revealed the latter and not the former2 and from posts from the likes of Kerry and Rob it 1 is obvious that the sales and marketing campaign c has started.  8 Unfortunately as we now know from various Compaq posters7 the development/test/debug plan and the setting of the r8 technology milestones for the IA-64 port have only just  started.  7 If you want confirmation of this then read Mr Hoffmans a: post, do you think from the post that OpenVMS development 8 were consulted prior to the sales campaign starting ????   > Spin, spin, spin, spin...3 > ? > > From coments made by various Compaq representatives on thisl= > > newsgroup it is clear that VMS development engineers werew? > > either consulted very very close to the 25th or not at all.n > >o< > > The decision to move OpenVMS to IA-64 is one of the most< > > important development decisions that has been made about= > > OpenVMS in the last 5 years. A powerfull influencer wouldoA > > have been consulted, there is no evidence that this happened,n@ > > if it had then why do "powerfull influencers" post responsesB > > like we have only had 13 days to look at the porting issues ?? > F > Because the (few) engineers with advanced knowledge don't post here,, > or are required to keep their mouths shut? >   : But since none of these shadowy indeviduals if they exist 7 at all have posted to this newsgroup on this subject weh8 can only take you word for it that they actually exist.   # Care to dig out a post from one ???)  A > Compaq engineers have posted that the decision was made as muchlB > for engineering reasons as anything else.  Either they are lyingA > or they were lied to, or they are telling the truth.  Since you-8 > can't handle the truth ;-), you assume they are lying. >   : Really, I suspect that you are the one in denial. What was: the engineering reason given for dropping Alpha ??? it was7 if I remember a suggestion that Alpha could not keep upf9 performance wise with IA-64, this claim has subsequently   be debunked.   Regards: Andrew Harrison  Enterprise IT Architectn   ------------------------------  # Date: Mon, 23 Jul 2001 19:17:45 GMTO2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)3 Message-ID: <tL_67.1120$rc5.73614@news.cpqcorp.net>   ] In article <3B5C65CD.DA57978C@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:o  F   If I read the contents of the posting correctly, I can summarize it H   as: "OpenVMS is porting to IPF.  Questions exist.  Details to follow."  H   We are porting OpenVMS to IPF, and we will be providing more specific 4   technical information as the design work proceeds.  H   Clair Grant (the OpenVMS Technical Architect) and I (resident OpenVMS H   "fixture") will be presenting a session on the OpenVMS port to IPF at G   the CETS2001 event, and I'd expect to see that information also made s;   widely available to folks that are unable to attend CETS.n  ?   To date, I am not aware of the identification of any porting e   show-stoppers.  9 :Unfortunately as we now know from various Compaq postersh8 :the development/test/debug plan and the setting of the 9 :technology milestones for the IA-64 port have only just s	 :started.e  E   So?  (I actually like the fact that things are moving very quickly,n3   it's fun and it's challenging...  But I digress.)l  8 :If you want confirmation of this then read Mr Hoffmans ; :post, do you think from the post that OpenVMS development  9 :were consulted prior to the sales campaign starting ????-  C   I am not in charge of OpenVMS Engineering -- that job is owned by    Mark Gorham.  H   As for who here in OpenVMS Engineering got consulted concerning IA-64 I   and when they were consulted, so what?  (Arguably a canard, of course.)a  F   And the complaint here is that the marketing folks are out in front C   of the engineers?  (That complaint is certainly a switch from the !   historical newsgroup norms. :-)r  ; :But since none of these shadowy indeviduals if they exist e8 :at all have posted to this newsgroup on this subject we9 :can only take you word for it that they actually exist. N :.$ :Care to dig out a post from one ???  I   Don't bother looking -- shadowy individuals almost by definition don't iG   post.  If they did, they would not be shadowy.  For that matter, the  E   post now being read might well be created by an automated spin-bot vI   blowing some freshly-spun left-whirled hot air, so folks can obviously -&   also discount this posting, too. :-)  ; :Really, I suspect that you are the one in denial. What wash; :the engineering reason given for dropping Alpha ??? it wasw8 :if I remember a suggestion that Alpha could not keep up: :performance wise with IA-64, this claim has subsequently 
 :be debunked.-  H   I'd like to post further details on this, but -- having seen postings G   on this topic that have missed the central issue -- I'm unfortunatelybJ   not in a position to post those details right now.  The suggestion that J   Alpha could not keep up with IA-64 over the long haul is quite correct, J   and is (at least for now) the limit of the details on the decision that     I can reasonably provide here.  J   If anyone here want additional specifics on the port of OpenVMS to IPF, K   I can get you in contact with the folks here in OpenVMS Engineering that tI   are fielding these questions.  (But as has been pointed out, we do not tI   yet have extensive technical design details of the OpenVMS port to IPF s
   available.)s  F   Additional information will be posted as it becomes available.  As aJ   specific example of this -- and as I have mentioned elsewhere -- I have H   a specification of how application code (DCL procedures and executableI   programs) can identify the processor and platform.  This specification yK   is presently under review.  As soon as this is reviewed and is approved,     then it will be provided.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 23 Jul 2001 15:45:18 -0400y* From: "Andy Stoffel" <acs@fcgnetworks.net>H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)7 Message-ID: <P9%67.18980$sE4.384064@news6.giganews.com>o  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messaget- news:tL_67.1120$rc5.73614@news.cpqcorp.net...-  J >   Don't bother looking -- shadowy individuals almost by definition don'tH >   post.  If they did, they would not be shadowy.  For that matter, theF >   post now being read might well be created by an automated spin-botJ >   blowing some freshly-spun left-whirled hot air, so folks can obviously( >   also discount this posting, too. :-)  D Well, given the technical knowledge/expertise exhibited for the last: few years in comp.os.vms (and other online venues) by this< supposed "spin-bot" (Created, I can only assume, by the real: Stephen Hoffman as part of some experiment deep within the4 bowels of (Open)VMS Engineering.) I'm impressed :-).  = [It's even intelligent enough to deal with holidays and otherr5  occasions when its' creator is out of the office...]y  B And if the effort that appears to have gone into the "spin-bot" is; applied to the VMS IPF port we have "nothing to fear" whilef "Waiting for Itanium" :-).   -Andy-   ------------------------------  % Date: Mon, 23 Jul 2001 15:58:24 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>oH Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)( Message-ID: <9jhvcm$agc$1@pyrite.mv.net>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagee- news:tL_67.1120$rc5.73614@news.cpqcorp.net...d< > In article <3B5C65CD.DA57978C@uk.sun.com>, andrew harrison" <andrew.nospam@uk.sun.com> writes:   ...o  = > :Really, I suspect that you are the one in denial. What wash= > :the engineering reason given for dropping Alpha ??? it wase: > :if I remember a suggestion that Alpha could not keep up; > :performance wise with IA-64, this claim has subsequently  > :be debunked.e >rI >   I'd like to post further details on this, but -- having seen postingsgI >   on this topic that have missed the central issue -- I'm unfortunatelynK >   not in a position to post those details right now.  The suggestion thatrK >   Alpha could not keep up with IA-64 over the long haul is quite correct,mK >   and is (at least for now) the limit of the details on the decision thata" >   I can reasonably provide here.  F That statement bothers me a lot, since I suspect that most people hereG (including me) would normally consider such a statement from you prettyA7 close to a Revealed Truth that could not be questioned.n  G Unfortunately, I've seen at least equally unequivocal statements to thepL contrary from senior Alpha engineers and I find it difficult to believe thatL you know as much about the technical aspects of chip performance as they do.I So I'm left with the conclusion that any inability of Alpha to retain andsJ even increase its performance lead over IA64 was not a technical issue butJ the result of some business decision - which is not inconsistent with whatL you state above, but hardly the impression that your statement appears to be trying to convey.    - bill   ------------------------------  % Date: Mon, 23 Jul 2001 15:10:17 -0500i+ From: Christopher Smith <csmith@amdocs.com> H Subject: RE: Now we're cooking with gas. (was:  Wailing and moaning....)L Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DA55@cmiexch1.cmi.itds.com>  L In that case, what are they hypothetical chances we can get this spin-bot on the next freeware cd? :)   Regards,   Chrisa  ! Christopher Smith, Perl Developern Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");r '       > -----Original Message-----% > From: hoffman@xdelta.zko.dec.nospamw   > matter, the G >   post now being read might well be created by an automated spin-bot h= >   blowing some freshly-spun left-whirled hot air, so folks i > can obviously ( >   also discount this posting, too. :-)   ------------------------------  % Date: Mon, 23 Jul 2001 15:02:31 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>t Subject: Re: OT: Dr Who., Message-ID: <3B5C74C0.BF7167B1@videotron.ca>   "Bart Z. Lederman" wrote: : > As for Mr. Bean and Black Adder: he hasn't done anything0 > really good since "Not the Nine O'Clock News".  L Actually, there was a series about Bean being the chief constable in a smallK town police station with Constable Habib (female) and Goodie (useless cop). * The title escapes me. It was an OK series.   ------------------------------    Date: 23 Jul 2001 21:07:00 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: OT: Dr Who.* Message-ID: <3b5c75d4$1@news.kapsch.co.at>  \ In article <3B5C74C0.BF7167B1@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >"Bart Z. Lederman" wrote:; >> As for Mr. Bean and Black Adder: he hasn't done anything91 >> really good since "Not the Nine O'Clock News".  >aM >Actually, there was a series about Bean being the chief constable in a smallaL >town police station with Constable Habib (female) and Goodie (useless cop).+ >The title escapes me. It was an OK series.a   Insp. Fowler ?   -- n< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888e< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------   Date: 23 Jul 2001 20:06:27 GMT2 From: ap333@FreeNet.Carleton.CA (Marvin Kaplansky) Subject: Re: OT: Dr Who./ Message-ID: <9ji043$ob2$1@freenet9.carleton.ca>i  , Peter LANGSTOEGER (eplan@kapsch.net) writes:^ > In article <3B5C74C0.BF7167B1@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >>"Bart Z. Lederman" wrote:h< >>> As for Mr. Bean and Black Adder: he hasn't done anything2 >>> really good since "Not the Nine O'Clock News". >>N >>Actually, there was a series about Bean being the chief constable in a smallM >>town police station with Constable Habib (female) and Goodie (useless cop). , >>The title escapes me. It was an OK series. >  > Insp. Fowler ? >    "The Thin Blue Line"     Marvin Kaplansky   ------------------------------  # Date: Tue, 24 Jul 2001 04:04:11 GMTr. From: "mulp" <michaelpettengill@earthlink.net># Subject: Re: Process adopts ItaniumeE Message-ID: <%s677.11493$Xn.1379097@newsread1.prod.itd.earthlink.net>f  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:susnlt4m1cij8k13uv7mirtic9ijl1dq70@4ax.com...E > Richard also presented some slides of what the 2004 servers will beiG > like. They showed one system running NT, Tru64 (or was it Linux?) andeG > VMS in partitions. So in four years time Compaq will start selling anfG > Intel based server which can do what was first demonstrated in publici" > about two years ago on an Alpha.  = This was demonstrated more like 4-5 years ago on a tlaser....f   ------------------------------  % Date: Tue, 24 Jul 2001 10:35:43 +0800e' From: Tim Sneddon <tsneddon@olc.com.au>r> Subject: RE: SMS on VMS [was RE: Full port of VMS to Itanium.]< Message-ID: <2FCE1FC4E068D411877B00D0B7477F4DBF048E@onlpc26>  D I heard that SMS in Australia was running on VMS. Also the Lotteries0 Commission in Western Australia runs on VMS too.   Tim.   -----Original Message----- From: Main, Kerrye To: Info-VAX@Mvb.Saic.Coml Sent: 24/07/2001 1:34 AM> Subject: RE: SMS on VMS [was RE: Full port of VMS to Itanium.]    8 >>> I know that the British Columbia Lottery uses VMS.<<   As does Ontario.   Regards,  
 Kerry Main Senior Consultantu Compaq Canada Inc. Professional Servicesr Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----* From: John Vottero [mailto:John@mvpsi.com] Sent: July 23, 2001 11:24 AM To: Info-VAX@Mvb.Saic.Comi> Subject: Re: SMS on VMS [was RE: Full port of VMS to Itanium.]    : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B594BB0.76EA27F7@videotron.ca... > Burnie M wrote:.H > > Sorry for the TLAs but yes VMS is at the core of Telecoms especially > > GSM mobile networks. > D > You make it sound like all GSM networks make extensive use of GSM. Funnys how B > the local GSM network here in canada seems to only advertise for window weenie > and Sun Solaris jobs.n >aG > I keep hearing how lotteries run on VMS, yet the provicial lottery is> a  tandemH > shop. I keep hearing how telecom runs on VMS, yet I never see adds for VMS ) > folks from the local telecom companies.i >c  2 I know that the British Columbia Lottery uses VMS.   ------------------------------  % Date: Mon, 23 Jul 2001 16:18:05 -0400 . From: "Jerry Alan Braga" <jabraga@flanagan.ca>$ Subject: SMTP and distribution lists4 Message-ID: <oE%67.267463$Z2.3250513@nnrp1.uunet.ca>  G SMTP will look for a file in the tcpip$smtp_common directory for a filet4 named the same as the TO address in the email. GREAT  K That way you can actually has more than 1 alias for a single vms user emaily accountn   tcpip domain = domain.com  OpenVMS user = joe  % email address would be joe@domain.com   K If you place a file in the tcpip$smtp_common directory call testjoe.dis and = have contain the address joe@domain.com you can then email toe) testjoe@domain.com and it will work also.   G Is it possible to somehow use the first.last@domain.com using the abovetD construct.  I have tried this but of course OpenVMS does not allow aL filename called FIRST.LAST.DIS .  Can you somehow substitute using a logicalL or something a character in the filename that would translate to another for
 the filename.n  J eg email = first.last@domain.com = tcpip$smtp_common:first$last.dis (where( the "." is replaced by a "$") for lookup   ------------------------------  # Date: Mon, 23 Jul 2001 21:37:00 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)( Subject: Re: SMTP and distribution lists3 Message-ID: <0O077.1129$rc5.73715@news.cpqcorp.net>p  e In article <oE%67.267463$Z2.3250513@nnrp1.uunet.ca>, "Jerry Alan Braga" <jabraga@flanagan.ca> writes:v  H :Is it possible to somehow use the first.last@domain.com using the aboveE :construct.  I have tried this but of course OpenVMS does not allow ap# :filename called FIRST.LAST.DIS .  o  J   OpenVMS does support this ability (V7.2 and later), but TCP/IP Services 0   has not been updated to full support of ODS-5.  + :Can you somehow substitute using a logicalnM :or something a character in the filename that would translate to another forp :the filename.     Try:       $ def foo.bar foo/system  H   Where the target distribution file is named tcpip$smtp_common:foo.dis.E   (You could use another logical name table, but you need to keep thetF   logical in a name table where it is visible to the SMTP processing.)  I   I do not know if this is documented and supported, but it does seem to     work.s  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 24 Jul 2001 03:42:34 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on IA-64n= Message-ID: <K8677.17946$N21.5885175@typhoon.ne.mediaone.net>i  C > In article <unQ57.340$Xn.28543@newsread1.prod.itd.earthlink.net>,e/ > mulp <michaelpettengill@earthlink.net> wrote:nL > > Not sure who all the mulp's are that prevent me from signing on as mulp, butlJ > > Terry probably figures that mulpinnh no longer works for Compaq and noH > > longer needs to get information about what's going on inside Compaq.  K The truth of the matter is that the mysterious individual known as mulpinnhuJ has been nil heard hereabouts for quite some time. Where he/she is and who% he/she works for, I haven't a clue...   F But the way things are right now, you might get more information aboutE what's going on inside Compaq from an outsider than from an employee!l   ------------------------------  % Date: Mon, 23 Jul 2001 18:07:05 +0100(0 From: andrew harrison <andrew.nospam@uk.sun.com>: Subject: Re: The death of VMS has been greatly exaggerated* Message-ID: <3B5C59B9.3F97198A@uk.sun.com>   YYYGAC2 wrote: > d > andrew harrison <andrew.nospam@uk.sun.com> wrote in message news:<3B5BF9A7.A6B115B0@uk.sun.com>... > > "Main, Kerry" wrote: > > >D >  > -- snip -- >  > >a > > Here is you post.PM > > > In addition, with the exception of MS, each OS provider has a backup orgO > > > alternate 64bit HW plan (Power4, Alpha EV7, PA, MIPS) that will allow thenQ > > > Customer to migrate when they feel the timing is right - whether it is in 3  > > > years or 5+ years. > > >x > >t" > > Is you memory so short ??????? > >e > > Regardst > > Andrew Harrisonl > > Enterprise IT Architectt > D > I believe that memory problems can only be revealed after you have > executed a NDA. ;^)e  9 Hum, we are talking about Compaqs roadmap for OpenVMS on /9 IA-64, ironic that you bring up NDA's since NDA's are thef8 last thing you can expect from Compaq. How can you even 5 get an NDA on something (the roadmap) which is still i under construction.d   :):):)       Regards  Andrew HarrisonI Enterprise IT Architectf   ------------------------------  % Date: Mon, 23 Jul 2001 18:10:25 +0100S0 From: andrew harrison <andrew.nospam@uk.sun.com>: Subject: Re: The death of VMS has been greatly exaggerated) Message-ID: <3B5C5A81.5621D21@uk.sun.com>k   "Main, Kerry" wrote: > 	 > Andrew,S > ? > >>>Bullshit if you didn't mean backup why did you say it ?<<<n > M > "Backup" referred to an IA64 failback strategy (HP-PA, Alpha-EV7, NSK-MIPS,hK > IBM-Power) until IA64 servers met expectations while "alternate" strategyt? > referred to IBM having two future strategies - IA64 or Power.- > & > >>>Is you memory so short ???????<<< > ! > Hey, maybe I need some ECC eh ?s  	 You need:e   1.	Credibility.j- 2.	A masters degree in spin (you deserve it).y  ) 1 will be tricky 2 is already in the bag.s   :):)   Regards  Andrew Harrisoni Enterprise IT Architect    ------------------------------  % Date: Mon, 23 Jul 2001 13:59:26 -0400w- From: JF Mezei <jfmezei.spamnot@videotron.ca>aY Subject: Re: Triggering tasks from network file arrival - Was Re: Basic VMS Questio Questd) Message-ID: <3B5C65FA.45692@videotron.ca>d  K Actually, what would be nice for the FTP server on VMS is if a logical namen such as " $define TCPIP$FTP_SUBMIT  my_queue  K is set, then FTP would submit each received file to "my_queue" upon closingt the file succesfully.w  K "my_queue" could then be a "server" queue which would process in the comingo6 file. That would be a very esthetic and efficient way.    I I guess another way would be to send the logging information from the FTPoK process to a mailbox where a server process would consume messages and thenhK process a received file once the FTP process issues the message that a files has been received.   ------------------------------  % Date: Mon, 23 Jul 2001 17:53:45 -0400h  From: norm.raphael@jamesbury.com' Subject: Re: Upgrade PAGEFILE.SYS erroro4 Message-ID: <C2256A92.00780C41.00@jklh21.valmet.com>   Hoff,M0 (Excuse me if I'm reasking, I got to this late.)   R U saying:s  5 the DEC 2000 model 300 will no longer be supported byn* OpenVMS releases after OpenVMS Alpha V7.3?   or  7 the version of this hardware that was running Microsofts8 Windows NT (and that hardware only supported Windows NT)7 [that] was known as the DECpc AXP 150 will no longer bef6 supported by OpenVMS releases after OpenVMS Alpha V7.35 <If "that hardware only supported Windows NT" how canf this be at all?>?a   or both?   -Normy          7 hoffman@xdelta.zko.dec.nospam on 07/16/2001 06:44:16 PMh  / Please respond to hoffman@xdelta.zko.dec.nospam-   To:   Info-VAX@mvb.saic.com- cc:-( Subject:  Re: Upgrade PAGEFILE.SYS error        P In article <9ivnno$9mg@dispatch.concentric.net>, "Paul Dembry" <pade@trifox.com> writes:oJ :I am upgrading an AXP 150 from 7.2-2 to 7.3.  All goes well for the firstC :80% of the execution phase and then I get three messages about the-M :PAGEFILE.SYS filling up, full, and attempting to continue.  Needless to say,kI :the update hangs at this point.  My 7.2-2 PAGEFILE.SYS was 76000 blocks..K :Using the DCL prompt on the 7.3 CD, I enlarged it to 86000 blocks but thisaJ :does not seem to have "taken".  How do I expand the PAGEFILE.SYS pagefile  :such that the upgrade keeps it?  J   I would not expect the primary PAGEFILE.SYS on the target system disk toI   be altered or bypassed by the upgrade.  That said, it would appear thatnH   your 86,000 block pagefile is simply (still) too small, and I'll guessH   that your system's physical memory is also constrained -- insufficientG   physical memory obviously tends to increase the load on the pagefile.e  M   In other words, create a large(r) version and purge out any older versions.b  H   I will assume you are aware that the DEC 2000 model 300 -- the versionK   of this hardware that was running Microsoft Windows NT (and that hardwareiF   only supported Windows NT) was known as the DECpc AXP 150 -- will noC   longer be supported by OpenVMS releases after OpenVMS Alpha V7.3.f  N  ---------------------------- #include <rtfaq.h> -----------------------------J       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.comN  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 23 Jul 2001 17:15:37 -0400$# From: fyom <fyom@symmsys.comNOSPAM>"@ Subject: Will a DEC Alpha XL300 300 MHz Workstation run OpenVMS?8 Message-ID: <9u4plt0ss5sqifik1p3i4kp9dqjodlh3rt@4ax.com>   Hi,@  F I am thinking of getting an alpha system to run OpenVMS as a hobbyist.D Can anyone please tell me if the DEC Alpha XL300 300 MHz Workstation can run openVMS?   Thanks!o Francisg   ------------------------------  # Date: Mon, 23 Jul 2001 22:47:18 GMTe2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)D Subject: Re: Will a DEC Alpha XL300 300 MHz Workstation run OpenVMS?3 Message-ID: <WP177.1133$rc5.73873@news.cpqcorp.net>i  ^ In article <9u4plt0ss5sqifik1p3i4kp9dqjodlh3rt@4ax.com>, fyom <fyom@symmsys.comNOSPAM> writes:  G :I am thinking of getting an alpha system to run OpenVMS as a hobbyist.iE :Can anyone please tell me if the DEC Alpha XL300 300 MHz Workstationr :can run openVMS?t     Relevent OpenVMS FAQ section:   6     ALPHA15.  Will OpenVMS run on the Alpha XL series?     Short answer:s       No.   :   The XL series runs Windows NT and (probably also) Linux.  G   For a hobbyist without particular experience in OpenVMS (infering faruC   to much from your posting, I'm sure), I'd initially recommend an t@   AlphaStation series, with EV4 at 300 MHz, or an EV5 or better.E   I'd stick to supported I/O configurations until more familiar with cB   the requirements and the options -- and once you have a baselineE   configuration working.  The AlphaStation also gets you a reasonablecE   console, reasonable SCSI and PCI expandability, and (given 128+ MB nI   of memory) reasonable performance and the AlphaStation series normally rJ   also provides such useful features as a failsafe firmware loader should    you toast your firmware.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 24 Jul 2001 01:02:26 +0100 1 From: "Chris Townley" <news@townleyc.demon.co.uk>u" Subject: Re: Your reply on GSDFULLA Message-ID: <995934502.18507.0.nnrp-14.d4e45fa5@news.demon.co.uk>i  @ This prompted me to take a look at what is now DYNAMIC under 7.3 Bleedin'bootiful!n  * Can't of read the release notes very well!  G Now got to get 3 production machines off 6.2, 4 off 7.2 plus France andl9 Germany off 7.1  then I can move my development machines..  / On second thoughts bu**er Germany and France...,     -- Chris:  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B58E7A4.356AEBC8@fsi.net...  > "Dr. Otto Titze" wrote:n > >  > > Hamlyn,d > >" > > concerning your remark > >lH > > > When you increased GBLPAGFIL, did you do a WRITE ACTIVE in sysgen?G > > > If you did, then it DID increase it.  This parameter (at least ons 7.2-1)L > > > is a dynamic parameter and does not require a reboot.  If you do a USEC > > > ACTIVE in sysgen, then SHOW GBLPAGFIL, what does it show now?- > >-. > > Under VMS V6.2 the GBLPFIL is not DYNAMIC. >m/ > YEAH! Tell me 'bout it! THAT one bit ME, too!R >O > -- > David J. Dachtera5 > dba DJE Systems. > http://www.djesys.com/ >0< > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/t > H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. >CB > Feel free to exercise your rights of free speech and expression. >iH > However, attacks against individual posters, or groups of posters, are > strongly discouraged.p   ------------------------------  % Date: Mon, 23 Jul 2001 21:55:12 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>1" Subject: Re: Your reply on GSDFULL' Message-ID: <3B5CE390.E240B9BC@fsi.net>A   Chris Townley wrote: > B > This prompted me to take a look at what is now DYNAMIC under 7.3 > Bleedin'bootiful!  > , > Can't of read the release notes very well! > I > Now got to get 3 production machines off 6.2, 4 off 7.2 plus France and); > Germany off 7.1  then I can move my development machines.9 > 1 > On second thoughts bu**er Germany and France...w  F Yecch! No, thank you! If I'm gonna piss anyone off, I'll just flip 'em	 the bird!o  @ Been to Deutschland(sp?) - very charming and steeped in history.  2 Never been to France - maybe one of these years...   -- c David J. Dachteral dba DJE Systems> http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/b  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.l   ------------------------------  # Date: Tue, 24 Jul 2001 04:42:46 GMT7. From: "mulp" <michaelpettengill@earthlink.net>$ Subject: Re: Zero Quadword Time PollE Message-ID: <a1777.9452$Px1.1089341@newsread2.prod.itd.earthlink.net>.  5 I'm not sure that I understand what the change is....e? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message(- news:0sJ57.1022$rc5.70029@news.cpqcorp.net... H >   One of the local engineers has suggested changing the interpretationG >   of a OpenVMS quadword time containing a zero from its existing to anF >   new interpretation; from an absolute time (17-Nov-1858) to a delta >   time ("now", basically).  8 What value would be used to represent no time specified?  H In the context of scheduling a timer event, 0 meaning 1858, has the same effect as NOW.@ Specifying 1970 would result in the timer going off NOW as well.   > F >   (Some folks here may remember seeing evidence of an existing tweakH >   within OpenVMS, a tweak that will convert a calculated delta of zero( >   into a delta of a very small value.)  K I seem to recall that a zero is converted to -1 when queuing a timer entry; J as I recall this was done so that when a driver queued a timer with a zeroC value inside a timer  callback it didn't result in a loop since theuH interface promised that the callback wouldn't occur until the next tick.   >:D >   Anybody here directly using a quadword zero as an absolute time? >   Supporters?  Detracters? >o/ As noted, its used to indicate "not specified".o  H For such a minor change, why even think about changing the behavior?  ItJ can't be to improve any code.  Is this to make $FAO time conversion called@ with a null pointer and a pointer to zero return the same thing?   ------------------------------  # Date: Tue, 24 Jul 2001 04:51:12 GMT . From: "mulp" <michaelpettengill@earthlink.net>$ Subject: Re: Zero Quadword Time PollE Message-ID: <49777.9459$Px1.1090670@newsread2.prod.itd.earthlink.net>   5 "Richard Brodie" <R.Brodie@rl.ac.uk> wrote in messages& news:9jhi7r$1m3k@newton.cc.rl.ac.uk...  > $ spawn/nolog/nosymb show statC >   Status on  23-JUL-2001 17:01:14.33     Elapsed CPU :17-NOV-1858e 00:00:00.00 H >   Buff. I/O :       28    Cur. ws. :   16384    Open files :         0H >   Dir. I/O :         0    Phys. Mem. :   976    Page Faults :       70  8 Converting 0 to none specified would work for the above:    > $ spawn/nolog/nosymb show statH >   Status on  23-JUL-2001 17:01:14.33     Elapsed CPU :<None specified>H >   Buff. I/O :       28    Cur. ws. :   16384    Open files :         0H >   Dir. I/O :         0    Phys. Mem. :   976    Page Faults :       70   ;-)y   ------------------------------  % Date: Tue, 24 Jul 2001 01:29:51 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>=$ Subject: Re: Zero Quadword Time Poll, Message-ID: <3B5D07BE.28982083@videotron.ca>   mulp wrote:c: > Converting 0 to none specified would work for the above: > " > > $ spawn/nolog/nosymb show statJ > >   Status on  23-JUL-2001 17:01:14.33     Elapsed CPU :<None specified>J > >   Buff. I/O :       28    Cur. ws. :   16384    Open files :         0J > >   Dir. I/O :         0    Phys. Mem. :   976    Page Faults :       70  M On the other hand, consider that much software may parse a date-time string ,lS extract the year, month, day etc, assuming the respective position of those fields.p  M In each case, this proposed change can be handled easily in programs. You can-K use various routines to extract individual fields of a binary date time andoN then do what is needed to be done. The problem is that this change might forceN anyone using dat-time values to check their programs to ensure that the change: would not affect them and if so, implement the simple fix.  @ The checking to see if the change will affect you is the "COST".( So, what is the benefit of that change ?   ------------------------------  % Date: Tue, 24 Jul 2001 07:26:45 +0200a  From: Paul Sture <paul@sture.ch>$ Subject: Re: Zero Quadword Time Poll+ Message-ID: <VA.00000402.2d0a9ff3@sture.ch>n  C In article <tloiaaq4daeo67@news.supernews.com>, John Vottero wrote: < > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3B5B96B9.2469AE0A@videotron.ca... > > John Vottero wrote: M > > > I don't see the problem.  If you subtract zero from something, you windc > up > > > with the same thing. > >rN > > Subtract an absolute time from an absolute and you get a delta time. (now)N > > Subtract a delta time from an absolute and you get an absolute. (proposed) > >uI > Yes, you're right.  In this case, subtracting zero from a number shouldiL > change it's sign (to make it a delta time).  And that's what lib$sub_timesH > does.  However, sys$asctim refuses to format the result, it fails with > %SYSTEM-F-INVTIME. > = I've run into similar. A snippet of COBOL from VMS V6.2 days:M    *
  *   Add thema  *,       call 'lib$add_times' using      quad_1,                                       quad_21                                       quad_result>3                   giving              status_value.s"         if status_value is failure8             call 'lib$stop' using by value status_value. *w) *   Force the output date to delta formati *e         if quad_result >= 0o2             compute quad_result = quad_result * -1         end-if.g( *   display quad_result with conversion.2         call 'sys$asctim' using         result_len6                         by descriptor   add_result_val * 9 I can't remember whether the >= 0 there was deliberate orr just a > 0 would have done.i  G > This is all getting a little gray.  Doing things like subtracting thedJ > absolute time zero from the current time should return a delta time but,L > that violates the 10,000 day rule.  Was the 10,000 day rule eliminated for8 > the Unix time fix?  Or was the 10,000 value increased? >-? IIRC the 10,000 day bug was limited to things like Motif - i.e.h$ stuff originating from Unix systems.   [snip]   > >a) > > What benefit would the change bring ?s > 2 > I'm still wondering what the benefit is as well. >  Me too.w ___i
 Paul Sture Switzerland.   ------------------------------    Date: 23 Jul 2001 19:28:03 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)> Subject: RE: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ?* Message-ID: <3b5c5ea3$1@news.kapsch.co.at>   So, my current plan is:   K 1) run with the currently good 2nd HSJ with WRITEBACK_CACHE units (4x RAID,i 	4x MIRROR) as beforee  I 2) Look for used/new good cache batteries for HSJ40 on the retail market.t@ 	(this is likely difficult, because the batteries dies much more6 	often than the HSJ - we have now the 4th set of them)  I 3) If 2nd cache battery dies before replacement parts are available here,AG 	change both HSJ to CACHE_UPS (because the cluster is really on an UPS)6  
 Thanks folks.u   -- u< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888p< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------    Date: 23 Jul 2001 13:58:25 -0500+ From: young_r@encompasserve.org (Rob Young)T> Subject: RE: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ?3 Message-ID: <GeoCwOyjFPtF@eisner.encompasserve.org>   W In article <3b5c5ea3$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes:c > So, my current plan is:i > M > 1) run with the currently good 2nd HSJ with WRITEBACK_CACHE units (4x RAID,x > 	4x MIRROR) as beforet > K > 2) Look for used/new good cache batteries for HSJ40 on the retail market. B > 	(this is likely difficult, because the batteries dies much more8 > 	often than the HSJ - we have now the 4th set of them) > K > 3) If 2nd cache battery dies before replacement parts are available here,sI > 	change both HSJ to CACHE_UPS (because the cluster is really on an UPS)- >   A 	But I am never excited about depending on a dependable UPS.  YouFE 	have dual power supplies?  That is better.  I wouldn't do it withoutrF 	dual power supplies.  Separate Lieberts, (room power supplies/circuitD 	panels)?   Power supplies plugged into separate Lieberts?  Second, ; 	"what if" your datacenter UPS with battery backup takes a C9 	dive?  Can't happen?  I've seen it happen.  Can't happenaF 	to you?  The room the UPS is in gets flooded, some other major event,> 	etc. you have very big problems that could *easily* have been	 	avoided.o  H 	Here is what I would do (As I was nearly *toasted*.  If it *wasn't* forA 	cache batteries, I would have been) ... I would press for *two* sA 	UPSes (about $500 U.S. each)  and plug HSJs into them.  The HSJ eD 	batteries were/are in a sense your first line UPS just in case the H 	datacenter UPS tanks.  Thus, you are replacing your first line UPS and @ 	may be cost effective and a lot less of a hassle than replacing3 	HSJ batteries.  Keep everyone away from the UPSes.D= 	Tape the plugs into the back of the UPSes or whatever other e@ 	measure to ensure "hands off at all costs."  Otherwise, I would@ 	strongly advise that you replace the batteries if not going the 	"HSJ UPS route."V   				Rob    ------------------------------  # Date: Mon, 23 Jul 2001 18:08:29 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)0 Subject: Re: [TCPIP V5.1] Still no TFTP client ?3 Message-ID: <xKZ67.1111$rc5.72831@news.cpqcorp.net>3  W In article <3b558de9$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: B :Is this correct that the TCPIP V5.1 package still doesn't contain :a TFTP client ?  G   I can't say I've seen very many requests for a tftp client, but I do c   know that one is available:I  M     http://www.openvms.compaq.com/freeware/freeware50/vouters/TFTP_CLIENT.TXTr  B   Typical tools (ftp, COPY/FTP, etc) obviously use the ftp client.  C   As I am sure you are aware, tftp and bootp servers are available.h  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   End of INFO-VAX 2001.407 ************************