Re: Forcing TMS Tape entry into scratch status
On Fri, 18 Sep 2009 23:56:13 +0530, Prabhath V Gannavarapu wrote: >Hi, Have noticed a few of HSM duplexed tapes becoming orphan. These have a permanent retention to them. So, they are neither being controlled by HSM to DELVOL and get the tape returned to CA-1 control...neither CA-1 is getting the control as it has the EDMID ON to point to HSM and FLAG3 to 20 for EDM. How do we deal with these? A TMSUPDTE for updating the EDMID to HEXZEROS and altering the FLAG3 should fix I suppose. But, could there be any problems. Having tried reading the CDS records yielded me saying no records found. Is this the right method to reclaim these tapes? Prabhath V S Gannavarapu Do you have the ARCTVEXT installed? CA-1's usermod SMPHSM2 provides this functionality. With this exit installed HSM will notify CA-1 to turn the EDM flag OFF when it releases the tape. This will not affect the orpaned tapes you mentioned. For those you need to ensure HSM is done with them prior to running TMSUPDTE. hth, Dave -- 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: Forcing TMS Tape entry into scratch status
Hi, Have noticed a few of HSM duplexed tapes becoming orphan. These have a permanent retention to them. So, they are neither being controlled by HSM to DELVOL and get the tape returned to CA-1 control...neither CA-1 is getting the control as it has the EDMID ON to point to HSM and FLAG3 to 20 for EDM. How do we deal with these? A TMSUPDTE for updating the EDMID to HEXZEROS and altering the FLAG3 should fix I suppose. But, could there be any problems. Having tried reading the CDS records yielded me saying no records found. Is this the right method to reclaim these tapes? Prabhath V S Gannavarapu This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- 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: Forcing TMS Tape entry into scratch status
Dave, Sorry for the confusion, I meant to say that I also did it by changing the expdt of a large number of tapes to today in batch and let TMS maintenance set them to scratch. If the TMS parms are set correctly, it will also uncatalog them at the same time. Kees. "O'Brien, David W. [C] , NIH/CIT" wrote in message news:... > Kees, > > Following your suggestion, I tried to delete one of the problem tapes and got the following: > > 200041UNABLE TO DELETE, MUST BE SCRATCH STATUS > 0 RECORDS MARKED AS DELETED > 1 ERRORS > > Thank You, > Dave O'Brien > NIH Contractor > > From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM [kees.vern...@klm.com] > Sent: Wednesday, September 16, 2009 10:33 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Forcing TMS Tape entry into scratch status > > "O'Brien, David W. [C] , NIH/CIT" wrote in > message > news:... > > We are in the process of eliminating old pools of tapes. > > The application owner and the tech support for the silos uncataloged > the datasets and changed the Expdt to the current date expecting the > nightly TMS functions to flip the scratch bit for each of these tapes. > > > > I thought I could delete the pool but the tapes must be in scratch > status first. > > > > Maybe I'm just forgetting something simple but I don't see a utility > that will force a 'scratch status'. > > > > Any suggestions? > > > > Thank You, > > Dave O'Brien > > That's the way I used to do it too. > > Kees. > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > 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 > > -- > 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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: Forcing TMS Tape entry into scratch status
Hi Linda, Yes, lots of errors on the pointers report. I've taken Mark's advice and opened a ticket with CA. Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Linda Mooney [linda.lst...@comcast.net] Sent: Wednesday, September 16, 2009 1:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status Hi David, It is likely that the inital update(s) happened with NOCHAIN in use, otherwise a scratch operation should have failed for anything other than vol 1. Have you run an invalid pointers report (rpt 29)? It will identify all of the volumes involved. Sometimes it is easier, depending on how many volumes are involved, to rebuild the broken chains and then scratch the vol 1 rapes, which will then take the chains along with them. I have a rpt29 JCL if you want one. If you go ahead with scratching the individual volumes, VOLSEQ for each tape will need to be set to 0001 and the 1STVOL, NEXTVOL, PREVVOL, and OUTCODE (if any) will need to be cleared out. As others have said, that can be done with TMSUPDTE. I see that there is no EDMID= present for the tape posted. That does simplify things. Anytime there is an EDM involved, it has to get the updates too. Scratch operations involving EDM tapes should be initiated with the EDM. Best Regards, Linda Mooney - Original Message - From: "David W. O'Brien (NIH/CIT) [C]" To: IBM-MAIN@bama.ua.edu Sent: Wednesday, September 16, 2009 8:04:32 AM GMT -08:00 US/Canada Pacific Subject: Re: Forcing TMS Tape entry into scratch status John and Jay, Thanks for responding, no EDM is not involved nor do we use 'out of area' codes. Our off-site tapes are written to a remote silo so there is no need for tape movement. Volseq is not equal to 001 and the dataset inquiry follows the tape inquiry. Here is the Inquiry display of one of the tapes: VOLSER = 200041 ACTVOL=SMSMC= BLANKS DSN= NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 DSN17= P.WEEKS3.G0048V00 EXPDT = 2009/256 ACCT= HEXZEROS FLAG1 = E0 FLAG2 = 40 FLAG3 = 00 BATCHID= 59 = TMSIONLN FLAG4 = 00 FLAG5 = 00 FLAG6 = 00 HOOKID = FE = EDMID =WMC= 0WWID = - - CDATE = 2006/182 CJOB = NEUMMBKP CTIME = 0638CPGM = IKJEFT1B LDATE = 2006/182 LJOB = NEUMMBKP LTIME = 0724LPGM = IKJEFT1B CSTEP = MICS CDDNAME= BKUPCKPT CUNIT = 0351LUNIT = 0351 OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 BTHDATE= 2004/154 VENDOR = BLANKS COUNT = 00011 TWERRC = 0 DATECLN= ZEROS USECLN = 0CLNCNT = 000 TRERRI = 0 VOLSEQ = 0004 ROBTY = ROBID = 000 TWERRI = 0 1STVOL =NEXTVOL= PREVVOL= PRERRC = 0 NUMDSNB= 1STDSNB= 000 LSTDSNB= 000 PWERRC = 0 LABEL = SL DEN= 38KC TRTCH = 36X2PRERRI = 0 RECFM = FB LRECL = 000200 BLKSIZE= 000200 PWERRI = 0 AUDATE = 2009/256 AUTIME = 2201 BLKCNT = 00 AUCODE = 00 AUFLAG1= 00 CPUID = 4090USERID = $WGL VOLPERC= 097FILPERC= 093 COMPRES= 000 CTLGCNT= 000 I = Inquiry U = Update 09.259 (Note: Only the first 43 bytes of the dataset name is displayed.) VOLUME FILE EXPIRE CREATE CMD DATA SET NAMESERIAL SEQ DATE DATE NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200041 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200305 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300274 0001 *SCRATCH* 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300491 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300573 0001 2009/256 2006/182 300274 was the first volume, now how to scratch the others? Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of John Kington [john.king...@convergys.com] Sent: Wednesday, September 16, 2009 10:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status David, >We are in the process of eliminating old pools of tapes. >The application owner and the tech support for the silos uncataloged the >>datasets and changed the Expdt to the current date expecting the nightly TMS >>functions to flip the scratch bit for each of these tapes. > >I thought I could delete the pool but the tapes must be in scratch status >first. > >Maybe I'm just forgetting something simple but I don't see a utility that will >>force a
Re: Forcing TMS Tape entry into scratch status
Hi David, It is likely that the inital update(s) happened with NOCHAIN in use, otherwise a scratch operation should have failed for anything other than vol 1. Have you run an invalid pointers report (rpt 29)? It will identify all of the volumes involved. Sometimes it is easier, depending on how many volumes are involved, to rebuild the broken chains and then scratch the vol 1 rapes, which will then take the chains along with them. I have a rpt29 JCL if you want one. If you go ahead with scratching the individual volumes, VOLSEQ for each tape will need to be set to 0001 and the 1STVOL, NEXTVOL, PREVVOL, and OUTCODE (if any) will need to be cleared out. As others have said, that can be done with TMSUPDTE. I see that there is no EDMID= present for the tape posted. That does simplify things. Anytime there is an EDM involved, it has to get the updates too. Scratch operations involving EDM tapes should be initiated with the EDM. Best Regards, Linda Mooney - Original Message - From: "David W. O'Brien (NIH/CIT) [C]" To: IBM-MAIN@bama.ua.edu Sent: Wednesday, September 16, 2009 8:04:32 AM GMT -08:00 US/Canada Pacific Subject: Re: Forcing TMS Tape entry into scratch status John and Jay, Thanks for responding, no EDM is not involved nor do we use 'out of area' codes. Our off-site tapes are written to a remote silo so there is no need for tape movement. Volseq is not equal to 001 and the dataset inquiry follows the tape inquiry. Here is the Inquiry display of one of the tapes: VOLSER = 200041 ACTVOL= SMSMC= BLANKS DSN = NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 DSN17= P.WEEKS3.G0048V00 EXPDT = 2009/256 ACCT= HEXZEROS FLAG1 = E0 FLAG2 = 40 FLAG3 = 00 BATCHID= 59 = TMSIONLN FLAG4 = 00 FLAG5 = 00 FLAG6 = 00 HOOKID = FE = EDMID = WMC = 0 WWID = - - CDATE = 2006/182 CJOB = NEUMMBKP CTIME = 0638 CPGM = IKJEFT1B LDATE = 2006/182 LJOB = NEUMMBKP LTIME = 0724 LPGM = IKJEFT1B CSTEP = MICS CDDNAME= BKUPCKPT CUNIT = 0351 LUNIT = 0351 OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 BTHDATE= 2004/154 VENDOR = BLANKS COUNT = 00011 TWERRC = 0 DATECLN= ZEROS USECLN = 0 CLNCNT = 000 TRERRI = 0 VOLSEQ = 0004 ROBTY = ROBID = 000 TWERRI = 0 1STVOL = NEXTVOL= PREVVOL= PRERRC = 0 NUMDSNB= 1STDSNB= 000 LSTDSNB= 000 PWERRC = 0 LABEL = SL DEN = 38KC TRTCH = 36X2 PRERRI = 0 RECFM = FB LRECL = 000200 BLKSIZE= 000200 PWERRI = 0 AUDATE = 2009/256 AUTIME = 2201 BLKCNT = 00 AUCODE = 00 AUFLAG1= 00 CPUID = 4090 USERID = $WGL VOLPERC= 097 FILPERC= 093 COMPRES= 000 CTLGCNT= 000 I = Inquiry U = Update 09.259 (Note: Only the first 43 bytes of the dataset name is displayed.) VOLUME FILE EXPIRE CREATE CMD DATA SET NAME SERIAL SEQ DATE DATE NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 200041 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 200305 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 300274 0001 *SCRATCH* 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 300491 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 300573 0001 2009/256 2006/182 300274 was the first volume, now how to scratch the others? Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of John Kington [john.king...@convergys.com] Sent: Wednesday, September 16, 2009 10:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status David, >We are in the process of eliminating old pools of tapes. >The application owner and the tech support for the silos uncataloged the >>datasets and changed the Expdt to the current date expecting the nightly TMS >>functions to flip the scratch bit for each of these tapes. > >I thought I could delete the pool but the tapes must be in scratch status >first. > >Maybe I'm just forgetting something simple but I don't see a utility that will >>force a 'scratch status'. > >Any suggestions?
Re: Forcing TMS Tape entry into scratch status
Thanks John, guess I better get to work as I've got thousands of these to do. Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of John Kington [john.king...@convergys.com] Sent: Wednesday, September 16, 2009 11:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status David, >From the inquiry, it looks like all of the chaining is missing or has been >removed. The only option that I can suggest is to turn on the scratch bit with >tmsupdate. VOL 200041 VER DSN=NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 OI FLAG1=04 Regards, John 513-723-7527 john.king...@convergys.com -- 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 -- 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: Forcing TMS Tape entry into scratch status
On Wed, 16 Sep 2009 11:04:32 -0400, O'Brien, David W. (NIH/CIT) [C] wrote: >John and Jay, > > Thanks for responding, no EDM is not involved nor do we use 'out of area' codes. Our off-site tapes are written to a remote silo so there is no need for tape movement. > >Volseq is not equal to 001 and the dataset inquiry follows the tape inquiry. > >Here is the Inquiry display of one of the tapes: >VOLSER = 200041 ACTVOL=SMSMC= BLANKS >DSN= NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 DSN17= P.WEEKS3.G0048V00 >EXPDT = 2009/256 ACCT= HEXZEROS >FLAG1 = E0 FLAG2 = 40 FLAG3 = 00 BATCHID= 59 = TMSIONLN >FLAG4 = 00 FLAG5 = 00 FLAG6 = 00 HOOKID = FE = >EDMID =WMC= 0WWID = - - >CDATE = 2006/182 CJOB = NEUMMBKP CTIME = 0638CPGM = IKJEFT1B >LDATE = 2006/182 LJOB = NEUMMBKP LTIME = 0724LPGM = IKJEFT1B >CSTEP = MICS CDDNAME= BKUPCKPT CUNIT = 0351LUNIT = 0351 >OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 >BTHDATE= 2004/154 VENDOR = BLANKS COUNT = 00011 TWERRC = 0 >DATECLN= ZEROS USECLN = 0CLNCNT = 000 TRERRI = 0 >VOLSEQ = 0004 ROBTY = ROBID = 000 TWERRI = 0 >1STVOL =NEXTVOL= PREVVOL= PRERRC = 0 >NUMDSNB= 1STDSNB= 000 LSTDSNB= 000 PWERRC = 0 >LABEL = SL DEN= 38KC TRTCH = 36X2PRERRI = 0 >RECFM = FB LRECL = 000200 BLKSIZE= 000200 PWERRI = 0 >AUDATE = 2009/256 AUTIME = 2201 BLKCNT = 00 >AUCODE = 00 AUFLAG1= 00 CPUID = 4090USERID = $WGL >VOLPERC= 097FILPERC= 093 COMPRES= 000 CTLGCNT= 000 > >I = Inquiry U = Update 09.259 >(Note: Only the first 43 bytes of the dataset name is displayed.) > > VOLUME FILE EXPIRE CREATE >CMD DATA SET NAMESERIAL SEQ DATE DATE > NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200041 0001 2009/256 2006/182 > NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200305 0001 2009/256 2006/182 > NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300274 0001 *SCRATCH* 2006/182 > NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300491 0001 2009/256 2006/182 > NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300573 0001 2009/256 2006/182 > >300274 was the first volume, now how to scratch the others? I'm not sure why things are out of sync since I don't know how you attempted to scratch the tapes to begin with. Maybe some pointers were broken or you forced a scratch of some volumes in a multivolume set without the first volume (which would break chains) etc. FLAG1 x'04' is scratch, and that bit is not on - so it's not scratch. You could turn it on with TMSUPDTE: VOL 200041,NODSN OI FLAG1=40 You should contact CA for further advise. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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: Forcing TMS Tape entry into scratch status
David, >From the inquiry, it looks like all of the chaining is missing or has been >removed. The only option that I can suggest is to turn on the scratch bit with >tmsupdate. VOL 200041 VER DSN=NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 OI FLAG1=04 Regards, John 513-723-7527 john.king...@convergys.com -- 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: Forcing TMS Tape entry into scratch status
John and Jay, Thanks for responding, no EDM is not involved nor do we use 'out of area' codes. Our off-site tapes are written to a remote silo so there is no need for tape movement. Volseq is not equal to 001 and the dataset inquiry follows the tape inquiry. Here is the Inquiry display of one of the tapes: VOLSER = 200041 ACTVOL=SMSMC= BLANKS DSN= NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00 DSN17= P.WEEKS3.G0048V00 EXPDT = 2009/256 ACCT= HEXZEROS FLAG1 = E0 FLAG2 = 40 FLAG3 = 00 BATCHID= 59 = TMSIONLN FLAG4 = 00 FLAG5 = 00 FLAG6 = 00 HOOKID = FE = EDMID =WMC= 0WWID = - - CDATE = 2006/182 CJOB = NEUMMBKP CTIME = 0638CPGM = IKJEFT1B LDATE = 2006/182 LJOB = NEUMMBKP LTIME = 0724LPGM = IKJEFT1B CSTEP = MICS CDDNAME= BKUPCKPT CUNIT = 0351LUNIT = 0351 OUTDATE= ZEROS OUTCODE= SLOT = 000 TRERRC = 0 BTHDATE= 2004/154 VENDOR = BLANKS COUNT = 00011 TWERRC = 0 DATECLN= ZEROS USECLN = 0CLNCNT = 000 TRERRI = 0 VOLSEQ = 0004 ROBTY = ROBID = 000 TWERRI = 0 1STVOL =NEXTVOL= PREVVOL= PRERRC = 0 NUMDSNB= 1STDSNB= 000 LSTDSNB= 000 PWERRC = 0 LABEL = SL DEN= 38KC TRTCH = 36X2PRERRI = 0 RECFM = FB LRECL = 000200 BLKSIZE= 000200 PWERRI = 0 AUDATE = 2009/256 AUTIME = 2201 BLKCNT = 00 AUCODE = 00 AUFLAG1= 00 CPUID = 4090USERID = $WGL VOLPERC= 097FILPERC= 093 COMPRES= 000 CTLGCNT= 000 I = Inquiry U = Update 09.259 (Note: Only the first 43 bytes of the dataset name is displayed.) VOLUME FILE EXPIRE CREATE CMD DATA SET NAMESERIAL SEQ DATE DATE NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200041 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00200305 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300274 0001 *SCRATCH* 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300491 0001 2009/256 2006/182 NIH.NEUMICS.PPT.MBACKUP.CHECKPT.G0059V00300573 0001 2009/256 2006/182 300274 was the first volume, now how to scratch the others? Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of John Kington [john.king...@convergys.com] Sent: Wednesday, September 16, 2009 10:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status David, >We are in the process of eliminating old pools of tapes. >The application owner and the tech support for the silos uncataloged the >>datasets and changed the Expdt to the current date expecting the nightly TMS >>functions to flip the scratch bit for each of these tapes. > >I thought I could delete the pool but the tapes must be in scratch status >first. > >Maybe I'm just forgetting something simple but I don't see a utility that will >>force a 'scratch status'. > >Any suggestions? I would check to see if there is an out of area code or the external data manager flag is set. Regards, John -- 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 -- 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: Forcing TMS Tape entry into scratch status
Kees, Following your suggestion, I tried to delete one of the problem tapes and got the following: 200041UNABLE TO DELETE, MUST BE SCRATCH STATUS 0 RECORDS MARKED AS DELETED 1 ERRORS Thank You, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM [kees.vern...@klm.com] Sent: Wednesday, September 16, 2009 10:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Forcing TMS Tape entry into scratch status "O'Brien, David W. [C] , NIH/CIT" wrote in message news:... > We are in the process of eliminating old pools of tapes. > The application owner and the tech support for the silos uncataloged the datasets and changed the Expdt to the current date expecting the nightly TMS functions to flip the scratch bit for each of these tapes. > > I thought I could delete the pool but the tapes must be in scratch status first. > > Maybe I'm just forgetting something simple but I don't see a utility that will force a 'scratch status'. > > Any suggestions? > > Thank You, > Dave O'Brien That's the way I used to do it too. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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 -- 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: Forcing TMS Tape entry into scratch status
David, >We are in the process of eliminating old pools of tapes. >The application owner and the tech support for the silos uncataloged the >>datasets and changed the Expdt to the current date expecting the nightly TMS >>functions to flip the scratch bit for each of these tapes. > >I thought I could delete the pool but the tapes must be in scratch status >first. > >Maybe I'm just forgetting something simple but I don't see a utility that will >>force a 'scratch status'. > >Any suggestions? I would check to see if there is an out of area code or the external data manager flag is set. Regards, John -- 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: Forcing TMS Tape entry into scratch status
"O'Brien, David W. [C] , NIH/CIT" wrote in message news:... > We are in the process of eliminating old pools of tapes. > The application owner and the tech support for the silos uncataloged the datasets and changed the Expdt to the current date expecting the nightly TMS functions to flip the scratch bit for each of these tapes. > > I thought I could delete the pool but the tapes must be in scratch status first. > > Maybe I'm just forgetting something simple but I don't see a utility that will force a 'scratch status'. > > Any suggestions? > > Thank You, > Dave O'Brien That's the way I used to do it too. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Forcing TMS Tape entry into scratch status
We are in the process of eliminating old pools of tapes. The application owner and the tech support for the silos uncataloged the datasets and changed the Expdt to the current date expecting the nightly TMS functions to flip the scratch bit for each of these tapes. I thought I could delete the pool but the tapes must be in scratch status first. Maybe I'm just forgetting something simple but I don't see a utility that will force a 'scratch status'. Any suggestions? Thank You, Dave O'Brien NIH Contractor -- 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
