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
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
"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.
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
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
5 matches
Mail list logo