Make “Program Call” macros rename automatically (MAGIC and Client/Server)

You may know that you can make a macro in a report that can be called as a program, rather than used as a block of code that is incorporated into your main report logic based on a keyword in a footnote. This has certain advantages, but if you make a copy of your report and fail to track down and change the program calls, your new report will still call the macros from the original.

In this month’s tip, we will show how you can add some code to a “start” macro of your report that will use the name of the new page program to make sure that you always call the “program macros” of the current report, without needing to track down and edit the program calls every time you make a copy.

The big advantage of making your macro a program is that it is completely separate code with separate variables. Two big advantages: you do not need to re-translate your report after changing the macro and you can change the value of subscripts in the macro without worrying that you will affect the behavior of the report by possibly changing the value of a subscript the report is looping on.

A typical use of a macro as a program would be to create a download file:
(C/S Version shown, for MAGIC just omit the PFF NO footnote).

The two macros look like this (MAGIC versions):

 

The difference for Client/Server (C/S) is that you cannot send a tab character to the printer without surrounding it with some extra codes so that it can sneak by the print manager:

Important Note: If you do not do any output in the picture, you will get a “no records found” message at the end of the report, and if your export is large, the report will run slowly. To fix this for both MAGIC and C/S, add a call the @.line in your “detail” macro. We don’t need to do this in this example report because we have an HR and D region in our picture, so the report will call @.line per record for us.

Now (finally), onto the tip. When you call a macro with a keyword like this: AL D your.macro.name, if you make a copy, the new version of the report uses “its own” macro. If you call it as a program (start with %, pass arguments in ()) like this AL D %ABS.PAT.zcus.is.your.report.M.macro(A), unless you change the call in the copy, you will call the macro of the original report. It is easy to miss this if you call your macro from a line attribute or computed field.

Fortunately, the report keeps its own name in a slash variable called @.new.page.pgm (translates to /R.NEW.PAGE.PGM). For MAGIC, the value stored is the name of the report with a “.R” at the end. In C/S, the value stored is the internal name of the macro, including the prefix. If we write a start macro that uses the data stored in @.new.page.program to build the program names from the report name in @.new.page.pgm, we can be sure that any copy of our report will call its own macros, with no hand-editing necessary.

For MAGIC, we can attach a start macro that creates two program names in two variables, using the @.new.page.pgm value, then modify the footnote to call the programs using those variables:

Then we modify our footnotes to call the start macro and to call the programs using the HEADER and DETAIL variables we set up in the start macro.

The C/S code is just slightly different, as we have to cope with the fact that the @.new.page.pgm holds the translated name of the program. If you use the “List Object Code” option in Process Reports, you can see what these look like:

So, our start macro has to use some extra dots, and in the footnote, we call the program from within square brackets with no % sign on the outside:

We put two dots between the M and the macro name:

And we call the macros like this [MACRO](0)

C/S and MAGIC versions of this example report ABS.PAT.zcus.is.eupdate.local.macro has been uploaded to our report library.