RE: Compiling into production libraries -- MIDRANGE-L

>Buck Calabro (mcalabro@commsoft.net) wrote:
>
>>      In the interest of keeping the peace on the list, I'll just say that we
>>try very hard to keep a minimum number of records in the test/development
>>libraries.  The customer reminds us when we have too much of their DASD!
>
>If I understand this right the development and test libraries are
>typically on the customer's machine, and this is necessary because the
>software is so highly customised that it's impractical for you to be
>able to reproduce a given client's environment on your own machines, and
>your programmers would normally work directly on the client's machine
>either on site or by passthrough/TELNET..

Dead on.

>If the test files have different format level identifiers from those in
>production then your development process is seriously flawed. You first

We recognise that, but there are...additional issues.  We have one library 
for all programmers to use.  At any one time, there may be several 
people making changes simultaneously.  We have an informal process
to try to avoid having 2 people work on the same application, but it is not
perfect. (Obviously)  

One problem arises when programmer A makes a database change
while programmer B makes a logic change to a separate application
that refers to the changed file...  When compiled in the test system,
things are fine: the program doesn't refer to the new fields and 
doesn't care about them.  If we move this program to production,
it will fall over, even though the logic of the program has been tested
and is intact.

>need to be sure that the environments match up. Once you've done that
>they should stay in step. Your development process should ensure this by
>cycling every change through development, testing and production. I
>would suggest the following 2 steps would help immensely..
>
>1. Develop a tool or procedure to compare the environments and tell you
>exactly where they don't match. I don't mean the data, but rather the
>files themselves and their format levels..

It's on my list... <grin>

>2. Develop a process to bring them into line when they don't match. Be
>careful not to hose carefully created test data, and watch out for soft
>coding that may need to be different between production and testing..

This one's the hard one.  The problem is that we don't have rigid 
enough procedures to ensure that we understand WHY there are
differences.  Did I forget to move a file to production?  Is someone
working on an emergency fix?

>I realise that this may not always be practical. For example, if you are
>only meant to do half a day's work you can hardly afford to spend an
>hour or more verifying the environments before you start. So if you must
>compile into production, at least run a comparison between the test and
>production programs before you delete them from the test library. Make
>sure the compiled sizes are the same and make sure the DSPPGMREF outputs
>match all the way down. Then at least you'll know that they wouldn't
>have level checked if you had simply moved them into production..

Good suggestions, all.  Thank you!

Buck Calabro
Commsoft, Rensselaer, NY

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---