IBM i stores programs, files, libraries, data areas, job queues and many other resources as objects. When a job finds the wrong thing, start with object lookup commands. Use the same approach when a job cannot find an object or lacks authority.
This page is a lookup for commands that inspect objects, libraries and members. For the concept-level explanation, read IBM i Libraries, Objects, and Members Explained.
Quick command map
| Task | Command | Changes something? |
|---|---|---|
| Search for an object | WRKOBJ | Display is read-only; options can change objects |
| Display object details | DSPOBJD | No |
| Check existence and authority in CL | CHKOBJ | No |
| Display a library’s contents | DSPLIB | No |
| Work with libraries | WRKLIB | Display is read-only; options can change libraries |
| Work with source or file members | WRKMBRPDM | Display is read-only; options can change members |
| Display file description | DSPFD | No |
WRKOBJ
Use WRKOBJ when you know a name or pattern and need to find matching objects.
WRKOBJ OBJ(*ALL/CUSTOMER) OBJTYPE(*FILE)
WRKOBJ OBJ(MYLIB/ORD*) OBJTYPE(*PGM)
WRKOBJ OBJ(*LIBL/PRT*) OBJTYPE(*OUTQ)
OBJTYPE matters. The same object name can exist with different types. Include the type when troubleshooting.
DSPOBJD
DSPOBJD displays object metadata.
DSPOBJD OBJ(MYLIB/CUSTOMER) OBJTYPE(*FILE)
DSPOBJD OBJ(MYLIB/ORDENTR) OBJTYPE(*PGM) DETAIL(*FULL)
Use it to inspect owner, object type, attribute, text, creation date, change date and library. It does not show file fields; use DSPFD for database file details.
CHKOBJ
CHKOBJ is useful in CL programs because it sends escape messages when an object is missing or authority is insufficient.
CHKOBJ OBJ(MYLIB/CUSTOMER) OBJTYPE(*FILE) AUT(*USE)
MONMSG MSGID(CPF9801 CPF9802 CPF9810) EXEC(DO)
/* handle missing object, not authorized, or missing library */
ENDDO
Common monitored conditions are object not found, not authorized, library not found and member not found. Use specific message IDs when possible instead of broad CPF0000.
This block is a CL procedure fragment: MONMSG and ENDDO are not standalone command-line commands. The explicit AUT(*USE) checks use authority; the default AUT(*NONE) does not establish that the application can read or update the file. Match the requested authority to the intended operation and monitor additional failures, including member-not-found when checking a member.
DSPLIB and WRKLIB
DSPLIB displays or prints information about libraries and their contents.
DSPLIB LIB(MYLIB)
DSPLIB LIB(*LIBL)
WRKLIB gives an interactive work-with display. From a work-with display, options may delete, change or authorize objects, so treat the menu as potentially operational.
WRKMBRPDM
WRKMBRPDM is common for source files and members.
WRKMBRPDM FILE(MYLIB/QRPGLESRC)
WRKMBRPDM FILE(MYLIB/QCLLESRC) MBR(ORD*)
It is convenient but powerful. Options can edit, copy, delete and compile members depending on your environment. For read-only investigation, inspect names, types and text first.
DSPFD
DSPFD displays a database file description.
DSPFD FILE(MYLIB/CUSTOMER)
DSPFD FILE(MYLIB/CUSTOMER) TYPE(*MBRLIST)
Use it when object details are not enough: member list, record format, access path, key fields and file attributes are file-description questions, not object-description questions.
Practical lookup patterns
| Problem | Command pattern |
|---|---|
| Program cannot find a file | WRKOBJ OBJ(*LIBL/file) OBJTYPE(*FILE), then DSPLIBL |
| Program finds the wrong file | WRKOBJ OBJ(*ALL/file) OBJTYPE(*FILE) and compare library order |
| CL check fails | CHKOBJ, then read the exact CPF message |
| Source member missing | WRKMBRPDM FILE(lib/srcfile) MBR(member) |
| Level check or file mismatch | DSPFD FILE(lib/file) and compare record format |
| Authority problem | DSPOBJD, DSPOBJAUT, and security review |
For library-list order problems, use IBM i Library List Commands Reference.
Member and file-detail boundaries
Object commands tell you that a file object exists. They do not answer every question about what is inside the file.
| Question | Better command |
|---|---|
| Which members are in this physical file? | DSPFD TYPE(*MBRLIST) |
| Which source members match a pattern? | WRKMBRPDM |
| What are the record formats and keys? | DSPFD |
| Who owns the file object? | DSPOBJD |
| Does the file exist in the application library list? | WRKOBJ OBJ(*LIBL/name) OBJTYPE(*FILE) |
This distinction matters during level-check errors and source-member cleanup. A file can exist as an object while the specific member, format or access path you expected is different.
Common mistakes
- Searching without
OBJTYPEand acting on the wrong object type. - Looking only in
*LIBLwhen the duplicate object lives elsewhere. - Assuming a work-with option is harmless.
- Checking object existence but not authority.
- Confusing source members with database file members.
- Using
DSPOBJDwhen the question is really a file-definition question forDSPFD.
Authority-aware lookup
Object lookup and authority troubleshooting are related but not identical.
| Question | Better starting point |
|---|---|
| Does the object exist? | WRKOBJ, DSPOBJD, or CHKOBJ |
| Which library contains it? | WRKOBJ OBJ(*ALL/name) OBJTYPE(type) |
| Can this user use it? | CHKOBJ under that user’s job, or DSPOBJAUT review |
| Who owns it? | DSPOBJD |
| What authority is required? | Command help, object authority and application design |
Do not grant authority just because an object exists and a job failed. First confirm the object type, library, owner and public authority. Also confirm whether the job should be using that object at all. For the security model, read IBM i Security Fundamentals and Best Practices.
Duplicate-name checklist
Duplicate object names are normal on IBM i. They are also a frequent source of test-versus-production surprises.
| Check | Why it matters |
|---|---|
| Object type | The same name can exist as different object types |
| Library order | The first matching library in the job’s list wins |
| Object attribute | A file, program or command can have a subtype or attribute |
| Owner and authority | The object found may not be usable by the job |
| Change date | An old test object can hide in a library for years |
When the wrong object is found, compare the job’s actual library list with the duplicate-object list. The IBM i Library List Commands Reference covers that side of the investigation.
FAQ
Why did CHKOBJ fail when WRKOBJ finds the object?
The job may not have authority, may be checking a different object type, or may be searching a different library path. Read the exact CPF message.
Should I use *ALL for object type?
Use it only for exploration. Once you know the target, specify the object type so you do not act on a different object with the same name.
Is a member an object?
A source or database member belongs to a file object. Use member tools such as WRKMBRPDM or file-description tools such as DSPFD when the question is about members.
What should I save from a lookup?
Save the object name, type, library, owner, attribute, text and change date. If authority is involved, save the specific message ID too.
When should I qualify the library name?
Qualify the library when you know the intended object. Use *LIBL only when you are testing the same lookup path the application uses.
Summary
- Use
WRKOBJandDSPOBJDto find and inspect objects. - Use
CHKOBJin CL when a program needs to test existence or authority. - Use
DSPLIB,WRKLIB,WRKMBRPDMandDSPFDfor library, member and file details. - Always include object type and library context when troubleshooting.