System 1032 and Year 2000 compliance
by Nancy Diettrich
System 1032 has always been Year 2000 compliant in that it uses a variation of the OpenVMS data type to store dates and times in a dataset. Even a 2-digit date is stored using the maximum precision possible. This practice provides a range for dates of January 2, 0000 to January 1, 9999. The only issue for System 1032 in the 21st century is the interpretation of 2-digit years (for example, 03/15/55) on input.
V9.61-0 and earlier versions of System 1032 assigned all 2-digit years (with the exception of an RD using date format 5, YYMMDD) to the 20th century. The newest version of System 1032, V9.70, introduces a system variable, $CENTURY_BOUNDARY (data type integer) to give you control over the century to which 2-digit dates are assigned.
For example, if the value of $CENTURY_ BOUNDARY is set to 1945, then 2-digit years greater than or equal to the value of 45 are interpreted as belonging in the 20th century. Two-digit years that are less than 45 are interpreted as belonging in the 21st century. The date 03/15/55 is interpreted as March 15, 1955, while 08/30/25 is interpreted as August 30, 2025.
Starting with V9.70, you can dump dates in other centuries using formats with 2-digit years (RDs using date formats 2, 3, and 4) by setting $CENTURY_ BOUNDARY to the first year of the desired century; that is, 1900 for the 20th century, and 2000 for the 21st century. By default, $CENTURY_BOUNDARY is set to be the first year of the current century, as determined by the system clock.
When dumping dates with 2-digit years using an RD with date formats other than 5, all dates must be within the same century. When reloading the data, $CENTURY_ BOUNDARY must be the same value as at dump time. Because the value of $CENTURY_BOUNDARY is not stored as part of the dump file, you must record that value in a secure place.
In versions prior to V9.70, the only way to dump 2-digit years across centuries is by the use of an RD with a date format 5. You can then use $CENTURY_BOUNDARY in Version 9.70 to control the interpretation of these dates during a subsequent load.
Note that no value for the system variable $CENTURY_BOUNDARY allows date values across three or more centuries to be interpreted correctly, if dumped in a format with 2-digit years.
An attempt to dump dates with 2-digit years across the century boundary using an RD with a date format other than 5 gives the following errors:
%S1032-W-DUMCNVERR, error converting to field <name> - set to default value Invalid value input from ID <#> of <dsname> dataset -S1032-E-CBFOVFL, character buffer overflow
This error occurs for every record that contains a date that falls outside the century designated by $CENTURY_BOUNDARY. The system default value (MISSING) is output to the DMO file.
The table below illustrates the values placed in a DMO file for each date as the value of
$CENTURY_BOUNDARY changes from 1800 to 1900 to 2000. The RD used the date format FORMAT 4 LENGTH 6. For each MISSING value in the file, System 1032 issued the DUMCNVERR and CDFOVFL error.
The results for format 5 are given for comparison and to illustrate that the use of RD date format 5 renders the year value ambiguous when multiple centuries are involved. For this reason, CCA recommends that you dump date values as 4-digit years.
If your current applications dump data using an RD with date formats 2, 3, or 4 and the dates straddle the century, CCA recommends that wherever possible change the RD to use date formats that dump a 4-digit year.
If your receiving application requires only a 6-character format, you can change the date format in the RD to 5. Keep in mind that the order of items within the date has changed to YYMMDD.
If you have any questions concerning $CENTURY_BOUNDARY or date values across centuries, contact System 1032 Customer Support.
Enclosed with this CCAPRINT issue is an index of CCAPRINT technical article titles, from the premier May 1996 issue to the present.
This index also appears on the Web site. The Web site version will be updated monthly. The printed version will be updated and mailed to you annually in December.
In 1997 CCA analyzed over 150 Customer Surveys and interviewed 144 representatives from 82 user organizations. Thanks to that customer participation, CCA published the 1996 Product Plans that will take us forward to the year 2000. The first tangible results of the Product Plans are the commercial releases of Model 204 V4R1 and System 1032 V9.7.
CCA intends to revisit those plans every 12-15 months to refine them as your needs and desires for CCA products change. When you receive a copy of the 1997 Customer Survey within the next week, please take a few minutes to respond. For additional copies, call Sharon Gilberti at 508-270-6666, or send e-mail to sharon_gilberti@cca-int.com.
If your organization has conflicting priorities among application groups or business areas, each can submit a response; however, multiple responses from one organization will be prorated. We hope to increase your participation this year to give CCA an even broader and deeper understanding of where you want us to focus our development resources.
In September and October CCA will host regional meetings, where your senior technical staff can meet for an open exchange of ideas with representatives of CCA marketing, development, and technical support to ensure that CCA's survey analysis is on target. At the end of November, CCA will present first
drafts to the Customer Advisory Board, a body made up of senior managers from a number of customer sites. The final versions will be published in February, 1998.
We look forward to your replies!
Living an ORDERED Life
by Jim Damon
As a DBA you might well appreciate the overwhelming operational advantages of ORDERED fields vs. KEY fields. In addition to the increased functionality for ORDERED fields-pattern matching and range retrievals, ordered processing without sorting, for each value processing, support for invisible fields-you can reduce maintenance costs by eliminating TABLEC FULL conditions.
Have you ever seen the following messages?
M204.1270: TABLE C FULL - PROPERTY ENTRY,... M204.1272: TABLE C FULL - PAGE ENTRY:... M204.1273: TABLE C FULL - REDEFINE:...
At this point, any attempt to add new Table C index entries fails, and you must reorganize the file to enlarge Table C (CSIZE). Reorganizing a large file (+5M records) can be time-consuming, and the requirement to reorganize often comes at an inopportune moment (such as the middle of the night, or during a critical processing period at month end or quarter end).
Stable Table D
Let's look at Table D and the ordered index: unlike a Table C full condition, you can easily accommodate a Table D full condition by issuing a dynamic INCREASE DATASETS command followed by a dynamic INCREASE TABLED command. Essentially, filling Table D never necessitates a file reorganization, and the dynamic increase process can continue until 16M pages have been allocated to Table D.
Consider a typical Table C with 60% utilization. In this case, each physical I/O to a Table C page results in reading almost 2500 bytes of hex zeroes - 40% * 6144 bytes worth of hash cells are unused. A typical ordered-index leaf page starts out at 85% utilization, although you can increase that percentage for read-only or seldom-updated fields to 99% with NRESERVE and LRESERVE.
Data sharing
The potential for large performance gains through the ordered index relates to the increased opportunity for data sharing. Date fields provide a good example of how this works.
DATE_OF_BIRTH, for example, usually has a maximum of 365 different values for one year. As a key field, these values are hashed to find a Table C hash cell. In a large Table C, say CSIZE=10000, 8.77M hash cells are available.
The Model 204 hash algorithm distributes these values widely across all available hash cells. This means, in the worst case, that the 365 values (property entries) of DOB might land on 365 different Table C pages. Each user who does a FIND on a unique value of date probably incurs a physical I/O to Table C, because the values hash to randomly distributed pages. In the ordered index, however, all 365 values are on one leaf page (in ascending sequence) and multiple users asking for different values of date share the same leaf page and incur no physical I/O.
Successful user testifies
One user who converted all fields in all files to ordered index saw a 40% reduction in file I/O across all Model 204 files. This result might reflect both the data sharing potential of the ordered index coupled with applications using ordered index syntax against key fields. Even though that syntax (pattern-match finds, IS GT, IS LT, and so on) is supported for NON-ORD fields, it often results in direct searches of Table B and other inefficiencies, which disappear when all fields are converted to ORD.
There might still be specific types of data or specific applications that perform better using the KEY attribute. Those instances are rare and most likely to occur with random access to very large files.
Conversion to ORDERED, however, would not be palatable if it involved any application coding changes. Fortunately, it does not. Set CSIZE=1 and convert your KEY, NR, and FRV fields to ORDERED by changing a few DEFINE FIELD commands the next time you reorganize a file.
Conversion to ORDERED is transparent to all applications and requires no coding modifications whatsoever, unless you are using the FLOD LOCATE command, which does not support ORDERED CHARACTER.
Increased performance and reduced maintenance coupled with increased functionality make ORDERED an easy choice.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
