Desarrollando en Cobol y Natural sobre Plataforma Mainframe

jueves, 29 de mayo de 2014

Utilidad IEBGENER para JCL

Continuando con la revisión de las Utilidades JCL estándar de las que disponemos en el sistema operativo ZOS, hoy vamos a revisar la denominada IEBGENER. Este programa resulta de gran utilidad cuando necesitamos operar con ficheros secuenciales (Sequential Data Set).

La utilidad IEBGENER sirve para realizar copias de ficheros secuenciales. Normalmente se emplea para realizar un backup de un fichero secuencial origen, aunque también se puede utilizar para producir un PDS o un PDSE a partir de un Secuencial.



A continuación, podemos ver un ejemplo de cómo se podría emplear la utilidad IEBGENER para tomar un fichero secuencial origen y crear una copia del mismo.

//* PARAMETROS A USAR EN EL PGM: SYSPRINT, SYSIN, SYSUT1, SYSUT2 
//PASO1    EXEC PGM=IEBGENER 
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=JJ00.FACTURA1.ORIGINAL,DISP=SHR
//SYSUT2   DD DSN=JJ00.FACTURA1.COPIAFAC,
//            DISP=(NEW,CATLG,DELETE),UNIT=SYSDA,
//            SPACE=(TRK,(1,1),RLSE),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSIN    DD DUMMY   DUMMY--->COPIA SYSUT1 EN SYSUT2


Tal y como se puede observar, los parámetros que necesita la utilidad son los siguientes:

1º) Card SYSPRINT: Aquí tenemos que indicar el lugar al que deseamos que se envíen todos los mensajes generados durante el proceso de ejecución. Si ponemos SYSOUT=* entonces dicha información se enviará directamente al SPOOL (a la MSGCLASS indicada en nuestro job).

//SYSPRINT DD SYSOUT=*

2º) Card SYSIN: Son las sentencias de control de entrada para el programa. En este caso, el IEBGENER no lleva parámetros, así que lo ponemos a DUMMY.

//SYSIN    DD DUMMY

3º) Card SYSUT1: Se trata del fichero de origen, es decir, es el fichero secuencial del que vamos a realizar una copia. En el ejemplo es el fichero JJ00.FACTURA1.ORIGINAL.

//SYSUT1   DD DSN=JJ00.FACTURA1.ORIGINAL,DISP=SHR

4º) Card SYSUT2: Es el fichero de salida, es decir, el fichero copia del que hemos indicado en la card SYSUT1. En el ejemplo, el fichero se denominará JJ00.FACTURA1.COPIAFAC. Como vemos, aquí podemos indicar las características que deseamos que tenga nuestro fichero secuencial: DISP, SPACE, UNIT, VOLSER, RECFM, LRECL, BLKSIZE, etc...

//SYSUT2   DD DSN=JJ00.FACTURA1.COPIAFAC,
//            DISP=(NEW,CATLG,DELETE),UNIT=SYSDA,
//            SPACE=(TRK,(1,1),RLSE),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)


Una vez provisionados estos 4 parámetros, podríamos ejecutar nuestro JCL sin peligro ya que la ejecución del paso IEBGENER no debería darnos ningún problema. En el caso del ejemplo, nuestro JCL tomó el fichero secuencial JJ00.FACTURA1.ORIGINAL y realizó una copia con nombre JJ00.FACTURA1.COPIAFAC.

En líneas generales (aunque no siempre tiene por qué ser así), emplearemos la utilidad IEBGENER para operar con ficheros secuenciales y la utilidad IEBCOPY para la operativa con miembros particionados (PDS y PDSE). Esto nos facilitará mucho las cosas a la hora de elaborar nuestros JCL.

Y nada más. Como siempre, si os queda alguna duda al respecto de lo indicado sobre IEBGENER no dudéis en preguntárnoslo. Intentaremos resolverla en la medida de nuestras posibilidades.

Saludos.

jueves, 22 de mayo de 2014

Utilidad IEBCOPY para JCL

Ya hemos hablado en post anteriores sobre algunas de las Utilidades estándar para el tratamiento de JCL que vienen definidas en el sistema operativo ZOS. Otra de ellas es la denominada IEBCOPY, que nos puede ser muy útil para realizar el trabajo con miembros particionados (ficheros PDS) o Library (ficheros PDSE).

La utilidad IEBCOPY se emplea para realizar una copia de un miembro particionado (o de un miembro Library) o para unir dos miembros particionados. Su uso, muy sencillo, está muy extendido y lo encontraremos en gran cantidad de JCL de las aplicaciones que hay activas hoy en día.



Un ejemplo de cómo habría de emplearse lo podemos ver en el código que incorporamos a continuación. Se trata de un paso que podríamos insertar en cualquier JCL.

//STEP1    EXEC PGM=IEBCOPY                               
//SYSUT1   DD   DSN=LIBPR.JJ00.PROCLIB,DISP=SHR           
//SYSUT2   DD   DSN=LIBPR.JJ01.PROCLIB,

//              DISP=(NEW,CATLG,DELETE),
//              SPACE=(TRK,(10,5),RLSE),UNIT=SYSDA,       
//              DCB=(DSORG=PO,LRECL=80,RECFM=FB,BLKSIZE=0),
//              VOL=SER=ZARES1
//SYSPRINT DD   SYSOUT=*                                  
//SYSIN    DD   DUMMY    
                                 

Los declaraciones que hay que realizar para el IEBCOPY son las siguientes:

1º) Card SYSUT1: Se trata del miembro de origen, es decir, es el miembro del que vamos a realizar una copia. En el ejemplo es el miembro LIBPR.JJ00.PROCLIB.

//SYSUT1   DD   DSN=LIBPR.JJ00.PROCLIB,DISP=SHR  

2º) Card SYSIN: Son las sentencias de control de entrada para el programa. En este caso, el IEBCOPY no lleva parámetros, así que lo ponemos a DUMMY.

//SYSIN    DD   DUMMY                                  

3º) Card SYSUT2: Es el miembro de salida, es decir, el miembro copia del que hemos indicado en la card SYSUT1. En el ejemplo, el miembro se denominará LIBPR.JJ001.PROCLIB. Como vemos, aquí podemos indicar las características que deseamos que tenga nuestro miembro particionado: DISP, SPACE, UNIT, DCB, VOLSER, etc...

//SYSUT2   DD   DSN=LIBPR.JJ01.PROCLIB,
//              DISP=(NEW,CATLG,DELETE),
//              SPACE=(TRK,(10,5),RLSE),UNIT=SYSDA,       
//              DCB=(DSORG=PO,LRECL=80,RECFM=FB,BLKSIZE=0),
//              VOL=SER=ZARES1


4º) Card SYSPRINT: Aquí tenemos que indicar el lugar al que deseamos que se envíen todos los mensajes generados durante el proceso de ejecución. Si ponemos SYSOUT=* entonces dicha información se enviará directamente al SPOOL (a la MSGCLASS indicada en nuestro job).

//SYSPRINT DD   SYSOUT=*        

Una vez informadas estas 4 cards, nuestro paso JCL no debería dar ningún problema a la hora de crear una copia del miembro origen. En nuestro ejemplo, se creó el miembro LIBPR.JJ01.PROCLIB con una réplica de la información contenida en el miembro original LIBPR.JJ00.PROCLIB.

Esta es la forma en la que se suelen realizar copias de miembros particionados en la mayoría de las aplicaciones ZOS que hay operativas actualmente. Comentar que, aparte de para copiar, el IEBCOPY también se suele usar para realizar fusiones de miembros, pero la estructura de cards sería la misma.

Esperamos que, con la información proporcionada, podáis incluir la utilidad IEBCOPY en vuestros JCL. Si hay algo que no os ha quedado claro, no dudéis en preguntarlo.

Saludos.

jueves, 15 de mayo de 2014

Tipos de Ficheros VSAM

Los ficheros VSAM (Virtual Storage Access Method) fueron un tipo de fichero muy específico creado en 1970 para tratar de mejorar el rendimiento de los ficheros secuenciales, que era la entidad que se usaba hasta entonces para almacenar información de forma masiva.

La idea era que los archivos VSAM, debido a su estructura de almacenamiento y a su innovador método de acceso, permitiesen un tratamiento más rápido de la información y, de esa manera, el funcionamiento de las aplicaciones fuera más eficiente. Sin embargo, poco tiempo después, en 1975, aparecieron las Bases de Datos Relacionales y, desde ese momento, el empleo de los VSAM cayó en desuso.

A pesar de ello, hoy en día siguen quedando activas muchas aplicaciones que usan VSAM, con modelos de datos elaborados en los años 1970 y que han permanecido operativos durante todas estas décadas. De ahí que exista la posibilidad de que, en pleno siglo XXI, nos encontremos con la necesidad de realizar algún tipo de mantenimiento sobre este tipo de ficheros.



En la actualidad, existen 4 tipos de ficheros VSAM: KSDS, RRDS, ESDS y LDS. A continuación, detallamos un poco más en qué consiste cada uno de ellos.

1º) Entry Sequenced Data Set (ESDS): se trata del fichero VSAM equivalente al clásico Fichero Secuencial.

2º) Key Sequenced Data Set (KSDS): emplea dos subficheros para el tratamiento de los datos. Uno para el almacenamiento de índices y otro para la información (registros de datos) asociada a cada índice.

3º) Relative Record Data Set (RRDS): se trata del VSAM más eficiente. Se asigna un número relativo a cada registro, que es el que se usará para recuperar la información. Obviamente, si dicha asignación no se actualiza correctamente cada vez que borramos registros del fichero, entonces irán quedando espacios de memoria sin uso y el acceso será cada vez menos eficiente.

4º) Linear Data Set (LDS): este tipo de fichero se emplea para almacenar los TABLESPACE de las bases de datos DB2.



Tengamos en cuenta que, si vamos a crear una aplicación o un módulo nuevo, lo normal es que construyamos haciendo uso de una Base de Datos Relacional (por ejemplo, DB2) y de Ficheros Secuenciales. Hoy en día no se implementan desarrollos nuevos con ficheros VSAM, así que estos objetos únicamente los encontraremos cuando hagamos el mantenimiento de un sistema cuyo modelo de datos se elaboró en los años 70.

En principio, lo comentado debería bastar para hacernos una idea de la diferencia entre Ficheros Secuenciales, Ficheros VSAM y Bases de Datos Relacionales. De todas formas, en futuros post trataremos de ir profundizando sobre el tema.

Saludos.

jueves, 8 de mayo de 2014

Mostrar colores en los textos de un mapa Cobol (y 2)

Hace unos días publicamos un artículo en el que estuvimos hablando de la posibilidad de mostrar colores distintos del verde en los Mapset de Cobol (ver post Mostrar colores en los textos de un mapa Cobol - 1). De hecho, en la imagen que poníamos como ejemplo aparecían el amarillo, el rojo, el rosa, el azul y el turquesa.

Aunque en dicho post estuvimos hablando de la posibilidad de definir los colores en el propio mapa, nos quedó ver una segunda posibilidad, consistente en asignar los colores de los campos en el código del programa Cobol que invoca al Mapa. Esto último es lo que vamos a ver hoy.

Opción 2: Definir colores del mapa en el programa Cobol

Una alternativa para asociar colores a los textos de un mapa consiste en ir definiéndolos en el propio objeto Cobol. De esta forma, además, podremos ir cambiando el color de un determinado campo varias veces a lo largo del programa sin más que ir incluyendo una nueva sentencia de definición de color.

Por ejemplo, tendríamos la opción de mostrar un campo numérico en azul al comienzo del programa y, en un momento dado, si dicho campo supera un determinado valor, entonces podríamos decidir que pasara a mostrarse en rojo.

La definición de un color en el objeto Cobol es bastante sencilla. Simplemente tendremos que asignar el color deseado al parámetro Color que está asociado a la variable sobre la que deseamos actuar.



Imaginemos que, según el ejemplo que estamos analizando, queremos mostrar la variable "EQUIPO" con color amarillo en el mapa. Entonces, bastará con incluir esta sentencia antes de hacer la invocación al mapset.

MOVE DFHYELLO     TO EQUIPOC

En esta sentencia DFHYELLO es la constante que indica que queremos mostrar un dato en color amarillo (yellow), y "EQUIPOC" es el parámetro Color asociado a la variable "EQUIPO" en la copy del Mapset. Recordemos que, cuando compilamos un Mapset, se genera una Copy para el mismo (que es, en realidad, lo que se conoce como Mapa Simbólico) en la que aparecen todas las variables definidas en el mapa, junto con una serie de parámetros asociados a cada una de dichas variables.

De hecho, si nos vamos al Mapa Simbólico del ejemplo (que, en nuestro caso, se encuentra en la librería LIBPR.COPYS.JJ00) en su contenido veremos, entre otras cosas, la siguiente información.

01  JJ0005AO REDEFINES JJ0005AI.
    02  FILLER PIC X(12).       
    02  FILLER PICTURE X(3).    
    02  EQUIPOC    PICTURE X.   
    02  EQUIPOH    PICTURE X.   
    02  EQUIPOO PIC 999.     
   

Como se observa, para la variable EQUIPO se han generado varios parámetros con diferentes funciones. Cada parámetro se genera uniendo el nombre de la variable con una letra determinada: en particular, el parámetro Color resulta de la unión de la variable y la letra -C. En el caso del ejemplo, el parámetro creado es el denominado "EQUIPOC", con formato PIC X, que se usará para asociarle el color deseado a la información mostrada en la variable "EQUIPO".



Análogamente a lo que hemos hecho con este primer campo, si queremos mostrar los colores del ejemplo inicial en las variables correspondientes, tendremos que incluir las siguientes sentencias en el programa Cobol.

MOVE DFHRED       TO NOMBREC
MOVE DFHPINK      TO PUNTOSC
MOVE DFHBLUE      TO FAVORC 
MOVE DFHTURQ      TO CONTRAC


Como vemos, estaríamos asignando la constante del color requerido a cada uno de los parámetros Color (acabados en -C) de los campos afectados del Mapset (NOMBRE, PUNTOS, FAVOR y CONTRA). DFHRED es la constante para verde, DFHPINK para rosa, DFHBLUE para azul y DFHTURQ para turquesa (turquoise).









Finalmente, tras la asignación de colores, habría que realizar la invocación del Mapa, tal y como siempre se hace en los objetos Cobol. De esta forma ya se mostraría la información correspondiente con los colores definidos.

EXEC CICS                               
  SEND MAP ('JJ0005A') MAPSET ('JJ0005M')
  ERASE                                 
  FROM (JJ0005AO)                       
  NOHANDLE                              
END-EXEC.


Hay que tener en cuenta que las posibles constantes color que se podrán asignar a un Mapset en un programa Cobol serán las que se indican en la siguiente tabla.

CONSTANTE COLOR
DFHCOLOR 2 Color
DFHDFCOL 2 Default color
DFHBLUE Blue
DFHRED Red
DFHPINK Pink
DFHGREEN Green
DFHTURQ Turquoise
DFHYELLO Yellow
DFHNEUTR Neutral color

En líneas generales, eso es todo por lo que respecta a la asignación de colores en los mapas Cobol. Como vemos, se trata de un tema muy sencillo y que tampoco tiene mayor dificultad, una vez que se conoce la nomenclatura usada para cada uno de los colores disponibles.

De todas formas, si os queda alguna duda, no dudéis en preguntar y trataremos de resolverla (como siempre) en la medida de nuestras posibilidades.

Saludos.

jueves, 1 de mayo de 2014

Mostrar colores en los textos de un mapa Cobol (1)

En ocasiones, cuando estamos elaborando una aplicación, nos surge la necesidad de mostrar los textos de nuestros mapas con unos colores determinados. La paleta existente en Cobol no es demasiado amplia, pero al menos nos sirve para ir un poco más allá de los clásicos tonos verdes.



En realidad, para definir los colores en un mapa Cobol tendremos dos posibilidades.

1º) Definirlos directamente en el código del Mapset.
2º) Definirlos en el programa Cobol que va a invocar a nuestro Mapset.

Para explicar más fácilmente cómo se hace esto, vamos a tomar como ejemplo el mapa de la imagen, en el que observamos que se muestran textos en colores verde, amarillo, rojo, rosa, azul y turquesa. A continuación, veremos cómo se obtendría este resultado.



Opción 1: Definir colores en el código del Mapset

Si decidimos usar esta opción, tendremos que añadir el comando COLOR junto al texto que deseemos que adquiera el color seleccionado.

Por ejemplo, si queremos que el campo "EQUIPO" se muestre en color amarillo, como en el ejemplo anterior, la sentencia del Mapset tendrá el siguiente aspecto, incluyendo COLOR=YELLOW al final de la misma.

EQUIPO   DFHMDF POS=(11,24),LENGTH=3,ATTRB(NORM,UNPROT,NUM,FSET),
               PICIN='999',PICOUT='999',COLOR=YELLOW


Del mismo modo, si queremos que el campo "NOMBRE" se muestre en color rojo, tendremos que incluir el comando COLOR=RED al final de la sentencia correspondiente.

NOMBRE   DFHMDF POS=(13,24),LENGTH=25,ATTRB=(ASKIP,NORM),COLOR=RED

Los otros colores del ejemplo se corresponderán con las sentencias que detallamos a continuación, que incluyen los comandos COLOR=PINK, COLOR=BLUE y COLOR=TURQUOISE.

PUNTOS   DFHMDF POS=(13,51),LENGTH=3,ATTRB=(ASKIP,NORM),COLOR=PINK

FAVOR    DFHMDF POS=(14,28),LENGTH=3,ATTRB=(ASKIP,NORM),COLOR=BLUE

CONTRA   DFHMDF POS=(15,28),LENGTH=3,ATTRB(ASKIP,NORM),
               COLOR=TURQUOISE


Y la cosa no tiene mucho más misterio. Añadiendo la cláusula COLOR en la sentencia DFHMDF correspondiente, obtendremos fácilmente el resultado requerido (obviamente, no es obligatorio que dicha cláusula vaya al final, aunque en los ejemplos mostrados lo hayamos hecho así).

El próximo día continuaremos hablando sobre este tema y aprovecharemos nuestro siguiente post para hablar de la segunda opción de la que vamos a disponer para establecer los colores de los campos creados en nuestros Mapas Cobol.

Pues nada, simplemente nos queda emplazaros a la segunda parte de este post para completar la visión global sobre el manejo de colores por pantalla.

Saludos.


Related Posts Plugin for WordPress, Blogger...