John, you might be right.  We've discovered that a major BPCS program is
owned by SSA, *OWNER and has adopt authority turned on - SSAZ99:  The BPCS
menu.  And it does hold true for a command line called from under that
program.

Here is the big clue!!!!!

Object . . . . . . . :   DUH3            Owner  . . . . . . . :   SSA
  Library  . . . . . :     ROB           Primary group  . . . :   *NONE
Object type  . . . . :   *FILE

Object secured by authorization list  . . . . . . . . . . . . :   *NONE

                         Object
User        Group       Authority
SSA                     *ALL
*PUBLIC                 *EXCLUDE
*ADOPT                  *ALL

Reeve,
When you do a WRKOBJ and do an option 5 to display authority, do you see
*ADOPT as a user?


Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "John Earl"
                    <johnearl@powertech       To:     <midrange-l@midrange.com>
                    group.com>                cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     Re: Authority issue
                    drange.com


                    01/15/2002 03:23 PM
                    Please respond to
                    midrange-l









> It sounds to me like the program is using the authority of the programs
> owner and not that of the user.  Change the program to use user authority
or
> give the owner the authority to perform the task.

I don't think that this is possible.  Aopted authority is cuulative,
meaning
that when you adopt the authority of another user you get the combined
authorities of both users.  It's not exclusive the way that swapped
profiles
are.

> I created a file.  If I clear the file (clrpfm) from the command line,
all
> is well.
>
> If I call a program from a command line that clears this file, I get an
> error message saying that I am not authorized.

Assuming that you call the program from the from the same session (indeed
the same command line) that the clrpfm was run, there is one scenario that
I
can think of that could cause this...

-You are not authorized to clear FILE1.
-USER1 is authorized to clear FILE1.
-USER1 owns PROGRAMA
-PROGRAMA adopts it's owner's authority (USRPRF(*OWNER)).
-You call PROGRAMA.
-You access a command line while PROGRAMA is still open.
-You are able to clrpfm FILE1 because you are running under PROGRAMA which
adopts USER1's authority.
-You access a PROGRAMB while PROGRAMA is still open.
-PROGRAMB states "Use Adopted Authority=*NO"  (USEADPAUT(*NO))
-You are not able to clrpfm FILE1 because PROGRAMB has stipulated that you
are not to acquire adopted authority from a previous program (PROGRAMA in
this case).

Does that fit?

jte




_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.