ADSM-L

Re: [ADSM-L] Database move

2007-11-08 15:51:36
Subject: Re: [ADSM-L] Database move
From: "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 8 Nov 2007 15:50:34 -0500
>From past experience, moving from Burroughs to Honeywell to IBM
mainframe to IBM RISC --

ALL archival data will be flat-file database unloads, with the entire
key structure required on each data record; the records will be
display-format ASCII or Unicode UTF-16; the records will be fixed
length, with a length divisible by 4. Any other archival format, for
data over five years old, it will be cheaper to pay the fine/judgment
than to retrieve the data.

And ALL record layouts and database designs will be archived ON PAPER.

I'm looking forward to the end of the year; I have some old mainframe
DASD backups (Innovation FDR/ABR 3480) of a Cyborg payroll system that
will simultaneously hit 7 years and a month AND the trash.

Tom Kauffman
NIBCO, Inc

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dwight Cook
Sent: Thursday, November 08, 2007 1:40 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Database move

if your media is portable to your new platform, you should be able to
just
export/import your data base...
then modify your library definition to point to the new device
definition...
put in new drive definitions...
and you are back in business...

NOW... for legally required long term data retention...
You never really want to depend on anything other than spinning dasd in
a
live environment for that.
Use an archive server, place your data over there on spinning dasd and
back
it up with TSM...
Then if you have a hardware issue and the data gets corrupted, restore
it
with TSM.

Otherwise you really need to have dual tape copies and test each tape at
least yearly to ensure your data remains usable because gravity impacts
everything, even tapes that just sit. (and by test I mean create a new
tape
and roll the old tape back into tape rotations and if your read fails,
retrieve your alternate copy and use it to create your new copy)


Dwight E. Cook
Systems Management Integration Professional, Advanced
Integrated Storage Management
TSM Administration
(405) 253-4397
(877) 625-4186
T/L 349-4361



-----Paul Zarnowski wrote: -----

>Your avenue is export / import. Not pretty if you have a lot of
>data.  And I'm talking about the data, not just the database.
>As I believe more people will be interested in switching server
>platforms as time goes by, I would really like to see IBM provide
>some better migration tools for helping sites transition from one
>server platform to another. TSM is a high-end solution, and needs
>better tools in this area (IMHO).

I work for a hospital. We are required to retain some clinical
records for as long as 25 years (a former pediatric patient gets a
seven year window after his or her eighteenth birthday to decide
whether to sue the hospital). We are required to maintain
information on employee health for the lifetime of the employee.
We can't realistically commit to staying with our current server
platform for decades to come, and the prospect of exporting and
importing would get increasing daunting as long-lived archives
accumulated. We are currently looking at options for long-term
archiving of digital data, and the poor support for platformchanges is a
major point against using TSM.
CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.


<Prev in Thread] Current Thread [Next in Thread>