Subject: RE: brief remarks on today's Y2K test
From: Christopher Orth (corth@budoe.bu.edu)
Date: Fri Dec 17 1999 - 11:05:14 EST
Hi all,
I didn't have as much luck as Mario, but I haven't tracked down
where the problems I've had are occuring. My platform is Solaris on a 64
bit RISC processor, and I'm testing Alec's WFD DREAM plus my changes, as
well as my FARFALLA dst production code. Both have strange problems.
Perhaps suprisingly to some, the FARFALLA code seems more robust.
It runs ok, but DREAM reports a "Missing UTC equipment" for all but the
first few events in the second run performed. (For those that don't use
FARFALLA, the dst production is exactly like "normal" dream job except
that the routine DUSER is replaced with a C++ routine that handles the
calls to FARFALLA routines) Also, DSAGET reports an error condition when
asked for the number of slow tracks (any type) in the event.
My FORTRAN-only code reports bogus RUN and EVENT numbers (often
all ****** due to overflowing the space allotted in the FORMAT).
While none of these problems have to do with Y2K per se, and I'll
be the first to admit that they are probably at least in part caused by
something I added, it is interesting to note that when I run on older
non-Y2K raw data on disk I have NONE of the above problems. So this is
probably my FAVORITE case of bugs causing other bugs to appear.
I wasn't going to say anything until I had time to look into these
matters further, but Mario's annoying success 8-) made me feel like it was
my duty to warn people they might not be as lucky. Perhaps the difference
is calling ERP decoding, as Mario might not have enabled this by default
and the ERP routines have known Y2K issues. (?)
As to Mario's comment about "1900": I read on VXMACB that a fix
was introduced into routine DRHEAD. It looks like this fix is essentially
to change the "year" from:
HEAD(12) = YEAR-1900
to:
HEAD(12) = MOD((YEAR-1900),100)
This is NOT EXACTLY what is written in the code, but the effect is
the same. This fix maps 2001 to "1" instead of "101". It seems to me
that just leaving this "bug" in place would have been better, as time
differences and Julian dates for year >= 2000 calculated later in other
routines would already have a 100 year offset, which is good (I thought
the "usual" Y2K fix was to STOP using 2 digit represenations for year).
It also seems to me that the ONLY thing that the above fixes is for
cosmetic things like printing the year as two digits. Is there another
reason why this fix was made, such as some sort of bit packing in data
written to disk? Note, I don't claim that not applying this fix is going
to help fix every Y2K problem in the code.
That all for now,
Chris Orth
On Fri, 17 Dec 1999, Flectar non frangar wrote:
> L.N.G.S.,Assergi, 17-DEC-1999
>
> Thanks a lot for your informatipon. I have a little remark though:
> during the Y2K test, the UTC slave displays showed correctly the time,
> the day and the month, but the year was 1900 instead of 2000. Also the
> Julian day was something like (I cite by memory) ~41000 while in real
> time (I mean yesterday) it is something like ~59000 (actually I remember
> exactly only the first figure "4" instead of "5", maybe the guys in the
> tunnel remember better than me).
>
> Ciao
> Mario
>
>
> _____________________________________________________________________
> /\ Laboratori Nazionali del Gran Sasso \
> \_| Mario Sitta sitta@lngs.infn.it |
> | The MACRO Experiment http://www.al.unipmn.it/~sitta/ |
> | |
> | |
> | It is more important to have beauty in one's equations |
> | than to have them fit experiments. |
> | Paul Adrian Maurice Dirac |
> | ________________________________________________________________|___
> \_/___________________________________________________________________/
>
This archive was generated by hypermail 2a24 : Fri Dec 17 1999 - 11:05:25 EST