1 INFO-VAX	Sun, 27 Oct 2002	Volume 2002 : Issue 594       Contents:3 Re: 6 free RA81 disks near philly (for pickup only) & Re: Free Microvax IIs in San Diego, CA Re: Immutable laws of the PC  Re: java on VMS - help requested? Re: Rejuvenating OpenVMS [was Re: So I went to the HP IT forum]   Re: So I went to the HP IT forum Timezone-change observations  Re: Timezone-change observations  Re: Timezone-change observations  Re: Timezone-change observations  Re: Timezone-change observations  Re: Timezone-change observations  F ----------------------------------------------------------------------  % Date: Sat, 26 Oct 2002 23:37:45 -0400 ' From: Howard S Shubs <howard@shubs.net> < Subject: Re: 6 free RA81 disks near philly (for pickup only)< Message-ID: <howard-91731E.23374526102002@enews.newsguy.com>  5 In article <apffb9$130n1$1@ID-135708.news.dfncis.de>, *  bill@cs.uofs.edu (Bill Gunshannon) wrote:  G > Actually, I have had relatively few failures and when you figure that I > all of these disks bounced their way here in the back of station wagons K > and trucks it goes a long way to proving the quality of computer products  > from that era.  H Not R81 disks.  They used a sealant that broke down after about a year, F in my experience.  From what I've been told, DEC knew this but it was > cheaper to deal with the problem than to fix it at the source.   --  4 Today, on Paper-view: The World Origami Championship   ------------------------------  # Date: Sun, 27 Oct 2002 18:15:59 GMT  From: nospam@nospam.com / Subject: Re: Free Microvax IIs in San Diego, CA + Message-ID: <aphahh$hs4$1@home.network.net>   % The Microvaxs have found a good home.    Thanks for looking, 
 Bill Young  L In article <apemqa$8ds$1@home.network.net>, Bill Young <bill@cox.net> wrote:J >I have 3 Microvax IIs in the San Diego, California area that need to findF >a new home.  They are the Q2, Q3, and Q5 models (pedistal/rack mount,J >rolling tower like enclosure, and short rack with RA81).  Unfortunately IG >don't have time to deal with shipping or parting them out.  If you are M >near the San Diego area and would like to pick them up, please send mail to:  >  >s   h   @   . > p   o   c   n  >  a   l   o   e >   m   e   x   t  >  >Thanks, >Bill Young    ------------------------------  % Date: Sun, 27 Oct 2002 03:30:18 -0600 " From: xganon <remailer@xganon.com>% Subject: Re: Immutable laws of the PC 9 Message-ID: <d62fdaca217a98689aec24fe97c6fdf4@xganon.com>   F "It occurred to me that perhaps the reason you were inclined to go allE slack-jawed over the 6 MB / 12 MB of cache in future Itanics might be @ because you don't understand that with main-memory latency held 
 relativelyH constant (at least through Montecito:  it takes an architectural change  suchG as Hammer's on-chip controller reduce it any faster than the relatively C leisurely rate of latency improvement the basic DRAM manufacturers   achieve)H you *need* to double the amount of cache in the chip for every 40% or soH increase in clock rate just to keep performance increases fairly linear  withG clock frequency.  So if Montecito clocks at about 2 GHz (compared with   1 GHz G for McKinley and 1.4 GHz or so for Madison) it will *need* all that 12   GB of F cache in 2004 just to achieve twice the performance of McKinley (1600  or so E SPECint) - and if you're optimistic that Montecito will clock faster   than 2A GHz, then even 12 MB won't be sufficient to keep the performance   increaseG linear (i.e., at 2.25 GHz a SPECint score of 1800 would start to become = difficult to attain with 'only' 12 MB of cache on the chip)."   E You spend a good deal of time talking about specint.  specint is nice F but certainly misses the point in the server space.  The key to serverB sales break down differently in separate segments but essentially B rides on a handfull of key factors.  The sweet spot of 4P to 8P isA driven by transactions.  How well does the box perform running a  @ database.  Several easily locatable studies point out that largeA on-chip caches coupled with keeping the cache misses down (branch B prediction coupled with I2 speculative execution) drive the rates E higher.  That is why a less powerful 4P Itanium 2 beats all other 4P   boxes.  E When on-chip cache goes to 6MByte (Madison) and 12 MByte (Montecito)  5 the transactions per cpu will be driven quite higher.       ------------------------------  % Date: Sun, 27 Oct 2002 08:24:43 +0100 6 From: Arne =?ISO-8859-1?Q?Vajh=F8j?= <arne@vajhoej.dk>) Subject: Re: java on VMS - help requested ) Message-ID: <3DBB94BB.1070901@vajhoej.dk>    Z wrote:  . > Java is supposed to be platform independent. > ; > Why on Earth would you write jave code and tie it to VMS?       * 5 years ago Java was being promoted as the% way to achieve platform independence.   % Today Java is more *the* language for  everything unless you like MS.  % Technically JNI and the like has been $ present in Java from day one, so the" possibility has always been there.   Arne   ------------------------------    Date: 27 Oct 2002 10:29:15 -0800( From: bob@instantwhip.com (Bob Ceculski)H Subject: Re: Rejuvenating OpenVMS [was Re: So I went to the HP IT forum]= Message-ID: <d7791aa1.0210271029.54740f6c@posting.google.com>   ` JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3DBB2985.B45A651@videotron.ca>... > Brian Chase wrote:I > > I think getting OpenVMS back into universities as a general computing K > > platform would be very difficult.  VMS has long since lost its momentum  > > in academia. > L > Unix is a clustering wannabe.  VMS has what Unix will have years from now. > O > Teachers and graduate students currently wouldn't want a legacy system called G > VMS. But what if Digital/Compaq/HP/whetever were to volunteer its VMS L > ambassadors to give lectures on clustering and disaster tlleran issue ? InE > those lectures, obviously VMS' strengths would be used as example.   >  > This will have 2 effects:  > M > -students, graduate students and teachers will find that those lectures are L > giving students information/experience on state of the art clustering thatN > their current unix environmment cannot provide. So those guest lectures willN > provide the univeristy with a more complete curriculum. And give students anJ > edge when they get jobs or start volunteering to ikrpove Linux etc etc.  > M > Having the best clustering system doesn give you any payback unless to make N > sure people know you have the best clustering system. If students don't knowM > VMS is 10 years ahead of Unix in clustering, then students won't tell their H > future employers that the proposed unix solution is far behind VMS for/ > clustering and mission critical applications.  > G > And by prosenting VMS as a stand of the art OS to universities, those M > ambassadors will get a foot in the door and work to change attitudes within 0 > academia to be more open/positive towards VMS. > P > Giving away VMS boxes is pointless if the teachers don't want VMS because theyP > see VMS as a legacy system. Present VMS as something the teachers need to haveI > in order to teach the state of the art, then all of a sudden, VMS gains : > stature and the door starts to open for VMS in academia. > N > Note that I had made such a suggestion/proposal to Compaq some time ago, but& > of course, no response was received.  ? vms is a legacy system ... its been around 25 years now with no ? competition, and it will be around another 25 years ... that's   a heck of a legacy ...   ------------------------------   Date: 27 Oct 2002 14:40:21 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)) Subject: Re: So I went to the HP IT forum 5 Message-ID: <apgtsj$1egcu$1@ID-135708.news.dfncis.de>   = In article <55f85d77.0210262048.35d48f0c@posting.google.com>, , 	P.Young@unsw.EDU.AU (Patrick Young) writes:f > winston@SSRL.SLAC.STANFORD.EDU wrote in message news:<00A16025.D49BA4AA@SSRL04.SLAC.STANFORD.EDU>... >>  O >> The actual text of the license (last time I looked, when it appeared to have O >> been cut and pasted from the hobbyist license text) didn't support this, and 5 >> even said it was specifically for single-user use.  > M > The agreement you posted is also my understanding, however this part is not G > my understanding. We have *always* (going back at least 10 years) run  > multiple users.  > B >> It would be nice for the license to reflect what the FAQ says.  > K > Probably an oversight on someones part. The OPENVMS-ALPHA-USER license is I > certainly a part of the CSLG PAK kit. I *VERY MUCH* doubt that this PAK K > would be included if you were not allowed multiple users (ie: to use this I > PAK). Advanced Server user licenses are not included - we pay for those $ > the same price everyone else does. > 5 >  Authorization:               A1001-CAMPUSWIDE-1929 2 >  Product Name:                OPENVMS-ALPHA-USER# >  Producer:                    DEC ! >  Units:                       0 + >  PAK Termination Date:        30-JAN-2003   H But your talking about two different things here.  The Education ProgramG and CSLG are two totally different things.  CSLG is expensive and there E is no incentive for schools to pay it as there is no percieved value. E For example, my department has a budget of $0 for VMS.  I provide the I equipment from my personal stash and my time setting up and administering H them because I, personally, think it is important for the students to beJ exposed to OSes other than Windows and Unix.  (That's also why I have beenG trying to get in touch with someone at Mentec for a couple of years now E about the possibility of a license grant for PDP OSes, but alas, they C are better at ignoring beople than even Compaq was.)  We used to be E covered by CSLG, paid for by the datacenter and not by my department. H The VAX was dropped.  That means I no longer have licenses that allow meF to open these boxes up to students.  And that means that each year allG these students will go out into the world with no knowledge of even the F existence of VMS.  If I thought we were unique, I would say "so what?"I But I am sure we are not.  I am fairly certain ti is the same at more and E more Universities. And who is the long term looser in this situation?   J If VMS is to survive and especially if it is ever to see even minor growthH it is going to be necesssary to get it back into the minds of the peopleI who make computing decisions.  That starts in school where these decision I makers have their thought processes formed.  A solid education program is F vital.  After all, if BSD had remained locked away at AT&T rather thanI being dumped into every (or nearly every) CS program by BSD would Unix be  what it is today?    bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Sun, 27 Oct 2002 07:19:00 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)% Subject: Timezone-change observations 5 Message-ID: <ErMu9.176047$N_6.2542849@news.chello.at>   B Because summertime ended today, I thought I share my observations.  9 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! ( 	I'm running VMS V7.3 and TCPware V5.6-2G 	but no longer DECdts (which made perfect timezone changes for years !)   7 2) VMS timezone logicals showed correct values on Alpha 2 	but showed wrong (still summertime) values on VAX9 	(just like as there happened no timezone change on VAX - 6 	which seems logical [but unacceptable] as there is no, 	AUTO_DLIGHT_SAV parameter in SYSGEN on VAX)   	SYS$TIMEZONE_DAYLIGHT_SAVING  	SYS$TIMEZONE_DIFFERENTIAL 	SYS$TIMEZONE_NAME  7 3) TCPWARE_TIMEZONE_NAME Logical contained wrong values / 	("MET-DST" instead of "MET") on both platforms < 	while TCPWARE_TIMEZONE Logical contained the correct values    6 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula  ' 		"MET-1MET DST-2,M3.5.0/02,M10.4.0/03" 
 instead of' 		"MET-1MET DST-2,M3.5.0/02,M10.5.0/03"    while on VAX% 		"MET-1MET_DST-2,M3.5.0/2,M10.5.0/3"   D I saw this (and another) bug in DECdts some years ago for some yearsJ but it is - at least in DECdts - fixed for some years now. It surprises meH that such a bug reappears in VMS timezones now. And why only on Alpha...  > 5) One still needs to fix TCPware startup files as there is in TCPWARE:TCPWARE_CONFIGURE.COM    	$ NETCU_TIMEZONE  == "+0200" # 	$ NETCU_TIMEZONE_NAME == "MET-DST" # 	$ NETCU_TIMEZONE_RULES == "EUROPE"   G Which seems silly, because a fixed timezone value and name doesn't make N sense while there is an automatic change (TCPWARE_TIMEZONE_RULES) implemented.   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 27 Oct 2002 09:48:45 +0100 $ From: Michael Unger <unger@decus.de>) Subject: Re: Timezone-change observations * Message-ID: <00A16126.815CA431.1@decus.de>  1 "Peter LANGSTOEGER" <peter@langstoeger.at> wrote:   D > Because summertime ended today, I thought I share my observations. >  > [...]  > 8 > 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula > ' > "MET-1MET DST-2,M3.5.0/02,M10.4.0/03"  > instead of' > "MET-1MET DST-2,M3.5.0/02,M10.5.0/03"  >  > while on VAX% > "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3"  > F > I saw this (and another) bug in DECdts some years ago for some yearsL > but it is - at least in DECdts - fixed for some years now. It surprises meJ > that such a bug reappears in VMS timezones now. And why only on Alpha... >  > [...]     ; Just to add the POSIX compliant time zone specification ...      FORMAT  D      <std><offset>[<dst>[<offset>][,<start>[/<time],<end>[/<time>]]]   where:  B      <std>           Is the designation for the standard time zone1                      (min 3 chars - max 10 chars)   <      <dst>           Is the designation for summer time zone1                      (min 3 chars - max 10 chars)   J      <offset>        Indicates the value one must add to the local time toE                      obtain the Universal Coordinate Time (UCT).  The 7                      <offset> has the following format:   .                              [+|-]hh[:mm[:ss]]                        where: J                              [+|-]   Is the sign.  The minus sign (-) mustK                                      be present if the time zone is east of 8                                      the Prime Meridian.*                              hh      Hours,                              mm      Minutes,                              ss      Seconds  L      <start>         Is the date when summer time starts.  The <start> field4                      can be in the following format:  9                      Jn      The Julian day n (1<=n<=365) D                      n       The zero-based Julian day n (0<=n<=365)D                      Mm.n.d  The day d of the week n of the month m,#                              where: 3                              0<=d<=6; d=0 is Sunday M                              1<=n<=5; n=5 means the last d day in the month m K                                       n=1 means the first week in which the 9                                           d'th day occurs 5                              1<=m<=12; m=1 is January   H      <end>           Is the date when summer time ends.  The <end> field>                      has the same format as the <start> field.  F      <time>          Describes when, in current local time, the changeI                      to the other time is made.  The <time> field has the F                      same format as the <offset> field except that the)                      sign is not allowed.     G (extracted from the file POSIX$LOCALIZATION.COM a long time ago ... :-)      Michael    ------------------------------  % Date: Sun, 27 Oct 2002 10:18:52 +0100 ) From: Bart Zorn <B.Zorn@xs4all.nospam.nl> ) Subject: Re: Timezone-change observations * Message-ID: <apgb1t$374$1@news1.xs4all.nl>   Peter LANGSTOEGER wrote:D > Because summertime ended today, I thought I share my observations. > ; > 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! * > 	I'm running VMS V7.3 and TCPware V5.6-2I > 	but no longer DECdts (which made perfect timezone changes for years !)  > 9 > 2) VMS timezone logicals showed correct values on Alpha 4 > 	but showed wrong (still summertime) values on VAX; > 	(just like as there happened no timezone change on VAX - 8 > 	which seems logical [but unacceptable] as there is no. > 	AUTO_DLIGHT_SAV parameter in SYSGEN on VAX) >  > 	SYS$TIMEZONE_DAYLIGHT_SAVING  > 	SYS$TIMEZONE_DIFFERENTIAL > 	SYS$TIMEZONE_NAME > 9 > 3) TCPWARE_TIMEZONE_NAME Logical contained wrong values 1 > 	("MET-DST" instead of "MET") on both platforms > > 	while TCPWARE_TIMEZONE Logical contained the correct values >  > 8 > 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula > ) > 		"MET-1MET DST-2,M3.5.0/02,M10.4.0/03"  > instead of) > 		"MET-1MET DST-2,M3.5.0/02,M10.5.0/03"  >  > while on VAX' > 		"MET-1MET_DST-2,M3.5.0/2,M10.5.0/3"  > F > I saw this (and another) bug in DECdts some years ago for some yearsL > but it is - at least in DECdts - fixed for some years now. It surprises meJ > that such a bug reappears in VMS timezones now. And why only on Alpha...  I I was surprised too. In 2002 and in 2003 it makes no difference. In 2004   it does.  D I did the test. I set my Alpha workstation clock to 20-oct-2004 and  rebooted. (It runs DTSS)  ( The result is amazing. The timezone was 5 "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3", as it should be.   F It seems that the rule as you see it, gets CALCULATED. However, to be I able to calulate it, I expect that there is a RULE somewhere. I have not  B been able to find this rule, yet. However, it seems to be correct.  F A rule to calulate a rule: it really takes brains to invent something 
 like that.  E And VAXen do it differently? I believe DECnet-Plus and its ancestors  H were developed on Alpha and then ported to VAX. Maybe they removed this  nonsense during porting.     > @ > 5) One still needs to fix TCPware startup files as there is in > TCPWARE:TCPWARE_CONFIGURE.COM  >  > 	$ NETCU_TIMEZONE  == "+0200" % > 	$ NETCU_TIMEZONE_NAME == "MET-DST" % > 	$ NETCU_TIMEZONE_RULES == "EUROPE"  > I > Which seems silly, because a fixed timezone value and name doesn't make P > sense while there is an automatic change (TCPWARE_TIMEZONE_RULES) implemented. >     	 Bart Zorn    ------------------------------  # Date: Sun, 27 Oct 2002 09:33:22 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)) Subject: Re: Timezone-change observations 5 Message-ID: <CpOu9.176732$N_6.2570846@news.chello.at>   Q In article <00A16126.815CA431.1@decus.de>, Michael Unger <unger@decus.de> writes: 2 >"Peter LANGSTOEGER" <peter@langstoeger.at> wrote: > E >> Because summertime ended today, I thought I share my observations.  >> >> [...] >>9 >> 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula  >>( >> "MET-1MET DST-2,M3.5.0/02,M10.4.0/03"
 >> instead of ( >> "MET-1MET DST-2,M3.5.0/02,M10.5.0/03" >> >> while on VAX & >> "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3" >>G >> I saw this (and another) bug in DECdts some years ago for some years M >> but it is - at least in DECdts - fixed for some years now. It surprises me K >> that such a bug reappears in VMS timezones now. And why only on Alpha...  >> >> [...] > < >Just to add the POSIX compliant time zone specification ... >  >FORMAT  > E >     <std><offset>[<dst>[<offset>][,<start>[/<time],<end>[/<time>]]]    which doesn't explain why   A a) the timezone name is once "MET_DST" and another time "MET DST" @ b) the bug with 4th instead of last sunday in October reappearedJ c) the rule on Alpha contains zeroes at the 'time' ("/03" and on VAX "/3")   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Sun, 27 Oct 2002 09:50:34 GMT . From: peter@langstoeger.at (Peter LANGSTOEGER)) Subject: Re: Timezone-change observations 5 Message-ID: <KFOu9.176811$N_6.2570846@news.chello.at>   V In article <apgb1t$374$1@news1.xs4all.nl>, Bart Zorn <B.Zorn@xs4all.nospam.nl> writes:E >I did the test. I set my Alpha workstation clock to 20-oct-2004 and   >rebooted. (It runs DTSS)   F As I already wrote, DTS does make things really different (and correct  for me in the last say 5 years).  ) >The result is amazing. The timezone was  6 >"MET-1MET_DST-2,M3.5.0/2,M10.5.0/3", as it should be.  E DTS timezones come from the SYS$SYSTEM:DTSS$TIMEZONE_DIFFERENTIAL.DAT = which are once setup from SYS$UPDATE:DTSS$TIMEZONE_RULES.DAT.   F There once was an error in SYS$UPDATE:DTSS$TIMEZONE_RULES.DAT (with /2G instead of /3 and 4 instead of 5 and also 9 instead of 10 when timezone K switch did no longer happen in september as it used to be the years before) H and was fixed with an ECO some years ago. But one had to REDO THE CONFIGI (IIRC with SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM) to get the new rule K from SYS$UPDATE:DTSS$TIMEZONE_RULES.DAT to the actually used during startup H SYS$SYSTEM:DTSS$TIMEZONE_DIFFERENTIAL.DAT (or as I did. years before theH ECOs arrived, fix the bugs by hand in all DTSS$TIMEZONE_DIFFERENTIAL.DAT? files and while you are there also in DTSS$TIMEZONE_RULES.DAT).   G >It seems that the rule as you see it, gets CALCULATED. However, to be  J >able to calulate it, I expect that there is a RULE somewhere. I have not C >been able to find this rule, yet. However, it seems to be correct.   G Without DTS there is a SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM] which contains F the timezone rulefiles and you select the correct one with the name of' your timezone you entered during setup.   B   "SYS$LOCALTIME" [exec] = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]MET."  G >A rule to calulate a rule: it really takes brains to invent something   >like that.   9 I do believe you get something mixed. Please check again. D But maybe HPQ did the mixture when they introduced the SYS$LOCALTIME one or two VMS versions ago...  F >And VAXen do it differently? I believe DECnet-Plus and its ancestors I >were developed on Alpha and then ported to VAX. Maybe they removed this   >nonsense during porting.    Not that I'm aware of.G DECnet-Plus had DECdts from day one on both platforms and they did work ? identical on each platform. At least due to my observations ;-)   C It's the new SYS$LOCALTIME and the AUTO_DLIGHT_SAV which is new and L unfortunately different on VAX and Alpha. On VAX there is no AUTO_DLIGHT_SAV   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 27 Oct 2002 17:50:10 +0100 $ From: Michael Unger <unger@decus.de>) Subject: Re: Timezone-change observations * Message-ID: <00A16169.C2402D33.6@decus.de>  1 "Peter LANGSTOEGER" <peter@langstoeger.at> wrote:   : > In article <00A16126.815CA431.1@decus.de>, Michael Unger <unger@decus.de> writes:4 > >"Peter LANGSTOEGER" <peter@langstoeger.at> wrote: > > G > >> Because summertime ended today, I thought I share my observations.  > >>
 > >> [...] > >>; > >> 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula  > >>* > >> "MET-1MET DST-2,M3.5.0/02,M10.4.0/03" > >> instead of * > >> "MET-1MET DST-2,M3.5.0/02,M10.5.0/03" > >> > >> while on VAX ( > >> "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3" > >>I > >> I saw this (and another) bug in DECdts some years ago for some years O > >> but it is - at least in DECdts - fixed for some years now. It surprises me M > >> that such a bug reappears in VMS timezones now. And why only on Alpha...  > >>
 > >> [...] > > > > >Just to add the POSIX compliant time zone specification ... > > 	 > >FORMAT  > > C > > <std><offset>[<dst>[<offset>][,<start>[/<time],<end>[/<time>]]]  >  > which doesn't explain why  > C > a) the timezone name is once "MET_DST" and another time "MET DST" B > b) the bug with 4th instead of last sunday in October reappearedF > c) the rule on Alpha contains zeroes at the 'time' ("/03" and on VAX "/3")   P It just wasn't meant as an explanation of bugs, only as a general specification.    I Having read the other specification from DTSS again (see below) I suppose   L a) a space character within any part of the specification is NOT allowed, so! "MET DST" seems to be a real bug;  b) ?; M c) "One or more digits may be used", so both formats of the specification are  valid.     SYS$TIMEZONE_RULE format:   =  <std><offset>[<dst><offset>,<start>[/<time>],<end>[/<time>]]   B  <std> and       Three or more characters that are the designation@  <dst>           for the standard (<std>) or summer (<dst>) timeC                  zone. Only <std> is required; if <dst> is missing, @                  then summer time does not apply in this locale.<                  Upper- and lowercase letters are explicitlyD                  allowed. Any characters except digits, comma (","),B                  minus ("-"), plus ("+"), space, and ASCII NUL are                  allowed.   =  <offset>        Indicates the value to be added to the local >                  time to arrive at Coordinated Universal Time.+                  The <offset> has the form:   !                      hh[:mm[:ss]]   @                  The minutes (mm) and seconds (ss) are optional.>                  The hour (hh) is required and may be a singleA                  digit. One or more digits may be used; the value @                  is always interpreted as a decimal number.  TheB                  hour must be between zero and 24, and the minutesD                  (and seconds) -- if present -- between zero and 59.B                  If preceded by a "-", the timezone is east of the@                  Prime Meridian; otherwise it is west (which may<                  be indicated by an optional preceding "+").  A  <start> and     Indicates when to change to and back from summer ?  <end>           time. Start describes the date when the change <                  from standard to summer time occurs and endA                  describes the date when the change back happens. ?                  The format of start and end must be one of the                   following:   =                  Jn      The Julian day n (1 < n < 365). Leap ;                          days are not counted.  That is, in =                          all years -- including leap years -- =                          February 28 is day 59 and March 1 is ;                          day 60. It is impossible to expli- =                          citly refer to the occasional Febru-                            ary 29.  ;                  n       The zero-based Julian day (0 < n < <                          365). Leap days are counted, and it=                          is possible to refer to February 29.   =                  Mm.n.d  The nth d day of month m (1 < n < 5, <                          0 < d < 6, 1 < m < 12). When n is 5=                          it refers to the last d day of month ,                          m. Day 0 is Sunday.  =   <time>         The <time> field describes the time when, in @                  current time, the change to or from summer time?                  occurs. <Time> has the same format as <offset> E                  except that no leading sign (a minus sign ("-") or a D                  plus sign ("+")) is allowed. The default, if <time>+                  is not given, is 02:00:00.   >   As an example, if the logical name SYS$TIMEZONE_RULE had theA   value EST5EDT4,M4.1.0,M10.5.0 it would describe the rule, which @   went into effect in 1987, for the Eastern timezone in the USA.?   Specifically, EST would be the designation for standard time, @   which is 5 hours behind GMT.  EDT would be the designation forC   DST, which is 4 hours behind GMT.  DST starts on the first Sunday B   in April and ends on the last Sunday in October.  In both cases,>   since the time was not specified, the change to and from DST/   would occur at the default <time> of 2:00 AM.     A (POSIX compliant timezone specification rules extracted from file . SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM ...)     Michael    ------------------------------   End of INFO-VAX 2002.594 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  @z    Az    Bz    Cz    Dz    Ez    Fz    Gz    Hz    Iz    Jz    Kz    Lz    Mz    Nz    Oz    Pz    Qz    Rz    Sz    Tz    Uz    Vz    Wz    Xz    Yz    Zz    [z    \z    ]z    ^z    _z    `z    az    bz    cz    dz    ez    fz    gz    hz    iz    jz    kz    lz    mz    nz    oz    pz    qz    rz    sz    tz    uz    vz    wz    xz    yz    zz    {z    |z    }z    ~z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z    z     {    {    {    {    {    {    {    {    {    	{    
{    {    {    
{    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {     {    !{    "{    #{    ${    %{    &{    '{    ({    ){    *{    +{    ,{    -{    .{    /{    0{    1{    2{    3{    4{    5{    6{    7{    8{    9{    :{    ;{    <{    ={    >{    ?{    @{    A{    B{    C{    D{    E{    F{    G{    H{    I{    J{    K{    L{    M{    N{    O{    P{    Q{    R{    S{    T{    U{    V{    W{    X{    Y{    Z{    [{    \{    ]{    ^{    _{    `{    a{    b{    c{    d{    e{    f{    g{    h{    i{    j{    k{    l{    m{    n{    o{    p{    q{    r{    s{    t{    u{    v{    w{    x{    y{    z{    {{    |{    }{    ~{    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    {    