C'est le cauchemar de tout administrateur de traitements par lots (Batch) : votre programme doit traiter 30 jours de données. Le fichier du 3ème jour est manquant. SAS© déclenche une erreur, passe en "Mode Vérification de Syntaxe", et refuse d'exécuter les 27 jours suivants, même s'ils sont valides.
Comment forcer SAS© à "oublier" l'erreur et continuer le traitement ? Voici les leçons tirées d'une discussion d'experts sur le sujet.
1. Le Phénomène : Syntax Check Mode
Lorsque SAS© tourne en mode interactif (SAS© Enterprise Guide, Fenêtre Display Manager), une erreur n'arrête pas tout. Mais en mode Batch (soumission via script, .bat, cron), SAS© est programmé pour être prudent.
Dès qu'il rencontre une erreur grave (ex: "Physical file does not exist"), il active le Syntax Check Mode.
Conséquences immédiates :
L'option OBS passe à 0.
L'option REPLACE passe à NOREPLACE.
SAS© ne fait plus que vérifier la syntaxe du code restant sans l'exécuter.
Le log affiche alors :
NOTE: SAS© set option OBS=0 and will continue to check statements.
2. Solution A : La Prévention (Check d'existence)
La méthode la plus propre est d'empêcher l'erreur de se produire.
L'utilisateur Darryl suggère d'utiliser la fonction fileexist() avant de tenter de lire le fichier.
Le problème spécifique (FTP) :
L'auteur du post original (Chuck) fait face à une contrainte : ses fichiers sont sur un serveur FTP distant accédé via SAS© (FILENAME FTP). Dans ce cas précis, fileexist échoue souvent ou retourne des faux négatifs car il ne peut pas vérifier le chemin réseau distant aussi simplement qu'un chemin local.
L'alternative : Il faut récupérer la liste des fichiers du répertoire FTP (via une commande ls ou dir envoyée au FTP) et parser cette liste pour vérifier la présence du fichier. C'est robuste, mais lourd à coder.
3. Solution B : La Réinitialisation "Force Brute"
Si l'erreur est inévitable (ou trop complexe à prévenir), comment forcer SAS© à sortir du mode "Syntax Check" et reprendre le travail ?
L'expert David propose de réinitialiser manuellement les options que SAS© a modifiées lors de l'erreur. Si vous insérez ce code après chaque étape susceptible d'échouer (ou au début de votre boucle de traitement), vous forcez le système à redevenir opérationnel.
Voici les commandes magiques pour "ressusciter" votre session SAS© :
OBS=MAX : Annule le OBS=0 qui empêchait la lecture des données.
REPLACE : Autorise à nouveau l'écrasement des tables.
NOSYNTAXCHECK : Désactive explicitement le mode de vérification.
Note avancée : Dans certaines versions ou contextes, David mentionne l'option non documentée NO$SYNTAXCHECK. Cependant, dans la plupart des cas modernes, les trois options ci-dessus suffisent. Il est parfois aussi nécessaire de réinitialiser le code erreur macro via %let SYSCC=0;.
4. L'Astuce de l'Expert : Comment trouver ces options ?
Comment savoir quelles options SAS© modifie en cachette lors d'une erreur ? David partage une méthode de débogage géniale :
Utilisez PROC OPTSAVE pour sauvegarder l'état "sain" de vos options dans une table.
Provoquez une erreur volontaire.
Utilisez PROC OPTSAVE à nouveau pour sauvegarder l'état "erreur".
Utilisez PROC COMPARE pour voir les différences.
Exemple de code d'investigation :
Pour survivre à une erreur en batch :
Idéalement : Vérifiez l'existence des fichiers avant lecture (FILEEXIST).
Si impossible (FTP/Complexe) : Placez un bloc de réinitialisation (OPTIONS OBS=MAX REPLACE NOSYNTAXCHECK;) au début de chaque itération de votre boucle de traitement pour garantir que le jour N+1 soit traité même si le jour N a planté.
