| 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
| |||||