SAS 9 Content Assessment: Code Check

2 Likes

Continuing the series of posts on the SAS 9 Content Assessment reports, we review the SAS 9 Code Check report to see what information it provides, what conclusions can be drawn from it, and what likely actions you would take after reviewing it. As a reminder, this series of posts does not cover how to run SAS Content Assessment applications; instead, it focuses on using the results. Check out this post and demo for information about running the SAS Content Assessment.

SAS 9 Content Assessment Code Check

SAS 9 Code Check examines SAS programs to determine compatibility with SAS Viya. It examines SAS 9 code stored in program files on the file system. The SAS Code check will check the code for the following:

Syntax elements that are not supported in SAS Viya 4
Syntax elements that might have processing restrictions in SAS Viya 4
Hard-coded physical paths.

Before we examine what we can learn and what we can do with what we learn, let’s see how the code is checked. In the SAS 9 environment, we have SAS code in programs that reside on the file system in a directory "d:\\workshop\\gelcorp" and SAS code in SAS artifacts like Enterprise Guide projects, Stored Processes and Data Integration Jobs. We want to check all of this code. For the programs on the file system, we can run code check directly against the directory where the files are stored, and all files with a .sas extension in the directory or any sub-directories will be checked. The scan tag is used to tag the data from this scan, and the tag can be used to subset the data on the report.

codeCheck.exe --scan-tag basecode --source-location "d:\\workshop\\gelcorp"

SAS artifacts such as SAS Catalogs, Stored Processes, Enterprise Guide Projects and User-written code in Data Integration Studio jobs cannot be processed directly by Code Check. A companion tool, Gather SAS Code, can generate SAS code from these artifacts and write it to the file system, supporting code assessment with Code Check.

gatherSASCode.exe --all
codeCheck.exe --scan-tag bidi --source-location "d:\\workshop\\SAS9ContentAssessment\\assessment\\gatheredSASCode"

Multiple Code Check reports focus on each type of artifact; the format of each report is the same. In this post, we will use the SAS 9 Code Check for the SAS Viya Report, which surfaces the results for all scanned items.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

What can we learn?

Let’s look at the SAS 9 Code check for SAS Viya Report to see what we can learn.

The overview page summarizes all the programs scanned and provides general statistics such as the % Compatible Programs, % Incompatible Programs, % Compatible Statements, % InCompatible Statements, etc. From this page, you can understand how easy or difficult it will be to run these SAS programs on SAS Viya. The tag filter allows the user to subset the report based on the scan tag. In our case we will select the “basecode” scan tag to focus on the results for SAS programs stored on the file system.

Let’s look at the incompatible programs to see what issues the reports surface.

One key thing we can discover in the report is which SAS programs have syntax elements that are not supported. This information is provided on the Incompatible Programs Tab. The report below shows three categories of incompatibility.

PROCEDURE: a SAS procedure that does not run on SAS Viya
ASSIGNMENT: an assignment statement that uses a syntax element not available in SAS Viya
LIBNAME: a libname statement that will not work on SAS Viya

You can click on a row in the table to see the line of code with the incompatible statement. Let us look at one from each category. The first row in the report shows an incompatibility related to the LIBNAME statement. The details show that the line uses an information map libname. Information maps are a 9.4 artifact that does not exist in SAS Viya.

The PROCEDURE category surfaces SAS procedures that will not run in Viya. If we use the filter on the left, we can see that our code contains 8 procedures that will not run on SAS Viya. The procedures operate on the Metadata Server or the LASR Analytic Server; neither server exists in SAS Viya.

The ASSIGNMENT category surfaces programming elements that are not available in SAS Viya. A review of these items shows they are all metadata data step functions. These functions cannot run in SAS Viya as SAS Viya has no metadata server.

In addition to incompatible code, the report also flags syntax elements that might have processing restrictions in Viya 4. On the SAS Viya platform, the SAS Compute Server and the SAS/CONNECT Server are LOCKDOWN enabled by default. This security measure in the SAS Viya Platform restricts access to specific system files and SAS language features. Here are some key reasons that LOCKDOWN disables features:

Access Methods: Methods like EMAIL, FTP, HTTP/URL, and SOCKET are disabled to prevent unauthorized data transfer and communication, which could expose the system to security vulnerabilities.
SAS Language Features: Features such as PROC GROOVY, PROC JAVAINFO, and PROC PYTHON are disabled to limit the execution of external code that could potentially harm the system or access sensitive data.
Functions and CALL Routines: Functions like ADDR and ADDRLONG are restricted to prevent direct memory access, which could be exploited to manipulate or extract data inappropriately.

These restrictions help maintain a secure and controlled environment, ensuring only authorized and safe operations are performed within the SAS Viya environment. SAS 9.4 was more permissive than SAS Viya so the Code Check report flags, functions, access methods, procedures, and features in the code that may not run by default in SAS Viya. If you attempt to use a resource that is locked down, SAS issues an error message to the SAS log.

The Code Check report surfaces this information in the Review:Warnings tab. The report shows that our code has some elements that may not run by default in SAS Viya.

The Review Hard-coded paths tab lists the locations in the SAS 9 code where file system paths are referenced. In SAS Viya running on Kubernetes, the paths to files on the file system, such as SAS programs, data files, etc., may differ from those in SAS 9.4. You can use the report to identify hard-coded paths in libname and filename statements, SAS procedures, %include statements etc.

The report has two tabs we have not covered: Review: Library Engines and Advanced: Explore Details. The Library Engines tab documents all the library engines used in the SAS programs, and Explore Details allows us to drill down on the CodeCheck results in several different ways.

What do we do with what we learned?

Now that we have reviewed the content of the Code Check report, what can we do with what we have learned?

The code flagged as incompatible must be rewritten for use in SAS Viya. Any code that accesses the SAS Metadata server will no longer work in SAS Viya. In the SAS Viya architecture, the information stored in the SAS 9..4 metadata server is stored in other places like the SAS Infrastructure Data Server and the SAS Configuration Server. In SAS Viya, similar functionality is available using the SAS Viya REST APIs. Another example of a change is PROC IMSTAT, which was used to process data in the SAS 9 LASR Analytic server and would likely be replaced by PROC CAS to process data in the CAS Server in SAS Viya. The table below presents some common incompatibilities (thanks to Joseph Kneen for creating this table).

Code with processing restrictions may be a little easier to deal with. Some elements can potentially be replaced with other, more secure techniques. An alternative to changing the code in SAS Viya is to modify the LOCKDOWN settings to allow the restricted elements to execute. Lockdown can be modified to allow specific features. Check out the SAS Viya documentation regarding using the LOCKDOWN System Option and the LOCKDOWN Statement. This approach has some risks, as the SAS Viya environment will not be fully secured. However, this could be done temporarily and/or in a separate SAS Viya compute context until a more secure technique is implemented.

The report also flagged hard-coded file system paths, which, in many cases, may need to change in SAS Viya. If the hard-coded paths need to be changed in SAS Viya, then help is available. Another SAS Content Assessment Application, modifySASCode, can update paths in SAS code in batch. Before running modifySAScode, you need to execute Code Check. The Code check results are copied to the ASSESSMENT_INFILES directory in the Content Assessment install directory. The modifySASCode application uses the results to generate a mapping CSV file. You edit the mapping CSV file to map the old paths (SAS 9) to the new paths(SAS Viya). ModifySASCode uses the mapping CSV file to apply the new, modified paths to the SAS program files. It updates new copies of the SAS program files in the specified output location. It does not update any original SAS program files. Comments for each update are written in the new SAS program files. Check out this video to see CodeCheck and the modifySASCode application in action.

Wrap up

SAS 9 Code Check examines SAS programs to determine their compatibility with SAS Viya by analyzing SAS 9 code stored in program files on the file system. A companion application, gatherSASCode, can generate SAS code from SAS 9 artifacts to be processed by code check. It checks for syntax elements that are not supported in SAS Viya 4, syntax elements that might have processing restrictions in SAS Viya 4, and hard-coded physical paths.

The code check results are presented in a series of reports. The reports can be used in the migration planning phase to identify the level of effort required to migrate SAS 9 Code to SAS Viya. The report's details can help plan and execute the migration of SAS code to SAS Viya.

Here are some related resources, including the first two posts in this series:

Find more articles from SAS Global Enablement and Learning here.

SAS Communities Library