I have a report that builds a work file by passing through a large number of
invoices.
The build program pauses and beeps often due to group locks.
I am not doing any record locks.
Is there anyway to suppress this behaviour of d3 or at least make it
quieter?

The most likely cause of this is either more than one port accessing any of
the files you are using, or more likely that the files you are dealing with
are under-sized.

Use ISTAT filename to look at how big the files are and how well sized they
are. Do this before purging your work file. You can use the resize verb to
increase the size file without having to do a restore.

hth

Dale

"bob" <bgf66 (AT) comcast (DOT) net> wrote

Hi Bob
Locks cause the beeps.

You can see the locks with the LIST-LOCKS command and clear all or one
with the CLEAR-LOCKS command.

Better to not cause the problem at all by always coding a LOCKED branch
in every READ statement. Yeah, I know its 3 extra lines of code, but
here is the right way to do that.

ONFILE = 1
READ ITEM FROM FILENAME,ID LOCKED
LOCK.USER = OCONV(SYSTEM(30),"TPIBS;X;;7") ;** D3 style
LOCK.USER.NAME = OCONV(LOCK.USER,"TUSERS;X;;1")
ERR.MSG = LOCK.USER.NAME:" has ":ID:" locked up, please try later."
CRT ERR.MSG ;** whoever you like to do that
END ELSE
ONFILE = 0
END

D3 offers you the user ID of the User who has the item locked which
allows the users to solve their own problem, without having to call
you.

- Alan Gruskoff
performantsystems.com

Alan,

Would not the READ have to be a READU, MATREADU, or READVU in order to
invoke the LOCKED clause?

See <http://www.weaver-consulting.com/tip012.htm>

Dave Weaver, Weaver Consulting

The OP refers to "Group" locks...

I'm no expert on D3, but I thought that most MV variants had moved to Record
locking rather than group locking.

I do seem to recall in the depths of my memory, that a group lock
effectively locked that complete group for *all* reads and writes (though my
memory could be mistaken). I seem to remember "problems" caused by
READU'ing one item from a file, and then before writing back, READing
another record from the same frame (normally caused by 1 frame files with
lots of overflow!).. This would cause a deadly handshake...

It may just have been a bug in the OS (we used Mentor at the time - and I'm
thinking mid-1980's here!) but I'm sure we used to be very careful to avoid
this sort of behaviour.

Having said that, on jBASE with record locks, you can't lock yourself at
all. It will allow you to READU the same record twice without complaint (I
think it's controllable by an environment variable).

Either way, the OP problem sounds strange... READ's should always pass
because no record lock is being taken. Sounds like a bug, either in D3 or
possibly his program is actually doing a READU somewhere else in the code???

Regards
Simon
"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

I may be wrong, in which case hopefully Mark or Tony will correct me,
but I think that both D3 and UV set a group lock before every write, and
probably before every read as well, to insure the stability of the group
being read. On UV, this can cause a heavily overflowed group to remain
locked if a retreiVe statement pauses for a page break in the middle of
a group - there is actually a uvconfig parameter to set the timeout for
this (the default is, like 1/2 hour).

On some of my busy D3 systems, this causes large batch processes to
sometimes "beep" occasionally (sometimes even frequently) even though
all the readu statements use a locked clause and the files are
reasonably sized. I assumed this was because there is some size
limitation on the group lock table. I have never noticed this
batch-beeping-syndrome on UV.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Simon Verona wrote:

The transaction loggers sets locks constantly. The beeping is very annoying.

"Scott Ballinger" <scott (AT) paretoTIRED-OF-SPAM (DOT) net> wrote

Scott,

Nice to see you haven't washed away yet. What is it now, 32 days of rain?
You guys are going for the biblical record, right?

IIRC, there are three kinds of locks placed on the group at various times:
Group lock, Update Lock and Retrieval Lock. Which it sets depends on what
it's doing at the time.

Group lock says the group is being changed: updated, added to or deleted
from.

Update lock says you can't read or write the item because the group is in
the process of being changed and there could be a "temporary" GFE if you
were to scan to group in its current condition. EG, while a group is being
"pulled up" (more below).

Retrieval Lock means the group is being changed "in place", so you can read
but you can't write.

With a "traditional" file structure and update routine, items are selected
in physical sequence (Select filename; or internal select statement) and
then processed. As they are updated, they are removed from the group, the
end of the group is pulled up and then the new item is added to the end of
the group. If you're doing that a lot, in a file you query regularly,
eventually you'll hit this condition.

It's the reader that's doing the beeping, not the locker. If there's no
READU then there's probably an update lock somewhere.

Mark

"Scott Ballinger" <scott (AT) paretoTIRED-OF-SPAM (DOT) net> wrote

Hi Mark,

Acutally the RECORD hereabouts was 32 days of rain, but we had no rain
sometime last week, so our run for the record stopped at 25 days. (That
was no rain "technically", which means it didn't rain at the airport
[the "official" weather station of record for Seattle], but it did
certainly rain in some parts of the city that day.) Last few days have
been sunny though... mucho snow in the mountains, I have been skiing
every weekend this year with 2-3 feet of new each time.

/Scott

If you are using workfiles and you create them or clear them, your
problem can be on the FOF. Take a look at the size of the FOF.
If you need to resize the FOF there are some techs notes in order to do
it.

A good practice is to do a little mantain to the FOF frequently. You
have many examples from Tony and others. Find out in google groups (FOF
comp.databases.pick).

Hope this help
joseba