I basically agree with those in the ADSM community who seek better
documentation.  We so often have to repeatedly go back and pore over
the manuals to make sense of various elements and interconnections.
    After consideration, though, I think the true problem is the
excessive complexity of ADSM.  Attempting to define a structured hierarchy
in ADSM is an experience which feels like filling out federal tax forms:
you have to gather all these little pieces of information together and
then try to figure out where they go on all the right forms, all the while
trying to make sure you don't overlook one.  (That ADSM also has an AUDIT
command lends to this feeling.)  This is all much more complex than it
needs to be.  IBM has needlessly aggravated this situation in departing
from structural discipline when adding things, the worst affront being
HSM, where its governing parameters where haphazardly thrown under MGMTCLASS
rather than find a consistent place in the hierarchy.  (There should, for
example, be a "migration copy group" to be consistent with archive and
backup, rather than create a MIGDESTINATION keyword within MGMTCLASS.)
    Just as the comprehensive information in the tax code doesn't help
render your taxes any more comprehensible, I don't think that concentrating
on ADSM documentation is the answer in making ADSM more comprehensible.
The solution, I believe, is for IBM to take a serious look at restructuring
ADSM to eliminate the needless complexity and make dealing with it easier
for both customers and the vendor.  Beyond that there should clearly be
better development management happening in IBM to assure that augmentations
like HSM are properly integrated rather than being scabbed on, aggravating
the administration task.
            Richard Sims, Boston University OIT