home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / lvmctr / 334 < prev    next >
Encoding:
Text File  |  1993-01-12  |  4.4 KB  |  93 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!usc!howland.reston.ans.net!paladin.american.edu!auvm!ROHVM1.BITNET!MBDMD
  3. Message-ID: <L-VMCTR%93011208154739@VM1.CC.UAKRON.EDU>
  4. Newsgroups: bit.listserv.l-vmctr
  5. Date:         Tue, 12 Jan 1993 08:15:47 -0500
  6. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  7. From:         "Martin J. Doyle (215) 752-2296" <MBDMD@ROHVM1.BITNET>
  8. Subject:      VMarchive dasd crash
  9. Lines: 82
  10.  
  11. On Sat, 9 Jan 1993 03:57:06 GMT Stan Horwitz said:
  12. >...stuff deleted...                                        exactly  how much
  13. >trouble will we be in if this catalog file become corrupt or destroyed?
  14.  
  15. Stan,
  16.  
  17. If this data is so critical I think a DASD failure is the least of your
  18. problems.  Have you taken a close look at VM/Archive's ability to
  19. create "twins".  Most people skim over the sections on twins.  They
  20. just create them and assume that they can be used for disaster recovery.
  21. Unfortunately, while a tape set is open, BOTH THE PRIMARY AND THE TWIN
  22. MUST be ON SITE!  If you had a disaster that destroyed you tape library
  23. all of the data on the open tape sets would be lost forever since you
  24. had no way of creating an off site copy of the data.
  25.  
  26. When people think about disaster recovery they concentrate on DASD and
  27. as they create tapes they create an on site and an off site copy.  They
  28. forget the VM Archive tape pools are really just a logical extension
  29. of their DASD and must be recovered in a disaster.  Your only options
  30. are to close out tape sets frequently (like every day), mark the twin
  31. as missing, and send it off site.  You then have to go through merge
  32. purge on a regular basis and take the twin of the merge purge off site
  33. before you bring the other twins back.  AN EXTREMELY MESSY PROCESS
  34. WHICH IS PRONE TO ERROR.  The other option which we have chosen to
  35. implement is a tape duplication process.  WARNING!  The whole process
  36. is more complicated than just a tape copy.  You need to generate a
  37. tape with the same VOLSER (this causes headaches when the tapes are
  38. returned to the scratch pool and have the wrong VOLSER).  You also
  39. need to keep the HDRn files in tack.  This can be tricky; we're willing
  40. to share our code to do this with anyone that's interested.
  41.  
  42. Flame on...
  43.  
  44. I can not believe that people are putting up with this problem,
  45. unfortunately, many people don't even know a problem exists.  This
  46. problem is extremely serious.  Lack of a REASONABLE method of disaster
  47. recovery jeopardizes the integrity of the data.  If you had a fire that
  48. destroyed you tape vault today how much VM/Archive data would you
  49. loose?  Most people that realize this problem exists do not put
  50. "production" data in VM/Archive because they can't afford to loose
  51. the data.  That's really the key: DON'T STORE ANYTHING IN VM/ARCHIVE
  52. THAT YOU CAN'T AFFORD TO LOOSE.
  53.  
  54. I can't believe that we're all paying these outrageous upgrade fees to
  55. move to VM/Archive/E.  What are we getting for it?  I understand that
  56. they are adding some interesting new function to the next release
  57. but what good is new function when there is a serious problem that
  58. jeopardizes the integrity of the data?  Systems Center should always
  59. address all data integrity problems before they even think about adding
  60. new function.
  61.  
  62. Systems Center knows about this problem.  I've discussed it with them a
  63. number of times.  It's a tough problem.  I get the impression that they'd
  64. rather spend time adding function that sells more copies of the
  65. product instead of spending time to address integrity problems that
  66. many people are not aware of.  This is not the way I'd treat my
  67. customers!
  68.  
  69. If anyone is interested, I've been discussing this problem with the
  70. people at Syncsort.  They sell a product that competes with VM/Archive.
  71. They use the same basic architecture as VM/Archive which means they
  72. have the exact same problem.  The big difference is that SYNCSORT SEES
  73. THIS PROBLEM AS AN OPPORTUNITY TO MAKE THEIR PRODUCT BETTER THAN
  74. VM/ARCHIVE AND AN OPPORTUNITY TO TAKE MARKET SHARE.  I doubt that
  75. Systems Center is going to do much about this problem until they
  76. realize that people are mad and are willing to talk to another vendor.
  77. If you are interested in discussing this problem with SYNCSORT just
  78. send me a note and I'll be glad to give you the names and numbers of
  79. the people at SYNCSORT who are addressing this issue.
  80.  
  81. Flame off...
  82.  
  83.  
  84. Thanks,
  85.  
  86. Martin J. Doyle
  87. VM Systems Programming Contractor
  88. Rohm and Haas Company
  89. Philadelphia,  Pennsylvania
  90. MBDMD@ROHVM1
  91. (215) 592-6865 (Day)
  92. (215) 752-2296 (Evening)
  93.