>IBM support have recommended to us to change the MIRRORWRITE LOG option
>in dsmserv.opt to sequential, rather than the default of parallel, as
>there have been reported instances of log file corruption where, by
>setting MIRRORWRITE LOG to sequential, the corruption could have been
>avoided. If this is true, why have IBM not told their customer base
>about this? Instead, they have created an extremely peeved customer.

The "Installing the Server..." manual alludes to this, under its
description of the MIRRORWrite option:

    Note: If a system outage occurs at exactly the instant that each
          mirror is partially complete in writing its page, a partial
          write to each mirror can result.

Allusion isn't enough, as you point out.  Full ramifications should be
discussed in the Admin Guide (including what happens during disk
malfunctions).  That manual now only says that the option exists and that you
should look in the "Installing the Server..." manual for info, which is wimpy
documentation.  I've tried to encourage customers to use "MIRRORWrite
Sequential", in several posts to ADSM-L (without trying to sound like a broken
record).  In my view, serious ADSM implementations should be doing mirroring,
and use of Sequential mode is the only sane approach.  Responses from some
customers have been that Sequential might hurt performance, so they stick with
Parallel.  Yet what's the point of mirroring if you implement it in jeopardy
mode??

I think your valuable contribution of your painful experience will help
convince others of what they are risking.  To everyone who hasn't implemented
these options: Don't wait for your own painful experience before doing so.

   Richard Sims, Boston University OIT