HP1000/RTE

HP has made every effort to ensure the accuracy of our product testing. However, because each customer's environment is different from HP's laboratory test environment, it is the customer's responsibility to validate the Year 2000 readiness of these products in their own environment. Therefore, information about the Year 2000 status of HP products is provided "as is" without warranties of any kind and is subject to change without notice. HP makes no representation or warranty respecting the accuracy or reliability of information about non-HP products. Such information, if any, was provided by the manufacturers of those products and customers are urged to contact the manufacturer directly to verify Year 2000 readiness. The information provided here constitutes a Year 2000 Readiness Disclosure for purposes of the Year 2000 Information and Readiness Disclosure Act.

HP 1000 y2k product status

» summary of RTE Products, and their Y2K status
» testing results and older Operating Systems

Overview

The purpose of this document is three-fold. First, to explain how the HP1000 maintains time, second to discuss what problems one may expect to encounter and the solutions HP offers, and third to provide information about the Y2K status of HP 1000 (RTE) software.

First of all, the HP1000 (with the exception of the A990's TOD clock) 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 and even older systems as we gather information on them.

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.

» OS details on the $TIME+2 values

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 was December 1,1981. But in 1983, in the 2301 release, the RTE-6 generator was changed to put the current time and date of the system that the generator was running on into the newly generated system as the default startup time and date.)

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 for RTE-A but was not incorporated into RTE-6 until 6.2.

   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.

   (Note: FTIME is the primary routine that causes older systems (RTE-2, RTE-3, RTE-4A, RTE-4B, and pre 6.2 RTE-6) to format date strings incorrectly in the next millennium. A patch has been made available that corrects the problem with pre 5.0 versions of FTIME. This patch can also be used with RTE-2, RTE-3, RTE-4A & 4B by relocating it with applications that call it.)

2. EDIT/1000's internal timestamp is also afflicted by a similar problem as FTIME above. It will display ":0" for the year 2000 as the year portion of the timestamp. This also disables the timestamping ability of EDIT/1000 as the "timestamp" is no longer recognized as one by EDIT/1000.

   This problem was fixed in EDIT itself at 6.2.

3. 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

4. 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...
   

   (Note: In pre 5.1 (5010) RTE-6 systems the SETTM routine would not allow setting of the date past 1999. This only affected the CI TM command as FMGR (:SYTM) and the System command (*TM) does not use SETTM.)

5. 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 or use the touch program to do so.

   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.

6. 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

7. EDIT/1000's internal timestamp feature only displays 2 digits for the year. Thus starting in the year 2000, the timestamp will be <000101.0000>.
   

   This will not be changed, due to possible adverse impact on existing code.

8. Similar in format to the EDIT/1000 timestamp is the string returned from the routine NumericTime. The format of this routine, yymmdd.hhmmss, also only includes a 2 digit year and will "roll" to "00" in the year 2000. Applications that use this routine should be wary of this and check how the output of this routine is utilized.

   This will not be changed, due to possible adverse impact on existing code.

9. 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.