Stuart Baker Software offers high quality consulting services and products to users of IBM PCs and compatibles (DOS and Windows)
    as well as Interdata, Perkin-Elmer and Concurrent Computer Corporation 3200 series machines (OS/32).

Concurrent 3200 and Y2K


 

Concurrent 3200 Systems and the year 2000

by Tim Gething & Lee Brueni of Concurrent Computer Corporation

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:

OS/32 R08-02 and earlier Must upgrade to handle year 2000 dates
OS/32 R08-03, R09-01 OS/32 will handle dates correctly, but the utilities will not. Either upgrade to R09-02 or later, or purchase the OS/32 Enhanced Utilities package
OS/32 R09-02 and higher OS/32 and utilities will handle dates correctly
OS/32 C programs SCR 21518 must be applied to correct time functions (see also below).
Reliance and CoDE Concurrent will provide patches to Reliance R08-01 and later, but not earlier releases. The patched versions are in the 'Y2K for Reliance and Languages' package which covers Reliance, C and CoDE.
TOTAL No changes necessary because it has no date field support

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:

if ( year > 70 )
year = year + 1900;
else
year = year + 2000;

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:

  • A file compression utility, COMPRESS/32 has been added.
  • The following enhancements have been added to CAL/32:
    • A directive to output a message for pass completion
    • A directive to suppress certain symbols (e.g. those staring with @) in the cross-reference
    • A directive to list only unreferenced symbols
    • A directive to force a warning error
  • Source Updater has been enhanced to support record lengths up to 132 bytes.
  • The following enhancements have been added to FASTCHEK:
    • An option to allow the user to control file deletion
    • The directory can now be written without interleaving
    • The write recovery option is option is no longer set on by default
  • FASTBACK now checks the disk space required prior to starting a restore and terminates if it is not sufficient. The total disk space required by the selected files is displayed during backup and display operations.
  • BACKUP has the following enhancements:
    • Allow comment lines in the select file
    • The SKIP and DELETE commands are enhanced to allow the skip and file replaced messages to be suppressed
    • The SINCE and BEFORE options can now be used together to select a date range
    • The VERIFY option is enhanced to allow suppression of the comparison listing
    • The ARCHIVE option is enhanced to provide an ArchiveOnly option which allows old (i.e. not assigned since ) files to be removed from the disk.
    • The listing now includes the files Last Assigned date and time
    • The listing's display of the options used has been improved
    • A confidence check on the tape operation is now performed at the beginning of the backup and verify phases
  • The Error Report utility error count fields are expanded to 8 characters.
  • SPOOLER will no longer delete a write protected file.
  • The LINK listing now includes the addresses of EXTRNs and ENTRYs
  • EDIT/32 is enhanced as follows:
    • Again can be repeated
    • A NOTYPE command has been added (to type the next line not containing the specified string)
    • Searches can be made in the reverse direction using the UP command
    • The ability to use a wildcard character in the CHANGE and SUBSTITUTE commands
  • CACHE/32 now allows the user to specify the number of disks to be cached (and hence reduces its memory requirements on most systems.
  • The following utilities now support years greater than 1999: ACCT, BACKUP, OBJECT32, FASTCOPY, FASTCHEK, LINK, FASTBACK, ERROR. For these any year in the range 00 through 70 is considered to be a year in the range 2000 through 2070, and any year in the range 71-99 is considered to be in the range 1971 through 1999.

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.

Utility Task Image File Minimum OS Release
Account Reporting Utility ACCT83.TSK R08-03
  ACCT91.TSK R09-01
  ACCT.TSK R09-02
BACKUP BACKUP.TSK R08-03
  BACKUMAC.TSK R08-03
CACHE CACHE83.TSK R08-03
  CACHE91.TSK R09-01
  CACHE.TSK R09-02
CAL/32 CAL32.TSK R08-03
  CAL32MAC.TSK R08-03
COMPRESS COMPRESS.TSK R08-03
EDIT/32 EDIT32.TSK R08-03
Error Reporting Utility ERROR.TSK R08-03
FASTBACK FASTBACK.TSK R08-03.2 **
  FASTBMAC.TSK R08-03.2 **
FASTCHEK FASTCHEK.TSK R08-03
  FASTCMAC.TSK R08-03
FASTCOPY FASTCOPY.TSK R08-03
  FASTPMAC.TSK R08-03
LINK/32 LINK.TSK R08-03
  LINKMAC.TSK R08-03
OBJECT/32 OBJECT32.TSK R08-03
  OBJECMAC.TSK R08-03
Source Updater Utility OSSRCUP.TSK R08-03
OS/32 Spooler SPOOLER.TSK R08-03

** 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:

DDMMYY   DDMMMYY
MMDDYY   YYMMDD
DDMMYYYY   DDMMMYYYY
MMDDYYYY   YYYYMMDD

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:

  • in DMS select, if a selection is "date-field < 12/12/96" does the literal value 96 mean 1996 or 2096? If date-field has a two digit year is it 19xx or 20xx?
  • if a DMS file has an index of a date field (YYMMDD) the dates would have previously come out in chronological order, now year 2000 dates will be selected before 19xx. This problem only affects YYMMDD because the other date formats would be in the wrong order anyway. For example DDMMYY would come out in order of year within month within day.
  • RQL, RUS and Reporter will have the same problems as DMS select, both in interpreting literal values and also deciding which century database dates are in.
  • the RUS log uses a 2 digit year and thus its date related print and purge function will not work correctly.
  • Reliance Builder converts fields when moving from screen fields to dataview fields and back, in comparison functions, in arithmetic functions, for select functions etc.
  • all user written programs that use YY format will need to be looked at. Those that only move the date either to a file or to display won't need to change. However any comparisons except for equality will need to change to take into account the correct century.

Date Types

To identify what needed to be fixed, we categorized the dates as one of four types:

  • near past, e.g. statement date for credit card
  • near future, e.g. delivery date
  • long past, e.g. birth date
  • long future, e.g. repayment date for a mortgage.

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:

  • install fixes to RQL, Builder, DMS and maybe RUS and Reporter
  • check if any files with YY dates are accessed by date order or dates can be more than 90 years in past, if so convert file to YYYY and convert programs/queries etc. to use new format
  • check own programs for compares of dates with YY and fix as required

Then on the night:

  • ensure that no ITC background jobs are scheduled to run after midnight
  • close the system down just before midnight
  • delete any QREPORTn.nnn files
  • bring the system up after midnight

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:

  • This package allows Reliance Plus, Reliance DBMS, Reliance Access, C, CoDE, Reporter/32 and Reliance Builder to run after the year 1999 and handle dates correctly.
  • DMS/32 is enhanced so that the select and fetch functions compare dates correctly.
  • Reliance Access is enhanced so that RQL and RUS compare dates correctly when selecting records. RQL is enhanced to sort dates correctly during report writing. RUS is enhanced to select, print and delete log records correctly.
  • Reporter is enhanced to calculate dates correctly and to sort dates correctly.
  • Reliance Builder is enhanced to compare dates correctly.
  • CoDE is enhanced to get dates correctly using the ACCEPT command.
  • OS/32 C is enhanced to return the correct date using the gmtime() and ctime() functions.

The following SARs/SCRs are fixed:

  • Reliance: HM12121: Enhance Reliance to compare dates correctly after 1999
  • CoDE: I-IM12070: Date dependent accept formats give wrong value after 1999
  • OS/32 C: 21518: The C library function time will return an incorrect value after 1999

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.


Return to Contents
Copyright 1996 - 1998 Tim Gething & Lee Brueni

This SBSW.COM page has been optimized for printing.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.

Please use our Feedback form to submit questions or comments about this web site.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.
This site was last modified: Wednesday, December 29, 2010