RE: Installing 3rd Party Software using QSECOFR??

midrange-l-request@xxxxxxxxxxxx wrote:

  4. Installing 3rd Party Software using QSECOFR?? (Richard)

I am currently evaluating two software packages. One requires it be 
installed by QSECOFR, the other only requires user class *PGMR. I have taken 
points off  from the package requiring QSECOFR. When asked why, my response 
involved "having heard somewhere" it was an undesirable condition.

If I could get a little feedback, either way, I'd be most thankful.

Richard:

The _only_ company that should be asking you to install (or even sign on) with 
QSECOFR is IBM.

Note that requiring QSECOFR isn't exactly the same as requiring various special 
authorities for the user profile that's doing the install. A product might 
create a subsystem to do its work in and it might need to issue a STRSBS 
command when it runs -- the program that executes STRSBS needs *JOBCTL at that 
moment. It could get *JOBCTL by running under its *OWNER where the owner has 
*JOBCTL.

And the installation routine might create that owner profile with *JOBCTL 
assigned to it. But in order to do that, the install routine must have *JOBCTL 
available at that time. It also needs *SECADM just to run CRTUSRPRF. It 
(probably) won't need to add *SECADM to the owner profile, but will use *SECADM 
during the install.

The special authorities can add up in a hurry depending on what all is done by 
the install and the product.

However, a direct requirement to install as QSECOFR raises questions. I can't 
think of any legitimate reason for it. Far better for the install simply to ask 
for the authorities that it needs and not require more than that.

A flat QSECOFR requirement makes me wonder if the product itself was written 
with a solid understanding of OS/400.

Tom Liotta