Hi David,
As shown below, an operator group and administrator group are specified with
aopsetup when executed. The group names shown are the samples specified in the
documentation. Alternative group names can be used instead. Both groups must
have GIDs.
aopsetup AOPOPER AOPADMIN
Had aopsetup been run, the group in the File Security Packet for aopstop would
have been set to whatever group was specified for AOPOPER. Assuming ID AOPSTC
has been assigned to the AOPSTOP Started Task and is connected to whatever
group was specified for AOPOPER, AOPSTC would then have r-x access to aopstop
via this group.
I recommend aopsetup be rerun with the proper groups specified.
Regards, Bob
Robert S. Hansel 2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com
-----Original Message-----
Date: Wed, 24 Jul 2024 13:26:54 -0400
From: David Spiegel <[email protected]>
Subject: Re: [External] : Re: AOPSTOP
Hi Richard,
I asked the person who customized on V2.5.
He could not remember if he ran AOPSETUP or not.
My guess is that he didn't because the script CHMODs aopstop to 4754,
but, the file has Permission Bits 750.
Regards,
David
On 2024-07-23 11:02, Richard McIntosh wrote:
> Have you run the AOPSETUP to set the permissions for all the AOP files?
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
> David Spiegel
> Sent: Tuesday, July 23, 2024 9:55 AM
> To: [email protected]
> Subject: [External] : Re: AOPSTOP
>
> Hi Michael,
> No, it does not.
>
> Thanks and regards,
> David
>
> On 2024-07-23 10:09, Michael Babcock wrote:
>> Does AOPSTC have access to BPX.SUPERUSER on the 2.5 system?
>>
>> On Tue, Jul 23, 2024 at 8:43 AM David Spiegel <
>> [email protected]> wrote:
>>
>>> Hi John,
>>> Thank you for the suggestion.
>>> Unfortunately, the only thing displayed was the Permission Bits.
>>>
>>> $ getfacl /usr/lpp/Printsrv/bin/aopstop
>>> #file: /usr/lpp/Printsrv/bin/aopstop
>>> #owner: OMVSKERN
>>> #group: OMVSGRP
>>> user::rwx
>>> group::r-x
>>> other::---
>>>
>>> Thanks and regards,
>>> David
>>>
>>> On 2024-07-23 07:18, John S. Giltner, Jr. wrote:
>>>> If you have not you may want to see if somebody set a file ACL
>>>>
>>>> getfacl /usr/lpp/Printsrv/bin/aopstop
>>>>
>>>> On both systems and see if they are the same
>>>>
>>>>
>>>> On Mon, 22 Jul 2024 09:23:32 -0400, David Spiegel <
>>> [email protected]> wrote:
>>>>> Hi,
>>>>> In z/OS V3.1, I issued (via SDSF) S AOPSTOP and it failed because
>>>>> AOPSTC (taken from STDATA) has UID(1) and GID(24), and
>>>>> /usr/lpp/Printsrv/bin/aopstop has its Permission Bits set to 750.
>>>>> The file is owned bu UID(0) GID(1). This is expected.
>>>>>
>>>>> On z/OS V2.5, however, AOPSTOP works (with the same STARTED Class
>>>>> Profile and Permission Bits.) Can someone explain why it works on
>>>>> 2.5? (Based upon UID/GID and Permission Bits, it seems like it
>>>>> shouldn't.) I looked at the DBSYNC output comparing the 2.5 and 3.1
>>>>> RACF Databases and did not notice anything that would explain this
>>>>> behaviour.
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Regards,
>>>>> David
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
