Re: RMM processing under z/OS 1.12

2011-03-24 Thread Richard Pinion
I think I found my problem. I was using the z/OS 1.10 EDGUX100 rather than the 1.12 version. In addition I have removed my IGNORE code out of the exit completely and have started using the OPENRULE statements to perform this processing. Also, the example I showed for the output tape was one f

Re: RMM processing under z/OS 1.12

2011-03-24 Thread Mike Wood
Richard, All releases of rmm would react the same way to this JCL if the volume 050011 is scratch status. When the volume mounted is scratch you can only write to file 1, and also, you cannot specify a volser in your JCL if that volume is scratch. So, in the past, that volume 050011 must have bee

Re: RMM processing under z/OS 1.12

2011-03-21 Thread Pinnacle
"Richard Pinion" wrote in message news:... I recently upgraded from z/OS 1.10 to 1.12. I am receiving the following messages when running tape jobs. This didn't happen on 1.10. I've looked through the RMM 1.12 manuals and the migration documentation. I don't understand why this is happening.

Re: RMM processing under z/OS 1.12

2011-03-21 Thread Greg Shirey
I'm not understanding what is happening that you are questioning. Are you saying that volume 050011 is *not* a scratch tape, and you are wondering why RMM thinks it is? And that something similar is happening to every master tape you try to mod onto? Greg Shirey Ben E. Keith Company -O

RMM processing under z/OS 1.12

2011-03-21 Thread Richard Pinion
I recently upgraded from z/OS 1.10 to 1.12. I am receiving the following messages when running tape jobs. This didn't happen on 1.10. I've looked through the RMM 1.12 manuals and the migration documentation. I don't understand why this is happening. To get around the volume being rejected