1 INFO-VAX	Mon, 25 Apr 2005	Volume 2005 : Issue 229       Contents: BN21H-1E cable7 Re: CDE under DECwindows: customization, documentation? 7 Re: CDE under DECwindows: customization, documentation? 7 Re: CDE under DECwindows: customization, documentation?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  RE: Could a PC do this?  Re: Could a PC do this? . Re: Cyrillic fonts with Mozilla and DECwindows Re: DCL File directory browser Re: DCL File directory browser Re: DCL File directory browser5 HP Athlon 64 laptop for $1000 - oh if only it ran VMS 5 HP Athlon 64 laptop for $1000 - oh if only it ran VMS  Re: Legato NetWorker Re: Login mystery  Re: Login mystery  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  Re: Slow Filesystem I/O  RE: Slow Filesystem I/O ! Re: What is SMTP status code 556?   F ----------------------------------------------------------------------    Date: 24 Apr 2005 16:26:36 -0700( From: Javier Henderson <javier@KJSL.COM> Subject: BN21H-1E cable - Message-ID: <8664yb21ub.fsf@skylane.kjsl.com>    Couple of questions...  D Where can I get a BN21H-1E cable at a good price? This is purely for personal/hobby use.   E Are there longer versions of this cable? If I was to get enterprising * and make my own, can it be, say, 10' long?   Thanks.    -jav   ------------------------------    Date: 24 Apr 2005 15:22:54 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) @ Subject: Re: CDE under DECwindows: customization, documentation?3 Message-ID: <xqhYCFNFUz05@eisner.encompasserve.org>   [ In article <1114207221.48435.0@demeter.uk.clara.net>, issinoho <issinoho@gmail.com> writes:   G > And why, please someone explain, is it still referred to as the "New  F > Desktop Environment" a full 10 years after it first appeared and is 0 > probably the only OS that still ships with it.  D Because it does not include all the pieces and cannot be called CDE.   ------------------------------  % Date: Sun, 24 Apr 2005 16:46:07 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>@ Subject: Re: CDE under DECwindows: customization, documentation?* Message-ID: <426C139F.C6271EA@comcast.net>   FredK wrote: > [snip]J > CDE is still a requirement in most markets.  KDE and Gnome are out thereM > in source form - go ahead and port it.  If and when either of these becomes K > a requirement for a large portion of the customer base - or some critical . > application - then perhaps VMS will port it.  & Then when are you guys gonna get busy?  C Like "issinoho", I have rather a *LARGE* issue with statements like  that.   . Let's try that concept in a different context:  A Where was the demand for the following products before they first  appeared on the market?    o Satellite radio/TV
 o CompactDisc  o E-mail o Camera-Phones  o Personal Computers o Frozen "TV" dinners 
 o etc. ...  E Most of the highly successful products we see today are the result of B "generated" demand: someone dreamed up a product and convinced theC buying public (including corporate America) that they couldn't live  without it.   H Saying that "we'll wait for the demand before we produce" is the classicF example of the cart-before-the-horse. Some may say that the investmentD is "risky" until a proven demand exists. I ask, "What is the risk ofF lost revenue if we miss the boat because we waited too long to developG our product so we could exploit the opportunity?" Sure, you didn't lose ' money, but you didn't make any, either.   F Conversely, here are products where the demand is huge, but the supply is nil:   + o Secure Personal/Commercial Computing o/s* @ o Vehicles sans petrol that don't require batteries/charging for propulsion. 8 o Affordable in-home elevators for the marginally mobile
 o etc. ...  @ *: Actually, VMS would fit well here, but we all know how phobicH OVMS/Engr is about IA32. Those folks seem to master every challenge theyE face. Too bad they won't face that one head-on... (See above comments   about lost revenue opportunity.)   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Sun, 24 Apr 2005 19:47:21 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> @ Subject: Re: CDE under DECwindows: customization, documentation?B Message-ID: <1114386453.e0cda8a2c9fa9e6037cdbdea080cfa47@teranews>   David J Dachtera wrote: E > Like "issinoho", I have rather a *LARGE* issue with statements like  > that.   C In fairness, I think that FredK meant to say that he can't do those E needed projects during his spare time and that he does wish to have a  life outside of VMS.  F FredK seems to have taken this personally, but the criticism was meantF at VMS management who have not provided development prioroties to many areas where VMS badly needs it.   G VMS management will argue that they have limited resources and can't do G everything. For a product that generates so much profit, I am surprised ? that the new owner doesn't see fit to give much needed boost in K development to catch up with all the years of neglect in many areas of VMS.   B > *: Actually, VMS would fit well here, but we all know how phobic > OVMS/Engr is about IA32.  H I am not sure that engineering is all that phobic about VMS on the 8086.E  Now that a 64 bit 8086 exists, I fully expect Hoff and Frek to spend G all their spare time toying with the port to the 8086 :-) If that means ) that they won't upgrade Flight, so be it.   E Once VMS is on the 8086, it will be there for quite some time and can # finally start to be improved again.     A rolling stone gathers no moss.   ------------------------------    Date: 24 Apr 2005 09:20:50 -0700* From: "Alan Greig" <greigaln@netscape.net>  Subject: Re: Could a PC do this?C Message-ID: <1114359650.299724.301540@z14g2000cwz.googlegroups.com>    Alan Greig wrote:   G > And check the SAP benchmark site for comparisons with Itanic and Xeon D > http://www50.sap.com/benchmark/sd2tier.asp which show the new dual coreB > Opteron s outperforming Xeons by around 2:1 and roughly matching# > Itanium 2 at the same core count.   D Oops misread a line. The latest SAP HP benchmarks show the dual coreB Opteron outperforming Itanic by around 50% at the same core count. --  
 Alan Greig   ------------------------------  % Date: Sun, 24 Apr 2005 13:54:38 -0400 ' From: Dave Froble <davef@tsoft-inc.com>   Subject: Re: Could a PC do this?0 Message-ID: <116nnao57e42sbd@corp.supernews.com>   Main, Kerry wrote: >>-----Original Message-----1 >>From: Dave Froble [mailto:davef@tsoft-inc.com]   >>Sent: April 23, 2005 11:01 PM  >>To: Info-VAX@Mvb.Saic.Com " >>Subject: Re: Could a PC do this? >> >>Main, Kerry wrote: >> >>= >>>JF - If you want to know what Intel is really positioning   >>
 >>for x86 and  >>C >>>IA64 (as opposed to making up your own views), check out Intel's ( >>>whitepaper comparing x86 and Itanium: >>>  >>>  >>@ >>http://www.intel.com/business/bss/products/server/64-bit_tippi >  > ng_point.p >  >>>df  >>>  >>>Extract:  >>> G >>>"Intel offers two complementary architectural choices that cover the ; >>>full range of 64-bit requirements. One is Intel Itanium   >> >>architecture,  >>A >>>which is designed for the most demanding and business-critical ; >>>enterprise and technical applications. The other is the   >> >>family of Intel  >>= >>>Xeon processor based systems with Intel EM64T. Though not   >> >>equivalent to  >>? >>>Itanium architecture in terms of capacity, performance, and   >> >>RAS, these >>G >>>platforms enable a more gradual migration to 64-bit solutions, since ; >>>they provide native support for existing, legacy 32-bit   >> >>applications. In >>? >>>most enterprise computing environments, both platforms will   >>
 >>be needed."  >>D >>Sorry Kerry.  What you quote above could be, note, I say 'could', F >>similar to the EV8 roadmaps and PROMISES and COMMITMENTS concerning  >>Alpha on June 20, 1999.  >>? >>Actually, Intel is not making commitments and promises, just   >>'offers'. H >>Care to quote for us anything from Intel that PROMISES to keep making  >>anything?  >> >  >  > [Snip ...] > G > Dave - Care to quote us anything from any vendor on any platform that 9 > "promises" anything will happen in specific timeframes?   E Neat!  You slide "happen in specific timeframes" into the topic, and  > completely change the topic.  I'm not biting on that.  Forget $ timeframes.  I'm talking about ever.   > That's not reality.  > F > ALL vendors provide directions (roadmaps?) to Customers and AnalystsD > based on their best estimates of what they can deliver in specific > timeframes.  > . > Now, when certain things happen (engineeringF > /legal/marketing/political/stock dives/new mgmt/ new moon/whatever),I > these vendors sometimes need to adjust these roadmaps.  That is true of I > IBM, Sun, Microsoft, Intel, AMD, Oracle, SAP, etc etc and yes, even HP.  > F > Here are a few examples from other vendors where "stuff" happens andH > things do not always work out the way the vendor announced it to theirI > Customers: (and yes, you could argue which vendor was at fault, but the 7 > point is, "stuff happened" and the "roadmap" changed)  > G > "SUN TO DELIVER ENTERPRISE-CLASS SOLARIS FOR INTEL'S MERCED PROCESSOR F > Intel to support Sun in moving Solaris to IA-64" - December 16, 1997C > http://www.sun.com/smi/Press/sunflash/9712/sunflash.971216.3.html  > H > "The Road to Cairo" - April 8, 2002 (Cairo supposed to be available in> > 1996, then NT5, then Windows 2000 finally delivered in 2000)J > http://www.computerworld.com/softwaretopics/os/story/0,10801,69882,00.ht > ml  H Killing Alpha was much more than slipping some timing projections.  And F now where is HP?  Dependant upon Intel.  Intel can stab HP in the eye G with a stick any time.  At least when you control your own CPU, nobody  # else can affect you in this manner.    > You want "promises"??   ; After the ones that were broken?  Why?  What good are they?   F > Heck, similar to OpenVMS, I would be happy just to see public futureH > roadmaps for AIX, Solaris, Linux etc etc. Roadmaps are not meant to beI > etched in stone (hence the disclaimers usually found in them), but does J > provide some general direction on features and timeframes - based on theI > best information that vendor has available at the time the roadmaps are  > published.  G Go ahead and knock IBM.  Oh, you really can't, can you?  Their past is  B what speaks for them.  Oh, and don't go looking for some isolated G incident and try to use that to sully their record.  Alpha wasn't some  6 model that didn't sell or such.  Alpha was everything.  E So you work for HP and have to put on a brave face, but please don't  E insult the intellegence (and memory) of those on this newsgroup.  We  6 aren't wintel types with the attention span of a gnat.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 24 Apr 2005 20:59:42 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)  Subject: Re: Could a PC do this?, Message-ID: <3d2flrF6q53mfU1@individual.net>  R In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECC81@tayexc19.americas.cpqcorp.net>,* 	"Main, Kerry" <kerry.main@hp.com> writes: >  >  -----Original Message----- : >> From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 >> Sent: April 23, 2005 5:40 PM  >> To: Info-VAX@Mvb.Saic.Com# >> Subject: Re: Could a PC do this?  >>=20  >  > [snip ..]  >  > B >> Even Intel has progressively admitted that IA64 wasn't going=20 >> to make it.< >> First, it wasn't going to replace the 8086 as industry=20 >> standard. Second,I >> it wasn't going to make it for desktops/workstations, and then that it 3 >> was reallty good only for big iron computations.  >>=20  >  > [snip ..]  > G > JF - If you want to know what Intel is really positioning for x86 and B > IA64 (as opposed to making up your own views), check out Intel's' > whitepaper comparing x86 and Itanium:   B A yes, a whitepaper.  I remember a whitepaper that showed how muchB better Alpha was over Itanium.  And we all know how much good that@ did for Alpha.  Let's all go read the whitepaper.  Hmmmm....  Is2 this another of those new, catchy IBM commercials?   bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 24 Apr 2005 15:18:46 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)   Subject: Re: Could a PC do this?3 Message-ID: <DhmO96fjucNC@eisner.encompasserve.org>   N In article <opsppggslkzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:  J > The fact that there are still a lot of VAXen out there might lead you to= > the conclusion that the Alpha really wasn't that successful   B Why on earth should someone replace something that does their work adequately ?   ------------------------------  % Date: Sun, 24 Apr 2005 16:53:40 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: Could a PC do this?, Message-ID: <426C074D.C6FFF72D@teksavvy.com>   "Main, Kerry" wrote:F > ALL vendors provide directions (roadmaps?) to Customers and AnalystsD > based on their best estimates of what they can deliver in specific
 > timeframes.     7 There are credible roadmaps and less credible roadmaps.   F IBM's Power roadmaps are very credible because IBM is betting a lot onD Power and Power has leadership role and good adoption rate and Apple& (and a few others) also rely on Power.  B IBM's AS400 (Iseries I think) is perhaps less credible as is AIXs.  9 One learns to "read" those roadmaps with a grain of salt.     G Simimarly, if you look only at one product's roadmap, it may look neat, C but you also have to look at it on a corporate level. AIX's product D roadmap loses some credibility when you look at IBM's commitments toD Linux. (same for HP-UX and Linux). Solaris's roadmap is more cedible7 because Sun isn't betting its business on any other OS.   F In the case of Intel, you need to look at Intel's product roadmaps, asG well as Intels financial statements and pressure to perform and compete G against AMD. You need to look at statements made by Intel over the last G few years, the fact that it will now have a new CEO who has stated many L times that focus will be on profitable products and drop unprofitable lines.  E When you take a more global picture, the IA64 roadmap is not credible D beyond 2007. And so far, nothing has been said/done to alleviate the@ rumour that IA64 will be replacved by the 8086 in the enterpriseD products. Intel has sent plenty of fairly clear messages that IA64's> niche market growing narrower and narrower.  It may have greatO technological plans, but the business case makes those plans not very relevant.   F It is logical for Intel to focus on one architecture. It isn't logicalG and it isn't good business for Intel to have 2 competing architectures, E especially when the low volume one costs a lot more to develop due to L its bloatedness and very specific compilers required to achieve performance.   ------------------------------  % Date: Sun, 24 Apr 2005 22:50:11 -0400 ' From: "Main, Kerry" <kerry.main@hp.com>   Subject: RE: Could a PC do this?R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECC92@tayexc19.americas.cpqcorp.net>   > -----Original Message-----3 > From: Dave Froble [mailto:davef@tsoft-inc.com]=20  > Sent: April 24, 2005 1:55 PM > To: Info-VAX@Mvb.Saic.Com " > Subject: Re: Could a PC do this? >=20  	 [snip ..]    >=20= > Go ahead and knock IBM.  Oh, you really can't, can you? =20  > Their past is=20F > what speaks for them.  Oh, and don't go looking for some isolated=20? > incident and try to use that to sully their record.  Alpha=20  > wasn't some=208 > model that didn't sell or such.  Alpha was everything. >=20  C IBM is a good company but, I could bring out stuff they did (ending B OS/2, disk storage etc), which ticked off some of their Customers.  G However, whats the point? You can do that for any vendor. Same could be G said for Sun, Microsoft, Oracle etc etc. Every vendor has its skeletons ' in the closet if you look close enough.   I > So you work for HP and have to put on a brave face, but please don't=20 I > insult the intellegence (and memory) of those on this newsgroup.  We=20 8 > aren't wintel types with the attention span of a gnat. >=20  H Wow, where did that come from?  My reply was not intended to drag up old- Alpha "woulda, coulda, shoulda" arguments.=20   D I was simply commenting on the statement you made about asking whereC Intel promised to keep making anything and I made the point that no ? vendor "promises" to release anything. They state "we expect to G release.." or "First Customer ship date is expected ..". No vendor ever  says "we promise ..".=20  E The lawyers would take a baseball bat to anyone who tried to put that 6 type of statement in a public roadmap or announcement.   ------------------------------  % Date: Sun, 24 Apr 2005 23:10:15 -0400 ( From: Bill Todd <billtodd@metrocast.net>  Subject: Re: Could a PC do this?= Message-ID: <5KOdnTb9kboFwvHfRVn-iw@metrocastcablevision.com>    Main, Kerry wrote:   ...      They state "we expect toI > release.." or "First Customer ship date is expected ..". No vendor ever  > says "we promise ..".   H I see that you've conveniently forgotten the Heil/Lipcon 'commitment to H Alpha' letter, so allow me to refresh your memory (note, in particular, H the use of the phrase "we WILL" with respect to EV8, in addition to the H multiple very specific 'commitments' and flat statements such as "Alpha F WILL become the engine for future generations of our Compaq NonStopTM  Himalaya systems").    - bill     To Our Valued Customers:  A Over the past few months, we have taken a close look at Compaqs  G platform strategy and the needs of our customers. We concluded that we  ? needed to simplify our strategy, more clearly define our value  E proposition for you, and reinforce our message to you that Compaq is  3 unequivocally committed to Alpha for the long term.   ; The Compaq NonStopTM server platform strategy is clear and  G straightforward. We are focused on two key segments: Industry Standard  F Servers (Compaq ProLiant) and Business Critical Servers for customers H requiring the highest levels of availability, scalability, reliability,  data integrity and security.  G As our underlying processor technology, Alpha is absolutely key to our  H profitable growth and market leadership in the Business Critical Server G segment. As a result, we are investing aggressively in multiple future  H generations of Alpha chip technology and a robust Alpha system roadmap. E Our plan is to drive Alpha at the high end of the enterprise market,  I where our strengths in 64-bit platforms, Compaq NonStopTM technology and  C clustering help you build a competitive advantage. We have already  I announced an aggressive plan to grow Tru64 UNIX on Alpha systems in such  A key markets as high performance technical computing, e-commerce,  F telecommunications and enterprise applications, among others. We will H drive Alpha volumes by leveraging the growth of Linux. We will continue H to maintain the highest levels of customer satisfaction for our OpenVMS G customers. This includes a five-year rolling roadmap and investment in  I OpenVMS in the areas of business critical capabilities and software that  H enable Compaq NonStopTM solutions. And as we also announced, Alpha will A become the engine for future generations of our Compaq NonStopTM   Himalaya systems.   D Our commitment to Alpha is a sound one that provides Compaq and our E customers with unique competitive advantages. As you know, Alpha has  I maintained its unquestioned performance leadership against all other CPU  F architectures since January 1993. We plan to maintain and extend this E lead with a fully funded R+D program to ensure continued delivery of  " leadership products to the market.  G Specifically, we are now shipping our third-generation EV6 CPU chip in  G our full line of Compaq AlphaServer systems, available today with 1 to  I 14 processors, and have begun shipping faster versions of these products  E based on the EV67 CPU chip. In addition, we have just introduced the  E AlphaServer SC series of supercomputers to extend our #1 position in  I mid-range high performance technical computing into the traditional >$1M  B supercomputer space. By early 2000, we will begin rolling out our I next-generation high-end AlphaServer with up to 32 processors. Our Alpha  B manufacturing partner, Samsung, recently publicly demonstrated an F advanced development version of the EV68 CPU chip, the first to break E the 1GHz barrier. And we have an exciting Alpha roadmap ahead of us,  F including EV7, EV8, EV9 and EV10, with a plan to offer a full line of H systems based on these generations. In EV8, we will implement a new CPU I methodology, Simultaneous Multi-Threading, which was recently introduced  4 at the MicroProcessor Forum in San Jose, California.  I With these commitments, Compaq offers the most powerful set of platforms  H and the widest range of choices to deliver the greatest value for you  H from Windows NT on our ProLiant servers and Professional Workstations . J . . to Tru64 UNIX, Linux and OpenVMS on Alpha . . . to NonStopTM Himalaya.  H We appreciate your business, we value our relationship with you, and we ? look forward to building an even stronger partnership together.   
 Sincerely,  	 Bill Heil   	 Bill Heil " Vice President and General Manager! Business Critical Server Division    Jesse Lipcon   Jesse Lipcon Vice President Alpha Technology   ------------------------------  % Date: Sun, 24 Apr 2005 16:37:15 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Cyrillic fonts with Mozilla and DECwindows , Message-ID: <426C0375.8306ED7F@teksavvy.com>  / Phillip Helbig---remove CLOTHES to reply wrote: F > Yes, I realise that it isn't specified specifically in the HTML pageA > itself, but there has to be some algorithm which determines it.   P Actually, it CAN be specified explicitely in the HTML page through style sheets.  E In the case of Mosaic, the H1 font is specified in the resource file. , (By default, times, bold, 24 point iso8859-1    C When you try to load a cyrilic font, it probablty just replaces the G iso-8859-1 at the end fo the X font specification and asks to load that 9 cyrillic equivalent. And that would be browser dependant.    ------------------------------  % Date: Sun, 24 Apr 2005 22:35:46 +0200 3 From: "Ton van der Zwet" <ton.vanderzwet@hccnet.nl> ' Subject: Re: DCL File directory browser = Message-ID: <426c026d$0$784$3a628fcd@reader20.nntp.hccnet.nl>   < "JF Mezei" <jfmezei.spamnot@teksavvy.com> schreef in bericht& news:426B652D.EEC8095E@teksavvy.com... > stinehelferw wrote:  > >  > > Using a DCL menu. G > > After selecting function/operation need to find the file to operate  on. ? > > Something like the File/Open dialog on a text editor.  Just  something to  > > find the file and select it. > E > To find a list of files, you can do a DCL look with F$SEARCH("*.*") ) > until F$SEARCH returns an empty string.  > G > DCL doesn't have arrays per say, but you can still concuct something:  > 
 > $numfiles=0 	 > $loop1: $ > $ FILE_'numfiles = F$SEARCH("*.*")1 > $ if FILE_'numfiles .eqs. "" then GOTO endloop1  > $ temp = file_'numfiles / > $ write sys$output "''numfiles'      ''temp'"  > $ numfiles = numfiles + 1 
 > $goto loop1  > $! > $  > $endloop1:1 > $inquire select "Enter number of file you want"  > $the_file = file_'select > $edit 'the_file  > G > What the above does is assign the variable FILE_0 with the first file 3 > name, FILE_1 with the second file name and so on.  > E > If you have decwindows, fileview is really what you want to use. It E > gives you file list and you can define multiple actions that can be  doneF > on each file (right click pops a menu of actions on that file, based on > the file type).   . Just a little add-on to make the example work:  ' $define/user_mode sys$input sys$command    just before the edit command.    $numfiles=0  $loop1: " $ FILE_'numfiles = F$SEARCH("*.*")/ $ if FILE_'numfiles .eqs. "" then GOTO endloop1  $ temp = file_'numfiles - $ write sys$output "''numfiles'      ''temp'"  $ numfiles = numfiles + 1  $goto loop1  $!
 $endloop1:/ $inquire select "Enter number of file you want"  $the_file = file_'select' $define/user_mode sys$input sys$command  $edit 'the_file    ------------------------------  % Date: Sun, 24 Apr 2005 16:55:20 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: Re: DCL File directory browser + Message-ID: <426C15C7.F472AFDE@comcast.net>    stinehelferw wrote:  > ? > Has anyone found a way to use DCL to browse a file directory?  > N > I'm thinking C is a much better idea, but thought I'd check as I have a menu8 > of DCL utilities that this would be incorporated into.  F Well, it would be a considerable task, and DCL is a bit limited in itsG ability to trap individual keystrokes and do something useful, but yeah  - I'm sure it could be done.  D Although, I'd likely take the approach of writing code that could beF incoporated into other proc.'s by invocation, rather than re-inventing that wheel so many times.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------    Date: 24 Apr 2005 17:25:38 -0700$ From: "AEF" <spamsink2001@yahoo.com>' Subject: Re: DCL File directory browser B Message-ID: <1114388738.480520.15050@z14g2000cwz.googlegroups.com>   stinehelferw wrote: ? > Has anyone found a way to use DCL to browse a file directory?  > G > I'm thinking C is a much better idea, but thought I'd check as I have  a menu8 > of DCL utilities that this would be incorporated into.   Have you checked the freeware?   See   /     http://h71000.www7.hp.com/openvms/freeware/   9 Someone may have already written something you could use.    ------------------------------    Date: 24 Apr 2005 12:27:41 -0700* From: "Alan Greig" <greigaln@netscape.net>> Subject: HP Athlon 64 laptop for $1000 - oh if only it ran VMSB Message-ID: <1114370861.683499.54640@g14g2000cwa.googlegroups.com>  C Thanks to the Inquirer I've just noticed HP is selling the HP R4000 F laptop with Athlon 64 3200+ for approx $1000. This should also be ableC to handle the two core mobile Athlon 64 when launched with a simple 
 BIOS upgrade.   E Another HP offering that would make a damn fine VMS system if not for / the slight inconvenience of the lack of a port.   ) http://www.theinquirer.net/?article=22749  http://www.shopping.hp.com/webapp/shopping/computer_series.do?storeName=computer_store&category=notebooks/compaq_presario&series_name=R4000_series&catLevel=2&tab_switch=true&tab=specs    --  
 Alan Greig   ------------------------------    Date: 24 Apr 2005 13:51:20 -0700* From: "Alan Greig" <greigaln@netscape.net>> Subject: HP Athlon 64 laptop for $1000 - oh if only it ran VMSC Message-ID: <1114375880.753806.279770@z14g2000cwz.googlegroups.com>   C Thanks to the Inquirer I've just noticed HP is selling the HP R4000 F laptop with Athlon 64 3200+ for approx $1000. This should also be ableC to handle the two core mobile Athlon 64 when launched with a simple 
 BIOS upgrade.   E Another HP offering that would make a damn fine VMS system if not for / the slight inconvenience of the lack of a port.   ) http://www.theinquirer.net/?article=22749 H http://www.shopping.hp.com/webapp/shopping/computer_series.do?storeNa...   --  
 Alan Greig   ------------------------------  % Date: Sun, 24 Apr 2005 21:02:15 -0700 ( From: Jeff Cameron <roktsci@comcast.net> Subject: Re: Legato NetWorker / Message-ID: <BE91B9D7.CA64%roktsci@comcast.net>   E On 4/24/05 2:22 PM, in article 426C0E17.6EAF95F@comcast.net, "David J , Dachtera" <djesys.nospam@comcast.net> wrote:   > Jeff Cameron wrote: 	 >> [snip] & >> But DR is, and will remain, a pain. > $ > What is backup for, if not for DR? > A > In context, I'd consider the loss of even a single file to be a ( > "disaster", albeit on a limited scale.G I too consider the loss of a single file to be DR in a form, but in the ) industry there are two types of Restores:   I DR - Which implies full file system or mount-point restore, most commonly K due to failure of equipment. Also any loss of the backup system database is  considered DR.  J UR - User restore (which we sometimes call SE or Stupidity Restore) when aC user (most often management) deletes something they shouldn't have.    ------------------------------  % Date: Sun, 24 Apr 2005 16:17:42 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: Login mystery+ Message-ID: <426C0CF6.F14D75F5@comcast.net>    Ken Fairfield wrote: >  > Bob Koehler wrote:^ > > In article <d4bd97$crb$1@news01.intel.com>, Ken Fairfield <my.full.name@intel.com> writes: > > L > >>     I still use "MCR SYSMAN", even though I use SYSMAN daily and should' > >>  have defined a symbol for it. :-}  > >  > > < > >    You haven't yet realized MC is a unique abbreviation? > A >      Where's the smiley, Bob?  Of course.  What I actually type = > is "mc sysman", lowercase and all.  But I'm in the habit of : > spelling out verbs and/or image names fully when writingA > command procedures or in corresponance (with users, etc.).  ;-p   ! Can I get fries with my McSYSMAN?    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Sun, 24 Apr 2005 19:38:58 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: Login mysteryB Message-ID: <1114385945.31240c19ef91726999621ee8f09a2182@teranews>   David J Dachtera wrote: C > >      Where's the smiley, Bob?  Of course.  What I actually type ( > > is "mc sysman", lowercase and all.    # > Can I get fries with my McSYSMAN?   B Sorry, you can't. The owner of the McSYSMAN utility has been underD trememdous pressure to cut the fat from its product portfolio.  TheyH don't want to be seen as "with fries ?" anymore, it should be "would you( like a McSalad with this ?" from now on.  F There's even been a documentary about this: "Superzize that cluster"   :-) :-) :-) :-)   ? Time for the VMS engineers to change the DECW$BURGER utility to  DECW$SALAD.EXE  :-)    ------------------------------  + Date: Sun, 24 Apr 2005 17:30:32 +0000 (UTC) % From: Dan Foster <usenet@evilphb.org>   Subject: Re: Slow Filesystem I/O6 Message-ID: <slrnd6nm3h.78k.usenet@gaia.roc2.gblx.net>  d In article <_6Sdna3DBYn8OvbfRVn-3Q@comcast.com>, Bob Willard <BobwBSGS@TrashThis.comcast.net> wrote: > Dave Froble wrote: >> ksidibaba wrote:  >>  I >>> Working for the first time on an openVMS system, I found the file I/O F >>> performance to be extremly slow compared to a wintel notebook. TheG >>> openVMS platform I am using is a DS15, running openVMS 7.3, patched H >>> with the recommended patches from HP in order to run Java 1.4.2. TheJ >>> file I/O operations involved consist in writing a log file from a JavaI >>> program (i.e. an ODS 5 file). Writing approximately 80MB of data to a J >>> file takes about 60-80s, on a notebook about 8s (4s on a standard PC). >>   >>  F >> Nigel and Bill explained some of the issues.  I'd just ask, do you E >> really believe that any system does a substained write to disk of E >> 20MB/sec?  I don't. >> o > F > I'm afraid your expectations of sequential R/W performance are a bitH > behind the times.  The 74GB Raptor on this PC sustains ~70 MB/s on its; > outer bands, and I've measured that under XP with HDtach.l  G My initial reaction was same as yours. But then Mr. Froble subsequentlyoB explained what his concern with that kind of statistic was -- true: numbers can be significantly masked by caching strategies.  G For instance, Windows XP utilizes some form of write-through caching bylE default (if the disk controller supports it; many do) for performance  reasons.  B In essence, writes returns as soon as data has been written to theH in-memory (system or controller) cache, rather than actually written out and completed to disk.  H So you'd have to determine the true drive write speeds under XP, withoutF utilizing any form of caching (system memory, controller memory, drive onboard memory).  C That'd provide a more accurate view of the true capabilities of the-0 drive's write performance without cache assists.  A I can appreciate what he meant or was implying. I've seen numbers D grossly inflated by caching when testing disk arrays (on non-OpenVMS" platforms) with tools like iozone.  A iozone is specifically designed to explore true capabilities, andh/ includes attempts to defeat caching properties.t  = It has a pretty neat chart that shows you at what numbers thenH performance dramatically drops off -- this tend to be when the cache hasH been 'busted', and the numbers past that point tend to reveal the actualA non-cache-accelerated true drive platter capabilities for writes.C  D Prior to that point being reached on a particular test, I was seeingD numbers reported such as 400 MB/sec writes on theoretical 160 MB/sec> drives -- clearly due to use of controller write-back caching.  F That dropped off to somewhere around ... don't remember, neighbourhood, of 20-30 MB/sec (?) once cache was 'busted'.  E iozone also can explore effect of different type of application write.E patterns by simulating both sequential and random read/writes, and at0 various block sizes.  G It's been interesting reading the charts generated to gain insight intoo5 different configurations and true drive capabilities.@  B I'm not sure if an exact analog to iozone exists under OpenVMS for> exploring that kind of thing. Presumably people within OpenVMSE Engineering whom works on filesystems and performance engineering do.r  E I do concur that for OpenVMS, with appropriate knobs tweaked, one canlH get impressive disk performance -- be it through use of the XFC, throughH explicit write-back, through optimizing application write patterns, etc.   -Dan   ------------------------------  % Date: Sun, 24 Apr 2005 14:09:22 -0400e' From: Dave Froble <davef@tsoft-inc.com>e  Subject: Re: Slow Filesystem I/O0 Message-ID: <116no6agbss8u0b@corp.supernews.com>   Bob Willard wrote: > Dave Froble wrote: >  >> ksidibaba wrote:t >>I >>> Working for the first time on an openVMS system, I found the file I/O F >>> performance to be extremly slow compared to a wintel notebook. TheG >>> openVMS platform I am using is a DS15, running openVMS 7.3, patcheduH >>> with the recommended patches from HP in order to run Java 1.4.2. TheJ >>> file I/O operations involved consist in writing a log file from a JavaI >>> program (i.e. an ODS 5 file). Writing approximately 80MB of data to a J >>> file takes about 60-80s, on a notebook about 8s (4s on a standard PC). >> >> >>F >> Nigel and Bill explained some of the issues.  I'd just ask, do you E >> really believe that any system does a substained write to disk of e >> 20MB/sec?  I don't. >> > F > I'm afraid your expectations of sequential R/W performance are a bitH > behind the times.  The 74GB Raptor on this PC sustains ~70 MB/s on its; > outer bands, and I've measured that under XP with HDtach.   G Well, since my 'newest' system is an AlphaStation 200 4/233, yes, I am   behind the times a bit.  :-)   -- s4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Roady Vanderbilt, PA  15486e   ------------------------------  % Date: Sun, 24 Apr 2005 15:15:55 -0400i( From: Bill Todd <billtodd@metrocast.net>  Subject: Re: Slow Filesystem I/O= Message-ID: <aomdnbszCLDxbfbfRVn-ig@metrocastcablevision.com>    Nigel Barker wrote:iO > On Sat, 23 Apr 2005 14:09:30 -0400, Bill Todd <billtodd@metrocast.net> wrote:  >  > M >>When OpenVMS says it has completed an I/O it really has written it to disk.C >>D >>The same, of course, is true for Windows:  it's only higher-level K >>operations such as at the file level where the differences which I noted i! >>above start to become relevant.G >  > 3 > I think that you are playing with semantics here.i   You think incorrectly.     Compare & contrast a copydP > operation to a USB memory stick. If I yank it out as soon as I get the commandO > prompt back there is a good chance that under Windows my files are corrupt ort* > incomplete. This is not true of OpenVMS.  D Of course it's true, at least by default for sequential files:  VMS G (actually, RMS) only writes out its internal buffer (regrettably small gF though it is by default) when it has become full, or when the file is 5 closed, or when you explicitly ask it to (via FLUSH).   E By contrast, Windows by default flushes dirty data out of its system VH cache relatively aggressively, such that unless the system is shoveling H dirty data into the cache as fast as it can get rid of it a few seconds H at most after the last cached write has been submitted there's no dirty B data that hasn't made it to disk (Unix systems are sometimes more H leisurely, letting the dirty data sit in the cache for 30 seconds or so + by default, though this period is tunable).h  F And in both cases, while the file may be incomplete, it should not be D corrupt:  VMS uses 'careful replacement' algorithms to ensure this, C while Windows (NT/2K/XP) uses a transaction log (at least with its p default file system, NTFS).P  I (All that said, the COPY command may be a special case, if, for example, mB it uses RMS block I/O, which effectively translates to using QIOs H directly:  as I noted earlier, at the QIO level both systems return I/O H completion only after the disk or controller has said that the data has H been transferred - so if the Windows COPY-command behavior differs from E VMS's it is because of differences in the implementations of the two oL COPY commands rather than because of any generic file-handling differences.)  E Now, if you have specifically identified the USB stick as being some 0G kind of special (e.g., removable device), any of these systems may (or t> may not) treat it differently from their default behavior for F conventional disks (for example, Windows gives you the opportunity to D signal your intent to remove it so that it can flush out any cached D dirty data before you do, and it's possible that VMS transmits this I information to RMS such that RMS changes its normal behavior, I suppose).i   - bill   ------------------------------  % Date: Sun, 24 Apr 2005 16:00:18 -0400 ( From: Bill Todd <billtodd@metrocast.net>  Subject: Re: Slow Filesystem I/O= Message-ID: <55-dnQ89V8hOZ_bfRVn-gw@metrocastcablevision.com>    Dan Foster wrote:>   ...>  F  > That's a shame (Spiralog). Wonder why then-DEC dropped it if it wasF  > pretty good? There's some rumours of boundary conditions presentingI  > significant engineering work making it unpalatable to develop further?e  H Spiralog was extremely interesting, but was not an unqualified success. E   For example, while it helped some workloads enormously it provided yE little boost for others and actually caused some to slow down (e.g., iD when its on-disk layout caused files to become severely fragmented).  E One of the fundamental assumptions behind log-structured storage was sC that memory was becoming cheap enough that soon most data would be  F cached and update performance (rather than read performance) would be D the main bottleneck.  The explosion in data sizes which accompanied F increased memory sizes invalidated this assumption, and the drawbacks I associated with log-structured storage prevented it from taking over the   world.    >L > Note to self: a quick primer on filesystem writes -- three major policies: > B > 	a) Write-through caching -- app writes to fs; fs doesn't returnB > 	   until all data blocks has been successfully written to disk.  D Or at least is guaranteed to be persistent at the relevant level of G redundancy (e.g., if the disks are mirrored, then if I/O completion is mH returned when the data has reached battery-backed cache then that cache  should be mirrored also).r  I Furthermore, any related metadata updates must also be persistent before rI the I/O completes (it doesn't do you too much good to have your appended s? data on the disk if EOF hasn't also been updated, for example).    > D > 	   Safest but quite slow for obvious reasons. Default on OpenVMS.  E Actually, it can be pretty fast.  For example, if you've got a small  E update which can be wholly captured in a system transaction log, and ,D that system log can leverage the existence of (perhaps mirrored, as I described above) persistent cache and destaged to disk if necessary only  E later, in bulk, then many write-through updates can complete with no (I disk access latency at all (and even in the absence of such non-volatile sF cache require only a single small log write, potentially batched with G log records for other such updates performed concurrently, rather than iL multiple disk accesses to update both the data and the associated metadata).   > C > 	b) Write-back caching -- app writes to fs; fs returns as soon as,B > 	   data is in cache, even if cache has not yet flushed to disk. > C > 	   Very unsafe -- very good performance but if interrupted (e.g.w? > 	   power failure) at wrong time, filesystem data corruption.   E Not necessarily.  For example, the 'soft updates' algorithms in *BSD  I systems prevent data corruption in the presence of write-back caching by .F ensuring that when the updates actually get to disk they do so in the H appropriate order - very similar to the ordering which ODS-1/2 enforces G on its own synchronous disk updates and to the deferred ordering which  & Spiralog enforced on its disk updates.  E Furthermore, a similar ordering can be enforced in the presence of a tC transaction log, such that all writes (save those specified by the  , application as synchronous) can be deferred.   > @ > 	c) Write-behind caching -- app writes to fs; fs reorders data@ > 	   as necessary in order to guarantee that data will never be? > 	   corrupted even if interrupted mid-write, and also retainss3 > 	   performance properties of write-back caching.o  D The definition of 'write-behind' that I'm familiar with is simply a H process which uses multiple buffers to allow it to accumulate new dirty G data while previous dirty data is being written out to disk as fast as tG it can be.  In other words, it's pretty similar to write-back caching, n) just maximally aggressive in its writing..   > F > 	   Provides performance of write-back with safety of write-through.  @ No:  it may guard against corruption (as the other mechanisms I G described above do as well), but it still does not tell you *when* the t" data has actually made it to disk.   - bill   ------------------------------  % Date: Sun, 24 Apr 2005 17:10:23 -0400)- From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: Slow Filesystem I/O, Message-ID: <426C0B37.F345FCCB@teksavvy.com>   Dan Foster wrote:cD > In essence, writes returns as soon as data has been written to theJ > in-memory (system or controller) cache, rather than actually written out > and completed to disk.  8 Reminds me of backup and TK50s in the VMS 5.* timeframe.  H BACKUP made significant improvement to TK50 performance by caching a lotH of data and making one big write to tape, compared to previous behaviourB where it did multiple writes of smaller amounts. The TK50 had slowH "start to write", so the fewer times you required the unit to start, theE better it was. In teh past,  BACKUP woudl collect data while tape was2G iddle, write small amount to tape, wait for tape to complete, and start F gathering data again. The new BACKUP streamed a lot of data to tape at, the same time as it was collecting new data.  E Disk drives may have high maximum throughputs, but if you do multipleoH separate small IOs, you won't be getting that maximum throughput because5 the disk also has start-up times (position head etc).r  E On the other hand, from a multiuser OS point of view, having multipleiG smaller writes allows better timesharing behaviour because the IOs from.H another process wait less to get done. (if you were to do a single IO ofE a gig, then the other user would have to wait for that IO to complete ( before his read of 512 bytes completes).   ------------------------------  % Date: Sun, 24 Apr 2005 15:33:08 -0400l( From: Bill Todd <billtodd@metrocast.net>  Subject: Re: Slow Filesystem I/O= Message-ID: <ke6dnenjWcvrafbfRVn-rQ@metrocastcablevision.com>p   Alan Greig wrote:k > Bill Todd wrote: >  > G >>Any operating system at all serious about its future would have fixede >  > D >>such default behavior a decade or more ago:  looking like an utter >  > slug > = >>when compared with the default behavior on Windows or Unix,q >  > especially > C >>while providing no stronger guarantees that the data has actually  >  > made > . >>it onto the disk as compensation, is absurd. >  > = > Recall Bill that VMS did fix this problem a decade ago withy > Spiralog/TNFS/Files-64.v  G And then fairly quickly rescinded support for that fix.  That's simply  G more evidence that about a decade ago serious support for VMS's future  @ started grinding to a halt, though inertia allowed considerable C additional significant development to come to fruition before that  G process completed with the diversion of most remaining effort into the h Itanic port.  -   Sure it had problems but rather than fix orrD > re-implement the programmers were sacked during downsizing and theF > product dropped. With that file system in place a simple write of anE > 80MB file could indeed complete almost instantly. I ran a full-feedoG > news-server (ANU News) with Spiralog field-test for some time and meta > some of the developers.u  A My (admittedly vague) recollection is that (for obvious reasons) a> Spiralog did not change *default* file system behavior in any F application-visible way, but rather made a considerably richer set of F options available (some of which may, of course, have been options to B change the default behavior manually).  So I don't understand how E Spiralog itself could have affected RMS's default performance nearly  G that much (e.g., when RMS specified that its internal buffer should be iD written to disk, it had the right to assume that it indeed had been F written when the QIO completed, so Spiralog would have had to respect G that right by performing a synchronous disk write:  yes, it could have  I combined that with other data needing to make it to disk, but the bottom  D line would remain that it would take at last one disk revolution to D destage each 8 KB RMS buffer, which is nowhere nearly equivalent to G making the disk's entire sequential bandwidth available to that single  
 application).o  E Now, it certainly would have been possible to change *RMS* (probably  F only in relatively minor ways) such that it could tell QIO "Hey, just E take this small buffer off my hands so I can reuse it, and if I ever -A really care when it actually gets to disk (e.g., the application rI requests a FLUSH or the file is closed) I'll give you a nudge".  If such eH changes were implemented, then indeed it would have solved much of even ) the default-behavior performance problem.r   - bill   ------------------------------    Date: 24 Apr 2005 13:15:56 -0700* From: "Alan Greig" <greigaln@netscape.net>  Subject: Re: Slow Filesystem I/OC Message-ID: <1114373756.162676.271960@g14g2000cwa.googlegroups.com>n   Bill Todd wrote:   >i >0B > My (admittedly vague) recollection is that (for obvious reasons)? > Spiralog did not change *default* file system behavior in anyaG > application-visible way, but rather made a considerably richer set ofy  G > options available (some of which may, of course, have been options to   C > change the default behavior manually).  So I don't understand howmF > Spiralog itself could have affected RMS's default performance nearlyE > that much (e.g., when RMS specified that its internal buffer should  beE > written to disk, it had the right to assume that it indeed had beenPG > written when the QIO completed, so Spiralog would have had to respectl  C > that right by performing a synchronous disk write:  yes, it coulde have  A Spiralog allowed the user to over-ride the default on a directorye@ and/or per file basis. If you told it to use 'unsafe' write-backF caching on a file it would. QIO completion in this case meant that theG write had made it to Spiralog but not the physical disk. This was fullydD documented and only happened if you explicitly selected the riskiestG option. For a news server where I really didn't care if every last itemeA made it to disk after a crash it made sense to go for the fastestlD option. I also alternated the  news item storage across two SpiralogE volumes - reinitialising them often. Another app it really speeded up-F was purveyor web cache. Again losing the odd cache item would not be aA problem. Moving some students (it was a university) onto SpiralognF volumes caused a stream of them to turn up at my door asking how I had speeded up the Alpha so much.o   > - bill   ------------------------------  % Date: Sun, 24 Apr 2005 20:44:24 -0400e( From: Bill Todd <billtodd@metrocast.net>  Subject: Re: Slow Filesystem I/O= Message-ID: <E6adnVhYCcz3oPHfRVn-3A@metrocastcablevision.com>r   JF Mezei wrote:l   ...h  G > On the other hand, from a multiuser OS point of view, having multipletI > smaller writes allows better timesharing behaviour because the IOs fromb( > another process wait less to get done.   Not really.S  #   (if you were to do a single IO of G > a gig, then the other user would have to wait for that IO to complete * > before his read of 512 bytes completes).  E On the other hand, if you broke up that 1 GB write into, say 100,000 yG 10KB writes, instead of taking about 20 seconds to complete they'd tie rE up the disk for more like 10 - 20 minutes, and every 512-byte access o/ during that time would experience extra delays.M  D In practice, it makes sense to use writes large enough that they'll I achieve *most* of the available sequential bandwidth of the disk without u@   too seriously delaying any interleaved small access requests. I Breaking up larger writes into individual requests on the order of 1 - 4 .G MB in size isn't a bad compromise:  you get 60% - 90% of the available rG disk bandwidth without stalling interleaved requests by more than 30 - eE 90 ms. max (though if you're streaming data to disk you might choose uH slightly smaller request sizes such that you can keep exactly one extra F large request in the disk's request queue at all times, thus avoiding H any lost rotations when no other activity is present while limiting the 6 maximum delay for such activity when it *is* present).   - bill   ------------------------------  % Date: Sun, 24 Apr 2005 22:07:34 -0400s' From: "Main, Kerry" <kerry.main@hp.com>c  Subject: RE: Slow Filesystem I/OR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECC91@tayexc19.americas.cpqcorp.net>   > -----Original Message-----: > From: Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40=20! > [mailto:pmoreau@ath.cena.fr]=20u > Sent: April 24, 2005 2:33 PM > To: Info-VAX@Mvb.Saic.Comm" > Subject: Re: Slow Filesystem I/O >=20   [snip..]   >=20? > Bill is right, rms default values are stupid. They were OK=20u > for VAX 780=207 > (1 mips) with 4 Mb memory and disks at 500 Kb/sec ...g >=20	 > Patrick  > --   Patrick,  G Some parameters and quota's are being changed over time. As an example,s= check out the following extract from OpenVMS V7.3-1 notes:=20   < http://h71000.www7.hp.com/doc/731FINAL/6657/6657pro_007.html  
 Section 5.10:nG "Prior to Version 7.3--1, the maximum size for the mailbox buffer quota G was 64,000 bytes. OpenVMS Alpha Version 7.3--1 supports the creation ofdF mailboxes with larger buffer quotas for improved application scaling."   Section 5.11.1: > "The multiblock count for a sequential disk file sizes the RMSF intermediate buffer for disk block transfers; this count serves as theH I/O transfer size. The system default multiblock count is increased fromA 16 to 32. This increase reduces sequential file read or write I/OeA requests by a factor of 2. If the application does not assign thepA multiblock count explicitly (using the RAB$B_MBC setting) or as amG process default (using the DCL command SET RMS_DEFAULT), the new systemo( default multiblock count of 32 applies."   Section 5.11.3: 0 "New System RMS Write-Behind Performance Option"  D And in V7.3-2, while I am not sure how much is RMS related, a recentG poster found a COPY test he did resulted in 2x performance over V7.3-1. ; Search performance was also increased in V7.3-2. Reference: D http://h71000.www7.hp.com/doc/732FINAL/aa-rv8xa-te/00/00/19-con.html   Regardsl  
 Kerry Main Senior Consultantm HP Services Canada Voice: 613-592-4660n Fax: 613-591-4477t kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  # Date: Sun, 24 Apr 2005 21:07:44 GMT + From: "D. Stussy" <kd6lvw@bde-arc.ampr.org>n* Subject: Re: What is SMTP status code 556?< Message-ID: <Pine.LNX.4.62.0504182122380.73@kd6lvw.ampr.org>  * On Wed, 20 Apr 2005, Lawrence Bleau wrote:6 > I'm running OpenVMS 7.3-2 AXP with TCPIP V5.4 ECO 4.E > A user of mine had a mail message returned to him with the message:  >lB > 556 %TCPIP-E-SMTP_XFAIL, remote transaction failure, comcast.net >v; > I looked up SMTP_XFAIL with HELP/MESSAGE and got nothing. < > I searched for the SMTP status codes, finally found an RFC> > or two, but they don't say anything about 556.  In fact, the' > status codes only go up to about 554.h >z3 > Does anyone know what SMTP status code 556 means?t  N It means that you should report that system to rfc-ignorant.org.  556 is not aO valid defined code in RFC 2822 (which is current).  I know of no subsequent RFCo. or other standard which has added such a code.   ------------------------------   End of INFO-VAX 2005.229 ************************