Re: Developer Access. -- MIDRANGE-L

Hi

Developers on my production boxes have access to the end-user functions 
that end-user management is prepared to allow them to have.

Additionally, they have access to a couple of DSPOBJ, DSPFFD type functions 
(can't remember them specifically) that I created to stop their whining. 
Key to this was getting them to provide a detailed list of all the 
functions they needed that "required" QSECOFR type access to the box.

Now adays they DO NOT have access at *ALLOBJ level. This took literally 18 
months to achieve, but when we got there, the sky as predicted did not fall in.

In cases of problems, users contact us for first level support, we analyze 
the problem, print off job logs if necessary, send them the to the dev box, 
examine the job etc. Yeah this is a PITA but it's worth it to keep the 
developers from trashing the box. Saves the users sitting through the "we 
can't help you becuase <insert lame reason here>"

We also perform all insertions of code into production including setting 
authorities etc.

We now have all users without a command line and no special authorities 
whatsoever. All I need to fix is the library/resource security the system 
"developers" screwed up <sigh>

For what it's worth we normally only allow developers on the dev box to 
have *JOBCTL and *SPLCTL though we can and do make exceptions to this if 
someone makes a case. All exceptions are made on the clear understanding of 
what the additional security clearance is to be used for.

HTH
Evan Harris



>We suck.
>
>We develop for a group of applications:  Software Plus, BPCS, homegrown,
>etc.  And we run multiple companies BPCS on our production machine.  Each
>company has their own group profile.  About the only people who think that
>this is a PITA are developers.  Our implementation requires that they have
>multiple user id's.  Because, yes, some wear many hats.  No one except for
>me and the security person (you don't want to F&*% with Peggy), have
>*ALLOBJ and *SECADM on the production box.  But, on the production box,
>each developer whines, stomps their feet, sucks their thumb and complains
>until at least one of their user profiles has *ALLOBJ.  From then on that
>seems to be about the only user profile they use.  This helps them to avoid
>that pesky adequate testing and getting the object authority right before
>they slap it onto the production box.
>
>We are currently implementing Turnover, but heaven help you if you run into
>any glitch or anything.  It immediately gets labeled as a problem with the
>package in it's entirety.
>
>Rob Berendt
>
>==================
>A smart person learns from their mistakes,
>but a wise person learns from OTHER peoples mistakes.
>
>
> 
>
>                     "Chris 
> Beck" 
>
>                     <CBeck@good-sam.com        To: 
> <MIDRANGE-L@midrange.com>
>                     >                          cc: 
>
>                     Sent by:                   Subject:     Re: Developer 
> Access.
>                     owner-midrange-l@mi 
>
>                     drange.com 
>
> 
>
> 
>
>                     06/04/01 08:41 
> AM 
>
>                     Please respond 
> to 
>
>                     MIDRANGE-L 
>
> 
>
> 
>
>
>
>
>
>Sorry for being so vague, I didn't think before I typed.
>
>
>As far as Security Access.
>
>
>
> >>> rob@dekko.com 06/01/01 02:21PM >>>
>
>Might just be me but I find this question quite vague.
>
>Do you mean security access, like giving all developers *ALLOBJ?
>Do you mean do you use CODE/400 or SEU?
>Do you mean Token Ring, Ethernet, VPN, twinax?
>
>
>
>Rob Berendt
>
>==================
>A smart person learns from their mistakes,
>but a wise person learns from OTHER peoples mistakes.
>
>
>
>                     "Chris Beck"
>
>                     <CBeck@good-sam.com        To:
><MIDRANGE-L@midrange.com>
>                     >                          cc:
>
>                     Sent by:                   Subject:     Developer
>Access.
>                     owner-midrange-l@mi
>
>                     drange.com
>
>
>
>                     06/01/01 11:24 AM
>
>                     Please respond to
>
>                     MIDRANGE-L
>
>
>
>
>
>
>
>What does everyone else use for access when setting up developers on a
>separate Dev box.
>
>
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
>david@midrange.com
>+---
>
>
>
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
>david@midrange.com
>+---
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
>david@midrange.com
>+---
>
>
>
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---