RE: [SUSPECTED SPAM] Use of adopted profiles

We use a group profile to control the authority, owns the objects, as you described below, for some apps, not all.
Some of our 3rd party vendor's apps use the authorization lists, as Rob describes below.
We run 20+ 3rd party products, and they each have their own rules for authority purposes.
It gets complicated why trying to create a standard without breaking any of the products.

Public is not consistent across the board, which is another issue.

I'd like to see a comparison of the group profile vs authorization list, pros/cons.
If you an authorization list, who should be the object owner?
Do you change to once consistent owner, or leave objects as shipped.

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Friday, October 05, 2018 11:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: [SUSPECTED SPAM] Use of adopted profiles

The first thing to understand is the difference between "User profile" and
"Use adopted authority". The former is for that program. The latter says
use to continue to use the adopted authority of programs earlier in the
stack.

I would use an authority list and not a group profile. The reason being
is it becomes much easier to granularize security. For example:

ERPAUTL
*PUBLIC *EXCLUDE
PGMADOPT *ALL
QRYMAVEN *USE

In general this would say that *public could not access the data unless
they were using programs using adopted authority of PGMADOPT. And if you
have that person who is your local query maven they could read the data.
We have a guy from "corporate" who wanted to be assured that he could not
change the data but could read it and we use this.

For the love of God do not make PGMADOPT a group profile and put people
into that. If you do then they can modify the data from any ODBC program,
etc.

Oh, and the IFS doesn't give a rats posterior about adopted authority and
you have to use profile switching api's for that.

Rob Berendt