History and Common Usage

Macros are a simple name/value string substitution mechanism, where the macro value is substituted for the macro name when used in a Program. This single one-pass string substitution process occurs just prior to program execution. These macros are also created as a variable of the same name in the Runtime Programming Environment (RPE).

Since macros are also generated in the RPE, and because it provides greater flexibility, use of the RPE is strongly encouraged. Macros continue to be supported and provide a relatively easy way to work with variables. For example, a program used as the edit program in a Format would still likely use a macro to get the name of the checked in file to be edited.

The main limitation to macros is that they are available only for the program that calls them. When working with nested programs, the RPE enables you to pass values between programs, using get env MACRO.

Although the operating system determines the valid syntax of the commands, the typical syntax used is:

command ${"MACRO 1"} ${"MACRO 2"} ...

When using macros be sure to enclose them in quotes to allow spaces. (An exception to this rule is the OBJECT macro (see Business Object Identification Macros).

RPE variables can be redefined (and possibly unset) by subordinate programs, for example called programs, utility programs such as load and validate in trigger programs, range programs, and so on. To minimize the potential for unwanted name collisions, you should develop a naming convention for your RPE variables, and ALWAYS move macro variables into your RPE variables right away.

Also see the Studio Modeling Installation Guide for descriptions of the environment variables MX_JIT_TRIGGER_MACROS and MX_NESTED_TRIGGER_MACROS.

Macros are populated in the RPE as each subordinate program is called. These macros will remain in the RPE until the parent program execution has completed. With MX_JIT_TRIGGER_MACROS=true, users should be aware that there are conditions where these macros will not be able to be evaluated outside the subordinate program for which they were instantiated-- such as a disconnect trigger that removes a connection between 2 businessObjects. In this example, the macro ISFROZEN will be available, but if a user attempts to get this value outside the disconnect trigger, they will receive an error.