Desarrollando en Cobol y Natural sobre Plataforma Mainframe

viernes, 29 de abril de 2016

Programador de vacaciones


lunes, 25 de abril de 2016

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.

lunes, 18 de abril de 2016

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.

lunes, 11 de abril de 2016

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.

lunes, 4 de abril de 2016

Query SQL con UNION y con UNION ALL (y 2)

Hace unas semanas comenzamos a ver cómo debían implementarse las queries con las cláusulas UNION ALL y UNION. La ventaja de estos comandos es que nos permiten rebajar drásticamente los tiempos de ejecución de las sentencias SQL que tengamos insertadas en el código de nuestros objetos Cobol. Aunque en principo esto pueda parecer poco relevante, en cuanto vayamos teniendo más experiencia lo normal es que también vaya aumentando la preocupación por el rendimiento de nuestros programas.

En la primera parte del post nos centramos en analizar cómo debía codificarse una query con la cláusula UNION (ver post Query SQL con UNION y con UNION ALL - 1). Hoy, para completar la visión global, vamos a examinar cómo debería implementarse una query con UNION ALL. Y, lo que es más importante, explicaremos cuál es la diferencia entre la instrucción UNION ALL y la instrucción UNION del lenguaje SQL.

Diferencia entre UNION ALL y UNION


Más arriba he hablado de la cláusula UNION ALL y de la cláusula UNION. ¿Cuál es la diferencia entre ambas? En realidad, son dos variantes del mismo concepto. En general, nos será más útil el comando UNION, pero es posible que alguna vez nos venga bien utilizar UNION ALL.

La ejecución de la query con UNION nos va a extraer el listado de datos eliminando todos aquellos registros que estén duplicados. ¿Cuáles se consideran duplicados? Pues aquellos registros que tengan provisionados valores idénticos en todos aquellos campos especificados en la cláusula SELECT (si hemos puesto un * entonces serían todos los campos del registro).

Siguiendo con este razonamiento, la ejecución de la misma query con UNION ALL nos va a extraer el listado de datos incluyendo todos aquellos registros que estén duplicados. Por eso decía que, en general, preferiremos usar el comando UNION. Eso sí, alguna vez puede que necesitemos recuperar el listado completo (con todos sus duplicados) y para eso nos vendrá muy bien el comando UNION ALL.



En el ejemplo anterior, el uso de UNION ALL no cambiaría demasiado el aspecto del código SQL. Quedaría del siguiente modo.

  SELECT *                                                     
  FROM JJDB22.JJETRAT0 A, JJDB22.JJTRAMT0 B
  WHERE                                                        
     ( A.JJTU_CO_INTERN = 'Z.BR' AND A.JJCA_CO_INTERN = 1)

    AND A.JJTU_CO_INTERN   = B.JJTU_CO_INTERN                  
    AND A.JJCA_CO_INTERN   = B.JJCA_CO_INTERN                   
    AND A.JJAM_NU_INTERN   = B.JJAM_NU_INTERN  


  UNION ALL

  SELECT *                                                     
  FROM JJDB22.JJETRAT0 A, JJDB22.JJTRAMT0 B
  WHERE                                                        
     (A.JJTU_CO_INTERN_1 = 'Z.BR' AND A.JJCA_CO_INTERN_1 = 1)
                  
    AND A.JJTU_CO_INTERN_1 = B.JJTU_CO_INTERN_1  
    AND A.JJCA_CO_INTERN_1 = B.JJCA_CO_INTERN_1  
    AND A.JJAM_NU_INTERN   = B.JJAM_NU_INTERN


Como vemos, se trata prácticamente de la misma query. Simplemente tendremos que decidir previamente si necesitamos los registros duplicados o no.


Conclusiones acerca de UNION ALL y UNION


Tal y como hemos podido comprobar a lo largo del post, la cláusula UNION nos puede resultar muy útil en aquellos casos en los que tengamos que mejorar el rendimiento de una query compleja. Como he podido comprobar en numerosas ocasiones, su uso suele tener mucho éxito a la hora de bajar los tiempos de ejecución por debajo de los 100 milisegundos. Así que tenedlo en cuenta a la hora de implementar los objetos Cobol.

Normalmente, yo suelo utilizar UNION para problemas de rendimiento. Por contra, dejo UNION ALL para casuísticas muy especiales en las que necesito conocer el número de registros que hay en una determinada tabla DB2. Si puedo prescindir de dicho dato, entonces prefiero obtener los listados sin registros duplicados.

En los ejemplos habéis podido comprobar que la implementación de un UNION es muy sencilla. La verdadera dificultad viene a la hora de pensar cómo se puede dividir una query compleja en varias queries más sencillas. Es decir, se trata más de un problema funcional que de una dificultad técnica.



Pero no os preocupéis. Con un poco de experiencia se va haciendo cada vez más fácil la tarea de dividir queries. Como punto de partida, en estos casos en los que preciséis mejorar el rendimiento, podéis echarle un vistazo a las declaraciones en las que se estén empleando operadores OR. Normalmente, no es difícil fraccionar estas sentencias en varias queries más simples.

Pues nada, eso es todo por hoy. Espero que lo comentado a lo largo del artículo os sea útil para entender el funcionamiento de UNION ALL y de UNION. En caso de que os quede alguna duda, ya sabéis que aquí abajo tenéis el apartado de comentarios...

Saludos.
Related Posts Plugin for WordPress, Blogger...