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

For those not into the mainframe world: In more modern terms, a 'scratch tape' is equivalent to a floppy disk with expired software that we reformat to re-use as a data disk. In an automated, or semi-automated tape library system, either the tape-robot or the tape gofer (position usually glorified with the term 'computer operator') is instructed which tape number to load, and which should never be used to save data onto (i.e. read-only). These could be software, software patches, documentation files, permanent archive backups/baselines, audit-trail tapes, or critical, permanent, historical files.

Examples: NASA data on the old 9-track systems that recorded our entire space-data downlinks for maybe 30 of the 40+ years we have been launching spacecraft and space probes. Irreplaceable(They are already having problems converting this data to a longer term storage medium.)

Permanent financial transaction records on tape archive.

Aircraft data records for the last 2 years, or the permanent history files of every change to a jet engine since before it rolled INTO the factory, much less than since it rolled out. .. Imagine talking to the IRS auditor and telling him you can't show him your last 3 year's books on disk because the Y2K bug ate them....(or told you to use those tapes to store temporary files on..)

By the way, check out the Iomega Zip/Jaz Y2K pages for updates to backup software for use with their systems... not EXACTLY the same, but the same potential for us 'microframe' users.

Doyle

-- Doyle Dacus (doydacus@feist.com), January 12, 2000.