My site has an assortment of Unix and Windows NT clients connected to an ADSM
server running under MVS, including one SCO system. The client software on the
SCO system was installed in mid-April, and was running daily backups without
incident until last night. Last night the backup session started, sent summary
messages indicating that only one file had been inspected, and ended. There
was an ANR2579E reporting that the scheduled event had failed with a return
code of 4. This was just before the ANR0403I message reporting the end of the
session. Two more client sessions started and ended in rapid succession. Each
of these ended with messages ANR0444W and ANR0484W. The first of these
reportted that a SignOff verb had been received out of sequence. The second
reported that the session had terminated due to a protocol error. When I
logged on to the client system I discovered that the ADSM scheduler process
was no longer running. terminated with server error messages indicating that a
SignOff verb had been received and last night the scheduler process
terminated. I did not find any relevant messages in dsmsched.log or
dsmerror.log. I have since restarted the scheduler process and run a backup
successfully under the control of the central scheduler, but I have no idea
what happened last night, and no assurance that it won't happen again. Does
anyone have suggestions for getting to the bottom of this?

In the course of investigating the problem I discovered three oddities in the
location and attributes of the ADSM files.

The "Installing the Clients" manual states that ADSM files are placed in
/usr/adsm when the client software is installed on a SCO system. I found the
files in /opt/K/IBM/adsmclient/3.1.0.6, with symbolic links to them in
/usr/adsm.

All of the ADSM binaries have change dates of November 18, 1999 (for the
benefit of those fetching this message from the ADSM archive, let me note that
I am posting this on June 1, 1999). Other files, such as dsmameng.txt, appear
to have correct change dates.

The dsmtca binary does not have the SUID bit set. This makes it impossible for
non-root users to use ADSM.

As far as I can tell, all three oddities date back to the original
installation of the software. Are some of all of these oddities normal for SCO
systems? If not, how do I go about fixing them.