RE: Ideas? -- MIDRANGE-L

Paul- okay, I'll bite...how do you feel about raid?. 

> +++++++++++++++++++++++++++
> 
> Jack Shoaf
> Director of MIS
> The Echo Design Group, Inc
> 1050 Valley Brook Avenue
> Lyndhurst, NJ 07071
> 
> Phone: 201-842-0088
> Fax     : 212-686-5017
> E-mail : Jshoaf@echodesign.com
> 
> -----Original Message-----
> From: PaulMmn [SMTP:PaulMmn@ix.netcom.com]
> Sent: Tuesday, July 21, 1998 12:22 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Ideas?
> 
> WARNING!   WAR STORIES FOLLOW....
> 
> Walden, here's how I see it (IMHO):
> 
> 1) Pgmrs should have read but don't touch rights to production
> objects.
> It's not a matter of trust.  I don't know how many times the 'oops'
> factor
> creeps in.  Like the time I had a test subsystem, QINTERPEM running.
> Then,
> while talking to someone, I ended subsystem QINTER.  OOPS!  It wasn't
> what
> I -intended- to do, but it happened anyway.  (I tend to hesitate over
> that
> last 'Warning' screen these days...)
> 
> 2) 3 AM problems?  Well, I have given out a god-like password now and
> then.
> And I've un-installed programs that I've been assured will "work just
> fine."
> 
> 3) Is a test data base worth the cost?  YES!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> I also have a firmly held belief that the test database does NOT have
> to be
> a 100% clone of the live data!  You need 'typical' data, plus the
> exceptions you've collected over the years (you know-- the ways the
> user
> 'tested' the system that you never counted on...).
> 
> 4) If the bad data isn't in the test database?  One place I worked we
> had a
> 'grabber' program.  Feed it the order number, and it grabbed part
> master,
> product structure, the order, and other information so you could run
> tests
> on the bad data.  *sigh*  You need time and dedication to the idea to
> make
> such a program a reality.  However, if you build it, they will use it.
> 
> I agree that you have to trust the programmers.  But between the oops
> factor and the auditors you need to have a way to keep the programmers
> out
> of the live data.  It's an issue of control; the 'need to know.'  As
> much
> as you trust people, there are some who will take advantage of that
> trust.
> 
> One time we were installing a new system, and the word came down from
> the
> head of IS:  "Let the programmers have full access to the production
> system.  It takes too long to get things into production with your
> 'install' process."  We got that in writing.  What a mess!  We didn't
> have
> any Change Management System in place, and programmers had no idea who
> was
> working on what program (let alone what version of the code was
> supposed to
> be 'live.').  There were multiple programmers changing the same live
> programs, users who had no idea that things were being changed, data
> was
> being scrambled and rebuilt.  AAARRRRGGGHHHH!!!
> 
> Never again!  We installed a change management system, locked down
> security
> on the production data bases, and kept the programmers in their own
> playground where they can't hurt anything.  It's NECESSARY.
> Inexcusable to
> do otherwise.
> 
> *whew*
> 
> Now...  ask me how I feel about RAID.  (:
> 
> --Paul E Musselman
> PaulMmn@ix.netcom.com
> 
> 
> >Paul,
> >
> >While in general I would agree with you, I have a couple questions.
> >
> >1) How do you handle cases where data the programmer needs is not
> >available on the users screens? (Surrogate keys, audit stamps,
> journal
> >receivers, etc.)
> >
> >2) How do you fix a problem at 3AM?
> >
> >3) If you have an image of the database for testing on another
> machine
> >is it worth the cost of 150Gig of disk?
> >
> >4) If you have an image of the database for testing, what if the
> "bad"
> >data that is causing the problem is newer than the image of the
> >database?
> >
> >I've never found a good solution to these problems. As I see it if I
> >can't trust my programmers with my production data why am I employing
> >them? Anyway, if they wanted to cause trouble they could always write
> a
> >logic-bomb and drop it into the order entry programs, I'd never know.
> I
> >don't have time to review every changed line of code.
> >
> >-Walden
> >
> >-----Original Message-----
> >From: PaulMmn [mailto:PaulMmn@ix.netcom.com]
> >Sent: Thursday, July 09, 1998 9:43 PM
> >To: MIDRANGE-L@midrange.com
> >Subject: Re: Ideas?
> >
> >
> >I'm afraid you won't get much sympathy from me.
> >
> >Programmers SHOULD NOT be able to do much to a production data base.
> I
> >feel they should be able to read production files (with proper
> controls
> >over sensitive data like Payroll).  They should NOT be able to update
> >production files using programmers' tricks or DBU.
> >
> >If a programmer has any access to a production data base, it should
> be
> >via
> >a *USER profile, just like every other user.  This does limit
> >programmers'
> >playing to using the proper menus and interfaces and controls built
> into
> >the production system, but it's never a good idea to let programmers
> run
> >things that they can program loopholes in.
> >
> >How -should- testing be handled?  Ideally, you should have a complete
> >copy
> >of the production environment on a test machine so that -you- can run
> >the
> >programs, watch yourself do things, and never, Never, NEVER risk
> damage
> >to
> >the production data base!
> >
> >Do you -really- want a user running a program that needs fixing?
> >
> >--Paul E Musselman
> >PaulMmn@ix.netcom.com
> >
> >-=-=-=-=-=-=-=-=-=-
> >
> >>Hi folks;
> >>I got a question concerning my current programming job.  Here's the
> >>scenario:  I am assigned a program that requires fixing, and this
> >>program is maybe 4 CLP's and 5 RPG programs deep into CALL's,
> therefore
> >>knowing exactly (dspjob info) the files it is accessing and any
> >>variables in a program *ENTRY PLIST is very helpful and a valuable
> time
> >>saver as well as an error preventer.  Normally what I would do is
> this:
> >>a) Have production user sign on to the system.
> >>b) Identify the name the AS400 has assigned to this users job.
> >>c) Then I would do the STRSRVJOB command on this job.
> >>d) Then a STRDBG on the specific program I wanted processing to stop
> >on,
> >>for my brief (information) collection.
> >>e) I would then allow the user to progress to the program area I
> wanted
> >>to look into.
> >>e) At program stop time I would view the PARMS in the *ENTRY PLIST
> of
> >>the program and the actual files the program was pointed at.
> >>Well guess what!  Programmers at this company are not AUTHORIZED to
> do
> >>this on a production machine, this has me floored!
> >>
> >>I would appreciate any suggestions my fellow-list-people would offer
> me
> >>to somehow circumvent this perplexing problem.
> >>Thanks very much in advance.
> >>
> >>----
> >>Tim & Dana Truax... and Caleb 4 years old.
> 
> 
> +---
> | 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
+---