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.