(I sent this on 10 July but never saw it on the mailing list, so I'm
sending it again.  Note that I've also discovered that this bug in
dsmc causes it to die whenever anyone logs on at the console.)

I'm running Digital Unix V4.0; I'm pretty sure I was also having this
problem with V3.2c.  The version number that dsmc spits out is

        Command Line Backup Client Interface - Version 2, Release 1, Level 0.3

I'm running the dsmc program in schedule mode; the line from the rc
file is

        ${ADSM_PROG} schedule -quiet &

(Where ADSM_PROG is previously defined to point to the dsmc
executable.)

The rc file that is starting it was named S95adsm.

The problem was that every time the system rebooted the dsmc process
wasn't started, although according to the "echo" lines in the rc file
it was.  Also, nothing was being recorded in either the sched.log or
dsmerror.log files.

I finally tracked it down.  When the system boots and runs all of the
various rc files, one of the files it runs is S90ws.  It contains


        #
        # Notify the configuration manager that multiuser has been reached.
        # Currently the graphics ws driver has a callback registered for
        # this point.
        #
        /sbin/sysconfig -r generic user_cfg_pt=45000 > /dev/null

For some reason this is what was preventing dsmc from running.  When I
renamed my rc file for adsm from S95adsm to S85adsm then I got the
usual lines in the sched.log file, but the ps command didn't show any
dsmc process running, so something (S90ws as I had suspected) had
caused dsmc to die.  (By renaming it to S85adsm that caused it to be
run before S90ws.)  When the rc scripts are run, they run with
standard input, standard output, and standard error attached to the
console; here's the line from /etc/inittab:

        s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1

Since this is on a workstation and my console is a video display (not
a terminal) I had this hunch that this S90ws was doing something to
the console which was causing dsmc problems (ws = workstation).
Renaming the adsm startup script to S85adsm confirmed my hunch.

I finally resorted to removing the S90ws script and now dsmc finally
stays running after the system is booted.  This is not a good fix
since what it does is disable the X window system; for me it's ok
because the system is used as a server.  Note also that when anyone
logs in on the console this also causes dsmc to die.

So my plea to the IBM engineers who maintain the Digital Unix
(formerly DEC OSF/1) adsm client is to add some way to close standard
input, standard output, and standard error when the client is running
as a unix daemon.  For example, add a -detach command-line option.
Here's the usual detaching code you see in unix daemon programs on BSD
systems:

        ndescriptors = getdtablesize();
        if (fork())
                exit(0);
        for (s = 0; s < ndescriptors; s++)
                (void) close(s);
        (void) open("/", O_RDONLY);
        (void) dup2(0, 1);
        (void) dup2(0, 2);
        tt = open("/dev/tty", O_RDWR);
        if (tt > 0) {
                ioctl(tt, TIOCNOTTY, (char *)0);
                (void) close(tt);
        }

On Digital Unix it looks like there's a routine in the libutil.a
library called "daemon" you can use that does the same thing.

If whoever supports the Digital Unix client doesn't read this list,
could someone from IBM please pass this on to them?  Thanks.