RE: File transaction date

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Joe Pluta

Database references and stale business logic are just two
reasons why I've never like bind by copy.

Joe, could you be more specific? I don't really understand that. I am finding bind by copy to be a real pain. Monday morning and there's a traffic jam of developers waiting to get to work : At night between Sunday and Monday, the prod LPAR is copied to the dev LPAR. Then the developer's changes are installed so that they can start testing their new versions. One developer may have changed a file, a load of programs are recompiled, then my job, last in the Q will do the same, often recompiling the same programs as the last developer just did. Took nearly 2 hours to get in today because of snow, now I have to wait 3 hours before the installation I scheduled Friday evening completes!
It seems that binding by copy gives you as much hassle as actually copying the code in each member.

Okay, that's the theoretical point. On to the practical.

As far as the time issue, here's a possibility: do you have
room for two copies of your program library, David? If so,
could you create a dummy library with an empty copy of the
new file and all your programs already compiled against that
new file? Then, your window would only need to be long
enough to CHGPF the file and then copy all the programs from
the new library to the production library. That has to be
faster than recompiling everything. Just a thought.

I'm obliged to use our standard procedure that pushes all the source changes and then compiles the source. The source is kept on the production LPAR. One must be able to do DSPOBJD and see the source used to create the object. I can't explain why.

Ok, now my file is being migrated. I've quickly changed it to LVLCHK(*no). That way all the programs that reference but don't even use it because of the bind by copy won't crash. I think I should be ok for now, but what a mess!