Re: Question on BRMS *SYSTEM Backup Control Group....

First thing: Check the DSPLOGBRM *BKU to ensure there were no problems.

That's run every day, and we filter through the report to show any errors. There's nothing there in either our weekly full system saves (as described) or our more granular dailies.

Second thing: Generate this report: STRRCYBRM OPTION(*SYSTEM)
ACTION(*REPORT)
Look at it to ensure that you have all you need to do a full system save.
I've started just enough of the system to physically print it off. If you know what you are doing you can override the spool file and use transformation services to create a pdf and download that instead.

We run that, and email it out for DR purposes, every day. On Sundays, it shows just the single tape from that morning's save as the sole tape needed. Every other day it shows Sunday's tape and the latest daily.

I've done several upgrades this way, following the BRMS recovery report.
Sure, there are those, even those who are familiar with BRMS, who still prefer to do a regular GO SAVE 21 for upgrades.
My thought is that if I cannot do an upgrade this way then my backups are worthless. It's one heck of an effective test.

Now, if you're doing a migration from 7.1 on a P5 to 7.3 on a P9 that get's a little more interesting.

We were moving from V7R1 (8202-E4D) to V7R3 (9009-41A).

The problem isn't what is or isn't on the tape. That appears to be complete. What happens is that users expect to restore V7R1 to a new box, then do either slip installs of V7R3 or other workarounds to get the system updated. Their steps fail because the restore commands use labels that are not on the BRMS created *SYSTEM save. I wish I had this better documented, but in the midst of an ERP upgrade I just threw it on the back burner and ran a full, manual system save.

That recovery report should also tell you if you are missing anything.

By BRMS standards, we aren't missing anything.