Re: Is job x running

[Tim Bronski <tim.bronski@xxxxxxxxx>]

I'm thinking mutexes are way too complex for the OP's purpose.
My favorite answer to "what's a mutex" comes from a stackoverflow 
response that you might enjoy:

> When I am having a big heated discussion at work, I use a rubber 
> chicken which I keep in my desk for just such occassions. The person 
> holding the chicken is the only person who is allowed to talk. If you 
> don't hold the chicken you cannot speak. You can only indicate that 
> you want the chicken and wait until you get it before you speak. Once 
> you have finished speaking, you can hand the chicken back to the 
> moderator who will hand it to the next person to speak. This ensures 
> that people do not speak over each other, and also have their own 
> space to talk.
>
> Replace Chicken with Mutex and person with thread and you basically 
> have the concept of a mutex.


On 11/20/2014 10:03 AM, D*B wrote:
> ... for a data warehouse load process, we've needed multiple 
> conditions, what could run together. We wrote a SRVPGM (not too 
> complcated) with following procedures
>
> getMutex(name, wait){
> if syncobj with name not exists create
> try to lock the syncobj with specified wait
> if not possible in time throw exception (send escape message via QMHSNDPM
> store locks in some array
> }
>
> releaseAll(){
>  free all locks
> }
>
> If you need more than one lock (we needed this for some sophisticated 
> schedules) be carefull with deadlocks. It's easier to avoid deadlocks, 
> than handling. simply define an order to get more than one: they have 
> to be sorted by alphabet. e.g. if someone has a lock to 'HUGO', he 
> could get 'MARTHA'. If he tries to get 'ADAM' throw an exception.
> We used a special lockfile and inserted a record with name as one 
> keyfield and held the lock using commitment controll to release all we 
> specified commit (so this must run in a named ACTGRP only used for 
> this SRVPGM. Advantage of this is, that you could see the sequence of 
> aquired locks in journal (if you use a FlipFlop mechanism :=  an int 
> column created with contents 1 multiplied by -1 for eych update).
> If you need more flexibility, to release only a single lock, still 
> holding others (releaseMutex(name)) , some lightweight syncobjects are 
> better.
>
> The QUSLOBJ and the write some info to a DTAARA/FILE I wouldn't 
> recommend. The first is not correct, if more than one is trying to run 
> at the same time, maybe none of them will win, worst case blocking 
> each other. The second is incorrect too, if a job dies you would have 
> to do some manual repair before it could run next time.
>
> Dieter