× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Passing ownership of object locks?
  • From: "Walden Leverich" <walden@xxxxxxxxxxxxxxx>
  • Date: Thu, 4 Dec 1997 10:53:54 -0500

Stephen,

There have been several other good suggestions on alternative ways to ensure
that the new batch job gets the lock but if you are hell-bent on
transferring the lock, it IS possible. However the job that you want to
transfer the lock to must become active before the job that currently owns
the lock dies. To be more specific, in the process flow below you will
notice that the original job is in a deqw state until the new job starts, so
if the submitter is an interactive program you may want to submit the
submitted job to a queue that has *nomax for number of jobs to start.

Job         Process
A            Lock data area (*EXCL).
A            Submit job B
A            Issue dequeue instruction on user queue and wait (I'm not sure
if you can use a data queue here as you are moving space pointers.)
B            Job starts
B            Retrieve space pointer to this job's process control space
(matpratr instruction)
B            Issue enqueue instruction to put PCS pointer into queue
B            Issue dequeue instruction to wait for indication that lock has
been transferred
A            Wakes up from dequeue and has the target jobs PCS pointer.
A            Resolve space pointer to data area that you have locked.
A            Issue transfer lock instruction (xfrlock) to transfer lock into
target pcs - job A no longer has lock
A            Issue enqueue instruction to tell job B it's ok to proceed.
A            Die
B            Now has lock. Continue with processing.

That's it. Simple. You may be able to do this in ILERPG, I'm not sure if the
proceedure exports in QC2UTIL1 are usable in RPG. If not you could create an
ILEC program to export them, but they should be usable.

-Walden

PS. This is theory. I haven't actually run this process. :-)

-----Original Message-----
From: Stephen Hunt <deptit@harvestime.co.uk>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Date: Wednesday, December 03, 1997 11:22 AM
Subject: Passing ownership of object locks?


>Can I transfer the ownership of an object lock to another program ?
>
>The program I am working on does the following :-
>
> 1. Locks a data area (so no one elses can run this job).
> 2. Performs some data validation.
> 3. Submits another job to QBATCH to perform some processing.
> 4. Releases the data area lock.
>
>However, the lock on the data area needs to be maintained until the batch
>job has finished.  Even though the submitted job re-locks the data area,
>this action could be delayed if it gets queued up behind other jobs, and
>someone else could obtain the lock on the data area.
>
>Can anyone help or perhaps suggest a better method ?
>
>TIA
>
>Stephen Hunt
>Technical Systems Manager
>Harvestime Limited
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
>| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.