RE: MKS Implementer change management question about losing sourc e co de

["Reger, Bill" <breger@xxxxxxxxxx>]

If I understand it correctly, I think I have experienced a problem similar
to this.   Of course, I have received no formal training on how to use the
product and may be using it in a way that was never intended, but I have yet
to find a way to ensure that version 1 of a program gets applied to an
environment before version 2 does.  I think there are features in the new
release of MKS Implementer that are supposed to address some of these issues
(they call it Release Control) but I can only assume this based on some
release highlights that I have read.

Jorge A. Aquino
Senior Project Manager
Levitz Furniture Corporation
561-994-5174
<mailto:jaquino@levitz.com <mailto:jaquino@levitz.com> >

        -----Original Message-----
        From:   Shaw, David [mailto:dshaw@spartan.com]
<mailto:[mailto:dshaw@spartan.com]>  <mailto:[mailto:dshaw@spartan.com]
<mailto:[mailto:dshaw@spartan.com]> >
        Sent:   Wednesday, April 12, 2000 2:04 PM
        To:     'MIDRANGE-L@midrange.com'
        Subject:        RE: MKS Implementer change management question about
losing sourc e co de

        Joel,

        Softlanding TurnOver doesn't do that.  The source on the development
box is only manipulated during the promotions to the development box's
"master" copy of the application.  When the forms ("installation packages"
might be more descriptive) on the production boxes are run, the only thing
returned to the development box is the completion code.  TurnOver is also
pretty resistant to running forms out of order, although it can be done if
one is persistent enough ("stupid" might be more descriptive for that
<grin>).
        -----Original Message-----
        From:   Stone, Joel [mailto:StoneJ@GourmetAward.com]
<mailto:[mailto:StoneJ@GourmetAward.com]>
<mailto:[mailto:StoneJ@GourmetAward.com]
<mailto:[mailto:StoneJ@GourmetAward.com]> >

        We lose source code using Implementer, and MKS tells me that it is
due to our unique configuration.  To me the config doesn't seem unique at
all, but rather the norm.
        We have a development box, and several production boxes.  When a
program is promoted, only the object is promoted to the production
environments, not the source.
        Each time a remote operator pulls in his changed objects,  the test
source matching that object is written over the master source.  If there are
10 remote environments, the master source is overlayed 10 times, once for
each promotion to production at each remote.  A problem occurs when a remote
operator pulls in changes out of sequence.  For example,  PGMA ver 1 is
promoted, and a week later PGMA ver 2 is promoted.
        The remote operator at one division was on vacation that week, and
let promotions slip.  When he returns, he accidentally pulls PGMA ver 2 in
first.  The next object he pulls in is then PGMA ver 1.  His was the last
division to pull in PGMA changes, and the PGMA source on the development box
is now one version old, at PGMA ver 1.  The problem may not be discovered
for months or years, when the PGMA ver 2 source code is long gone, and no
longer matches the object running in 9 out of 10 production environments.
        Has anyone else experienced this problem?? 
        Do other AS/400 change management packages allow a remote operator
to control source code integrity? 
        +---
                | This is the Midrange System Mailing List!
                | To submit a new message, send your mail to
MIDRANGE-L@midrange.com <mailto:MIDRANGE-L@midrange.com> .
                | To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com <mailto:MIDRANGE-L-SUB@midrange.com> .
                | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com <mailto:MIDRANGE-L-UNSUB@midrange.com> .
                | Questions should be directed to the list owner/operator:
david@midrange.com <mailto: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
+---