Automating analytical tasks via the SAS© Viya™ REST API is a common practice for integrating the power of SAS© into external pipelines. However, a frequent error occurs when using the runCode action to manipulate tables located in CAS libraries (Caslibs) whose names exceed the historical 8-character limit.
This article details the origin of this limitation and presents the correct syntax to work around the problem without having to rename your libraries.
When you submit Data Step code via an HTTP POST request to the CAS runCode endpoint, you might be tempted to use the classic two-level syntax (Libref.Table).
If your library name (Caslib) is long, for example mycaslibdatasaviya (which is much longer than 8 characters), you will encounter the following error if you try to use an explicit reference:
In the classic SAS© environment, library references (librefs) are strictly limited to 8 characters. Although SAS© Viya™ and CAS support much longer Caslib names, the Data Step interpreter invoked by runCode retains certain legacy syntax constraints when using the Library.Table notation.
Furthermore, attempting to define a LIBNAME statement within the runCode call (e.g., libname myref cas caslib=mycaslibdatasaviya ...) will often fail with an error indicating that the statement is invalid or misplaced, because LIBNAME is a global statement that cannot be executed in the restricted context of the runCode action.
The documentation and error messages suggest using the "CASLIB= data set option". Concretely, this means that instead of prefixing the table name with the library name, you must specify the library as an option in parentheses right after the table name.
This method completely bypasses the 8-character limit and works for all Caslib names, regardless of their length.
In this example, using the dot (.) to separate the library from the table causes the failure because mycaslibdatasaviya is too long to be interpreted as a classic libref.
| 1 | /* Code qui échoue dans l'appel REST à cause du nom long */ |
| 2 | DATA mycaslibdatasaviya.LAB_RESULTS(append=force); |
| 3 | SET mycaslibdatasaviya.data201902; |
| 4 | RUN; |
To fix this, remove the long name from the prefix and place it explicitly in the caslib= option.
| 1 | /* Code qui fonctionne parfaitement avec le nom long */ |
| 2 | DATA LAB_RESULTS(append=force caslib='mycaslibdatasaviya'); |
| 3 | SET data201902(caslib='mycaslibdatasaviya'); |
| 4 | RUN; |
Here is what the final JSON body of your API request looks like with the fix applied. Note that we no longer need to create temporary references.
Do not use the LongCaslibName.TableName notation in the runCode action.
Do not try to execute a LIBNAME statement inside a runCode call.
Use the (caslib='YourCaslibName') option directly after the table name.
This approach is more robust, standardized, and saves you the headaches associated with legacy character limits.
The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.