This technical bulletin announces the OMCS Version 2 Year 2000 Compliance upgrade. This revision (TB97-0004-1) supersedes the original edition. It was published after the PTFs for the OMCS base product and IRM were shipped.
In this document the use of "OMCS" without version information refers to OMCS Version 2.0.1 only. In general this publication does not describe the operation of other versions of OMCS.
Full Y2K compliance will be delivered as standard PTFs as follows:
| Product_name | FMID | PTF | * | availability |
| OMCS/V2 (base product) | ASEB200 | ASP0735 | * | Fri 7th Nov 1997 |
| ASP0742 | * | Fri 7th Nov 1997 | ||
| ASP0746 | * | Mon 10th Nov 1997 | ||
| ASP0747 | * | Mon 10th Nov 1997 | ||
| ASP0748 | * | Fri 14th Nov 1997 | ||
| OMCS/IRM (report management) | ASEC200 | ASP0738 | * | Fri 14th Nov 1997 |
| ASP0743 | * | Fri 14th Nov 1997 | ||
| ASP0745 | * | Fri 14th Nov 1997 | ||
| OMCS/JSF (job scheduling) | ASED200 | ASP0736 | * | Fri 21st Nov 1997 |
| OMCS/SRF (statement reprint) | ASEG300 | ASP0737 | * | Fri 21st Nov 1997 |
In GC28-1251 IBM recommends a "clean slate" testing methodology for Y2K test runs where synchronisation of time-stamp controlled processes is impacted by the repeated setting of system clocks forward and backward.
Typically this means discarding the results of previous test runs, allocating new datasets and, usually, restoring conditions from a baseline of backups, etc.
Clearly this imposes a significant workload on the people doing Y2K testing, who especially need to be able to view and compare the JCL listings, reports, syslogs and other output from a number of different IPLs in a context where system clocks are being reset from one IPL to the next. Capture, archiving and viewing of sysout is the prime role of the OMCS base product and we have designed our modifications to the base product to support this need for "dirty slate" operation.
Our Y2K compliance upgrade will support a continuous style of operation for the OMCS base product only without the need to discard databases and reset control files. Having said that, the points mentioned in the section Strategies to avoid inadvertant data loss must be taken into consideration.
We have made it possible for the OMCS base product to operate continuously through a series of IPLs where time is disordered by clocks being frequently reset. This goes beyond the strict requirement for Y2K compliance. We have taken this extra step because our customers tell us that they regard the base product as a sort of 'sysout vacuum cleaner' which their operations and programming staff rely on to show, as nearly as possible, a correct sequential perspective on the output from a series of IPLs.
As the following section makes clear, this ability to correctly operate continuously through disordered system time does not apply to the OMCS extension products.
The changes to the OMCS base product that allow it to support "dirty slate" operation DO NOT allow regression to the pre-Y2K support code level operating against the same databases. Once the Y2K support code level is operating against a database then you MUST NOT operate on that database with the pre-Y2K level of code.
Please note these points:
The Y2K compliance upgrade announced in this bulletin ensures that the OMCS extension products (IRM, JSF and SRF) will operate correctly throughout the period 1st Jan 1980 to 18th May 2007, so long as the products are not asked to cope with system clocks being set backward. Y2K compliance has never meant that software should cope with the disordered system time caused by system clocks being set backwards.
What this means for anyone doing Y2K compliance testing of the OMCS extension products is that they must follow the "clean slate" testing methodology espoused by IBM in GC28-1251 and alluded to in this bulletin.
One way to do "clean slate" testing is to have a series of volume backups which are restored prior to IPLing a test system with a Y2K start date, like 31st Dec 1999, or 28th Feb 2000. As long as the OMCS database that contains your IRM or JSF or SRF files (SRF has a set of 5 databases) resides on one of these restored volumes then you are guaranteed to be starting from that same "clean slate" each time.
One important caveat mentioned in IBM's GC28-1251, section 5, is reproduced in part here to highlight one difficulty of typical Y2K testing activities:
BE CERTAIN TO HEED THE FOLLOWING REQUIREMENTS
For example, if your system is set up to scratch all files that are 1-year old, all files will be scratched when the system clock is changed to 2000/01/01 or later from any date prior to 1999/01/01.
This text refers specifically to datasets, but the problem applies more generally to any data element that can be discarded under some sort of time-stamp control.
OMCS control files contain discard dates for archived data and for captured job output and reports. OMCS assumes that the system clock is correct and will discard data that appears to have passed its discard date. The following points are relevant:
| Program | Sample JCL member | File this program cleans up |
| OMCSJDET | RUNJDET | Job detail master file |
| OMCSRVCU | RUNRVCU | Report viewing index file |
| OMCSAMUT | RUNAMUT | Archive index file |
| OMCSAMFC | RUNAMFC | Archive request queue |
| OMCSDBSR | RUNDBSR | Job detail master file |
| OMCSJDET | RUNJDET | Job detail master file |
This Y2K compliance upgrade is intended to provide full operating capability for OMCS Version 2 within the range 1st Jan 1980 through 18th May 2007. This end date is still well beyond the period of crucial interest to sites doing Y2K compliance testing. Archiving and retention of data will operate correctly until 2038.
With PTFs ASP0735, ASP0742, ASP0746, ASP0747 and ASP0748 applied, the OMCS Version 2 base product will operate correctly with system clocks set to any date in this range.
With PTFs ASP0738, ASP0743 and ASP0745 applied, the OMCS version 2 IRM product will operate correctly with system clocks set to any date in this range.
With PTF ASP0736 applied, the OMCS version 2 JSF product will operate correctly with system clocks set to any date in this range.
With PTF ASP0737 applied, the OMCS version 2 SRF product will operate correctly with system clocks setto any date in this range.
We expect that during 2000/2001 all existing OMCS Version 2 users will have upgraded to Version 3. OMCS Version 3 is designed to operate with full date functionality compliance, including Y2K compliance, through the date range 1st Jan 1980 to 31st Dec 9999.
"This section of the bulletin is for those people who need to know specific details of changes to base product files. Some customers have written their own utility programs which read OMCS control files.
"The job detail master file contains one job detail record for each job captured into the database by OMCS.
The CAPTURED field, in positions 212 through 228, currently contains a timestamp recording the creation time of the associated database file that contains the captured job output. The format of the timestamp is yymmdd-hhmmss-day . Position 211 in the record is currently blank.
This field is visible on the job selection list display when the user scrolls several screens to the right. It is also visible on the display shown when the user uses the 'u' line command against a selection list entry. Lastly the field is visible in the OMCS job audit dataset which is appended to the end of every job output captured by OMCS.
After PTF ASP0735 is applied the CAPTURED field will have the format aaaaaaaddddhhmmss where:
Position 211 of the job detail record, currently left blank, will contain an underscore '_' to indicate that the CAPTURED field is in the new format.
This is an example of the group of Y2K techniques known as data encoding.
The job sequence master file contains one record for each unique jobname ever captured into the OMCS database. Each record contains a jobname and a count of how many jobs of that name have been captured by OMCS in this database.
When a new job is captured by OMCS the output is stored in a database file called jobname #nnnnnnn where nnnnnnn is the latest value of the counter in the corresponding jobname record.
It is a common practice for OMCS control files to have an ASPLEVL=nnnn record at the front to allow OMCS programs to check that the file format (identified by the number nnnn) is one that the program supports.
After ASP0735 is applied the job sequence master file will contain an ASPLEVL record as the first record in the file. This ASPLEVL record will look like:
----+----1----+----2----+----3--- ASPLEVL=0001 ABS#=nnnnnnn
where the Absolute Job Number nnnnnnn commences at 0000000 and is incremented by 1 for each job captured by OMCS into the database.
This is a new control file that will be maintained by the OMCS writer. It will contain records that relate specific dates, as determined from system clocks, that the OMCS writer task captures jobs to a range of absolute job numbers. This file will be used by the job selection list builder to identify the earliest and latest job detail master entries to be scanned to satisfy the date range specified by the user.
As this is a new file there will not be any existing user-written ECL programs referencing this file that might need modification.
OMCS/AMF changes will be needed to support correct use of this file. The following statements should be used as a guide to how your existing AMF rules should be updated:
IF FILE(.JOBDETL DATESPAN) AND UID(OMCSWTR) THEN ALLOW /* WRITER HAS ANY ACCESS IF FILE(.JOBDETL DATESPAN) AND UID(*) AND ACCESS(D) THEN PREVENT /* NO DELETION IF FILE(.JOBDETL DATESPAN) AND UID(*) AND ACCESS(I) THEN ALLOW /* ALL OTHERS MAY READ
Both of these files contain date-time stamps in positions 1 to 13 of each record. The format of these timestamps is yymmdd-hhmmss. This format was not designed to support dates beyond 1999 (when yy would be "99"). The Y2K compliance upgrade will change the first byte of the yy portion of these timestamps as follows:
| for timestamp year range | first byte of yy will be: | comment |
| 1980-1989 | x'F8' | ie character "8" (no change) |
| 1990-1999 | x'F9' | ie character "9" (no change) |
| 2000-2009 | x'FA' | '(no assigned display character) |
This is an example of the group of Y2K techniques known as data encoding.
ASE is unaware of any customer-written programs that reference these files.
This section of the bulletin is for those people who need to know specific details of changes to OMCS extension product files. Some customers have written their own utility programs which read OMCS control files.
At the time of writing, the only changes that will occur in any of these control files are that 2 digit year fields, like the yy portion of the timestamp described above, will be able to contain the non-character value x'FA' in the first position when the year is in the range 2000 to 2009.
Any such timestamp that is displayed or printed will be converted back to an appropriate 2 or 4 digit form.
Where a four digit display form is used then a value of x'FA' in the high order byte will cause the date to be shown as '20yy' while all other values in the high order byte will cause the date to be shown as '19yy'.
Where a two digit form is used then a value of x'FA' in the high order byte will cause the date to be shown as '0y' where y is the character (0-9) from the low order byte.
This is an example of the group of Y2K techniques known as data encoding.
In many places in the OMCS Version 2 applications, dates are shown with 2 digit years. A question often heard is "Doesn't Y2K compliance mean that every date must be shown as a 4 digit year?
Well, no, it doesn't. You may wish to read more about the appropriate use of 2 digit and/or 4 digit year dates in internationally recognised standards like ISO 8601, and in the IBM publication GC28-1251, to provide background for the following discussion of ease-of-use design factors.
Why didn't our systems analysts in the '60s, '70s and '80s use 4 digit years?
Well, the overwhelming majority of applications operate over a short span of years compared with a century -and- that short interval wasn't approaching a century boundary back then.
Now, what has changed is, that, for most applications, this operational context is overlapping the century boundary. OMCS is an example of an application with a "short" operational context and hence the use of 2 digit years will be unambiguous for most aspects of the products operation.
The OMCS applications operate within a context of current data (job output, reports, etc) being collected and archived for a period which typically does not exceed 7 years, a period primarily determined by tax and other business reporting requirements.
It is the shortness of this interval, compared with the 100 year span of a century, that lets users correctly interpret any 2 digit year dates that they see on the menus, selection lists and audit reports that constitute the OMCS user interface.
This ability of users, and programs, to correctly interpret 2 digit year numbers in context is the reason that the Y2K technique of windowing can be used effectively for OMCS.
Perhaps you will agree that the appropriate use of 2 digit years, rather than forcing every user to always type, and always see and interpret, 4 digit years, actually contributes to usability and may be taken as a measure of the sophistication of the application design. Ask yourself, do you really want to write the century digits (19 or 20) on every school lunch order, or even every cheque, given that even a cheque is only valid for one year from the date written on it.
From time to time each OMCS user will have even shorter operational contexts:
On the Job Selection Criteria display the user can specify not-before and not-after dates as part of the criteria for generating a list of jobs captured by OMCS. These date fields accept a wide range of date formats, including ones with 4 digit years. However, when a user types NOV in both not-before and not-after, their real-world experience leads them to expect that this will be interpreted as not before the 1st of November this year and not after the 30th of November this year. The words this year give the implicit context assumed by the user.
By omitting the year (no digits!) the user specifies this year, the most common year OMCS users need to specify.
A well-designed user interface will try to match users expectations, including implicit context expectations. Where the user wants something else then they will need to be more explicit, saying something like NOV1996, for example.
What about not-before SAT and not-after (SUN)? Which Saturday? Which Sunday? OMCS always interprets a day-of-the-week name as referring to the most recent occurrence of that day. It's like asking a friend on Friday What did you buy on Saturday? You're not referring to the next Saturday, or a Saturday 15 weeks ago, but the last one.
Let's look further at the effect of windowing on the interpretation of 2 digit year dates by OMCS.
If a user specifies a not-before value of 1JANyy OMCS will assume that they mean 1st of January 20yy, rather than the year 19yy so long as yy is less than 80.
Why 80? Because OMCS didn't capture any output before 1983 and 1980 is often chosen as a base date for date encoding systems.
OMCS users have a typical operational context of some hours, days, weeks, even a year or two, centered around the present moment. On the few occasions they may want to query a remote era, like 1900, then they will probably be prepared to specify an unambiguous date like 1Jan1900.
Now, what about seeing a date like 001225 on a Job Selection List? Will users be tempted to assume that this means Christmas day 1900?
Well, a date like this on a list of insurance policy holder birthdates would definitely be ambiguous. In fact any application involving displaying peoples birthdates has this characteristic. Those applications have an operational time context which is comparable with the length of a century, because people can live for about 100 years. Hence the implicit assumptions that people have when dealing with any information, computerised or not, that involves peoples birthdates, property transaction dates, etc, make such applications unsuitable for windowing and require dates with 4 digit years.
By contrast, OMCS selection lists are populated by entities (jobs, reports, who changed what when) with short life spans, like 7 years, and hence any eventdates containing low 2 digit year numbers like 00, 01, 02, etc, are going to be interpreted by users as meaning 2000, 2001, 2002, etc.
Although OMCS may show the user a 2 digit year date like 001225 on a selection list display, the internal representation of such a date may be different where it is necessary for correct operation.
Finally, what about OMCS Archive Management? AMF has always operated with full 4 digit year dates and it accepts retention periods of up to 9,999 days, about 27 years, adequate for most business purposes.
Please contact us (see Contacting ASE, below) to describe any situation in OMCS in which the dates shown, or the dates specifiable in input fields, are ambiguous or confusing for you or your users.
| Telephone: | +61 3 9419 4200 Fax +61 3 9419 5848 |
| Post: | 19 Glasshouse Road, Collingwood, Victoria, 3066 Australia |