Possible to prevent program from being called if other program is active?

330 pts.
Tags:
AS/400
i5
iSeries
OS/400
RPG
Ray has two CL programs: PgmA and PgmB. He doesn't want users to call PgmB at a command line if PgmA is active and vice versa. Is there a way to handle this in a CL? Getting rid of the command line is not an option. Let Ray know if you have any suggestions. Michelle Davidson Editor Search400.com mdavidson@techtarget.com
ASKED: August 10, 2005  9:10 AM
UPDATED: October 31, 2009  9:31 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

“dholland” had this suggestion:

“Create a blank data area and allocate the object in Program A. Be sure to deallocate the object at the end of program A. In program B, try to allocate the data area. If unsuccessful, end program.”

Michelle Davidson
Editor
Search400.com
mdavidson@techtarget.com

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Byimw02
    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
    0 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • BAGray
    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
    0 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following