Error JCL ABEND S837 al ejecutar un Job

El error JCL ABEND S837 es un retorno con el que nos vamos a encontrar de manera frecuente si trabajamos habitualmente con JCL Cobol. Si miramos la salida de uno de estos jobs fallidos, veremos que el detalle del problema es SYSTEM COMPLETION CODE=837  REASON CODE=00000008. Por tanto, la pregunta sería: ¿Cómo podemos solucionar este tipo de error?

Error ABEND S837 en ejecución de JCL Cobol

Obviamente, cuanto mayor experiencia vayamos teniendo con el lenguaje JCL, menos posibilidades hay de que veamos un S837. Pero, de todas formas, nada nos va a librar de cruzarnos con él de vez en cuando.



De hecho, hace algunas semanas, al lanzar un job (denominado JJUNLDIA) en uno de nuestros proyectos, obtuvimos precisamente un ABEND S837. Al revisar el contenido de la salida, pudimos ver que la descripción del error era la siguiente. 

10.43.35 JOB07414  -STEPNAME PROCSTEP    RC   EXCP   CONN       TCB

10.43.35 JOB07414  -PASO1    STEP010     00     81     55       .00
10.47.24 JOB07414  IEC028I 837-08,IFG0554A,JJUNLDIA,STEP030,SYSREC01
   206             JJPR.UNLOAD.X0005X.DIARIO.JJADOR 
10.47.28 JOB07414  $HASP375 JJUNLDIA ESTIMATED  LINES EXCEEDED
10.47.33 JOB07414  $HASP375 JJUNLDIA ESTIMATE EXCEEDED BY
10.47.37 JOB07414  IEA995I SYMPTOM DUMP OUTPUT  252                 
   252             SYSTEM COMPLETION CODE=837  REASON CODE=00000008 
   252              TIME=10.47.24  SEQ=19523  CPU=0000  ASID=012E  
   252              PSW AT TIME OF ERROR  075C1000   80DB8916  ILC 2
   252                NO ACTIVE MODULE FOUND                       
   252                NAME=UNKNOWN                                 
   252                DATA AT PSW  00DB8910 - 41003038  0A0DB20A  00
   252                AR/GR 0: 008D03E8/00DB8B24   1: 00000000/A4837
   252                      2: 00000000/000F4660   3: 00000000/00DB8
   252                      4: 00000000/008A64A8   5: 00000000/00DCF
   252                      6: 00000000/008A674C   7: 00000000/008A6
   252                      8: 00000000/008A676C   9: 00000000/008A7
   252                      A: 00000000/008BC8F8   B: 00000000/00DB8
   252                      C: 00000000/008A7680   D: 00000000/7FFB7
   252                      E: 00000000/00DB85A2   F: 00000000/00000
   252              END OF SYMPTOM DUMP
 10.47.39 JOB07414  -PASO1    STEP030     16  16137   6758       .02

En rojo hemos marcado la parte conflictiva de la ejecución, donde se especifica el error SYSTEM COMPLETION CODE=837  REASON CODE=00000008, y donde se indica cuál es el objeto causante del problema: en este caso, el fichero secuencial JJPR.UNLOAD.X0005X.DIARIO.JJADOR.

IEC028I 837-08,IFG0554A,JJUNLDIA,STEP030,SYSREC01,7820,$GB030
   206             JJPR.UNLOAD.X0005X.DIARIO.JJADOR
SYSTEM COMPLETION CODE=837  REASON CODE=00000008
NO ACTIVE MODULE FOUND

Causa del error ABEND S837

Hay que puntualizar que este JCL se encarga de crear el fichero secuencial mencionado. Por tanto, el problema no tiene nada que ver con que el proceso se haya encontrado con un dataset duplicado ni nada por el estilo.

Este job vuelca los datos de una tabla DB2 en un fichero secuencial y, en realidad, el error se produce por un problema de dimensionamiento del tamaño del fichero de salida. En este caso, estamos hablando de un DB2 con varios cientos de miles de registros y, por tanto, tenemos que ser cuidadosos a la hora de definir las características del dataset en nuestro JCL (aquí podemos ver un ejemplo de cómo se debe crear un fichero secuencial mediante la utilidad IEFBR14).



Echando un vistazo al código, vemos que el fichero de salida estaba definido del siguiente modo en el JCL.

//SYSREC01 DD DSN= JJPR.UNLOAD.X0005X.DIARIO.JJADOR,
//            DISP=(NEW,CATLG,DELETE),UNIT=(DISCO),    
//            SPACE=(TRK,(15,15),RLSE)            

Como se puede apreciar, para su alta se ha establecido en la cláusula SPACE que el fichero se cree usando 15 tracks como espacio primario y 15 tracks como espacio secundario. Esto es, a todas luces, insuficiente para trabajar con una tabla DB2 de varios cientos de miles de registros.

Cómo solucionar un ABEND S837

Por tanto, para solucionar el problema tendríamos que proceder a ampliar tanto el espacio primario como el secundario asignado al fichero de nueva creación. Haciendo esto, el dataset no tendrá problemas para absorber los 600.000 registros al ejecutarse el job.



En nuestro caso, para corregir el error procedimos a definir una nueva cláusula SPACE con dos cilindros como espacio primario y otros dos cilindros como espacio secundario. Recordemos que un cilindro equivale a 15 tracks y, por tanto, dos cilindros serían 30 tracks.

//SYSREC01 DD DSN= JJPR.UNLOAD.X0005X.DIARIO.JJADOR,
//            DISP=(NEW,CATLG,DELETE),UNIT=(DISCO),    
//            SPACE=(CYL,(2,2),RLSE)

Una vez realizado el cambio mencionado, procedimos a relanzar el JCL y, en esta ocasión, el job finalizó sin generar ningún error ni ningún ABEND, mostrando un CONDITION CODE = 0000. De hecho, al chequear el fichero de salida comprobamos que se habían cargado correctamente los 600.000 registros.



Por tanto, si alguna vez obtenéis un error del tipo ABEND S837, aseguraos de que estáis definiendo los ficheros de salida con el suficiente espacio, tanto primario como secundario. Esto os puede ahorrar bastante tiempo a la hora de detectar la causa del problema.

Y eso es todo. Esperamos que lo comentado os sirva para sacaros de un apuro si vuestro job se encuentra en una situación similar. Por supuesto, podéis hacernos cualquier pregunta que consideréis oportuna.

Saludos.