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.

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.

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.

Informático con insomnio

Fuente: El Economista

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.

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.

Programador de vacaciones

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.

Ver fichero VSAM mediante DITTO

La aplicación DITTO/ESA for OS/390 es una herramienta de IBM muy útil a la hora de tratar con registros de ficheros VSAM. En el blog ya hemos visto muchas otras formas de visualizar el contenido de un VSAM, pero nunca viene mal disponer de un acceso alternativo. Quizás nos sea útil en el futuro.

Ver fichero VSAM mediante DITTO

Como ya sabemos, el contenido de los ficheros VSAM no se consulta del mismo modo que el de los ficheros secuenciales estándar. En general, para acceder a sus registros tenemos que hacer uso de herramientas específicas para dicha tarea. A este respecto, hoy en particular vamos a revisar la aplicación "DITTO/ESA for OS/390" de IBM.

Es posible que muchos de vosotros no dispongáis de esta herramienta en vuestro trabajo. Si es así, comentadlo con vuestros responsables o con vuestro cliente. En muchas ocasiones no suelen poner pegas para incluir esta aplicación en la instalación e incluso, si tenéis suerte, puede que ya esté instalada y simplemente no tuviérais constancia de ello.

La herramienta DITTO/ESA dispone de muchas funcionalidades, pero hoy en el post vamos a centrarnos en la opción que nos permite visualizar el contenido de los ficheros VSAM. Si trabajáis a menudo con ficheros VSAM, entonces este conocimiento os será muy útil. Si no los usáis demasiado, bueno, entonces es que estáis empezando en esto del mundo Host: pronto os cansaréis de operar con ellos.

Opción DITTO para visualizar registros VSAM

A continuación, sin más demora, vamos ir viendo los pasos que hay que seguir para visualizar registros VSAM mediante DITTO. Intentaré hacerlo con el mayor detalle posible, para intentar evitar que os queden muchas dudas al respecto.

1º) Accedemos al menú principal de DITTO/ESA for OS/390. Esto se hace de forma diferente en cada instalación, así que tendréis que preguntar a vuestros responsables de soporte.

2º) Se selecciona la opción 1 - BROWSE DATA y pulsamos INTRO. De esta forma, accederemos a la ventana de visualización de datos.



3º) Se selecciona la opción 3 - VSAM DATA y pulsamos INTRO. Así se accederá al menú de visualización.

4º) Procedemos a introducir el nombre del fichero VSAM buscado en el campo DATA SET NAME. Pulsamos INTRO y pasaremos a la ventana en la que se nos muestra el contenido del fichero.

Por ejemplo, en la imagen anterior vemos que se ha introducido el fichero VSAM con nombre 'JJLDB2.DSNDBD.JJATL23.JJFRLOTE.I0001.A001'.

5º) Si ponemos M y pulsamos PF5, nos desplazaremos a la derecha hasta el final del fichero VSAM. De esta forma, los últimos campos de los registros quedarán visibles para nosotros.

Siguiendo con el ejemplo anterior, en la imagen podemos ver los últimos campos del fichero VSAM con nombre 'JJLDB2.DSNDBD.JJATL23.JJFRLOTE.I0001.A001'.

Conclusiones acerca del Browse de DITTO

Siguiendo los pasos comentados anteriormente, no deberíamos tener problema para ver el contenido de los ficheros VSAM mediante DITTO. De todas formas, tal y como os he dicho más arriba, aquí lo más importante es que os digan cómo se puede acceder a la herramienta en vuestra instalación (o, si no disponéis de ella, que negociéis con vuestro cliente y que intentéis que os la proporcione).

En el post de hoy hemos visto cómo usar la opción BROWSE del DITTO para visualizar el contenido de los ficheros VSAM. Por supuesto, la aplicación permite realizar funcionalidades adicionales como, por ejemplo, edición de datasets VSAM. En futuros post os iré hablando sobre estas otras opciones.

En el blog ya hemos ido hablando en repetidas ocasiones sobre diferentes herramientas que nos permiten acceder a ficheros VSAM. Aunque normalmente nos bastará con disponer de una de ellas en nuestro trabajo, nunca viene mal conocer el mayor número posible de aplicaciones de tratamiento VSAM. La razón de esta necesidad es que va a resultar complicado que nos encontremos con la misma herramienta en dos clientes diferentes.



Conforme vayamos teniendo más experiencia en Cobol, nos daremos cuenta de que la aplicación DITTO de IBM es bastante utilizada en el mundo Host. Así que, cuanto antes os pongáis con la tarea de aprender su funcionalidad, pues más fácil os resultará posteriormente empezar a trabajar con ella. Siempre hay que coger el toro por los cuernos...

Pues nada, eso es lo que quería comentaros hoy con respecto a esta herramienta. Espero que todo haya quedado claro pero, si no es así, dejadme vuestras preguntas en el apartado de comentarios. Intentaré contestaros lo antes posible.

Saludos.

READ FILE: Leer fichero VSAM desde Cobol

Uno de los problemas relevantes con los que nos vamos a encontrar a menudo es la necesidad de acceder a un fichero VSAM para leer su contenido desde un programa Cobol. Este acceso no es tan sencillo como la lectura de una tabla DB2 y, por tanto, para su implementación tendremos que utilizar instrucciones CICS. Pero bueno, no hay que dejarse amedrentar por ello y en este post trataremos de explicar en detalle cómo realizar dicha operativa.

Leer fichero VSAM desde programa Cobol

En muchas ocasiones nos vamos a encontrar con que, desde un programa Cobol, tenemos que proceder a leer información que no está almacenada en ninguna tabla DB2 y que, en cambio, está contenida en un fichero VSAM. Para poder realizar esta función tendremos que recurrir a la instrucción CICS denominada READ FILE (o, en su codificación antigua, READ DATASET). Se trata de uno de los comandos básicos de acceso a ficheros.



Para ver cómo se debería implementar esta actuación vamos a revisar un ejemplo con el que me encontré hace algún tiempo. En él se trataba de leer los registros contenidos en un fichero VSAM denominado JJRPRTAK para luego tratarlos posteriormente en el programa Cobol.

05 COM2EZ-CLAVE.                                  
   10 COM2EZ-EIBTASK                      PIC 9(7).
   10 COM2EZ-JJEQ-IN-TIPELE               PIC X.  
   10 COM2EZ-JJEQ-NU-EXTERN               PIC 9(9).
05 W-RESP                    PIC S9(8) COMP  VALUE ZEROES.

...

EXEC CICS                  
   READ FILE('JJRPRTAK')
        INTO(COM2EZ) 
        LENGTH(COM2EZ-LONGITUD)      
        RIDFLD(COM2EZ-CLAVE)             
        RESP(W-RESP)       
END-EXEC. 

IF W-RESP NOT  = 0                                 
   MOVE W-CD-1             TO COM2JN-W-NMENSA      
   MOVE W-CD-MENSAJE-E0301 TO COM2JN-W-MENSA(W-CD-1)
   PERFORM 9999-ERROR THRU 9999-ERROR-FIN          
END-IF.                                            

Como vemos, en el código anterior tenemos dos partes diferenciadas. En la primera parte aparece, entre los marcadores EXEC CICS y END-EXEC, el comando READ FILE y las cláusulas de las que se compone. Y en la segunda parte se muestra simplemente una de las formas (habría otras alternativas) en la que se podría implementar el control de errores asociado a la instrucción READ FILE.

Cláusulas de la instrucción CICS READ FILE

A la hora de implementar un READ FILE, lo  más importante es que tengamos claro a qué concepto corresponde cada una de las cláusulas del comando CICS. A continuación, vamos a ir examinando las sentencias de las que se compone la instrucción READ DATASET del ejemplo anterior.

1º) Instrucción READ: Este comando se emplea para indicarle al CICS que vamos a proceder con la lectura de un fichero VSAM.

2º) Cláusula FILE (o DATASET): En esta cláusula tenemos que indicar el nombre del fichero que queremos leer con la instrucción READ.

3º) Cláusula INTO: Aquí indicaremos el nombre de la variable del área de datos en la que queremos que se almacenen los campos del registro recuperado del fichero VSAM.

4º) Cláusula LENGTH: Aquí tendremos que especificar la longitud del área de datos en la que se va a capturar el registro del fichero VSAM.

5º) Cláusula RIDFLD: En esta importante cláusula tendremos que indicar el nombre de la variable de la clave por la que se tiene que buscar el registro en el fichero VSAM. Esto es, el READ del CICS buscará el registro cuya clave coincida con la que hemos especificado en RIDFLD y, una vez encontrado, nos lo devolverá para que almacenemos sus campos en la variable que habíamos indicado en INTO.

6º) Cláusula RESP: Aquí indicaremos el nombre de la variable en la que queremos capturar el código de retorno de la ejecución del comando CICS READ FILE.

7º) Control de errores: Finalmente, en la última intrucción IF validaremos si el retorno ha sido igual a cero (ejecución correcta) o distinto de cero (ejecución errónea). En este último caso procederemos a ejecutar el control de errores que consideremos necesario.

Una vez rellenadas las cláusulas anteriores, nuestra declaración EXEC CICS debería ejecutarse sin problema alguno. Como resultado de la misma se accedería al fichero indicado en FILE mediante la clave especidficada en la cláusula RIDFLD. Y posteriormente se cargaría el contenido de un registro del fichero VSAM en la variable especificada en la cláusula INTO, siempre y cuando se obtenga un código de retorno nulo en RESP.

Conclusiones acerca de la instrucción READ FILE

La instrucción READ FILE nos será muy útil en los casos en los que tengamos necesidad de acceder a los ficheros VSAM de una aplicación. Recordemos que los accesos a las tablas DB2 deben hacerse de otra forma diferente, tal y como ya vimos en el blog hace algún tiempo. Pero en el mundo host tan importantes son los VSAM como el DB2.

Hay que tener en cuenta que, al tratarse de un comando CICS, la instrucción READ FILE también podría ejecutarse directamente desde el entorno CICS. Esto se haría mediante el empleo de la transacción CECI. Tal y como ya sabemos, CECI nos permite, entre otras cosas, acceder tanto a ficheros VSAM como a colas TS y colas TD.

Si provisionamos las cláusulas tal y como hemos especificado más arriba, no deberíamos tener ningún problema a la hora de ejecutar nuestro programa Cobol. Pero, eso sí, si nunca habéis usado EXEC CICS READ FILE, entonces tendréis que tener un poco de paciencia, ya que a nadie le suelen funcionar los comandos CICS la primera vez que los usa.



En un futuro seguiremos viendo instrucciones CICS adicionales para operar con los ficheros VSAM desde programas Cobol. Aparte de leer, siempre son necesarias las operaciones de actualización, de inserción y de borrado. Pero, como digo, eso lo dejaremos para más adelante.

Así que eso es todo por hoy. Espero que os haya quedado claro cómo debemos emplear el comando CICS READ FILE. Si seguís teniendo alguna duda, la podéis dejar en el apartado de comentarios.

Saludos.