FILE LOCKING IN QTP (long)

[Arthur Kogan]

Hi Paul,

there are basically 2 strategies available when running QTP.

1. Lock all files used for the duration of the run. This is the default and
ensures that the critical job runs without any interference (and does not crash
or otherwise fail due to interference). In addition consider that a job may
involve a number of dependent QTP/QUIZ programs where you do not want any
updates during the whole of the run, as may be in the case of running the
weekly payroll job. This option allows read access to files, but not update.

2. You can modify the QTP behavior using "lock", "commit" etc... statements so
that the locks are more localized. This allows updates while the job is
running, but creates risks of crashing or other failure for your critical job.

In your situation, I would consider the protection of the critical job to be of
primary importance. Now you also say that apart from about 2 files, other apps
only open files for reading. I suggest the following strategy. For the screens
which open the files for update, create a "READ ONLY" copy. Let the critical
job set some sort of flag (e.g. create a flag file, or set a field in a common
system control file) when it starts and remove it when finished. Let the other
application check for this flag and if it is set, use the "READ ONLY" version
of the screens, giving the user an appropriate message.

I have used this technique on a number of occasions.

I hope this is helpful.

Arthur Kogan.
Westpac Financial Services
Sydney, Australia.

Pablo Grim wrote:

> Hello,
>
> I've been reading the QTP (vms) reference manual trying to figure out file
> locking without much success.  A number of terms are either not defined or
> ambiguously defined.
>
> My situation is this:  We have a 'central' application (payroll/HR) with a
> number of spinoff ancilliary applications that have read and write access
> to the files in payroll.  When payroll is processing, we generally lockout
> the ancilliary apps to prevent the payroll qtps from crashing due to file
> locking conflicts.  My customers would like the ability to leave the
> ancilliary apps open during payroll processing.  Our QTPs contain the
> statement SET LOCK RECORD UPDATE, and usually multiple SET FILE X OPEN
> UPDATE SHARE.  READ SHARE, UPDATE SEMIEXCLUSIVE etc.  Rarely if ever an
> EXCLUSIVE open.
>
> Our ancilliary apps open most files as REFERENCE files in Quick, usually
> with an explicit OPEN READ.   There are one or two files that are opened in
> Quick for update.  Ancilliary batch file access is not an issue here (just
> interactive).
>
> Here's where I am confused:  What does the SET LOCK RECORD UPDATE actually
> do?  The manual says, "locks a file for concurrent write".  Does this apply
> to every file in the run?  Is the lock exclusive?  Does the lock apply to
> all files or just output files?  What is meant by 'concurrent write'?
>
> Also, how does this statement work with the SET FILE X OPEN UPDATE SHARE
> type of statements?  Does it overide it?  Or visa versa?
>
> What i would like to happen is to have everything shareable or at least
> semi-exclusive so that QTPs and QUICK can access the same files at the same
> time.  QTP should lock files during update, but only for the duration of
> the update.
>
> many thanks
>
> paul  (OVMS, RMS, PH6.20)
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.



= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.