1 INFO-VAX	Thu, 01 Jun 2000	Volume 2000 : Issue 304       Contents:H Abolute fastest way to get a 100% correct record count for RMS: summary:, Re: AlphaStation 200 firmware update problem Amazon jumps ship  Re: Amazon jumps ship  Re: Amazon jumps ship  Re: Capellas supports Microsoft  Connecting to console port.  Re: Connecting to console port. 
 Re: DAP error  Re: ES40 Configuration Re: ES40 Configuration Re: ES40 Configuration Re: ES40 Configuration FREE $25 Chip Bonus! Re: FTP Server Logs. Re: General discussion comment Re: General discussion comment, Re: How do I fix RMS corruption of MAIL.MAI?E Re: I/O cache - HSZ, was Re: Compaq not as bad as Andrew says (wish?)  Re: internet mail under VMS  Re: Motif - Version?5 Moving sysuaf.dat from OpenVMS VAX 7.1 to Alpha 7.1-2 * Re: OpenVMS vs Tru64 Pathworks performance* Re: OpenVMS vs Tru64 Pathworks performance* Re: OpenVMS vs Tru64 Pathworks performance3 Re: POS/credit card verification with OpenVMS Alpha  scsi disks on OVMS Re: scsi disks on OVMS Re: scsi disks on OVMS re: Telnet and License Re: Telnet and License UCX$POP_SERVER problems  Re: Unneeed RMS overhead with C  Re: Unneeed RMS overhead with C  Re: Unneeed RMS overhead with C  Re: Unneeed RMS overhead with C  Re: Unneeed RMS overhead with C  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 7.2 Bug? ; backup/image/(no)alias D Re: VAXCluster Principles book (was Re: Problem with resource	locks)D Re: VAXCluster Principles book (was Re: Problem with resource	locks)0 VMS V6.2 to V7.2 upgrade disaster (VAXsta 3138). Re: War Stories ?  RE: Wildfire Announcement  Re: Wildfire Announcement  Re: Wildfire Announcement  Re: Wildfire Announcement  Re: Wildfire Announcement   F ----------------------------------------------------------------------  % Date: Wed, 31 May 2000 12:39:20 -0700 - From: "Dann Corbit" <dcorbit@solutionsiq.com> Q Subject: Abolute fastest way to get a 100% correct record count for RMS: summary: ' Message-ID: <NTdZ4.587$jK6.1369@client>    $assign input.txt sys$input  $assign output.txt sys$output  $ana/rms/stats 'p1'  $ANA/RMS/STATS 'p1'  $convert/nocreate/stat 'p1' nl:  $sea/stat 'p1' "" /window=0 
 $run speed $run speed2   J I ran ANA/RMS/STATS twice and used the second result, so that VMS cacheingF of the file could be taken into consideration.  I ran the command file  several times to get an average.  , Times are for a moderate sized indexed file:   ANA/RMS/STATS 2:44.89  CONVERT/NOCREATE/STAT 2:03.76  SEARCH/STAT 1:59.50 ' SEQUENTIAL RMS GET (speed program) 1.59 ) SEQUENTIAL RMS FIND (speed2 program) 1:51   L Naturally, your mileage may vary.  I was hoping for some miraculous solutionH like reading from the FAB enough data for an instant calculation or someI kind of ludicrous speed-up.  No pot of gold at the end of this rainbow, I  guess. --0 C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html$  "The C-FAQ Book" ISBN 0-201-84519-91 C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p I C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm    ------------------------------  % Date: Wed, 31 May 2000 13:48:58 -0700 ! From: Shane.F.Smith@Healthnet.com 5 Subject: Re: AlphaStation 200 firmware update problem C Message-ID: <OFE57D2139.BD8254BF-ON882568F0.007258C6@HEALTHNET.COM>   $ >Shane.F.Smith@healthnet.com writes:K >> I use the supplimentary menu's "update firmware" option, the screen goes G >> flat BSOD blue with a message at the top saying it's looking for the J >> firmware update on CD ROM and floppy. After maybe a minute or two, evenJ >> that text disappears and the screen is solid BSOD blue. The floppy does get I >> accessed during this time. A little while later, the screen goes black  asJ >> if there's no video signal (although the LED on the monitor stays green asE >> if there is a signal), the keyboard lights flash a little, and the  machine H >> goes completely unresponsive. The only indications it's turned on are the , >> light on the front, and the fan whirring. > H >  Try hooking up a terminal (or emulator) to the serial port. I've seen cases H >where the SRM firmware behaves as if someone said "set console serial". NoteH >that the updater actually executes the new firmware from RAM (since you can't J >erase the flash while running from it) so the act of booting the firmware up- 5 >date disk actually has you running the new firmware.  > 1 >    Terry Kennedy             http://www.tmk.com 6 >        terry@tmk.com             Jersey City, NJ USA  K Thanks Terry, and thanks Hoff for the help with the serial cable. I haven't K found one yet, but I think I've just discovered what's really happening and K it changes matters somewhat. Last night I was playing with this again and I I noticed that before the screen goes black and the keyboard flashes, there K is a very brief black background display with the characteristic bowed grey K boundaries of a monitor being asked to do a resolution or refresh rate it's I not capable of, and there's a white underscore cursor in the bottom left. H Then the monitor goes "plink", and goes "no signal" black. It looks likeE the update program wants monitor settings my 17" NoName monitor can't 2 handle. Looks like I need to find another monitor.  K The full current BIOS version is 4.56 971219.1000 (NVRAM usage 11%, 341 out K of 3052). It's the Microsoft (hawk, spit) compatible firmware, not the SRM, J that's loaded, and the option it lists to use the OpenVMS console does sodB all. The video card reports as a "24 plane frame buffer video cardH ZXLp-E2", device number 13, vendor 1011, device id 4, device revision 3,H interrupt 9. Can anyone tell me what monitor settings it is looking for?  K Failing that, can anyone tell me the EXACT keystrokes on a Microsoft (hawk, K spit) compatible keyboard that I need to use to update to the SRM blind and  monitorless?  H Failing that, does anyone know how to boot this smegger from a floppy toJ update the firmware? I tried the bootable VMS floppy option, and it didn't even recognize the file system.   K Failing that, can anybody give me any practical alternative ideas to change I this @#$!@#R thing to use the SRM? I should point out that several people > have already suggested variations on bell, book and candle....   Shane   H  #####   ---------------------------------------------------------------I #-O-O-# | Shane underbar S on pacbell dot net. Spam to abuse@127.0.0.1  | H #  L  #  ---------------------------------------------------------------D  #===#   Don't blame HealthNet for anything I say. They're innocent.H   ###    OpenVMS: The operating system God runs the Earth simulation on.   ------------------------------  % Date: Wed, 31 May 2000 22:28:26 -0400 & From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Amazon jumps ship% Message-ID: <3935c8d3@news.toast.net>   L cbs.marketwatch.com/archive/20000531/news/current/amzn.htx?source=htx/http2_ mw   --     Jeff Killeen - www.Killeen.cc E =====================================================================    ------------------------------  % Date: Wed, 31 May 2000 22:38:27 -0400 & From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Re: Amazon jumps ship% Message-ID: <3935cb2d@news.toast.net>   : http://www.computerworld.com/home/print.nsf/all/000531E47E   --     Jeff Killeen - www.Killeen.cc E ===================================================================== 1 "Jeff Killeen" <Jeff@Killeen.cc> wrote in message  news:3935c8d3@news.toast.net...  > L cbs.marketwatch.com/archive/20000531/news/current/amzn.htx?source=htx/http2_ > mw >  > -- >  >  > Jeff Killeen - www.Killeen.cc G > =====================================================================  >  >    ------------------------------  " Date: Thu, 1 Jun 2000 02:48:52 GMT0 From: "Terry C. Shannon" <shannon@world.std.com> Subject: Re: Amazon jumps ship& Message-ID: <FvGFr6.MM4@world.std.com>  1 "Jeff Killeen" <Jeff@Killeen.cc> wrote in message  news:3935c8d3@news.toast.net...  > L cbs.marketwatch.com/archive/20000531/news/current/amzn.htx?source=htx/http2_ > mw >   A Hmmm... there's always www.barnesandnoble.com and www.borders.com   L Actually, I have found that Amazon frequently does not have the best prices,8 at least according to the deal broker at www.ichoose.com  G And I always go for the best price, even though I'm an Amazon Affiliate * through the SKC page on the Acersoft site.   Caveat emptor,  
 Charlie Matco    ------------------------------  % Date: Wed, 31 May 2000 18:08:41 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> ( Subject: Re: Capellas supports Microsoft( Message-ID: <8h42be$b27$1@pyrite.mv.net>  2 Carl Perkins <carl@gerg.tamu.edu> wrote in message' news:31MAY200002245636@gerg.tamu.edu...    ...   H > You are mistaken. It is 2 terms. Not 2 consecutive terms. Any instanceH > where the VP (or other person farther down the list) becomes PresidentK > for more than 2 years counts, in effect, as a term. Thus the actual limit I > is 2 terms + 2 years = 10 years (since a term is 4 years - if this were A > changed the maximum time in office would change along with it).   J Although there may be other limitations elsewhere, the text below does notF establish that limit:  a maxed-out President could apparently serve anL unlimited additional amount of time by being the Vice President for a series of unfortunate successors.   - bill   >  > The actual text of the thing:  >  >    AMENDMENT XXII (1951) > I >    Section 1. No person shall be elected to the office of the President I >    more than twice, and no person who has held the office of President, K >    or acted as President, for more than two years of a term to which some I >    other person was elected President shall be elected to the office of F >    President more that once. But this Article shall not apply to anyJ >    person holding the office of President when this Article was proposedI >    by Congress, and shall not prevent any person who may be holding the H >    office of President, or acting as President, during the term withinD >    which this Article becomes operative from holding the office ofH >    President or acting as President during the remainder of such term. > K >    Section 2. This article shall be inoperative unless it shall have been H >    ratified as an amendment to the Constitution by the legislatures ofI >    three-fourths of the several States within seven years from the date 5 >    of its submission to the States by the Congress.  > 
 > --- Carl   ------------------------------  % Date: Wed, 31 May 2000 19:20:40 -0600 + From: "Chris Morrill" <cmorrill@micron.net> $ Subject: Connecting to console port.2 Message-ID: <bSiZ4.1011$bR5.41167@news.uswest.net>  I Is there an easy way to connect to the console port of a VAX without a VT L term?  I am trying to set up a VAX3100 but do not have a VT term.  I am sure( it is sitting at the >>> prompt now.  :)   ------------------------------  % Date: Wed, 31 May 2000 19:38:10 -0600 + From: "Chris Morrill" <cmorrill@micron.net> ( Subject: Re: Connecting to console port.2 Message-ID: <b7jZ4.1018$bR5.44398@news.uswest.net>  L Let me be a little more specific.  I plan to connect to it via a serial portC on a PC.  Does anyone know of the pin layout for a 9-pin connector?   4 Chris Morrill <cmorrill@micron.net> wrote in message, news:bSiZ4.1011$bR5.41167@news.uswest.net...K > Is there an easy way to connect to the console port of a VAX without a VT I > term?  I am trying to set up a VAX3100 but do not have a VT term.  I am  sure* > it is sitting at the >>> prompt now.  :) >  >    ------------------------------  # Date: Wed, 31 May 2000 23:08:30 GMT  From: f.novelli@iol.it Subject: Re: DAP error) Message-ID: <8h4616$uam$1@nnrp1.deja.com>   * After many hours I discovered the problem.E The DAP error happens when I try to send to a microvax a file created F after 1/1/2000. If I send a file created before everything works fine.B I don't know if it's nft.exe by pc side that has a bug, or if it's fal.exe by vax side, or both... F If anyone knows where I can find a patch or new executables please let me know.E I'm running Pathworks 4.1 client on the pc and Pathworks 4.1 server +  VAX/VMS5.4 on a microvax3400. F I also have two Multia pc P100 xterminals from digital with WinNT 3.51 and Pathworks for WinNT.% Two microvax 3100/85 with Openvms6.2. 
 Thanks again,    Francesco Novelli   7 In article <200005300714_MC2-A6D3-BD79@compuserve.com>, 5   "Richard B. Gilbert" <DRAGON@compuserve.com> wrote: C >         DAP is Data Access Protocol.   It's been years since I've  seen th= > isH > error.  I believe that Pathworks has a log file which may provide some; > details.  VMS may have logged something in NETSERVER.LOG,  particularly if= > . > you have defined the FAL$LOG logical to "1". > G >         I suspect that you have a network hardware problem; something  is- > corrupting the data you are trying to send.  > 8 > Message text written by INTERNET:f_novelli@my-deja.com+ > >Trying to copy some files from a PC with 3 > PATHWORKS to a microVAX machine via DECNET, using  > nft, I get the error: 4 > Error opening file: node"account pwd"::remote_path2 > Because DAP error reported by remote node xx/xxx3 > On the remote host a file of 0 blocks is created. ( > Anyone can help me solve this problem? > Best regards,< >  >     & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Wed, 31 May 2000 18:03:59 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: ES40 Configuration ( Message-ID: <8h422f$a6e$1@pyrite.mv.net>  - Dan Sugalski <dan@sidhe.org> wrote in message 2 news:4.3.1.0.20000531073037.028c9b80@24.8.96.48...   ...   K > Oracle doesn't know what the heck it's talking about, then. It's possible K > that some other manufacturer has a cache problem (EMC or Sun, perhaps, or K > someone's software RAID), but it works fine for StorageWorks devices. You H > can shoot yourself by yanking the power or a drive before the cache isG > flushed, but operationally? No difference, just the speed boost and a * > larger danger window in case of failure.  I That statement is correct only if you (and any automated system functions L that might deal with the situation) guarantee to treat any loss of power (orI other failure affecting the cache) as a full-disk catastrophe and rebuild H the disk from scratch, using Oracle mechanisms.  Any attempt to continueG using the data on the disk if there's *any* possibility that some dirty E cached data got lost can potentially spread corruption throughout the 	 database.    - bill   >  > Dan  > K > --------------------------------------"it's like this"------------------- 4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and even = >                                       teddy bears get drunk  >  >    ------------------------------  % Date: Wed, 31 May 2000 19:28:29 -0500 * From: Keith Brown <kbrown780@usfamily.net> Subject: Re: ES40 Configuration , Message-ID: <3935AE2D.901A4FB8@usfamily.net>  ! steven.reece@quintiles.com wrote:  >  > Dan Sugalski wrote: L > >>>7) If the system's on a reliable UPS (and it is, *right*?), then enableK > write-back caching on all the drives. You *will* see a win on drives that ' > are written to with any frequency.<<<  > M > But you might not want to do that on disks related to Oracle (that's Oracle R > Classic, not RDB).  Whenever we have a problem with Oracle we get told "turn offJ > write back caching".  We say "but we've never had it on the disks in ourR > ESA10000s".  They then respond with any other cache (almost taken at random) andR > say "is it on?" to which we respond "yes, but it makes no difference to what the> > Oracle stuff is doing" and we still get told to take it off. > 
 > Result ?K > We have no caching anywhere with our Oracle setups.  Performance may suck P > because of it when the database loads get up but that's not for me to questionM > (I only try to maintain the viability of the systems - I don't do apps like 
 > databases).  >  > Steve.  < We run with HSZxx writeback caching on both our VMS and Unix/ systems running Oracle. No problems whatsoever!    --   Keith Brown  kbrown780@usfamily.net   ------------------------------  + Date: Wed, 31 May 2000 20:58:21 -0400 (EDT) " From: Dan Sugalski <dan@sidhe.org> Subject: Re: ES40 Configuration H Message-ID: <Pine.LNX.4.10.10005312055530.31236-100000@tuatha.sidhe.org>  % On Wed, 31 May 2000, Bill Todd wrote:    > / > Dan Sugalski <dan@sidhe.org> wrote in message 4 > news:4.3.1.0.20000531073037.028c9b80@24.8.96.48... >  > ...  > M > > Oracle doesn't know what the heck it's talking about, then. It's possible M > > that some other manufacturer has a cache problem (EMC or Sun, perhaps, or M > > someone's software RAID), but it works fine for StorageWorks devices. You J > > can shoot yourself by yanking the power or a drive before the cache isI > > flushed, but operationally? No difference, just the speed boost and a , > > larger danger window in case of failure. > K > That statement is correct only if you (and any automated system functions N > that might deal with the situation) guarantee to treat any loss of power (orK > other failure affecting the cache) as a full-disk catastrophe and rebuild J > the disk from scratch, using Oracle mechanisms.  Any attempt to continueI > using the data on the disk if there's *any* possibility that some dirty G > cached data got lost can potentially spread corruption throughout the  > database.   H Right, and that's fine--Oracle will force a rebuild in that case anyway,H which is as it should be. That's why you enable archive logs (preferablyG going to a shadowed mirror set) and make sure they're backed up onto at  least two tapes.  G What Oracle is claiming is that the very fact that writeback caching is A enabled will corrupt your data and should be turned off, which is J completely bogus. (Especially since many disk drives these days have a megG or more of writeback cache built into them *anyway*--how the heck would  you turn that off?)    					Dan   ------------------------------  % Date: Wed, 31 May 2000 23:50:03 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: ES40 Configuration ( Message-ID: <8h4mbc$bic$1@pyrite.mv.net>  - Dan Sugalski <dan@sidhe.org> wrote in message B news:Pine.LNX.4.10.10005312055530.31236-100000@tuatha.sidhe.org...   ...   I > What Oracle is claiming is that the very fact that writeback caching is C > enabled will corrupt your data and should be turned off, which is L > completely bogus. (Especially since many disk drives these days have a megI > or more of writeback cache built into them *anyway*--how the heck would  > you turn that off?)   L Without dredging up a discussion on this point I participated in a while agoK elsewhere, I can relate that virtually all drives have a supported means of I turning off write-back caching (though not via jumpers, as used to be the L case), both temporarily (I think those mechanisms are standardized, for bothJ SCSI and IDE command sets) and as the drive start-up default (these may beL drive-specific, but the manufacturer typically provides downloadable controlK programs on request for this kind of job - and if necessary you could write 1 your own, using the particular drive's commands).   F SCSI Write commands (perhaps only the 'verbose' version) also have theL option to force write-through on a per-request basis, even if the write-back cache is enabled.    - bill   >  > Dan  >  >    ------------------------------  0 Date: Thu, 01 Jun 2000 08:05:38 +0500 (GMT+0500)  From: ldad%TDC.cc.com@dot.net.in Subject: FREE $25 Chip Bonus! 7 Message-ID: <200006010305.IAA0000021116@agr.dot.net.in>   1 Play our games for FREE! or, Play for REAL MONEY! * Register NOW and receive a FREE $25 BONUS!  A We have the BEST ODDS on the Internet with a WHOPPING 97% PAYOUT! ? It really is like turning your PC into a REAL Las Vegas Casino.   / Try out ALL of our NEW NO DOWNLOAD java games!   WE have SOMETHING for EVERYONE!  **BLACKJACK  **SLOTS  **POKER  **CRAPS 
 **ROULETTE  O ATTN: SLOT MACHINE Players - WE HAVE the PROGRESSIVE SLOTS you are looking for! 2 Progressive QUARTERS, AND Progressive NICKLES TOO!S You will also find Super Beetle, Triple Diamond, and 5 Line COMBO, and High Roller.    Videopoker fans can play for as little as a NICKEL! You'll also find player favorites like, Jacks Or Better COMBO, and High Stakes TOO!   1 <http://www.topdeckcasino.com/partner.asp?id=230>    WHY pick us to play with? G 1. BEST ODDS on the Internet, 97% PAID BACK! Now just try to beat that! K 2. FAST gaming action requiring ABSOLUTELY NO lengthy download of software.  3. We are a Licensed operation.  4. 24/7 technical support. 5. AUDITED for fairness.  	So come visit our casino, we'll throw in $25 as a BONUS for all first time players, AND don't forget ALL of our games can be played for FREE TOO. So you can try your luck without ANY risk. (The games in our free area are the very SAME games found on the pay side!)     You're about to experience the most visually captivating VIRTUAL CASINO on the Internet to date! Register NOW and receive a FREE $25 BONUS!   1 <http://www.topdeckcasino.com/partner.asp?id=230>      You may also want to check out our sister site, the nickeldimecasino.com, home of the infamous "Colorado DIMES" slot machine! PLAY Roulette and BLACKJACK for a NICKLE! (That FREE $25 bonus could be 500 NICKELS!)   4 <http://www.nickeldimecasino.com/partner.asp?id=230>   ------------------------------  % Date: Wed, 31 May 2000 20:28:04 +0200 2 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: FTP Server Logs. ; Message-ID: <393559b4.524144494f47414741@radiogaga.harz.de>   * Jerry Leslie (leslie@clio.rice.edu) wrote:5 : Martin Vorlaender (martin@RADIOGAGA.HARZ.DE) wrote: 6 : : If you want to completely get rid of all of those: : : < : : UCX> (or TCPIP>) SET SERVICE FTP /LOG_OPTIONS=(FILE=NL:) : L : We tried this to suppress UCX$RSHD_STARTUP.LOG and UCX$REXECD_STARTUP.LOG M : files, after first disabling the service, and reenabling it after the "SET  K : SERVICE" command. But new LOG files were still created, after the change.   B Sorry about that. This command only suppresses the log files namedE SYS$SYSDEVICE:[UCX$FTP]UCX$FTPD_STARTUP.LOG (which you see when doing G a $ UCX SHOW SERVICE FTP /FULL). The UCX$FTPSERVER.LOG (and presumably, F UCX$RSHD_STARTUP.LOG) file name is hard-coded in the FTP server image.  B So, $ SET FILE/VERSION_LIMIT seems to be the only (half-)solution.   cu,    Martin --D                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.de H   KNOW where you want  |        http://www.pdv-systeme.de/users/martinv/8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  % Date: Wed, 31 May 2000 18:23:09 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ' Subject: Re: General discussion comment , Message-ID: <393590C6.34597F0E@videotron.ca>   David A Froble wrote: O > Things are starting to happen.  Since it appears that Compaq management is no N > longer seeking to 'kill' VMS, I'd rather approach it as a partnership than a > confrontation.    K While it is clear that VMS is no longer activelly being killed, the lack of K VMS presence in advertising and especially the Wildfire announcement has to  make one wonder:  J Is Compaq just doing enough to keep us quiet ? Or are they truly intent on! selling VMS to a wider audience ?   J Since Capellas admitted they are only targetting Wildfires to the existingL customer base (focused targetted markets where they already have significantM market penetration), and since the efforts so far by Compaq to make VMS a bit M more visible have been targetted at the existing customer base, one can argue J that Compaq intends only to try to stop the bleeding and keep existing VMSA customers instead of trying to push VMS to new customers/markets.   N Prior to the Wildfire launch, I was more positive about the future of VMS than after the Wildfire launch.   ------------------------------  % Date: Wed, 31 May 2000 20:59:41 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> ' Subject: Re: General discussion comment - Message-ID: <3935C38D.69C5EE19@earthlink.net>    David A Froble wrote:  >  > > Bill Todd wrote: > > > O > > > VMS as you know it is in no danger of disappearing any time soon, so your  > > > livelihood is secure.  > > H > > Come look for an OpenVMS job here in Metro Chicago. You may discover > > otherwise. > @ > So, someone else got there first, likes it, and isn't leaving?  F No - someone got there, got let go, and is not being replaced, because7 the OVMS system he was maintaining is being replaced by  {NT,LINUX,Solaris,???}.   @ Give Dick Reichmann at V.A.C.S. a call (411, ask for V.A.C.S. inA Shorewood, IL) and him how many orders he's had for new VMS-Alpha @ systems this year. (V.A.C.S. is the biggest OpenVMS VAR in Metro# Chicago, http://www.vacs-inc.com/).    ; > > > But it also has no likelihood of growing market share N > > > by continuing business as usual (the past decade-plus should be adequateJ > > > proof of that, despite hardware that *should* have helped it do so). > > H > > Exactly what we've been pounding on Compaq about (and Digital beforeL > > them) for a *VERY* long time now. I think we're starting to make a dent,L > > but that's less than half a step in a journey of several hundred million
 > > miles. > ! > Things are starting to happen.    D Seems to me we said/heard that not so long ago - not long before the! whole Compaq debacle got started.   / > Since it appears that Compaq management is no N > longer seeking to 'kill' VMS, I'd rather approach it as a partnership than a > confrontation.  H I, too, would love to have a partnership with Compaq. How might we breakD down their "Golden Rule" mentality ("the guy with the gold makes the rules")?   J > > > Extending (rather than morphing) VMS to be more palatable to a widerE > > > audience can only improve matters, both for you and for Compaq.  > > K > > Agreed. However, would you care to elucidate the concept of "extending" K > > an o.s. which is already a superset of most of the others we encounter?  > 1 > So, you're saying there's no need for VMS V7.3?    Where did that come from?     [snip] > D > So, there's no need for VMS V7.3????  Should we dispose of the VMS > developers???? >  [snip]Q > Without going into more detail possibilities, I just want to say that your post P > invoked the memory of the head of the US patent office in I believe 1890 or inQ > that time frame, that decided that the office should be closed since everything L > that could be invented had already been invented.  If you look at what hasL > occured since 1890, I believe that you should find it hard to say that VMS > cannot be extended.  > L > No flame intended here.  It's just that if you go back and read your post,, > you'll say "I can't believe I wrote that".  , I'm very certain that you misread my intent.  A Yes, there _IS_ a need for OVMS V7.3, and V8.x, V9.x, V10.x, etc.  There's still LOTS to be done.  G Perfection? That may be a bit too much. I'd rather look at what's being F done right well AS WELL AS what's not being so well and say, "what can we do to improve this?".  H As for device support, let me go over one idea that would go over REALLY big at many sites right now:  5 There exists a device known as a Castlewood Orb drive F (http://www.castlewood.com/) - SCSI removable cartridge drive. CurrentF capacity: 2.01 GB formatted (ODS2). Currently known to work (with someC caveats) with some MicroVAX 3100s, but not with VAXstation/4000-VLC 3 (V7.2 in both cases) or with AlphaStation (V7.1-2).   H Now, picture this: a storage array full of Orbs - mirrored. Quiesce yourE app., split your mirror-sets, then re-start the app. "BACKUP" window: D near zero (10 minutes or less). Now the operator removes the ejectedG cartridges, replaces them with expired previous "backups", then submits 6 a job to start joining them back into the mirror-sets.  C Imagine - no more backup tapes, minimal "backup window", ... to say G nothing of disaster recovery: take your disks to the hot-site, plug 'em F in, boot up and your up in minutes instead of hours - no restores from tapes.  E ...and the price? Orb cart.'s are $39.95 retail, vs. thousands apiece D for "certified OVMS supported" drives, or $100 or so each for DLT-IV
 tape cart.'s.   5 Know any sites that COULDN'T use something like that?   ( Too bad Orbs aren't OVMS certified, huh?  G Yeah - lots of room for improvement, but sitting on our hands won't get A us there. Technology marches on. Gotta either keep up or get left D behind. Gotta get those new gadgets certified, or lose more sites to billy boxes and penguin boxes.   --   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: 31 May 2000 14:22 -0400  From: hein@eps.zko.dec.c*m5 Subject: Re: How do I fix RMS corruption of MAIL.MAI? & Message-ID: <31MAY200014225091@miasys>  T In article <8h3hd5$afj$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes...: (in reply to Glen Martin <GLENMARK@utxvms.cc.utexas.edu> )  L >If you can't CONVERT the file to a sequential one to retrieve its contents,I >that makes it likely that the corrupt bucket is in the user data level.     Right   L > If so, you can (often) get at least most of the records out of the file byB >writing a short program that retrieves records sequentially untilI >encountering the corrupt bucket, then, using the key for the last record B >successfully retrieved, starts probing randomly, incrementing (orM >equivalent, for a string key) the key value until a probe succeeds, and then $ >continuing sequentially from there.  H Right, and for a VMSmail file the key values to try are very predictableF (direct function on binary date), and you get some hints by looking atD the external mail file names/dates. Also, you can do a convert/key=1' to select records from an other 'angle'   H >Given that most of the bucket header starting at VBN 1186 appears to beJ >trash, there may well be nothing to be gained from examining that bucket.  E Yabut... dump it and surrounding buckets anyway to understand what is G going on. All zero? Some text? Is that 1186 reasonable or is it in fact * a broken next pointer from a prior bucket?  F Use ANA/RMS/INT to look at the L1 index to learn the prior bucket VBN.  L >And while you could follow the bucket chain and attempt to repair it enoughH >to allow CONVERT to run, describing how to do that is considerably more! >complex than the approach above.   E Yabut, with the help of a restored old copy, it might not be all that G hard to learn what the contents sould have looked like and/or at least  G to readily find a good candidate next bucket to point to from the prior  skipping the broken current.   ------------------------------  % Date: Wed, 31 May 2000 15:36:25 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> N Subject: Re: I/O cache - HSZ, was Re: Compaq not as bad as Andrew says (wish?)( Message-ID: <8h3pdr$ohd$1@pyrite.mv.net>  4 John Nebel <nebel@ATHENA.CSDCO.COM> wrote in messageA news:Pine.OSF.4.21.0005290703080.19409-100000@athena.csdco.com...  >  > Bill,  > L > This is an attempt to address some of your points to bring what appears to2 > be a one-sided point of view into better balance > G > "But you need to double up on the controllers, each with stable write L > cache, and have them communicate to avoid losing dirty data due to a cache
 > failure" > C > You probably didn't realize that HSZs are typically configured in L > dual-redundant mode with battery power sufficient for a 12-hour outage forI > the caches which can be mirrored on one another and are configured that  > way by default.   L I certainly realized that they *could* be so configured, but did not realize that this was 'typical'.   > L > The controller can make i/o optimizations at a lower cost than the host asI > its only job managing the disks.  HSZ22 is pretty cheap if ones storage ? > needs are in the range of 100-500gb.  The street price of the J > newly-obsolete HSZ70 is also pretty resonable in the low terabyte range.  H 'Cheap' is relative.  The street price of decent-quality (e.g., IBM) IDEB drives, which are eminently usable in software-managed stripe setsI (especially if the IDE drivers support SCSI-style access, which the newer F IBM IDE drives support, making them fully performance-competitive withL SCSI), is under $7/GB.  That gives you mirrored storage of 100 - 500 GB at aJ hardware cost of under $1400 - $7000.  How much does a pair of HSZ22s with= mirrored, battery-backed write-back cache add to that figure?   L > The three 80 series controllers have more speed and other features and are > priced accordingly.  > L > Unix can be darn difficult to tune - I'd never say it was easier then VMS.  K My comments related to *application* tuning (or lack thereof), not *system*  tuning.    > L > You assume away the most difficult part of the problem: "(as long as there9 > are lulls during which you can dump the data to disk)."   K Not sure what you mean there, since it kind of sounds as if you think I was F 'assuming it away' such that Unix looked better.  In fact, the commentK related to the fact that there are write access patterns that can make even L a good-sized hardware write-back cache largely ineffective - since once it'sH filled up, it can destage data to disk (and accept new data) only at theL underlying disk access rate (improved somewhat, but not dramatically, by theL ability to order the writes to take advantage of head position, but that canA be done with system-software-managed write-back caching as well).   J Stable hardware write-back cache is most effective for data that *must* beI written synchronously (usually for reasons of integrity), since it allows J such writes both to be coalesced and to be deferred (when loads are heavy)C to take better advantage of head position.  But many, perhaps most, J applications don't actually require synchronous write activity most if notL all of the time, and a well-designed modern file system doesn't either - andK in such cases write-back cache provides relatively little benefit.  That it J is so beneficial to a VMS system is reflective of the fact that VMS's fileH system (and the default use RMS makes of it), while superbly designed inK 1976 terms, can no longer be considered 'modern' and imposes write activity G requirements on the underlying disks that more modern systems can often  avoid.  J Not to mention the fact that system-level write-back caching provides muchH faster application write-completion response (in the typical synchronousI use) than controller-level write-back caching:  someone recently (but I'm K not sure publicly, so I won't mention his name) provided figures indicating @ that controller-level write-back caching on VMS systems providedI application-perceived write latencies of about a millisecond, which jibes K well with typical SCSI controller command-processing latencies (though I've F never understood why they were so slow), whereas latency to write to a2 system-level cache is in the tens of microseconds.   > K > One series of tests I performed with Unix on a couple of Alphas (2100 and H > ES40) with various controllers (multiple host-based, HSZ50, HSZ70) andK > file systems (UFS, UFS+LSM), the HSZs were the only way to keep up with a  > DS3 news feed.  I 'UFS' covers a multitude of virtues and sins.  Depending upon the variant D you used, it may have been forcing all file system meta-data updatesK synchronously (including every change in the EOF mark, which could occur on J each user write) - Sun's UFS implementation did so at least until into theF '90s (and did not provide psuedo-extent behavior until around the sameJ time), and for all I know Tru64's still does (since people who are looking) for performance have AdvFS as an option).   H SGI's XFS on IRIX (and soon on Linux) is the best example I know of of aB Unix file system implementation that does a good job of minimizingJ unnecessary write activity.  It wouldn't surprise me if AdvFS did a decentJ job as well (Chris Saether, father of the XQP and IIRC the first developerB hired to work on RMS-32 back in 1976-7, was its prime designer andI implementor).  I think 'soft updates' made it into one or more of the BSD H variants, but I'm not even sure Sun uses them (its own file system has aK somewhat primitive logging option that may only eliminate the need for fsck K on unclean restart - Sun users who want performance *and* availability tend D to gravitate toward the Veritas file system, which uses its log moreK effectively to limit write activity).  And the last I knew Linux had yet to G acquire a really good file system (though there are a couple of kind of ( interesting but obscure ones available).   > J > So it was a case of hardware to the rescue when nothing else worked, not1 > even the supposedly efficient Unix file system.   J As I said, depends upon whether it was one of the variants that is in factD efficient.  And I'm not sure *any* existing Unix file system handlesL system-level write-back optimally - but if one did/does, I'd be surprised ifC additional hardware write-back caching would help all that much for B something like a news feed, even for log writes (a few dozen MB ofC solid-state disk for logs can work wonders for some highly-parallel J work-loads, but I'd expect a news feed to be sufficiently sequential - andK throughput-sensitive rather than latency-sensitive - that regular log disks  could keep up just fine).      Turns out that theH > payment for host-caching, the periodic fsync, will seriously lower theL > average i/o rate in a write-mostly environment unless there is some pretty( > massive controller cache to absorb it. > K > There are some other payments for the Unix file system: backup/restore is J > extremely time-consuming if there are many files - once a file system is6 > on a disk it it requires major down time to move it.  H Veritas does both (backup and location-shuffling) on line.  So (I think)L does AdvFS, and if some others do not (I'd have to check to know which ones)L there are third-party (and/or lower-level disk hardware) 'snapshot' products# that can add such features to them.     Boots after crashesJ > can take over a hour due to fsck in the above INN environment, and thereE > is the problem that the operating system has to be tuned to allow a D > large-enough cache for fsck leading to an occasional reboot-never.  I No file system that requires fsck can be termed 'modern'.  Veritas' VxFS, I Tru64's AdvFS, Sun's UFS with the log option, SGI's XFS on IRIX (and soon > Linux), and IBM's JFS on AIX are some that don't require fsck.   > F > Over-all, given HSxxx controllers, VMS and Unix, both of which I useL > extensively, have file systems with equivalent speed.  Personally I prefer4 > the VMS one - it is a lot less hassle in practice.  A I suspect that your acquaintance with the range of competing Unix L alternatives may be limited.  And that at least some of them could give yourK application close to the same performance even without the controller-level  cache, whereas VMS could not.    - bill   >  > John Nebel   ------------------------------  # Date: Wed, 31 May 2000 18:03:15 GMT - From: Lonnie Carreau <Lonnie.Carreau@mci.com> $ Subject: Re: internet mail under VMS' Message-ID: <393553E8.9881A326@mci.com>   @ I got it working with UCX 4.2, but it was a real pain  the arse.   -Lonnie        Michael Austin wrote:   O > UCX 5.0 has a PPP client that you can use, or if you have DSL or Cable-Modem, J > just connect to the ISP using their POP and SMTP outgoing mail services. > ( > Multinet also has a PPP dialer IIRC... >  > Michael Austin > $ > Softwaregroep TB/GA Gasunie wrote: > 
 > > Hello, > > G > > I'm fairly new to alpha and VMS and I want to connect a modem to an J > > Alphastation 500 and do some internet mail with the MAIL utility and a
 > > provider. P > > I hope someone can point me in the right direction to do the following jobs: > > @ > > 1. How to connect and configure a modem to a VMS workstation > > M > > 2. How to configure the TCP/IP services (UCX) so that I can email using a  > > POP/SMTP server via PPP  > > N > > The system has to gather the email, dial-out to the provider and bring/get > > the email. > > P > > If anyone has some tips to this or can point me to some reading to do this I > > would be very happy. > >  > > Thanks, , > >   Hans van der Veeke (Gasunie Groningen)   ------------------------------  % Date: Wed, 31 May 2000 20:31:36 +0200 2 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: Motif - Version? ; Message-ID: <39355a88.524144494f47414741@radiogaga.harz.de>   E Ed James, ed.james@telecomsys.com (jamese@beast.dtsw.army.mil) wrote: 5 : martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) wrote:  : > $ @SYS$UPDATE:DECW$VERSIONS  :  : This sets symbols: ... 0 : Add a non-null P1 argument for printed output: ...   7 On VMS/VAX 6.2, calling it without arguments does both.    cu,    Martin --D                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.de H   KNOW where you want  |        http://www.pdv-systeme.de/users/martinv/8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  # Date: Thu, 01 Jun 2000 02:20:05 GMT G From: "Stephen Eickhoff (remove the - to reply)" <operagost@e-mail.com> > Subject: Moving sysuaf.dat from OpenVMS VAX 7.1 to Alpha 7.1-2* Message-ID: <3935C859.FF5E57A8@e-mail.com>  J Can I copy the sysuaf.dat from an OpenVMS VAX 7.1 system to an Alpha 7.1-2 system? M Is there a better way of transferring the users? The nodes are clustered, but  won't be in the future. --  " ----------------------------------          Stephen Eickhoff            Havertown, PA " ----------------------------------   ------------------------------  % Date: Wed, 31 May 2000 13:15:40 -0400 * From: David A Froble <davef@tsoft-inc.com>3 Subject: Re: OpenVMS vs Tru64 Pathworks performance - Message-ID: <393548BC.372BFC9A@tsoft-inc.com>    David Mathog wrote:  > \ > In article <3934BD56.A3B43B49@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes: > > S > >Having been through the file caching arguments, I've got to observe that there's N > >something really screwed up in Pathworks.  VMS disk activity isn't all thatO > >slow, and to blame it is ignoring the problems in Pathworks.  I have no idea  > >what the real problems are. > 2 > The most likely cause of write slowdown is this: >  > 1 client sends packet  > 2 server receives packetV > 3 server writes it to disk, waiting for the write to complete (fprintf() or write())? > 4 server signals client that it is ok to send the next packet  > J > If this code came over verbatim from Unix it will be really slow on VMS.K > That's because step 3 is very fast on Unix (it goes to file cache, unless K > they've gone to great lengths to do otherwise) and so it completes nearly M > instantaneously.  On VMS, on the other hand, unless the RMS parameters have L > been set on the application to allow buffering it's going to take at leastM > 10 milliseconds, possibly more to return.  Worse, it will tend to cause the I > file to extend by tiny increments, which is the slowest possible way to P > write a file.  At the very least step 3 on VMS should be rewritten to use QIOsO > (without waiting for completion) to write to a file with buffering turned on.  > H > Similarly, for read performance, if the application doesn't use a highH > multiblockcount (a no brainer here, but...) it will have at least a 2XM > poorer read performance compared to a real disk read on other OS's.  If the J > file is being read from file cache on Unix that will be much faster than) > any disk read could possibly be on VMS.  > K > So, it could well be that virtually all of the performance penalty we see D > with Pathworks on OpenVMS is a direct result of running code whichM > implicitly assumes file caching for its efficiency being run on an OS which  > doesn't provide it.  > H > Does anybody out there have Perfect Cache from Raxco running on a diskI > served by Advanced Server?  If this theory is correct it should perform ) > very similarly to what's seen on Tru64.  > M > We can't know what Advanced Server does, but Samba is in the public domain. O > Can one of the Samba for VMS developers comment on what this version of Samba + > does for write optimization, if anything?  > 
 > Regards, >  > David Mathog > mathog@seqaxp.bio.caltech.edu @ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                                RIP VMS                                 *L > **************************************************************************  P I understand what you're saying David, but I'm under the impression that the T64N stuff came from VMS Pathworks, which means the problem was there before seeingL any improvement on Unix.  But it's more than that. This stuff (Pathworks) isO real slow on reads, and VMS doesn't read disks all that slowly.  It's either in O the networking, and earlier versions of Pathworks used DECnet which isn't slow, P or in the product, which is VERY slow.  No, I still strongly believe that it's a> bad implementation.  In my opinion VMS isn't the culprit here.   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: 31 May 2000 19:58:02 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)3 Subject: Re: OpenVMS vs Tru64 Pathworks performance , Message-ID: <8h3qsa$fr7@gap.cco.caltech.edu>  Z In article <393548BC.372BFC9A@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes:Q >I understand what you're saying David, but I'm under the impression that the T64 O >stuff came from VMS Pathworks, which means the problem was there before seeing  >any improvement on Unix.     J Advanced Server was licensed from somebody else (IBM?) and originally ran  on their Unix.  3 >But it's more than that. This stuff (Pathworks) is @ >real slow on reads, and VMS doesn't read disks all that slowly.  F VMS per se reads from a disk as fast as anything.  But there's always J software that can do things in such an inefficient manner that performanceJ goes completely to hell.   For instance, I found a mode in POVRAY where itG used freopen() on every single write.  That would move the heads to the J beginning of the file (or the directory entry) and then back to the end ofK the file for each write.  It was sooooooooo slow.  But not on a cached file  system.   H In this instance, imagine that Advanced Server is doing something reallyK innately evil.  For instance, interleaving reads from two files on the same F disk, using synchronous IO to both disk and the net, with a MULTIBLOCKH count of zero, and no RMS or program buffering of any sort. That kind ofK code would run ok on a cached file system, but not at all well on OpenVMS.  K If anybody is running Advanced Server on a DS10 this sort of problem should H be obvious from the disk buzzing which it causes.  That tell tale BZZZZZH sound (sort of like a "joy buzzer") is a good indication that you've gotE (yet) another file access problem to fix.  Can Advanced Server can be J induced to serve a RAMdisk?  That would be a very worthwhile test.  My bet9 is that in that mode it will be nearly as fast as Tru64.     Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Wed, 31 May 2000 17:49:37 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 3 Subject: Re: OpenVMS vs Tru64 Pathworks performance ( Message-ID: <8h417m$938$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in message ' news:393548BC.372BFC9A@tsoft-inc.com...  > David Mathog wrote:  > > @ > > In article <3934BD56.A3B43B49@tsoft-inc.com>, David A Froble <davef@tsoft-inc.com> writes:  > > > H > > >Having been through the file caching arguments, I've got to observe that there'sK > > >something really screwed up in Pathworks.  VMS disk activity isn't all  thatL > > >slow, and to blame it is ignoring the problems in Pathworks.  I have no idea  > > >what the real problems are. > > 4 > > The most likely cause of write slowdown is this: > >  > > 1 client sends packet  > > 2 server receives packetL > > 3 server writes it to disk, waiting for the write to complete (fprintf() or write()) A > > 4 server signals client that it is ok to send the next packet  > > L > > If this code came over verbatim from Unix it will be really slow on VMS.F > > That's because step 3 is very fast on Unix (it goes to file cache, unlessF > > they've gone to great lengths to do otherwise) and so it completes nearlyJ > > instantaneously.  On VMS, on the other hand, unless the RMS parameters haveH > > been set on the application to allow buffering it's going to take at least - > > 10 milliseconds, possibly more to return.   I My guess would be that unless Pathworks opens the file such that external K VMS accessors (or accessors using a second instance of Pathworks, if that's L allowed at all) can share it, RMS will buffer up sequential writes until itsJ internal buffer is full before actually performing a disk write.  However,L since by default that internal buffer is only 8 KB in size, this would limitI sequential throughput to something like 1 MB/sec (or less, unless nothing H else was competing for the disk so that 8 KB could be written about onceI every revolution - 8+ ms. for a 7200 rpm disk), whereas normal Unix-style H write-back cache behavior could allow bulk transfers approaching the raw1 disk bandwidth (certainly approaching 10 MB/sec).   L It has been noted elsewhere that the C RTL may by-pass RMS in such cases but@ (now) honors RMS defaults, so that shouldn't change things much.  "   Worse, it will tend to cause theK > > file to extend by tiny increments, which is the slowest possible way to  > > write a file.   J There are multiple levels of default extension quantity defaults that helpI some here - and in any event the amount is never less than a disk cluster J (whatever that may be nowadays).  And the NT file system interface (thoughH perhaps not the Win32 API layered on top of that interface) allows spaceJ pre-allocation on file creation, which may (or may not) get passed throughH the Pathworks interface to avoid any run-time file extension activity on things like Copy operations.  A   At the very least step 3 on VMS should be rewritten to use QIOs F > > (without waiting for completion) to write to a file with buffering
 turned on.  L As mentioned, the C RTL may already be doing something like this (though I'dH question how much difference it makes compared to using RMS:  the bufferH size and availability of write-back caching as an option are the two big ways to win here).   > > J > > Similarly, for read performance, if the application doesn't use a highJ > > multiblockcount (a no brainer here, but...) it will have at least a 2XK > > poorer read performance compared to a real disk read on other OS's.  If  the L > > file is being read from file cache on Unix that will be much faster than+ > > any disk read could possibly be on VMS.   I Again, the key is that at least some Unix caches detect sequential access I and automatically pre-fetch data (one example I remember, though I forget L which system, performs asynchronous read-ahead using 3 buffers of 64KB each,J which potentially allows - again - sequential access at something like theI 10 MB/sec or better raw disk speed vs. - again - perhaps 1 MB/sec using a   single default 8 KB RMS buffer).   > > I > > So, it could well be that virtually all of the performance penalty we  see F > > with Pathworks on OpenVMS is a direct result of running code whichI > > implicitly assumes file caching for its efficiency being run on an OS  which  > > doesn't provide it.   = To be picky, the problem is not that RMS doesn't provide good C read-ahead/write-behind facilities, just that they don't kick in by K default - though for non-sequential access patterns it's more difficult for 5 RMS to match the flexibility of a central Unix cache.    > > J > > Does anybody out there have Perfect Cache from Raxco running on a diskK > > served by Advanced Server?  If this theory is correct it should perform + > > very similarly to what's seen on Tru64.  > > G > > We can't know what Advanced Server does, but Samba is in the public  domain. K > > Can one of the Samba for VMS developers comment on what this version of  Samba - > > does for write optimization, if anything?  > >  > > Regards, > >  > > David Mathog! > > mathog@seqaxp.bio.caltech.edu B > > Manager, sequence analysis facility, biology division, Caltech > > J **************************************************************************, > > *                                RIP VMS *  > > J ************************************************************************** > J > I understand what you're saying David, but I'm under the impression that the T64 I > stuff came from VMS Pathworks, which means the problem was there before  seeingK > any improvement on Unix.  But it's more than that. This stuff (Pathworks)  isG > real slow on reads, and VMS doesn't read disks all that slowly.  It's 	 either in K > the networking, and earlier versions of Pathworks used DECnet which isn't  slow, K > or in the product, which is VERY slow.  No, I still strongly believe that  it's a@ > bad implementation.  In my opinion VMS isn't the culprit here.  J See above comments.  Perhaps the best way to put it is that VMS *defaults*F may be the culprits (which both Hoff and Hein have also suggested in aL different thread), though an actively bad application implementation remainsI a possibility as well (the absence of oplock support, as noted elsewhere,  isn't exactly a good sign).    - 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: Wed, 31 May 2000 20:26:10 -0400   From: kuff@tessco.com (Hal Kuff)< Subject: Re: POS/credit card verification with OpenVMS AlphaO Message-ID: <37240562F0B03FEA.5A18CE20D7697430.36D84609A80DB7D5@lp.airnews.net>   E    We use Intrix.....  so far so good ... Tim Carter was our engineer     D In article <8h3hf0$gfb$1@nnrp1.deja.com>, itjck01@my-deja.com wrote:  9 > Does anyone know what credit card verification software H > packages/services are being used on OpenVMS Alpha?  I would appreciateG > hearing the good, bad, and ugly of what folks are using in this area.  > E > Our desire is interactive credit card verification (on the order of B > seconds) that has some sort of API that we can interface to.  WeF > believe the following are available for OpenVMS in the way of credit% > card verfication software/services:  > 	 > PAYLINX 
 > ICVERIFY > PAYMENTECH > 8 > Anyone know of any others or have comment on the above > software/services? >  > :) jck > --& > Free personal opinion is what I post >  > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.    ------------------------------  % Date: Wed, 31 May 2000 14:42:26 -0400 " From: Donal Day <dbd@virginia.edu> Subject: scsi disks on OVMS , Message-ID: <39355C34.5796363E@virginia.edu>  H I have a alpha workstation based on a "durango" mother board with a scsiA controller interfaced to a Quantum 4.5 Gb Atlas II 3.5 inch disk.   E I wish to add another scsi drive and would like to know if there is a E limit to the disk size that I can iitialize and mount under OVMS 7.1?   = I would be foolish to buy a 18 Gbyte and only see part of it.    Thanks  	 Donal Day    ------------------------------  # Date: Wed, 31 May 2000 18:58:11 GMT / From: "John Nixon" <jorlnixon@worldnet.att.net>  Subject: Re: scsi disks on OVMS F Message-ID: <7hdZ4.1781$pk3.103690@bgtnsc04-news.ops.worldnet.att.net>  G I think the size of disk you can use under VMS 7.1 is mostly a function F of how big an enclosure you have.  I have some 36+GB arrays configured
 under VMS 7.1   / "Donal Day" <dbd@virginia.edu> wrote in message & news:39355C34.5796363E@virginia.edu...J > I have a alpha workstation based on a "durango" mother board with a scsiC > controller interfaced to a Quantum 4.5 Gb Atlas II 3.5 inch disk.  > G > I wish to add another scsi drive and would like to know if there is a G > limit to the disk size that I can iitialize and mount under OVMS 7.1?  > ? > I would be foolish to buy a 18 Gbyte and only see part of it.  >  > Thanks >  > Donal Day  >    ------------------------------  # Date: Wed, 31 May 2000 19:30:36 GMT ' From: "mark" <bmlyczewskib@bddwpab.com>  Subject: Re: scsi disks on OVMS = Message-ID: <01bfcb36$b07085a0$51ca0080@mlyczewski.ddpwa.com>   4 I have had a 47 Gig Seagate connected to a OVMS 7.1.; I believe I saw your question on answered at the VMS Wizard = site and although I cannot recall the actual reply, the limit @ was such that you don't really have to worry about it right now. Terrabytes come to mind..   - Donal Day <dbd@virginia.edu> wrote in article # <39355C34.5796363E@virginia.edu>... J > I have a alpha workstation based on a "durango" mother board with a scsiC > controller interfaced to a Quantum 4.5 Gb Atlas II 3.5 inch disk.  > G > I wish to add another scsi drive and would like to know if there is a G > limit to the disk size that I can iitialize and mount under OVMS 7.1?  > ? > I would be foolish to buy a 18 Gbyte and only see part of it.  >  > Thanks >  > Donal Day  >  >    ------------------------------  + Date: Wed, 31 May 2000 15:03:12 -0300 (EST)  From: becherini@vortex.ufrgs.br  Subject: re: Telnet and License , Message-ID: <00053115031257@vortex.ufrgs.br>  : Received:	by vortex.ufrgs.br (V5.0A-1, OpenVMS V7.2 Alpha)+ From:		Fabio Becherini <becherini@ufrgs.br>  Reply-to:	<becherini@ufrgs.br>< Comments:	@vortex.ufrgs.br, vortex(46.451)::, psi%........::2 References:	BR, TCHE, UFRGS, CPD network, Cia-INFO- Organization:	Cia-INFO /DRS /CPD-UFRGS /UFRGS O _______________________________________________________________________________   / . From: ezzaoudi med <m.ezzaoudi@digitem.co.ma>  . Subject: Telnet and License ' . Date: Wed, 31 May 2000 13:39:03 +0000  . To: Info-VAX@Mvb.Saic.Com  .  . Hi, = . I have probleme with telnet in Alpha OpenVMS configuration. J . When 200 users are connected with Telnet , no new connexion is possible. . 0 . But I can do connection by Decnet ( set host).9 . with UCX>SHOW SERVICE TELNET /FULL   I have a limit=320 ? . I have a UCX license with UNIT=1050 .  Is it the probleme ???  . An Alpha VMS license = 15 ! . An Alpha VMS users license = 75  . 
 . Thank you .      	try it ...    		set logins /interactive   	 	regards,   N  _____________________________________________________________________________O |                                                                             | O | Fabio Becherini                   System & Network Manager, Webmaster UFRGS | O | CPD-UFRGS                         Centro de Processamento de Dados da UFRGS | O |                                   Universidade Federal do Rio Grande do Sul | O |                                                   Divisao de Rede e Suporte | O |                                          (55)(51) 316-5041 / 331-1215 (fax) | O | Rua Ramiro Barcelos, 2574  -  Santa Cecilia  -  Porto Alegre - RS -  Brasil | O |_____________________________________________________________________________| O |                                                                             | O | Cia-INFO (c) Ophicin@ das Informacoes                   Coordenacao Central | O |_____________________________________________________________________________| O |                                                                             | O | INTERnet:  fabio.becherini@ufrgs.br              DECnet:  vortex::becherini | O |_____________________________________________________________________________|    ------------------------------  $ Date: Thu, 1 Jun 2000 12:40:24 +1000/ From: "Phil Howell" <howellp@snowyhydro.com.au>  Subject: Re: Telnet and License 1 Message-ID: <v2kZ4.5765$N4.218857@ozemail.com.au>   = There are sysgen parameters ijoblim bjoblim njoblim & rjoblim E which you cannot exceed whatever your set logins or ucx licences say.  Phil8 ezzaoudi med <m.ezzaoudi@digitem.co.ma> wrote in message' news:393515F7.75AE8AEA@digitem.co.ma...  > Hi, = > I have probleme with telnet in Alpha OpenVMS configuration. J > When 200 users are connected with Telnet , no new connexion is possible. > 0 > But I can do connection by Decnet ( set host).9 > with UCX>SHOW SERVICE TELNET /FULL   I have a limit=320 ? > I have a UCX license with UNIT=1050 .  Is it the probleme ???  > An Alpha VMS license = 15 ! > An Alpha VMS users license = 75  > 
 > Thank you .  >  >  >    ------------------------------  # Date: Wed, 31 May 2000 19:51:10 GMT ' From: "mark" <bmlyczewskib@bddwpab.com>   Subject: UCX$POP_SERVER problems= Message-ID: <01bfcb39$9029dbe0$51ca0080@mlyczewski.ddpwa.com>   8 I am trying to set up a VMS box running 7.1 and UCX 4.1.  G When I try to connect to the host using a POP client (running on Win95) 8 the server dies, sending an email to the System account,B and the UCX$POP_RECV_STARTUP.LOG file contains the following text:J (I replaced the actual domain name with mydomain for security reasons...ie# I haven't locked this poppy up yet)        $ !+K $ !             UCX$POP_RECV_STARTUP.COM -- DEC TCP/IP Services for OpenVMS 	 Software, 9 $ !                        POP receiver startup procedure  $ ! 0 $ !                        COPYRIGHT (C) 1996 BY= $ !                    DIGITAL EQUIPMENT CORPORATION, MAYNARD < $ !                     MASSACHUSETTS.  ALL RIGHTS RESERVED. $ ! J $ !  THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIEDC $ !  ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE 	 INCLUSION F $ !  OF THE ABOVE COPYRIGHT NOTICE.  THIS SOFTWARE OR ANY OTHER COPIESI $ !  THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY OTHER A $ !  PERSON.  NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY  TRANSFERRED. $ ! I $ !  THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE  AND A $ !  SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT  CORPORATION. $ ! H $ !  DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS; $ !  SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL.  $ !  $ L !*************************************************************************** ** $ !  $ ! Modifications  $ ! " $ ! 01  Karol Zielonko Feb-29-19965 $ ! Cloned and munged from original IUPOP .com files.  $ L !*************************************************************************** ** $ !- $ SET VERIFY# $ ON WARNING   THEN GOTO ERROR_TRAP # $ ON CONTROL_Y THEN GOTO FINAL_EXIT  $! $!************************ $! Purge log files $!************************ $!$ $ SAVE=5+2*f$getsyi("CLUSTER_NODES") $ PURGE/KEEP=5 $!************************
 $! Initialize  $!************************ $!I $! If a POP postmaster is defined then send mail to them if error occurs. $ $! Otherwise send to SYSTEM account.. $ PROGRAMMERS = F$TRNLNM("UCX$POP_POSTMASTER")5 $ IF PROGRAMMERS .EQS. "" THEN PROGRAMMERS = "SYSTEM"   $ NODE    = F$GETSYI("NODENAME") $!- $ DEFINE SYS$SCRATCH  SYS$SYSDEVICE:[UCX$POP]  $!2 $! Message maximum = 0 means *no* message maximum." $ DEFINE UCX$POP_MESSAGE_MAXIMUM 0 $!> $! Let a link remain idle for two mintes before timing it out.2 $ DEFINE UCX$POP_LINK_IDLE_TIMEOUT "0 00:02:00.00"L $!************************************************************************** ****J $! To turn on any of the following options simply uncomment. Remember thatB $! "boolean" logicals are turned on when the logical is defined to anything. WeK $! only set them to "1" by convention. If you want a boolean logical to be  G $! turned off then do not define it. If you define it to "0" or "FALSE"  you'll $! be turning it on.L $!************************************************************************** **** $!I $! Do not include any personal name from the VMS mail "From:" line in the 6 $! "From:" header line that we send to the POP client.! $! DEFINE UCX$POP_PERSONAL_NAME 1  $!; $! Do not do a PURGE/RECLAIM when closing user's mail file. ! $! DEFINE UCX$POP_PURGE_RECLAIM 1  $!  $! Do not ignore mail11 headers.) $! DEFINE UCX$POP_IGNORE_MAIL11_HEADERS 1  $!) $! Take UCX POP server default log level. H $! DEFINE UCX$POP_LOG_LEVEL "enter ERROR, INFORMATIONAL, THREAD or DEBUG here"  $! $!************************ $! Start the Server  $!************************* $ UCXPOP := $SYS$SYSTEM:UCX$POP_SERVER.EXE $ UCXPOP1 19100-05-31 05:50:19 sizeof(block_wait_times) 160 3 19100-05-31 05:50:19 sizeof(struct vms_time_rec) 32   19100-05-31 05:50:19 num_elems 5F 19100-05-31 05:50:19 starting UCX POP server UCX V4.1-12, OpenVMS V7.10 Alpha on host nodename.mydomain.com and port 110 19100-05-31 05:50:19  , 19100-05-31 05:50:19 POP configuration info:4 19100-05-31 05:50:19    ignore_mail11_headers: FALSE. 19100-05-31 05:50:19    send_id_headers: FALSE* 19100-05-31 05:50:19    disuserpass: FALSE, 19100-05-31 05:50:19    personal_name: FALSE, 19100-05-31 05:50:19    purge_reclaim: FALSE- 19100-05-31 05:50:19    max_messages: No max. 7 19100-05-31 05:50:19    master_log_level: INFORMATIONAL * 19100-05-31 05:50:19    security: FRIENDLY1 19100-05-31 05:50:19    decnet_rewrite: TRANSFORM 8 19100-05-31 05:50:19    quoted_decnet_rewrite: TRANSFORM, 19100-05-31 05:50:19    sndbuf: UCX default.; 19100-05-31 05:50:19    link_idle_timeout:    0 00:02:00.00  19100-05-31 05:50:19  ( 19100-05-31 05:50:19 Miscellaneous info:H 19100-05-31 05:50:19    UCX POP version: UCX V4.1-12, OpenVMS V7.1 Alpha* 19100-05-31 05:50:19    POP server PID: A7: 19100-05-31 05:50:19    POP server process name: UCX$POP_1 19100-05-31 05:50:19  - 19100-05-31 05:50:19 SMTP configuration info: + 19100-05-31 05:50:19    substitute_domain:   19100-05-31 05:50:19   19100-05-31 05:50:21  D %%%%%%%%%%%%                   31-MAY-2000 05:50:21.68  %%%%%%%%%%%%; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual : address=FFFFFFFFF64E733F, PC=000000000003F37C, PS=0000001B  ; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual : address=00000000F64E733F, PC=000000000003F37C, PS=0000001B  2   Improperly handled condition, image exit forced.1     Signal arguments:   Number = 0000000000000005 1                         Name   = 000000000000000C 1                                  0000000000010000 1                                  00000000F64E733F 1                                  000000000003F37C 1                                  000000000000001B        Register dump:J     R0  = 00000000007EFD09  R1  = 000000007B520017  R2  = 0000000000011DC0J     R3  = 0000000000050410  R4  = 000000007AFC79C8  R5  = 0000000000509140J     R6  = 0000000000023830  R7  = 0000000000050170  R8  = 0000000000050250J     R9  = 0000000000050370  R10 = 00000000000503F0  R11 = 00000000000507D6J     R12 = 000000007AFC7308  R13 = 0000000000050260  R14 = 0000000000000000J     R15 = 00000000009EAE4C  R16 = 000000007AFC7328  R17 = 00000000F64E72F7J     R18 = 0000000000000020  R19 = 0000000000000000  R20 = 00000000000005A8J     R21 = 0000000000023BE8  R22 = 0000000000000017  R23 = 000000007AFC7350J     R24 = 0000000000000000  R25 = 0000000000000588  R26 = 000000000003F33CJ     R27 = 0000000000011CE0  R28 = 0000000000000000  R29 = 000000007AFC72E0J     SP  = 000000007AFC72E0  PC  = 000000000003F37C  PS  = 200000000000001B
 $ ERROR_TRAP:  $ SS_STATUS = $STATUS  $ ON WARNING THEN CONTINUE& $ ERROR_MESSAGE = F$MESSAGE(SS_STATUS) $ NODE = F$GETSYI("NODENAME")  $!B $ MAIL SYS$INPUT "SYSTEM"/SUBJECT="KIRK - %SYSTEM-F-ACCVIO, access@ violation, reason mask=!XB, virtual address=!XH, PC=!XH, PS=!XL"H Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:? The UCX POP server has experienced a runtime error.  The reason @ for the error should appear on the subject line of this message.  7 Please investigate this problem as quickly as possible. 
 Thank you. $! $!************************
 $! Final Exit  $!************************
 $ FINAL_EXIT:  $ EXIT8   UCX$POP      job terminated at 31-MAY-2000 05:50:22.92     Accounting information: J   Buffered I/O count:                267      Peak working set size:       4528H   Direct I/O count:                  197      Peak virtual size:         178240K   Page faults:                      1448      Mounted volumes:                 0 C   Charged CPU time:        0 00:00:00.98      Elapsed time:       0  00:00:05.59      **************** **************** ****************    = and here is the list of all the UCX images I got from INSTAL>       1    UCX$ACCESS_SHR;1 Open     Shar          Lnkbl  1    UCX$CFS_SHR;1    Open     Shar     Prot Lnkbl  1    UCX$ESNMP_SHR;1  Open Hdr Shar Prv      Lnkbl  1    UCX$IPC_SHR;1    Open     Shar          Lnkbl  1    UCX$RPCXDR_SHR;1 Open     Shar          Lnkbl      UCX$SMTP_MAILSHR;1 1                     Open     Shar          Lnkbl      UCX$SMTP_PARSESHR_TV;1 1                     Open     Shar          Lnkbl              UCX$ESNMP_SERVER;1 &                     Open Hdr Shar Prv &    UCX$FTP;1        Open Hdr Shar Prv &    UCX$FTPC;1       Open Hdr Shar Prv &    UCX$FTPD;1       Open Hdr Shar Prv &    UCX$OS_MIBS;1    Open Hdr Shar Prv &    UCX$POP_SERVER;1               Prv &    UCX$RLOGIN;1     Open Hdr Shar Prv     UCX$SMTP_RECEIVER;1&                                   Prv &    UCX$TELNET;1     Open Hdr Shar Prv "    UCX$UCP;1        Open Hdr Shar    ------------------------------   Date: 31 May 2000 17:55:35 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)( Subject: Re: Unneeed RMS overhead with C, Message-ID: <8h3jmn$ab8@gap.cco.caltech.edu>  ] In article <4.3.1.0.20000531125418.01e89630@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes: / >At 03:37 PM 5/31/00 +0000, Hoff Hoffman wrote:  > H >>In article <4.3.1.0.20000531103238.00e495c0@24.8.96.48>, Dan Sugalski  >><dan@sidhe.org> writes: 4 >>:At 11:47 AM 5/31/00 +0200, Jan Vorbrueggen wrote:M >>:>It seems to me that the crucial point is "Tru64 with its more lightweight P >>:>filesystem": that implies, to me, that using RMS naively in that applicationL >>:>is a problem, especially if you're programming via, say, the C RTL. In a4 >>:>sense, you're buying more than you've asked for. >>: I >>:This is definitely true, and something that the C RTL team ought to be L >>:working on, honestly. The RTL should keep one cluster in flight in or outK >>:for files opened naively (i.e. with a plain open or fopen, with no extra N >>:doodads to speak of) and I bet we'd see a nice performance boost with plain >>:ported software.  >>I >>   This arguably isn't C, nor best fixed in the C RTL.  The default RMS J >>   defaults suck, bluntly.  The RMS defaults were determined a long timeD >>   ago in a cluster far, far away, and many of the relevent systemH >>   constraints (eg: available physical memory, etc) have changed.  The >>   RMS defaults have not.  > G >Oh, without a doubt. I was looking at things from a C RTL perspective   >mainly because: > L >1) C's default I/O routines are less well integrated into RMS than all the  >other languages I've seenL >2) Access to the RMS stuff in the context of the default I/O system's more ' >black art in C than in other languages L >3) Most of the code that sees the big hit is C, ported from other platformsL >4) Backwards compatibility wouldn't be compromised nearly as much. (If you K >were using the defaults anyway, it would make sense that the RTL could do  D >whatever it wanted--hey, this is C, after all, and the RTL changes   >behaviour at the drop of a hat)J >5) It would be a relatively easy upgrade--just another behaviour changed  >with a C RTL ECO , >6) I use C more than any other language. :)  " And Dan also wrote to me directly:   > H >Just out of curiosity, do you see any sorts of speedup from doing this: >  >$ SET RMS/BUFFER=255/BLOCK=127  > @ >before running the programs that perform less than wonderfully?  G RMS tuning helps for some things, not so much for others.  For write it G never, ever equals file caching (or, roughly the equivalent, directing  H output to  nla0:).   "gunzip" is a classic case.  On my linux boxes it'sJ instantaneous, except for really huge files, but no amount of tuning makesJ it that fast on OpenVMS.  On linux it usually reads the file out of memoryG (it just came in via FTP, so still in cache) and writes it back there.  D Memory bandwidth on the DS10 is very high, so this is very fast.  OnI OpenVMS it reads the file from disk, and the program must complete all IO J back to disk before it exits (I asked that in an earlier thread) so if theI output is 100 Mb it has to wait until all 100 Mb are written to disk.  If K RMS is set _just_ right that takes about 5 seconds.  If it's set wrong (the C default RMS /EXTEND is very wrong for gunzip) it can take minutes.    L I mean, it's shocking sometimes how fast things are on the Linux box (which C is essentially identical to the VMS box - same disks, very similar  G Intraserver SCSI card). I have a program which splits a certain type of E linear text file ("fasta" format) out into chunks of N entries each.  E Here's how it runs on a RH 6.2 Linux box and a 7.2-1 OpenVMS box when F processing an 8 Mb file, this on two nearly identical DS10s (slightly + different Intraserver U2W lvd controllers):    Seconds Y  0.5        Linux (by my wristwatch - difficult to time when the interval is this short.) " 30          VMS,Default RMS values, 10          VMS,set rms/buffer=255/block=1278  6          VMS,set rms/buffer=255/block=127/extend=22001  1.5        VMS,default RMS values, set def nla0: 0  1.0        VMS,set rms/block=127, set def nla0:  E "Out of the box and untuned" Linux is 60X faster than OpenVMS.  With  H extensive tweaking to OpenVMS Linux is merely 12X faster.  I fail to seeK the benefit for VMS users in THAT.  Things only get close when I direct the H output files into the bit bucket, and even then VMS never caught up withK Linux as it still had to read the 8 Mb file from disk no matter what I did. K It's a 20 Mb/sec disk so about 1 second to read it.  Feel free to mess with H this code if you want.  The program is called "mysplit.c" and follows my$ signature. Fasta format looks like:    >name1V ACGAGTTAG   (etc., this is DNA or Protein sequence, usually wrapped at col. 80 or 100)
 ACGAGAGATA >name2	 AGTAGTAGT 	 AGTAGTAGT   E (I know, the program will not handle a sequence with extremely long,   nonwrapped sequence properly!)  G And you can find some really huge files to mess with in this format at    &   ftp://ftp.ncbi.nlm.nih.gov/blast/db/   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   /* MYSPLIT.C  5 quicky program.  It splits a fasta file into a series 4 of new files at N line intervals.  First argument is4 the filename and second is the number of entries per
 file fragment    */   #include <stdlib.h>  #include <stdio.h> #include <unistd.h>  #define MYMAXSTRING 100000! int main(int argc, char *argv[]){ 
 char *infile;  char *outfile; char root[]="frag";  char bigstring[MYMAXSTRING]; char outname[200]; int  n,count,fragcount; 
 FILE *fin; FILE *fout;         fout=NULL;   fragcount=0;
   count=0;   n=0;9   if(argc != 3 || (sscanf(argv[2],"%d",&n)==EOF) || n<1){ [     (void) printf("Usage:  mysplit infile N, where N is number of entries per fragment\n");      exit(0);   }    infile=argv[1]; 6   (void) printf("Processing %s with n=%d\n",infile,n);      fin=fopen(infile,"r");   if(fin==NULL){:    (void) printf("Could not open input file %s\n",infile);     exit(0);   } 3   while( fgets(bigstring,MYMAXSTRING,fin) != NULL){      if(bigstring[0] == '>'){       count--;       if(count<=0){           count = n;           fragcount++; $          if(fout!=NULL)fclose(fout);6          (void) sprintf(outname,"frag%.3d",fragcount);;          (void) printf("Opening output file %s\n",outname); #          fout = fopen(outname,"w");        }      } (     (void) fprintf(fout,"%s",bigstring);   } I   (void) printf("All done, entries in final file segment: %d\n",n-count); 
   exit(1); }    ------------------------------  % Date: Wed, 31 May 2000 14:18:23 -0400 " From: Dan Sugalski <dan@sidhe.org>( Subject: Re: Unneeed RMS overhead with C8 Message-ID: <4.3.1.0.20000531141504.00e49260@24.8.96.48>  . At 05:55 PM 5/31/00 +0000, David Mathog wrote:L >I mean, it's shocking sometimes how fast things are on the Linux box (whichC >is essentially identical to the VMS box - same disks, very similar  >Intraserver SCSI card).  L You don't even need the same box. On my home machine (A 300MHz Celeron with J 64M of ram, an IDE drive, and running Enlightenment as my window manager, H which is a *pig* for memory) building perl is several (like five) times H faster than building it here at work on a TurboLaser with lots of 6/525 6 processors, ~8G free ram, and HSZ80-connected storage.  J Granted, Dec C is a slower compiler than gcc, and it produces better code 3 as a result, but the effects are wildly noticeable.    					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunk    ------------------------------   Date: 31 May 2000 14:56 -0400  From: hein@eps.zko.dec.c*m( Subject: Re: Unneeed RMS overhead with C& Message-ID: <31MAY200014564035@miasys>  _ In article <4.3.1.0.20000531125418.01e89630@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes... / >At 03:37 PM 5/31/00 +0000, Hoff Hoffman wrote: 4 >>:At 11:47 AM 5/31/00 +0200, Jan Vorbrueggen wrote:  F Hi, I was just passing through the neighbourhood and stumbled into the* middle of this RMS thread. A few comments:  / First of, >>>> Unneeed RMS overhead with C <<<<   F DEC C actually does NOT use RMS for plain unshared sequential file IO.D They decided to do so precisely to avoid unneeded RMS overhead in C!K Specifically they avoid the CMEXEC round-trip per record and the associated C argument probing and can more readily implement stuff like 'unget'.   E This is good and bad. It is better on CPU time, but we have plenty of F that these days! They did not as good a job in IO as RMS can do and IO can never be fast enough.   H Now VAXC and early DECC were really dumb in doing single block IO. Yuck.G DECC now listens to most SET RMS parameters so at least you can specify # a large IO buffer size for example.   H RMS, is probably too conservative, notably with respect to memory usage.I But it is willing to listen to your superior application/system insights!   3 2 buffers, 16 blocks = 8KB each just is not enough.   L Hundreds of buffers, each hundreds of blocks each for (potentially) hundredsL of file opened by (potentially) hundreds for processes is probably too much.   I suggest you try:  < 	SET RMS [/SYSTEM] /SEQ /BLOCK=64 / BUFFER = 4 / EXTE = 1000" 	SET RMS [/SYSTEM] /IND /BUFFER=20  6 This will give you the bulk of all the potential gain.  C NOTE, multy-buffers are really only effective with the application  E specifically requesting READ-AHEAD and WRITE-BEHIND  (RAB: RAH, WBH). , Not all applications/ language RTLs do this.  E There is little or no excuse for RMS not switching into RAH mode when > more than one records it read sequentially... but it does not.  A Enabling WBH for all would go against the VMS philosophy of only  I allowing potential data loss when explicitly indicated by the application   C For random IO to shared file the RMS design dictates write-through, E but knows how to hold up through 'deferred write' = DFW if it is told ) that it is ok to take the increased risk. A FORTRAN is one of the few (only?) language which sets that option . by default. COBOL has a handy interface to it.   <end of brain dump>    hth, 	Hein.   ------------------------------  % Date: Wed, 31 May 2000 15:33:31 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> ( Subject: Re: Unneeed RMS overhead with C( Message-ID: <8h3p8b$o2h$1@pyrite.mv.net>  H <hein@eps.zko.dec.c*m> wrote in message news:31MAY200014564035@miasys...   ...   B > Enabling WBH for all would go against the VMS philosophy of onlyK > allowing potential data loss when explicitly indicated by the application   	 Hi, Hein!   H I'd think that for non-shared sequential file sequential record-orientedH write access, automatic WBH (not deferred write) shouldn't really make aI *qualitative* change in RMS behavior, since the application already isn't L aware of when records go to disk (i.e., when a buffer fills and is flushed).   - bill   ------------------------------  % Date: Wed, 31 May 2000 16:25:12 -0400 " From: Dan Sugalski <dan@sidhe.org>( Subject: Re: Unneeed RMS overhead with C8 Message-ID: <4.3.1.0.20000531161436.01e962a0@24.8.96.48>  6 At 02:56 PM 5/31/00 -0400, hein@eps.zko.dec.c*m wrote:G >In article <4.3.1.0.20000531125418.01e89630@24.8.96.48>, Dan Sugalski   ><dan@sidhe.org> writes...1 > >At 03:37 PM 5/31/00 +0000, Hoff Hoffman wrote: 6 > >>:At 11:47 AM 5/31/00 +0200, Jan Vorbrueggen wrote: > G >Hi, I was just passing through the neighbourhood and stumbled into the + >middle of this RMS thread. A few comments:  > 0 >First of, >>>> Unneeed RMS overhead with C <<<< > G >DEC C actually does NOT use RMS for plain unshared sequential file IO. E >They decided to do so precisely to avoid unneeded RMS overhead in C! L >Specifically they avoid the CMEXEC round-trip per record and the associatedD >argument probing and can more readily implement stuff like 'unget'.  J Ah, that makes sense, since the C RTL treats Stream_LF files like they're  just binary data anyway.  F >This is good and bad. It is better on CPU time, but we have plenty ofG >that these days! They did not as good a job in IO as RMS can do and IO  >can never be fast enough.  I Sounds like a good place to spend some developer days. Speeding up plain  E sequential reads in the C RTL would be a *huge* win for all sorts of  K programs, including the upcoming Apache release. (And the pathworks server   too, if memory serves)  I >Now VAXC and early DECC were really dumb in doing single block IO. Yuck. H >DECC now listens to most SET RMS parameters so at least you can specify$ >a large IO buffer size for example.  L That's something. Proactively keeping the buffers filled for read (or empty # for write) would be a Better Thing.   I >RMS, is probably too conservative, notably with respect to memory usage. J >But it is willing to listen to your superior application/system insights! > 4 >2 buffers, 16 blocks = 8KB each just is not enough.  4 I think "pathetic" is more like it at this point. :)  M >Hundreds of buffers, each hundreds of blocks each for (potentially) hundreds M >of file opened by (potentially) hundreds for processes is probably too much.  >  >I suggest you try:  > E >         SET RMS [/SYSTEM] /SEQ /BLOCK=64 / BUFFER = 4 / EXTE = 1000 + >         SET RMS [/SYSTEM] /IND /BUFFER=20  > 7 >This will give you the bulk of all the potential gain.  > C >NOTE, multy-buffers are really only effective with the application F >specifically requesting READ-AHEAD and WRITE-BEHIND  (RAB: RAH, WBH).- >Not all applications/ language RTLs do this.   J I'll have to give this a whirl to see if it makes any difference locally. + Probably not, as we're mostly C/C++, but...   F >There is little or no excuse for RMS not switching into RAH mode when? >more than one records it read sequentially... but it does not.  > A >Enabling WBH for all would go against the VMS philosophy of only J >allowing potential data loss when explicitly indicated by the application  J Enabling it for C stdio makes perfect sense. It already guarantees (well, K promises) some level of buffering, so the fact that data may or may not be  K in async flight is just fine. Whether this is a good thing in general is a  F language/RTL design issue, and I'm just Not Going There at the moment.  D >For random IO to shared file the RMS design dictates write-through,F >but knows how to hold up through 'deferred write' = DFW if it is told* >that it is ok to take the increased risk.  J Which is fine, since you have to do Odd Magic to open files shared anyway.   					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunk    ------------------------------  % Date: Wed, 31 May 2000 15:51:30 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: VAX on Intel?( Message-ID: <8h3qa2$pv5$1@pyrite.mv.net>  F Well, after the initial inclination to parse 'VAX on Intel' as 'VMS on" Intel' passes, it becomes clearer.  I Neat.  Interesting.  But is the ability to run VMS on it actually useful? L (I.e., is there anything like an approximate "PIII Mhz-to-VUPs" relationship@ that could hint at whether VMS could boot on it in my lifetime?)   - bill  > Eric Hollander <eric.hollander@NOSPAMeds.com> wrote in message# news:39351223.433A@NOSPAMeds.com...  > Jeff Killeen wrote:  > >  > > http://www.charon-vax.com/ > >  > > -- > > ! > > Jeff Killeen - www.Killeen.cc I > > =====================================================================   > Does it exist ? VAX in INTEL ? > -- > Eric Hollander > H > Wie de toekomst als tegenwind ervaart, loopt in de verkeerde richting./ > (E.M.C. Michiels, Universiteit van Amsterdam)  > 2 > ************************************************2 > To reply thru E-mail, remove NOSPAM from address2 > ************************************************   ------------------------------  + Date: Wed, 31 May 2000 13:30:47 -0700 (PDT) ! From: Tom Linden <tom@kednos.com>  Subject: Re: VAX on Intel?E Message-ID: <Pine.ULT.3.91.1000531132952.269D-100000@gunn.kednos.com>   % On Wed, 31 May 2000, Bill Todd wrote:   ' > Date: Wed, 31 May 2000 15:51:30 -0400 ' > From: Bill Todd <billtodd@foo.mv.com>  > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: VAX on Intel? > H > Well, after the initial inclination to parse 'VAX on Intel' as 'VMS on$ > Intel' passes, it becomes clearer. > K > Neat.  Interesting.  But is the ability to run VMS on it actually useful? N > (I.e., is there anything like an approximate "PIII Mhz-to-VUPs" relationshipB > that could hint at whether VMS could boot on it in my lifetime?) >   E There web site seems to indicate that 1 VUP per 100Mhz of intel chip   performance.  	  > - bill  > @ > Eric Hollander <eric.hollander@NOSPAMeds.com> wrote in message% > news:39351223.433A@NOSPAMeds.com...  > > Jeff Killeen wrote:  > > >   > > > http://www.charon-vax.com/ > > >  > > > -- > > > # > > > Jeff Killeen - www.Killeen.cc K > > > ===================================================================== " > > Does it exist ? VAX in INTEL ? > > -- > > Eric Hollander > > J > > Wie de toekomst als tegenwind ervaart, loopt in de verkeerde richting.1 > > (E.M.C. Michiels, Universiteit van Amsterdam)  > > 4 > > ************************************************4 > > To reply thru E-mail, remove NOSPAM from address4 > > ************************************************ >  >  >   A                __________________________________________________ A               /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ @              /_/                                             /_/?             /_/     Tom Linden              PL/I Support    /_/ >            /_/    Kednos Corporation       OpenVMS and     /_/=           /_/   tel 831 373 7003          Tru64 Unix      /_/ <          /_/_____________________________________________/_/;         /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/    ------------------------------  # Date: Wed, 31 May 2000 20:26:04 GMT 3 From: Eric Dittman <dittman@narnia.int.dittman.net>  Subject: Re: VAX on Intel?? Message-ID: <wzeZ4.22188$v7.1306952@news-west.usenetserver.com>   5 In comp.os.vms Bill Todd <billtodd@foo.mv.com> wrote: H : Well, after the initial inclination to parse 'VAX on Intel' as 'VMS on$ : Intel' passes, it becomes clearer.  K : Neat.  Interesting.  But is the ability to run VMS on it actually useful? N : (I.e., is there anything like an approximate "PIII Mhz-to-VUPs" relationshipB : that could hint at whether VMS could boot on it in my lifetime?)  K The specifications page doesn't like the speed of the default emulated VAX, J but mentions an additional CPU model is available that is 1VUP per 100MHz,H which means a 500MHz PIII would run as fast as a 5VUP VAX.  I don't know/ if the additional CPU model is included or not.  --   Eric Dittman dittman@dittman.net    ------------------------------  % Date: Wed, 31 May 2000 21:35:52 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>  Subject: Re: VAX on Intel?- Message-ID: <3935CC08.3A8E9ED8@earthlink.net>    Jeff Killeen wrote:  >  > http://www.charon-vax.com/  A Looks like someone ELSE sees the value/potential of VMS on Intel.   1 Wonder what they know that DEC/Compaq doesn't....    --   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: Thu, 1 Jun 2000 02:55:20 GMT0 From: "Terry C. Shannon" <shannon@world.std.com> Subject: Re: VAX on Intel?% Message-ID: <FvGG1q.p8@world.std.com>   B "David J. Dachtera" <djesys.nospam@earthlink.net> wrote in message' news:3935CC08.3A8E9ED8@earthlink.net...  > Jeff Killeen wrote:  > >  > > http://www.charon-vax.com/ > C > Looks like someone ELSE sees the value/potential of VMS on Intel.  >   I Yes indeed. There are few things as cool as watching OpenVMS boot up on a  Windoze PC!   K Granted, Charon-VAX is just an emulator, but it's a great piece of work and % the perpetrators are to be commended.   K I just got a copy of the software; will provide a review in SKC Pretty Soon G Now. In the interim, check the product out at the above-referenced URL.    cheers,    terry s    ------------------------------  # Date: Thu, 01 Jun 2000 03:00:26 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com> Subject: Re: VAX on Intel?3 Message-ID: <elkZ4.61$ru5.1966@typhoon.aracnet.com>   H In comp.org.decus David J. Dachtera <djesys.nospam@earthlink.net> wrote:C > Looks like someone ELSE sees the value/potential of VMS on Intel.   3 > Wonder what they know that DEC/Compaq doesn't....   K Me I wonder what Compaq knows that they don't.  If I read correctly they're H emulating a MicroVAX II.  I suspect that it might make sense from their I standpoint since they've already got a PDP-11 emulator (haven't looked to  see exactly what it emulates).  J One slight problem, OpenVMS V7.2 is supposed to be the last to support theL MicroVAX II.  Besides if they're emulating the MicroVAX II, one would assumeI that means you're limited to 16MB RAM.  Then there is the question of the > fact it sounds like they're emulating RD54's for the disks....  I It sounds like it's got real potential, I just question their choice of a  model to emulate.    			Zane    ------------------------------  + Date: Wed, 31 May 2000 20:47:24 -0700 (PDT) ! From: Tom Linden <tom@kednos.com>  Subject: Re: VAX on Intel?E Message-ID: <Pine.ULT.3.91.1000531202841.269K-100000@gunn.kednos.com>   H This really is no major technological feat, been done many times in the H past, earliest I remember is the IBM 1401.  But, BTW FX!32 from Digital G which was a very nifty tool for getting Windoze applications to run on  B Alpha running NT was also a VERY clever product.  What makes it a J possibly attractive proposition is the cost of Intel based HW.  It is the F Software that counts, I mean who really cares if it runs on VAX, AXP, K Intel or whatever, its the price per unit of operation that is significant. G VAX was a great architectural design, AXP was ill conceived, and Intel  H was obolete before it was launched, but then such considerations seldom 1 factor into the follies with which we must labor.   I But getting back the topic, the authors claim about 1 VUP per 100 MHz of  G underlying Intel machinery.  My question is, what is the corresponding  I relationship to Alpha?  For rather modest sums I can get (actually have)  H about 1 Ghz of Intel power unfortunately running W2K, thus about 10 VUP  for less than $1K.   regards  Tom     ( On Thu, 1 Jun 2000, Zane H. Healy wrote:  % > Date: Thu, 01 Jun 2000 03:00:26 GMT 2 > From: Zane H. Healy <healyzh@shell1.aracnet.com> > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: VAX on Intel? > J > In comp.org.decus David J. Dachtera <djesys.nospam@earthlink.net> wrote:E > > Looks like someone ELSE sees the value/potential of VMS on Intel.  > 5 > > Wonder what they know that DEC/Compaq doesn't....  > M > Me I wonder what Compaq knows that they don't.  If I read correctly they're J > emulating a MicroVAX II.  I suspect that it might make sense from their K > standpoint since they've already got a PDP-11 emulator (haven't looked to   > see exactly what it emulates). > L > One slight problem, OpenVMS V7.2 is supposed to be the last to support theN > MicroVAX II.  Besides if they're emulating the MicroVAX II, one would assumeK > that means you're limited to 16MB RAM.  Then there is the question of the @ > fact it sounds like they're emulating RD54's for the disks.... > K > It sounds like it's got real potential, I just question their choice of a  > model to emulate.  > 	 > 			Zane  >   A                __________________________________________________ A               /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ @              /_/                                             /_/?             /_/     Tom Linden              PL/I Support    /_/ >            /_/    Kednos Corporation       OpenVMS and     /_/=           /_/   tel 831 373 7003          Tru64 Unix      /_/ <          /_/_____________________________________________/_/;         /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/    ------------------------------  # Date: Thu, 01 Jun 2000 04:30:04 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com> Subject: Re: VAX on Intel?3 Message-ID: <gFlZ4.63$ru5.1982@typhoon.aracnet.com>   " Tom Linden <tom@kednos.com> wrote:K > But getting back the topic, the authors claim about 1 VUP per 100 MHz of  I > underlying Intel machinery.  My question is, what is the corresponding  K > relationship to Alpha?  For rather modest sums I can get (actually have)  J > about 1 Ghz of Intel power unfortunately running W2K, thus about 10 VUP  > for less than $1K.  K Not sure I'm on totaly the same wavelength as you here.  Mainly becuase I'm J not sure where you come up with the 10 VUP's figure for less than $1K.  AtK the moment a 1Ghz Intel processor is just short of $1k, a system to go with : that is probably going to cost as much as a low-end Alpha.  J Ah... I just looked at the web-page again and see they've apparently addedK to it in the last couple days.  At least I don't remeber any comments about  it running on Alphas.   J Anyway, you've got the cost of the hardware to run it, you've got the costH of the Emulator itself, and then you've got the cost of licenses for theG OpenVMS and anything you're going to want to run on it.  In the case of E Industrial control systems I'd assume that means you've also got some K specialized hardware plugged into your existing Q-Bus, that means aditional H money spent on a Q-Bus-to-PCI widget.  Still in the case of replacing anJ existing control system with modern hardware it's likely to be worth it to gain reliability.   L I also snagged the manual and took a look at it, I guess it's emulating moreI than just a MicroVAX II, and when it's emulating a 3100 it can have up to H 128MB of RAM.  In fact looking through the manual it looks to be a quiteI nice product.  To bad they don't give that much info on they're web page.   K My initial reaction was along the lines of COOL, but to bad it runs on a MS J OS.  After some thought, and as expressed in my previous post, it was moreI along the lines of are they out of their mind, it's so limited.  However, I having read through a little of the manual and knowing now that it's also K going to be available on AlphaServers, I'm impressed, and it adds a feature K that would have been nice to see in OpenVMS/Alpha, namely the ablity to run 
 VAX binaries.   E Word of advice, don't form an opinion on this product without reading H through the manual.  That's where all the info on the product really is.  E Now if only they'd do a Hobbyist license :^)  I'd love to put it on a L laptop, but I doubt I'll be able to afford a copy since it would only be for
 Hobbyist use.    				Zane      ------------------------------  # Date: Thu, 01 Jun 2000 02:20:06 GMT ) From: "Neil Rieck" <n.rieck@sympatico.ca> 6 Subject: Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias9 Message-ID: <qLjZ4.3431$dK2.142968@news20.bellglobal.com>    VAX VMS 7.2 Update   Folks,  H I have a little more info to pass on for whatever it's worth. Caveat: AtH this point it is still possible that I have some corruption on my systemG disk but you should be checking your backups to make sure that your not I seeing what I'm seeing after a BACKUP/IMAGE. Note that checking your logs B and journals is not good enough because mine indicated no problem.  
 First off,  J 1. I've cleaned up the ALIAS situation on the troublesome VAX disk so that: DFU reports the same alias structure as my good Alpha disk9 2. executing "ANA/DISK DSA0:" from DCL produces no errors ) 3. "VER DSA0:" from DFU shows no problems L 4. executing "DUMP/HEADER DSA0:[000000]VMS$COMMON.DIR" from DCL produces the) same back link info on both VAX and ALPHA    Next,   E 1. I do a hot "BACKUP/IMAGE/IGNORE=(INTER,NOBACK)/INIT" from DSA0: to 	 $1$DIA50: I 1a. this is from an RF35 to an RZ26; (we're trying to migrate to a larger  disk) G 1b. it doesn't matter if I use /ALIAS or /NOALIAS with /IMAGE because I L always get the same result. A couple of minutes into the backup, I receive aF warning indicating that ALIAS file "$DSA0:[SYS0]SYSCOMMON.DIR" was notL backed up (this message is from memory and may not be exact; but you get the picture)H 2. After the backup, I mount $1$DIA0: and many directories and files are missing including WRITEBOOT.EXE , 2a. Directory "[000000.VMS$COMMON]" is emptyH 3. next I execute "ANA/DISK/REPAIR $1$DIA50:" from DCL and it produces aF list of many errors. One of them says that "[000000]VMS$COMMON.DIR" is invalid and is now deleted. F 3a. many files have be recovered and were placed in "[000000.SYSLOST]"A 4. Since VMS$COMMON.DIR was deleted, I just rename SYSLOST.DIR to  VMS$COMMON.DIRC 5. Next I create the missing ALIAS from DCL like so (this is a very  dangerous operation):   + $SET FILE $1$DIA50:[000000]VMS$COMMON.DIR - %   /ENTER=$1$DIA50:[sys0]SYSCOMMON.DIR   A 6. Now all the files appear to be present including WRITEBOOT.EXE   L Tomorrow I'll attempt a backup of this reconstructed disk to a different one# to see if VAX BACKUP 7.2 is broken.   
 Neil Rieck* Kitchener(New Berlin?)/Waterloo/Cambridge, Ontario, Canada.! http://www3.sympatico.ca/n.rieck/   2 Neil Rieck <n.rieck@sympatico.ca> wrote in message2 news:4G6Z4.1446$dK2.75167@news20.bellglobal.com... >  <snip> > C > For anyone following this thread, here are the results of running 	 DIR/ALIAS L > from DFU ("Disk File Utility" from the Freeware CD-ROM) on the troublesomeH > VAX and the working Alpha. It would seem that the VAX system disk is aK > little messed up but this doesn't explain why so many files are seemingly I > dropped by BACKUP/IMAGE. (unless there is a bug in BACKUP 7.2 that only 9 > allows a perfect copy when there is no alias confusion)  > J > Whatever the reason for my problems, it would be nice if future versions ofH > BACKUP issued some sort of "ALIAS cross linked directory" warning whenH > copying from any suspect disk. This little feature may could be a life saver  > for someone. >  <snip>) > --------------------------------------- ( > KAWC15 (VAX VMS 7.2 upgraded from 5.4) > E > %DFU-I-INDSCAN, Making directory table for DSA0:[000000...] (DSA0:) - > %DFU-I-DIRSCAN, Scanning 190 directories... J > DSA0:[000000]SYSMAINT.DIR;1 is alias for DSA0:[VMS$COMMON]SYSMAINT.DIR;1) > DSA0:[SYSEXE]SYSBOOT.EXE;1 is alias for ' > DSA0:[VMS$COMMON.SYSEXE]SYSBOOT.EXE;1 G > DSA0:[SYS0]SYSCOMMON.DIR;1 is alias for DSA0:[000000]VMS$COMMON.DIR;1  > ( > %DFU-S-DONE, Directories scanned : 190) > --------------------------------------- * > KAWC05 (Alpha VMS 7.2-1 initial install) > L > %DFU-I-INDSCAN, Making directory table for DKB0:[000000...] (KAWC05$DKB0:)- > %DFU-I-DIRSCAN, Scanning 244 directories... 0 > KAWC05$DKB0:[SYS0]SYSCOMMON.DIR;1 is alias for! > KAWC05$DKB0:[000000]VMS$COMMON.  > DIR;1  > ( > %DFU-S-DONE, Directories scanned : 244) > ---------------------------------------    ------------------------------  % Date: Wed, 31 May 2000 19:27:35 +0100   From: steven.reece@quintiles.comM Subject: Re: VAXCluster Principles book (was Re: Problem with resource	locks) > Message-ID: <802568F0.006579EE.00@qedilc01.qedi.quintiles.com>  A This topic just keeps on coming up, time and time and time again.  What can I say, except...   1 Please, Please, Pretty Please Even Digital Press. D Please can you do something about updating and re-issuing this book.   Steve Spires wrote:  >>>I agree wholeheartedly!  O So, anyone at Compaq or interested and knowledgable parties... Are we likely to M see an update to this tome? The original is good, if a little expensive here, M but an updated alpha-ised version (relevant to OVMS 7.n?) would be better.<<<    ------------------------------  " Date: Thu, 1 Jun 2000 04:02:52 GMT9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) M Subject: Re: VAXCluster Principles book (was Re: Problem with resource	locks) + Message-ID: <Icb6EcCtQbIH@eisner.decus.org>   a In article <802568F0.006579EE.00@qedilc01.qedi.quintiles.com>, steven.reece@quintiles.com writes:  >  > C > This topic just keeps on coming up, time and time and time again.  > What can I say, except...  > 3 > Please, Please, Pretty Please Even Digital Press. F > Please can you do something about updating and re-issuing this book. >  > Steve Spires wrote:  >>>>I agree wholeheartedly!  > Q > So, anyone at Compaq or interested and knowledgable parties... Are we likely to O > see an update to this tome? The original is good, if a little expensive here, O > but an updated alpha-ised version (relevant to OVMS 7.n?) would be better.<<<   @ I actually heard second-hand recently about someone from Digital@ Press being interested in beefing up their VMS repertoire. I may? or may not believe that, but it seems more likely than the idea A that people posting in this topic are interested.  Surely you are C not under the impression that people from Digital Press, a division > of another publishing company, follow comp.os.vms.  If you are> serious about wanting updates, mail a letter to Digital Press.   ------------------------------  + Date: Wed, 31 May 2000 23:39:56 -0500 (CDT)  From: sms@antinode.org9 Subject: VMS V6.2 to V7.2 upgrade disaster (VAXsta 3138). ) Message-ID: <00053123395602@antinode.org>   E    I just tried to do a VMS upgrade on my VAXstation 3100 mod 38 from B V6.2 to V7.2 (Hobbyist CD-ROM), twice, with identical, unfortunate results.  D    The upgrade appears to work fine, but the final reboot fails like this:    [...] N    OpenVMS (TM) VAX Version V7.2     Major version id = 1 Minor version id = 0? %DECnet-I-LOADED, network base image loaded, version = 05.0D.00   C %DECnet-W-NOOPEN, could not open SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT   ; [Attempts to re-boot, with same result.  Rinse.  Repeat...]   B    Booting mini-VMS V7.2 from the CD-ROM ("b/10000000") works, butF mounting the (normal) system disk fails.  No message, it just tries toB reboot after the mount command ("mount /noass /ove = id dka200:").  B    Booting Standalone BACKUP V7.2 from the CD-ROM ("b") works, but the BACKUP command fails:   $ $ bac /ver /ima mka100: /rew dka200:  E **** Fatal BUG CHECK, version = X72TINVEXCEPTN, Exception while above - ASTDEL or on [... (Long line does not wrap.)] E [Register dumps, too long to transcribe from the workstation screen.]     D    It appears to a naive observer that V7.2 hates DKA200:, a Seagate> ST5660N, while V6.2 has long been happy as a bivalve using it.  E    Has anyone else seen anything similar?  Any better theories on the F cause?  Ironically enough, I was doing this to explore the better SCSIB device support I keep hearing about with V7.2.  As Daffy Duck once, asked, "Where did I take the wrong turning?"  H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home) C    382 South Warwick Street        (+1) 763-781-0308  (voice, work) G    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work) 9    sms@antinode.org                sms@provis.com  (work)    ------------------------------  # Date: Thu, 01 Jun 2000 01:41:01 GMT 8 From: DCantor@remove.three.words.shore.net (Dave Cantor) Subject: Re: War Stories ?; Message-ID: <NajZ4.98638$hT2.403291@news1.rdc1.ct.home.com>   M In article <39318317.5538BFC9@netscapeonline.co.uk>, mpatt@bigfoot.com wrote: I >         When I worked for DEC (yes before it was Q'd) there was a Notes G > conference (similar system to Usenet) called War Stories, which was a H > repository for old anecdotes and stupid mistakes that have happened inI > the computing world over the years. Does anyone know if there's anthing % > similar available on the Internet ?   L I can't answer your question directly, but others have already addressed it.  $ However, I thank you for the memory.  L Back around 1983 I think, several of us who worked in the I.S. group at the J old DEC facility in Andover, Mass. ("APO") had a particularly hard day at O work.   We decided to go out to the local watering hole nearby, and we ate and   drank and had way too much fun.   N We left the restaurant but were out in the parking lot for about another hour ; or so.  We were telling each other stories of disasters or  = disasters-just-barely-averted on our systems and in our labs.   H The next morning I established the notesfile (they weren't called Notes J conferences until way later when a real Notes product was first available J internally).  It was originally called WARSTORY.NOT, and was on the systemD then known as NUHAVN::.   I remained the moderator of that notesfileN for several years.  If I remember correctly, the first war story noted in the K file concerned a case of a "backwards DSC".  For those of you too young to  J remember, DSC is what we used before BACKUP.  DSC stood for Disk Save and  Corrupt\tpurr\mpress.    Dave NUHAVN::CANTOR    ------------------------------  % Date: Wed, 31 May 2000 14:59:30 -0300 1 From: "Boyle, Darren" <boyledj@bankofbermuda.com> " Subject: RE: Wildfire AnnouncementK Message-ID: <F150836441C5D311A11700508B6FF01AB2B11C@bdant024.bda.bobda.com>   B Yep, I agree, I never said it was good just that it happened.  ;-) -Darren    > ----------5 > From: 	Terry C. Shannon[SMTP:shannon@world.std.com] ( > Sent: 	Wednesday, May 31, 2000 2:46 PM > To: 	Info-VAX@mvb.saic.com% > Subject: 	Re: Wildfire Announcement  >  > > > "Boyle, Darren" <boyledj@bankofbermuda.com> wrote in messageG > news:F150836441C5D311A11700508B6FF01A983500@bdant024.bda.bobda.com... 8 > > > From: Terry C. Shannon[SMTP:shannon@world.std.com]I > > > night? If not, it's worth resurrecting the film clip so you can see  > how  > a E > > > company who knows how to market can prevail over firms offering 
 > superior > > > technology.  > > > 7 > > That's been happening for years, look at McDonalds.  > C > And look at the corpulence and obesity that has resulted from the ? > FoulArches! Directly proportional to the divorce rate, sez I!  >  >     F **********************************************************************C This message and any files transmitted with it are confidential and J may be privileged and/or subject to the provisions of privacy legislation.M They are intended solely for the use of the individual or entity to whom they L are addressed. If the reader of this message is not the intended recipient, B please notify the sender immediately and then delete this message.I You are notified that reliance on, disclosure of, distribution or copying  of this message is prohibited.   Bank of Bermuda F **********************************************************************   ------------------------------  % Date: Wed, 31 May 2000 16:56:43 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> " Subject: Re: Wildfire Announcement( Message-ID: <8h3u4b$38l$1@pyrite.mv.net>  9 Terry C. Shannon <shannon@world.std.com> wrote in message  news:FvFHq2.rr@world.std.com...    ...   J > How is this possible? Beats me... why not lure some of those Sucker Moms out > > of their SUVS and ask 'em why they voted for Clinton, twice.  J Just a suggestion, but you could save your fingers a lot of effort just by7 putting a generic comment like the above into your sig.    - bill   ------------------------------  # Date: Wed, 31 May 2000 22:39:29 GMT 0 From: "Terry C. Shannon" <shannon@world.std.com>" Subject: Re: Wildfire Announcement& Message-ID: <FvG46y.LD6@world.std.com>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:8h3u4b$38l$1@pyrite.mv.net... > ; > Terry C. Shannon <shannon@world.std.com> wrote in message ! > news:FvFHq2.rr@world.std.com...  >  > ...  > L > > How is this possible? Beats me... why not lure some of those Sucker Moms > out @ > > of their SUVS and ask 'em why they voted for Clinton, twice. > L > Just a suggestion, but you could save your fingers a lot of effort just by9 > putting a generic comment like the above into your sig.  > C Yeah, but until I have the tpcs, there anin't much else I can do...    Hint: GS160 exceeds 75K tpmC...    ------------------------------  % Date: Wed, 31 May 2000 18:40:47 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> " Subject: Re: Wildfire Announcement, Message-ID: <393594E7.7AF09096@videotron.ca>  ( Andrew Harrison SUNUK Consultancy wrote:J > Compaq pays Oracle a considerable amount of money for the OpenVMS, Tru64P > ports of Oracle, you should get something back for your investment and Larry'sN > kind words are part of the deal. Don't read anything else into it than that.  J Yep, And Ellison admitted during the Widlfire launch that Oracle had otherI people's hardware and deals too. Compaq can only claim a "me too" for its ' Unix, but can't claim anything for VMS.   H > Really, so who is Compaq working with to get e-Business apps available
 > on OpenVMS.   L Yep. While the OSU and APACHE web serves on VMS are great, there is the lackN of visible applications. VMS is great for home grown applications, but not for purchased applications.   C > How about SSL crypto accelerators and key vaults got any of those C > How about a certificate management system, this is basic plumbing   = > People on this newsgrou have complained that "anti OpenVMS" A > posts effect their livelyhood and no doubt they will think that  > my post is "anti OpenVMS".  M No, it is not your posts that affect our livelyhood. Your posts only point to M Compaq's weaknesses, and it is sometimes hard to accept that VMS is no longer L a leader,  that it is lagging behind, and everytime Compaq raises our hopes,M it is hard to be brough back down to the harsh reality that VMS , for all its L technological superiority, missed the boat a long time ago and nothing short8 of a spectacular rocket would bring it back in the race.   ------------------------------  # Date: Wed, 31 May 2000 23:06:34 GMT 0 From: "Terry C. Shannon" <shannon@world.std.com>" Subject: Re: Wildfire Announcement& Message-ID: <FvG5G4.3Jx@world.std.com>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:393594E7.7AF09096@videotron.ca...* > Andrew Harrison SUNUK Consultancy wrote:L > > Compaq pays Oracle a considerable amount of money for the OpenVMS, Tru64J > > ports of Oracle, you should get something back for your investment and Larry's J > > kind words are part of the deal. Don't read anything else into it than that.  > L > Yep, And Ellison admitted during the Widlfire launch that Oracle had otherK > people's hardware and deals too. Compaq can only claim a "me too" for its   L Well, would Tier One status for Oracle Apps on OpenVMS make you feel better?
 Stay tuned...    ------------------------------   End of INFO-VAX 2000.304 ************************