Desarrollando en Cobol y Natural sobre Plataforma Mainframe

viernes, 26 de diciembre de 2014

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.

jueves, 18 de diciembre de 2014

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.

jueves, 11 de diciembre de 2014

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.

jueves, 4 de diciembre de 2014

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.

jueves, 27 de noviembre de 2014

Transacciones básicas del entorno CICS

La primera vez que comenzamos a trabajar en un entorno on-line CICS no tardamos en damos cuenta de que existen multitud de transacciones que podemos emplear para realizar tareas muy diversas. Aunque es muy complicado llegar a conocer todas las opciones disponibles, hay una serie de transacciones básicas que nos servirán para poder movernos con cierta soltura.

Una vez que hemos entrado en un terminal CICS, nos encontramos ante una pantalla en la que se pueden introducir infinidad de transacciones de 4 letras (o números). Si bien es cierto que cuantas más de ellas conozcamos mayor será nuestra destreza, también es verdad que en realidad hay un número reducido de transacciones que nos bastarán para realizar la mayoría de las tareas precisadas.



La lista de las transacciones más importantes es la siguiente. Hay que tener en cuenta que no se trata de una lista exhaustiva, sino de un resumen de las que consideramos más relevantes.

1º) Transacción CESN: Esta transacción es la más básica de todas, ya que sirve para hacer Log On en el terminal y abrir una nueva sesión en nuestro CICS.

2º)  Transacción CESF: De manera análoga a la anterior, esta transacción sirve para hacer un Log Off y desconectar la sesión que tengamos abierta en el CICS.

3º) Transacción CEOT: Lanzando esta transacción se nos mostrará una pantalla informativa en la que podremos ver cuál es el código de Terminal asociado a nuestra sesión.

4º) Transacción CECI: Se trata de una transacción especial que nos permitirá acceder a todo el API del CICS. De esa manera, con ella podremos ejecutar cualquiera de los comandos existentes en CICS (por ejemplo, SEND, READ o RETURN), del mismo modo que si los estuviésemos ejecutando desde un programa Cobol.



5º) Transacción CMAC: Esta transacción permite visualizar una explicación detallada asociada a los mensajes y códigos de error CICS. Para ello, basta con introducir el código correspondiente.

6º) Transacción CEDA: Sirve para definir la infraestructura de los recursos (programas, mapas, ficheros, colas, terminales o transacciones) que van a estar asociados a nuestra aplicación en el CICS. Esta información queda almacenada en el fichero CSD (CICS System Definition). Adicionalmente, con CEDA también podemos realizar la instalación de los recursos, momento en el que la información de la infraestructura se enviará desde el fichero CSD hasta la memoria del CICS (esto es, al CICS Transaction Server).

Todo este proceso es de gestión administrativa y, por tanto, no implica que realmente existan los objetos asociados a los recursos definidos. Esto último corresponde a la parte de gestión operativa y se realizará mediante la transacción CEMT.

7º) Transacción CEMT (Master Terminal): Esta importante transacción permite acceder a la información operativa de los recursos de la infraestructura. También sirve para ejecutar la función Newcopy sobre los objetos de nuestra aplicación (programas on-line o mapas). Lo que hace dicha función es tomar la compilación de nuestro objeto y enviarla a la memoria del CICS. De esta forma, el objeto quedará disponible de forma operativa para ser invocado por la transacción CICS que deseemos asociarle.

Hay que tener en cuenta que, antes de hacer el Newcopy, previamente el objeto habrá tenido que ser instalado administrativamente mediante la transacción CEDA.



8º) Transacción CEDF: Se trata de una herramienta de depuración. En el caso de que tengamos algún error en la ejecución de la transacción de nuestra aplicación, con esta opción podremos realizar un Debug de la misma. Al lanzar la aplicación, CEDF realizará una simulación controlada de la ejecución, mostrándonos en todo momento el contenido de las variables activas y la parte del código CICS que se está ejecutando.

9º) Transacción CEBR: Esta transacción sirve para visualizar el contenido de las Colas TS (Temporary Storage) y de las Colas TD (Transient Data).

10º) Transacción CMSG: Permite el envío de mensajes a través del CICS. Hay que especificar el código de terminal en el que deseamos que se visualice el texto.

Básicamente, estas son las transacciones con las que nos tendremos que pelear más comúnmente. Por supuesto, hay muchas más aparte de estas, pero si conocemos el funcionamiento de las indicadas anteriormente lo más probable es que podamos capear cualquier problema con el que nos encontremos en el CICS.



Hay que tener en cuenta que el entorno on-line CICS es bastante diferente de lo que hoy en día se conocen como aplicaciones on-line interactivas (implementadas en Java, Visual Basic, C++, etc...). Por tanto, lo importante es tener paciencia para ir conociendo poco a poco las transacciones CICS e ir adaptándonos al peculiar funcionamiento de los procesos on-line pseudo-conversacionales de Cobol CICS DB2.

Y eso es todo lo que queríamos ver por hoy. Esperamos que lo comentado en el post os sirva para tener una visión global de las transacciones (básicas) que hay que conocer para sobrevivir en el mundo CICS.

Saludos.

jueves, 20 de noviembre de 2014

Modificar contenido de un fichero VSAM desde ISPF

Hace unas semanas comenzamos a explicar cómo se podía acceder al contenido de un fichero VSAM desde el ISPF, teniendo en cuenta que la opción 3.4 no permite trabajar con ellos. Hoy detallaremos cómo se pueden modificar los registros VSAM desde esa misma herramienta.

En un post anterior estuvimos viendo cómo se podía examinar el contenido de un fichero VSAM mediante el FILE MANAGER (revisar post Ver contenido de un fichero VSAM desde ISPF). Del mismo modo que hay una forma para visualizar los registros VSAM, también existe un método para modificarlos. Los pasos a seguir serían los siguientes.

Edición del contenido de un fichero VSAM

1º) Seleccionamos la opción 13 - File Manager - File Manager for Z/OS. De este modo, accedemos a las distintas opciones del File Manager ZOS.

13 File Manager  File Manager for Z/OS

2º) A continuación, desde el menú principal del File Manager, seleccionamos la opción 2 - Edit - Edit data. Esto nos permitirá acceder a la ventana de visualización.

2  Edit          Edit data 

3º) En la pantalla de edición tendremos que indicar el nombre del fichero VSAM que deseamos ver, el PDS en el que se encuentran las copys y el nombre de la copy asociada a nuestro fichero (en ella se detallarán los campos de los que se componen los registros del dataset). Como Processing Option elegiremos la número 1 - Above.



4º) Tras pulsar INTRO accedemos a la ventana en la que se nos mostrarán los registros contenidos en el fichero VSAM. Para cada uno de estos registros, se muestra una línea con la información contenida en todos los campos del dataset.



A diferencia del caso de visualización, ahora estamos en modo edición (Edit). Por tanto, podríamos modificar el campo que deseemos de cualquier registro, o incluso añadir un registro adicional con información nueva.

5º) Por ejemplo, vamos a proceder a insertar un registro nuevo. Para ello, nos posicionamos en el registro 000013, insertamos una I al comienzo del mismo y pulsamos INTRO.

000002  1       AT. MADRID           90      77      26
000003  2       BARCELONA            87      100     33
000004  3       REAL MADRID          87      104     38
000005  4       ATH. BILBAO          70      66      39
000006  5       SEVILLA              63      69      52
000007  6       VILLARREAL           59      60      44
000008  7       REAL SOCIEDAD        59      62      55
000009  8       VALENCIA             49      51      53
000010  9       CELTA                49      49      54
000011 10       LEVANTE              48      35      43
000012 11       MALAGA               45      39      46
000013 12       RAYO                 43      46      80
000014                                                 
****** ****  End of data  ****                                                           

De este modo, se añadirá una nueva línea en el editor, la 000014, en la que podremos ir incluyendo el contenido deseado del nuevo registro.

6º) A continuación, rellenamos todos los campos del registro con los datos correspondientes. La nueva información que vayamos añadiendo se mostrará con un color diferente al del resto, indicándonos que se trata de campos aún no consolidados en el fichero VSAM.



7º) Introducimos SAVE en la línea de comandos y pulsamos INTRO. De esta forma, el nuevo registro que habíamos introducido en el editor quedará verdaderamente dado de alta en el fichero VSAM. Por contra, si hubiésemos introducido el comando CANCEL, entonces la información modificada en el editor no se consolidaría y nunca llegaría a actualizarse en el VSAM.

Command ===> SAVE

8º) Finalmente, podremos ir a la opción de visualización del File Manager y comprobar si el registro creado realmente aparece en la consulta.



Como podemos ver en la imagen, el nuevo registro añadido aparece correctamente en la visualización (000014 13       GETAFE               42      35      54      38). Por tanto, así queda confirmado que la inserción de registro VSAM se completó sin problemas.

Como se puede observar en todo lo anteriormente comentado, la modificación de registros de ficheros VSAM es un proceso bastante sencillo. Hay que tener en cuenta que los VSAM no se pueden visualizar mediante la opción 3.4 del ISPF y, por tanto, la elección del FILE MANAGER para este tipo de trabajos es la elección más sensata.

Y eso es todo por lo que respecta al File Manager. Esperamos que todos los puntos hayan quedado aclarados y si os queda alguna duda, como siempre, enviádnosla y trataremos de resolverla lo antes posible.

Saludos.

jueves, 13 de noviembre de 2014

Ver contenido de un fichero VSAM desde ISPF

Los ficheros VSAM no pueden ser visualizados con un Browse del mismo modo que hacemos con un fichero secuencial o con un PDS. Afortunadamente, en el ISPF disponemos de una opción que nos permitirá acceder fácilmente al interior de los mismos, ya sea simplemente para visualizar su contenido o para modificar alguno de sus registros.

En el menú principal POM del ISPF (Primary Option Menu) hay disponible una opción, denominada FILE MANAGER, que nos permite realizar distintas acciones sobre los ficheros VSAM. Entre estas operaciones, disponemos de la visualización y la edición del contenido de los registros del dataset.



Para ver cómo se puede realizar la visualizacion y la edición del VSAM, vamos a suponer que nos encontramos en el menú POM del ISPF.

Visualización del contenido de un fichero VSAM

1º) Seleccionamos la opción 13 - File Manager - File Manager for Z/OS. De este modo, accedemos a las distintas opciones del File Manager ZOS.

13 File Manager  File Manager for Z/OS

2º) A continuación, desde el menú principal del File Manager, seleccionamos la opción 1 - View - View data. Esto nos permitirá acceder a la ventana de visualización.

1  View          View data

3º) En la pantalla de visualización tendremos que indicar el nombre del fichero VSAM que deseamos ver, el PDS en el que se encuentran las copys y el nombre de la copy asociada a nuestro fichero (en ella se detallarán los campos de los que se componen los registros del dataset). Como Processing Option elegiremos la número 1 - Above.



4º) Finalmente, accedemos a la ventana en la que se nos mostrarán los registros contenidos en el fichero VSAM. Recordemos que estamos en modo visualización y, por tanto, no se puede modificar nada de la información mostrada.



Tal y como podemos ver en la imagen, esta opción nos muestra los datos almacenados en todos los campos de cada uno de los registros que hay dados de alta en el VSAM.

Esta es una forma muy sencilla de visualizar el contenido de los ficheros VSAM. Teniendo en cuenta que este tipo de ficheros no se puede abrir mediante la opción 3.4 del ISPF (como hacemos normalmente con un dataset secuencial), el FILE MANAGER nos ofrece una cómoda alternativa para solucionar esta deficiencia.

Pues nada, esperamos que con esto os haya quedado clara la forma en la que podemos acceder al detalle de los ficheros VSAM desde el propio ISPF.

Saludos.

jueves, 6 de noviembre de 2014

Modificar contenido de una tabla DB2 desde ISPF

Hace unas semanas comenzamos a explicar cómo se podía acceder al contenido de una tabla DB2 desde el ISPF, sin tener que recurrir al SPUFI o al QMF. Hoy detallaremos cómo se pueden modificar los registros DB2 desde esa misma opción.

En un post anterior estuvimos viendo cómo se podía examinar el contenido de una tabla DB2 mediante el FILE MANAGER DB2 (ver post Visualizar contenido de una tabla DB2 desde ISPF). Del mismo modo que hay una forma para visualizar los registros del DB2, también existe un método para modificarlos. Los pasos a seguir serían los siguientes.



Edición del contenido de una tabla DB2

1º) Seleccionamos la opción 14 - File Mgr / DB2 - File Manager for DB2. De este modo, accedemos a las distintas opciones del File Manager DB2.

14 File Mgr/DB2  File Manager for DB2

2º) A continuación, desde el menú principal del File Manager DB2, seleccionamos la opción 2 - Edit - Edit DB2 Object. Esto nos permitirá acceder a la ventana de visualización.

2  Edit          Edit DB2 object 

3º) En la pantalla de edición tendremos que indicar el Owner y el nombre de la tabla DB2 que deseamos ver. Como Processing Option elegiremos la número 3 - Generate from table.



4º) Tras pulsar INTRO accedemos a la ventana en la que se nos mostrarán los registros contenidos en la tabla DB2. Para cada uno de estos registros, se muestra una línea con la información contenida en todos sus campos.



A diferencia del caso de visualización, ahora estamos en modo edición (Table Edit). Por tanto, podríamos modificar el campo que deseemos de cualquier registro, o incluso añadir un registro adicional con información nueva.

5º) Por ejemplo, vamos a proceder a insertar un registro nuevo. Para ello, nos posicionamos en el registro 000010, insertamos una 'I' (INSERT) al comienzo del mismo y pulsamos INTRO.

****** ****  Top of data  ****                                   
000001 0000000001 TOLKIEN              EL SEÑOR DE LOS ANILLOS   
000002 0000000002 TOLKIEN              EL HOBBIT                 
000003 0000000003 KING                 LA TORRE OSCURA           
000004 0000000004 KING                 IT                        
000005 0000000005 WEISS                EL RETORNO DE LOS DRAGONES
000006 0000000006 BECQUER              LEYENDAS                  
000007 0000000007 ASIMOV               FUNDACION                 
000008 0000000008 ASIMOV               YO, ROBOT                 
000009 0000000009 LUCA DE TENA         LOS RENGLONES TORCIDOS DE D
000010 0000000010 MALKIEL              UN PASEO ALEATORIO POR WALL
000011                                                           
****** ****  End of data  ****                                           
                                  
De este modo, se añadirá una nueva línea en el editor, la 000011, en la que podremos ir incluyendo el contenido deseado del nuevo registro.

6º) A continuación, rellenamos todos los campos del registro con los datos correspondientes. La nueva información que vayamos añadiendo se mostrará con un color diferente al del resto, indicándonos que se trata de campos aún no consolidados en la tabla DB2.



7º) Introducimos SAVE en la línea de comandos y pulsamos INTRO. De esta forma, el nuevo registro que habíamos introducido en el editor quedará verdaderamente dado de alta en la tabla DB2. Por contra, si hubiésemos introducido el comando CANCEL, entonces la información modificada en el editor no se consolidaría y nunca llegaría a actualizarse en el DB2.

Command ===> SAVE

8º) Finalmente, podremos ir a la opción de visualización del File Manager DB2 y comprobar si el registro creado realmente aparece en la consulta.



Como podemos ver en la imagen, el nuevo registro añadido en el ejemplo aparece correctamente en la visualización (000011 0000000011 KOONTZ               VICTIMAS). Por tanto, así queda confirmado que la inserción del registro DB2 se completó sin problemas.

Como se puede observar en todo lo anteriormente comentado, la modificación de registros de tablas DB2 mediante el FILE MANAGER DB2 es un proceso bastante sencillo. Por tanto, es lógico que muchos programadores prefieran este sistema de trabajo frente al uso de las herramientas SPUFI o QMF. A partir de ahora, la decisión de usar una u otra es vuestra.

Y eso es todo por lo que respecta al File Manager DB2. Esperamos que todos los puntos hayan quedado aclarados y si os queda alguna duda, como siempre, enviádnosla y trataremos de resolverla lo antes posible.

Saludos.

domingo, 2 de noviembre de 2014

Universo Cobol alcanza las 10.000 visitas

Esta semana hemos alcanzado el hito de las 10.000 visitas en nuestro blog de Cobol. Aún es una cifra muy pequeña, pero hay que tener en cuenta que todavía estamos en el primer año de vida. Los comienzos son duros, pero esperamos que este sea el inicio del camino hacia las 100.000 visitas...



Simplemente queríamos agradeceros a todos el haber contribuido con vuestro granito de arena a que actualmente podamos ver las 5 cifras en el blog. ¡Gracias!

Saludos.

jueves, 30 de octubre de 2014

Visualizar contenido de una tabla DB2 desde ISPF

Para aquellos a los que no les resulte del todo cómodo usar las herramientas SPUFI o QMF para acceder al contenido de las tablas DB2, existe una forma mucho más sencilla de visualizar o modificar el contenido de las mismas desde una opción del ISPF.

En el menú principal POM del ISPF (Primary Option Menu) hay disponible una opción, denominada FILE MANAGER DB2, que nos permite realizar distintas acciones sobre las tablas DB2. Entre estas operaciones, disponemos de la visualización y la edición del contenido de los registros de la tabla.



Para ver cómo se puede realizar la visualizacion del DB2, vamos a suponer que nos encontramos en el menú POM del ISPF.

Visualización del contenido de una tabla DB2

1º) Seleccionamos la opción 14 - File Mgr / DB2 - File Manager for DB2. De este modo, accedemos a las distintas opciones del File Manager DB2.

14 File Mgr/DB2  File Manager for DB2

2º) A continuación, desde el menú principal del File Manager DB2, seleccionamos la opción 1 - View - View DB2 Object. Esto nos permitirá acceder a la ventana de visualización.

1  View          View DB2 object

3º) En la pantalla de visualización tendremos que indicar el Owner y el nombre de la tabla DB2 que deseamos ver. Como Processing Option elegiremos la número 3 - Generate from table.



4º) Finalmente, accedemos a la ventana en la que se nos mostrarán los registros contenidos en la tabla DB2. Recordemos que estamos en modo visualización y, por tanto, no se puede modificar nada de la información mostrada.



Tal y como podemos ver en la imagen, esta opción nos muestra los datos almacenados en todos los campos de cada uno de los registros que hay dados de alta en el DB2.

Esta es una forma muy sencilla de visualizar el contenido de las tablas DB2. Por supuesto, ya sabemos que disponemos de las herramientas SPUFI o QMF para realizar esta acción pero, tal y como hemos podido observar, el FILE MANAGER DB2 también nos ofrece una cómoda alternativa de acceso a DB2.

Pues nada, esperamos que con esto os haya quedado clara la forma en la que podemos acceder al detalle de las tablas DB2 desde el propio ISPF.

Saludos.

jueves, 23 de octubre de 2014

Herramienta DCLGEN para generar Includes de DB2 (y 2)

Hace unas semanas comenzamos a ver cuáles eran los pasos a seguir para generar objetos DCL mediante la Herramienta DCLGEN (ver post Herramienta DCLGEN para generar Includes de Ficheros - 1). Hoy trataremos de ver qué es lo que tenemos que hacer para utilizar dichos objetos desde nuestros programas Cobol.

Tal y como estuvimos viendo, siguiendo el procedimiento indicado, la herramienta DCLGEN nos generaba un objeto en una librería de nuestra elección. Al final del anterior post llegamos a mostrar un ejemplo de cómo era el contenido de un objeto DCL que habíamos generado con el nombre SEQUIPOS.



Como se podía observar en dicho ejemplo, el código de un objeto DCL está dividido en 3 partes:

A) Estructura de la Tabla DB2. En esta primera parte nos aparece el nombre de la tabla DB2  y de las columnas que la componen. Estos son los nombres de columna que tendremos que usar en las sentencias SQL que usemos en nuestro programa Cobol.

B) Estructura de Variable Host. En esta segunda parte nos aparece la definición de todas las variables Host que podríamos utilizar en el programa Cobol. Básicamente, el DCLGEN habrá creado una variable Host equivalente a cada una de las columnas de la tabla DB2. La idea es que podamos usar cada una de estas variables de la agrupación DCLEQUIPOS para recoger la información de la columna de nombre análogo de la tabla DB2.

C) Estructura de Variables Indicador. En la tercera y última parte se habrán creado las Variables de Indicador Nulo asociadas a cada una de las variables Host que lo requieran. Se da de alta un array INDSTRUC cuyo tamaño será igual al número de columnas de la tabla DB2 (en el ejemplo, se crea un INDSTRUC de 5 ocurrencias debido a que la tabla EQUIPOS tiene 5 columnas).

Para que toda la estructura de datos creada está disponible desde Cobol, en el programa tendremos que incluir la correspondiente sentencia INCLUDE haciendo referencia al objeto DCL. En nuestro ejemplo, en la WORKING-STORAGE SECTION tendríamos que incluir tanto las del área de comunicaciones estándar SQLCA como las de nuestro objeto SEQUIPOS.

* INCLUDES DE LOS OBJETOS DCL
EXEC SQL      
  INCLUDE SQLCA
END-EXEC.

*      
EXEC SQL      
  INCLUDE SEQUIPOS
END-EXEC.     


Con la definición anterior, un ejemplo de cómo se codificaría, en un programa Cobol, una declaración SELECT contra la tabla EQUIPOS empleando el objeto DCL sería la siguiente. En primer lugar, ponemos la definición del Cursor de la tabla (que estaría en la WORKING-STORAGE SECTION) y, a continuación, la sentencia FETCH que carga la información en las variables Host (ubicada en la PROCEDURE DIVISION).

* CURSOR PARA POSICIONARSE EN LA TABLA EQUIPOS
EXEC SQL DECLARE EQUIPOS-C CURSOR FOR
  SELECT *                        
  FROM   EQUIPOS                    
  WHERE EQUINO = :ENO              
  ORDER BY EQUINAME               
END-EXEC.                           


...
...
...

* OBTENCION DE COLUMNAS DE REGISTRO DE LA TABLA EQUIPOS
EXEC SQL                       
         FETCH EQUIPOS-C        
         INTO                  
         :EQUINO,           
         :EQUINAME,           
         :ENTNO, 
         :EMPREQUI,              
         :CITYNAME
END-EXEC.
                       

Como vemos, en el FETCH se está haciendo referencia a las variables Host que aparecen en el objeto DCL definidas bajo la agrupación DCLEQUIPOS (en el DECLARE CURSOR que aparece justo encima, por contra, se hace referencia a los nombres de las columnas de la tabla DB2). Una vez recuperadas, ahora ya podremos trabajar normalmente con estas variables Host en el código de nuestro programa Cobol. Por ejemplo, podríamos hacer un DISPLAY así.

DISPLAY EQUINO EQUINAME ENTNO EMPREQUI CITYNAME

Como se puede observar, el empleo de la herramienta DCLGEN nos ahorra mucho trabajo a la hora de definir, en nuestros programas Cobol, las estructuras de las tablas DB2 y las estructuras de sus variables Host asociadas. Esto mismo se podría declarar de forma manual, pero es indudable que haciéndolo mediante la herramienta nos ahorraremos quebraderos de cabeza.

Siguiendo los pasos que se han ido indicando en el post, no deberíamos tener ningún problema con la generación de los objetos DCL a través de la herramienta DCLGEN. Quizás os parezca un poco complicado la primera vez, pero os podemos asegurar que enseguida dominaréis el procedimiento y que agradeceréis el tiempo economizado.

En principio, con todo lo comentado, por nuestra parte quedaría completado el tema de la herramienta DCLGEN. De todas formas, no dudéis en consultarnos cualquier duda que os surja respecto a ella, si lo consideráis oportuno.

Saludos.

jueves, 16 de octubre de 2014

Herramienta DCLGEN para generar Includes de DB2 (1)

Cuando estamos implementando un programa Cobol con acceso a DB2, una de las cosas que tenemos que incluir en el mismo es la declaración de las tablas DB2, junto con todos los campos que las componen, y la declaración de las variables auxiliares que vamos a emplear para recoger los registros de dichas tablas. El DCLGEN nos permitirá crear de forma automática toda esta estructura de datos.

La herramienta DCLGEN sirve para realizar la generación de objetos DCL. El DCL (Data Control Language) es la parte del lenguaje SQL destinada al control de los datos. Así que, dicho de otro modo, el DCLGEN nos permite realizar la generación de la parte del código SQL que contiene las variables necesarias para el tratamiento de las tablas DB2 desde los programas Cobol.

Obviamente, estas sentencias DCL también se podrían generar manualmente, pero siempre será más cómodo realizar la tarea mediante un generador automático como el DCLGEN. Una vez hayamos aprendido cómo se opera con él, lo más probable es que nunca dejemos de usarlo.



Los pasos a seguir para realizar la generación de un objeto con código DCL son los siguientes, suponiendo que nos encontramos en el menú principal POM (Primary Option Menu) del ISPF.

1º) Seleccionamos la opción 12 - Subsystems - DB/DC Subsystems. Se nos abrirá una ventana mostrando las diversas opciones disponibles.

12 Subsystems    DB/DC Subsystems 

2º) Opción D - DB2I: Seleccionamos la opción D - DB2I - Interactive Database 2. Así entraremos en el menú principal (POM) de la herramienta DB2I.

D  DB2I      Interactive Database 2   

3º) Opción 2 - DCLGEN: Seleccionamos la opción 2 - DCLGEN - Generate SQL and source language declarations.

2  DCLGEN      (Generate SQL and source language declarations)

4º) En el panel DCLGEN tendremos que introducir los parámetros requeridos para la generación del objeto DCL.

- SOURCE TABLE NAME: Aquí tendremos que introducir el nombre de la tabla para la cual deseamos que se genere su objeto DCL asociado. Por ejemplo, nosotros especificamos la tabla EQUIPOS.

1  SOURCE TABLE NAME ===> EQUIPOS

- TABLE OWNER: Aquí habrá que especificar el nombre del usuario propietario de la tabla.

2  TABLE OWNER ..... ===> SYSTEM1

- DATA SET NAME: En este campo se debe especificar el nombre (y la ubicación) del objeto DCL que va a generar la herramienta DCLGEN. Por ejemplo, nosotros queremos un objeto llamado SEQUIPOS que deberá crearse en la librería JJ00.FACTURAS.DCLGEN.DATA.

4  DATA SET NAME ... ===> 'JJ00.FACTURAS.DCLGEN.DATA(SEQUIPOS)'

- ACTION: Se provisionará el comando ADD si vamos a generar un nuevo objeto DCL o el comando REPLACE si se va a cambiar la estructura de un objeto ya existente.

6  ACTION .......... ===> REPLACE 

- INDICATOR VARS: Si queremos que nuestro objeto DCL incluya la declaración de las Variables de Indicador Nulo para los campos de la tabla que lo requieran, entonces tendremos que indicar YES en este parámetro.

12  INDICATOR VARS .. ===> YES

5º) Tras especificar todos los parámetros anteriores y pulsar INTRO, nos aparecerá un mensaje indicando que la generación se ha llevado a cabo correctamente.

DSNE904I EXECUTION COMPLETE, MEMBER SEQUIPOS REPLACED
***
  
                                               

A continuación, iríamos a la librería especificada en DATA SET NAME (en nuestro ejemplo, la JJ00.FACTURAS.DCLGEN.DATA) y podríamos verificar la existencia del nuevo objeto DCL generado.

Si nos asomamos al interior del objeto, veremos que su contenido tendrá un aspecto similar al siguiente:

******************************************************************
* DCLGEN TABLE(SYSTEM1.EQUIPOS)                                  *
*        LIBRARY(JJ00.FACTURAS.DCLGEN.DATA(SEQUIPOS))            *
*        LANGUAGE(COBOL)                                         *
*        QUOTE                                                   *
*        INDVAR(YES)                                             *
* ... IS THE DCLGEN COMMAND THAT MADE THE FOLLOWING STATEMENTS   *
******************************************************************
     EXEC SQL DECLARE EQUIPOS TABLE                     
     ( EQUINO                         CHAR(3) NOT NULL,          
       EQUINAME                       VARCHAR(36) NOT NULL,      
       ENTNO                          CHAR(6),                   
       EMPREQUI                       CHAR(3) NOT NULL,          
       CITYNAME                       VARCHAR(16)                
     ) END-EXEC.                                                 
******************************************************************
* COBOL DECLARATION FOR TABLE SYSTEM1.EQUIPOS                    *
******************************************************************
 01  DCLEQUIPOS.                                                

     10 EQUINO               PIC X(3).                           
     10 EQUINAME.                                                
        49 EQUINAME-LEN      PIC S9(4) USAGE COMP.               
        49 EQUINAME-TEXT     PIC X(36).                          
     10 ENTNO                PIC X(6).                           
     10 EMPREQUI             PIC X(3).                           
     10 CITYNAME.                                                
        49 CITYNAME-LEN      PIC S9(4) USAGE COMP.               
        49 CITYNAME-TEXT     PIC X(16).                          
******************************************************************
* INDICATOR VARIABLE STRUCTURE                                   *
******************************************************************
 01  IEQUIPOS.                                                  
     10 INDSTRUC           PIC S9(4) USAGE COMP OCCURS 5 TIMES.  
******************************************************************
* THE NUMBER OF COLUMNS DESCRIBED BY THIS DECLARATION IS 5       *
******************************************************************


El próximo día seguiremos viendo el procedimiento que hay que seguir para poder hacer uso del contenido del objeto DCL desde el programa Cobol en el que vamos a operar con el fichero DB2. Recordemos que, al fin y al cabo, la finalidad del DCL es que nos facilite el intercambio de información entre el entorno SQL DB2 y el entorno Host Cobol.

Dicho esto, ya sólo nos queda emplazaros a la segunda parte del post, donde terminaremos de ver la forma en que debe utilizarse la herramienta DCLGEN. Disfrutad del Cobol mientras tanto.

Saludos.

jueves, 9 de octubre de 2014

Estructura básica de un programa Cobol (y 2)

Hace algunas semanas comenzamos a repasar la configuración estándar de un programa Cobol (ver post Estructura básica de un programa Cobol - 1). Aunque vimos unas cuantas secciones del código, nos quedaron pendientes otras tantas para completar la revisión de la estructura.

Recordemos que un programa Cobol está organizado en 4 Divisiones principales. De ellas, en la primera parte del post vimos la "Identification Division" y la "Environment Division". A continuación, completaremos la revisión de la estructura viendo las secciones y párrafos de las dos Divisiones restantes.

 

3º) DATA DIVISION

Esta División es, quizás, la más compleja de la programación Cobol, ya que se compone de varias secciones que no resultan del todo intuitivas para los programadores de otros lenguajes más modernos.

DATA DIVISION

A) FILE SECTION

Aquí se definirá la estructura de los ficheros especificados en la INPUT-OUTPUT-SECTION y también habrá que detallar los campos en los que se desglosan los registros asociados a cada uno de dichos ficheros.

   FILE SECTION
      ...
      FICHERO
         REGISTRO
      ... 

B) WORKING-STORAGE SECTION

Aquí deben definirse todas las variables que van a usarse en la lógica procedimental del programa. Se incluyen tanto las variables estándar como las variables auxiliares que se emplearán para trabajar con la información descargada de los ficheros.

   WORKING-STORATE SECTION
      ...
      VARIABLE
      ...

C) LINKAGE SECTION

Aquí se deberán indicar los parámetros (variables) con los que debe invocarse nuestro fuente si es llamado desde otro objeto. Lógicamente, esta sección sólo se usará si estamos codificando un subprograma que debe ser invocado, mediante unos parámetros determinados, por otros objetos de la aplicación.

   LINKAGE SECTION
      ...
      PARAMETRO
      ... 

4º) PROCEDURE DIVISION

Finalmente llegamos a la última División de la estructura de un programa Cobol. En ella tendremos que definir las secciones y párrafos (esto es, las subrutinas) en las que queramos dividir nuestro objeto y, en cada una de ellas, se deberán incluir las sentencias (esto es, las instrucciones) requeridas para la correcta implementación del algoritmo de nuestro programa.

Por supuesto, en la DATA DIVISION tienen que estar definidas todas las variables con las que vayamos a operar en la PROCEDURE DIVISION.

PROCEDURE DIVISION
   ...
   SECCION
      PARRAFO
         SENTENCIA
   ...

Obviamente, la elaboración de un programa Cobol tiene más complejidad que la detallada a lo largo de todo el artículo. Sin embargo, esta estructura básica nos puede servir de guía cuando realicemos la creación de nuestros primeros objetos Cobol. Y esa era la idea del post, servir de ayuda a los programadores novatos.

Como hemos dicho al principio, no hay que desanimarse por la aparente rigidez del Cobol. Todos los lenguales tienen sus particularidades y eso puede hacer que, al principio, nos parezca extraña la forma en que se realiza el tratamiento de algunas cosas. Sin embargo, con un poco de tiempo y de práctica, seremos capaces de adaptarnos al nuevo entorno y codificar nuestros programas con fluidez.

Y nada más. Esperamos que el post os sea de ayuda, sobre todo a los que nos habéis escrito pidiendo esta información enfocada para los programadores menos avanzados.

Saludos.

jueves, 2 de octubre de 2014

Estructura básica de un programa Cobol (1)

Hoy vamos a tratar un tema muy básico de nuestro lenguaje pero para el que, sin embargo, hemos recibido varias cuestiones de lectores principiantes en el mundo Cobol. Se trata de identificar cuáles son todos los apartados que debe incorporar un programa Cobol estándar.

Al principio, si no estamos acostumbrados a trabajar con Cobol, nos puede parecer un poco rígida la forma en que se estructuran los programas en este lenguaje. Sin embargo, una vez vayamos ampliando nuestra experiencia, nos daremos cuenta de que la cosa es tan sencilla como pueda serlo en cualquier otro lenguaje de programación.



Un programa Cobol está estructurado en una serie de Divisiones, Secciones y Párrafos en los que hay que ir declarando la información que corresponda a cada una de ellas. La estructura general sería la siguiente:

IDENTIFICATION DIVISION
   PROGRAM-ID
   AUTHOR
   INSTALLATION
   DATE-WRITTEN
   DATE-COMPILED
   SECURITY

ENVIRONMENT DIVISION

   CONFIGURATION SECTION
      SOURCE-COMPUTER
      OBJECT-COMPUTER
      SPECIAL-NAMES

   INPUT-OUTPUT SECTION
      FILE CONTROL
      I-O-CONTROL

DATA DIVISION

   FILE SECTION
      ...
      FICHERO
         REGISTRO
      ...

   WORKING-STORATE SECTION
      ...
      VARIABLE
      ...

   LINKAGE SECTION
      ...
      PARAMETRO
      ...

PROCEDURE DIVISION
   ...
   SECCION
      PARRAFO
         SENTENCIA
   ...

A continuación, comentamos un poco más en detalle en qué consiste cada una de las Divisiones y Secciones enumeradas anteriormente.

1º) IDENTIFICATION DIVISION

Esta División se utiliza para declarar una serie de variables globales asociadas al programa, tales como el nombre del objeto (PROGRAM-ID), el nombre del autor del objeto (AUTHOR), la instalación (INSTALLATION), las fechas de codificación y de compilación (DATE-WRITTEN y DATE- COMPILED) y la seguridad (SECURITY). En general, se trata de datos informativos que no tienen mayor impacto en la codificación posterior del programa.

IDENTIFICATION DIVISION
   PROGRAM-ID
   AUTHOR
   INSTALLATION
   DATE-WRITTEN
   DATE-COMPILED
   SECURITY 

2º) ENVIRONMENT DIVISION

Esta División se compone de dos importantes secciones, CONFIGURATION SECTION e INPUT-OUTPUT-SECTION, cuyo contenido pasamos a detallar a continuación.

ENVIRONMENT DIVISION

A) CONFIGURATION SECTION

Aquí se especifica información relevante para el programa. Por un lado, se debe indicar el nombre de la máquina empleada para la codificación (SOURCE-COMPUTER y OBJECT-COMPUTER). Por otro lado, en el apartado SPECIAL-NAMES hay que detallar las configuraciones especiales que vaya a tener nuestro programa.

Este último apartado tiene su importancia. En general, en Europa se emplea para hacer la declaración DECIMAL POINT IS COMMA, que le indica al compilador que, en nuestro programa, la parte decimal de un número va a ir precedida de una coma (,) y no de un punto (.) como ocurre en EEUU.

   CONFIGURATION SECTION
      SOURCE-COMPUTER
      OBJECT-COMPUTER
      SPECIAL-NAMES 

B) INPUT-OUTPUT SECTION

En esta sección, en el apartado FILE CONTROL hay que especificar el nombre de los ficheros que se tratarán en nuestro fuente. Se indicará la equivalencia entre el nombre lógico que va a tener un determinado fichero en el programa Cobol y el nombre externo que tendrá en el JCL que lo invoque. Este apartado sólo se rellenará si nuestro objeto va a estar insertado en un proceso batch (por contra, no se usará si se va a tratar de un programa CICS on-line).

Adicionalmente, en esta sección aparece también el apartado I-O-CONTROL, que se usará para indicar el área de memoria que va a ser compartida por los ficheros utilizados en el programa. Este segundo apartado es opcional.

   INPUT-OUTPUT SECTION
      FILE CONTROL
      I-O-CONTROL

El próximo día continuaremos revisando las dos últimas Divisiones del programa Cobol, junto con todas las secciones contenidas en ellas. Os adelantamos que hablaremos de la "Data Division" y de la "Procedure Division", aunque ya las revisaremos en detalle en el siguiente post.

Y eso es todo. Ya sólo nos queda emplazaros a la segunda parte para que podamos completar la revisión de todas las Divisiones y secciones de la estructura básica de un programa Cobol.

Saludos.

Related Posts Plugin for WordPress, Blogger...