I'm afraid the best bet is to work with IBM VTL engineers to manually get rid of them.
- KB ------- Original Message ------- On Monday, April 10th, 2023 at 7:15 AM, Mark Jacobs <00000224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > I'm not able to answer your question but I totally sympathize. There have > been many times where I wanted "systems programmer mode" to be enabled where > the @#$!!**@#$ software would let me do what I asked, regardless of whether > it thought it was smarter than I am and wouldn't do what I asked for. > > Mark Jacobs > > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > ------- Original Message ------- > On Sunday, April 9th, 2023 at 9:37 PM, Tom Longfellow > 000003e29b607131-dmarc-requ...@listserv.ua.edu wrote: > > > > > I have a TS7700 Grid of three cluster members. In the past volumes were > > created for a z/OS system that no longer exists. We have hundreds of tapes > > in scratch (0012) and private (001F) category. So now, the data is taking > > up space in my newest grid member because of COPYRFSH activities. > > > > What I would like to do is totally remove the existence of these volumes > > from the Grid. Every standard method I have found via management GUIs fails > > because these volumes have once left the 'INSERT' status at some time in > > the past. Everything that implies it might work from Z host to 'EJECT' > > these tapes require all the infrastructure of RMM, DEVSUP00 changes, and a > > Tape Volume Catalog (TVC). I do not want to rebuild an entire z/OS LPAR so > > that it will talk the special DEVSUP language to manipulate these tapes. > > Nor do I wish to add hundreds of volumes to my tape management system and > > TVC) just to turn around and delete them again. > > > > I really need a way for this GRID to never mention these tapes in any way > > ever again. One of the prime directives of the TS7700 seems to be 'never > > delete data until you have no other choice'. For example a 'scratch' tape > > is still there even after the hold period expires and is still known after > > storage RECLAIM has happened. Those 'zombie' reclaimed volumes are > > preserved in perpetuity as you migrate from TS7700 to TS7700. I am trying > > to Stop the Madness. The 'Default' of 'We shall delete no data before its > > time' needs to be broken. A full mind wipe for these volumes is in order. > > > > I know this defeats the 'feature' of miraculous unexpected recoveries of > > data that has served its purpose and been honorably discharged but reality > > does have to play a role here. If I say keep it for 8 days, I do not want > > it storing data forever and deleted by its own arcane incomprehensible > > rules. If it is available for miracle unexpected recoveries, there may be > > some security auditors interested what that equipment is up to. > > > > Anybody know a fast and efficient way to accomplish this? > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
