As we continue to setup our development environment, SECURITY / 3000
expired an account manager password, under which most job streams run
(not a good idea for a lot of reasons). So we run into yet another
classic MPE issue: what do we do about passwords in job streams? I am
foremost concerned with good security: let people do their jobs without
getting in their way, and present anyone else with a brick wall. I see
three possibilities, and welcome feedback, both constructive and
critical.

First is to make the most of MPE capabilities. MPE does prompt for
passwords on job streams; if there was a time when this wasn't the case,
that time was before my time. However, this both decreases security, and
can rapidly become a pain, since start-up & Operations Support will both
be streaming jobs within non-sys accounts. Some of the more routine
account-level jobs could still have embedded passwords. The only scheme
I have come up with is, in each account, have a password protected
userid with out IA access, homed to a password protected group
containing the job streams, and put an ACD on the job streams. So,
almost no one can access the job streams, except as allowed by the ACD.
But, this is a lot of maintenance, changing expired passwords in the
jobs is still a chore (time to learn sed, awk, & perl!), and is a rather
obscure solution, requiring copious documentation and some training.
This is the idea for which I am most interested in getting feedback,
both pro and con.

Or we could use VeSoft's STREAMX. We are after all using SECURITY/3000
and liking it. I appreciate that STREAMX has some intelligence about not
prompting for passwords depending on who is doing the streaming,
although someone somewhere will leave a session unattended, so that
makes me a little nervous. But this would be a fundamental change to
what Operations / Support is used to, so the jury is still out on that.
And I cannot get over my prejudice against third-party software
utilities that extend the OS.

Or, we could use the facilities of job schedulers to handle passwords.
Two players all but insisted on NSD's JobTime on the production box, and
we are looking at Carl Kemp's MasterOp on development. Either one look
like they handle those passwords nicely. But this means really
understanding both schedulers and maintaining these capabilities on both
3Ks, as well as more learning and documentation. And, this only handles
production and 'model' systems. It does very little for us in
development.

Or, we could use any of pair of the above, or even all three. That would
probably increase security, and it would increase the complexity, and
need for documentation and training. That in turn could let us either so
complicate things that we can't do our work, or let us get stupid and
leave some gaping hole in our security.