advantages of SAS UNIX

[anil]

All,

I have observed that SAS programmers in clinical trials (Phase II-IV) prefer UNIX to EG and SAS 9.1.3.

I request experts to elaborate the advantages of it.

Curious,

Anil

[1162]

I'm not an expert, but I'll start things off anyway.

Unix is an operating system while EG and 9.1.3 are SAS software products. SAS runs on Windows or Unix (or other platforms) so if you want to use SAS and you want to use the Unix operating system, then you buy and install a Unix version of SAS v9.1.3.

The issue may be more about a preference to write custom scripts rather than use EG. This may be in part because of the very structured formatting of the tables and listings for clinical trials. I haven't used EG, but I think I know enough about it that I wouldn't ignore this product for getting you through 75% of the required programming.

The issue may also be about comfort level. I've done some SAS programming for clinical trials and have used SAS 9.1.3 on Windows without any resistance or complaints. The preference for Unix may also be related to the OS on which the programmers 'grew up'. There are some benefits to using an OS that 1) programmers are comfortable with and 2) may be more compatible with other data sources or software products.

[Doc_Duke]

To follow-up on 1162's comments.

If you are working in an FDA regulated environment, then it is marginally easier to validate things once in a more controlled environment than to have to lock-down all the PCs.

Enterprise Guide will run all the sorts of structured code that our shop has and has the addition of a natural interface for documentation and ordering analyses. It doesn't do as well of allowing multiple users to work simultaneously on the same project (maybe in 4.2).

EG can run on the PC and the SAS on the Unix box. Some groups are doing that. EG is very nice for diagnostic graphics from the statistical modeling procedures; they are needed some for secondary analyses.

Doc Muhlbaier

[deleted_user]

Also, Unix offers a number of powerful yet easy-to-use (after gaining some familiarity with the environment) built-in tools for searching and manipulating text. Frequently referenced are grep/egrep/fgrep for searching masses of text using regular expressions, e.g. for extracting warnings, notes, and errors from logs, or for finding all uses of a particular macro in dozens of .sas files. One can write shell scripts that launch a sequence of SAS programs, perhaps performing sophisticated manipulations of the output of one program before passing it as input to the next. Follow that up with automated processing by having the system invoke the shell script at specific times to produce reports, backup files, etc. The possibilities are endless, making unix, in my humble opinion, the ideal support environment for SAS development, at least for those willing to learn how to work in it.

[deleted_user]

Unix has been 64-bit at lot longer than Windows, and the servers have superior floating point performance over Intel processors.

It is generally easier to secure a Unix box than a Windows box. Mainframes are the best at this, still.

Unix can run on more than 8 processors very effectively: 32, 64, 128.

Unix has superior IO performance tuning/ability over Windows, and SAS is highly IO intensive -- writing and reading the work datasets.

Scripting (batch wrappers) are easier and significantly more powerful than on Windows, generally. Unix shell scripting in bash (Linux), Korne shell, Bourne shell, C Shell, Perl is basic common stock and trade for most any Unix user. Batch scripting on Windows (DOS artifact) has become obscure, and the other Windows command language (VBA) is not as pervasive amongst Windows users on a percentage basis.

Unix boxes are real servers, not that Windows can't be, but the point here, is that EG and PC SAS run on your local box. Regular production runs of SAS jobs should not be dependent on the availability of anyone's particular PC. These jobs are usually scheduled with scheduling products like Control-M. Control-M can run a COBOL job on a mainframe, creating a VSAM file; and then, based on the job's return code as an in-condition, kick of a SAS job on a Unix box that uses SAS/CONNECT and SAS/ACCESS to read the VSAM file directly and do additional stuff with the data, ending in loading an Oracle database sitting on another server. Then the scheduler could kick off another process that runs on a Windows server because some developer wrote a tool that runs only on Windows, and accesses data in some database (Oracle in this case), and the company has to have that tool for some business reason. Through the use of in-conditions and out-conditions, the scheduler can run a process flow without worrying about the timing of when a job might/should complete so that the next one in a series can start. This is superior to using cron on Unix and Scheduled Tasks on Windows to manage processing flows.

EG is a great front end tool for ad hoc analysis and reporting of data. But for regularly performed stuff, you can't beat SAS batch run from a scheduler on a reliable server.

[Hima]

• You can run multiple programs at a time in batch mode using the command ---> nohup sas sasprogram.sas &. This will execute the job behind the scenes.
• Cron jobs can be scheduled via Unix SAS.