🚀 go-pugleaf

On Sat, 9 Jan 1993 03:57:06 GMT Stan Horwitz said:
>...stuff deleted...                                        exactly  how much
>trouble will we be in if this catalog file become corrupt or destroyed?

Stan,

If this data is so critical I think a DASD failure is the least of your
problems.  Have you taken a close look at VM/Archive's ability to
create "twins".  Most people skim over the sections on twins.  They
just create them and assume that they can be used for disaster recovery.
Unfortunately, while a tape set is open, BOTH THE PRIMARY AND THE TWIN
MUST be ON SITE!  If you had a disaster that destroyed you tape library
all of the data on the open tape sets would be lost forever since you
had no way of creating an off site copy of the data.

When people think about disaster recovery they concentrate on DASD and
as they create tapes they create an on site and an off site copy.  They
forget the VM Archive tape pools are really just a logical extension
of their DASD and must be recovered in a disaster.  Your only options
are to close out tape sets frequently (like every day), mark the twin
as missing, and send it off site.  You then have to go through merge
purge on a regular basis and take the twin of the merge purge off site
before you bring the other twins back.  AN EXTREMELY MESSY PROCESS
WHICH IS PRONE TO ERROR.  The other option which we have chosen to
implement is a tape duplication process.  WARNING!  The whole process
is more complicated than just a tape copy.  You need to generate a
tape with the same VOLSER (this causes headaches when the tapes are
returned to the scratch pool and have the wrong VOLSER).  You also
need to keep the HDRn files in tack.  This can be tricky; we're willing
to share our code to do this with anyone that's interested.

Flame on...

I can not believe that people are putting up with this problem,
unfortunately, many people don't even know a problem exists.  This
problem is extremely serious.  Lack of a REASONABLE method of disaster
recovery jeopardizes the integrity of the data.  If you had a fire that
destroyed you tape vault today how much VM/Archive data would you
loose?  Most people that realize this problem exists do not put
"production" data in VM/Archive because they can't afford to loose
the data.  That's really the key: DON'T STORE ANYTHING IN VM/ARCHIVE
THAT YOU CAN'T AFFORD TO LOOSE.

I can't believe that we're all paying these outrageous upgrade fees to
move to VM/Archive/E.  What are we getting for it?  I understand that
they are adding some interesting new function to the next release
but what good is new function when there is a serious problem that
jeopardizes the integrity of the data?  Systems Center should always
address all data integrity problems before they even think about adding
new function.

Systems Center knows about this problem.  I've discussed it with them a
number of times.  It's a tough problem.  I get the impression that they'd
rather spend time adding function that sells more copies of the
product instead of spending time to address integrity problems that
many people are not aware of.  This is not the way I'd treat my
customers!

If anyone is interested, I've been discussing this problem with the
people at Syncsort.  They sell a product that competes with VM/Archive.
They use the same basic architecture as VM/Archive which means they
have the exact same problem.  The big difference is that SYNCSORT SEES
THIS PROBLEM AS AN OPPORTUNITY TO MAKE THEIR PRODUCT BETTER THAN
VM/ARCHIVE AND AN OPPORTUNITY TO TAKE MARKET SHARE.  I doubt that
Systems Center is going to do much about this problem until they
realize that people are mad and are willing to talk to another vendor.
If you are interested in discussing this problem with SYNCSORT just
send me a note and I'll be glad to give you the names and numbers of
the people at SYNCSORT who are addressing this issue.

Flame off...


Thanks,

Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)