IBM has decided to keep the Y2K alert page up a while longer too... Maybe someone could explain the ramifications likely impacts of this report? What sorts of problems will result?

'DFSMSrmm: Tapes with datasets set to EXPDT 99365/99366 & >1999 may be released to scratch in error

PROBLEM: This situation applies for tapes containing multiple or stacked datasets. If datasets with "never expire" expiration dates of 99365 or 99366 are stacked on the same tape with datasets with expiration dates set to expire in 2000 and beyond, the tapes may be released to scratch in error.

Normal processing assigns tapes a "never expire" expiration date when at least one dataset on the tape contains a "never expire" expiration date. Instead, the tape is being assigned the expiration date of the dataset with an expiration date after 1999 and is eligible to be released to scratch when that expiration date has been reached.

The only tapes that are affected are those containing "stacked" datasets that have "never expire" and >1999 expiration dates. The only datasets released to scratch incorrectly are those set to "never expire" (99365/99366) that are on the same tape with datasets set to expire after midnight on 12/31/99.

For example, if a tape contains dataset A.B.C with an expiration date of "never expire" and dataset D.E.F with an expiration date of 2000/003, DFSMSrmm assigns the tape an expiration date of 2000/003 rather than "never expire". As a result, the tape and datasets will be scratched on day 2000/003 rather than retaining the tape and data forever. Because EXPDT 99365 and 99366 are special dates indicating "never expire", DFSMSrmm should have assigned the tape a "never expire" expiration date.

Customers using DFSMShsm or Tivoli Storage Manager (5697-TSO)/ADSM (5655-A30) owned tapes will not experience this problem. Customers managing their tape data exclusively by Vital Records Specification, "VRS", without the use of "until expired" within the Vital Record policies, will not experience this problem. Customers who have implemented YR2000 APAR OW26043 by specifying the RMM PARMLIB member MAXRETPD(xxxx) with a value other than NOLIMIT are not affected by this problem for any tapes created since the customer implementation of the MAXRETPD parameter. RESOLUTION: Suspend housekeeping if exposure to this situation is suspected. Final PTFs are now available from APAR OW42560. Click on the APAR number to search IBMLink for this APAR to view the details and obtain the applicable PTFs for your installation. UPDATED: 01/11/2000, 17:05:25 GMT

Link to IBM y2k alert

http://www-4.ibm.com/software/year2000/alert/indexbydate.html

-- Carl Jenkins (Somewherepress@aol.com), January 11, 2000

Answers

If I recall, Cory Hamasaki discovered this in his work and posted it here several days ago - I wonder if he notified IBM - just a thought.

Robert Bright

-- robert bright (roosterbos@go.com), January 11, 2000.

>Maybe someone could explain the ramifications likely impacts of this report?

Some IBM software properly handles the values of "99365" and "99366" in dataset expiration fields, and some doesn't. The IBM report posted above specifies some cases of each category.

>What sorts of problems will result?

Short answer: Lots of businesses might lose lots of very important data. IMO this could be a candidate for the most serious single Y2k programming error because it can affect so much data at so many different places in such a serious way.

Longer answer: The expiration date field of a dataset specifies when a dataset _may_ (not _must_) be deleted. If software incorrectly handles an expiration date, the result could be that a dataset is deleted before it should have been.

This is especially serious in the case of expiration date values 99365 and 99366 because those are "special" values intended to signal that the associated dataset should _never_ be deleted (not even on the last day of 1999!).

So what we have here (BTW, this was widely foreseen as a potential Y2k problem many years ago) is the possibility that thousands of IBM mainframe customers may lose millions of datasets that they wanted never to be deleted. Note: this is only a _possibility_, but the possible consequences are quite serious and far-reaching.

Background:

One large category of programming error involves the interpretation of a given number (or, equivalently, bit pattern) in multiple incompatible ways. Long ago I began using the phrase "A bit cannot serve two masters" to express this to my coworkers.

A common example of this error is the use of so-called "special" values in data fields such as a year number. Back in the 1950s, 1960s, 1970s, and even 1980s, the year 1999 seemed so far in the future as to be disregardable. Many programmers used the value "99" in a two-digit year field to mean something other than the year 1999. And they either used the value "00" to mean something other than the years 1900 or 2000, or else they completely forgot to properly take care of the instances in which the year number field would have the value "00".

Even IBM was not immune to committing this error. It decided, somehow, that it was acceptable to use the value "99365" in an expiration date field to mean not the 365th day of the year 1999, but instead to mean "infinity". That is, while the value "78365" referred to expiration on December 31, 1978, the value "99365" meant "never expire" instead of "expire on December 31, 1999".

NOW, what's happening is that when some IBM software is set up to correctly handle expiration dates beyond 1999, it is interpreting "99365" as December 31, 1999 instead of "never expire".

-- No Spam Please (nos_pam_please@hotmail.com), January 11, 2000.