Download Article As PDF

1. Overview
This article outlines and describes the components of the SAS® platform and how they relate to each other.

2. SAS® Platform - A Layered and Tiered Approach
To understand the SAS platform you should first understand the four tiers that make up the architecture and then the layers of technology within these tiers.

2.1 Data Tier
At the heart of any SAS license is Base SAS which in turn has three primary layers

• Input Layer
• Processing Layer
• Output Layer

The real benefits of this approach are that once a LIBNAME or FILENAME has been defined it can be referred to by its name from then on without worrying about details, locations or formats. This is what makes SAS so portable. The LIBNAME engines that are part of Base SAS are:

• Native SAS®9 through SAS 6 Datasets or Tables
• Native SAS® Scalable Performance Data Engine Tables
• Sequential Tape Decks or Reels
• SPSS Tables
• XML
• TCP/IP Ports

• Relational Databases - DB2, Informix, ODBC, OLE-DB, Oracle, SQL Server, Sybase, Teradata, and MySQL
• Non-Relational Databases - ADABAS, CA-IDMS, IMS, PC File Formats, and System 2000
• ERP System Access (what SAS calls Data Surveyors) - Oracle Applications, PeopleSoft, SAP and Siebel

• Flat Files (of any record format)
• FTP
• SMTP (email)
• SOCKET
• URL or HTTP

2.2 Server Tier
The majority of SAS processing takes place on the Server Tier. It is the Server Tier that handles, manages or executes all of the three primary layers within Base SAS.

2.2.1 Processing Layer
Within Base SAS code, processing takes place in Procedures, Data Steps and Macros. Those that know SAS code understand that these are amongst the most powerful methods of data manipulation and analytics on the market. In SAS®9, with its persona based GUIs, the need for users and analysts to write SAS code has been removed. SAS® Enterprise Guide®, SAS® Data Integration Studio and SAS® Enterprise Miner™ provide the functionality without requiring knowledge of the language.

However, the SAS 4GL is at the heart of every SAS implementation and understanding its power will enable any customer to further customise, troubleshoot and extend the value of their SAS applications.

2.2.2 Procedures
Base SAS delivers many pre-written and pre-tested procedures to manipulate or transform data. Traditional SAS users and SAS employees call these "procs" because of how they are coded in SAS programs. It is these procedures that are often called from the client GUIs. As a user completes dialog screens they are supplying the values to options in the procedure itself. It is still the case that knowing the actual procedure helps a customer to better know the available capabilities, know how to troubleshoot problems and where to get documentation on what can be accomplished.

Procedures need input data and output destinations. In SAS®9 the ability for an IT administrator to define the inputs and outputs in one place (in the metadata) protects the end user from needing to understand these concepts (the GUIs pick them up automatically), but can also make the programmer's life much easier.

2.2.3 Data Step
There can be no doubt as to the power of Data Step. It can be as simple as a few lines of code that create a data table or view or it can be very complex performing transformations that are beyond the normal scope of rival software or SQL.

The Data Step has hundreds of available functions that can be used to further manipulate data such as functions for date comparison and processing, string handling, hex to decimal conversations and mathematical computations.

The Data Step is an integral part of SAS because it is sometimes needed to prepare, massage or join data to get it into the desired shape for use as the input to a procedure. In SAS®9 the client GUIs are extending the power of SAS to groups of users that are quite unaware of this programming language. However, just like the SAS procedure, the customer that understands SAS Data Step can increase the value of their SAS investment.

2.2.4 Macro Language
The SAS Macro language allows users to write macro code that dynamically creates SAS 4GL code. It can be easily used to accomplish difficult tasks or can be very complex and accomplish amazingly advanced tasks. The Macro language is used behind the scenes in almost all of the SAS GUIs - many times as pre-processing or clean-up tasks. Macros can be written and saved in Macro Libraries that are available to all SAS processes.

2.3 Output Layer
In the same way the procedures data steps can read from any data source with the use of FILENAME and LIBNAME statements, they can also write back to these locations since both are for input and output - with few exceptions. In addition to creating tables many SAS Procedures create other forms of output, such as HTML, RTF or PDF. The capability to generate these result types comes from the SAS Output Delivery System.

Many of the client GUIs utilise SAS ODS behind the scenes to manage output and with each new release the power and flexibility of these output options gets stronger and even more robust.

2.4 Stored Processes
Stored Processes are saved SAS programs that are registered in the central metadata repository, have an added ability to prompt for parameters (ie, Macro Variables), and are callable from many SAS GUIs. All of the information in the earlier sections on the Input, Processing and Output Layers of SAS applies to Stored Processes. A Stored Process can contain all of the functionality and power of SAS and can also be made available to non applications and GUIs.

Stored Processes can be authored by a SAS programmer or by point-and-click via SAS Enterprise Guide. Once created a Stored Process allows the non-programming user to take advantage of these common processes for use in interfaces such as SAS Enterprise Guide, SAS® Web Report Studio, SAS® Information Delivery Portal and SAS® Add-In for Microsoft Office, etc.

2.5 Middle (or Web) Tier
The Web Tier is a layer that enables clients on varying platforms (Windows, Unix, Linux, zOS) running varying application types (Windows, Java, Browser) to communicate with Web applications and servers on other varying platforms. It is a middleware layer that is described better in other papers and documents.

In some situations it is not needed. For example, if a Windows user has SAS Enterprise Guide and PC SAS installed locally on their computer, no Web Tier is needed to do basic SAS processing.

The WebDAV component is optional but needed for applications that require the storing of content, such as Stored Process output, by Web applications for later retrieval.

2.6 Client Tier
The Client Tier is the most visible aspect of SAS®9 and the most obvious change over earlier versions.

The Client GUIs are designed around the personas of the people who use them and make best and most appropriate use of the SAS technologies described above, whilst utilising the most suitable architecture and technology.

SAS Enterprise Guide is a Windows-only application based on the .NET framework from Microsoft. By using Windows technology the power users and analysts get the full functionality they need on an operating system they already use.

IT oriented clients, such as SAS® Enterprise Data Integration Studio, SAS® Management Console and SAS® Information Map Studio are Java applications as their users are as likely to use Windows as Unix operating systems

Mass population clients, such as SAS Web Report Studio and the SAS Information Delivery Portal are web based and need only a browser to use them. This reduces the strain on IT by reliving much of the burden of desktop maintenance.

3. Conclusion
Although SAS has evolved significantly, the traditional skills that many SAS programmers have developed over the years can complement the new ways of working, and still be used to increase the value of a customer's investment in SAS.