1 INFO-VAX	Fri, 30 Jun 2000	Volume 2000 : Issue 362       Contents:& Re: Compaq paying for software ports ?& Re: Compaq paying for software ports ? DE500 on Alpha VMS 6.2< Re: Directory Sizes (was: good news (for me,  I think) . . .7 Re: Disk I/O Performance (was Re: OpenVMS loses big...) 7 Re: Disk I/O Performance (was Re: OpenVMS loses big...) 7 Re: Disk I/O Performance (was Re: OpenVMS loses big...) 7 Re: Disk I/O Performance (was Re: OpenVMS loses big...) & Re: good news (for me,  I think) . . .4 How can I "replicate" Volume Shadowing on a Sun box?8 Re: How can I "replicate" Volume Shadowing on a Sun box?8 Re: How can I "replicate" Volume Shadowing on a Sun box? Maximum Password Lengths Re: Maximum Password Lengths Re: Maximum Password Lengths Re: Maximum Password Lengths7 Re: Northern Light vs. Google (and the winner is . . .) 7 Re: Northern Light vs. Google (and the winner is . . .) 7 Re: Northern Light vs. Google (and the winner is . . .) 7 Re: Northern Light vs. Google (and the winner is . . .) 7 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 clusters. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. RE: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. 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 advertises2 Re: OpenVMS loses big, was:  RE: Compaq advertises2 Re: OpenVMS loses big, was:  RE: Compaq advertises, Re: Oracle Press Release, incl. OpenVMS info OT: "Open Windows"% Re: RS232 CTS/RTS flow control on VAX  Re: Sub-DS10 Alpha" Sub-DS10 Alpha (was: VAX on Intel)& RE: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel)& Re: Sub-DS10 Alpha (was: VAX on Intel) Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX/VMS networking  F ----------------------------------------------------------------------   Date: 29 Jun 2000 18:28:18 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)/ Subject: Re: Compaq paying for software ports ? , Message-ID: <8jg4g2$q40@gap.cco.caltech.edu>  Z In article <395ADB14.D8E7D851@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > J >First, before I make a statement, I'd ask just what is your definition ofQ >'commercial apps'.  Then, I'd probably choose to disagree with you regardless of M >the answer.  David Mathog also claimed that 95% of VMS apps come from Unix.  E >Maybe true for his biology type apps.  Not everybody is a biologist.   G True.  It also applies to chemists, physicists, geologists, astronmers, I etc. Even many business applications are coming from Unix, most notably ,  Oracle's products.    
 > Most VMSD >apps probably are custom developed, on VMS, to meet specific needs.  K Which is not a good thing, because it restricts the growth of the operating 9 system to sites that can afford to pay for custom coding.    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Thu, 29 Jun 2000 18:51:07 +0100 % From: Alan Greig <a.greig@virgin.net> / Subject: Re: Compaq paying for software ports ? * Message-ID: <395B8C8B.8B4611BF@virgin.net>   David Mathog wrote: G Although OpenVMS ports have their own peculiar set of problems, the one   K > thing they generally do not represent is any sort of a security hole.  So F > long as they aren't installed with privs, and aren't run from priv'dM > accounts, there's generally nothing a regular user can do with one to break 9 > into a system. Bog it down, sure, become SYSTEM, never.  >   i I well remember installing POSIX for the first time in a student environment. Guess how long it took them h to work out that the wall (write all - ie send message to all users) command was available by default toh ordinary users because the POSIX standard required this? Fortunatately you could just INSTALL REMOVE thec image and this was buried somewhere in the release notes but not in BIG SHOUTY CAPITALS at the top.   h Still, I strongly support better support for migration from UNIX as long as it is done carefully - which% I expect is the way it is being done.    >    --
 Alan Greig   ------------------------------  % Date: Thu, 29 Jun 2000 18:31:35 -0400 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com> Subject: DE500 on Alpha VMS 6.2 7 Message-ID: <200006291831_MC2-AA9B-CE9A@compuserve.com>   F         I believe that only the DE500-XA was supported under VMS/AlphaJ V6.2.  The DE500-BA definitely requires several patches in order to work.=  =  7 The DE500-AA may also require patches in order to work.   $ Message text written by "John Nixon"H >In preparing for our Alpha VMS upgrade, we copied a system disk from anJ Alpha 2100 VMS 6.2 system to another Alpha 2100 that in a previous life w= asJ running Windows NT.   We had already loaded VMS 7.2-1 on this 2100 with n= o J problem.  We plan to run through a mock upgrade from VMS 6.2 to 7.2-1 wit= h C all patches and layered products etc... on the test sytsem prior to   upgrading the production system.  J The problem is that when we attempt to boot the new 2100 under VMS 6.2 it=  J crashes,  (I hate to give incomplete error messages, but the last message=  J was something about a setting on the ethernet port.   I am repeating this=  D message from someone else that actually saw it, but is not currently available).   G The 2100 has a DE500 fast ethernet card.  Will this work under VMS 6.2? H Could it cause the crash?   Are there any settings that will force it to work under VMS 6.2?   J We have a couple of DEFPA-DAs (fddi) that we plan to install so we can lo= adE 6.2 and proceed with the upgrade.  Is that a viable workaround?  (our G network has all sorts of hubs and switches so we can use either fddi or  fast or slow ethernet). <    ------------------------------  % Date: Thu, 29 Jun 2000 22:08:29 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> E Subject: Re: Directory Sizes (was: good news (for me,  I think) . . . - Message-ID: <395C0F2D.A179B788@earthlink.net>    Hey - question:   H Suppose I wrote a DCL proc. to move (rename) files around so that no oneD directory is more than 127 blocks in size, and also builds a logicalF name (search list) of the various locations where these files would be found.   What would be slower:   G A. Doing logical name (search list) translations and scanning cacheable 3 directories which may (or may not) be in the cache,    ...or...    B. Scanning one large directory?   --   David J. Dachtera  dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------   Date: 29 Jun 2000 18:40:04 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)@ Subject: Re: Disk I/O Performance (was Re: OpenVMS loses big...)6 Message-ID: <8jg564$dq1$1@mailint03.im.hou.compaq.com>  R In article <8jg49o$62h$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:9 :Tim Llewellyn <tim.llewellyn@bbc.co.uk> wrote in message $ :news:395B88AC.5AABDFF9@bbc.co.uk... :...C :> Not that stupid write thru/write back cache issue again, David?  ? :> ...issues involved in performance versus caching strategy... % :...integrity is not at issue here...   F   There are differing interests here, depending on the application andG   the customer environment.  Some customers need the reliability, some  F   need the performance.  Most want both, but that gets expensive.  OneG   example of performance and reliability involves, for instance, adding *   batteries into the StorageWorks shelves.  I   XFC is a recent step in this area (and XFC write-behind caching support M   is under development), and I know that one of the senior OpenVMS engineers  H   has taken an interest in locating the current file system performance K   bottlenecks.  This as part of locating good performance enhancements for  K   OpenVMS, and as part of the new file system work, and as part of scaling  2   into larger and larger storage configurations.    I   Given some of the relatively low I/O performance in several of the more J   common tools -- one of the locals has a significantly faster version of K   zip that gains its performance through larger transfers, for instance --  D   even basic SET RMS-level tuning can help with the I/O performance.  F   One of my pet peeves is the relatively poor settings for various RMSH   defaults -- they were good back when memory was tight, but they're not%   so hot with large-memory systems...   N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 30 Jun 2000 02:18:30 GMT $ From: Ed Wilts <ewilts@mediaone.net>@ Subject: Re: Disk I/O Performance (was Re: OpenVMS loses big...), Message-ID: <395C036D.F246D8E5@mediaone.net>   Hoff Hoffman wrote:  > H >   One of my pet peeves is the relatively poor settings for various RMSJ >   defaults -- they were good back when memory was tight, but they're not' >   so hot with large-memory systems...   G So why don't you suggest some good defaults or a reasonable formaula in F the FAQ? Then you'll have a place to point people when they complain. F This could suffice until a future release of VMS that incorporates the new and improved defaults.   	.../Ed  --   Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  % Date: Thu, 29 Jun 2000 22:25:18 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> @ Subject: Re: Disk I/O Performance (was Re: OpenVMS loses big...)- Message-ID: <395C131E.2BDF46C6@earthlink.net>    Hoff Hoffman wrote:  [snip]  H >   One of my pet peeves is the relatively poor settings for various RMSJ >   defaults -- they were good back when memory was tight, but they're not' >   so hot with large-memory systems...   H Have any tips on how to calculate some better RMS tuning based on either6 F$GETSYI( "MEMSIZE" ) or F$GETSYI( "VIRTUALPAGECNT" )?   --   David J. Dachtera  dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------   Date: 30 Jun 2000 04:15:39 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)@ Subject: Re: Disk I/O Performance (was Re: OpenVMS loses big...), Message-ID: <8jh6tb$k7i@gap.cco.caltech.edu>  A In article <8jg564$dq1$1@mailint03.im.hou.compaq.com>, you write:  > J >  Given some of the relatively low I/O performance in several of the moreK >  common tools -- one of the locals has a significantly faster version of  L >  zip that gains its performance through larger transfers, for instance -- E >  even basic SET RMS-level tuning can help with the I/O performance.  >   J Right.  The thing that seems to make the most difference is setting extendI properly.  For instance, if I run gunzip "vanilla" on the DS10 it makes a K frenetic "ticky-ticky-ticky" sound as the heads bounce around the disk for  K each extend.  What I usually do is eyeball the size of the .gz, multiply by G three, and set extend to that.  It speeds things up a lot and _sounds_  8 better, just one quick "bzzt" or "blaaaat" as it writes.  K When my users run various programs I hear a lot of that "ticky-ticky-ticky"  noise.  H Anyway, that suggests that the manner in which file extends are handled K could use some work in the performance area.  I'm guessing that it actually J has to write the disk bitmap and maybe the directory each time it extends,G and that's three 8 ms delays as the heads move to the bitmap, then the  J directory, then back to the end of the file.  I may have the details wrongG but you can really hear the heads jumping around on the drives at each  K extend.  (One of the "benefits" of having your DS10 sitting on a large flat 8 table which does an excellent imitation of a drum head.)  G >  One of my pet peeves is the relatively poor settings for various RMS I >  defaults -- they were good back when memory was tight, but they're not & >  so hot with large-memory systems... >   L At least for files you can twiddle the RMS parameters, pipes are even worse.G The only parameter you can tweak sets the general mailbox sizes, so it  K affects all mailboxes on the system, and when I cranked those up Decwindows  failed on the next login!     G The limit I keep running into is that no matter what I do RMS IO always I seems to come out 2.5 - 6x slower than on Linux, for any memory to memory C operation.  That was the ratio for netpipe tests through localhost, H and that was the same ratio for a record based copy test using a Ramdisk' (versus file caching.)  If you look at    ;   http://seqaxp.bio.caltech.edu/www/vmstcpip/COMPARISON.GIF   B and examine the localhost tests on various systems you'll find theH interesting result that the plot is linear up to the point it bends overI due to saturation and the slope in the linear regions of the plots is the = same for all OS's. It's a log log plot, so I guess that shift I indicates an overhead ratio which is proportional to the size of the size H of the data. So if I'm thinking straight, and y = log(xfer rate) and x =! log(buffer size) then y = ax + b       exp(y) = exp(ax+b)"   xfer rate = buffer size * exp(b)$   xfer rate = buffer size * constant  < That is, the performance is proportional to the buffer size,H and the constant is likely inversely proportional to the number of timesI each byte is scanned (or average operations per byte.)  That's a bit too  I simplistic - I should probably fit the curves better to pick up any other K nonlinear terms.  Anyway, it fits a model where Linux uses say 2 operations L per byte, TCIP/IP services about 6, and Multinet about 10, (or multiply all ! of the above by the same factor.)    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------   Date: 29 Jun 2000 22:33 CST ' From: carl@gerg.tamu.edu (Carl Perkins) / Subject: Re: good news (for me,  I think) . . . - Message-ID: <29JUN200022331769@gerg.tamu.edu>   3 "John Nixon" <jorlnixon@worldnet.att.net> writes... C }On our VAX VMS 6.X systems, when we put 3 or 4 thousand files in a  }directory, we would have M }all sorts of problems.   Now,  on hearing that VMS 7.2 fixed these problems,  }I have heard a C }proposal to allow the application to put over  60,000 files in one # }directory.   I think this is nuts, = }but I have not had the opportunity to test the improvements.  }  }Can anyone comment on this?  5 My comment: The person who proposed this is an idiot.    --- Carl   ------------------------------  % Date: Thu, 29 Jun 2000 19:53:36 -0500 / From: Scott Vieth <svieth@ameritech.net.nospam> = Subject: How can I "replicate" Volume Shadowing on a Sun box? 4 Message-ID: <395BEF90.8DEBE542@ameritech.net.nospam>   Hi:   B How can I use make a Sun box do the same magical things that I can< do with an OpenVMS system that runs Volume Shadowing?  We'veE got a nifty little nightly routine where we shut down our main Oracle ? (on VMS Alpha) database, dismount the DSAs, re-mount two out of A the three shadow members, re-start the database software and then > back-up the third member of each shadow set.  Once the backups= are done, we merge the third member back into each DSA volume 
 "on the fly".   C Can a Solaris system do the same thing?  What 3rd party software dos# I need to be able to pull this off?p   Thanks in advance.   -Scott  :^)q   ------------------------------  # Date: Fri, 30 Jun 2000 02:32:32 GMT $ From: Ed Wilts <ewilts@mediaone.net>A Subject: Re: How can I "replicate" Volume Shadowing on a Sun box?i, Message-ID: <395C06C1.FA885967@mediaone.net>   Scott Vieth wrote: >  nD > How can I use make a Sun box do the same magical things that I can> > do with an OpenVMS system that runs Volume Shadowing?  We'veG > got a nifty little nightly routine where we shut down our main OracleiA > (on VMS Alpha) database, dismount the DSAs, re-mount two out ofuC > the three shadow members, re-start the database software and thens@ > back-up the third member of each shadow set.  Once the backups? > are done, we merge the third member back into each DSA volume  > "on the fly".t > E > Can a Solaris system do the same thing?  What 3rd party software dot% > I need to be able to pull this off?t  7 You should actually post this to a Solaris newsgroup...v  C I believe this can be accomplished in Tru64 with the logical volumed< manager, but I don't know Solaris at all (nor do I want to).  H You can also port your applications from Solaris to a real enterprise OS% like VMS (hey, this is comp.os.vms!).M   	.../Edv     -- y Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  % Date: Thu, 29 Jun 2000 22:56:57 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> A Subject: Re: How can I "replicate" Volume Shadowing on a Sun box?C( Message-ID: <8jh27q$aa0$1@pyrite.mv.net>  / Ed Wilts <ewilts@mediaone.net> wrote in messagew& news:395C06C1.FA885967@mediaone.net... > Scott Vieth wrote: > > F > > How can I use make a Sun box do the same magical things that I can@ > > do with an OpenVMS system that runs Volume Shadowing?  We'veI > > got a nifty little nightly routine where we shut down our main Oracle C > > (on VMS Alpha) database, dismount the DSAs, re-mount two out ofoE > > the three shadow members, re-start the database software and thenaB > > back-up the third member of each shadow set.  Once the backupsA > > are done, we merge the third member back into each DSA volume  > > "on the fly".  > > G > > Can a Solaris system do the same thing?  What 3rd party software do ' > > I need to be able to pull this off?i > 9 > You should actually post this to a Solaris newsgroup...-  B And will probably get a reasonably knowledgeable response at, say, comp.unix.solaris.   >oE > I believe this can be accomplished in Tru64 with the logical volumeg> > manager, but I don't know Solaris at all (nor do I want to).  I Both Tru64 and Solaris have optional logical volume managers based on theID Veritas LVM (VxVM).  I'm pretty sure that VxVM does support many-way@ mirroring with break-out for such backup purposes (and efficientJ reintegration following the backup); I think it also supports at least oneK form of 'snapshot' technology that doesn't require the additional mirror ati all for a backup.l  I When you run Oracle on the Veritas File System (VxFS) on top of VxVM, thebD combination offers some attractive management benefits, including anJ additional (optional) special snapshot mechanism optimized for Oracle use.K Browse around veritas.com for details:  they do a pretty good job of addingwB value to Oracle, but they also expect you to pay them well for it.  J Sun offers its own volume manager called DiskSuite, which most people seemK to hold in somewhat lower esteem than VxVM in terms of features (it doesn't*J seem to have a bad reputation for reliability, but I may have read about aL problem at one point).  I don't know whether it would do what you're lookingH for, but the newsgroup can probably provide the answer (and Sun has someI details on line at their web site - nothing like the VMS on-line doc set,g though).   - bill   >uJ > You can also port your applications from Solaris to a real enterprise OS' > like VMS (hey, this is comp.os.vms!).l >u > .../Ed >r >h > --
 > Ed Wilts > Mounds View, MN, USA > mailto:ewilts@mediaone.net   ------------------------------  # Date: Thu, 13 Apr 2000 14:46:50 GMTa4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>! Subject: Maximum Password LengthshE Message-ID: <u5lJ4.13133$q67.403510@newsread2.prod.itd.earthlink.net>o  K What is the maximum user password length on VMS 7.2, and NT 4 Domain, and ae= Win 2000 Active Directory?  I need information for all three.e   Thanks, 
 Mike Ober.   ------------------------------  % Date: Thu, 13 Apr 2000 17:18:32 +0200e= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>i% Subject: Re: Maximum Password Lengths ) Message-ID: <38F5E548.BDC226DE@gtech.com>h   "Michael D. Ober" wrote:M > What is the maximum user password length on VMS 7.2, and NT 4 Domain, and ap? > Win 2000 Active Directory?  I need information for all three.i   VMS: 32t   WNT/W2K: no idea   Arne   ------------------------------  % Date: Thu, 13 Apr 2000 11:42:05 -040025 From: "Amiri Jones" <MyFirstName.MyLastName@pseg.com><% Subject: Re: Maximum Password Lengthso7 Message-ID: <uCWjU7Vp$GA.196@cppssbbsa02.microsoft.com>@  = Michael D. Ober <mdo.@.wakeassoc.com.nospam> wrote in messages? news:u5lJ4.13133$q67.403510@newsread2.prod.itd.earthlink.net... K > What is the maximum user password length on VMS 7.2, and NT 4 Domain, ande an? > Win 2000 Active Directory?  I need information for all three.p >nK     The only one I can say for sure is NT 4; maximum is 14 characters.  I'm6> not at my Win2K machine right now, and I've never used VMS....   ------------------------------  % Date: Sun, 16 Apr 2000 15:24:16 +0300  From: "subZ" <subz@sci.fi>% Subject: Re: Maximum Password Lengths & Message-ID: <8dcbs5$g07$1@tron.sci.fi>  @ "Amiri Jones" <MyFirstName.MyLastName@pseg.com> wrote in message1 news:uCWjU7Vp$GA.196@cppssbbsa02.microsoft.com...o >o? > Michael D. Ober <mdo.@.wakeassoc.com.nospam> wrote in messageoA > news:u5lJ4.13133$q67.403510@newsread2.prod.itd.earthlink.net... I > > What is the maximum user password length on VMS 7.2, and NT 4 Domain,o ands > atA > > Win 2000 Active Directory?  I need information for all three.s > >5H >     The only one I can say for sure is NT 4; maximum is 14 characters. I'mh@ > not at my Win2K machine right now, and I've never used VMS.... >  >   ! Copy - Paste from the Win2k Help:t  L Windows 2000 passwords can be up to 127 characters long. However, if you areK using Windows 2000 on a network that also has computers using Windows 95 orsK Windows 98, consider using passwords not longer than 14 characters. Windows-L 95 and Windows 98 support passwords of up to 14 characters. If your passwordC is longer, you may not be able to log on to your network from thosea
 computers.     subZ   ------------------------------  % Date: Thu, 29 Jun 2000 14:02:08 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>o@ Subject: Re: Northern Light vs. Google (and the winner is . . .)( Message-ID: <8jg2t6$4eu$1@pyrite.mv.net>  > I'm more than happy to continue this at a lower decibel level:  6 Tim Shoppa <shoppa@trailing-edge.com> wrote in message+ news:395B49CF.4E882ACD@trailing-edge.com...a > Bill Todd wrote:K > > And surely you're not suggesting that the cost of *managing* backups is F > > decreasing at as great a rate as the media cost:  that would be in markedJ > > contrast to the generally (and rapidly) increasing percentage of totalJ > > expenditure devoted to managing storage (rather than simply purchasing it). >-H > I agree with you here - the cost of managing/creating/maintaining dataC > is the dominant component in any computer system these days.  ThesD > offline and online storage (hardware and media) costs for the data > are in the noise.h >pC > Still, the reason why it's so (comparatively) difficult to managelD > backups is that many modern platforms come with no integrated toolA > for doing this, it's something that managers unfortunately havee > to "bolt on".i  L That's *one* reason, and one that, as you note, can be dealt with.  A largerL problem is the size of the data that needs to be backed up compared with theL bandwidth available to back it up:  incrementals help only so far with this,H and start tying up subsidiary systems just merging them to keep the fullK backup from getting ridiculously out of date.  But the *really* big problemi! is how to handle full *restores*.t  J I think it was in the recent Ruettgers (EMC CEO) interview where he tossedG off the observation that restoring a PB of data takes a year and a half C (IIRC - and if my quick mental calculation went right, that's abouthK 20MB/sec, so while one can clearly improve the number with parallelism it'sgJ really hard to get it *'way* down).  That's just not feasible:  we'll haveL to move toward some other, far more continuous (and on-line, to limit growthC in the service aspect of recovery) way to protect our data, and theeK continuing decrease in hard-drive prices suggests at least one direction toa	 consider.n  1   To say that it's difficult to manage backups on G > your system-critical Windows NT server or Linux server is to say thatwJ > you've chosen the wrong OS.  As in, "whad'ya mean, there's no way for meF > to mark that big scratch file /NOBACKUP"?  What *should* be a simpleA > job gets turned into a confusing array of fixed-size partitions B > (themselves a waste of storage space, not so important as it wasA > ten years ago) and complicated scripting to exclude a couple ofa > named files or directories.-  K Yup, all those things are necessary.  But they're not sufficient, given the<( way storage is exploding (figuratively).   - bill   >w > Tim.   ------------------------------  % Date: Thu, 29 Jun 2000 14:11:47 -0400H' From: "Bill Todd" <billtodd@foo.mv.com>v@ Subject: Re: Northern Light vs. Google (and the winner is . . .)( Message-ID: <8jg3f8$599$1@pyrite.mv.net>  5 Arne Vajhj <arne.vajhoej@gtech.com> wrote in message.# news:395B85D9.51E45AF5@gtech.com...o > Bill Todd wrote:K > > I'm getting tired of responding to people who haven't taken the time tot readH > > and understand what's already been written on this subject.  So I'll just > > suggest that you do so.  >.< > And I think you should read what I wrote. I am saying that= > replication and backup is two completely independent issuesu( > for anyone who cares about their data.  I And that's incorrect - for specific reasons as applied to Google, and forsG general reasons as I've been discussing with Keith Brown and Tim Shoppa L elsewhere in this overall thread.  To understand why, though, you'll have to do as I suggested.   - bill   > ; > That is a general statement and completely independent ofe > the Google Linux story.a >- > Arne   ------------------------------  % Date: Thu, 29 Jun 2000 21:43:36 +0200d= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> @ Subject: Re: Northern Light vs. Google (and the winner is . . .)) Message-ID: <395BA6E8.4C490E30@gtech.com>    Bill Todd wrote:7 > Arne Vajhj <arne.vajhoej@gtech.com> wrote in messageo% > news:395B85D9.51E45AF5@gtech.com... > > > And I think you should read what I wrote. I am saying that? > > replication and backup is two completely independent issuesO* > > for anyone who cares about their data. > K > And that's incorrect - for specific reasons as applied to Google, and foryI > general reasons as I've been discussing with Keith Brown and Tim ShopparN > elsewhere in this overall thread.  To understand why, though, you'll have to > do as I suggested. >   - You mean like the following quote from Keith:o  ; #                               Your statement that backupsh #will soon be obsolete is crap.h  
 And from Tim:t  1 #I agree with Keith: This argument is total crap.    ????  A They did backup 25 years ago. They will make backup in 25 years !r: Backup is a must. And almost completely independent of any technological & price progress.t  B Will the media be tape ? That can be discussed. Personally I think> it will be. Tape has shown an amazingly capability to improve.   Arne   ------------------------------  % Date: Thu, 29 Jun 2000 16:00:10 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>c@ Subject: Re: Northern Light vs. Google (and the winner is . . .)( Message-ID: <8jg9qc$c2v$1@pyrite.mv.net>  F I'm afraid that wherever you've got your head stuck, the visibility is- severely limited.  Let us know if it emerges.c   - bill  5 Arne Vajhj <arne.vajhoej@gtech.com> wrote in messaget# news:395BA6E8.4C490E30@gtech.com...t > Bill Todd wrote:9 > > Arne Vajhj <arne.vajhoej@gtech.com> wrote in messagel' > > news:395B85D9.51E45AF5@gtech.com...r@ > > > And I think you should read what I wrote. I am saying thatA > > > replication and backup is two completely independent issues , > > > for anyone who cares about their data. > >rI > > And that's incorrect - for specific reasons as applied to Google, andk for K > > general reasons as I've been discussing with Keith Brown and Tim Shoppa H > > elsewhere in this overall thread.  To understand why, though, you'll have toh > > do as I suggested. > >k >t/ > You mean like the following quote from Keith:  >l= > #                               Your statement that backupsa! > #will soon be obsolete is crap.i >  > And from Tim:t >s3 > #I agree with Keith: This argument is total crap.m >u > ???? >sC > They did backup 25 years ago. They will make backup in 25 years !t< > Backup is a must. And almost completely independent of any! > technological & price progress.p >eD > Will the media be tape ? That can be discussed. Personally I think@ > it will be. Tape has shown an amazingly capability to improve. >  > Arne   ------------------------------    Date: 30 Jun 2000 00:41:47 +0200. From: Aaron Spink <spink@kraftwerk.pa.dec.com>@ Subject: Re: Northern Light vs. Google (and the winner is . . .)2 Message-ID: <sfqpup0cdp0.fsf@kraftwerk.pa.dec.com>  ) "Bill Todd" <billtodd@foo.mv.com> writes:a    J > Rather, your ability to read is what appears to be 'crap':  my statementK > (which you included above, but apparently didn't bother to read) was thatxN > "it's convincingly arguable that traditional backup is in general on the wayM > out", a view which I happen to share with such diverse people as the CEO offK > EMC (a company rather more interested in the future of storage than most)tN > and Linus Torvalds - both of whose industry credibility likely exceeds yours7 > (though I wouldn't consider either to be infallible).  >   B Bill, while EMC may think that backup may be on the way out, thatsF only because they want to sell you 10 systems instead of 1, aka bigger? profit.  I know a decent number of places that have had cluster E replication of storage in addition to full RAID on the storage.  TheyqD still needed backup and always will.  Someplace like google or other? seach engines/caches don't need it, simply because they deal in.A transient, regeneratable data(ie they redo it on a pretty regular ; basis anyways and don't care what they had 2 months ago).  h  D But, the vast majority of systems(everything except transient searchC engines(aka not yahoo like directories) or cache servers) will needhD traditional backup if for nothing else than human error.  When I wasD actually getting paid to do backup activities, the number one reason> for a request was human error.  In that case, you need lots ofC historical snap shots, enough that the only thing cost effective is  tape.  n  E If you want some perspective, try posting that tradition backup is non? longer needed on comp.arch.storage and don the perverbial flameh suit. :)     Aaron Spink0 not speaking for Compaqi   ------------------------------  % Date: Thu, 29 Jun 2000 20:00:41 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>B@ Subject: Re: Northern Light vs. Google (and the winner is . . .)( Message-ID: <8jgntc$1ot$1@pyrite.mv.net>  9 Aaron Spink <spink@kraftwerk.pa.dec.com> wrote in messageo, news:sfqpup0cdp0.fsf@kraftwerk.pa.dec.com...   ...u  D > Bill, while EMC may think that backup may be on the way out, thatsH > only because they want to sell you 10 systems instead of 1, aka biggerA > profit.  I know a decent number of places that have had cluster G > replication of storage in addition to full RAID on the storage.  Theyl& > still needed backup and always will.  H My God, the illiteracy has spread into the corporation.  So much for our! hopes for competency from Compaq.q  G To give you the benefit of the doubt, perhaps you're responding without L having seen the original comment.  I'll reproduce it below.  The sentence is> a bit long and convoluted, but it can be parsed unambiguously:  = "For that matter, it's convincingly arguable that traditionalbE backup is in general on the way out, given the decreasing gap in costhH between on-line and off-line storage and the increasing relative cost ofA creating, organizing, and storing said off-line storage:  keepingnL differential (to minimize space requirements; perhaps partial as well, sinceB a lot of data is easily recoverable by other means) redundant (andL separated, to guard against both media and whole-site failures) snapshots onI line is one promising alternative, and particularly attractive in that it L can allow users to recover from their own mistakes without invoking the Gods of the Data Center."      Someplace like google or otherA > seach engines/caches don't need it, simply because they deal inaC > transient, regeneratable data(ie they redo it on a pretty regular ; > basis anyways and don't care what they had 2 months ago).  > F > But, the vast majority of systems(everything except transient searchE > engines(aka not yahoo like directories) or cache servers) will need-: > traditional backup if for nothing else than human error.  K Which, you will note, is covered by the snapshot component of the mechanismh sketched out above.C     When I wasF > actually getting paid to do backup activities, the number one reason  > for a request was human error.  L And wouldn't you have loved it if those humans had been able to recover fromI almost all the errors they made by accessing an on-line (write-protected)o, snapshot rather than bothering you about it?      In that case, you need lots of > historical snap shots,   No shit:  see above.  -  enough that the only thing cost effective ise > tape.m  K Until recently - and possibly even still - tape may be more cost-effective.o That seems likely to change.  L The minimum street price of commodity IDE drives has just recently hit $5/GBK (quantity:  1) and shows no sign of stopping there.  But the real issue mayaI be the *marginal* cost of on-line storage:  as individual disk sizes passdH the 100 GB (probably this year) and 200 GB (probably sometime next year)I marks, the adverse performance impact of trying to use most of that spacee. for reasonably active data may be prohibitive.  H In such a case, the marginal cost of that space when used for reasonablyL 'cold' data (and backups tend to be about as cold as most data gets) becomesH very close to zero.  Factor in the cost of requiring heavy-duty links toL handle periodic backup loads, banks of tape handlers, physical management ofH tape media, off-line merges of incrementals to keep the full backup fromH getting too old, the problems of restoring data of any real size after aC site disaster (in another post I quoted Ruettgers' observation thatSJ restoring 1 PB takes a year and a half at 20 MB/sec), and those pesky userJ requests for old data, and continuous on-line backup starts looking like a
 real bargain..   >wG > If you want some perspective, try posting that tradition backup is no A > longer needed on comp.arch.storage and don the perverbial flame 
 > suit. :)  I comp.arch.storage is not much of a forum for architectural issues:  whilesJ there are few people there interested in such things, most discussions are far more mundane.   L But comp.arch is not a bad location for such conversations, and I've touchedE on at least some aspects of this recently there, though before havingp/ thought it through as thoroughly as I have now.a  L And of course, what I said originally was not that traditional backup was noJ longer needed, but that there was reason to suspect it was on the way out:I I have no problem standing by that statement, for the reasons I've noted.r   - bill   >d >l
 > Aaron Spinke > not speaking for Compaq@   ------------------------------  % Date: Thu, 29 Jun 2000 18:36:45 -0400:2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>7 Subject: Re: OpenVMS clusters vs other systems clusters-7 Message-ID: <200006291836_MC2-AAA3-2754@compuserve.com>n  
         Bill,h  J         Try again.  I didn't just "investigate", I bought two ES40-2 with=  H VMS license.  They also shipped with an "Enterprise Integration" package5 which did include TCP/IP and a bunch of other things.   # Message text written by "Bill Todd"8H >Only a couple of months ago, a friend who investigated the situation (IJ suspect thoroughly, since low-end VMS issues are of considerable interest=   toH him) reported that the base VMS license available in the low-end pricingC tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack ande friends,J and cost around $1200.  Now the least expensive package listed for the DS= 10J reportedly *does* include the TCP/IP stack and friends, and costs several=  H times that amount (haven't heard whether the old, $1200 base package was? actually discontinued, or is just something you have to ask forc specifically to find out about it).<l   ------------------------------  % Date: Thu, 29 Jun 2000 18:36:43 -0400i2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>7 Subject: Re: OpenVMS clusters vs other systems clustersi7 Message-ID: <200006291836_MC2-AAA3-2753@compuserve.com>r           Andrew,i  H         If you buy an Alpha with a VMS license you also get a package ofJ other licenses.  TCP/IP is one of the products licensed.  TCP/IP ships on=  , one of the CD's in the VMS distribution kit.           Try a little harder!  9 Message text written by Andrew Harrison SUNUK Consultancyr4 >Just for a moment just consider packaging, all part0 of marketing. How out of touch do you heve to be2 to try to market an OS in this day and age without8 including an IP stack and all the accompanying utilities5 with it. What sort of message do you think this sendsw3 to people building internet/intranet based systems.  <    ------------------------------  % Date: Thu, 29 Jun 2000 19:30:36 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>m7 Subject: Re: OpenVMS clusters vs other systems clusters ' Message-ID: <8jgm4u$l4$1@pyrite.mv.net>   F How nice for you!  But the fact that you bought one configuration saysK nothing about the existence of others at that time, let alone in the recentw past.t  K Too bad someone who *knows* both the current and historical situation can'tn take the time to respond here.   - bill  ; Richard B. Gilbert <DRAGON@compuserve.com> wrote in messageu1 news:200006291836_MC2-AAA3-2754@compuserve.com...n
         Bill,k  I         Try again.  I didn't just "investigate", I bought two ES40-2 with H VMS license.  They also shipped with an "Enterprise Integration" package5 which did include TCP/IP and a bunch of other things.r  # Message text written by "Bill Todd"yH >Only a couple of months ago, a friend who investigated the situation (II suspect thoroughly, since low-end VMS issues are of considerable interestC toH him) reported that the base VMS license available in the low-end pricingC tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack anda friends,K and cost around $1200.  Now the least expensive package listed for the DS10eI reportedly *does* include the TCP/IP stack and friends, and costs several H times that amount (haven't heard whether the old, $1200 base package was? actually discontinued, or is just something you have to ask fors specifically to find out about it).<    ------------------------------  % Date: Thu, 29 Jun 2000 20:41:10 -0400 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>7 Subject: Re: OpenVMS clusters vs other systems clustersn7 Message-ID: <200006292041_MC2-AAAB-6194@compuserve.com>o  G         Since I bought the systems in question not much more than seveneJ weeks ago, I think I am entitled to speak about the "recent past".  Three=  = different Compaq Resellers (Authorized) quoted me on the sameh3 configuration.  I'd say it was generally available!   =         I'm sure that these systems might have been available,J somewhere/somewhen without the Enterprise Integration Package but so what= ?k  H         If you prefer to discount the evidence that doesn't support your point. . . .    # Message text written by "Bill Todd"hG >How nice for you!  But the fact that you bought one configuration saysoJ nothing about the existence of others at that time, let alone in the rece= nt past.c  J Too bad someone who *knows* both the current and historical situation can= 't take the time to respond here.   - bill  ; Richard B. Gilbert <DRAGON@compuserve.com> wrote in messagea1 news:200006291836_MC2-AAA3-2754@compuserve.com...(
         Bill,   J         Try again.  I didn't just "investigate", I bought two ES40-2 with=  H VMS license.  They also shipped with an "Enterprise Integration" package5 which did include TCP/IP and a bunch of other things.a  # Message text written by "Bill Todd"lH >Only a couple of months ago, a friend who investigated the situation (IJ suspect thoroughly, since low-end VMS issues are of considerable interest=   toH him) reported that the base VMS license available in the low-end pricingC tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack ande friends,J and cost around $1200.  Now the least expensive package listed for the DS= 10J reportedly *does* include the TCP/IP stack and friends, and costs several=  H times that amount (haven't heard whether the old, $1200 base package was? actually discontinued, or is just something you have to ask for- specifically to find out about it).<4   <0   ------------------------------  % Date: Thu, 29 Jun 2000 21:29:14 -0400s+ From: "Main, Kerry" <Kerry.Main@compaq.com>D7 Subject: RE: OpenVMS clusters vs other systems clusterseJ Message-ID: <910612C07BCAD1119AF40000F86AF0D8052844B2@kaoexc4.kao.dec.com>  ' Just to expand on Richards statement ..o  8 Check out the various low-medium range Alpha configs at:G <http://www1.compaq.com/products/docdetail/0,1521,wp%7E16367_2,00.html>    DS10:sJ OpenVMS systems include pre-installed software (V7.2-1), Base license withG System Manager license and Compaq Enterprise Integration Server License 
 Package V3.0Ao   DS20E:F AlphaServer DS20E OpenVMS systems include pre-installed software, BaseE license with System Manager license and Enterprise Integration ServerhF License Package for OpenVMS V3.0A.  AlphaStation DS20E OpenVMS systemsL include pre-installed software, Base license, Concurrent Use 1-user license,> NAS 150 Client license, and Compaq Open3D traditional license.   ES40:yE AlphaServer ES40 OpenVMS systems include pre-installed software, Base0E license with System Manager license and Enterprise Integration ServergK License Package for OpenVMS V3.0A AlphaStation ES40 OpenVMS systems include L pre-installed software, Base license, Concurrent Use 1-user license, NAS 150L Client license, Compaq MMS RT license and Compaq Open3D traditional license.  I Note - all of the above systems include: Service and Support-Protected bylF Compaq Services including a 3-year on-site hardware warranty with nextJ business day response. Software warranty is a 90-day telephone advisory.    K More information on what is contained in the "Enterprise Integration Serveri5 License Package for OpenVMS" package can be found at:r= http://www.digital.com/info/SP6475/SP6475HM.HTM (EIP pointer) E http://www.digital.com/info/SP6298/SP6298HM.HTM (NAS150 license info)    Regards,  
 Kerry Main Senior Consultant,
 Compaq Canadaw Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.comp       -----Original Message-----7 From: Richard B. Gilbert [mailto:DRAGON@COMPUSERVE.COM] % Sent: Thursday, June 29, 2000 8:41 PMn To: Info-VAX@Mvb.Saic.Comr7 Subject: Re: OpenVMS clusters vs other systems clusterss    G         Since I bought the systems in question not much more than sevenyI weeks ago, I think I am entitled to speak about the "recent past".  Three = different Compaq Resellers (Authorized) quoted me on the same 3 configuration.  I'd say it was generally available!r  =         I'm sure that these systems might have been availabledJ somewhere/somewhen without the Enterprise Integration Package but so what?  H         If you prefer to discount the evidence that doesn't support your point. . . .    # Message text written by "Bill Todd"cG >How nice for you!  But the fact that you bought one configuration sayseK nothing about the existence of others at that time, let alone in the recent  past.r  K Too bad someone who *knows* both the current and historical situation can'te take the time to respond here.   - bill  ; Richard B. Gilbert <DRAGON@compuserve.com> wrote in messager1 news:200006291836_MC2-AAA3-2754@compuserve.com... 
         Bill,s  I         Try again.  I didn't just "investigate", I bought two ES40-2 withnH VMS license.  They also shipped with an "Enterprise Integration" package5 which did include TCP/IP and a bunch of other things.n  # Message text written by "Bill Todd" H >Only a couple of months ago, a friend who investigated the situation (II suspect thoroughly, since low-end VMS issues are of considerable interesti toH him) reported that the base VMS license available in the low-end pricingC tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack ande friends,K and cost around $1200.  Now the least expensive package listed for the DS10 I reportedly *does* include the TCP/IP stack and friends, and costs severalnH times that amount (haven't heard whether the old, $1200 base package was? actually discontinued, or is just something you have to ask fort specifically to find out about it).<    <    ------------------------------  % Date: Thu, 29 Jun 2000 22:36:56 -0400k' From: "Bill Todd" <billtodd@foo.mv.com>.7 Subject: Re: OpenVMS clusters vs other systems clustersh( Message-ID: <8jh12a$9i8$1@pyrite.mv.net>  I While your response may be helpful to people interested in purchasing the D listed configuration (the availability of which has not, AFAIK, beenI questioned by anyone), it throws absolutely no light upon the issue undertG discussion, to wit, whether any DS10 VMS configuration can still be putaK together without TCP/IP support (and at a significantly lower price, thougheG I realize Compaq may not want any specific price information released - L 'why' is a question for another day) and, if not, at what point in time this ceased to be possible.  G Richard's latest response is equally useless in this regard, but you'reeG presumably in a position to obtain this information fairly easily:  any  chance you might do so?    Thanks,l   - bill  4 Main, Kerry <Kerry.Main@compaq.com> wrote in messageD news:910612C07BCAD1119AF40000F86AF0D8052844B2@kaoexc4.kao.dec.com...) > Just to expand on Richards statement ..n >p: > Check out the various low-medium range Alpha configs at:I > <http://www1.compaq.com/products/docdetail/0,1521,wp%7E16367_2,00.html>n >n > DS10: L > OpenVMS systems include pre-installed software (V7.2-1), Base license withI > System Manager license and Compaq Enterprise Integration Server Licensei > Package V3.0Ak >a > DS20E:H > AlphaServer DS20E OpenVMS systems include pre-installed software, BaseG > license with System Manager license and Enterprise Integration ServercH > License Package for OpenVMS V3.0A.  AlphaStation DS20E OpenVMS systemsE > include pre-installed software, Base license, Concurrent Use 1-usere license,@ > NAS 150 Client license, and Compaq Open3D traditional license. >- > ES40:-G > AlphaServer ES40 OpenVMS systems include pre-installed software, BasebG > license with System Manager license and Enterprise Integration ServernE > License Package for OpenVMS V3.0A AlphaStation ES40 OpenVMS systemss includetJ > pre-installed software, Base license, Concurrent Use 1-user license, NAS 150 E > Client license, Compaq MMS RT license and Compaq Open3D traditional, license. >yK > Note - all of the above systems include: Service and Support-Protected by H > Compaq Services including a 3-year on-site hardware warranty with nextJ > business day response. Software warranty is a 90-day telephone advisory. > F > More information on what is contained in the "Enterprise Integration Server7 > License Package for OpenVMS" package can be found at:v? > http://www.digital.com/info/SP6475/SP6475HM.HTM (EIP pointer) G > http://www.digital.com/info/SP6298/SP6298HM.HTM (NAS150 license info)c >s
 > Regards, >d > Kerry Main > Senior Consultant, > Compaq CanadaF > Professional Servicesi > Voice : 613-592-4660 > FAX   : 819-772-7036 > Email : kerry.main@compaq.come >c >s >  > -----Original Message-----9 > From: Richard B. Gilbert [mailto:DRAGON@COMPUSERVE.COM]r' > Sent: Thursday, June 29, 2000 8:41 PMl > To: Info-VAX@Mvb.Saic.Comr9 > Subject: Re: OpenVMS clusters vs other systems clustersw >, >nI >         Since I bought the systems in question not much more than sevenaK > weeks ago, I think I am entitled to speak about the "recent past".  Threee? > different Compaq Resellers (Authorized) quoted me on the samet5 > configuration.  I'd say it was generally available!s >t? >         I'm sure that these systems might have been availablegL > somewhere/somewhen without the Enterprise Integration Package but so what? >aJ >         If you prefer to discount the evidence that doesn't support your > point. . . . >' >a% > Message text written by "Bill Todd" I > >How nice for you!  But the fact that you bought one configuration saysiF > nothing about the existence of others at that time, let alone in the recent > past.  > G > Too bad someone who *knows* both the current and historical situation  can'tt  > take the time to respond here. >d > - bill > = > Richard B. Gilbert <DRAGON@compuserve.com> wrote in message,3 > news:200006291836_MC2-AAA3-2754@compuserve.com...o >         Bill,t >uK >         Try again.  I didn't just "investigate", I bought two ES40-2 witheJ > VMS license.  They also shipped with an "Enterprise Integration" package7 > which did include TCP/IP and a bunch of other things.l > % > Message text written by "Bill Todd":J > >Only a couple of months ago, a friend who investigated the situation (IK > suspect thoroughly, since low-end VMS issues are of considerable interest  > toJ > him) reported that the base VMS license available in the low-end pricingE > tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack andg
 > friends,H > and cost around $1200.  Now the least expensive package listed for the DS10K > reportedly *does* include the TCP/IP stack and friends, and costs severalmJ > times that amount (haven't heard whether the old, $1200 base package wasA > actually discontinued, or is just something you have to ask fors > specifically > to find out about it).<  >n > <  >  >s   ------------------------------   Date: 29 Jun 2000 23:45 CST ' From: carl@gerg.tamu.edu (Carl Perkins)F7 Subject: Re: OpenVMS clusters vs other systems clusterse- Message-ID: <29JUN200023455412@gerg.tamu.edu>   9 "Larry D Bohan, Jr" <LBohan@dbc.spam_less..com> writes...eF }On Wed, 28 Jun 2000 20:19:19 -0400, "Bill Todd" <billtodd@foo.mv.com> }wrote:tI }>Only a couple of months ago, a friend who investigated the situation (IrN }>suspect thoroughly, since low-end VMS issues are of considerable interest toJ }>him) reported that the base VMS license available in the low-end pricingN }>tier (DS10, DS20, ES40) indeed did not include the TCP/IP stack and friends,M }>and cost around $1200.  Now the least expensive package listed for the DS10tK }>reportedly *does* include the TCP/IP stack and friends, and costs severalfJ }>times that amount (haven't heard whether the old, $1200 base package wasN }>actually discontinued, or is just something you have to ask for specifically }>to find out about it). }  }??? } * }I can't speak for the DS10 (workstation) < }but DS20's (and likely, ES40's) come with the EIP bundle.   }ie, } & }DIGITAL Enterprise Integration Server } @ }DIGITAL Enterprise Integration Server for OpenVMS, Release 2.0,G }license packages are included with most OpenVMS AlphaServer systems.  n  6 This would be included in the standard configurations.  E But you can buy your DS20 (or whatever) bare naked without an OS (the E "linux ready" configuration). Then you could (and possibly still can)0J buy *just* the VMS license without the EIS package. This would, of course,D not come with the EIS related licenses, so you wouldn't have TCP/IP.  K But that's not the normal way of doing things. I expect you can buy servers M from Sun in some "odd" configurations too, if you do it on purpose instead ofh# buying the standard configurations.    --- Carl   ------------------------------  % Date: Thu, 29 Jun 2000 14:25:54 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>r; Subject: Re: OpenVMS loses big, was:  RE: Compaq advertisesi( Message-ID: <8jg49o$62h$1@pyrite.mv.net>  8 Tim Llewellyn <tim.llewellyn@bbc.co.uk> wrote in message# news:395B88AC.5AABDFF9@bbc.co.uk...(   ...S  K > Not that stupid write thru/write back cache issue again, David? If peoplen cannotI > appreciate this issues involved in performance versus caching strategy,  surely: > they deserve evey lost/corrupted nibble they experience.  K Rather, if VMS bigots can't appreciate them, they deserve to see the systemoL they like go down the drain:  integrity is not at issue here, but you appear  incapable of understanding that.   ...-  K > David, and those few bytes of data could mean the difference between lifeGI > and death for someone with a terminal illness that some geneticists arei tryingK > to help a few years down the road of the genome project, because they are 6 > running on a windoze box without ECCram or whatever. >aH > As someone who learned to do real life reatime science on RSX and VMS,H > Unix and Windows (whatever variety) scared the shit out of me then (10
 years ago) > as it does now.t >i8 > Of course, if you really don't care about your data...  J ... you use RMS sequential files, which buffer writes just like Unix does,G just usually not for as long (so your *chances* may be a bit better, if I chance is what you're relying on rather than correct application design).g  K If you *do* care about your data, you use $FLUSH with RMS when appropriate, J or fsync on Unix (at pretty much the same points).  The difference is that> you get rewarded with considerably better performance on Unix.   ...u      Well, besidesK > > their not wanting to rewrite their code, a lot of what they do involvesB theeH > > generation and manipulation of a zillion small files, and OpenVMS is turtle& > > slow at that particular operation. > >t >  > Application design issue.   J Not on Unix, it isn't.  Are you saying that it's no problem that VMS oftenI performs like a pig for applications not specifically designed around itsuH limitations?  Doesn't sound like a really good market-growth strategy to me...r   - bill   ------------------------------   Date: 29 Jun 2000 18:19:22 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog); Subject: Re: OpenVMS loses big, was:  RE: Compaq advertisess, Message-ID: <8jg3va$q40@gap.cco.caltech.edu>  Y In article <Fwx92y.3qt@world.std.com>, "Terry C. Shannon" <shannon@world.std.com> writes:i >  >> However - >>M >> Does the COE project discussed in Terry Shannons articles not address someiM >> of the issues you raise in the attached ie. combining the good features ofeE >> OpenVMS with some of the core functions associated with UNIX OS's?e >vM >(Terry here...) COE not only will equip OpenVMS with "Solaris-like" APIs, itfF >will guarantee that OpenVMS remains viable for a minimum of 15 years. >Probability Factor: 0.9999...  I It would have been viable for 15 years even without the COE - but only in I the few niches where it is currently competitive.   If the COE is to let  6 OpenVMS escape from those niches it must deliver BOTH:  $   1.  effortless Unix compatibility 0   2.  speeds equivalent to Tru64 and Linux/Alpha  L Funny thing in a way that they are going for "solaris-like" APIs when Tru64 J compatibility would in many ways be more natural.  But they didn't make up" the COE standard, and that's that.  M >Seems to me that $100M in INCREMENTAL NEW OPENVMS business in 1FQ00 ought tor >say something...w >g  E Care to hazard a guess as to the amount of that growth which is _not_eL attributable to "transaction processing in data centers"?   Or how about an G estimate of the market losses outside of that lucrative niche which ares: being more then covered by income from growth within it?    L OpenVMS seems to be doing well in that market and terribly everywhere else.    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu > Manager, sequence analysis facility, biology division, Caltech   ------------------------------    Date: 29 Jun 2000 16:03:59 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)u; Subject: Re: OpenVMS loses big, was:  RE: Compaq advertises@+ Message-ID: <GQI1aC+b+oKV@eisner.decus.org>   a In article <8jg3va$q40@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes: [ > In article <Fwx92y.3qt@world.std.com>, "Terry C. Shannon" <shannon@world.std.com> writes:s >>
 >>> However -w >>>nN >>> Does the COE project discussed in Terry Shannons articles not address someN >>> of the issues you raise in the attached ie. combining the good features ofF >>> OpenVMS with some of the core functions associated with UNIX OS's? >>N >>(Terry here...) COE not only will equip OpenVMS with "Solaris-like" APIs, itG >>will guarantee that OpenVMS remains viable for a minimum of 15 years.d >>Probability Factor: 0.9999...s > K > It would have been viable for 15 years even without the COE - but only inhK > the few niches where it is currently competitive.   If the COE is to let o8 > OpenVMS escape from those niches it must deliver BOTH: > & >   1.  effortless Unix compatibility 2 >   2.  speeds equivalent to Tru64 and Linux/Alpha > N > Funny thing in a way that they are going for "solaris-like" APIs when Tru64 L > compatibility would in many ways be more natural.  But they didn't make up$ > the COE standard, and that's that.  C Both Solaris and Tru64 are COE certified.  So is HP-UX.  Windows NTnF is grandfathered in.  I have no idea what versions of the COE standard apply to these various systems.    ------------------------------    Date: 29 Jun 2000 16:02:42 -0500* From: young_r@eisner.decus.org (Rob Young); Subject: Re: OpenVMS loses big, was:  RE: Compaq advertises + Message-ID: <03aeLxDh6349@eisner.decus.org>-  a In article <8jg3va$q40@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:e[ > In article <Fwx92y.3qt@world.std.com>, "Terry C. Shannon" <shannon@world.std.com> writes:t   > G > Care to hazard a guess as to the amount of that growth which is _not_ N > attributable to "transaction processing in data centers"?   Or how about an I > estimate of the market losses outside of that lucrative niche which aren< > being more then covered by income from growth within it?   > N > OpenVMS seems to be doing well in that market and terribly everywhere else.  >    	VMS has its niches. 	Tandem has its niches too.e 	Linux has its niches too.  / 	VMS niches aren't growing fast enough for you?   ? 	Let's shed a tear for the Netware bigots.  Got a few around meqB 	here.  The really sad fact is they are less than half the size of@ 	VMS in annual revenue and their revenues are tailing off badly.  / 	There's a dying OS if you want to pick on one.t   				Robi  O *******************************************************************************p,                                  RIP NetWareO *******************************************************************************o   ------------------------------   Date: 29 Jun 2000 16:53:37 PDTT From: Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515); Subject: Re: OpenVMS loses big, was:  RE: Compaq advertises.3 Message-ID: <88QiedE5WIdL@mccdev.slac.stanford.edu>d  g In article <GQI1aC+b+oKV@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:tc > In article <8jg3va$q40@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:k [...]nO >> Funny thing in a way that they are going for "solaris-like" APIs when Tru64 hM >> compatibility would in many ways be more natural.  But they didn't make upb% >> the COE standard, and that's that.t > E > Both Solaris and Tru64 are COE certified.  So is HP-UX.  Windows NTn > is grandfathered in. ...      ^^^^^^^^^^^^^^^^e  D         Gack!  The new kid on the block is "grandfathered in"???  OnE     what basis?  Oh, I know, on the basis of BGinc's grip on everyonet2     else's short hairs...  Yee gads, what a world.           -Ken -- oM  Kenneth H. Fairfield            |  Internet: Fairfield@SLC.Slac.Stanford.Eduo:  SLAC, 2575 Sand Hill Rd, MS 46  |  Voice:    650-926-2924:  Menlo Park, CA  94025           |  FAX:      650-926-3515N  -----------------------------------------------------------------------------B  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...   ------------------------------  % Date: Thu, 29 Jun 2000 22:16:31 -0500a7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>/5 Subject: Re: Oracle Press Release, incl. OpenVMS infon, Message-ID: <395C110F.D888B28@earthlink.net>   "Main, Kerry" wrote: > ! > As a followup to Steve's note -y > K > A few pointers for those folks who have beed asking for more applicationst > and marketing of OpenVMS:  > N > <http://www.oracle.com/corporate/press/index.html?228177.html> (Oracle Press
 > release) > ; > <http://www.oracle.com/tellmemore/?228177> (Tell me more)i > N > <http://www1.compaq.com/pressrelease/0,1494,wp%7E14583_2%21ob%7E31866_1_1,00 > .html> (Compaq Press release)v > I > And in case, some folks missed the other posting (and I like the splashs > stuff :-)n/ > <http://www.openvms.digital.com/e-postcard1/> / > <http://www.openvms.digital.com/e-postcard2/>-J > (under each url is a pointer that you can save and run directly on a PC) [snip]  ; Now, how do we go about getting this out to the mass media?e  0 Preaching to the choir = spitting into the wind!  H (Pardon my tone, but I don't know how to drive that point home anymore!)   -- i David J. Dachteray dba DJE Systems," http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/n   ------------------------------  % Date: Thu, 29 Jun 2000 22:33:48 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>p Subject: OT: "Open Windows"a- Message-ID: <395C151C.319630E8@earthlink.net>d  E While preparing an update (and move) of my website, I happened across 
 this link:  * http://www.geocities.com/openwindows_2000/  = (Usual caution about cookies, ads, etc. re: Geocities apply.)e  @ This is a follow-on to FreeDOS, which is where I found the link.  G Looks like the free software movement continues to nip at BG's heels...0   -- F David J. Dachtera. dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/c   ------------------------------  % Date: Fri, 30 Jun 2000 00:16:50 -0500d) From: "John E. Malmberg" <wb8tyw@qsl.net>e. Subject: Re: RS232 CTS/RTS flow control on VAX7 Message-ID: <087501bfe252$67a622c0$020a0a0a@xile.realm>a   <nospam@nohost.no.net> wrote:p >M > Greetings,? >           is the use of RS232 hardware flow control on a VAX,i4 > in particular, the CXY08 board described anywhere.  0 I would recommend looking in the I/O Users Guide  = > This is needed for flow control for a device on our system.e5 > XON/XOFF cannot be used because of the application.    A common occurrence.  9 > The documentation on modem control which I got from DECi< > aka Compaq states that if CTS is not "on" then VMS assumesA > a login. If this is so that it would seem that CTS would not be 8 > usable for flow control. I have set the terminal port,7 > "nointeractive" but aside from changing more than oneU9 > terminal attribute I don't know what it does since it'sR > not described in the help.  I This seems to be comming up enough to make it a candidate for the OpenVMSa FAQ.  ? How to I set a terminal port up for getting data from a device?r  E While VMS boots, interactive logins are inhibited from occuring until ! SYSTARTUP*.COM is done executing.o  C Terminal devices have two settings, their active settings and theirvF permanent settings.  When a terminal device is allocated the permanent+ setting is copied to be the active setting.p  K A terminal device that is not allocated and has /TYPEAHEAD set will respondo$ to stimulus with a USERNAME: prompt.  F To prevent this from interfering with your application you must do the
 following:  K 1. In SYSTARTUP_*.COM you must set the device to have the /NOTYPEAHEAD/PERM-
 attribute.  H While you are in there, you can set all of the other attributes that youD need like your handshaking, and the device protection and ownership.  F 2. When your application needs to access the terminal, it should firstI allocate the device, and then turn TYPEAHEAD.  But only turn it on for an H active setting, not the permanent setting.  This can be done from DCL or from your application program.  J 3. Run your program.  If the process ends for any reason, the port will beH deallocated and the typeahead will be turned off.  This will prevent VMS, from trying to log your widget in as a user.   -Johnt wb8tyw@qsl.network   ------------------------------  # Date: Fri, 30 Jun 2000 04:15:10 GMTu2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com> Subject: Re: Sub-DS10 Alphaw2 Message-ID: <i9V65.73$ma.1514@typhoon.aracnet.com>  % Ed Wilts <ewilts@mediaone.net> wrote:sE > Get rid of the darn keyboard & mouse!  I'm accumulating too many of H > these as it is.  My systems are servers, not desktops, and as such areG > connected to a cluster console system that doesn't require a keyboardl > and mouse for every server.o  I Agreed!  I'd like one of these for a home box if it was affordable, but I K don't need any more keyboards or mice either, and every little bit helps to L drive the cost down.  Besides even as a home box I'd probably be using it at- least partially in a server configuration :^)n   			Zane    ------------------------------    Date: 29 Jun 2000 15:59:31 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) + Subject: Sub-DS10 Alpha (was: VAX on Intel)s+ Message-ID: <WeEas191Y57+@eisner.decus.org>r  Z In article <395AFC7E.CF596B6B@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > Nigel Arnot wrote:  D >> Creating a sub-DS10 Alpha hardware platform will have significantD >> development costs. If Compaq does not believe that they will sellC >> in sufficient quantities, that's a sensible reason not to do so.nC >> (I'm not arguing that they are right, and I suspect that if theydC >> add the potential Linux market for a really cheap Alpha platformy1 >> they are wrong. But I don't have the figures.)- >  > You got my vote on this one.  = Ok, so what features of the DS10L would the assembled expertsF> suggest Compaq omit to make a more affordable sub-DS10 Alpha ?   ------------------------------  % Date: Thu, 29 Jun 2000 15:57:29 -0400b. From: Hank Vander Waal <hvanderw@novagate.com>/ Subject: RE: Sub-DS10 Alpha (was: VAX on Intel)o8 Message-ID: <000001bfe204$41d13740$2b96a8c6@mscmain.com>  " I can not resist -   The margin!!!   Hank Vander Waal   -----Original Message-----@ From: Larry Kilgallen [mailto:Kilgallen@eisner.decus.org.nospam]% Sent: Thursday, June 29, 2000 5:00 PMr To: Info-VAX@Mvb.Saic.Comd+ Subject: Sub-DS10 Alpha (was: VAX on Intel)     < In article <395AFC7E.CF596B6B@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes:s > Nigel Arnot wrote:  D >> Creating a sub-DS10 Alpha hardware platform will have significantD >> development costs. If Compaq does not believe that they will sellC >> in sufficient quantities, that's a sensible reason not to do so.uC >> (I'm not arguing that they are right, and I suspect that if theytC >> add the potential Linux market for a really cheap Alpha platformD1 >> they are wrong. But I don't have the figures.)E >r > You got my vote on this one.  = Ok, so what features of the DS10L would the assembled expertsV> suggest Compaq omit to make a more affordable sub-DS10 Alpha ?   ------------------------------  % Date: Thu, 29 Jun 2000 22:04:11 +0200w= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>d/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)c) Message-ID: <395BABBB.A0AA5D72@gtech.com>f   Larry Kilgallen wrote:\ > In article <395AFC7E.CF596B6B@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > > Nigel Arnot wrote:F > >> Creating a sub-DS10 Alpha hardware platform will have significantF > >> development costs. If Compaq does not believe that they will sellE > >> in sufficient quantities, that's a sensible reason not to do so.0E > >> (I'm not arguing that they are right, and I suspect that if theysE > >> add the potential Linux market for a really cheap Alpha platformm3 > >> they are wrong. But I don't have the figures.)t > >m  > > You got my vote on this one. > ? > Ok, so what features of the DS10L would the assembled expertss@ > suggest Compaq omit to make a more affordable sub-DS10 Alpha ?  $ Good question - very good question !  6 But what would a DS05 delivered early 2001 consist of:# - a board with a 667 MHz Alpha chipg - a PCI busr - 128 MB memory  - a 18 GB IDE disk - a CD drive - a floopy drive - a power supply - a cabinet 8 - keyboard & mouse (let us make monitor optional, people/   often has an old or want a new bigger anyway)d  C It is quite obvious that it is not the costs of the inividual partsi that is the problem.  $ The biggest costs must be the other: - overhead of design of systemD - overhead of testing system with various software and hardware (big task !)a - overhead of sales costso" - overhead of administrative costs - profit - logstic costsx - cost of 3 year warrantye  G All theese fixed overheads makes it very difficult for a low volume box 1 to compete with the very high volume x86 systems.t  ; It is not easy to go much further withot specific knowledgeu about Comaqs cost structure.   But my recommendation would be:s:   - just make one variant with a life-span of 12-24 months&     to make volume as high as possible>   - limit supported hardware & software to minimize test costs<   - sell it on the web to minimize sales and logistics costs   - cut bureacracy !!!  D Today third part suppliers can seel VMS capable Alphas for 2000-2500 USD,D whch tells me a something about both what is pssible and what is not possible   Arne   ------------------------------  # Date: Fri, 30 Jun 2000 02:22:49 GMTl$ From: Ed Wilts <ewilts@mediaone.net>/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)t, Message-ID: <395C047A.E9AFF712@mediaone.net>   Arne Vajhj wrote: > 8 > But what would a DS05 delivered early 2001 consist of:% > - a board with a 667 MHz Alpha chipt
 > - a PCI bus? > - 128 MB memorye > - a 18 GB IDE disk > - a CD drive > - a floopy drive > - a power supply
 > - a cabinet : > - keyboard & mouse (let us make monitor optional, people1 >   often has an old or want a new bigger anyway)s  C Get rid of the darn keyboard & mouse!  I'm accumulating too many oftF these as it is.  My systems are servers, not desktops, and as such areE connected to a cluster console system that doesn't require a keyboardr and mouse for every server.n  E > It is quite obvious that it is not the costs of the inividual partsd > that is the problem. > & > The biggest costs must be the other:  > - overhead of design of systemF > - overhead of testing system with various software and hardware (big	 > task !)I > - overhead of sales costsO$ > - overhead of administrative costs
 > - profit  $ they don't need to make a profit :-)   > - logstic costso > - cost of 3 year warrantyO  = make 'em so they don't break and this is a zero cost item :-)e   	.../EdC   -- o Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  % Date: Thu, 29 Jun 2000 22:30:29 -050047 From: "David J. Dachtera" <djesys.nospam@earthlink.net>i/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)l- Message-ID: <395C1455.EA358E88@earthlink.net>e   Hank Vander Waal wrote:t > $ > I can not resist -   The margin!!!  D ...or at the very least, trim it to the bone (try not more than 10%)   Say, "loss leader"...t   >  > -----Original Message-----B > From: Larry Kilgallen [mailto:Kilgallen@eisner.decus.org.nospam]' > Sent: Thursday, June 29, 2000 5:00 PMs > To: Info-VAX@Mvb.Saic.Comu- > Subject: Sub-DS10 Alpha (was: VAX on Intel)  > > > In article <395AFC7E.CF596B6B@tsoft-inc.com>, David A Froble > <davef@tsoft-inc.com> writes:  > > Nigel Arnot wrote: > F > >> Creating a sub-DS10 Alpha hardware platform will have significantF > >> development costs. If Compaq does not believe that they will sellE > >> in sufficient quantities, that's a sensible reason not to do so.iE > >> (I'm not arguing that they are right, and I suspect that if theygE > >> add the potential Linux market for a really cheap Alpha platformo3 > >> they are wrong. But I don't have the figures.)m > >@  > > You got my vote on this one. > ? > Ok, so what features of the DS10L would the assembled expertsn@ > suggest Compaq omit to make a more affordable sub-DS10 Alpha ?     -- e David J. Dachteras dba DJE Systemso" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Thu, 29 Jun 2000 22:50:38 -0500l7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>a/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel) - Message-ID: <395C190E.6464219A@earthlink.net>    Larry Kilgallen wrote: > \ > In article <395AFC7E.CF596B6B@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > > Nigel Arnot wrote: > F > >> Creating a sub-DS10 Alpha hardware platform will have significantF > >> development costs. If Compaq does not believe that they will sellE > >> in sufficient quantities, that's a sensible reason not to do so.aE > >> (I'm not arguing that they are right, and I suspect that if theynE > >> add the potential Linux market for a really cheap Alpha platform 3 > >> they are wrong. But I don't have the figures.)- > >W  > > You got my vote on this one. > ? > Ok, so what features of the DS10L would the assembled expertso@ > suggest Compaq omit to make a more affordable sub-DS10 Alpha ?  F How 'bout dropping the double-digit margin percentage down to a singleH digit? T'would work wonders, no doubt! T'would work even greater wonders5 to also do the same for OpenVMS licenses (Hi, Bill!).c   -- e David J. Dachterab dba DJE Systemsa" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/e   ------------------------------  % Date: Fri, 30 Jun 2000 01:05:20 -0400s' From: "Bill Todd" <billtodd@foo.mv.com>h/ Subject: Re: Sub-DS10 Alpha (was: VAX on Intel)s( Message-ID: <8jh9ok$g43$1@pyrite.mv.net>  @ David J. Dachtera <djesys.nospam@earthlink.net> wrote in message' news:395C190E.6464219A@earthlink.net...e > Larry Kilgallen wrote:   ...   A > > Ok, so what features of the DS10L would the assembled expertsiB > > suggest Compaq omit to make a more affordable sub-DS10 Alpha ? >LH > How 'bout dropping the double-digit margin percentage down to a singleJ > digit? T'would work wonders, no doubt! T'would work even greater wonders7 > to also do the same for OpenVMS licenses (Hi, Bill!).s   Hi, David -y  G I think you're just not trying hard enough to come up with things I can*J disagree with.  It's reasonable for Compaq to make *some* profit on DS10s,E but anything over 20% after all costs are taken into account is a bit*I unseemly for an entry-level product (and if they're not selling that many2G anyway, there'd be negligible profit impact in cutting that margin even  lower).9  I And regardless of how the "Is there, or was there recently, a TCP/IP-lesseH VMS license at around $1200?" mystery turns out, I've said several timesD already that I believe there are reasonable justifications (based onJ industry practice with other somewhat comparable systems) one can offer toK Compaq for a VMS license - including TCP/IP and friends, VOLSHAD, and DFO -a< priced at about $1K when purchased as a package with a DS10.   - bill   >w > -- > David J. Dachteraa > dba DJE Systemsd$ > http://home.earthlink.net/~djesys/ >a< > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/.   ------------------------------  % Date: Thu, 29 Jun 2000 03:15:35 -0400"* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395AF797.EDE81339@tsoft-inc.com>s   Chris Scheers wrote:  J > But if you go into a company that does not currently have a VMS presenceG > and try to sell them on a VMS based product, they will generally show A > you the door the moment that you tell them they have to buy new2 > hardware.-  O So what type of products are we talking about here?  Nickle and dime stuff?  MyiL experiences have been that for any significant software product the requiredN hardware is obtained.  Except for add-ons, like defrag utilities and such, theM hardware is usually not an issue.  Even if it's PC type software, and all PCsVO are already in use, more are bought for the new product.  This argument doesn't  make any sense to me.e   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: Thu, 29 Jun 2000 03:36:30 -0400r* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395AFC7E.CF596B6B@tsoft-inc.com>s   Nigel Arnot wrote: > < > > It all depends on your definition of "revitalizing VMS". > >/R > > If you mean to only make VMS healthy in its remaining small market niche, thenQ > > you're right. Making VMS priced competitively isn't necessary because the fewg8 > > customers left are stuck with VMS and can be milked. > >eN > > But if you want VMS to regain some of the markets it used to have then youN > > need to compete against those systems that stole your customers during the > > last decade. > >d > J > There's two issues need separating: the hardware and the software price.   Yep!  O > Creating a sub-DS10 Alpha hardware platform will have significant development0Q > costs. If Compaq does not believe that they will sell in sufficient quantities,cN > that's a sensible reason not to do so. (I'm not arguing that they are right,H > and I suspect that if they add the potential Linux market for a reallyE > cheap Alpha platform they are wrong. But I don't have the figures.)t   You got my vote on this one.  J > The bigger issue is the VMS and VMS layered products software prices. AsL > long as Compaq keep the single band structure for everything from the ES40H > downwards, then the price of VMS on low-end platforms is going to lookE > expensive -- the lower you go, the more expensive it looks. And thetK > production cost of copies of software is very close to zero: whatever you 3 > sell it for is pretty much all positive cashflow.   P Well, not necessarily zero, but definitely in perspective to the HW cost.  WhileO VMS pricing may be good at many levels, there are aberations, and at the bottomo is one big one.i  G > So, to first order Compaq could afford to sell whatever minumum AlphanG > platform they havew running VMS for no more than the cost of the samekE > platform running Linux. Why, therefore, do they charge (much) more?e > J > The argument for so doing is second-order: probably that they don't wantG > to cannibalise their profitable high-end systems. They may worry thatfJ > customers might replace an ES40, or maybe something bigger, by a clusterG > of small cheap VMS systems. So they keep VMS expensive and VMSclusterf' > still more so so that doesn't happen.p  I I don't buy this argument at all.  Regardless of the price of the clustertN license, and the ease of managing a cluster of small systems, an ES40 is stillN the best choice if your needs match this system.  Based upon the past, they'reK really not expensive.  If you accept this argument, then a cluster of ES40sML would steal market share from department or enterprise level systems, and itO just doesn't happen.  Not when the capabilities of the enterprise level systems 
 are required.m  K > IMO, what they miss in this analysis is that a new customer for VMS needscK > to start somewhere, and it's far, far easier to start small than to startnL > big. Two of VMS's key andvantages are cluster-ability and scalability. ButD > the proportionally high software costs for the lowest VMS platformE > serve to place both of these advantages out of reach of the low-end K > customers who'd maybe LIKE a non-stop (cluster) system, but can't justifytK > the cost. So the present policy is locking out what may be a large sourceeL > of NEW customers -- the ones who can't contribute much to Compaq's profitsL > with their first small purchase, but who are most likely to come back someO > time later for a bigger system if their needs grow and they like what they've K > got. Salesmen in just about any industry know the value of "a foot in thesM > door" It's something that you can't price for a bean-counter, and somethingu& > that Compaq seem to ignore with VMS. > I > Any mention of service cost in this is a red herring. Customers wanting-J > service from Compaq will pay for it as an option. Other customers may beI > quite happy with nothing apart from access to patches vis the Internet,gQ > and if they are forced to pay for support that they don't need it's yet anothere > reason that VMS loses out. > G > So my suggestion would be that the combined cost of a software bundlerP > including VMS, Cluster, Volshad, DFO, TCPIP, and a restricted-user license forI > a programming language of choice should be set at a smallish percentage H > of the price of the hardware platform. I don't buy the cannibalisationM > argument -- in most cases someone buying a bigger VMS platform needs the IOhJ > bandwidth it provides, which a small cluster can't -- but if the low-endG > bundled cluster license was restricted to no more than three nodes, I-N > don't think it would hurt much. (You need three to build a disaster-tolerantK > cluster). The system should also come with VMS-Perl and a webserver (botheJ > open-source, but Compaq should offer full support for these to those who > want it).>  N Don't even need the restrictions, which cause problems.  Don't know if the VMSK people can affect the cost of hardware, so the DS10 system price may not besN movable, but the cost of VMS and the rest mentioned sure should be under theirL control, and could be added to the DS10 cost in a manner that keeps the baseM system cost well below $5000.  Doesn't hurt Compaq, unless HW for Linux salesyO also hurts them, and is a positive for the VMS people, another seed planted for  possible future harvest.  N > And once you've got the pricing attractive from the very bottom upwards, useL > VMScluster as the unifying concept and the one to base VMS advertising on.K > Is there any other system where you can grow from a couple of entry-levelnN > systems to a huge "mainframe" without ever having had an application outage?L > And isn't that *exactly* what a start-up e-business wants: easy, virtuallyK > unlimited scalability and no visible shutdowns or breakdowns to annoy thee > customers? > P > VMS should be competing hard in the *server* market. At the low end, it's not.G > Sometime, maybe soon, this window of opportunity will close, when theeP > competition finally catches up to where VMScluster was more than a decade ago.G > If VMS is still seen as "legacy" then, it won't get any more chances.w   Got that right!t   Dave   -- t4 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: Thu, 29 Jun 2000 03:44:00 -0400h* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395AFE40.1818C3F7@tsoft-inc.com>g  ! steven.reece@quintiles.com wrote:a >  > Nigel Arnot wrote:M > >>>The bigger issue is the VMS and VMS layered products software prices. AsrL > long as Compaq keep the single band structure for everything from the ES40H > downwards, then the price of VMS on low-end platforms is going to look@ > expensive -- the lower you go, the more expensive it looks.<<< > Q > Whilst I'm not saying that the pricing policy is right, it is worth rememberingnP > (perhaps) that the ES40 did replace the 4100 but dropped down a license group.N > The 4100 was a departmental class machine whereas the ES40 is only workgroupP > class.  This specifically means that the software for the ES40 is cheaper than > for the 4100.t  M What this effectively did was lower the cost of VMS in the workgroup class atrN the top of the class.  If you look at cost vs performance, the cost stayed theN same, but the performance rose significantly.  However, the scale didn't applyO to the low end since the cost never changed.  If the ES40 is to be considered aqN workgroup class system, then what is a DS10?  Big difference between the two. O The three pricing tiers just doesn't work for software tied to the hardware, as P VMS is.  What is needed, an many have indicated, is base VMS pricing tied to the hardware capability/cost.m   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: Thu, 29 Jun 2000 03:52:16 -0400k* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395B0030.743D33C3@tsoft-inc.com>a   JF Mezei wrote:f > * > Andrew Harrison SUNUK Consultancy wrote:5 > > So what happens when all this get added to Linux.s > >s > > 1.    It is no longer smalluH > > 2.    Its no longer as fast as it was, particularly on small systems > ...dI > > Since this is also a description of most commercial UNIX's the choicesD > > of Linux or a commercial UNIX OS becomes one that is going to be@ > > based much more on issues like applications availability and > > support, OS support etc. > N > But if Linux is still "free" (especially on large corporation with many manyJ > seats (or requirements to handle manu IP connections), and large supportJ > organisations provide as good a job of supporting it, do the proprietaryM > Unixes of the world really still have such an edge worth paying the extra ?:  N Well, the big problem here for the Unicies of the world is that they never didO have much of an edge to starrt with.  That's a real big 'IF' above with respecto to the 'support'.h   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   ------------------------------  % Date: Thu, 29 Jun 2000 04:13:18 -0400t* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395B051E.46B03911@tsoft-inc.com>e   Arne Vajhj wrote: >  > Nigel Arnot wrote:% > > > 1.  Software development costs.  > >uS > > I'd say that all the parts of VMS most relevant to an entry-level customer were O > > developed years ago (1984-90 timescale, apart from the Alpha porting). Mosto@ > > of the new stuff is aimed more toward the big-iron hardware. > I > Who pays for the software engineers and QA engineers working on VMS nowf > ?   L The same people that will pay for them if entry level systems are not sold. D Does anyone really think that the VMS licenses on DS10s are all thatO meaningful?  Compared to the prospect of many more entry level sites, with manynP more entry level people learning about VMS?  Something's gotta give first, and IP seriously doubt it's the customer's love of low cost of acquisition.  Don't comeL back with total cost of ownership.  There's been enough data gathered by nowL that anyone who's interested can see the much higher cost of operating PCs. K They're not interested.  They're not listening.  If VMS wants to grow, it's" gotta plant seeds first.   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: Thu, 29 Jun 2000 04:40:27 -0400o* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395B0B7B.5AE44A34@tsoft-inc.com>    Jeff Killeen wrote:h > ( > >  a. sell lots with low profit margin/ > >  b. sell fewer with a larger profit margin.  > I > Business 101 - The only manufactures who consistently turn a profit arenL > those who are either the highest volume manufactures, and thus achieve theD > greatest productivity, which allow for profit at low prices or theK > manufactures would offer a premium product which consumers are willing tosM > pay a premium price for.  It is not a case of simply volume equals profits.cH > You must be a high volume producer with a low cost structure.  Premium7 > products (like OVMS) do not has a low cost structure.h > G > This fact has been proven industry by industry.  The manufactures whoeG > consistently fail to make money are the ones in the middle - they arepL > neither suppliers of the highest volume product or the product that offers; > the most premium value.  If you build a graph based on...t >  > Profits  ! >             !6 >             !> >             !<- >             ------------------------ Volumer > M > ...it will almost always plots out as a U shaped curve where the low volume J > highest premium manufacturers on the left side make high profits and theJ > high volume highest efficiency manufacturers of the right side make highL > profit.  The ones in the middle always are low or no profit manufacturers. > N > This is where the "we must be the 1 or 2 supplier in the market" theory thatL > GE started came from.  A classic example of that in our industry is TandemM > (on left side) and Dell (on right side).  If Compaq was to increase volumes K > but failed to achieve a number 1 or close number 2 status they would findiE > they would not achieve the volume to offset the market leaders cost K > advantage.  They would then be faced with loosing money on every unit andeH > unable to make it up on volume.  You wouldn't even get to the point of* > addressing the issue of cost structures. > F > A company these days needs to decide if it is in the premium productL > business or the volume product business but it can't successfully within aL > product line be in both.  A premium product means extra costs.  Unless youL > are dealing with a very mature technology (laundry detergent) you can't be > both and profititable. > N > I really wonder how many current OVMS customers would be happy if Compaq didK > what would be required to its cost structure to achieve a volume product.sN > You can't offer a high tech product with premium service at volume prices...  L Not buying this argument.  Are you saying a DS10 is (or should be) a premiumO product?  If you follow this explicitly, then only the largest Wildfire systems L would be offered.  A real problem here is then where would the customers forO these premium products come from, and where would technical people to work witht them come from?l  O When you start out and money is tight, you drive a Chevy or Ford.  When you can M afford it, and are so inclined, you get the Cadillac/BMW/whatever.  Same withhN appliances, TV, etc. Doesn't work that way with computers.  With the exceptionP of IBM and speciality systems (Cray), most computer manufacturers seem to need a broad range of products.  O What's your view on the hobby licenses?  There's more than one way to advertisedO (draw attention to your product and cause people to purchase it), and the hobby D license is a form of advertising.  Low end VMS systems are from someM perspectives part of the cost of successfully continuing to sell high end VMSu systems.  O I may be wrong, but I don't think anyone is advocating lowering the cost of VMS M at any level except the smallest entry level systems.  From that perspective,aB there is no question of premium product/service at a volumn price.   Dave   -- o4 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: Thu, 29 Jun 2000 05:15:57 -0400 * From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <395B13CD.73657E97@tsoft-inc.com>t   Tim Llewellyn wrote: > N > I'd say Compaq would be better off persuing the really-low-end Alpha box (or > even$ > nVAX, if they could produce them).  N Now there's the real answer.  Won't happen.  VAX is dead, and no-one at CompaqK wants a re-birth.  However, what really pushed the popularity of VMS in theEM early to mid 1980s?  Wasn't the VAX 9000, the 8600/8650, or any of the bigger P stuff.  It began with the MVII.  The successors to this system were the MicroVAXO 3100 systems more so than the VAX 4000 systems.  You still read about old 3100s,A supporting 50-80 users, still performing the same required tasks.M  N Would N-VAX systems be profitable at today's entry level prices?  Don't know. M If yes, there's a lot of jobs they'd be great for.  Build them like a PC, PCImM slots for add-ons.  Heck, the last system, the model 88/98 are in a mid-tower O enclosure.  The second SCSI controller plugs into a slot in a manner similar tooN a PCI/ISA card. Not much chance of taking away higher level Alpha sales.  Nah, VAX is dead!   Dave   -- l4 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: Thu, 29 Jun 2000 15:53:08 -0400y' From: "Bill Todd" <billtodd@foo.mv.com>. Subject: Re: VAX on Intel?( Message-ID: <8jg9d8$c2c$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in messagea' news:395B0B7B.5AE44A34@tsoft-inc.com...e   ...0  F > Not buying this argument.  Are you saying a DS10 is (or should be) a premiumc
 > product?  J At the risk of putting words in Jeff's mouth, I think he's saying that the7 DS10 *is* a premium product, and is priced accordingly.   G   If you follow this explicitly, then only the largest Wildfire systems. > would be offered.   L Not at all:  premium products can exist in all market segments, not just the	 high end.   ;   A real problem here is then where would the customers forf# > these premium products come from,r  I From the ranks of people willing to pay a bit more for a better product -u see Hyundai/Yugo comment below.   .  and where would technical people to work with > them come from?r  C From the ranks of people interested in working on a better product.    >lI > When you start out and money is tight, you drive a Chevy or Ford.  Whene you cancJ > afford it, and are so inclined, you get the Cadillac/BMW/whatever.  Same withF > appliances, TV, etc. Doesn't work that way with computers.  With the	 exceptionnK > of IBM and speciality systems (Cray), most computer manufacturers seem to  need a > broad range of products.  L [Not wishing to get side-tracked here, but are you seriously suggesting thatL IBM doesn't have an *extremely* broad product range, which it leverages very
 effectively?]y   >yG > What's your view on the hobby licenses?  There's more than one way toa	 advertise K > (draw attention to your product and cause people to purchase it), and thel hobbys# > license is a form of advertising.   A Absolutely.  But this is a special case:  hobby licenses by theiriK restrictive nature do not directly compete with standard licenses, hence do K not affect Compaq's cash flow (save for that miniscule number of people whoeG otherwise might have purchased standard VMS licenses for non-commercialS use).o  #   Low end VMS systems are from someoK > perspectives part of the cost of successfully continuing to sell high endl VMS 
 > systems.  J Only after the long-term growth potential of high-end VMS systems has beenH established:  otherwise, no one is likely to want to bet their future onJ continued VMS competitiveness, so lowering the price just loses profit and8 revenue without compensating increases in volume - ever.   >lJ > I may be wrong, but I don't think anyone is advocating lowering the cost of VMSB > at any level except the smallest entry level systems.  From that perspective,D > there is no question of premium product/service at a volumn price.  K Of course there is.  Even Chevy and Ford don't compete directly at the verycL low end with the likes of Yugo (RIP) and Hyundai (though the latter has beenI steadily working up-market over the years) - at most, Chevy and Ford haveiI traditionally resold rebadged products of foreign very-low-end producers,u8 and/or just not competed right down to the bottom level.  J Plenty of other very successful car makers (even ignoring the likes of BMWI and Mercedes, whose 'low end' offerings start where most other carmakers' K offerings end) do very well without bottom-end offerings:  the bulge in thesK car market is in the middle, and lack of strength far below that level doeseJ not appear to be a significant disadvantage (some might even consider it a mark of prestige).  J OK, the car market may be considerably more image-driven than the computerF market, but you're the one who started the analogy (though I admit youC qualified it later).  But the point that there's room for 'premium'gG entry-level products as long as they offer something real in additionaltB value (and don't suffer in terms of familiarity or utility - e.g.,( application availability) remains valid.  G Conversely, if they *do* suffer in familiarity or utility, price paritylI won't help them (consider what the market would be for a right-hand-drivetL car with a joystick for steering/acceleration/braking and keyboard input for the other controls...).e  G By migrating Alpha toward commodity components (e.g., use of PCI and, IsF assume, commodity monitors; standard memory could help too) Compaq hasJ started to address the hardware side of this issue (I suspect that there'sG more they could do, but someone more familiar with the situation than IaJ should comment on this aspect).  By increasing VMS's support of Unix-styleJ environments (which seems to be happening via the COE route), the softwareG side will improve somewhat - but again there are likely more steps that0D could be taken to make low-end VMS use more feasible from a customer
 viewpoint.  L Your point ('way back up above) was that computer manufacturers need a broadK range of products.  But that doesn't mean that any single product of theirsuH must cover that entire range.  VMS is already unique in that it covers aL greater portion of that range than just about anything else available today.B As long as VMS offers something at the entry level that's at leastJ *reasonable* in price (and I'd claim that the DS10 hardware satisfies thatJ criterion, albeit marginally, though current VMS license pricing may not),L it's not clear that heroic efforts (such as an IA port or attempts to reduceJ Alpha hardware prices to IA levels, rather than the more modest reductionsJ that *might* be feasible) to address the very bottom of the range would beF particularly advantageous to Compaq under any circumstances, let alone= before VMS's *general* future viability has been established.r   - bill   >  > Dave >i > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596@ > DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com8 > T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 29 Jun 2000 14:56:30 -0500b% From: Chris Scheers <asi@airmail.net>V Subject: Re: VAX on Intel?O Message-ID: <13837608EA233E7A.A92A58C34621B5D8.F04B879ACF427A70@lp.airnews.net>e   David A Froble wrote:b >  > Chris Scheers wrote: > L > > But if you go into a company that does not currently have a VMS presenceI > > and try to sell them on a VMS based product, they will generally show C > > you the door the moment that you tell them they have to buy newt
 > > hardware.v > Q > So what type of products are we talking about here?  Nickle and dime stuff?  MytN > experiences have been that for any significant software product the requiredP > hardware is obtained.  Except for add-ons, like defrag utilities and such, theO > hardware is usually not an issue.  Even if it's PC type software, and all PCsiQ > are already in use, more are bought for the new product.  This argument doesn't  > make any sense to me.s    H It's not necessarilly nickel and dime stuff.  I'm talking about stuff upG to a few thousand dollars.  For argument, let's say anything that costs * less than the hardware required to run it.  E I'm also talking about smaller companies, say with up to a half dozenm	 machines.   D Unless the software is absolutely vital to the core of the business,E these companies generally will not go out and buy hardware to run thesE software.  They will definitely not buy hardware just to evaulate thea	 software.t  C Yes, if the decision has already been made to use the software, the2F hardware will be obtained.  (Deciding to obtain the hardware is a part% of the decision to use the software.)t  @ But how do you get a decision to use the software when you can'tG evaluate the software inhouse because you don't have hardware to run it0 on?r  G And having to obtain hardware to run the software effectively increasesgF the cost of the software, making it more likely that the decision will  be made NOT to use the software.   Does this make more sense?  G -----------------------------------------------------------------------.$ Chris Scheers, Applied Synergy, Inc.  G 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asi@airmail.neto   ------------------------------  % Date: Thu, 29 Jun 2000 16:51:33 -0400b& From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Re: VAX on Intel?2 Message-ID: <8jgctq$tm$1@nntp9.atl.mindspring.net>  E >Not buying this argument.  Are you saying a DS10 is (or should be) ao premiumn	 > producte  H Nope I am saying below that OVMS is the premium product.  If tomorrow byJ magic DS10's sold for the same HARDWARE price as a Dell Windows Server boxF it wouldn't matter.  OVMS needs to sell at a premium price in order toJ deliver the service we have come to know and love.  Remember business doesK not just look at the hardware box price but the price of the whole "server"w  including and required software.  E This whole topic IMHO has missed the point that it is the cost of thee software and hardware together.x  ) > What's your view on the hobby licenses?   L My view on hobby licenses that they are a great thing but by definition that are not a commercial product.-     --   Jeff Killeen - www.Killeen.cc3E =====================================================================X7 "David A Froble" <davef@tsoft-inc.com> wrote in messagee' news:395B0B7B.5AE44A34@tsoft-inc.com...  > Jeff Killeen wrote:a > >v* > > >  a. sell lots with low profit margin1 > > >  b. sell fewer with a larger profit margin.u > >rK > > Business 101 - The only manufactures who consistently turn a profit areiJ > > those who are either the highest volume manufactures, and thus achieve the F > > greatest productivity, which allow for profit at low prices or theJ > > manufactures would offer a premium product which consumers are willing toF > > pay a premium price for.  It is not a case of simply volume equals profits.J > > You must be a high volume producer with a low cost structure.  Premium9 > > products (like OVMS) do not has a low cost structure.s > >aI > > This fact has been proven industry by industry.  The manufactures who I > > consistently fail to make money are the ones in the middle - they areeG > > neither suppliers of the highest volume product or the product that  offers= > > the most premium value.  If you build a graph based on...s > >g > > Profits  ! > >             !t > >             !. > >             !a/ > >             ------------------------ Volume0 > >eH > > ...it will almost always plots out as a U shaped curve where the low volumeL > > highest premium manufacturers on the left side make high profits and theL > > high volume highest efficiency manufacturers of the right side make high? > > profit.  The ones in the middle always are low or no profitV manufacturers. > >-K > > This is where the "we must be the 1 or 2 supplier in the market" theorye thatG > > GE started came from.  A classic example of that in our industry is  TandemG > > (on left side) and Dell (on right side).  If Compaq was to increase  volumeshH > > but failed to achieve a number 1 or close number 2 status they would findG > > they would not achieve the volume to offset the market leaders costwI > > advantage.  They would then be faced with loosing money on every unitu andcJ > > unable to make it up on volume.  You wouldn't even get to the point of, > > addressing the issue of cost structures. > >eH > > A company these days needs to decide if it is in the premium productL > > business or the volume product business but it can't successfully within ayJ > > product line be in both.  A premium product means extra costs.  Unless youfK > > are dealing with a very mature technology (laundry detergent) you can'tl be > > both and profititable. > >tL > > I really wonder how many current OVMS customers would be happy if Compaq did D > > what would be required to its cost structure to achieve a volume product.F > > You can't offer a high tech product with premium service at volume	 prices...f >iF > Not buying this argument.  Are you saying a DS10 is (or should be) a premiumhI > product?  If you follow this explicitly, then only the largest Wildfire  systems J > would be offered.  A real problem here is then where would the customers forrL > these premium products come from, and where would technical people to work with > them come from?e >sI > When you start out and money is tight, you drive a Chevy or Ford.  Whena you cancJ > afford it, and are so inclined, you get the Cadillac/BMW/whatever.  Same withF > appliances, TV, etc. Doesn't work that way with computers.  With the	 exceptionfK > of IBM and speciality systems (Cray), most computer manufacturers seem to  need a > broad range of products. > G > What's your view on the hobby licenses?  There's more than one way toe	 advertiseeK > (draw attention to your product and cause people to purchase it), and theu hobbynF > license is a form of advertising.  Low end VMS systems are from someK > perspectives part of the cost of successfully continuing to sell high endl VMSy
 > systems. > J > I may be wrong, but I don't think anyone is advocating lowering the cost of VMSB > at any level except the smallest entry level systems.  From that perspective,D > there is no question of premium product/service at a volumn price. >h > Dave >r > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596@ > DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com8 > T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 29 Jun 2000 05:22:20 -0400e* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX/VMS networkingy- Message-ID: <395B154C.F832DFF9@tsoft-inc.com>    rbcannon wrote:d > M > My company has pulled a Microvax 3100 running VAX/VMS v5.4 out of mothballstC > and wants some data off of it. What is the command/procedures foraL > configuring the Microvax to operate on ethernet (TCP/IP). I want to ftp toK > the Microvax from an HP-UX Unix workstation. It is currently connected on M > the network, but I am unable to ping the Microvax and cannot find a network K > configuration command. At one time, the Microvax was networked, but maybes' > lost the config data upon power down.f > -- > /rcs > rcannon@ieee.org  P Real good chance this system didn't have TCP/IP on it.  What was it working with when it was on the network?   / Shutdown would not lose any configuration data.s   Dave   -- h4 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.362 ************************ PA  15486   ------------------------------  % Date: Thu, 29 Jun 2000 05:15:57 -0400 * From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX ox	a	8]a-F2ɓ 
xRx/Ok"o;ז8fXbSƕ⍿;
LZ}5Wզr]a.
mX8c^K "`7v>=`!p
V'3	 X8r@ė"	fYC4P
ĕ
j1g ^`t=hJI|u.WU;-R7BV]ONטVd"BAMzINigzM6}U8\: n)%RTL	96ɞM"#tC{m)'3M/FnYU:ھ]_踕6ڍRsFJf魙JϮRK
&ƄpTCr Z,b%4&ͷ@Mf y
^m:%rj徒F?*/ϞOe	$̠cBf:dtk-݃wt2u[vcV-֎rl
e$[[fMDE[Řaw!V6_OY@`D\+cPa+7+m^Nޯ'IQG3kNjES_+E
)eEkz[BB>p}C&^
7S v}Ѿ[ё׈4ŵ_ߔe-tj(:0Ui~v=pG g1^@AS +V%?ۢ"j$qJ#ʅXFsַ
rC*Ɵ.k6ʞ8D$Z'XsF }Y(WjFWl ߁Q+MmXQa`߈̿5z=@KI}g&p
vMqߑoh:-q.
rog`pwV"$7z,e$>=bX=F; CP{NQxϼ QAU=*~OET=
=|>l_g7`|8!AXr %[[5k@rYlVyH\zXw=e`X#r'aU=P`*pnվ'8"SF0'Rl =wL088~"BnK $	#~tE0kLSbGo%Ckh`ܿ?z8t}©^G0'#L R^~Xg3ZhUT
1%lbʫ
	#NCC)I"'5	a=Y<!0;
΅5uapO,cа3Bs*(_	M01醂?_G
#10bx'A[@ὰs/m&9.X%%w.ocXvF)-E=w%K`Pow@`а_W
|N5/UPf
O9a)uBːIDk 8Uq
6b:VO[^
 C`49Fٕ<U`MA?hX9/

"nTeH\68,pV#lSo=Zvٲ5iu;
/m`3^(w ]@PBX;Aiy+Ө#=Duң9<
݁xcGHrz_,h7FT"|n7@NV	<ɂjeJʉkfgਰ@ -J>!X:/2oO U{Bhk>^1l #zq'Y@0m[ygaNbSUd>[`жݔΑAbUDs[N$ᮑU* Kz?1p~#_VqFSٳ쨭 LN\@kB{OXU
Ky;֔+3\s(a(
Dg@ϱ# ZM aE XƊYP(iK*&ZGU "XKrǉ@2y8v54ڃ=3@oE7 Y+cIepkL%%(EҽY
"R>]JH];_W%Pw#)y8MՖ] P	QbIOʤ\4otbcnJ0Kx~f_na0T,p.v?gtTL#Nɞ{b`/0ciͲ~xrK0F~ً}0"\/ZZ-%
o/tL	TGX
ɍ)EV49j	8g7>U+jqubr%c%'co[0r,
Nbb-;>G=êMX!f9`_ρрU401d:B>`t\Ck  mrcěc)F:YHAXu>VU\o`S]u˲##f"o`qB{j}Tbգ%ӘS
L
iJ)OJ$(,Y#İO& RFݡYilռ_(emuöq\uiQJ	Y{iN25Ҏ n8[]/*,	kƕNȺ62PrYPp]}X7"< o5Ⱥ^%tA#$>Fl^Mx>\A>q.~Q̈́mX>X~o6ԄQvX-Z0`׽CeksW%@{1F.PrM.q|Ec1oGR>idgW|KmdUY^}֗\&࠸d Zc&FA̓f4at-{Pl,D%Qҕe?
,0GPUA VP.g&WACVe!Z(]s:HѪ=x81v)Z?`s#IŎ]1wA^z)-ҁTǟ56mѳO | &PvH{`}m1;
 a2#-cOdxTfODn|߀umMd(k)5_d% J
YEs r`r5dTRu$́L'8sJ=_˲0"?|P|J  0`X g8dur` 29Jhxz,isE@rS	JD.<';)2u Be#& Ibi FRE؉TGS^XFo J`bH.FN%Yq2τo<[-ۦ~8!"