Re: Custom compile from IFS

----- Message from John Yeung <gallium.arsenide@xxxxxxxxx> on Thu,
21 Apr 2016 12:44:40 -0400 -----

To:

"Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries" <wdsci-l@xxxxxxxxxxxx>

Subject:

Re: [WDSCI-L] Custom compile from IFS

On Thu, Apr 21, 2016 at 12:03 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

Alas, terminology.

Indeed. As is often the case, there are different levels of meaning
for any given word or phrase.

One level is the thing you get when you do RTVJOBA TYPE(&TYPE).

Another level is the notion, not specific to the i, that "batch
processing" entails sequential queues of work, whereas "interactive
processing" entails parallel or perceived-as-parallel execution.

I think a more precise understanding of Batch would be that batch entails
a detached process where the requesting(/submitting) process does not wait
for the result.

The host server jobs where the compiles run "interactively" are prestart
jobs. (Display job indicates a job type of PJ) Prestart jobs are a subtype
of Batch jobs. So either way, you are compiling in batch.

If the same hundred developers requested the same hundred compiles
simultaneously, and those requests went to a single, common job queue
('batch compile'), they would process one after the other, rather than
all in one go.

So here's another term with multiple levels of meaning: queue. ;) At
our shop, we all compile in batch, and we all submit to the same
queue, but it's configured to run more than enough concurrent jobs
that in practice none of our compilation jobs ever has to wait for
another to finish.

All batch jobs run through a queue. (Not to correct your comments above,
but to make sure no one misunderstands.) Some queues are single-threaded
allowing only one active job at a time and others allow multiple jobs to
be active at the same time (all controlled by the MAXACT parameter on the
jobq entry). Practically, it may never be an issue for a multi-threaded
job queue, but the reality is there is a limit. Even if MAXACT is set to
*NOMAX, the subsystem has a MAXACT parameter. It, too, could be set to
*NOMAX, but there is a practical limit to how many active jobs any system
can handle. Regardless, the jobs start (or become active) by way of a
queue--the line or order of jobs submitted and/or waiting to start in the
subsystem. They are started in order submitted within the JOBPTY of the
job.

Oddly enough, compiling in batch in RDi could allow simultaneous process
of multiple jobs submitted from one RDi instance. Compiling
"Interactively" would insure a single job at a time. If the job queue used
by RDi is not single threaded, it would be wise to do it Interactively.
Then compiles of multiple objects would be handled in the proper sequence.
Submitting jobs to a multi-threaded queue could be problematic. e.g., A
program which uses a display file could be compiling at the same time
changes to the display file are compiling--not very productive.

John Y.