I appreciate all of the input that I have gotten but I am not looking to
rewrite the security on the machine.
I am looking for a very specific solution of that blocks the manipulation of
objects (creating, deleting, renaming) while still allowing the use of
member commands like ADDPFM, RNMM, and RMVM.
It appears that IBM has tied the execution of the member commands to the
authority of the file AND LIBRARY which makes no sense to me. I was sure
that I was missing something in the combination but it does not appear that
I am.
And to further clarify, I am trying to prevent the developers from screwing
up their own environment which is breaking the testing for other developers.
It is stupid stuff like the renaming a PF and creating a new one but not
changing the logicals so they are still pointing to the old file. The
change management software handles this so if they used it, there wouldn't
be a problem.
Production is a whole other story that I don't have the energy to fight so
I'm not going to bother. Besides, they will get reprimanded for breaking
production but nobody cares if they break the test environments.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
vforbes@xxxxxxxxx
Sent: Friday, June 10, 2022 11:49 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Object authority
The best method is having production on one box/partition & development on
another.
Adopting authority programs should not be needed.
This is one method of setting security. This may not be complete, but it is
a start.
Create new 'Group' user profiles. APPUSER, APPOWNER, PGMR. These ids have
no password & cannot sign on.
Change developers to be part of the Grpprf PGMR, App users to the Grpprf
APPUSER Create an AUTL (authorization lists). I.e. PROD
Add PGMR to this Autl with only *USE access if you want problem
support or *NONE if you don't want them to even see it.
Add APPUSER to this Autl with either *CHANGE or *ALL access. You
need to test this.
Revoke *ALL authority to *ALL users to all 'Production' objects & libs.
Leave IBM libs alone. Do this after hours.
Change the owner of all 'Production' objects & libs to a new id APPOWNER
Grant authority to all 'Production' objects & libs to the Autl PROD. Any
future authority changes are done in the Autl. I.e. adding a 'FireFight'
id.
Make a copy of production libs for developers.
Create new Autl DEV
Add PGMR to this list with only *CHANGE or *ALL access Restore prod
libs to new names Change obj & lib Autl to new Autl DEV Optional, you may
want to create a 'Sterilization' program to mask things like account SIN,
name, address etc.
Vincent
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
dr2@xxxxxxxx
Sent: June 9, 2022 3:40 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Object authority
Among other things I would look at using programmes that adopt
authority...and firing a few programmers....
On 2022-06-09 14:42, smith5646midrange@xxxxxxxxx wrote:
We are having problems with developers "installing" new objects
outside of the change management software and also renaming existing
objects and creating new versions of them.
We are an IP based company so we rely heavily on adding and removing
PF and LF members.
Is there a level of security that I am overlooking that will allow us
to lock down a library to prevent the creation of new objects and the
renaming of existing objects yet still allow the ADDPFM/ADDLFM and
RMVM
commands?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
