Hello Tom,
many thanks for the interesting link.
I believe, the intention of enforced periodically password-changes is to counteract situations, that when the password is known by an authorized person, and this person leaves the company, or an unauthorized person gets knowledge of the known password, etc .... isn't it?
When the job-statements in your JCL in Endevor
(1) do neither specify USER= nor PASSWORD=,
--> then the user of the batchjob is inherited from the submitting user, who is subject to expiring passwords.
(2) specifiy only USER=batchusr and no PASSWORD=
--> then the submitting user needs to be permitted to ACID(batchusr) and does not need to know the password of 'batchusr', and the batchjob executes unter security of batchusr
(3) specify both USER=batchusr and PASSWORD=batchpwd in clear text
--> you have an security exposure, because everybody who is allowed to read this JCL gets knowledge of the password of that userid which then might be used also in other contexts.
(4) specify "softly" both USER=&batchusr& and PASSWORD=&batchpwd& and those placeholders are replaced by the submitter (for example the job-scheduler) from an encrypted source.
--> you have a centralized place (the encrypted source) where the passwords are to be maintained by a security person in power.
If you are working with option (2) - specify USER= but not PASSWORD= - nobody needs to know the password and a randomized password can be set once and can be changed at any time again.
Maybe this fact, that nobody has to know the randomized password, satisfies the need resp. intention of your security team.
Kind regards,
Josef