How to Run SAS Code on Linux

Most answers to this question assume you already have SAS and just want it headless. This one is for the other case: the programs exist, the licence does not, and the job still has to run on the server tonight.

The short answer

Jenner is a single binary. Put it on the server, point it at a .sas file, and it runs — no GUI, no display, no licence server to reach, and nothing to check out at start-up. It exits non-zero when the program fails, which is the part a scheduler actually cares about. If you are still comparing options, the questions below name every route a Linux user really has, including the ones that are not us.

Built for the way Linux work is actually run

Call it from cron, from a systemd timer, from an Airflow task, from a GitHub Actions job, or from inside a container. It reads from stdin and writes to stdout and a log file, so it composes with the tools already on the box instead of asking for a session.

What runs on Linux

Jenner is SAS-compatible: the language your programs are already written in, executing on the server with the same statement and option names you use now.

DATA steps, PROC SQL, and macros

The core of the language runs as written — DATA step logic, arrays, formats and informats, the macro facility, and PROC SQL. Code written against SAS 9.4 syntax does not need a porting pass before it will execute.

100 procedures

Regression and linear modeling, survival analysis, multivariate methods and clustering, time series, quality control, summary and reporting. Every procedure has a published reference page listing the statements and options it supports, so a scheduled job's dependencies can be checked before it is scheduled.

The files already on the server

Jenner reads and writes SAS7BDAT and XPT directly, alongside CSV and Parquet. Datasets on a mounted volume or an object store do not need converting first, and output can be written back in the format the downstream job expects.

The same program the analyst wrote

The same source runs on Linux, macOS, and Windows. A program developed on someone's laptop runs unchanged as a scheduled job here, which removes the rewrite that usually sits between analysis and production.

Results you can demonstrate

Jenner passes all 58 datasets in the NIST Statistical Reference Datasets benchmark — the standard third-party accuracy suite for statistical software. The procedure reference is published in full, so the claim that a specific PROC is supported is one you can check before you put it in a pipeline.

Start Free TrialSee the procedure reference

Frequently Asked Questions

Install the Jenner binary and run it against the file. It is an independent implementation of the SAS language, so it executes .sas programs directly on Linux without SAS present and without a SAS licence. Nothing is converted first — the program on disk is the program that runs.

Yes. Linux is a supported platform for SAS 9.4, so this is not a platform problem the way Apple silicon is. The obstacle is the licence, and on a server it is usually also the licence server: a box that cannot reach it does not run.

Yes. There is no GUI and nothing that wants a display. It is an ordinary command-line program, which is what makes it usable on a machine you only ever reach over SSH.

No. Jenner is a clean-room implementation of the SAS language and does not embed, wrap, or call SAS software. There is no licence to renew and no licence server for the job to fail against at two in the morning.

Copy the binary into the image and invoke it as the entrypoint or from your own script. It does not need a daemon, a display, or a network call to start, so a container that runs it is as small and as reproducible as the base image you chose.

Yes, and this is a common reason people arrive here. Because it is one binary with a meaningful exit code, a CI job can run a .sas program as a build step and fail the pipeline when the program fails. Scheduling from cron, a systemd timer or Airflow works the same way.

Yes. A failing program exits non-zero, so cron mail, a systemd unit, or a pipeline step sees the failure rather than a clean run with an error buried in the log. This is worth checking on anything you adopt: a log full of red text and an exit code of zero is how overnight failures stay invisible.

That is the intent. The same source runs on Linux, macOS and Windows, so the analyst's file and the scheduled job's file are the same file. Coverage is not the whole language, so the honest way to confirm it for your code is to run it in both places and compare the logs.

Altair SLC also runs SAS-language programs without a SAS licence, on Linux included, and has been doing it far longer than we have. For a server estate where someone else's edge case has already been hit and fixed, that track record is worth real money. Price both. Siemens now sells it as Rapidminer SLC, so it is worth searching under both names.

Often that is right, and on a server it is more tempting than elsewhere because the surrounding tooling is already Python. If the SAS code is small, or the team is leaving SAS anyway, rewrite it. The case for running it as-is is strongest when there is a lot of it, it is validated, and rewriting means re-validating rather than merely re-coding.

Run your SAS programs on your Linux servers

One binary, no licence server, and an exit code your scheduler can trust.

Start Free Trial