The "New & Improved" CHGPF
By Thibault Dambrine
This article was started before I had a chance to read "Tips from Jackie" in our May 1997 issue. It was started on the base of an internal presentation at Saville Systems and it is now here for your perusal. It is a little bit more detailed than Jackieís piece but essentially covers the same material.
As Programmers, most of us like to think we are good enough systems designers. When we decide to put "n" number of fields in a file, we usually donít expect to have to change that in the immediate future. Of course, in the real world, business requirements change, legacy applications are a fact of programming life, and changes in file format is something we will have to face sooner or later.
Changing the format of a widely used file, with a number of logical views and a few more bells and whistles can be a lot of work. In the most complicated case, the to-do list involved in a change of physical file would look like this:
For those who are not yet aware (I was part of that bunch until recently), CHGPF has changed a lot.
Starting at Version V3R2 however, CHGPF can do a lot more for you.
If you are changing a physical file with a lot of logical views, specific authorities and special features attached; CHGPF can now help you in a big way.
With the new features offered in CHGPF, there is no need to delete and re-create physical files or any of the associated logical files when changing the number of fields or altering fields in an existing physical file. Authorities are taken care of, trigger programs are automatically re-attached, as are journals and everything else that was hooked up to the old file.
All you have to do now, is to change the DDS, call CHGPF and stand back!
First, lets review the DDS changes supported by CHGPF:
With these new parameters in the CHGPF command, the to-do list to modify a file becomes:
Note: The File Level Identifier will change when the following features change:
A change to any of the above, causes the data map to change and therefore programs using the file have to be re-compiled.
All this sounds pretty good, but there are still considerations to watch out for. Do not attempt to use CHGPF without reading these:
Enough Storage must be available to make a copy of the data from the physical file.
Exclusive Use of the physical file is required.
Only users with *OBJALTER or *OBJMGT authority can run CHGPF.
When changing the data type of a field, the new data type MUST be compatible with the old one, i.e., numeric to numeric, or character to character.
File statistics not preserved.
CHGPF will NOT recompile programs that use the physical file.
CHGPF will NOT remove deleted records from a physical file.
Some changes can cause data loss, e.g.: field is deleted; new field is shorter, field is changed from being NULL-capable to not being NULL-capable, CPF will issue a message if data loss possible.
When adding a new field, plan ahead to determine the default value of the new field.
CPF cannot apply or remove journal changes across a CHGPF journal entry.
What happens if there is an error?
CHGPF returns all objects involved in their state just prior to the change occurring.
Having a current backup of the file(s) involved still a good idea.
Although the new CHGPF feature does not do EVERYTHING you need when changing fields in an existing file, it will significantly reduce the tedious parts of the job. Proper planning, backups, program re-compiling is still part of the job. Also, there is no substitute for reading the specifics in the manual. This article is more of an introduction than a detailed technical example.
Note: I would like to give credit to Skip Marchesani of Lexel-Custom Systems Corp. (Newton, NJ) for his contribution to this article.
Back to Tylogix Home Page