1-About it

One day I had a problem with Paul, a user of my site. He had a CL program executing in sequence two Java utilities downloaded from my site. The first utility was running fine. The second utility was bumping out because - in the same job -the properties of the JVM started by the first utility were not appropriate for it.
The solution was apparently very obvious. The main program had to submit the execution of the second utility in a separate batch job.
However, the main program needed to resume control and continue its process once the submitted job - running the second utility - had reached its completion.
So, the problem was: how to synchronize two events, the end of the submitted job and the process resuming of the main program?

I therefore I developed a RPG tool that allows a program to submit a job and to resume processing only when the submitted job (which I call " tightly synchronized " job) comes to completion.
I sent this solution to Paul and he was enthusiastic about it.

A few days later, I though that it would be appropriate to have an alternate way of submitting a synchronized job. The main program, after submitting a job, is allowed to continue its process until the results from the submitted job are needed to continue the its process. At that time the main program explicitly waits for the completion of the submitted job.
This type of submitted jobs I call " loosely synchronized ".
This technique can be used to perform PARALLEL JOB PROCESSING: several loosely synchronized jobs are submitted from a main program, which then waits for their completions.

Look at the following example.

• A program (A) that computes the quarter sales income
• A program (B) that computes the cost of purchased material and services
• A program (C) that computes the structural costs (employees, building maintenance, administration, electric power, telephone, ad so on)
• A program (D) that computes the net profits from the results of the previous three programs.

In case some of these programs cannot be executed in the same job (for instance: they come from different vendors, and each vendor has its own JVM CLASSPATH), using ouy utility you can run them sequentially in separate submitted jobs, see Figure 2. The work is completed in the same time as in the previous approach, but you have no headaches.

Let's go une step further. Suppose that programs A, B and C do not share any database resources, so they could work in parallel. If so, why not having the main program submitting them for parallel running, resuming execution when they are all completed, the run program D. Also that can be implemented with this utility and will result in a significant time reduction, see Figure 3.

J1 pgm A pgm B pgm C pgm D

Figure 1 - Standard Main program

J1 pgm A J2     pgm B       J3       pgm C     J4         pgm D

Figure 2 - Main program running tightly synchronized jobs

J1 pgm D   J2   pgm A   J3   pgm B   J4   pgm C

Figure 3 - Main program running loosely synchronized (parallel) jobs

In summary with utility SYNCJOB you can

• Run submitted jobs maintaing control on their completion status, which results into
• No environmental conflicts
• Parallel job processing and consequent faster execution.

2-Prerequisites

• Minimum OS/400 release: V5R2
  
• 57xx-WDS Compiler ILE RPG IV (needed only during the installation process)

3-Installation

• Download file syncjob.zip from the Easy400 download page and unzip it.
• Follow the syncjob.txt instructions to upload and to restore library SYNCJOB.
• On your IBM i
  • sign on with a class *SECOFR user profile
  • run the following procedure:
    STRREXPRC SRCMBR(INSTALL) SRCFILE(SYNCJOB/QREXSRC)
    It does the following:
    • creates objects in library SYNCJOB
    • restores IFS directory /syncjob
    • creates and populates library SYNCJOBDTA (Local data)
    • installs the HTTP instance SYNCJOB (listening on port 8019).

4 - Updates