> often.  He is concerned that these files will be backed up once and then
> never be touched again.  If something should happen to one or more of them,
> he wouldn't know until he needed to do a restore.  He would like to be
> able to force ADSM to backup all the files periodically, similar to the
> full pack dumps we do on the mainframe.

If a file is never modified (ie, remains the only active copy),
the ADSM backup facility retains the file forever, or until a
delete is issued by the user or an administrator.  This is unlike
the archive facility, which can quietly allow files to expire
without notice.

> basis.  However, I would rather have a more automated way to handle it.
> Another way would be to have two different copy groups, one for incremental
> dumps and one for absolute.  Then have two different DSM.OPT files that would
> control which server files were backed up with which group.  Finally, I
> have thought about simply deleting the filespace, which ought to force a
> full dump of the server.

Combine the two -- use the central scheduling features to
initiate the regular scheduled backups, and periodically schedule
a backup job specifying a different management class in the
schedule definition. You'll have to keep all the schedules
straight manually, but it would accomplish the task.

Another word about scheduling -- supplying a list of domains or
ALL-LOCAL in the Central Scheduling menu is completely ignored by
all the clients, or treated as an error in the case of ALL-LOCAL.
I've opened an APAR on this; will post the number tomorrow. Not
quite there yet, I'm afraid.

Is anyone else concerned that there doesn't seem to be a
way to have a default backup schedule for all nodes? You can
define a schedule and include all nodes present at the time of
schedule definition by specifying '*', but nodes added after the
schedule is defined are notautomatically added to the schedule.

(BTW -- word to the wise. If you're converting from WDSF and have
a significant number of files stored in WDSF, allow a *lot* of
time to reload the database. We had roughly 3.5 million catalog entries
stored in WDSF and it took more than 14 clock hours to reload the
catalog data into ADSM. Yow. I intend to APAR this one as well --
careful data handling is one thing, but this thing is *paranoid*.)