To keep you up to date with news about this web site, I will issue a newsletter
from time to time. I will probably issue one about every three months but
sometimes it will be more frequent, other times less. It all depends on
how many changes I make. You can link to all the current and past newsletters
below. They are in MS Word format so that they are suitable for printing.
If you don't have MS Word (I don't) then there is always OpenOffice
software you can download for free which will read and print these documents.
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
bound to each other. The more complex macros rely on lower level macros and
if these macros change then the more complex macros might encounter errors or
it might change their functionality. This has to be avoided so my macros are not
in the spirit of being "open source". Any changes to them are only safely
made by me, since I know their dependencies. So instead of "open source" you
should regard the code as educational that shows you how macros can work
together. But as for using these macros -- you are free to use them as if they
were open source. Use them freely but don't amend them.
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 content of 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, 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?
Something most people don't like about these macros is that they are very tightly
linked. You call one macro and it might call others which in turn call others which
in turn might call others. You call one macro and you might end up calling twenty or so.
Most programmers are not used to this. It's "bad" but it has to be that way. I use many of the smaller macros in many places and
to avoid duplicating the code I have to keep them as lots of separate macros so that I can maintain them.
And I use the sasautos approach in that all the 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.
The patient profiler described in the article is similar in parts to the PPD
Patient Profiles.
PPD Patient Profiles
I have written an entirely independent version of a graphical patient profiler,
inspired by Ya Huang's creation, which I thought was a brilliant design achievement.
I have put a lot of man-hours of my free time into this as 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.
For these reasons stated, it is with much pride and pleasure that I have released
my graphical patient profiler such that all can use it for free. It is now released as
a compiled and stored macro that you can download from this web site. You can
link to the patient profiler page below. Feel free to use it and if you encounter bugs
then please send me details.
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.
Clinical reporting macros %unistats and %npcttab
There are two major clinical reporting macros I wrote for the Spectre (Clinical)
reporting system named %npcttab
and %unistats.
They rely on some other macros. They are designed so that you can run them
independently of the clinical reporting system they were designed to work
with. All the documentation on how to use them comes with the Spectre (Clinical)
e-book that you can download in the next section but to give you an idea
on how the %unistats macro works and what it does there is a short PowerPoint
demonstration you can link to below. You will see actual code run and output
produced.
unistats.pps
Through late 2007 and early 2008 I put a lot of work into upgrading these macros
so the current documentation is not up to date. I'll be updating and moving this
documentation out of the Spectre e-book and into this web site when and if time
allows. This may take some time as it has now reached the stage when I must stop
working on these macros due to other commitments. I now no longer support these macros
for users who use them for free. As for fixing bugs, although these may get reported to me
it may take me a long time to fix them. I use these macros myself and tend to fix bugs
when they affect my own work. They are highly complex macros and fixing a bug and updating
the documentation to go with it can take up to 8 hours. This is time I can no longer afford.
The only way I can justify this work is if users have a support contract with me.
A new major version of %unistats (and %unicatrep) is planned that will have added
a dsparams= parameter to define a single-observation dataset whose variable names and
their values will be converted to macro parameters of the same name and their values.
This is for advanced users (as no checking will be done). The reason this is needed is
because the number of macro parameters will be increased to allow for different ODS
reporting styles and for this it becomes easier to store values in a sas dataset.
I plan to release these versions in 2009, as I have other commitments for 2008, but
these releases will be brought forward if those with a support contract with me request it.
Spectre (Clinical)
Spectre (Clinical) is a clinical reporting system I wrote from late 2003 onwards.
It used to have its own web site but now you have 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 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) - 16 Feb 2008 macros.zip (macros) - 03 Aug 2008 scripts.zip (scripts) - 29 Jul 2007
Spectre (Clinical) can be downloaded from the following page which will
also give instructions on how to set it up as an e-book.
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.