Desarrollando en Cobol y Natural sobre Plataforma Mainframe

lunes, 13 de junio de 2016

Ver campos Hexadecimales en QMF con HEX (y 2)

Hace algunas semanas comenzamos a revisar los pasos que hay que seguir para ver campos hexadecimales en QMF mediante la cláusula HEX. Aunque en su momento ya estuvimos viendo cómo hacer esto mismo con la ventana FORM, nunca viene mal tener formas alternativas de hacer esta decodificación. Recordad que, si no realizamos ningún tratamiento sobre los datos, el informe de QMF nos mostrará los campos hexadecimales en un formato no legible

En la primera parte del post ya estuvimos viendo los primeros puntos del procedimiento (acceder al post Ver campos Hexadecimales en QMF con HEX - 1). Hoy nos centraremos en finalizar el examen de los pasos a seguir, de manera que completemos la visión global de este método de decodificación. Si nos dedicamos al análisis de incidencias, esta alternativa nos resultará muy útil. Vamos con ello.

4º) Una vez codificada la query anterior, la ejecutamos desde QMF. De esta forma obtendremos el informe de la tabla DB2 con el listado de registros extraidos.







Como vemos en la imagen, ahora el informe ya no muestra datos hexadecimales. Por un lado, la cláusula HEX ha hecho que se nos presente la información en formato alfanumérico. Por otro lado, los comandos SUBSTR que hemos incluido nos han permitido dividir el campo hexadecimal en cada uno de los subelementos con significación propia.

                                           SITU    LOCA
ORCI         VERSIO  TJALON  SITU    LOCA   1       1 
-----------  ------  ------  ------  ----  ------  ----
00662341105  000     C2      990003  290   900001  002
01458141303  000     C2      990003  839   900001  002
02180781101  002     C2      990003  290   900001  002
03038681303  000     C2      990003  290   900001  002
03422721304  000     E3      990002  031   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03723801304  000     D2      990003  788   900001  002


Si nos centramos en un único registro, podremos apreciar con mayor claridad lo cómoda que resulta ahora la lectura de la información del antiguo campo hexadecimal. Parece que ha merecido la pena dedicar algo de tiempo a la codificación.

                                           SITU    LOCA
ORCI         VERSIO  TJALON  SITU    LOCA   1       1 
-----------  ------  ------  ------  ----  ------  ----
03560631304  000     C2      990003  290   900001  002


Fijaos que estos son los mismos datos que vimos en la alternativa anterior de decodificación. La única diferencia es que de este modo  son más fáciles de leer.

03560631304  000     C2      990003  290   900001  002

Creo que ahora ya entenderéis por qué os digo que, de esta forma, os va a resultar mucho más fácil analizar los registros DB2. Si os dedicáis al análisis de incidencias, como es el caso de muchos programadores Cobol, a largo plazo esto supondrá un gran ahorro de tiempo. Y si ahora no os dedicáis a ello, bueno, guardáos este post por ahí, porque en el mundo Host tarde o temprano tendréis que resolver incidencias...



¿Cuál de las dos alternativas es mejor?


Una vez vistas estas dos formas de traducir campos hexadecimales en QMF, nos podríamos hacer la pregunta: ¿cuál de las dos alternativas es mejor? Realmente no podemos decir que uno de los procedimentos sea mejor que el otro, cada uno tiene su aplicación específica. Va a ser cuestión nuestra decidir cuál de los dos métodos es el adecuado para la situación con la que nos estemos enfrentando.

-------------------------------------------------------------------------------------------------------------------------------
Tip: Aquí podéis ver diversas herramientas clave del entorno Host
-------------------------------------------------------------------------------------------------------------------------------

Por ejemplo, si únicamente queremos hacer una consulta rápida de un dato y no vamos a acceder a esta tabla DB2 nunca más, entonces la alternativa 1 será la mejor. Para un escenario de este tipo no tiene sentido invertir demasiado tiempo en la traducción del campo hexadecimal. Aquí va a primar la rapidez frente a la comodidad, ya que no se va a tratar de una extracción periódica.

En cambio, si lo que nos están pidiendo es algo que vamos a tener que consultar una vez cada semana (o cada mes), entonces yo me plantearía acometer la alternativa 2. En este caso sí que va a merecer la pena invertir un poco más de trabajo en desarrollar la query para mostrar los subcampos hexadecimales de la forma más legible posible. Posteriormente, eso nos supondrá un gran ahorro de tiempo a la hora de revisar los datos extraídos de forma periódica.


En cualquier caso, la idea del post es que dispongáis de un par de opciones para traducir los campos hexadecimales con los que os vayáis encontrando en vuestro día a día. En realidad, seleccionar una alternativa u otra es un problema secundario una vez que ya somos conscientes de que la información hexadecimal no es un obstáculo insalvable para nosotros. En última instancia, elegid la solución que os resulte más óptima en vuestra instalación.

Pues nada, eso es todo por lo que respecta a la visualización de campos hexadecimales en QMF. Espero que lo comentado en el texto os ayude a superar este tipo de problemas de formato. Cualquier duda que tengáis, ya sabéis, me la dejáis aquí abajo en los comentarios...

Saludos.

lunes, 6 de junio de 2016

Ver campos Hexadecimales en QMF con HEX (1)

Hace algunas semanas estuvimos viendo la forma de decodificar campos hexadecimales mediante la clásusula X de la ventana FORM de QMF. Como ya os podéis imaginar, se trata de un método para salir del paso, así que hoy examinaremos otra forma de visualizar datos hexadecimales de forma más amigable. Os adelanto que tiene que ver con la implementación de queries mediante los comandos HEX y SUBSTR.

En su momento ya estuvimos viendo un método rápido para decodificar información hexadecimal (ver post Ver campos Hexadecimales en QMF con FORM - y 2). Dicho método es muy útil para cuando tenemos que hacer una consulta puntual y no disponemos de mucho tiempo. Sin embargo, la alternativa que vamos a revisar hoy estaría más orientada a escenarios de consulta que se nos plantean periódicamente. El uso de HEX nos va a requerir algo más de trabajo de codificación, pero luego nos servirá para ahorrar tiempo a la hora de leer la información.

Visualizar Hexadecimales mediante SELECT con HEX


Otra de las alternativas para visualizar campos hexadecimales en QMF es usar una query SELECT con la cláusula HEX. Esta solución es algo más compleja de implementar que la anterior (X en ventana FORM). Pero, a cambio, los resultados mostrados serán mucho más cómodos de leer, lo que nos permitirá analizar el contenido con mucha mayor rapidez.

A continuación, vamos a ver los pasos que habría que seguir para poner en práctica esta alternativa de traducción de datos. Recordemos que la query de partida era la siguiente.

SELECT INCI_CO_ORIGEN, INCI_IN_ORIGEN,INCI_TS_TIMEST
FROM A0DB22.A0INCIT0
WHERE  SUBSTR(HEX(INCI_CO_ORIGEN),34,6) IN
             ('900001','900002','900003',
              '900005','900006','900007','900008')

Los pasos 1º) y 2º) serían los mismos que en el método anterior, ya que lo único que hacíamos en ellos era mostrar cómo era la extracción inicial de datos sin decodificar. Continuamos, pues, con los siguientes puntos.

3º) Teniendo en cuenta que, en nuestro ejemplo, el dato Hexadecimal es el denominado INCI_CO_ORIGEN, lo que vamos a hacer es aplicar la cláusula HEX a este campo del registro. Esto se conseguiría fácilmente especificando esta declaración SELECT.

SELECT HEX(INCI_CO_ORIGEN)

Adicionalmente, en nuestro caso el campo INCI_CO_ORIGEN en realidad está compuesto por varios subcampos. Por ello, vamos a usar el comando SUBSTR para establecer un nombre específico para cada uno de dichos subelementos. De esta forma, conseguiremos que el informe extraído tenga un formato mucho más legible.

SELECT SUBSTR(HEX(INCI_CO_ORIGEN),1,11) AS ORCI,
       SUBSTR(HEX(INCI_CO_ORIGEN),13,3) AS VERSIO,
       SUBSTR(HEX(INCI_CO_ORIGEN),17,2) AS TJALON,
       SUBSTR(HEX(INCI_CO_ORIGEN),22,6) AS SITU,
       SUBSTR(HEX(INCI_CO_ORIGEN),29,3) AS LOCA,
       SUBSTR(HEX(INCI_CO_ORIGEN),34,6) AS SITU_1,
       SUBSTR(HEX(INCI_CO_ORIGEN),41,3) AS LOCA_1

Una vez explicado lo anterior, ya podemos codificar la query entera. Lo que haríamos es tomar el código inicial y aplicarle las cláusulas indicadas HEX y SUBSTR.
 


Como vemos en la imagen anterior, la query SQL se corresponde con la original, pero ahora hemos incorporado el traductor hexadecimal HEX y el comando SUBSTR. Con estos cambios ya conseguiríamos el objetivo inicialmente buscado de decodificar los campos hexadecimales.

SELECT SUBSTR(HEX(INCI_CO_ORIGEN),1,11) AS ORCI,
       SUBSTR(HEX(INCI_CO_ORIGEN),13,3) AS VERSIO,
       SUBSTR(HEX(INCI_CO_ORIGEN),17,2) AS TJALON,
       SUBSTR(HEX(INCI_CO_ORIGEN),22,6) AS SITU,
       SUBSTR(HEX(INCI_CO_ORIGEN),29,3) AS LOCA,
       SUBSTR(HEX(INCI_CO_ORIGEN),34,6) AS SITU_1,
       SUBSTR(HEX(INCI_CO_ORIGEN),41,3) AS LOCA_1,
       INCI_IN_ORIGEN, INCI_TS_TIMEST
FROM A0DB22.A0INCIT0
WHERE  SUBSTR(HEX(INCI_CO_ORIGEN),34,6) IN
                     ('900001','900002','900003','900005',
                      '900006','900007','900008')

Es cierto que ahora la query queda un poco más compleja que el SQL de partida, pero es el precio que hay que pagar por obtener un informe más cómodo de leer. La codificación requiere un poco más de dedicación por nuestra parte, pero luego ganaremos mucho tiempo a la hora de realizar el análisis de los datos obtenidos. Si tenéis que descubrir la causa de una incidencia, creo que agradeceréis hacer las cosas siguiendo este procedimiento.

-------------------------------------------------------------------------------------------------------------------------------
Tip: Aquí podéis ver cómo se pueden almacenar queries en QMF
-------------------------------------------------------------------------------------------------------------------------------

El próximo día, en un nuevo post, continuaremos viendo los pasos que hay que seguir para visualizar los campos hexadecimales en QMF mediante la cláusula HEX. Mientras tanto, si tenéis mucha necesidad de decodificar información que se encuentre en dicho formato, podéis recurrir al artículo que escribimos en su día hablando de la ventana FORM. En cualqueir caso, recordad que siempre es conveniente disponer de varias alternativas para poder ejecutar una misma acción.

Pues nada, eso es todo por ahora. Como ya sabéis, quedáis invitados a la segunda parte del post, así que espero veros por aquí dentro de unas semanas. Disfrutad del Cobol mientras tanto...

Saludos.

lunes, 30 de mayo de 2016

Ver campos Hexadecimales en QMF con FORM (y 2)

Hace algunas semanas comenzamos a ver los pasos que había que seguir para visualizar campos hexadecimales en QMF con FORM. Aunque existen otras técnicas para decodificar este tipo de formatos, la verdad es que el uso del comando X de FORM es una de las más rápidas. Afortunadamente, también es una de las más fáciles de poner en práctica.

En la primera parte del post estuvimos viendo los primeros pasos de esta técnica (ver post Ver campos Hexadecimales en QMF con FORM - 1). Hoy simplemente nos centraremos en terminar de examinar los puntos requeridos para implementar la visualización mediante X de FORM. Como veremos, se trata de un procedimiento que no nos debe dar ningún problema una vez aprendido.

Visualizar Hexadecimales con X en FORM


Llegados a este punto, una de las alternativas de que disponemos para visualizar los campos hexadecimales en QMF es el uso de la etiqueta X de FORM. Se trata de una funcionalidad sencilla de ejecutar y que siempre tendremos disponible en la herramienta QMF. Nos permitirá traducir los campos encriptados a alfanuméricos, que pasarán a estar en un formato inteligible aunque, como veremos, no del todo cómodo de leer.

3º) Desde la pantalla de REPORT que nos muestra el informe extraído por la sentencia SQL, pulsamos la tecla PF9 para ir a la ventana FORM.




4º) A continuación, nos situamos en la columna EDIT y en la fila correspondiente al campo hexadecimal que queremos decodificar. Introducimos una X en esa ubicación y pulsamos PF12 para obtener de nuevo el informe optimizado.






En la imagen anterior podemos ver cómo se mostraría el informe tras realizar la acción anterior. Los registros ya han dejado de mostrar caracteres extraños y ahora nos aparecen en formato alfanumérico. Tal y como he dicho más arriba, la información no es cómoda de visualizar pero, eso sí, al menos son datos legibles. Aquí ya tendríamos un punto de partida para analizar el problema que tengamos en nuestra aplicación.

 INCI                                         
  CO                                          
ORIGEN                                        
-----------------------------------------------
00662341105C000CC2C50990003C290C0900001C002C002
01422001600C000CE3C80990002C031C0900001C002C003
01458141303C000CC2F20990003C839C0900001C002C001
02180781101C002CC2C50990003C290C0900001C002C002
03038681303C000CC2C50990003C290C0900001C002C001
03422721304C000CE3C80990002C031C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001
03560631304C000CC2C50990003C290C0900001C002C001


Si tomamos, por ejemplo, el último registro, veremos que ahí ya se podría hacer una lectura de la información contenida en el campo hexadecimal de la tabla DB2.

 INCI                                         
  CO                                          
ORIGEN                                        
-----------------------------------------------

03560631304C000CC2C50990003C290C0900001C002C001

Cada subcampo del registro estaría separado de los demás mediante el carácter "C". Sabiendo esto, ya podríamos identificar cada uno de los datos informativos.

03560631304C000CC2C50990003C290C0900001C002C001

En la línea anterior hemos coloreado cada uno de los subcampos que existen en el registro que estamos usando de ejemplo. Ya tenemos la información disponible. Queda claro que no es la forma más rápida de trabajar pero, al menos, tenemos un camino por el que seguir avanzando (cosa que no ocurría al principio, cuando sólo teníamos registros con caracteres extraños).

Una vez que hemos visto la forma de visualizar campos hexadecimales con FORM, el próximo día os mostraré una forma alternativa de hacerlo, mediante la cláusula HEX. Pero bueno, con lo que hemos examinado hoy al menos ya tenéis un método para decodificar este tipo de campos y mostrarlos con un formato más amigable. Lo importante es que dispongamos de algo que nos permita seguir avanzando en el análisis de nuestra base de datos DB2.

Pues nada, eso es todo por lo que respecta a la utilización de la cláusula X en FORM. Espero que su empleo haya quedado lo suficientemente claro en el post. Si no es así, dejadme las dudas que tengáis aquí abajo...

Saludos.

lunes, 23 de mayo de 2016

Ver campos Hexadecimales en QMF con FORM (1)

Hay ocasiones en las que estamos ejecutando una query SQL y nos damos cuenta de que la extracción nos recupera campos en formato hexadecimal. Obviamente, se trata de información que no podemos interpretar a primera vista. ¿Qué podríamos hacer para mostrar estos campos en un formato más amigable? En este post vamos a tratar de contaros una forma de resolver este problema.

Campos Hexadecimales en QMF


Cuando empecé en esto del mundo Cobol, recuerdo que las primeras veces que me encontré con extracciones de campos hexadecimales me llamó mucho la atención el formato con el que se visualizaban en la herramienta QMF. Se mostraban una serie de símbolos extraños que eran imposibles de interpretar y, por tanto, era muy complicado ponerse a analizar la información de los registros extraídos. Si en vuestra Base de Datos no hay campos hexadecimales, entonces no entenderéis de qué os estoy hablando...

En la siguiente imagen podéis ver a qué me refiero. Si nos vamos al QMF y extraemos la información de un campo encriptado, veremos que los registros nos muestran caracteres especiales. Si eres un programador novato, entonces probablemente no sabrás qué hacer para solucionar esta situación. Y si, por ejemplo, estás analizando una incidencia, entonces va a ser complicado llegar a alguna conclusión.





Afortunadamente, en QMF existe una forma muy sencilla de transformar estos campos hexadecimales en un formato interpretable. Con ello conseguiremos que la información se muestre en caracteres alfanuméricos, cosa que nos permitirá avanzar en nuestro trabajo. O, al menos, nos servirá para decodificar el contenido de los registros que estamos leyendo.

¿Cómo visualizar campos Hexadecimales en QMF?


Dicho lo anterior, vamos a ver rápidamente qué es lo que tendríamos que hacer para pasar de una extracción de campos hexadecimales a unos registros en formato alfanumérico normal. Como veremos, se trata de una acción muy sencilla. Pero, a pesar de su simplicidad, se trata de una actividad que nos permitirá evitar problemas innecesarios. Los pasos a seguir son los siguientes.

1º) Una vez que estamos en la herramienta QMF, procedemos a codificar la query. Recordemos que se tratará de un SQL que accederá a una tabla que posea campos en formato hexadecimal.




En el ejemplo anterior se puede observar que la query implementada es la siguiente. He escogido una sentencia sencilla para que podamos centrarnos en el objetivo del post.

SELECT INCI_CO_ORIGEN, INCI_IN_ORIGEN,INCI_TS_TIMEST
FROM A0DB22.A0INCIT0
WHERE  SUBSTR(HEX(INCI_CO_ORIGEN),34,6) IN
             ('900001','900002','900003',
              '900005','900006','900007','900008')

2º) Lanzamos la ejecución de la query codificada anteriormente. QMF nos mostrará la salida de la extracción realizada sobre la tabla DB2.





Aquí se puede observar el problema del que hemos estado hablando más arriba. La sentencia SQL nos ha extraído registros cuyo primer campo se encuentra en formato encriptado. Tal y como se muestra en estos momentos, la información devuelta es inútil, ya que no seremos capaces de interpretar el contenido de ninguna línea. Esto es lo que tenemos que conseguir decodificar.

 INCI                                         
  CO                                          
ORIGEN                                        
-----------------------------------------------
     *  BE                                    
    -   TH                                    
  a     B2    c                               
   a    BE                                    
  fa    BE                                    
     <  TH                                    
     <  BE                                    
     <  BE                                    
     <  BE                                    
     <  BE                                    
     <  BE                                    
     <  BE                 


Vamos a ver ahora un par de métodos para traducir los caracteres extraños a contenido alfanumérico. Usaremos uno u otro según nos convenga.

El próximo día, en un nuevo post, continuaremos viendo los pasos que hay que seguir para visualizar los campos hexadecimales en QMF mediante la herramienta FORM. Es importante que dominemos esta técnica pues, aunque no es la forma más cómoda de leer hexadecimales, sí que se trata del método de visualización más rápido. Si necesitamos consultar y analizar un dato lo antes posible, entonces os puedo asegurar que lo mejor será recurrir al FORM.

Pues nada, eso es todo por ahora. Ya sabéis que quedáis invitados a la segunda parte del artículo, espero veros por aquí cuando revisemos los pasos que nos quedan pendientes. Que sigáis disfrutando del Cobol hasta entonces...

Saludos.

lunes, 16 de mayo de 2016

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.

lunes, 9 de mayo de 2016

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.

Related Posts Plugin for WordPress, Blogger...