Concurrent 3200 Systems and the year 2000
This document was originally issued in May 1997. This May 1998 revision provides some updated information.
Handling the year 2000 in OS/32
Handling the year 2000 in Reliance
This paper documents the status of Concurrent 3200 systems with regards to the handling of the year 2000 problem. Reliance and Cincom's TOTAL database are also covered.
Note that this paper covers only the OS/32 operating systems, Reliance and TOTAL. It does NOT address the problems associated with two digit date fields embedded in user written applications and application data files. However, the discussion of near/long past/future dates in the Reliance section will be useful to customers who need to modify application code and perhaps data file formats.
The following table summarizes the options:
In looking at this issue one must break OS/32's handling of the year 2000 into three areas:
the OS/32 operating system itself;
the utilities such as BACKUP, FASTBACK, etc. that are part of the OS/32 object package; and
For customers wanting a simple and reliable solution, the answer is to use OS/32 R09-02 or later. In these releases both the operating system itself and the utilities correctly handle year 2000 dates. Of course customers will have to identify and modify any applications of their own which compare two dates or display a four digit year.
If the customer is using a release older than R08-03, the only option is to upgrade. Not doing so will result in corrupted dates for any files created or accessed on or after 1 January 2000. Because of the nature of how these dates are corrupted, a user of the system may not be aware of the problem for some time.
Furthermore, the date dependent facilities in the BACKUP, FASTBACK and FASTCOPY utilities (such as the DELETE, BEFORE, SINCE, ARCHIVE, CHECKTAPE, and KEEPFILES options) will not function as expected after 1 January 2000. The most pronounced problems will occur when performing a restore operation with BACKUP or FASTBACK.
The OS/32 R08-03 release was the first that supported the year 2000. However, the utilities in R08-03 and R09-01 do not support the year 2000 (see section OS/32 R08-02 and older). If the customer is using revision R08-03 or R09-01, and for whatever reason feels that they do not want to upgrade to R09-02 or R10-01, an option does exist. Concurrent has released a version of the R10-01 utilities called the OS/32 Enhanced Utilities package. These will run on R08-03 and R09-01 but handle year 2000 dates correctly. (They also contain all the 10-01 and earlier enhancements and hence are worth using even with R09-02 because of the 10-01 enhancements see section 2.7.)
Note that one utility in this package, FASTBACK, will not run on the R08-03.01 release. This requires R08-03.02 or later. (See section Release Compatibility)
In the R09-02 release of OS/32 the following utilities were modified to handle the year 2000 and beyond; ACCT, BACKUP, FASTBACK, FASTCOPY, FASTCHEK, ERROR, OBJECT32, LINK, and AUDIT32. These were the only utilities in the OS/32 object package found to compare two dates or display a four digit year. The OS/32 Enhanced Utilities package contains all of these except for AUDIT32, plus CACHE, CAL32, COMPRESS, EDIT32, ERROR, SRCUPD, and SPOOLER. Customers who need a Year 2000 safe version of AUDIT32 for R08-03 or R09-01 should contact Concurrent.
As mentioned above, the customer will have to identify applications they developed which compare two dates or display a four digit year. The general assumption made when OS/32 Development changed the utilities listed above for the R09-02 release was a year greater than 70 would be treated as in the 1900's, a year less than or equal to 70 would be treated as in the 2000's. Let one assume the variable "year" contains the two digit year in binary, then the general algorithm used follows:
This provides a valid range of years from 1971 through 2070. The OS/32 Development group chose 70 because the model 7/32 first came out in 1974.
Your understanding how OS/32 maintains the current date will help you to identify which applications must be changed and how.
Calendar maintenance in OS/32 is performed in the Timer Management Module (EXTI) through the routine called TIM.DAY which is part of the Line Frequency Clock's (LFC) Event Service Routine (ESR). Here, the number of seconds from midnight, the current day, month and year are stored in certain fields in the System Pointer Table (SPT).
SPT.YEAR is a binary halfword which contains only the last two digits of the current year. In OS/32 releases prior to 8.3, if this field was increased by one from 99 it would have incremented incorrectly to 100. SCR13167 of March 1988 corrects this anomaly so that now, OS/32 releases R08-03 and later, increment SPT.YEAR from 99 to 00.
Applications interface to OS/32 through Supervisor Calls (SVC's). The only SVC which reads the current date is SVC 2, Code 9, which returns the date as an ASCII string in the form mm/dd/yy or dd/mm/yy. In OS/32 releases prior to R08-03, even though SPT.YEAR will contain 100 for the year 2000, the SVC 2, Code 9, will return '00' in the 'yy' field.
The SET TIME Operator Command accepts numbers only in the range of 00 to 99 so regardless of the OS/32 Revision Level, SPT.YEAR will contain zero if the year 2000 is entered.
The DISPLAY FILES command using the CTIME, ATIME or MTIME options, is the only OS/32 function that compares dates. As these options were not incorporated until the OS/32 R09-02 release, the dates are correctly interpreted.
Every disc file has an associated directory entry which, besides other essential data, contains the date and time the file was created, modified and last assigned. Prior to the R08-03 release, the year was not maintained correctly, so one can expect to encounter problems with file dates if earlier OS/32 revisions are used.
There are no problems with the timer services provided through SVC 2, Codes 10, 11 and 23, as these are concerned only with time intervals, so the current date is irrelevant.
SCR13167 which is included in OS/32 R08-03 and later releases, addresses the problem where the O.S. was unaware of the existence of February 29th during a leap year. O.S. releases earlier than R08-03 will always increment the date from 28th February to 1st March.
The following information is derived from the Release Notes for the OS/32 Enhanced Utilities package (officially called the OS/32 Version R10-01.U Utilities/Y2000 Release Notes).
The following enhancements are included:
The following SCRs have been resolved:
SCR 20637 => FASTBACK
SCR 20638 => FASTCMSS
SCR 20683 => FASTBACK
SCR 20694.1 => FASTBACK
SCR 20715 => FASTCHEK
SCR 20762 => FASTCPYI, FASTCPYF
SCR 20900 => FASTBACK
SCR 20929 => SPOOLER
SCR 21037 => FASTBACK
SCR 21061 => FASTCMSS
SCR 21130.1 => BACKUP
SCR 21139 => ASDG, FASTBACK,
SCR 21243 => BACKUP
SCR 21263 => SPOOLER
SCR 21436 => EDIT32
SCR 21469 => ERRORF, ERRORI
SCR 21500 => ERRORF, ERRORI
SCR 21502 => FASTBACK
SCR 21522 => SPOOLER
SCR 21535 => ERRORF, ERRORI
SCR 21,608 => FASTBACK
SCR 21642 => BACKUP
SCR 21782 => BACKUPM
The R10-01.U utilities are generally intended to be compatible with OS/32 release R08-03 and higher. The following table lists the minimum OS/32 release for each utility; the task image files are also indicated.
** There is in fact a patch available to FASTBACK R10-01.U that will allow it to run on R08-03. This patch disables the check for enough free space when starting a restore operation.
There is a problem in the OS/32 C library. The relevant SCR is #21518. If you have any programs that use this and the related functions, this SCR must be applied to the C libraries and the tasks re-linked. Note that patched versions of these libraries are supplied in the 'Y2K for Reliance and Languages' package.
Here is a copy of the SRF text:
The C library function time() will return an incorrect value after 1999. This will be evident when using functions such as gmtime() and ctime() which use the time() value as input.
This patch can also be applied to rtle.obj, replacing the first line by
Rename the patched versions as libe.obj and rtle.obj to install the new libraries.
When the date changes from 31 Dec 1999 to 1 Jan 2000 there will be problems with dates that are stored with two digits for the year. This is because the year part of the date will contain 00 and most software is going to assume that the date is 1900. The problem is going to be most evident where dates are compared, the year 99 comes before 00.
Reliance supports a number of different date formats and every date format can be defined with a four digit year or a two digit year. Any date defined with a four digit year will work correctly and doesn't need any change. The problem only affects dates with two digit years.
Field types are defined to Reliance using the data dictionary. The data dictionary supports date fields with the following formats:
There is only a problem if the data uses a YY format. Fields which use YYYY do not have a problem.
There are a number of places in Reliance where date comparisons or sorts are made. The problematic areas are as follows:
To identify what needed to be fixed, we categorized the dates as one of four types:
It is assumed that any systems that have long future dates already use four digit years. The reason for this is because the year 2000 is less than 4 years away and so the problem would have been encountered already.
It is also assumed that four digit years are already used for long past dates because the possibility of an 18xx date would exist. However there could well be dates that could be quite old but the designer knew that they couldn't be old enough to cause a problem. An example of this could be date of birth for students at an adult education college, or even birth dates for employees of a company.
It is likely for both near future and near past that two digit years will have been used. The reasons for this are not only to save database space but also to make the entry of dates more natural. It is normal to write dates using a two digit year and so when entering dates into the computer this format feels more natural. In addition where today's date is required in the record, getting the date from the operating system returns the date with a two digit year.
Fixes for these problems must be incorporated both in Reliance and in all affected user written applications.
In the Y2K Package, Reliance has been changed so it will make sensible assumptions about which century a two digit year is in. Patches have been applied so that Reliance assumes that all dates where only a two digit year is specified, are in a range from 90 years in the past to ten years in the future. Reliance previously assumed that all two digit years were 19xx.
User written applications which compare two dates will need to be changed so they handle these dates correctly.
The above changes will solve all the near date problems and also any long past dates which are never going to be more than 90 years old, but this leaves a further two problems.
The first is where a date can now be more than 90 years old. For example, when the system was new, nobody had a date of birth over 60 years ago, but as time goes on, some of the ex-employees may now have birthdays more than 90 years ago. This is not specifically a year 2000 problem, but it might first show up when the year 2000 fixes are applied.
The second problem is where a date field in the YYMMDD format is defined as a DMS key field. The records are retrieved with year 00 being first and 99 being last. This was correct when all dates were assumed to be 19xx, but when 1999 is followed by 2000, the order will no longer be correct.
In order to solve problems where either a date is used as a database key and the record order is important or where the date is YY but now could be more than 90 years old the user is going to have to perform a data conversion. The data from the affected file will have to be unloaded and converted to a four digit year. The database file definition will need to be changed and the file re-implemented, together with any dataviews which use it. Any Reliance applications which use the view should be re-implemented automatically when they are first run, however screen formatting changes may be required in RUS or Builder and report zones may need enlarging in Reporter. The application programs which use this data will have to be changed to use the new larger record and also if the date field was a part of an index, the key values will have to be changed as well. The data will then be reloaded into the file.
The following steps are required for any Reliance system:
First the preparation:
Then on the night:
The 'Y2K for Reliance and Languages' package contains all the Reliance, C, and CoDE components that have been updated for correct Y2K operation. Note that this package can be used to update Reliance R08-01, R08-01.1, and R08-02.
The following is an extract from the Release Notes for this package:
The following SARs/SCRs are fixed:
1. You will need to install the Y2K package if you use RUS's log facilities, CoDE or time routines from the C library.
2. You will also need to install the Y2K package if there are date fields in the data base that have been defined as only two digit years, and such date fields are used as part of a DMS key, for DMS Select and Fetch functions, for RQL or RUS Select, for RQL sort, for Reporter32 date calculations or sort, or as date fields with Reliance Builder.
Nothing in the Y2K package can fix anything in the customers' application code or screen forms. These must be checked and corrected independently.
The TOTAL database itself requires no fixes to cope with the year 2000. (Unlike Reliance, it contains no date typing facility, or query system.)
However, the roll forward/roll back mechanisms do require date comparisons. Because this code is not year 2000 safe, it is strongly suggested that the system be shutdown and completely backed up prior to midnight 31 December 1999, and then started again on or after 1 January 2000.
As with systems using the Reliance DMS data base, applications programs that use two digit dates will require modifications to cope with the year 2000. The earlier discussion in the Reliance section of near past/near future/long past/long future dates may be useful.
Some sites use third party query/data extraction programs to interrogate the TOTAL database. The suppliers of these programs should be contacted to ascertain whether these tools will require modification.
Copyright © 1996 - 1998 Tim Gething & Lee Brueni
This SBSW.COM page has been optimized for printing.