RE: Adopting authority not?

One major difference between CLRPFM and a regular-old-file-update is that
CLRPFM requires *OBJMGT authority, whereas updating a file requires *OPR +
*READ* + the appropriate data update rights (*ADD, *UPD, *DLT).  

Based on your example below, I cannot say why this program is successful.
Is it possible that the authority to update the file comes from some
previous adoption (or from ownership or *ALLOBJ authority possessed by the
calling user)?  If you turned on the *ADOPT value in the QAUDLVL system
value, it could assist in determining where the authority to update the file
is coming from.

jte


(*Strictly speaking, updating a file does not technically require *READ
authority, but as a practical matter it usually does).

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxxxxxxx
www.powertech.com 
--
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Thursday, April 03, 2003 1:59 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Adopting authority not?
> 
> John,
> 
> I really appreciate your in depth analysis.
> 
> However, we use this user ADOPT to own programs in numerous other cases.
> 
> Example
> program GDIINTEDI/POEXTV is owned by ADOPT.  It is used to update this
> file:
> Object . . . . . . . :   IIML01          Owner  . . . . . . . :   SSA36
>   Library  . . . . . :     CLIDIVF       Primary group  . . . :   *NONE
> Object type  . . . . :   *FILE           ASP device . . . . . :   *SYSBAS
> 
> Object secured by authorization list  . . . . . . . . . . . . :   *NONE
> 
>                          Object
> User        Group       Authority
> SSA36                   *ALL
> *PUBLIC                 *EXCLUDE
> 
> Remembering that SSA36  is a supplemental group of ADOPT.
> 
> I am doing some testing to see if CLRPFM is just pickier than other data
> operations.  For example, while I can create a program which adopts
> QSECOFR to create user profiles, that program cannot give that new user
> profile a group profile that the job user does not have access to.
> (Remember my QTCP ftp exit point issue?)  I am wondering if CLRPFM has
> some strange requirement.  The gent who does the most here with adopting
> was pretty sure that he does RMVM, and ADDPFM with adopted authority, but
> he didn't look like he  was willing to bet the farm on it.
> 
> Rob Berendt