Consultor Eletrônico

Record Scoping and subprocedures: What to consider

Subject: Record Locking and Scoping

Here is a simplified example of a common issue with how long locks are held.

/* prog1.p */

FIND FIRST customer NO-LOCK.
RUN prog2.p.

/* prog2.p */

FIND FIRST customer EXCLUSIVE-LOCK.
UPDATE customer.
RELEASE customer.
FIND FIRST customer NO-LOCK.

EXCLUSIVE-LOCK starts a transaction.
So prog2.p is part of the transaction block.
The record scope is the whole of prog1.p and
therefore encompasses prog2.p.

In this above example you might expect RELEASE to
release the customer buffer record. However, when
you compile these procedures Progress uses
separate buffers for each program. On running
them as subprocedures Progress realizes you may
well want to use this customer record in prog1.p,
i.e., display it on returning to prog1.p.
Progress dictates that you must then see the
changes you have performed in prog2.p. The
customer record scope implies that you will
want to use that record. Therefore it cannot
release the record buffer, so the release is
not having the effect you would expect.
So the shared lock is not released by the
RELEASE and rereading NO-LOCK. When all this
code is in a single program there is only one
buffer, hence the RELEASE works as in the
example given in the Programming Handbook manual.

This is Progress's default way of working.
If this is not the result you require, the
way to override Progress's default is to
strong scope the first find as below:

/* prog1.p */

DO FOR customer:
FIND FIRST customer NO-LOCK.
END.

RUN prog2.p.

Prog2.p no longer needs a release statement and
to reread the record NO-LOCK. So prog2.p now looks like this:

/* prog2.p */

FIND FIRST customer EXCLUSIVE-LOCK.
UPDATE customer.

The share lock will now be released on
returning to the first program.

This is a very simple scenario. Depending where you
want the locks released you may need to consider where
your transactions begin and end.

Progress Software Technical Support Note # 11847