manejo de cuencas en el SAS bajo OpenVMS error

Question

Estoy utilizando SAS 9.2 en OpenVMS 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 debe ser) el 99% del tiempo. Sin embargo, de vez en cuando el programa que se supone que se escucha en el puerto remoto no lo es. Actualmente esto hace que el programa se cierre con un error:

Error: Connection refused.

Después de que intentarlo de nuevo, y por lo general funciona. Sin embargo, esto se está volviendo aburrido así que me gustaría para detectar este error en el programa y tratar con él allí. ¿Alguien sabe de una manera de detectar este tipo de error en el SAS?

He intentado comprobar la validez de la extsrc fileref usando la función fileref (), pero que sólo devuelve -20005, lo que significa que el fileref es asignado pero no apunta a un archivo local (lo cual es cierto). 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 de manera que el problema ha fallado a surgir En los últimos días, así que no estoy seguro de lo que la solución final todavía es. [/ Update1]

[Actualización 2] El error, finalmente, surgió de nuevo. Según cmjohns respuesta, el valor de SYSERR es 1012 después de producirse este error. Voy a ver ahora el valor de SYSERR, y vuelve a intentarlo un número fijo de veces si falla. [/ Actualización 2]

[Update3] He tenido algo de código a una corriente durante unos días ahora que funciona. El problema adicional fue que (por supuesto) si &syserr obtiene un valor superior a 6 una condición de error se ha producido, por lo que dependiendo de su configuración de este errorabend/noerrorabend hace que el programa terminará por completo, o que hace que el programa continuará con obs=0 en modo syntaxchek. Ambas son indeseables. La solución es establecer options noerrorabend nosyntaxcheck antes de la datastep que produce este error. Además, si se produce el error que tengo que borrar extsrc nombre de archivo y reasignar la misma. Por último, una vez que esta pieza de código se haya completado restauro errorabend. Si restauro nosyntaxcheck esto causa de SAS para detectar la condición de error anterior y cambiar al modo de syntaxcheck en ese punto que también es indeseable. [/ Update3]

Answer 1

¿Usted ha intentado probar el valor de Y SYSERR. Todo lo que no 0 indica generalmente un problema.

Puede ver los valores de retorno aquí . A juzgar por la lista supongo que un 1012 o 1020 es lo que está recibiendo en el error de socket.

Answer 2

Se puede probar para la indu datos? Si no hay datos entonces se puede establecer un bucle de reintento, si existen datos, continuar?

Algo así como:

  

doitagain:

     

(insertar el código de socket aquí)

/*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 tema y SYSERR (en realidad y syscc), puede apenas claro él para durar-conocida buen valor una vez que estás pasado que la sección sensible de código.

Aquí están 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 ;