"Tim Hare" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED] e.fl.us>... > 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 Tim, I know the problem and found out that I had to live with it. So I can't provide you with a solution, but there are a couple of things in your analyzes that could do with some clarifications/corrections: 1. The basic problem is the different view on tapepools by CA1 and HSC. If a scratch is requested without a pool specification, HSC allows any tape, while CA1 only allows non-subpool tapes. 2. If HSC has mounted a scratchtape, it marks it as non-scratch, because it has no view on what has happened to the tape when it is dismounted. It remains non-scratch till the next scratch-synchronization and therefor it will never mount the same tape again on the retry, but wil mount the next tape. 3. The "next" is dependent on the sub-pooling in the HSC. If you have subpools in HSC, it will select the next tape (within the same silo to avoid pass-throuhgs) from the same pool, until another job requesta a tape from another pool, after which the error-job will be satisfied with the next tape from this new pool (I hope I am clear). Basically, given enough time, you will run out of all scratches in your HSC. 4. You can somewhat tackle and automate the problem by setting WARN thresholds for your HSC scratchpools and run scratch-synchronization or even more CA1 maintenance to provide the HSC with a new set of scratchtapes. 5. Finally, the operator must detect and cancel this destructive job. Kees. ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************************** ---------------------------------------------------------------------- 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
