A long time ago, in a galaxy far . . .

We used to set up generic user profiles for certain processing on our machines. Maybe we used QUSER for all DDM transactions, maybe we created a profile for use in EDI, or maybe we made up a profile DOCK for all users who signed on from the loading dock.

It was not uncommon for us to set up a user as ABCUSER, where ABC was the name of our company, and we used that profile always to log on to the PC support router. Now we use it to log on to the sign-on server (that little GUI box that asks for your profile and password).

Maybe all of our system operators sign on as QSYSOPR. That also would be a generic profile name.

And QSECOFR, who is that?

Having multiple people sharing a profile and password presents a big problem in the area of security and accountability. If 10 users know the password for the generic profile DOCK (at the loading dock), you have no real way to know who did what.

When DOCK changes an order or re-prices an invoice, who actually did it? Can you prove who made the change?

Users must be held accountable for their actions, and if users share profiles and passwords, you cannot enforce that much-needed accountability.

I know that in various industries generic profiles abound -- on the shop floor, on the casino floor, at the retail store. In such instances, the business case may be made that generic profiles are required due to the nature of the workplace. That is an argument you can take up with your auditors. If you can convince them, you probably have a REALLY good case.

But alas, most of us don't have a good business case. Instead, we have users who are reluctant to any change in their routine.

In the above article, I explained how you can audit and report on database record changes. When you are using generic user profiles, the ability to tie a real person to a database change is lost.

Please, try to move from generic users wherever possible. You'll be thankful some day that you made the change.