Control-M: Gestión de ejecuciones Batch (y 2)

Hace algunas semanas comenzamos a ver el funcionamiento de la opción ACTIVE ENV de la herramienta Control-M. Se trata de una opción encaminada a realizar la gestión de las ejecuciones de los procesos batch de nuestra aplicación. Por supuesto, en el mundo Host existen otras alternativas para realizar este trabajo, pero he de deciros que, hoy en día, Control-M es una de las soluciones más extendidas.

En la primera parte del artículo nos pusimos a examinar los pasos que había que seguir para comenzar a operar con la opción ACTIVE ENV (ver post Control-M - Gestión de ejecuciones Batch - 1). Hoy nos centraremos en tratar de completar la revisión iniciada en el post anterior. Si todo va bien, cuando finalicemos ya deberíais tener las nociones básicas para poder empezar a trabajar con Control-M. Por tanto, ahora continuemos viendo los pasos a partir de donde lo dejamos el último día.

4º) Si introducimos una 'S' en la línea de comando y pulsamos INTRO, accedemos a una ventana en la que podemos filtrar las fases mostradas en el listado.

Como se aprecia en la imagen, se puede filtrar por infinidad de conceptos: por el nombre de la fase, por grupo, por rango de fechas, por estado de ejecución, por propietario, etc... En el ejemplo procederíamos a recuperar únicamente las fases batch cuyo nombre empiece por A8.

5º)  Si se selecciona una fase con 'S' y se pulsa INTRO, accederemos a un histórico de las últimas ejecuciones. Se muestra la fecha de ejecución, así como la hora de inicio y la hora de fin del proceso batch.

En el ejemplo anterior podemos ver el registro de las últimas ejecuciones de una fase batch. Tal y como se observa, para cada ejecución se muestra su fecha/hora de inicio (STRT DATE/TIME) y su fecha/hora de finalización (END DATE/TIME). Junto a estas columnas, también se muestra el número de minutos consumidos por el job lanzado (ELAPSED).

Conclusiones acerca del Gestor de Ejecuciones de Control-M

Como hemos visto, la opción ACTIVE ENVIRONMENT de Control-M no plantea excesivas dificultades para un empleo estándar. En general, esta funcionalidad la usaremos para verificar el estado de los procesos batch en curso y para chequear las salidas de las ejecuciones ya finalizadas. La información mostrada por la aplicación nos será de gran utilidad a la hora de analizar los eventuales errores que aparezcan en nuestras fases.

Recordad que en el ejemplo que os he mostrado, Control-M está incluido en el Bloque 4 (Control-M & CTM/Restart) del POM de la herramienta IOA (Integrated Operations Arquitecture). Sin embargo, IOA es una arquitectura abierta y, por tanto, la organización podría ser distinta en vuestra instalación. De todas formas, una vez que detectéis la ubicación del bloque, la estructrura interna de Control-M será la misma que os he indicado en el post.

Entre esta opción y la funcionalidad de Planificación de fases que vimos el otro día, ya tenemos las herramientas básicas para empezar a trabajar con Control-M. Os aconsejo que comencéis a emplear esta aplicación lo antes posible (si no la tenéis, pedid que os la incluyan en vuestra instalación), ya que os va a permitir resolver los problemas batch con mayor celeridad. Así ha sido en mi experiencia, y estoy seguro de que así será también en la vuestra.

Pues nada, eso es todo lo que quería indicaros con respecto a la opción ACTIVE ENVIRONMENT de Control-M. Espero que lo comentado os sea suficiente para moveros por la herramienta sin problemas. En cualquier caso, ya sabéis que aquí abajo podéis dejarme las dudas que tengáis.

Saludos.

Control-M: Gestión de ejecuciones Batch (1)

Hace algún tiempo ya estuvimos hablando de la herramienta Control-M y de sus bondades a la hora de realizar la gestión de cadenas batch. En su momento estuvimos examinando la funcionalidad de JOB SCHEDULE DEF de Control-M, empleada para la planificación de fases batch. Sin embargo, nos quedó pendiente revisar la funcionalidad ACTIVE ENV, la cual nos permite acceder a las ejecuciones de los jobs y obtener el detalle de los errores producidos. Vamos con ello.

Control-M: Revisión de ejecución de Fases Batch

Como vimos en su día, la herramienta Control-M es una aplicación ampliamente extendida entre las instalaciones de la mayoría de los clientes importantes. En general, tiene dos usos principales. Por un lado, se emplea para planificar las fases y las cadenas batch de una aplicación. Y, por otro lado, también se usa para realizar toda la gestión de ejecuciones de los procesos batch.

Hoy nos vamos a centrar en revisar esta última funcionalidad, que se realiza desde el apartado ACTIVE ENV de Control-M. Desde esta opción podremos revisar el estado de las ejecuciones batch, ver si una fase está pendiente de lanzamiento o si ya está en curso, examinar el detalle de los errores en aquellos procesos fallidos, etc... Básicamente, tendremos acceso a todas las especificaciones de la parte batch de nuestra aplicación o de nuestro módulo.

En la imagen anterior podemos ver el menú principal de Control-M, una de las herramientas más conocidas del mundo Host. Obviamente, nuestra aplicación está incluida en el bloque cuarto denominado Control-M & CTM/Restart. En su día ya estuvimos viendo la opción 2 - JOB SCHEDULE DEF. La funcionalidad a la que nos vamos a referir hoy es la incluida en la opción 3 - ACTIVE ENV.

Control-M: Opción de Active Environment

A continuación, vamos a ir viendo los pasos que hay que seguir para navegar por la opción 3 de Control-M, denominada ACTIVE ENV. Esta funcionalidad nos sirve para consultar el estado o el resultado de la ejecución de una fase de una cadena batch. Además, nos puede ser de gran ayuda a la hora de determinar las causas de un error en el procesamiento de un Job.



Los pasos a seguir para operar correctamente con la facilidad ACTIVE ENV de Control-M son los siguientes.

1º) Entrar en el menú principal de Control-M. En mi instalación, esto se hace entrando en la aplicación IOA desde ISPF mediante el comando IOA del entorno TSO. Posiblemente en vuestra instalación esté configurado de otra forma.

2º) Seleccionar la opción 3 - ACTIVE ENV. Una vez que estamos dentro de la arquitectura IOA, dicha opción la encontraremos en el bloque Control-M.

3º) En el menú principal de ACTIVE ENVIRONMENT se nos muestra el listado de fases correspondientes a las cadenas batch de nuestra aplicación. 

Como vemos en la imagen, en el entorno ZOS se muestra el nombre de la fase (NAME), el propietario (OWNER), la fecha de ejecución (ODATE) y el estado de la ejecución (STATUS).

En el campo estado de la ejecución se pueden mostrar las siguientes variantes (cada una con su propio color asignado).

- Estado WAIT SCHEDULE: En blanco o azul. Son las fases batch que están planificadas pero que aún no han iniciado su ejecución. Están en espera.

- Estado EXECUTING: En amarillo. Son las fases que están ejecutándose, tanto aquellas que estaban planificadas como las que hemos relanzado manualmente.
 
- Estado ENDED OK: En verde. Son las fases batch que ya han terminado su ejecución y que han terminado el proceso de manera correcta.

- Estado ENDED - NOT OK - ABENDED: En rojo. Son las fases batch que han terminado su ejecución y que han finalizado el proceso de manera errónea (como era de esperar, por el color rojo).

El próximo día, en un nuevo post, continuaremos viendo los pasos que hay que seguir para comenzar a operar con la opción ACTIVE ENV de Control-M. Recordemos que este apartado se emplea para la gestión de las ejecuciones batch. Dicha opción y la funcionalidad de planificación de fases batch (opción JOB SCHEDULE DEF) constituyen la columna vertebral de la herramienta Control-M.

Pues nada, eso es todo por ahora. Quedáis invitados a la segunda parte del artículo, donde completaremos la revisión que hemos iniciado hoy. Sinceramente, espero que no faltéis a la cita...

Saludos.

Control-M: Planificación de ejecuciones Batch (y 2)

Hace algunas semanas comenzamos a ver cómo se podía acceder a la Planificación de ejecuciones Batch mediante la herramienta Control-M. Actualmente, esta herramienta es utilizada ampliamente en las instalaciones Mainframe para realizar el tratamiento de la parte batch de las aplicaciones de numerosos grandes clientes. Por tanto, creo que no tengo que hacer mucho más hincapié en la importancia de iniciar el aprendizaje de la misma cuanto antes.

En la primera parte del artículo estuvimos viendo cuáles eran los pasos a seguir para acceder a la opción JOB SCHEDULE DEF (ver post Control-M - Planificación de ejecuciones Batch - 1). Dicho apartado nos sirve para consultar los atributos asociados a la ejecución de las fases de una cadena batch. Hoy nos centraremos en otra interesante funcionalidad de Control-M: se trata de una opción que nos permitirá acceder a un esquema gráfico de la cadena batch seleccionada.

Control-M: Esquema gráfico del Batch

Para los que gusten de esquemas visuales, Control-M dispone de una opción para mostrarnos, de un modo gráfico, el orden de ejecución de las fases de una cadena batch. La verdad es que esta opción se agradece a la hora de examinar cadenas con un alto número de componentes, ya que nos permite ahorrar gran cantidad de tiempo. En cualquier caso, también se podría alcanzar el mismo resultado revisando los atributos de los procesos batch desde la consulta de Definición de Fases.

Para poder acceder al esquema gráfico de una cadena batch determinada, bastará con seguir los siguientes pasos.

1º) Accedemos al menú de Listado de Cadenas, donde se muestran todas las cadenas que tenemos planificadas en nuestra aplicación.

 
2º) Seleccionamos la cadena deseada con 'G' y pulsamos INTRO. De este modo accedemos a la pantalla en la que se nos muestra el esquema gráfico de dicha cadena.

 
Como se aprecia en la imagen anterior, en esta consulta se nos muestran varias cajas con los nombres de las distintas fases incluidas en la cadena batch seleccionada. Adicionalmente, mediante flechas, también se nos muestran las distintas relaciones de precedencia entre dichas fases. Por ejemplo, en la imagen se puede ver que en primer lugar se ejecutará la fase A801RBK0 y, una vez finalizada, se lanzará la fase A8ESRAPE (A801RBK0 ---> A8ESRAPE).

Conclusiones acerca de la herramienta Control-M

La verdad es que la herramienta Control-M y, en particular, la opción de Planificación de ejecuciones Batch que hemos visto en el post, nos pueden resultar muy útiles a la hora de gestionar las cadenas de fases batch de nuestra aplicación. Una consulta lanzada a través de esta opción nos va a bastar para tener una visión global clara de cómo está estructurada la parte batch de un sistema Host.

-------------------------------------------------------------------------------------------------------------------------------
Tip: Aquí podéis acceder a la lista de utilidades básicas Batch para JCL
-------------------------------------------------------------------------------------------------------------------------------

Es posible que tengáis mala suerte y en vuestra instalación no se disponga de ella. Sin embargo, esto es improbable. Os comento que en mi caso, por ejemplo, me he encontrado con Control-M en todos los clientes con plataforma Host con los que he trabajado hasta ahora. Así que no os va a quedar más remedio que aprender a convivir con esta herramienta y, cuanto antes aprendáis a hacerlo, pues menos problemas tendréis en vuestro día a día.

Cuando os incorporéis a un nuevo sistema, tendréis dos grandes aliados para adquirir conocimientos sobre su parte batch. Por un lado, el Manual de Explotación, que estará más o menos detallado en función del tiempo que le hayan dedicado los analistas precursores. Por otro lado, la herramienta Control-M. Accediendo a su apartado de Planificación, podréis ver cuáles son las fases de las que se compone la cadena batch y, lo que es mejor, todas las características asociadas a cada una de ellas.

En definitiva, creo que Control-M es una herramienta imprescindible para la plataforma Host. Si es posible, hemos de tratar que se incorpore en nuestra instalación. De todas formas, si trabajáis en un cliente grande, lo más probable es que esta aplicación ya esté integrada en su entorno ZOS. De una forma u otra, será muy beneficioso para vosotros que aprendáis a usarla (cuanto antes mejor).

Y eso es todo. Por mi parte, ya no me queda nada más que comentaros sobre la opción de Planificación de Control-M. Ya sabéis, las dudas podéis dejarlas aquí abajo y yo trataré de contestaros en cuanto tenga un hueco disponible.

Saludos.

Control-M: Planificación de ejecuciones Batch (1)

La herramienta Control-M es una de las más utilizadas para la definición y gestión de cadenas de fases batch en el mundo Host. Por supuesto, existen otras alternativas, pero esta aplicación es una de las más extendidas entre los clientes importantes. Dentro de sus diversas opciones, destaca la funcionalidad de Scheduling Definition Facility. Hoy vamos a echarle un vistazo.

Control-M para gestión de cadenas Batch

Los que ya tengan algo de experiencia en Mainframe estarán de acuerdo conmigo en que Control-M es una herramienta Host muy útil a la hora de enfrentarse con cadenas batch. Nos permite tanto definir los atributos con los que se va a ejecutar una determinada fase como examinar los resultados de la ejecución de un JCL. Ambas tareas nos van a servir para ahorrar mucho tiempo de análisis.

La verdad es que ya he trabajado en varias aplicaciones Host de clientes distintos y, hasta ahora, en todos ellos he tenido disponible el Control-M. Os digo esto para que os hagáis una idea de lo rentable que puede ser aprender a manejar esta herramienta. En cualquier caso, creo que tarde o temprano tendréis que enfrentaros con ella.

 
En la imagen anterior podemos ver el aspecto del menú principal (POM) de la aplicación IOA (Integrated Operations Architecture). Como podemos ver, en mi instalación actual el POM está dividido en 4 bloques diferenciados: IOA, Control-D, Control-O y Control-M & CTM/Restart. Como no es difícil deducir, nuestra herramienta Control-M es la correspondiente al cuarto bloque mostrado en el menú.

Control-M: Scheduling Definition Facility

A continuación, vamos a ir viendo los pasos que hay que seguir para navegar por la opción 2 de Control-M, denominada JOB SCHEDULE DEF. Esta funcionalidad nos sirve para definir (o consultar) los atributos asociados a la ejecución de las fases de una cadena batch. Además, nos puede ser de gran ayuda a la hora de determinar las causas de un error en el procesamiento de un Job.

Los pasos a seguir para operar correctamente con la facilidad JOB SCHEDULE DEF son los siguientes.

1º) Entrar en el menú principal de Control-M. En mi instalación, esto se hace entrando en la aplicación IOA desde ISPF mediante el comando TSO IOA. Posiblemente en vuestra instalación esté configurado de otra forma.

2º) Seleccionar la opción 2 - JOB SCHEDULE DEF. Una vez que estamos dentro de la arquitectura IOA, dicha opción la encontraremos en el bloque Control-M.

3º) En la ventana de entrada de Scheduling Definition Facility debemos provisionar la línea LIBRARY. En ella debemos introducir la Librería en la que, en nuestra instalación, se estén guardando los atributos de los procesamientos de cadenas batch.

 
Como vemos, en el ejemplo anterior hemos introducido la librería ASPR.V7R01.A8.TRAN.SCHED en la línea LIBRARY. A continuación, pulsamos INTRO.

LIBRARY ===>    ASPR.V7R01.A8.TRAN.SCHED

4º)  Accedemos a la consulta en la que se muestra la Lista de Cadenas Batch que se están ejecutando en nuestra aplicación o en nuestro módulo.

 
5º) Seleccionamos una Cadena con 'S' y pulsamos INTRO. De este modo, accederemos a la ventana en la que se muestra el desglose de Fases Batch en las que se descompone dicha cadena.

 
6º) Aquí podemos seleccionar una Fase con 'S' y pulsar INTRO. Así accedemos a la consulta de definición de atributos del proceso batch elegido. Como veremos a continuación, esta consulta se divide en 4 ventanas.

* Definición de Fase Batch - Atributos 1

 
* Definición de Fase Batch - Atributos 2

* Definición de Fase Batch - Atributos 3

 
* Definición de Fase Batch - Atributos 4

 
En todas estas ventanas podremos ir viendo los atributos con los que se ha definido la ejecución de la Fase Batch seleccionada. Si el perfil de nuestro usuario nos lo permite, aquí también tendremos la opción de modificar los parámetros que deseemos. En cualquier caso, esta información nos será de mucha utilidad a la hora de analizar los errores de ejecución de la fase.

Una vez vista la opción de planificación de ejecuciones batch (JOB SCHEDULE DEF), ya nos debería quedar bastante clara la forma de consultar los atributos asociados a una determinada fase. Dicho esto, el próximo día (en un nuevo post) examinaremos una función que nos permitirá acceder a un esquema gráfico de la cadena batch seleccionada. Esta funcionalidad será del agrado de los que gusten de esquemas visuales, aunque no debemos olvidar que nos encontramos en plataforma Mainframe y, por tanto, no podemos esperar nada demasiado sofisticado.

Pues nada, eso es todo por hoy. Como siempre os digo, quedáis invitados a la segunda parte del artículo, donde trataremos de ampliar un poco más nuestro conocimiento de la herramienta Control-M. Espero veros por allí...

Saludos.

ICETOOL: Como cruzar Ficheros con SPLICE (y 2)

Hace algunas semanas comenzamos a ver cómo se podía realizar un cruce de ficheros en un JCL mediante el comando SPLICE de la herramienta ICETOOL. Hoy completaremos dicha revisión, de manera que, a la conclusión del post, ya deberíamos ser capaces de crear nuestro propio Job para realizar este tipo de procesamiento.

En la primera parte del artículo empezamos a examinar cuáles eran las fichas que había que incluir en el paso 1 del JCL, esto es, en el paso necesario para reformatear los ficheros de entrada (ver post ICETOOL - Como cruzar Ficheros con SPLICE - 1). En esta segunda parte nos concentraremos en revisar las fichas correspondientes al paso 2 del JCL, en el que se procederá a generar los ficheros de salida.

PASO 2: PASO ICETOOL PARA GENERAR SALIDAS

6º) Invocación a ICETOOL: Al iniciar el paso, como siempre, se debe realizar la invocación a la herramienta ICETOOL mediante el comando EXEC PGM.

//JJ0107   EXEC PGM=ICETOOL

7º) Ficheros de entrada: En esta ficha especificamos como entrada el fichero CONCAT, que será la unión de los dos ficheros indicados en el código: SIST.JJ0105T1.DDD.X0060X.POBL.T1 y SIST.JJ0105T2.X0060X.DDD.POBL.T2. Se puede apreciar que estos dos datasets son los ficheros de salida del Paso anterior del JCL.

//* CONCAT: FICHERO UNIFICADO PARA REALIZAR EL ICETOOL        
//CONCAT   DD  DSN=SIST.JJ0105T1.DDD.X0060X.POBL.T1,
//             DISP=SHR                             
//         DD  DSN=SIST.JJ0105T2.X0060X.DDD.POBL.T2,
//             DISP=SHR                      

8º) Ficheros de salida: Aquí se deben indicar los nombres de los ficheros de salida de la herramienta ICETOOL, que contendrán los registros modificados por el operador. En nuestro ejemplo son el SIST.JJ0107S1.X0060X.DDD.POBL.MD (que contiene los registros del MASTER modificados según la relación del KEYS) y el SIST.JJ0107S1.X0060X.DDD.POBL.RS (que contiene los registros que no han sido modificados en la operación).

//* OUT  : FICHERO SALIDA CON LOS REGISTROS MODIFICADOS         
//OUT      DD  DSN=SIST.JJ0107S1.X0060X.DDD.POBL.MD,
//             DISP=(NEW,CATLG,DELETE),             
//             SPACE=(CYL,(00100,00100),RLSE),              //             UNIT=DISCO
//* OUT1 : FICHERO SALIDA CON LOS REGISTROS NO MODIFICADOS
//OUT1     DD  DSN=SIST.JJ0107S2.X0060X.DDD.POBL.RS,  
//             DISP=(,CATLG,DELETE),                       
//             SPACE=(CYL,(00100,00100),RLSE),              
//             UNIT=DISCO
                                     

9º) Ficha TOOLIN: Aquí es donde tenemos que indicarle a la utilidad cuáles son las acciones que debe realizar. En nuestro caso, como estamos haciendo cruce de ficheros, tendremos que usar el operador SPLICE.

En la primera sentencia indicamos que, partiendo del fichero CONCAT, se debe transferir la información al fichero OUT realizando el cruce por el campo de longitud 6 que empieza en la posición 1 (Población). La forma de realizar dicho cruce se especificará en la ficha de control CTL3.

La cláusula WITHALL se emplea para que, en el caso de que una clave esté más de una vez en el fichero Maestro de Poblaciones (POBL.T2), se recojan todos los registros que la contengan. Si no se especifica WITHALL, entonces el filtrado se quedará únicamente con el primer registro encontrado. Por otra parte, al no incluir los comandos KEEPNODUPS y KEEPBASE, sólo saldrán en la salida los registros cuyas claves existan en ambos ficheros (POBL.T1 y POBL.T2).

Del mismo modo, en la segunda sentencia indicamos que, partiendo del fichero CONCAT, se debe transferir la información al fichero OUT1 realizando el cruce por el campo de longitud 6 que empieza en la posición 1 (Población). La forma de realizar dicho cruce se especificará en la ficha de control CTL4.

Las cláusulas KEEPNODUPS y KEEPBASE se emplean para mostrar en el fichero de salida los registros del fichero POBL.T1 cuya clave no existe en el fichero POBL.T2. Es decir, con estas cláusulas le indicamos al filtrado que nos saque toda la información de los ficheros, incluidos los registros de POBL.T1 cuyas claves no se localicen en el Maestro de Poblaciones (POBL.T2).

*--------------------------------------------------------*
* <<< FICHA JJRS1A06 >>>
* OUT: REGISTROS QUE COINCIDEN                           *
* INCLUIMOS TODO DEL MASTER MAS POBLACION NUEVA DE KEY   *
* MAS UN INDICADOR NUEVO DE MODIFICADO
* OUT1: RESTO DE REGISTROS QUE NO COINCIDEN              *
*--------------------------------------------------------*
  SPLICE FROM(CONCAT) TO(OUT) ON(1,6,CH) WITHALL  -
  WITH(7,40) USING(CTL3)                         
  SPLICE FROM(CONCAT) TO(OUT1) ON(1,6,CH) WITHALL  -
  WITH(7,40) USING(CTL4) KEEPNODUPS KEEPBASE       

10º) Fichas de Control: En esta tarjeta es donde tenemos que indicar cómo queremos que se realice la función SPLICE de la herramienta ICETOOL. En nuestro ejemplo, aquí estarían incluidas las fichas CTL3 y CTL4.

*--------------------------------------------------------*
* <<< FICHA JJRS1A07 >>>
* SUSTITUIMOS POBL ENCONTRADOS POR POBL NUEVAS
* SE INCLUYE INDICADOR DE MODIFICADO
*--------------------------------------------------------*
  OUTFIL FNAMES=OUT,
  INCLUDE=(47,1,CH,EQ,C'D'),
  OUTREC=(7,2,48,6,15,32)   


    
Esta primera ficha de control (CTL3) hace referencia al primer comando SPLICE de las sentencias del TOOLIN anterior. Como podemos ver en su codificación, en ella se hacen tres cosas con los datos de entrada.

-          OUTFIL: Se indica que la información se debe enviar desde el fichero de entrada CONCAT al fichero de salida OUT.

-          INCLUDE: Se establece la Condición de Filtrado. En esta sentencia se indica que debemos quedarnos únicamente con aquellos registros que en la posición 47 tengan un campo alfanumérico de longitud 1 igual a ‘D’ (INCLUDE=(47,1,CH,EQ,C’D’)).

-          OUTREC: A continuación, transfiere del CONCAT al OUT la siguiente información de los registros: el campo de longitud 2 que empieza en la posición 7 (7,2), el campo de longitud 6 que empieza en la posición 48 (la Población nueva) y el campo de longitud 32 que empieza en la posición 15 (15,32).

*--------------------------------------------------------*
* <<< FICHA JJRS1A08 >>>
* SACAMOS REGISTROS NO ENCONTRADOS PARA CUADRAR ENTRADA
*--------------------------------------------------------*
  OUTFIL FNAMES=OUT1,
  INCLUDE=(47,1,CH,EQ,C' '),
  OUTREC=(7,40)                              

La segunda ficha de control (CTL4) hace referencia al segundo comando SPLICE de las sentencias de la TOOLIN especificada anteriormente. Al igual que en la ficha CTL3 anterior, aquí también se realizan tres acciones sobre los registros de entrada.

-          OUTFIL: Se indica que la información se debe enviar desde el fichero de entrada CONCAT al fichero de salida OUT1.

-          INCLUDE: Se establece la Condición de Filtrado. Debemos quedarnos únicamente con aquellos registros que en la posición 47 tengan un campo alfanumérico de longitud 1 igual a un espacio en blanco (INCLUDE=(47,1,CH,EQ,C’ ’)).

-          OUTREC: A continuación, transfiere del CONCAT al OUT1 el campo de longitud 40 que empieza en la posición 7 (7,40).

Una vez especificados todos los puntos anteriores, ya se podrían ejecutar sin problemas los dos pasos JCL comentados. Para personalizar estas fichas, recordad que tendríamos que cambiar tanto los nombres de los ficheros de entrada y de salida como la ubicación de los campos (de los registros) indicados en las sentencias asociadas.

Ejecución de un JCL con SPLICE

Para ver el impacto que tendría la ejecución de un operador SPLICE, podemos ver cómo irían quedando los ficheros que se generen en los dos pasos JCL anteriores. Recordemos que inicialmente partimos del fichero con la relación clave antigua – clave nueva SIST.UNLOAD.X0005X.POBL.KEYS y del fichero de poblaciones SIST.UNLOAD.X0005X.POBL.MASTER.

Tras la ejecución del primer paso, se generan dos ficheros de salida, con denominación SIST.JJ0105T1.X0060X.DDD.POBL.T1 y SIST.JJ0105T2.X0060X.DDD.POBL.T2. El fichero POBL.T1 es el fichero de relaciones entre claves (KEYS) al que, al final, se ha añadido un literal ‘D’ y el código de la clave nueva de la población.

----+----1----+----2----+----3----+----4----+----5---
***************************** Top of Data ***********
000002-100002                                 D100002
000004-100004                                 D100004
000005-100005                                 D100005
000006-100006                                 D100006
000007-100007                                 D100007
000008-100008                                 D100008
000010-100010                                 D100010
**************************** Bottom of Data *********

El fichero POBL.T2 se corresponde con el fichero maestro de poblaciones (MASTER), al que al final se le han añadido siete posiciones en blanco. Con esto se consigue que POBL.T1 y POBL.T2 tengan la misma longitud de registro.

----+----1----+----2----+----3----+----4----+----5---
***************************** Top of Data ***********
000002B-000002-ALMERIA................ALM01300    
000004B-000004-SANTANDER..............SAN01500    
000005B-000005-TARRAGONA..............TAR01600    
000006B-000006-BADAJOZ................BAD01700    
000007B-000007-SALAMANCA..............SAL01800    
000008B-000008-BURGOS.................BUR01900    
000010B-000010-SEGOVIA................SEG01100    
000011B-000011-TOLEDO.................TOL01000    
000012B-000012-GRANADA................GRA00900    
000014B-000014-CASTELLON..............CAS00700    
000015A-000015-ZARAGOZA...............ZAR00600    
000017A-000017-VALENCIA...............VAL00400    
000018A-000018-BARCELONA..............BAR00300    
000019B-000019-CIUDAD REAL............CRE00200    
000020A-000020-MADRID.................MAD00100    
**************************** Bottom of Data *********

A continuación, el segundo paso del JCL usa como entrada los dos ficheros que se acaban de generar (POBL.T1 y POBL.T2). La salida la constituyen el fichero con los registros modificados SIST.JJ0107S1.X0060X.DDD.POBL.MD y el fichero con el resto de registros que no ha sufrido ningún cambio por parte de la utilidad ICETOOL SIST.JJ0107S2.X0060X.DDD.POBL.RS.

En el dataset POBL.MD encontraremos los registros cuya clave de población antigua ha sido sustituida por la nueva (según la relación establecida en el fichero KEYS): 100002, 100004, 100005, etc…

----+----1----+----2----+----3----+----4    
***************************** Top of Data *****
B-100002-ALMERIA................ALM01300    
B-100004-SANTANDER..............SAN01500    
B-100005-TARRAGONA..............TAR01600    
B-100006-BADAJOZ................BAD01700    
B-100007-SALAMANCA..............SAL01800    
B-100008-BURGOS.................BUR01900    
B-100010-SEGOVIA................SEG01100    
**************************** Bottom of Data ***

Del mismo modo, en el fichero POBL.RS se almacenan los registros que no han sufrido ninguna modificación. Y, por tanto, continúan estando identificados por la clave de población antigua: 000011, 000012, 000014, etc…

----+----1----+----2----+----3----+----4    
***************************** Top of Data *****
B-000011-TOLEDO.................TOL01000    
B-000012-GRANADA................GRA00900    
B-000014-CASTELLON..............CAS00700    
A-000015-ZARAGOZA...............ZAR00600    
A-000017-VALENCIA...............VAL00400    
A-000018-BARCELONA..............BAR00300    
B-000019-CIUDAD REAL............CRE00200    
A-000020-MADRID.................MAD00100    
**************************** Bottom of Data ***



Finalmente, si unimos en un fichero resultante los registros de los datasets POBL.MD y POBL.RS, dispondremos del nuevo maestro de poblaciones en el que ya se han realizado los cambios de código de población requeridos.

----+----1----+----2----+----3----+----4    
***************************** Top of Data *****
B-000011-TOLEDO.................TOL01000    
B-000012-GRANADA................GRA00900    
B-000014-CASTELLON..............CAS00700    
A-000015-ZARAGOZA...............ZAR00600    
A-000017-VALENCIA...............VAL00400    
A-000018-BARCELONA..............BAR00300    
B-000019-CIUDAD REAL............CRE00200    
A-000020-MADRID.................MAD00100    
B-100002-ALMERIA................ALM01300    
B-100004-SANTANDER..............SAN01500    
B-100005-TARRAGONA..............TAR01600    
B-100006-BADAJOZ................BAD01700    
B-100007-SALAMANCA..............SAL01800    
B-100008-BURGOS.................BUR01900    
B-100010-SEGOVIA................SEG01100    
**************************** Bottom of Data ***

Como vemos, en el fichero anterior se pueden apreciar tanto códigos antiguos de población (000011-TOLEDO, 000012-GRANADA, 000014-CASTELLON, etc…) como códigos nuevos de población (100002-ALMERIA, 100004-SANTANDER, 100005-TARRAGONA, etc…). En un cliente real, a partir de ahora este sería el nuevo fichero maestro de Poblaciones. 

Conclusiones del cruce de ficheros mediante SPLICE

La verdad es que, si no la hemos realizado nunca con anterioridad, la ejecución de un cruce de ficheros mediante SPLICE nos puede parecer algo compleja. Tengo que reconocer que, al menos a mí, así me lo pareció la primera ocasión en la que tuve que enfrentarme con esta operación.

Sin embargo, os aseguro que, una vez que hayáis practicado con algunos ejemplos, os daréis cuenta de que el empleo del SPLICE del ICETOOL nos puede ahorrar muchos pasos (y mucho trabajo) a la hora de elaborar un JCL. Pensad: ¿cuánto nos habría costado implementar el ejemplo (sencillo) del artículo sin usar el SPLICE?

Siempre es complicado empezar a pelearse con una nueva utilidad Host. Pero eso no significa que lo más óptimo sea seguir trabajando con nuestros antiguos operadores de toda la vida. Aunque nos pueda parecer tedioso a corto plazo, el empleo de las utilidades más potentes nos ahorrará mucho tiempo de codificación a largo plazo. No lo olvidéis la próxima vez que os tengáis que enfrentar con un SPLICE.



En este artículo hemos tratado de ver cómo se puede realizar un cruce de ficheros mediante el operador SPLICE. Ciertamente, existen otros muchos comandos relacionados con la utilidad ICETOOL, pero este es uno de los más utilizados. De todas formas, en el Blog iremos viendo poco a poco cómo se deben implementar las operativas JCL con aquellos operadores que considero como los más importantes.

Pues nada, espero que lo comentado aquí os sirva para tener un poco más claro cuáles son los pasos a seguir a la hora de elaborar un SPLICE. Si lo he conseguido, con eso ya me puedo dar por satisfecho…

Saludos.

ICETOOL: Como cruzar Ficheros con SPLICE (1)

Una de las funcionalidades más apreciadas de ICETOOL es la que nos permite cruzar varios ficheros y realizar comparaciones entre los registros contenidos en ellos. Estas acciones se realizan mediante el comando SPLICE, que puede ser considerado como uno de los operadores más útiles de la herramienta.

Cruzar ficheros mediante SPLICE de ICETOOL

En muchas ocasiones nos podemos encontrar con la necesidad de comparar los registros de dos ficheros distintos con el objetivo de determinar si son iguales en función de una clave determinada o no. Esto, que en principio parece una operativa compleja, puede ser realizado de forma bastante ágil mediante el operador SPLICE de la utilidad ICETOOL.

Tal y como se especifica en la documentación de la herramienta, la función SPLICE sirve para realizar un cruce de ficheros, comparar los registros contenidos en ellos, extraer la información seleccionada y enviarla a un fichero de salida.



Una vez comentado de forma teórica, lo mejor es que veamos cómo funciona el proceso de cruce de ficheros mediante un ejemplo. Para ello, vamos a partir de dos ficheros de diferente longitud de registro. En ambos datasets se va a encontrar la misma clave Población, así que vamos a ejecutar la comparación mediante este campo.

Comparar registros de ficheros mediante SPLICE

En nuestro ejemplo, vamos a usar como entrada un fichero de claves (KEYS) y un fichero maestro (MASTER). En el KEYS tendremos la relación entre los códigos de Población actuales (antiguos) y los códigos de Población nuevos. En el MASTER tendremos los registros de Población con toda su información asociada (uno de esos campos será la clave Población, que figurará inicialmente con el código actual).

En este caso, nos piden que sustituyamos en el MASTER los códigos actuales de las Poblaciones por los códigos nuevos (recordemos que la relación entre ambos figura en el fichero KEYS). Aquí es donde va a entrar en escena el empleo del SPLICE de la utilidad ICETOOL.
El contenido del fichero de relaciones entre claves, denominado SIST.UNLOAD.X0005X.POBL.KEYS, es el siguiente (en primer lugar figura la clave actual y, a continuación, la clave nueva sustituta):

----+----1---
*************
000010-100010
000002-100002
000004-100004
000005-100005
000006-100006
000007-100007
000008-100008
*************



Por otra parte, los registros que tenemos cargados en el fichero de Poblaciones, denominado SIST.UNLOAD.X0005X.POBL.MASTER, son los siguientes:

----+----1----+----2----+----3----+----4
***************************** Top of Data *****
A-000020-MADRID.................MAD00100    
B-000019-CIUDAD REAL............CRE00200    
A-000018-BARCELONA..............BAR00300    
A-000017-VALENCIA...............VAL00400    
A-000015-ZARAGOZA...............ZAR00600    
B-000014-CASTELLON..............CAS00700    
B-000012-GRANADA................GRA00900    
B-000011-TOLEDO.................TOL01000    
B-000010-SEGOVIA................SEG01100    
B-000002-ALMERIA................ALM01300    
B-000004-SANTANDER..............SAN01500    
B-000005-TARRAGONA..............TAR01600    
B-000006-BADAJOZ................BAD01700    
B-000007-SALAMANCA..............SAL01800    
B-000008-BURGOS.................BUR01900    
**************************** Bottom of Data ***

La idea es que, tras lanzar nuestro proceso de conversión, la población Madrid del MASTER, por ejemplo, ya no esté asociada al código antiguo 000020 sino al código nuevo 100020. El resto de campos de los registros del fichero maestro tienen que quedar exactamente igual que ahora.

A continuación, mostramos el código necesario para realizar el cambio comentado.

//*            *******************************************
//*            * PASO ICETOOL PARA REFORMATEAR ENTRADAS      //*            *                                          //*            *******************************************
//JJ0105   EXEC PGM=ICETOOL                                          //TOOLMSG  DD  SYSOUT=*                                             
//DFSMSG   DD  SYSOUT=*                                             
//* KEYS  : FICHERO DE RELACIONES ENTRE CLAVES                   
//KEYS     DD  DSN= SIST.UNLOAD.X0005X.POBL.KEYS,    
//             DISP=SHR                                             
//* MASTER: FICHEROS DE POBLACIONES
//MASTER   DD  DSN= SIST.UNLOAD.X0005X.POBL.MASTER,
//             DISP=SHR                                              //* TEMP1 : FICHERO KEYS FORMATEADO Y ORDENADO PARA CRUCE
//TEMP1    DD  DSN=SIST.JJ0105T1.X0060X.DDD.POBL.T1,
//             DISP=(NEW,CATLG,DELETE),                              //             SPACE=(CYL,(00100,00100),RLSE),                     
//             UNIT=DISCO                                          
//* TEMP2 : F. POBLACIONES FORMATEADO Y ORDENADO PARA CRUCE
//TEMP2    DD  DSN=SIST.JJ0105T2. X0060X.DDD.POBL.T2,
//             DISP=(NEW,CATLG,DELETE),                              //             SPACE=(CYL,(00100,00100),RLSE),                     
//             UNIT=DISCO                                          
//TOOLIN   DD  DSN=SIST.SYSIN(JJRS1A03),                      
//             DISP=SHR                                            
//CTL1CNTL DD  DSN=SIST.SYSIN(JJRS1A04),                     
//             DISP=SHR                                            
//CTL2CNTL DD  DSN=SIST.SYSIN(JJRS1A05),                     
//             DISP=SHR                                            
//JJ0105A  EXEC PGM=ABEN3333,                                      
//             COND=(4,GE,JJ0105)                                  
//CTRNORST DD  DUMMY                                               
//*                                                                
//*            *******************************************
//*            * PASO ICETOOL PARA GENERAR SALIDAS
//*            *                                            
//*            *******************************************
//JJ0107   EXEC PGM=ICETOOL                                         
//TOOLMSG  DD  SYSOUT=*                                             
//DFSMSG   DD  SYSOUT=*                                             
//* CONCAT: FICHERO UNIFICADO PARA REALIZAR EL ICETOOL       
//CONCAT   DD  DSN=SIST.JJ0105T1.X0060X.DDD.POBL.T1,
//             DISP=SHR                                              //         DD  DSN=SIST.JJ0105T2.X0060X.DDD.POBL.T2,
//             DISP=SHR                                             
//* OUT   : FICHERO DE SALIDA CON LOS REGISTROS MODIFICADOS         
//OUT      DD  DSN=SIST.JJ0107S1.X0060X.DDD.POBL.MD,
//             DISP=(NEW,CATLG,DELETE),                              //             SPACE=(CYL,(00100,00100),RLSE),                      
//             UNIT=DISCO                                           
//* OUT1  : F. DE SALIDA CON LOS REGISTROS NO MODIFICADOS      
//OUT1     DD  DSN=SIST.JJ0107S2.X0060X.DDD.POBL.RS,
//             DISP=(NEW,CATLG,DELETE),                              //             SPACE=(CYL,(00100,00100),RLSE),                    
//             UNIT=DISCO                                         
//TOOLIN   DD  DSN=SIST.SYSIN(JJRS1A06),                    
//             DISP=SHR                                           
//CTL3CNTL DD  DSN=SIST.SYSIN(JJRS1A07),
//             DISP=SHR                                           
//CTL4CNTL DD  DSN=SIST.SYSIN(JJRS1A08),                    
//             DISP=SHR                                           
//JJ0107A  EXEC PGM=ABEN3333,                                      
//             COND=(4,GE,JJ0107)                                 
//CTRNORST DD  DUMMY                                              
//*
   
Y las fichas asociadas al código anterior son las siguientes:

*--------------------------------------------------------*
* <<< FICHA JJRS1A03 >>>
* COPIA KEYS A FICHERO TEMP1 PARA PERMITIR SPLICE
* COPIA MASTER A TEMP Y AÑADE LOS REGISTROS A COMBINAR
*--------------------------------------------------------*
  COPY FROM(KEYS) TO(TEMP1) USING(CTL1)          
  COPY FROM(MASTER) TO(TEMP2) USING(CTL2)

*--------------------------------------------------------*
* <<< FICHA JJRS1A04 >>>  
* REFORMATEAMOS EL KEYS - LA CLAVE ES LA POBLACION
*--------------------------------------------------------*
  SORT FIELDS=(1,6,CH,A)                                  
  OUTREC FIELDS=(1,13,33X,47:C'D',8,6)

*--------------------------------------------------------*
* <<< FICHA JJRS1A05 >>>
* REFORMATEAMOS EL MASTER - LA CLAVE ES LA POBLACION
*--------------------------------------------------------*
  INREC FIELDS=(3,6,1,40)     
  SORT FIELDS=(1,6,CH,A)      
  OUTREC FIELDS=(1,46,47:C' ',6X)

*--------------------------------------------------------*
* <<< FICHA JJRS1A06 >>>
* OUT: REGISTROS QUE COINCIDEN                           *
* INCLUIMOS TODO DEL MASTER MAS POBLACION NUEVA DE KEY   *
* MAS UN INDICADOR NUEVO DE MODIFICADO
* OUT1: RESTO DE REGISTROS QUE NO COINCIDEN              *
*--------------------------------------------------------*
  SPLICE FROM(CONCAT) TO(OUT) ON(1,6,CH) WITHALL  -
  WITH(7,40) USING(CTL3)                         
  SPLICE FROM(CONCAT) TO(OUT1) ON(1,6,CH) WITHALL  -
  WITH(7,40) USING(CTL4) KEEPNODUPS KEEPBASE     

*--------------------------------------------------------*
* <<< FICHA JJRS1A07 >>>
* SUSTITUIMOS POBL ENCONTRADOS POR POBL NUEVAS
* SE INCLUYE INDICADOR DE MODIFICADO
*--------------------------------------------------------*
  OUTFIL FNAMES=OUT,
  INCLUDE=(47,1,CH,EQ,C'D'),
  OUTREC=(7,2,48,6,15,32)                  

*--------------------------------------------------------*
* <<< FICHA JJRS1A08 >>>
* SACAMOS REGISTROS NO ENCONTRADOS PARA CUADRAR ENTRADA
*--------------------------------------------------------*
  OUTFIL FNAMES=OUT1,
  INCLUDE=(47,1,CH,EQ,C' '),
  OUTREC=(7,40)                              

Como vemos, el código anterior se compone de dos pasos JCL, que son los que vamos a necesitar para, en primer lugar, reformatear e igualar la longitud de los dos ficheros de entrada y, posteriormente, generar un fichero de salida con los registros modificados y otro con los registros no modificados.

Detalle de las fichas requeridas para realizar un SPLICE

A continuación, una vez mostrado el código anterior, vamos a ir revisando con un poco de detalle en qué consisten cada una de las fichas que hemos tenido que crear en los dos pasos del JCL. Como veremos, muchas de ellas son bastante genéricas.

PASO 1: PASO ICETOOL PARA REFORMATEAR ENTRADAS

1º) Invocación a ICETOOL: El primer paso es, como siempre, la invocación a la herramienta ICETOOL mediante el comando EXEC PGM.

//JJ0105   EXEC PGM=ICETOOL                                           

2º) Especificación de los ficheros de entrada: A continuación, indicamos los nombres de los dos ficheros de entrada que vamos a emplear en el ICETOOL. Se trata del fichero de relaciones entre claves (SIST.UNLOAD.X0005X.POBL.KEYS) a emplear y del fichero maestro con los datos de poblaciones (SIST.UNLOAD.X0005X.POBL.MASTER).

//* KEYS  : FICHERO DE RELACIONES ENTRE CLAVES                    
//KEYS     DD  DSN= SIST.UNLOAD.X0005X.POBL.KEYS,    
//             DISP=SHR
//* MASTER: FICHEROS DE POBLACIONES
//MASTER   DD  DSN= SIST.UNLOAD.X0005X.POBL.MASTER,
//             DISP=SHR

3º) Especificación de los ficheros de salida: Del mismo modo, también indicamos los nombres de los ficheros que van a contener la información reformateada de KEYS y MASTER. Estos datsets intermedios se denominarán SIST.JJ0105T1.X0060X.DDD.POBL.T1 y SIST.JJ0105T2.X0060X.DDD.POBL.T2.

//* TEMP1 : FICHERO KEYS FORMATEADO Y ORDENADO PARA CRUCE
//TEMP1    DD  DSN=SIST.JJ0105T1.X0060X.DDD.POBL.T1,
//             DISP=(NEW,CATLG,DELETE),               
//             SPACE=(CYL,(00100,00100),RLSE), 
//             UNIT=DISCO  
//* TEMP2 : F. POBLACIONES FORMATEADO Y ORDENADO PARA CRUCE
//TEMP2    DD  DSN=SIST.JJ0105T2. X0060X.DDD.POBL.T2,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(00100,00100),RLSE),
//             UNIT=DISCO

4º) Ficha TOOLIN: Aquí es donde vamos a indicarle a ICETOOL que tiene que proceder a ejecutar el operador COPY en dos ocasiones. La primera de ellas para pasar de KEYS a TEMP1 y la segunda para pasar de MASTER a TEMP2.

*--------------------------------------------------------*
* <<< FICHA JJRS1A03 >>>                                
* COPIA KEYS A FICHERO TEMP1 PARA PERMITIR SPLICE
* COPIA MASTER A TEMP2 Y AÑADE LOS REGISTROS A COMBINAR
*--------------------------------------------------------*
  COPY FROM(KEYS) TO(TEMP1) USING(CTL1)
  COPY FROM(MASTER) TO(TEMP2) USING(CTL2)

                                     

5º) Fichas de Control: Aquí es donde tenemos que indicar al SPLICE la forma en la que queremos que se ejecuten los operadores COPYS del TOOLIN anterior. En nuestro ejemplo, aquí están incluidas las fichas CTL1 y CTL2.

*--------------------------------------------------------*
* <<< FICHA JJRS1A04 >>>                            
* REFORMATEAMOS EL KEYS - LA CLAVE ES LA POBLACION
*--------------------------------------------------------*
  SORT FIELDS=(1,6,CH,A)                                  
  OUTREC FIELDS=(1,13,33X,47:C'D',8,6)

La primera ficha de control (CTL1CNTL) hace referencia al COPY de KEYS a TEMP1. Como podemos ver en la codificación de la ficha anterior, en ella se realizan dos cosas con los datos de entrada.

-          Lo primero que hace es ordenar el fichero KEYS en función del campo de longitud 6 situado en la posición 1 (se trata del campo código de Población).

-          A continuación, transfiere del KEYS al TEMP1 la siguiente información de los registros: el campo de longitud 13 que empieza en la posición 1 (1,13), 33 espacios en blanco (33X), un carácter ‘D’ en la posición 47 (47:C’D’) y el campo de longitud 6 que empieza en la posición 8 (8,6).

*--------------------------------------------------------*
* <<< FICHA JJRS1A05 >>>
* REFORMATEAMOS EL MASTER - LA CLAVE ES LA POBLACION
*--------------------------------------------------------*
  INREC FIELDS=(3,6,1,40)     
  SORT FIELDS=(1,6,CH,A)      
  OUTREC FIELDS=(1,46,47:C' ',6X)



La segunda ficha de control (CTL2CNTL) hace referencia al COPY de MASTER a TEMP2. Del mismo modo que en la anterior, en esta segunda ficha vemos que también se realizan varias acciones con los datos de entrada.

-          INREC: En primer lugar, a los registros de entrada le insertamos por delante el campo de longitud 6 que está en la posición 3 (3,6), que es la Población. A continuación, se incluyen las 40 posiciones de los registros sin realizar ningún cambio sobre ellas (1,40).

-          SORT: Se ordena el fichero en función del campo de longitud 6 situado en la posición 1 (se trata del campo código de Población que acabamos de insertar en la sentencia anterior).

-          OUTREC: Se transfiere del MASTER al TEMP2 la siguiente información de los registros: el campo de longitud 46 situado en la posición 1 (1,46), un carácter en blanco (47:C’ ‘) y 6 espacios en blanco (6X).

El próximo día, en un nuevo post, terminaremos de ver las fichas necesarias para implementar un SPLICE en un JCL. La idea será examinar en detalle para qué sirve cada una de las sentencias incluidas en el paso 2. De ese modo, completaremos la visión global del proceso y, a partir de ese momento, ya no deberíais tener problemas a la hora de codificar vuestro propio job.

Pues nada, eso es todo por hoy. Como ya sabéis, quedáis invitados a la segunda parte del artículo. De todas formas, si no podéis esperar hasta entonces, aquí abajo podéis ir dejándome las dudas que os surjan en relación con este tema.

Saludos.