Well, we're planning to do this process some time in the near future and
from the discussions I've seen here so far, it's not something I'm looking
forward to. Since I don't feel the documentation in the ADSM Administrator's
Guide is adequate, I'd like to ask a few questions:

  1). Is there is more comprehensive planning information
      available which might help prevent some of the problems mentioned here?
      For example,
      I get nervous when I see the need for a 64meg virtual machine when
      were running all of VM in a 48meg LPAR. I see a real need to be able to
      estimate ahead of time:

      o How long the recommended WDSF audit takes
      o How long the DSSERV DBDUMP to tape takes
      o How long the DSMSERV DBCNVT from tape takes
      o What system resources (CPU, Memory) will be required for each step.

      Since it's necessary to take WDSF out of service when all this happens,
      (apparently for more than a few minutes)
      and since we bill customers for it (real $), it's extremely important
      to us that we do this right the first time and that the length of the
      service interruption be minimized and somewhat predictable.

  2). Is there a specific state the ADSM server must be in before I do
      the conversion? For example, am I allowed to have additional client
      nodes, non-default storage pools and policy domains defined, and must
      the default storage pools and domains be present at the time the
      conversion is done?

  3). What will happen if ADSM tries to convert data for
      a client node that is already defined? Administrators?
      We have a test ADSM server up and running completely independently
      of our production WDSF system. We are using it quite heavily
      already for testing new clients and features, updating operator
      tools, familiarization, etc. Will we have to throw all the set-up
      effort away and start from scratch to do the conversion? What, if
      anything, can we safely keep, and what must we discard?

  4). One thing which bothers me about the conversion process is the reuse
      of the WDSF repository disks. This strikes me as inviting trouble
      and ought to be avoided. In environments (like ours) where there
      is enough disk to run two separate WDSF and ADSM servers, it occurs
      to me that one could do the following:

      o On the WDSF server, delete all the DISK repository volumes with the
 RECLAIM
      option. When all have been deleted, all the data will be on tape, and
 there
      won't be any repository disk to convert. You can then delete the WDSF
      disk repository level as well.

      o In the event that the conversion doesn't work, you restore things to
 their
      previous state by redefining the repository level and volumes. Presumably,
      they are still formatted properly. Although they won't have any data
      on them, you've still got an operational WDSF server set up the same as
      when you started. The only difference is that data which was on disk
      is now on tape. I think this is an acceptable tradeoff, given the apparent
      ease with which you can back out if the conversion process fails.

      I'd appreciate it if people could comment on the viability of this
      approach. I'm most concerned about whether the conversion utility
      could handle the situation where no repository disks are defined, and,
      of course, for other show stoppers I haven't forseen.

Thanks to all.