Codes retour des traitements par lots

Le code retour du travail par lots est extrait à l'aide de l'interface EJB getBatchJobRC, de l'interface des services Web get BatchJobRC ou de l'option de commande lrcmd getBatchJobRC.

Le tableau suivant répertorie les codes retour des travaux par lots utilisés par l'environnement de traitement par lots. Ne confondez pas le code retour d'un travail par lots avec les constantes de statut des travaux (voir l'API com.ibm.websphere.longrun.JobStatusConstants) ou avec les constantes du planificateur de travaux (voir l'API com.ibm.websphere.longrun.JobSchedulerConstants). Les constantes JobStatusConstants représentent le statut du travail, par exemple : soumis, terminé, redémarrable, annulé ou échec de l'exécution.

Le statut du travail peut être obtenu à l'aide de l'interface EJB getJobStatus, de l'interface de services Web getJobStatus ou via la console d'administration des travaux. JobSchedulerConstants représente les conditions d'exploitation renvoyées par le planificateur de travaux sur des demandes impliquant plusieurs travaux. Par exemple :

int[] cancelJob( String[] jobid ))
Ces conditions comprennent :
  1. Le travail n'existe pas.
  2. Le travail n'a pas un statut valide.
  3. Une exception de base de données s'est produite.
Tableau 1. Codes retour des tâches par lots . Le tableau inclut chaque code retour avec une explication.
Code retour Explication
0 Le travail s'est terminé normalement.
-4 Le travail a été suspendu.
-8 Le travail a été annulé.
-10 La tâche a été annulée de force (z/OS® seulement)
-12 Le travail a échoué et a le statut redémarrable.
-14 Le travail a échoué et a le statut 'Echec de l'exécution'
Évitez les ennuis : Même si une application peut définir une valeur pour le code retour de la tâche, cette valeur n'est renvoyée que lorsque la tâche se termine normalement. Si le travail échoue avec un statut indiquant que l'exécution a échoué ou le statut redémarrable, la valeur renvoyée est l'un des codes retour négatifs d'exécution décrits dans le tableau précédent.
Deux options sont utilisées pour signaler une erreur dans une application par lots :
  • La première option permet à l'application de produire une exception lorsqu'une erreur est rencontrée. Cela a pour résultat d'arrêter le travail avec le code retour de travail par lots -12 et le statut restartable. L'exception peut être émise dans n'importe laquelle des méthodes de l'API par lots.
  • La seconde option permet à l'application de renvoyer un code retour BatchConstants.STEP_COMPLETE_EXECUTION_FAILED (voir l'interface de programme d'application com.ibm.websphere.batch.BatchConstants) à partir de la méthode processJobStep et un code retour d'erreur spécifique à l'application à partir de la méthode destroyJobStep. Cela entraîne l'arrêt du travail et un statut de travail par lots deexecution failed . Le code retour d'étape défini dans la méthode destroyJobStep est transmis à l'algorithme de résultats spécifié dans l'étape du travail et est utilisé pour influencer le code retour du travail afin d'indiquer la cause précise de l'échec.
Tableau 2. Codes de retour des tâches d'utilitaire spécifiques à WSGrid . Le tableau inclut chaque code retour avec une explication.
Code retour Explication
-1 Erreur de protocole interne
-2 Erreur de paramètre d'entrée
-16 Incident sérieux ou échec de l'exécution

Par défaut, l'utilitaire WSGrid signale le code retour -16 spécifique à WSGrid si le travail Java Batch qu'il a soumis se termine avec l'état d'échec d'exécution. Le com.ibm.websphere.batch.execution.failed.wsgrid.rc La propriété personnalisée du planificateur de travaux modifie le comportement par défaut du travail Java Batch WSGrid en cas d'échec d'exécution.