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.

I agree. Binding by module essentially does exactly that: it copies the code into every program. It copies compiled code rather than source code, but it copies it just the same. And that code is then statically bound until the next time you compile.

Which means that if your business rules change, you have to recompile the module and then rebind every program that includes that module. On the other hand, with a service program or even a good old called program, any change to the the service/called program is immediately reflected in all the programs that call it with the usual caveats of signing off and signing on and so on).

That has two side effects, one subtle and one horribly un-subtle. The subtle problem is that binding by copy defeats the paging mechanism of i/OS. The i loves paging things in and if multiple jobs in a subsystem use the same service program, only one copy is brought in and not only that, if it's used a lot it tends to stay in memory. With copy by module, that code is on every program and so needs to be pulled into memory multiple times, defeating both the memory usage and performance aspects of paging. And that's the subtle problem! The less subtle problem is that you can miss a program during the recompile phase and that program could be using out of date logic. It's bad when it involves a file change, because the program will blow up with a level check. It's worse when there ISN'T a file change, because now you have rogue business logic doing bad, horrible things to your database - whatever old behavior you just got done changing.

Not good. Not good at all.

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!

Yeah, it's a mess alright. LVLCHK(*NO) is evil, but it's there for situations like this. Just so you know, you could have compiled the programs into a temporary library on production and then moved them into the production library and still kept all the source information.

Joe