Re: Job ran halfway thru, then vanished except for 2 QPDSPJOB spool files in QEZDEBUG.

On 02 May 2012 12:30, John Rusling wrote:

We have an interactive, end of day job that the user keys a date
into, then enter's to run (interactively) some CLs and RPGs.

Yesterday the job was started, but never finished. We talked to the
user this morning who declared that nothing unusual happened when
she ran it yesterday.

I can't find anything, anywhere in the system to show how/why this
happened.

If our in-house log file hadn't revealed this, we would have had no
clue that anything was out of the ordinary ...

No QSYSOPR message was generated, the QEZDEBUG spool files merely
contain some job stats info. No escape msg info or anything like
that. DSPLOG command doesn't reveal anything.

We've resolved that an admin or developer accidentally whacked it
-or- the user did 'something' not normal, somehow to end it.
(Although, we don't give them that much power)

Does this sound familiar to anyone, has this happened to you before,
or anyone have a hint or insight?

We've moved on but... it's bugging me and I just thought I'd ask.

Attempt to get a DSPJOBLOG OUTPUT(*PRINT) for the job, get a new QPDSPJOB using WRKJOB OUTPUT(*PRINT), then post the three QPDSPJOB and if produced, the QPJOBLOG, to code.midrange.com

DSPLOG for the job would typically show the job end message, even if someone had deleted a program from the stack. If the job effectively ended as incomplete, perhaps un-notified, but the Job Message queue would remain; that could be dumped. If something bad happened, then there would likely be VLogs including one with a process dump included. As Rob noted, along with DSPLOG, the WRKPRB may have something if the QPDSPJOB were some variety of system code versus user code; only looking at the existing QPDSPJOB will reveal that, minimally by review of the stack. The timestamps in the QPDSPJOB spools are good for timestamps to review other information, such as the VLIC logs.

Regards, Chuck