From: HP REAL-TIME SUPPORT DATE: 970221.1205 Subject: HP Real-Time TechNotes Report Number 9708 ------------------------------------------------------------------------- **HP 1000 Corner** Table of Contents (1) Year 2000 concerns for RTE -------------------------------------------------------------------------- -------------------------------------------------------------------- + ___ ___ ___ ___ __ __ ___ __ ___ + + /__/ /__/ / / / / / / / / / / /__/ /\ / /__ /__/ + + / / / / /__/ /__/ /__/ /__ /__/ / \ / \/ /__ / \ + + + -------------------------------------------------------------------- (1) Year 2000 concerns for RTE by Walt Boeninger <19970220.1400> There has been a lot of discussion in the news lately about how many computers will have major problems dealing with the year 2000. The purpose of this article is two-fold. First to explain how the HP1000 maintains time, and second to discuss what problems one may expect to encounter and the solutions. First of all, the HP1000 has no inherent problem with the year 2000. Over the years, there have been several time related problems that have been corrected as they were encountered. What we will try to do in this article is describe what these problems are, what they affected and when they were fixed. This is in no way a comprehensive list, and certainly there could be unknown problems with different subsystems. The focus of this article will be RTE-A, since RTE-6 has no official support beyond 1999. When possible, we will make comparisons to RTE-6. First some background on how time is managed in RTE-A. All A Series CPUs have a Time Base Generator that 'ticks' every 10 milliseconds. These 'ticks' are accumulated in system entry point $TIME (and $TIME+1) as a double-integer. This value is then interpreted as the negative number of centiseconds until midnight. Entry point $TIME+2 is a second accumulator which counts the number of days since Jan 1, 1976. (In RTE-6, this is Jan 1, 1970) This value is then converted into the appropriate month-day-year when needed. This theoretically means the maximum year in RTE-A is 2065, or 2155 if we treat $TIME+2 as a unsigned integer. File system timestamps are stored as double-integer values in the file's directory entry. This double-integer number is the number of seconds since 1970. This is the same in both RTE-A and RTE-6, for compatibility. So the maximum year for a file's timestamp is 2,147,483,647 seconds/(60*60*24*365) = approximately 2037. File Manager and type 0 files, (which have no actual timestamps) will appear with a timestamp of Jan 1,1970 when viewed by a program like FST which stores timestamps. As you can see, the maximum year for RTE and the file system is not the same, because of the way the information is stored. And it should be apparent that this scheme has no inherent problem when the year 2000 rolls around. The problems that have existed were caused by the interpretation of these numbers. And this inconsistency led to one of the problems we'll see later. Another date that appears in RTE-A is April 1, 1983. This is the release date of the original RTE-A (Previous versions of RTE-A were known as A.1) RTE-A introduced the hierarchical file system, CI and Code and Data Separation (CDS, which was sold as a separate product from RTE-A, called VCPLUS). When an RTE-A system is booted, the default startup time is April 1, 1983. This date is placed in $TIME+2 by the RTE-A Generator program. Thus if one forgets to set the time on bootup, the clock starts at 12:00:00 AM on April 1, 1983. (For RTE-6 this date is December 1,1981. But sometime in the 1980's, this startup date was changed to be the current system time when the RTE-6 generator was run.) So what are the problems that have been encountered? Actually, they are very few in number. We will list these in order of apparent severity (our choice!) 1. Library routine FTIME, which is called to return the formatted ASCII time, was broken for the year 2000 and above. It was originally coded using 1900 as a hardcoded base. This caused FTIME to return the year as 19:0 for the year 2000, 19:1 for 2001 and so on. This was fixed in release 5.0. If you are using a release prior to 5.0, the easiest workaround is to simply relink any programs that call FTIME, and relocate a later version of FTIME from $BIGLB. This can be done in link as follows: link: RM,/Newer_libraries/$BIGLB.LIB,FTIME This will relocate just the module FTIME. The version of $BIGLB can be anything up to 6.2. 2. Prior to the 6.2 release of RTE-A, the time setting routine found in &TIME allowed the system time to be set to years up to 2144. Obviously, this was inconsistent with the file system max year. So as of 6.2, the TM command will only allow years from 1976 through 2037. Not normally a problem, since one wouldn't normally set the system time incorrectly. But if it is set incorrectly, it will cause FMP problems... 3. Years beyond 2037 are not valid for FMP timestamps. If the system time is set to a year beyond 2037, and a file is updated or created, certain masking functions will fail. Typical symptom is a DL will not find the file, yet EDIT or LI will display the file. The solution is to 1) Don't set the time incorrectly and 2) if you do, then reset the time correctly, and copy the file to update the timestamp. While on the subject of masking: We have tested timestamps in masks and as of 6.2 have not discovered any problems using date ranges in the year 2000+ range. This is not to say that earlier releases did not have a problem, we just are not aware of any. 5. There is a routine called DAYS70, contained in module &DLIB2 which failed for years 2000+. This routine is only used by MACRO, and thus should not be a major concern. This was fixed at revision 6.2 6. Two PASCAL routines, PAS.TIMESTAMP and PAS.TIMESTRING, do not handle the year 2000 correctly. This affects WH and LANVCP. This was fixed at revision 6.2 7. EDIT/1000's internal timestamp is also afflicted by a similar problem as FTIME above. It will display ":0" as the year for the year 2000 and so on. This problem was fixed in EDIT itself at 6.2. 7a. EDIT/1000's internal timestamp feature only displays 2 digits for the year. Thus starting in the year 2000, the timestamp will be <000101.000>. This will not be changed, due to possible adverse impact on existing code. 8. Now we're down to the really minor problems. The 6.0 Programmer's Reference Manual states that SETTM has a upper limit of 1999. This is incorrect, as the limit was really 2144. Of course that limit was subsequently made 2037 (at 6.2) to match FMP timestamps. Documentation was updated at revision 6.1. And now a word about Leap Year. Everyone knows that leap year occurs every four years, when the year is divisible evenly by 4. Thus the year 2000 is a leap year by this simple rule. But, there is a secondary leap year rule that states if the year is divisible by 4 AND by 100, then it is NOT a leap year. Thus 1900 was not a leap year and it follows that 2000 should not be a leap year. Many people are not aware of the Divide-By-100 rule. And even less are aware of the Divide-By-400 Rule: If the year is divisible by 400, then it is a leap year. This over rules the Divide-By-100 rule. Confused? Let's do it in FORTRAN: if (mod(year,4).eq.0) then if (mod(year,100).ne.0.or.mod(year,400).eq.0) then LeapYear = .TRUE. endif endif So the bottom line is: The year 2000 is a leap year, and RTE-A treats it as such. Other subsystems which have been tested to some degree include: FORTRAN - Fortran does not have intrinsic time/date routines. However, the date printed on the listings will roll to 1900 after the year 2027. BASIC - Routines TIMEDAY and TIMESTRING have been tested in the year 2010 - They worked fine. C - not tested yet Image-II - Only has two date functions, DATE and EDATE which both use a four digit year and have been tested to December 31 2037. It is our feeling that one of the largest impacts of the year 2000 may involve custom or third party application code that only uses two digits for the year. Obviously, when the year 2000 occurs the "number" will roll from 99 to 00 and all sorting using this number will fail when mixed with numbers before the year 2000. Note: This article is meant as a living document, and as such will be available on the RTE/HP1000 Web site at: http://www.hp.com/computing/rte Check the Web for future updates to this article. The Real-Time TechNotes is an email message sent from factory support to field entities discussing the latest HP 1000 and HP-RT issues. Real-Time TechNotes articles are uploaded to the HP Systems forum of CompuServe as a service to real-time subscribers. Email with comments or suggestions for future articles should be sent to donp@cup.hp.com (CompuServe email address: INTERNET:donp@cup.hp.com).