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根本不会显示这一故障。