bjects can easily be misplaced in production libraries. By this I mean that program objects can end up in libraries meant for database files only, and files can be lost in libraries where only programs were intended to be.
Objects which are not in the proper libraries can cause a lot of time to be spent on locating objects. In addition, once an object has been placed in the incorrect library, it is easy to end up with more than one object of the same name in the library list. The usual cause of misplaced objects is an error in object promotion.
The first step in finding misplaced objects is to define the correct placement for each object type / attribute combination in production libraries. This step only needs to be done once, unless you start using new object types in production.
For example, let's assume that you are interested in accounts payable, which has a file library and a program library. The libraries to be analyzed are APPGMS and APFILES. After reviewing the types of objects in production for accounts payable, we'll further assume the only object types / attributes used and their placement should be as follows:
Library Type Attribute
APPGMS *PGM RPG
*PGM CL
*FILE DSPF
*FILE PRTF
*QRYDFN
APFILES *FILE PF
*FILE LF
*DTAARA
Let's say that source files QRPGSRC and QCLSRC should be placed in the program library, although all other physical files are in the file library.
To find misplaced objects, first create a file of object descriptions for all of the libraries to be checked:
DSPOBJD OBJ(APFILES/*ALL) +
OBJTYPE(*ALL) +
OUTPUT(*OUTFILE) +
OUTFILE(mylib/myfile) +
MBROPT(*REPLACE)
DSPOBJD OBJ(APPGMS/*ALL) +
OBJTYPE(*ALL) +
OUTPUT(*OUTFILE) +
OUTFILE(mylib/myfile) +
MBROPT(*ADD)
Keep adding object descriptions if it is necessary to find misplaced 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.
For DSPOBJD, ensure that you have provided for sufficient authority to get all of the information you need. The AS/400 will give you information for only those objects to which you are authorized. Commands that adopt authority can be helpful for this purpose. For example, if you use the command DSPOBJD as QPGMR, you will get only object descriptions that QPGMR is authorized to see. So, create a command and command-processing program called, for example, ALLOBJD. Have QSECOFR compile these new objects with USRPRF(*OWNER).
When you use the command ALLOBJD, you will get object descriptions for all objects in the requested libraries, but will not have permanent access to them.
Use query to select records for objects that are misplaced, based on their object type and attribute. For our example, the select records part of the query would look like:
ODLBNM EQ 'APPGMS'
and ODOBTP NLIST '*PGM'
'*FILE'
'*QRYDFN'
or ODLBNM EQ 'APPGMS'
and ODOBTP EQ '*FILE'
and ODOBAT NLIST '*PRTF'
'*DSPF'
'*PF'
or ODLBNM EQ 'APPGMS'
and ODOBTP EQ '*FILE'
and ODOBTP EQ 'PF'
and ODOBNM NE 'QRPGSRC'
'QCLSRC'
or ODLBNM EQ 'APFILES'
and ODOBTP NLIST '*FILE'
'*DTAARA'
or ODLBNM EQ 'APFILES'
and ODOBTP EQ '*FILE'
and ODOBAT NLIST 'PF' 'LF'
or ODLBNM EQ 'APFILES'
and ODOBTP EQ '*FILE'
and ODOBAT EQ 'PF'
and ODOBNM LIST 'QRPGSRC'
'QCLSRC'
Because of the detailed selection criteria specified on the query, the report shows only objects which are misplaced. 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 find promotion errors by following this procedure to find misplaced objects.
T
<
G
Debbie Gallagher has experience at finding misplaced objects in production libraries.