Re: RMM: Best, safest way to mass delete tape volumes

2013-05-14 Thread Jeffery Swagger
Thank you Mike and everybody else who has responded. Many things to think about 
here.

-- 
Jeff


On Thu, 9 May 2013 02:23:31 -0500, Mike Wood mww...@ntlworld.com wrote:

Jeff,  leaving all the concerns alone at the moment . Deleting volumes 
should be straightforward. You do need to consider the scratch volumes and 
non-scratch volumes separately.
Scratch volumes should already have been through release processing and any 
cataloged data sets uncataloged. RACF profiles deleted (if any). To delete 
scratch volumes - use the RMM DV volser REMOVE command.
Non-scratch volumes you still have this consideration.  You can cause the 
volumes to go through release processing and allow rmm to uncatalog and 
cleanup RACF. Use the RMM CV volser RELEASE command.  Using the RMM DV volser 
FORCE may not do these tasks for you.
You also have some possible cleanup of the VRSes that are causing these 
non-scratch volumes still to be retained even though they no longer exist.

You can use the SEARCHVOLUME subcommand with CLIST to help build the commands 
needed. It is very powerful, can be run in TSO or batch, or even with the help 
of the dialog.  Also in the dialog, within search results list, you can use 
the SELECT primary command to set the line commands for selected entries in 
the list, then press ENTER to process them.

When you are making changes to volumes and other things defined to rmm, it 
normally creates journal records, and processing also should be creating PDA 
trace records, Either journal or trace data sets can become full when making 
mass changes - as others have mentioned.  In a well-run environment there 
should already be automation to take care of these things.

Deleting volumes should not usually cause space problems in the CDS. Rather it 
should free up space that can be reused. However, depending on how old the 
volumes are, and when the records were last updated, causing a change to a 
record may cause the record to be stored back larger than before .  Again, 
usually, this extra space can be accommodated by VSAM without needing to split 
CIs/CAs.

Another way to delete volumes, which was added more recently to rmm, is to use 
the REPLACE release action. Probably best for non-scratch volumes, use RMM CV 
volser RELEASE(REPLACE) command then release the volume. Once pending release 
you can use RMM DV volser REPLACE to delete them without going through return 
to scratch process.

Mike Wood


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RMM: Best, safest way to mass delete tape volumes

2013-05-09 Thread Mike Wood
Jeff,  leaving all the concerns alone at the moment . Deleting volumes 
should be straightforward. You do need to consider the scratch volumes and 
non-scratch volumes separately.
Scratch volumes should already have been through release processing and any 
cataloged data sets uncataloged. RACF profiles deleted (if any). To delete 
scratch volumes - use the RMM DV volser REMOVE command.
Non-scratch volumes you still have this consideration.  You can cause the 
volumes to go through release processing and allow rmm to uncatalog and cleanup 
RACF. Use the RMM CV volser RELEASE command.  Using the RMM DV volser FORCE may 
not do these tasks for you.
You also have some possible cleanup of the VRSes that are causing these 
non-scratch volumes still to be retained even though they no longer exist.

You can use the SEARCHVOLUME subcommand with CLIST to help build the commands 
needed. It is very powerful, can be run in TSO or batch, or even with the help 
of the dialog.  Also in the dialog, within search results list, you can use the 
SELECT primary command to set the line commands for selected entries in the 
list, then press ENTER to process them.

When you are making changes to volumes and other things defined to rmm, it 
normally creates journal records, and processing also should be creating PDA 
trace records, Either journal or trace data sets can become full when making 
mass changes - as others have mentioned.  In a well-run environment there 
should already be automation to take care of these things.

Deleting volumes should not usually cause space problems in the CDS. Rather it 
should free up space that can be reused. However, depending on how old the 
volumes are, and when the records were last updated, causing a change to a 
record may cause the record to be stored back larger than before .  Again, 
usually, this extra space can be accommodated by VSAM without needing to split 
CIs/CAs.

Another way to delete volumes, which was added more recently to rmm, is to use 
the REPLACE release action. Probably best for non-scratch volumes, use RMM CV 
volser RELEASE(REPLACE) command then release the volume. Once pending release 
you can use RMM DV volser REPLACE to delete them without going through return 
to scratch process.

Mike Wood

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RMM: Best, safest way to mass delete tape volumes

2013-05-08 Thread R.S.

W dniu 2013-05-08 03:52, Jeffery Swagger pisze:

A few months ago all of our 3480/3490 tapes were destroyed. Something
like over 30,000. Not to mention the REEL tapes that are still defined
but non-existent.

I would like to remove these from the RMM database.

Something is telling me in the back of my mind Don't try do do it all
at once. I have nightmares of journals filling up, CDS corruption, etc,
and other Bad Things, all of which I'd rather avoid.

My environment:
z/OS 1.13 on z10, current maintenance.
3 LPAR resource sharing SYSPLEX.

I have been told that the only valid tape volumes are 05*. Anything else
is obsolete and can be deleted. Oh, and these are all non-SMS and are
actually STK/Oracle 94somethingorother residing in a STK/Oracle Silo. If
that makes a difference.

So, what is a good way to approach this?
Any suggestions welcome, and thanks in advance,


1. Backup. CDS and other important datasets can be backed up before the 
action.
2. Restore. Yes, you should be sure that backup is usable, restore is 
the best way to prove it.

3. Test environment. Yes, tests should be performed on non-prod environment.
4. Now you can start the job. ;-)
If you really afraid of mass delete then consider usage of TSO RMM 
commands (with CLIST option) - you can easily get subsets of your tape set.


BTW: RMM is only directory. What do you plan to do with real data on 
real tape carts?
Option 1. Quick and easy. Destroy the content using degausser. But the 
carts will become unusable.
Option 2. Slow and harder. Use data erase facilities of the drives. It 
will take a lot of time (many minutes per cart). But the tapes will be 
still usable.
Option 3. The quickest and the easiest, but somehow not recommended. Do 
nothing. Who would be interested your data? Who has such drives? ;-)))



--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RMM: Best, safest way to mass delete tape volumes

2013-05-08 Thread David Devine
Jeff hello,
firstly just to clarify the situation with the tapes as the first part of your 
mail states the tapes were destroyed, but the 2nd part implies they are still 
extant in the silo's

If they still exist  if you still have paths to the drives (not removed from 
HCD) you may want to data wipe/erase the volumes prior to removal and 
subsequent destruction.
RMM has this facility, refer to running Edginers ERASE in the implementation  
customization guide chapter 18  also the Changevolume command in Managing and 
using removable media. 

This would be a due diligence exercise so you can prove to 
management/audit/compliance that you have taken reasonable precautions about 
data security before the tapes leave site.
Also known as C.Y.A 

*** Do it all under your sites change management procedures  

That aside, yes you are quite correct that you will get issues with journal 
filling, master file filling up (fragmentation) if you just steam on in, so 
some basic checks are in order.

(a) check your current rmm housekeeping jobs and make sure its actually working 
properly and that you are also backing up the master file and journal at least 
on a daily basis. (the edghskp backup will also null the journal when backup is 
succesfull, edgbkup will only backup) How many versions are kept?   

(b) do a listcat on your master file (usually) rmm.master and look at the high 
used rba and also volume check under tso 3.4 (or similar) Is it in extents? how 
many? is there plenty of freespace on the volume to do multiple extends? You 
may want to reorg or resize the masterfile before you start.
It's a vsam ksds so beware the basic 4gb limitation; redefine as an extended 
dataset if needed.
Reorg  resizing are all covered in the manual.
 
(c) same with RMM.Journal how big is it? do you want to resize?
 
(d) check the rmm startup parms, the warning for journal full should be there; 
80% is usual. You may have automation to watch for this and submit a job to 
backup master files and null the journal 

As to the doing, once you are happy with a,b,c,d above, i'd suggest batches of 
500 to start, you canalways ramp up when you are comfortable with it. 

Under your change management protocols, schedule a large window on your plex 
when its at a quiet point tapewise, as if it all goes horribly wrong, ALL your 
tape processing is stuffed till you get it sorted out. 

An approach would be:-
 
(1) ad hoc job to backup control dataset and journal and null the journal.  
(2) submit a batch job to run the tso command 
rmm deletevolume x force  
I dont believe you can do ranges, so its a command for each individual volume.
(3) when 2 is succsessful  (try display to volumes via tso rmm interface, 
should be gone)  
rmm deleterack x  you can put a count field here but may be 
prefferable/safer to do it for each volume.
(4) keep an eye on the master file  journal after each batch and run 
additional ad hoc backup (and journal null) as needed or every 10,000 or so and 
definitely at the end.

N.B as you will be doing multiple additional backups, make sure you don't 
overwrite them with subsequent runs, so have a 2nd step to copy to gdg's with a 
large limit! 

When you are all done, you may well want to reorg or resize the master file to 
get it nice  tidy again.

regards

Dave

P.S all opinions are my own and offerred on a no liability basis.   
 
 



***


 A few months ago all of our 3480/3490 tapes were destroyed. Something 

like over 30,000. Not to mention the REEL tapes that are still defined 
but non-existent.

I would like to remove these from the RMM database.

Something is telling me in the back of my mind Don't try do do it all 
at once. I have nightmares of journals filling up, CDS corruption, etc, 
and other Bad Things, all of which I'd rather avoid.

My environment:
z/OS 1.13 on z10, current maintenance.
3 LPAR resource sharing SYSPLEX.

I have been told that the only valid tape volumes are 05*. Anything else 
is obsolete and can be deleted. Oh, and these are all non-SMS and are 
actually STK/Oracle 94somethingorother residing in a STK/Oracle Silo. If 
that makes a difference.

So, what is a good way to approach this?
Any suggestions welcome, and thanks in advance,
Jeff



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


RMM: Best, safest way to mass delete tape volumes

2013-05-07 Thread Jeffery Swagger
A few months ago all of our 3480/3490 tapes were destroyed. Something 
like over 30,000. Not to mention the REEL tapes that are still defined 
but non-existent.


I would like to remove these from the RMM database.

Something is telling me in the back of my mind Don't try do do it all 
at once. I have nightmares of journals filling up, CDS corruption, etc, 
and other Bad Things, all of which I'd rather avoid.


My environment:
z/OS 1.13 on z10, current maintenance.
3 LPAR resource sharing SYSPLEX.

I have been told that the only valid tape volumes are 05*. Anything else 
is obsolete and can be deleted. Oh, and these are all non-SMS and are 
actually STK/Oracle 94somethingorother residing in a STK/Oracle Silo. If 
that makes a difference.


So, what is a good way to approach this?
Any suggestions welcome, and thanks in advance,
Jeff

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN