Guru: Ready or Not! Part 3 Of Big Changes In RDi V9.6, Compare/Merge, Code Coverage, and More
June 4, 2018 Susan Gantner
This is the third in my series of tips on RDi V9.6. In this one I’ll cover the new compare and merge support, along with improvements to code coverage and a few other smaller enhancements in V9.6. I originally thought this would be the last in the series, but IBM recently made available a new point release that introduced enough new features to mean I’ll be adding at least one more tip.
Compare And Merge
The ability to compare the content of two source members is not new to RDi, but with V9.6 the facility now offers the option to merge selected blocks of code from one member to the other. Many RDi users may already be using a similar merge facility courtesy of the iSphere plug-in. This new support in the base RDi package is very similar, but not identical, to the iSphere approach.
To begin a compare and merge session, choose two source members in the Remote Systems list view, right click and choose Compare With > Each Other. A new tab will appear in your editor window with the code comparison. Check out the screen shot below to see what this screen looks like. You can see that the color has disappeared — this screen is just black and white. It shows the two source members with any differences between them highlighted and a line connecting the code blocks between the members.
Figure 1: Compare and merge in the editor.
This screen looks very similar to how it looked in V9.5 – except that there are new icons (highlighted in Figure 1) appearing at the top right corner that allow you to apply changes from one side of the screen to the other. The first icon allows you to switch the side the members are on. The next two icons allow you to copy a specific selected difference from right to left or vice versa. Read on for another way to do the same thing. The last four icons allow you to navigate to the next or previous difference or change. As nearly as I can tell, the difference between the “next difference” and “next change” is that the difference option only stops once on a block of code while the changes option will stop at each individual change within a block.
Unless you’re very confident and want to use the option to apply all the changes from one side to the other, you will probably be more comfortable looking at each difference and deciding whether to apply each change one at a time. In that case you could use the icons mentioned above to navigate to the next change and then apply the current change. Alternatively, you may also simply hover over the little box in the middle of the connecting line between the blocks. When you do so, a small pair of arrows appear (right and left) that allow you to copy that specific change from left to right or vice versa, as shown below. Personally, I prefer this option of applying changes over using the icons.
Figure 2: Copy changes individually.
There are a few options you can specify to control the comparison. These can be activated by icons in the toolbar or by the context menu (from a right click) in the compare editor. You may have noticed in my comparison in Figure 1 above that one of the changes noted was simply a difference in indentation within the Select/When block of code. You can choose to ignore such white space differences if you choose. There is a similar option about whether to ignore the source change date. In the image below, the icons to control those features are highlighted. I’ve enabled the option to ignore white space and you can see that as a result the two Select/When blocks are now treated as being the same.
Figure 3: Compare option to ignore white space.
If you look just under the Compare tab near the upper left of the figures, you’ll see a pull-down option that says “IBM i Member Compare.” The other option to choose there is “Text Compare.” The IBM i Member compare type hides the full sequence numbers and change dates and — more significantly — maintains them for the developer as changes made by copying code from one source to the other. Text compare, on the other hand, includes the sequence numbers and change dates and does not maintain them as changes are made. When using Text Compare, a warning pops up the first time you make a change to alert you to the fact that you are responsible for maintaining that information. You can switch between Member and Text compare modes by using the arrow next to the compare type name. Personally, I can’t think of an occasion when I’d choose to use text compare at the moment, but the documentation indicates that it may be useful when using eGit tools.
CL Command For Code Coverage
If you’re a Code Coverage tool user, you’ll be interested to know that there is now a CL command to begin a code coverage session. Read on for details of the command. For those of you who are thinking “What is code coverage?” a brief introduction. Code coverage was first introduced about four years ago. It gives you a way of determining how much of a program (or group of programs or service programs) has been executed during a test. In other words, it helps you to find out how complete your testing efforts have been.
The basic idea of code coverage is that you start a session — specifying what program(s) you want to monitor. Then you run your tests. When you think your testing is complete, you instruct RDi to analyze the data collected during the session and produce reports about what code was tested and, more significantly, what code was never touched during the test. The reports can go down to the line of code level to show exactly which lines were and were not tested.
Those shops who have standard testing processes in place will find code coverage very useful to verify the quality of the testing process itself, whether those processes are manual or automated. Especially when using automated testing tools, it could sometimes prove cumbersome to run code coverage because previously the session had to be started manually via RDi. Beginning with V9.6, the new CODECOV CL command can more easily be integrated into the host-based testing processes already in place. RDi is still needed, however, to produce and view the reports related to the results of the test.
When using the CODECOV command, there are many parameters you can specify, including two required parameters – a command that can be used to do the testing and the module(s) from the program(s) and/or service program(s) you are testing. You will typically also want to specify the location for the output file where the data collected by code coverage will be stored. This location is important to know because you will need to specify it in RDi to analyze and view the results. This is done via a special Code Coverage Results view.
You must be at IBM i 7.2 or 7.3 to use this CL command and you must also have the following PTFs installed:
- V7R3: 5770WDS PTFs SI65229 and SI64655
- V7R2: 5770WDS PTFs SI65228 and SI64544
More Info About V9.6
In response to requests from RDi users via RFEs (Request for Enhancement) a new preference for ILE RPG has been added which will categorize named indicators as fields in the Outline view. This is not enabled by default but if you prefer to see them in your Fields list rather than in the separate Indicators list in Outline, you should turn on that preference.
If you are an iProjects user, you will find some new shortcuts for doing builds and retrieving errors and you can now associate a connection and library for multiple iProjects at once.
ACS (Access Client Solutions) can now be launched from the context menu for the Objects subsystem in Remote Systems. Options appear there now for the full ACS interface and for directly launching just Run SQL Scripts or the 5250 emulator or the database schemas interface. It will launch the version of ACS you already have installed if it is recent enough. If you don’t have ACS installed separately or if it is too old to be launched this way, it will launch the version shipped with RDi, which is currently ACS version 1.1.7.1.
This new version of RDi is based on more recent version (4.6.3) of Eclipse. That new base brought with it a few other notable differences. First, by default the open perspectives (listed near the top right of the workbench) do not contain the name of the perspective. This was done to reduce the space required for them. You can bring the text back for your perspectives by right clicking on one of the icons and choosing the “Show Text” option.
Also due to the Eclipse version change, the print toolbar button has also been hidden by default. It’s not a feature I use myself, but if you do, you can bring it back. Choose Perspective > Customize perspective from the Window pulldown menu and expand the File category to find the Print icon.
As I mentioned, there have been some fix packs or point releases already for V9.6. I plan to cover more of the introduced enhancements in a later tip, including improvements to the Object Table view to make it more PDM-like.
