hen reviewing reports of storage used on your AS/400, do you ever wonder if the figures for production libraries really ought to be so great? Is it possible that extra file copies reside there, or perhaps some one-time program objects?
You could use command DSPLIB to find out exactly
what's there. However, the objects likely to catch your attention
on the listing are those with unusual object names. You could
save a lot of time by creating a report that prints only the non-standard
My assumption is that when you create objects destined for production libraries, you use a standard name format.
For example, I am going to assume that for Accounts Payable, your standard physical file names include APPVN and APPDT. The first two characters are AP for Accounts Payable, the third character is P for Physical file, and the fourth and fifth characters identify the file (VN for Vendor Number, and DT for Detail).
Let's say that you also use standard names for your
Accounts Payable programs, such as AP123CLP and AP456RPG. The
first two characters are AP for Accounts Payable, the third to
fifth characters are a program number, and characters six to eight
indicate the program type.
If you see file names such as COPY_VN, DT_9605, and APPVN_SAV or program names like @AP789RPG, AP123CLP_X, and FIX_VN, you suspect immediately that they are not legitimate production objects.
Since these non-standard names are the objects most likely to not belong in the production library, it is helpful to create a report that prints only the objects that have non-standard names.
Identify the Standards
If the standards being used are not already documented,
figure out what the pattern is for the various object types that
Create a file of object descriptions (using command
DSPOBJD) for the library or libraries that you want to review.
(Note: In January 1996, I described a method for creating a file
of object descriptions to monitor storage. If you used that method,
simply use the file created by that process, instead of creating
a new one.)
Create a query. Use result fields with substring expressions to break the object name into its components. In the outfile created by DSPOBJD, the field for the object name is ODOBNM. For the physical file example, the result fields needed are:
Result Expression PFX substr(odobnm,1,2) PL substr(odobnm,3,1) FILE substr(odobnm,4,2) ENDF substr(odobnm,6,5)
For the program example, the result fields needed are:
Result Expression PFX substr(odobnm,1,2) PGMNO substr(odobnm,3,3) ATTR substr(odobnm,6,3) ENDP substr(odobnm,9,2)
For substring expressions, the parentheses contain
three items: first, the field to substring; second, the first
character of the field to use; and third, the number of characters
to include in the result field.
Use the select records feature of query to find objects which have non-standard names. For example, for physical files, the select records tests are:
PFX NE 'AP' OR PL NE 'P' OR FILE LT 'AA' OR FILE GT 'ZZ' OR ENDF NE ' '
For programs, the select tests are:
PFX NE 'AP' OR PGMNO LT '001' OR PGMNO GT '999' OR=#008080 OR ATTR NLIST 'CLP''RPG' OR ENDP NE ' '
Because result fields and select records tests were used in the query, your report will include only those objects which have non-standard object names.
Your query can be used to create reports by object
type, by user that created the object, by object size, or by any
other sort method that you find helpful.
Investigate the objects which appear on the report, to determine if they are production objects or not. Some (or many?) objects reported will be those which were renamed or copied by your programmers, who intended to remove them in just a few days, and then forgot.
This same technique can be used for any object type for which you use standard names in your applications. It can also be used in development and test environments, as well as production libraries.
Now, can you persuade your programmers to help you
clean up the objects you found?