Códigos de retorno por lotes
El código de retorno de trabajo por lotes se recupera utilizando la interfaz de EJB getBatchJobRC, la interfaz de servicios web getBatchJobRC o la opción de mandatos lrcmd getBatchJobRC.
En la siguiente tabla se enumeran los códigos de retorno de trabajos por lotes del sistema usados por el entorno por lotes. No confunda el código de retorno de trabajo por lotes con las constantes de estado de trabajo (consulte la API com.ibm.websphere.longrun.JobStatusConstants) ni con las constantes del planificador de trabajos (consulte la API com.ibm.websphere.longrun.JobSchedulerConstants). JobStatusConstants representa el estado del trabajo como, por ejemplo, sometido, finalizado, reiniciable, cancelado o fallo en la ejecución.
El estado de trabajo se puede obtener utilizando la interfaz de EJB getJobStatus, la interfaz de servicios web getJobStatus o mediante la consola de gestión de trabajos. JobSchedulerConstants representa condiciones operativas devueltas por el planificador de trabajos sobre solicitudes que incluyen varios trabajos. Por ejemplo:
int[] cancelJob( String[] jobid ))
- El trabajo no existe
- El trabajo está en un estado no válido
- Se ha producido una excepción en la base de datos.
Código de retorno | Explicación |
---|---|
0 | El trabajo ha finalizado normalmente |
-1 | Error de protocolo interno; programa de utilidad WSGrid |
-2 | Error de parámetro de entrada; programa de utilidad WSGrid |
-4 | El trabajo se ha suspendido |
-8 | El trabajo se ha cancelado |
-10 | El trabajo se ha cancelado forzosamente (sóloz/OS) |
-12 | El trabajo ha fallado y está en estado reiniciable |
-14 | El trabajo ha fallado y está en estado de ejecución anómala** |
-16 | Anomalía grave: programa de utilidad WSGrid |

- La primera opción es que la aplicación produzca una excepción cuando se detecte un error. Esto provoca la terminación del trabajo con el código de retorno de trabajo por lotes -12 y el estado de trabajo por lotes restartable. La excepción puede lanzarse en cualquiera de los métodos del API por lotes.
- La segunda opción es que la aplicación devuelva un código de retorno BatchConstants.STEP_COMPLETE_EXECUTION_FAILED (consulte la API com.ibm.websphere.batch.BatchConstants) en el método processJobStep y devuelva un código de retorno de error específico de la aplicación desde el método destroyJobStep. Esto provoca la terminación del trabajo y el estado de trabajo por lotes execution failed. Este conjunto de códigos de retorno de paso del método destroyJobStep se pasa a cualquier algoritmo de resultados especificado en el paso del trabajo y se utiliza para influir en el código de retorno del trabajo para indicar la causa específica de la anomalía.