1 INFO-VAX	Sat, 01 Jul 2000	Volume 2000 : Issue 365       Contents: Re: Backup and Restore for VMS& Re: Compaq paying for software ports ?4 Re: Compaq Viewed As a PC-Only Company By Analysts ?4 Re: Compaq Viewed As a PC-Only Company By Analysts ?0 DECevent startup unproperly redefines sys$output4 Re: DECevent startup unproperly redefines sys$output4 Re: DECevent startup unproperly redefines sys$output Re: DSP3210's on HSJ30?  Re: DSP3210's on HSJ30? & Re: good news (for me,  I think) . . .& Re: good news (for me,  I think) . . .& Re: good news (for me,  I think) . . .& Re: good news (for me,  I think) . . .0 Re: Loss of functionality UCX V4.1-->TCPIP V5.0A7 Re: Northern Light vs. Google (and the winner is . . .) 7 Re: Northern Light vs. Google (and the winner is . . .) . Re: OpenVMS clusters vs other systems clusters2 Re: OpenVMS loses big, was:  RE: Compaq advertises2 Re: OpenVMS loses big, was:  RE: Compaq advertises2 Re: OpenVMS loses big, was:  RE: Compaq advertises Re: OT: "Open Windows" Re: Sub-DS10 Alpha& Re: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel) Re: VAX on Intel?   F ----------------------------------------------------------------------  % Date: Sat, 01 Jul 2000 00:35:38 -0400 * From: David A Froble <davef@tsoft-inc.com>' Subject: Re: Backup and Restore for VMS - Message-ID: <395D751A.3A5D40EF@tsoft-inc.com>    scott a meister wrote: >  > HiH > I have a system that is a Microvax II with one RD54 disk drive. I am a' > new user to VMS. My question is this. F > I need to write two scripts for doing a simple backup and also for a6 > restore. The person who knew the system is no longerK > working here.  The tape media is a TK50.  There is no data on this drive, 5 > only  VMS and some programs.  We have thought about D > getting another system and building a duplicate disk for emergencyA > purposes. Any info on writing these scripts or info to good VMS  > docs would be appreciated.
 > Thank  you.   N You need docs.  They're on-line on the Compaq web site.  Also, you need to get6 the FAQ.  But, to specifically answer the question ...  N The following file, named BACKUP.COM, assumes a privilidged user account namedO BACKUP.  Replace device names and logicals with whatever is appropriate on your  system.    $! Nightly backup command file $ M $ submit /after="TOMORROW+4:00" /user=BACKUP /log=[BACKUP] [BACKUP]BACKUP.COM  $ = $! TAPE := MKA400:  (place the device name of your TK50 here)  $  $! init 'TAPE' BACKUP  $! mount/foreign 'TAPE'  $ 
 $ set NOON $  $ DISK0:8 $ backup/image/noalias/ignore=(LABEL,INTERLOCK) DISK0: -          TAPE:DISK0.BCK /save_set $  $ dismount 'TAPE'  $  $ EXIT   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Sat, 01 Jul 2000 17:28:25 +0100 % From: Alan Greig <a.greig@virgin.net> / Subject: Re: Compaq paying for software ports ? * Message-ID: <395E1C28.545AED46@virgin.net>   Wayne Sewell wrote: H When I heard the term, I kinda guessed this was the meaning.  Only I was  N > thinking of "Section 8" from the U.S. military.  To quote Private Joker fromQ > Full Metal Jacket: "Leonard talks to his rifle.  I don't think Leonard can hack N > it any more.  I think Leonard is a Section 8."  Since Leonard (also known asQ > Private Pyle) then went on to shoot the drill instructor and himself, Joker was  > probably right.  :-) >   V Andrew's just forgotten that true visionaries are often called crazy at first. There'sW perhaps an OS revolution coming and the Sun is no longer at the centre of the Universe.    No wonder he's a bit upset.  :) --
 Alan Greig   ------------------------------  $ Date: Sat, 1 Jul 2000 03:47:55 -0400' From: "Bill Todd" <billtodd@foo.mv.com> = Subject: Re: Compaq Viewed As a PC-Only Company By Analysts ? ( Message-ID: <8jk7l9$j66$1@pyrite.mv.net>  K Well, Heil's 'interoperability' statement certainly caught my eye, given my E interest in things like Linux-friendliness and heterogeneous SAN file I systems.  Too bad the statement only referred to interoperability between J Win2K and Unix (which stood out especially, given that the article started# out talking about *VMS* viability).   K (Also too bad about what I assume was a typo stating that the worldwide VMS J customer base was 40K systems - not exactly as reassuring to a prospectiveL purchaser as 400K.  Or possibly that number counted each cluster as a single
 system...)  C Wasn't exactly reassured by Heil's statement that "Tru64 Unix is an J important growth engine for the company in the enterprise space", plus theH unveiling of the 37 new Tru64 ISVs:  where is the comparable support for VMS?  L And the juxtaposition 'Walker says he is pleased with Compaq's clarificationG of its Alpha and OpenVMS strategy.  Compaq is "really putting its money I where its mouth is with Alpha and Tru64", he says' was equally disturbing ! for what it didn't say about VMS.   I The $100 million promised last year for Tru64 has once again morphed into I 'marketing *and development*', though the original statement said nothing K about development (save for encouragement of third-party activity) - but it I still highlights the fact that Tru64 at least got *something* and VMS did  not.  I In sum, I think there's a fair amount for the Tru64 folks to like in this G article, but not too much for VMS (except for reinforcing the idea that F Compaq is no longer actively trying to kill VMS - which, while it's an> important message to get out there, is not exactly inspiring).   - bill  4 Main, Kerry <Kerry.Main@compaq.com> wrote in messageD news:910612C07BCAD1119AF40000F86AF0D8052844CA@kaoexc4.kao.dec.com... > K > In case there is any doubt that Compaq intends to aggressively attack the H > enterprise market (course, I define enterprise as any environment with moreL > than 25 users, but thats another debate :-)), check out this press review: > ( > http://www.vnunet.com/Analysis/1102826 > J > "Claiming that Compaq's inherited OpenVMS operating system {OS} customerI > base is growing, Heil said the OS is one of the most important customer E > sectors the company has. He also confirmed that Compaq would not be  looking E > to migrate OpenVMS customers to Windows NT/2000 in the near future, I > contradicting the vendor's claims in the days of former chief executive 6 > Eckhard Pfeiffer that it would be an NT juggernaut." > H > "Although analysts such as Gartner have questioned Compaq's enterpriseJ > strategy and the longevity of the technologies it inherited from Digital inH > 1998, the recent launch of its GS Wildfire series of Alpha servers andL > upgrades to OpenVMS is helping the vendor turn the negative opinion tide." > ! > And opportunities for partners:  > G > "Bill Heil, vice president of Compaq's business critical server group I > {BCSG}, said at the vendor's recent Compaq Technology Symposium: "We're F > still transforming Compaq from a PC company into an internet access,F > internet appliance company, and we'll do all that through partners." > A > "Compaq and its resellers should focus their high-availability, B > fault-tolerant, transaction and storage strategy on building theJ > infrastructure for the present and future ebusiness economy, said Heil." > I > "Mike Cohen, group sales director of former DEC and now Compaq reseller  CSF,K > says the announcement is long overdue. "CSF is also delighted in Compaq's K > investment in marketing and development for Alpha and OpenVMS. It's great  > news for the market."  > J > Like others from Compaq have said in other postings - times are changing and  > OpenVMS is back. > H > Still lots of work to do (marketing is improving and pricing is always under B > review), but, imho, is definately moving in the right direction. >  > :-)  >  > Kerry Main > Senior Consultant, > Compaq Canada  > Professional Services  > Voice : 613-592-4660 > FAX   : 819-772-7036 > Email : kerry.main@compaq.com    ------------------------------  $ Date: Sat, 1 Jul 2000 01:01:07 -0700* From: "Nikita V. Belenki" <kit@nospam.net>= Subject: Re: Compaq Viewed As a PC-Only Company By Analysts ? 8 Message-ID: <QBh75.960$0x.29664@nuq-read.news.verio.net>  A "Jerry Leslie" <LESLIE@209-16-45-102.insync.net> wrote in message " news:by075.1010$5L3.5335@insync...  K >    As the second quarter comes to an end, analysts are still at odds over I >    the financial and strategic health of personal computer maker Compaq  >    Computer.J >    Today, Salomon Smith Barney analyst Richard Gardner downgraded CompaqH >    to "neutral" from "buy" and cut the company's near-term share priceI >    target to $25 from $45. Gardner cited perceived weakness in PC sales  >    for the downgrade."F > There's NO mention of Compaq's non-PC products and services, such as Tru64, > OpenVMS, et.al.   + What? Compaq losing its money on them, too?   > > The analysts should be made aware of the existence of non-PCJ > products and services, and their percentage of the total Compaq revenue.G > This article sounds like they're only aware of the PC side of Compaq.   I Yes. But when you say "gambler" you usually don't speak about the way the  person *earns* the money ;)    Kit. kit # kits.net   ------------------------------  $ Date: Sat, 1 Jul 2000 10:05:50 +0200> From: "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr>9 Subject: DECevent startup unproperly redefines sys$output 3 Message-ID: <8jk8ul$2l6i$1@s2.feed.news.oleane.net>    Bonjour  tous !  J I'm using STARTUP_P2 to redirect startup output to sys$system:STARTUP.LOG,K along with OPC$OPA0_ENABLE to FALSE, to have minimum output on the console, E giving a simple visual way to check the correct startup of the system J (only 15 lines should appear on the console). The startup.log file is then* searched for errors to mail me any errors.  E When DECevent is started, I still outputs information on the console, K because of sys$output redirections in the procedure. My guess is that it is K done because the programmer didn't whant to check if P1 ... P8 where empty.  This is done twice.   H The redefinition of sys$output should not be done by a system procedure,E because any output of the procedure after the deassign is lost on the I console, instead of beeing logged to the STARTUP.LOG file. Maybe it could  be corrected for 7.3 ?   Cordialement   Jean-Franois Marchal  X9000 - LYON (FR)    ------------------------------  $ Date: Sat, 1 Jul 2000 11:53:33 +0200, From: "Bart Zorn" <B.Zorn@TrueBit.nospam.nl>= Subject: Re: DECevent startup unproperly redefines sys$output + Message-ID: <8jkf4e$1se0$1@buty.wanadoo.nl>    Ah.. DECevent...  G Unfortunately, DECevent was developed by people who don't know anything H about OpenVMS, at least, they don't know anything about what we considerD normal. For instance, in the documentation there is a chapter in theI documentation. It has a big header "Cluster Support". The content of this ? chapter boils down to "there is absolutely no cluster support"!   K You could submit the startup of DECevent in a batch job and include the log ' file in your search for error messages.   I But there is light at the end of the tunnel. DECevent will be replaced by  Compaq Analyze (aka CA :-)0 Unfortunately that light is anything but bright!  	 Bart Zorn  OpenVMS consultant TrueBit B.V.  I "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> wrote in message - news:8jk8ul$2l6i$1@s2.feed.news.oleane.net...  > Bonjour  tous ! > L > I'm using STARTUP_P2 to redirect startup output to sys$system:STARTUP.LOG,D > along with OPC$OPA0_ENABLE to FALSE, to have minimum output on the console,G > giving a simple visual way to check the correct startup of the system L > (only 15 lines should appear on the console). The startup.log file is then, > searched for errors to mail me any errors. > G > When DECevent is started, I still outputs information on the console, J > because of sys$output redirections in the procedure. My guess is that it isF > done because the programmer didn't whant to check if P1 ... P8 where empty. > This is done twice.  > J > The redefinition of sys$output should not be done by a system procedure,G > because any output of the procedure after the deassign is lost on the K > console, instead of beeing logged to the STARTUP.LOG file. Maybe it could  > be corrected for 7.3 ? >  > Cordialement >  > Jean-Franois Marchal  > X9000 - LYON (FR)  >  >    ------------------------------   Date: 1 Jul 2000 11:43:10 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) = Subject: Re: DECevent startup unproperly redefines sys$output + Message-ID: <Nags0mq8zfxI@eisner.decus.org>   t In article <8jk8ul$2l6i$1@s2.feed.news.oleane.net>, "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> writes:  J > The redefinition of sys$output should not be done by a system procedure,G > because any output of the procedure after the deassign is lost on the K > console, instead of beeing logged to the STARTUP.LOG file. Maybe it could  > be corrected for 7.3 ?  > For $40 US you can get a copy of the V7.3 "SDK" this month andC verify for yourself if they have fixed it.  If not, please complain @ in the newsgroup set up for that purpose, so they can fix it for
 everybody.   ------------------------------  % Date: Fri, 30 Jun 2000 22:56:08 -0400 * From: David A Froble <davef@tsoft-inc.com>  Subject: Re: DSP3210's on HSJ30?- Message-ID: <395D5DC8.4F892ACB@tsoft-inc.com>    Jack Ziegler wrote:  >  > Hello, > L > We have some old DSP3210 2 GB disks that (I believe) are early versions ofK > RZ28's.  My question is whether anybody is successfully using these disks H > on an HSJ30.  They don't appear on the supported device list for HSOF; > RZ28 does. > & > Thanks for any help you can provide. > # > Jack Ziegler                    | @ > Information Technology          | internet: ziegler@sonoma.edu; > Sonoma State University         | phone   : (707)664-3098 ; > Rohnert Park, CA 94928          | FAX     : (707)664-2505   P Back before BP sold off another decent division of DEC, they were making some ofK the best disks on the market. Internally DEC sold the drives as RZ26, RZ28, L etc.  For OEM sales the very same drives were sold as DSP drives, and widely used.    DSP3105 - early RZ26 1.05 GBN DSP3107 - later, lower profile, possibly better performance, RZ26L (I believe) with 1.07 GBF DSP3160 - Not offered as RZ, 1.6 GB drive, and used for DSSI I believe DSP3210 - RZ28, 2.1 GB  H I have used these drives very successfully on VAXstations, MicroVAX 3100M systems, and AlphaStation 200s.  This is a rather generic usage, and not very ? demanding.  More complex storage systems may be more demanding.   M Note that the RZ drives report as RZ drives, and the DSP drives report as DSP N drives, so there is at least that difference in the stuff loaded on the disk. N There could be other differences that might affect usage in a particular area,N such as the HSJ30.  Not saying there is, saying I don't know.  If you can takeP the chance, try them.  If data is critical, why are you considering anything but certified for VMS drives?   I If I had to guess, some of the gotchas in some drives, such as inadequate O implementation of tag-queueing and such are the same, and the drives will work.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Sat, 01 Jul 2000 12:48:56 GMT / From: StevenU@POBoxes.com (Steven P. Underwood)   Subject: Re: DSP3210's on HSJ30?1 Message-ID: <395de656.35214215@news.telocity.com>   C At work, we have a DEC 3000-400S at work that came installed from a F reseller with a DSP3160 as a data drive.  This machine is 7/24 runningB our manufacturing database (Oracle 7.3), until mid-july when I canF install our new ES40.  Then it takes on a reduced role of only a small part of the database.   F It is still working with no problems except that since the Compaction,E every time I have to renew my contract, Compaq can not figure out how E to cover it.  They finally just changed it on the contract to an RZ28a7 ("since that is what we would replace it with anyway").l   Stevee  2 On Fri, 30 Jun 2000 22:56:08 -0400, David A Froble <davef@tsoft-inc.com> wrote:   >Jack Ziegler wrote: >> t	 >> Hello,p >> lM >> We have some old DSP3210 2 GB disks that (I believe) are early versions ofeL >> RZ28's.  My question is whether anybody is successfully using these disksI >> on an HSJ30.  They don't appear on the supported device list for HSOF; 
 >> RZ28 does.  >> o' >> Thanks for any help you can provide.s >> u$ >> Jack Ziegler                    |A >> Information Technology          | internet: ziegler@sonoma.edun< >> Sonoma State University         | phone   : (707)664-3098< >> Rohnert Park, CA 94928          | FAX     : (707)664-2505 >CQ >Back before BP sold off another decent division of DEC, they were making some ofoL >the best disks on the market. Internally DEC sold the drives as RZ26, RZ28,M >etc.  For OEM sales the very same drives were sold as DSP drives, and widelye >used. >  >DSP3105 - early RZ26 1.05 GB-O >DSP3107 - later, lower profile, possibly better performance, RZ26L (I believe):
 >with 1.07 GBrG >DSP3160 - Not offered as RZ, 1.6 GB drive, and used for DSSI I believe  >DSP3210 - RZ28, 2.1 GB5 >1I >I have used these drives very successfully on VAXstations, MicroVAX 3100sN >systems, and AlphaStation 200s.  This is a rather generic usage, and not very@ >demanding.  More complex storage systems may be more demanding. >pN >Note that the RZ drives report as RZ drives, and the DSP drives report as DSPO >drives, so there is at least that difference in the stuff loaded on the disk.  O >There could be other differences that might affect usage in a particular area,dO >such as the HSJ30.  Not saying there is, saying I don't know.  If you can takecQ >the chance, try them.  If data is critical, why are you considering anything butd >certified for VMS drives? >CJ >If I had to guess, some of the gotchas in some drives, such as inadequateP >implementation of tag-queueing and such are the same, and the drives will work. >r >Davet >m >-- 5 >David Froble                       Tel: 724-529-0450i5 >Dave Froble Enterprises, Inc.      Fax: 724-529-0596o? >DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com=7 >T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486a   Steven P. Underwood,DNRC Whitinsville,MA! StevenU@POBoxes.com    ------------------------------  $ Date: Sat, 1 Jul 2000 03:39:14 -0400' From: "Bill Todd" <billtodd@foo.mv.com> / Subject: Re: good news (for me,  I think) . . .A( Message-ID: <8jk751$iuh$1@pyrite.mv.net>  > Larry D Bohan, Jr <LBohan@dbc.spam_less..com> wrote in message, news:bR9dOXz1OqTZ+rkt4V11=li5u+sk@4ax.com...G > On Fri, 30 Jun 2000 17:54:32 -0400, "Bill Todd" <billtodd@foo.mv.com>a > wrote:   ...   / I tried to convince DEC to port an enhanced RMSa$ > >to Windows and Unix 14 years ago. > >GK > >But Unix already has some fairly standard mechanisms for this (C-ISAM is  > >one). >3? > It'd been a while for me, but are such facilities part of thed9 > 'least common denominator" Unix nowadays, or is there as7 > 3rd party product that almost everyone tends to use:?   J This is not an area I'm familiar with either, so someone else will have toH fill in details.  But I don't think anything normally ships with variousJ Unix variants - just that there are at least a few things like C-ISAM thatB are fairly commonly used when one wants record-oriented operation.   > F > >And one should remember that files in a directory can support usageD > >that an RMS indexed file has trouble with - e.g., variable-length entities" > >that may grow moderately large. > >e	 > >- bills >  > yah,  tongue in cheek: >-B > when your only major tools are  the C RTL open/close/read/write,2 > everything starts to look like a file system ...  I And for the things that fit in well with looking like a file system, that@G works well - and probably better than trying to stuff large and/or verygI variable-length entities into an RMS indexed file where they'd have to begE broken up (non-transparently, at least internally to the application)rI whenever their size exceeded the bucket size and where size changes couldtD precipitate significant bucket split/coalesce activity (assuming RMSA coalesces at all during normal operation - it's been a while...).    >t7 > I remember though, seeing somewhere a cogent argumenta? > *against*  Unix's paradigm of "..everything-is-like-a-file.."   I It's easy to argue against the paradigm that *everything* is like a file,aJ because many things transparently are not.  That's what something like RMSJ is for.  But for the things that *are* like a file, the file system shouldF do a good job of organizing them - even in occasionally large numbers.   >s9 > something along the lines of, that it was too simple anV, > abstraction.   Was it security/ACL issues?  K Possibly the argument was that files are too heavy-weight for many purposes L (what with the size overhead of timestamps, access controls, etc., the speedF overhead of maintaining the timestamps and controlling access, and theH overhead of having an index file entry with a permanently-reserved 'fileL ID' - though ISTR that ODS-2 doesn't guarantee FID uniqueness as strongly asH RSX did, so that last may not be as much of an issue).  That's certainlyJ true when you start trying to use them for things like fine-grained object management.e  J But it would be kind of neat to have a file system that optionally allowedJ light-weight leaf (non-directory) nodes (with access controlled by the ACLD of the parent directory) to extend its range into at least some suchK applications - another instance of using a hierarchy seen as homogeneous by.L the user but implemented differently at different levels (as is already trueK for things like the split between levels handled by network directories andnF levels handled by local file systems in environments such as OSF DCE).   - bill   >e4 > Being able to  (optionally) make such abstractionsH > on VMS (at least fom the C RTL) would be a further help for unix ports > ...e   ------------------------------  % Date: Fri, 30 Jun 2000 23:08:32 -0400t* From: David A Froble <davef@tsoft-inc.com>/ Subject: Re: good news (for me,  I think) . . .V- Message-ID: <395D60B0.2A79A5CE@tsoft-inc.com>u   Bill Todd wrote: > @ > Larry D Bohan, Jr <LBohan@dbc.spam_less..com> wrote in message. > news:o6NcOf3JTm7wviPyzoM4VXOCojO4@4ax.com... >  > ...o > 3 > > in the unix world, it seems common to abuse thee/ > > file system for use as a catalogue/library.o > M > Or one could take the viewpoint that in the Unix world, it's common to takesK > advantage of the file system for use as a catalogue/library (in ways thatt > VMS doesn't support as well).   K Not disagreeing with anything you are saying.  However, I find this type ofbJ activity to be a serious lack of good planning, design, and organization. P There's lots of things in this world that 'work', but working with them can be a real nightmare.s  I > Web pages are one good example:  zillions of smallish entities that are K > hierarchically addressed (due to the format of a URL - can that be wholly-M > coincidental?).  Of course, you *can* buy a full-fledged database to handlerL > them, but having a file system that can do the job (and VMS probably isn'tK > all that bad at this particular one, either) certainly would seem to haven > value. > M > Human beings find operations they're used to convenient (and to some degree J > comforting).  Homogeneous hierarchies are popular for this reason.  It'sM > certainly possible to camouflage heterogeneous implementations at differentnH > levels of the hierarchy, such that some levels are handled in the fileB > system and others within individual, structured files, but sinceK > *developers* also appreciate the convenience and comfort of a homogeneousnN > environment, having a file system versatile enough to handle the entire tree > has value. >  > - bill  N If you step back (far enough) and look at an on-disk file system, it's nothingM more than structures put in place to enable easier and well ordered access ofmM disk storage.  There's not really a hugh difference between file entries in a@K directory, and records in a file.  But, the structures were developed for awK need, and when used appropriately, work well.  When abused, well, abuse in,a
 abuse out.  M Some of the stuff I see that's just thrown together without some planning andtM organization reminds me a bit of building a tunnel, starting from both sides, O without a survey.  They of course miss each other, and then weave around insidedP the mountain until they run into each other.  Yeah, you can get from one side to& the other, but using the tunnel sucks.  N Maybe I'm just too organized (not likely, if you could see my desk) and have a hard time with chaos.p   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 1 Jul 2000 12:03:19 -0400 4 From: "Robert Deininger" <rdeininger@mindspring.com>/ Subject: Re: good news (for me,  I think) . . .-* Message-ID: <B5838E89-54D36@165.247.31.53>  C On Sat, Jul 1, 2000 3:39 AM, Bill Todd <billtodd@foo.mv.com> wrote:rK >But it would be kind of neat to have a file system that optionally allowedeK >light-weight leaf (non-directory) nodes (with access controlled by the ACL E >of the parent directory) to extend its range into at least some such  >applications   C Interesting idea.  Maybe there could be some flag set for an empty sI directory file, which would cause all the files created in that directorys toF "light".  But the file header itself would have to have enough info toH mark the file as light-weight, since a lot of file access is by FID, notH via directory.  There would need to be special care around aliases, etc.  G Maybe this would be significantly easier on a volume-wide basis, rathert than directory-wide.  E Could any of those add-on unixy file systems be ported to work on VMSl$ with foreign-mounted disk volumes?   ---------------------------c Robert Deininger rdeininger@mindspring.coms   ------------------------------  $ Date: Sat, 1 Jul 2000 13:30:55 -0400' From: "Bill Todd" <billtodd@foo.mv.com>e/ Subject: Re: good news (for me,  I think) . . .-( Message-ID: <8jl9qf$n73$1@pyrite.mv.net>  = Robert Deininger <rdeininger@mindspring.com> wrote in messagen$ news:B5838E89-54D36@165.247.31.53...E > On Sat, Jul 1, 2000 3:39 AM, Bill Todd <billtodd@foo.mv.com> wrote:lE > >But it would be kind of neat to have a file system that optionallyl allowed'I > >light-weight leaf (non-directory) nodes (with access controlled by theh ACL G > >of the parent directory) to extend its range into at least some suchn > >applicationso >ID > Interesting idea.  Maybe there could be some flag set for an emptyK > directory file, which would cause all the files created in that directorye > to
 > "light".  L That would avoid the need to extend the programming interface to support theF concept of creating a light-weight file directly.  But there's also noK particular reason light-weight files couldn't share a directory with normalbK files (it might be possible to create minor user confusion by doing so, buthF that's something for the application to weigh rather than for the file system to enforce arbitrarily).   >   But the file header itself would have to have enough info toJ > mark the file as light-weight, since a lot of file access is by FID, notJ > via directory.  There would need to be special care around aliases, etc.  E If a light-weight file had no access control (depending on the parent I directory to control access), then it couldn't be accessed by FID (unlessyL there was a back-pointer to the parent directory so that the access could beK validated there).  And since a light-weight file tends by nature to be parttG of some kind of group, individual by-FID access may be of less interest  anyway.   J By-FID access has two virtues:  it provides a fast, direct path to a file,J and it supports multiple directory paths to a file in an effective manner.I But supporting those features has file system design costs, one major oneSF being the inability to scan the attributes of the files in a directoryK efficiently, since there's no way to allocate file headers in such a way as-C to guarantee that the files in a directory will occupy a reasonablyg" contiguous area of the Index File.  F You can get around this (in a new design) by compromising the absoluteI performance of by-FID access with an additional level of indirection (and$J assuming that multiply-linked files are rare), but that entails (at least)L additional create/delete overheads.  So the question I have is:  would it beK reasonable for a new file system design to support by-FID access only on an H as-needed basis - when multiple paths are created or when FID support is3 explicitly requested for a file by the application?   L Or to put it another way, just how often do applications actually use by-FIDK access explicitly (not counting by-DID access to directories, since one cant treat them separately)?    >rI > Maybe this would be significantly easier on a volume-wide basis, rather: > than directory-wide. > G > Could any of those add-on unixy file systems be ported to work on VMSD$ > with foreign-mounted disk volumes?  K Don't see why not:  many VMS applications seem to be able to deal (at least B most of the time) with accessing files in other (Unix and Windows)H environments via the network, so they shouldn't have any more difficulty doing so locally.p  J But would there really be much use of such support, save in the occasionalJ case where one wished to import an entire volume?  Granting that there areH some performance advantages that VMS's native environment lacks, I'm notK sure they're sufficiently attractive to get applications to forsake having,7J e.g., a cluster-wide file system (which is why I keep saying that what VMSF *really* needs is a heterogeneous SAN/cluster-style file system it can *share* with Windows and Unix).    - bill   > ---------------------------d > Robert Deininger > rdeininger@mindspring.coma >  >6 >0   ------------------------------   Date: 1 Jul 2000 11:47:01 GMTR& From: Cthulhu <cthulhu@kadath.deep.it>9 Subject: Re: Loss of functionality UCX V4.1-->TCPIP V5.0Ae( Message-ID: <8jklnl$ha$1@kadath.deep.it>  + Peter LANGSTOEGER <eplan@kapsch.net> wrote:M  E > It's called PTRV50A-05_VAX7.BCK and PTRV50A-05_AXP7.BCK and is onlys > available via Qservice.n  D I don't rember if I already asked this, but: is there a valid reason. to not make that patch avaliable to hobbyists?  
 	patching,
 	  Cthulhu   -- e  G        Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it wgah'nagl fhtgan!l% 		       <cthulhu at flashnet dot it>t   ------------------------------  % Date: Fri, 30 Jun 2000 23:30:06 -0400n* From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: Northern Light vs. Google (and the winner is . . .)- Message-ID: <395D65BE.4797680D@tsoft-inc.com>    Tim Llewellyn wrote: > U > David A Froble wrote: Now my shop is not what you'd call large.  Tiny is a start ine > the proper > S > > direction.  I do not use any tape devices.  Never trusted them as much as disk,eS > > but acknowledged the necessity of backups.  However, with about 20 African GrayEJ > > parrots sharing the same building as some of my systems, the amount ofL > > ultra-fine dust from the birds is rather large, and a tape drive in that8 > > environment is lucky to last a month.  I have proof! > S > Well, if you don't insist on separate, environmentally controlled environment forr > your servers...0  L Well, ya gotta remember, I'm pretty much doing software development, and notO much else.  All my systems are what are defined as office environment systems. lM Yeah, the air conditioned big plate glass data center is nice, but I'd rather I spend my extra cash on aircraft, not a (rather expensive) building.  I amsK working on a new office building, and it will be quite a bit cleaner.  Hey,oL someone's gotta perform the enviromental tests on this equipment.  I can say- what many know, DEC hardware is pretty tough.    > >eT > > My solution, since I have systems in multiple buildings, is to have several withR > > a large (for me) disk dedicated solely to 3 versions of image backups from allR > > in-use disks on all in-use systems.  I'm safe from a system/disk failure.  I'mR > > safe if a single building is lost.  No, I do not have off-site storage of dataS > > in a vault 2 miles underground.  I don't need that level of backup.  Every site S > > has to have some limit to their recovery capability.  I also have the save-sets Q > > on-line and have on multiple occasions extracted data from one when I perform O > > another of my many screw-ups.  No tapes, and I'm reasonably well protected.| > >  > R > David, I am interested, how do you do a system disk restore like this? Boot intoQ > a cluster temporarily as a satellite and restore the image backup of the systems > disk?2T > For that you need cluster licences, and I do I think rememeber you saying you have
 > no cluster.1  L No cluster, but everything is on the network.  Some time back we were saying "the network is the system".  P Never had to do so, at least because of disk failures.  But, if I should finallyN lose a disk, I just go to one of the systems with the backup save-sets, pull aN spare disk off the shelf, put it in the system, and restore the image saveset.N (Or any of my systems, since the save-set can be restored from a remote DECnetP node.)  Then move that disk to the affected system, and I'm bact to the point ofK the image backup.  Now, this manual procedure may not be for everyone.  I'mlK rather well acquainted with digging around inside the systems, and changinggM disks isn't too big a problem.  An extra 10 minutes or so.  But, refer to thenO first sentence of this paragraph, and you'll see that I'm not too inconvienced,y and I am protected.n   Dave   -- i4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Fri, 30 Jun 2000 23:41:58 -04004* From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: Northern Light vs. Google (and the winner is . . .)- Message-ID: <395D6886.3F1E09AE@tsoft-inc.com>,   Tim Shoppa wrote:! >  > Bill Todd wrote:# > > while it was rather frustratingaI > > to see Aaron continue the string of faulty interpretations that I had & > > already responded to several times > @ > You might consider, Bill, that if so many folks interpret whatE > you're trying to say incorrectly, that perhaps the problem was that45 > you expressed yourself in a less than clear manner?-  K On this point, I'm hoping to convince Bill to maybe set some standards. :-)c  E > As a related but tangential point, consider that if you have a farmGF > of ten thousand IDE drives, you currently need 2500 or 5000 PC-cloneA > motherboards to drive them due to IDE cable length limitations.l= > So if you're all hot to use the cheapest IDE drives in your G > big-storage system, you don't have a lot of choice but to use a large ? > number of PC-clones attended to by a large number of flunkiesiC > to maintain them.  Is it possible that this is one of the reasonspC > why Google has so many PC-clones and staff to maintain them, thatiB > they didn't have any other choice given that they were committed! > to lowest-end storage hardware?o  I Sorry, can't let you get away with that one.  First remember that Bill isSN suggesting a new method for doing something, recognizing the absurd size disksO are growing to.  So it doesn't have to be limited to todays widgets.  Suppose ayI new device, that supports some rather large number of IDE interfaces, andaH addresses whatever issues there are for supporting a large number of IDEO drives.  Doesn't exist today, as far as I know, but not something impossible toi design and build.n  J For example, crude SCSI implementations only support 7 drives on one bus. M Talking narrow SCSI here.  But we have devices now that have large numbers ofr! drives on one SCSI bus and/or ID.b  L So having decided that there are multiple methods of doing things, I'll fallO back a bit and say that if people are looking for such an environment, it's noteM unreasonable for them to pay a bit more for SCSI disks, cause they're not tooaK expensive either these days.  Flipping back to the other side again, 10,000sI drives?  Might be enough price difference there to create an incentive to  developing the IDE device.   Dave   -- w4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Sat, 01 Jul 2000 16:08:59 GMTg% From: jlsue <jlsuexxxz@dialupnet.com>h7 Subject: Re: OpenVMS clusters vs other systems clusterse8 Message-ID: <5b5sls44acr7o69v0j74u0gd6c9e3tvf9p@4ax.com>  / On Thu, 29 Jun 2000 12:58:38 +0100, Nigel Arnott$ <sysmgr@maxwell.ph.kcl.ac.uk> wrote:     >tA >For once I find myself in almost complete agreement with Andrew.t >a; >The only marketing lies concerning unix that I encountereda? >emanated from Digital. If there ever was a conspiracy, it was t- >within the Digital Corporation, not outside.i >   D That wasn't my experience at all.  My experience, as someone working? *outside* of Digital, was that Unix vendors were making lots ofeC promises that they couldn't deliver in the business-critical world.e For several years, in fact.m  C I never mentioned anything about a conspiracy, someone else startedmD that FUD.  However, it is a fact of my work experience that I had to@ constantly fight against the Unix lies that they could deliver aC stable, quality product that had the reliability and scalability ofsF our VMSclusters.  Hell, they didn't even do "upgrades" back then - youD just wiped out your OS and re-installed fresh (though you could keepE your other file systems).  And don't forget, there was nothing like a-C "disaster-mode" disk restore from backups, if your system disk juste happened to flake-out on you.:  @ But the MGMs of the world were entranced by the headlines of the< press, and the bull coming out of the Gartners of the world,: forgetting that these are just self-fulfilling prophecies.1 Not speaking for anyone, certainly not DEC/Compaq - (get rid of the xxxx in my address to e-mail)s   ------------------------------  $ Date: Sat, 1 Jul 2000 02:31:54 -0700* From: "Nikita V. Belenki" <kit@nospam.net>; Subject: Re: OpenVMS loses big, was:  RE: Compaq advertisese8 Message-ID: <b2k75.973$0x.29770@nuq-read.news.verio.net>  7 "Rob Young" <young_r@eisner.decus.org> wrote in messagei% news:03aeLxDh6349@eisner.decus.org...i  @ > Let's shed a tear for the Netware bigots.  Got a few around meC > here.  The really sad fact is they are less than half the size ofhA > VMS in annual revenue and their revenues are tailing off badly.e   Hardware costs excluding?i   Kit. kit # kits.net   ------------------------------  $ Date: Sat, 1 Jul 2000 03:32:38 -0700* From: "Nikita V. Belenki" <kit@nospam.net>; Subject: Re: OpenVMS loses big, was:  RE: Compaq advertisesm8 Message-ID: <g2k75.974$0x.29770@nuq-read.news.verio.net>  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message & news:8jfr3b$h48@gap.cco.caltech.edu...  H > >Does the COE project discussed in Terry Shannons articles not address someJ > >of the issues you raise in the attached ie. combining the good features ofE > >OpenVMS with some of the core functions associated with UNIX OS's?,J > I don't know yet.  The requirements for a competitive general purpose OSC > right now are very simple - it must be able to build and run codee	 developediK > on Unix systems, with no more than a trivial amount of code changes (sucht# > as that between Unixes) required.   L Why not the code developed on Windows systems? Because *you* like Unix more, right?  J > and it completes with no problems.  That is, it builds with nothing moreG > than minor modifications required to the makefile, the program sourcec code,eK > and when the binary runs it does everything at least as fast as Tru64 (orwJ > Linux), with the output produced exactly the same as on Tru64 (includingI > especially when a "record" sent to a stream text file exceeds 32k.) AndhH > yes, there really must be a bash and tcsh, because Makefiles and otherJ > supporting "glue" for many packages will only work properly within thoseL > shells.  If OpenVMS can't do that, then for small users who are not crazedK > by the thought of losing a few bytes of data, Linux and Tru64 will remaing > the OS of choice for Alpha.   J If these "small users" really want to type all this weird stuff instead ofH just clicking on the links in their browsers. Otherwise they will prefer Windows and ix86.o   > For 99% ofI > the market Unix style NIS/NFS is adequate, and the insanely high pricesv foro9 > "real" OpenVMS clustering are an unjustifiable expense.   H No. For 99% of the market Windows style is adequate. I don't want to sayH what it is good for VMS (or even for me). What I want to say is that anyL your point about Unix-style VMS is even more appealing one for Windows-styleI VMS. So either your position about the matters is completely wrong or youiL just sejected the wrong "role model" for VMS, in both cases it should not be Unix.   L [Sorry, I don't want to be offensive. Nothing personal, just my lame English ;) ]  G > Now you may say, "Celera is running a huge, sort of datacenter, styletH > installation, so why shouldn't they consider OpenVMS?"   Well, besidesI > their not wanting to rewrite their code, a lot of what they do involves. the F > generation and manipulation of a zillion small files, and OpenVMS is turtle$ > slow at that particular operation.  G It reminds me of SETI@HOME. If someone uses "a zillion small files" andiL doesn't want to rewrite their code, they don't really need very fast I/O. So' probably they shouldn't consider VMS ;)n  6 > Nobody is saying that OpenVMS isn't a great OS for aI > datacenter doing transaction processing - the problem is with the othero 99%D5 > of computing applications that it isn't addressing.-  J Actually, I am not sure that trying to "address the other 99% of computingH applications" is the right way to develop "a great OS for a datacenter".C IMHO, there will be a big risk of maiking it "not so great OS for amJ datacenter" (for technical or marketing reasons) without the guarantees of4 better-than-mediocre appearance for "the other 99%".  K I don't want to say that all the "enhancements" for "the other 99%" will beaK wrong. But don't forget to consider that some of them could actually *harm*oG VMS's current position, from technical and/or marketing points of view.a  E As an example of spoiling VMS-like functionality for the sake to meeteH mass-"style" technical and marketing reasons, you can look at Windows NT- Native (kernel) API vs. Windows NT Win32 API.    Kit. kit # kits.net   ------------------------------  % Date: Fri, 30 Jun 2000 23:54:21 -0400 * From: David A Froble <davef@tsoft-inc.com>; Subject: Re: OpenVMS loses big, was:  RE: Compaq advertisesd- Message-ID: <395D6B6D.9B74BD0B@tsoft-inc.com>i   JF Mezei wrote:c >  > David Mathog wrote:bL > > and it completes with no problems.  That is, it builds with nothing moreO > > than minor modifications required to the makefile, the program source code,dM > > and when the binary runs it does everything at least as fast as Tru64 (oriL > > Linux), with the output produced exactly the same as on Tru64 (includingG > > especially when a "record" sent to a stream text file exceeds 32k.)e > M > Instead of trying to port Unix to VMS, why not do the opposite: port VMS tob > UNIX ?  4 Rather play Russian Roulette with all chambers full!  B If I wanted Unix, I'd have switched long ago.  I didn't.  I won't.   Typical troll.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Sat, 01 Jul 2000 10:45:08 -0500s* From: Keith Brown <kbrown780@usfamily.net> Subject: Re: OT: "Open Windows"n, Message-ID: <395E1204.810AFB43@usfamily.net>   "David J. Dachtera" wrote: > G > While preparing an update (and move) of my website, I happened acrosso > this link: > , > http://www.geocities.com/openwindows_2000/ > ? > (Usual caution about cookies, ads, etc. re: Geocities apply.)b > B > This is a follow-on to FreeDOS, which is where I found the link. > I > Looks like the free software movement continues to nip at BG's heels...t >  > -- > David J. Dachteras > dba DJE Systemsu$ > http://home.earthlink.net/~djesys/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/u  4 Is poor software quality required for contributions? --   Keith Brown  kbrown780@usfamily.net   ------------------------------  % Date: Sat, 01 Jul 2000 00:00:55 -0400 * From: David A Froble <davef@tsoft-inc.com> Subject: Re: Sub-DS10 Alpha - Message-ID: <395D6CF7.4BBB8E24@tsoft-inc.com>o   "Zane H. Healy" wrote: > - > Arne Vajh-j <arne.vajhoej@gtech.com> wrote:o > > Ed Wilts wrote:sH > >> Get rid of the darn keyboard & mouse!  I'm accumulating too many ofK > >> these as it is.  My systems are servers, not desktops, and as such are J > >> connected to a cluster console system that doesn't require a keyboard  > >> and mouse for every server. > I > > Maybe. But some/many buyers will want keyboard & mouse. And the price ' > > impact is probably not significant.a > N > OK, how about the environmental impact :^)  How many of us here have growingN > piles of keyboards and mice both at work and at home that aren't being used? >  >                         Zane  M Keyboards, yeah.  They don't wear out so quickly.  Mice do, and the ones thatyP came with workstations now being used as servers are now on windoz systems where4 the mice died.  Got extra mice, send them to me. :-)   Dave   -- -4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Sat, 01 Jul 2000 00:13:17 -0400e* From: David A Froble <davef@tsoft-inc.com>/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)5- Message-ID: <395D6FDD.C048BD7D@tsoft-inc.com>e  9 "Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515" wrote:  > - > In article <WeEas191Y57+@eisner.decus.org>,oA >     Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:n1 > > In article <395AFC7E.CF596B6B@tsoft-inc.com>, 6 >         David A Froble <davef@tsoft-inc.com> writes: > >> Nigel Arnot wrote:  > >3G > >>> Creating a sub-DS10 Alpha hardware platform will have significantuG > >>> development costs. If Compaq does not believe that they will sellDF > >>> in sufficient quantities, that's a sensible reason not to do so.F > >>> (I'm not arguing that they are right, and I suspect that if theyF > >>> add the potential Linux market for a really cheap Alpha platform4 > >>> they are wrong. But I don't have the figures.) > >>! > >> You got my vote on this one.e > >tA > > Ok, so what features of the DS10L would the assembled expertssB > > suggest Compaq omit to make a more affordable sub-DS10 Alpha ? > J >         I took a hard look at the  DS10L specs and decided there's not aJ >     lot  you'd  want to leave off, at least, not a lot that  would  save >     money. > J >         For example, I really doubt you  need two Ethernet interfaces onJ >     an entry level system, but that'll be in the noise.  One other thingJ >     that  caught my eye is that the system comes with 2MB onboard cache.J >     Remember the DPW's (444au, 500au, 600au)?  You could buy those  withJ >     2MB, 1MB or 0MB of cache, and IIRC, that cache is/was pretty pricey,J >     not  like main memory.  You've got one PCI slot, and you'll use thatJ >     for the graphics if this is going  to be a workstation rather than aJ >     server.   You  need a CDROM and an internal hard disk (at least  forJ >     page and  swap,  although  strictly  speaking,  you  could  severelyJ >     cripple the system by making a satellite in a VMScluster and put theJ >     page  and  swap  files  on served storage...yuch!).  [But then you'dJ >     need a VMS Cluster license which would  cost more than you'd save on >     disk and SCSI adapter...]d > J >         Get back to the issue Bill  Todd  and others keep bringing up ofJ >     $1200  for  the  base VMS license.  I think I now  understand  whereJ >     that's coming from, but I'm not sure it's a  very  accurate  number.J >     If  you  compare the list prices for a DS10L w/256MB of memory (baseJ >     system in the QuickSpecs)  for  Linux-Ready,  Tru64 UNIX and OpenVMSJ >     (part  numbers DJ-71AAA-DA, DA-71AAA-DA and DY-71AAA-DA), the pricesJ >     are (US) $5334, $6134 and $6586.  So the "delta" for VMS compared toJ >     no O/S is $1252 (and about $450 compared to TU).  Note that the  VMSJ >     licenses  include  both  the base VMS, the "EIS" package, the latterJ >     giving  TCP/IP,   DECNET,   Pathworks/Advanced   Server,  DCPS-Plus,J >     DCPS-Open, and a couple of other things.  The alternative and harderJ >     question to answer is what is the price for the base VMS license for6 >     a DS10L purchased separately?  I have no idea...  N This pricing is news to me.  The data I used is from months ago, and the DS10,O not the 'L'.  (Continually browsing the pricing doesn't get any work done.)  IfnM you are getting base VMS, and the networking, and the rest of the EIS packagenL for $1252, then that's not really a bad price.  Now your difference in priceO between VMS and windoz is down to 3 digits.  I wonder if the 3-year HW warrantynO and 90 days software support are still the same.  Comments based upon precedingi paragraph only.   J >         Note that this is  less  than  the  "bundled" systems from AvnetJ >     that  Dave  Froble  (I  think, hope I didn't  botch  the  reference)J >     mentioned in another post.  It also points out the apparently  largeJ >     margins  that Compaq is garnering on these systems...are they reallyJ >     taking a loss  when  they  discount  for  academia,  or GSA for that >     matter?  I doubt it.  * Nope, not me.  Terry I believe.  Not sure.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  $ Date: Sat, 1 Jul 2000 12:44:42 -0400' From: "Bill Todd" <billtodd@foo.mv.com> / Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)h( Message-ID: <8jl73o$jb2$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in messagen' news:395D6FDD.C048BD7D@tsoft-inc.com...t; > "Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515" wrote:    ...r  L > >         Get back to the issue Bill  Todd  and others keep bringing up ofL > >     $1200  for  the  base VMS license.  I think I now  understand  whereL > >     that's coming from, but I'm not sure it's a  very  accurate  number.L > >     If  you  compare the list prices for a DS10L w/256MB of memory (baseL > >     system in the QuickSpecs)  for  Linux-Ready,  Tru64 UNIX and OpenVMSL > >     (part  numbers DJ-71AAA-DA, DA-71AAA-DA and DY-71AAA-DA), the pricesL > >     are (US) $5334, $6134 and $6586.  So the "delta" for VMS compared toL > >     no O/S is $1252 (and about $450 compared to TU).  Note that the  VMSL > >     licenses  include  both  the base VMS, the "EIS" package, the latterL > >     giving  TCP/IP,   DECNET,   Pathworks/Advanced   Server,  DCPS-Plus,L > >     DCPS-Open, and a couple of other things.  The alternative and harderL > >     question to answer is what is the price for the base VMS license for8 > >     a DS10L purchased separately?  I have no idea... > J > This pricing is news to me.  The data I used is from months ago, and the DS10,nF > not the 'L'.  (Continually browsing the pricing doesn't get any work
 done.)  IfG > you are getting base VMS, and the networking, and the rest of the EISh packageiH > for $1252, then that's not really a bad price.  Now your difference in pricenH > between VMS and windoz is down to 3 digits.  I wonder if the 3-year HW warrantyG > and 90 days software support are still the same.  Comments based uponr	 preceding, > paragraph only.M  L That part was the good news:  VMS, including networking support, at $1252 isH not unreasonable compared to Win2K Server at $839 (the last, and lowest,J price I happened to see for it) - though one could point out that softwareI mirroring and defragmentation are bundled into the Win2K Server price (ifl& they're not part of that VMS package).  H The bad news was the cost of the DS10L itself:  my impression (which, asD with the VMS pricing, came from others having presumably more directL acquaintance with the matter) was that the DS10 hardware could be bought for about $3500.   - bill   ------------------------------  % Date: Sat, 01 Jul 2000 00:24:25 -0400r* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395D7279.852282D9@tsoft-inc.com>o   Chris Scheers wrote: > J > This can give your software developer a very strong incentive to developF > for "commodity" platforms instead of VMS.  (I admit that I am biased$ > here.  I am a software developer.)  N As am I.  Sticking with VMS will never make me rich.  Nothing guarantees that.  G > Much as I dislike the design of PC platforms, I have to say that theyeH > have gotten much more reliable over the years.  I don't think that the2 > problem is the hardware as much as the software.  O Yep!  The software drivers provided with various widgets, notably the graphics, K which in NT now is in the kernel.  The same drivers that the vendors do not.J write for VMS, and most probably still wouldn't if VMS ran on Intel chips.  P Now, if the graphics drivers for Alpha based VMS systems are a tough problem forO the VMS people, what will the need of providing Intel drivers do to them?  NoteiP that the average life span of a particular graphics adapter is measured in days.  N When you don't have graphics drivers, will you still be as fond of the concept of VMS on Intel?  I > Most Windows code is an example of what I call "optimistic coding":  ItgF > assumes that there won't be any problems.  When a problem occurs, it > goes belly up. > H > VMS is an example of "pessimistic coding":  It assumes that everythingD > can go wrong.  As a result, when errors happen, they are much moreE > likely to be handled and not be catastrophic.  (Yes, the results innI > lower performance in benchmarks, but most machines have more horsepower J > than is needed anyways.  And what is the performance impact of a machine) > that runs blindingly fast into a BSOD?)e > G > I suggest that a VMS port to IAx hardware could be MORE reliable thane > Windows on the same hardware.g  O For the hardware that VMS supports, which won't be all the hardware, and I feel-P that VMS on Intel supporters would then blame Compaq, while nobody blames MS forI not writing drivers for all hardware.  Real double standard brewing here.i  J > (Cynic that I am, I suspect that Microsoft's "qualification" of hardwareF > for W2K consists of ensuring that the hardware never reports errors, > whether they happen or not.)  O Don't know that I'd agree with this.  Not that I like MS, but they're not totals idiots.r   Dave   -- a4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   End of INFO-VAX 2000.365 ************************