Concurrent 3200 Systems and the year 2000

Preface:

This document was originally issued in May 1997. This May 1998 revision provides some updated information.

Contents:

Introduction

Summary

Handling the year 2000 in OS/32
OS/32 R08-02 and older
OS/32 R08-03 to R09-01
OS/32 R09-02
Application Code
OS/32 Internal Calendar Maintenance
OS/32 Enhanced Utilities
Enhancements
SCRs
Release Compatibility

C Library

Handling the year 2000 in Reliance
Introduction
Problem Areas
Date Types
Upgrade Steps
Y2K for Reliance and Languages package contents
Do you need Y2K for Reliance and Languages?
Customers' Applications

Systems using TOTAL

Introduction

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.

Return to Contents

Summary

The following table summarizes the options:

Return to Contents

Handling the year 2000 in OS/32

Introduction

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

customer applications.

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.

OS/32 R08-02 and older

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.

OS/32 R08-03 to R09-01

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)

OS/32 R09-02

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.

Application Code

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.

OS/32 Internal Calendar Maintenance

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.

OS/32 Enhanced Utilities

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

Enhancements

The following enhancements are included:

SCRs

The following SCRs have been resolved:

SCR 20637 => FASTBACK
When running Fastback with the RESTORE option, the "selection file" that was used during the backup process is not completely displayed on the console. The file extension and account number are missing.

SCR 20638 => FASTCMSS
An internal error 0112 is issued when FASTCHEK encounters a defective sector in the bit map and processes the error message.

SCR 20683 => FASTBACK
Fastback will pause with a "segment limit address error" at times, when performing a backup and verify operation of a disk.

SCR 20694.1 => FASTBACK
Modify the Fastback utility so that it uses the fast SVC7 fetch directory function search when looking for file names. This saves time during a restore.

SCR 20715 => FASTCHEK
Fastback gets an error message on a non-3280 class processor system during a backup/restore to the system disk after a crash has occurred.

SCR 20762 => FASTCPYI, FASTCPYF
When Fastcopy is run without the newdate option, and a file from the input disk is copied to the output disk, the date/time created and date/time last written of the output file remains the same as that of the input file, but the last assigned date/time of the output file gets changed to the current date/time.

SCR 20900 => FASTBACK
When using Fastback with an HPCT-200S (3480) tape drive with a stacker, Fastback should unload a full tape cartridge and automatically load the next tape cartridge without pausing.

SCR 20929 => SPOOLER
The printer prints the first and then every fourth line of Contiguous and Extendible Contiguous files.

SCR 21037 => FASTBACK
Fastback is not correctly checking for Fujitsu Stackloader.

SCR 21061 => FASTCMSS
The record numbers of the EXTENDED FILE message are incorrect.

SCR 21130.1 => BACKUP
BACKUP may not always detect EOM properly when reading 3480 cartridge tapes. This could result in BACKUP not verifying or restoring all tape cartridges in a multi-cartridge tape backup.

SCR 21139 => ASDG, FASTBACK, FASTBMSS
Provide support for disks greater than 4GB.

SCR 21243 => BACKUP
Restore done to an account number greater than 32K puts the file in the wrong account.

SCR 21263 => SPOOLER
Data was being lost with forward and backward Spooler functions.

SCR 21436 => EDIT32
SVC address error occurred when the RULER command was issued with list=NULL:

SCR 21469 => ERRORF, ERRORI
CC152 occurs when there is a core directory overflow on a dual-port disk and the read-only side is marked on with CD=ALL.

SCR 21500 => ERRORF, ERRORI
CD.NODE in FMCD does not check for fullword alignment of address.

SCR 21502 => FASTBACK
Fastback tapes created by an R08-03.2 Fastback cannot be read by other versions of Fastback.

SCR 21522 => SPOOLER
Spooler pauses with internal print structure overwritten.

SCR 21535 => ERRORF, ERRORI
The Error Reporting Summary APU and IOP max queue depths are incorrect.

SCR 21,608 => FASTBACK
Provides support for the HP DAT tape stack loader.

SCR 21642 => BACKUP
BACKUP fails verify with internal failure 021 on huge indexed files with record length =1.

SCR 21782 => BACKUPM
Volume header of BACKUP tape has incorrect revision.

Release Compatibility

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.

Return to Contents

C Library

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:

Problem:

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.

Solution:

Apply the following fix using OS/32 Patch:

>object libe.obj,newlibe.obj,lib
>lcase on
>get time
>bia 0:p
>expand p,18
>verify 106,cab0,ffba
>var %v1
>var %v2
>range 106,patch,%v1
>range patch+e,10a,%v2
>modify 106,4300,%v1
>modify patch,c9b0,0046,2313,cab0,0064,cab0,ffba,4300,%v2
>idno 21518,SCR
>save
>end

This patch can also be applied to rtle.obj, replacing the first line by

>object rtle.obj,newrtle.obj,lib

Rename the patched versions as libe.obj and rtle.obj to install the new libraries.

Return to Contents

Handling the year 2000 in Reliance

Introduction

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.

Problem Areas

There are a number of places in Reliance where date comparisons or sorts are made. The problematic areas are as follows:

Date Types

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.

Upgrade Steps

The following steps are required for any Reliance system:

First the preparation:

Then on the night:

Y2K for Reliance and Languages package contents

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:

Do you need Y2K for Reliance and Languages?

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.

Customers' Applications

Nothing in the Y2K package can fix anything in the customers' application code or screen forms. These must be checked and corrected independently.

Return to Contents

Systems using TOTAL

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.