Now is a good time to download my macros as they are all extremely stable. The reason being
that my SAS licence has expired and I can't afford to pay for a new one. What you can download
below is my 2500 hours of contributions to SAS macro coding spent over 25 years of my life that has
now come to an end. Enjoy!
Copy and paste the above line of code into your sas session and run it three times if your session gets
stuck in that you submit things and see it echoed in the log but it does not
do anything. If you see the ">>> NOW WORKING" message starting at column
one in the log then your session just came back to life again (hopefully).
%aetab available
A clinical reporting macro has been added to Spectre that can do multi-level AE
reporting beyond the current three-level reporting limit of %npcttab. Note that there
is a current limitation in that only Western character sets will be correctly aligned
with this macro. The same applies to the style=3 reporting for %npcttab. This is
because it uses the utility macro %splitvar to do the alignment and this assumes
one letter takes up one byte. This is not the case for many Asian character sets.
A new version of %splitvar called %ksplitvar will hopefully be made available in the
future to overcome this limitation but this will rely on this macro being supplied
to me, most likely from China.
%aetab
Clinical Reporting macros must be licensed for commercial use
Because the SAS Learning Edition is no longer available I have to ask for a licence fee for
using the Clinical reporting macros. The time I have put into writing the entire Spectre
system stands at about 2500 hours of which 250 hours was maintenance and development for
the year 2011. This is not
excessive for an ongoing development of such size and complexity but it does not make sense
for me to continue with this beyond 2011 unless it is financially viable.
Therefore, from 2012, I must charge for the commercial use of the Clinical Reporting macros
that you can download from this web site. I have set the yearly licence fee at 10% of the
individual SAS licence fee renewal per programmer. For Europe, the renewal SAS licence is about
€2000 per year and for China about €1110 per year so the licence for the macros will be 10%
of the regional individual renewal price per year (applicable sales tax to be added).
Block discounts are available to large organisations (the minimum block size is 50).
The utility macros and system macros will continue to be free to all users and if you are just
studying the Clinical Reporting macros or using them purely for demonstration purposes
and not for real reporting or QC work then there is no licence required. If you are
evaluating the suitability of these macros then you are permitted to use them on two studies
without a licence.
The conditions and licence fee is now clearly stated on the download page.
Old-time SAS programmers will be familiar with the macros %left and %trim.
These have been supplied with the sasautos library distributed with copies
of SAS for many years. They behave like macro functions and yet they are
macros. They have now been made redundant, because %sysfunc calls can replace
them, but %left and %trim have been used by programmers for years not knowing
or caring whether they are macro language functions or macros. You use
them in the same way. There is no rationale as to why some of these macros
are there and some not. You might be familiar with the %words macro that
you can find on the SAS Technical Support site. That has never been a member
of the supplied sasautos library and yet it is obviously a useful macro
to have there. The point is, it is up to you to decide what utility
macros you want to make available and to create them if you need them.
Obvious candidates for adding to the sasautos library are the very useful
function calls used in SCL for extracting variable and data set information.
In SCL you need to open the data set and give it a file handle before you
can get this information but it is easy enough to write this code into
a macro in a way that the whole macro behaves like a macro function. I
have used this technique for many of the sasautos extension macros. This
is not at all efficient when you are making many of these calls, because
the data sets are being opened and closed multiple times when once would
have been better, but when you are developing more complex macros, such
as I have done for some clinical reporting macros, then the convenience
outweighs the efficiency considerations.
Since 1987 I have been building up my collection of low-level, general-purpose
utility macros. Every time I have spotted the need for one, I have written
one. I have asked many other people to tell me what macros would be useful
and created them if I could see a need. The result is that my collection
of macros is very comprehensive and the number of them stands at over 150.
If you ever think of a macro, the chances are that it is already in my
macro collection. I would put that probability at higher than 95% so my
collection is a very good place to start looking if you are thinking you
need a macro to do something general-purpose and low-level, especially
in the field of clinical reporting. To see these macros in alphabetical
order plus their searchable descriptions then use the link below.
From time to time I get asked why I don't distribute my macros under an
"Open Source" license. This sounds like a good idea except that the idea
of "Open Source" encourages software to be improved upon. Again, this sounds
like a good idea but the trouble with my macros is that they are tightly
interlinked. The more complex macros rely on lower level macros and if
these lower-level macros change then the more complex macros might encounter
errors or it might change their functionality. This has to be avoided so
any changes to them are only safely made by myself, since I know all their
dependencies. So instead of "Open Source" they are public domain
software (this does not apply to the clinical reporting macros) and this
suits many of the smaller utility macros since they are
just commonly-used code (i.e. already "public domain" knowledge) encapsulated
into a macro. But as for using these macros, you are free to use them as
if they were Open Source. Use them freely but I advise against amending
them for the reason stated.
Are there bugs in these macros?
Almost certainly. All complex software has bugs in it no matter
who tells you otherwise. And if not bugs, changes are required, sometimes,
for the software to be more useful or understandable. You will see from
the "Bugs and changes log" page below that there have been many bug fixes
and changes made to these macros. More bugs will be found in the future
and more changes made. I don't feel I am a bad programmer because of this.
It is normal for this sort of thing. For those who used to work on IBM
mainframes, even the program IEFBR14 had bugs in it or at least
had to be amended more than once to get it to work properly. And what did
IEFBR14 do, you might wonder? I will tell you -- it did nothing.
It was a null program that would instantly return control to the calling
program by using the instruction "BR 14" which means "Branch to the address
in register 14" so the only instruction it originally contained was one
to exit the program. Even that went wrong so don't expect my macros to
be entirely bug free as, collectively, they are about a million times more
complicated. Because of this, if you intend to use these macros in a production
environment, especially the more complex macros, then it is only wise to
do so if they are covered by some sort of support contract.
Having said that, it is very rare I have found a bug in one of the simple
low-level macros. The bugs are nearly always in the complex reporting macros
but I am giving no promises. To give you an idea of how reliable the macros
are, please read the "Bugs and changes log" that you can link to in the
"Spectre (Clinical)" section near the end where you can see what work I
have done on these macros over the past two years or more.
How to use the macros
All the macros you can download here are intended to be put in a library
and included on the sasautos path. The major macros often call lower-level
macros so these will only work correctly if all these macros
are made available and declared to the sasautos path. I sometimes get asked
by email why the major macros don't work and why it is complicated by them
calling other macros but this is the whole point of this web site and the
approach it takes. It is all to do with the "sasautos extensions" idea
that I advocate and by that I mean building your own library full of all
the utility macros you will ever need and putting them on the sasautos
path. If you do this right then all the macros will work correctly and
you should be far more productive in your work.
What's BAD about these macros?
The biggest complaint I get about my macros are that most are not stand-alone.
They call other macros. I have to design my macros this way to remove code
duplication. I place the commonly used routines in small macros where I can
maintain the code in one place.
I use the sasautos
approach in that all the utility macros I need are in one library and this
library gets declared to the sasautos= system option. In other words, it
is a second autocall library. You got one of these autocall libraries
from the SAS Institute with your copy of SAS and now I am giving you a
second library which you are supposed to put on the sasautos path in front
of SASAUTOS. If you are working on your own PC or in your own work area
then this is easy enough. The trouble comes when you use my macros to create
a solution that other people are supposed to use. You then have to install
my sasautos library somewhere centrally where all the users can access
them. Here it gets more difficult as most sites will not want to see all
these macros appear - especially in their production area and especially
because none of my macros have been formally validated. However, what might
be acceptable, is a minimum set of these macros that are needed to implement
a needed solution. How to identify a minimum set of macros and copy just
those macros across to a library is explained on the page you can link
to below.
On this website I present a challenge. That is to tell me which macro I
am missing in the sense of utility macros of use in the field of clinical
reporting. I have 170+ macros on my website and I think I have the complete
set. I don't know much about statistics, so I am making no claims about
that, but if you are in the field of clinical reporting then I am openly
making the claim that I have a complete set of macros for you to use in
that field. If I lack a macro then TELL ME! I will read your description
of what it needs to do and if I feel it is needed then I will write it.
You can email me using the link at the bottom of this page.
SAS software tips and techniques
As I think of them, I will be adding my own sas tips and techniques to
this site. You can get to them by clicking on the link below.
The patient profiler described in the article is similar in parts to
the PPD Patient Profiles.
PPD
Patient Profiles
I wrote an entirely independent version of a graphical patient
profiler, inspired by Ya Huang's creation, which I thought was a brilliant
design achievement. I consider it to be a very important enhancement to
the clinical trials process. Clinicians, who follow the progress of clinical
trials, will know about the serious adverse events and the successes. They
will probably find this out via telephone calls or faxes because the data
from the clinical trial will be "unclean". Indeed, I have had access to
this unclean data from many clinical trials and it is truly unclean, even
with wrong years for events. It takes months to sort out the irregularities.
But there is a lot of useful data in there that could be used for the benefit
of patient safety. If the clinician had access to the data and could visualise
the situation, they could, perhaps, spot danger-signals for patients on
the trial, based on the profile of patients who have already withdrawn
from the trial or patients who had suffered drug-related adverse events.
If the data were clean enough to use, and the patient profiling software
were good enough and flexible enough, then perhaps potential problems could
be spotted in advance, much to the benefit of patient safety.
As a sas programmer working on Linux/Unix, you may think you do not need
to learn Unix beyond knowing how to use some of the common commands. This
is largely true but if you work in a high-production environment, such
as clinical trials reporting, then having a good knowledge of Unix commands
and being able to write shell scripts can increase your efficiency and
make your work easier, so learning more about it becomes worthwhile. To
help you in this, I have written several pages to do with Unix and using
it with SAS software.
If you have never written shell scripts before and your knowledge of
Unix is limited then you are better off using this link.
If you already have a shell script library you use and you want to hunt
for more useful tips and shell scripts then go direct to this page.
Spectre (Clinical)
Spectre (Clinical) is a clinical reporting system I wrote from late 2003
onwards. It is webbed here but it is better to download it and set it up
on your PC as an e-book. It is more suited to being an e-book as it is
of an advanced technical nature and not something you can "dip into" and
browse. It is a full and complete clinical reporting system with shell
scripts, sas macros and extensive documentation. Its SAS macros are the
same ones you can download from this web site so you will not find any
more macros there. You can link to it below.
Spectre
(Clinical)
You can download Spectre using the link at the end of this section.
What follows is the current status of Spectre that you can download.
Bugs
and changes log spectre.zip (documentation) - 23 Jan 2012 clinmacros.zip (macros) - 26 Jan 2012 utilmacros.zip (macros) - 29 Jan 2012 sysmacros.zip (macros) - 08 May 2011 scripts.zip (scripts) - 23 Mar 2011
Spectre (Clinical) can be downloaded from the following page.
Spectre download
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.
