Submitting a separate job for each such request, in an attempt to achieve multi-threading, in this case, might actually be worse, in overall elapsed time, due to the extra overhead of job start-up, etc.

You might also want to consider starting one or more "server" jobs that all listen to the same request data queue, and then PgmA just calls QSNDDTAQ to post a request to that data queue, with any needed information such as the "key" or invoice #.

Then, you can "tune" the system by starting up more jobs to run in parallel, all listening to the same data queue.  Each job, after processing one request, goes back to the top to issue QRCVBDTAQ to receive the "next" request.

OS/400 and IBM i takes care of distributing requests to however many listeners you choose to start up.

Hope that helps,

Mark S. Waterbury


On Wednesday, April 15, 2026 at 04:48:09 PM EDT, smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx> wrote:

If I have PgmA and it repeatedly calls PgmB, I know not setting on LR makes the process faster because it doesn't have to reload PgmB into memory every time. 

The argument that we are having is related to PgmA submitting PgmB to enable multi-thread processing.  Does not setting on LR help in this case because they are different jobs?

For example,
PgmA
    Do until shutdown
        Read Invoice Header File for unprocessed invoices
            If a new invoice is found
                Mark the invoice as In-Process
                Submit PgmB to process the invoice


PgmB
    Process invoice based on invoice number received
    Mark invoice as Processed
    ** Note: no *INLR logic here
    Return

    VS

    Process invoice based on invoice number received
    Mark invoice as Processed
    *inlr = *on
    Return


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.