Technology Tales

Platform-independent file deletion in SAS programming

11^th September 2025

There are times when you need to delete a file from within a SAS program that is not one of its inbuilt types, such as datasets or catalogues. Many choose to use X commands or the SYSTASK facility, even if these issue operating system-specific commands that obstruct portability. Also, it should be recalled that system administrators can make these unavailable to users as well. Thus, it is better to use methods that are provided within SAS itself.

The first step is to define a file reference pointing to the file that you need to delete:

filename myfile '<full path of file to be removed>';

With that accomplished, you can move on to deleting the file in a null data step, one where no output file is generated. The FDELETE function does that in the code below using the MYFILE file reference declared already. That step issues a return code used in the provision of feedback to the user, with 0 indicated success and non-zero values indicating failure.

data _null_;
  rc = fdelete('myfile');
  if rc = 0 then put 'File deleted successfully.';
  else put 'Error deleting file. RC=' rc;
run;

With the above out of the way, you then can clear the file reference to tidy up things afterwards:

filename myfile clear;

Some may consider that SAS programs are single use items that may not be moved from one system to another. However, I have been involved in several of these, particularly between Windows, UNIX and Linux, so I know the value of keeping things streamlined and some SAS programs are multi-use anyway. Anything that cuts down on workload when there is much else to do cannot be discounted.

Octals in UNIX shell scripting

9^th February 2007

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.