Conversion Considerations :: SAS(R) 9.3 Stored Processes: Developer's Guide

Overview of Conversion Considerations

There are a number of differences in the stored process server environment that might affect existing SAS/IntrNet programs. Use the items in the following sections as a review checklist for your existing programs.

HTTP Headers

In SAS Stored Processes, HTTP headers cannot be written directly to _WEBOUT by using a DATA step PUT statement or SCL FWRITE function. You must use the STPSRV_HEADER (or APPSRV_HEADER) function to set header values. Automatic header generation cannot be disabled with appsrvset("automatic headers", 0).
SAS/IntrNet programs require that HTML Formatting Tools use the RUNMODE=S option, which writes an HTML header directly to _WEBOUT. For stored process programs, you should change the option to RUNMODE=B, or an extra header line appears in the output.

Macro Variables

Unsafe processing is different for stored processes; there is no UNSAFE option. Unsafe characters (characters that cause unwanted macro language processing) are quoted instead of removed from the input parameters, so you can safely use the &VAR syntax without worrying about unsafe characters. The following examples work without using the APPSRV_UNSAFE function:
```
%if &MYVAR eq %nrstr(A&P) 
%then do something...;
```
Here is another example:
```
data
_null_;
file _webout;
put "MYVAR=&MYVAR";
run;
```
APPSRV_UNSAFE works in the stored process server and still returns the complete, unquoted input value. This change might cause subtle behavioral differences if your program relies on the SAS/IntrNet unsafe behavior. For stored processes, use the STPSRV_UNQUOTE2 function instead.
The _REPLAY macro variable does not have the same syntax in stored processes as it did in Application Dispatcher. References to &_REPLAY are not recommended for SAS/IntrNet programs, but they can be used in stored processes. The DATA step function symget('_REPLAY') does not return a usable URL in a stored process and should be replaced with "&_REPLAY". For example:
```
url =
symget('_REPLAY')...;
```
should be changed to
```
url =
%str(&_REPLAY)...;
```
However, if you were already using %str(&_REPLAY) in SAS/IntrNet, then no change is necessary.
The _SERVICE, _SERVER, and _PORT macro variables do not exist for stored processes. You must review any code that uses these macro variables. Usually, they are used to create drill-down URLs or forms. In many cases, this code does not require any change; input values for these variables are ignored.
In stored processes, _PROGRAM refers to a stored process path and name in the metadata repository folder structure, and not a three-level or four-level program name. Any programs that create drill-down links or forms with _PROGRAM must generally be modified to use the stored process path.

Code Differences

The stored process server cannot directly execute SOURCE, MACRO, or SCL catalog entries. You must use a wrapper .sas source file to execute the catalog entry.
Instead of using an ALLOCATE LIBRARY or ALLOCATE FILE statement to assign a library, as you can do in SAS/IntrNet, you must assign a library in one or more of the following ways:
- using the Data Library Manager plug-in for SAS Management Console
- using the server start-up command or the SAS config file
- using a SAS autoexec file
For more information about how to assign libraries, see the SAS Intelligence Platform: Data Administration Guide.
There is no REQUEST TIMEOUT functionality in stored processes; appsrvset('request timeout') is not supported.
The Application Server functions APPSRV_AUTHCLS, APPSRV_AUTHDS, and APPSRV_AUTHLIB are not supported in stored processes. There are no STPSRV functions that are equivalent to these Application Server functions.
Stored processes do not support the SESSION INVSESS automatic user exit program. Similar functionality can be implemented in the SAS Stored Process Web Application through a custom Web interface.
AUTH=HOST functionality is not supported by the stored process server. In Application Dispatcher, this functionality provides the ability for the program to run under the operating system permissions of the client user.
If you are writing to _WEBOUT by using PUT statements while ODS has _WEBOUT open, when you execute the code the PUT statement data might be out of sequence with the data that is generated by ODS. This problem occurs with both SAS/IntrNet applications and stored processes. It tends to be more of an issue if you are upgrading from SAS 8 to SAS®9. This problem occurs because both your code and ODS are opening the same fileref at the same time. For example, the following code might not always work as expected:
```
ods listing close;
ods html body=_webout path=&_tmpcat
(url=&_replay) Style=Banker;
... other code ...
data _null_;
file _webout;
put ' ' ;
put 'Test.
If you see this in order, it worked.';
run;
... other code ...
ods html close;
```
This code might work in some SAS/IntrNet programs, but it can cause problems with the order of data even in SAS/IntrNet. This code is more likely to fail in a stored process. This problem can be fixed by inserting PUT statements before you open ODS, closing ODS while you write directly to the fileref, or using the ODS HTML TEXT="string" option to write data. The following code is an example of how you can both close ODS while you write directly to the fileref, and insert your PUT statements before you open ODS:
```
ods html
body=_webout
(no_bottom_matter)...;
... other code ...
ods html close;

data _null_;
file _webout;
put ' ' ;
put 'Test.
If you see this in order, it worked.';
run;

ods html body=_webout (no_top_matter)...;
... other code ...
ods html close;
```
The following code is an example of how you can use the ODS HTML TEXT="string" option to write data:
```
ods
listing
close;
ods html body=_webout path=&_tmpcat
(url=&_replay) Style=Banker;
... other code ...
ods html text=' ' ;
ods html text='Test.
If you see this in order, it worked.';
... other code ...
ods html close;
```