Restarting batch jobs
Content in the job control file CJBCTL and job command file is displayed using M3 BE programs 'Job. Display History' (MNS320) and 'Submitted Job. Open' (MNS250).
Jobs are restarted in (MNS320) if they are in status 10, 25, or 26. If an interrupted job cannot be restarted directly in (MNS320), a message is displayed indicating that it must be restarted from another program.
Some jobs are restarted in (MNS250) if status is 15 or 25. However, this is not a good idea unless the original problem has been analyzed. In most cases, a restart only causes a new dump.
See further information in the General Ledger documentation under Financial Accounting.
The execution of the jobs can stop in different ways:
- If a single job is finished abnormally, this is managed by CMNGJOB and the status in CJBCTL is updated.
- If the whole computer dumps, or CMNGJOB dumps, the status is not updated in CJBCTL for active job. The jobs that were executing when the crash occurred will still have status 20, active, in the CJBCTL file.
A check is performed each time the CMNGJOB is restarted. All jobs currently with status 20 are checked on all active JVMs. If the jobs with status 20 are not active, the status will be set to 25, and an investigation procedure should be started to determine the reason for this.
A submitted job can be in different statuses when the problem occurs:
Status | Description | Action |
---|---|---|
00 | Submitted but not started | No action required. The job remains in status 00 and will be started when CMNGJOB is restarted. |
10 | Job is manually put on-hold. | On-hold jobs can either be restarted or canceled from (MNS321). They can also be restarted directly from (MNS320). |
15 | Start of the job failed. This status is set by CMNGJOB. | Examine the cause, and when fixed, try to restart
from (MNS321), (MNS250), or (GLS047). This is normally harmless to do, as the job failed before the execution has begun. |
20 | The job was active when the crash occurred. | Normally this job is set to status 25 when the CMNGJOB is restarted. If not, manually set status to 25 and proceed with action on that status (see below). |
25 | The job had dumped or was in status active when the crash occurred. | Examine the cause and try to fix the problem. This
is the trickiest part as we cannot say for certain what happened. The transaction will
normally take care of all unfinished database updates, so it will be OK to restart
from (MNS250) or (GLS047). However some jobs cannot be restarted without deleting work files or restoring backup. |
26 | The job has been terminated because of shut down of the subsystem | Only jobs for which controlled shut down is implemented will be set to status 26 if interrupted by a controlled subsystem shut down. |
30 | Finished | No action required. |
90 | Canceled | No action required. |
If the batch job manager (CMNGJOB) does not release a job if the execution subsystems are fully occupied, it is important to check that the restart function works properly. If not, the subsystem can be empty, but the batch job manager assumes that the subsystem is fully occupied as many CJBCTL records are in status 20 (but were interrupted and should have status 25). A job in status 20 cannot be restarted as the system still treats it as active.
If a 'full load stop' occurs, it can result in no jobs being started. In this case, CMNGJOB will make the wrong assumption that all subsystems are busy. This can temporarily be managed by changing the number of jobs in the subsystem until the situation is under full control and the problems are sorted out.
To cleanup a job control file, the files CJBCTL and CJBCMD must be examined and cleaned up on a regular basis as no automatic function can manage to clear these files for interrupted jobs.