Re: DASD housekeeping

[PaulMmn <PaulMmn@xxxxxxxxxxxxx>]

Jerome implied that his disk was full and needed to be burped-- he 
wanted to know the best way to do it.

The motto where I work is, "The only good disk drive is a full disk 
drive."  And all of our programmers do their best to make it so.

From time to spare time, I browse the lists of libraries, looking for 
things I recognize as old and unused, and for things I do NOT 
recognize, and try to track down someone who knows what it is and why 
we have it.  It's not pretty, and there's no easy way to automate 
this process.

Yes, you can do 'date of last use' reporting, but a human still has to decide.

Once we've identified the potential unused library, we rename it by 
putting a "Z" in front of the name (ie FRED becomes ZFRED).  Except 
for one package we purchased, NO ONE uses "Z" as the first character 
of a library name.  But we were using Z to indicate a potential 
cleanup candidate first!   (:

Then we let the Z libraries sit until we've run a month end cycle. 
The theory is that if nothing needs that library through a month end, 
it's probably safe to remove it from the system.  If a job does 
scream that it's missing a library, it's a simple task to name the 
library back and give the job a retry.

After that month ending (or any time, at your convenience), make 2 
backups of the Z libraries, and delete them from the system.  2 
copies, because 1 may be bad.

I've started backing up the Z libraries whenever I get a bunch of 
them.  I then change the description to "Already saved on tape 
#23958."  This lets me know that the backup is already done, and when 
I need the space NOW, I just have to delete the library.

We actually carry this Z naming to the object and source level, 
although it's not a formal process.

One reason disk space tends to grow is that programmers can create 
new libraries and copy data to those libraries without asking.  Lock 
down the CRTLIB command, so only the system administrator can create 
a new library.   Make sure all programmers have their own libraries, 
and tell them to keep their stuff in it.

Now you can browse the programmer libraries and see who's been hoarding stuff.

If your test and production environments have become one and the 
same, you need to enforce some controls over who can do what to 
production libraries.  The first step is to get someone in management 
to decree that This Is The Way It Will Be.  It usually takes just one 
major screwup for managment to agree that this is a Good Thing.

Make the programmers *PGMR users.  No special authority.  *USERs 
shouldn't need special authority either.

Lock down the production libraries.  The programmers only need -read- 
rights to production data, -use- rights to production objects, and 
-read- rights to production source code.  Do it; I don't care how 
loudly the programmers protest that they can't do their jobs and that 
it'll slow down development.  Your users will thank you!

Make copies of the production libraries for the programmers to play in.

Use a change management system.  If you can't afford to buy one, you 
can write a bare bones one yourself.  We used to use our own command. 
It was used for about 5 years (and we still use pieces of it now and 
then).

Our system has (had) 2 main components:

--ARCHIVE command-- this works like the MOVOBJ command, but if the 
object already exists in the destination library, it is renamed with 
$$$ padding the name to 10 characters.  If a version with $$$ exists, 
it is renamed with ###, if ### --> @@@.  If a version with @@@ 
exists, it is deleted.  This gives the current version, plus 3 prior 
versions.  Yes, it does keep all of the old stuff in the destination 
library, but it's easy enough to spot.  If the name has 10 
characters, we replace the last character with the $,#, or @.  Using 
these characters, a library list shows them in order by age (Plain 
newer than $$$ newer than ### newer than @@@).  This command does a 
lot of error checking needed to make sure the from object exists, and 
to make sure this command is solid.  I still use this command instead 
of MOVOBJ.

--ARCHIVESRC command-- does the same thing, but for source members.

Our Change Management Command then wrapped around these 2 commands 
(and a few others), did some editing and existence checking, and 
moved the source and object from wherever the developer put them and 
placed them in the production library.

Only the CMC had the authority to place something in a production 
library-- and it was restricted to the technical support group (who 
weren't application programmers).

By cleaning up old libraries, and controlling who can create 
libraries, and who can touch production data, you can start to clean 
up your system.

--Paul E Musselman
Paulmmn@xxxxxxxxxxxxxxxxxxxx