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.

Transacción CMAC: Mensajes de error CICS

La transacción CMAC de CICS es una herramienta muy sencilla, pero que nos va a permitir acceder a una explicación detallada del error CICS que nos esté bloqueando el avance en un momento dado. Aunque su uso no supone complejidad alguna, a mi siempre me gusta incluirla en la lista de transacciones básicas CICS, fundamentalmente debido a su gran utilidad. Estoy seguro de que a vosotros también os gustará disponer de esta ayuda en vuestra instalación.

Transacción CMAC: Mensajes de error

En líneas generales, podemos decir que la transacción CMAC nos permite introducir un determinado código de error y, a partir de él, nos va a devolver una explicación del mensaje de error. También nos proporcionará algunas directrices de cómo podríamos proceder para tratar de subsanar el problema con el que nos hemos encontrado. Se trata, por tanto, de una base de datos de errores CICS.

A continuación, vamos a enumerar los pasos necesarios para poder recuperar la información mencionada. Son los siguientes.

1º) En primer lugar, procedemos a entrar en la sesión CICS y, una vez dentro, introducimos la transacción CMAC.

2º) Tras pulsar INTRO, se nos desplegará la ventana inicial de la herramienta, en donde aparecen dos campos pendientes de provisionar: COMPONENT ID y MESSAGE NUMBER.

En el campo COMPONENT ID tendremos que indicar la tipología del error y en MESSAGE NUMBER habrá que especificar el código numérico del mensaje de error o aviso para el que queremos conocer más detalles. Por ejemplo, en la imagen anterior hemos introducido "TC" y "1060" (correspondientes al error CICS DFHTC1060).

3º) Si insertamos COMPONENT ID y MESSAGE NUMBER y, a continuación, pulsamos INTRO, la aplicación nos llevará a la ventana de detalle del mensaje.

En el ejemplo podemos ver que en dicha ventana se muestra el título DFHTC1060 APPLID INSUFFICIENT STORAGE - CODE(X'CODE') IN MODULE DFHTCRP. En el informe nos aparecen varios apartados (EXPLANATION, SYSTEM ACTION, USER RESPONSE, DESTINATION, MODULE y MESSAGE INSERTS) en los que se nos va explicando detalladamente en qué consiste el error y cuáles son las medidas que podemos tomar para tratar de subsanarlo.

   

Conclusiones sobre la Transacción CMAC

Y no hay mucho más que comentar acerca de esta transacción. Se trata de una herramienta de uso sencillo y con un objetivo muy definido. Eso sí, las explicaciones de los errores son detalladas y útiles. En más de una ocasión os puede dar buenas ideas acerca de cómo superar ese error CICS que os está impidiendo avanzar tanto con el desarrollo de vuestros módulos Cobol como con la implementación de las fases JCL.

Eso sí, verificad que en vuestra instalación está disponible. He comprobado que algunas empresas se olvidan de instalar CMAC y, entonces, no podréis acceder a esta ayuda en vuestro día a día. Si tenéis la posibilidad, pedidle a vuestro cliente que lo instale en el entorno.

Como he dicho al principio, aunque en muchos listados no aparezca, yo siempre incluyo a CMAC entre las transacciones básicas de CICS. Ya sé que es una transacción muy sencilla, pero el hecho de que una herramienta sea simple no significa que no sea importante para nuestro desempeño. Ya lo iréis comprobando con el tiempo.

Y eso es todo por lo que respecta a CMAC. Supongo que os habrá quedado bastante claro el funcionamiento de la transacción pero, si no es así, no dudéis en dejarme los comentarios que creáis convenientes...

Saludos.

Como obtener la fecha del sistema en Cobol

Una rutina típica que suele tener todo programa Cobol es la de recuperación de la fecha y la hora actual del sistema. Se trata de una información muy útil generalmente precisada para su inclusión en los informes solicitados por el usuario o para indicar la fecha de actualización de los datos en las tablas DB2 (TIMESTAMP).

Aunque hay varias alternativas, una forma estándar de obtener la fecha en Cobol es mediante la utilización de los comandos CICS ASKTIME y FORMATTIME. Con unas pocas operaciones, estas instrucciones nos permiten disponer de una variable fecha (y hora) formateada según las necesidades de nuestra aplicación.



A continuación, vamos a ver un ejemplo en Cobol de cómo se podría recuperar la fecha y dejarla cargada en una variable de trabajo. Supongamos, en primer lugar, que tenemos definidas las siguientes variables en nuestra WORKING-STORAGE SECTION.

05  W-FECHA-HORA-SISTEMA  PIC   S9(15) COMP-3 VALUE   0.
05  W-ANNO-SISTEMA        PIC   S9(8)  COMP   VALUE   0.
05  W-MES-SISTEMA         PIC   S9(8)  COMP   VALUE   0.
05  W-DIA-SISTEMA         PIC   S9(8)  COMP   VALUE   0.

05  W-HORA-SISTEMA.                                  
    10  W-HH-SISTEMA      PIC    9(2)      VALUE    0.
    10  FILLER            PIC    X         VALUE  '.'.
    10  W-MM-SISTEMA      PIC    9(2)      VALUE    0.
    10  FILLER            PIC    X         VALUE  '.'.
    10  W-SS-SISTEMA      PIC    9(2)      VALUE    0.

05  W-FECHA-SISTEMA.                                 
    10  W-ANNO            PIC    9(4)      VALUE    0.
    10  FILLER            PIC    X         VALUE  '-'.
    10  W-MES             PIC    9(2)      VALUE    0.
    10  FILLER            PIC    X         VALUE  '-'.
    10  W-DIA             PIC    9(2)      VALUE    0.

05  W-TIMESTAMP.                                       
    10  W-FECHA-SYS       PIC    X(10)     VALUE SPACES.
    10  FILLER            PIC    X(1)      VALUE '-'.  
    10  W-HORA-SYS        PIC    X(8)      VALUE SPACES.
    10  FILLER            PIC    X(1)      VALUE '-'.  
    10  W-MILISEG-SYS     PIC    9(6)      VALUE 0.    

La idea es recuperar la fecha del CICS en el parámetro W-FECHA-HORA-SISTEMA y, tras las operaciones pertinentes, dejar preparada la fecha/hora del sistema en W-TIMESTAMP. Esta última variable podrá ser utilizada para provisionar los campos TIMESTAMP de los registros de las tablas DB2 que sean modificados por nuestro programa.

A continuación, mostramos un código que podría ser incluido en una rutina Cobol para realizar la transformación comentada. Obviamente, no es la única solución que podría ser implementada.

EXEC CICS                        
     ASKTIME                     
     ABSTIME(W-FECHA-HORA-SISTEMA)
END-EXEC                         
                                 
EXEC CICS                        
     FORMATTIME                  
     ABSTIME(W-FECHA-HORA-SISTEMA)
     YEAR(W-ANNO-SISTEMA)        
     MONTHOFYEAR(W-MES-SISTEMA)  
     DAYOFMONTH (W-DIA-SISTEMA)  
     TIME(W-HORA-SISTEMA)        
     TIMESEP('.')                
END-EXEC.                        

MOVE W-DIA-SISTEMA  TO  W-DIA              
MOVE W-MES-SISTEMA  TO  W-MES              
MOVE W-ANNO-SISTEMA TO  W-ANNO.            
                                           
MOVE W-FECHA-SISTEMA      TO W-FECHA-SYS   
MOVE W-HORA-SISTEMA       TO W-HORA-SYS    
MOVE W-FECHA-HORA-SISTEMA TO W-MILISEG-SYS.

Una vez visto el código completo, pasamos a detallar un poco cuál sería el objetivo de cada uno de los bloques desarrollados.

1º) En primer lugar, se emplea el comando CICS ASKTIME para recuperar la fecha y hora actual del sistema.

2º) La cláusula ABSTIME permite almacenar (en una variable) la fecha del sistema con un formato conocido como tiempo absoluto. Dicho formato especifica la cantidad de milisegundos transcurridos desde el inicio del año 1900 hasta el momento actual.

3º) El comando FORMATTIME transforma una fecha de tiempo absoluto en una fecha y hora con el formato que deseemos.



4º) En el ejemplo anterior se obtienen varios elementos de la variable de tiempo absoluto. Con YEAR, MONTHOFYEAR y DAYOFMONTH se extraen de ella el año, el mes y el día, respectivamente. Finalmente, con TIME extraemos la hora del reloj y con TIMESEP especificamos el separador deseado entre horas, minutos y segundos.

5º) A continuación, transferimos los datos extraídos de día, mes y año a una variable W-FECHA-SISTEMA donde guardaremos la información con el formato que deseemos.

6º) Finalmente, movemos la fecha del sistema, la hora del sistema y el tiempo absoluto en milisegundos a una variable W-TIMESTAMP. Esta variable será la que se use para almacenar el TIMESTAMP en los registros que nuestro programa Cobol precise modificar en las tablas DB2.

Aunque aparentemente parecen demasiados pasos para la elaboración de una rutina tan básica, la realidad es que, una vez codificada, podremos ir copiándola sin más de un programa a otro. Se trata de un párrafo que no necesitará modificaciones adicionales, salvo que queramos cambiar el formato de la fecha obtenida.



Como vemos, aquí tenemos un método estándar para crear una fecha/hora de sistema y para disponer de un TIMESTAMP en los programas Cobol. La primera funcionalidad es muy útil para mostrar información a los usuarios y la segunda resulta imprescindible si queremos mantener una trazabilidad de las modificaciones que se vayan realizando en las tablas DB2. Si todavía no estáis de acuerdo con ello, os aseguramos que tarde o temprano lo estaréis.

Pues nada, eso es todo lo que queríamos comentaros por hoy. Esperamos que esta rutina de captura de fecha de sistema os sea útil y que podáis emplearla frecuentemente en vuestros propios objetos.

Saludos.

Tipos de Colas CICS (y 2)

Hace algunas semanas comenzamos a ver en qué consistían las Colas CICS y cuáles eran los tipos que nos podíamos encontrar en un sistema Mainframe. Básicamente, las colas son un soporte de almacenamiento alternativo a los ficheros secuenciales, a los ficheros VSAM y a las tablas DB2.

En la primera parte del post ya estuvimos revisando las Colas TS - Temporary Storage (ver post Tipos de Colas CICS - 1). Sin embargo, nos quedó pendiente examinar el funcionamiento del otro gran grupo de este género de entidades: las Colas TD - Transient Data.

Colas TD: Transient Data Queue

Las Colas TD son un tipo de almacenamiento que, en su origen, se usaba fundamentalmente para implementar las colas de impresión. Actualmente suelen ser utilizadas como soporte de memoria para procesos batch: con cierta periodicidad, los demonios recogen los datos de la cola y realizan un tratamiento con ellos. Por supuesto, también pueden ser empleadas como simples ubicaciones de memoria para nuestros procesos on-line.

Los registros guardados en una Cola TD, tal y como ocurría con los de las Colas TS, son de longitud variable y se denominan items. En este caso son almacenados y recuperados de forma secuencial.

A diferencia de las TS, las Colas TD tienen que ser creadas y definidas antes de poder ser utilizadas en un programa Cobol. Junto a esto, la otra diferencia importante es que, conforme vamos recuperando la información, los items extraídos se van borrando automáticamente de la Cola TD.



Las Colas TD pueden ser de dos tipos:

- Tipo Extra-Partition: Este tipo de colas, que tienen que ser definidas como de entrada o de salida, permiten intercambiar datos con ubicaciones exteriores a nuestra región CICS. Es decir, con una Cola Extra-Partition podríamos enviar datos a un demonio externo o recoger los datos generados por un proceso batch externo.

- Tipo Intra-Partition: Estas Colas TD se almacenan en un espacio de memoria interno de nuestro CICS y admiten el procesamiento ATI (Automatic Transaction Initiation). Dicha técnica permite lanzar de forma automática (sin intervención alguna del usuario) una transacción CICS predefinida cuando en la Cola TD se acumule un número determinado de items.



En resumen, hemos visto que en el sistema CICS disponemos de varios tipos de Colas para afrontar las diversas opciones de procesamiento que nos podemos encontrar en una aplicación. Por un lado, las Colas TS (Main y Auxiliary) nos permitirán almacenar información que va a ser requerida de forma temporal por nuestros programas Cobol. Y por otro lado, las Colas TD (Extra-Partition e Intra-Partition) nos permitirán realizar procesamientos ATI o implementar procesos batch de intercambio de datos con otros CICS.

Las Colas son un tipo adicional de soporte de almacenamiento utilizable en los sistemas CICS, una opción más que se une a las ya conocidas de ficheros secuenciales, ficheros VSAM y tablas DB2. Ya será decisión nuestra, en función de las necesidades, usar uno u otro tipo en los programas Cobol.



Por supuesto, la única forma de aprender a utilizar las Colas es practicando con ellas. Aunque su uso pueda parecer un poco extraño al principio (sobre todo si estamos acostumbrados a operar con ficheros y tablas DB2), la realidad es que su operativa es tan sencilla como pueda serlo la del resto de tipos de almacenamiento.

Esperamos que, con todo lo comentado en el post, queden resueltas todas las dudas que os puedan surgir con relación a las Colas CICS. Si no es así, se aceptan preguntas...

Saludos.

Tipos de Colas CICS (1)

Las Colas CICS son instrumentos auxiliares que se utilizan para almacenar datos (fundamentalmente de forma temporal) que, con posterioridad, podrán ser empleados por nuestros programas Cobol. Cada una de las unidades de información guardadas en dichas Colas se denomina item (de manera análoga a lo que sería el registro de un fichero).

Las Colas CICS son ampliamente utilizadas para el intercambio de datos temporales entre varios programas Cobol (o incluso dentro de un mismo programa). De esta forma, evitamos sobrecargar los ficheros secuenciales, los ficheros VSAM o las tablas DB2 con información de vida efímera.

En un primer nivel, las Colas se dividen en dos tipos principales: Colas TD (Transient Data Queue) y Colas TS (Temporary Storage Queue). A continuación, pasamos a verlas en detalle.

Colas TS: Temporary Storage Queue

Las Colas TS, tal y como su nombre indica, sirven para almacenar información temporalmente y suelen ser utilizadas para la paginación de los datos mostrados por los programas Cobol. Los registros que se guardan en ellas son de longitud variable y se denominan items.

La ventaja de este tipo de Colas es que no es necesario que estén predefinidas con anterioridad a la ejecución de nuestra aplicación. Es decir, si en un objeto Cobol indicamos que queremos almacenar información en una Cola TS inexistente (con el comando WRITEQ, por ejemplo), la entidad se creará automáticamente en el momento en que se ejecute la instrucción del programa.

Los items de la Cola pueden ser recuperados de forma secuencial o directa y, una vez dados de alta, también podrían ser modificados. Finalmente, comentar que la información permanecerá almacenada en la Cola hasta que los items no sean borrados explícitamente (con el comando DELETEQ, por ejemplo).



Las Colas TS pueden ser de dos tipos:

- Tipo Main: Se almacenan en la memoria principal. Son el tipo más común de Cola TS, ya que su creación es viable en cualquier sistema CICS.

- Tipo Auxiliary: Utilizarán como soporte de almacenamiento una memoria temporal auxiliar. Este tipo de Colas TS se podrá crear siempre y cuando nuestro sistema CICS permita el uso de memoria auxiliar.

El próximo día continuaremos viendo el segundo tipo de Colas CICS, las Transient Data Queue, y haremos hincapié en las características específicas que las distinguen de las Colas TS. Tal y como veremos, hay algunas diferencias importantes en el comportamiento de ambas entidades, cosa que deberá ser tenida en cuenta a la hora de implementar su uso en los programas Cobol.

Pues nada más. Os invitamos a que leaís la segunda parte del post, donde terminaremos de revisar los tipos de Colas CICS existentes. Con ello nos debería quedar una idea bastante clara que nos ayude a entender qué son estas entidades.

Saludos.

Transacción CEBR: Visualización de Colas CICS (y 2)

Hace algún tiempo comenzamos a ver cuáles eran las posibilidades que nos ofrecía la transacción CEBR para trabajar con las Colas CICS. Esta herramienta nos permitía acceder a una Cola TS (o una Cola TD) y extraer los items almacenados en su interior.

Ya estuvimos viendo cuál era la operativa que teníamos que seguir para examinar el contenido de las Colas TS (ver post Transacción CEBR - Visualización de Colas CICS - 1). Sin embargo, nos quedó pendiente revisar el proceso requerido para sus entidades hermanas, las Colas TD. A continuación nos ponemos con ello.

B) Visualización de una Cola TD

En el caso de una Cola TD (Transient Data), el procedimiento a seguir para visualizar su contenido es algo diferente del de las Colas TS. Una vez nos encontremos en el menú inicial de la herramienta CEBR, en la línea de comandos tendremos que insertar la instrucción GET y, a continuación, el nombre de la Cola que deseamos leer.

ENTER COMMAND ===> GET COTD

En nuestro ejemplo, vamos a consultar el contenido de la Cola TD denominada COTD. Por tanto, tras pulsar INTRO, la transacción CEBR mostrará la siguiente pantalla.



Como podemos ver, en este caso se han recuperado dos items, el primero de ellos con el texto "ESTO ES UNA COLA TD" y el segundo con la información "ESTO TAMBIEN" (estos items han sido cargados en COTD con anterioridad).

El contenido de la Cola TD se borra automáticamente tras extraer los items con GET. Por tanto, si deseamos que la información recuperada vuelva a estar disponible en la Cola, tendremos que hacer uso de la instrucción PUT. Este comando sirve para insertar en la Cola TD los items que se estén visualizando en ese momento en la herramienta CEBR.

En nuestro caso, si en la línea de comandos insertamos PUT y, a continuación, COTD (el nombre de la Cola TD del ejemplo), el sistema procederá a insertar los dos items que estamos viendo ("ESTO ES UNA COLA TD" y "ESTO TAMBIEN") en la cola COTD.



Tal y como vemos, el proceso de visualización de una Cola TD es algo diferente del de las Colas TS pero, en definitiva, sigue siendo igualmente sencillo.

En principio, con los dos ejemplos comentados, ya no deberíamos tener problemas a la hora de acceder al contenido de las Colas CICS, independientemente de que estemos frente a una Cola TS o una Cola TD. Tal y como hemos visto, ambos procedimientos constan de muy pocos pasos, por lo que son sencillos de recordar.

 

Aunque existen otras formas de acceder al contenido de las Colas CICS, la realidad es que la transacción CEBR nos facilita enormemente el proceso de visualización de los datos almacenados en ellas. De ahí que lo más inteligente sea aprender a operar con la herramienta, ya que eso nos ayudará a ahorrar bastante tiempo en nuestra rutina diaria (cosa que siempre debería ser uno de nuestros objetivos).

Eso es todo. Esperamos que haya quedado todo claro en relación con la transacción CEBR. De todas formas, como siempre os recordamos, podéis hacernos llegar cualquier duda que os surja al respecto.

Saludos.

Transacción CEBR: Visualización de Colas CICS (1)

La transacción CEBR es una herramienta que nos puede ser muy útil para trabajar de una forma sencilla con las Colas TS y las Colas TD. Recordemos que las Colas CICS son instrumentos auxiliares que se utilizan para almacenar información (fundamentalmente de forma temporal) que pueda ser utilizada por nuestros programas Cobol.

La transacción CEBR (BROWSE TEMPORARY STORAGE) sirve para visualizar el contenido de las Colas TS (Temporary Storage) y de las Colas TD (Transient Data). Sin más que indicar el nombre de la Cola deseada, la herramienta nos permitirá examinar el contenido de la misma en nuestra pantalla.



Al introducir la transacción CEBR en el terminal CICS, el sistema nos redirigirá al menú principal de la herramienta, que tendrá el aspecto siguiente.



A continuación estudiaremos los procedimientos a seguir para examinar tanto una Cola TS como una Cola TD. A pesar de tratarse de entidades Cola, vamos a ver que la forma de acceso al contenido difiere ligeramente si trabajamos con una TS o con una TD.

A) Visualización de una Cola TS

Para visualizar el contenido de una Cola TS (Temporary Storage) tendremos que situarnos en la línea de comandos e introducir la instrucción Q (QUEUE). Junto a ella, habrá que especificar el nombre de la Cola TS cuyo contenido deseamos examinar.

ENTER COMMAND ===> Q COLA_TS

En nuestro ejemplo, vamos a consultar el contenido de una Cola denominada COLA_TS. Por tanto, tras pulsar INTRO, la transacción CEBR mostrará la siguiente pantalla.



Tal y como se puede observar, en COLA_TS aparecen dos items (los cuales habrán sido cargados en la cola, previamente, mediante algún proceso). En la primera posición aparece el mensaje "ESTO_ES_UNA_COLA_TS" y en el segundo item aparece el texto "ESTO_TAMBIEN".

Opcionalmente, tenemos la posibilidad de borrar el contenido de la Cola TS sin más que introducir la instrucción PURGE en la línea de comandos. Su ejecución procedería a borrar todos los items, dejando la Cola totalmente vacía.

ENTER COMMAND ===> PURGE

En líneas generales, el proceso de visualización de una Cola TS es bastante simple, y no precisa seguir más pasos que los comentados previamente.

Del mismo modo que hoy hemos visto las Colas TS, el próximo día seguiremos viendo cómo se puede trabajar con las Colas TD mediante la herramienta CEBR. Tal y como hemos dicho más arriba, aunque en ambos casos estemos hablando de Colas CICS, el procedimiento de acceso al contenido cambia ligeramente según nos enfrentemos a un tipo de Cola u otro.

Y con esto terminamos. Sencillamente nos queda convocaros para la segunda parte del post, donde procederemos a examinar el resto de posibilidades que nos ofrece CEBR.

Saludos.

Transacción CMSG: Servicio de mensajería CICS

En el post de hoy vamos a hablar de una nueva transacción secundaria, denominada CMSG, cuya funcionalidad nos permitirá el envío de mensajes de un terminal CICS a otro. Aunque hoy en día existen muchas alternativas de comunicación, nunca está de más saber cómo funciona el servicio de mensajería en CICS.

La transacción CMSG (MESSAGE SWITCHING) permite el envío de mensajes a través del CICS, sin más que especificar el código de terminal en el que deseamos que se visualice el texto. Puede ser empleada para, desde un terminal CICS origen, enviar un mensaje tanto a un único terminal como a un grupo de terminales destino.



Operar con esta herramienta es muy sencillo. Simplemente tendremos que introducir la transacción CMSG y, seguidamente, el código del terminal destino y el mensaje de texto que deseamos enviar. A continuación veremos un par de ejemplos, uno en el que se envía información a un terminal único y otro cuyo destino es un grupo de terminales.

A) Envío de mensaje a un terminal

Para enviar un mensaje a un terminal determinado, tendremos que indicar el código del terminal destino en una sentencia como la siguiente.

CMSG M='HOLA DESDE CICS',R=L701,S

En dicha línea se incluye la transacción CMSG, la cláusula R (ROUTE) con el código del terminal requerido (en nuestro caso, queremos enviar el mensaje al terminal L701), la cláusula M (MSG) con el mensaje de texto que vamos a enviar a la ubicación destino (en el ejemplo, "HOLA DESDE CICS") y el comando S (SEND).

Tras pulsar INTRO, en el terminal CICS L701 aparecerá la siguiente pantalla con el mensaje enviado a través de CMSG.



Como se puede apreciar, se muestra el texto "HOLA DESDE CICS", que era el mensaje que queríamos emitir desde nuestro terminal origen.

B) Envío de mensaje a un grupo de terminales

Si queremos enviar un mensaje a un grupo de terminales destino, tendremos que incluir dicho grupo en la cláusula R (ROUTE) de la transacción CMSG.

CMSG M='REINICIO DE CICS EN 15 MINUTOS',R=ALL,S

Por ejemplo, la sentencia anterior ejecutará el envío al grupo ALL (es decir, a todos los terminales del CICS) del mensaje "REINICIO DE CICS EN 15 MINUTOS". Obviamente, en R podemos incluir cualquier grupo de terminales que tengamos predefinido.

Si, tras introducir la transacción anterior, pulsamos INTRO, en todas las ubicaciones del CICS aparecerá la siguiente pantalla.



Aunque en la imagen anterior sólo se muestra el resultado de un terminal específico, en realidad en cualquiera de ellos se mostrará el mensaje "REINICIO  DE CICS EN 15 MINUTOS" (correspondiente al texto lanzado desde el terminal origen).

Como vemos, enviar mensajes desde nuestro terminal (mediante CMSG) es algo sencillo, tanto si queremos enviar un texto a un terminal único como si tenemos que publicar un comunicado destinado a todos los terminales de nuestro CICS. La operativa no tiene mayor complejidad que la indicada.

Evidentemente, CMSG se encuadra dentro de lo que hemos venido denominando transacciones secundarias de CICS. Se trata de una herramienta cuyo uso no es imprescindible en nuestro día a día pero, a pesar de ello, es conveniente saber cómo funciona por si en algún momento tenemos que recurrir a ella.

Eso es todo. Esta transacción no tiene mayor historia y estamos seguros de que, con los ejemplos mostrados, habrá quedado claro cómo es su funcionamiento.

Saludos.

Transacción CEOT: Información del Terminal CICS

Hoy vamos a examinar una herramienta (transacción) muy sencillita cuya utilización nos permite acceder a la información asociada a nuestro Terminal. Fundamentalmente se emplea para determinar el código del Terminal que estamos empleando, aunque también muestra otro tipo de información.

La transacción CEOT (TERMINAL STATUS) sirve para ver el estado de nuestro Terminal CICS y configurar los parámetros asociados al mismo. A pesar de ello, en general sólo se suele utilizar cuando se precisa saber cuál es el código del Terminal desde el que tenemos que introducir los comandos CICS.



Si limpiamos la pantalla de una sesión CICS e introducimos la transacción CEOT, el primer menú que nos aparecerá en el terminal será el siguiente.



Como podemos ver, en la parte de arriba se muestra la configuración que tiene actualmente asociada nuestro terminal (STATUS).

STATUS:  RESULTS - OVERTYPE TO MODIFY
Ter(L701) Tra(CEOT) Pri(000) Pag Ins Ati Tti Net(LCL701  )
   Acq Uct                                                

El primer dato (el más usado) es el código del terminal TER, que en nuestro caso es el L701. A continuación, también se indican la transacción TRA (CEOT), la Prioridad PRI (000) y el nombre de la Red NET (LCL701).

Podemos observar que en esta línea de STATUS aparecen ciertos campos en color verde: estos son los valores que nos permite modificar el sistema. Se corresponden con las siguientes características: PAGESTATUS, ATISTATUS, TTISTATUS y UCTRANST.

A este respecto, en la parte de abajo de la pantalla se nos muestran cuáles serían los posibles valores que podría tomar cada uno de estos cuatro campos.

CEOT SYNTAX:                       
 < Pageable | Autopageable >       
 < Ati | Noati >                   
 < Tti | Notti >                   
 < Uctran | Nouctran | Tranidonly >

Pulsando sobre cualquier campo del apartado STATUS accederíamos a una nueva pantalla en la que se nos presentaría, de forma más detallada, la configuración actual asociada a nuestro terminal. Del mismo modo que en el menú anterior, aquí los campos modificables también aparecen en color verde.



A continuación, en los puntos siguientes, vamos a detallar cuáles serían las diferentes opciones de las que dispondríamos en cada una de las características modificables.

1º) PAGESTATUS: Aquí podremos introducir Pageable o Autopageable. Con Pageable las páginas sucesivas de una serie se irán mostrando en el terminal conforme el usuario vaya solicitando pasar a la siguiente. Con Autopageable, en cambio, todas las páginas de la serie se irán enviando al terminal de forma automática.

2º) ATISTATUS: Disponemos de las opciones Ati o Noati. Con Ati el terminal estará disponible para ser usado por las transacciones arrancadas automáticamente desde CICS. Con Noati, como es fácil deducir, no estará disponible.

3º) TTISTATU: Podríamos introducir Tti o Notti. Tti indica, simplemente, que nuestro terminal puede ser usado por transacciones CICS. Notti, por contra, nos estaría indicando que no podría ser utilizado por las transacciones arrancadas desde nuestro terminal.

4º) UCTRANST: En este caso disponemos de tres opciones, que se aplicarían a la sesión que tengamos abierta: Uctran, Nouctran o Tranidonly. La opción Uctran activaría la traducción de mayúsculas para las aplicaciones que vayamos a ejecutar (de manera que no se distinguiría entre mayúsculas y minúsculas), mientras que Nouctran la desactivaría. Finalmente, Tranidonly indicaría que se debe emplear la traducción de mayúsculas únicamente para los códigos de Transacciones (y no para el resto de cosas que hagamos en las aplicaciones arrancadas).



Con todo lo indicado anteriormente, ya nos debería quedar una visión global bastante clara de la información que se puede obtener (y modificar) mediante el comando CEOT. Como vemos, aunque casi todo el mundo la utilizar para identificar su código de terminal, en realidad sirve para algunas cosas más.

En realidad, no hay mucho más que comentar. Se trata de una transacción muy sencilla y de uso bastante limitado. Pero, como siempre decimos, es importante conocer el alcance de estos comandos secundarios, pues algún día nos puede hacer falta modificar la configuración de nuestro terminal.

Y nada más. Como siempre, confiamos en que el post os haya servido para resolver las dudas relacionadas con CEOT. Guardadlo por ahí por si en algún momento tenéis que rescatarlo...

Saludos.

Transacción CECI para ejecución de comandos CICS (y 2)

Hace algunas semanas comenzamos a ver en qué consistía la transacción CECI y cómo se podía utilizar para llevar a cabo la ejecución de un comando CICS desde el propio terminal. Esto es muy útil para saber si nuestras sentencias CICS son válidas antes de realizar su inclusión en el programa Cobol.

Ya estuvimos examinando cómo se podía mostrar un mapa mediante CECI y SEND MAP (ver post Transaccion CECI para ejecucion de comandos CICS - 1). Pero, tal y como dijimos, nos queda pendiente revisar otra situación en la que también podremos observar cómo hay que ejecutar las instrucciones CICS mediante esta herramienta.

Del mismo modo que hemos visto la ejecución del comando SEND, ahora pasaremos a ver otro ejemplo de cómo se lanzaría el comando WRITEQ mediante CECI.

Crear una Cola TS mediante CECI

1º) En primer lugar tendríamos que introducir WRITEQ en la línea de comandos.



2º) A continuación se nos mostraría una pantalla en la que tendríamos que seleccionar alguna de las opciones disponibles: TD (Transient Data Queue) o TS (Temporary Storage Queue).



En nuestro caso, como queremos crear una Cola TS, recurriremos a la opción TS. Por tanto, en la línea de comandos tendremos que añadir TS a continuación de la función WRITEQ.

WRITEQ TS

3º) Ahora pasaremos a una pantalla en la que se nos mostrarán todas las opciones disponibles para la creación de una Cola TS. Del mismo modo que en el ejemplo anterior (cuando estuvimos viendo el SEND MAP), dichas opciones se corresponderán con todas las cláusulas que podrían acompañar a la sentencia WRITEQ TS cuando la codificamos en un programa Cobol.



Como vemos, aparecen las cláusulas QUEUE, SYSID, FROM, LENGTH, ITEM, REWRITE, etc... Obviamente, no hace falta que las provisionemos todas, sino solamente aquellas que realmente sean necesarias para la operación que queremos realizar.

Ahora, para el ejemplo actual, sólo vamos a indicar el nombre de la Cola (en el parámetro QUEUE) y el contenido que deseamos insertar en ella (en el parámetro FROM). Para ello, incluiremos la sentencia QUEUE ('COLA2') FROM ('TEXTO') tras el comando WRITEQ TS.

WRITEQ TS QUEUE ('COLA2') FROM ('TEXTO')

4º) Finalmente, tras pulsar INTRO, nos aparecerá el mensaje "COMMAND EXECUTION COMPLETE" y la respuesta RESPONSE: NORMAL. Esto quiere decir que la creación de la Cola TS se ha completado con éxito.

COMMAND EXECUTION COMPLETE
RESPONSE: NORMAL

De hecho, si visualizásemos el contenido de la cola COLA2 veríamos que el contenido de la misma se corresponde con lo que hemos enviado en la cláusula FROM ('TEXTO'). Esto lo podemos confirmar en la siguiente imagen.



Con los dos ejemplos anteriores, SEND MAP y WRITEQ TS, nos podemos hacer una idea bastante clara de cómo sería la operativa que habría que seguir con la transacción CECI a la hora de ejecutar los comandos CICS. Lo realizado con estas dos instrucciones es fácilmente extrapolable al resto del API de CICS.

Por tanto, a partir de ahora ya sabemos que disponemos de una herramienta (CECI) que nos permitirá lanzar y probar las instrucciones CICS que deseamos incluir en nuestro programa Cobol. De este modo, podremos ahorrarnos mucho trabajo de depuración, ya que desde un primer momento sabremos que el código creado es correcto.

Y eso es todo lo que queríamos comentar. Esperamos que, con los ejemplos indicados, haya quedado claro para qué sirve la herramienta CECI y cómo se puede utilizar para mejorar nuestra programación Cobol.

Saludos.

Transacción CEDF: Herramienta CICS de depuración (y 2)

Hace algunas semanas comenzamos a revisar el funcionamiento de la transacción CEDF de depuración CICS. Aunque ya vimos cuáles eran las pantallas básicas de la herramienta, nos quedó pendiente mostrar cómo se visualizaría en el depurador el proceso de envío y de recepción de datos entre un Mapa y un programa Cobol.

En la primera parte estuvimos viendo cuáles eran los pasos iniciales a seguir para navegar por CEDF (ver post Transacción CEDF - Herramienta CICS de depuración - 1). A continuación, continuaremos mostrando cuáles serían las etapas correspondientes si quisiéramos simular, desde el depurador, el proceso de comunicación entre un Mapset y el programa que lo invoca.

6º) Si ahora pulsamos INTRO, se mostrará en pantalla el mapa enviado y podremos operar sobre él del mismo modo que lo haríamos si no estuviésemos en modo depuración.



7º) En el ejemplo que estamos tratando, procedemos a introducir el valor '3' en el campo EQUIPO y, a continuación, pulsamos la tecla INTRO. De este modo, pasamos de nuevo a una pantalla con estado "COMMAND EXECUTION COMPLETE".



Como vemos en la imagen, el comando ejecutado es EXEC CICS RECEIVE MAP y el MAP asociado es el JJ0005M. En el parámetro INTO, que es la información que nuestro programa Cobol recibe del terminal, vemos que aparece el valor '003' (el número de equipo que hemos introducido previamente en el mapa).

8º) Si pulsamos INTRO se mostrará de nuevo el mapa con la información que se ha recuperado para el elemento solicitado (el '003', en nuestro caso). Como vemos, ya aparecen rellenos los campos N+PTOS, GOLES FAVOR y GOLES CONTRA, que inicialmente estaban vacíos.



9º) A continuación, pulsando INTRO pasaremos otra vez a la pantalla con estado "COMMAND EXECUTION COMPLETE", en la que se ha ejecutado el comando EXEC CICS SEND MAP.



Podemos ver que los parámetros ahora muestran la siguiente información:

MAP ('JJ0005A')              
FROM ('......6.003...21REAL MADRID              ...3.53 ...1.6'...)
LENGTH (74)
MAPSET ('JJ0005M')
TERMINAL
ERASE
NOHANDLE

El parámetro FROM muestra la información que se envió al mapa y se mostró en el terminal. En el ejemplo, en el contenido de esta línea podemos apreciar el nombre del equipo (REAL MADRID), los puntos (53), los goles a favor (60) y los goles en contra (21). Esto siempre nos será de mucha ayuda para ver qué es lo que realmente se está intentando enviar desde el programa Cobol hacia el Mapset.

10º) Finalmente, pulsando otra vez INTRO, pasaremos a una pantalla en la que se nos muestra el estado TASK TERMINATION, lo que significa que ha terminado la ejecución de la tarea de la transacción y se devuelve el control al CICS.  



Para salir del CEDF tendremos que acordarnos de indicar 'NO' en el campo REPLY de la ventana y pulsar la tecla INTRO.

REPLY: NO

De este modo volveremos al terminal CICS y ya nos encontraremos fuera de la funcionalidad del entorno de depuración de esta valiosa herramienta.

Al principio, puede parecer un poco complejo ir navegando por todas las pantallas de la transacción CEDF. Sin embargo, en realidad se trata de un proceso bastante repetitivo y, en cuanto lo hayamos usado un par de veces, no tardaremos en acostumbrarnos a interpretar los datos proporcionados por este Debugger.

Como hemos dicho al principio, se trata de una herramienta muy útil (y casi imprescindible a la hora de detectar los errores con rapidez). Obviamente, existen otras formas de detectar los problemas en nuestros programas Cobol pero, si nos acostumbranos a usar CEDF, pronto nos daremos cuenta de que el proceso de depuración nos ayuda a que la búsqueda sea mucho más rápida.

Pues nada, esperamos que, con lo comentado, sea suficiente para que os hagáis una idea de cómo es el funcionamiento de la transacción CEDF. Ahora ya es decisión vuestra aprender a utilizarla (o no).

Saludos.

Transacción CEDF: Herramienta CICS de depuración (1)

Al igual que en otros muchos lenguajes más modernos, en el entorno CICS también disponemos de una herramienta para realizar la depuración de los programas COBOL DB2. Como ya sabemos, el empleo de los debuggers nos puede ahorrar mucho tiempo a la hora de encontrar errores en el código de los objetos.

La transacción CEDF sirve para iniciar la herramienta de depuración (o Debugger) de la que disponemos en el entorno CICS. Una vez arrancada, podremos indicar la transacción asociada a nuestra aplicación y CEDF realizará una simulación controlada de la ejecución de la misma, mostrándonos en todo momento el contenido de las variables activas y la parte del código CICS que se está ejecutando.



Si entramos en un terminal CICS e introducimos la transacción CEDF, lo primero que nos aparecerá será el mensaje: "THIS TERMINAL: EDF MODE ON". Esto significa que CEDF está esperando que introduzcamos la transacción de la aplicación sobre la que deseamos realizar el proceso de depuración (debugging).

THIS TERMINAL: EDF MODE ON

A continuacion, los pasos a seguir para trabajar con CEDF serán los siguientes:

1º) Tendremos que pulsar la tecla CLEAR (PAUSA) para limpiar el texto mostrado. Una vez tengamos la pantalla en blanco, procederemos a introducir la transacción correspondiente y pulsamos INTRO. La primera pantalla del Debugger que nos aparecerá será la siguiente.



Como vemos en la imagen, en la primera línea nos aparecen los datos de la transacción cuya ejecución estamos simulando con CEDF. En nuestro caso, se trata de la transacción 0005, el programa JJ0005CO (asociado a la transacción 0005) y la tarea 0000082.

TRANSACTION: 0005
PROGRAM: JJ0005CO 
TASK: 0000082
APPLID: CICS

En el centro de la pantalla nos aparecerán los valores que tengan en cada momento los parámetros del área de comunicaciones EIB. Esta información irá variando conforme se vayan ejecutando las rutinas de los programas asociados a la transacción y podrá ser consultada desde cualquier ventana del Depurador pulsando la tecla PF11 - EIB DISPLAY.

EIBTIME      = 42923         
EIBDATE      = 0114241       
EIBTRNID     = '0005'        
EIBTASKN     = 82            
EIBTRMID     = 'L701'        
                             
EIBCPOSN     = 4             
EIBCALEN     = 0             
EIBAID       = X'7D'         
EIBFN        = X'0000'       
EIBRCODE     = X'000000000000'
EIBDS        = '........'    
EIBREQID     = '........'           

2º) Si pulsamos INTRO, el Debugger saltará al primer comando CICS que se encuentre en el programa que se está ejecutando (JJ0005CO, en nuestro ejemplo). En el estado se mostrará "ABOUT TO EXECUTE COMMAND", con lo que nos está avisando de que está a punto de ejecutarse el comando mostrado.

STATUS:  ABOUT TO EXECUTE COMMAND                              
EXEC CICS SEND MAP                                             
 MAP ('JJ0005A')                                               
 FROM ('...................................................'...)
 LENGTH (74)                                                   
 MAPSET ('JJ0005M')                                            
 TERMINAL                                                      
 ERASE                                                         
 NOHANDLE                                                                                                                      
En el ejemplo se indica que se va a ejecutar el comando CICS SEND MAP. Debajo se muestra el contenido de las variables correspondientes a cada una de las cláusulas del SEND MAP, esto es, el nombre del mapa a enviar (JJ0005A), el nombre del mapset (JJ0005M), la longitud del mapa (74) y la información a mostrar en el mapa.

3º) Si pulsamos INTRO, se mostrará la siguiente pantalla. Como vemos, el estado de la transacción a cambiado a "COMMAND EXECUTION COMPLETE", lo que significa que ya se ha enviado el mapa.



4º) Si volvemos a pulsar INTRO ahora se mostrará la pantalla siguiente. Aquí se nos indica que está a punto de ejecutarse (ABOUT TO EXECUTE COMMAND) el comando EXEC CICS RETURN, que es el que finaliza la transacción que está en curso y devuelve el control al terminal CICS.



5º) Para continuar debemos pulsar INTRO de nuevo. En esta pantalla se nos muestra el estado PROGRAM TERMINATION, lo que significa que ha terminado la ejecución del programa Cobol y que se ha devuelto el control al CICS. 



El próximo día, en un post adicional, continuaremos viendo cómo es el sistema de navegación a través de la herramienta CEDF. No deberíamos tener problemas en entenderlo ya que, al fin y al cabo, el proceso consta de una serie de pasos estándar que, sencillamente, se van repitiendo con cada una de las instrucciones CICS que posee nuestro programa Cobol.

Y eso es todo por hoy. Os emplazamos a la segunda parte del post para terminar de ver el funcionamiento del depurador CEDF. Nunca viene mal aprender cosas nuevas.

Saludos.

Transacción CECI para ejecución de comandos CICS (1)

Una de las herramientas más empleadas en el entorno CICS es la denominada CECI. Se trata de una transacción muy útil que nos sirve para ejecutar comandos CICS en un terminal on-line y acceder a todos los recursos del entorno sin necesidad de codificar un programa Cobol.

La transacción CECI tiene acceso a todo el API del CICS y, por tanto, permite la ejecución de cualquier comando contenido en él. Normalmente se suele emplear para verificar, en el propio entorno on-line, si los comandos CICS que hemos incluido en nuestro programa Cobol se han codificado correctamente o no.



Si entramos en un terminal CICS e introducimos la transacción CECI, la primera pantalla que nos aparecerá será la siguiente.



Tal y como podemos apreciar, lo que se están mostrando son todos los comandos CICS que están disponibles para su uso: READ, RECEIVE, REWRITE, SEND, START, WRITE, etc... Dicho de otro modo, estas serían todas las instrucciones que podríamos embeber en los bloques CICS (aquellos delimitados por las sentencias EXEC CICS y END-EXEC) de un programa Cobol.

Desde esta primera pantalla de CECI, seleccionando cualquiera de las funciones listadas, podríamos realizar la ejecución de la instrucción CICS que deseemos.Y, lo que es más importante, dicha ejecución daría exactamente el mismo resultado que si lanzásemos la operación desde un programa Cobol.

A continuación examinaremos dos ejemplos de cómo se trabajaría con CECI. En primer lugar veremos cómo se mostraría un Mapset por el terminal si lanzásemos el comando SEND mediante la transacción CECI. Para ello, seleccionaremos el mapa JJ0005M.

Mostrar un Mapa mediante CECI

1º) En primer lugar tendríamos que introducir SEND en la línea de comandos.



2º) A continuación se nos mostraría una pantalla en la que tendríamos que seleccionar alguna de las opciones disponibles: CONTROL, MAP, PAGE, PARTNSET o TEXT.



En nuestro caso, como el objetivo es mostrar un mapa, recurriremos a la opción MAP. Por tanto, en la línea de comandos tendremos que añadir MAP a continuación de la función SEND.

SEND MAP

3º) Ahora pasaremos a una pantalla en la que se nos mostrarán todas las opciones disponibles para enviar un mapa al terminal CICS. En realidad, son todas las cláusulas que podrían acompañar a la sentencia SEND MAP cuando la codificamos en un programa Cobol.



Como vemos, aparecen las cláusulas FROM, LENGTH, DATAONLY, MAPSET, CURSOR, ERASE, etc... No debemos sentirnos intimidados por la gran cantidad de campos que aparecen en esta pantalla, en realidad no hace falta rellenarlos todos. Al igual que haríamos desde Cobol, sólo especificaremos aquella información que deseamos que acompañe al envío del Mapset.

Ahora, para el ejemplo en curso, nosotros sólo vamos a indicar el nombre del mapa. Para ello, incluiremos el literal (JJ0004M) tras la sentencia SEND MAP.

SEND MAP (JJ0004M)

4º) Finalmente, se nos mostrará el mapa indicado (JJ0004M, en nuestro caso). Como no hemos especificado ninguna información en la cláusula FROM, en la pantalla nos aparece un asterisco (*) en los campos que podrían mostrar algún dato (EQUIPO, N+PTOS, GOLES FAVOR y GOLES CONTRA).



El próximo día continuaremos repasando, tal y como habíamos prometido, otro ejemplo de cómo se trabajaría con CECI para realizar la creación de una Cola TS (Temporary Storage). Como veremos, al final todo se resume en aplicar una serie de pasos estándar en los que vamos seleccionando las opciones deseadas y rellenando las cláusulas opcionales que deben acompañar al comando CICS.

Y eso es todo. Ya sólo nos queda convocaros a la segunda parte del post, donde procuraremos que quede totalmente definida la forma de trabajo de la herramienta CECI.

Saludos.