On Fri, 27 Feb 2009 08:32:23 -0500, Lizette Koehler wrote: >Running z/OS V1.9 with JES2, GRS, and CA1 > >I have a production batch job that has been running fine for months passing >a tape from one step to the next. Now it is receiving CBR4000I messages >indicating that the tape is already mounted on a different drive. > >The previous step is (,CATLG) and VOL=(,RETAIN,REF=*.prevstep.ddname) for >all of the datasets that are to be stacked on the same tape. And the next >step uses the same coding technique for stacking its datasets on the >previous steps output tape dataset. > >The job will get the CBR message to Cancel Retry or Wait. When Cancel is >replied the job fails with S613-1C > >Okay, I can see that. The tape is still mounted on the drive from the >previous step and now the next step wants it to be mounted on a different >drive. No Dismount has been issued between the steps. > >IBM is telling me that this is normal. That something called tape stealing >can occur in a busy system and they looked at my dump and see that the UCB >has been cleared. >
We have this problem too. We get around it by defining the tape drives as a resource in our scheduler and only allowing a certain number of JOBs to run against that resource at a time. We still run into issues occasionally when users submit a JOB to access a tape and all the drives are being used. We have eight of the drives and set the resource to seven. That allows one user JOB to enter the mix without issue. If there are more, drive stealing occurs and the operators cancel user JOBs. Seems pretty silly, but that's the way IBM suggested we deal with it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
