| Title: | *OLD* ALL-IN-1 (tm) Support Conference | 
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 | 
| Moderator: | IOSG::PYE | 
| Created: | Thu Jan 30 1992 | 
| Last Modified: | Tue Jan 23 1996 | 
| Last Successful Update: | Fri Jun 06 1997 | 
| Number of topics: | 4343 | 
| Total number of notes: | 18308 | 
    ALL-IN-1 v.3.0 VMS 5.5-1
    Note 787 is similar to this in that this machine is using a process 
    killer like Zap, but the user whose process caused the problem said
    that she was actually doing some cutting and pasting within 2020 and
    then her process hung (but this might be a slight digression from 
    the truth).  
    After this, once their captive users had logged out of ALL-IN-1, 
    they could not log back in again but received the error "Already 
    using ALL-IN-1, you cannot reenter".
    It was due to the fact that this user's process was waiting for an 
    EX lock for the DAF_D.  However, she had the same resource DAF_D 
    locked in EX mode.  Lots of other processes were in DELPEN state 
    and disconnected, all waiting for EX lock on this file.  Because 
    the process was in a DELPEN state, stop/id did not work and the 
    customer had to force a crash.
    Can anyone shed any light on why this happened - was it a RMS/
    wait problem with Zap?  I'll cross post this within the VMS notes 
    file too.
    Thanks
    julia
    UK CSC
 
| T.R | Title | User | Personal Name | Date | Lines | 
|---|---|---|---|---|---|
| 1777.1 | Sounds very familiar ... | AIMTEC::VOLLER_I | Gordon (T) Gopher for President | Fri Nov 13 1992 16:40 | 22 | 
|     Julia,
    
    	Sounds like you may well have the problem described in 787.8. Did
    	you analyze the system ? If you saw that the EX lock on 
    	the SDAF was granted in EXEC mode, the process  had an 
        EXEC mode AST active, was running in KERNEL mode and the stack 
    	contained the $DELPRC call then you can be reasonably sure that
    	this is exactly the same problem.
    
    	I don't have any knowledge of Zap but the way to fix this problem
    	generically is to increase the elapsed time before the process
    	killer issuing it's $FORCEX and it's $DELPRC. Better still advise
    	the customer to stop running it !!!
    
    	If the user really was active immediately before the hang then
    	either you have a different problem or there's something wrong
    	with Zap's selection criterior.
    
    Cheers,
    
    Iain.
    
 | |||||
| 1777.2 | Poor Frank | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Mon Nov 16 1992 20:27 | 9 | 
|     
    	Maybe ZAP was ZAPping the ALL-IN-1 main process, forgetting
    	that it had subprocesses? It would be fairly dumb, but I'll
    	believe anything...
    
    	Can you use the FORCE_WAIT workaround as suggested in 787.*?
    
    Regards,
    Paul
 | |||||