1 INFO-VAX	Wed, 14 Jun 2000	Volume 2000 : Issue 330       Contents:@ Re: AlphaStation 200 firmware update problem - Success & summary@ Re: AlphaStation 200 firmware update problem - Success & summary Alternate boot root number Re: Autogen " Re: blocks incorrectly marked free/ Re: C bashing (was Re: VMS File Caching Futures / Re: C bashing (was Re: VMS File Caching Futures % Changing tape density of Tz86 to Tz85 ) Re: Changing tape density of Tz86 to Tz85  Chinese VMS  Re: CONV$RECLAIM question  Re: CONV$RECLAIM question  Re: CONV$RECLAIM question  Re: CONV$RECLAIM question  Re: DECnet help!* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD Re: Fun VMS Facts? Re: Fun VMS Facts? Re: Info on VAXstation 400-VLC MVII heat output Re: MVII heat output Re: MVII heat output Need VMS media - Austin, Texas1 Proxy problem: Why does node:: work but 0:: fail? 5 Re: Proxy problem: Why does node:: work but 0:: fail? 9 Re: ramdisk vs. file cache, and the winner is, file cache 3 Relative Newbie: Accessing NT/Other Shares from VMS 7 Re: Relative Newbie: Accessing NT/Other Shares from VMS 7 Re: Relative Newbie: Accessing NT/Other Shares from VMS  ST39204LW vs Alpha 4100 problem  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel? " VMS File Caching Futures and so on VMS's URL home page  Re: VMS's URL home page  Re: www.compaq.com ZLXp-E1/E2/E3 Switch Settings   F ----------------------------------------------------------------------  % Date: Tue, 13 Jun 2000 12:22:07 -0700 ! From: Shane.F.Smith@Healthnet.com I Subject: Re: AlphaStation 200 firmware update problem - Success & summary C Message-ID: <OFFF889F64.A3035A88-ON882568FD.006A653F@HEALTHNET.COM>   K I have managed to get my AlphaStation 200 4/166 working. Thanks to all that G helped with this one, particularly Hoff, Dave Froble and Terry Kennedy. F Here's a summary of the process in case anyone else gets into the same
 situation.  H The AlphaStation had the Windoze compatible AlphaBios loaded, and when IJ tried use the firmware update to put the SRM console up instead the screenB blanked and the keyboard stopped responding. The machine had to beG rebooted, and the monitor had to be power cycled to get a picture back.   J Problem one: The display. The ZXLp-E2 card I have uses dip switches on theF back to set its display mode. When the firmware update started, it wasH trying to go to the set display mode, and my monitor couldn't handle it.G The solution was to set the switches to down/up/down/up from the card's F point of view (it's upside-down in the Alphastation), which puts it inK 800x600x60hz, which just about any monitor can handle. (If anyone's got the H key to these switch settings, I'd be interested in getting a copy.) ThisG gave me a black screen display with a white block cursor at bottom left . when the firmware update software was started.  K Problem two: The keyboard was still unresponsive. It turned out the machine D was using the serial port as a console. This was solved by running aK standard PC (hawk, spit) null modem cable between COM1 on a PC (hawk, spit) H and the top serial port on the Alpha. Microshaft's hyper terminal sucks,K but it did the job. It needs to be set on COM1, 9600 baud, and the rest can I be left at the defaults. The firmware update worked fine from there. - So C far, this is the only serious use I've found for a PC (hawk, spit).   I Problem three: 24 meg isn't enough to boot the SRM - it stackdumps with a G "not enough memory" error. An extremely expensive trip to several local F techie stores eventually turned up what seem to be the last two 32-megK parity simms in the western world. 70ns would apparently have done, but all H that was available was 60ns and they did the trick. The SRM now gets allK the way through the self test, and gets me to the dead sargeant prompt with H 64meg, 80meg or 88meg. (I tried a few different configs). Interestingly,G although apparently not certified for this beast, 4meg simms do seem to E work ok in it. Once the dead sargeant appears, the Alphastation's own G keyboard starts working again and the PC (hawk, spit) can be shut down.   F Problem four: Although my SCSI Toshiba 24x CD-Rom seems to work on theE machine, I can't find my @#$^ VMS installation CD. This one I'm still I working on. A friend tells me he has a VMS 7.2 CD somewhere, so it should  be solved quite soon.   F A word of warning; if shopping for hard drives for these beasts, don'tH settle for the ones that need a converter card to allow them to accept aI 50pin SCSI cable. They only fit in one of the bays, and they're so fiddly 7 to get in there that you usually jiggle the card loose.    ------------------------------  # Date: Tue, 13 Jun 2000 21:55:46 GMT ( From: Terry Kennedy <terry@gate.tmk.com>I Subject: Re: AlphaStation 200 firmware update problem - Success & summary ' Message-ID: <Fw44wy.5oJ@spcuna.spc.edu>   # Shane.F.Smith@healthnet.com writes: G > work ok in it. Once the dead sargeant appears, the Alphastation's own I > keyboard starts working again and the PC (hawk, spit) can be shut down.   K   "set console graphics" should fix it so it always uses the local display/ / keyboard. "set console serial" for the reverse.   H > Problem four: Although my SCSI Toshiba 24x CD-Rom seems to work on theG > machine, I can't find my @#$^ VMS installation CD. This one I'm still K > working on. A friend tells me he has a VMS 7.2 CD somewhere, so it should  > be solved quite soon.   J   You can also get the hobbyist CD. I have had mixed results using genericI CD-ROMs (as well as older DEC ones like the RRD42). I'm using Plextor 32X J drives, which guarantee VMS compatibility and have a 512 byte/sector mode.  - 	Terry Kennedy             http://www.tmk.com 5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  # Date: Tue, 13 Jun 2000 23:51:32 GMT  From: WalingK@datacom.co.nz # Subject: Alternate boot root number ) Message-ID: <8i6hdu$oq6$1@nnrp1.deja.com>    Hi,   D I have 2 identical Alpha servers (2000 4/275 ) in a VMS cluster (VMSD 7.1-2). SYSTEMA boots of [SYS0] and SYSTEMB of [SYS1]. SYSTEM B is aG DR/backup system for SYSTEMA. The plan is that if SYSTEMA goes down for A a longish period, SYSTEMB will be rebooted from its root, [SYS0].   C Is there a method to change the boot root number on SYSTEMB without  using the console?   Regards    Waling      & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Tue, 13 Jun 2000 18:19:52 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>  Subject: Re: Autogen- Message-ID: <3946C198.1E4C1096@earthlink.net>    tforsyth wrote:  >  > Shawn, > = > Yes, savparams to setparams will set the system ready for a @ > reboot (only specify feedback if it's been up less than 24 hrs3 > and you _need_ feedback from the running system).  > B > It'll also run a genfiles phase, so be prepared for some disk to= > disapear as that'll create new page, swap and dump files if 	 > needed.   : ...unless you put DUMPFILE=0, PAGEFILE=0 and SWAPFILE=0 in MODPARAMS.DAT.    --   David J. Dachtera  dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Wed, 14 Jun 2000 07:47:47 +0200 > From: "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr>+ Subject: Re: blocks incorrectly marked free 3 Message-ID: <8i768e$2t22$1@s2.feed.news.oleane.net>   
 To summarize,   = 1.- the AES macro example compiles with several "INFORMATION" )     messages that do not sound very sane.   A 2.- the program works ok on an ODS2 disk , but NOT on an ODS5 one ;     (the block #0 is reported as not belonging to any file)   A 3.- the block allocation problem survives to disconnection of all (     PC clients and dismount of the disk.  C 4.- same for incorrect busy headers that simply appear as incorrect      headers for DUMP.   @ I think I will not be able to identify the source of the problemB without a correction of the FIND_LBN program to support ODS5, whatB I'm totaly unable to do. (You may consider it is an incantation to
 VAXMAN ;-)  2 Thanks to all who gave advices on this question...  
 Jean-Franois       I "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr> wrote in message - news:8hr7em$203a$1@s2.feed.news.oleane.net...  > Bonjour  tous ... > C > Running analyze/disk, I got some "blocks incorrectly marked free" E > messages. As I already had to repair my disk yesterday for the same C > reasons, I'd like to identify what files are affected, suspecting B > Advanced Server (7.2A on OpenVMS Alpha 7.2-1 + current patches). >  > I found a example in DSNH > "Example-MACRO Givent an LBN, how to find the file it is allocated to" > G > But when I can't compile with $ MACRO FIND_LBN.MAR (ends with errors)  > * > How could I build the executable image ?( > Will it run on an ODS5 shadowed disk ? >  > Cordialement ... >  > Jean-Franois Marchal  > X9000 - LYON >  >    ------------------------------   Date: 13 Jun 2000 15:49:17 CDT= From: wayne@tachysoft.xxx.044962.killspam.0138 (Wayne Sewell) 8 Subject: Re: C bashing (was Re: VMS File Caching Futures. Message-ID: <u2xmKrgFxMeV@tachxxsoftxxconsult>  U In article <394635ED.8427603F@compaq.com>, Ed Vogel <edward.vogel@compaq.com> writes: @ >     Just to make everyone aware, the Compaq C compiler has theH >     ability to detect many of the cases that have been discussed here.4 >     If you compile /WARN=ENABLE=QUESTCODE the V6.24 >     compiler will issue diagnostics for the cases: >  >     if (xyz = abc) >         {  >         do_this(); >         }  > 
 >     and: >  >     /*  >     ** Try this nested comment >     *\( >     printf("This will never print\n"); >  >     /* >     ** And there is no error >     */ > 
 >     and: >  >     do_this; >  > J >     as well as many other common user "mistakes".  While it is true that: >     using /WARN=ENABLE=QUESTCODE can also generate a lotH >     of "noise", it can be also save developers a lot of time by having2 >     the compiler detect potential coding errors. > B >                                                         Ed VogelN >                                                         Compaq C Engineering >  >  >     J Fantastic!!  I didn't know about this.  Is this only with 6.2 and later?       --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== O Otter, on dining with Bluto:"It's perfectly safe if you keep your arms and legs  			away from his mouth."   ------------------------------  # Date: Wed, 14 Jun 2000 02:07:54 GMT 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 8 Subject: Re: C bashing (was Re: VMS File Caching Futures+ Message-ID: <aIC9BOeFUYWT@eisner.decus.org>   n In article <u2xmKrgFxMeV@tachxxsoftxxconsult>, wayne@tachysoft.xxx.044962.killspam.0138 (Wayne Sewell) writes:  L > Fantastic!!  I didn't know about this.  Is this only with 6.2 and later?    : Extra warning capabilities were there at least 4 years ago9 (when I used them).  I don't know the details of when any  particular tests were added.   ------------------------------  % Date: Tue, 13 Jun 2000 12:24:09 -0700 0 From: "Weiner, Howie" <Howiew@ci.portland.or.us>. Subject: Changing tape density of Tz86 to Tz85F Message-ID: <73235F76236AD311A72500A0C9EE0B0D0429D5@ecntsix.boec.city>  A I have a Tz86 tape drive connected to an infoserver 150 via SCSI. @ I need to create a tape in Tz85 format. The manual mentions that> I can use the PARAMS utility to modify the DUP parameter named FORCEDENSITY to TK85 format.  J I am having trouble connecting to the infoserver. When I enter the command. SET HOST/DUP/SERVER=MSCP$DUP/TASK=PARAMS INFO, I get back: > %HSCPAD-F-FILCONSRVR, Failed to establish connection to server- -SYSTEM-F-NOSUCHNODE, remote node is unknown.   K I have a VT plugged into the console port of the infoserver and when I do a ' SHOW SERVER, it says it's name is INFO.   F Now to the question: Am I missing something about how the infoserver'sG node name is served up to the VAX? What else am I missing? I can access 1 the tape drive for normal operations using LADCP.   , Running VMS 7.1 on two clustered VAX 4500's.B Thanks in advance. I had enough time to write that instead of TIA.   ------------------------------  % Date: Tue, 13 Jun 2000 23:25:22 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net> 2 Subject: Re: Changing tape density of Tz86 to Tz857 Message-ID: <035b01bfd5b8$8fdbaae0$020a0a0a@xile.realm>   2 Weiner, Howie <Howiew@ci.portland.or.unitedstates>  C > I have a Tz86 tape drive connected to an infoserver 150 via SCSI. B > I need to create a tape in Tz85 format. The manual mentions that@ > I can use the PARAMS utility to modify the DUP parameter named > FORCEDENSITY to TK85 format.  ) You have a manual for a TF86, not a TZ86.   L The recommended procedure is to init the tape on a Tx85, or one of the newerH devices where you can specified the tape's density from the front panel.   -John  wb8tyw@qsl.network.    ------------------------------  % Date: Tue, 13 Jun 2000 11:49:24 -0700 + From: Steven Xie <r33300@email.sps.mot.com>  Subject: Chinese VMS1 Message-ID: <39468234.8BE01E04@email.sps.mot.com>   
 Hello all,  G Have a question regarding to the double byte font display. We are doing B some testing on VMS V7.2-1. There is an application running on theC system need display chinese (double byte font). My question is if I F don't install chinese software (chinese vms and chinese motif) to VMS,D can I be able to display chinese when I running that application (on( some workstation with chinese support)?    Thanks,  Steven   ------------------------------  % Date: Tue, 13 Jun 2000 15:43:51 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> " Subject: Re: CONV$RECLAIM question, Message-ID: <39468EF5.731FF835@videotron.ca>   hein@eps.zko.dec.c*m wrote: : > Be sure to use the reclaim stats to quantify the effort.B > You may also want to limit efforts to key-0 for your application  M The documentation I have for CONV$RECLAIM only provides 2 arguments, the file N name and the output statitics vector. What did you mean by limiting efforts to key-0 ?   J > scan, write) would be needed for a simalar amount of data. You just pick> > between paying 100 times 1 units or 1 times a hundred units.  K But from an architecture point of view, if doing 100* 1 unit means that the H application need not be shutdown because the time for each unit is shortI enough that mailbox messages can wait in the mailbox buffers, it makes it M easier to design. And if a mailbox buffer does fill up, it means that sending I processed are RWMBXed only for a couple of seconds until service resumes.   O > Reclaiming for the whole day is problably a little more efficient in terms of I > startup/shutdown/roundup. It has a risk however that you end up pushing 1 > into an additional indexe layer during the day.   E Also requires a larger queue file allocation and/or having to pay for  extending the file.   K > An approach might be to reclaim whenever the the application 'knows' that N > an additional index layer is imminent (number of records queued, SYS$DISPLAY; > + AREAS, File grown beyond initial extend, whatever)...).   N Yes, doing this based on number of transactions is probably the way to do it. M I have already found the spot in the program/flow where the reclaim should be M done, and I just need to keep track of the number of transactions done and do L the reclaim at that spot whevener it gets there and the number is higher.  IL had thought of doing it blindly there everytime, but your suggestion makes a
 lot of sense.     G > Instead of a daily large reclaim, leaving behind a few valid records, D > why not do a full convert with FDL to create a clean file with the > few remaining records.  J If I have a file which at one point had 1000 records and is down to 1 (the< last one inserted, all inserted in incresing order of key0).  D Assuming that the file was originally sized to contain 1500 records.  L If I do a CONC$RECLAIM on the file, will the resulting file provide the sameB performance compared to creating a fresh one with a full convert ?  N > Or... You can possibly keep the down time very low by pre-creating the file;  M I would prefer staying away from recreating the file at regular intervals. It K adds too much complexity to the software (checking version numbers, dealingRF with the case when version number gets to 32k etc, and system managers: probably don't like it from a fragmentation point of view.   ------------------------------  % Date: Tue, 13 Jun 2000 16:09:28 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> " Subject: Re: CONV$RECLAIM question( Message-ID: <8i647d$ggk$1@pyrite.mv.net>  L Since there seems to be a bit more complexity involved in this approach thanE you had originally contemplated, have you considered rolling your ownlG mechanism instead of using one that doesn't seem too well-suited to thei problem?  L If you don't need alternate keys, for example, it shouldn't be too difficultE to set up your file (an unstructured RMS block I/O file, or perhaps aeL sequential file, or even a relative file if the entries are fixed-size) as aD circular buffer (with randomly-addressable contents if you must, forI example, remove queue elements sometimes - whether you establish explicit-J linkages or just take the overhead of scanning past deleted elements wouldH depend upon the expected normal maximum length such scans).  Sharing theI file could increase the level of complication, but in this application isA sharing required?   J Growing the circular buffer is also an interesting, though not impossible,I exercise - but disk space is cheap enough these days that preallocating a J sufficiently generous amount to avoid the need to grow it is a possibilityH (an alternative to cover exception cases would be additional, extendibleJ files that could be 'patched into' the first at the appropriate points and4 then collapased out as their contents were emptied).   - bill  8 JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message& news:39468EF5.731FF835@videotron.ca... > hein@eps.zko.dec.c*m wrote:a< > > Be sure to use the reclaim stats to quantify the effort.D > > You may also want to limit efforts to key-0 for your application >pJ > The documentation I have for CONV$RECLAIM only provides 2 arguments, the fileE > name and the output statitics vector. What did you mean by limitingn
 efforts to	 > key-0 ?c >uL > > scan, write) would be needed for a simalar amount of data. You just pick@ > > between paying 100 times 1 units or 1 times a hundred units. >aI > But from an architecture point of view, if doing 100* 1 unit means thato thelJ > application need not be shutdown because the time for each unit is shortK > enough that mailbox messages can wait in the mailbox buffers, it makes itlG > easier to design. And if a mailbox buffer does fill up, it means that) sendingeK > processed are RWMBXed only for a couple of seconds until service resumes.p > H > > Reclaiming for the whole day is problably a little more efficient in terms ofK > > startup/shutdown/roundup. It has a risk however that you end up pushingr3 > > into an additional indexe layer during the day.i > G > Also requires a larger queue file allocation and/or having to pay foru > extending the file.  >cH > > An approach might be to reclaim whenever the the application 'knows' thatD > > an additional index layer is imminent (number of records queued, SYS$DISPLAYa= > > + AREAS, File grown beyond initial extend, whatever)...).e >uK > Yes, doing this based on number of transactions is probably the way to doa it.hL > I have already found the spot in the program/flow where the reclaim should beL > done, and I just need to keep track of the number of transactions done and doK > the reclaim at that spot whevener it gets there and the number is higher.c IhL > had thought of doing it blindly there everytime, but your suggestion makes an > lot of sense.p >  > I > > Instead of a daily large reclaim, leaving behind a few valid records,oF > > why not do a full convert with FDL to create a clean file with the > > few remaining records. >eL > If I have a file which at one point had 1000 records and is down to 1 (the> > last one inserted, all inserted in incresing order of key0). >tF > Assuming that the file was originally sized to contain 1500 records. >cI > If I do a CONC$RECLAIM on the file, will the resulting file provide thef sameD > performance compared to creating a fresh one with a full convert ? >-J > > Or... You can possibly keep the down time very low by pre-creating the file;r >gL > I would prefer staying away from recreating the file at regular intervals. ItE > adds too much complexity to the software (checking version numbers,h dealingrH > with the case when version number gets to 32k etc, and system managers< > probably don't like it from a fragmentation point of view.   ------------------------------   Date: 13 Jun 2000 23:41 -0400t From: hein@eps.zko.dec.c*m" Subject: Re: CONV$RECLAIM question& Message-ID: <13JUN200023413693@miasys>  ^ In article <39468EF5.731FF835@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes...  N >The documentation I have for CONV$RECLAIM only provides 2 arguments, the fileO >name and the output statitics vector. What did you mean by limiting efforts tob >key-0 ?  C Just that. Get with the plan! It's been there since 6.1. Check out:nN   http://www.openvms.digital.com:8000/72final/4493/4493pro_007.html#index_x_68, [I should know... I added that parameter :^]  I >application need not be shutdown because the time for each unit is short J >enough that mailbox messages can wait in the mailbox buffers, it makes it >easier to design.  # Sure. That's reasonable. go for it.A8 Are you using any other semantics from the indexed file?D If not, you may want to consider a simple 'circular buffer' instead.  M >If I do a CONC$RECLAIM on the file, will the resulting file provide the sameSC >performance compared to creating a fresh one with a full convert ?   . I suppose it should. Don't recall trying that.  N >I would prefer staying away from recreating the file at regular intervals. ItL >adds too much complexity to the software (checking version numbers, dealingG >with the case when version number gets to 32k etc, and system managers-; >probably don't like it from a fragmentation point of view.D  E You should never allow fragmentation. I was thinking more in terms ofeF overlaying the old file, using fixed version numbers and variable fileG names with renames (old, active, new) for new cycle delete 'old.idx.1'; G rename 'active' to 'old'; rename 'new' to 'active'; create 'new.idx.1'.   1 [or use COPY/OVER or that 'reset' tool i posted']   	 Have fun!n 	Hein.   ------------------------------  % Date: Wed, 14 Jun 2000 01:15:59 -0400w- From: JF Mezei <jfmezei.spamnot@videotron.ca>." Subject: Re: CONV$RECLAIM question, Message-ID: <394714FE.F5D287BF@videotron.ca>   hein@eps.zko.dec.c*m wrote:yP > >The documentation I have for CONV$RECLAIM only provides 2 arguments, the file  E > Just that. Get with the plan! It's been there since 6.1. Check out:-P >   http://www.openvms.digital.com:8000/72final/4493/4493pro_007.html#index_x_68. > [I should know... I added that parameter :^]    K Sorry, I still use the "wall"... Also, I could not find any info in the VMS.L HELP section on the CONV$ routines. (if they are there, under which topic ?)  , And furthermore, the .H include file on VAX:  N DECC$LIB.REFERENCE.SYS$STARLET_C]CONV$ROUTINES.H (which I beleive is generated from the .SDI)  Y has a comment describing the CONV$RECLAIM which shows only 2 arguments (file, statistics)m   (DECC V6.0)s    % > Sure. That's reasonable. go for it.o: > Are you using any other semantics from the indexed file?F > If not, you may want to consider a simple 'circular buffer' instead.  N 2 keys actually. A primary key (unique, added in increasing key values), and aI secondary key which allows me to get records in the order they need to bed processed. n   > Have fun!A    N Yes I am ! Am reusing some code which has been running for years for somethingL I will productize and want to make sure that under heavy loads, the softwareL will run for months without any human intervention.  (It has for me, but not under heavy loads).    ------------------------------  % Date: Tue, 13 Jun 2000 23:19:24 +0200t" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: DECnet help!o( Message-ID: <8i68dv$aoq$1@news.IAEhv.nl>   Steven,a  5 Arne's advice is pretty sound (besides the typo, it'ss @SYS$MANAGER:NET$CONFIGURE).I Before you start, make sure you've decided on the address and the name oft your computer.K If you want phase iv backwards compatibility, use a name of 6 characters oro less.uH The address must have the form <area>.<node>  where <area> is an integer from 1 to 63 and <node> runs from 1 to 1023. E Beyond that, use all the defaults and the configuration is soon done.J Starting it might take a little@L more, depending on your platform. The recomendation for DECnet plus is 32 MB minimum. It will run int@ less provided your pagefile is large enough, it just takes time.I On a VS2000:a little over an hour. On a VS3100: less than 10 minutes (for  DECnet) to start.e  
 Hans Vlems  & Steven Xie heeft geschreven in bericht( <39465678.1BA1244A@email.sps.mot.com>... >Hello,s >s@ >                   I have a new system, OS is V7.2-1. I want to >configure it to beu >                   running D >                   DECnet-plus. This is the first time I try to use >DECnet-plus, can: >                   somebodyE >                   show me a example for how to configure and how to  >design the name >                   for that. F >                   Looking at the new manual for DECnet-plus confused >me. >m >u >                   Thanks,t >                   Steven   ------------------------------  # Date: Tue, 13 Jun 2000 20:27:45 GMTo From: mccrobie@my-deja.com3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDi) Message-ID: <8i65fd$g3v$1@nnrp1.deja.com>   - In article <3945AADD.BBD92809@earthlink.net>, :   "David J. Dachtera" <djesys.nospam@earthlink.net> wrote: > Chuck McCrobie wrote:  > >s > > <sarcasm on> > >oG > > Well, given the overwhelming response I've had so far, I doubt this=/ > > product/project will make the light of day.= >=G > Well, it's just that there are already at least two ODS-2 readers for@. > DOS/WIN, W/9x and/or UN*X (including Linux). >n  C Are these native file systems or a user mode utility program?  I amgG aware of the ODS2 read utility on the Freeware CD - it does not, to the=E best of my knowledge, offer a mountable file system interface to ODS2  volumes.  & Can one get support for these readers?  H > > Adding write support is far beyond the scope of what I planned to do -0G > > and I don't see any need for writing ODS-2 on FreeBSD to be read by ; > > OpenVMS.  Why would you recommend adding write support?e >gB > ...and if you could dual boot *BSD/Linux and OpenVMS? (...and of course,xB > you can!), would you not want to share data between the o.s.-es? >e   ISO9660 isn't good enough?  E > > Perhaps a Windows NT/2000 installable file system driver would bea betterG > > received...  Oh well, long live Microsoft - may Bill Gates get evene more > > richer!  >t  > Like to live dangerously, huh? >- > -- > David J. Dachterae > dba DJE Systems1$ > http://home.earthlink.net/~djesys/ >w< > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/C >0    & Sent via Deja.com http://www.deja.com/ Before you buy.e   ------------------------------  # Date: Tue, 13 Jun 2000 21:08:01 GMTm From: mccrobie@my-deja.com3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDm) Message-ID: <8i67r5$htv$1@nnrp1.deja.com>   > In article <hshubs-6F5744.23341512062000@news.mindspring.com>,/   Howard S Shubs <hshubs@mindspring.com> wrote:S< > In article <3945A3B8.1D189D16@apl.jhu.edu>, Chuck McCrobie > <mccrobi@apl.jhu.edu> wrote: >O > ><sarcasm on>n > [mild rant deleted]a > ><sarcasm off> >t@ > That doesn't sound like sarcasm; it sounds like a statement of	 position. G > Let me clue you, from my POV and apparently others: if you want to dohB > this, do it.  Don't expect to make money off it directly.  While you're > at it, try doing ODS-5.e >rF > As far as I can figure, the only way to "make money" off Open Source isF > to get a really great rep from the quality of your code and get jobs > that way.- >- > --! > Howard S Shubs, the Denim Adept0 >:  E I wasn't planning on doing open source.  It seems most companies wantaB some type of purchasable before committing to use a product.  ThisG may/may not include support contracts.  My goal is to provide a productaD that someone can use to access their OpenVMS written data on anotherD platform (FreeBSD in this case) in a "native file system mode".  How> many in this newsgroup would use open source software in theirF production environment without a support contract?  How many would use2 open source software even with a support contract?  F Yes, I would agree that the only way to make money from open source isC to have a good reference for the next job.  I wish to make money bykG doing what I know best - writing software.  However, it seems that this0- particular product is not the way to do that.m   Enough said.   Chuck     & Sent via Deja.com http://www.deja.com/ Before you buy.l   ------------------------------  % Date: Tue, 13 Jun 2000 17:57:35 -0500n7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>u3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDe- Message-ID: <3946BC5F.D7481BF8@earthlink.net>n   mccrobie@my-deja.com wrote:hI > > > and I don't see any need for writing ODS-2 on FreeBSD to be read bya= > > > OpenVMS.  Why would you recommend adding write support?n > > D > > ...and if you could dual boot *BSD/Linux and OpenVMS? (...and of	 > course, D > > you can!), would you not want to share data between the o.s.-es? > >  >  > ISO9660 isn't good enough?  & Can you write ISO-9660 on a hard disk?   -- e David J. Dachterae dba DJE Systemss" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/p   ------------------------------  % Date: Tue, 13 Jun 2000 18:02:55 -0500d7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>r3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDu- Message-ID: <3946BD9F.E6580580@earthlink.net>o   mccrobie@my-deja.com wrote:uG > I wasn't planning on doing open source.  It seems most companies want ? > some type of purchasable before committing to use a product.    C PKware has had both shareware and payware versions almost since the @ beginning. Something to think about, with Open Source instead ofE shareware. Naturally, there should be a subtle difference between thes1 two versions to make the payware more attractive.t   > ThisI > may/may not include support contracts.  My goal is to provide a productuF > that someone can use to access their OpenVMS written data on anotherF > platform (FreeBSD in this case) in a "native file system mode".  How@ > many in this newsgroup would use open source software in theirH > production environment without a support contract?  How many would use4 > open source software even with a support contract?  G If the company does not object, why not? I even know of a place runninge$ CMU/IP on a mission critical system!  eH > Yes, I would agree that the only way to make money from open source isE > to have a good reference for the next job.  I wish to make money bytI > doing what I know best - writing software.  However, it seems that this / > particular product is not the way to do that.r  F I dunno. Phil Katz, rest his soul, did pretty well for himself, though' perhaps he never believed that himself.    --   David J. Dachterac dba DJE Systemsi" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/a   ------------------------------  + Date: Wed, 14 Jun 2000 00:33:09 +0000 (   ) 3 From: Christopher Smith <chriss@Mufasa.pubserv.com>n3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDtI Message-ID: <Pine.LNX.4.05.10006140030320.3988-100000@Mufasa.pubserv.com>o  - On Tue, 13 Jun 2000, David J. Dachtera wrote:e  ( > Can you write ISO-9660 on a hard disk?  F Theoretically, yes.  You can also write it to a floppy.  Macintosh andC unix machines will read disks like this, but of course, won't writee them.o  E I haven't tested VMS for simmilar capabilities, but I imagine they'res there.  H I generated the disk inquestion by using mkisofs (I think this will workJ on VMS), and writing it to the disk device under unix.  I imagine it might< work to mount the device /foreign with VMS, and do the same.   Regards,   Chriss  O ===============================================================================1@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmerh Prime Synergy of Champaign, IL. % ------------------------------------- I "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949  O -------------------------------------------------------------------------------s   ------------------------------  % Date: Tue, 13 Jun 2000 16:20:51 -0400V' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: Fun VMS Facts? ( Message-ID: <8i64sl$gsb$1@pyrite.mv.net>  J The '18 years without a reboot' story from the Irish National Railway is aH good one, though someone else would have to provide the details (kind ofK makes you wonder about modern systems that seem to accept 'memory leaks' ast a way of life...).  H VMS V1.0 would run (and not much else) in 256KB of memory using (IIRC) aJ pair of 30 MB disks.  For that matter, it wouldn't surprise me if VMS V7.2H were a *lot* smaller (and required considerably less physical memory andC disk space) than, say, Win2K (again, you'd have to dig up details).n  H Rdb on VMS held the TPC record back in the mid-'90s (before DEC and then1 Compaq stopped spending money on VMS benchmarks).e  L And clustering is now the talk of the town, despite having been pioneered 16I years ago by VMS.  (Who knows - will record managers be next?  Of course,=+ VMS can't claim to have pioneered those...)y   - bill  K <jbecker@ui.urban.org> wrote in message news:8i5mdp$4eg$1@nnrp1.deja.com...r6 > I'm putting together an orientation presentation for; > internal end users who are new to OpenVMS Alpha. For part : > of the presentation, I'm going to include material along5 > the lines of "What's OpenVMS" and "What's an Alpha" 8 > because most of these people are completely unfamiliar > with either. >s8 > Here's where you come in. What fun VMS facts would you9 > include in such an orientation? I'm looking for tidbitsM8 > that can be stated briefly and effectively to (in this8 > situation) a general but educated audience. I want the/ > items to show that VMS is a good place to be.  >s7 > I have several ideas of my own, but I thought I'd aske > the VMS community. >i > -- > Jim Becker- > The Urban Institute (http://www.urban.org/) 5 > DECUS ESILUG (http://eisner.decus.org/lugs/esilug/)t >g >e( > Sent via Deja.com http://www.deja.com/ > Before you buy.?   ------------------------------   Date: 13 Jun 2000 21:46:06 CDT= From: wayne@tachysoft.xxx.044962.killspam.0138 (Wayne Sewell)e Subject: Re: Fun VMS Facts?t. Message-ID: <u9mUEJCm3Y$p@tachxxsoftxxconsult>  F In article <8i5mdp$4eg$1@nnrp1.deja.com>, jbecker@ui.urban.org writes:6 > I'm putting together an orientation presentation for; > internal end users who are new to OpenVMS Alpha. For part : > of the presentation, I'm going to include material along5 > the lines of "What's OpenVMS" and "What's an Alpha"w8 > because most of these people are completely unfamiliar > with either. > 8 > Here's where you come in. What fun VMS facts would you9 > include in such an orientation? I'm looking for tidbitsa8 > that can be stated briefly and effectively to (in this8 > situation) a general but educated audience. I want the/ > items to show that VMS is a good place to be.s > 7 > I have several ideas of my own, but I thought I'd askn > the VMS community. >     K Have you seen the "dummies" book that has been mentioned here ("OpenVMS andtI Windows NT Integration for Dummies")?  They were handing these out at theaM dfwdays event last weekend.  The book has a lot of pro-vms stuff like that ine it.  p  K It contains a section called Ten Ways to Tell if You're an OpenVMS fanatic,aM contining items like "You know what happened on November 17, 1858"  "You knowoJ why the 'sho system' display had to have the system uptime field increased beyond 999 days."  And so on.S   -- nO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxn: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)aO ===============================================================================eO Otter, on dining with Bluto:"It's perfectly safe if you keep your arms and legs  			away from his mouth."   ------------------------------  % Date: Tue, 13 Jun 2000 14:45:45 -0500 % From: Chris Scheers <asi@airmail.net>.' Subject: Re: Info on VAXstation 400-VLC-O Message-ID: <809817AACF067A6D.E0CFC9B6D3292B6C.2449D5A004C37C03@lp.airnews.net>a   Bill Bradford wrote: > ? > Anybody know where I can find a user's manual for this thing?g7 > (VAXstation 4000-VLC).  Specifically, I need to know:e > C >         - Type of RAM (I know its 72pin parity, but can I fill itS >           with 16s?)  H You MUST use 4MB parity SIMMs.  I have not had any luck in getting a VLCD to recognize other size SIMMs.  It won't even see them as 4MB SIMMs.    C >         - Position of "S3" switch to enable serial console (all I  >           have is a VT320).g  G I think that the position you want is "up".  Just play with it until itbG works.  Remember that the console port is the MMJ port on the back, notlD the 25 pin port.  Set your terminal to 9600 baud, 8 bit, no parity. G There is a 10-15 second delay after power up before you see anything on0 the display.  
 Good luck!  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  G 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asi@airmail.netn   ------------------------------  # Date: Wed, 14 Jun 2000 00:48:47 GMTt/ From: StevenU@POBoxes.com (Steven P. Underwood)d Subject: MVII heat outputt5 Message-ID: <3946d2dc.353664193@news.ma.ultranet.com>i  B With the hardware guru's and collectors who seem to populate theseC groups, I'm hoping someone has some old documentation that can helpe me.s  F I have been given the task of determining the cooling requirements forD a new computer room as we are going to be moving the computer centerC (slight exaggeration) to a new building in a few months.  This is aeD very good thing, since our current computer room has been around 80FA for most of the winter and I am not looking forward to the summerv months.w  F Finding this information has not been a major problem with most of theF equipment, which is relatively new.  However, the problem is our MVII,E which is running quietly in the corner.  This unit is in a three footeF high rack with 2 BA23 type cabinets inside (H9xxx?).  It has a TK50 inD the upper unit and a EXB-8500C in the lower unit.  No hard drives in
 the BA23's.  h  F Also in this rack is a disk drive (CDC/Seagate) which is half the rackD wide and as deep as the BA23's.  This unit puts out at least as muchC heat as the BA23 units and I will use that to calculate if I do note find more detailed information..  ; Any information you can locate will be greatly appreciated./   Steven P. UnderwoodF Steven P. Underwood,DNRC Whitinsville,MAe StevenU@POBoxes.comf   ------------------------------  % Date: Tue, 13 Jun 2000 22:15:51 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Re: MVII heat output + Message-ID: <3946EACE.54EAF8B@videotron.ca>o   "Steven P. Underwood" wrote:H > equipment, which is relatively new.  However, the problem is our MVII,G > which is running quietly in the corner.  This unit is in a three footyH > high rack with 2 BA23 type cabinets inside (H9xxx?).  It has a TK50 inF > the upper unit and a EXB-8500C in the lower unit.  No hard drives in
 > the BA23's.y  B The information from the MVII manual states a heat dissipation of:   5872 Btu/hr for the 120Vac t! 6022 Btu/hr for the 240Vac mode. n  I That page doesn't seem to specify what sort of config is included. But it-G indicates power consumption of 16.4 A typical and 26.1 max. (for 110V).@  N And RA drive (using those drive bays) is what drew mega power. The actual BA23J cabinets insider draw a max of 230 watts each. I suspect the values quoted$ above include at least one RA drive.   There is a pointer to:  W EK-H9642-SP Micro Systems Site preparation and Verification Guide. H9642-JA/JB cabinet.h  M Not sure how you can obtain that manual (dates back to 1986/1987 timeframe !)o   ------------------------------  # Date: Wed, 14 Jun 2000 03:00:32 GMTe/ From: StevenU@POBoxes.com (Steven P. Underwood)e Subject: Re: MVII heat output 5 Message-ID: <3946f502.362407697@news.ma.ultranet.com>t  0 Thanks.  I can use that number for my estimates.   Steve-  , On Tue, 13 Jun 2000 22:15:51 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:e   >"Steven P. Underwood" wrote: I >> equipment, which is relatively new.  However, the problem is our MVII,cH >> which is running quietly in the corner.  This unit is in a three footI >> high rack with 2 BA23 type cabinets inside (H9xxx?).  It has a TK50 inpG >> the upper unit and a EXB-8500C in the lower unit.  No hard drives inl >> the BA23's. >eC >The information from the MVII manual states a heat dissipation of:a >l >5872 Btu/hr for the 120Vac " >6022 Btu/hr for the 240Vac mode.  >iJ >That page doesn't seem to specify what sort of config is included. But itH >indicates power consumption of 16.4 A typical and 26.1 max. (for 110V). >eO >And RA drive (using those drive bays) is what drew mega power. The actual BA23.K >cabinets insider draw a max of 230 watts each. I suspect the values quotedn% >above include at least one RA drive.  >l >There is a pointer to:  >rX >EK-H9642-SP Micro Systems Site preparation and Verification Guide. H9642-JA/JB cabinet. > N >Not sure how you can obtain that manual (dates back to 1986/1987 timeframe !)   Steven P. Underwood,DNRC Whitinsville,MAu StevenU@POBoxes.comm   ------------------------------  % Date: Tue, 13 Jun 2000 16:15:26 -0500 ' From: Bill Bradford <mrbill@mrbill.net>a' Subject: Need VMS media - Austin, Texas0. Message-ID: <20000613161526.A24998@mrbill.net>  3 This is probably a long shot, and I apologize, but  3 is anybody on this list / reading this newsgroup inx7 Austin, Texas and have either the OpenVMS/VAX Hobbyist b6 Media Kit , or a VMS distribution (5.5-2 or better) on7 CD-ROM that I can borrow for an evening and copy?  I'vei6 got licenses and my own Media Kit ordered, but its not7 here yet, and I'd like to fire this system up tonight../  0 Thanks.  If anybody can help, please email me at mrbill@decvax.org.   Bill   -- l* +--------------------+-------------------+* |   Bill Bradford    |   Austin, Texas   |* +--------------------+-------------------+* | mrbill@sunhelp.org | mrbill@mrbill.net |* +--------------------+-------------------+   ------------------------------   Date: 14 Jun 2000 02:04:24 GMT* From: bleau@umtof.umd.edu (Lawrence Bleau): Subject: Proxy problem: Why does node:: work but 0:: fail?) Message-ID: <8i6p78$nc7$1@hecate.umd.edu>   I I'm having a puzzling time with proxy accounts on one of my systems.  I'mhO running OpenVMS AXP 7.1-2.  The system name is ULEIS.  It's also running DecnetsL phase V with a local node name database.  I have a proxy account mapping all5 users onto themselves; AUTHORIZE SHOW/PROXY displays:n   LOCAL:.ULEIS::*,	     * (D)u  M When I enter the command DIR ULEIS:: I get a listing of all files in my loginm$ directory, which is as it should be.  J When I enter the command DIR 0:: I get a login failure!  Here is the exact message:  1 %DIRECT-E-OPENIN, error opening 0::*.*;* as inputn/ -RMS-E-FND, ACP file or directory lookup failedo< -SYSTEM-F-INVLOGIN, login information invalid at remote node  E Here's the contents of the intrusions database (from SHOW INTRUSION):   A Intrusion       Type       Count        Expiration         Source G    NETWORK      SUSPECT       1   13-JUN-2000 21:53:25.06  6903::SYSTEMn  H The accounting file shows a LOGIN FAILURE entry with the final status as. %LOGIN-F-NOTVALID, user authorization failure.  I One odd thing about this entry is the Remote fill name field.  It has thepL number 6903, which is the Decnet address of the system as an integer number.K On the entry for the successful DIR command this field is LOCAL:.ULEIS .  Ik( don't know if this has a bearing or not.  L I administer several other VMS systems.  Their proxy accounts are set up theH same way, but the DIR 0:: command works.  Any ideas on what to look for?O I checked the Decnet V settings for the FAL object (application); both incomingi) and outgoing proxy and alias are enabled.c   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edua   ------------------------------  % Date: Tue, 13 Jun 2000 23:16:38 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net>n> Subject: Re: Proxy problem: Why does node:: work but 0:: fail?7 Message-ID: <034901bfd5b7$58523fe0$020a0a0a@xile.realm>r  1 Lawrence Bleau <bleau@umtof.umd.education> wrote:   K > I'm having a puzzling time with proxy accounts on one of my systems.  I'mlJ > running OpenVMS AXP 7.1-2.  The system name is ULEIS.  It's also running DecnetJ > phase V with a local node name database.  I have a proxy account mapping allt7 > users onto themselves; AUTHORIZE SHOW/PROXY displays:o >C > LOCAL:.ULEIS::*f >     * (D)  >uI > When I enter the command DIR ULEIS:: I get a listing of all files in my  loginf& > directory, which is as it should be. >tL > When I enter the command DIR 0:: I get a login failure!  Here is the exact
 > message: >r3 > %DIRECT-E-OPENIN, error opening 0::*.*;* as inputc1 > -RMS-E-FND, ACP file or directory lookup failede> > -SYSTEM-F-INVLOGIN, login information invalid at remote node >oG > Here's the contents of the intrusions database (from SHOW INTRUSION):w >aC > Intrusion       Type       Count        Expiration         Source,I >    NETWORK      SUSPECT       1   13-JUN-2000 21:53:25.06  6903::SYSTEMt >,  K I can duplicate your problem if you have a non-default proxy for the SYSTEM'+ account in your proxy database to anything.    LOCAL:.ULEIS::SYSTEM MUMBLEi  D The other thing might be that your local decnet address might not be' registered in your local address tower.m  L If you do a SET HOST 0, and you are able to log in but you get a "Failure on? the back translate address request", then I would suspect that.c   See MISC6 in the OpenVMS FAQ.I   -John  wb8tyw@qsl.network   ------------------------------   Date: 14 Jun 2000 00:56 -0400s From: hein@eps.zko.dec.c*mB Subject: Re: ramdisk vs. file cache, and the winner is, file cache& Message-ID: <14JUN200000560191@miasys>  T In article <8i39p6$s7a@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu writes...  L I can not make VMS (File IO) as fast as Unix, but I can explain some detailsK to help understand. On VMS, when your program returns from a file close allLP the data and meta data (header, directory) for that file is on the disk. Period.M This is a nice, comfortable, secure notion which makes VMS 'robust' but slow.sL This specifically hurts when you don't give a Ra&^ A@* / FLying F(^2 whetherL the file ever makes it out, because if all is well you will delete/overwrite> and if there is a problem you relaunch the whole batch anyway.O On Unix, unless you call fsync, on close the file is merely in the (UBC) cache.-K It may or might not might it do the disk ever. On Digital Unix, there is an ? update deamon runnig every 30 second or so to flush that cache.sI This specifically hurst when the file is critical and the application has2N commited to have received the data through an external event (socket message).J Still, on Unix you can choose to call fsync, but on VMS you can not chooseF to call 'sys$enable_lazy_writes' or some such. This, IMHO, gives a BIGH advantage to Unix (as much as I like VMS). It si not clear to me to what< extent the 7.3 XFC will finally solve this (10+ years late).    N >I'd really appreciate it if somebody with a Tru64 DS10 could run these tests.   Done. Results mailed.s  ) >  I suspect it will come out near Linux,k  1 Ayup, except for a funky UFS file system anomaly.m    G >RMS parameters apparently do have an affect even when using a RAMDISK:=   Ayup. As expected. =  H By adding calls to LIB$INIT_TIMER and LIB$SHOW_TIMER to begin/end of the: test programs we start to see quickly where the time goes.F For further insight onn the CPU time, simply run MONI MODE in a windowD and look for Idle: IO, User: C-code, Exec: RMS, Kernel: file system.B I did so, and run you programs on an uncontrolled Alphaserver-1000  D C use RTL code for 'normal' IO (unshared, sequential) but listens to? the  RMS process setting for buffer size and extend ($SHOW RMS)-F It does not listen to buffer count (unless RMS is forced with ctx=rec) C always set RAH and WBH.r  N I just did some tries on a normal disk using an uncontrolled Alphaserver-1000.   set rms/block=0/buf=0/ext=0  run maketestO ELAPSED:    0 00:00:13.10  CPU: 0:00:02.55  BUFIO: 455  DIRIO: 1927  FAULTS: 10m  = The BUFIO reflect $EXTEND operations (and/or terminal output)o   set rms/block=64/buf=8/ext=1000  run maketestM  ELAPSED:    0 00:00:04.26  CPU: 0:00:01.86  BUFIO: 20  DIRIO: 413  FAULTS: 9   B         whammo. 3 times better. Just a few extends, far fewer IOs.    ! set rms/block=120/buf=8/ext=10000e del *.nfa.*a run maketestM  ELAPSED:    0 00:00:03.73  CPU: 0:00:01.72  BUFIO: 4  DIRIO: 143  FAULTS: 11,  I         A little better still, but this first step did the big job alreade   -----  Now for the mysplit program:   set rms/block=0/buf=0/ext=0n, All done, entries in final file segment: 199P  ELAPSED:    0 00:00:33.06  CPU: 0:00:05.07  BUFIO: 1441  DIRIO: 4401  FAULTS: 2      Yuck!   set rms /ext=300/bloc=120/buf=4', All done, entries in final file segment: 199O  ELAPSED:    0 00:00:11.84  CPU: 0:00:03.51  BUFIO: 562  DIRIO: 809  FAULTS: 20     C    Much better. Let's try ctx=rec for the output, and remove printfe  , All done, entries in final file segment: 199O  ELAPSED:    0 00:00:16.00  CPU: 0:00:10.09  BUFIO: 482  DIRIO: 731  FAULTS: 50e  :    Ooops, see that CPU time come up and add on to elapsed?L    Looking with moni mode you'll see all the added time come from exec mode.    %    Noow ctx=rec for output and input.   , All done, entries in final file segment: 199O  ELAPSED:    0 00:00:21.45  CPU: 0:00:16.93  BUFIO: 482  DIRIO: 761  FAULTS: 56u    8     Yikes, an othe 6 second CPU time in EXEC mode (RMS).;     Let's foll a little more with buffer sizes and extends:h  " no ctx=rec, 4 buffers, 120 blocks.O  ELAPSED:    0 00:00:12.67  CPU: 0:00:03.38  BUFIO: 482  DIRIO: 838  FAULTS: 20S    ' 4 buffers, 64 block --> need 4th buffer P  ELAPSED:    0 00:00:14.79  CPU: 0:00:03.50  BUFIO: 482  DIRIO: 1087  FAULTS: 20    7 set rms /block=70/buf=4/ext=204  ! need only 3 buffers.  Processing test.nfa with n=200, All done, entries in final file segment: 199O  ELAPSED:    0 00:00:13.84  CPU: 0:00:03.54  BUFIO: 482  DIRIO: 995  FAULTS: 25g      set rms /block=103/buf=4/ext=204
 del frag*.*.*' mysplit test.nfa 200 Processing test.nfa with n=200, All done, entries in final file segment: 199O  ELAPSED:    0 00:00:12.16  CPU: 0:00:03.36  BUFIO: 482  DIRIO: 832  FAULTS: 17i  :    Best time. But not noticably better than coarse tuning.    E >I also tried changing the output directory to NLA0: inside the test e  D The NL device stinks. It is record oriented and goes through most of@ the kernel motions for an IO (buffer probing, yada yada yada...)> IMHO VMS needs a block oriented alternative to NL:   say NLB0:    H >I don't have the source code for OpenVMS, but it is certain that APPENDG >must use RMS, and it seems likely that COPY does not in this instance..F >Given their age, I suspect neither is written in C (somebody with the >source code please check),   = Yes and no. APPEND == COPY. Single program. written in bliss.dN The COPY branch just uses RMS in block IO mode. No record processing overhead.M You got close to Unix speeds because copy minimize the file creation overheadcH (just one longish pre-allocated file) and use good-sized (32KB) buffers.  0 > so that would seem to indicate that RMS is theF >primary culprit for the poor IO performance of OpenVMS versus Linux.   E NO. RMS sucks CPU cycles big time. and the experiments above show how=@ the C RTL made the right decision to go native for simple files.@ RMS is however at the mercy of the QIO overhead / file system / " (lack of) cache for the IO delays.  7 My experiments for the test file in question this give:    @time "copy test.nfa tmp.tmp3 Dirio=   525 Bufio=    12 Cpu=    25 Elapsed=   888e  $ @time "append test.nfa tmp.tmp3 Dirio=   525 Bufio=    23 Cpu=   805 Elapsed=  1384r  I @time is a simple command file (attached) doing before/after sys$GETJPIs.: As to be expected no?i<         - few bufIO thanks to pre-extend to match input sizeG         - 16000/64 = 250 IOs to read input and 350 more to write output@'         - low CPU for simple block copy E         - high (exec mode) CPU for append due to per-record RMS calls   H For grins lets change the COPY buffer size. From the listings (availableF to all interested parties for a mionor fee) we can spot how the buffer< count (64 = 40x) is in a global long following a 0 and  a 1:  E $ pipe dump copy.exe | search sys$input " 00000040 00000000 00000001"m  5  Virtual block number 18 (00000012), 512 (0200) bytesoP   00000000 00000000 00000000 00000000 00000040 00000000 00000001 00000000 ......  .....@................... 000000   $ copy sys$system:copy.exe []e
 $ x="    " $ x[0,32]=18 $ open/read/write copy copy.exeo $ read/key=&x copy rec0 $ write sys$output f$cvsi(12*8,4*8,rec)   !check 64 $ rec[12*8,4*8]=0  $ write/update/symb copy rec $ close copy  " $ define copy sys$disk:[]copy.exe;# $ @time "appe/log test.nfa tmp.tmp"-E %APPEND-S-APPENDED, TEST.NFA;1 appended to TMP.TMP;1 (176000 records) 3 Dirio=   284 Bufio=    28 Cpu=   804 Elapsed=  1037n
 compare with:.3 Dirio=   525 Bufio=    23 Cpu=   805 Elapsed=  13841D         - Half the IOs. Same RMS work, nicely improved elapsed time.  > [fwiw, the number of buffers for COPY is much harder to tweak]     Hope this helps some,i5                         Hein.   (time.com follows...)a    + $       old_cputim = F$GETJPI ("","CPUTIM") * $       old_dirio  = F$GETJPI ("","DIRIO")* $       old_bufio  = F$GETJPI ("","BUFIO") $       old_time   = F$TIME () $! $!      Run the test $! $       'p1c $! $!      Save the end timea $!+ $       end_cputim = F$GETJPI ("","CPUTIM") * $       end_dirio  = F$GETJPI ("","DIRIO")* $       end_bufio  = F$GETJPI ("","BUFIO") $       END_TIME   = F$TIME()o $rP $       old_elapsed = ((F$EXT(12,2,old_time) * 60 + F$EXT(15,2,old_time)) * 60 -<         + F$EXT(18,2,old_time)) * 100 + F$EXT(21,2,old_time)P $       end_elapsed = ((F$EXT(12,2,end_time) * 60 + F$EXT(15,2,end_time)) * 60 -<         + F$EXT(18,2,end_time)) * 100 + F$EXT(21,2,end_time)+ $       elapsed = end_elapsed - old_elapseda? $       if elapsed .lt. 0 then elapsed = elapsed + 24*60*60*100  $       WRITE sys$output -I                 f$fao ( "Dirio=!6UL Bufio=!6UL Cpu=!6UL Elapsed=!6UL ", -A?                 end_dirio - old_dirio, end_bufio - old_bufio, -s3                 end_cputim - old_cputim,  elapsed )m $exita   ------------------------------  % Date: Tue, 13 Jun 2000 21:32:55 +0100i, From: "Gordon Maxwell" <gord@madasafish.com>< Subject: Relative Newbie: Accessing NT/Other Shares from VMS0 Message-ID: <8i65st$rq7$1@tcnnt0.totalserve.net>  E My company has several clusters of VAX 4000/60 and AlphaStation 4/200RF computers that are all used for digital mapping. We have recently beenL forced into upgrading the digital map backdrops to a newer version that will. (at least) quadruple our storage requirements.  L I have provisionally looked into replacing some of the SCSI-I disks (RZ58s IK think) with larger models, but this seems to be prohibitively expensive (iniJ the UK at least). Given the ludicrously cheap price per Gb of EIDE storageK devices, I was wondering about the possibility of accessing data on anothert platform, namely NT 4 PCs?  E Is this a completely ridiculous idea? I have search Deja for anythinguJ similar but the only thing I can find are references to Samba, which seems% to do the opposite to what I require.   K The VMS clusters run OpenVMS 7.2, all with UCX and some with an old versionaH of Pathworks (4 I think). Any help/advice/general comments would be much appreciated.   Cheers gordon   -- Gordon Maxwell
 GIS Developeri gord@madasafish.comr   ------------------------------  # Date: Tue, 13 Jun 2000 20:51:55 GMTt4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>@ Subject: Re: Relative Newbie: Accessing NT/Other Shares from VMSE Message-ID: <L9x15.21746$hp4.560921@newsread1.prod.itd.earthlink.net>e  I Whatever you end up doing, don't put an old version of Pathworks on an NT K machine.  Chances of corrupting NT are extremely high.  Suggest you put NFS1L on the NT systems (if that's what you decide to use as a disk farm) and thenI use the DEC TCP/IP (UCX) to mount the NT shares via NFS.  This would alsolI allow you to replace the NT systems with Unix, which ships with NFS.  YouiJ would need to purchase NFS for NT.  Your best choice in this case would beJ to fork out the money and hang bigger drives off your AlphaStation and letL VMS deal with it directly.  Any translation to another OS via a network will* be slower than a direct connection to VMS.  
 Mike Ober.  7 "Gordon Maxwell" <gord@madasafish.com> wrote in messaget* news:8i65st$rq7$1@tcnnt0.totalserve.net...G > My company has several clusters of VAX 4000/60 and AlphaStation 4/200.H > computers that are all used for digital mapping. We have recently beenI > forced into upgrading the digital map backdrops to a newer version that  will0 > (at least) quadruple our storage requirements. >dL > I have provisionally looked into replacing some of the SCSI-I disks (RZ58s ItI > think) with larger models, but this seems to be prohibitively expensive  (innL > the UK at least). Given the ludicrously cheap price per Gb of EIDE storageE > devices, I was wondering about the possibility of accessing data on- anothere > platform, namely NT 4 PCs? > G > Is this a completely ridiculous idea? I have search Deja for anythingtL > similar but the only thing I can find are references to Samba, which seems' > to do the opposite to what I require.a >oE > The VMS clusters run OpenVMS 7.2, all with UCX and some with an oldt versionpJ > of Pathworks (4 I think). Any help/advice/general comments would be much > appreciated. >  > Cheers > gordon >n > -- > Gordon Maxwell > GIS Developere > gord@madasafish.coms >t >e >y   ------------------------------  % Date: Tue, 13 Jun 2000 21:01:26 -0400a* From: David A Froble <davef@tsoft-inc.com>@ Subject: Re: Relative Newbie: Accessing NT/Other Shares from VMS- Message-ID: <3946D966.E4373DDD@tsoft-inc.com>-   Gordon Maxwell wrote:- > G > My company has several clusters of VAX 4000/60 and AlphaStation 4/200+H > computers that are all used for digital mapping. We have recently beenN > forced into upgrading the digital map backdrops to a newer version that will0 > (at least) quadruple our storage requirements. > N > I have provisionally looked into replacing some of the SCSI-I disks (RZ58s IM > think) with larger models, but this seems to be prohibitively expensive (inSL > the UK at least). Given the ludicrously cheap price per Gb of EIDE storageM > devices, I was wondering about the possibility of accessing data on anothera > platform, namely NT 4 PCs?  J Have you looked for SCSI disks?  I can find 9 GB drives for under $300 US,G sometimes far under, and 18 GB for under $500.  Far from 'prohibitivelyaK expensive'.  Even buying new drives from Compaq isn't too much these days. PJ True, the EIDE disks are cheaper, but if your company finds something in 3/ digits as expensive, you've got other problems.o  ' > Is this a completely ridiculous idea?e  O Yep!  A decent PC will cost more than the SCSI disk, and the accessing, backup, # etc will be a much larger headache.c   I have search Deja for anything L > similar but the only thing I can find are references to Samba, which seems' > to do the opposite to what I require.L > M > The VMS clusters run OpenVMS 7.2, all with UCX and some with an old versionhJ > of Pathworks (4 I think). Any help/advice/general comments would be much > appreciated.  P Look around for a couple Seagate ST39173N drives.  They work well in the systemsN you have.  While the firmware in the VAXstation 4000 model 60 doesn't work tooC well with the larger disks, once VMS is running there's no problem.y   Dave   -- :4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Tue, 13 Jun 2000 20:11:34 +0200-, From: "Krzysztof Karpio" <karpio@fuw.edu.pl>( Subject: ST39204LW vs Alpha 4100 problem' Message-ID: <8i5t8d$jo4$1@h1.uw.edu.pl>l  F I have a problem with disk Seagate ST39204LW - message DEVICE OFFLINE.G The system is Alpha Server 4100 with QLOGIC SCSI Ultra Wide controller,e running OpenVMS 7.1H2.I However disks ST39103 LW and LWV are working properly on the same system.M   Krzysztof Karpio   karpio@fuw.edu.plI   ------------------------------  % Date: Tue, 13 Jun 2000 18:06:29 -0500e7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>A Subject: Re: VAX on Intel?- Message-ID: <3946BE75.66A86FBA@earthlink.net>    Hoff Hoffman wrote:d > i > In article <3945A986.FD0E0421@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:eI > :So, someone tell me: under EXACTLY what conditions would expanding thegE > :OpenVMS user base harm Compaq's stock price or its investors???!!!F > I >   Please make your case -- I'd love to see this port.  In the interrum,oJ >   please see the OpenVMS FAQ, and specifically please see section VMS11.  G What further case needs to be made? (Further info. is also available atx the link(s) below.)c   --   David J. DachteraC dba DJE SystemsN" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/a   ------------------------------  # Date: Wed, 14 Jun 2000 02:10:35 GMTh9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)d Subject: Re: VAX on Intel?+ Message-ID: <6b$MSynd8$C7@eisner.decus.org>e  g In article <3946BE75.66A86FBA@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:e > Hoff Hoffman wrote:F >>  j >> In article <3945A986.FD0E0421@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:J >> :So, someone tell me: under EXACTLY what conditions would expanding theF >> :OpenVMS user base harm Compaq's stock price or its investors???!!! >> pJ >>   Please make your case -- I'd love to see this port.  In the interrum,K >>   please see the OpenVMS FAQ, and specifically please see section VMS11.s > % > What further case needs to be made?m  @ I think the idea is that you have to make your point (with which@ I happen to disagree) to Compaq management.  It sounds much moreA convincing coming from a customer than from employees like Steve.u   ------------------------------  % Date: Tue, 13 Jun 2000 21:57:55 -0500e7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>e Subject: Re: VAX on Intel?- Message-ID: <3946F4B3.A83AA58E@earthlink.net>u   Larry Kilgallen wrote: > i > In article <3946BE75.66A86FBA@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:h > > Hoff Hoffman wrote:  > >>l > >> In article <3945A986.FD0E0421@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:L > >> :So, someone tell me: under EXACTLY what conditions would expanding theH > >> :OpenVMS user base harm Compaq's stock price or its investors???!!! > >>L > >>   Please make your case -- I'd love to see this port.  In the interrum,M > >>   please see the OpenVMS FAQ, and specifically please see section VMS11.x > >t' > > What further case needs to be made?e > B > I think the idea is that you have to make your point (with whichB > I happen to disagree) to Compaq management.  It sounds much moreC > convincing coming from a customer than from employees like Steve.m  A Well, I could be wrong, but I assume they've all been to businessnH school. They shouldn't need a tech. nerd like me to come along and teachB them what they should have known to get their degrees in the first place.  F All the same, as far as I know, Richard M. and some of the others haveA already seen my "Unofficial Affordable OpenVMS Home Page". If theeG information there is insufficient or not comprehensible, then that's itrI - I can talk until I'm blue in the face and they still won't understand. i  C The formula is very simple, and any business person can prove it to G him/herself. When the price is too high, no one buys. When the price istH low enough, people will buy whether they need it or not. Remember beanie= babies? Ever heard of "e-bay"? ...priceline.com? ...ubid.com?=  H We can bandy this about until VMS is all but a happy memory in the foggyH minds of a handful of Alzheimer's(sp? it's not in Netscape's dictionary)F victims - the last surviving people who remember what VMS was and what it could have been.0  H In the final analysis, however, it's all going to come back to one basic9 law of business: supply (read: price) and demand. "Market < capitalization" is meaningless to a company whose product isC economically infeasible for the great bulk of its potential market.   @ For example: did you know that an entirely petroleum-free familyB passenger vehicle is entirely possible, and has been for about twoG decades? Wanna know why you've never heard of it? Well, there's several G reasons, from the NRC to the EPA and the Petroleum Industry itself. ButUC the biggest reason is the cost. It may last for a virtual lifetime,rC pollution free and more powerful than the "muscle cars" of the late:B 60's, but no one could afford to acquire it or maintain it. So, noG matter how well capitalized the company might have been (had it got offfA the ground), the market for the product would still be near zero.   B The bottom line is: price+marketing=$$$. Period, end of statement.   -- n David J. Dachtera? dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/m   ------------------------------  % Date: Tue, 13 Jun 2000 21:18:07 -05006, From: "Glenn C. Everhart" <Everhart@GCE.com>+ Subject: VMS File Caching Futures and so onl' Message-ID: <3946A50F.5D5BEAFD@GCE.com>n   A bit of summary. = 1. VMS caching has been a problem for some time, and is being3; addressed. The forthcoming 7.3 fieldtest will see the firstc? public light for the new caching system. There are still things51 that can improve but it should be worth the wait.   = 2. On the Veritas homepage are some whitepapers detailing the.< unix caching scheme (and their replacement scheme). Note how9 in both, user data is not written to disk till long afterR> the program is done; there is no mention of even ensuring that; data is written before closing the program, so in principle2: a program written for the default situation in unix cannot; know that its data was written correctly. I have seen casesU= where treating user data this way, for an app written withoutt@ being laced with explicit flushes, can lose application metadata@ and royally corrupt its data as a result. Admittedly the Veritas= f/s allows one to specify write-through; it appears not to beo the default.  9 3. When writing to nla0:, every record results in a $qio.:= When writing to a ramdisk, RMS and language runtime librariest; can be between your app and the disk. Ditto for hard disks,y> though default behavior can change; RMS has lots of variations8 in its defaults depending on device characteristic bits.> It is well to count I/O operations (show dev/full shows these); to see whether every record is writing disk or every block.I< VMS underlying block I/O has generally been faster than unix< block I/O in tests at low level, but a user app that invokes? multiple levels of additional interpretation slows things down.r: VMS engineering is I believe well aware of this. Still one: should not expect default VMS behavior to ever change to a  setting that can lose user data.  : 4. The VMS compilers I've seen have had the most wonderful> diagnostics I've encountered, pointing out errors which sailed< by compilers from old RSX, from Microsoft, from Absoft, from> Sun. While I must confess (in a joking way here) that it would= be refreshing for a C dialect to allow itself to be expressed < in Macro-11, allowing some of that good old code to migrate,; C and its descendants (both legitimate and Morganatic) haved9 proven their worth. Much more C has been ported in native , format than has Macro-11 (or pal-11r or...).  8 5. Now that QT is ported to VMS, anyone up for compiling
 the K office?    Glenn Everhart   ------------------------------  # Date: Wed, 14 Jun 2000 01:01:09 GMTp From: j_k@techie.com (J. K.) Subject: VMS's URL home page& Message-ID: <pPA15.91$y4.3830@llslave>   Hi VMS Guru,  8 Would anyone point out VAX/VMS home page where contains A MVS's commands, operating system information and user guide's of 6 Makefile etc....   Your help will be appreciated.   Thanks in advance.   ------------------------------  % Date: Wed, 14 Jun 2000 03:27:06 +0200e= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>0  Subject: Re: VMS's URL home page) Message-ID: <3946DF6A.17F203C5@gtech.com>.   "J. K." wrote:9 > Would anyone point out VAX/VMS home page where containsrB > MVS's commands, operating system information and user guide's of > Makefile etc....   VMS or MVS ?  9 If VMS, then try either http://www.openvms.compaq.com/ ory http://www.levitte.org/~ava/ !   Arne   ------------------------------  % Date: Tue, 13 Jun 2000 19:57:37 -0500e* From: Keith Brown <kbrown780@usfamily.net> Subject: Re: www.compaq.coma, Message-ID: <3946D881.EF03CE37@usfamily.net>   John Nixon wrote:E > L > Last week there was a discussin thread about people that could not connect > to COMPAQ.COMn  > Are there any updates on this? > L > I am still having this problem from my office connection.  I can get thereM > from my personal dialup session  but not from work.  I can get to all otherlJ > web sites, but not Compaq.com.  I am probably the only one in my companyI > that actually cares about this so it is a low priority with our networkcI > group.  Is there any advice I can give them to help me get this abilityU > restored.   > Interesting John,  I have been able to get there from work but' not from home.  My ISP is playing dumb.M   -- r Keith Brown_ kbrown780@usfamily.net   ------------------------------  % Date: Tue, 13 Jun 2000 19:14:32 -0700)3 From: David Miller <dmiller@cslab.bemidji.msus.edu> & Subject: ZLXp-E1/E2/E3 Switch SettingsD Message-ID: <4.3.1.2.20000613184003.00a89550@otter.bemidji.msus.edu>   Folks)  J  From the manual (EK-T2323-OG), these are what the switch settings on the  ZLXp-E1/E2/E3 video2 board mean:     E SW1  SW2  SW3  SW4   Pixel	                 Resolution        RefreshC2                                              Freq 0 (MHz)                                  Rate (Hz)  E     D         D        D        D      130                 1280X1024 -    72-O     U         D        D        D      119                 1280X1024         66sN     D         U        D        D     108                 1280X1024         60D     U         U        D        D      104                 1152X900     72 E     D         D        U        D       93                  1152X900       66F     U         D        U        D        75                  1024X768      70F     D         U        U        D        74                  1024X768       72 G     U         U         U       D         69                  1024X864 I      60wE     D         D        D       U        65                  1024X768 h    60 F     U         D        D        U        50                   800X600        72F     D         U        D        U        40                   800X600        60G     R         U        D        U        32                    642X480 y       72F     D         D        U        U       25                    640X480        60G     U         D        U        U       135                  1280X1024 i    75aG     D         U        U        U       110                  1280X1024 e    60o@     U         U        U        U                       Reserved  ; 1. SW1 is the switch on the right, nearest the stereo jack.-L 2. As I recall Up and Down is reversed - that is interchange the U/D in the  above (published) table.  " I hope somebody finds this useful.   dave.    ------------------------------   End of INFO-VAX 2000.330 ************************