2

I have got an assignment where I need to increase the size of a number of fields in several RPG programs. What I am doing first is changing the field size in the Definition (the most obvious one). The next step is to search for all instances where the changed field is used (like assignment to another variable or arithmetic operations) and if the size of a variable to which the value of the changed variable being assigned to is smaller, the receiver variable is enlarged. The last step is to follow the receiver variables identified in the second step and identify any arithmetic operations they are used in and so on..

Apart from this, can the more experienced programmers provide any suggestions if anything more id to done?

3 Answers3

2

In my current position we use a field reference file (FRF) to hold definitions of the fields we use. Then I can start with changing the definition in the field reference file. If my FRF definitions are set up correctly, and used properly, there should be little left to do besides recompile the affected programs. Now determining what is affected is a whole other kettle of fish. There are tools like Hawkeye Pathfinder which can be an immense help. Otherwise you are manually searching through your whole codebase for uses of a given field.

Finally, you are going to have to ensure that any 5250 screens or print files can successfully contain the expanded fields. This can be a non-issue, or it may require reformatting the display or report.

jmarkmurphy
  • 11,030
  • 31
  • 59
  • thanks for the comment. I have a doubt with respect to Printer files as I have never used this before. So i did come across a few cases where the modified fields where being written to Printer file fields of smaller size. For instance there was a filed as below in a Printer file: N25 TLAACR 9 2 71 The length of the TLAACR field had to be changed to 15.2 to match the source variable. How to confirm this is good? –  Jan 14 '17 at 03:00
  • This seems to be a never ending cycle! as i go deeper and deeper, there are more programs and more fields that need to be changed being identified. So much that I doubt if what is being is correct?? –  Jan 14 '17 at 14:04
  • RDi,you are using RDi, aren't you, has a print file editor that is way better than RLU, or you can lay out the report the old fashioned way manually on some graph paper. – jmarkmurphy Jan 14 '17 at 14:14
  • Yes, a commonly used field is a lot harder to change than one that is only used in a single place. Be careful, sometimes different fields can be named the same in different programs. – jmarkmurphy Jan 14 '17 at 14:17
  • I have a further doubt related to this. Consider the arithmetic operation TOTINVAMT += (WDQTYS * WDPERU); Here I need to increase the size of WDPERU to 15.2 from the earlier size of 9.2. So obviously TOTINVAMT needs to be increased to 15.2. I think there is no need to change WDQTYS. Is this understanding correct? –  Jan 15 '17 at 18:23
  • Yes, but 15.2? That's a lot of clams. – jmarkmurphy Jan 16 '17 at 13:07
1

I would use DSPPGMREF PGM(*USRLIBL/*ALL) OUTPUT(*OUTFILE) OUTFILE(LIB/NAME), when my library list contains all libraries that contain programs using the affected file(s). Query this file to find all programs which reference the affected file(s). Scan these programs for all occurrences of the affected fields. This scan will also point you to any display or printer files that reference these fields.

Montana
  • 81
  • 5
0

At many places in definition specs, consider how relative sizing might be useful:

D ap_asp                        +4    like( APASP  )

In that spec, variable ap_asp is defined to be LIKE() a database field named APASP. The database field is defined as 3P 0, packed-decimal with three digits and no decimal fraction. The compiled definition of ap_asp is then 7P 0, which is four positions ("+4") larger.

If APASP changes in the future, it's almost certain that ap_asp won't need to be touched. Its size will adjust automatically at compile-time.

This won't work for everything. Your printer file field for example might not be possible to change. So a MONITOR for assignment only to that final printed field might be the only one needed in a program.

user2338816
  • 2,163
  • 11
  • 11