Conference noted::hackers

    re .0
                     
    Assuming that it is conceptually the same as $GETJPI...
    
>still, there does not appear to be enough context information for the 
>system to operate reliably.  
    
    I would guess that $GETLKI can distinguish the following three states
    of the value in lkidadr
    
    * start new scan (0 or -1)
    
    * scan in progress (some kind of context always distinguishable from a
    			valid or potentially valid lock id)
    
    * a non-wildcard request (a potentially valid lock id)

    The context would have to be represented in a way that guarantees it
    does not look like a lock id but allows the scan to resume at the
    correct point.
    
>how does the operation get to the next lock on the next call in a loop?
    
    from the context in lkidadr
    
>    so i have to initialize it outside the loop
    
    Definitely. It must be initialized and it must not be initialized
    inside the loop.
    
>    , and not reinit it in the loop. ok, that is just a simple doc omission.
    
    So you would be raising a DOC QAR, right?
    
>      but what does the service store in the lock id field to help the next
>    time?
    
    Don't know.
    
    I think *$GETJPI* uses the negation of the process index of the last
    process returned as the context. (It has to be able to distinguish
    process scan contexts as well but that's another story.)
    
    Note that a context pointing at a (potential) process is distinguishable
    from the id of that process.
    
    $GETLKI may do something similar.

>that one might be gone by the time the next call happens.
    
    True. But it doesn't matter because it is probably not using the lockid
    itself.
    
>so perhaps there is some context information saved internally.
    
    I don't believe that $GETLKI supports this (so your remaining questions
    are not applicable).
    
    $GETJPI with $PROCESS_SCAN and $GETQUI both do have internal context.
    
    In the case of $GETJPI you call $PROCESS_SCAN first outside the loop in
    order to create the context. In the case of $GETQUI, the service manages
    the context itself (causing lots of confusion for young players).

    Re: .0
    
    Do you need a pointer to the relevant OpenVMS source listing files ?
    
    John. :)

re .2

>                        -< isn't hypothesizing fun! :) >-
    
    yeah, I didn't have time either to check sources or write a program.
    It's easier to speculate...

I could not read the sources, when I posted the base note.
I should have apologized in advance there.  Anyway, .1 is right.
The lock id is positive, being an index and a sequence number.
The context that is maintained is negative and includes the index
and some flags.

No, I did not try it.  I was writing the code when the possibility of a
problem hit me.  I looked at some locks, and it appeared to be a
dense set.  Then I looked in internals and data structures.
The word "index" is there in the description, but it did not register.
Instead, I misread the sentence as advancing from one lock id to the next.
So, I paniced and asked. 
After a brief look at the code this morning, the operation is clear.

Again, my apologies.  Next time, I'll wait for the sources to come back.

>still, there does not appear to be enough context information for the 
>system to operate reliably.  
    
    Even with perfect conext this cannot work reliably.  The lockmunger can
    be changing literally hundereds of thousands of lockstates per second
    and so all you will get is a 'smear' across the lock state (sort of
    like doing a backup/ignore=interlock).
    
    So unless you *know* that the locks you are interested in are quiescent
    you'll get an approximation.
    
    (as to the internals of the locmanager, I'll leave that to others, it's
    like CLENUP.B32, I try to keep clear of it)