Welcome to Logical Data Corporation's Year 2000 Millennium Compliance Pages

YEAR 2000 COMPLIANCE


LDC is examining all of its software products for Year 2000 Compatibility (Y2K). All 2-digit dates are being converted to the 4-digit format. Care is being taken to insure the year 2000 is recognized as a leap year according to the 400-year rule. Fortunately, most system software products use dates for display or interface purposes with few, if any, calculations based on the actual value of the year.

The following text provides interim information, which will be updated as the investigation continues. (Click here for information on specific products).

Requests for Certification and Compliance:

We have received individual requests for information and certification of Y2K compliance but have not responded in all cases since Y2K work is in progress on the various products and some information is incomplete. As product reviews and updates are completed, we will respond to each inquiry.

The preliminary Y2K information on this Web site is being provided so you will understand the current degree of compliance of products you may be using and so you can coordinate plans for updates and testing, if necessary. This information will be updated periodically on our Web site. As product certifications are completed, we will provide specific details on product changes. We will also provide information on the impact these changes may have on existing applications, as well as any system software prerequisites that may be necessary for the updated products.

Year 2000 Updates Included in Next Product Releases:

Y2K compliance will be standard in the next release of each product. Updates should be available within 30-60 days. Customers with software maintenance contracts will automatically receive updates on the maintained products.

Other Updates:

MODCOMP has some Y2K updates for MAX IV and MAX 32. Although available for current revisions, they should work for many prior revisions. We encourage you to obtain and schedule installation of these updates as soon as possible.

Assistance Available:

Logical Data Corporation provides expert assistance on installing hardware and software product updates. We can also help you, either on-site or remotely, review and convert your applications, data bases, and other files to be Y2K compliant and to meet any other requirements you may have. We also provide professional services: consulting, strategic planning, design, development, and integration of systems and software.

Contact:

If you have specific questions on our Year 2000 efforts, how our changes may affect your system, or if you need other assistance, contact us at support@logicaldata.com or at our address and phone numbers accessible here.


Compliant Products:

The following products do not use dates or have always been Year 2000 compliant:

Unchecked Products:

The following products are scheduled to be checked but have not been thoroughly examined at this time:

Checked Products:

Return to top


CLG
Year 2000 Millennium Compliant

The D.00 revisions of CONSOLE LOGGER and CONSOLE LOGGER/32, released October 5, 1998, are fully Year 2000 compliant. They obtain a 4-digit year and format output to display, printer, and disk/tape as a 4-digit year. D.00 revisions are adaptable to existing log file header sequences of 2-digit year headers.

 


EXTENDED COMMERCIAL SUBROUTINES
Year 2000 Millennium Compliant

The Extended Commercial Subroutines included seven date-related subroutines. Five subroutines were not Year 2000 compliant due to the use of 2-digit ASCII or integer dates. The Year 2000 Update for these subroutines includes three replacement routines, two improved routines, and six additional new routines.

The use of 4-digit dates requires inspection and possible modification of existing applications that call these subroutines. Concerns have been expressed that changes made to subroutines in the existing library may adversely affect interim maintenance of applications not yet modified for Year 2000. Managers, however, want to insure that Year 2000 compliance is enforced.

Our strategy for correcting this library is:

  1. Not to introduce unexpected side effects from relinking applications with library routines before applications can be modified for Year 2000 compliance, and
  2. To allow system managers to insure that no 2-digit date support remains in the library and calling applications by removing the obsolete routines.

EXTENDED COMMERCIAL SUBROUTINES

YEAR 2000 UPDATES

Subroutine

Action

Argument Changes or Function

Existing

New

ACTPER

 

Obsolete

 

CALDX

CALDX4

Replace

SOURCE:
MMDDYY to MMDDYYYY

DESTINATION:
"Month DD, 19YY" to
"Month D, YYYY"

DATE

DATE4

Replace

SOURCE:
MMDDYY to MMDDYYYY

DAYWK

DAYWK4

Replace

None

IJUL

IJUL4

Replace and add third Argument: CNV = 0

SOURCE:
MMDDYY to MMDDYYYY

IJUL2

IJUL4

Replace

SOURCE:
MMDDYY to MMDDYYYY

WKEND

WKEND4

Replace

None

 

ASCDAT

 

Format date string

 

ASCDAY

 

Return day name (using title case)

 

ASCTIM

 

Format time string

 

DAYYR

 

Get day of year and day of week

 

IYEAR4

 

Convert 2, 3, 4-digit year to 4-digit year

 

ISLEAP

 

Determine leap year

 

Existing subroutines were not changed. New subroutines have been created from the affected subroutines and have similar names, but the names have been altered slightly to imply the 4-digit year usage. Other calling arguments are not changed. For example, IJUL2 is changed to IJUL4, and the associated ASCII date is formatted as MMDDYYYY.

The new version of each modified subroutine can be added to a common subroutine library until all application programs have been modified for 2000 compliance. Then each routine that is not Year 2000 compliant can be removed from the library (IJUL2 for the example above), ensuring any programs using a noncompliant subroutine will fail to link. Source libraries can be quickly searched for programs that use noncompliant subroutines.

Year 2000 compliance implies that all routines will operate consistently across the 1999 to 2000 boundary like any other year change and that an accurate leap year calculation is provided, including the 100 and 400-year rules, which recognize 2000 as a leap year. In cases where algorithms could not be verified, some routines have been recoded with traceable algorithms. Some new subroutines have been included to assist in formatting and to support underlying calculations.

Implementation Notes

This routine makes major assumptions about the start of a company's accounting year. Due to the specific nature of this routine, we have chosen to discontinue it and not modify it in its current form. A number of changes would be needed to generalize it. Should you choose to enhance it, it appears to have the right calling format and will process 2000 as a leap year correctly, but it fails to test for the 100 and 400-year exceptions. You should use the new function ISLEAP to provide accurate leap determination. Better yet, use of new routines like IJUL4 or DAYYR will provide accurate day numbering. Like the IJUL family, this routine also has its origin at January 1, 1976.

This routine replaces CALDX and expects a full 4-ASCII digit year. It simply reformats a date string in the form of MMDDYYYY into the form Month D, YYYY and has no concept of leap year. CALDX4 now suppresses the leading zero in the returned day, and the name of the month is returned in title case.

This routine was derived from the original DATE routine, which is used to validate a date. The new routine requires a 4-digit year and uses the ISLEAP function to determine leap year accurately (rather than the original divide-by-4 leap calculation).

The original DAYWK subroutine accepted a 4-digit year but only used the divide-by-4 calculation to determine leap year, which does work for 2000. The original algorithm was not documented, so a new routine obtained from a Web article by Claus Tondering at c-t@pip.dknet.dk was implemented. The article appears at URL:

http://www.pip.dknet.dk/~c-t/calendar.html

The routine calls DATE4 for a date validation and returns a 1 or 2-character day.

This routine replaces both IJUL2 and IJUL; it accepts and returns 4-digit years. Programs that call IJUL and IJUL2 should be changed to call IJUL4. Calls changed from IJUL to IJUL4 should include a third argument, an integer constant or variable with a value of zero. The Julian Year Number used in this routine is based on January 1, 1976 as day 1 by default. Using this origin, the range of this routine is limited to Sept. 16, 2065 since the Julian Year Number is passed as a 16-bit integer. The new routine removes the restriction of the origin year at 1976 and provides additional functions to allow a program to retrieve and set the origin year. The function ISLEAP is used to provide accurate leap year calculation.

This subroutine replaces WKEND. The algorithm used in WKEND was not documented, and it was difficult to certify the leap year accuracy. The routine was recoded with some code borrowed from DAYWK4. Date validation, missing in WKEND, was added to WKEND4. Comparative testing revealed at least one major error in WKEND. It returns a date one day after the correct date for Friday for any date in January and most of February during any century year that is not a real leap year (i.e. 1900, 1800, 2100, etc.). Since no calling arguments were changed, programs using the old routine can simply have the old routine name changed to WKEND4, or you could rename this routine to WKEND and replace the old routine with the new one.

New Subroutines

This FORTRAN INTERGER*2 function was added to convert 2, 3, and 4-digit years to a uniform 4-digit integer value. It is used as follows:

YR4 = IYEAR4( YR )

It uses a date window beginning at 1976. Dates less that 76 will be added to 2000 for a range of 2000 - 2075. Dates from 76 through 9999 will be added to 1900 for a 4-digit range of 1976 through 2899. Systems that use small integer years as serial numbers can continue to increment past 99, and this routine will interpret 100, 101, etc., as 2000, 2001, and so on. Dates with values of 1000 or more remain unchanged.

This is a new FORTRAN LOGICAL*2 function that returns TRUE if the year is a leap year. It includes both the 100-year and 400-year rules. The function has a single I*2 argument, a 4-digit year, and is released with the Y2K date routines. It can be used as follows:

IF (ISLEAP(YR4)) ...

You must declare ISLEAP a LOGICAL*2 function in the calling program or subroutine.

This routine was added to provide the day of the year and day of the week for any date. All arguments are in INTEGER*2 format, and the routine is fully Year 2000 compliant. It is called as follows:

CALL DAYYR (MONTH, DAY, YEAR, NDAY, NWK)

This routine provides a flexible date formatting function. Month, day, and year are supplied as INTEGER*2 values with an ASCII separator character in A1, A2, or the first character of an even length character variable, to produce a date string in the form MM-DD-YYYY. You can specify other separator characters, such as a slash (/). If the year is supplied as an A1 or A2 blank, only the month and day will be returned as MM-DD. And likewise, if the value of day is blank, only the month is returned in the form MM. The routine calls IYEAR4 to accept 2, 3, and 4-digit year values. The calling sequence is:

CALL ASCDAT (ADATE, MONTH, DAY, YEAR, SEPCH)

Where:

ADATE is an integer array, character variable, or character array to receive the date string, which can be up to 10 characters.

This routine provides a flexible time formatting function. Hour, minute, and second are supplied as INTEGER*2 values with an ASCII separator character in A1, A2, or the first character of an even length character variable, to produce a time string in the form HH:MM:SS. You can specify other separator characters, such as a period (.). If the second is supplied as an A1 or A2 blank, only the hour and minute will be returned as HH:SS. And likewise, if the value of day is blank, only the month is returned in the form MM. The calling sequence is:

CALL ASCTIM (ATIME, HOUR, MINUTE, SECOND, SEPCH)

Where:

ATIME is an integer array, character variable, or character array to receive the time string, which can be up to 8 characters.

This routine returns the name of the day of the week for any date. It calls the DAYWK subroutine to obtain the relative day number in the week. The date is provided as month, day, and year (INTEGER*2 values). The name of the day is supplied as 10 ASCII characters. The calling sequence is:

CALL ASCDAY (ADAY, MONTH, DAY, YEAR)

Where:

ADAY is an (A2) integer array, character variable, or character array to receive the name of the day. The routine always returns 10 characters, padded with trailing blanks as needed.

Software Availability

The Year 2000 Updates are included in the current release of the Extended Commercial Subroutines, which are available from Logical Data Corporation on 1/2 inch magnetic tape or 4 mm DAT tape. The release includes source and binary libraries and documentation. A self-extracting Winzip file containing the source of the Year 2000 updates is available here.

Source modules can be compiled with FR5 or F77. Binary routines in the 16-bit binary library are ready to use and were compiled with FR5, using $23 and $4E options. The 16-bit library modules can be linked using M4EDIT with applications produced by MODCOMP FR5 (FORTRAN IV) and F77/16 (FORTRAN 77).

The source routines may be used to generate 32-bit library modules for use with F77/32 (FORTRAN 77) applications. But the existing routines use a few 16-bit commercial subroutines such as MOVE, FILL, PUT8, etc., which must be replaced.

Other Year 2000 Updates

These Commercial Subroutine updates are not sufficient to make a MODCOMP system fully compliant for year 2000. MODCOMP, Logical Data Corporation, and other vendors provide updates for products affected by year 2000. If your system uses any of these products, we recommend that they should also be installed as part of your Year 2000 updates.

The MODCOMP MAX operating system has always maintained the year as a 4-digit integer value. Traditional MAX subroutines like TIMDAT and TIMDT4 handled years as 4-digit integers. This was consistent with the REX TIME (#40) REX service and with the way the system stored and incremented the year. Often applications would store or print a 2-digit year to save storage or print space, and the Year 2000 problems were introduced.

In more recent MAX revisions, MODCOMP added REX TIME services that return formatted 2-digit ASCII dates that assume a 1900-based year and subtract 1900 from the system year. The REX MESSAGE service was enhanced with an option STAMP to utilize one of the TIME functions to format a date/time stamp with a 2-digit year. Code using these time functions will have to be changed along with the TIME REX service.

The OC task provides operator entry and inquiry for date using the /DATE directive. This directive accepts any integer year value. If the year is supplied as 00-99, it assumes the year is 1900-1999. Any value larger than 99 for the year will be used as specified. Unfortunately, the DATE display appears to use the REX MESSAGE service with the STAMP option to print the previous and current date with the 2-digit year format. The /DATE OC directive should be replaced.

MODCOMP has software to update these critical areas to Year 2000 compliance, and we recommend that you install these changes on your system or make similar changes to correct the problems mentioned above. You should be able to install these MODCOMP updates safely to older revisions, at least as far back as MAX IV I.00 and MAX 32 B.00. The MODCOMP updates correct critical OS-based functions but do not address less critical date problems like the SED directory dates and listing formats.

 

 Return to product list

 


INFINITY and INFINITY/32
Year 2000 Millennium Compliant

 

INFINITY E.06 and INFINITY/32 B.06, released August 20, 1998, contain the following:

WARNING: Y2K corrections for INFINITY will not automatically correct or reformat customer data in data base files.

INFINITY has never provided a DATE data type. We plan to provide an extension to the Fast Load utility to save a significant amount of customer effort in converting data in files where 2-digit year values exist. This extension will allow data in files with fields that use 2-digit years (integer or characters) to be unloaded and reformatted to 4-digit values, outputting data to sequential media (tape). During reformatting, 2-digit ASCII dates will be extended to 4-digit ASCII dates by pre-appending "19"; integer dates less than 1000 will be changed by adding 1900.

DBCREATE can then be used to modify and expand the record structure of data base files with 2-digit character date fields, and the data base can be reallocated. DBCREATE can simply modify the definitions for data base files containing 2-digit integer dates without requiring reallocation.

When changes to the data base file structures have been completed, Fast Load can be used to restore each file by rapidly reloading data records that it reformatted previously and rebuilding each key. This strategy relieves customers from having to write, test, and run special programs to reformat and rebuild data base files, providing more time to modify and test related applications. Procedures can be developed to automate the reformatting process.

 Return to product list

 


IPC
Year 2000 Millennium Compliant

(Click here for most recently added IPC information).

IPC software is not sensitive to calendar date, so when the rollover to year 2000 occurs IPC users can expect continued performance without interruption. The IPC has its own microkernel real-time operating system. The IPC is based on the Intel family of PC-compatible machines and software, and it uses MS-DOS as a startup mechanism and MS-DOS utilities for off-line management of files, editing configuration, and running diagnostics.

MS-DOS version 6.22 was tested for operation and will operate properly, tracking the system date from 1999 to 2000 as the millennium changes. Some displayed dates such as those shown in a directory listing will only show the last 2 digits of the year. Tests on the file system have shown the file system does keep sufficient information to define the year 2000 and beyond, so date-ordered listings of files created in 2000 and beyond will collate after files created in say 1999, even though only the 2-digit year is displayed.

MS-DOS gets its system date initially from the hardware clock located on the motherboard, or the date can be entered as a command. The hardware clock maintains the date differently depending on the motherboard in use. Since production started, IPCs have been shipped with four different motherboards from one of three different manufacturers. The earliest systems, produced in 1992, used a computer motherboard produced by Deico. These were delivered with 486SX processors running at 25 MHz. In 1993, IPC production switched to the Micronics Gemini and shortly later to the Micronics MX-30. The Gemini had on-board peripherals. Systems with Micronics computers were delivered with either a 486SX running at 25 MHz or a 486DX2 running at 66 MHz. In 1996, we switched to the Tyan Tomcat series that supports Pentium processors. IPC systems since then have been supplied with Pentium processors running from 100 to 133 MHz.

To date we have tested the Micronics MX-30 and Tyan motherboards for Year 2000 compliance. The Tyan accepts and properly tracks the change in year from 1999 to 2000. The Micronics setup utility displays a 4-digit year, but the hardware clock changes from 1999 to 1990, not 2000. If your system is operating during the millennium change, it will continue to operate correctly, but when it is first restarted after the millennium change, MS-DOS will read the year as 1990 from the Micronics MX-30 motherboard.

Micronics's problem with the year will not affect the performance or operation as a peripherals system for the MODCOMP computer, but it may be annoying for those involved in occasional file maintenance if they forget to change the MS-DOS system date to 2000 rather than 1990. Dates and time are often important in tracking file revisions. It is trivial to add a startup program in the AUTOEXEC.BAT file to automatically adjust an old date forward 10 years when the system is booted.

Systems with 486 processors can eliminate this problem and significantly enhance the performance of their systems by replacing the Micronics or older motherboards with a Pentium system. Performance gains of 25 to 40% have been measured for disk-intensive applications. An upgrade kit available as Model 3085A provides a 133 MHz Pentium motherboard that will directly replace the Micronics system. This Pentium-based board has 5 ISA slots and 4 PCI slots with one of each shared. Standard floppy, communications and printer ports are on the motherboard. If you have more than 5 ISA peripherals, we can move your video and SCSI disk/tape controllers to PCI slots using newer controllers to relieve the demand for the ISA slots. The 3085A system is supplied with 8 MB of SIMM memory, which can be used to increase the disk cache. The current price for the upgrade is $575.00 and includes any necessary software upgrades.

Pentium systems require a PC Adapter Model 3100 revision C or later interface. The revision C interface is a 2/3 size card with the logic in a single chip, is housed in the IPC chassis, and attaches the IPC to the MODCOMP computer. Systems with full-length revision A or B interface cards will require upgrades to the new card before the Pentium system can be used. The new interface transfers data at rates of 4 to 5 times faster and decouples the ISA and MODCOMP busses with two 256-word FIFO buffers for maximum transfer efficiency. The new interface card is completely software upgradeable should any updates be needed. A replacement upgrade for systems with earlier revisions of the interface is available as Model 3101C1 for $1,350.00.

Motherboard replacement and interface changes, if needed, usually require about 1 hour and can usually be accomplished with the IPC still mounted in the system rack. The replacement can usually be performed by site personnel. Telephone assistance is available and provided without charge to insure a smooth transition.

The IPC software has no Y2K dependencies.

Our Web site documents Y2K tests on various motherboards used in IPCs. Failure of the century to change will not affect IPC system operation or restart.

  1. Pentium-based IPCs use TYAN Tomcat motherboards and are Year 2000 compliant.
  2. Most 486 IPC systems used the Micronics 486 (MX-30) motherboard. Further checks on the Micronics 486 motherboards indicate the century is stored in the CMOS clock RAM but not updated by the clock itself. The century is updated when the date is set or updated while DOS is running. The century is read by BIOS, DOS, and the SETUP utility to establish the actual 4-digit year. The real-time clock on these boards also handles 2000 as a leap year. If the system is not running at midnight on December 1999, the century will not be incremented by DOS, and when the system is subsequently started the date will be incorrect. At startup, DOS will set the date to 1/4/1980 if the date was obviously invalid (eg. 1900). Setup will choose 1/1/1990 when dates are older than 1/1/1980. We have developed a DOS application that checks the system date and automatically corrects the century, if needed. This program will be included in the next IPC software release. This program can be executed at start-up by including it in AUTOEXEC.BAT to provide automatic century correction at restart in case the IPC was not operating during the turn of the century.
  3. Only 10 IPCs were built with the original Deico 486 Predator motherboards, and only nine were shipped. We changed vendors when subsequent versions had a serious defect in the I/O support chip. We suspect the century correction code will work, but it has not been verified on the Deico board. The century architecture was established in the original IBM 286 AT and supported by its ROM BIOS and PC-DOS code. How the Deico setup utility supports the century update and what happens in its BIOS if the date is older than 1/1/1980 is yet to be determined and may affect the century correction routine.

 Return to product list

 


TSX
Year 2000 Millennium Compliant

TSX J.05 and TSX/32 D.05, released August 5, 1998, are fully Year 2000 compliant.

The following is a summary of the changes made to accommodate the upcoming date change:

The Screen utility
Changed in source file SCR$DIR subroutine SDLDIR
Released as TOC object module SCREEN

  1. LDI directive title changed to display 4-digit date
  2. LDI documentation changed to show 4-digit date in example
  3. SAVE documentation corrected to show 4-digit date (document error only)
  4. SCREEN depends on TIMDT4 subroutine always documented as 4 digits

The JM utility "." (Dot)
Changed in source file JM$STA
Released in TOC object module "."

  1. Footer line changed to display 4-digit year
  2. Depends on MAX IV or MAX 32 REX TIME Service date documented as 4-digit integer

Changes are not critical for existing product to operate correctly at the century boundary. 

 Return to product list

 


1Home2About Our Company3Products4Support & Services4News


Copyright © 1998-2001 Logical Data Corporation