Universe DICT modification time?

[James A]

We had an outage on one of our UniVerse servers (UV 10.1.20 on Linux
2.6.18 [CentOS]) this morning due to a lock on a DICT file; but none
of our production applications write DICT files; so it seemed strange
that there was a lock in the first place (clearing the lock restored
the system but only after many customer calls/complaints/etc).

I've found that simply OPENING a DICT file updates the modification
date; and there IS some kind of difference in the file but it's in the
header and it's not clear what's changing. I assume this is also
what's creating a lock but I can't see any in normal operation. (Also,
it seems that the modification time is not always updated immediately;
the change is cached somehow...)

Anyone have a clue to what's going on; and ideally how we can stop UV
from updating the DICT files (and creating locks) ?

- James

[Jeff K]

I know that you're talking about Universe, so this may not apply.

We had a situation with our Unidata installation recently that showed the same symptoms you're describing, which was eventually tracked down to a corrupted alternate index for the file.

Rebuilding the index from scratch (DELETE.INDEX {filename} ALL, followed by CREATE.INDEX and BUILD.INDEX) fixed our issue.

[Anthony Youngman]

On 03/04/12 22:24, James A wrote:
> We had an outage on one of our UniVerse servers (UV 10.1.20 on Linux
> 2.6.18 [CentOS]) this morning due to a lock on a DICT file; but none
> of our production applications write DICT files; so it seemed strange
> that there was a lock in the first place (clearing the lock restored
> the system but only after many customer calls/complaints/etc).

Do any of your reports use "LIST ... EVAL ..."?

You need write access to the dict to use EVAL, so that presumably means
UV actually writes to it as a temporary measure ...

Cheers,
Wol

[James A]

Thanks for the suggestion but I don't think this applies. For some files just a 'LIST.DICT' updates the DICT files last modification date (and presumably creates a lock). It seems very strange but we've mitigated the problem somewhat by sizing our DICT's bigger so the lock is less likely to block other threads. Not sure exactly why this helps but it seems to.

On Saturday, April 7, 2012 4:38:25 PM UTC-7, Wol wrote:

On 03/04/12 22:24, James A wrote:

> We had an outage on one of our UniVerse servers...

Do any of your reports use "LIST ... EVAL ..."?...

[Scott Ballinger]

If you list a file, UV sets group locks as you move through it. If you pause at the bottom of a page, the current group lock remains in effect. There is a UV parameter called PAK timeout (Press Any Key) that controls how long the group lock remains asserted under these circumstances.

/Scott Ballinger