Re: Change Control

I'm a strong believer in some kind of change control.
But programmers will often resist change management for
several reasons, most of which have little validity.

I have used both Aldon's ACMS (pre-Affiniti) and
SoftLanding's TurnOver. They are not cheap, but both do
very well, IMO. We had about 10-15 people using Aldon,
we had 12 systems to distribute software to, and it took
care of so many of the details of testing and
distribution. Kept us from stepping on each other and
handled modifications very well.

TurnOver was just getting going when I left the second
company. I actually like aspects of it better than
Aldon, esp. their integration with other platforms. But
this is 3 years ago, and Aldon (finally) got Affiniti,
their cross-platform piece, going.

There is a free utility called csv, that handles
checkout/checkin/merge quite well, I here. One of the
members on the list uses it for extensive 400
development. There's another thing called ant that I
haven't looked at enough, but I think it does project
management to some degree, or else it's a good
replacement for the make utility (unix thing). But there
are make utilities now for the 400.

The time wasted on having an older version get
installed, one with bugs that you fixed a month ago,
costs a lot.

Some developers are concerned they will lose control of
the process. Yes, but who are they working for?
Themselves? No.

Some think they should have access to any and all data
on any box in the enterprise. Again, no. Data on
production boxes is a corporate asset and needs to be
protected from all manner of mostly accidental
corruption. (Very little that happens is malicious, but
rather from someone with too much power forgetting to be
careful enough.) Set up some special permission-granting
process, with an audit trail, so that anything that
happens on a production system can be known. We had a
special command, that only the help desk could run, that
transferred, basically, QSECOFR rights temporarily to a
user, and set up audit journaling against that user,
then gave him/her a command line. Leaving the command
line lost the authorization.

Basically data could be touched only through authorized
interfaces, or applications.
> I work for a Children's Hospital in South Texas.  We are a pretty small shop 
>as
> far as the AS/400 goes.  3 programmers and 2 operators.  I used to work for 
>our
> Electric Utility and in a much bigger shop.  None of the Programmers/Analyst 
>had
> Security Rights to Change Live Objects, Source Code or Files.  Everything was
> done in Test and we had someone in charge of Change Control to move everything
> over once we got the proper signatures.
>
> Recently we had an I/S audit and the auditors are requiring us to use some 
>form
> of Change Control.  The other 2 programmers are very much against this and so
> far we have avoided doing such.  So my question is this, are most 400 shops
> small and dont do Change Control, or are we unique in not doing so?
>
> Hector Sanchez
>
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>