byimw02   0 pts.  |   Aug 11 2005  9:07AM GMT

If only one user on the entire system is allowed to call either program, the object allocation method is adequate. Additionally you could call a Pgm C which simply calls either Pgm A or B dependent on status of the locked object. This automates the decision-making whether to call A or B. You can make Pgm A and Pgm B only be callable from Pgm C and not directly from a command line using the object allocation or existence method. Hope this helps.

General example:
A: PGM
chkobj qgpl/temp *dtaq
monmsg cpf9801 exec(goto endpgm)
alcobj temp *dtaq *EXCL
monmsg cpf1000 exec(goto endpgm)
alcobj A *dtaaara *EXCL
monmsg cpf1000 exec(goto endpgm)

-pgm A logic-
dlcobj A *dtaara *excl
endpgm: endpgm

B: PGM
chkobj qgpl/temp *dtaq
monmsg cpf9801 exec(goto endpgm)
alcobj temp *dtaq *EXCL
monmsg cpf1000 exec(goto endpgm)
-pgm B logic-
endpgm: endpgm

C: PGM
chkobj qgpl/temp *dtaq
monmsg cpf9801 exec(do)
CRTDTAQ QGPL/TEMP
alcobj temp *dtaq *EXCL
ALCOBJ A *DTAARA *EXCL
monmsg cpf1000 exec(do)
Call B
goto endpgm
enddo
Call A
DLCOBJ A *DTAARA *EXCL
enddo
endpgm:
Dltdtaq temp
monmsg cpf0000
endpgm

TomLiotta   8025 pts.  |   Aug 11 2005  2:19PM GMT

In general, no. That is, unless the application is specifically programmed to support that feature, it isn’t supported by the system.

Exclusive locks written into the code is the most common method. Separate objects, such as a data area, aren’t necessary; the program objects themselves can be the target of the locks. Note that the locks don’t prevent programs from being called, but the programs would test the locks and exit if conditions were wrong.

The nice thing about locks is that they clean up automatically. Even if programs end abnormally, locks will disappear when the locking job goes away. One trouble with locks is that a single job can establish multiple locks and _every_ lock should be released.

This might be the case where JOBA calls PGMA and PGMA establishes a lock and then fails. As long as JOBA continues, the lock remains. If JOBA calls PGMA again, a second lock is established. When PGMA completes normally this time, it needs to deallocate _two_ locks; otherwise, no other job can run PGMA until JOBA ends. Further, only JOBA can release the lock; the lock can’t be forced to go away by JOBB (unless JOBB ends JOBA or unless some more complex programming is done beyond CL).

An example of a potential alternative would be PGMA creating a system-level environment variable. If the environment variable already exists, then PGMA knows it shouldn’t be running. In this case, when PGMA fails to complete in JOBA, JOBB could take control by removing the system-level environment variable. But note that the environment variable will persist if JOBA ends abnormally without removing it.

Other possibilities could be renaming the program objects temporarily or moving the program objects to a different library temporarily. In each, the rename or move would be undone at the end of program.

In short, anybody can call any program that they’re authorized to at any time. If the program shouldn’t run at that moment, it’s the program’s responsibility to end.

Tom

BAGray   0 pts.  |   Aug 31 2005  11:43AM GMT

PgmA could allocate itself at start and de-allocate itself at end. When PgmB is invoked, if PgmA is allocated, don’t go any further.

Hope this helps.
BAGray

TomLiotta   8025 pts.  |   Oct 31 2009  9:31AM GMT

Perhaps the biggest problem with trying to answer is that there is no indication why the two programs shouldn’t run concurrently. Consider that the reason might be, say, that PgmA will be performing some action on ObjectX and that PgmB would perform some conflicting action.

That is, it isn’t the “programs” that are the problem. It is the combination of actions plus ObjectX that make up the real problem.

The point is that all kinds of effort could be put into the control of PgmA and PgmB until they work exactly as desired. Then someday runs PgmA.

And somebody else executes CmdC against ObjectX that performs the same conflicting action that PgmB was locked out of. If the effort had gone into proper locking of ObjectX in the first place, then PgmB couldn’t run nor could CmdC be executed against ObjectX. Nor could any other potential program or command be run that interfered with PgmA.

The question is wrong to begin with. It doesn’t state the actual problem.

Tom