AS400 - jobs abended, no joblogs, nothing in DSPLOG.....

Frosty the Coder

Legendary Poster
Our nightlyjobs are submitted from a OW menu, to 3 diff HELD jobqs on our
(This is to get around issues w/SCHEDULER, RUNUBE, .....)

This procedure has been working for many months, w/out any problems.

Fri night, the jobs kicked off as scheduled, after the completion of

The 1st nine jobs that had been submitted died.
The next six ran to completion.
The next five died.
The next 23 ran to completion.
The next 6 die.
The final 14 ran to completion.

The completions and abends are found in each of the jobq's.

The completions and abends are comprised of JDE vanilla
and custom batch jobs.

The completions and abends are such that one version of
a job (ie r42520 (pick slip print)) fails and it is immediately
followed by a diff version of that same job, which completes
(in the same jobq).

We have resubmitted _some_ of the failed jobs, this morning,
and they've run to completion.

WSJ just says the jobs ERRORED. We cannot view the logs,
as we don't run w/logging turned on. Performance is bad enough
as it.

There are no joblogs on the 400 that might give a clue as to what
may have happened.

DSPLOG for the time span that these just shows the jobs starting
and completing w/out mentioning the fact that they did abend. Nor
do we see any other jobs/events that would cause this to occur.

This being the case, where can we look to find out what happened?

TIA for any/all help, suggestions.


PS - there is a great email floating about of WINDOWS err msgs written
as Haiku. Paraphrasing one to express THIS situation:

Yesterday it worked.
Today it is not working.
Oneworld is like that.

Gene Piekarski, Jr

AS/400, B733, SP11.2, NT client


Well Known Member

We have had similar problems in the past.

One thing we do on at least a weekly basis (at least we try to) is IPL the AS400 and delete all the SQL Packages. Weekly backup is a good time for this. This has greatly reduced the number of jobs that fail for us. We were never able to deterimine the exact causes either.

FWIW, we have been running our nightly with CL progams and RUNUBE for over 2 years now. Along with jobs we run during the day, we submit about 160 jobs with RUNUBE through CL programs every day.

The only UBEs we do not run this way are table conversions or UBEs that require daily processing option and/or data selection changes. For those jobs, we submit those to a held queue as you do and release/hold the queue in our CL programs.

On issue we found is that we would occasionally lose a job submitted this way, We added a 15 second delay between each SBMJOB of a UBE. (We always use SBMJOB appears to control the QUEUE and job name, etc. and this way and the CL program does not need to wait for each UBE to run.)

Hope this helps.