Resolve xxRUNJOB command issue in MailStream Plus, CODE-1 Plus, List Conversion Plus, and more on IBMi

Operating System: IBMi, iSeries, AS400



This applies to the original Group1 Software products on the IBMi platform.
When submitting a job from a Command Line or CL script using the xxRUNJOB command, the JobID gets locked until the step completes.
(xx= 'UP' for MailStream Plus, 'C1' for CODE-1 Plus, 'LC' for List Conversion Plus, etc.)

If a job such as @IVP@ is ran using xxRUNJOB, and while it is running it is attempted to be ran a second time, the second one will fail, because the Job is locked (ie 'in use') by the first job. 
A job is 'locked' by the creation of a temporary data area in the application library (like 'G1MSPGMS').   For example, the file would be called 'JBID_@IVP@' if the JobID was @IVP@.

The same error can occur if the job is open for viewing/editing on the CHUI screens when it is submitted from a CL.


There will be errors in the JOBLOG (QPJOBLOG) *similar* to these:
Data area JBID_@IVP@ exists in G1MSPGMS.
Job @IVP@ in use by NATI0001   at QPADEV000J since 13:01:15 on 01/05/17.
RNX0233 ... RPG procedure UPSBMRUN returned with halt indicator 1 on
The halt indicator 1 in RPG procedure UPSBMRUN in program G1MSPGMS/UPSBMRUN was set on and a return was requested.
CPM8199    Diagnostic  ...  Message . . . . :   Abnormal termination detected, see previously listed



UPDATED: December 27, 2018
The resolution is to not use xxRUNJOB to run a job a 2nd time, while it is still running from a previous xxRUNJOB.
If xxRUNJOB is used within just one CL calling the same JobID more than once, there should not be a problem.  That's because each xxRUNJOB stops the CL from going to the next step in the CL until the xxRUNJOB has completed.  And at the completion of each xxRUNJOB the lock should have been removed. 

But when using xxRUNJOB within different CLs that happen to be calling the same JobID at near the same time, the first one would lock the JobID, and the second would get the error.

There is another command option, using xxSBMJOB.  It works like the xxRUNJOB, but it just *submits* the job to run in batch mode.  It does not lock the JobID while it is running.  
And xxSBMJOB in a CL it does not stop the CL from immediately going to the next step.  Since using xxSBMJOB does not stop the CL from proceeding, this may not be a solution if you need to have the application job step finish each time, before the CL continues.

Do not have the job open on the CHUI screens while trying to run it in a CL.