2009-04-27 9 views
7

J'utilise SAS 9.2 sur OpenVMS pour se connecter à une source de données externe sur une prise spécifiées avec une instruction nom:Gestion des erreurs sur les sockets dans SAS sous OpenVMS

filename extsrc SOCKET "extserver:port" recfm=v; 

data foo; 
infile extsrc; 
input; 
.... some statements to read stuff ...; 
run; 

Cela fonctionne (comme il se doit) 99 % du temps. Cependant, de temps en temps, le programme censé écouter sur le port distant ne l'est pas. Actuellement, cela provoque la sortie du programme avec une erreur:

Error: Connection refused. 

Ensuite, nous essayons à nouveau, et cela fonctionne habituellement. Cependant, cela devient fastidieux alors je voudrais détecter cette erreur dans le programme et y faire face. Quelqu'un sait-il un moyen de détecter ce type d'erreur dans SAS?

J'ai essayé de vérifier la validité de fileref extsrc en utilisant la fonction fileref(), mais cela renvoie simplement -20005, ce qui signifie que le fichier fileref est assigné mais ne pointe pas vers un fichier local (ce qui est vrai). L'erreur ne se manifeste que lorsque j'utilise le fileref dans un datastep, donc je voudrais faire quelque chose le long des lignes de:

data _null_; 
rc=infile extsrc; 
if rc=0 then do; 
    //whatever I want to do; 
end; 
else do; 
    //throw some error and try again later; 
end; 
run; 

[Update1] J'essaie les suggestions faites ci-dessous, mais en vrai heisenbug mode le problème n'a pas réussi à surgir au cours des derniers jours, donc je ne suis pas sûr de ce que la solution finale est encore. [/ update1]

[update2] L'erreur a finalement réapparu. Selon la réponse de cmjohns, la valeur de syserr est 1012 après que cette erreur se produit. Je vais maintenant regarder la valeur de syserr, et réessayer un nombre fixe de fois s'il échoue. [/ update2]

[update3] J'ai eu du code en cours d'exécution depuis quelques jours maintenant qui fonctionne. Le problème supplémentaire était (bien sûr) si &syserr obtient une valeur supérieure à 6 une condition d'erreur est survenue, donc en fonction de votre paramètre cela provoque la fin complète du programme, ou le programme continue avec obs=0 en mode syntaxchek. Les deux sont indésirables. La solution consiste à définir options noerrorabend nosyntaxcheck avant le flux de données qui génère cette erreur. De plus, si l'erreur se produit, je dois effacer le nom de fichier extsrc et le réaffecter. Enfin, une fois cette partie de code terminée, je restaure errorabend. Si je restaure nosyntaxcheck, cela provoque que SAS détecte la condition d'erreur précédente et passe en mode de vérification syntaxique à ce point, ce qui est également indésirable. [/ update3]

+0

Avez-vous demandé ce dans le forum SAS http://groups.google.com/group /comp.soft-sys.sas/topics –

Répondre

5

Avez-vous essayé de tester la valeur de & syserr. Tout ce qui n'est pas 0 indique généralement un problème. Les valeurs de retour here sont affichées. A en juger par la liste, je suppose qu'un 1012 ou 1020 est ce que vous obtenez pendant l'erreur de socket.

+0

Je suis actuellement en train d'examiner ceci pour voir s'il résout mon problème. –

+1

Vous pouvez également vérifier la valeur de & syscc après avoir réglé ERRORCHECK sur STRICT voir http://support.sas.com/ documentation/cdl/fr/mcrolref/61885/HTML/default/tw3514-syscc-var.htm – cmjohns

3

Pouvez-vous tester pour les données foo? S'il n'y a pas de données, vous pouvez définir une boucle de réessai, si les données existent, continuer?

Quelque chose comme:

doitagain:

(insert your socket code here)

/*see if ds exists*/ 

%if not %sysfunc(exist(data.foo)) %then %do ; 

/*if the ds does not exist then*/ 

%put WARNING: The file does not exist! ; 

%goto doitagain; 

%end; 
+0

Oui c'est bien mon plan, mais d'abord j'ai besoin d'un moyen de détecter de manière fiable que le jeu de données raison n'existe pas est ce problème de socket . Je veux toujours me tromper si quelque chose ne va pas. –

+0

Pouvez-vous faire une combinaison de tests pour l'existence des données et l'analyse de l'erreur si les données ne sont pas là. Par conséquent, si les données ne sont pas là et l'erreur n'est pas ce que vous attendez, die ..? BTW, n'oubliez pas de limiter le nombre d'itérations sur la boucle. Mon exemple ci-dessus n'a pas fait ça. – AFHood

3

Je sais que c'est un fil rassis, mais:

SYNTAXCHECK est agréable d'avoir; Au lieu de s'exécuter nu à cause du problème syserr & syserr (en réalité & syscc), vous pouvez l'effacer à la valeur last-known-good une fois que vous avez dépassé cette section sensible du code.

Voici les bits correspondants de code pour quand je devais gérer correctement les erreurs tables verrouillées de DB2:

/*** temporarily disable ERRORABEND and SYNTAXCHECK ***/ 
options NOERRORABEND NOSYNTAXCHECK ; 

/* save &syscc for laster restoration */ 
%let presyscc=&syscc; 

%do until (...); 
    /* do a task, handle some possible errors */ 
%end; 

/* restore &syscc */ 
%let syscc=&presyscc; 

/*** re-enable ERRORABEND and SYNTAXCHECK ***/ 
options ERRORABEND SYNTAXCHECK ; 
Questions connexes