Grupos de jobs JES2 en la práctica

Un JOBGROUP hace visibles para JES2 un conjunto de jobs relacionados y sus respectivas reglas de secuenciación como un único objeto de orquestación. En lugar de pedir a cada job que descubra sus propias dependencias, primero se define la orquestación y después se asocian los jobs reales a ese grupo.

Este artículo es deliberadamente práctico. Define un pequeño JOBGROUP, envía los jobs asociados en el mismo input stream y valida un flujo simple:

• JGA se ejecuta primero
• JGB y JGC se ejecutan después de JGA
• JGD se ejecuta solo después de JGB y JGC

1. Objetivos del laboratorio

Al final del laboratorio debería poder:

• Explicar qué es un JOBGROUP de JES2
• Distinguir JOBGROUP de SCHEDULE AFTER/BEFORE/DELAY=YES
• Definir un grupo de jobs nativo con GJOB y AFTER
• Asociar jobs al grupo con SCHEDULE JOBGROUP=...
• Entender las principales restricciones del bloque de definición del grupo

2. Entorno necesario

Para este laboratorio, necesita:

• z/OS 2.2 o posterior
• JES2
• acceso TSO/ISPF con permiso para enviar jobs encadenados
• acceso SDSF, o un monitor equivalente para estados de jobs y de grupos de jobs JES2

Requisitos importantes:

• Los grupos de jobs JES2 deben estar configurados y activos a nivel del sistema (JES2 GRPDEF)
• La instalación debe estar en el modo de activación JES2 exigido para grupos de jobs. Todos los miembros deben estar ejecutando z/OS 2.2 o posterior para el modo de activación requerido

Si el laboratorio falla inmediatamente en el momento del envío con errores JES2 de grupos de jobs, pida al programador de sistema que verifique la activación de los grupos antes de continuar.

3. Lo que JOBGROUP le aporta

Un grupo de jobs JES2 es una definición nativa de orquestación dentro del input stream enviado. Describe:

• Los jobs que pertenecen al grupo
• Las reglas de dependencia entre ellos
• El objeto global de orquestación que JES2 monitoriza

Las sentencias principales son:

Para asociar un job enviado a un grupo de jobs, el propio job usa:

//         SCHEDULE JOBGROUP=group-name

4. Por qué JOBGROUP es más fuerte que la secuenciación dinámica ligera

En el modelo SCHEDULE AFTER/BEFORE/DELAY=YES, cada job descubre dinámicamente sus dependencias a medida que los jobs entran y salen de JES2. Eso es útil, pero conviene tener algunos cuidados operativos debido a la forma en que JES2 lo implementa: la dependencia se resuelve de forma distribuida y dinámica, job a job, a partir del estado corriente de las colas JES2.

JOBGROUP cambia el modelo:

• El objeto de orquestación se crea primero
• Los jobs se registran en ese grupo
• JES2 controla el flujo desde la propia definición del grupo

Por eso IBM indica explícitamente que JOBGROUP evita los problemas observados en la secuenciación dinámica ligera (modelo SCHEDULE AFTER/BEFORE/DELAY=YES).

5. Restricciones importantes antes de codificar el laboratorio

El bloque del grupo de jobs no es JCL ordinario. Existen varias restricciones:

• Solo se permiten sentencias de control de ejecución JES2 entre JOBGROUP y ENDGROUP
• No se permiten sentencias JECL como /*...
• No se permiten datos in-stream
• No se permiten símbolos
• No se permiten sentencias normales JOB, EXEC o DD dentro del propio bloque de definición del grupo

Los jobs batch reales van después de la definición del grupo y se asocian a él con SCHEDULE JOBGROUP=....

6. La orquestación que vamos a construir

Este laboratorio usa el siguiente grafo nativo de dependencias:

JGA
├── JGB
└── JGC
    └──
     JGD

Más concretamente:

• JGB se ejecuta después de JGA
• JGC se ejecuta después de JGA
• JGD se ejecuta después de JGB y JGC

Los propios jobs van a ejecutar acciones simples sobre data sets para que pueda validar que la secuencia realmente ocurrió.

7. Crear el input stream completo

Cree un miembro como JGLAB con el siguiente contenido:

//MYJG     JOBGROUP
//JGA      GJOB
//JGB      GJOB
//         AFTER NAME=JGA,WHEN=(RC=0)
//JGC      GJOB
//         AFTER NAME=JGA,WHEN=(RC=0)
//JGD      GJOB
//         AFTER NAME=(JGB,JGC)
//MYJGD    ENDGROUP
//*
//JGA      JOB ,'JOBGROUP LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//         SCHEDULE JOBGROUP=MYJG
//STEP1    EXEC PGM=IEFBR14
//OUTA     DD  DSN=&SYSUID..JGDEMO.A,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//*
//JGB      JOB ,'JOBGROUP LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//         SCHEDULE JOBGROUP=MYJG
//STEP1    EXEC PGM=IEFBR14
//OUTB     DD  DSN=&SYSUID..JGDEMO.B,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//*
//JGC      JOB ,'JOBGROUP LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//         SCHEDULE JOBGROUP=MYJG
//STEP1    EXEC PGM=IEFBR14
//OUTC     DD  DSN=&SYSUID..JGDEMO.C,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//*
//JGD      JOB ,'JOBGROUP LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//         SCHEDULE JOBGROUP=MYJG
//STEP1    EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DELETE '&SYSUID..JGDEMO.A'
  IF LASTCC = 8 THEN SET MAXCC = 0
  DELETE '&SYSUID..JGDEMO.B'
  IF LASTCC = 8 THEN SET MAXCC = 0
  DELETE '&SYSUID..JGDEMO.C'
  IF LASTCC = 8 THEN SET MAXCC = 0
/*

Envíe el miembro una sola vez para que la definición del grupo de jobs y los jobs asociados entren juntos en JES2.

8. Qué observar después del envío

En SDSF, o en su monitor JES2 equivalente, busque:

• Los cuatro jobs JGA, JGB, JGC y JGD
• El objeto de grupo de jobs JGDEMO
• El orden de ejecución

Comportamiento esperado:

• JGA se vuelve elegible primero
• JGB y JGC permanecen dependientes de JGA
• JGD permanece dependiente de JGB y JGC
• Después de que JGA termine con RC=0, JGB y JGC se vuelven elegibles
• Después de que ambos terminen, JGD se vuelve elegible

Resultado funcional esperado:

• JGA, JGB, JGC y JGD terminan normalmente
• JGD elimina los tres data sets creados por los jobs anteriores

Esto confirma que la secuenciación del grupo se impuso correctamente.

9. Por qué la condición WHEN=(RC=0) es importante

La dependencia de JGA hacia JGB y JGC no es solo “después de JGA”. Es:

AFTER NAME=JGA,WHEN=(RC=0)

Eso significa que la dependencia solo queda satisfecha cuando JGA termina con RC=0.

Este es el valor práctico:

• Puede construir reglas de orquestación basadas en la calidad de finalización
• Un job padre que termina mal no tiene por qué liberar el resto del flujo

En diseños de grupos mayores, aquí es donde WHEN=, ACTION= y OTHERWISE= se vuelven operacionalmente importantes.

10. Cómo encaja JOBSET

Este laboratorio usa solo GJOB porque es la forma más simple de introducir la función, pero JOBSET es la siguiente capacidad que conviene aprender cuando el grafo empieza a crecer.

El objetivo de JOBSET es permitir tratar varios jobs como una única unidad de orquestación nombrada dentro del grupo de jobs. En lugar de escribir dependencias contra jobs individuales uno a uno, se define un conjunto y luego se hace referencia a ese conjunto por su nombre.

En la práctica, JOBSET es útil cuando:

• Varios jobs pertenecen a la misma fase lógica del flujo
• Un sucesor debe esperar a un conjunto completo de jobs, y no solo a un job
• Quiere que el modelo de dependencias describa fases de negocio y no solo jobs aislados
• Quiere que el comportamiento de flush sea controlado al nivel del conjunto con FLUSHTYP

Piense en la distinción de esta forma:

10.1 Qué problema resuelve JOBSET

Suponga que tiene tres jobs de extracción:

• EXTA
• EXTB
• EXTC

y después un job de consolidación:

• LOAD1

Sin JOBSET, la dependencia se expresa job a job:

//LOAD1    GJOB
//         AFTER NAME=(EXTA,EXTB,EXTC)

Esto sigue siendo válido, pero la intención queda solo implícita. JES2 ve tres jobs padre individuales, no una fase nombrada.

Con JOBSET, puede modelar esa fase explícitamente:

//EXTRSET  JOBSET
//EXTA     SJOB
//EXTB     SJOB
//EXTC     SJOB
//EXTRSET  ENDSET
//LOAD1    GJOB
//         AFTER NAME=EXTRSET

Ahora la dependencia se lee de forma más natural:

• Primero el conjunto de extracción
• Después el job de carga

Ese es el principal valor de JOBSET: una estructura de orquestación más clara.

10.2 Cuándo JOBSET es más útil que GJOB

JOBSET se vuelve útil cuando el grafo deja de ser “solo unos pocos jobs” y empieza a tener fases reutilizables o reconocibles.

Ejemplos típicos:

• Una fase de extracción paralela seguida por una fase de merge
• Varios jobs de validación seguidos por un job de publicación
• Una familia de jobs regionales seguida por un resumen global
• Un conjunto de jobs preparatorios que todos deben terminar antes de que empiece la fase siguiente

En ese momento, JOBSET mejora la legibilidad porque:

• La lista de dependencias se vuelve más corta
• La definición del grupo empieza a reflejar mejor las fases reales del proceso
• El mantenimiento posterior se vuelve más fácil cuando hay que añadir un nuevo job al conjunto

10.3 Por qué FLUSHTYP importa

JOBSET también introduce una capacidad importante que GJOB simple no ofrece de forma tan limpia: semántica de flush al nivel del conjunto.

IBM documenta FLUSHTYP en JOBSET como:

• ALLFLUSH
• ANYFLUSH

Esto controla lo que ocurre con los jobs del conjunto cuando los jobs padre son flushed.

Significado práctico:

• ALLFLUSH: hace flush de un job del conjunto solo si todos los jobs padre son flushed
• ANYFLUSH: hace flush de un job del conjunto si cualquier job padre es flushed

Esto importa cuando el conjunto representa una fase real y necesita un comportamiento coherente de fallo o bypass para toda la fase.

10.4 Regla práctica de bolsillo

Use GJOB cuando:

• El grafo es pequeño
• Las dependencias job a job siguen siendo fáciles de leer
• Está introduciendo la función por primera vez

Use JOBSET cuando:

• Varios jobs forman una única fase lógica
• Un job posterior depende de la fase como un todo
• Necesita comportamiento de flush al nivel del conjunto
• La orquestación empieza a resultar difícil de leer como una lista plana de nombres GJOB

11. Cómo esto difiere de las capacidades básicas de scheduling

Las capacidades básicas de scheduling cubren:

• HOLDUNTL
• AFTER
• BEFORE
• DELAY=YES

Siguen siendo útiles, pero funcionan como controles más ligeros de scheduling por job.

Los grupos de jobs son diferentes:

• El objeto de orquestación existe primero como JOBGROUP
• Los jobs se asocian después con SCHEDULE JOBGROUP=...
• JES2 gestiona la red de dependencias a partir de esa definición nativa del grupo

11. Cleanup

En esta versión del laboratorio no se necesita un job adicional de cleanup. El job final JGD ya elimina los tres data sets creados por JGA, JGB y JGC.

Si quiere repetir el laboratorio inmediatamente después de una ejecución satisfactoria, es más seguro crear una segunda variante del miembro con un nombre JOBGROUP diferente y nombres de job diferentes, porque JES2 todavía puede retener durante algún tiempo los metadatos del grupo anterior.

Resumen

Si necesita orquestación nativa dentro de JES2, JOBGROUP es la respuesta más fuerte.

El patrón práctico es:

1. Definir primero la orquestación con JOBGROUP, GJOB, AFTER y sentencias relacionadas 2. Enviar los jobs reales con:

//         SCHEDULE JOBGROUP=group-name

Eso da a JES2 un grafo nativo de dependencias en lugar de pedir a cada job que descubra dinámicamente sus propias dependencias.

Documentación útil de IBM

• Sentencias de control de ejecución JES2
• Ejemplos de un JOBGROUP y jobs asociados
• Sentencia JOBGROUP
• Sentencia GJOB
• Sentencia JOBSET
• Sentencia SJOB
• Sentencia AFTER
• Sentencia CONCURRENT
• Configurar y activar grupos de jobs
• JOBGROUP logging job