![]() |
Millennium Language Extensions |
The three main approaches for handling date data are:
The pros and cons of each of these approaches and a description of the methodology and tools offered with VisualAge 2000 can be found in the Inventory and Assessment material. For those date data for which century windowing is your choice, the Millennium Language Extensions (MLE) offered with the IBM COBOL compilers may significantly reduce your source-code updates, and thereby improve your schedules.
With this approach, you establish a 100-year interval, called a century window, within which you assume all two-digit years lie. Programs can then infer the correct century, depending on where in the century window the two-digit year lies. For example, if the range of your century window is January 1, 1956 through December 31, 2055, and the two-digit year is >= 56, the century is inferred to be 19; otherwise, if the two-digit year is <= 55, the century is inferred to be 20.
There are two types of century windows: the fixed window and the sliding window. The fixed window doesn't move after it has been established; the sliding window moves forward with the system date.
MLE is short for Millennium Language Extensions, IBM's patent-pending technology that provides support for automated date windowing in its year 2000 ready COBOL and PL/I compilers. Conceptually, these extensions give you a mechanism to indicate to the compiler which dates should be windowed. It is a compiler-assisted solution for your windowed dates. MLE is pronounced "Emily" and is referred to as such in this section.
Using Language Environment on MVS, OS/390, VM, or VSE gives you windowing support at runtime by supplying callable service routines to set and query a century window. But Emily provides even more assistance, essentially providing the logic that you would otherwise have to code yourself.
With Emily, you have the ideal situation: the ability to fix programs with no PROCEDURE DIVISION changes. While century windowing is the quickest and most powerful feature, field expansion is also supported, making Emily the easiest way to implement permanent internal bridges.
Using Emily, you can change your application data definitions in the DATA DIVISION to indicate which data items represent windowed dates and how you want the window to be defined. The compiler can then automatically implement the associated windowing changes, in many cases without your having to code the associated logic changes in the PROCEDURE DIVISION. Because it is compiled in the context of you program, it is the best performing windowing solution. So, where windowing is your approach of choice, Emily might help reduce the programming time and effort needed to implement a windowing solution and simplify subsequent maintenance of your application programs.
Emily also enables a flexible and comprehensive mixing of windowed dates with expanded dates within a program, allowing you to:
You can use Emily to help with date variable identification by identifying obvious date variables and letting the compiler diagnostics lead to you the ones that you missed.
Using Emily may also reduce your testing effort, particularly in those cases where you have few if any manual logic code changes. It's rather like using pre-tested logic.
Emily is not a silver bullet. It is important to understand that, whatever the merits of Emily, it does not render unnecessary all the year 2000 work at your enterprise: a windowing solution may not be an acceptable approach for all your applications. While it may relieve you of many of the logic changes where you do choose windowing, it does not relieve you of the assessment, planning, analysis, implementation, and testing activities. And there will be cases where the limitations of Emily require you to make manual logic changes.
Also, the extensions are not intended to be a durable piece of language design, with a long-term usage. They do not constitute a fully-specified set of date-oriented data types, with rich semantics, enabling improved functionality for new applications or enhancements to existing applications. Their use should be limited to making year 2000 repairs only.
In particular, the windowing feature is not intended for long-term use. The start of the window must be in the range 1900-1999, so this feature buys you time to get code through the year 2000 and to a long-term solution that can be implemented later.
Because the extensions do not provide date data types, the non-year part of the supported date formats is denoted by Xs: no special processing is done for the non-year part. To do otherwise might change the meaning of existing programs. The only date-sensitive semantics that are provided involve automatically expanding (and contracting) the two-digit year part of dates with respect to the 100-year window for the program.
See the MLE Guide for the COBOL contexts in which you cannot specify a windowed date.
Any host application running under Language Environment and any workstation application using IBM COBOL or PL/I products can use Emily. But consider three areas:
To use Emily effectively, you need to keep in mind some key principles used in developing these extensions:
The level of source source code is an important consideration. If your programs have been compiled with the OS/VS COBOL compiler, you will probably have to convert the source, which is at the ANSI 68/74 level, to ANSI 85. The CCCA, COBOL and CICS Command Level Conversion Aid (5785-ABJ), can be a big help with the conversion, very often doing the entire job for you. If you are going to use VisualAge COBOL for your year 2000 work, you can use the conversion facility in a snap.
If your programs have been compiled with VS COBOL II or later, no conversion is necessary. You can mix Emily programs with unchanged older modules, and only those programs with date logic need to be recompiled.
The Millennium Language Extensions permit the specification of windowed dates for sorting and merging, in conjunction with sort products such as DFSORT. However, the following subsystems do not support windowed dates:
This can cause a variety of problems, from outright failure to a source of confusion and errors from mismatched ordering.
See The MLE Guide for details.
A pilot project is always something to consider for your year 2000 work. In particular, you may want to take Emily for a spin to further investigate its viability and merits for your use. Be aware that this may involve a migration if you are not already using a year 2000 ready compiler. But, you were going to do that anyway for your windowing, right?
If the century window approach can be used, then Emily is applicable. If Emily is applicable:
This process can be applied on a source module by source module basis. Any executable can be compiled and tested with full year 2000 support by using the compiler option to enable the new attributes.
Test:
If all this seems a bit daunting, here is a brief sample to show how simple it can be to get started using Emily. First a look at a specific problem, then how to use the features of Emily for a simple solution.
Let's say your program compares the date that a video tape was returned with the date it was due back, to see whether to impose a fine. These two dates are stored in the file as 6-digit Gregorian dates; that is, YYMMDD. The program looks like this:
01 Loan-Record. 05 Member-Number Pic X(8). 05 Tape-ID Pic X(8). 05 Date-Due-Back Pic X(6). 05 Date-Returned Pic X(6). · If Date-Returned Greater than Date-Due-Back Then Perform Fine-Him.
If the tape was due back on 14 September 1998, the contents of Date-Due-Back will be 980914. If it was returned on 12 September, the contents of Date-Returned will be 980912. So no fine is imposed, because Date-Returned is less than Date-Due-Back.
But let's go forward in time and see how this reliable program behaves in January 2000. If the tape is due back on 2 January 2000, but is returned on 31 December 1999, the contents of the fields will be:
As you can see, Date-Returned is much larger than Date-Due-Back, so the program will impose a hefty fine for being 100 years late.
But what if the program recognized that the year 00 was in fact 2000, not 1900? Then the "If ... Then ..." statement would behave properly, viewing 991231 as 19991231 and 000102 as 20000102, resulting in correct logic path and no fine for the tape that was returned early, not late.
Fortunately, IBM COBOL allows for this, but you have to do a few things to make it work. Here's what you have to do:
01 Loan-Record. 05 Member-Number Pic X(8). 05 Tape-ID Pic X(8). 05 Date-Due-Back Pic X(6) Format of Date is yyxxxx. 05 Date-Returned Pic X(6) Format of Date is yyxxxx.More about the FORMAT OF DATE clause later, but for now it's enough to know that it has two or four Ys and some Xs. Two Ys means that the field is an MLE date window, which means that COBOL will apply the century window to the date.
So you can see that it's quite simple to introduce a windowed date concept into a COBOL program. All you have to do is decide on a century window, change some data items, then recompile the program.
Two code examples using a Language Environment century window (sliding window) are shown in COBOL window example .