RE: Adopting authority not? -- MIDRANGE-L

Rob,

Another thought (guess?), Is the failing operation (the CLRPFM) running in
batch?

An interactive job will not transfer its adopted authority to any batch job
it submits.  You must arrange for the batch job to adopt authority
separately.  Is this what you're running into?

jte

--
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: Monday, April 07, 2003 8:23 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Adopting authority not?
> 
> I think I see what you are saying.  If I make a program owned by ADOPT,
> and the program is *OWNER and not *USER, and access to the object is SSA
> *ALL and *PUBLIC *EXCLUDE, and ADOPT has
> Group profile  . . . . . . . . . . . . . . :   SSA
> Supplemental groups  . . . . . . . . . . . :   SSA01
>                                                SSA13
>                                                SSA23
>                                                SSA26
>                                                SSA30
>                                                SSA32
>                                                SSA33
>                                                SSA36
>                                                SSA52
>                                                SSA70
>                                                SSA78
>                                                SSA89
> 
> Then adopted authority cannot come from any of the groups listed above.
> However that has not been what I've seen in practice.  The program can
> easily update data, read data, etc.  However it cannot do any member
> operations, like CLRPFM, etc.  And by SSA *ALL I mean *ALL, all options
> are checked, object and data.  (Did I mention that I hate multiple member
> files?  Did I mention that I prefer the SQL unqualified DELETE FROM FILE
> with REUSEDLT(*YES) over CLRPFM?)
> 
> The reason that we don't make SSA the owner of the program is that there
> are several objects owned by SSA01, etc that SSA does not have access to.
> 
> We could try adding ADOPT to that object explicitly to see if that works.
> But that will be a major pain to determine all the objects that will have
> to be modified.
> 
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
> 
> 
> 
> 
> qsrvbas@xxxxxxxxxxxx (Tom Liotta)
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 04/04/2003 03:47 PM
> Please respond to Midrange Systems Technical Discussion
> 
>         To:     midrange-l@xxxxxxxxxxxx
>         cc:
>         Fax to:
>         Subject:        RE: Adopting authority not?
> 
> 
> midrange-l-request@xxxxxxxxxxxx wrote:
> 
> >   1. Re: Adopting authority not? (rob)
> >
> >I know that some of you out there have had projects in which you create
> >files in which no one has access to.  All access is done via 5250 type
> >programs in which adopted authority is used.  So even if the user is a
> >member of a particular group, that group still does not have access to
> the
> >data.  Only the programs that adopt some other authority actually have
> >access to that data.
> >
> >In your experience, does CLRPFM work under this situation?
> 
> 
> Rob:
> 
> This should work as long as the following comment from John Earl is
> heeded:
> 
> > > *         User Profile "ADOPT" belongs to the group "SSA", but adopted
> > > authority cannot come from the group profile of a program's owner.
> 
> Commonly, the authority is granted to the program *OWNER, not to one of
> the *OWNER's group profiles -- e.g., make the group profile be *OWNER.
> 
> Of course, I don't see that there's anything to stop *OWNER from switching
> to one of its group profiles if any specific operation required it and
> switching is authorized.
> 
> Tom Liotta
> 
> --
> --
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788 x313
> Fax    253-872-7904
> http://www.powertechgroup.com
> 
> 
> __________________________________________________________________
> Try AOL and get 1045 hours FREE for 45 days!
> http://free.aol.com/tryaolfree/index.adp?375380
> 
> Get AOL Instant Messenger 5.1 for FREE! Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.