Technology Tales

Porting SAS files to other platforms and versions

SAS uses its transport file format to port files between operating and, where the need arises, different software versions. As with many things, there is more than one method to create these transport files: PROC CPORT/CIMPORT and PROC COPY with the XPORT engine. The former method is for within version transfer of SAS files between different operating systems (UNIX to Windows, for instance) and the latter is for cross-version transfer (SAS9 to SAS 8, for example). SAS Institute has a page devoted to this subject which may share more details.

The power of pipes

One of the great features of the UNIX shell is that you can send the output from one command to another for further processing. Take the following example for instance:

ls -l | grep "Jul 12"

This takes the long directory file listing output and sends it to grep for subsetting (all files created today in this example) before it is returned to the screen. The | character is the pipe trigger, and you can have as many pipes in your command as you want, though readability may dictate how far you want to go.

Using alternative editors for SAS programming

When it comes to writing SAS programs, most use the tools that SAS gives us, be it Enterprise Guide, the Enhanced Editor or the Program Editor. While Enterprise Guide can work with UNIX SAS as the processing engine, it is very much a Windows tool and the Enhanced Editor functionality is provided through Windows-only programming (ActiveX, I seem to recall). However, that means that creature comforts are left behind you if you turn to writing SAS code using UNIX SAS; you have only got the good old-fashioned Program Editor supplied by SAS itself. However, there is a trick that you can use to make life more comfortable: SAS does allow you to submit the contents of your paste buffer (or clipboard) using the command SUBMIT BUFFER=DEFAULT and this can be assigned to a function key for ease of use (I use the same key to clear the log and output screens at the same time). In the Windows, you may need to explicitly copy the code to do this but, in UNIX, merely highlighting a section of code with an editor like NEdit will do the trick and, given that NEdit is reasonably pleasant tool for code cutting (the ability to define its macros with a spot of scripting is a definite plus point), this makes life more comfortable again.

Using SAS FILENAME statement to extract directory file listings into SAS

The filename statement's pipe option allows you to direct the output of operating system commands into SAS for further processing. Usefully, the Windows dir command (with its /s switch) and the UNIX and Linux equivalent ls allow you to get a file listing into SAS. For example, here's how you extract the list of files in your UNIX or Linux home directory into SAS:

filename DIRLIST pipe 'ls ~';
data dirlist;
    length filename $200;
    infile dirlist length=reclen;
    input buffer $varying200. reclen;
run;

Using the ftp option on the filename statement allows you to get a list of the files in a directory on a remote server, even one with a different operating system to that used on the client (PC or server), very useful for cases where cross-platform systems are involved. Here's some example code:

filename dirlist ftp ' ' ls user='user' host='host' prompt;
data _null_;
    length filename $200;
    infile dirlist length=reclen;
    input buffer $varying200. reclen;
run;

The PROMPT option will cause SAS to ask you for a password, and the null string is where you would otherwise specify the name of a file.

Checking existence of files and directories on UNIX using shell scripting

Having had a UNIX shell script attempt to copy a non-existent file, I decided to take another look for ways to test the existence of a file. For directory existence checking, I was testing for the return code from the cd command, and I suppose that the ls command might help for files. However, I did find a better way:

if [ -f $filename ]
then
    echo "This filename [$filename] exists"
elif [ -d $dirname ]
then
    echo "This dirname [$dirname] exists"
else
    echo "Neither [$dirname] or [$filename] exist"
fi

The -d and -f flags within the evaluation expressions test for the existence of directories and files, respectively. One gotcha is that those spaces within the brackets are important too, but it is a very way of doing what I wanted.

The joys of eBooks

Octals in UNIX shell scripting

I have just discovered that if you have a number with a leading zero, such as 08, it is assumed to be an octal number, that is, one of base 8. The upshot of this is that you get errors when you have numbers like 08 and 09 in your arithmetical expressions; they are illegal in octal: 08 should be 10 and 09 should be 11. Of course, as luck would have it, you get exactly these expressions when date/time processing. Luckily, you can force things to be base 10 by having something like 10#08 or, when extracting the minute from a date-time value, 10#$(date +%M). Strange as it might appear, this behaviour is all by design. It is dictated in the POSIX standard that governs UNIX. That said, I'd rather it if 08 was interpreted as an 8 and 09 as a 9 rather than triggering the errors that we see, but that could have been seen as muddying the simplicity of the standard.

Trying out OpenSolaris

Having been programming (mostly in SAS as it happens) on Sun's venerable Solaris operating system platform at work since the start of this year, the chance to try OpenSolaris x86 edition in a VMware virtual machine seemed a good opportunity for advancing my skills.

Before this, my exposure to Solaris was when I was at university and things have moved on a bit since then, not least on the technology side but also in terms of my own skills. In those days, my mindset was fixed by exposure to macOS and Windows with their point-and-click functionality; the fact that the terminals that we were using were ancient didn't make for a positive impression. You can see below what I mean. And the concept of tackling a command line, even one as powerful as that in UNIX, armed with a good book was somehow foreign to me.

Mind you, in those pre-Safari days, getting your hands on books not in the university library was an expensive outing for the student finances. Armed with years of programming and web development experience, the UNIX command line now looks like a powerful tool to be used to the greatest advantage. Years of exposure to Perl and Linux have made the tool a less daunting one for me. Also, the availability of shell scripting makes the Windows batch file language look positively archaic. The default ksh shell (I believe that it is ksh88) in Solaris is not as friendly as it could be, but bash is available on demand, so life isn't that uncomfortable on the command line.

To date, my experience of OpenSolaris has been brief because I wrecked the installation while trying to sort out an annoying graphics issue that appeared after installing VMware Tools (drivers for various pseudo-devices) on OpenSolaris; I have yet to put things back. The installation procedure is pretty painless for what is a technical operating system. The Community: Tools section of the OpenSolaris website has articles on installation and installation under VMware is discussed on Developer's Quarterdeck Log.

As regards a desktop environment, you have a choice between the ubiquitous Gnome and Sun's own CDE, of which I have seen plenty at work. As it happened, I installed the developer edition, but there are the usual Linux mainstays on the desktop: StarOffice (in place of OpenOffice), GIMP, Mozilla Firefox, etc. One thing that I wasn't able to sort out was the internet connection, and that may be because ZoneAlarm was blacklisting VMware at the time of installation. All in all, it looked like a far friendlier environment for users than that which I encountered during my early years on UNIX. I must get it back in action and take things on from here…