FOCUS AREAS

• Analytics Life Cycle
• Base SAS
• Graphics
• Enterprise Management Integration
• Migration
  • Planning Your Migration
    • - Data
    • - Software
    • - Hardware
    • - Dependencies
    • - Validation
  • SAS Migration Utility
  • PROC MIGRATE
  • Industry-Specific Answers
  • National Language Support
  • Papers
• Scalability & Performance
• SAS for Containers
• Statistics & Operations Research

Hot Topics

• Migration for Metadata-Based Deployments
  • Moving to SAS 9.4
• Calculators
  • Compatibility Calculator
  • PROC MIGRATE Calculator
• Papers
  • Peaceful Coexistence: Multiple SAS Releases
  • Migration Planning Worksheet
  • More papers...
• SAS Notes
  • for data migration and compatibility
  • for metadata-based deployments

Related Links

• Install Center
• Section 508 Accessibility
• Expanded Table of Contents
• Contact Us

Software

Migration

Updating Base SAS Code

SAS programs are commonly saved as text files, with a .SAS file extension, to be run in batch mode. You might also own custom applications that contain SAS code. PROC MIGRATE does not move SAS programs to the target installation. Instead, you must use your normal transfer tool, such as an FTP tool.

Below are the few known compatibility issues. Programs that you created in a previous version of SAS will run correctly in the target SAS deployment when you make these changes.

About SAS Component Language (SCL) code

Most of the issues on this page apply to SCL code as well. SCL code generally exists as catalog entries, but it can also be stored in an external text file that is called by an %INCLUDE command. Any change you make to SCL code requires a recompile to pick up the changes.

First determine whether your existing SCL catalogs are compatible in the target environment. SAS does not support update processing for incompatible catalogs, so you must migrate incompatible SCL catalog entries to a compatible SAS release in order to edit them.

Most Recent Compatibility Issues

For changes to default behavior that can cause different results than in previous releases, see these documents. Look for the chapters about product-specific details.

• SAS 9.4 Guide to Software Updates
• SAS 9.3 Guide to Software Updates

Common Issues

Here are some common compatibility issues to look for in your code.

Backward compatibility of enhancements

If you don't migrate your data to your current SAS release, beware of using any new functionality in your SAS programs and applications that does not work against the legacy SAS files. For example, the DATECOPY option is not supported when you use the COPY procedure and the XPORT engine to create a Version 6 or 7 file; and a few new file features are not supported in prior releases. For a brief summary of compatibility issues, see the topics that link from Cross-Release and Cross-Environment File Compatibility, and refer to SAS documentation for full details.

Catalogs

The behavior of a catalog entry can change in a new release and cause undesired behavior.

Hardcoded values

Fix any hardcoded values such as pathnames, engine names, values specific to the operating environment, and so forth.

• Pathnames can appear many language elements, for example, SAS options; LIBNAME, FILENAME, FILE, and INFILE statements; and FILENAME and PATHNAME functions, to name just a few. Also look for pathnames in macro variables.
• When you use PROC MIGRATE, embedded librefs associated with a SAS data view are not changed when migrated.
• You might choose to specify the engine name in a program to get version-specific processing, for example, the V6 compatibility engine.
• If you alter or update the operating environment, then any SAS code that directly calls operating environment commands (for example, manipulating files, printing) must be recoded to the new operating environment's commands. See your SAS Companion for language elements that are specific to an operating environment.

Macros

Beginning in SAS 9.1, the IN (#) operator is supported in macro expressions. SAS 9.0 and previous versions did not support it. Because IN and # now have meaning to the expression evaluator, any time these values appear in an expression context and are not meant as the IN operator, you must quote the values using either one of the macro quoting functions or double quotation marks. For example, the expressions

   &state=in
   &var = #

must be recoded as

   %quote(&state) = %quote(in)
   %quote(&var) = %quote(#)

or

   "&state"="in"
   "&var" = "#"

National language support (NLS)

If you take advantage of the multilingual capabilities of SAS, see information about a few migration issues that are a result of SAS enhancements.

Output Delivery System (ODS)

• ODS templates in item stores (styles, tagsets, and tables) might not be compatible from an earlier release. A best practice is to use PROC TEMPLATE to update the template for the current release. See a special topic about migrating ODS templates. The ODS documents item store is compatible from previous releases if you don't change to a different operating environment.
  
  
• Starting in SAS 9.1, ODS generates HTML 4.0 output by default instead of HTML 3.2 when you issue the ODS HTML statement. This can be important, for example, when you use the NOTOP argument. Some formatting specifications have been moved to the cascading style sheet (CSS). Therefore, if your code includes NOTOP, then you do not get the CSS formatting unless you specify the HTML 3.2 standards. If this is an issue, then your choices are to update existing ODS code to the HTML 4.0 standard, or to issue the ODS HTML3 statement, or to toggle the registry entry to HTML3 (which makes it the default).

User-defined names

For every SAS release since your source installation, see the What's New documentation for new functions, CALL routines, macros, formats, and informats. SAS names generally take precedence over user-defined names. In other words, if your existing SAS code contains a user-defined name, and that name is identical to a new SAS name, then you might encounter an error.

z/OS

See also z/OS Compatibility Issues for additional changes that are specific to the z/OS operating environment.

Best practices

Search SAS code. Make a list of problematic SAS language elements and use a search tool (like GREP under UNIX) to scan external files for SAS code to change. Be aware that such a tool cannot search catalog entries, so it will not search SCL code unless the code is in an external text file. To search SCL catalog entries, you can open an entry and use the editor's search feature.

Use your employees' experience. Identify a staff member who has previously updated SAS programs to use in a later version. Use this person as a resource to train others in what changes to look for.

Use correct coding in any new programs. When using a PUT statement to write a character string followed by a variable name, it's a good coding practice to always type a blank space between the string and the variable. A log note reminds you of this. See the SAS documentation of the PUT statement for details.