RE: i5 Security info and training

Only one of our developers has a second account that has a high level of
security. And he pretty much reserves it only for helping us run Mimix.
I kept hearing this whining "but what about that emergency middle of the
night call that needs it?". Situation is, it hasn't happened in over 10
years. Sure, there have been late calls, but none, zippo, that just had
to have qsecofr type access.

Honestly, it used to frustrate me to no end that vendors required qsecofr
to install their product. I guess it just works.
OTOH, keep your guard up. We had a vendor that had a program with qsecofr
adopted authority. One line: CALL QCMD. Apparently it was their back
door to talk users through some stuff remotely without having to file a
100 page exception report with the customers security officer on why they
needed qsecofr.
We no longer do business with them.

I sincerely believe that many vendors really tried to get their installs
working as other than QSECOFR, but after this failure, and that failure,
just gave up.
Some of their installs I wonder how they ever get through them.
Hopefully in this age of virtualization they will try their installs on
clean lpars. And not the same old lpar where their owning profile already
existed or whatever.

If your developers keep needing qsecofr access they're doing it wrong.
That's like having first aid equipment down at the bottom of the ski slope
not "just in case" but "we're going to use it at the end of every run".

I realize it get's trickier when you have interfaces between disparate
vendor applications. Heck we got through this and we used to have ERP by
one vendor and accounting by another.

You know what really helps? A good change management package. One that
knows, and can be configured to set up things like: programs that need to
adopt authority, programs and data that have special authorization lists
and stuff set up on them.


Rob Berendt