I hope that someone more "on top" of this will reply, but more than one of
these look like files that are not backed up for an appropriate reason.
Whether that is a good thing or a bad thing requires some evaluation. Which
of these have changed, say, since the last full backup?

I do not recognize /var/stm/logs/os/memlog, for instance, but if memlog is
to be taken at face value, it's a log. So, you probably want to close that
log and open a new one, immediately before your backup. I cannot imagine
/SYS/MPEXL/DUMPINFO being something you need, and I can't imagine
/SYS/PUB/JMATFILE (the job table, right?) doing you any good, as is.
/SYS/PUB/HP?ID@, aren't those group and user info? /SYS/PUB/DST@ are
probably related. I thought that /SYS/PUB/SL did go to SLT, but its been a
while since I have had occasion to look at this, and am probably wrong about
one or more of these.

When I wanted a clean-running STORE job, I used an indirect file, which,
among other things, excluded files that would not get backed up. I even had
logic within the job to create and use a temp copy, and append the LOG and
spool file names, so that no files should have failed to back up. So, if any
did, it was an incident that the operators had to address.

Of course, we also had to change our DRP, to properly recover certain files,
such as those used by our scheduling software, so that they would be
properly rebuilt or what have you, should the DRP have to be executed.

Greg Stigers
http://www.cgiusa.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *