I decided to go ahead and try this command:

EXPORT NODE DOMAIN=87P FILEDATA=BACKUPACTIVE DEVCLASS=CARTRIDGE -
SCRATCH=NO VOLUMENAMES=A12787,-
...

"87P" is the domain that includes the 72 nodes that are in the
building where the server and tape robot are.

I had a few false starts:

1.  Once, when an expiration process ran shortly after I had started
    the EXPORT, the EXPORT failed with this message:

      ANR0655W EXPORT NODE: Retrieve or restore failed - file was deleted
      from storage during retrieval.

    I am told that this problem is fixed (though I thought I had all of
    ADSM very current).  Since I was exporting only the active files, I
    don't see why an expiration would have this effect.  (There were no
    clients doing backups at the time.)

2.  The next two attempts failed because two of the tapes I had included
    in the output pool had previously been used for DUMP DB tapes:

      ANR5366E 088: Volume A12785 dataset name "ADSM.DMP" in HDR1 label
               cannot be overwritten with Export dataset name "ADSM.EXP".

    As far as I can see, there is no way to override this; one must
    relabel the tapes.  The server's action when this occurs is not
    very bright; it keeps trying to mount the same tape over and over
    until one cancels the export process.

3.  The next attempt failed after 23.5 hours because I had not specified
    enough output tapes.  (A prompt for more tapes would have been very
    welcome at that point.)

4.  The next attempt succeeded after 27.5 hours:

      ANR0617I EXPORT NODE: Processing completed successfully.
      ANR0626I EXPORT NODE: Copied 72 node definition(s).
      ANR0627I EXPORT NODE: Copied 153 file space(s), 0 archive file(s)
               and 529821 backup file(s).
      ANR0630I EXPORT NODE: Copied 12001830 kilobytes of data.

    The process wrote 56 output cartridges and mounted 183 cartridges
    for input.

I haven't tried importing anything from these tapes, so it may be a bit
premature to say that the export was successful, but at least it ended
normally.  There were a few oddities along the way:

1.  DSMSERV used all of one of our 3090's six processors for the entire
    27.5 hours, except for when it was waiting for a tape mount.  Every
    phase of the process was CPU-constrained:  the sort, dumping from
    disk to tape, copying from tape to tape, and cleaning up the
    database at the end.

2.  The sort took "only" three hours, so fixing the sort problem would
    not be enough to make EXPORT really usable.

3.  The last hour was spent purging the database pages that had been
    used in the sort.  In the case where the EXPORT failed because it
    ran out of tapes, the purging went on for an hour after the process
    terminated; in the successful case, the purging went on for an hour
    before the termination messages.  During this hour, DSMSERV's CPU
    use was 95+ percent of a processor, but there was no other sign that
    it was doing anything (unless one queried the pages in use in the
    database and noticed that that number was going down).

3.  DSMSERV held the first output tape all the time it was doing the
    sort.  It held the last input tape and the last output tape while
    it was purging the database pages.

4.  DSMSERV deactivated two of my tape exit machines for reasons that are
    not clear to me.

So, my conclusion is that EXPORT NODE is (border-line) usable for monthly
offsite backups.  I've given up on the idea of weekly offsites.  I'll
choose weekends when the machine isn't being taken down for maintenance
on Sunday mornings, and I may split the load across two servers so I can
throw two of the six processors at the problem.

Melinda Varian
Princeton University