I agree. If you have the option of going to the source, that would probably be 
the safest approach.
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Pommier, Rex <[email protected]>
Sent: Monday, April 10, 2023 4:48 PM
To: [email protected]
Subject: Re: TS7700 abandoned volumes questions

Enzo,

Knowing nothing about the internal workings of the TS77xx boxes I should 
probably keep my mouth shut but I don't think this is a good idea.  Where does 
the TS keep metadata on the virtual volumes?  Is there a db2 or other database 
holding pointers to the virtual volumes?  Will internal links between the 
virtual libraries and the physical files (that now don't exist) be broken and 
cause the entire cluster to drop with internal corruption errors?

I would think the safest approach would be to go to the source (i.e. IBM) and 
get their approach for cleaning this up.

My $.01.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
Enzo D'Amato
Sent: Monday, April 10, 2023 3:04 PM
To: [email protected]
Subject: [EXTERNAL] Re: TS7700 abandoned volumes questions

I don't think this is the "IBM-approved" way of doing things, but the ts7700s 
use standard FC drive shelves. Have you tried breaking the cluster links, 
powering down the controller, and then manually mounting the FC shelves on a 
generic Linux box? If you can do that, you should be able to search them for 
the actual emulated tape files and erase them. If this works on one node, you 
can bring the other two down and purge them before bringing the entire grid 
back up, and since the virtual tapes are not in memory on any of the nodes, you 
should be good to go.

-Enzo Damato
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Tom 
Longfellow <[email protected]>
Sent: Sunday, April 9, 2023 9:37 PM
To: [email protected]
Subject: TS7700 abandoned volumes questions

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

----------------------------------------------------------------------
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

----------------------------------------------------------------------
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

Reply via email to