Tim, Actually, I thought that STK had already corrected this problem. I know that both IBM and CA-Vtape already have "limits" set, so that if a scratch request is made and re-made too often within a set period of time the job will be abended. For example, with CA-Vtape I believe the default limit is 5 times within xx minutes. A normal job that actually writes data will not be able to "fill" that many tapes that quickly; so they don't have a problem. And I am almost positive that IBM has also such a throttle on both their 3494/ATL and 3494/VTS environments.
I had thought that STK has something similar, but maybe it only applies to their virtual environment. We (CA-1) had thought about adding some similar logic (we know if we are rejecting a tape, and if we reject the tape mounted more then xx times without a success to clear the counter we would abend the job). But to be honest, when both IBM and CA-Vtape came up with similar solutions (and I thought STK had as well) we decided to put that project on the back-burner since it wasn't needed anymore. If we don't hear from STK on this list, I will send a note directly to my contact at SUN/STK and find out more tomorrow. Russell Witt CA-1 Level-2 Support Manager -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Tim Hare Sent: Wednesday, December 13, 2006 8:45 AM To: [email protected] Subject: Tape mount / CA-1 / STK question 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
