On Fri, 5 Feb 2016 11:54:37 -0600, Tom Marchant <[email protected]> wrote:
>Many years ago, I had a colleague run REPOR MERGECAT as a way of creating a >backup >copy of some catalogs. I didn't notice the caution in the manual that says >that the old >catalog should not be used to access the VSAM data sets after the MERGECAT >operation. > >The result was that the VVDS entries for all of the VSAM data sets in the >catalogs had been >updated to point to the new catalog. The aliases were not changed, so the >system continued >to use the old catalogs. There were a lot of data sets in the same condition >that you describe. > >I don't remember what the problem was that this caused. Perhaps it had to do >with restoring a >data set from a backup. Art called me the following week to tell me about the >problem and ask >for suggestions as to what he should do to fix it. > >Maybe Art remembers what problems were caused by it. We both learned a lot >from the >experience. I was hoping never to speak of this again =^O I did learn more about ICF catalog structure that I ever thought I wanted to. The problem was actually with REPRO NOMERGECAT, though similar results can likely be achieved with MERGECAT, if you work at it. Neither of us noticed the caution, which, if memory serves, is now a more visible _warning_. BTW, this was in DFP v1 (yes, MVS/SP). As Tom stated, the VVRs were updated, however the datasests were still accessed via the original catalogs. As long as the datasets didn't move, everything was fine. We ran for days, maybe even a week or more, until application reorgs started to run. The standard process at the time was to REPRO to a PS file, delete/define, then REPRO from the PS file into the VSAM file. The REPRO ran without incident. So did the DELETE, though it shouldn't have (IMHO). Because the VVR back-pointer didn't match the catalog containing the BCS entry, AMS did not delete the VVR entry, though it did delete the BCS and VTOC entries. Next, the VSAM dataset is defined anew in the standard search order, so AMS created a BCS entry, a duplicate VVR entry, which fell after the previously orphaned VVR entry, and a VTOC entry. Still no consistency checking done or errors reported. Finally, when the REPRO ran to repopulate the VSAM dataset, all hell broke loose, because AMS found and used the old VVR entry, pointing back to the wrong catalog, with information that did not match up with the VTOC entry. At this point AMS decided at last to throw an error message and fail the operation. The error message of course was obscure and obtuse, and it took a sev1 with IBM to figure out what was really going on. It was then suggested we run DIAGNOSE to see how much trouble we were in...let's just say it took us 2-3 weeks to dig out, because, well, we didn't stop at a single alternate catalog...we had to create one for every catalog in the system. Thankfully we had a Rexx wizard who wrote up a couple of programs to process DIAGNOSE output and generate AMS statemnts to EXPORT PERMANENT, DELETE VVR, and IMPORT for each afflicted dataset. Otherwise, it might have taken 2-3 months. There were a handful of datasets that had VTOC problems, too, but it's a little hazy - those could have been from failed attempts to repair the problem before we fully understood it. We had to zap a few VTOC VSAM bits so to complete the cleanup. Art Gutowski General Motors, LLC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
