A: I have consolidated my entire collection of macros into one
library and they just so happen to be stored here on the Spectre web site.
I had to do this because I could not continue to maintain a separate Spectre
macro collection as a subset of the full macro collection due to time constraints.
There were good reasons for having separate Spectre macros at first, the
main one being so that the validation effort could concentrate solely on
those macros that Spectre needs. However, as the Spectre macros get enhanced,
more macros from the main macro library need to be copied across to support
them to the point where it is better if all macros are regarded as potentially
needing validation so all the macros might just as well be stored together,
which I have now done.
Q: Why are the all Spectre scripts written in the bash shell?
A: Because the bash shell is easy to program in, is widely available
for free, has good functionality and is a widely used interactive shell
so a lot of people are familiar with it. Ksh-93 is probably better at time
of writing but it is not a free shell, not widely available and its advantages
do not matter for the sort of shell scripts used in Spectre. By using the
bash shell I hope there is a greater pool of programmers available to maintain
the Spectre scripts and write new ones as the need arises. I regard the
shell scripts in Spectre mostly as throw-away code that links the components
of Spectre together. I hope programmers will be in the position that they
can see the need for and write shell scripts for Spectre as they see fit
at any time so that the components of Spectre can fulfill their reporting
needs in a variety of situations. Spectre is really an infrastructure and
was never intended as a fixed reporting system.
Q: What if I want to keep the titles and footnotes in a spreadsheet instead of using Spectre ".titles" members?
A: That is no problem. So long as your spreadsheet is storing
all the information that Spectre needs, you could create a file exactly
like ALL.TITLES from your extracted spreadsheet fields so that the Spectre
script "crtitlesds" can read it in or you could create the "titles" and
"protocol" dataset by a direct method so long as it entirely matched the
structure needed by Spectre. If the latter, then you should perform the
same error checking that Spectre does.
Q: How do I break the 10 titles, 10 footnotes limit? I need to do this to copy a client layout style.
A: I plan to build in the flexibility to handle this by allowing
you to declare a client pagexofy macro to enable you to add extra titles
and footnotes to the output file at the same time as adding the "Page x
of Y" labels.
Q: How do I filter out some categories I am not interested in showing using %unistats?
A: If it is "no" responses you want to exclude then one way is
to reset these to missing in a data step and use the parameter missing=no
so that these now missing values are not shown. You can also use the filtercode=
parameter for very simple editing of the report dataset. For other categories
you can post-process the output dataset to drop these categories and then
call %unicatrep to produce the report as shown in Demo 12 for %unistats
that you can link to here.
Q: Can I show the "%" sign for %unistats and %npcttab percentage values?
A: Yes. For both macros you can specify pctsign=yes to
make these appear.
Q: Can I combine two values in one line using %unistats like turning min and max values into a range?
A: Yes and since version 5.0 of %unistats this has been made
very easy. You just specify your stats labels together with no spaces inbetween
such as "Min;Max" to the descstats= parameter and the macro will
do the rest. You can get truncation sometimes but you can set mincolw=
to a suitable value or change the length of the numeric formats to widen
the column to avoid truncation.
Q: The field width used by %unistats is 11 bytes which is not wide enough for me. How can I make it wider?
A: The field width is controlled by the "catnfmt" parameter which
by default is catnfmt=3. The field width is this format length plus 8 bytes
(includes 5 bytes for the default percentage format pctfmt=5.1). If you
set the parameter pctsign=yes then an extra byte is allocated. To make
the field wider then increase the catnfmt= format length to catnfmt=4.
, catnfmt=5. etc. until it is as long as you want or set the parameter
mincolw=
(minimum column width) to a suitable value.
Q: I want to use Spectre on Windows but I do not want to install Cygwin. Will Spectre still work?
A: Yes, Spectre will still work on Windows without Cygwin but
none of the Spectre scripts will work. Because the "titles" and "protocol"
datasets are built using a script, you will have to write a sas program
to do this instead, but this should be easy to do since the script calls
macros to do this, namely %crtitlesds
and %crprotds so you
can call these macros in your sas code. If it is just the reporting macros
%unistats
and %npcttab you want to use then these will work on any platform
and how to do this for Windows is explained on this
page.
All the demonstration of these two macros shown on their main pages were
done on my PC outside of the Spectre system and without using Cygwin so
you can do the same.
%unistats
%npcttab
Q: What email client should I use on Cygwin?
A: There is currently no "mailx" for Cygwin so you need
to download "ssmtp" from the Cygwin "mail" directory. Make sure
it is working by using the testemail
script and making amendments where you need to. When "mailx" has been ported
over to Cygwin and is reliable then use of "ssmtp" will be dropped from
the Spectre scripts. The only use Spectre makes of the email client is
to send an email to the user telling them when a long-running production
script has finished so it is not important in any case.
Q: When will the Postscript and PDF scripts work for Spectre on Windows?
A: This is being worked on.
Q: Will the Windows version of Spectre work exactly like the Unix version?
A: It will be very similar but you will probably choose to use
Wordpad on Windows to edit or view files while you are pointing to the
same directories on Cygwin. Wordpad can also be called directly from Cygwin
to edit files and how to do this is detailed elsewhere in this FAQ.
Q: Can I use Wordpad from a Cygwin terminal window?
A: Yes, you can call Wordpad directly from a Cygwin window, and
I encourage you to do so, but you have to make sure the directory where
wordpad.exe
is stored is on your PATH statement. It will not be there by default (although
the Notepad directory is probably there). If you have a shortcut
to Wordpad then look at the properties of the shortcut and where it is
stored will be in the "Target:" field. In mine it says "C:\Program
Files\Windows NT\Accessories\wordpad.exe" so I have added it to my PATH
in my .bashrc file like this.
| PATH=$PATH:/cygdrive/c/"Program Files"/"Windows NT"/Accessories |
When you call Wordpad you should run it as a background task by having
a "&" at the end of your command line. Not only will you be
able to carry on using commands in your Cygwin window in this way but you
will also be able to open other files using Wordpad -- but again -- remember
the "&" at the end.
| wordpad filename.ext & |
Note that Wordpad does not understand Unix-style directory names.
If you use Wordpad then it is best limited to viewing or editing files
in the current directory.
Q: I am browsing a file using Notepad but the lines are all joined together. What is wrong?
A: Notepad expects the file to have DOS line endings which have a line feed and carriage return at the end of every line. Unix and Linux files do not have these carriage returns (only a line feed) so if one of these files are opened in Notepad then it thinks everything is in one line. The solution to the problem is to use Wordpad instead. Wordpad understands these files and shows them as separate lines and will add carriage returns if you save the file after editing it. After you save a file you have edited in Wordpad you will find that Notepad can now read it correctly since these carriage returns have been added.
Note that Wordpad does not understand Unix-style directory names.
If you use Wordpad then it is best limited to viewing or editing files
in the current directory.
Q: I am using Cygwin but can't navigate to the "C:" directory. How do I find my way around?
A: Cygwin follows the same convention as Unix so a root directory
must begin with a slash that looks like this -- "/". Windows have root
directories that start like this "C:\". To get to the "C:" drive on Cygwin
then there is a special "/cygdrive/" notation you must use, so to
navigate to the "C:\" drive on Windows going through a Cygwin window then
you should use "cd /cygdrive/c". Once you know that then
you will have no problems navigating to the directory you need to.
Q: What Linux emulators are recommended for Spectre on Windows?
A: I only know Cygwin
well enough to recommend it although there are others about such as UWin
and WSH (Windows Script Host, aka Interix). I recommend Cygwin because
it has been around for a long time so most of the bugs should have been
fixed and I know it has all the utilities that Spectre needs (I have it
on my PC). Also, Spectre scripts are bash shell scripts and bash
is the normal shell for Cygwin. For other Linux emulators you might have
to download bash from somewhere else if it does not come with the package.
Also, a very important thing, Cygwin should be installed with a Default
Text File Type of "DOS / text" (not the recommended way) so
that you can edit command files using Wordpad and not run into problems.
I don't know if other Linux emulators have this facility that you will
need.
Q: What options should I use for installing Cygwin?
A: At the start of installing Cygwin you will be shown a screen
that shows the directory it will download to and below it on the left will
be "Install For" for which you should choose the recommended "All
Users" (unless you really don't want other people to have access to
it) and on the right "Default Text File Type" for which you should
change the default so that it becomes the non-recommended "DOS /text".
Q: What is the minimum configuration for running Spectre?
A: If you are running on a pure Unix or Linux platform then you
will need a Linux/Unix version of SAS software. If on a Windows platform
then you will need a Windows version of SAS but to run the Spectre shell
scripts you will need a Linux emulator installed such as Cygwin.
The bash shell must be present (the default for Cygwin) and gawk 3.1.4
(or higher) should be installed as well as the "lptops" utility ("lptops"
for Unix/Linux installations only). Assuming you do not need SAS/GRAPH®
software then a lot can be done with Base SAS software but calculating
p-values for numeric variables will require SAS/STAT® software. More
details can be found on the installation
page. SAS Learning Edition contains all the modules you require but you
are limited to 1500 observations (for SAS/LE 4.1) so you can not use that
for production work.
Q: I am using SAS® Learning Edition. How can I make the Spectre macros automatically available as sasautos macros when I invoke it?
A: You can add the Spectre macros to the sasautos path in your
autoexec.sas
member. If you do not already have an autoexec member then you can set
one up. If you are using SAS® Learning Edition 4.1 then you can place
this in the same directory as the sas executable (sas.exe) which
should be in C:\Program Files\SAS\SAS Learning Edition 4.1 directory
(assuming that when you installed SAS Learning Edition you let the directory
names default). I have done this and this is what my autoexec.sas member
contains. You may have placed the macros in a different directory but the
change should be obvious. You will see some other options required by Spectre
in the entry below.
| options noovp nodate nonumber xsync noxwait;
options sasautos=("C:\spectre\clinmacros" "C:\spectre\utilmacros" SASAUTOS); |
Q: When doing clinical reporting, what does Spectre expect from the autoexec.sas member?
A: The required system options "noovp nodate nonumber xsync
noxwait" must be set and the Spectre macros defined to sasautos as
was done above. If sas is started from the clinical reporting folders then
sasautos
should be set to all needed macro directories in the correct order with
the Spectre macros and SASAUTOS last. That is all. Do not allocate
any study libraries in autoexec.sas or call a macro that does this
as for new studies there won't be any datasets to allocate and perhaps
no allocation macros to call. You might call a macro from within autoexec.sas
to set up sasautos but when autoexec.sas ends this should have been done.
I use a high-level
autoexec.sas on my PC that is stored in the same
folder as the sas executable and my directory structure for clinical reporting
is explained below and this is what the code looks like for my autoexec.sas
(best viewed as the source file).
Q: I wrote my autoexec.sas member that allocates all the macros correctly. Now, how do I assign the data libraries and formats?
A: Spectre requires that you have two macros to do this named %allocr and %allocw. %allocr assigns data libraries and formats in read mode and %allocw does the same for write mode. Within these macros you must set up a global macro variable named _ptlibref_ set to the libref of where the "titles" dataset and "protocol" dataset are to be stored.
These macros are required for the Spectre scripts so you should use
these for all allocation purposes. You might have low level macros to do
this or high level macros. I use low level macros for this such that one
has to be written for every study increment. You can see two examples of
them below.
%allocr
%allocw
Q: I am using Cygwin (or another Linux emulator). How can I call SAS on Windows from my scripts?
A: To call SAS from the Linux emulator you will have to add the
directory that contains the sas executable (sas.exe) to your PATH declaration.
If you don't know where it is located then do a file search for "sas.exe"
on Windows on the SAS directories contained in the "Program Files" subfolder.
You should also add the Spectre scripts to the PATH statement. Also, because
SAS on Windows will not recognise Unix-style path names, you will have
to declare your home directory in a way that SAS will understand it. For
the Spectre scripts that call SAS, a variable HOMEW is set up and
exported for this. You can set this up in your .bashrc file (or
it might be .bashrc_own or another file name). The relevant entries
in my .bashrc file (I use Cygwin) are shown below.
| # Add Spectre scripts to the path as well as the sas executables
# For SAS Learning Edition 1.0 on Windows 98
# For SAS Learning Edition 4.1 on Windows XP - note that file names
containing spaces must be quoted
# Set up HOMEW as a Windows path so SAS on Windows knows where my
home directory is
export HOMEW |
Q: Why are there different versions for scripts that call SAS on Windows?
A: For every shell script that calls sas, there is a mirror Windows
script whose name ends in "_win". This is a different version of
the same script that does not rely on the "-stdio" feature of SAS
that will be there for pure Linux or Unix implementations. For the "_win"
version, sas code will be written to a temporary file and that file name
supplied to the "-sysin" statement instead of feeding the code into
standard
input (which is by far the better method to use on pure Unix or Linux
platforms). This could all be done in the same script but it keeps things
neater and easier to maintain if separate scripts are used. If you are
running on Windows then you can call the main script as normal but it will
automatically branch to the "_win" member if it detects you are running
on Windows.
Q: Will there ever be a GUI front end supplied with Spectre?
A: There is a future possibility of a GUI front end for Spectre
and at the time of writing it is envisaged that it will be written in "python"
and make Spectre platform independent but as yet, no decision has been
made. At this stage it is not clear whether the envisaged GUI front end
will require a Linux emulator for Spectre but it seems likely. If I ever
get round to writing one, it will only be made available to clients with
a support contract with me.
Q: The ".lis" output files always have the same name (before the period) as the program that created it. Is it possible to change this so that it fits in with our site naming conventions?
A: This is possible using the "lisfile:" line in the ".titles"
member. I would urge people to use it sparingly as an important thing about
any reporting system is to know what program created what output. If you
break this relationship between program name and output file name then
you will not be sure what program created what output and you might be
obliged to write both the program and the output file name somewhere in
the output such as the final footnote.
Q: A p-value I need for one of my variables is not supplied by the %unistats macro. Does this mean I can not use the %unistats macro to produce the table and I must code everything by hand?
A: No, you should still use %unistats with print=no so
that it produces an output dataset and no print but do not ask for a
p-value for that variable. You can then merge in the p-value you need
into the output dataset after you have calculated it and then you can call
%unicatrep to finish the job of producing the report. See the Demo
12 example on the unistats page as a guide to show you how to do this.
The macro was designed to work in that way.
Q: What sort of directory structure do I need for clinical reporting?
A: If you haven't got one already then consider that a formats
directory and sas macro directory would sometimes be needed at every level
with the format search path and sasautos search path going from the lowest
directory upwards. If you are a CRO then you will have different clients
and each client office might have different standards, formats or macros
so it is best if your directory structure distinguishes the office within
the client even if not needed for some clients. This is the directory structure
I have set up on my PC for pharma reporting for purposes of illustration.
What you see is the output from the script dirtree
run from the "C:\pharma" directory which equates to the "/cygdrive/c/pharma"
directory on Cygwin. I have one imaginary customer called "xenuyama" with
an office in Tokyo. They have a drug they call "DRUG001" and the protocol
is for their first phase III trial which is named "DRUG001C3001". I am
working on the "24weeks" increment.
| xenuyama
formats macros tokyo DRUG001 DRUG001C3001 24weeks data analysis derived raw formats macros progs formats macros formats macros formats macros |
Taking this illustrative example further, I am doing a lot of work in
the 24weeks programs directory for xenuyama so in my .bashrc file
(might be .bashrc_own for you) I have set up a user environment
variable so I can jump to this directory using "cd $xyprogs". Here
are the two lines I put in my .bashrc file so I can do this.
| xyprogs=/cygdrive/c/pharma/xenuyama/tokyo/DRUG001/DRUG001C3001/24weeks/progs
export xyprogs |
This is me jumping to that directory direct from my home directory in
a Cygwin session.
| Roland@DELL1 ~
$ cd $xyprogs Roland@DELL1 /cygdrive/c/pharma/xenuyama/tokyo/DRUG001/DRUG001C3001/24weeks/progs
|
Q: I have set up the margins and paper type in the protocol member but I am not getting the linesize and pagesize values requested by the client.
A: Spectre will calculate linesize and pagesize values correctly
but if your client has special needs for linesize and pagesize values then
you can override what Spectre calculates in the client titles macro.
Q: I need to make a system call from one of my sas programs. What is the best way to do this?
A: If you make a system call from one of your sas programs then
try to write it so that it will work on both Unix and Windows. Use "systask
command" rather than "x", especially if you are running on Windows,
to avoid command windows flashing up and disappearing. If using "systask
command" then consider whether you should wait for the system call to complete
before you do any more sas work. If you do then use the "waitfor"
statement. If, for example, your system call was to delete an output file
that you were then going to write to in your sas code then you should make
sure the system call has finished before you write to the file otherwise
it might get deleted after you have written to it. Here is a snippet of
code from the %openrep
macro that illustrates this.
| *- delete temporary file if it already exists -;
%if "&sysscp" EQ "WIN" %then %do; systask command "erase &outfile" taskname=del; %end; %else %do; systask command "rm -f &outfile" taskname=del; %end; waitfor del; |
Q: What sort of power server do I need to run Spectre?
A: Spectre was developed for a single processor server
and ran live on it for many months without any performance problems so
its power requirements are very low. The SAS licence is cheaper for single-processor
servers so the power needs of Spectre have been deliberately kept low.
Its macros do a lot less error checking than is usual to achieve that.
But you have to remember that Spectre is a back end system. If you
are using a GUI front end that is resident on the same server then power
requirements will be higher (approximately double or more) and there will
be more traffic on the network in refreshing the graphics. For Spectre
without a front end then I would recommend having one processor for every
project suite of programs that you intend to run in parallel on a regular
basis. For multiple projects that will never have their suites run in parallel
then you can make do with a single processor server indefinitely, thus
minimizing licence costs.
Q: Does Spectre need expensive Unix administrators to look after it?
A: No, Spectre administration can all be done with a single Spectre
administrator who could also be doing the job of a clinical trials SAS
programmer. Spectre places no demands on Unix administrators beyond the
usual requirements of making backups, etc., but sometimes you may need
to use their services for copying files to other directories as the "root"
user, thus keeping existing timestamp and ownership details unchanged.
Some help from a Unix administrator will be required during the installation
of Spectre on Unix.
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.