1 INFO-VAX	Tue, 30 May 2000	Volume 2000 : Issue 301       Contents:7 Re: "VMS on Wildfire" Slides from NELUG meeting May 4th L Re: Absolute fastest way to get a 100% correct record count for RMS   files?
 Re: AES V2.2E 
 Re: AES V2.2E 
 Re: AES V2.2E 
 Re: AES V2.2E 
 Re: AES V2.2E , Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?) Re: Compiling c++ on VMS Re: Compiling c++ on VMS Re: Compiling c++ on VMS Re: Compiling c++ on VMS
 Re: DAP error 0 Display open files on shadow set across cluster?4 RE: Display open files on shadow set across cluster? Efficient Sleep function Re: ES40 Configuration Re: General discussion comment Re: General discussion comment Memo:  internet mail under VMS Re: MicroVMS 4.4 Re: MicroVMS 4.4* Re: OpenVMS vs Tru64 Pathworks performance Re: Physical memory usage  Re: Physical memory usage  Re: Physical memory usage & Re: Prob w/DCPS 1.7,HP4050, and HPGL/2 Problem with resource locks * Re: RMS handling of extremely long records" Re: RMS tuning versus file caching" Re: RMS tuning versus file caching" Re: RMS tuning versus file caching Re: Setting password% UCX v4.2 - Telnet connection timeout?  variable and FTP in a script  Re: variable and FTP in a script  Re: variable and FTP in a script  Re: variable and FTP in a script  Re: variable and FTP in a script- Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias , Re: ver 7.1 Openvms will run on the new Ds20, Re: ver 7.1 Openvms will run on the new Ds20 Re: Wildfire Announcement  Re: Wildfire Announcement  Re: [DOCUMENTATION]: Help me ? Re: [DOCUMENTATION]: Help me ?& Re: [humor] UNIX/OpenVMS email "virus"  F ----------------------------------------------------------------------  % Date: Tue, 30 May 2000 08:11:40 -0400   From: norm.raphael@jamesbury.com@ Subject: Re: "VMS on Wildfire" Slides from NELUG meeting May 4th4 Message-ID: <C22568EF.004228E2.00@jklh21.valmet.com>  4 I stand corrected.  My point remains valid, however.        ' paul@sture.ch on 05/28/2000 02:11:05 AM    Please respond to paul@sture.ch    To:   Info-VAX@mvb.saic.com  cc: A Subject:  Re: "VMS on Wildfire" Slides from NELUG meeting May 4th         < In article <C22568E9.005A6362.00@jklh21.valmet.com>,  wrote:   >  > Soon to be fixed!  > K > [BSOD's notwithstanding, it is no less unsafe to "turn off" a VMS machine  > without first = > performing an orderly shutdown than it is a Wintel machine. N > You never shut down an OpenVMS cluster, but you do sometimes shut down a VMSB > machine. The "beauty part" is that they are not the same thing.] > L Sorry, but I have to correct you there. NT employs a "lazy write" technique.   ___ 
 Paul Sture Switzerland    ------------------------------    Date: 30 May 2000 12:31:47 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> U Subject: Re: Absolute fastest way to get a 100% correct record count for RMS   files? H Message-ID: <y4hfbgfhws.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  , David A Froble <davef@tsoft-inc.com> writes:  N > Actually, I'm not sure what happens with an indexed file when the bucket and > buffer differ.  K That can't happen 8-) - by definition, a buffer fro non-sequential files is L the same size as a bucket. For sequential file, there's also the multi-block( count (IIRC) which sets the buffer size.   	Jan   ------------------------------  % Date: Tue, 30 May 2000 12:00:47 +0200 % From: "Fred Zwarts" <F.Zwarts@KVI.nl>  Subject: Re: AES V2.2E. Message-ID: <8h03gd$14d$1@info.service.rug.nl>  9 "James Lee" <r35920@email.sps.mot.com> wrote in message = + news:392D0FD6.249EC422@email.sps.mot.com...  >=201 > Any europeans (uk even) got AES 2.2E running...  >=20G > Can't get modem to dial (MultiTech modem MT2834L ) supplied by COMPAQ  >=20 > --=20 	 > Jim Lee 
 > VMS Support   > Yes. We in the Netherlands have it running with a REPKO modem, supplied years ago by Digital.G I'm not happy with AES 2.2. It has less features than earlier versions, G in particular it is not "cluster aware". It probably is a rewrite for =  Unix, H later ported to VMS. Earlier versions could be used transparantly on anyH node in the cluster. Now it can be used on only one node in the cluster,E the one with the modem. It did not work properly anymore with a Modem   connected to a DECserver 200 MC.F Another problem came with VMS 7.2. The foreign mail protocol specifierH DSN% is now interpreted differently and it requires that the remainder = of) the address is within quotation marks.=20 F These two problems together caused that no automatic AES notifications0 are sent to Compaq after system crashes anymore.   ------------------------------  % Date: Tue, 30 May 2000 12:22:21 +0100   From: steven.reece@quintiles.com Subject: Re: AES V2.2E> Message-ID: <802568EF.003E8B3A.00@qedilc01.qedi.quintiles.com>  4 Fred Zwarts (f dot zwarts at kay vee I dot nl wrote:0 >>>It did not work properly anymore with a Modem# connected to a DECserver 200 MC.<<<   O This is likely and , perhaps, even expected.  The only DECserver which has been O qualified against V2.2 of DSN is the DECserver 700 MC.  This is a DECserver 700  with modem control on it.   G I know of a DS700-08 at another site, without a flash-card, running the = WWENG1.SYS image with a modem attached which works just fine.    ------------------------------  % Date: Tue, 30 May 2000 13:31:07 +0200 % From: "Fred Zwarts" <F.Zwarts@KVI.nl>  Subject: Re: AES V2.2E. Message-ID: <8h08pr$2ot$1@info.service.rug.nl>  2 "Fred Zwarts" <F.Zwarts@KVI.nl> wrote in message =( news:8h03gd$14d$1@info.service.rug.nl...9 "James Lee" <r35920@email.sps.mot.com> wrote in message = + news:392D0FD6.249EC422@email.sps.mot.com... J > It did not work properly anymore with a Modem connected to a DECserver = 200 MC.   / Sorry for the typo, I meant a DECserver 700 MC. C I finally managed to make it work, but it needed some dirty tricks.    ------------------------------  % Date: Tue, 30 May 2000 05:02:33 -0700 ? From: Mike Price <mike.priceNOmiSPAM@littlewoods.co.uk.invalid>  Subject: Re: AES V2.2E9 Message-ID: <003575d0.0f9e75fd@usw-ex0103-086.remarq.com>   : We will probably be upgrading AES in the near future - any? chance you could tell us what the 'dirty tricks' are to save us  re-inventing them please??   Thanks  
 Mike Price    L * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *G The fastest and easiest way to search and participate in Usenet - Free!    ------------------------------  % Date: Tue, 30 May 2000 17:42:56 +0200 % From: "Fred Zwarts" <F.Zwarts@KVI.nl>  Subject: Re: AES V2.2E. Message-ID: <8h0ni0$79k$1@info.service.rug.nl>  F "Mike Price" <mike.priceNOmiSPAM@littlewoods.co.uk.invalid> wrote in =; message news:003575d0.0f9e75fd@usw-ex0103-086.remarq.com... < > We will probably be upgrading AES in the near future - anyA > chance you could tell us what the 'dirty tricks' are to save us  > re-inventing them please?? >=20 > Thanks >=20  C The problem was that AES now wants to create the LTA device itself, G with a fixed name. However, we have many other products using reverse =  LAT.F The LAT ports are created dynamically, so we can't be sure that the=20F LTA device name given to AES is free at the moment that AES wants to =
 create it.C What we did is that we told AES that the device was called LTA0DSN. C AES accepts it, because it starts with LTA and a numeric character. G We use LATCP to create a new LTA device with this logical name LTA0DSN. " LATCP CREATE PORT /LOGICAL=3D(...)C AES, when it starts, checks the name, tries to create de device,=20 J which fails, but it then discovers that the device somehow is existing,=20 and it starts to use it.   ------------------------------  % Date: Tue, 30 May 2000 13:11:45 +0100   From: steven.reece@quintiles.com5 Subject: Re: Compaq not as bad as Andrew says (wish?) > Message-ID: <802568EF.0043103E.00@qedilc01.qedi.quintiles.com>   Bill, M Your comments are (like alot of what we all say here in comp.os.vms/info-vax)  very subjective.  P Whilst it may be tricky to get the last gasp of performance out of a VMS system,O it is likely the same on _all_ platforms.  This is why we are going through the O present cycle of "we need more horsepower to do this job so we'll buy another/a  bigger box".  P This is also yet another reason why bloatware from a certain company is acceptedK by the industry.  It needs more CPU and more disk so the PHM's view is that / they'll just buy more disks and faster systems.   J Nobody in my experience goes to get the last bit of performance out of anyJ application which they have bought in.  A very limited number of operatingJ system writers or application writers probably go the extra bit to get the3 maximum performance.  One also has to balance out : N - the cost in terms of manpower to tune the application that final little bit;6 - the cost of that faster system or that extra system;O - the cost in the future of losing something because you've taken a shortcut to O get performance and it's compromised either the system or the application data.   G Most managers in most companies are forced to go for the bigger system.    Steve.   Bill Todd wrote:N >>>Not to mention the related point that you need *more* expertise to get goodK performance out of VMS than out of Unix, which gives most applications good ! performance right out of the box.   G And of course that last dovetails neatly with your own observation that J people seldom bother with much performance optimization:  for such typicalK non-performance-optimized applications, Unix therefore makes more efficient G use of the hardware than VMS does, hence is correctly perceived as more  cost-effective.<<<   ------------------------------   Date: 30 May 2000 15:37:54 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)5 Subject: Re: Compaq not as bad as Andrew says (wish?) , Message-ID: <8h0n8i$d7t@gap.cco.caltech.edu>  R In article <8gs3ga$jbg$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > H >And of course that last dovetails neatly with your own observation thatK >people seldom bother with much performance optimization:  for such typical L >non-performance-optimized applications, Unix therefore makes more efficientH >use of the hardware than VMS does, hence is correctly perceived as more >cost-effective.  E Exactly.  And it all boils down to (essentially) a SINGLE difference  J between the OS's.   On a typical lightly loaded, memory rich, workstation,@ Linux (and probably most other Unices, but I can't say for sure)A automatically utilize the unused portions of memory to cache file F operations.  This results in huge increases in write performance and aJ substantial increase in read performance in a typical workstation job mix,J which consists of a lot of small files being written, read, and then oftenI deleted.  Only when file sizes reach up into the hundreds of megabytes or J the system becomes heavily loaded do the returns for this automatic systemG break down. At that point RMS tuning on OpenVMS can outperform the Unix F workstations.  However, in the normal mix of things for lightly loadedI machines, the "out of the box" Unix configurations do "disk I/O" about an C order of magnitude faster than VMS does.   That's in quotes because G oftentimes the data never hits the disk. You can tune VMS processes and I programs to give better performance, but on the lightly loaded systems at H best you can get really close on the read speeds and you can never come J anywhere close on the write speeds (defining write as "program wrote data H to 'disk' successfully, without worrying about if the data ever hit the F physical disk).  And you had to work at it.  Whereas on Linux it just > happened automatically.  Consequently, something as simple as    % tar xf whatever.tar 
 % cd whatever  % make  G runs blindingly fast on Unix, and crawls on VMS.  And here I'm talking  F about two nearly identical DS10s, one running RedHat 6.2 and the otherI OpenVMS 7.2-1.  (It doesn't help that the Elsa graphics card and DECterms I don't scroll very quickly - sometimes you're just waiting for the text to  scroll through.)    J Typically in these "lightly loaded" environments, the safety of having theK data hit the disk is of little importance.  So VMS really is slow and Linux H (Unix) is fast for typical programmer/technical workstation workloads.  K And Linux gets this boost without anybody having to twiddle RMS parameters, I which is a good thing, because, well, WHY NOT make good use of the unused A memory in a system?  Lord knows you pay enough for it on a DS10!     Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  # Date: Tue, 30 May 2000 18:35:22 GMT * From: young_r@eisner.decus.org (Rob Young)5 Subject: Re: Compaq not as bad as Andrew says (wish?) + Message-ID: <aTT5NM+KjsR7@eisner.decus.org>   a In article <8h0n8i$d7t@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes: T > In article <8gs3ga$jbg$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: >>I >>And of course that last dovetails neatly with your own observation that L >>people seldom bother with much performance optimization:  for such typicalM >>non-performance-optimized applications, Unix therefore makes more efficient I >>use of the hardware than VMS does, hence is correctly perceived as more  >>cost-effective.  > G > Exactly.  And it all boils down to (essentially) a SINGLE difference  L > between the OS's.   On a typical lightly loaded, memory rich, workstation,B > Linux (and probably most other Unices, but I can't say for sure)C > automatically utilize the unused portions of memory to cache file H > operations.  This results in huge increases in write performance and aL > substantial increase in read performance in a typical workstation job mix,L > which consists of a lot of small files being written, read, and then oftenK > deleted.  Only when file sizes reach up into the hundreds of megabytes or L > the system becomes heavily loaded do the returns for this automatic systemI > break down. At that point RMS tuning on OpenVMS can outperform the Unix H > workstations.  However, in the normal mix of things for lightly loadedK > machines, the "out of the box" Unix configurations do "disk I/O" about an E > order of magnitude faster than VMS does.   That's in quotes because I > oftentimes the data never hits the disk. You can tune VMS processes and K > programs to give better performance, but on the lightly loaded systems at J > best you can get really close on the read speeds and you can never come L > anywhere close on the write speeds (defining write as "program wrote data J > to 'disk' successfully, without worrying about if the data ever hit the H > physical disk).  And you had to work at it.  Whereas on Linux it just @ > happened automatically.  Consequently, something as simple as  >  > % tar xf whatever.tar  > % cd whatever  > % make > I > runs blindingly fast on Unix, and crawls on VMS.  And here I'm talking  H > about two nearly identical DS10s, one running RedHat 6.2 and the otherK > OpenVMS 7.2-1.  (It doesn't help that the Elsa graphics card and DECterms K > don't scroll very quickly - sometimes you're just waiting for the text to  > scroll through.)   > L > Typically in these "lightly loaded" environments, the safety of having theM > data hit the disk is of little importance.  So VMS really is slow and Linux J > (Unix) is fast for typical programmer/technical workstation workloads.  M > And Linux gets this boost without anybody having to twiddle RMS parameters, K > which is a good thing, because, well, WHY NOT make good use of the unused C > memory in a system?  Lord knows you pay enough for it on a DS10!   >   - 	So things aren't moving fast enough for you?   ? 	Caching gets much improved in the next go round of VMS (unless D 	I've mixed up roadmaps or am misremembering).  How did this happen?D 	Senior engineer at a DECUS explained that: "remember, VIOC was justA 	a stop-gap measure... it wasn't supposed to be around this long" A 	or something similar.  Relase notes showed new sysgen parametersME 	for write behind caching and write delay.  Something to look forward2D 	to.  So how did this happen?  Fork in the road called Spiralog from 	what I understand.A  A 	So maybe in a year or less, we put the limited caching behind us F 	for those that are at 7.3 and higher and maybe move on to complaining< 	that VMS is so primitive because a lot still has to be doneD 	at a command line.  How primitive.  MS-DOS is dead... I want things$ 	to look and feel just like Windows.    	NOT!  Cut my pinkies off first.  = 	So what is the next complaint we can moan about so I can gett 	practiced up?     				Robr   ------------------------------  % Date: Tue, 30 May 2000 11:18:58 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>l! Subject: Re: Compiling c++ on VMS,) Message-ID: <39338782.194DBC19@gtech.com>o   Jeffrey Ric wrote:H > Is it possible to compile a c++ program using either VAX cc, DEC cc orD > gcc.  I tried to use gcc and the plus_plus option.  I got an errorE > message saying that the executable wasn't found.  I did not see anyi5 > documentation on c++ source on the other compilers.b  ? To compile a C++ source FOOBAR.C use $ CXX FOOBAR.C for DEC C++b9 and either GXX FOOBAR.C or GCC/PLUS FOORBAR.C for GNU C++/ depending on the setup.p  A If GCC/PLUS can not fine the image, then the GNU C++ installatione3 is broke and you should contact the system manager.u   Arne   ------------------------------  # Date: Tue, 30 May 2000 11:05:47 GMTm7 From: Marcin Kasperski <Marcin.Kasperski@softax.com.pl>-! Subject: Re: Compiling c++ on VMS-- Message-ID: <39339E7C.38730BEF@softax.com.pl>0   Jeffrey Ric wrote: > H > Is it possible to compile a c++ program using either VAX cc, DEC cc orD > gcc.  I tried to use gcc and the plus_plus option.  I got an errorE > message saying that the executable wasn't found.  I did not see any0I > documentation on c++ source on the other compilers.  Thanks in advance.X >   C 1) There is separate Digital^HCompaq product - DEC CXX. This is thet< C++ compiler. You should purchase it and install separately.  ? 2) AFAIR GNU C++ is not fully ported to VMS - only GNU C works.w< But I have not checked this subject for some time, maybe sth has changed.   ------------------------------    Date: 30 May 2000 13:19:48 +0100T From: pmoreau@cenaath.cena.dgac.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40)! Subject: Re: Compiling c++ on VMS ! Message-ID: <iU1f5GJQd00w@gaelic>,  . In article <39339E7C.38730BEF@softax.com.pl>, 9 Marcin Kasperski <Marcin.Kasperski@softax.com.pl> writes:- [...] A > 2) AFAIR GNU C++ is not fully ported to VMS - only GNU C works. > > But I have not checked this subject for some time, maybe sth > has changed.  M Gnu C++ works at least on VAX VMS. I have ported some X11 applications on VMSD; with gcc/plus before buying a personal licence of DEC CXX. >   Patrick  -- eO ===============================================================================nO pmoreau@cena.dgac.fr  (CENA)     ______      ___   _           (Patrick MOREAU)f4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================a   ------------------------------  % Date: Tue, 30 May 2000 13:34:11 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>p! Subject: Re: Compiling c++ on VMS ( Message-ID: <3933A733.CDE239A@gtech.com>   Marcin Kasperski wrote:gA > 2) AFAIR GNU C++ is not fully ported to VMS - only GNU C works. > > But I have not checked this subject for some time, maybe sth > has changed.  H GNU C++ has worked on VMS VAX for more than a decade (since version 1.3x# or something in the late 1980's !).    Arne   ------------------------------  % Date: Tue, 30 May 2000 07:14:36 -0400h2 From: "Richard B. Gilbert" <DRAGON@compuserve.com> Subject: Re: DAP error7 Message-ID: <200005300714_MC2-A6D3-BD79@compuserve.com>   J         DAP is Data Access Protocol.   It's been years since I've seen th= isF error.  I believe that Pathworks has a log file which may provide someJ details.  VMS may have logged something in NETSERVER.LOG, particularly if=  , you have defined the FAL$LOG logical to "1".  H         I suspect that you have a network hardware problem; something is+ corrupting the data you are trying to send.t  6 Message text written by INTERNET:f_novelli@my-deja.com) >Trying to copy some files from a PC withr1 PATHWORKS to a microVAX machine via DECNET, using  nft, I get the error:e2 Error opening file: node"account pwd"::remote_path0 Because DAP error reported by remote node xx/xxx1 On the remote host a file of 0 blocks is created.f& Anyone can help me solve this problem? Best regards,<   ------------------------------  % Date: Tue, 30 May 2000 10:01:11 -0400n1 From: "Todd Nelson" <toddnelson@lehighcounty.org>N9 Subject: Display open files on shadow set across cluster? / Message-ID: <sj7i8bso5pj149@corp.supernews.com>   J I have two Alpha 4000 nodes running OpenVMS v 7.2.  The systems analysts /K programmers like to be able to see what files are open on a volume in orderFK to facilitate their file work.  However, when they use sho dev /files, they H get the files open on the volume on the system they are currently loggedG into... therefore, the file(s) could be accessed on the other system as I well, but they cannot tell unless they log into the other cluster member. K Is there a way to allow them to see the files open on both cluster members?tI The disks are Raid 5 Shadowsets..  The analysts have  GROUP        GRPNAM2A LOG_IO       NETMBX       SYSGBL       SYSLCK  TMPMBX privs only.i  H I know that I can use sysman to do this by executing the command on bothH nodes simultaneously, but I do not know how to allow the programmers to.   Any help would be appreciated.     Thanks   ------------------------------  % Date: Tue, 30 May 2000 11:22:27 -0300e1 From: "Boyle, Darren" <boyledj@bankofbermuda.com>I= Subject: RE: Display open files on shadow set across cluster?sK Message-ID: <F150836441C5D311A11700508B6FF01A9834DB@bdant024.bda.bobda.com>   D you can create a command file to do this using SYSMAN, then write anI executable shell to call the command file.  This executable shell is thennF installed with the required privileges, this is generally safe enough. - Darren   > ----------6 > From: 	Todd Nelson[SMTP:toddnelson@lehighcounty.org]' > Sent: 	Tuesday, May 30, 2000 11:01 AM- > To: 	Info-VAX@Mvb.Saic.Com< > Subject: 	Display open files on shadow set across cluster? > L > I have two Alpha 4000 nodes running OpenVMS v 7.2.  The systems analysts /G > programmers like to be able to see what files are open on a volume ino > ordernH > to facilitate their file work.  However, when they use sho dev /files, > theyJ > get the files open on the volume on the system they are currently loggedI > into... therefore, the file(s) could be accessed on the other system asdK > well, but they cannot tell unless they log into the other cluster member.rD > Is there a way to allow them to see the files open on both cluster
 > members?K > The disks are Raid 5 Shadowsets..  The analysts have  GROUP        GRPNAMoC > LOG_IO       NETMBX       SYSGBL       SYSLCK  TMPMBX privs only.e > J > I know that I can use sysman to do this by executing the command on bothJ > nodes simultaneously, but I do not know how to allow the programmers to. >   > Any help would be appreciated. >  >  > Thanks >  >  >     F **********************************************************************C This message and any files transmitted with it are confidential andvJ 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 copyingi of this message is prohibited.   Bank of BermudaMF **********************************************************************   ------------------------------  # Date: Tue, 30 May 2000 17:24:34 GMT  From: bbrzwski@my-deja.com! Subject: Efficient Sleep functionf) Message-ID: <8h0tfs$inp$1@nnrp1.deja.com>r  : We have been having difficulty coming up with an efficientF Sleep(TimeInMs) function that is accurate to within 1ms. The followingC is the code we are using and our timing results.  It appears we are F incurring an overhead of 1ms for every function call but is not due toG the actual call on the stack since we ran the sleep in a loop with timesE to sleep of 0 and received a timing of 30ms for 1000 sleeps.  We have < tried several different Sleep routines, but we come out with approximately the same timings.t   System Configuration:t ---------------------i% System Type    AlphaServer 2100 5/250t Cycle Time     4.0 nsec (250Hz)  Pagesize       8192 Byte OperatingSys   V7.1-2b  ! /////////  Code Sample //////////a #include <lib$routines.h>s #include <starlet.h> #include <descrip.h> #include <lnmdef.h>z #include <ssdef.h> #include <sleep.hxx>   uint32 SleepAst(uint32 u32Tmp) {e!   Flag * pflag = (Flag *) u32Tmp;h     if (pflag)     pflag->Signal();     return 1;s }r  " void Sleep(uint32 u32MilliSeconds) {-   uint32 u32Status;e   int64  i64Delay;   Flag   flag;  G   i64Delay = - (ONE_MILLISECOND * u32MilliSeconds); // negative is timea from current time in setimrg  ;   u32Status = sys$setimr(0, &i64Delay, SleepAst, &flag, 0);g     if (!(u32Status & 1))d     lib$stop(u32Status);     flag.Wait(); }o  " /////////  TEST RESULTS //////////   call               time slept  -----------------------------a Sleep(1)     2ms Sleep(2)     3ms Sleep(10)    10mso Sleep(100)   101ms Sleep(1000)  1001mse  ) for(int i=1; i<=1000; i++) Sleep(0)  30msM+ for(int i=1; i<=1000; i++) Sleep(1)  1953ms   2 Any insight or clues would be greatly appreciated.   Brian B.    & Sent via Deja.com http://www.deja.com/ Before you buy.g   ------------------------------  # Date: Tue, 30 May 2000 16:50:58 GMTi, From: Stanley Hippler <shippler@my-deja.com> Subject: Re: ES40 Configurationm) Message-ID: <8h0rha$h02$1@nnrp1.deja.com>t  E Thanks to all those who replied.  My interpretation of the replies iseG that 1) the 9 gig drives should be replaced with the 18 gig (at least), B 2) dual HSZ80s is probably a good thing, and 3) I need to ask more- questions as to the setup of the system disk.g  D What I Plan to Do:  as many physical disk drives as possible will beE put in a single Raid5 set, with this set being broken up into variouspE logical drives as needed by the applications.  This would spread dataoD access across as many physical spindles as possible and minimize theD storage loss due to Raid5.  A hot spare would be configured as well.E As to the number of physical drives in a Raid5 set,  I have not heardnC that there was a point of diminishing return, so if there is one, I F want to know!   The sales rep has suggested that we use a 9 gig systemE disk using the ES40's "onboard" SCSI controller.  Dual disks would beeE supplied, so shadowing would be possible.  I would prefer to keep theoD system disk as part of the raid configuration, and not have internalA disks at all.  I am interested in knowing what others use for theC/ system disk, given similiar i/o configurations.w  D To answer some other questions:  this is a single ES40 with dual 677G mhz processors; a DS-TZ89N-VW DLT drive will be used for backup; expectsH approximately 400 concurrent telnet sessions to SCT's Plus2000 software.  + Thanks again.  All replies are appreciated.    Stanley Hippler  McNeese State University  ) In article <8glrmu$2i4$1@nnrp1.deja.com>, /   Stanley Hippler <shippler@my-deja.com> wrote: H > From our local sales rep, we requested an ES40 configuration; dual 667C > processors, 4 gigabytes ram, roughly 200 gigabytes Raid-5 capableeH > disk.  The response included dual HSZ80 controllers, twenty-four 9 gig& > disks to meet the disk requirements. > F > While this is skimpy information I am supplying, what I want to know is:i- >     1) Is this really a one-node "cluster"?n< >     2) Does this seem like a reasonable disk configurationA >     3) Given the associated costs of using the HSZ80s, is therel@ >        some other I/O configuration that should be considered? >*H > I can set up and run a cluster.  However, this is a single machine.  IA > would prefer a more simple I/O solution, without the clustering* > management overhead. >-F > The main software applications will include SCT's Plus2000 packages,/ > email for up to 8000 students, OSU webserver.: >:, > Any responses will be greatly appreciated. >g > Stanley Hippler@ > McNeese State University >e( > Sent via Deja.com http://www.deja.com/ > Before you buy.e >(    & Sent via Deja.com http://www.deja.com/ Before you buy.n   ------------------------------  % Date: Tue, 30 May 2000 02:29:07 -0400s* From: David A Froble <davef@tsoft-inc.com>' Subject: Re: General discussion commentp- Message-ID: <39335FB3.ECABDED9@tsoft-inc.com>o   Bill Todd wrote: > F > I've been aware for a while now both in discussions here and privateK > extensions of them that my wording has gotten, shall we say, rather blunt M > rather often with people with whom I actually enjoy interacting.  Since theeH > bluntness may be much more apparent than the appreciation, I'd like toG > explain it - especially as it's not my preferred method of discourse.o  M For you Bill, I have to find another word.  'Blunt' isn't quite adequate. :-)i  I > By and large, comp.os.vms comprises a set of die-hards, people who haveeM > stuck with VMS through thick and thin (more the latter for a long time now)oN > because they appreciate it.  Not only does this make them decidedly partisanH > as individuals, voicing opinions often more strident than informed andL > balanced when discussing the relative merits of other environments, but itK > makes the environment self-reinforcing, since dissenting opinions tend tor, > get drowned out regardless of their merit.  4 You got a point.  However, it's not always that way.  M > My normal inclination is to avoid such groups, since I don't much care whatqN > other people think if I've considered their opinions and found them wanting.K > The problem here is that I really *do* appreciate VMS, believe that othersM > systems are by and large technically inferior, and would really like to seerM > Compaq take the steps necessary to make VMS palatable (without sacrifice todI > its existing strengths) to the world at large - and automatic fanatical K > opposition by current VMS customers to all things non-VMS seems likely to A > make Compaq think twice before undertaking any such initiative.   N I believe you do appriciate VMS.  I've seen the honest effort.  However, we'veO seen that the 'Palmer Doctrine' appears to be dead and behind us.  I do believecN we both see positive and pragmatic actions starting.  I'll also admit that theP last part of your grossly over-run sentence does have a valid point, but doesn't apply to everybody.n  J > People here often do seem willing at least to contemplate new directionsM > once they've gotten past their initial automatic responses, so I've come toiJ > tend to phrase things in a manner that grabs their attention in a mannerB > difficult just to slough off ("First, you have to get the mule'sK > attention...").  Should the environment become more receptive to balancedhK > discussion of such input, I will happily revert to a less confrontationalm > approach.   O Having been nice, I'll now say that when you start stating opinion as fact, andyP go on to build a case with such 'facts', the 2x4 up alongside the mule's head is a bit too much.r   Your statement:.  K Not to mention the related point that you need *more* expertise to get goodVK performance out of VMS than out of Unix, which gives most applications goodg! performance right out of the box.n  O In my experience it DOES NOT require more expertise to get good performance outeN of VMS.  You based your statement on some porting of Unix code to VMS, withoutO re-doing the I/O in a VMS manner.  Sort of like pounding the square peg throughiP the round hole.  You used a bad example, and then classified all VMS performance based upon that example.   Another example:  H 'Good' is a subjective term, so let's just say that default, unoptimizedK Unix file system performance is noticeably better than default, unoptimized J VMS file system performance for typical applications, mostly due to Unix'sK default system caching (my vague recollection is that VMS can be configuredaF to read-cache at the disk level, though possibly only in non-clusteredL environments, though that may no longer be a restriction, which helps some -E though the path to such a cache is considerably longer than that to atE file-level cache - but in any case doesn't cover write-back caching).   M You make the assumption that a VMS solution will use the same techniques as axO Unix solution.  Yes, if I write Unix code for VMS, VMS will sometimes, probablyoO many times, be at a disadvantage.  But I would not do that.  I would design the+O application to use the strengths of VMS, and many times do better than the UnixsK system.  You tout the Unix caching of data, rather than go to disk for each M read.  Yeah, not a bad thing.  But, to be cached, the data still must be read-J one time, and when done, any updates written back to disk.  There are manyE methods in VMS to achieve the same result, and many times they can be-M implemented in a manner that will allow VMS to provide the best performance. sI I'll observe that caching data at the file system level doesn't allow any.P intellegence to be built into how the data is handled, and sometimes intellegent> handling of the data can be faster than the file system cache.  K I really don't mind your doses of reality.  But please don't make unfoundedeP statements, declare them fact, and then build more arguments upon these 'facts'.   Dave   -- t4 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: Tue, 30 May 2000 13:26:00 -0400a' From: "Bill Todd" <billtodd@foo.mv.com>.' Subject: Re: General discussion commento( Message-ID: <8h0tdj$kuo$1@pyrite.mv.net>  @ David J. Dachtera <djesys.nospam@earthlink.net> wrote in message' news:39333AF1.7CF905CC@earthlink.net...- > Bill Todd wrote:< > > Should the environment become more receptive to balanced= > > discussion of such input, I will happily revert to a lessa confrontational 
 > > approach.a >oH > As I've mentioned before, Bill, many of us do OpenVMS - period. That'sI > why it's what we do best. Many of us tolerate other o.s.-es because the=H > systems we maintain must interface with them in one way or another. InE > the case of the Chicago OpenVMS market, however, other o.s.-es haveU+ > become a matter of professional survival.  > 6 > Two points you seem unable (or unwilling) to accept: >|( > 1. You're messing with our livelihood.  G I understand that, and don't have any hesitation in doing so as long asRL there's no down-side risk and I think it may help change VMS for the better: you use VMS, you don't own it.  I VMS as you know it is in no danger of disappearing any time soon, so your=L livelihood is secure.  But it also has no likelihood of growing market shareH by continuing business as usual (the past decade-plus should be adequateD proof of that, despite hardware that *should* have helped it do so).D Extending (rather than morphing) VMS to be more palatable to a wider? audience can only improve matters, both for you and for Compaq.u   >aI > OpenVMS feeds, houses and supports us and our families. Assault that in A > *ANY* way, and you *WILL* provoke a confrontation - guaranteed.x  L If asserting that VMS is not perfect and trying to improve it constitutes an assault, so be it.   >0C > My advice? Knock off the confrontations. Period. They are neither  > appropriate nor productive.- > A > 2. There's room in the world for other o.s.-es - just not here.  >e. > This is "comp.os.vms", not "comp.os-dujour". > B > If you want to proselytize on the merits, advantages, etc. otherH > o.s.-es, feel free to participate in other newsgroups, but be preparedI > to encounter an equal (or possibly greater) degree of bigotry regardingc: > those systems in those groups. It's not unique to c.o.v.  H No, I'll continue to feel free to point out their comparative advantagesK here:  VMS is a lot more capable of incorporating their strengths than theyKD are of incorporating VMS's (the old 'quality built in, not added on'L advantage), so VMS is the logical place to start if you want to wind up with+ a system that's superior in *all* respects.l  I The definition of 'proselytizing' involves conversion, not extension.  IfrJ you think I've been encouraging people to convert to other systems, you've missed the point entirely.   - bill   >h
 > ...IMHO. >u > -- > David J. Dachteran > dba DJE Systemsc$ > http://home.earthlink.net/~djesys/ >p< > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/i   ------------------------------  % Date: Tue, 30 May 2000 09:55:34 +0100t, From: Paul BEAUDOIN <paul.beaudoin@hsbc.com>' Subject: Memo:  internet mail under VMS : Message-ID: <802568EF.00310970.00@lithium.systems.uk.hsbc>   Gents,  B I have a macro program/DCL procedure that dials out from VMS, logs into the provider and sets uptC the terminal port for IP (UCX /SLIP now but as this is the DCL bit, E probably easily changed). The program is SMG based and you can set up F a database of numbers to call, ports to use, usernames, passwords etc.C It also watches the port and disconnects after a settable amount oftD time of no (or little) data and keeps a running record of time spentF on line. A bit quirky but reliable. Anyone want a copy please mail me.. If enough interest, I will submit to Freeware.   Paul            D ********************************************************************B  This message and any attachments are confidential to the ordinaryB  user of the e-mail address to which it was addressed and may also>  be privileged. If you are not the addressee you may not copy,8  forward, disclose or use any part of the message or itsC  attachments and if you have received this message in error, pleaseeB  notify the sender immediately by return e-mail and delete it from
  your system.d  =  Internet communications cannot be guaranteed to be secure or A  error-free as information could be intercepted, corrupted, lost,a>  arrive late or contain viruses. The sender therefore does not?  accept liability for any errors or omissions in the context ofr?  this message which arise as a result of Internet transmission.i   D  Any opinions contained in this message are those of the author and ?  are not given or endorsed by the HSBC Group company or office y=  through which this message is sent unless otherwise clearly )A  indicated in this message and the authority of the author to so  3  bind the HSBC entity referred to is duly verified.   D ********************************************************************   ------------------------------   Date: 30 May 2000 12:48:11 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: MicroVMS 4.4v6 Message-ID: <8h0dab$52m$1@mailint03.im.hou.compaq.com>  b In article <B5555730-48364@165.247.44.178>, "Robert Deininger" <rdeininger@mindspring.com> writes:3 :On Fri, May 26, 2000 12:36 PM, Hoff Hoffman wrote:  :>I :>In article <8gjvpl$2qaa$1@info.cs.uofs.edu>, bill@cs.scranton.edu (Bill* :>Gunshannon) writes:mI :>:It's a long story, but I have installed MicroVMS 4.4 on a MicroVAX II.i :>J :>  Whoa.  Send me a copy of your distribution kit when you're done (as itJ :>  looks readable), and I'll archive it in the antiques section.  (I haveI :>  a MicroVMS V4.4 kit on RX50 in a box, but I have no idea if the RX50 t0 :>  media will itself still read correctly.) :-) :gH :If you really have gaps in your library, I've got drawers full of TK50sJ :going back to that era.  Some of our own, and a lot more that we recentlyI :inherited.  I don't have a complete inventory, but I know I've seen some-G :microVMS 4.x labels in there.  Also a TU58 boot tape for a Vax 11/750 aH :(version 5.something I think), but it says 1/2 on the label and I don'tB :have its mate.  We even got a large stack of 8" floppies with the7 :nice orange DEC labels - but no way to read these...   J :Let me know if there are specific TK50s you need, and I'll look for them.  C   I'm looking (as part of increasing the density and breadth of my iB   cubical's media stash), to try to duplicate the corporate media B   stash (on the assumption that all media eventually goes bad, andA   it's better to have a few copies around), and looking for most  $   any old OpenVMS distribution kits.  =   Contact me offline, and I can likely organize a media swap.y  J :spare parts. (THEY don't have any more VMS machines, but WE do.)  Lots ofF :hex-width unibus boards from 11/785s and machines of similar vintage.I :Probably some Vax 6000 stuff too.  I got a 1 MB memory "SIMM" for a 750.i  B   The DFWCUG folks are actively collecting old DIGITAL hardware ofE   all sorts, as well as old DIGITAL manuals for the scanning project.hG   (I don't have the amps nor the space for this old hardware, and thus uF   must limit myself to more recent and more workstation-sized widgets G   and old software kits.  Alas, I must read the old nine-tracks at the g   office.  Bummer.)c  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 30 May 2000 15:48:48 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: MicroVMS 4.40H Message-ID: <y4vgzwqhbz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  @ > Alas, I must read the old nine-tracks at the office.  Bummer.)  K The hardware wouldn't help you by itself - those tape drives draw a startup-L current that most residential installations won't handle. I know of somebodyN who, after tripping the building's fuses about every second time he turned theJ thing on and making himself exceedingly popular with the other inhabitantsJ in the process, inserted a 1 Ohm resistor into the power lead, cooled by aF bucketful of water; when the voltage was back to normal, a Reed relaisL switched the resistor out of the circuit. One day the relais got stuck; whenL the water had evaporated, the resistor thankfully desoldered itself from the wires.   	Jan   ------------------------------   Date: 30 May 2000 15:06:27 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)3 Subject: Re: OpenVMS vs Tru64 Pathworks performancer, Message-ID: <8h0ldj$d7t@gap.cco.caltech.edu>  i In article <3931229D.2349BC38@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:p% >Mark Iline - Info-VAX account wrote: E >> I'm not asking why this is - I know this isn't a trivial question.  >  >Many reasons:E >  - VMS systems usually do much less caching than Unix & Win systemsdD >    and it costs performance (but you are happy for it if the power >    goes !)  K This keeps coming up and I'm pretty sure that it's WRONG for a typical filedK serving application. Imagine Jane user works on some Microsoft document andrJ hits "save" every 10 minutes.  The time to transfer the file up to the VMSF machine is 1 minute, and it's 10 seconds to the other machine (Unix orG WNT).  If the power fails during the transfer interval the network and fI remote PC will both fail and the file will be corrupted on either OS, and I the slower one has a 6X larger window of opportunity for such failure, sotH on average, would end up corrupting files 6X more frequently.  The otherG common mode of failure is for the remote PC to crash for no good reasonaH other than that it's a piece of MS garbage, and that could easily happenK once a day, far more frequently than power failures occur.  For any server,tK regardless of OS, there should be a UPS (or the person managing it is nuts)wK and so it will stay up for a brief power failure, and shut down normally ifeK the power is off too long. My Linux machines never go down unless the powerfE fails for a long period, neither does my VMS machine.  So in the mosttG likely scenarios, the "write all data to disk immediately" results in ahJ HIGHER rate of file corruption than would a cached system which could move the data over the net faster.   I That isn't to say that once the data does get to the machine it shouldn'tpK go to disk reasonably quickly, which apparently WNT isn't so great at.  I'meG not sure how long data waits on Unix before it actually hits the disk. n   David Mathog mathog@seqaxp.bio.caltech.eduj? Manager, sequence analysis facility, biology division, Caltech dJ **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Tue, 30 May 2000 11:08:39 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>i" Subject: Re: Physical memory usage) Message-ID: <39338517.C1818C3E@gtech.com>m   Markus Nopp wrote:2 > where and how can i see how much physical memory > a process is using ?  " The very simple solution would be:  
 $ SHOW SYSTEMo   Arne   ------------------------------  % Date: Tue, 30 May 2000 11:14:20 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>m" Subject: Re: Physical memory usage) Message-ID: <3933866C.E93A8CCB@gtech.com>k   Georges SZAFRANSKI wrote:r > Markus Nopp wrote:4 > > where and how can i see how much physical memory > > a process is using ? > ; > The physical memory used by a process is the working set.d > J > The size of the working set list gives you the amount of physical memory% > that the process uses at this time.r > A > For each process you have to sum PCB$L_PPGCNT and PCB$L_GPGCNT.o > & > These fields are available with SDA.   And F$GETJPI !   Arne   ------------------------------  % Date: Tue, 30 May 2000 13:37:23 +0200e< From: Georges SZAFRANSKI <szafranski@lutece.evt.cpqcorp.net>" Subject: Re: Physical memory usage6 Message-ID: <3933C413.50302054@lutece.evt.cpqcorp.net>   Arne Vajhj wrote: >  > Markus Nopp wrote:4 > > where and how can i see how much physical memory > > a process is using ? > $ > The very simple solution would be: >  > $ SHOW SYSTEMn >  > Arne  G And of course the better one. But one has to keep in mind that on AlphatE Show system and sho proc/cont give a number of pages (8192 bytes) but 3 PPGCNT and GPGCNT are given in pagelets (512 bytes)    Georges.   ------------------------------  # Date: Tue, 30 May 2000 16:08:59 GMTP+ From: Paul Anderson <panderson@genicom.com> / Subject: Re: Prob w/DCPS 1.7,HP4050, and HPGL/2m@ Message-ID: <panderson-D393D3.12085430052000@news.earthlink.net>  D In article <Me-B46894.15213726052000@svlnews.lmms.lmco.com>, Jethro  Bodine <Me@nospam.com> wrote:   H > It would be nice if DCPS would skip the PCL to postscript translation F > for unrecognized printers as long as the DATA_TYPE=PCL parameter is  > specified.  G I'll have to check with others to see why this was not implemented.  I  G have a feeling that when the DCPS PCL translator was written, not many  E PostScript printers had native PCL and the PCL 4 translator was more h than adequate.  D Something like a DATA_TYPE=PCL /TRUST_ME_REALLY_MY_PRINTER_DOES_PCL  might be good.   Paul   -- s"    Paul Anderson, DCPS Engineering"    GENICOM Corporation, Gardner MA   ------------------------------  % Date: Tue, 30 May 2000 17:04:39 +0100e, From: "Adrian Lumsden" <A.Lumsden@xdt.co.uk>$ Subject: Problem with resource locks/ Message-ID: <8h0p7n$uvd$1@newsg1.svr.pol.co.uk>h  D Platform MV3100-80 & VS3100-M38, VMS 6.2, also various Alphas VMS7.1  C I have been developing a distributed application that uses locks toc co-ordinate theYG various components and to distribute small amounts of data out over thed cluster.H I have had problems with certain aspects of what I'm doing which I think I'veG found a workaround to. I'd like to know if this is the "solution" or ise theret something I've missed.  H I have a single process, MP, running on one of the nodes in the cluster, andzF several slave processes, SPn, running on various nodes of the cluster, possiblyH including the one that MP is running on. The SPs can't do anything untilG MP is up and running and acquiring data. The SPs have to be aware if MPuH has died or exited for any reason so they can warn the user applications5 that the distributed data is no longer being updated.c  A I implemented support for this by having a system lock MP_STATUS.aE If MP starts first it creates an EX lock on MP_STATUS and carries on.c  A When the SPs start they attempt  to obtain a CR lock on MP_STATUStE with a blocking AST. If this succeeds then MP does not have EX so can @ be assumed to be inactive. SPs then $hiber(). When MP starts and attemptsB to get EX, the SP blocking AST fires and converts the lock CR->NL.@ This lets MP's EX lock complete to EX. SPs then enqueue a NL->CRG conversion with completion AST. If MP subsequently dies, the completionr@ AST fires and SPs know that MP has gone away and can wait for it to restart.e  F If the SP's initial attempt to obtain CR on MP_STATUS fails, then theyC assume that MP already holds EX and can enqueue a NL->CR conversionh with AST completion as above.n  H My problem was that this worked fine when I had only a single SP waitingC for the MP to start (either on the same cluster member as the MP ornA on a different one). If I had two SPs waiting for MP to start thee initialiH creation of the MP_STATUS lock by MP would get queued  and not complete.  F Both SPs were sitting with the lock at CR blocking the MPs EX request.> However my debugging code showed that the SPs blocking AST hadC fired and that the locks had dropped to NL and then gone back up to2" CR without MP getting the EX lock.  H I finally fixed the problem by having MP initially create the lock at NL2 and then immediately enqueuing a conversion to EX.  D What I figure was happening was that MP would enqueue a new EX lock.D This triggered the blocking ASTs in the two SPs. The ASTs would drop> the lock CR->NL and then $wake(). SP1 would wake and enqueue aB NL->CR conversion. By this time the other SP had also got a NL->CR> conversion into the conversion queue. VMS seems to process allD requests in the conversion queue before looking at the waiting queueA so both of these would complete (since they weren't being blocked @ by anything) and then they would block the completion of the MPs EX request.   B By having MP create the lock at NL first and then enqueue a NL->EXF conversion, MP would get into the conversion queue before the blockingA ASTs triggered and dropped the locks CR->NL. Now when they try to-C go back up to CR, MP is already there in the conversion queue aheadnF of them and that conversion happens first. This then blocks the NL->CRE conversions and they hang around in the conversion queue where I wanti them to be.   E Moral?? Always create your locks as NL first and then manipulate themr with conversions.s  D Is this right? Have I missed something obvious in the way $enq worksE and should be doing it a different way. The moral is not right anywaynA because I had problems with two SPs starting. When one of them isa? already up, its NL->CR queued conversion blocks another SP frome> creating an NL lock and then queuing its own conversion to CR.  F By the way, I have always been using the LCK$M_QUECVT flag. This seemsB to put them at the back of the conversion queue but still ahead of anything in the waiting queue.a  E PS If you need a utility to spy on locks please e-mail me. As soon ast you C start messing with DEBUG you alter all of the timing and everythingp works.   regards,   Adrian   --( Adrian Lumsden, XDT Computer Systems, UK AdotLumsden at xdtdotcodotuk   ------------------------------  # Date: Tue, 30 May 2000 14:23:05 GMTw From: briggs@eisner.decus.orgo3 Subject: Re: RMS handling of extremely long recordsu+ Message-ID: <nHuDk+w9Yps5@eisner.decus.org>h  s In article <8gt13g$d1b$1@s2.feed.news.oleane.net>, "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> writes:t > I'm using OpenVMS Alpha 7.2-1 < > Recently I downloaded a patch from ftp.service.digital.com  > I downloaded the checksum too.: > Then I tried to checksum the downloaded DCX_AXPEXE file," > with a RECORD TOO LONG error ...  H It sounds like you managed to download a file that started with 512 byteD fixed length records and wound up with a Stream format file that has? a stretch of data over 32767 bytes long that happens to have noa record delimiters.  B $ SET FILE xyz.DCX_AXPEXE /ATTR=(RFM:FIX,MRS:512,LRL:512,RAT:NONE)  B RMS doesn't deal well with records longer than 32K bytes.  And theB typical situation in which this restriction is encountered is when? files of arbitrary binary data are treated as if they containedc@ delimited records.  The various STREAM formats are good for text& data but are not good for binary data.  & 	John Briggs			briggs@eisner.decus.org   ------------------------------    Date: 30 May 2000 12:03:05 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> + Subject: Re: RMS tuning versus file cachingEH Message-ID: <y48zwsgxt2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  , David A Froble <davef@tsoft-inc.com> writes:  L > Still seems to me that mapping the file as a global section might give you > better results.   L That is exactly what RMS's global buffers do. For non-sequential files, thatH has the advantage that RMS knows just what parts of the file are best to cache.   	Jan   ------------------------------    Date: 30 May 2000 12:08:38 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>i+ Subject: Re: RMS tuning versus file cachingeH Message-ID: <y466rwgxjt.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " Paul Sture <paul@sture.ch> writes:  F > As long as you are doing sequential reads, it does help there, by a  > considerable margin.  G Having more thatn two or three buffers doesn't usually help unless your N traffic is _very_ bursty - think of the buffers as providing a low-pass filterM (in time) of the demands your application makes on the I/O system, as well as D providing a concurrent I/O thread in addition to the compute thread.  ' > The buffers come from non-paged pool.o  N No they do not - they usually come from P1 space or, via a linker option, from	 P0 space.c   	Jan   ------------------------------  # Date: Tue, 30 May 2000 17:13:40 GMTo- From: "Richard D. Piccard" <piccard@ohio.edu>s+ Subject: Re: RMS tuning versus file caching ( Message-ID: <3933F6BD.88199862@ohio.edu>   David,  F 	Perhaps for the systems used for these dedicated tasks it would make 7 sense to change the SYSTEM RMS_DEFAULT values, such as:y  . $ SET RMS/BLOCK=127/BUFFER=4/SEQUENTIAL/SYSTEM) $ SET RMS/BLOCK=127/BUFFER=4/INDEX/SYSTEMa  H and then tweak for the exceptional case.  I recently got a factor of 60 ? elapsed time speed-up this way in a CONVERT command execution. *  	 						RDP*     David Mathog wrote:- > K > We've gone over the RMS vs. file caching stuff quite a bit, but there arenM > a couple of things that are still unclear to me.  The default RMS counts onl > my system are: >  > $ sho rmscO >           MULTI-  |                MULTIBUFFER COUNTS               | NETWORK>N >           BLOCK   | Indexed  Relative            Sequential         |  BLOCKN >           COUNT   |                     Disk   Magtape  Unit Record |  COUNTL > Process     0     |    0         0        0       0         0       |    0L > System     16     |    0         0        0       0         0       |    8 > 2 >           Prolog    Extend Quantity      VCC_DFW/ > Process     0              0                0i/ > System      0              0                00 > K > And this results in, as far as I can tell, each file write going straights# > to disk.  If the process issues al >  > $ set rms/buffer=100 > J > that will increase write performance (it doesn't seem to do anything forH > read though).  But any use of buffers decreases data integrity, right? > So is this correct?5 > 7 > 1. If the system crashes before the buffer is written) >    then the data vaporizes.a > ; > 2. Once buffering is enabled the last buffer of data onlyp> >    goes to disk once the program closes the file (explicitly >    or on exit.)w > K > That's not quite so insecure as WNT or Unix style file caching (where theaK > data may not get written to disk even on process exit), but its certainly)I > enough to hose software which depends on state data written to files on K > disk. It also means that in terms of data integrity there's not much data)J > integrity advantage for RMS using buffers with a program written naivelyL > (ie, not written to force flushes through the cache at key regions) versusK > running the same thing on Unix and following each program with a "synch".s > H > While VMS doesn't do file caching, there is "SET FILE/GLOBAL" which isH > supposed to let multiple processes share buffers for one file.  (I sayM > "near as I can tell" because I have not yet found a program where I can runaM > two copies and see a difference with this on versus off.)  I couldn't see aiJ > way to force it to leave those buffers around between runs, but maybe itL > would if a dummy program was running that did nothing but leave the accessJ > "open"???  I'm thinking about a case where a large file is read over andE > over again by different programs, and I'd like to avoid the disk IOaF > associated with that.  For a moment I thought that the engineers hadH > actually put in a way to do this, but SET FILE/CACHING only applies toK > Spiralog volumes, and Spiralog was (last time I heard) not a product that0 > is safe to use.z > L > Anyway, by futzing around with the RMS parameters I have been able to makeK > at least one program (TFASTA3, which scans a protein sequentially againsteM > a 9 Mb DNA database file) run as fast on OpenVMS as it does on Linux/Alpha.vF > If I don't change the RMS parameters it runs exactly half as fast onF > OpenVMS.  That sort of fine tuning shows that equivalent performanceI > usually be had, but I sure wish there was a global knob I could turn tooM > make that the default, rather than having to muck around on a file by file,o > process by process basis.  > 
 > Regards, >  > David Mathog > mathog@seqaxp.bio.caltech.edus@ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                                RIP VMS                                 *L > **************************************************************************   -- OB ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------   Date: 30 May 2000 13:00:10 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Setting passwordr6 Message-ID: <8h0e0q$52m$2@mailint03.im.hou.compaq.com>  j In article <wiiY4.3790$N4.129712@ozemail.com.au>, "Antony Wardle" <antony.wardle@nospam.met.co.nz> writes:  D :Is there a utility/easy way of setting my password for NT,VMS,LinuxE :all in one easy go. I can already change my vms password in multiplenI :nodes/clusters in one little command procedure, I just wanted to know if ( :anyone had already invented this wheel.  G   Distributed password authentication and modification, in other words.e  D   Windows NT and OpenVMS can be configured to synchronize passwords E   using a PDC (running on NT or OpenVMS) with OpenVMS V7.1 and later.eG   (Donno about Linux access to the PDC.  Best to ask in a Linux group.)r  C   The next OpenVMS release is expected to have Kerberos V5 support,c0   which can synchronize OpenVMS, W2K, and Linux.  G   The explicit act of synchronizing passwords is pretty easy using any uH   of various network protocols and even home-grown software.  The tough I   part is in the design; in preventing the password mechanism from being l"   used as a massive security hole.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 30 May 2000 10:14:37 -0400 * From: Chuck Chopp <ChuckChopp@rtfmcsi.com>. Subject: UCX v4.2 - Telnet connection timeout?+ Message-ID: <3933CCCC.576FB8FC@rtfmcsi.com>   E Is there a way to configure the telnet service on UCX v4.2 to be more G tolerant of network delays and interruptions?  I'm looking at a problemaF that is being caused by either a flakey router or a flakey frame-relayG circuit that keeps cutting off a remote site from its host system for a*G period of time ranging from 20 seconds to 60 seconds at a time.  Telnet @ sessions keep getting terminated when this happens.  It would beF perfectly acceptable if the telnet session simply hung and retried for@ several minutes before giving up on the host and terminating theH underlying TCP session.  There was nothing in the UCX documentation thatH seemed promising in regards to this issue.  Many years ago I had a largeF VMScluster that was running Multinet; we had similar WAN communicationD problems and we were able to have telnet sessions that would surviveF network outages as long as 5 minutes w/o any disconnections occurring.  F I am also suspsicious of the telnet client itself.  It may be that theC UCX telnet service is willing to keep the telnet session active andeE retry the packet transmissions for some period of time and that it is F the telnet client that is giving up too quickly.  If this is the case,G then I'll need to do some digging in the SmartTerm emulator for furthero@ details about the configurability and features of that software.     TIA,   Chucki -- Chuck Choppo  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com0                                   ICQ # 22321532@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 400 4935 pagerC                                   8004004935@alphapage.airtouch.comp   ------------------------------  % Date: Tue, 30 May 2000 16:20:10 +0100o/ From: "eric chevallier" <chevalli@mpfrance.com>s% Subject: variable and FTP in a scriptu, Message-ID: <8h0fge$k40$1@reader1.fr.uu.net>   Hi,n# i have a script to make this below.aG i use "INQUIRE fichier "command to ask the user the name of the file tom
 transfert.% then i make FTP server login passwordrL i can't use "put 'fichier" because the line can't begining with a $ as it is FTP., have you an idea to pass a varaible to FTP ? thanks in advancen regardsc Eric   ------------------------------  % Date: Tue, 30 May 2000 16:51:52 +03009% From: Gabriel Sterk <gabi@AIPM.CO.IL> ) Subject: Re: variable and FTP in a scripte2 Message-ID: <000201bfca3e$3699dea0$2c46bf10@manai>  H If the VMS version is 7 and up, use 'COPY/FTP' where the variable can be used. L In VMS lower than that, write a command file (OPEN & WRITE in DCL) which can be @'d.    -- Gabriel Sterk   -----Original Message-----4 From: eric chevallier [mailto:chevalli@mpfrance.com]# Sent: Tuesday, May 30, 2000 5:20 PMa To: Info-VAX@Mvb.Saic.Coma% Subject: variable and FTP in a scripta     Hi, # i have a script to make this below.TG i use "INQUIRE fichier "command to ask the user the name of the file to 
 transfert.% then i make FTP server login passwordCL i can't use "put 'fichier" because the line can't begining with a $ as it is FTP., have you an idea to pass a varaible to FTP ? thanks in advance  regardsP Eric   ------------------------------  % Date: Tue, 30 May 2000 16:20:13 +0200l= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>7) Subject: Re: variable and FTP in a scripta) Message-ID: <3933CE1D.F667D3BE@gtech.com>    Gabriel Sterk wrote:J > If the VMS version is 7 and up, use 'COPY/FTP' where the variable can be > used.    6.2 !a   Arne   ------------------------------  % Date: Tue, 30 May 2000 18:19:22 +0100o* From: "chevallier" <chevalli@mpfrance.com>) Subject: Re: variable and FTP in a scriptl, Message-ID: <8h0mft$rru$1@reader1.fr.uu.net>  J i have solved my pb, my script create en other script who is passed to ftp with the command :. FTP serveur /login /password /input=new_script  K eric chevallier a crit dans le message <8h0fge$k40$1@reader1.fr.uu.net>...h >Hi,$ >i have a script to make this below.H >i use "INQUIRE fichier "command to ask the user the name of the file to >transfert.o& >then i make FTP server login passwordJ >i can't use "put 'fichier" because the line can't begining with a $ as it is >FTP. - >have you an idea to pass a varaible to FTP ?S >thanks in advance >regards >Eric  >k >  >S >U   ------------------------------   Date: 30 May 2000 15:33:22 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: Re: variable and FTP in a scriptt6 Message-ID: <8h0n02$8lb$1@mailint03.im.hou.compaq.com>  ^ In article <8h0fge$k40$1@reader1.fr.uu.net>, "eric chevallier" <chevalli@mpfrance.com> writes:$ :i have a script to make this below.H :i use "INQUIRE fichier "command to ask the user the name of the file to :transfert.f  E   I would encourage the use of READ, rather than INQUIRE.  The formeruC   does what you expect, while the latter also has some rather more hE   magical (though fully documented) capabilities, and thus the use of 1   the latter command should generally be avoided.   & :then i make FTP server login passwordM :i can't use "put 'fichier" because the line can't begining with a $ as it ist :FTP.r  A   Ayup, DCL symbol substitution only works when processed by DCL..  - :have you an idea to pass a varaible to FTP ?c  B   You could write a file from DCL and then invoke it, or you couldC   use COPY/FTP if the system is running OpenVMS V6.2 or later and aeD   compliant IP package.  (You don't mention the OpenVMS version nor B   the IP product and version, and this omission can (does) make itE   rather more difficult to tailor the answer(s) to your environment.)n  E   Also please see "SOFT10. Why doesn't DCL symbol substitution work?" F   in the OpenVMS FAQ.  It specifically covers this topic.  The OpenVMS?   FAQ is available via a link at http://www.openvms.compaq.com/   N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 30 May 2000 11:26:28 GMTe) From: "Neil Rieck" <n.rieck@sympatico.ca>t6 Subject: Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias8 Message-ID: <EzNY4.9606$WV.531182@news20.bellglobal.com>   John,P( I think you may be on to something here.  L First off, if I execute ANA/DISK on the suspect source disk (which backed up> just fine under VMS 6.2 by the way), no problems are reported.  K However, if I do a BACKUP/IMAGE on this same disk and then execute ANA/DISKR? on the target disk, many errors are reported. If I then executeIK ANA/DISK/REPAIR on the target disk, then all my missing files are now found L in [SYS$LOST}. At this point I could probably rename the [SYSLOST] tree back? to VMS$COMMON and try a boot of the target (after first runningt WRITEBOOT.EXE of course).t  F (BTW - this means that BACKUP/IMAGE was working all along but that the+ proper directory entries have been skipped)b  G I think I'll start by first comparing the directory structure of my VAXsL system disk (which had been progressively upgraded from VMS 5.4) to my Alpha: system disk (which contains a new VMS 7.2-1 installation).  
 Neil Rieck* Kitchener(New Berlin?)/Waterloo/Cambridge, Ontario, Canada.! http://www3.sympatico.ca/n.rieck/A    4 John Santos <jasantos@ultranet.com> wrote in message7 news:MPG.139bed3c558e3774989779@news.ma.ultranet.com...n? > In article <MPG.139be0264aeef6d5989778@news.ma.ultranet.com>,x > jasantos@ultranet.com says...- >-B > Sorry to follow up my own post, but I'm not sure if the next two= > paragraphs make much sense with out some info I left out...d > J > > I'm not sure if ANALYZE/DISK will consider this an error.  I think theG > > original problem (from VMS V5 days) was that the disk structure was0G > > valid, but not what VMS upgrades assumed, so ANALYZE/DISK was happy G > > with it.  In your case, it might be that VMS$COMMON.DIR's header is L > > pointing to a non-existent or deleted directory, or at least a directoryL > > that doesn't have a filename pointing to VMS$COMMON.DIR.  If this is the, > > case, I think ANA/DISK should detect it. > >hC > > BTW, if this ground hasn't been covered already in this thread:nK > > All that is in a VMS directory is a list of filenames and correspondingAE > > file IDs.  The file IDs are basically pointers to file headers incK > > [0,0]indexf.sys.  All the other info about the file (attributes, dates,tJ > > ownership, protection, retreival pointers, etc.) is in the file headerJ > > in indexf.sys.  There is no reason why the same file ID can't exist inJ > > more then one directory, or more than once in the same directory underK > > different names.  These are aliases.  Or the file ID (and thus the file+L > > header might not be pointed to by any directory at all, in which case it > > is a "lost" file.n > >sE > Among the info in the file header are the file name and the file IDrD > of the directory listing the file.  If that directory contains theH > given file name with the correct file ID of the header, that directoryG > entry is considered the "non-alias" entry for the file, and any otheroI > directories listing it are considered aliases.  This name and directoryrH > ID are what I meant by "VMS$COMMON.DIR's header is pointing to ..." in > the 1st paragraph above. >8 > --
 > John Santosb   ------------------------------  % Date: Tue, 30 May 2000 11:20:49 +0200S= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>o5 Subject: Re: ver 7.1 Openvms will run on the new Ds20a) Message-ID: <393387F1.D07589B0@gtech.com>e   Horse Nuts wrote:d/ > Will ver 7.1 Openvms will run on the new Ds20i= > we have received. There may be a minimum limit and if so wel= > need to know the version. If the version needs upgrading it * > may affect other software running there.  8 I think the minimum version is 7.1-2 but the recommended version is 7.2-1 !   Arne   ------------------------------   Date: 30 May 2000 13:43:26 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)5 Subject: Re: ver 7.1 Openvms will run on the new Ds20 6 Message-ID: <8h0ghu$6gm$1@mailint03.im.hou.compaq.com>  S In article <3932a412.21124916@news.dal.ca>, hx_101@hotmail.com (Horse Nuts) writes:u@ :Will ver 7.1 Openvms will run on the new Ds20 we have received.  F   V7.1 is not supported on this box.  V7.1-2 (with ECOs) is supported.  D :There may be a minimum limit and if so we need to know the version.  E   For the minimum OpenVMS versions for the various platforms, please MG   see section VMS13 in the OpenVMS FAQ.  (There exists a web page with cD   all of the OpenVMS minimum version information posted, and the FAQ   has a pointer to it.)t  B   The OpenVMS FAQ is accessable via http://www.openvms.compaq.com/  E :If the version needs upgrading it may affect other software running   :there.   C   V7.1-2 should be indistinguishable from V7.1 from the perspective:E   of application software -- I am aware of only one package that doesUF   not upgrade in all cases, and this was the result of an explicit andF   deliberate check that was added into certain versions of Oracle Rdb #   to look for this OpenVMS version.    	--   4   Some useful Rules of Thumb for processor support:   "     Alpha System   OpenVMS Minimum      Processor      Version Req'd"     ------------   ---------------  '     EV6/21264      OpenVMS Alpha V7.1-2D$     EV67/21264A    (V7.2-1 prefered)    -     EV56/21164A    OpenVMS Alpha V6.2-1H3, or ,                    V7.1 or later.  NOT V7.0..                    (V7.1-2 or V7.2-1 prefered)    7   There are relevent ECO kits around for these systems.r  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 30 May 2000 09:45:28 +0100 B From: Andrew Harrison SUNUK Consultancy <andrew.nospam@uk.sun.com>" Subject: Re: Wildfire Announcement* Message-ID: <39337FA6.BC80CF43@uk.sun.com>  ! steven.reece@quintiles.com wrote:i   > You tell him Terry.i3 > Oh, but I forgot.  Andrew doesn't listen does he?rI > And VMS is dead and Compaq are just a PeeCee company.  Dream on Andrew.e >i  ? Neither of which I have ever said. The  fact is there are a lot 9 of people on this alias with a vested interest in OpenVMSn6 surviving who seem to take the view that you attribute. to me namely that OpenVMS is dead or dying and0 Compaq is just a PeeCee Company who don't give a damn about OpenVMS.s  : I don't, I simply question what Compaq are doing to ensure8 that they don't ultimately lose OpenVMS/Tru64 and become a PC company by default.  9 Gallingly for those people who simply dismiss my posts ase8 FUD the simple facts are that over a period of 18 months5 my posts have been shown with hindsight to be largely < correct with respect to Compaqs/Digitals handling of OpenVMS$ and the state of the OpenVMS market.  2 OpenVMS boosters who no doubt you agree with wholeE heartedly in general proven with hindsight to have been spectacularlyc wrong.  A Alpha hasn't eaten Intel's lunch or anyone elses, one prediction.a  ? ISV's havn't shown any interest in Galaxies, another predictioni> in fact the opposite is true the number of commercial software6 vendors supporting OpenVMS/Tru64/NT/Alpha has steadily	 declined.C  @ NT on Alpha is not going to trash NT on Intel nor is it going to< reinvigorate the Alpha market. In fact Compaq dropped it not/ long after this particular prediction was made.a  6 Compaq have not given OpenVMS the shot in the arm that@ people expected/hoped for and have treated it no better or worse  than Digital did in the Bob era.  5 Alphaservers have not had Sun's lunch or anyone elsese lunch.  3 eBay has not moved from Sun to OpenVMS or any othern: OS and has recently announced a further comitment to using Sun's to host their site.   5 I have never said that OpenVMS is dead, I have simplyr4 questioned the amount of resource being allocated to9 keeping it alive and one good example of this is the lacka5 of collateral Compaq had to justify their performancee leadership claims at launch.     Regardsl Andrew Harrison* Enterprise IT Architect*   ------------------------------  % Date: Tue, 30 May 2000 10:14:44 +0100RB From: Andrew Harrison SUNUK Consultancy <andrew.nospam@uk.sun.com>" Subject: Re: Wildfire Announcement* Message-ID: <39338684.EA66505B@uk.sun.com>   jlsue wrote:  G > On Tue, 23 May 2000 10:05:19 +0100, Andrew Harrison SUNUK Consultancye# > <andrew.nospam@uk.sun.com> wrote:e >  > > 8 > >Who cares how many CPU's Fujitsu used to get a better; > >number than Compaq for 2 tier SAP. I bet that many CTO's-; > >of major corporates would be very pushed to tell you howr7 > >many CPU's their S390's or E10K's have in them, they:E > >don't care. The fact is Fujitsu can sustain a higher SD throughputa> > >than a GS320 and provided the price is right and they don't4 > >cost more to own then nobody cares how many CPU's > >there are in the box. >yH > Now you're really losing credibility Andrew.  I can't count the numberH > of times you've railed against VMSclusters of systems providing betterG > performance at the same cost of a single Sun system.  If the standardiC > is price/performance, which you seem to say here, then almost anynB > configuration would be comparative in this, INCLUDING VMScluster
 > systems. >d  D No, no, no non, niet. This is not the same thing at all. The Fujitsu9 box and the GS320 ran the same version of SAP and the the < same Oracle DBMS. The fact that the Fujitsu box had 64 CPU's; and the GS320 made no difference to how the SAP applicationW; was implimented and how it would be managed in a productiond5 environment because they are both single SMP servers.o  : Your point about OpenVMS clusters is simply a red herring,6 even assuming SAP R3 ran on OpenVMS which it does not,@ because running it on any kind of cluster, be it a Sun one or an? OpenVMS one is entirely different to running it on a single SMP 3 system. The DBMS licences cost more, the DBA's needl; additional training courses and thats before you get to the,< little detail which is that SAP don't actually support their/ apps running on a parallel database with a DLM.   ; The fact is it does not matter how many CPU's Fujitsu used.e@ Trying to defend Compaq for not including the Fujitsu SAP result@ on the basis that the Fujitsu box was faster but used more CPU'sH is a bankrupt argument. You are trying to defend a piece of indefensible
 marketing BS.h     Regardsi Andrew Harrisoni Enterprise IT Architecto   ------------------------------  % Date: Tue, 30 May 2000 11:19:53 +0200e= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>l' Subject: Re: [DOCUMENTATION]: Help me ?s) Message-ID: <393387B8.B8185345@gtech.com>    Vecchiato Michele wrote:  > Is there somebody can help me?G > I 'm looking for free OpenVMS 7.1 manual ( for Student or Similar) inm > the PDF  file.   VMS manuals cost money.y   But try look at:+   http://www.levitte.org/~ava/vms_doc.htmlxh+   http://www.levitte.org/~ava/vms_faq.htmlx    Arne   ------------------------------   Date: 30 May 2000 13:27:48 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)' Subject: Re: [DOCUMENTATION]: Help me ?t6 Message-ID: <8h0fkk$643$1@mailint03.im.hou.compaq.com>  ^ In article <39329990.919AAB3C@mail.tim.it>, Vecchiato Michele <mvecchiato@mail.tim.it> writes:F :I 'm looking for free OpenVMS 7.1 manual ( for Student or Similar) in :the PDF  file.   A   Please see the OpenVMS FAQ, via http://www.openvms.compaq.com/.eB   I would encourage you to look specifically at the information onA   the OpenVMS hobbyist program, as well as at the pointers to the    on-line documentation.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 30 May 2000 16:28:07 +0930 A From: "Geoff Roberts" <geoffrobx@stmarksx.ppx.catholicx.edux.aux>-/ Subject: Re: [humor] UNIX/OpenVMS email "virus"01 Message-ID: <8EJY4.4643$N4.168298@ozemail.com.au>l  @ "Christopher Smith" <chriss@Mufasa.pubserv.com> wrote in messageD news:Pine.LNX.4.05.10005241508190.15858-100000@Mufasa.pubserv.com..., > On Tue, 23 May 2000, David A Froble wrote: >kH > > Darn, I only got 13 VMS systems.  Now I feel left out.  Wait, I have	 6 more atrD > > another site!  How's 19 sound? Anybody else got a better number? >i@ > No, but add mine to the whole count.  I've got four VAXen.  MyB > significant-other has one -- given to her as a present actually. Those3 > are fine.: >5F > I know of one at a university (yes, really), and have a friend who's gotT5 > at least four going -- well, three vaxen and an alpb  F Got a 6000-440 and a VS4000-90 cluster here at a K-Yr12 school, the 6KA is the schools Web/Proxy/FTP/Mail/POP3 server, and is as close to(C unbreakable as it gets, which is why it's still here.  Plus severalO< VS3100's, a UvaxII, a Uvax 3400 and a 6000-430 at home......E I know of Vaxen and Alphas in use at at least one major university ini Melbourne..c Listening Huw? :^)n   Cheers  
 Geoff Robertse Computer Systems Manager Saint Mark's College Port Pirie,n South Australia 6 geoffrob at stmarks dot pp dot catholic dot edu dot au ICQ: 1970476   ------------------------------   End of INFO-VAX 2000.301 ************************, have you an idea to pass a varaible to FTP ? thanks in 