Re: SEPPUCLU bugcheck introducing new cluster node

Tom,

here is a little bit of information about the resource hash table
(RESHASHTBL) and how it's used for resource lookup. This information
could be used to judge the advice: just increase your RESHASHTBL
parameter to prevent this crash.

Whenever receiving a LOCK request (via the $ENQ system service),
OpenVMS has to decide, if this lock is for a NEW resource or for an
existing resource. To speed up this lookup operation, some fields in
the RSB are hashed to provide a 32-bit hash value (16 bits prior to
V7.1). The same hash algorithm is used on all nodes in a cluster, so
every node would calculate the same hash value for a given resource.
The hash value is store is the RSB - resource block (at RSB$L_HASHVAL).

When looking up a resource based on its hash value, the hash value is
shifted based on the local resource hash table size and used to index
into the local hash table starting at @LCK$GQ_HASHTBL (previously
LCK$GL_HASHTBL). Each quadword (previously longword) hash table entry
is a header for a chained list of resources (RSBs) - all with a hash
value pointing to the same hash chain header entry.

The hash chain is searched sequentially and each RSB found is checked
for a matching resource name, length, access mode, UIC group and parent
RSB. The hash chain is terminated with a zero forward link. The hash
chain header entry is zero, if there is no RSB in this hash chain.

The hashing algorithm is used to prevent a sequential search through
all possible resources. Only RSBs within the same hash chain have to be
searched sequentially. This is where RESHASHTBL size comes into play.
If the resource hash table is 'too small' for a given number of
resources, the individual number of RSBs in each hash chain may become
quite large and may delay the sequential scanning for a resource
lookup. If the RESHASHTBL is 'too large', it's just a waste of memory
(although 8 bytes per entry is not that much memory anymore these
days).

Here is how to look at the related data structures with SDA (example
from OpenVMS I64 V8.2):

$ ANAL/SYS or $ ANAL/CRASH dumpfile

SDA> READ SYSDEF ! read symbol definitions

SDA> SHOW RESOURCE
Resource Database
-----------------
RSB: FFFFFFFF.7E3A6440 GGMODE: NL Status: VALID
....
SDA> FORMAT FFFFFFFF.7E3A6440 ! format the whole RSB (resource block)

SDA> EXA FFFFFFFF.7E3A6440 + RSB$L_HASHVAL ! just examine hash value
for resource
RSB+00108: 0A000000.00048C04

Use above hash value to find hash chain header entry in local hash
table:

SDA> eva (00000000.00048C04@-(^d32-@lck$gl_htblcnt))*8
Hex = 00000000.00000048 Decimal = 72

SDA> exa @^qlck$gq_hashtbl+00000048
FFFFFFFF.7F7B2048: FFFFFFFF.7E3A6440 "@d:~...."

SDA> vali queue/singly/list/quad FFFFFFFF.7F7B2048

Entry Address Flink
----- ------- -----
Header FFFFFFFF.7F7B2048 FFFFFFFF.7E3A6440
1. FFFFFFFF.7E3A6440 00000000.00000000

Queue is zero-terminated, total of 1 element in the queue

The first entry in this hash chain is the RSB looked up above. There is
only one RSB in this hash chain, so a lookup for this resource would be
very fast.

If you are up to it, you could combine the whole operation in one SDA
command line ;-)

SDA> vali queue/singly/list/quad
@^qlck$gq_hashtbl+(00000000.00048C04@-(^d32-@lck$gl_htblcnt))*8


According to the OpenVMS programming Concepts Manual (chapter 7.2.9.3
Resource Hash Table), the size of the resource hash table should be
about 4 times the average number of resources used on the system (use $
MONITOR LOCK to find out). RESHASHTBL has AUTOGEN FEEDBACK attributes,
so an AUTOGEN with feedback should take care of the correct setting of
this parameter.

Volker.

.

Relevant Pages

  • Strong Name hash verification and linkresource
    ... The assembly loader does NOT appear to verify the hash of that linked resource image. ... However, if I change the image file, or hide it, the assembly loads and does ...
    (microsoft.public.dotnet.security)
  • Re: SEPPUCLU bugcheck introducing new cluster node
    ... lets first rule out the suspicion regarding LOCKIDTBL being too small. ... There was a known problem in V7.2-1 causing a LOCKMGRERR crash at ... OpenVMS takens to locate the resource after receiving the ... It uses the HASH value to locate the hash chain in the ...
    (comp.os.vms)
  • Re: SEPPUCLU bugcheck introducing new cluster node
    ... No, it's not a system service code, but a sequential error number for ... the identification of these LOCKMGRERR/SEPPUCLU errors. ... that the hash did not match. ... to remove an existing root resource. ...
    (comp.os.vms)
  • Re: Resource Files
    ... if the assembly that links the resource file is strong named it ... If the assembly is strong named then a hash is created ... public key are stored in the assembly. ...
    (microsoft.public.dotnet.general)