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&[email protected] ------- Original Message ------- On Sunday, April 9th, 2023 at 9:37 PM, Tom Longfellow <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
