Re: adding new fields to PF

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