Latest News on the Date Bug HP has sent a letter to all support customers explaining the date bug and available remedies. The bad news is that the fix is unavailable for any Apollo node released before the dn3000 or for those still running sr9.7. The good news is that it's not as serious as we thought. You can find the full text of the letter at: http://www.interworks.org/Tech/apollonov2/ (US) http://iworks.erls02.siemens.de/Tech/apollonov2/ (Europe) -- Here is a piece I wrote some time ago before all the facts were in, and before the current set of patches was available. Date Bug Bites by Jim Rees , University of Michigan Sun, 11 Aug 1996 -- Around April First of this year reports started circulating in the Apollo Usenet newsgroup of a "date bug" in Domain/OS that would render all Apollo workstations useless after November 2, 1997. Given the proximity to April Fool's Day and recent horror stories involving the "Millenium Bug" (software unable to cope with dates in the 21st century and costing billions of dollars to fix), most people dismissed these reports as a hoax. Unfortunately the reports were at least partly true. One user has reported that setting the clock past November 1997 and trying to boot fails with "UNABLE TO MAP `NODE_DATA/STACK -- 40001." The bug apparently results from the high 32 bits of the clock data type being declared as a 31 bit value instead of 32 bit in the pascal include files. The reason for this is lost to history, but early pascal compilers may have had problems with 32 bit unsigned numbers, possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations. The bug will cause problems when the high bit (not the "penultimate bit," as the patch description says) becomes set at 14:59 GMT on November 2, 1997. A letter from HP to customers on maintenance contracts said that, "The 9601 Domain patch kit... repair[s] a timer defect which caused the system to malfunction in a variety of ways after November 2, 1997." A search on the HP Supportline web server (free to all, not just customers on support contracts) turns up 11 patches related to 1997. After stripping out the duplications for various versions of Domain/OS, the problem software seems to be domain_os, /lib/kslib, and the d3m, mbx, and alarm servers. Although the letter from HP says "each patch bundle... is supported on all SAU types," the patch does not include a domain_os for any machine type below sau7 or for any version of domain_os before sr10.3.5, so the fix is not available for any Apollo node released before the dn3000 or for those still running sr9.7. One possible solution for users of older machines or software would be to set the clock back to a date before November 1997. Other than the obvious problems of having wrong date stamps on everything from file modification attributes to email headers, there are two potentially serious problems with this. One is that if you have two nodes on your network with serious time skew between them, some network protocols will not work. The other is that you will run the risk of getting duplicate file uids, which may result in file system corruption. If you do get the 1997 patch, or any other patch, from the HP Supportline web site, you should be aware of a couple of problems. First, what you get isn't the patch itself, it's a uuencoded compressed wbak file with a lame uudecoder tacked to the front. So you'll first have to trim the garbage, then uudecode, then uncompress. None of this is mentioned on the page that describes the patch. Also, the "rbak" command given is wrong. The correct command is: rbak -l -all -ms -pdt -from PD9X_XXXXX -as //aa_node/install One user reports that using the "rbak" command given by HP left his node unbootable. As November 1997 approaches, those of us with older Apollo nodes will be faced with the unpleasant choice of either taking the risk of setting the clock back, or sending our equipment to the scrap dealer. HP has so far not shown any interest in helping us with this choice. -- P.S. szabo_p@maths.su.oz.au (Paul Szabo) reports: they managed to release a bad patch: installing it, cal_$encode_time or similar fails in any September, or on the 5th of any month, or at 6am of any day... -- From: lbayuk@delphi.com Subject: cal_$encode_time fix for kslib patch Date: Sun, 8 Sep 96 21:52:47 -0500 As has been reported by psz@maths.usyd.edu.au and tomb@badgers.demon.co.uk, the Domain/OS patches to fix the 11/2/97 problem broke cal_$encode_time for many dates, including the 5th of every month. I've seen no HP fix yet. The problem does not seem to affect much system software; the only case I found was where e.g. "/com/ld -moa 90/8/5.10:00" finds no files due to the bug. Nevertheless, I offer the following 1-byte patch for those brave enough to patch system code. Caution: proceed at your own risk, and be absolutely sure you are patching the same version as me. File: /lib/kslib (from pd96_m0739) 122,244 bytes Timestamp=12/12/95 (Note the timestamp does not match that given in the 9601 document.) Procedure: (# and ! are prompts, () enclose comments) # cd /lib # cp kslib kslib.patch # /com/db ! ma kslib.patch 1DD84 bytes mapped at XXX ! ab XXX+0CFD1 (Where XXX is where it mapped) (db prints:) 8 (and leaves cursor there. Enter:) 54 / ! q # mv kslib kslib.orig # mv kslib.patch kslib (reboot) Explanation: In the kslib released with SR10.4.1, cal_$encode_time returned an error value (fff7ffff ffff) for any year > 2013. Patch pd96_m0739 fixes cal_$sub_clock to work with unsigned instead of signed values, to fix a problem after 11/2/97. But for some reason the patch also includes a "fix" to cal_$encode_time. The fix tries to squeeze out more valid dates by making dates up to 9/5/2015.05:58:26 valid. But the logic is wrong. The check for (year >= 2015) is independent of the checks against the month and day. The code in pd96_m0739 probably looks something like this: if (year > 2015) ERROR if (year == 2015 && month > 9) ERROR if (month == 9 && day > 5) ERROR if (day == 5 && hour >= 5) ERROR ... After applying the above 1-byte patch, the logic looks like this: if (year > 2015) ERROR if (year == 2015) { <<= This is the branch offset I changed if (month > 9) ERROR ... } -- Bad news: HP Supportline is going away for unregistered users at the end of February, 1997. Grab the patch now if you need it.