Conference noted::hackers_v1

    The problem is we're taking a CICS based application generation
    facility, and shifting it to VAX. The resource locking strategy
    they use (their own) is holding resource locks across screen I/O.
    
    We do not wish to use 1 process per person for resouce reasons,
    and thus we wish to have serially re-useable server processes which
    asynch. terminal handlers can pass work to.  This means we cannot
    allocate 1 server to a user - has horrible effects on throughput
    on a TP system (which is what this will be).
    
    Hence we need to take out a lock in a server, and hold it while
    releasing the server process for another terminal user.  We can't
    then assume we'll re-appear within the same server to get the next
    item of work done.
    
    I guess we can have a single "lock manager" process on each machine
    which we communicate to via a global section to get locks, however
    I think this could prove to be a bottleneck on a heavily used system,
    hence the question about using VMS Lock Manager.
    
    Any and all ideas gratefully accepted
    
    Steve            

    	Since this is "hackers" check out :-
    
    LCK$M_CVTSYS	This flag is reserved to DIGITAL. When this
    			flag is set, the lock is converted from a
    			process-owned lock to a system-owned lock.
    			The calling process must be running in executive
    			or kernel mode to set this flag.
    (SYS-143)
    
    	When I looked at the code this seemed to be doing what you want. I
    would suggest that a user-written system service or a protected
    shareable image might be the right way to use it.
    
    	Or maybe I have misunderstood what you want?
    
    		Dave
    

    I'm still not sure I completely understand the problem.  Say we
    have Processes A (PID 2100000A), B (PID 2100000B), and C (PID 2100000C).

    Travel agent (TA) hits magic key combination that says "show me
    the Chicago>>Denver flights for March 4th".  This combination of
    keystrokes gets shipped off to Process C, because A and B are "busy".
    
    Process C observes input on an I/O channel and reads the request.
    C obtains a CR lock (on, say, "ORD-DEN-88.03.04") and then goes out to a
    file and gets the flight schedules and ships them off to the sender.
    Then C converts the lock to NL mode, copying a sequence number from
    the lock value block.  (Also specifying CVTSYS).
    
    The TA reads the list, gets a cup of coffee, thinks, and finally
    fills in a request for the 9:33 United flight.  TA hits ENTER and
    the request is stuffed down the pipe.  This time Process A is free,
    so A gets the filled-in request.
    
    At this point A does another $ENQ(PW) on "ORD-DEN-88.03.04" and reads
    the value block.  If the sequence number in the value block is the
    same, then by design no changes have been made to that resource.
    So (normal case) the reservation is made, the sequence number is
    bumped and the lock is converted to system, NL mode.  It makes no
    difference that C is used for part of the reservation and A another.
    
    If somebody else made a change to the resource while TA was looking
    at it on the screen, then the value block sequence number will be
    different and the application knows it has to go out and reread
    the "locked" block before trying to complete the reservation.
    
    Now what is it about the application methodology that is so different
    from this model?  Can you respond in specific terms?
    
      John

    The mechanisme John shows is one way. It has the possible
    disadvantage that the user goes through a certain effort
    to find out that is was all in vain when the time comes
    to update a record.
    
    An alternative could be:
    ENQ a lock using the recourcename. If it did not exist; fine. The
    resource is all yours. Put the identification of the user you are
    currenty serving in the value block. Convert to NL.
    If the lock did exist, check the value block, if it mentions the
    same user you intended to server then proceed. If an other user
    identification is found then you give an error message to the 
    current requestor. In either case convert to NL on receipt.
    Yes the lock will become owned by severs tempting to get it. So what.

    Possible refinement:
    
    	- Investigate the possibillity to use multiple lock levels to
    distiguish between first ENQ and subsequent ENQ for re-entries into
    severs.
    
    	- If you want to build in waiting on a lock; you will probably
    need a second lock; based on the terminal id:
    	1 ENQ to take out a lock on a resource. Convert to NL
    	2 ENQW to take out a lock on the user-id. Keep it.
    	If step 1 fails, ENQ with WAIT on user id and retry the 
    	resource lock when you get the user-id lock.
    	3 DEQ to Release resource lock, clearing the value block.
    	4 DEQ to Release user-id lock.
    Somehing like that anyway.
    
    Hey Rikki, It is precisely ACMS that has this problem!
    
    Hope this helps,
                    Hein.
    	
    
    

Use RMS.  Create an indexed file with the resource-id as the key,
a field to indicate whether the resource is locked, and (if necessary)
a list of waiting processes (who should be notified to "try again"
when the resource becomes unlocked).

BTW, it sounds like you're implicitly storing the fact that resources
are locked (how else would you know they need to be unlocked eventually?).