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

Conference share::zap

Title:Zap Technical Conference
Notice:ZAP Version 5.3 is available. See note 1.1
Moderator:ZAPDEV::MACONI
Created:Mon Feb 24 1986
Last Modified:Mon May 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:170
Total number of notes:492

158.0. "Zapping... but not quite...." by PAKORA::TCROOKSTON (It's always August under your armpits...) Fri Feb 03 1995 10:57

Hi

Anyone got any ideas why ZAP (V5.3) should behave as follows:

When running one particular image on our system ZAP doesn't seem 
to be able to get rid of it. The proper warning messages come up 
on the screen at the right times, but then after the time limit
it simply starts counting time again i.e. putting the first
warning up again, and never actually kills the process.

I have been through all the documentation and tried everything
I could think of, there is nothing in the exception file to
cause such a problem.

Thanks in advance for your help
Tommy.
T.RTitleUserPersonal
Name
DateLines
158.1Check the history fileZAPDEV::MACONIThe Doctor is InTue Feb 07 1995 17:3833
Hi,

	The history file can be used to determine what was done to the
process.  Make sure that your configuration has it enabled (ZAP$CONFIG) and,
if not, enable it and restart the monitor.  After the process has been
"zapped", search the history file for the PID or USERNAME of the process.
The action will be listed as either STOP, EXIT or USERxxx.

	Once the action is taken, ZAP automatically clears the record from
its database and the countdown starts again.  Here are some of the possible
problems:

	STOP:  A $DELPRC was issued, but the process can not be terminated.
		(A $ STOP PROC/ID= will also fail).  This means that the
		process is probably in a resource wait state (RWxxx).  A
		system reload may be required to clear the problem.

	EXIT:  A $FORCEX was issued, but the process was either unable or
		unwilling to exit.  Remember that processes that are "exited"
		are only returned to the DCL prompt if they are interactive.
		Interactive users should be STOPped.

	USERxxx:  A separate process was created that ran a user written
		procedure to kill the process.  Check the log file for the
		procedure.  It will be located in ZAP$DIR:

	In addition, try generating a report before the process is killed.
This will indicate the exact rule being used to narrow down what is going on.
This can be done with:  $ DEFINE/SYS/EXEC ZAP$RUN_STATUS REPORT

	I hope this helps,

				Keith Maconi
158.2PAKORA::TCROOKSTONIt's always August under your armpits...Fri Feb 17 1995 04:3557
Hello again

Thanks for the reply Keith. I looked again at what was happening and in fact
I am not even getting an entry in the history file for the offending 
processes.

The user is getting the ZAP warning messages on their screen but it never 
clears the process away and doesn't log that it even tried. 

Below is an entry from the report file of a typical process that 'wont' be zapped,
followed by what is in our exception file. Any other ideas?

Thanks 
Tommy.




2F414223 � Stuart1 ?  SACAMPBELL [00130,000022] LTA7852:  Lat  0  13  0  00000000  17  30 CMT001


Rule Node   Username     UIC            Image Name                              Process   Terminal From  Until
Warn Limit Action
---- ------ ------------ -------------- --------------------------------------- --------- -------- ----- -----
---- ----- -------
   0 *      *            [00001,*     ] *                                       Detach    *        00:00 23:59  N 
    *  STOP
   1 *      SYSTEM       [    *,*     ] *                                       Remote    *        00:00 23:59  Y 
   15  STOP
   2 *      *            [    *,*     ] *                                       Batch     *        00:00 23:59  N 
    *  STOP
   3 *      *            [00001,*     ] *                                       All       *        00:00 23:59  Y 
    *  STOP
   4 *      *            [    *,*     ] *                                       Detach    *        00:00 23:59  Y 
    *  STOP
   5 *      *            [    *,*     ] *                                       Network   *        00:00 23:59  Y 
    *  STOP
   6 *      *            [    *,*     ] DECW$SESSION                            All       *        00:00 23:59  Y 
    *  STOP
   7 *      *            [    *,*     ] VUE$MASTER                              All       *        00:00 23:59  Y 
    *  STOP
   8 *      *            [    *,*     ] DECW$MWM                                All       *        00:00 23:59  Y 
    *  STOP
   9 *      *            [    *,*     ] SYS$COMMON:[SYSEXE]DECW$SESSION         All       *        00:00 23:59  Y 
    *  STOP
  10 *      *            [    *,*     ] SYS$COMMON:[SYSEXE]VUE$MASTER           All       *        00:00 23:59  Y 
    *  LOG
  11 *      *            [    *,*     ] SYS$COMMON:[SYSEXE]DECW$MWM             All       *        00:00 23:59  Y 
    *  LOG
  12 *      *            [    *,*     ] *                                       Remote    *        00:00 23:59  Y 
   30  STOP
  13 *      *            [    *,*     ] *                                       All       *        00:00 23:59  Y 
   30  STOP
  14 *      *            [    *,*     ] *                                       All       *        00:00 23:59  N 
    *  STOP

158.3Looks like it is working ok, but needs a little tuning...ZAPDEV::MACONIThe Doctor is InFri Feb 17 1995 18:0635
Hi,

	When looking at your exception file, rules # 9,10 & 11 are not
required.  ZAP removes all device and directory specifications when comparing
image names.  That means that these entries will never match any process.
Entries 6,7 & 8 take care of this.

	In addition, rule 14 can never be reached, as rule 13 is a global
rule (* or ALL specified for all catagories).  This entry can be removed also.

	When looking at the process, I see that it is using the correct
rule (# 13), so ZAP is looking at it properly.  The next question is does
this image, CMT001, do anything periodically?  Is it always the same image?

	To check, try adding a new rule (before your global rule) which has
the following items:

		Image:		CMT001
		Idle limit:	10
		Action:		LOG

	This will cause ZAP to log the process if it is idle for 10 or more
minutes into the log file WHEN it becomes either active or logs out.  This
means that you will be able to track the moment when ZAP thinks it becomes
active.  If this is on a regular basis, could it be that the application has
some type of automatic update/save routine it runs periodically?  Does it
update a menu with a new date or time?

	If some small amount of work is done periodically, perhaps the
sensitivity of ZAP could be increased.  Caution should be used as this may
affect other applications negatively, though.

	Hope this helps some. 

				Keith Maconi