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