First of all I would query who is using QSECOFR and why it is being disabled regularly (I presume it is, as you want to scan for the message on a daily basis).
As QSECOFR is the ultimate profile on the 400, I would strongly recommend you restrict it’s usage.
However, if for whatever reason you need to use it regularly and it is becoming frequently disabled, I would not go to the effort of writing a pgm, I would simply use a scheduler (IBM supplied, Robot, etc) to perform a CHGUSRPRF QSECOFR *ENABLED on a pre-defined basis.
If QSECOFR is not disabled, nothing will change but if it is…..!!!
Automatic re-enablement of <b>any</b> profile other than perhaps a designated GUEST profile with strong controls is a seriously risky process. Any auditor who saw such a process should order it shut down immediately. Why have a disabling process if it’s simply going to be automatically re-enabled?
Any re-enablement should wrapped in an appropriate challenge/response proc.
Further, for QSECOFR in particular, there is no point to it. It <i>should</i> be disabled and it should stay that way most of the time.
I agree with the above comments as to investigating why QSECOFR is being Disabled,
But another option is to use Management Central, Message Monitors. You can set this up to monitor for the CPF message in Qsysopr and it will execute a trigger program that could Enable the Qsecofr Profile.
Hope this helps,