2009-04-27 6 views
7

I SAS bin mit 9.2 auf OpenVMS zu einer externen Datenquelle über eine Buchse zum Anschluss mit einem Dateinamen Anweisung specifed:Fehler auf Steckdosen in SAS unter OpenVMS Umgang

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

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

Dies funktioniert (wie es sein soll) 99 % der ganzen Zeit. Hin und wieder ist das Programm, das auf dem Remote-Port hören soll, jedoch nicht. Momentan führt dies dazu, dass das Programm mit einem Fehler beendet wird:

Error: Connection refused. 

Nach dem wir es erneut versuchen, und es funktioniert in der Regel. Dies wird jedoch mühsam, daher möchte ich diesen Fehler im Programm erkennen und damit umgehen. Kennt jemand eine Möglichkeit, diese Art von Fehler in SAS zu erkennen?

Ich habe versucht, die Gültigkeit der Dateiref extsrc mit der Funktion fileref() zu überprüfen, aber das gibt nur -20005 zurück, was bedeutet, dass die Dateiref zugeordnet ist, zeigt aber nicht auf eine lokale Datei (was wahr ist). Der Fehler wird erst deutlich, wenn ich die fileref in einem datastep verwenden, so würde Ich mag etwas entlang der Linien von dem tun:

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] ich die Vorschläge bin versucht, unten getan, aber im wahren heisenbug Mode das Problem ist in den letzten Tagen nicht aufgetaucht, so bin ich mir nicht sicher, was die endgültige Lösung ist noch. [/ update1]

[update2] Der Fehler tauchte schließlich wieder auf. Wie pro cmjohns antwortet, ist der Wert von syserr 1012, nachdem dieser Fehler auftritt. Ich beobachte nun den Wert von syserr und versuche es erneut, wenn es fehlschlägt. [/ update2]

[Update3] Ich habe jetzt das funktioniert ein Lauf für ein paar Tage etwas Code musste. Das zusätzliche Problem war, dass (natürlich) wenn &syserr einen Wert höher als 6 bekommt, eine Fehlerbedingung aufgetreten ist, abhängig von Ihrer errorabend/noerrorabend Einstellung bewirkt dies, dass das Programm vollständig endet, oder es bewirkt, dass das Programm mit obs=0 im Syntaxchek-Modus fortfährt. Beide sind unerwünscht. Die Lösung besteht darin, options noerrorabend nosyntaxcheck vor dem Datenfehler zu setzen, der diesen Fehler erzeugt. Außerdem, wenn der Fehler auftritt, muss ich den Dateinamen extsrc löschen und neu zuweisen. Endlich, sobald dieses Stück Code fertig ist, stelle ich das Fehlerprogramm wieder her. Wenn ich nosyntaxcheck wiederherstelle, führt das dazu, dass SAS die vorherige Fehlerbedingung erkennt und an diesem Punkt in den Syntaxcheck-Modus wechselt, was ebenfalls unerwünscht ist. [/ update3]

+0

Haben Sie dies in der SAS-Newsgroup gefragt http://groups.google.com/group /comp.soft-sys.sas/topics –

Antwort

5

Haben Sie versucht, den Wert von & syserr zu testen. Alles andere als 0 deutet auf ein Problem hin.

Sie können die Rückgabewerte here sehen. Nach der Liste zu urteilen, würde ich 1012 oder 1020 schätzen, was Sie während des Socket-Fehlers bekommen.

+0

Ich bin derzeit dabei, um zu sehen, ob es mein Problem behebt –

+1

Sie können auch den Wert von & syscc überprüfen, nachdem ERRORCHECK auf STRICT gesetzt wurde, siehe http://support.sas.com/ Dokumentation/cdl/de/mcrolref/61885/HTML/default/tw3514-syscc-var.htm – cmjohns

3

Können Sie für die Daten foo testen? Wenn keine Daten vorhanden sind, können Sie eine Wiederholungsschleife einrichten, falls Daten vorhanden sind, fortfahren?

Etwas wie:

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

Ja, das ist in der Tat mein Plan, aber zuerst brauche ich eine Möglichkeit, zuverlässig zu erkennen, dass der Grund, warum foo nicht existiert, dieses Socket-Problem ist . Ich möchte immer noch zuverlässig ausbrechen, wenn etwas anderes nicht stimmt. –

+0

Können Sie eine Kombination von Tests für die Existenz der Daten und analysieren den Fehler, wenn die Daten nicht da sind. Daher, wenn die Daten nicht da sind und der Fehler nicht das ist, was Sie erwarten, sterben ..? BTW, vergessen Sie nicht, die Anzahl der Iterationen in der Schleife zu begrenzen. Mein Beispiel oben hat das nicht getan. – AFHood

3

Ich weiß, dass dies ein schaler Faden, aber:

SYNTAXCHECK schön zu haben; anstatt nackt wegen der & sysrr (eigentlich & syscc) Problem zu laufen, können Sie es nur zum letzten-bekannt-guten Wert löschen, sobald Sie hinter diesem sensiblen Abschnitt des Codes sind.

Hier sind die entsprechenden Bits von Code, wenn ich musste Locked-Tabelle Fehler von DB2 ordnungsgemäß handhaben:

/*** 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 ;