Gil, I can answer the question as to why somebody would want to read a scratch tape. The tape management system scratched a master tape due to configuration rules. Later, before the tape was overwritten, it was realized that the data on the tape was still valid and needed to be kept. One way of doing this is to IEBGENER the data to a new location, either tape or disk.
BTDT, but using TLMS which at the site I was working at allows a job to read scratch tapes. TLMS would go through and verify that the DSN specified in the JCL matched that on the tape label. Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Wednesday, April 11, 2007 5:05 PM To: [email protected] Subject: Re: IEC145I 413-08 (and implications for SMP/E GIMDTS) In a recent note, willie bunter said: > Date: Wed, 11 Apr 2007 14:30:01 -0700 > > We are having a difference of opinion with the following issue. A gener job is failing on an IEC145I 413-08. My interpretation is that the job failed because of an I/O error. The other opinion is that because the tape is scratch (in RMM) and it does not permit the processing of a scratch tape. Can we both be right? > > EDG4025I VOLUME J01932 REJECTED. READING OF SCRATCH VOLUMES OR > VOLUMES OBTAINED WITH GETVOLUME IS NOT PERMITTED > I would readily call this message by the term (here deprecated) "self-explanatory". But M&C does say for EDG4025I: Explanation: The specified volume serial number is either a scratch volume or a scratch volume obtained using the RMM GETVOLUME subcommand. The volume cannot be used for input processing unless you write the first file. .. and goes on to say that the EDG4006E is collateral. This seems to support opinion 2. > EDG4006E VOLUME J01932 ON 4611 REJECTED FOR USE BY O00130J, STEP01, > SYSUT1, OPEN REQUEST FAILED BY DFSMSrmm IEC145I > 413-08,IFG0194K,O00130J,STEP01,SYSUT1,4611,,AMR4.PSEL$08.PFG98.Y2K.DRT > ES > I can fairly wonder why one attempts to process a scratch tape as gener SYSUT1. But some time ago, I coded: //STEP EXEC PGM=GIMDTS //SYSUT2 DD PATHOPTS=OWRONLY, ... .. and the OPEN failed with a permission violation. IBM explained this as a result of GIMDTS's attempting first to open SYSUT2 for input to verify that DSORG is not PO and that it will not be overwriting a PDS directory. WAD. So, I wonder whether with your RMM setup, GIMDTS would similarly fail with SYSUT2 assigned to a scratch tape. Or with a GDG(+1). -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
