Re[2]:RE: Compiling into production libraries

>I think you mentioned that you can't get more DASD because of (politely
>called) budget reasons? That really makes this hard. Ideally you could
>have separate program & data libraries for development, integration
>testing (this is to prevent changes by other developers from affecting
>things you've completed), quality testing, and production. Since you
>probably don't have this (necessary) luxury, here's at least one
>thought--you don't need to duplicate test data in the production library
>(this assumes a separate library for production and development). Have
>test data in the development library and have <bold>empty</bold> files in
>the production library. This way, you can compile over the current
>versions of files, eliminating level check issues, without taking up too
>much extra space. One premise behind this is that the production library
>is reserved for distribution and normally would not have data, since each
>installation will have its own..

Vernon,
        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!  

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
+---