It's usually a good practice to keep passwords fresh. A 3000 development manager once posed a question about how to do this while staying inside the bounds of MPE/iX. He had the usual limited budget associated with HP 3000 ownership.
"Management wants users to be forced to change their passwords on a regular basis. Also, certain rules must be applied to the new password. I don't have budget for the good tools for this, like Security/3000, so I need to write something myself, or see if there's any contributed code to do the job."
Homegrown and bundled solutions followed. When Jeff Vance worked in the 3000 lab at HP, he offered the pseudo random password generator as a solution. It's in the HP Migrations webpage hosted on the website of the company formerly known as Speedware. These HP Jazz solutions that used to be on the HP website are still available at Fresche Solutions.
There are UDCs on Jazz which force a password to be supplied when using NEWUSER, NEWACCT and NEWGROUP CI commands. These required passwords can be random (uses the script above) or user entered with a minimal length enforced.
Then Vance added as an afterthought, a strategy to program your own password system:
I haven’t thought about it much, but it seems you could have a password file (maybe a CIRcular file?) for each user on the system. This file would have their last N passwords, and the modified date of the file would be the date their password was most recently changed.
A logon UDC could detect if the password file for that user exists. If not create it and require a new password right then. If the password file exists then get it’s modified date and compare that to today’s date. If greater than X days then in a loop prompt for a new password. Validate the entered password against previous N passwords and your other rules. Maybe run a dictionary checking program to make sure the password is not common, etc.
Update the user-specific password file with their new password, and then logon the user.
From the user community, Donna Hofmeister weighed in with this advice:
If you have no choice other than to develop your own software, then I’d certainly model it after what VEsoft has already done. That is:
Based on a system-wide UDC, examine all sessions (it is just sessions, yes? By the way, a DSLOGON from inside a job is still a session....) against a ‘database’ (By the way, just how secure is this database? A real database needs passwords... Who’s going to maintain that? A flat file could be lockworded... but that’s not a slamdunk answer.) which is looking for the ‘age’ of the password (By the way, are you going to provide an advance warning period?).
If it is time to change the password, get the ‘new’ password from the user... but writing the rules is a pain, and keeping track of reused passwords is just annoying. Auditors in the states love when you can say the password is one-way encrypted. Dunno what your management is saying for encrypting an MPE password.
It ought to be possible to do everything for free, using just MPE. Editing the new password is the ugly part, but if you randomly assign it that issue goes away. The next issue is that the :password command seems to like to be purely interactive, as in:
echo oldpass >> tempf
echo newpass >> tempf
echo newpass >> tempf
:password < tempf
Command not allowed in noninteractive environment. (CIERR 2500)
PASSWORD WAS NOT CHANGED.
That leaves the altuser cmd, which needs AM cap. If you don't want a background job (like Paul's suggestion), you can have the command file (called by your logon UDC) use the echo command to build job with AM cap, which it then streams, kind of like (untested, but I have working examples of cmd-files building other jobs):
ECHO !!JOB ACCTMGR/PASS.SOMEACCT; HIPRI >> TF
ECHO !!ALTUSER !HPUSER;PASS=!NEW_PASS >> TF
ECHO !!SETVAR STREAMED_BY WORD(HPSTREAMEDBY,"()",2) >> TF
ECHO !!TELL !!STREAMED_BY Your new password is !NEW_PASS >> TF
ECHO !!EOJ >> TF
ECHO Please note your new password when it appears
PAUSE 99; JOB = !HPLASTJOB
PURGE TF, TEMP
If I haven't screwed up the fine print too badly, this code in the middle of the password cmd-file runs the job that changes your password, then waits for the job to tell you what the new password is. The single exclamations before HPUSER & NEW_PASS mean that values that are variables to the session and command-file become hard-wired values for the job.
Before all this your cmd-file checks the date, gets a random password, etc., as posted by others. After it the cmd-file writes (or just builds) a file that serves as a timestamp. But I am not too comfy with putting the passwords into a plain-text file, so I might skip that part (remember, the user needs both read and write access to it). Put the command file in a group that users have xeq access to, but not read/write access.