Es ist der Albtraum jedes Batch-Verarbeitungsadministrators: Ihr Programm muss 30 Tage Daten verarbeiten. Die Datei des 3. Tages fehlt. SAS© löst einen Fehler aus, wechselt in den "Syntax Check Mode" und weigerst sich, die nächsten 27 Tage auszuführen, selbst wenn sie gültig sind.
Wie zwingt man SAS© dazu, den Fehler zu "vergessen" und die Verarbeitung fortzusetzen? Hier sind die Erkenntnisse aus einer Expertendiskussion zu diesem Thema.
1. Das Phänomen: Syntax Check Mode
Wenn SAS© im interaktiven Modus läuft (SAS© Enterprise Guide, Display Manager Window), stoppt ein Fehler nicht alles. Aber im Batch-Modus (Übermittlung per Skript, .bat, cron) ist SAS© darauf programmiert, vorsichtig zu sein.
Sobald ein schwerwiegender Fehler auftritt (z.B. "Physical file does not exist"), wird der Syntax Check Mode aktiviert.
Sofortige Konsequenzen:
Die Option OBS wird auf 0 gesetzt.
Die Option REPLACE wird auf NOREPLACE gesetzt.
SAS© prüft nur noch die Syntax des restlichen Codes, ohne ihn auszuführen.
Das Protokoll zeigt dann an:
NOTE: SAS© set option OBS=0 and will continue to check statements.
2. Lösung A: Die Prävention (Existenzprüfung)
Die sauberste Methode ist, den Fehler gar nicht erst auftreten zu lassen.
Der Benutzer Darryl schlägt vor, die Funktion fileexist() zu verwenden, bevor versucht wird, die Datei zu lesen.
Das spezifische Problem (FTP):
Der Autor des Originalbeitrags (Chuck) steht vor einer Einschränkung: Seine Dateien befinden sich auf einem entfernten FTP-Server, auf den über SAS© (FILENAME FTP) zugegriffen wird. In diesem speziellen Fall schlägt fileexist oft fehl oder gibt falsch negative Ergebnisse zurück, da es den entfernten Netzwerkpfad nicht so einfach überprüfen kann als einen lokalen Pfad.
Die Alternative: Es ist notwendig, die Liste der Dateien aus dem FTP-Verzeichnis abzurufen (über einen ls- oder dir-Befehl an den FTP-Server) und diese Liste zu parsen, um die Anwesenheit der Datei zu überprüfen. Dies ist robust, aber aufwendig zu codieren.
3. Lösung B: Die "Brute-Force"-Rücksetzung
Wenn der Fehler unvermeidlich ist (oder zu komplex, um ihn zu verhindern), wie zwingt man SAS©, den "Syntax Check"-Modus zu verlassen und die Arbeit wieder aufzunehmen?
Der Experte David schlägt vor, die Optionen, die SAS© bei dem Fehler geändert hat, manuell zurückzusetzen. Wenn Sie diesen Code nach jedem Schritt, der fehlschlagen könnte (oder am Anfang Ihrer Verarbeitungsschleife), einfügen, zwingen Sie das System, wieder betriebsbereit zu werden.
Hier sind die magischen Befehle, um Ihre SAS©-Sitzung zu "reanimieren":
OBS=MAX : Hebt das OBS=0 auf, das das Lesen von Daten verhinderte.
REPLACE : Erlaubt das Überschreiben von Tabellen wieder.
NOSYNTAXCHECK : Deaktiviert explizit den Überprüfungsmodus.
Erweiterter Hinweis: In einigen Versionen oder Kontexten erwähnt David die undokumentierte Option NO$SYNTAXCHECK. In den meisten modernen Fällen reichen jedoch die drei oben genannten Optionen aus. Es ist manchmal auch notwendig, den Makro-Fehlercode über %let SYSCC=0; zurückzusetzen.
4. Der Experten-Tipp: Wie finde ich diese Optionen?
Woher weiß man, welche Optionen SAS© bei einem Fehler heimlich ändert? David teilt eine geniale Debugging-Methode:
Verwenden Sie PROC OPTSAVE, um den "gesunden" Zustand Ihrer Optionen in einer Tabelle zu speichern.
Lösen Sie absichtlich einen Fehler aus.
Verwenden Sie PROC OPTSAVE erneut, um den "Fehler"-Zustand zu speichern.
Verwenden Sie PROC COMPARE, um die Unterschiede zu sehen.
Beispiel für Untersuchungs-Code:
Um einen Fehler im Batch zu überleben:
Ideal: Überprüfen Sie die Existenz von Dateien vor dem Lesen (FILEEXIST).
Wenn unmöglich (FTP/Komplex): Platzieren Sie am Anfang jeder Iteration Ihrer Verarbeitungs Schleife einen Reset-Block (OPTIONS OBS=MAX REPLACE NOSYNTAXCHECK;), um sicherzustellen, dass Tag N+1 verarbeitet wird, selbst wenn Tag N abgestürzt ist.
