manejo de cuencas en SAS bajo OpenVMS

Question

estoy usando SAS 9.2 en OpenVMS error para conectarse a una fuente de datos externa sobre un socket specifed con una declaración de nombre de archivo:

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

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

Esto funciona (como debería) 99 % del tiempo. Sin embargo, de vez en cuando el programa que se supone que escucha en el puerto remoto no lo es. Actualmente esto hace que el programa termine con un error:

Error: Connection refused. 

Después de lo cual intentamos de nuevo, y por lo general funciona. Sin embargo, esto se está volviendo tedioso, así que me gustaría detectar este error en el programa y tratarlo allí. ¿Alguien sabe de una forma de detectar este tipo de error en SAS?

He intentado comprobar la validez de fileref extsrc usando la función fileref(), pero eso simplemente devuelve -20005, lo que significa que el archivo fileref está asignado pero no apunta a un archivo local (que es verdadero). El error sólo se hace evidente cuando se utiliza la fileref en un datastep, así que me gustaría hacer algo en la línea 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] Estoy tratando las sugerencias hechas por debajo, pero en cierto heisenbug moda El problema no ha surgido en los últimos días, por lo que aún no estoy seguro de cuál es la solución final. [/ update1]

[update2] El error finalmente volvió a aparecer. Según la respuesta de cmjohns, el valor de syserr es 1012 después de que ocurra este error. Ahora veré el valor de syserr, e intentaré nuevamente una cantidad fija de veces si falla. [/ update2]

[update3] Hace algunos días que tengo un código funcionando que funciona. El problema adicional es que (por supuesto) si &syserr obtiene un valor superior a 6, se produce una condición de error, por lo que dependiendo de su configuración errorabend/noerrorabend esto hace que el programa termine por completo, o hace que el programa continúe con obs=0 en modo syntaxchek. Ambos son indeseables. La solución es establecer options noerrorabend nosyntaxcheck antes del paso de datos que produce este error. Además, si ocurre el error, tengo que borrar el nombre del archivo extsrc y reasignarlo. Finalmente, una vez que este fragmento de código se completa, restauro errorabend. Si restauro nosyntaxcheck, esto hace que SAS detecte la condición de error anterior y cambie al modo de comprobación de sintaxis en ese punto, lo que también es indeseable. [/ update3]

Answer 1

Ha intentado probar el valor de & syserr. Cualquier cosa que no sea 0 generalmente indica un problema.

Puede ver los valores de retorno here. A juzgar por la lista, supongo que un 1012 o 1020 es lo que está obteniendo durante el error de socket.

Answer 2

¿Puedes probar la información foo? Si no hay datos, puede establecer un ciclo de reintento, si existen datos, ¿continuar?

Algo así como:

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; 

Answer 3

Sé que esto es un hilo rancio, pero:

SYNTAXCHECK es bueno tener; en lugar de correr desnudo por el problema syserr & syserr (actualmente & syscc), puede borrarlo al último valor conocido una vez que haya pasado esa sección sensible del código.

Éstos son los bits correspondientes de código para cuando tenía que controlar correctamente errores de tabla bloqueada desde 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 ;