1 INFO-VAX	Mon, 13 Nov 2006	Volume 2006 : Issue 625       Contents: Re: 2007 US time changes Re: ANN: VMS Mosaic 4.1  Re: ANN: VMS Mosaic 4.1  Re: ANN: VMS Mosaic 4.1  Re: ANN: VMS Mosaic 4.1 1 Can OpenVMS support Emulex LP10000 HBA on rx2600? # RE: Datacenter standarts(off topic) - Re: DECC:  VAX 7.2 vs 7.3: malloc/free oddity  Re: DECconnect adapters # DECTERM: Logout/nohangup suggestion ' DECTERM: remotely creating  an instance * Re: DECWindows: Support for pseudo color ?( Re: DELL vs HP support: offshoring story+ Re: DS10L hanging problem, tracking it down K How to retrieve and set default file version limit of directories and files O Re: How to retrieve and set default file version limit of directories and files P Re: How to retrieve and set default file version limit of directories and files ( Re: PCSI Installation philosophy comment7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 7 Re: Performance comparison Alpha ES40 vs Itanium rx3600 P Re: Problem with sys$system:AXPVMS$PCSI_INSTALL_MIN.COM (VMS V8.3, Alpha) Alpha) Re: Where to get a cable? 6 Re: writing fixed size records with one shorter record6 Re: writing fixed size records with one shorter record6 Re: writing fixed size records with one shorter record6 Re: writing fixed size records with one shorter record  F ----------------------------------------------------------------------  % Date: Mon, 13 Nov 2006 09:38:23 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>! Subject: Re: 2007 US time changes ( Message-ID: <eja012$ali$1@pyrite.mv.net>   DaveG wrote:I > I applied the latest patches ( TZ v2 and ACRTL v3) required for the new G > US time change rules starting in 2007 on a 7.3-2 system this weekend.  > No DTSS on this system btw.   G    You have DTSS; that's the default timekeeping mechanism in V7.3 and  I later for DECnet-Plus, for TCP/IP Services, for the CRTL and for OpenVMS  H itself.  The DTSS mechanisms were integrated into OpenVMS itself.  It's , the basis for the automatic DST change, too.  I > Looks like April and October, so I ran UTC$TIME_SETUP.COM thinking that G > might change the SYS$TIMEZONE_RULE logical to the new 2007 rules.  It 
 > did not.  H    I'd suggest testing the sequence with a copy of your system disk, or / with a test system.  Test the roll-over itself.   F    Also take a look at the definitions and see when the rules go into E effect.  It would not surprise me to see the rules going into effect  I starting in 2007; that is, we're still on the old rules now.  (The rules  H have to allow the correct historical conversions, so the rules have the = change-over dates for the various rules encoded in the data.)   D > Yes I read the FAQ and release notes for the patches and I'm a bit1 > confused on when the new rules will be applied.   E    The copy of the FAQ at the HP address is stale (I let Warren know  F about that), and IIRC there was a fix in this area.  The copy over at " HoffmanLabs is two editions newer.   ------------------------------   Date: 13 Nov 2006 03:24:47 EDT) From: cook@wvnvms.wvnet.edu (George Cook)   Subject: Re: ANN: VMS Mosaic 4.1! Message-ID: <4RBh4$clsMHT@wvnvms>   h In article <e4a3a$4558229c$cef8887a$32569@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > George Cook wrote:0 >> Release 4.1 of VMS Mosaic is now available at > B > Many thanks on the continued work on a reliable browser for VMS. >  > Some notes (in random order).  > # > MAKE_VMS.COM : (and local.config) ? > $ POSTSCRIPT_VIEWER ="View/interface=decwindows/format=ps %s"  > ( > This is no longer supported on VMS :-(   Unfortunately.   = > ----------------------------------------------------------- 	 > On VAX: I > UnZip:  Zipfile Extract v5.0 of 21 August 1992;  (c) 1989 S.H.Smith and  > 1 > had problems unzipping the file midway into it.  >  > BUT:. > UnZip 5.52 of 28 February 2005, by Info-ZIP. >  > Had no problems. > O > (This is just an FYI - my unzip symbol still pointed to the very old version)   F I zip it with "Zip 2.2 (November 3rd 1997)".  To keep as much backwardF compatibility as possible I have avoided upgrading Zip, but I wouldn't$ want to use anything older than 2.2.  > > ------------------------------------------------------------ > 
 > SUGGESTION:  > M > There should be a documented way to have a blank page at startup (and when  J > creating new window) so that one need to not clear the URL field before 2 > pasting an URL copied from elsewhere (email etc)  C Press mouse button two on the Mosaic Logo to paste an URL.  The URL H will be accessed immediately.  With this release you can even paste URLs+ from mail, etc. which have <> around them.     A > ---------------------------------------------------------------  > 
 > COMPILATION 8 > HP C V7.1-015 on OpenVMS Alpha V8.3  ===> no problems. > 8 > Compaq C V6.4-005 on OpenVMS VAX V7.3 ===> no problem. > 5 > DEC C V6.0-001 on OpenVMS VAX V7.3 ==> problems :-(  > L > CC/DECC/INCLUDE=([-.ZLIB],[-.LIBJPEG])/OBJECT=ODIR:TIF_FAX3.OBJ TIF_FAX3.C >          inline static int32 >          ^G > %CC-W-FUTUREKEYWD2, "inline" is expected to be a keyword in the next  K > revision of the ANSI C Standard.  Using it as an identifier will prevent  0 > your program from conforming to that standard.M >                  At line number 776 in APPL:[MOSAIC41.LIBTIFF]TIF_FAX3.C;1.  >  >          inline static int32 >          .......^  > %CC-E-NOSEMI, Missing ";".M >                  At line number 776 in APPL:[MOSAIC41.LIBTIFF]TIF_FAX3.C;1.  > M > And of course, it causes problems with the definition of the find0span and  F > find1span routines which are then causing complaints later that the 2 > functions are implicitely declared as functions.  I I normally catch this type of thing by compiling with VAX C, but the TIFF H library had far too many other issues like this, so I gave up supportingB TIFF images with VAX C builds.   I will put out a fix later today.     George Cook  WVNET    ------------------------------  % Date: Mon, 13 Nov 2006 05:59:54 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: ANN: VMS Mosaic 4.17 Message-ID: <247b0$45585042$cef8887a$8390@TEKSAVVY.COM>    George Cook wrote: > K > I normally catch this type of thing by compiling with VAX C, but the TIFF J > library had far too many other issues like this, so I gave up supportingD > TIFF images with VAX C builds.   I will put out a fix later today.  I Well, I upgraded my C compiler, and now it works. But thought you should  < know that with DEC-C 6.0, the tiff routines had some issues.  J Now, if I can only figure out how to get DEC-C 6.4 to say "DEC C" instead F of that stupid unwanted "Compaq C".  (And the Alpha version shoudl be L changed to DEC C instead of HP C, but that is harder since one needs to add  a character :-(    ----  K It would still be nice to be able to start the app with a blank URL field.  I   Defining the default home page to be a null string ends up returning a  I directory of files in the current directory and the URL field updated to  % have the file:///directory_spec  URL.    ------------------------------  % Date: Mon, 13 Nov 2006 09:53:47 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>  Subject: Re: ANN: VMS Mosaic 4.1( Message-ID: <eja0ts$ar6$3@pyrite.mv.net>   George Cook wrote:  H > I zip it with "Zip 2.2 (November 3rd 1997)".  To keep as much backwardH > compatibility as possible I have avoided upgrading Zip, but I wouldn't& > want to use anything older than 2.2.  G    AFAIK, the zip from the current Freeware works on ancient versions,  @ and the archives are upward- and downward-compatible across the D versions.  There are various bugs in the older zip tools, including  security bugs.   ------------------------------  + Date: Mon, 13 Nov 2006 10:45:58 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)  Subject: Re: ANN: VMS Mosaic 4.12 Message-ID: <06111310455801_2020028F@antinode.org>  8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>   > George Cook wrote: > J > > I zip it with "Zip 2.2 (November 3rd 1997)".  To keep as much backwardJ > > compatibility as possible I have avoided upgrading Zip, but I wouldn't( > > want to use anything older than 2.2. > I >    AFAIK, the zip from the current Freeware works on ancient versions,  B > and the archives are upward- and downward-compatible across the F > versions.  There are various bugs in the older zip tools, including  > security bugs.  F    I can test the stuff only so far back as VAX C V3.2 on VMS V5.4 (myG oldest CD-ROM set, November 1990), but that does happen (and others may H do more), so I tend to use only the latest versions (released: Zip 2.32,? UnZip 5.52).  I've grown rather fond of the bug fixes and speed # improvements in the newer versions.   H    If anyone has any actual problems involving compatibility between Zip; anything and UnZip anything, complaints are always welcome.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------    Date: 12 Nov 2006 23:33:11 -0800 From: ray.chen@gmail.com: Subject: Can OpenVMS support Emulex LP10000 HBA on rx2600?C Message-ID: <1163403191.450269.177060@b28g2000cwb.googlegroups.com>    Hi,   C Does anybody have the experience with OpenVMS running on HP Itanium G servers? I have a Emulex LP10000 HBA which can be supported by HP-UX on B rx2600. But I am not sure if it is supported by OpenVMS running on rx2600.    ------------------------------  % Date: Mon, 13 Nov 2006 07:37:57 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> , Subject: RE: Datacenter standarts(off topic)T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401D7A784@tayexc19.americas.cpqcorp.net>   > -----Original Message-----E > From: apogeusistemas@gmail.com [mailto:apogeusistemas@gmail.com]=20 ! > Sent: November 12, 2006 4:25 PM  > To: Info-VAX@Mvb.Saic.Com * > Subject: Datacenter standarts(off topic) >=20H > Do you know where could I get informations about datacenter standarts, > likeA > how storage data tapes, off site data storage, how carrier data 
 > tapes,etc ? 	 > Regards  >=20 >=20  D Well, it might not have everything you are looking for, but one good" start would be the following site:+ http://www.upsite.com/tuipages/tuihome.html 8 http://www.upsite.com/tuipages/whitepapers/tuitiers.html   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------    Date: 13 Nov 2006 08:02:46 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 6 Subject: Re: DECC:  VAX 7.2 vs 7.3: malloc/free oddity3 Message-ID: <xIMVaFHOO+0G@eisner.encompasserve.org>   h In article <4b4b9$4552c234$cef8887a$27800@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > DECC , version 6.001 VAX VMS.  > C > Compiling the OSU web server module tmemory.c (and a few others).  > 2 > On VAX VMS 7.2, no complaints from the compiler. > L > On VAX VMS 7.3, complaints about the memory allocation functions (malloc,  > calloc, free, realloc) > 
 > example: > $ cc tmemory.c$ >                      free ( cur ); >          ............^H > %CC-I-IMPLICITFUNC, In this statement, the identifier "lib$vm_free" is& >   implicitly declared as a function., >                  Listing line number 6547.I >                  At line number 112 in WWW_ROOT:[BASE_CODE]TMEMORY.C;1.   B    Looks like somewhere in your code somebody #define'd free to beG    lib$vm_free.  Normally the compiler will replace free with a call to B    decc$free.  I'd compile with /list/show=(include,expansion) and-    search the listing file until you find it.    ------------------------------    Date: 13 Nov 2006 04:33:33 -0800 From: etmsreec@yahoo.co.uk  Subject: Re: DECconnect adaptersB Message-ID: <1163421213.777742.83420@h54g2000cwb.googlegroups.com>  B Could always modify the cable to have an RJ45 on it.  DB25 to RJ45: adapters seemed to be common as muck last time I looked...   Steve    Carl Lowenstein wrote:1 > In article <gjgk24-3vv.ln1@dadsys2.fuller.com>, + > Stuart Fuller  <stufuller@usa.net> wrote:  > >JF Mezei wrote: > >  > >> Jack Patteeuw wrote:  > >>> J > >>> I'm looking for a "reasonably priced" supplier of H8575-E DECconnect > >>> adapters.  > >>2 > >> What is a -E ? From decconnect to what type ? > >>J > >> I have some -A connectors (decconnect on one side, and female DB25 on > >> the other). > > @ > >The -E is to connect to the serial port of a Sun workstation. > K > What I did when faced with that problem was take a D-connector pin puller L > to an H8575-F (male for DCE) and swap the pins to fit the Sun workstation.H > Hint -- Sun workstation is female DTE, unlike DEC workstation which isH > male DTE.  Pins in the same place on the connector, but the other sex. > 
 >     carl > --D >     carl lowenstein         marine physical lab     u.c. san diegoD >                                                  clowenst@ucsd.edu   ------------------------------  % Date: Mon, 13 Nov 2006 06:21:06 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> , Subject: DECTERM: Logout/nohangup suggestion8 Message-ID: <8a0dd$455854f0$cef8887a$11125@TEKSAVVY.COM>  H It would be nice to be able to do a LOGOUT/NOHANGUP inside a DECTERM so 3 that the decterm instance can be reused immediatly.   9 As it stands, prior to doing the logout, the user has to  J CREATE/TERM/DETACHED/NOLOGGED which creates a new instance of DECTERM, at E which poiunt you can logout, destroy the old DECTERM window and then  K quickly log back into the new decterm before the Username: prompt logs out  + and that decterm is also rendered unusable.    ------------------------------  % Date: Mon, 13 Nov 2006 06:27:15 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: DECTERM: remotely creating  an instance8 Message-ID: <e2419$455856aa$cef8887a$10753@TEKSAVVY.COM>  H Right now, if the X-server is on node1, in order to to create a decterm I running on node2 but targetted at node1, one needs to use lots of SYSMAN   commands from node1 decterm.  6 It would be nice, if from a node1 decterm, I could do F CREATE/TERM/REMOTE=node2/TRANSPORT=DECNET/NODE=node1   and this would J automatically cause node2 to create a terminal pointed at node1's display.  E Just a suggestion. I realise that it may be of use only in my unique  F universe and that the rest of the world may not have any needs for it.   ------------------------------  # Date: Mon, 13 Nov 2006 13:31:29 GMT # From: "FredK" <fred@nospam.dec.com> 3 Subject: Re: DECWindows: Support for pseudo color ? 2 Message-ID: <Rs_5h.2355$oX2.1682@news.cpqcorp.net>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  2 news:204fa$4555970b$cef8887a$19249@TEKSAVVY.COM...M > From what I have read, the Radeon 7500 card, which came highly recommended  M > in this newsgroup, can only handle one visual type on a display. So if you  E > are at 24 bit TrueColor, you cannot run any apps that are in 8 bit   > PseudoColor. > E > So if you want to run modern applications, you can't run many core  D > mission/critical VMS applications such as DECW$PAINT or FLIGHT 3.1 >  >  > QUESTION:  > H > *IN THERORY* would it be possible to have some X extension that would L > provide PseudoColor emulation  so that an 8 bit application could display ' > on a Radeon Card running in 24 bits ?  > L > Of the cards supported by VMS, is the Radeon 7500 the only one which does L > not support multiple visuals at the same time on the display ? Or is this : > the shape of things to come with newer cards like that ?  H In theory, 8-bit can be simulated on a 24-bit display (does not need an A extension).  SUN did this on one of their cards a long time ago.  J Essentially the server DDX would convert 8-bit pixels into 24-bit pixels. I Performance of image related functions would be the biggest penalty - as  G would anything that try's to do colormap animation (since changing the  G pseudocolor map would require repaining the pixels of that color.  The  M "simple" way to do this would be to have 8-bit operations done offscreen and  J then paint the result into the window.  A more complex way would be to do  the conversion on-the-fly.  K I've thought about doing it in my copious spare time.  But it hasn't risen   to the top of the to-do list.    ------------------------------  % Date: Mon, 13 Nov 2006 07:37:16 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>1 Subject: Re: DELL vs HP support: offshoring story 6 Message-ID: <4558831d$0$25778$815e3792@news.qwest.net>  G I find it interesting that HP snared their IT chief from Dell.  Dell's  J outsourcing customer support to India was their IT chief's idea.  When HP H snagged him, Dell started moving their customer support back from India K because it wasn't working, but HP is moving their's to India now.  When he  I leaves for another company, HP will probably move their customer support  F back to North America while that future company moves theirs to India.  
 Mike Ober.  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  2 news:2a0fd$45558f0b$cef8887a$14549@TEKSAVVY.COM... > from http:://www.angustel.ca > L >  DELL TO DOUBLE OTTAWA CALL CENTRE: Dell Inc. says that over the next few H > years it will "nearly double" the size of its Ottawa Customer Contact F > Centre, which supports customers in the U.S. and Canada. The Centre G > currently employs about 1,200 people; a new three-storey facility is  - > scheduled for completion in September 2007.  >  > K > It would be ironic if Dell were to move into the old DEC/Compaq facility  K > that handled customer support calls at the same time as HP is moving its   > folks out to India.    ------------------------------    Date: 13 Nov 2006 10:21:04 -0800( From: "Rich Jordan" <jordan@ccs4vms.com>4 Subject: Re: DS10L hanging problem, tracking it downC Message-ID: <1163442064.764057.253810@h54g2000cwb.googlegroups.com>    Rich Jordan wrote: > bob.birch@gmail.com wrote: > > JF Mezei wrote:  > > > Rich Jordan wrote:J > > > > Replaced the KZPBA, used a memory contact cleaner on the DIMMs andJ > > > > risers, reseated every removable cable and connector.  Still hangsK > > > > after a little while.  Pulled the drive power and the KZPBA and its K > > > > been running a self test since last night.  We'll see how its doing  > > > > when I get home. > > 5 > > Never swap it out, fix it even it it doesn't make 2 > > sense time or money wise. Anybody can swap out8 > > a bad box but it takes skill, determination to fix a > > tough problem. > >  > > Sounds weird but... 9 > > - check the earth ground from the wall socket to both 5 > >   chasis. Make sure there is a common chasis gnd. ; > > - use heat gun and chiller to make the problem go solid . > > - run the box on it's side and upside down > > - change console > >  > > > M > > > Between the time you power on and the time it hangs, do you monitor the H > > > temperature to see if it is changing ? Or is it perfectly stable ? > > > Q > > > does the machine also hang if it stays iddle at the >>> prompt ? If you are N > > > connected via a serial console, can you escape <esc><esc><esc>RMC to theQ > > > remote management console once the system has hanged ? You might be able to  > > > see something there. > > > P > > > Once VMS has hung, can you just reboot and it will be fine for a few hoursA > > > ? Or do you need to power off o let the machine cool down ?  > A > When VMS is running there's a job recording system temp every 5 G > minutes.  It doesn't tend to change once the system has been up about G > 15 minutes, and has never shown a change immediately prior to a hang. < > I could tighten up the loop to get more frequent readings. > H > If it hangs there is a chance that the system can be rebooted by usingG > the RMC RESET command (so far I can always get into RMC), but usually F > that only works once; the second reset flashes the test light but noD > console info comes up.  Using RMC power off/on briefly will alwaysI > reboot, and can stay up for several hours or hang during boot.  Staying I > powered off longer tends to give a longer uptime before hanging but its ! > not really consistent about it.  > F > A quickie outlet tester says ground is good whether plugged into theI > UPS, directly (via surge suppressor), or an APC power conditioner.  All H > equipment connected to it is on the same circuit, and it has hung evenG > with no external devices (network or disk) connected to it other than B > the console terminal.  I'll try to verify circuit-chassis groundI > continuity tonight.   It has hung when connected to a VT420 or to a PWS  > serial port. > G > Neither the damaged grafoil pad, the CPU, or the heat sink showed any H > sign of excessive heating (and there are some pictures of very toastedI > looking DS10L CPUs out there still running).  Thats certainly not proof F > the CPU wasn't damaged due to the bad grafoil pad or something else. > H > One more test before getting a replacement.  I'll run it top open withD > a big fan blowing into it to keep it cool; the fan will be runningG > outside air (40 degrees tonight) into the box.  I'd love to take more H > time to track down the real problem but my site (hobby/personal thoughB > it is) has been down too long; its time to get it running again. >  > Thanks for all the responses.  >  > Rich  G Ran it in an open window, top open, with a 10" fan blowing into the box F and propping the lid.  outside temp was around 45 degrees (F), ambientG in the room was mid 50s.  ~36 hour self test passed, then booted and it 7 hung after 6 hours.  Oh well.  New system in my future.    Rich   ------------------------------    Date: 13 Nov 2006 00:39:45 -0800" From: "Jose Baars" <peut@peut.org>T Subject: How to retrieve and set default file version limit of directories and filesC Message-ID: <1163407185.840797.279100@h54g2000cwb.googlegroups.com>   6 In DCL you can set the default file version limit with create/dir/version=x, G or with set directory/version=y. You can set the version limit on files  with set file/version=z.   @ In C, using RMS, you can retrieve the version limit of a file in XABFHC,  in field XAB$W_VERLIMIT.  E The default file version limit of a directory is one of the arguments  to LIB$CREATE_DIR, I can do that :-).   So, now I have two questions :5 - How to set the file limit of a file in a C program? B - How to retrieve the default file limit of an existing directory?   ------------------------------    Date: 13 Nov 2006 04:35:38 -0800< From: "Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com>X Subject: Re: How to retrieve and set default file version limit of directories and filesB Message-ID: <1163421338.715893.53970@k70g2000cwa.googlegroups.com>  C http://h71000.www7.hp.com/doc/732FINAL/aa-pv6sf-tk/aa-pv6sf-tk.HTMl    Jose Baars wrote:   7 > - How to set the file limit of a file in a C program?   1 You SPAWN (  system() ) the SET FILE/VER command. F I know, not what you want to hear, but really, how often are you going to do this? 3 It a native calleable interface all that important?   D > - How to retrieve the default file limit of an existing directory?  D Does XAB$W_VERLIMIT not return that? I never tried, I guess you did.> With an ACP QIO reading FAT$W_VERSIONS in the attribute block?  E Note... file version limit is not as much a file attribute as it is a  directory entry setting.C So the same file can have mutliple version limits, depending on the  directory used to find it.A Admittedly it is pretty silly to do so, but you could (see below) F You can 'see' it (and I suppose you could read it) with DUMP/DIR x.dir   $ cre/dir [.yyy]1 $ set file/ent=[.yyy]abc.tmp File:  [.xxx]abc.tmp " $ set file/versio=42 [.yyy]abc.tmp $ dir/ful [.yyy]abc.tmp 6 ABC.TMP;1                     File ID:  (82424,1575,0) : ; File attributes:   ...                    Version limit: 42  $ dir/ful [.xxx]abc.tmp 6 ABC.TMP;1                     File ID:  (82424,1575,0) : 9 File attributes:  ...                    Version limit: 5  $      Cheers,  Hein.    ------------------------------  % Date: Mon, 13 Nov 2006 08:36:04 -0800 ' From: David Mathog <mathog@caltech.edu> Y Subject: Re: How to retrieve and set default file version limit of directories and files  + Message-ID: <eja6tk$g6d$1@naig.caltech.edu>    Jose Baars wrote: 8 > In DCL you can set the default file version limit with > create/dir/version=x, I > or with set directory/version=y. You can set the version limit on files  > with > set file/version=z.   0 This is off topic slightly but here goes anyway.  B The one caveat I used to have with the file version limit was thatE there was no way to have it make a time distinction as well as a file < version limit.  For instance, say one wanted to keep no more? than 10 versions BUT at least one from the day or month before. 9 (Pick your own time frame.)  This came up in all sorts of A contexts, editing source files, keeping log files from batch runs  or web interfaces, etc.   : The only way to do this was to rename an older copy of the7 file in question so that it wouldn't be included in the 7 file version count.  But then you had to roll a complex A script to "exempt" files from the version limit, and then somehow 9 prune them out again later when the relevant time horizon 4 had passed.  To extend the file version mechanism to< also allow time differentiation is logically straightforward: but syntactically difficult.  Consider a typical batch run: log file requirement, where one wants to retain at least a8 single copy for each day for the last week, and up to 20: copies total.  So if you find out something has gone wrong: you can check back and see which day the problem was first= encountered.  For the sake of argument the runs are triggered C by end users through a web interface, and there can be zero to many 3 each day. To specify this one needs something like:   ! file version limit = 20  (as now)  minimum retained day -1 = 1  ...  minimum retained day -6 = 1 & mimimum retained day older than -6 = 03    (allow but do not require files 7 days and older      to be deleted)  8 For some other application the relevant time frame might5 be hours or minutes.  To achieve the desired level of : flexibility would seem to require a fairly complex syntax.= Probably so complex that it would have to be implemented with 9 a "VCL" (Version Control List, analogous to an ACL) which  is applied/modified with:   !   edit/vcl dirname  (or filename)    Regards,   David Mathog   ------------------------------    Date: 13 Nov 2006 04:37:16 -0800 From: etmsreec@yahoo.co.uk1 Subject: Re: PCSI Installation philosophy comment C Message-ID: <1163421436.476521.142420@m73g2000cwd.googlegroups.com>   G Depends what happens to the old images.  In the case of TCP/IP, it just 3 isn't possible since the BGDRIVER isn't compatible.   E It also comes to the philosophy of "just deliver the files and config F later" (a la TCP/IP Services) versus "do it all at once - delivery and config".   Steve    JF Mezei wrote: K > Just spent a long time fighting against PCSI to install DWMOTIF on a VAX. " > (And this isn't the first time). >  > K > If you are doing a fresh install, then I can see why checking FREE_****** K > would be good since you are adding software which will consume additional * > pages when it is started after a reboot. > L > But when doing an upgrade, one should not have to first reboot to add moreH > gblpages just to please PCSI procedures who don't realise that the oldK > version will no longer take up GBLPAGES and free enough to accomodate the C > new version at the next reboot. Forcing one to reboot prior to an 5 > installation , and then after the install is silly.  > M > Secondly, in the case of DWMOTIF, on top of moving the files, it also tries D > to install them. (thankfully, when the install fails, one is given< > opportunity to continue). This should NOT be done by PCSI. > H > The system manager should have the opportunity to execute the softwareL > startup procedure at his leasure to intall the files from the new version." > (or just reboot at his leasure).   ------------------------------   Date: 13 Nov 2006 06:33:58 EDT) From: cook@wvnvms.wvnet.edu (George Cook) @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600! Message-ID: <1i+a0C5oHkDT@wvnvms>   r In article <dYKdnTB6La4znMXYnZ2dnUVZ_u2dnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: > George Cook wrote:u >> In article <lNadnTFdfPVvScrYnZ2dnUVZ_vadnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes:  >>> George Cook wrote: >>>   B Admittedly it was the last century when I last looked in detail atC EPIC.  My opinions were formed from reviewing a non-biased detailed H analysis of EPIC way back then.  What I have seen since has done nothingG to change my opinion of EPIC.  Stupid concept then, stupid concept now, C stupid concept when Intel gives up on it.  However, it is true some = of the details I based my opinions on have faded from memory.    >>> K >>>> If I recall correctly, even the simplest IA64 instruction is 128 bits. G >>> I think you recall incorrectly:  doesn't Itanic place three 41-bit  ( >>> instructions in each 128-bit bundle? >>  F >> No, I recall correctly.  IA64 can place multiple operations in eachI >> instruction, but I guess it depends on your definition of instruction.  > I > I was using the one that seemed most equivalent to 32-bit conventional  J > RISC instructions, since that appeared to be the topic under discussion. > I >> By the definition usually used in discussing VLIW, an instruction is a 9 >> single unit of work consisting of multiple operations.  > I > Then an Itanic instruction is indeed 41 bits, not 128:  IIRC the three  G > instructions in a bundle are not a 'single unit of work' in any real  B > sense other than their syntactic ability to be grouped together.  C We will just have to be in disagreement here.  You call it what you F and Intel want; I will call it what the accepted VLIW usage calls it.    >    With the first H >> IA64 CPUs, even if you just wanted to do one thing, it took 128 bits. > E > That's a little like saying that on an Alpha, even if your program  F > executes only a single instruction, it still occupies a full memory H > page:  perhaps technically accurate but essentially irrelevant, since I > single instructions just don't exist in a vacuum in the real world but  + > rather alongside many other instructions.   G Not done a lot of coding?  Just for example, a "return from subroutine" F operation could quite often be a stand alone operation (i.e., one thatI must be in an instruction by itself) in an EPIC environment.  Returns are E frequently reached by many paths other than the immediately preceding C code, therefore, unless it is possible to branch into the middle of H an instruction, such Returns must be in an instruction alone.  Of courseF the solution, in this particular example, would be for the compiler toF generate separate Returns for all the other paths.  Note that I am not% talking about IA64 specifically here.   E It is easy to generate many common examples of where it is simply not @ possible for a compiler to generate more than two operations perI instruction (unless it did stupid stuff like branching to the immediately D following instruction), so that exercise will be left to the reader.  E >> The last I read (it has been a while), compiler produced IA64 code ? >> rarely did the maximum number of operations per instruction.  > J > Just as compiler-produced Alpha code rarely issues an instruction every H > 32 bits (at least IIRC NOPs are inserted quite frequently for various  > reasons).  > 	 >    Each H >> instruction usually did two operations at most because the operationsG >> which can be combined (and the order they can be combined in) in one H >> instruction are very restricted (the restrictions were supposed to beG >> reduced with newer Itanics, but I have not kept up if whether or not  >> that has been the case).  > C > Perhaps your information is just very far out of date, then:  my  H > distinct impression is that existing compilers have for several years A > not had difficulties in this area, and that there have been no  ; > substantive hardware changes in this area since mid-2002.   F It has never really been a compiler problem so much as it is a problemD with the code being compiled.  A great deal of code just doesn't fitF well into EPIC.  All the magic that compilers were supposed to performD when generating EPIC instructions just isn't possible for some code.  D Something is causing compilers to generate code that is two to threeD times bigger than Alpha.  I would be interested in your explanation.F If the compilers were generating a large percentage of three operationJ instructions, I would expect the size increase to be well under two times.G This assumes a lot of course (e.g. that the IA64 operations are similar 6 to Alpha instructions as far as being RISC in nature).  . >    This was one of the issues which advanced! >> compilers were going to solve.  >>  F >> FWIW, in the case of Itanic 2, the maximum number of operations per >> instruction is 6. > K > I think not:  perhaps you are confusing its ability to issue two 128-bit  D > bundles per clock with the number of 'operations per instruction' J > (regardless of how one defines 'instruction' - at least I don't know of 3 > any definition that would include *two* bundles).    D I believe you are correct.  That was a nearly verbatum quote I wroteE down, but I was unable to find the document I took it from.  I either * quoted it wrong or the document was wrong.  C >> At least to me, combining multiple short operations into a giant ' >> instruction never made sense period.  > I > While I'm no expert on these aspects of Itanic (perhaps someone who is  K > will chime in here and correct me if I'm wrong), I suspect that this may  G > have been because you really didn't understand what was going on.  I  I > suspect that a large part of the reason for 'bundles' was because they  F > couldn't fit the information they wanted to be able to contain in a G > single instruction into 32 bits, and did not want to take the hit of  I > doubling its size to 64 bits (when they could instead increase it only  = > by about 1/3 by bundling three instructions into 128 bits).   F No, the theory behind EPIC/IA64 is VLIW which by definition means eachG instruction does multiple things (or at least trys to).  Unfortunately, H it's the "at least trys to" part where the theory starts to breaks down.G I believe they started with the theory, decided on a number of bits for H the instruction length (128), then came up with the number of operationsH which would fit.  VLIW might be a neat concept if it didn't have so manyG downsides.  Downsides which everyone involved with IA64 appears to have F worked hard at ignoring, glossing over or dumping on others (i.e., the compiler writers).  I > I'm also no expert on the POWER architecture in this respect, but seem  F > to remember that it issues 5 instructions in something a bit like a K > 'bundle' as well - with rather impressive results - though this may have  K > more to do with the way POWER is pipelined than with instruction density  	 > per se.   G Never heard of POWER being considered VLIW like, but I know very little 9 about it other than I thought it was a RISC architecture.   E >> To me EPIC has always been in the same league as stuff like bubble J >> memory and the VAX 9000 (i.e., incredibly complex solutions to problems  >> which need simple solutions). > I > Yet another statement that makes me suspect that you really don't know  B > what you're talking about.  EPIC was *originally* meant to be a ? > *simpler* solution than RISC:  it only became complex in its  I > *implementation* (one might suspect due in part to design by committee  K > and perhaps also in desperate attempts to add features to compensate for  H > disappointing initial performance - especially by the fiasco that was 
 > Merced).  F True, it was originally meant to be simpler, but that involved a greatC deal of hand waving about compilers being the answer to everything. E Turns out compilers didn't have all the answers.  Plus when you start E pipelining and multi-issuing EPIC instructions, you have all the same F problems as with pipelining and multi-issuing RISC instructions but on a much "grander" scale.   C >> I suspect any implementation of EPIC, given the current state of ; >> software technology and hardware design, would be a dog.  > J > Then you suspect incorrectly, since the newest version is by no means a H > dog:  it is competitive with (though not superior to and in some ways H > arguably not *quite* equal to) the best that the rest of the industry F > has to offer - and only in part due to its gargantuan on-chip cache.  B Another case where we will just have to disagree.  If the originalB expectations for EPIC had panned out, IA64 should have two or moreI times the (at least in the case of non-mathematic operations) performance F of its competitors.  Even a pig can fly given enough effort, money andI time, however Intel and HP, in spite of spending many years and vast sums I of money, have barely been able to keep it competitive.  My guess is that F they have by now realized the effort is futile but will keep going forG a while due to simple momentum.  For the sake of VMS, I hope I'm wrong.   A Take a RISC instruction set and implement it two ways.  One where E all instructions are stored in 64 bits, and one where they are stored F in 128 bits.  Double the caches, memory, memory bandwidth, data lines,E etc. of the 128 bit implementation.  One would expect them to perform F at about the same speed with 128 bit program code being twice the sizeB of 64 bit code.  Now change the 128 bit implementation so that twoD instructions (operations) are in each 128 bits and that they execute< simultaneously at the same speed as before.  Now the 128 bitG implementation would perform at around twice the speed (actually faster @ than twice if it still has double the cache, etc.) of the 64 bitE implementation, and its program code would be the same size as the 64 G bit code.  (Note, all of this ignores, for simplicity, instruction data G accesses.)  The 128 bit implementation could now be classified as VLIW, F while the 64 bit remains RISC.  Sounds simple in theory, but in theoryA only.  Too bad reality gets in the way.  You can't always get two F operations in each instruction, you normally don't have doubled cache,C memory bandwidth, etc., and it takes a great deal more circuitry to C execute two operations simultaneously.  In the end you are lucky if D the 128 bit VLIW performs even a little better than the 64 bit RISC.C Intel hasn't thrown humongous amounts of cache at IA64 just because  they felt like it.  J > The main problem is that it took until late 2006 to field a respectable J > part, rather than the original projected release date of 1997-1998 (and B > the original projection was that that product would not just be G > 'respectable' but outright dominant).  Even the McKinley and Madison  I > parts available since mid-2002 have been respectable in *some* senses,  I > just not all all that impressive overall (especially in terms of power  D > consumption, which Montecito has finally put to rest as an issue).  H There are very good and readily apparent (to any one who takes a seriousC look) reasons as to why it was nearly ten years late.  Ten years of B dealing with all the "simplicity" of EPIC.  Not a flawed design or# implementation, but a flawed idea.    J > Unfortunately for Itanic, it doesn't look like much further improvement I > will occur prior to 2009 - while its competition will be forging ahead  K > vigorously.  But that's not so much an EPIC issue as a matter of Intel's  ! > priorities (and past missteps).  > H > Now, while I'm reasonably confident about these last assertions, it's B > entirely possible that I'm misinformed about some of my earlier G > architectural observations.  So again I'll express hope that someone  B > credible in those areas will chime in to help settle the matter. >  > - bill     George Cook    ------------------------------    Date: 13 Nov 2006 10:26:32 -0500. From: brooks@cuebid.zko.hp.nospam (Rob Brooks)@ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600, Message-ID: <e76oFLwcubGD@cuebid.zko.hp.com>   twnews@kittles.com writes: > Stephen Hoffman wrote: >> Syltrem wrote:  >>E >>> That server (the ES40 to be replaced by some Itanium box) hosts 6 E >>> Oracle databases of which 1 is heavily accessed, plus all clients J >>> (300) that run different applications (mostly 4GL apps), some of which$ >>> use RMS files and others Oracle. >>J >>   Whether a move to OpenVMS I64 and an Integrity server will speed yourJ >> operations, or hinder them, depends greatly on various factors and data >> not yet in evidence.  >>J >>   At the core, the typical OpenVMS I64 configuration is faster than theE >> typical OpenVMS Alpha AlphaServer configuration, and the Integrity J >> rx3600 is a very nice and very fast box.  But whether it will be fasterI >> for your specific installation and your specific applications is a far  >> more difficult question.  > G > Hoff finally starts to get to the core of your question.  The current F > state of the art Integrity servers are on average just incrementally% > faster than the Alpha you describe.   M Your statement is definitely not true, given that he's got an EV6-based ES40.   E > The key, IMHO, is that you should not count on anything but a small D > boost in going from your particular Alpha's to fairly cutting edge- > Integrity.  It just isn't that much faster.   / That isn't true, going from an EV6-class Alpha.    --    H Rob Brooks    VMS Engineering -- Exec Group     brooks!cuebid.zko.hp.com   ------------------------------   Date: 13 Nov 06 13:42:50 EST) From: cook@wvnvms.wvnet.edu (George Cook) @ Subject: Re: Performance comparison Alpha ES40 vs Itanium rx3600! Message-ID: <6uaPiipl5EOp@wvnvms>   [ In article <zo06h.2359$qo3.1912@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: E > Lets see if I can clear up/confirm various things in the newsgroup.  > I > 1) On Alpha, alignment faults are fixed up by the PAL code without the  J > knowledge of the OS.  You can get the PAL code to call back into the OS H > to report the fault (see the SYS$PERM_REPORT_ALIGN_FAULT for example)  > but that isn't the default.  > J > On Itanium, the chip itself may fix up alignment faults if the data all I > is inside the same cache line.  For the times when it cannot, it traps  H > to the OS.  As others have said, to prevent another CPU in the system K > from deleting the memory out from other the alignment fault handler, the  G > handler has to current take out various memory management spinlocks.  + > That makes the operation quite expensive.  > I > 2) George's terms of instruction and microoperation aren't correct for  E > Itanium.  Itanium instructions are packages as 3-instructions in a  H > 128-bit bundle.  The bundle contains 3 41-bit instruction slots and a I > 5-bit template.  The template gives information about which functional  E > unit should look at what slot.  This lets the instruction encoding  H > overload the varous 41-bit values (the same value will be a different - > instruction to different functional units).   F I usually know better than to get in a semantics argument, so in orderG to put this one to rest, in my previous posts "instruction" is "bundle" @ and "operation" is "instruction".  Unfortunately, changing wordsG doesn't change the issues as to why VLIW/EPIC/IA64 is broken bydesign.      George Cook    ------------------------------  % Date: Mon, 13 Nov 2006 09:49:25 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>Y Subject: Re: Problem with sys$system:AXPVMS$PCSI_INSTALL_MIN.COM (VMS V8.3, Alpha) Alpha) ( Message-ID: <eja0ln$ar6$1@pyrite.mv.net>   bradhamilton wrote:   E > Installed minimal boot on a non-system disk.  Installation went as  K > expected (I've done this a number of times on V7.2X/7.3X systems without  	 > issue).  > E > When I went to boot from the "alternate" boot disk, I received the   > following at the console:  >  >>>>> b -fl e,0 dkb600 ... 1 > %APB-I-FILENOTLOC, Unable to locate SYSBOOT.EXE H > %APB-I-LOADFAIL, Failed to load secondary bootstrap, status = 00000910  C    Do you have a [SYSE] root on DKB600:?  Or is the root in [SYS0]? G    Does the root contain (%x910 is a file not found error) SYSBOOT.EXE? A    Are all the SYSBOOT.EXE files on the disk (DIR/FILE) the same?      What sort of disk is DKB600:?3    Does a [SYS0] bootstrap (b -fl 0,0 dkb600) work?    ------------------------------  % Date: Mon, 13 Nov 2006 09:51:24 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>" Subject: Re: Where to get a cable?( Message-ID: <eja0pc$ar6$2@pyrite.mv.net>   Carl Lowenstein wrote:  0 > There is something peculiar about this table. F > The column labeled MMJ has 9 entries, the MMJ connector has 6 pins. N > The column labeled DB-9 has 6 entries, the connector called DB-9 has 9 pins. > / > Maybe I just don't understand how to read it.     +    I suspect the column titles are swapped.    ------------------------------    Date: 13 Nov 2006 06:01:50 -0600 From: briggs@encompasserve.org? Subject: Re: writing fixed size records with one shorter record 3 Message-ID: <z2U77heHqorQ@eisner.encompasserve.org>   q In article <7nhSt1NzlOdd@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: o > In article <u1fe24-4ud.ln1@news.hus-software.de>, Albrecht Schlosser <ajs567XNewsX-XNewsX@tiscali.de> writes: $ >> This is how the file gets opened: >>  " >>          OPEN    (UNIT   = LUN,# >>       *           FILE   = NAME, $ >>       *           TYPE   = 'NEW',, >>       *           CARRIAGECONTROL='NONE',* >>       *           RECORDTYPE = 'FIXED'," >>       *           RECL   = 512,# >>       *           ERR    = 2900)  >>   > I >    RECORDTYPE of FIXED and RECL of 512 for a formatted file means every   >    record _will_ be 512 bytes. > I >    VMS can handle your needs as undefined record type.  I haven't tried I >    it but HELP makes it look like specifying Fortran RECORDTYPE STREAM  L >    may do what you want.  If not, I'd try using a USEROPEN routine before 0 >    I'd bother doing all the I/O via RMS calls.  = A quick test with RECORDTYPE='STREAM' makes it clear that the ; HELP page is incorrect.  <CR><LF> is inserted in the stream C after each write.  FORM='UNFORMATTED' and CARRIAGECONTROL='NONE' do  nothing to alter this behavior.    ------------------------------    Date: 13 Nov 2006 06:09:12 -0600 From: briggs@encompasserve.org? Subject: Re: writing fixed size records with one shorter record 3 Message-ID: <D2CvHW1AsLhP@eisner.encompasserve.org>   l In article <8ni5h.2359$6t.1776@newssvr11.news.prodigy.com>, Jack Patteeuw <jack.patteeuw@nospam.net> writes: > JF Mezei wrote: ! >> Hein RMS van den Heuvel wrote: = >>> Well, it is not really a fixed length 512 file is it now? < >>> Just some tools seemed to find it handy to call it that. >>   > <snip> >>  L >> It would *appear* to me that if you do not put the equivalent of ctx=rec L >> as record processing option,  you *should* be able to write raw data and J >> the system fills the blocks and when you close the file, it should set 5 >> the end of file marker where you last write ended.  > H > IIRC, you can do this from Fortran by NOT using a FORMAT specifier on  > your WRITE statement.   < Nope.  By not using a FORMAT specifier you are shifting intoC "unformatted" mode.  You can only do unformatted I/O on a file that  was opened for unformatted I/O.   B If you open the file in question with RECORDTYPE='FIXED', RECL=64,; (in unformatted mode, the recl is in units of 32 bit words) @ FORM='UNFORMATTED' you'll find that each Fortran WRITE creates aF 512 byte record.  And you'll find that the RMS FFB is not set to point8 to the offset within the partially complete last record.  I > You can "fake" doing block IO by simple putting the data in a 512 byte  I > array and writing that.  For the last "record" only write out what you  ! > have put in that buffer so far.    That plan appears not to work.   ------------------------------    Date: 13 Nov 2006 06:16:45 -0600 From: briggs@encompasserve.org? Subject: Re: writing fixed size records with one shorter record 3 Message-ID: <zXW19qMoqLgU@eisner.encompasserve.org>   T In article <D2CvHW1AsLhP@eisner.encompasserve.org>, briggs@encompasserve.org writes:D > If you open the file in question with RECORDTYPE='FIXED', RECL=64,C                                                                  ^^ = > (in unformatted mode, the recl is in units of 32 bit words)   E Brain fade.  One would, of course, use RECL=128 to create a file with 2 512 byte fixed length records in unformatted mode.  G [As written previously, unformatted I/O doesn't help with this problem]    ------------------------------    Date: 13 Nov 2006 07:47:30 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: writing fixed size records with one shorter record 3 Message-ID: <VB0YnWOcgjPo@eisner.encompasserve.org>   l In article <8ni5h.2359$6t.1776@newssvr11.news.prodigy.com>, Jack Patteeuw <jack.patteeuw@nospam.net> writes: > JF Mezei wrote: ! >> Hein RMS van den Heuvel wrote: = >>> Well, it is not really a fixed length 512 file is it now? < >>> Just some tools seemed to find it handy to call it that. >>   > <snip> >>  L >> It would *appear* to me that if you do not put the equivalent of ctx=rec L >> as record processing option,  you *should* be able to write raw data and J >> the system fills the blocks and when you close the file, it should set 5 >> the end of file marker where you last write ended.  > H > IIRC, you can do this from Fortran by NOT using a FORMAT specifier on  > your WRITE statement.  > I > You can "fake" doing block IO by simple putting the data in a 512 byte  I > array and writing that.  For the last "record" only write out what you  ! > have put in that buffer so far.   G    Nope.  With the file opened as 512 byte fixed length records Fortran +    will pad any short records to 512 bytes.    ------------------------------   End of INFO-VAX 2006.625 ************************