On Wed, 22 Feb 1995 14:44:09 EST, I said, in part...
> 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.

    I just installed the Windows V1R2L6 client and am very happy to
    report that the DSM.OPT file is now left intact, but if it
    doesn't exist, a new DSM.OPT file is created from DSM.SMP.  Nice
    job, IBM.

While I have your attention, I'll relay a few comments I have about
the Windows install just completed:

  there's still no ERRORLOGNAME statement in DSM.OPT. :(

  My existing DSMSCHED.LOG and DSMERROR.LOG were destroyed by
    the installation program.  :(

  The ADSM client version/level information is still not written
    to the DSMSCHED.LOG.  :(

  The installation program dutifully renamed all the old ADSM
    files to ?.BAK.  Thanks for the thought, but why do I need them?
    I don't! They're just stealing disk space.  There's nothing
    valuable here. Throw them out!  At the least, throw them out by
    default and give a check-off to specify saving old files if it's important
    to someone.

  The install ends by suggesting registration, but details are sketchy.
     Do you really want people to call someone each time they upgrade?

  An ADSM program group is nicely created/updated for the ADSM
    client "things".  Why not go the extra step and add the
    scheduler to the start-up group, if the installer wants you to?
    Maybe the scheduler should be started at end of install, if the
    installer wants you to?

  Lest I forget, thanks for the new SCHEDLOGRetention and
    ERRORLOGRetention statements.   Great help for controling
    ever-growing logs!  :)

cheers,

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