It's the nightmare of every batch processing administrator: your program needs to process 30 days of data. The file for the 3rd day is missing. SAS© triggers an error, enters "Syntax Check Mode", and refuses to execute the next 27 days, even if they are valid.
How can you force SAS© to "forget" the error and continue processing? Here are the lessons learned from an expert discussion on the subject.
1. The Phenomenon: Syntax Check Mode
When SAS© runs in interactive mode (SAS© Enterprise Guide, Display Manager Window), an error doesn't stop everything. But in Batch mode (submission via script, .bat, cron), SAS© is programmed to be cautious.
As soon as it encounters a serious error (e.g., "Physical file does not exist"), it activates the Syntax Check Mode.
Immediate consequences:
The OBS option is set to 0.
The REPLACE option is set to NOREPLACE.
SAS© only checks the syntax of the remaining code without executing it.
The log then displays:
NOTE: SAS© set option OBS=0 and will continue to check statements.
2. Solution A: Prevention (Existence Check)
The cleanest method is to prevent the error from occurring.
The user Darryl suggests using the fileexist() function before attempting to read the file.
The specific problem (FTP):
The original poster (Chuck) faces a constraint: his files are on a remote FTP server accessed via SAS© (FILENAME FTP). In this specific case, fileexist often fails or returns false negatives because it cannot check the remote network path as easily as a local path.
The alternative: You need to retrieve the list of files from the FTP directory (via an ls or dir command sent to the FTP server) and parse this list to check for the file's presence. It's robust, but cumbersome to code.
3. Solution B: The "Brute Force" Reset
If the error is unavoidable (or too complex to prevent), how do you force SAS© to exit "Syntax Check" mode and resume work?
The expert David suggests manually resetting the options that SAS© modified during the error. If you insert this code after each step that is likely to fail (or at the beginning of your processing loop), you force the system to become operational again.
Here are the magic commands to "resurrect" your SAS© session:
OBS=MAX: Cancels the OBS=0 that was preventing data from being read.
REPLACE: Allows tables to be overwritten again.
NOSYNTAXCHECK: Explicitly disables the syntax check mode.
Advanced Note: In some versions or contexts, David mentions the undocumented option NO$SYNTAXCHECK. However, in most modern cases, the three options above are sufficient. It is also sometimes necessary to reset the macro error code via %let SYSCC=0;.
4. The Expert's Trick: How to Find These Options?
How do you know which options SAS© secretly modifies during an error? David shares a brilliant debugging method:
Use PROC OPTSAVE to save the "healthy" state of your options to a table.
Intentionally cause an error.
Use PROC OPTSAVE again to save the "error" state.
Use PROC COMPARE to see the differences.
Example of investigation code:
To survive an error in batch:
Ideally: Check for file existence before reading (FILEEXIST).
If impossible (FTP/Complex): Place a reset block (OPTIONS OBS=MAX REPLACE NOSYNTAXCHECK;) at the beginning of each iteration of your processing loop to ensure that day N+1 is processed even if day N has failed.
