ADSM development and service personnel have recently been involved in a number
of situations involving Y2K testing. These tests usually involve setting the
system date for the ADSM server forward into year 2000 or 2001 and performing
client backup, archive and server database backup operations.
This notice has been developed to inform our customers of the consequences in
performing these kinds of tests, especially on production systems, and to
communicate recommendations for performing these tests.
When you set your system date forward in time it affects 2 important aspect of
ADSM policy: file retention and versioning. The effect on retention should be
the easiest to realize - if you have established a 60-day file retention time
and reset your system date to 1 year in the future, then all but the active
files in your backup repository will be deleted when an expiration is executed:
1 year is more than the 60-day retention time you established. Your archive
data will also be subject to this problem, since retention is the only attribute
that determines when ADSM removes archive files.
Versioning is also date-based: the "latest" version of a file is that version
that has the latest backup date, so if you set your date forward, back up some
files, and then set the date back to today, the latest version of the file will
be the one that was backed up when the date was set into the year 2000 (or
2001). What this means is that any "new" versions of the file will be recorded
as earlier versions than the one that was backed up when the date was set to the
year 2000. In fact, new changes will be versioned off in favor of the versions
that were backed up when the date was set to a time in the future. The BACKUP
date/time for files that are sent to the ADSM server is the date/time as
recorded on the server when the files are received, not the date on the client
when the files were sent.
If you perform a server database backup while the date is set to some future
date, you will not be able to delete all of your database backup volume history
records after the date is reset to the present. Activity log records will
likewise be recorded with future date information and will not deleted by normal
pruning processes until the actual date to which the server was set does occur.
When the ADSM server detects a significant date change, message ANR0110E is
issued and server functions are disabled until an authorized administrator
issues the ACCEPT DATE command. Before issuing this command, please examine the
date on your system and consider the points in this notice.
To avoid these date-related problems IBM recommends the following:
1. Do not perform these kinds of Y2K tests on your production systems
2. If a test MUST be performed on a production ADSM server the following should
be done prior to adjusting the system date:
a. Perform a full database backup
b. Disable migration and reclamation by adding the NOMIGRRECL keyword in your
server options file
c. Disable expiration processing by placing the following statement in your
server options file:
EXPINTERVAL 0
After the system date has been reset to the correct date/time (when testing is
complete), restore your database to the current time (using the TODATE=
parameter on the dsmserv restore db command) and audit storage volumes that
appear in your volume history file after the (valid) date of the last database
backup. All disk storage pool volumes should also be audited.
You might also consider making a copy of your production server using the
database and storage pool backup functions. This copy can be used to establish
a test system that would utilize the restored database and copy storage pool
volumes for isolated Y2K testing that would not affect data. Please refer to
your ADSM administrative documentation for the procedures that can be used to
create this copy.
For information in Y2K readiness for IBM products, please refer to
http://www.ibm.com/ibm/year2000/
|
