Tape Stealing in z/OS with CBR4000I
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. Yet there does not seem to be a solution other than perhaps changing the job to only do one step for stacking datasets on a tape or having an operator issue a manual dismount when this message occurs. Has anyone run into this situation? When you will get the CBR4000I message in a multiple step job trying to pass a tape which is having datasets stacked on it, from one step to another? If so, how do you resolve the CBR4000I messages? Lizette -- 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
Re: Tape Stealing in z/OS with CBR4000I
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Friday, February 27, 2009 7:32 AM To: IBM-MAIN@bama.ua.edu Subject: Tape Stealing in z/OS with CBR4000I 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 step's 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. Yet there does not seem to be a solution other than perhaps changing the job to only do one step for stacking datasets on a tape or having an operator issue a manual dismount when this message occurs. Has anyone run into this situation? When you will get the CBR4000I message in a multiple step job trying to pass a tape which is having datasets stacked on it, from one step to another? SNIP I have a similar situation with allocation using cartridge drives. I have 4 drives, with my tapes MOUNTed (MVS MOUNT). When a restart happens (long story, but the job restarts a process and goes back through allocation), ALLOCATION asks for a new drive. It should know that the volume it wants is mounted, yet it still asks for a new drive (which doesn't exist in this case) to put the *MOUNTed* volume on. I have a second situation where an MVS MOUNT has been done, but the job step has a label problem (one of its own making). OPEN causes the MOUNT to be terminated! Me thinks that something in allocation (and possibly a conflict from inside of DFP O/C/E) is not working quite right. Regards, Steve Thompson -- Opinions expressed by poster may not be those of poster's employer. -- -- 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
Re: Tape Stealing in z/OS with CBR4000I
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
Re: Tape Stealing in z/OS with CBR4000I
Oh good, I am not alone. I am pushing IBM at the moment to try and rectify this condition. However, I felt I was in a losing battle. Seems I was correct. I will redo our side and leave poor over worked IBM alone. Lizette 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
Re: Tape Stealing in z/OS with CBR4000I
Would changing the disposition from CATLG to PASS help? (You would have to add a catalog step at the end of the job.) -Original Message- From: Lizette Koehler Sent: Friday, February 27, 2009 5:32 AM To: IBM-MAIN@bama.ua.edu Subject: Tape Stealing in z/OS with CBR4000I 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 step's 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. Yet there does not seem to be a solution other than perhaps changing the job to only do one step for stacking datasets on a tape or having an operator issue a manual dismount when this message occurs. Has anyone run into this situation? When you will get the CBR4000I message in a multiple step job trying to pass a tape which is having datasets stacked on it, from one step to another? If so, how do you resolve the CBR4000I messages? -- 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
Re: Tape Stealing in z/OS with CBR4000I
On 27 Feb 2009 11:54:41 -0800, in bit.listserv.ibm-main you wrote: Would changing the disposition from CATLG to PASS help? (You would have to add a catalog step at the end of the job.) I have used DISP=(NEW,CATLG),VOL=(,RETAIN) -Original Message- From: Lizette Koehler Sent: Friday, February 27, 2009 5:32 AM To: IBM-MAIN@bama.ua.edu Subject: Tape Stealing in z/OS with CBR4000I 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 step's 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. Yet there does not seem to be a solution other than perhaps changing the job to only do one step for stacking datasets on a tape or having an operator issue a manual dismount when this message occurs. Has anyone run into this situation? When you will get the CBR4000I message in a multiple step job trying to pass a tape which is having datasets stacked on it, from one step to another? If so, how do you resolve the CBR4000I messages? -- 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
