Avoiding "collisions" with Spectre Macros

Last updated: 21 Apr 2015


The Spectre macros give little consideration for care of the user's environment. The macros favour speed above all, and by "user's environment" is meant the macros that the user may define and the user's datasets and variable names. The Spectre macros might redefine a user's macro or delete a user's dataset unless a convention is followed to avoid such "collisions". The same goes for global macro variables. No checking of pre-existing datasets or macros is done when a macro is defined or a dataset created by the Spectre macros. Instead, the user needs to be aware of and follow the conventions used by Spectre to avoid their own datasets and macros being overwritten. To add such preventative coding would have merits but would slow down the macros - and Spectre macros need to be CPU efficient so they can run on low power PCs or servers or give maximum processing speed where very large datasets are concerned. Some systems of macros do use preventative coding but this comes at a cost of processing speed that might be justified in many cases. For example, every time a macro is called it might delete and reload all its needed sub-macros and reset its entire environment, and this might take up to two minutes for every macro call (from actual experience) - but such delays would be against the Spectre macro design philosophy of maximum speed.

Dataset name collisions

The Spectre convention with internally created temporary dataset is to start the dataset name with an underscore. What follows the underscore is usually the first part of the macro name. If you use the Spectre macros then your own datasets should not start with an underscore otherwise they risk being overwritten or deleted.

Macro name collisions

Obviously there are a lot of macros in Spectre with the clinical macros and the utility macros. You have to be careful what names to use to define your own macros if working with the Spectre macros. You are more likely to overwrite a Spectre macro than the other way round. For example, at a lot of sites they have a macro named "nobs" that finds out the number of observations in a dataset. Spectre also has a macro of this name and it is important it does not get overwritten in the work.sasmacr catalog by a user-defined macro.

Spectre follows the same macro naming convention as used in the SAS Institute supplied macro library in that all the macros have ordinary, meaningful names with no special prefix to identify them.You just have to know they are there and not accidentally redefine them.

Internally-defined macros (i.e. macros defined within macros) are not limited in scope to operating only within the macro. They are written to work.sasmacr where they might overwrite another macro. The Spectre convention to avoid this problem is that internally definned macros should start with an underscore followed by the first part of the macro name so this is a convention the user should avoid when defining their own macros. The clinical macros %npcttab and %unistats do a mass deletion of macros from work.sasmacr that start with "_npct" and "_uni" (using the Spectre %delmac macro) at execution end.

This is the most difficult area in avoiding collisions. If sites use a naming convention, such as a consistent start letter for a macro, then this is less likely to occur, but the possibility always exists so care should be taken.

Global macro variable name collisions

Spectre follows the commonly used naming convention for global macro variables for a system of macros in that they both start and end with an underscore. When such a variable is set then for the clinical reporting macros it writes a note to the log telling the user what global macro variables have been set and what value set to. It does not do this for the utility macros.

The recommendation to the user of the Spectre system is to not set up global macro variables both starting and ending with an underscore. If the user needs a convention to make global macro variable stand out then two suggestions are 1) to have global macro variables starting (but not ending) with an underscore or 2) starting with a double underscore.

If Spectre macros are called from an existing system of macros then check what global macro variable naming convention is used for the other system of macros. If this also uses the start and end underscore convention then problems are likely to occur and it may not be wise to use both systems together.

Variable name collisions

Some of the clinical reporting macros accept as parameters the variable names defined by the user and internally add other variables. These added variables will start with an underscore. There is a chance of a collision of variable names if the user's variable list supplied to the macro parameters also start with an underscore so the user should avoid having variable names starting with an underscore when passing these datasets to the Spectre clinical reporting macros.


You have learned about the Spectre naming conventions and how to avoid unwanted "collisions" within the user's environment.


Use the "Back" button of your browser to return to the previous page.

contact the author

SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration.