movimentazione su boccole in SAS sotto OpenVMS errore

Question

Sto usando SAS 9.2 su OpenVMS per connettersi a un'origine dati esterna su un socket specifed con un comunicato il nome del file:

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

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

Questo funziona (come dovrebbe) il 99% del tempo. Tuttavia, di tanto in tanto il programma che si suppone essere in ascolto sulla porta remota non è. Attualmente questo fa sì che il programma per uscire con un errore:

Error: Connection refused.

Dopo di che ci riproviamo, e di solito funziona. Tuttavia, questo sta diventando noiosa quindi mi piacerebbe rilevare questo errore nel programma e trattare con esso là. Qualcuno sa di un modo per rilevare questo tipo di errore in SAS?

Ho provato la verifica della validità del extsrc fileref utilizzando la funzione fileref (), ma che restituisce solo -20.005, il che significa che il fileref è assegnato, ma non punta ad un file locale (il che è vero). L'errore diventa solo apparente quando uso il fileref in un datastep, quindi mi piacerebbe fare qualcosa sulla falsariga di:

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] Sto cercando i suggerimenti fatti qui di seguito, ma in vero heisenbug moda il problema non è riuscita a ritagliare nel corso degli ultimi giorni, quindi non sono sicuro di quello che la soluzione finale è ancora. [/ Update1]

[Update2] L'errore, infine, ritagliata di nuovo. Come per cmjohns risposta, il valore di SYSERR è 1012 dopo che si verifica questo errore. Io ora guardo il valore di SYSERR, e provare di nuovo un numero fisso di volte se non riesce. [/ Update2]

[Update3] Ho avuto un po 'di codice di un correre per un paio di giorni ormai che funziona. Il problema ulteriore è che (ovviamente) se &syserr ottiene un valore superiore a 6 una condizione di errore si è verificato, in modo a seconda della impostazione di questo errorabend/noerrorabend fa sì che il programma di terminare completamente, o che provoca il programma per continuare con obs=0 in modalità syntaxchek. Entrambi sono indesiderabili. La soluzione è impostare options noerrorabend nosyntaxcheck prima della datastep che produce questo errore. Inoltre, se si verifica l'errore che ho per cancellare il nome del file extsrc e riassegnarlo. Infine, una volta questo pezzo di codice è completo restauro errorabend. Se restauro nosyntaxcheck questo provoca SAS per rilevare la precedente condizione di errore e passare alla modalità syntaxcheck a quel punto che è anche indesiderabile. [/ Update3]

Answer 1

Hai provato testare il valore di & SYSERR. Nulla non 0 indica generalmente un problema.

È possibile visualizzare i valori di ritorno qui . A giudicare dalla lista direi un 1012 o 1020 è quello che hai trovato durante l'errore di socket.

Answer 2

Si può verificare l'pippo dati? Se non ci sono dati, allora è possibile impostare un ciclo di tentativi, la presenza di dati, continuare?

Qualcosa di simile:

  

doitagain:

     

(inserire il prefisso presa qui)

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

Answer 3

So che questo è un filo stantio, ma:

SYNTAXCHECK è bello avere; invece di correre nudo a causa della & SYSERR (in realtà e syscc) problema, si può solo chiaro che per durare-noto buon rapporto una volta che sei passato che parte sensibile del codice.

Ecco i bit rilevanti di codice per cui ho dovuto gestire correttamente gli errori di locked-tavolo da 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 ;