ADSM-L

5.1.7 CRCData Parameter

2003-06-24 14:55:16
Subject: 5.1.7 CRCData Parameter
From: Shannon Bach <SBach AT MGE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 Jun 2003 13:54:31 -0500
We have just put the 5.1.7 PTF for the MVS/OS-390 TSM Server on the test
LPAR.  Although it cannot be tested extensively, I try to do every possible
task that is possible.  We upgraded to a Magstar 3494 (3590 12GB) last
year, which I use for all of TSM except the Archive's.  Instead the
Archives go directly to 3494 tapes (about 800 MB) in our old Memorex ATL.
Since the test LPAR does not have a sequential primary storage going to the
Magstar I thought to create one, the old ATL will soon be going away.   In
defining this stgpool I ran across the CRCData parameter.  After reading
everything I could about it I still haven't quite figured out if it would
be beneficial or not.  This is my take on it and if I'm wrong would someone
please let me know?
1.  By not using the CRCData (default), everything stays exactly like it
was in 4.1 or 4.2, meaning that it will still search or repair DB
inconsistencies if fix=yes, but it will go through all the data on the
volume to check for  these problems.

2.  By using CRCData=yes, the data is stored with this CRC info, which uses
more overhead on each of the tapes it writes to.  As I backup to disk and
then migrate to tape, this overhead would happen during migration and the
Offsite copy, and would probably also affect the  DB backup because of this
added CRC information.  But....when I need to audit a tape the DB would
first compare CRC data.  If both the DB and the tape CRC data is in sync it
would not have to actually go through the whole tape looking for problems
and would actually use less overhead at this time.  If they weren't in sync
and fix=yes it would then process like the old audit volume where it would
go through the whole cart looking for inconsistencies.

But the end result would be the same, right?  All the CRC data can do is
know a little faster if there is a inconsistency or save a little time if
there is not a problem but it does not actually do anything else?  So
overall it would depend on if I wanted to use more overhead in the tape
pool processing or instead in the audit of a tape?  Does anyone have other
takes on this?  I would appreciate any and all opinions.

Thank You,
Shannon

Madison Gas & Electric Co.
Operations Analyst - Data Center Services
e-mail sbach AT mge DOT com

<Prev in Thread] Current Thread [Next in Thread>
  • 5.1.7 CRCData Parameter, Shannon Bach <=