1 INFO-VAX	Sun, 04 Jun 2000	Volume 2000 : Issue 310       Contents:+ Format of Help Files (SYS$HELP:HELPLIB.HLB) / Re: Format of Help Files (SYS$HELP:HELPLIB.HLB) " Re: Pipe throughput, sigh, slow..." Re: Pipe throughput, sigh, slow... Re: VAX on Intel? 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever) 7 Re: VMS File Caching Futures (Was: Re: Andrew whatever)  RE: Wildfire Announcement   F ----------------------------------------------------------------------  # Date: Sun, 04 Jun 2000 01:40:47 GMT  From: tsm@palindrome.org4 Subject: Format of Help Files (SYS$HELP:HELPLIB.HLB)) Message-ID: <8hcc2t$bn9$1@nnrp1.deja.com>   < I was wondering if the format of help files (*.HLB) files is- documented, or if it is a proprietary format.   C What I want to do, basically, is transfer SYS$HELP:HELPLIB.HLB to a F Linux computer, and then write a clone of the HELP program which wouldF be able to read that file. I know it is an indexed file, so I would be= of course willing to write a program to transfer it into some : intermediate format which the Linux computer could handle.  E Any ideas? I do have the complete VMS documentation set, but I do not G know what utilty to look at -- I am not even sure which program creates  help files!    Thanks for any insight.    Regards,   Terry Murphy   http://www.palindrome.org         & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Sat, 03 Jun 2000 21:59:14 -0400 * From: David A Froble <davef@tsoft-inc.com>8 Subject: Re: Format of Help Files (SYS$HELP:HELPLIB.HLB)- Message-ID: <3939B7F2.21D8FC83@tsoft-inc.com>    tsm@palindrome.org wrote:  > > > I was wondering if the format of help files (*.HLB) files is/ > documented, or if it is a proprietary format.  > E > What I want to do, basically, is transfer SYS$HELP:HELPLIB.HLB to a H > Linux computer, and then write a clone of the HELP program which wouldH > be able to read that file. I know it is an indexed file, so I would be? > of course willing to write a program to transfer it into some < > intermediate format which the Linux computer could handle. > G > Any ideas? I do have the complete VMS documentation set, but I do not I > know what utilty to look at -- I am not even sure which program creates 
 > help files!  >  > Thanks for any insight.  > 
 > Regards, >  > Terry Murphy >  > http://www.palindrome.org  > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.   J I have seen some documentation on the format of the VMS help material, butN cannot remember where.  I'd look at the information on text libraries, and theF VMS library utility.  Remember, the help utility reads from libraries.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------   Date: 3 Jun 2000 19:31:25 GMT 2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)+ Subject: Re: Pipe throughput, sigh, slow... , Message-ID: <8hbmed$guq@gap.cco.caltech.edu>  b >In article <8h8uol$9og@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes: >>three level pipe >>   2-JUN-2000 10:55:21< >>   2-JUN-2000 11:04:05                            00:08:44 >  >SYSMAN> param use active % >SYSMAN> param set defmbxbufquo 32000 % >SYSMAN> param set defmbxmxmsg  32000  >SYSMAN> write active  >  >drops this to 00:02:30.    J Unfortunately, I just discovered these values makes a hash of DECwindows. H Some byte limit is exceeded and you can't get anything to start once theK console login completes - and you can't log out either!  By trial and error K I found that both parameters can be set to 4196 and decwindows still works. G Probably I could have made the higher values work if I knew which other - parameters needed to be raised to match them.      David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------  " Date: Sat, 3 Jun 2000 22:08:38 GMT9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) + Subject: Re: Pipe throughput, sigh, slow... + Message-ID: <jw+7dQGpiAvb@eisner.decus.org>   a In article <8hbmed$guq@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:   L > Unfortunately, I just discovered these values makes a hash of DECwindows. J > Some byte limit is exceeded and you can't get anything to start once the9 > console login completes - and you can't log out either!   3 So have you formally reported this problem to DEQ ?   > Sometimes I think comp.os.vms hurts VMS by providing catharsis# that discourages problem reporting.    ------------------------------  # Date: Sun, 04 Jun 2000 01:35:54 GMT 0 From: Timothy Stark <sword7@grace.speakeasy.org> Subject: Re: VAX on Intel?8 Message-ID: <_ni_4.151494$MB.2783522@news6.giganews.com>  > In comp.os.vms David Skinner <david3@drspc.demon.co.uk> wrote:8 > Downloaded it this morning, and it seems to work well.  I > However, I'm a VAX/VMS newbie and what I really want it for is to learn  > about VMS.  G > I have a question: When I finished playing with it, I needed to bring > > the system down. As a guess, I typed SHUTDOWN, which worked.  H > However, the last message told me to halt the system at the console. IA > couldn't get a prompt, so I ended up just killing the emulator.   J > Big mistake. The next time I booted, I got 7...6...5...4...3... OH SHIT,H > Faiure (okay, I'm paraphrasing). Pesumably I screwed the filesystem or7 > something. I had to wipe the emulator and re-install.   H > Is there a magic key combination to get back to the console prompt andG > halt the system properly? Or could I have cleaned up the mess by some 5 > other means? Have I missed something in the manual?   E Yesterday I downloaded 100 MB stuff demo kit from www.charon-vax.com. I Thank to the DSL service,  I downloaded it for est. 20 minutes.  Not bad. J I installed it into my PC successfully....  I started to run the emulator.J The emulator successfully prints "Username:". :-)  I logged into system as= SYSTEM.  I immediately was asked for new password and did it.   J After I played with it, I tried to figure out how to shutdown this system.E I tried many attempts until I typed 'shutdown' and it worked so well.   A Yeah. VAX emulator seems working so well!  Good job, VAX emulator  developers.   I No, it worked fine with me when I booted second time without any problem. G I am new to VAX/VMS as "system admin" myself.  :-) I figured out how to  add accounts to system.   C In the past, I was formerly VAX/VMS user while I attended Gallaudet I University.  I developed some small programs for VAX system.  Remember me  as 11TSTARK@GALLUA? :-)    -- Tim Stark   --  C Timothy Stark	<><	Inet: sword7@speakeasy.org, sword7@firesword7.net J --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  $ Date: Sat, 3 Jun 2000 16:59:36 -0400' From: "Bill Todd" <billtodd@foo.mv.com> @ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)' Message-ID: <8hbrd8$dr$1@pyrite.mv.net>   5 Keith Brown <kbrown780@usfamily.net> wrote in message & news:39394525.677E8963@usfamily.net... >  > > Bill Todd wrote: > F > > 1) Using a language that the average developer (who, after all, is exactly ? > > the developer who *won't* do much if anything in the way of  optimization) is > > likely to select.  > >  > > > I am always amazed at the number of people who choose C (the? > language from hell) and then complain that they can't get any ? > work done. Yes, I known that C is popular, yet that fact does A > not does not always make it the best choice.  As many have said @ > before me, "we have a standardized language now, too bad it is > C".   G Whether you are amazed is completely irrelevant.  Wake up and smell the I coffee:  people use C/C++ in preference to other languages whether or not I you approve, and users evaluate system performance based in large part on K the applications such people create ('cause those are the applications they  run).    >  > > L > > 2) Making the desired behavior transparent rather than requiring that it beE > > specified (though making it easy to obtain, albeit explicitly, is 	 certainly * > > better than keeping it truly obscure). > >  > A > We certainly can't expect software developers to RTFM can we :)   I Once again, your own inclinations in this area are are irrelevant if they I don't reflect what most developers do in the real world.  Pat yourself on J the back all you want, but don't presume that this makes any difference toD the way the rest of the world works (hint:  a great many applicationH developers are in it for the money, and time spent learning a relativelyI obscure system so that their ported application will perform better there L may well not be recouped by increased sales due to that improved performance9 in that relatively unimportant - for them - environment).   K And if developers may be willing to RTFM to use Linux (or any Unix) but not F to use VMS, well, that's a reality VMS has to accept (and adjust to ifK feasible), 'cause it's behavior that's existed for the past decade-plus and G short of paying the entire software development community to attend VMS K familiarization classes there's no likelihood it's going to change any time  soon.   H But in the particular area under discussion, the more important point isL that developers *don't* have to RTFM to get good file system performance out# of Unixes whereas they *do* on VMS.   A > .  Bill, I've been using VMS for over 16 years. I never saw VMS A > while I was in school BTW, it all came after I started working. ; > In the last 2 years I have been spending significant time @ > learning Linux. RingTFM is what I have to do. I do not find it? > intuitive as you would imply, but do see many similarities to ? > VMS. I like Linux but do find that it has some funky features > > that require some learning and as many times as not they areB > more difficult to deal with than on VMS. I also find it to be no? > easier to learn than VMS, which was easy BTW. If we are to be @ > dependent on SW developers that can only write code for the OS8 > they saw in school we will never get anywhere will we?  D That's exactly how VMS got into the position it enjoys today.  And -K surprise! - the world still moves on, even if VMS doesn't keep pace with it B (in areas like acceptance and market share).  And the systems thatJ developers encountered in school are (belatedly) starting to offer some ofJ the VMS features (first extent-based file systems, then asynchrony, albeitJ sometimes limited, and most recently primitive clustering) that the market actually seems to value.  	  My point A > is that SW developers need to RTFM for ANY system they code on. - > I they don't we won't buy their SW will we?  >  > > L > > As for your other comment elsewhere, if VMS performance is 'good enough' for H > > you even if it doesn't match Unix performance, rejoice and be happy. But H > > don't assume that's 'good enough' for everyone, or even a majority -L > > especially given purchasing situations where VMS is typically the systemH > > that must justify being considered against competition that sets the6 > > expectations by virtue of its industry acceptance. > >  > @ > What my comment elsewhere said was that our VMS performance is9 > AS GOOD as Unix due to the use of external controllers.   J Not the comment I was referring to (11:39 P.M. EDT 6/2/00), which assertedJ that EFC V2 performance (in the context of otherwise default environments)J would be 'good enough' (in general, not specifically for you - and since II don't recall any other comment of yours to that effect, your confusion on H this point seems curious, though I do remember a post of yours some timeD back, which I can't find in the recent ancestry of this thread, thatJ indicated you used hardware write-back caching).  Perhaps what you mean isJ that this was what you had in your head when you wrote (in response to the= statement of my own that precedes it) what I reproduce below:    ---    >EFC V2 willJ > likely still fall somewhat short of Unix default file system performance (at ; > least for some of the better implementations, like SGI's)   > As you are fond of saying about NT, "It may not be perfect but it is good enough"   -- Keith Brown    ---     Note A > also that even though Unix does have a default performance edge < > on I/O we still chose to use HSZxx controllers on the Unix3 > systems for reliability reasons as we did on VMS.   L I'm curious what you mean by the above:  write-back caching in stable memoryB (vs. writing to disk) is purely a performance optimization, it has* absolutely nothing to do with reliability.  
   There is no = > free lunch. What Unix gains in I/O performance it looses in  > reliability.  I This is pure bullshit, and I'm getting tired of hearing it.  Even if some K Unix write-back-cache implementations may have been buggy (hell, some still J may be - I have my doubts about Linux's ext2fs), that does not reflect anyL limitation of the architecture.  I'm not familiar enough with the full rangeL of implementations to state that any are as bug-free as ODS-2 likely is, butJ there are certainly good ones out there (Veritas at least has an excellentJ reputation, and its use of a log allows it to provide good performance for synchronous writes as well).  J Most applications do not depend for their integrity on writes making it toJ disk immediately.  For the few that do, Unix provides mechanisms to ensureK this behavior (or provide 'synch' points, which is an intermediate strategy H that can be a win for a third class of applications); for the rest, UnixA default mechanisms provide good performance with *no* decrease in  reliability.  L About the only positive aspect of VMS's behavior is that an application thatG *does* depend upon the ordering and timing of disk writes but *doesn't* K understand the fact that it depends on them may luck out and work correctly G after an interruption, whereas it may be less likely to on Unix.  But I I don't think 'reliability' is the right word to apply to such a situation.   3  Go ahead, ask about the AdvFS restore we did a few 9 > months back after DU crashed before flushing the cache.   H Submit a bug report and get on with your life:  this is not a conceptual) deficiency, just an implementation error.    - bill   >  >  > --
 > Keith Brown  > kbrown780@usfamily.net   ------------------------------  % Date: Sat, 03 Jun 2000 17:19:41 -0400 * From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)- Message-ID: <3939766D.1B05FEA3@tsoft-inc.com>    Bill Todd wrote: > 7 > Keith Brown <kbrown780@usfamily.net> wrote in message ( > news:39388193.FBE81237@usfamily.net... >  > ...  > 7 > > How difficult is this in PL/I. What can be simpler?  > L > 1) Using a language that the average developer (who, after all, is exactlyN > the developer who *won't* do much if anything in the way of optimization) is > likely to select.   P Stuff a sock in it Bill.  If you're talking about C, then your average developerP is a mistake just waiting to happen, so what does it matter how fast the mistake occurs?   M > 2) Making the desired behavior transparent rather than requiring that it be M > specified (though making it easy to obtain, albeit explicitly, is certainly ( > better than keeping it truly obscure).  N When I transistioned from RSTS/E to VMS in the late 70s, RSTS was perceived byP it's users to be extremely user friendly, and VMS was just soooooo complicated. N I soon discovered why RSTS was so user friendly.  There were few options, justJ one way to do things.  Fortunately, in many cases the developers made goodO design decisions and the 'one way' was a rather good way.  I soon found that if J I kept an open mind (I know, you'll doubt that) that VMS was a much betterL environment because I, and every other user/programmer/designer could chooseG from many options and if they choose well, the result would be a better  application.  O Not everyone is running Unix design applications that benefit from file caching K on a single user workstation with lots of extra memory.  'Desired behavior'  isn't always easily defined.   Enjoy reading your posts.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 03 Jun 2000 17:25:49 -0400 * From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)- Message-ID: <393977DD.4908D102@tsoft-inc.com>    Bill Todd wrote: >  > just an implementation error.  >  > - bill  0 Oh, I see.  You're talking about Unix and C. :-)   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  " Date: Sun, 4 Jun 2000 02:06:39 GMT9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) @ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)+ Message-ID: <kxhi6tj3Y4wK@eisner.decus.org>   Z In article <393977DD.4908D102@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > Bill Todd wrote: >>    >> just an implementation error. >>  	 >> - bill  > 2 > Oh, I see.  You're talking about Unix and C. :-)  > No.  Case-sensitive filenames are not an implementation error,. they are an error of design (or lack thereof).   ------------------------------  % Date: Sat, 03 Jun 2000 21:53:09 -0400 * From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)- Message-ID: <3939B685.412B9F50@tsoft-inc.com>    Larry Kilgallen wrote: > \ > In article <393977DD.4908D102@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > > Bill Todd wrote: > >>" > >> just an implementation error. > >> > >> - bill  > > 4 > > Oh, I see.  You're talking about Unix and C. :-) > @ > No.  Case-sensitive filenames are not an implementation error,0 > they are an error of design (or lack thereof).  P Sorry Larry, I wasn't explicit enough.  What I meant was that the implementation of Unix and C was an error. :-)    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  + Date: Sat, 03 Jun 2000 23:18:06 -0400 (EDT) " From: Dan Sugalski <dan@sidhe.org>@ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)G Message-ID: <Pine.LNX.4.10.10006032315050.3140-100000@tuatha.sidhe.org>   ) On Sat, 3 Jun 2000, David A Froble wrote:    > Larry Kilgallen wrote: > > ^ > > In article <393977DD.4908D102@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > > > Bill Todd wrote: > > >>$ > > >> just an implementation error. > > >>
 > > >> - bill  > > > 6 > > > Oh, I see.  You're talking about Unix and C. :-) > > B > > No.  Case-sensitive filenames are not an implementation error,2 > > they are an error of design (or lack thereof). > R > Sorry Larry, I wasn't explicit enough.  What I meant was that the implementation! > of Unix and C was an error. :-)   B C'mon, that's not fair. Both Unix and C have quite a few very niceD features. That they're so badly applied (and have a number of ratherI glaring design flaws) doesn't detract from those areas that they are good F at. Pity nobody ever redid either from scratch and got them right, butH it's not like VMS doesn't have its share of quirks. (Granted they're notI of the "let's open up my system because I have lousy security granularity I and a system that has no string handling capabilities" type, but they are 	 there...)    				Dan    ------------------------------  $ Date: Sun, 4 Jun 2000 01:31:24 -0400' From: "Bill Todd" <billtodd@foo.mv.com> @ Subject: Re: VMS File Caching Futures (Was: Re: Andrew whatever)( Message-ID: <8hcpcn$bt6$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in message ' news:3939766D.1B05FEA3@tsoft-inc.com...  > Bill Todd wrote: > > 9 > > Keith Brown <kbrown780@usfamily.net> wrote in message * > > news:39388193.FBE81237@usfamily.net... > >  > > ...  > > 9 > > > How difficult is this in PL/I. What can be simpler?  > > F > > 1) Using a language that the average developer (who, after all, is exactly ? > > the developer who *won't* do much if anything in the way of  optimization) is > > likely to select.  > H > Stuff a sock in it Bill.  If you're talking about C, then your average	 developer J > is a mistake just waiting to happen, so what does it matter how fast the mistake 	 > occurs?   J Fortunately (or not), there are so many of those developers out there thatK natural selection does an adequate (as defined by the market - your opinion H may differ) job of narrowing down the field to a still-large number of CG applications that work well enough (again, as defined by the market) to K define the performance standard by which VMS is unfortunately often judged.   C The world really doesn't care about a group of self-styled (or even G occasionally real) cognoscenti who look down their noses at C and Unix, J because their numbers are too negligible to be noticed, let alone listenedI to.  But the world does notice how fast their applications (the ones that   work, hence become popular) run.   > L > > 2) Making the desired behavior transparent rather than requiring that it beE > > specified (though making it easy to obtain, albeit explicitly, is 	 certainly * > > better than keeping it truly obscure). > C > When I transistioned from RSTS/E to VMS in the late 70s, RSTS was  perceived byD > it's users to be extremely user friendly, and VMS was just soooooo complicated.K > I soon discovered why RSTS was so user friendly.  There were few options,  justL > one way to do things.  Fortunately, in many cases the developers made goodI > design decisions and the 'one way' was a rather good way.  I soon found  that if L > I kept an open mind (I know, you'll doubt that) that VMS was a much betterG > environment because I, and every other user/programmer/designer could  chooseI > from many options and if they choose well, the result would be a better  > application.  H Since I came from an RSX environment, I never had to make that step, butG appreciate that it was a hard one for many RSTS people to take (I liked J RSTS, just thought of it as limited - but it had a wonderfully gung-ho andK experienced set of developers).  But the next step (one that took me a long C time to take, and that you don't yet seem to have taken) is that of H appreciating that packaging up a full-function environment such that itsG *default* choice of behaviors is as well-thought-out as RSTS's was (and F perhaps exposed in a simplified interface layer above the nitty-grittyJ full-function layer) is just as important in making a full-function systemI acceptable to the masses (who appear largely still to be in the place you D were before your VMS conversion occurred, and don't seem to have anyH particular reason to make the kind of jump into complexity that you were somewhat forced to make).   E VMS's default choice of file system behavior wasn't at all bad in the H limited-memory, etc., environment of the late '70s, though it lacked anyJ sub-set interface level as approachable as RSTS's (or, some would say, theG 10/20 environment).  It still lacks such a layer (the POSIX environment I might have qualified, but my understanding is that it was limited both in L scope and in performance), and the file system/RMS defaults have become muchJ poorer choices over time (yes, there are compatibility issues - one way toG avoid them neatly would be to create a new, simpler interface layer and , limit the new defaults to that environment).  L 'Way back when, I thought of the choice between RSX and RSTS as an either/orB decision, and to some degree that was reasonable, 'cause in the 11L environment the overhead of creating multiple, layered personas for a systemL was likely excessive.  But that's not been true in the VMS environment for aJ long time:  you don't have to give up a single bit of the VMS you know andG love to make it more approachable (and more effective) for a much wider " audience than it currently enjoys.   > I > Not everyone is running Unix design applications that benefit from file  caching C > on a single user workstation with lots of extra memory.  'Desired 	 behavior'  > isn't always easily defined.  @ No, but Unix does a pretty good job of making sure that the mostL commonly-desired behavior (good performance for the majority of applicationsL that just aren't concerned about *exactly* when writes occur) is the defaultB behavior, plus makes it easy to obtain intermediate but still goodC performance for applications that only care about what's on disk at L particular points in their processing (by 'synching' - flushing - dirty dataK to disk on a per-file basis), plus offers write-through operation when it's  needed.   J The utility of this isn't limited to single-user workstations with lots ofL memory (that's just one environment that David Mathog happens to be using asI an example):  Unix caches (NT's too, I think) grow and shrink dynamically F according to overall system memory use - just like VMS's can (at leastI that's planned for the EFC work, and may already exist in other VMS cache L areas) - and are one of the tools used by the system to get the best overallL performance out of whatever physical memory is available - just as VMS does.  G The bottom line is that RMS exhibits default write-back behavior in its I internal buffers (so much for the 'better reliability' line of argument), I but just doesn't do so very effectively (default sizes are too small, and L default behavior may well be single-buffered, though I'm not certain of thatJ last).  And RMS exhibits default bulk-read behavior also in its buffering,K but - again - not effectively compared to a system that uses larger buffers C and allows their contents to be shared automatically among multiple 9 processes (along with some access-pattern recognition for K read-ahead/write-back operation).  We're not talking major semantic changes I here:  Unix just does a better job (today - it might well not have been a H better choice 20+ years ago) of doing the things RMS is at least to someE extent already doing (plus some Unix implementations have file system ? meta-data update optimizations that the VMS file system lacks).    >  > Enjoy reading your posts.   K I hope someone does - wouldn't want this to be a complete waste of my time.   J As I've intimated before, I take a hard line because my experience is thatL if you give a VMS bigot an inch (an inch that they don't deserve, anyway:  IE try to be fair) they'll grab it and use it to assert that your entire H argument has no basis and that VMS couldn't possibly be at a comparativeJ disadvantage in any area.  And as I've said, that kind of bunker mentalityI is somewhat understandable, but I really believe it's counter-productive: I in what medium if not this one should people explore how to improve areas H that hinder VMS's wider acceptance in the marketplace?  And how can thatB exploration (and one hopes resulting improvements) be anything butD beneficial both to VMS and to the people who depend on its continued
 viability?   - bill   >  > Dave >  > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596= > 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  > Vanderbilt, PA  15486    ------------------------------  " Date: Sat, 3 Jun 2000 19:47:45 GMT9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) " Subject: RE: Wildfire Announcement+ Message-ID: <1yPLZPKl1Erz@eisner.decus.org>   = Kerry, you don't need to blurt out sensitive competitive data B here in comp.os.vms.  You could just tell Andrew privately :-) :-)  x In article <910612C07BCAD1119AF40000F86AF0D805284353@kaoexc4.kao.dec.com>, "Main, Kerry" <Kerry.Main@compaq.com> writes:  ? >>>> I asked you who these unnamed eBusiness partners were. <<<  > K > Sure, Compaq will just blurt out what potential partners it is talking to G > before any final deals are made .. Yup, that would go over real well.  > 
 > Regards, >  > Kerry Main > Senior Consultant, > Compaq Canada  > Professional Services  > Voice : 613-592-4660 > FAX   : 819-772-7036 > Email : kerry.main@compaq.com  >  >  >  > -----Original Message-----) > From: Andrew Harrison SUNUK Consultancy # > [mailto:andrew.nospam@uk.sun.com] % > Sent: Friday, June 02, 2000 5:18 AM  > To: Info-VAX@Mvb.Saic.Com $ > Subject: Re: Wildfire Announcement >  >  > "Main, Kerry" wrote: >  >> Andrew, Andrew .. >>K >> So, if you have no faith in what Compaq marketing is stating on official J >> Compaq pages, and if you continue to think that the head of Oracle does > not M >> in any way stand behind what he says, and if you continue to ignore recent G >> wins (17% of OpenVMS revenue last year was new business, but I don't  > expectI >> you to believe that) and if you continue to try to spread gloom-n-doom K >> information from the past to the readers of this list no matter what new # >> information is presented here ..  >> > H > Kerry, what exactly did Larry say. He said nice products, nice companyK > and Oracle runs on the nice procucts. Thats it, there isn't anything more D > reading Larrys comments as being some sort of long term endorsmentA > of Compaq/Tru64/OpenVMS is naive in the extreme. Reading Larrys > > comments as being an endorsment of Tru64/OpenVMS over any ofH > Oracle's other platforms is simply clutching at straws. He turns up to@ > our launches, HP's launches and IBM's launches and pretty much > says the same thing. > A > Its designed to keep the platform vendor doing the launch happy < > without offending Oracle's other partners. Why would Larry= > want to offend Sun, HP or IBM. Sun has the largest share of 8 > Oracles revenues on our systems would he want to place> > that revenue stream under any threat. Of course he wouldn't. > ? > I would place a lot more emphasis on Larrys kind words if the @ > words were backed up by deads. The fact is that 8i still isn't; > available on OpenVMS it was due last year, then march and = > it still hasn't happened. How many OpenVMS customers do you C > think you have lost to other vendors or to Tru64 because of this, ; > I know of two that I have worked with in the UK and thats A > before you start looking at all the other apps that Oracle have  > that don't run on OpenVMS. > K >> However, when presented with very positive new information, you continue K >> with your "sky is falling" FUD that totally ignores the new information.  >> > < > No sorry, there is no new information in the press release? > you posted, there arn't endorsments from any of the eBusiness < > partners alluded to in the press release but not named andA > this is simply a preservation of the status quo, press releases 7 > are cheap, but marketing and market development isn't  > just press releases. > ; > Come on Kerry where is the new information, I bet that if : > I could find the 8400 product announcements I would find* > an almost identical sentiment expressed. >  >>? >> How can you expect anyone to reasonably take you seriously ?  >> > 6 > Sorry but given your postings this is hardly a point4 > that is worth making from your standpoint. I asked0 > you who these unnamed eBusiness partners were. > 2 > You posted a Cognos URL which simply showed that8 > it was possible to put a WEB front end on a Powerhouse1 > app running on OpenVMS, this isn't the basis of 2 > an eBusiness strategy and if you think it is and7 > if your views reflect Compaqs views then to be honest $ > you may as well retire gracefully. > F >> I just came back from a week of futures, new stuff in VMS V7.3, newM >> application vendor strategies (including eBusiness), great new performance K >> enhancements, new marketing strategies (read the magic word GROW OpenVMS  >> business) etc etc.. >> > F > Kerry an application vendor strategy is simply that a strategy, whatA > matters is how that strategy is executed and what resources are C > available to assist in the execution. You need to spend money and K > lots of it, people like Broadvision and Ariba and all the other eBusiness > > apps vendors arn't going to port to Tru64 or OpenVMS withoutK > you parting with cash. It is also pretty apparent that Digital and Compaq D > have never been prepared to spend the kind of cash required to get > them into this market. > D > Why do you think Sun has being buying people like JCP and InnosoftH > it wasn't because somebody said nice technology it was because someone? > in market development said we need this technology to capture 6 > a particular market segment lets go buy the company. > 	 > Regards  > Andrew Harrison  > Enterprise IT Architect  >  >    ------------------------------   End of INFO-VAX 2000.310 ************************