AS400 backups using BRMS running over allocated time

30 pts.
AS/400 backup
iSeries 520
Good Day. I am sys admin for a Iseries 520 9406 System ASP . . . . . . . : 773.0 G % system ASP used . . . : 55.0899 Total aux stg . . . . . : 773.0 G I am using Brms to do my backups initially i was doing a full sys save everyday to a LT03 tape 400g compressed 800 uncompressed, due to business changes i have now changed my backups to Daily incremental backups. __________ Group . . . . . . . . . . : DAILYA Default activity . . . . : IIIIIII Text . . . . . . . . . . : NEW BACKUPS ON LTO4 DRIVE MON TO THU Backup Seq Items Exit command 10 *LOAD 20 *EXIT CALL PGM(AUTOMATION/BRMSBKUDAT) 30 *ALLUSR 40 *ALLDLO 50 *LINK 60 *SAVSECDTA 70 *SAVCFG 80 *EXIT STRSBS SBSD(QSYSWRK) 90 *EXIT CALL QSTRUP 100 *EXIT STRTCP Group . . . . . . . . . . : DAILYA Default activity . . . . : IIIIIII Text . . . . . . . . . . : NEW BACKUPS ON LTO4 DRIVE MON TO THU Backup Seq Items Exit command 110 *EXIT CALL PGM(AUTOMATION/STRFAX) 120 *EXIT SBMJOB CMD(CALL PGM(AUTOMATION/DAILYUP)) JOBD(PKDG 130 *EXIT CALL PGM(AUTOMATION/PRTJOBLOG) 140 *EXIT SBMJOB CMD(CALL PGM(AUTOLIVE/BRMSMAINT)) JOB(BRMSM 150 *EXIT DSPLOGBRM PERIOD((210000)) OUTPUT(*PRINT) however i am facing a new challenge for some or other reason *savsecdta is now backing up for more then three hours pushing over my backup times. if anyone can suggest something ill greatly appreciate it. Thank you.-

Answer Wiki

Thanks. We'll let you know when a new response is added.

I think you are saying that your daily is running long because of the *avsecdta portion. First I would suggest that save security data isn’t necessary more than once a week during your full save unless you have a huge turnover, but if you think you have to have it, do savsecdta to a savefile outside of your backups then let the backups save the save file daily. You may get a few lockups but they should be of short duration and cause little problem.


SAVSECDTA and SAVCFG are two parts of SAVSYS that not only should be done daily but that can also be done to savefiles without needing restricted state. The rest of SAVSYS can generally be ignored daily and handled whenever you do full-system saves. (Other times SAVSYS would be done would be before and after significant changes such as cume or group PTFs or upgrades. If your system is very static, with very few new objects being created, then the two saves are less important daily. Don’t forget about IFS objects.)

However, if SAVSECDTA is running for extended periods, then you should examine how your application authorities are being assigned. In particular, review how private authorities are assigned. Private authorities should be kept to a minimum.

One way to find potential problem profiles is to run PRTPRFINT SELECT(*PCTFULL). You might specify percent-full first at a low level, say 1.00% or maybe 3.00%. Normally, I wouldn’t expect many profiles to be selected; but you might have a couple extreme cases. If the listed number of profiles is too high to make sense of, then specify a higher percentage threshold. Review the profiles with the highest numbers first.

Or you might review all user profiles to see how big they are. Use DSPOBJD *ALL *USRPRF to list the user profiles. If you have few profiles, listing to a display might be good enough. Or you can send results to an outfile. If you use SQL, you can order the outfile rows descending in size by column ODOBSZ. You can probably ignore any Q* profiles. Look at the largest of your profiles with PRTPRFINT SELECT(*USRPRF).

You said you were doing “full sys save”. I <i>assume</i> that that means “full system save” rather than “full SAVSYS”. Those are two very different saves.

With a “full system save”, there is no good way to avoid the integrated SAVSECDTA. You would need to customize the QMNSAVE CL program from QSYS after using RTVCLSRC if you wanted to OMIT(*SECDTA) from your daily saves. As noted above, though, you can run SAVSECDTA outside of your backup window and include a resulting savefile in the remainder of the “full system save”.

Be aware that that would leave authorities and ownerships slightly out of sync for objects that changed between the two save operations. Perhaps that’s only a minor inconvenience for you.

But you’re running under BRMS, so the QMNSAVE route’s probably irrelevant anyway. You could at least drop *SAVSECDTA from the BRMS list by breaking it out. Unfortunately, you’d probably need to run any separate SAVSECDTA at least a couple hours before your BRMS process started.


Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    Please describe (1) how many *AUTLs are used in your applications, (2) how many objects are on those *AUTLs, (3) how many user profiles are on those *AUTLs and (4) how many user profiles have private authorities to application objects. A 3-hour SAVSECDTA would indicate higher numbers of authorities that must be captured and saved. In order to capture accurately, there may be large numbers of locks that must be established in order to have all profiles and objects in sync at a given point in time. Getting a mental picture of possible webs of authorities is a starting place to look. It might not provide an answer, but it should help narrow the possibilities. Note that I'm not asking about actual numbers of *AUTLs, profiles or objects. I'm only indicating that research into those numbers might get you going in a direction. Tom
    125,585 pointsBadges:
  • TomLiotta
    BTW, is the BRMS "*LINK" item intended for IFS "links"? Tom
    125,585 pointsBadges:
  • pdraebel
    I have had similar issues with backup, BRMS and SAVSECDTA. Private authorities were the main cause of the Lengthy SAVSECDTA. IFS private authorities turned out to be the big issue. So review the PRTPRFINT *PCTFULL report. Track the authorities on objects and try to reorganise any private authorities into authority settings with Authorisation Lists
    7,545 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: