I recently added feature to a very busy system I support which uses
callx to trace changes to the major data files and then records the
program, user, date, data changes etc.
Works great except that today for the 2nd time since I activated this,
d3 has frozen while processing data.
The frozen port would not respond to a break char.
where z shows something like clx which leads me to believe it's hung in
the callx subroutine and list-locks shows a group lock.
Clearing the group lock doesn't help.
To lessen the chance of this happening I put a limit on how much of the
data it compares when looking for changes b/c the design of this is to
spend as little time in this routine as possible. Both times it locked
it was on a record which has at least one very large mv'd field. I just
compare at the attribute level but capture the attribute to my trace
file and in process I convert the value marks and subvalue marks to
other chars so I can store the changes efficiently.
Hopefully my changes will keep this from happening again.

But still I am concerned about why this happens and would like to
understand what's going on so I can design this if possible to avoid
these group lock hangups.
What happens in d3 to cause a group lock to hang up like this and stay
locked?
Also, is my design faulty in that I use the same subroutine to handle
many different files. Is it having trouble trying to load the same
program into memory so many times? Does it lock a group when it loads a
program?

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

I'll need a little more than "something like clx" in the where.

It SHOULD be in br.CALL or one of the BR runtime modes; also, if it's hung
because of locks, it should be lkitemfail or a similar mode.

When UPDITM wites an item into a file, before the item is actually written,
it checks the file control block and if it finds a CALLX correlative, it
will set up the "english control block" which makes basic thnik it's been
called from a basic subroutine, then it executes the same command Pick Basic
does when it calls a sub.

Mark Brown

Yeah that sounds right. Unfortunately I didn't note what it was and am
going from memory. I think br.cat and br.bas might also have been shown.
I guess my question boils down to whether or not I'm doing something
here that I shouldn't. The first freeze was harmless but the second
resulted in a partially posted check so I really don't want to see this
happen again. I'm not sure it failed due to a lock but just that I
noticed the group lock from the frozen port. I know lkitemfail was not
shown. It was a looping of two br. modes. If it does happen again I'll
make sure I note the modes.
Thanks


Mark Brown wrote:

It IS possible to get what we used to call "deadly embrase" where a process
locks itself out. Strictly as an example, let's say your callx has to
update the group the item that's being updated is in.

During the update of the item (upditm), it does a retix to find the item if
it exists and set some registers. It accesses the file control block to see
if this item is to be logged or triggers a call. The system probably locks
the updating item's group so it can't change while the CALLX is being done,
which would invalidate its register pointers.

If the callx tries to update that same group, it will be locked out by the
higher level process.

Mark Brown

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