Before I try writing up the enhancement requests to three vendors, I thought I'd ask on the list to see if there's already a solution that I'm overlooking.
Here's the problem: I created a new backup job which would use "real" 9840s, and modified my HSC (StorageTek) TAPEREQ statements to reflect that, but I forgot to modify CA-1's TMONSMxx statement so that the job used tapes from that scratch pool. CA-1 therefore rejected every scratch 9840 tape mounted because the tape was from a specific scratch pool and the request was not for that pool - IECTMS3 not scratch message with reason code 84. Every time one of these IECTMS3 messages happened, the tape was marked scratch in the STK CDS. This, naturally, depleted by scratch pool causing failures in other jobs as well. Yes, I have now fixed the error, but I think somewhere along the line the various pieces of software involved should be modified so that scratch pool rejections like that do not cause the tape to be marked as non-scratch in the CDS. It's not a simple case however: CA-1 rejects the tape and drives another mount. HSC sees each mount as an individual thing. Therefore, if the tape is still scratch, it might get mounted again immediately, causing the job to "loop" forever mounting the same tape or set of tapes (depending upon how HSC picks what the next scratch tape to mount is). Because ot that kind of issue, I'm thinking this is a three-vendor problerm: A. The original mount (IBM message) needs some sort of identifier to identify a unique mount sequence. B. CA-1 needs to use that identifier in all subsequent mounts used to satisfy the original request. C. HSC needs to avoid marking the tapes as non-scratch in this situation, but it also needs to keep track of the tapes it has already mounted for the uniquely-identified request so that it can bypass tapes it has already tried. Has anyone developed or seen a solution for this, or even things which would help? Obviously, paying enough attention to what I'm doing to avoid making these mistakes is the first thing, but I'm afraid there's not a debugging tool for the software running on the old "grey matter" box, so I'm looking for solutions that run on z/OS . Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
