McIDAS Year 2000 Strategy

What does it mean to make McIDAS Year 2000 capable?

Our goal is that when the calendar changes from 31 December 1999 to 1 January 2000, McIDAS software will function no differently than it has for any other end-of-year changeover, and will continue to function properly into the 21st century.

How does that get translated into what needs to be done?

First and foremost, we want McIDAS to transition through the millennium with no difficulties. But we must also keep down the cost of making this happen. Our strategy is to make the transition smooth, while maintaining as much backward compatibility as practical. We have analyzed most of the McIDAS-X, -OS2, -SDI, and -XCD code to identify patterns of date use. From this analysis, we have drawn up guidelines for making changes. See the specifics below.

How will the work be done?

It is imperative that McIDAS be tested and verified as a system and not only as individual components. Since there are no platform-dependent issues for McIDAS, we have set up one machine that will be used for testing code compiled on another machine. This test machine will be isolated from our source control system. Programmers and testers will be able to change the system date as needed. Normal McIDAS code modification processes (inquiries, code sharing, unit testing, etc.) will be followed. VDUC has volunteered to participate in the testing, so we will be passing code and data to them for an independent test.

Test datasets of McIDAS format files (grid, point/MD, and image/area) have been created for this machine. These files contain a variety of data straddling the 12/31/1999 - 1/1/2000 boundary and into the 21st century. You can download the following compressed grid, image, and point files for local testing of Year 2000 changes.

*** Use the uncompress command from the Unix prompt to uncompress the files. ***

File name	Description
GRID5999.Z	0.3MB compressed grid file containing grids for days 31 December 1999, 1 January 2000, and 1 May 2001 [uncompresses to 0.6MB]
AREA1999.Z	2.0MB compressed image file with GOES-8 imager data for 19:02 UTC, 31 December 1999 [uncompresses to 3.3MB]
AREA2000.Z	5.9MB compressed image file with GOES-8 imager data for 15:45 UTC, 1 January 2000 [uncompresses to 11.0MB]
AREA2001.Z	1.9MB compressed image file with GOES-8 imager data for 19:02 UTC, 1 January 2001 [uncompresses to 3.1MB]
MDXX0001.Z	1.1MB compressed ISFC schema point file with global surface hourly data for 1 January 2000 [uncompresses to 25.8MB]
MDXX0005.Z	1.0MB compressed ISFC schema point file with global surface hourly data for 31 December 1999 [uncompresses to 25.9MB]
MDXX0011.Z	0.19MB compressed IRAB schema point file with global mandatory-level RAOB data for 1 January 2000 [uncompresses to 4.3MB]
MDXX0015.Z	0.19MB compressed IRAB schema point file with global mandatory-level RAOB data for 31 December 1999 [uncompresses to 4.3MB]
MDXX0021.Z	0.14MB compressed IRSG schema point file with global significant-level RAOB data for 1 January 2000 [uncompresses to 1.5MB]
MDXX0025.Z	0.09MB compressed IRSG schema point file with global significant-level RAOB data for 31 December 1999 [uncompresses to 1.5MB]
MDXX0031.Z	0.19MB compressed ISHP schema point file with global ship, buoy, and C-MAN data for 1 January 2000 [uncompresses to 5.0MB]
MDXX0035.Z	0.17MB compressed ISHP schema point file with global ship, buoy , and C-MAN data for 31 December 1999 [uncompresses to 5.0MB]
MDXX0041.Z	0.28MB compressed FO14 schema point file with U.S. FOUS14 forecasts for 1 January 2000 [uncompresses to 2.2MB]
MDXX0045.Z	0.28MB compressed FO14 schema point file with U.S. FOUS14 forecasts for 31 December 1999 [uncompresses to 2.2MB]
MDXX0051.Z	0.34MB compressed SYN schema point file with global surface synoptic data for 1 January 2000 [uncompresses to 4.2MB]
MDXX0055.Z	0.42MB compressed SYN schema point file with global surface synoptic data for 31 December 1999 [uncompresses to 7.3MB]
MDXX0061.Z	0.21MB compressed PIRP schema point file with global PIREP/AIREP data for 1 January 2000 [uncompresses to 6.0MB]
MDXX0065.Z	0.20MB compressed PIRP schema point file with global PIREP/AIREP data for 31 December 1999 [uncompresses to 6.0MB]

What is the schedule?

We expect to complete the Y2K work during the 1998 calendar year, with most or all of the changes being included in the November 1998 upgrade (version 7.5).

We will fix library routines and other isolated cases first, then complete work on applications and servers. These changes will appear in upgrades and Fastrack versions throughout 1998. Some changes will require modifications to the McIDAS Programmer's Manual, which will be updated as soon as practical.

See the McIDAS Y2K Modifications Page (updated 16 October 1998) for the list of subsystems and individual modules being changed. Modules that have passed internal testing and are part of a McIDAS-X or -OS2 release also list the version of the release.

What are the specifics?

Below is a list of specific guidelines we will use as we work to make McIDAS Year 2000 capable.

• Years represented in binary in McIDAS format files (MD, grid and area) will generally be stored in the yyyddd form. This includes all critical information in the headers, directories and data. In the yyyddd form, yyy is calculated as the year (ccyy form) minus 1900. For example, 15 January 2002 would be stored as 102015. The exceptions to the yyyddd form are:
  • MD file data record - the unit of SYD indicates ssyyddd or yyddd; the unit of CYD indicates ccyyddd
  • Navigation blocks - epoch dates remain stored as yymmdd
  • Master navigation file - remains unchanged with records filed based on ssyyddd
• User input to commands must be expressed as either yyddd or ccyyddd. The mccmd...() argument fetching routines will always return a ccyyddd format to the caller. When the century is not specified, the default for these and other date-related functions will be the date closest to the current year. For example, in the year 2008, a date entered as 97123 would be returned as 1997123.
• The uniform display of dates by applications is a longer-term goal. Decisions to make these changes will be based on difficulty and the level of ambiguity that might result from not making changes.
• The master navigation file format will be changed as needed to support the ccyy format. If a new file format is required, the routines that use the file will be changed to accommodate both the old and new formats.
• Arbitrary range checking on dates will be removed.
• Old argument fetching routines (IKWP, IPPYD, etc.) will not be changed. Their use by core McIDAS commands will be limited, if used at all, to parameters that do not involve dates.
• Two dates have been identified by the computer world as being significant: 9/9/99 and 1/1/00. Neither of these dates, or values based on them (like missing value codes), were deemed to be of any significance for McIDAS.
• Two new functions will be added to the McIDAS library:
• • a translator function that converts dates from the forms yyddd, yyyddd, or ccyyddd to ccyyddd
  • a routine to compute the difference between two given dates and times
• The SKSECS() library routine is used to compute the seconds since 1 January 1972. This has many uses in McIDAS, primarily for computing ranges and testing for inclusion/exclusion in ranges. This function will continue to work properly until 2012. However, its functionality will be subsumed by other library routines and it will be eventually moved to the compatibility library.
• No gratuitous changes will be made to the code to fix existing problems and limitations. For example, if a routine is found not to be checking the return status of a function call it makes, and it is not related to the Y2K work, it will not be changed as part of this process.

What about ADDE?

The guidelines below are specific to ADDE.

• Client-side ADDE APIs (that is, the routines that are called by applications to get data) will always return dates in the form ccyy; applications will be changed as needed to accommodate this.
• The low-level ADDE code on the client side will be changed to convert yyddd and yyyddd formats into ccyy before handing the data, directory, or header blocks to the application.
• The low-level ADDE code on the client side of a point server transaction will use the units of either SYD or YYDD to signal that a field contains a date. All other data servers (for example, image and grid) will use the specific words in the directory that store dates, and convert appropriately.
• All ADDE servers will be checked to insure that they use the mcarg/mccmd parameter retrieval functions, so that identical results are obtained by clients and servers when converting formats.