SAS中的虚拟返回码
对于比较熟悉第三代语言（3GL）的软件开发人员来说，前面对返回码的解释可能会显得不充分或不准确。实际上，在许多软件语言中，“返回”程序指令的目的是提示终止某个参数，即从子进程向父进程返回某个或某些值。在SAS中，系统生成的返回码确实会执行这个功能，然而，%RETURN宏函数“造成当前运行宏的终止”，但实际并不会返回任何内容。BaseSAS 中没有固有的方法用来返回宏的值。
考虑到这种限制，BaseSAS 中不能生成真正的返回码，因而需要编写返回码。通过在 SAS 宏中启用通用宏变量，信息能够有效地从子进程传递到父进程中。尽管与其他计算机语言相比，这样做的效率较低，且安全性较差，但确实发挥了它应有的作用，同时，该限制不应该妨碍 SAS 从业人员在其软件中执行返回码。
编写返回码的一个缺点是违反松耦合——通用宏变量一旦创建，所有的子进程便都可调用，而并非只是调用该宏的父进程。因此，软件必须确保所有通用宏变量定义的独特性，以避免它们之间相互影响或干扰其他程序。实现这种安全性的一个方法是将宏名称作为返回码变量名称的基础。在下面的案例中，%CHILD宏会产生&CHILDRC返回码 ：
%macrochild();
%letsyscc=0;
%globalchildRC;
%letchildRC=GENERALFAILURE;
*dosomeprocess;
%if&syscc=0%then%letchildRC=;
%mend;
编写返回码的另一个缺点是返回码的持续存在性，它会一直存留在以前的程序或在同一 SAS 会话运行的上一项目中。例如，如果代码未将返回码初始化为默认值，那么上一个操作的值可能会继续存留在当前的运行环境中，从而影响该返回码及结 果。如前所述，在宏初始阶段将返回码设定为一种故障状态，或者仅在过程已经被证 实成功之后再指定一个有效的返回码，通过这两种方式均可以消除上述漏洞（第 11章会具体讲解）。
系统数字返回码
SAS系统生成的自动宏变量扮演着多个角色，它们能帮助我们了解 SAS运行环境及操作系统（OS），控制SAS的操作运行方式，记录性能指标。自动宏变量的子集包括描述软件性能的返回码，如特定SAS程序指令或功能的成功与失败。在执行过程中出现的警告或运行错误通常会自动地存储在返回码中。返回码一个主要的优点是， 它们能够自动驱动动态处理过程，而无须手动识别错误，这避免了 SAS从业人员费 时费力地分析日志结果以搜索出故障或证实软件的成功运行。
《SAS9.4宏语言 ：参考（第4版）》（SAS 9.4MacroLanguage: Reference, 4thed）中涵盖了多数 SAS自动宏变量，其余的 SAS自动宏变量则出现在《SAS9.4SQL程序用户指南（第 3版）》（SAS9.4SQLProcedureUser’sGuide, 3rded）中。
数字返回码：
&SYSERR 系统错误表示最近运行过程中的错误代码，在每个边界步骤中会重置该错误代码。
&SYSCC 系统当前代码指整个SAS 工作中产生的最高错误代码，该代码在SAS 会话中不会进行重置。
&SQLRC SQL 返回码表示最近的SQL 程序指令—— 是指令而不是程序——是否被正确执行。
&SYSFILRC 系统文件返回码指FILENAME 程序指令是否被正确执行。
&SYSLIBRC 系统数据库返回码指LIBNAME 程序指令是否被准确执行。
&SYSLCKRC 系统锁定返回码指LOCK 程序指令是否被准确执行。
&SYSRC 系统返回码记录的是与OS 运行环境直接互动的程序指令的状态，
如X、 SYSEXEC、SYSTASK 和WAITFOR。
SYSRC() 尽管从技术层面来讲系统返回码是一个函数而不是一个返回码，但它返回的是最近执行的输入/ 输出（I/O）函数的状态。
&SYSERR
&SYSERR 宏变量是一个非常重要的返回码，它能显示最近执行过程的成功与失败。下面的输出结果显示的是一个成功的、创建 Final数据集的DATA步骤，由于没有出现任何警告或错误，因此，&SYSERR的值设置为“0”：
datafinal;
setoriginal;*datasetexists;run;
NOTE:Therewere1observationsreadfromthedatasetWORK.ORIGINAL.NOTE: The data set WORK.FINAL has 1 observations and 0 variables.NOTE:DATAstatementused(Totalprocesstime):
realtime 0.01seconds
cputime 0.01seconds
%putSYSERR:&syserr;
SYSERR:0
若以下输出中，Original数据集不存在，那么&SYSERR将设置为“1012”，这表示 SAS总体的错误条件 ：
datafinal;
setoriginal;
ERROR:FileWORK.ORIGINAL.DATAdoesnotexist.run;
NOTE:TheSASSystemstoppedprocessingthisstepbecauseoferrors.
WARNING:ThedatasetWORK.FINALmaybeincomplete.Whenthisstepwasstoppedtherewere0observationsand0variables.
WARNING:DatasetWORK.FINALwasnotreplacedbecausethisstepwasstopped.
NOTE:DATAstatementused(Totalprocesstime):realtime 0.01seconds
cputime 0.01seconds
%putSYSERR:&syserr;
SYSERR:1012
&SYSERR 宏变量是只读模式，开发人员无法直接复制该变量，因此，&SYSERR通常会包含准确值，然而，通过错误的业务逻辑，可以手动将读写自动化宏变量重置为一个无效的非错误条件。&SYSERR 在每一个步骤边界之后都会进行重置，包括DATA 步骤及程序。需要特别注意的是，如果两个程序按顺序执行，在程序执行之后评估 &SYSERR值时，只能评估第二个程序的状态。因此，如果测试和调试序列化的单片 SAS代码，可能需要重复检查&SYSERR的值，以确保能够识别或分离出有故障的程序。
然而，许多特定的故障类型只有借助具体的返回码才能识别。例如，FILENAME程序指令出现了错误，&SYSERR依然是“0”（表示操作没有任何错误），这是因为 &SYSFILRC捕获了异常情况的信息。当 SAS 代码用于宏框架时，尤其需要利用所有相关的返回码来捕获全部的故障信息。例如，当软件遭遇错误情况“T”时，是很麻烦的事情？在下面的例子中，“5”被错误拼写为“T”，尽管宏已进行编译，但依然发生了故障 ：
%macrotest;
%letsyscc=0;*requiredtoresetSYSCCanytimeitwillbeassessed;
datafinal;
%doi=1%toT;*softwaredefectinwhichTshouldhavebeen5;lengthchar&i$10;
%end;run;
%mend;
当该代码运行时，DATA步骤就会出现故障，日志中只会出现提示信息，而
此时，&SYSERR会显示无错误运行。只有 &SYSCC会准确捕获引起故障的语法错误 ：
%test;
NOTE: The data set WORK.FINAL has 1 observations and 0 variables.NOTE:DATAstatementused(Totalprocesstime):
realtime 26.44seconds
cputime 0.90seconds
ERROR: A character operand was found in the %EVAL function or %IFconditionwhereanumericoperandisrequired.Theconditionwas:TERROR:The%TOvalueofthe%DOTloopisinvalid.
ERROR:ThemacroTESTwillstopexecuting.
%putSYSERR:&syserr;SYSERR:0
%putSYSCC:&syscc;
SYSCC:1012
该代码依然会创建数据集，但由于 LENGTH程序指令没有运行，因而没有任何变量。对于这种“悲壮”的故障，必须使用 &SYSCC来捕获错误，因为 &SYSERR根本不会显示这一故障。