Guru: Compare Pieces Of Source Members
April 19, 2021 Ted Holt
Next to Barbara Morris, the F15 key seems to be the RPG programmer’s best friend. I do not like duplicated source code, but for years I have been finding it everywhere. Sometimes I find the same source code in multiple source members. Sometimes I find the same source code two or more times in a single source member. If you’ve been programming in an IBM i shop for more than two hours, you know what I’m talking about.
As I wrote three years ago in this august publication, duplicated source code is bad because it embodies the WET principle, whereas DRY is better. That article dealt with one technique I use to find duplicated source code. Today I’m pleased to publish a utility I use to determine whether a section of source code is truly duplicated or not.
This story contains code, which you can download here.
I wrote this utility several years ago because I needed something that would compare two sections of a single source member to see if they were duplicates or not. The Compare Physical File Member (CMPPFM) command compares entire source members. It was too “noisy” for my purposes, so I came up with the idea of copying pieces of one or two source members to temporary source members, and having CMPPFM compare the temporary members. It’s not rocket science, but I learned years ago that rocket science doesn’t put product on the shipping dock.
My utility is built from four source members.
| Name | Type | Description |
| CMPSRC | CMD | The command interface |
| CMPSRCC | CLLE | The command processing program |
| MOVPGMMSG | CMD | Brian Rusch’s command interface over the QMHMOVPM API |
| RSNESCMSG | CMD | Brian Rusch’s command interface over the QMHRSNEM API |
If you missed the last two when we published them in 2012, here’s a second chance to get them. They are fabulous. I put all four members into the downloadable code, along with a text file with the necessary object-creation commands.
Once you’ve created the objects, type CMPSRC on a CL command line and press F4. The system will prompt you for the qualified file name, member name and range of source code sequence numbers for the two sections of code you want to compare.
These are the parameters.
| Name | Description |
| FILE1 | The qualified file and member name that contains one section of source code. |
| RANGE1 | The first and last sequence numbers of the first file member. |
| FILE2 | The qualified file and member name that contains the other section of source code. Leave the file name blank to compare two sections of source code within the same source physical file member. |
| RANGE2 | The first and last sequence numbers of the second file member. |
Be aware that the sequence number field is defined as 6,2 zoned decimal in source physical files. This means that you must key the decimal point if there’s a non-zero digit following the decimal point. However, you don’t have to key leading zeros. If you edit in SEU, you’ll have no trouble remembering the decimal point because SEU shows them to you. If you use the LPEX editor in RDi, as I do, you may forget to key the decimal point until you get used to using the utility.
Once I determine that two sections of code are identical, the refactoring fun begins. I often move duplicate code into a subroutine, and from there into a subprocedure. If two sections of source code are almost identical except for a slight difference, such as a field or variable name, I parameterize the code. Once a routine is in a subprocedure, it may very well end up in a service program. What better home could there be for a routine that has been needed in many places?
