Guru: How Do You Do That With RDi? Part 3: Complex Compiles
June 19, 2017 Susan Gantner
In an earlier tip I tried to convince RDi users to give up compiling in PDM because the RDi compile interface has the time-saving Error List to offer. I offered some tips that help me with my compiles in RDi. Here I’ll continue my “Compile in RDi” campaign by offering some additional ideas for those who have more complex compile processes.
There are two common issues I hear that keep people returning to PDM for their compiles. One is that their library lists aren’t set up correctly for the compile and the other is that they need to do something in addition to a simple compile command – typically some overrides or some other kind of pre- or post-compile steps. I’ll address both of those issues here.
Assuming you have taken my advice from my earlier compile tip to change the preference to turn off the default behavior to “Compile in batch,” it is easy to tell what library list will be used for your compiles. Simply expand “Library List” in the Remote Systems view. If you’d like some tips on how to temporarily modify the library list that you see there, refer to earlier Guru tips written by myself and by Ted Holt. You can change the default library list that your connection uses as I described several years ago in this tip.
If for some reason you must use the “Compile in Batch” option, then you may want to check out the “Job description” setting on that same preference page to make sure the initial library list in the job description is what you need. In the Remote Systems pane, right-click on the appropriate system, and choose Properties. In the navigation pane of the Properties window, click on Subsystems. You will find the job description setting on the Commands tab in the contents pane.
Pre- Or Post-compile Steps
Some developers tell me they need to do something more complex than the standard IBM compile commands that appear as RDi Compile options. One of the most common requirements I’ve heard for this is that there is a need for one or more override commands to be issued prior to doing the compile. One simple way to deal with this requirement – assuming you are not compiling in batch with RDi – is to simply do the override command(s) (or call a CL program that does the override for you) using the command entry box at the bottom of the Commands Log view. Make sure you use the “Normal” option for the command to make sure it affects your currently connected RSE server job.
There is a non-RDi-specific solution to the need for an override that works well in many cases, at least for RPG IV programs. Simply use the EXTDESC keyword in the F spec or Dcl-F in RPG. That way you can specify the file that will provide the compiler with the external description. After that, you can do away with any special handling for compile-time, whether compiling with RDi or PDM (which I hope you won’t be doing from now on).
If you use a PDM user-defined option or perhaps just a CL program or command that you created to do your “special” steps, then you can create a customized compile option just as I described in my previous compile tip. In the last tip, however, our customized compile options simply provided special non-default values for parameters on the regular IBM compile commands. You can also create a customized compile option if you need to use your own command or program, but you need to know a small trick in order to get the primary benefit of compiling this way to work, i.e., getting your Error List feedback to work.
Just as we did when customizing the IBM compile commands, you start the process by using “Work with Compile Commands…” from the Compile menu. Then choose “New Command” from the list of compile commands. Put in the name you want to use for this compile in the list in the Label box. Then put the name of your CL command into the command box, remembering that CALL is a perfectly good CL command if you haven’t created a CL command specifically for the process. Note when you do this that you can prompt the command if you want to make it easier to add parameters. If you need to pass parameters to your program, notice the “Insert variable…” button that allows you to use some of the same substitution variables that are commonly used with PDM user-defined options – such as &N for the name of the source member you are working with, &F for the source file name, &L for the library name, etc.
Before you hit the “Create” button on your custom compile option, you need to add the “trick” to ensure any compile errors will appear in the RDi Error List. To do this, simply add a comment to your command which contains the keywords “*EVENTF” – or the more complete OPTION(*EVENTF) if you prefer – and “SRCMBR(&N)”. The figure below shows an example of the necessary comment. Including those two keywords in a comment in the command string provides RDi with the information it needs to retrieve the event file generated by the compiler. If you leave out the comment with the keywords, your compile option will work to compile the program, but it won’t be able to produce that helpful error feedback, which is the primary advantage of using RDi for compiles.
I hope that I’ve now convinced at least some more of you RDi users out there who still use PDM for your compiles to give RDi’s compile and error feedback facilities a try. Looking at compile listings to find errors is just so 1990s. If you have a special situation so that the ordinary compile options don’t work for you, try creating your own RDi compile options. And remember that when using RDi for your compile, change the default parameter value on your compile command to specify “Output(*None)”. Then you won’t have the hassle of deleting all those compile listings that you’ll never need to look at again!