Copyright 1989-2016 by Kevin G. Barkes

All rights reserved. This article may be duplicated or
redistributed provided no alterations of any kind are
made to this file.

This edition of DCL Dialogue is sponsored by Networking
Dynamics, developers and marketers of productivity software
for OpenVMS systems. Contact our website
www.networkingdynamics.com to download free demos of
our software and see how you will save time, money and
raise productivity! Be sure to mention DCL Dialogue!



DCL DIALOGUE

Originally published February, 1989


Of Wizards and Daemons

By Kevin G. Barkes


The first time I was told I should install a daemon process
on my VAX, I was somewhat taken aback. "I already have
enough demons lurking out there," I told my good-intentioned
advisor. "They're called users."

What my knowledgeable friend meant, of course, was that I
should consider  creating detached processes on the system
to independently monitor specific  operations and provide
warning messages when certain events occurred. 

What's In A Name?

As I noted in a previous article in our sister publication,
The VAX Professional (August, 1987), computer science
relies heavily on Greek mythology for its terminology. The
word mnemonic, for example, is taken from Mnemosyne, the
goddess of memory. 

According to legend, daemons were secondary Greek
divinities, ranking between gods and men, who frequently
acted as guardian spirits. The daemons which stalk computer
systems act similarly, insuring that various events occur as 
planned or warning against potentially dangerous situations.

While they sometimes exist as batch jobs, most VAX daemons
are detached processes, created by running LOGINOUT.EXE, the
system login image.

Spawning a Daemon

There are several advantages to running daemons as detached
processes instead of batch jobs. Batch daemons can be
interfered with or killed by manipulating the queue
manager; detached daemons, created by a privileged user, are 
relatively immune to such meddling.

Full information on detached process creation using the
system login image is available by reviewing the RUN
(process) documentation in the DCL Dictionary. For our
purposes, it's sufficient to review the basic DCL
incantation necessary for daemon spawning:

$ RUN SYS$SYSTEM:LOGINOUT.EXE -
  /INPUT = INPUTFILE.COM -
  /OUTPUT = OUTPUTFILE.LOG -
  /ERROR = ERRORLOG.LOG -
  /PROCESS_NAME = "OTTO" -
  /DETACHED

The command runs the system login image, which creates a
process named "OTTO" running under the control of the
command interpreter (DCL). The various qualifiers determine
where the process should obtain input and direct output, 
the name of the daemon, and specify that it should exist as
an independent entity (the /DETACHED qualifier). 

In order to use /DETACHED, you must have DETACH privilege.
Otherwise, the process is created as a subprocess of the
invoking process and disappears when the parent process
logs out. /NODETACHED is the default creation method, 
unless you've used the /UIC qualifier. /UIC=[n,n] causes
LOGINOUT to create a detached process with the specified
user identification code. The new process has the
privileges and quotas of the process which created it. 

How To Use A Daemon

It's best not to be over-ambitious when determining what
your daemon should monitor. Remember that DCL isn't
particularly efficient in a lot of areas. Your all-purpose
daemon which is watching a dozen or so items might be 
protecting your system by making it difficult for other
processes to get sufficient CPU time to do anything. Make
certain that any "permanent" daemons you create are
efficiently designed and flawless in execution.

Transient daemons, those intended for use over a short
period of time, are probably better examples of the utility
of detached processes.

Program 1 was whipped together in five minutes to keep an
eye on a VAX which had developed a cranky disk controller.
The procedure was used as the input to a daemon which
scanned the disks every half-minute to determine if new
errors had been accumulated. A common variation of this
daemon is one which monitors remaining available disk space
and issues a warning if the number of free blocks on any
one disk drops below a certain threshold level.

Program 2 was developed by a manager who wanted to know when
a certain user logged in to the system. The "built-in"
security methods (ACL alarms, etc.) were not useful since
the individual being watched had security privilege and 
would have noticed his login had set off an alarm. A similar
daemon can be used to monitor dial-in lines on a system. By
watching to see if a dial-in port has been allocated, the
daemon can alert the appropriate persons when someone has
logged in over a modem or has allocated a port for dial-out
use (a Kermit session, for example). Using a daemon to
watch a port eliminates the more customary methodology of
including such code in a login command file or a dial-out
script, both of which can be circumvented by a determined
user. 

Before you begin spawning daemons with wild abandon,
remember the necessary safety measures. Make certain the
command procedure your daemon will execute is as
bulletproof as possible. Give the daemon just the privileges
necessary to perform its function; nothing is more
frightening than an out-of-control detached process
consuming system resources with wild abandon. And use 
restraint when spawning daemons; each detached process uses
a process slot which could otherwise be utilized by an
interactive user or batch job. A system with 20 daemons
might be safe, if only because no one can log into it.

******

POSITIVE IDs:

When writing to us, make certain you place your return
address on your letter, not just on the envelope. Envelopes
and letters are frequently separated during handling,
making it virtually impossible to respond. If you've sent in 
a letter or procedure and are puzzled by a lack of response,
the odds are you've neglected to include your return
address. Drop us another line and we'll be certain to get
back to you.


----------

Kevin G. Barkes is an independent consultant. He publishes
the KGB Report newsletter, operates the www.kgbreport.com website,
lurks on comp.os.vms, and can be reached at kgbarkes@gmail.com.
*********************


PROGRAM 1
$!
$       DEVICE_NAME1 := DUA0:
$       DEVICE_NAME2 := DUA1:
$       DEVICE_NAME3 := DUA2:
$       DE_1OLD = 0
$       DE_2OLD = 0
$       DE_3OLD = 0
$ LOOP:
$       DE_1NEW = F$GETDVI(DEVICE_NAME1,"ERRCNT")
$       DE_2NEW = F$GETDVI(DEVICE_NAME2,"ERRCNT")
$       DE_3NEW = F$GETDVI(DEVICE_NAME3,"ERRCNT")
$       DE_1TOTAL = DE_1NEW - DE_1OLD
$       DE_2TOTAL = DE_2NEW - DE_2OLD
$       DE_3TOTAL = DE_3NEW - DE_3OLD
$       IF DE_1TOTAL .GT. 0 THEN REPLY/BELL/URGENT -
        /USER=USERNAME "''DEVICE_NAME1' HAS ''DE_1TOTAL' NEW ERRORS."
$       DE_1OLD = DE_1NEW
$       IF DE_2TOTAL .GT. 0 THEN REPLY/BELL/URGENT -
        /USER=USERNAME "''DEVICE_NAME2' HAS ''DE_2TOTAL' NEW ERRORS."
$       DE_2OLD = DE_2NEW
$       IF DE_3TOTAL .GT. 0 THEN REPLY/BELL/URGENT -
        /USER=USERNAME "''DEVICE_NAME3' HAS ''DE_3TOTAL' NEW ERRORS."
$       DE_3OLD = DE_3NEW
$       WAIT 00:00:30
$       GOTO LOOP
$       EXIT



PROGRAM 2
$!
$ TOP:
$       SHOW USER SUSPECT
$       IF $SEVERITY .NE. 1 THEN GOTO WAIT
$       REPLY/URGENT/BELL/USER=MANAGER "SUSPECT IS LOGGED ON."
$       EXIT
$ WAIT:
$       WAIT 00:00:30
$       GOTO TOP
$ EXIT