RE: Object authority -- MIDRANGE-L

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