&SYSCC
&SYSCC自动宏变量代表的是 SAS会话中遇到的警告或“运行时错误”的最大值。例如，如果遇到的“运行时错误”的值是“1012”和“1014”，那么&SYSCC会设置为“1014”，而“1012”错误则会被掩盖。&SYSCC是累积的，这一点与&SYSERR截然相反。当 SAS边界步骤相互交叉时，&SYSERR会自动重置，因此，即使&SYSERR已经重写为“0”，&SYSCC也会显示出过去某一时刻所发生的警告或错误。&SYSCC 不能识别全部的错误，因此，经常需要结合其他返回码对它进行检查。例如，当 LIBNAME程序指令发生故障时，SAS日志中会出现一条提示，而 &SYSCC无法以编程方式发现这条提示，只能通过 &SYSLIBRC发现。
当运行以下代码时，LIBNAME程序指令会发生故障，因为C:\neverland目录不存在，因此，&SYSLIBRC 呈现出来的是一个负值，在后续 LIBNAME 程序指令重置&SYSLIBRC之前，该负值会一直存在 ：
%letsyscc=0;
libnamelib'c:\neverland\';NOTE:LibraryLIBdoesnotexist.
%putSYSCC:&syscc;SYSCC:0
%putSYSLIBRC:&syslibrc;
SYSLIBRC:-70008
datalib.mydata;
lengthchar1$10;
run;
NOTE:Variablechar1isuninitialized.ERROR:LibraryLIBdoesnotexist.
NOTE: TheSASSystemstoppedprocessingthisstepbecauseoferrors.NOTE:DATAstatementused(Totalprocesstime):
realtime 0.01seconds
cputime 0.01seconds
%putSYSCC:&syscc;SYSCC:1012
%putSYSLIBRC:&syslibrc;
SYSLIBRC:-70008
由于 LIBNAME程序指令出现故障，因此，无法找到LIB.Mydata数据集，且DATA步骤会引起运行错误。尽管这是由上一个 LIBNAME程序指令故障间接造成的，但 &SYSCC在出现故障之后只能设置为一个错误代码。&SYSCC应该用于发现和处理那些不宜捕获的常见或未知错误，但需要注意的是，该代码需要与其他错误返回码结合使用。例如，如果能首先使用&SYSLIBRC值评估异常情况处理，就能够发现定义逻辑库时发生的错误，而且，通过动态执行能规避 DATA 步骤故障。
需要注意的是，&SYSCC必须初始化为“0”，以确保它的值不会从上一个程序运行中存留下来。由于 &SYSCC具有累积性，因此，它在SAS会话中不会自动重置。例如，某个SAS从业人员可能运行了上述代码（收到“1012”错误），吃完午饭之后又在同一个 SAS 会话中运行了一个不相关的程序，即使第二个程序运行顺利，但&SYSCC的值仍然会是“1012”。以下代码模拟了第二个在同一会话中运行的后续不相关程序 ：
datafinal;
setoriginal;run;
NOTE:Therewere1observationsreadfromthedatasetWORK.ORIGINAL.NOTE: The data set WORK.FINAL has 1 observations and 0 variables.NOTE:DATAstatementused(Totalprocesstime):
realtime 0.01seconds
cputime 0.00seconds
%putSYSCC:&syscc;
SYSCC:1012
由于SAS应用程序永远不会自动重置 &SYSCC，因而会出现逻辑错误，导致某个程序的错误代码继续存留并影响同一会话模式下运行的其他程序。为了克服这种持续存在性，又因为&SYSCC是一个可读写变量（与&SYSERR不同），因此， &SYSCC在执行和测试之前，需要重置为“0”。修改过的代码目前能准确反映出 DATA 步骤没有出现任何错误 ：
%letSYSCC=0;
datafinal;
setoriginal;run;
NOTE:Therewere1observationsreadfromthedatasetWORK.ORIGINAL.
NOTE:ThedatasetWORK.FINALhas1observationsand0variables.
NOTE:DATAstatementused(Totalprocesstime):realtime 0.01seconds
cputime 0.00seconds
%putSYSCC:&syscc;
SYSCC:0
关于 &SYSCC，最后需要指出的一点是，由于只保留最高的错误值，因此，当出现多个错误时，数值较低的错误就会被掩盖。例如，当出现一般的错误时，&SYSCC会设置为“1012”。然而，如果继续执行且SAS应用程序内存已满时，&SYSCC便会被重写覆盖，设置为“1016”。另外，如果“1016”错误值出现在“1012”之前，那么&SYSCC会设置为“1016”，而不会反映出“1012”，因为它已经被覆盖了。这同样又说明在后续进行评估之前，需要将&SYSCC重置为“0”。
执行最小异常情况处理的一个方法是，在程序启动之初将&SYSCC重置为“0”，而在程序结束时测试它的值。在以下虚拟的提取 - 转换 - 加载（ETL）框架中，任何 &SYSCC>0就表明出现了警告或错误，进而需要仔细查看日志：
%letSYSCC=0;
%macroextract;
%mend;
%macrotransform;
%mend;
%macroload;
%mend;
%extract;
%transform;
%load;
%putSYSCC:&syscc;
在实际的 ETL基础结构中，&SYSCC 在程序结束时的非零值可能会使程序日志文件自动保存下来，便于开发人员能够通过浏览该文件分析任何警告或“运行时错误”。如果没有发生任何故障，日志文件就会自动删除。&SYSCC 的一个比较稳健的操作可能是不断地重置及测试其在单个程序内的值。例如，在模块化代码中，宏一旦被调用，&SYSCC就会重置为“0”，它的值会在宏结束之前被评估，这一操作与上述案例是相同的，但该操作旨在模块级别重复发生时更好地分离出错误发生的位置及原因。而且，一旦识别错误，程序流程就会终止或改变方向，以避免程序因遭受连环错误而发生故障（第 6章会详细讲解）。
