There are a number of ways to tell the ADSM client what to do, how to
do it and where to put the results.  Yet installing (at least some)
ADSM clients is more difficult than it needs to be.

ADSM clients have command-line parameters, an options file and, on at
least some client platforms, environment variables.  Still other
settings may be made through the GUI interface.

Perhaps problems I've had are due to ignorance of the platform
facilities or some facet of ADSM, but I'd like to see progress in the
areas of ...

1. Control of where the Schedule and Error logs are written.  When I
installed the Windows client, the logs were dropped into the ADSM
directory, as expected, but on the OS/2 2.xx client the logs went
elsewhere (to the root directory ... and not even on the drive of
the ADSM software).  The rule of "least surprise" would tell me the
ADSM directory is a better default choice (directory of the DSM.OPT
file?).

2.  So I discovered the SCHEDLOGNAME statement in DSM.OPT and used it
to specify the schedule log file location.  It's one more manual
step, but the log goes where I think it should.

3. But the SCHEDLOGNAME (description) doesn't mention the error log.
So, I added the ERRORLOGNAME statement.  Bad move: there is no such
statement!

4. So, I discovered the SET DSM_LOG environment variable.  I *hate*
environment variables, but there is apparently no other way to
specify the location of the error file (OK, I don't know how to set
the "current directory" on OS/2).

5. Some users complained about having to enter the ADSM password on
every boot.  That's an easy fix, I thought, ... just add the PASSWORD
statement to the DSM.OPT file.  Oops, the OS/2 ADSM client doesn't
support that.  You must supply that as a command line parameter on
the scheduler invocation (and I suppose to the backup/restore icon
attributes somehow).

6. Auto-scheduled installation is much too difficult to set up on (at
least) OS/2 2.xx.  This is no doubt a platform specific problem and
probably an OS/2 TCP/IP problem, but something needs to be done so
that automatic scheduled backs may be performed with just a click on
an install screen.  Creating and/or editing TCPEXIT.CMD (in the
appropriate directory) to add

   "start /min c:\adsm\dsmc schedule"

(add -PASSWORD=MYPASSWORD, if you want)  is too much to ask!

(I also had to add a "bootp" to the OS/2 ADSM client TCPEXIT.CMD file
of *some* installs, but I'm not sure why!).

7. Execution from a file server is much too difficult to set up, at
least on some platforms.  How about platform dependent install
procedures to

   a. Install/re-install the ADSM client to a file server.

   b. Install ADSM scheduled backup for a workstation, given 7.a.

8. We shouldn't leave the area of installability without mentioning
re-installs and upgrades.  That an upgrade wipes out the current
DSM.OPT file (some? platforms) is outrageous, even if the install
does currently ask to rename it.

9. Upgrade of the Netware client seems to make the ADSM client forget
the Netware password.  The Netware administrator upgrades ADSM,
starts the NLM and goes home.  Sometime dfuring the night, a
scheduled backup starts up, only to stop in its tracks with the
userid/password prompt.  (And the prompt(s) are not at all clear, at
least to some my Netware administrators).

In case anyone thinks I don't like ADSM, they're wrong.  I like it a
lot ... it could be so much better.   What's important to you?

cheers,

Wayne T. Smith
Systems Group -- CAPS        internet: wts AT maine.maine DOT edu
University of Maine System   BITNET/CREN: WTS@MAINE