"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"
> > 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, 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. Thinking about your problem, I realize we have a slightly different approach/implementation, that might provide some help for you: We avoided the synchronization problem between TAPEREQ and TMONSMxx because of 2 reasons: 1. For datasets mentioned in TMONSMxx, we don't have TAPEREQ statements, but use HSC exit SLSUX01 to analyze the TMS001 and TSM002 mount messages, extract the CA1 scratchpool or SCRTCH/PRIVAT from the message and modify the HSC mount parameterlist to mount a scratch from the same HSC scratchpool. These CA1 and HSC subpools must correspond. 2. For datasets mentioned in TAPEREQ statements, we specify a scratchpool in TAPEREQ and don't mention these datasets in TMONSMxx. The scratchpool in TAPEREQ is not known to CA1, so CA1 will accept tapes from non-CA1 subpools. These HSC scratchpools must therefore correspond with non-CA1 subpools. Therefor we don't have your problem when adding datasets to either TAPEREQ or TMOSNMxx, because these datasets only exist in either of the members. Only when we move a dataset from TSMNSMxx to TAPEREQ, we could run in contradicting definitions, but that happened only once or twice in the past decade. Maybe this helps. Kees. By the way: soon we will have eliminated the problem entirely, since we are moving from STC to the IBM TS7700. ********************************************************************** 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
