170 pts.
 Serialization: Mutexes vs. Semaphores
I am looking for a way to serialize access to a RPGĀ program across multiple jobs. I have been doing some research on mutexes and semaphores and I am wondering what the advantages/disadvantages of each are. Also if there are any other ways to accomplish this. Thanks in advance for your reply

Software/Hardware used:
ASKED: August 19, 2009  1:22 PM
UPDATED: October 12, 2009  4:49 AM

Answer Wiki:
Hi, You can take a look to this link. http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzahw/rzahwsynco.htm The title is "Synchronization techniques among threads" Regards, Wilson
Last Wiki Answer Submitted:  August 20, 2009  2:16 pm  by  Sloopy   2,195 pts.
All Answer Wiki Contributors:  Sloopy   2,195 pts.
To see all answers submitted to the Answer Wiki: View Answer History.


Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


 

could you amplify

‘serialise access across jobs’

- you intend several jobs to use a single program?
- you need several jobs to share something concurrently?

 5,505 pts.

 

I have several different job flows that call the same program. I want to limit access to this program to one job at a time. So only one job will ever be running this program at any given time.

 170 pts.

 

There is an old-fashioned method for restricting a program to a single caller at a time, which I am giving you here because it’s quick to implement and needs no expertise beyond ‘normal’ programming knowledge – I hope that someone else can come up with the mutex and semaphore methods. I would love to try them!

In the *INZSR of the RPG program, write a loop to lock a data area:

C DoU not *In91
C *Lock In PGNAME 91
C EndDo

At the end of the program (when *INLR is set on before returning to the caller), unlock the data area:

C Out PGNAME

(In this example, the data area is assumed to have the same name as the program, which is reasonable.)

The first job to call the program will get the lock. Subsequent callers will stick in the loop, waiting for the time determined by the class of the object (I think it’s 60 seconds for a data area) in each run through the loop.

When the first job leaves the program it unlocks the data area and the next job to start a *LOCK IN operation on the data area will get it.

There is no ‘proper’ serialisation here, in that you can’t guarantee that the second caller will get the next call, the third the call after that and so on. It’s first lock, first served.

Regards,

Sloopy

 2,195 pts.

 

Hi,

Scott Klement wrote a good article about semaphore uses here:

http://systeminetwork.com/article/get-synch-semaphore-sets

Regards,
Wilson

 2,385 pts.

 

In general, if you want only one job at a time to run a program, just have the program place an exclusive lock on itself when it starts and release the lock when it finishes. For ILE RPG, the *PSDS contains the object name of the program and the library it’s running out of.

ALCOBJ     OBJ(( mylib/thispgm *PGM *EXCL)) WAIT(60)

…do program logic here…

DLCOBJ     OBJ(( mylib/thispgm *PGM *EXCL))

But usually it’s not the program that should be “serialized”; rather, resources used by the program need to be protected. Place locks on the appropriate resources and it doesn’t matter how many jobs are running the program.

Further, without placing locks on the resources, a second program can do the same processing as the program being “serialized”. That totally defeats the intention making it pointless.

Tom

 108,225 pts.