[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

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

1777.0. "Process hang problem" by KERNEL::SMITHERSJ (Living on the culinary edge....) Fri Nov 13 1992 13:37

    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.RTitleUserPersonal
Name
DateLines
1777.1Sounds very familiar ...AIMTEC::VOLLER_IGordon (T) Gopher for PresidentFri Nov 13 1992 19:4022
    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.2Poor FrankIOSG::TALLETTGimmee an Alpha colour notebook...Mon Nov 16 1992 23:279
    
    	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