Multi-threading batch AR cash applications

May work for your particular needs but here are two possible (and quick) solutions off top of my (balding) head:
- you can try changing AR575 in pgmdef to not run concurrently; that will force subsequent submissions to wait in queue
- set up a separate queue with job limit of 1, and assign it to the AR system code

Not sure how changing that will help since AR575 uses the ARIPMT and ARIPMT has to be loaded with data. AR575 will then process everything in ARIPMT regardless. We are wanting multiple users to be able to "load" data into the interface table(s) and then having just the transactions they loaded processed into Lawson.

sorry, i guess i misunderstood your original post.
How is the data getting into ARIPMT?

Our current processing:

AR575 --> we have a custom written cobol program (GS575) that reads a flat file and loads the data into ARIPMT. The first thing this code does is checks to see if any data exists in ARIPMT, if so, the job fails with Invalid Parameters. Once GS575 is completed, the user can run an AR575.

AR580 --> I wrote some perl scripts to read flat files and load the data into ARIPAYMENT and ARIREMIT (no check to see if data already exists). Some scripts auto submit an AR580 after data is loaded, others require a user to submit an AR580.

This conversation does lead me to think that I may be able to check for data, if data exists, sleep for X number of seconds and then check again. Another option i was thinking about was to create an IPA flow that processed the data using standard Lawson screens, thereby removing the interface tables completely. (Was trying to suppress the options I came up with so as not to impede everyone's creative thoughts)

The approach I was suggesting (which I've used with other clients) uses PFI or IPA to receive the data (via PFI's BCI ScanFileClient or IPA channels to detect new file drops), writes to CSV files for ARIPMT, loads via importdb, runs AR575 in a single-threaded queue, etc. The flow can be made to only operate on one file at a time and quietly exit or wait if ARIPMT already has data in it or there are no files left to process. The AR575 job is a multi-step job with the last step being to call the flow again to get the next file. As long as the IPA flow is the only entry point for the transactions, it does the trick. Poor man's orchestration, but it works.