MSGW means a job is waiting for a message reply. The dangerous part is not finding the message; it is replying without understanding what the program is asking. This runbook keeps the first response read-only until you know the safe action.
Use this page for operations triage. For command syntax, see the IBM i Job Commands Reference. For message IDs and job logs, see the IBM i Job Log and CPF Messages Reference.
First response
- In
WRKACTJOB, note the job name, user, number, subsystem, status and function. - Open the job with
WRKJOB JOB(number/user/name). - Display the job log with option
*JOBLOG, or runDSPJOBLOG JOB(number/user/name). - Find the inquiry message that is waiting for a reply.
- Read F1 help and message details before answering.
- If the message is not understood, escalate with the exact message ID and text.
Do not end the job or send a reply merely to clear the status. The job is stopped at a decision point, and the reply can affect data, files, printing, or recovery.
Commands to use
WRKACTJOB
WRKJOB JOB(123456/USER/JOBNAME) OPTION(*JOBLOG)
DSPJOBLOG JOB(123456/USER/JOBNAME)
WRKJOB JOB(123456/USER/JOBNAME) OPTION(*PGMSTK)
WRKJOB JOB(123456/USER/JOBNAME) OPTION(*JOBLCK)
These commands inspect the job. Replying to a message, ending the job, holding it, or changing its attributes is a separate action.
What to capture
| Evidence | Why it matters |
|---|---|
| Qualified job name | Prevents action against the wrong duplicate job |
| Current function | Often names the command, program or file involved |
| Inquiry message ID and text | The reply must match this message |
| Earlier diagnostic messages | The real cause is often above the inquiry |
| Call stack | Shows which program is waiting |
| Locks and open files | Helps identify record or object contention |
If you must escalate, paste the job name, message ID, available replies and the earlier diagnostic messages. Do not paraphrase the message as “it asked C or G”; the exact message matters.
Reply decision table
| Situation | Safer action |
|---|---|
| The message help names a harmless retry and the cause is fixed | Reply with the documented retry value |
| The message asks to cancel, ignore or continue after an error | Escalate unless the application runbook says exactly which reply to use |
| The message is about a missing file, library or device | Check library list, object existence, device or output queue before replying |
| The message repeats after the same reply | Stop replying and escalate |
| The job is production batch with possible data changes | Escalate before ENDJOB or cancel replies |
The right answer can be application-specific. A reply that is safe for a report may be unsafe for an order update or month-end process.
Common causes
| Symptom | Likely area to inspect |
|---|---|
| Object not found | Library list, object name, object type, authority |
| Not authorized | User profile, adopted authority, object authority |
| Record or object in use | Locks, commitment control, another job |
| Printer or output queue issue | Spooled file, writer, output queue status |
| Program inquiry message | Application error handling and message file |
| Decimal data, array index or RPG inquiry | Job log, RPG status, recent input data |
For library and object lookup, use IBM i Library List Commands Reference and IBM i Object and Library Commands Reference.
When to use ENDJOB
Use ENDJOB only after you decide the job should not continue or cannot continue safely.
ENDJOB JOB(123456/USER/JOBNAME) OPTION(*CNTRLD) DELAY(60)
A controlled end is normally preferable to an immediate end. Before ending the job, capture the job log and message details. If the job is in the middle of a transaction, coordinate with the application owner.
Preventing repeat MSGW
After the immediate incident, fix the cause:
- Correct the library list or job description if the job finds the wrong object.
- Add specific CL
MONMSGhandling for expected failures. - Improve application validation before submitting batch work.
- Fix authority instead of replying around an authority error.
- Route expected inquiries to an operator queue with a documented runbook.
- Use the system reply list only for well-understood, stable messages.
Do not use broad automatic replies as a substitute for error handling. They can hide production failures.
Common mistakes
- Replying from memory without reading F1 help.
- Looking only at the inquiry message and ignoring diagnostics above it.
- Ending a job before capturing evidence.
- Assuming every
MSGWcan be answered with the same reply. - Treating a missing object as a one-time incident when the batch library list is wrong.
- Adding a generic monitor or automatic reply that hides real failures.
What not to automate
Do not add a broad automatic reply because one recurring message is annoying. An automatic reply can turn a visible production wait into a silent data problem. Use automation only when all of these are true:
| Requirement | Why it matters |
|---|---|
| The exact message ID is known | A generic reply can match unrelated messages |
| The allowed reply is stable | Different programs can use different meanings |
| The cause is understood | Automation should not hide a defect |
| The application owner approves it | Business impact may be outside operations |
| The job log remains reviewable | You still need evidence when something changes |
If the cause is a predictable missing object or authority condition, fix that cause first. If the cause is an expected application condition, add specific error handling in the program or CL wrapper. For CL message design, read IBM i Message Files and Exception Handling in CL.
FAQ
Does MSGW mean the job is hung?
Not necessarily. It means the job is waiting for a message reply. The program may be doing exactly what it was coded to do when it encounters an inquiry message.
Should I answer C to cancel?
Only when the message help or application runbook says that cancellation is the right outcome. A cancel reply can stop processing after partial work has already happened.
Why does the same job keep entering MSGW?
The underlying condition is still present. Common repeat causes are wrong library list, missing object, authority failure, unavailable printer, record lock, or application data that triggers an inquiry.
Summary
MSGWis a waiting decision, not merely a stuck status.- Inspect first:
WRKACTJOB,WRKJOB,DSPJOBLOG, call stack and locks. - Reply only when the message help, application runbook or owner identifies the safe answer.
- Fix the underlying object, authority, library list, printer, lock or application condition so the job does not wait again.