How do I change the field length in a physical file using chgpf command?

130 pts.
Physical File

 This is giri.Im looking to change the field length in pf using chgpf command?Please give me what are the steps i have to do?How can i change the field?

Software/Hardware used:
software developer

Answer Wiki

Thanks. We'll let you know when a new response is added.

Thank you for visiting ITKE.

We are happy to help you with solving specific IT questions, but need as
much information as possible to do so. Let us know about the problem you
are trying to solve, how you are approaching it and what work you’ve
done so far, and we can help guide you in the right direction.

Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    The steps will depend on how the database and the application are defined. If all access is through logical files that have explicit field lists (rather than implicit), it will be very different from an application that has a lot of access directly through the physical file or if many logical files use implicit field lists. Also, if physical updates of the file is handled through a dedicated module that references the physical file, it will be different from an app that has updates in many modules through multiple logical files. Describe how the logical files reference the physical fields and provide a basic description of how modular the application is for table maintenance. Then we can describe the appropriate steps. Tom
    125,585 pointsBadges:
  • MDratwa
    Change the DDS and use CHGPF to recompile the physical file. Delete the logical file(s) and recreate using CRTLF. Recompile all program(s) that use the file(s). You will have to determine which program(s) that will have to be changed to use the new length.
    785 pointsBadges:
  • WoodEngineer
    If you use CHGPF to recreate the changed physical file it will automatically recompile the logicals as well. I have not tried CHGPF after changing a field used as a key in a dependant logical but would not be surprised to find that CHGPF handles that as well.
    8,225 pointsBadges:
  • TomLiotta
    Delete the logical file(s) and recreate using CRTLF. Recompile all program(s) that use the file(s). If defined properly, there may be no need to recreate any LFs nor to recompile any programs except at least one program that would be in charge of file updates. And, of course, any program that actually uses a changed field may need to be changed along with the field in order to make use of the new length or the change in data type. When increasing the length of an alphanumeric field, LFs that explicitly list their fields do not need to be recreated until you want them to reflect the new length. They will continue to work as before, with the old length. You can make this change to the database without needing to recreate LFs nor programs. ...IF the app and database was designed to allow it. (NOT very likely in most systems!) LFs that implicitly list the fields will change their behavior. Programs that use those LFs will hit a level check until they are recompiled. Assume an application that has one dedicated module to perform physical file updates. Any other program that wants to execute an update to that file must call the update program and pass the changed record image as a parm. All program accesses to the file outside of the one update program is through a few LFs that all explicitly list their fields. If you use CHGPF to increase, say, a MYTEXT field from 15 to 25 characters, the only thing that you must recompile is the one program that actually does the write or update to the PF. The only change that you must make is in the new record format that gets picked up by the recompile. Naturally, if you have a data structure coming in as a parm with a 15-byte field and you move that value to the new 25-byte field in the record format, there will be 10 bytes wasted in each record. There's no law against a little waste. But it illustrates what can be done. It begins to show how thoughtful definitions of "tables" and "views" can isolate programs from changes in the underlying database. It allows changes to be phased in. The field can be changed today. A couple of the more important programs might be changed tomorrow. Other programs might be changed next week. If a few new LFs are created that bring the new field definition in, you might just start cloning programs and changing them one at a time to use the new LFs, while programs that don't need the new field keep running over the old LFs. After a while, none of the old LFs nor the programs that referenced them will be needed -- they can simply be deleted. It's easy to create a TESTPF with half a dozen fields or so. Then create two or three LFs that present a few views of that PF. Create a trivial CL program that only DCLFs one of the LFs and executes a single RCVF, or a trivial RPG that consists of an Input Primary F-spec and a SETON LR statement. It only takes a few minutes to have a complete "test suite" of objects to see what works and what doesn't. Run CHGPF a few different times over changed DDS and see what causes the CL or RPG to 'level check'. Use DSPFFD to track changes to LF field definitions and record format IDs. Compare format IDs to those from DSPPGMREF to verify that they match or that they differ. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: