Jim writes:
> The method I had devised (but not implemented) would attempt to stream a
> job using the supplied Username and Password.  Then check HPCIERR to see
> if the job launched successfully.

Just for grins I tried to find a misuse of !JOB syntax that would allow
you to check the passwords without actually submitting a job.  In ten
minutes of playing around I was unable to find one.

I did find lots of reasons why !JOB is a really lousy way to check
passwords though :-)

The top problems are:

1) If the user has appropriate capabilities, the passwords passed to the
   !JOB command are ignored completely, and the job will always log on.
   This makes it look as though the passwords are valid when they are not.

2) If you fail to specify a password, or specify a null password, the
   :STREAM command will prompt you for each password three times.

3) All the jobs logging on and off causes lots of problems.  Logon/logoff
   is still a fairly intensive process, so there will be performance
   issues, and the job numbers will increase much faster than usual.
   Also the extra number of INVALID PASSWORD FOR... messages on the
   console might make it less likely that you'll notice an attempt to
   violate *MPE* security.

The first two restrictions could be gotten around by doing the check in
batch from a user without AM or SM capability, and which will never
be asked to check the user password for the user *it* is running as.
Otherwise it's not very useful.

From a security point of view, any facility that lets you quietly test
passwords for validity is a serious security hole, so there shouldn't
be any (non-privileged) way to do this that doesn't have a side-effect
such as the !JOB command's INVALID PASSWORD FOR... console messages.

So what you need is some privileged routine that quietly tests the
passwords for validity.  There may be something like this in MPE, but I
don't know about it.  One option is to go get the real passwords out
of the directory and do the compare yourself.  Code that does this
is probably available in the public domain somewhere (I've seen it
done several times).  Of course the user might have used SECCONF to
enable encrypted passwords, in which case even this won't do you any
good.

G.