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.
Conclusion
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.
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.