uplicate objects are objects of the same type, with the same object name, which are found in different libraries in the same production library list. If you have ever had duplicate object problems, you will remember them quite clearly as being difficult and time-consuming to diagnose. Duplicate objects can easily be discovered, before they cause problems for your production users.
One common cause of duplicate objects is improper promotion procedures. For example, if you promote a file to your general ledger file library, GLFILES, and later mistakenly promote a different version of the file to your general ledger program library, GLPGMS, you will have duplicate objects in the library list.
In this situation, every time that GLFILES is above GLPGMS in the library list, the incorrect version of the program will be used.
Another cause of duplicate objects is accidental re-use of an object name. If two programmers choose the same name for a new object, and both objects are promoted to different libraries in the library list, duplicate objects will occur. In this case, it is likely that when the incorrect object is used, a program will crash, due to some discrepancy in the expected parameters or file format.
To find duplicate objects in the library list, first create a file of object descriptions for all of the libraries to be checked. For example, in order to check that there are no duplicate objects in the general ledger file and program libraries:
DSPOBJD OBJ(GLFILES/*ALL) +
DSPOBJD OBJ(GLPGMS/*ALL) +
Keep adding object descriptions if it is necessary to find duplicate objects in more than two libraries. If you read my article in January 1996, "Where Did All The DASD Go?", and have created a file with all of the object descriptions for the system, you can use query to select out object descriptions for the libraries you want to analyze.
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 libraries being analyzed. 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 check duplicate objects.
Instead, it is useful to 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 libraries, but will not have permanent access to them.
Use query to join the file of object descriptions to itself. Therefore, file T01 is mylib/myfile and T02 is mylib/myfile. Use the Matched Records join (type 1), and match fields based on:
T01.ODOBNM EQ T02.ODOBNM
T01.ODOBTP EQ T02.ODOBTP
T01.ODLBNM NE T02.ODLBNM
The match criteria above indicate that you are searching for cases where the object name is the same, and the object type is the same, but the library name is different. When selecting the fields to print, remember that every object is already included in the first file, so you need only print the fields from the T01 file. If you sort the objects by object name, and use a level break on object name, you will get a tidy report with duplicate objects grouped together by name.
Because a matching record join was used with exactly the join criteria required to identify duplicate objects, your reports will include only duplicate objects. You could follow this procedure whenever significant promotions to production are done. You could also use it routinely, perhaps weekly or monthly, depending on the frequency with which you make changes to production programs.
You can save a lot of time and aggravation by finding duplicate objects before they find you!
Debbie Gallagher has experience at finding misplaced objects in production libraries.