hen trying to analyze whether or not objects in a specific library (or the entire library) can be removed, a typical approach is to use the DSPLIB command and send the output to a printer. Invariably, more information is needed on many, if not all, of the objects, so WRKOBJ is used and pencilled notes are made on the DSPLIB report.
Instead, you can create a report that prints every object in the library, and already has the most useful information from WRKOBJ on the same report.
Instead of using the DSPLIB command, start by creating a file of object descriptions for every object in the library.
For example, to find out what is in library GLTEST:
DSPOBJD OBJ(GLTEST/*ALL) + OBJTYPE(*ALL) + OUTPUT(*OUTFILE) + OUTFILE(mylib/myfile) + MBROPT(*REPLACE)
When using DSPOBJD to create the file of object descriptions, ensure that you have sufficient authority to obtain information on all of the objects in the library being reported. The AS/400 will give you object descriptions only for objects to which you are authorized.
It is unlikely that you will be able to have access to the QSECOFR password every time you want to review the objects in a library.
Instead, create a command and command-processing program which adopt QSECOFR authority. Create a new command and command-processing program called, for instance DSPALLOBJ. Have the security officer compile these new objects with USRPRF(*OWNER) and make the owner QSECOFR.
When you use the command DSPALLOBJ, you will get information reported on all objects in the requested library, but will not have permanent access to them.
The outfile from DSPOBJD has a field ODOBSZ, which used to be the object size, but it is defined as a 10.0 field, so it does not correctly report objects that are 10 gigabytes or more. You can create a result field in Query/400 for the correct object size. To calculate object size, multiply field ODBPUN (bytes per unit) times field ODSIZU (size of unit).
Use query to create a report of the objects in the library. The following fields are always included on my own Library Detail Reports:
I like to be able to choose the order in which the object descriptions are printed. My most frequently used sorting orders are:
Sort the records by Object Type; Object Attribute; and Object Name. With this order, the objects can be grouped and summarized by object type and/or attribute. This report is the one I use most often when asking programmers or users to review objects or libraries for possible clean up.
Sort the records by Object Size (as calculated) in descending order. If you are looking for disk space, this is a handy order, as you’ll find the best information on the first page of the report.
Sort by User; Object Type; Object Attribute. This report is often useful when several users or teams share a library, and you want to split up the report to give to different people.
If you are the person responsible for monitoring disk storage, you will find this a very useful report. You can give it to users and programmers and ask them to review the objects in the library. Most of the time, all of the information needed to make a decision on keeping or deleting an object is all on one report.
Now, all that remains to be done is to persuade someone to make the decision to delete!