How to Keep Watch on Backup Completions
August 12, 2015
We've had a backup hang up on a bad DAT, and we learned about it when the morning jobs couldn't start on the 3000. (We shut everything down we can, back up, then open everything up again.) To find a better way to respond to this, I'm making a procedure to compare the expected backup duration (from a table we've built) to the backup's actual duration so far. The idea is to get an early report if the duration has been exceeded by more than an hour.
I've parsed the JOBLIST output to get what I wanted. But it looks like I'll need help on converting a string variable to a numeric variable as part of this procedure. Does MPE have anything like that?
Francois Desrochers replies with this ![...] construct, an undocumented part of MPE/iX:
While
SETVAR TONY STR(TONYALL,3,2)
would create a string variable, you could do something like:
SETVAR TONY ![STR(TONYALL,3,2)]
to create a numeric variable.
Stan Sieler replies:
We've done this for a customer who was without an HP 3000. We decided to use MPE/iX on our system to
- Restore their data onto our 3000
- Package up the files (either with tar, or LZW)
- Move them to an external disk drive on a Unix or Linux or Windows machine
- Unpack them
- Then send that external drive to the customer.
This morning I came in to find our backup job stalled. Abortjob was ineffective, as was abortio. I ended up rebooting the system. While coming up, I got a “defective sector” message with “FILE.GROUP.ACCOUNT has an extent with unreadable data.” The file is now locked, and I need to use FSCHECK to unlock it. How can I determine which drive this extent is on?
Stan Sieler replies
FSCHECK’s DISPLAYEXTENTS command may help. Note that, if I recall correctly, it displays logical unit numbers, not exactly LDEVs.
I'd like to make sure I get complete backups. Should I be using @.@.@ in my TurboSTORE command?
Gilles Schipper replies that backups don't need to be specified with an @.@.@ command to be complete:
People should really be using the forward slash, because it's easy to accidentally omit the Posix file structure if you're not careful constructing your fileset backup. The slash is so much better — a backup specified by HP's TurboStore will replace any @.@.@ operation with "./" Combining @.@.@ with exclusions can lead to omitting files which should have been in a backup.