Re: DASD housekeeping -- MIDRANGE-L

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