Re: adding new fields to PF

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:
> inconveniencing? you have to have an exclusive lock to do the CHGPF or it 
> will fail due to object lock, so what's the difference, a few seconds 
> longer?
>
>   
I side with Tommy on this one.  Why are you adding a new field to a 
production file while users are online?  If this is a 24x7 shop, I can 
understand the need, but even those shops require occasional scheduled 
downtime for things like backups, PTFs, and so on.  So unless this is 
something you do regularly, I think finding a timeslot where you can 
compile the programs correctly is the right way to go.

If this *is* something you do regularly, I suggest using a different 
approach.  I suggest never using the physical directly, and instead 
using a logical (with a version number) over the physical.  Then you can 
add fields to the physical whenever you need to and the logicals don't 
change.  You add a new logical with a new version number that contains 
the new fields, and as you have time, you modify your program to point 
them to the new version of the logical and recompile.  Once all programs 
are weaned off the old logical, you remove it.

This has the added benefit of alerting you to programs that haven't been 
reviewed for changes.  The downside is that you have to actually change 
the file name when you recompile the program, but note that this is 
*only* in the case where you have a master file that changes so 
frequently that you can't schedule modifications during downtime.  It's 
a rather severe fix, but in my mind the requirement to regularly change 
a physical file is a rather severe requirement.

Joe