My company is using D3/linux (D3 Release Version 7.2.0.LINUX)
and a couple of times we have gotten a "phantom lock".
No locks are shown under LIST-LOCKS and 'CLEAR-LOCKS' does not fix the
problem. The only way to clear it seems to be to reboot the system.

:COUNT PARTS "beeping starts"
:EBUG

I lk.fail:0ED
unable to lock group: 1202766 for retrieval


Has anyone else run into it ? Fix ?

Thanks, John

Check the indexes on that file, are there any called basic subroutines?
If you try to re-read the same item you are processing within a BASIC
proggie in an index, you'll run into that error.

hth

There are three kinds of locks: Update, retreival and group.

Update locks just mean you can't update an item. You can read it or select
it, but you can't write it.

Group locks means you can't read anything in the group. Someone is changing
something in the group: update in place, flagging an item as deleted, moved,
"stolen", etc. You can scan the group, but you can't change it.

Retreival locks mean the group is being "pulled up": an item was deleted and
the data inside the group is physically changing. You can't even scan the
group because you'll probably encounter the other processes "pullup" and see
it as a GFE.

How baddly sized is the file in question?

And, finally, once you've hit the debugger, what's the WHERE status of the
port? Where did it come from before LK.FAIL?

Mark Brown


"John Skinkle" <jrskinkle (AT) yahoo (DOT) com> wrote

Thanks for the replies.

This file has no indexes.
Size 10 meg, modulo 6011, about every 4th frame overflows.

Will have to check the where status next time.

Thanks, John

Hi Mark,

The 'phantom' is back.


0005 000725 BF90 000018 T lk.fail:188 lk.ret.lock:072
TV.GEN.GROUP.LIST:223
TV.GEN.GROUP.LIST:076
tv.next.group:095 tv.ver.item:21E
TV.RD.ACCOUNT:185 TV.TVERIFY:2E8

This is during the VERIFY after a full file save. This file had not
been written to since the file save was started. The file averages 6
items per group for an average of 900 bytes per groups.

Thanks in Advance, John

Thanks, Rob

2 indexes on this file
A0(G0*1):"*":2
A0(G0*1)


13481 Items in total
modulo of 2511

Just a guess, but it looks like the t-verify is locking itself out somehow.

Because T-Verify works against a live system, it has to play some games with
the data it finds and the data it's looking for. It makes a list of the
items in the group on the tape, then the group in the file on disk, then
compares to two lists, so the file can't change underneath it.

Short term suggestion: change the t-verify to t-verify (fnT so that it only
verifies that the data on tape is readable and not against the data on disk.
It will be much faster and, if this is in fact a live system, changes are
you would get errors anyway, because an item that's changed since the save
passed by will look like an error to t-v.

Mark


"John Skinkle" <jrskinkle (AT) yahoo (DOT) com> wrote