Thanks for your input Andy, yes these are all valid points.
The requirement that we have is to be able to go back to the time of a decision and
have available all pertinent information so that the same decision could be made
again. I don't know who the optimist was who wrote the requirement, but somehow he
got it approved by goverment, and I daresay it will take 10 years before the practical
difficulties cause the requirement to change.
My approach would be to specify archiving functionality in EVERY new application that
is installed with a plain-text unload method such as XML. Then, there needs to be an
archive process attached to every old application as it is retired.
The issue here is not so much to hold every record, but to hold every record *once*
rather than multiple times. I understand that this function is mandated to be in all
new systems by 2006. I'm having trouble finding new employment in my current
specialities (AIX and TSM - its a very small pond where I am) so I'm thinking of
getting ahead of the game and becoming an archiving consultant. It will certainly be
a world wide growth sector for the next few years. Every Queensland state government
department will need to be doing a project in this area in the next year or two.
Regards
Steve.
>>> [EMAIL PROTECTED] 20/07/2004 2:25:00 >>>
Some considerations for long-term archive:
- Much of today's data, as it is used from day to day, exists in some
product-specific format. If you were to retrieve that data, say, 10 years
from now, would you have software capable of reading that data?
- Even if you archive the software, will operating systems 10 years from
now be able to run that software?
- Even if you archive the operating system installation files, will the
hardware 10 years from now be able to install and run that operating
system?
- There is a good case to consider carefully what gets archived and how
you archive it.For instance, maybe for database data, it would make sense
to export that data to some common format, such as tab- or comma-delimited
records, which is very likely to be importable by most software. Likewise,
for image data, consider a format that is common today and likely to be
common tomorrow.
- 10 years from now, the people that need to retrieve the archived data
will probably not be the same people who originally archived the data.
Will your successors know what that data is? Will they know how to get to
it? ("Gee, we need to get at the accounts payable database from 10 years
ago... under which node is it archived?") Will they know how to
reconstruct it, and how to use it?
I am by no means an expert in this area, but these are some things to
consider carefully for long-term archives. Note that most of these issues
are not directly related to TSM, but apply regardless of which data
storage tool you use.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole
use of the intended recipient(s). This confidentiality is not waived or lost, if you
receive it and you are not the intended recipient(s), or if it is transmitted/received
in error.
Any unauthorised use, alteration, disclosure, distribution or review of this email is
prohibited. It may be subject to a statutory duty of confidentiality if it relates to
health service matters.
If you are not the intended recipient(s), or if you have received this email in error,
you are asked to immediately notify the sender by telephone or by return email. You
should also delete this email and destroy any hard copies produced.
***********************************************************************************
