Uno de los errores típicos a la hora de desarrollar un programa Cobol es tratar de incluir definiciones de ficheros secuenciales en objetos que van a ser invocados mediante Transacciones CICS. Esto le suele ocurrir sobre todo a los programadores que vienen del mundo Cobol Batch o a los desarrolladores que han hecho algún tipo de migración de objetos.
Normalmente, si elaboramos un programa Cobol con declaraciones de ficheros secuenciales y tratamos de invocarlo mediante una Transacción CICS, nuestro terminal nos devolverá un mensaje de error indicando que la ejecución ha fallado.
DFHAC2206 CICS Transaction XXXX failed with abend 4038
Cuando se nos genere un error de este tipo, no nos quedará más remedio que ir al Log del CICS para tratar de encontrar información más detallada sobre el problema. En el caso que nos ocupa, al buscar este detalle encontraremos algún mensaje de este tipo.
IGZ0096C A Load of Module IGZEQBL was unsuccessful.
The trackback information could not be determined.
¿Qué significa esto? Si vamos a la descripción del error, se especifica que la causa del mismo es que la aplicación contiene (de manera incorrecta) una definición de la cláusula FD para un fichero secuencial. Y, según se indica, el LE (Language Environment) ZOS V1R2 (y sus versiones posteriores) no permite realizar dicha definición.
En resumen, lo que viene a decirnos el error es que el uso del bloque FILE-CONTROL en la división ENVIRONMENT DIVISION o de la sección FILE SECTION en la división DATA DIVISION no está permitido en las aplicaciones CICS. Por tanto, las sentencias FD deben ser eliminadas de nuestro programa Cobol CICS.
Si nos vamos al programa, seguro que encontraremos alguna definición de FD, tal y como sucedió en este objeto Cobol CICS que ponemos de ejemplo.
******************************************************************
* ENVIRONMENT DIVISION
******************************************************************
ENVIRONMENT DIVISION.
*
******************************************************************
* INPUT-OUTPUT SECTION.
******************************************************************
INPUT-OUTPUT SECTION.
*
******************************************************************
* FILE-CONTROL BLOQUE
******************************************************************
FILE-CONTROL.
* NOMBRE LOGICO
SELECT ENTRADA1
* NOMBRE REAL FICHERO EN EL JCL O PC
ASSIGN TO ENTRADA1
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS FS-ENTRADA1.
*
SELECT SALIDA1
ASSIGN TO SALIDA1
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS FS-SALIDA1.
*
******************************************************************
* DATA DIVISION
******************************************************************
DATA DIVISION.
*
******************************************************************
* FILE SECTION
******************************************************************
FILE SECTION.
*
* DEFINICION CARACTERISTICAS REGISTRO DEL FICHERO
* NOMBRE DE INPUT-OUTPUT SECTION
FD ENTRADA1
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD.
01 RG-ENTRADA1 PIC X(28).
*
FD SALIDA1
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD.
01 RG-SALIDA1 PIC X(92).
*
Aquí eran las definiciones FD ENTRADA1 y FD SALIDA1 las que estaban provocando el error a la hora de invocar al programa mediante una Transacción CICS. Una vez se eliminaron la sección FILE SECTION y el bloque FILE-CONTROL, ya se pudo realizar la ejecución sin problema alguno.
Este es un tema que tenemos que tener en cuenta a la hora de desarrollar programas Cobol CICS. En las versiones antiguas de CICS sí que se podían realizar este tipo de declaraciones, pero actualmente están prohibidas en las versiones más modernas y optimizadas.
Pues nada, esperamos que vosotros nunca tengáis problemas de este tipo. Y bueno, si alguna vez os pasa, recordad lo que leísteis en este post y podréis solucionarlo con sencillez.
Saludos.
Desarrollando en Cobol y Natural sobre Plataforma Mainframe
jueves, 20 de febrero de 2014
jueves, 13 de febrero de 2014
Librerías de Módulos para Transacciones CICS
Cuando creamos una Transacción CICS y la asociamos a un determinado programa Cobol, la ejecución de dicha transacción va a buscar el módulo del programa en unas librerías determinadas, que son las librerías estándar que se han definido a la hora de inicializar el CICS.
En ocasiones, al ejecutar nuestra Transacción CICS obtenemos un mensaje de error indicándonos que no se encuentra la aplicación. Sin embargo, la compilación de nuestro programa se realizó correctamente. ¿Qué es lo que ha pasado, entonces? Pues, en muchas ocasiones, el problema es que nuestro CICS no está apuntando a la librería en la que se encuentra el módulo de nuestro programa y, por tanto, no puede ejecutarlo correctamente.
Para configurar las librerías de módulos a las que tiene que apuntar el CICS tenemos que acceder a los procedimientos CICSA y CICSB, que son los JCL que realizan la inicialización del sistema. Estos procesos se encuentran en la librería estándar ADCD.Z110.PROCLIB.
Procedimientos CICSA y CICSB
Una vez que accedemos al procedimiento CICSA, tendremos que buscar el paso DFHRPL (CICS Library Concatenation). Ahí encontraremos las librerías a las que el CICS va a buscar los módulos de los programas cuando se ejecuta una transacción.
Por defecto, las librerías son las siguientes:
//DFHRPL DD DSN=&INDEX2..SDFHLOAD,DISP=SHR
// DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
Si los nuevos módulos que estamos generando se están almacenando en una ubicación diferente, entonces tendremos que especificárselo al CICS en este paso. Por ejemplo, nosotros generamos los módulos en la librería LIBPR.MODULOS.JJ01. Por tanto, necesitaremos incluir dicha librería en el jcl CICSA. Así, el paso quedaría así:
//DFHRPL DD DSN=&INDEX2..SDFHLOAD,DISP=SHR
// DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
// DD DSN=LIBPR.MODULOS.JJ01,DISP=SHR
Una vez guardado el procedimiento con esta nueva información, ya no deberíamos tener problemas con el enlace entre las Transacciones CICS y los módulos de los programas Cobol asociados.
Este mismo cambio que hemos hecho en CICSA deberemos realizarlo también en el procedimiento CICSB. Siguiendo con el ejemplo de arriba, aquí también tendremos que incluir la librería LIBPR.MODULOS.JJ01 en el paso DFHRPL del jcl CICSB.
Una vez guardada esta información, ya tendremos adaptados nuestros procedimientos CICSA y CICSB. Recordad que la ubicación de los mismos en la librería ADCD.Z110.PROCLIB puede variar ligeramente en función de la instalación de nuestro sistema.
La adaptación de estos procedimientos CICS evitará que tengamos el problema que se mencionaba al principio del post, según el cual la ejecución de nuestras transacciones no encontraba los módulos de los programas a pesar de que habían compilado correctamente.
Y eso es todo por lo que respecta a este tema. Por muy simples que nos parezcan estos problemas, es importante no olvidar lo comentado, ya que alguna vez se nos puede plantear un caso similar a nosotros.
Saludos.
En ocasiones, al ejecutar nuestra Transacción CICS obtenemos un mensaje de error indicándonos que no se encuentra la aplicación. Sin embargo, la compilación de nuestro programa se realizó correctamente. ¿Qué es lo que ha pasado, entonces? Pues, en muchas ocasiones, el problema es que nuestro CICS no está apuntando a la librería en la que se encuentra el módulo de nuestro programa y, por tanto, no puede ejecutarlo correctamente.
Para configurar las librerías de módulos a las que tiene que apuntar el CICS tenemos que acceder a los procedimientos CICSA y CICSB, que son los JCL que realizan la inicialización del sistema. Estos procesos se encuentran en la librería estándar ADCD.Z110.PROCLIB.
Procedimientos CICSA y CICSB
Una vez que accedemos al procedimiento CICSA, tendremos que buscar el paso DFHRPL (CICS Library Concatenation). Ahí encontraremos las librerías a las que el CICS va a buscar los módulos de los programas cuando se ejecuta una transacción.
Por defecto, las librerías son las siguientes:
//DFHRPL DD DSN=&INDEX2..SDFHLOAD,DISP=SHR
// DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
Si los nuevos módulos que estamos generando se están almacenando en una ubicación diferente, entonces tendremos que especificárselo al CICS en este paso. Por ejemplo, nosotros generamos los módulos en la librería LIBPR.MODULOS.JJ01. Por tanto, necesitaremos incluir dicha librería en el jcl CICSA. Así, el paso quedaría así:
//DFHRPL DD DSN=&INDEX2..SDFHLOAD,DISP=SHR
// DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
// DD DSN=LIBPR.MODULOS.JJ01,DISP=SHR
Una vez guardado el procedimiento con esta nueva información, ya no deberíamos tener problemas con el enlace entre las Transacciones CICS y los módulos de los programas Cobol asociados.
Este mismo cambio que hemos hecho en CICSA deberemos realizarlo también en el procedimiento CICSB. Siguiendo con el ejemplo de arriba, aquí también tendremos que incluir la librería LIBPR.MODULOS.JJ01 en el paso DFHRPL del jcl CICSB.
Una vez guardada esta información, ya tendremos adaptados nuestros procedimientos CICSA y CICSB. Recordad que la ubicación de los mismos en la librería ADCD.Z110.PROCLIB puede variar ligeramente en función de la instalación de nuestro sistema.
La adaptación de estos procedimientos CICS evitará que tengamos el problema que se mencionaba al principio del post, según el cual la ejecución de nuestras transacciones no encontraba los módulos de los programas a pesar de que habían compilado correctamente.
Y eso es todo por lo que respecta a este tema. Por muy simples que nos parezcan estos problemas, es importante no olvidar lo comentado, ya que alguna vez se nos puede plantear un caso similar a nosotros.
Saludos.
viernes, 7 de febrero de 2014
jueves, 6 de febrero de 2014
¿Mapa Físico o Mapa Simbólico?
En relación con el post sobre Mapas Cobol que escribimos hace algún tiempo, algunos de vosotros nos habéis enviado mails preguntando cuál era la diferencia entre los Mapas Físicos y los Mapas Simbólicos. Esta era una duda que también tenía yo cuando empecé a trabajar con Cobol, pero en realidad la diferencia es muy sencilla.
Cuando creamos un Mapa Cobol, normalmente damos de alta su código en una librería MAPLIB (por ejemplo, la nuestra es LIBPR.MAPLIB.JJ00). Una vez completado dicho código, lo que hacemos es lanzar el Proceso de Compilación para Mapas, del cual ya hemos hablado en posts anteriores.
El Compilador de Mapas (DFHMAPS) es un JCL que, con su ejecución, genera varios objetos de salida. Entre ellos tenemos al Mapa Físico y al Mapa Simbólico, que es de lo que va el tema de hoy. A continuación, detallamos en qué consiste cada uno de los mapas creados.
1º) Mapa Fuente: es el objeto que codificamos nosotros y donde se especifican los campos que se van a mostrar por pantalla. Es el único mapa existente antes de la compilacion. También se denomina Mapa BMS (Basic Mapping Support). Ya hemos hablado de la Estructura de los Mapas Fuentes en posts anteriores.
2º) Mapa Simbólico: se genera tras la ejecución del Ensamblador y es un objeto que incorpora las declaraciones de las variables que hemos definido en el mapa fuente. Normalmente, este objeto se utiliza como Copy en el programa Cobol donde vamos a incluir el Mapa.
3º) Mapa Físico: se genera tras la ejecución del Linkage y el objeto creado es un módulo ejecutable. Este es el objeto que se invoca desde el programa Cobol en el momento en que se desea mostrar el Mapa por pantalla.
Como vemos, el Mapa Simbólico y el Mapa Físico no son dos tipos diferentes de Mapas, sino que son dos objetos asociados al Mapa que hemos codificado previamente. Estos objetos no van a existir hasta que no hayamos lanzado el compilador correspondiente.
Ejemplo de Mapa Simbólico
Supongamos ahora que codificamos un Mapa simple para mostrar por pantalla el mensaje "Hola Mundo". Tendríamos el siguiente código.
JJ0004M DFHMSD TYPE=DSECT,MODE=INOUT,TERM=ALL,STORAGE=AUTO,
LANG=COBOL
*
JJ0004A DFHMDI SIZE=(24,80),LINE=1,COLUMN=1,COLOR=GREEN,HILIGHT=OFF,
MAPATTS=(COLOR,HILIGHT),DSATTS=HILIGHT,CTRL=FREEKB
DFHMDF POS=(10,10),LENGTH=20,INITIAL='********************',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(11,10),LENGTH=20,INITIAL='* *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(12,10),LENGTH=20,INITIAL='* > HOLA, MUNDO! *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(13,10),LENGTH=20,INITIAL='* *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(14,10),LENGTH=20,INITIAL='********************',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
*
DFHMSD TYPE=FINAL
END
Tras la compilación del Mapa se nos generaría un Mapa Simbólico en la librería que hayamos definido para ello (en nuestro caso, usamos la librería LIBPR.COPYS.JJ00). El contenido de dicho mapa sería el siguiente.
EDIT LIBPR.COPYS.JJ00(JJ0004M) - 01.00 Columns 00001
Command ===> Scroll ===>
****** ***************************** Top of Data ****************
000001 01 JJ0004AI.
000002 02 FILLER PIC X(12).
000003 01 JJ0004AO REDEFINES JJ0004AI.
000004 02 FILLER PIC X(12).
****** **************************** Bottom of Data **************
Este objeto puede ser usado como Copy en cualquier programa Cobol donde se precise.
Ejemplo de Mapa Físico
Al mismo tiempo, nuestro compilador de Mapas habrá generado un Mapa Físico en la librería correspondiente (en nuestro caso se trata de la librería LIBPR.MODULOS.JJ01). El contenido de dicho mapa será el siguiente.
BROWSE LIBPR.MODULOS.JJ01(JJ0004M) Line 0000000
Command ===> Scr
********************************* Top of Data ********************
IEWPLMH ...Ì...................Ì...........ð...........m...h......
******************************** Bottom of Data ******************
Este objeto es el que se debe invocar desde el programa Cobol cuando queramos mostrar el Mapa por pantalla.
Y esta es toda la diferencia existente entre el Mapa fuente, el Mapa Simbólico y el Mapa Físico. Recordad que no se trata de tipologías diferentes de mapas, sino de objetos que quedan asociados entre sí tras realizar la compilación de un Mapset.
Pues nada, esperamos que con este post haya quedado más o menos resuelta la duda con la que comenzábamos al principio. Si no es así, no dudéis en seguir preguntando.
Saludos.
Cuando creamos un Mapa Cobol, normalmente damos de alta su código en una librería MAPLIB (por ejemplo, la nuestra es LIBPR.MAPLIB.JJ00). Una vez completado dicho código, lo que hacemos es lanzar el Proceso de Compilación para Mapas, del cual ya hemos hablado en posts anteriores.
El Compilador de Mapas (DFHMAPS) es un JCL que, con su ejecución, genera varios objetos de salida. Entre ellos tenemos al Mapa Físico y al Mapa Simbólico, que es de lo que va el tema de hoy. A continuación, detallamos en qué consiste cada uno de los mapas creados.
1º) Mapa Fuente: es el objeto que codificamos nosotros y donde se especifican los campos que se van a mostrar por pantalla. Es el único mapa existente antes de la compilacion. También se denomina Mapa BMS (Basic Mapping Support). Ya hemos hablado de la Estructura de los Mapas Fuentes en posts anteriores.
2º) Mapa Simbólico: se genera tras la ejecución del Ensamblador y es un objeto que incorpora las declaraciones de las variables que hemos definido en el mapa fuente. Normalmente, este objeto se utiliza como Copy en el programa Cobol donde vamos a incluir el Mapa.
3º) Mapa Físico: se genera tras la ejecución del Linkage y el objeto creado es un módulo ejecutable. Este es el objeto que se invoca desde el programa Cobol en el momento en que se desea mostrar el Mapa por pantalla.
Como vemos, el Mapa Simbólico y el Mapa Físico no son dos tipos diferentes de Mapas, sino que son dos objetos asociados al Mapa que hemos codificado previamente. Estos objetos no van a existir hasta que no hayamos lanzado el compilador correspondiente.
Ejemplo de Mapa Simbólico
Supongamos ahora que codificamos un Mapa simple para mostrar por pantalla el mensaje "Hola Mundo". Tendríamos el siguiente código.
JJ0004M DFHMSD TYPE=DSECT,MODE=INOUT,TERM=ALL,STORAGE=AUTO,
LANG=COBOL
*
JJ0004A DFHMDI SIZE=(24,80),LINE=1,COLUMN=1,COLOR=GREEN,HILIGHT=OFF,
MAPATTS=(COLOR,HILIGHT),DSATTS=HILIGHT,CTRL=FREEKB
DFHMDF POS=(10,10),LENGTH=20,INITIAL='********************',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(11,10),LENGTH=20,INITIAL='* *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(12,10),LENGTH=20,INITIAL='* > HOLA, MUNDO! *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(13,10),LENGTH=20,INITIAL='* *',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
DFHMDF POS=(14,10),LENGTH=20,INITIAL='********************',
COLOR=BLUE,ATTRB=(ASKIP,NORM)
*
DFHMSD TYPE=FINAL
END
Tras la compilación del Mapa se nos generaría un Mapa Simbólico en la librería que hayamos definido para ello (en nuestro caso, usamos la librería LIBPR.COPYS.JJ00). El contenido de dicho mapa sería el siguiente.
EDIT LIBPR.COPYS.JJ00(JJ0004M) - 01.00 Columns 00001
Command ===> Scroll ===>
****** ***************************** Top of Data ****************
000001 01 JJ0004AI.
000002 02 FILLER PIC X(12).
000003 01 JJ0004AO REDEFINES JJ0004AI.
000004 02 FILLER PIC X(12).
****** **************************** Bottom of Data **************
Este objeto puede ser usado como Copy en cualquier programa Cobol donde se precise.
Ejemplo de Mapa Físico
Al mismo tiempo, nuestro compilador de Mapas habrá generado un Mapa Físico en la librería correspondiente (en nuestro caso se trata de la librería LIBPR.MODULOS.JJ01). El contenido de dicho mapa será el siguiente.
BROWSE LIBPR.MODULOS.JJ01(JJ0004M) Line 0000000
Command ===> Scr
********************************* Top of Data ********************
IEWPLMH ...Ì...................Ì...........ð...........m...h......
******************************** Bottom of Data ******************
Este objeto es el que se debe invocar desde el programa Cobol cuando queramos mostrar el Mapa por pantalla.
Y esta es toda la diferencia existente entre el Mapa fuente, el Mapa Simbólico y el Mapa Físico. Recordad que no se trata de tipologías diferentes de mapas, sino de objetos que quedan asociados entre sí tras realizar la compilación de un Mapset.
Pues nada, esperamos que con este post haya quedado más o menos resuelta la duda con la que comenzábamos al principio. Si no es así, no dudéis en seguir preguntando.
Saludos.
Suscribirse a:
Entradas (Atom)