1 INFO-VAX	Sun, 20 May 2001	Volume 2001 : Issue 277       Contents:% cancel <9e5ibh$c6t$1@news.netmar.com> $ Re: DEC-Keyboards to not-DEC systems$ Re: DEC-Keyboards to not-DEC systems$ Re: DEC-Keyboards to not-DEC systems Re: Mozilla 0.9  Re: Mozilla 0.9  Re: OT: UPS monitoring software " Re: POSIX threads and word tearing" Re: POSIX threads and word tearing" Re: POSIX threads and word tearing" Re: POSIX threads and word tearing/ Re: The Internet, Tru64 and other unix variants / Re: The Internet, Tru64 and other unix variants  Re: vfork/exec question  Re: vfork/exec question  Re: vfork/exec question  Re: VMS doc site master index  Re: VMS doc site master index   F ----------------------------------------------------------------------  % Date: Sat, 19 May 2001 22:51:47 +0200 3 From: Didier Morandi <Didier.Morandi@gmx.ch.nospam> . Subject: cancel <9e5ibh$c6t$1@news.netmar.com>( Message-ID: <3b06dcda_4@news.bluewin.ch>  / This message was cancelled from within Mozilla.    ------------------------------  # Date: Sat, 19 May 2001 20:17:51 GMT $ From: Wolfgang Rupp <rupp@chello.at>- Subject: Re: DEC-Keyboards to not-DEC systems 4 Message-ID: <PxAN6.104205$2q.3724150@news.chello.at>  * Christof Brass <brass@infopuls.com> wrote:? > 2.I loved most the old keyboards with a function key block on > > the left side and programs where I haven't to use the mouse.? I had one of those pre-MFII keyboards for a long time. Finally, > a coke in the key springs (yes, one real spring per key) glued the dust to so much goo.  9 > Since these keyboards aren't available anymore and it's 8 > impossible to attache them to Alphas I got used to theB > "standard" DEC keyboard. What bothers me is that I can't plug it > into a SUN or Peesee? ; I don't know about Windows, but an LK411 works just fine on ; a Linux PC. What I could _not_ yet find is a mapping to use 1 the extra keys. LK411 speak normal PS/2 protocol.   
 Wolfgang Rupp    ------------------------------  % Date: Sun, 20 May 2001 00:18:12 +0200 ) From: Christof Brass <brass@infopuls.com> - Subject: Re: DEC-Keyboards to not-DEC systems , Message-ID: <3B06F124.12FB0442@infopuls.com>   Wolfgang Rupp wrote: > , > Christof Brass <brass@infopuls.com> wrote:A > > 2.I loved most the old keyboards with a function key block on @ > > the left side and programs where I haven't to use the mouse.A > I had one of those pre-MFII keyboards for a long time. Finally, @ > a coke in the key springs (yes, one real spring per key) glued > the dust to so much goo. > ; > > Since these keyboards aren't available anymore and it's : > > impossible to attache them to Alphas I got used to theD > > "standard" DEC keyboard. What bothers me is that I can't plug it > > into a SUN or Peesee? = > I don't know about Windows, but an LK411 works just fine on = > a Linux PC. What I could _not_ yet find is a mapping to use 3 > the extra keys. LK411 speak normal PS/2 protocol.  >  > Wolfgang Rupp   : If the LK411 is a standard DEC keyboard that would be fine9 because the Peesees I have to use don't run Micro$hit SW. 0 The extra keys like "Do", "Help" and "F17..F20"?   ------------------------------   Date: 19 May 2001 21:39:44 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann) - Subject: Re: DEC-Keyboards to not-DEC systems 0 Message-ID: <9e6p70$oja$1@n.ruf.uni-freiburg.de>  X In article <3B062EB1.3EFDF792@infopuls.com>, Christof Brass <brass@infopuls.com> writes:6 >1.Does anybody know of a URL with the keyboard types,; >descriptions and pictures/layouts? Not only DEC preferred?   
 Me not :-(  > >2.I loved most the old keyboards with a function key block on= >the left side and programs where I haven't to use the mouse. 8 >Since these keyboards aren't available anymore and it's7 >impossible to attache them to Alphas I got used to the A >"standard" DEC keyboard. What bothers me is that I can't plug it ? >into a SUN or Peesee? Is it possible to do that? If so I would @ >carry that keyboard with me and use it at the customers' sites.  J The only way I know (and I actually use it myself) is to use a KVM switch.E I have a ServeView+ from Rose Electronics (http://www.rosel.com/) and E a Digital LKxxx attached to it (20 function keys). So I have only one B monitor, mouse and keyboard to control PCs, Alphas, Macs and Suns.   Regards,    Christoph Gartmann   H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  % Date: Sat, 19 May 2001 23:45:53 +0100 % From: Alan Greig <a.greig@virgin.net>  Subject: Re: Mozilla 0.9* Message-ID: <3B06F7A1.E192DB89@virgin.net>  & "Brian Schenkenberger, VAXman-" wrote:   >  > > G > >You can't get any of it to work so why does Compaq bother to make it / > >available to waste bandwidth downloading it?  > >  > >--   s Obviously it is annoying when it just plain doesn't work for you but I guess the reason they "make it available" is r because it works reasonably well for most of us. It isn't a waste of bandwidth. Can't you work with Colin Blake tot figure out the difference between your setup and theirs? Apologies for suggesting the obvious if you've tried and nom success but *all* we see here is you throwing bricks. And complaining loudly about bugs in alpha test quality  software is a bit pointless.   > R > >VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM > > R > >city, n., 1. a place where trees are cut down and streets are named after them. > P > Just for shits and giggles, I ran Mozilla from the console with display set to > the graphics display local.  >  > $ @MOZILLA > Starting mozilla-bin... 1 > Registering plugin 0 for : "*","All types",",*" M > Gdk-ERROR **: Fatal IO error 65535 (connection aborted) on X server _WSA6:. 7 > %CXXL-F-TERMINATE, terminate() or unexpected() called 1 > %TRACE-F-TRACEBACK, symbolic stack dump follows  >   image    module  >   s I know this might sound daft but, in the absence of other suggestions, have you tried looking at reducing quotas to h the minimum recommended for Mozilla? I have a vague recollection of problems with an X application dyingC mysteriously when run under an account with extremely large quotas.        >  > Then nothing...  >  > --Q > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM  > Q > city, n., 1. a place where trees are cut down and streets are named after them.    --
 Alan Greig   ------------------------------  # Date: Sun, 20 May 2001 01:52:31 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)  Subject: Re: Mozilla 0.90 Message-ID: <009FC436.77E30540@SendSpamHere.ORG>  R In article <3B06F7A1.E192DB89@virgin.net>, Alan Greig <a.greig@virgin.net> writes: >  > ' >"Brian Schenkenberger, VAXman-" wrote:  >  >> >> >H >> >You can't get any of it to work so why does Compaq bother to make it0 >> >available to waste bandwidth downloading it? >> > >> >-- > t >Obviously it is annoying when it just plain doesn't work for you but I guess the reason they "make it available" iss >because it works reasonably well for most of us. It isn't a waste of bandwidth. Can't you work with Colin Blake to u >figure out the difference between your setup and theirs? Apologies for suggesting the obvious if you've tried and no 6 >success but *all* we see here is you throwing bricks.  K Obviously then, since my problem hasn't piqued anybody's interest, I should % just go bugger off by your standards?    M It seems obvious that he reads this newsgroup.  He's posted numerous messages J about Mozilla and he's posted follow-ups to Mozilla threads, except mine.   L I am still waiting to get a Netscape 3.03 that doesn't trash the fonts on myL X server.  I am relaying my experiences in the hope that someday I might seeM a usable browser on VMS.  Unfortunately, I don't know what else I can provide L to help solve the problem.  The DECW$SERVER_0_ERROR.LOG has nothing in it ofM consequence after the server dies.  The last posting shows that I cannot even  get a symbolic traceback.   I The machine is an AlphaStation 200 4/233 running V7.2-1 and TCP/IP V5.0A. J It's got 384MB of memory and ZXLp-E3 graphics.  It also barfs with ZXLp-E1 graphics installed.     9 > And complaining loudly about bugs in alpha test quality  >software is a bit pointless.   3 Been absorbed in to the Micro$oft mindset have you?    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------  # Date: Sun, 20 May 2001 01:34:58 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) ( Subject: Re: OT: UPS monitoring software0 Message-ID: <009FC434.04275752@SendSpamHere.ORG>  n In article <6LwswLvXIEka@tachxxsoftxxconsult>, wayne@tachysoft.xxx.310887.killspam.0162 (Wayne Sewell) writes: {...snip...}N >> getting an update for the Alphas.  It *appears* that APC doesn't support it? >> anymore.  All the references I found were 3 or 4 years old.   > M >Even when they did, the price was jacked way up for the vms version.  But of / >course *that's* never happened before, has it?   K ... and the PowerChute for VMS was little more than a simple signal watcher L too.  It's nothing at all like the software of the same name for other plat-K forms and you pay a premium for it.  When I spoke to the folks at APC, they K said that they needed to charge more because VMS was so dificult to program K for and not as robust as other platforms they support!  One of the many too   many reasons I created UPShot.     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------  % Date: Sat, 19 May 2001 16:53:14 -0400   From: Dima Volodin <dvv@dvv.org>+ Subject: Re: POSIX threads and word tearing ' Message-ID: <3B06DD3A.BA9DE244@dvv.org>    Bill Todd wrote: > . > "Dima Volodin" <dvv@dvv.ru> wrote in message2 > news:3b093aca.72339003@news-server.cox.rr.com...= > > In message <3B052236.11C72762@web.de>, Alexander Terekhov  > <terekhov@web.de> 
 > > wrote: > > 
 > > >POSIX > > > 9 > > >"Applications shall ensure that access to any memory 2 > >                                            ^^^: > > > location by more than one thread of control (threads8 > > > or processes) is restricted such that no thread of8 > > > control can read or modify a memory location while9 > > > another thread of control may be modifying it. Such ; > > > access is restricted using functions that synchronize 7 > > > thread execution and also synchronize memory with   > > > respect to other threads." > > L > > Which is to say the standard doesn't make any exceptions about what kind > ofM > > memory location is protected by a mutex and, as worded, an implementation  > shall J > > make it safe to access "any memory location" of any alignment provided > thatD > > either the accessed object is not modified by other threads or a > particularN > > mutex is used to guard the access to the object. Also, if an object is notN > > accessed from other threads, it should be safe to access it even though itN > > shares a word of memory with objects that are accessed from other threads. > N > Well, the other way to interpret the statement is that 'access to any memoryL > location' refers to the entire entity (e.g., a full machine word) accessedJ > by the processor (i.e., outside the context of any cache that deals withL > inter-processor coherence), rather than only to that portion of the entityN > referred to in the source code (e.g., an individual byte).  In which case itB > is simply stating that applications are responsible for avoidingD > word-tearing.  After all, it is the processor (not the source-codeL > statement) that is actually performing the access, and if the access is inK > fact coarser than the source code might suggest, then the above statement J > simply makes applications responsible for understanding and allowing for > this.   L Exactly how can an application be responsible for avoiding word tearing whenN there's simply no such thing as a "full machine word" in the standard (unless,O of course, I missed something)? And who said that the "entire entity" is a word % and not any other addressable entity?    > - bill   Dima   ------------------------------  % Date: Sat, 19 May 2001 20:23:26 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> + Subject: Re: POSIX threads and word tearing ( Message-ID: <9e72md$h5m$1@pyrite.mv.net>  - "Dima Volodin" <dvv@dvv.org> wrote in message ! news:3B06DD3A.BA9DE244@dvv.org...    ...   I > Exactly how can an application be responsible for avoiding word tearing  whenG > there's simply no such thing as a "full machine word" in the standard  (unless,L > of course, I missed something)? And who said that the "entire entity" is a word' > and not any other addressable entity?   K My interpretation of the wording is that the application is responsible for I understanding the architecture on which it is running such that it avoids K operations that would not adhere to the standard's requirements.  I.e., the H standard doesn't presume to dictate how the hardware should work (a wiseK decision, since most hardware would simply tell it to take a flying leap if H it did), but does require (in fact, for this type of situation it prettyE much *has to* require) that the application adapt its behavior to the B hardware in cases like this where the hardware does in fact make a difference.   E If you think that's not pretty, come up with a better alternative and " suggest it to the standards group.   - bill   > 
 > > - bill >  > Dima   ------------------------------    Date: 20 May 2001 12:23:43 +0800, From: Paul Repacholi <prep@prep.synonet.com>+ Subject: Re: POSIX threads and word tearing - Message-ID: <87heygfy28.fsf@prep.synonet.com>   " Dima Volodin <dvv@dvv.org> writes:  A > Exactly how can an application be responsible for avoiding word D > tearing when there's simply no such thing as a "full machine word"B > in the standard (unless, of course, I missed something)? And who; > said that the "entire entity" is a word and not any other  > addressable entity?   
 1) USe Bliss. A 2) Use C and aligns on everything. How you do this with a dynamic & allocation, I'll leave to the C fans..> 3) Use some silly old language that has defined semantics with respect to the implementation.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.H Spam-To: uce@ftc.gov,enforcement@sec.gov,sness@fcc.gov,hfurchtg@fcc.gov,#   mpowell@fcc.gov,gtristan@fcc.gov     ------------------------------   Date: 20 May 2001 06:59:21 GMT- From: djweath@attglobal.net (Dave Weatherall) + Subject: Re: POSIX threads and word tearing 5 Message-ID: <DTiotGxQ0bj6-pn2-JlUfJXlgsXMZ@localhost>   F On Sat, 19 May 2001 02:32:46, "Bill Todd" <billtodd@foo.mv.com> wrote:   > . > "Dima Volodin" <dvv@dvv.ru> wrote in message2 > news:3b093aca.72339003@news-server.cox.rr.com...= > > In message <3B052236.11C72762@web.de>, Alexander Terekhov  > <terekhov@web.de> 
 > > wrote: > > 
 > > >POSIX > > > 9 > > >"Applications shall ensure that access to any memory    . SNIP  J > simply makes applications responsible for understanding and allowing for > this.   A Exactly. The programmer is responsible for managing asynchronous  > access to data items. Posix, or DecThreads, provide the tools F (mutexes) to perform the management. However, there are indeed dangers@ lurking in the Alpha's multiple word/read/write manipulation of B memory. Normally, though it is the WRITE access which needs to be B managed rather than the read, so even if the compiler does clever A things then, under normal circumstances, there should be no real u	 problems.    -- t Cheers - Dave.   ------------------------------   Date: 19 May 2001 20:54:22 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)8 Subject: Re: The Internet, Tru64 and other unix variants, Message-ID: <9e6mhu$415@gap.cco.caltech.edu>  ] In article <3B0541CD.17B93E27@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:e >Bill Todd wrote: L >> Which is exactly what file system expansion does when used in conjunctionH >> with a logical volume manager (or hardware RAID device) that allows a@ >> logical volume to be expanded on the fly by adding new disks. >>   > C >Which is what I was refering to. All the LVM's that we support on -@ >Solaris allow you to add a new piece of storage to an existing A >volume and then both major filesystems also allow you to expand c	 >into it.9  J Right.  And what _we're_ saying is that you've been able to do this on VMSK forever.  Except that you don't expand a file system on VMS, you just mount-C the whole disk and maybe bind it into a volume set.  If you want tohD restrict usage to part of the disk you use disk quotas.  VMS doesn'tK partition disks and honestly I've never seen any reason to do so on this OSmG - it's a Unix/ Windows thing with no utility on VMS.  Well, it might be K useful if you wanted a dual boot system with one disk, but disks are now sofK cheap it's easier just to put in another drive.  And it was never necessarygH for things like "swap" which used to need (and usually still have) their own disk partitions on Unix. b   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech o   ------------------------------  % Date: Sat, 19 May 2001 20:45:28 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>o8 Subject: Re: The Internet, Tru64 and other unix variants( Message-ID: <9e73vn$hr5$1@pyrite.mv.net>  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message-& news:9e6mhu$415@gap.cco.caltech.edu...< > In article <3B0541CD.17B93E27@uk.sun.com>, andrew harrison" <andrew.nospam@uk.sun.com> writes: > >Bill Todd wrote:2B > >> Which is exactly what file system expansion does when used in conjunctionsJ > >> with a logical volume manager (or hardware RAID device) that allows aB > >> logical volume to be expanded on the fly by adding new disks. > >> > > D > >Which is what I was refering to. All the LVM's that we support onA > >Solaris allow you to add a new piece of storage to an existingtB > >volume and then both major filesystems also allow you to expand > >into it.  > L > Right.  And what _we're_ saying is that you've been able to do this on VMSG > forever.  Except that you don't expand a file system on VMS, you just  mounto5 > the whole disk and maybe bind it into a volume set.   J Which is often far from the same thing:  adding another disk (with its ownG filesystem) to a VMS system is a lot more like adding another disk (andLH associated filesystem) to a Unix system, which is a lot less transparentG than *growing* an *existing* Unix filesystem such that it just has moredH space to use wherever in the existing directory structure may be useful.  K Even adding a volume to a concatenated VMS volume set is less flexible thanKL being able to add a volume to an LVM-managed or hardware RAID and extend theE file system to include the new space (and take advantage of the addediJ performance of the additional spindle, distributed throughout the existingL data as well as the new data).  I don't know that VMS hasn't added this kindK of support in the past few years, but it certainly hasn't had it 'forever'.i     If you want to9 > restrict usage to part of the disk you use disk quotas.'  K Not if you want to be able to reserve the space for potential use *outside*tH the existing filesystem.  I'll agree that hard partitions are a somewhatK kludgey way to do this (having multiple filesystems share the space withoutaL hard boundaries, as they do in a OSF DCE DFS 'aggregate', is more flexible),E but there are virtues in being able to use a single disk for multipleiK purposes (multiple filesystems and/or 'raw' partitions being two examples).h   - bill   ------------------------------   Date: 19 May 2001 21:01:59 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)  Subject: Re: vfork/exec question, Message-ID: <9e6n07$415@gap.cco.caltech.edu>  X In article <9e47rj$ijn@dispatch.concentric.net>, "Paul Dembry" <pade@trifox.com> writes:I >I am modifying our old server architecture to use vfork/exec to start up J >proxy servers.  The old method was that the listener became the proxy butK >just before it did that, it did a $CREPRC of a new listener.  Crude but it-D >worked ok for many years.  Now that our servers get many connectionM >requests/second, this is no longer acceptable because the $creprc turnaround K >time is too slow.  I modified this to be like our Unix version where thereF2 >is only one listener who just forks/execs proxys.  J But fork is a fast operation on Unix.  Process creation on VMS is slow (at? least until DII/COE anyway).  Do you really see any performancenG improvement over CREPRC? You'd likely do better to pre-create a pool of'J processes and shuffle jobs among them, obviating the need for the constantJ process creation.  I think that's what the OSU server does for speed, for 	 instance.w   > This all works greatL >except for one tiny flaw.  If the parent process dies (the one that did the/ >vfork/execs), all the vfork'd processes die.  l  I That's what you'd expect for subprocesses, which is what you're creating.p   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech A   ------------------------------  % Date: Sat, 19 May 2001 17:37:16 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r  Subject: Re: vfork/exec question' Message-ID: <3B06F59C.227566DB@fsi.net>h   David Mathog wrote:l > Z > In article <9e47rj$ijn@dispatch.concentric.net>, "Paul Dembry" <pade@trifox.com> writes:K > >I am modifying our old server architecture to use vfork/exec to start upWL > >proxy servers.  The old method was that the listener became the proxy butM > >just before it did that, it did a $CREPRC of a new listener.  Crude but it F > >worked ok for many years.  Now that our servers get many connectionO > >requests/second, this is no longer acceptable because the $creprc turnaroundaM > >time is too slow.  I modified this to be like our Unix version where there 4 > >is only one listener who just forks/execs proxys. > I > But fork is a fast operation on Unix.  Process creation on VMS is slow A  > That's what I keep reading/hearing; however, in my experience,   $ SPAWN commandd  . ...is not appreciably "slow"-er than simply...  	 $ command-  = ...with respect to the command actually beginning to execute.   H Maybe I've just become jaded from using fast Alphas and learning to live without PIPEs...   -- D David J. Dachtera0 dba DJE Systems> http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.s   ------------------------------   Date: 19 May 2001 23:44:19 GMT% From: "Paul Dembry" <pade@trifox.com>i  Subject: Re: vfork/exec question0 Message-ID: <9e70gj$in5@dispatch.concentric.net>  L > But fork is a fast operation on Unix.  Process creation on VMS is slow (atA > least until DII/COE anyway).  Do you really see any performancehI > improvement over CREPRC? You'd likely do better to pre-create a pool ofuE Definitely.  I created a client program that looped making connectioneH attempts.  I then started up 5 of these, each attempting 20 connections.J With the CREPRC method, I could connect perhaps 9 times out of 100 whereasC with the vfork() method, I connected 100 times out of 100 attempts.i  K I will ask our clients if they think the parent/subprocess death problem is.G in fact a problem.  There should be no reason for the parent process to K disappear so perhaps this is not a big issue.  Thank you all for answering!  Paul   ------------------------------  % Date: Sat, 19 May 2001 23:04:45 +0200e3 From: Didier Morandi <Didier.Morandi@gmx.ch.nospam>n& Subject: Re: VMS doc site master index& Message-ID: <3B06DFEE.54F48204@gmx.ch>   James Gessling wrote:1 > H > So  who was the genius that decided the VMS master index should be pdfL > format and not also html like most everything else?  It would be MUCH more > usefulA > to have it indexed similar to the indexes in the other manuals.  >  > Jimt  G The pdf file is not protected, character search is allowed and text andw images cut/paste too.    What do you want more?   (just curious) D.   ------------------------------  % Date: Sat, 19 May 2001 17:32:18 -0500n1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n& Subject: Re: VMS doc site master index' Message-ID: <3B06F472.7ED2D95D@fsi.net><   Didier Morandi wrote:c >  > James Gessling wrote:3 > >.J > > So  who was the genius that decided the VMS master index should be pdfN > > format and not also html like most everything else?  It would be MUCH more
 > > usefulC > > to have it indexed similar to the indexes in the other manuals.j > >  > > Jimr > I > The pdf file is not protected, character search is allowed and text and  > images cut/paste too.r >  > What do you want more? >  > (just curious) > D.  D I think his point was that instead only needing to have your browserF open, now ya gotta have (AcrobatReader, xpdf, ???, etc.) open as well.  ? Got RAM? (Parody of an American ad campaign being run on TV anduC billboards and in print by the dairy industry: "Got milk?", usually!= accompanied by a picture of a person with a "milk mustache".)   - I agree: HTML *WOULD* have been better, IMHO.1   -- X David J. DachteraO dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/a  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.w   ------------------------------   End of INFO-VAX 2001.277 ************************