EXIRION/OS -ETM API- by Rev.Rolando Fernandez Benavidez

ETM 2.0 API For COBOL developers

EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernĂĄndez Benavidez in the MĂŠxico States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 1 ]

NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Nova32 Development Software, if any, with respect to the products described in this document are set forth in such agreement. Nova32 Development Software cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Nova32 Development Software standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses.

INTRODUCCION

El presente documento describe algunas partes fundamentales del API ETM para programadores de lenguaje COBOL en el sistema operativo EXIRION/OS, en esta primera edición se incluyen las llamadas al API consideradas mas importantes para el desarrollo de aplicaciones empresariales, en posteriores ediciones de este documento se detallaran otras funciones de gran utilidad para el desarrollo en COBOL de EXIRION/OS.

Rolando Fernández Benavidez Nova32 Development Software

EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 3 ]

INDICE 1.GESTOR DINÁMICO DE DATOS . . . . . . . . 1.1 VERBOS PARA ANSI SQL . . . . . . . . . 1.1.1 EXEC_SQL . . . . . . . . . . . 1.1.2 EXEC_SQL_SELECT . . . . . . . . 1.2 VERBOS PARA MS SQL . . . . . . . . . . 1.2.1 EXEC_MSQL . . . . . . . . . . . 1.2.2 EXEC_MSQL_SELECT . . . . . . . 1.3 VERBOS Y TRANSACCIONES PARA DEPURACIÓN 1.3.1 WRITE_SPOOL . . . . . . . . . . 1.3.2 CEDX Y CEDF . . . . . . . . . . 1.4 DCLGEN DE EXIRION/OS . . . . . . . . . 1.4.1 MACRO DCLGEN . . . . . . . . . 1.4.2 MACRO JSONDB . . . . . . . . . 1.4.3 MACRO AXONDB . . . . . . . . . 1.4.4 MACRO HTMLDB . . . . . . . . . 1.4.5 MACRO XMLDB . . . . . . . . . 2.ACCESO A MEMORIA TEMPORAL 2.1 COLAS TS . . . . . . . 2.1.1 WRITEQ_TS . . . 2.1.2 READQ_TS . . . . 2.1.3 DELETEQ_TS . . .

. . . . .

. . . . . . . . . . . . . . . .

. 5 . 6 . 6 . 9 .12 .12 .14 .17 .18 .20 .32 .36 .38 .43 .48 .50

. . . . .

51 55 59 62 65

PROGRAMAS . . . . . . . . . . . . . . . . . . . .

. . . . .

67 70 74 77 79

4.COMPILACIÓN DE PROGRAMAS COBOL . 4.1 COMPILACIÓN EN MODO FOREGROUND 4.2 COMPILACIÓN EN MODO BATCH . . . 4.2.1 UTILERIA COBCL64 . . . . 4.2.2 JCL PARA COMPILACIÓN . . 5.ANEXOS . . . . . . . . . . . . . 5.1 TABLA CODIGOS DE ERROR . . . . 5.2 PROGRAMA DE EJEMPLO BRP200 . . 5.3 PROGRAMA DE EJEMPLO BCL215 . .

. . . . . . . . .

81 82 89 92 94 95 95 97 99

3.LLAMADAS DINÁMICAS DE 3.1 CALL DINÁMICO . . 3.1.1 ALLOCATE . . 3.1.2 SEND . . . . 3.1.3 LINK_PROGRAM

. . . . .

. . . . . . . . . . . . . . . .

1.GESTOR DINÁMICO DE DATOS Un sistema de gestión de contenidos (en inglés: Content Management System, más conocido por sus siglas CMS) es un programa informático que permite crear una estructura de soporte (framework) para la creación y administración de contenidos, principalmente en aplicaciones On-Line, por parte de los administradores, editores, participantes y demás usuarios que interactúan con el sistema.

Consiste en una interfaz de bajo nivel, que controla una o varias bases de datos donde se aloja el contenido de las aplicaciones . El sistema CMS permite manejar de manera independiente el contenido de los datos y su vista. Así, es posible manejar el contenido y darle en cualquier momento una vista distinta en cada aplicación sin tener que darle formato al contenido de datos de manera global, además de permitir el fácil y controlado acceso en el sistema operativo EXIRION/OS para todos los usuarios que dispongan de los privilegios suficientes para acceder a la información administrada por el CMS.

El API de ETM en su nueva versión 2.0 de 64-bits, integra un CMS desde el cual se puede acceder a diferentes sistemas de bases de datos como: 1. 2. 3. 4. 5. 6. 7.

Nova32 DMO 3.0 Nova32 DIN 1.0 Nova32 Phoenix 5.0 MySQL 5.5 MariaDB 5.5 Microsoft SQL Server 2005,2008,2012 PostgreSQL

Mediante el uso de los siguientes verbos: EXEC_SQL EXEC_SQL_SELECT EXEC_MSQL EXEC_MSQL_SELECT Los datos obtenidos de consultas pueden ser devueltos en varios formatos soportados por el DCLGEN de EXIRION/OS.

1.1 VERBOS PARA ANSI SQL 1.1.1 EXEC_SQL SQL(por sus siglas en inglés Structured Query Language) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas. Una de sus características es el manejo del álgebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar, de forma sencilla, información de bases de datos, así como hacer cambios en ellas. EXEC_SQL permite acceder al lenguaje de manipulación de datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado. Con EXEC_SQL es posible realizar algunas de las siguientes sentencias de SQL: INSERT INTO DELETE FROM UPDATE SET EXEC <PROCEDURE> En resumen el verbo EXEC_SQL nos permite ejecutar cualquier sentencia de tipo SQL que no devuelva datos, desde programas COBOL. Después de ejecutar su operación EXEC_SQL coloca un código de retorno en el registro especial RETURN-CODE de EXIRION COBOL, para informar alguno de los siguientes estados:

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS.

101

ABEND AL EJECUTAR LA CONSULTA SQL.

EXEC_SQL debe ser llamado desde un CALL dinámico, recordemos que en EXIRION-COBOL los llamados con CALL pueden ser estáticos o dinámicos, y es el compilador quien determina el tipo de llamada, para usar los verbos del gestor dinámico de datos incorporado en EXIRION-COBOL no debe utilizar el llamado dinámico de LINK_PROGRAM, en su lugar debe hacerse con un simple CALL y sera el compilador quien determine que es una llamada dinámica. Command Syntax: '–WS-QUERY-C-' '–WS-QUERY-B-' '–WS-QUERY-A-' >>-EXEC_SQL-----+------------+------------><

Command Options: WS-QUERY Contiene la sentencia SQL a ejecutar en la base de datos, es una variable de trabajo declarada en la WORKING-STORAGE SECTION.

Implementación en COBOL: CALL “EXEC_SQL” USING BY CONTENT WS-QUERY.

1.1.2 EXEC_SQL_SELECT EXEC_SQL_SELECT también permite acceder al lenguaje de manipulación de datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado. Con EXEC_SQL_SELECT es posible realizar algunas de las siguientes sentencias de SQL: SELECT * FROM SHOW DATABASES SHOW TABLES DESCRIBE <TABLE> EXEC <PROCEDURE> En resumen el verbo EXEC_SQL_SELECT nos permite ejecutar cualquier sentencia de tipo SQL que si devuelva datos, desde programas COBOL. Los datos obtenidos como resultado de una sentencia que incluya SELECT serán depositados en la variable de trabajo WS-RECORDSET que sea definida en la WORKING-STORAGE SECTION y pasada como argumento por referencia a EXEC_SQL_SELECT. Después de ejecutar su operación EXEC_SQL_SELECT coloca un código de retorno en el registro especial RETURN-CODE de EXIRION COBOL, para informar alguno de los siguientes estados:

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS.

101

ABEND AL EJECUTAR LA CONSULTA SQL.

102

ABEND AL EJECUTAR EL CÓDIGO DCLGEN, COMANDO NO VALIDO O MACROS NO EXISTE.

103

ABEND AL LEER EL PROGRAMA DCLGEN, DATA SET DAÑADO O NO EXISTE.

EXEC_SQL_SELECT debe ser llamado desde un CALL dinámico, recordemos que en EXIRION-COBOL los llamados con CALL pueden ser estáticos o dinámicos, y es el compilador quien determina el tipo de llamada, para usar los verbos del gestor dinámico de datos incorporado en EXIRION-COBOL no debe utilizar el llamado dinámico de LINK_PROGRAM, en su lugar debe hacerse con un simple CALL y sera el compilador quien determine que es una llamada dinámica.

Command Syntax:

'–WS-QUERY-C-' '–WS-QUERY-B-' '–WS-QUERY-A-' >>-EXEC_SQL_SELECT-----+------------+-----+---------+-----> '-DCLGEN1-' '-DCLGEN2-' '-DCLGEN3-'

'-RECORD-SET-' >----------+------------+----------><

Command Options: WS-QUERY Contiene la sentencia SQL ejecutar en la base de datos, contenido en una variable de trabajo de la WORKING-STORAGE.

DCLGEN Contiene el include de los datos a recibir de la base de datos, contenido en una variable de trabajo de la WORKING-STORAGE. RECORD-SET Es una variable de trabajo con suficiente tamaño en bytes para almacenar los datos devueltos por la consulta, generalmente producida por una sentencia SELECT. Implementación en COBOL: CALL “EXEC_SQL_SELECT” USING BY CONTENT WS-QUERY, BY CONTENT WS-DCLGEN, BY REFERENCE WS-RECORDSET.

Advertencias: El Query SQL debe estar almacenado en una variable de trabajo previamente definida en la WORKING-STORAGE SECTION, no puede pasar una cadena alfanumérica “AAA...” de manera directa, ya que producirá un ABEND en tiempo de ejecución en el sistema operativo EXIRION/OS. Esto mismo aplica también para el parámetro de DCLGEN. La variable de trabajo para almacenar los datos resultado de la consulta debe ser de tamaño adecuado en bytes a la cantidad de datos que espera recibir en su programa COBOL, ya que de lo contrario se realizara un truncamiento automático, esto lo administra el gestor del ETM del EXIRION/OS para evitar los errores de Overflow.

1.2 VERBOS PARA MS-SQL 1.2.1 EXEC_MSQL EXEC_MSQL permite acceder al lenguaje de manipulación de datos, lenguaje proporcionado por el driver para Microsoft SQL Server que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado desde un sistema operativo EXIRION/OS. Con EXEC_MSQL es posible realizar algunas de las siguientes sentencias en Microsoft T-SQL Server: INSERT INTO DELETE FROM UPDATE SET EXEC <PROCEDURE> En resumen el verbo EXEC_MSQL nos permite ejecutar cualquier sentencia de tipo T-SQL Server que no devuelva datos, desde nuestros programas COBOL en EXIRION/OS. Después de ejecutar su operación EXEC_MSQL coloca un código de retorno en el registro especial RETURN-CODE de EXIRION COBOL, para informar alguno de los siguientes estados:

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS DE MS-SQL SERVER

101

ABEND AL EJECUTAR LA CONSULTA SQL.

EXEC_MSQL debe ser llamado desde un CALL dinámico, recordemos que en EXIRION-COBOL los llamados con CALL pueden ser estáticos o dinámicos, y es el compilador quien determina el tipo de llamada, para usar los verbos del gestor dinámico de datos incorporado en EXIRION-COBOL no debe utilizar el llamado dinámico de LINK_PROGRAM, en su lugar debe hacerse con un simple CALL y sera el compilador quien determine que es una llamada dinámica. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 12 ]

Command Syntax: '–WS-QUERY-C-' '–WS-QUERY-B-' '–WS-QUERY-A-' >>-EXEC_MSQL-----+------------+------------><

Command Options: WS-QUERY Contiene la sentencia SQL a ejecutar en la base de datos, es una variable de trabajo declarada en la WORKING-STORAGE SECTION.

Implementación en COBOL: CALL “EXEC_MSQL” USING BY CONTENT WS-QUERY.

1.1.2 EXEC_MSQL_SELECT EXEC_MSQL_SELECT también permite acceder al lenguaje de manipulación de datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos de Microsoft SQL Server, que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado. Con EXEC_MSQL_SELECT es posible realizar algunas de las siguientes sentencias de T-SQL:

SELECT * FROM SHOW DATABASES SHOW TABLES DESCRIBE <TABLE> EXEC <PROCEDURE>

En resumen el verbo EXEC_MSQL_SELECT nos permite ejecutar cualquier sentencia de tipo T-SQL que si devuelva datos, desde programas COBOL. Los datos obtenidos como resultado de una sentencia que incluya SELECT serán depositados en la variable de trabajo WS-RECORDSET que sea definida en la WORKING-STORAGE SECTION y pasada como argumento por referencia a EXEC_MSQL_SELECT. Después de ejecutar su operación EXEC_MSQL_SELECT coloca un código de retorno en el registro especial RETURN-CODE de EXIRION COBOL, para informar alguno de los siguientes estados:

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA MS SQL SERVER.

101

ABEND AL EJECUTAR LA CONSULTA T-SQL.

102

ABEND AL EJECUTAR EL CÓDIGO DCLGEN, COMANDO NO VALIDO O MACROS NO EXISTE.

103

ABEND AL LEER EL PROGRAMA DCLGEN, DATA SET DAÑADO O NO EXISTE.

EXEC_MSQL_SELECT debe ser llamado desde un CALL dinámico, recordemos que en EXIRION-COBOL los llamados con CALL pueden ser estáticos o dinámicos, y es el compilador quien determina el tipo de llamada, para usar los verbos del gestor dinámico de datos incorporado en EXIRION-COBOL no debe utilizar el llamado dinámico de LINK_PROGRAM, en su lugar debe hacerse con un simple CALL y sera el compilador quien determine que es una llamada dinámica.

Command Syntax: '–WS-QUERY-C-' '–WS-QUERY-B-' '–WS-QUERY-A-' >>-EXEC_MSQL_SELECT----+------------+-----+---------+-----> '-DCLGEN1-' '-DCLGEN2-' '-DCLGEN3-'

'-RECORD-SET-' >----------+------------+----------><

Command Options: WS-QUERY Contiene la sentencia SQL ejecutar en la base de datos, contenido en una variable de trabajo de la WORKING-STORAGE. DCLGEN Contiene el include de los datos a recibir de la base de datos, contenido en una variable de trabajo de la WORKING-STORAGE. RECORD-SET Es una variable de trabajo con suficiente tamaño en bytes para almacenar los datos devueltos por la consulta, generalmente producida por una sentencia SELECT. Implementación en COBOL: CALL “EXEC_MSQL_SELECT” USING BY CONTENT WS-QUERY, BY CONTENT WS-DCLGEN, BY REFERENCE WS-RECORDSET.

Advertencias: El Query T-SQL debe estar almacenado en una variable de trabajo previamente definida en la WORKING-STORAGE SECTION, no puede pasar una cadena alfanumérica “AAA...” de manera directa, ya que producirá un ABEND en tiempo de ejecución en el sistema operativo EXIRION/OS. Esto mismo aplica también para el parámetro de DCLGEN. La variable de trabajo para almacenar los datos resultado de la consulta debe ser de tamaño adecuado en bytes a la cantidad de datos que espera recibir en su programa COBOL, ya que de lo contrario se realizara un truncamiento automático, esto lo administra el gestor del ETM del EXIRION/OS para evitar los errores de Overflow.

1.3 VERBOS PARA DEPURACIÓN La depuración de programas es el proceso de identificar y corregir errores de programación. En inglés se le conoce como debugging, es que se asemeja a la eliminación de bichos (bugs), manera en que se conoce informalmente a los errores de programación. Se dice que el término bug proviene de la época de los ordenadores de válvula termoiónica, en los cuales los problemas se generaban por los insectos que eran atraídos por las luces y estropeaban el equipo. Si bien existen técnicas para la revisión sistemática del código fuente y se cuenta con medios computacionales para la detección de errores (depuradores) y facilidades integradas en el sistema EXIRION/OS y en los ambientes de desarrollo integrado de ETM 2.0, sigue siendo en buena medida una actividad manual, que desafía la paciencia, la imaginación y la intuición del programador.

Muchas veces se requiere incluir en el código fuente instrucciones auxiliares que permitan el seguimiento de la ejecución del programa, presentando los valores de variables y direcciones de memoria, la salida de datos (modo de depuración), esto es posible utilizando el verbo WRITE_SPOOL para la depuración manual. Dentro de un proceso formal de aseguramiento de la calidad, puede ser asimilado al concepto de prueba unitaria. Como el software y los sistemas electrónicos se vuelven generalmente más complejos,en los sistemas operativos EXIRION/OS, EXIRION/XL65 y EXIRION/XE130 se han desarrollado varias técnicas comunes de depuración para detectar anomalías, corregir funcionalidades y optimizar código fuente, todo un entorno de debugging accesible desde la transacción CEDX y CEDF del gestor transaccional ETM II.

1.3.1 WRITE_SPOOL Este verbo nos permite realizar una depuración manual del código, ya que podemos mandar información al SPOOL del sistema operativo, para poder realizar pruebas unitarias. Para utilizar este verbo se debe hacer un CALL dinámico. Command Syntax: '-RC-CODE3-' '-RC-CODE2-' '-RC-CODE1-' >>-WRITE_SPOOL-------+----------+-----+----------+------->< '-MESSAGE1-' '-MESSAGE2-' '-MESSAGE3-' '-MESSAGE4-'

Command Options: MESSAGE Es una variable de trabajo de tipo alfanúmerico que contiene el mensaje o datos a mandar al SPOOL de EXIRION/OS. RC-CODE Es una variable de trabajo de tipo numérica “PIC 9(6)” que contiene el código de error generado durante el ABEND, puede ver la lista completa de códigos de error en el anexo de este manual. Implementación en COBOL: CALL “WRITE_SPOOL” USING BY CONTENT WS-MESSAGE, BY CONTENT WS-RETURN-CODE.

NOTAS: Este verbo fue el primer mecanismo de depuración en el sistema operativo EXIRION/OS, y requiere los privilegios de la cuenta “root”, o bien puede ser utilizado para depuración de aplicaciones Web que llaman a programas COBOL mediante los servicios SOA de Berly III. Se recomienda no utilizar WRITE_SPOOL para depurar sus aplicaciones, en su lugar use las transacciones CEDX y CEDF del gestor transaccional ETM II.

1.3.2 CEDX Y CEDF La ejecución del motor ETM 2.0 de diagnóstico ofrece dos transacciones que se pueden utilizar para los programas de aplicación de pruebas y depuración. Estas transacciones CEDF y CEDX, le permiten probar programas de aplicación de manera interactiva sin tener que suministrar procedimientos especiales de prueba al código de su programa como se hacia en las primeras versiones de EXIRION/OS con el verbo WRITE_SPOOL. CEDF Utilice CEDF para probar programas de aplicación que están asociados con las transacciones iniciadas por el usuario desde un terminal. CEDX Utilice CEDX para programas de aplicación de prueba que están asociados con las transacciones no terminales.

Command syntax: '-TRANID3-' '-TRANID2-' '-TRANID1-' >>-CEDX-----+---------+-------------------------><

>>-CEDF-----+---------+------------------------->< '-TRANID1-' '-TRANID2-' '-TRANID3-'

Command options: TRANID Es el nombre de la transacción a depurar, el motor debugging de ETM II extrae el programa binario asociado a la transacción pasada como parámetro, su código Ensamblador y código COBOL, para poder hacer la depuración, paso por instrucciones(step to step), volcados de memoria y seguimiento de datos.

Ejemplo depuración con CEDX: 1.Después de iniciar sesión en ETM II, ejecutamos CEDX pasando como parámetro la transacción BCL2 para depurar su programa asociado.

2.El ambiente de debugging del motor ETM II, esta listo para realizar la depuración del programa asociado a la transacción que fue seleccionada.

El ambiente debugging de CEDX ofrece las siguientes facilidades: PF

ACCION

F2 ASM

MUESTRA EL CÓDIGO ENSAMBLADOR DEL PROGRAMA ASOCIADO

F3 END

TERMINA EL USO DE CEDX Y REGRESA EL CONTROL DE LA TERMINAL A ETM II

F4 CBL

MUESTRA EL CÓDIGO COBOL DEL PROGRAMA ASOCIADO.

F5 TRACE

EJECUTA EL PROGRAMA ASOCIADO EN MODO PASO A PASO POR INSTRUCCIONES.

F6 ECOM

EDITAR LA LFHCOMMAREA QUE ESPERA EL PROGRAMA ASOCIADO PARA SU EJECUCION.

F7 DCOM

MOSTRAR LA LFHCOMMAREA QUE ESPERA EL PROGRAMA ASOCIADO PARA SU EJECUCION.

F8 RUN

EJECUTA EL PROGRAMA ASOCIADO SIN

DEPURACIÓN PARA GENERAR EL INFORME DE ESTADISTICAS Y PRUEBAS DE FUNCIONALIDAD. F9 STA

MUESTRA LOS RESULTADOS DE LAS ESTADÍSTICAS DE EJECUCIÓN EN EL SISTEMA OPERATIVO EXIRION/OS DEL PROGRAMA ASOCIADO.

3.[F2] Podemos ver el código ensamblador del programa asociado:

4.[F4] Podemos ver el código COBOL del programa asociado:

5.[F6] Podemos editar la LFHCOMMAREA:

6.[F5] Ejecutamos el programa asociado paso a paso: Cuando el programa asociado tuviera errores graves, no se podrá ejecutar paso a paso(TRACE) hasta que sean corregidos. Si el programa no contiene errores de tiempo de compilación nos muestra la siguiente pantalla,nos indica que el programa puede ser ejecutado paso a paso, debemos pulsar F3 para continuar.

Ahora podemos ejecutar paso a paso(TRACE):

TRACE contiene los siguientes comandos: N B G V C W

Siguiente Break Continuar solo hasta finalizar Volcado de WORKING-STORAGE Continuar Ver estructuras de datos.

7.[F8] Podemos ejecutar el programa para ver su salida y estadísticas en el sistema operativo EXIRION/OS:

Pulsamos F3 para desplegar la siguiente pantalla:

Nos muestra los datos devueltos por el programa asociado, en formato HEX como se encuentran de manera nativa en la memoria del computador y una representación visual de los mismos para facilidad del programador. Esta salida es devuelta por el programa asociado a la transacción BLC2, cada programa requiere su propia LFHCOMMAREA de entrada y produce su propia salida de datos, todo depende de que funcionalidad realiza el programa. 8.[F9] Finalmente podemos visualizar las estadísticas de ejecución del programa en EXIRION/OS:

1.4 DCLGEN DE EXIRION/OS DCLGEN es la herramienta generadora de Includes COBOL para acceso a bases de datos desde el sistema operativo EXIRION/OS. DCLGEN es un sub-lenguaje de tipo DCL(Data Control Language) que se integra a los programas COBOL para poder acceder a tablas de diferentes motores de bases de datos relacionales. Cuando estamos implementando un programa COBOL con acceso a Base de Datos, una de las cosas que tenemos que incluir en el mismo es la declaración de las tablas, 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 de base de datos desde los programas EXIRION-COBOL. Obviamente, estas sentencias DCL también se podrían generar manualmente dentro del propio código de programa COBOL en la WORKINGSTORAGE SECTION, 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 este sub-lenguaje, lo más probable es que nunca dejemos de usarlo. Realizar el Include utilizando el sub-lenguaje DCLGEN tiene grandes beneficios ya que los códigos DCLGEN pueden ser utilizados por muchos programas COBOL para consultar bases de datos, en cambio si se hace manualmente desde el propio código de programa COBOL, solo permitirá a ese programa el acceso a la base de datos. El sistema operativo EXIRION/OS esta diseñado para el trabajo concurrente y multi-proceso, por lo cual implementar el sub-lenguaje DCLGEN es la mejor alternativa para la creación de programas COBOL que tienen acceso a bases de datos.

El sistema operativo EXIRION/OS es algo diferente a otros sistemas operativos a los que tal vez usted se encuentra acostumbrado, cuando se crea un programa COBOL que requiere acceso a base de datos, lo único que necesita tener a la mano, es un pequeño código DCLGEN, el Query a ejecutar y el algoritmo de su programa(funcionalidad), usted no necesita definir la ubicación(IP) de la base de datos, usuario, password, puertos u otra información como lo hacen los programadores de otras plataformas, en EXIRION/OS desde el momento en que su cuenta de usuario es creada por el administrador del sistema, usted ya tiene un conjunto de privilegios dentro de los cuales se ha especificado incluso a que bases de datos tiene derecho, recursos de ficheros, cantidad de memoria RAM a utilizar, acceso a cierto hardware del computador y muchas otras opciones que pueden haber sido habilitadas o bloqueadas por su administrador. Cuando usted ejecuta su programa en EXIRION/OS desde una Terminal de TSO o ETM II, el programa corre en una región donde se encuentra su login activo, por lo cual el programa correrá con los privilegios que le fueron concedidos a usted por su administrador de sistema.

En el caso de que el programa se encuentra en ambiente productivo de ETM II, cuando es ejecutado por una transacción solicitada de manera remota desde una Terminal física o lógica desde una interfaz FrontEnd, el programa correrá con los privilegios propios de la región de ETM II y no con los privilegios de usted. Decimos que una Terminal es lógica cuando la transacción que ejecuta al programa asociado es una interfaz de tipo software con accesos al ambiente del sistema operativo EXIRION/OS. Las Terminales físicas generalmente son Hardware que contienen firmware con un micro-código escrito en memoria ROM, con la funcionalidad mínima requerida para solicitar una transacción al ambiente del sistema operativo EXIRION/OS. La interfaz de Front-End puede ser un programa remoto de computadora(Java,Net Framework,Linux, Mac,Windows,Etc.) o una persona real. En la siguiente tabla podemos ver el set de instrucciones soportadas por el sub-lenguaje DCLGEN para EXIRION/OS 9.0

INSTRUCCION SYSCTRL ADD

DESCRIPCION Define el tipo de estructura de datos para recibir el resultado de la consulta SQL, se debe indicar pasando como parámetro alguna de las siguientes macros: -DCLGEN -AXONDB -JSONDB -HTMLDB -XMLDB

RDBMS

Especifica el tipo de motor de base de datos, debe pasar como parámetro alguna de las siguientes macros: -PHOENIX-II -MSSQL

TABLE AT

Especifica el nombre de la tabla de base de datos a consultar.

Define la base de datos a usar.

OCCURS (?) TIMES

Define cuantos registros se van a guardar en el RECORD-SET provenientes de la tabla de base de datos a consultar.

USAGE (?) FIELDS

Le indica a COBOL cuantos campos forman la estructura de la tabla de base de datos.

STRUCTURE ACTION

Es en si el código DCL(Data Control Language) de todo sistema basado en SQL, ya que se especifica la estructura de la tabla, indicando nombre de campo, tipo y longitud. El tipo de campo depende del motor de base de datos a utilizar, por lo cual debe leer el manual de referencia de cada proveedor del sistema de base de datos que desea implementar.

//*

Permite agregar cualquier comentario, se deben utilizar siempre al final de las instrucciones del sub-lenguaje DCLGEN.

Macros de DCLGEN

Una macro (del griego makro, que significa “grande”) es una serie de instrucciones del sistema operativo EXIRION/OS que se almacenan para que se puedan ejecutar de manera secuencial mediante una sola llamada u orden de ejecución. Dicho de otra manera, una macroinstrucción es una instrucción compleja, formada por otras instrucciones más sencillas. Esto permite la automatización de tareas repetitivas. Las macros tienden a almacenarse en el ámbito del propio programa que las utiliza y se ejecutan como una combinación especial de funciones o un procedimiento especialmente creado y asignado para tal efecto. La diferencia entre una macroinstrucción y un programa es que en las macroinstrucciones la ejecución es secuencial y no existe otro concepto del flujo de programa. Las macros del sub-lenguaje DCLGEN son de tipo ocultas, son órdenes complejas de tipo macro que se han declarado en el código fuente pero que permanecen ocultas para el programador por motivos de seguridad, por acceso restringido y por políticas de ambiente de EXIRION/OS. Las macros permitidas para el sub-Lenguaje DCLGEN en el sistema operativo EXIRION/OS son las siguientes:

1.4.1 MACRO DCLGEN

Esta macros indica que los datos obtenidos de una consulta SQL serán almacenados en tablas de memoria en el propio lenguaje COBOL. El nombre de esta macros puede causar confusión ya que tiene el mismo nombre que el sub-lenguaje, pero son 2 cosas diferentes cuando hablamos de “DCLGEN” nos referimos al sub-lenguaje de tipo DCL para EXIRION/OS, y cuando nos referimos a “MACRO DCLGEN” es el formato de llegada de los datos provenientes de la consulta SQL.

Por ejemplo, cuando los datos son recibidos por COBOL: 01 ESTUDIANTES. 05 ESTUD-ROWS 07 ID-NOM 07 NOMBRE 07 EDAD 07 DIRECCION 07 PROMEDIO

OCCURS 10 TIMES. PICTURE 9(6). PICTURE X(60). PICTURE 9(3). PICTURE X(80). PICTURE S9(2)V2 USAGE COMP-3.

Obtenidos de una tabla como esta: ID_NOM

NOMBRE

EDAD

DIRECCION

PROMEDIO

1 2 3 4 5 6 7 8 9 10

Que fue creada con las siguientes sentencias SQL: CREATE TABLE ALUMNOS( ID_NOM NOMBRE EDAD DIRECCION PROMEDIO

INTEGER VARCHAR(60) INTEGER VARCHAR(80) DOUBLE

NOT NOT NOT NOT NOT

NULL, NULL, NULL, NULL, NULL,

PRIMARY KEY(ID_NOM) ); EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 37 ]

Y para ser recibida desde COBOL se utilizo el siguiente código DCLGEN: SYSCTRL ADD DCLGEN RDBMS PHOENIX-II TABLE AT ALUMNOS ON DBSAMPLE OCCURS 10 TIMES USAGE 5 FIELDS STRUCTURE ACTION ID_NOM INTEGER 6 NOMBRE VARCHAR 60 EDAD INTEGER 3 DIRECCION VARCHAR 80 PROMEDIO DOUBLE 9 //*REMARKS: //*THIS DCLGEN(DECLARATION GENERATOR) //*READ TO ALUMNOS TABLE //*PROGRAM: BRP100 COBOL //*BY: NOMBRE DEL PROGRAMADOR //*FOR: SISTEMA.

Por lo general cuando un programa COBOL requiere acceso a bases de datos es muy común utilizar tanto el código DCLGEN que contiene la definición de la tabla SQL, como una COPY-BOOKS de COBOL para almacenar la tabla de memoria, de esta manera varios programas COBOL pueden acceder a las mismas tablas SQL compartiendo el DCLGEN y la COPY-BOOKS.

1.4.2 MACRO JSONDB Esta macros es sumamente interesante, ya que permite devolver el resultado de la consulta en notación JSON, para poder exportarla a otras plataformas no COBOL, como la Web. Puede ser muy útil en la construcción de aplicaciones REST-full y servicios SOA.

JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen intercambio de datos.

que

JSON

sea

lenguaje

ideal

para

JSON está constituido por dos estructuras: Una colección de pares de nombre/valor: En varios lenguajes esto es conocido como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo. Una lista ordenada de valores: En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o secuencias. Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una forma u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras. En JSON, se presentan de estas formas: Un objeto es un conjunto desordenado de pares nombre/valor. Un objeto comienza con { (llave de apertura) y termine con } (llave de cierre). Cada nombre es seguido por : (dos puntos) y los pares nombre/valor están separados por , (coma).

Un arreglo es una colección de valores. Un arreglo comienza con [ (corchete izquierdo) y termina con ] (corchete derecho). Los valores se separan por , (coma).

Un valor puede ser una cadena de caracteres con comillas dobles, o un número, o true o false o null, o un objeto o un arreglo. Estas estructuras pueden anidarse.

Una cadena de caracteres es una colección de cero o más caracteres Unicode, encerrados entre comillas dobles, usando barras divisorias invertidas como escape. Un carácter está representado por una cadena de caracteres de un único carácter. Una cadena de caracteres es parecida a una cadena de caracteres C++.

Un número es similar a un número C++, excepto que no se usan los formatos octales y hexadecimales.

1.4.3 MACRO AXONDB Esta macros permite devolver el resultado de la consulta en formato Nova32 AXON. AXON es una notación de objetos de datos en texto plano, que he creado hace algunos años atrás(el año de 1999), cuando me encontraba en el desarrollo del primer EXIRION/OS la versión 1.2600.1 con una arquitectura de 16-bits y con solo 640K de memoria convencional de RAM, para trasmitir datos por el puerto RS232 a micro-controladores PIC y dispositivos PLC, era necesario utilizar un formato de datos muy simple, pero bien organizado, para evitar pasar cadenas de texto y después invertir tiempo en estar formando los campos por posiciones y longitudes, esto se logro resolver en gran medida con el formato AXON, que como otras notaciones como la JSON, permiten crear y extraer campos muy fácilmente de cadenas de texto plano. Dada la actual importancia de la transferencia de datos entre distintas plataformas y sistemas, decidí incluir esta notación de objetos también en la versión moderna de EXIRION/OS 9. La notación AXON, permite enviar y recibir tablas, estructuras de datos, matrices y vectores de manera ligera y rápida ya que utiliza el mínimo de elementos de lenguaje y se centra principalmente en el contenido de los datos a enviar.

Como toda notación tiene sus limitaciones, ya que los datos son enviados en formato de String, la notación AXON trata todos y cada uno de los campos y registros como tipo String, y es el sistema receptor del objeto AXON quien debe encargarse de dar el tipo y formato adecuado para cada campo pasado dentro de un objeto AXON, esto obliga a que el receptor del objeto AXON conozca los tipos de datos que espera recibir por el sistema o dispositivo que manda el objeto AXON. En la práctica esto no representa ningún problema pues la aplicación receptora generalmente siempre cuenta con sus propias características de presentación de los datos obtenidos. Como cualidad puedo mencionar que es un objeto de datos extremadamente ligero, mucho más que un objeto JSON o XML, por lo cual es muy viable su uso para transferir información en plataformas basadas en SOA con servicios REST u otro tipo de canales de datos.

Command Syntax:

>>---FIELDS----RECNO----+----------------------------------+--->< '--FIELD1--FIELD2--FIELD3--FIELDN--' '-------------RECORD1--------------' '-------------RECORD2--------------' '-------------RECORD3--------------' '-------------RECORDN--------------'

Command Options: FIELDS Número de campos que forman la tabla, matriz o estructura de datos. RECNO Número de registros que contiene el objeto AXON. FIELD Son los campos individuales dentro de un objeto AXON. RECORD Son cada registro formado por un grupo de campos dentro del objeto AXON. Ejemplo de implementaciones de una tabla como la siguiente: ID_CUENTA

CUENTA_BANCARIA

CARGOS

ABONOS

MX1001-C12

1,200.00

20,000.00

IS1025-C45

1,980.00

560.00

EDS788-W89

7,854.00

7000.00

CO7887-Q77

78.00

10.50

AND788-C87

1,689.00

900.00

La implementación en lenguaje C: char str_object[512]; strcpy(str_object,”4~5|1~MX1001-C12~1,200.00~20,000.00|2~IS1025C45~1,980.00~560.00|3~EDS788-W89~7,854.00~7000.00|4~CO7887Q77~78.00~10.50|5~AND788-C87~1,689.00~900.00”); La implementación en Java: String str_object = ”4~5|1~MX1001-C12~1,200.00~20,000.00|2~IS1025C45~1,980.00~560.00|3~EDS788-W89~7,854.00~7000.00|4~CO7887Q77~78.00~10.50|5~AND788-C87~1,689.00~900.00”; La implementación en COBOL: SYSCTRL ADD DCLGEN Nos devuelve automáticamente el siguiente objeto AXON: 4~5|1~MX1001-C12~1,200.00~20,000.00|2~IS1025-C45~1,980.00~560.00| 3~EDS788-W89~7,854.00~7000.00|4~CO7887-Q77~78.00~10.50|5~AND788C87~1,689.00~900.00

En COBOL simplemente basta con agregar la macro AXONDB, y el sublenguaje DCLGEN hará todo el trabajo por nosotros, convirtiendo cualquier tabla de tipo SQL a un objeto AXON. Para leer los campos de los objetos AXON, he publicado para Nova32 Development Software y www.exirion-os.org las siguientes bibliotecas multi-plataforma: BIBLIOTECA ETMRT.jar

LENGUAJE Java 8 J2EE

RESUMEN Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador

EXIRION XL65 operando como Servidor. Nova32.ETM.Runtime.dll

Microsoft.NET Acceso a clientes Framework 2.0, 3.5, remotos para ETM II en 4.0 y 4.5 una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando como Servidor.

BERLYRT.jar

Java 8 J2EE

Nova32.Berly.Runtime.dll

Microsoft.NET Acceso a los servicios Framework 2.0, 3.5, SOA y REST-full de 4.0 y 4.5 Berly III de EXIRION/OS 9.

ETMRTVBX.DLL

Microsoft Visual Basic 6.0 y ACTIVEX.

Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando como Servidor.

ETMRTW32.DLL

C++ para Windows

Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando como Servidor.

etmrt32.so

C++ para Linux de 32-bit.

Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando como Servidor.

etmrt64.so

C++ para Linux de 64-bit.

Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando

Acceso a los servicios SOA y REST-full de Berly III de EXIRION/OS 9.

como Servidor. ETMRTPS.PPU

Delphi o FreePascal.

Acceso a clientes remotos para ETM II en una región del sistema operativo EXIRION/OS en un computador EXIRION XL65 operando como Servidor.

Implementando las librerías anteriores es posible comunicar diferentes aplicaciones cliente creadas en distintos sistemas y diferentes lenguajes de programación con un ambiente EXIRION/OS 9 y EXIRION/XL65 utilizando como medio físico una red LAN,MAN o WAN y el protocolo TCP/IP.

1.4.4 MACRO HTMLDB Si usted ha pensado que el lenguaje COBOL no es compatible con las nuevas tecnologías, esta es una prueba clara de que es un lenguaje maduro, robusto y eficiente que ha superado la prueba del tiempo y que su uso es aun muy importante en el mundo de las computadoras y lo sera por muchos años mas. Esta macro permite devolver el resultado de una consulta realizada desde un programa COBOL en formato de tabla HTML, esto puede ser muy útil, si se esta construyendo un servicio tipo REST o basado en SOA con Berly III o cualquier otro lenguaje de programación que disponga de acceso al API de ETM para poder lanzar transacciones y ejecutar programas COBOL de un ambiente EXIRION/OS o EXIRION/XL65. Pese a que muchas personas creen que el lenguaje COBOL está en desuso, la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado. Según un informe de Gartner Group de 2005, el 75% de los datos generados por negocios son procesados por programas creados en COBOL, y en otro informe de 1997 estima que el 80% de los 300.000 millones de líneas de código existentes están creados en COBOL, escribiéndose 5.000 millones de líneas nuevas de COBOL cada año. Con todo eso, hoy por hoy, la programación en COBOL es uno de los negocios más rentables del mundo de la informática. En el resto de aplicaciones el COBOL ha caído en desuso, reemplazado por lenguajes más modernos o versátiles. Pero no todo es así. Hoy (2015) siguen existiendo decenas de miles de usuarios Cobol e instituciones que siguen instruyendo este lenguaje dados los números informados. Cobol sigue estando soportado y sigue evolucionando permanentemente; esto principalmente por la cantidad de aplicaciones que hoy sigue funcionando y que superan en número a los demás lenguajes gracias a tanta difusión en el pasado.

Utilizando la macro HTMLDB se obtiene como resultado de una consulta SQL una tabla de tipo HTML. Ejemplo de implementación de una tabla SQL como la siguiente: ID_CUENTA

CUENTA_BANCARIA

CARGOS

ABONOS

MX1001-C12

1,200.00

20,000.00

IS1025-C45

1,980.00

560.00

EDS788-W89

7,854.00

7000.00

Resultado de usar la macro HTMLDB: <table> <tr> <td>ID_CUENTA</td> <td>CUENTA_BANCARIA</td> <td>CARGOS</td> <td>ABONOS</td> </tr> <tr> <td>1</td> <td>IS1025-C45</td> <td>1,200.00</td> <td>20,000.00</td> </tr> <tr> <td>2</td> <td>IS1025-C45</td> <td>1,980.00</td> <td>560.00</td> </tr> <tr> <td>3</td> <td>EDS788-W89</td> <td>7,854.00</td> <td>7000.00</td> </tr> </table>

1.4.5 MACRO XMLDB Esta macro al igual que la anterior es muy útil para construir sistemas basados en SOA y servicios Web, el estándar WSDL de los Web Services es 100% XML, por lo cual esta macro puede resultar muy útil para exportar datos a la web. Utilizando la macro XMLDB se obtiene como resultado de una consulta SQL una tabla de tipo XML. Ejemplo de implementación de una tabla SQL como la siguiente: ID_CUENTA

CUENTA_BANCARIA

CARGOS

ABONOS

MX1001-C12

1,200.00

20,000.00

IS1025-C45

1,980.00

560.00

EDS788-W89

7,854.00

7000.00

Resultado de usar la macro XMLDB: <?xml version='1.0' encoding='utf-8' ?> <bancos> <row1> <ID_CUENTA>1</ID_CUENTA> <CUENTA_BANCARIA>IS1025-C45</CUENTA_BANCARIA> <CARGOS>1,200.00</CARGOS> <ABONOS>20,000.00</ABONOS> </row1> <row2> <ID_CUENTA>2</ID_CUENTA> <CUENTA_BANCARIA>IS1025-C45</CUENTA_BANCARIA> <CARGOS>1,980.00</CARGOS> <ABONOS>560.00</ABONOS> </row2> <row3> <td>3</td> <td>EDS788-W89</td> <td>7,854.00</td> <td>7000.00</td> </row3> </bancos>

2.ACCESO A MEMORIA TEMPORAL La memoria de acceso aleatorio (Random Access Memory, RAM) se utiliza como memoria de trabajo de la computadora EXIRION XL65 para el sistema operativo EXIRION/OS, los programas y la mayor parte del software. En la RAM se cargan todas las instrucciones que ejecutan la unidad central de procesamiento (procesador) y otras unidades del computador EXIRION XL65. Se denominan «de acceso aleatorio» porque una posición de memoria con un tiempo de posición, no siendo necesario seguir un secuencial) a la información de la manera

se puede leer o escribir en espera igual para cualquier orden para acceder (acceso más rápida posible.

Durante el encendido de la computadora EXIRION XL65, la rutina POST verifica que los módulos de RAM estén conectados de manera correcta. En el caso que no existan o no se detecten los módulos, la mayoría de tarjetas madres emiten una serie de sonidos que indican la ausencia de memoria principal. Terminado ese proceso, la memoria BIOS puede realizar un test básico sobre la memoria RAM indicando fallos mayores en la misma.

Los tipos principales de RAM compatibles con EXIRION/OS y EXIRION/XL65 son: SRAM (Static Random Access Memory) RAM estática, memoria estática de acceso aleatorio. NVRAM (non-volatile random access memory) Memoria de acceso aleatorio no volátil MRAM (magnetoresistive random-access memory) Memoria de acceso aleatorio magnetorresistiva o magnética DRAM (Dynamic Random Access Memory) RAM dinámica, memoria dinámica de acceso aleatorio. DRAM Asincrónica (Asynchronous Dynamic Random Access Memory, memoria de acceso aleatorio dinámica asincrónica) FPM RAM (Fast Page Mode RAM) EDO RAM (Extended Data Output RAM) SDRAM (Synchronous Dynamic Random-Access Memory, memoria de acceso aleatorio dinámica sincrónica) SDR SDRAM (Single Data Rate Synchronous Dynamic Random-Access Memory, SDRAM de tasa de datos simple) DDR SDRAM (Double Data Rate Synchronous Dynamic Random-Access Memory, SDRAM de tasa de datos doble) DDR2 SDRAM (Double Data Rate type two SDRAM, SDRAM de tasa de datos doble de tipo dos) DDR3 SDRAM (Double Data Rate type three SDRAM, SDRAM de tasa de datos doble de tipo tres) DDR4 SDRAM (Double Data Rate type four SDRAM, SDRAM de tasa de datos doble de tipo cuatro)

La expresión memoria temporal se utiliza frecuentemente para describir a los módulos de memoria RAM utilizados en las computadoras EXIRION XL65. La RAM es solo una variedad de la memoria de acceso aleatorio: las ROM, memorias Flash, caché (SRAM), los registros en procesadores y otras unidades de procesamiento también poseen la cualidad de presentar retardos de acceso iguales para cualquier posición. La implementación DRAM en EXIRION XL65 se basa en una topología de circuito eléctrico que permite alcanzar densidades altas de memoria por cantidad de transistores, logrando integrados de cientos o miles de megabits. Además de DRAM, los módulos poseen un integrado que permiten la identificación de los mismos ante la computadora EXIRION XL65 por medio del protocolo de comunicación Serial Presence Detect (SPD). La conexión con los demás componentes se realiza por de pines en uno de los filos del circuito impreso, el módulo al ser instalado en un zócalo o ranura placa base, tenga buen contacto eléctrico con los memoria y las fuentes de alimentación.

medio de un área que permiten que apropiada de la controladores de

La necesidad de hacer intercambiable los módulos, y de utilizar integrados de distintos fabricantes, condujo al establecimiento de estándares de la industria como los Joint Electron Device Engineering Council (JEDEC). Paquete DIP (Dual In-line Package, paquete de pines en-línea doble). Paquete SIPP (Single In-line Pin Package, paquete de pines en-línea simple): fueron los primeros módulos comerciales de memoria, de formato propietario, es decir, no había un estándar entre distintas marcas. Módulos RIMM (Rambus In-line Memory Module, módulo de memoria enlínea rambus): Fueron otros módulos propietarios bastante conocidos, ideados por la empresa RAMBUS. Módulos SIMM (Single In-line Memory Module, módulo de memoria enlínea simple): formato usado en computadoras antiguas. Tenían un bus de datos de 16 ó 32 bits. Módulos DIMM (Dual In-line Memory Module, módulo de memoria en-línea dual): usado en computadoras de escritorio. Se caracterizan por tener un bus de datos de 64 bits. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 53 ]

Módulos SO-DIMM (Small Outline DIMM): portátiles. Formato miniaturizado de DIMM.

usado

computadoras

Módulos FB-DIMM (Fully-Buffered Dual Inline Memory Module): usado en servidores EXIRION XL65.

2.1 COLAS TS

En este apartado vamos a ver lo que son las colas TS y como escribir/leer en ellas con un programa COBOL de ejemplo que se encuentra en el anexo del presente documento. Podemos definir las colas como "Instalaciones de almacenamiento secuencial que son recursos globales tanto dentro de una única región de ETM II como de un sistema de regiones de ETM II interconectadas". Lo que viene a significar almacenamiento de datos.

que

una

cola

una

región

Existen dos tipos de colas, las TS y las TD (transient data queues). En este apartado solo trataremos las colas TS. Las colas TS se crean dinámicamente, es decir, si al ejecutar un programa queremos escribir en una cola TS que no existe, se crea. La información se almacena en forma de registros y se puede acceder a ellos de forma secuencial o directa. Para la forma directa tendremos que indicar a la hora de leer la cola TS el número del registro al que queremos acceder (ITEM). Si no lo indicamos, iremos leyendo los registros de la cola TS secuencialmente. Al poder acceder de forma directa, permiten también actualizar la información almacenada. El nombre de una cola TS se lo asignaremos nosotros y debe iniciar con el signo “+” y 8 caracteres(sin contar el signo de +) como máximo, pueden ser letras y números, pero el primer carácter deberá ser una letra. Una cola TS es un elemento fundamental en el sistema operativo EXIRION/OS, ya que permite colocar en memoria RAM, variables, tablas, vectores y matrices para poder usarlos desde los programas ON-LINE de ETM II, la lectura de RAM es increíblemente rápida comparada con el acceso a discos solidos o unidades de cinta, gracias a esto una computadora EXIRION XL65 alcanza las grandes velocidades a las que trabaja con sus aplicaciones empresariales.

Ejemplo un nombre correcto de cola en EXIRION/OS: +CRBI1001 Para ver la información de una cola TS accederemos a la transacción CEBR (Temporary Storage Browse) tecleando CEBR dentro de una sesión de ETM II. La transacción CECI también permite ver y crear colas TS.

El sistema operativo EXIRION/OS dispone de un componente Software y Hardware llamado “SUPER-CHARGER” que es una región de memoria RAM designada para el almacenamiento de las colas TS, la capacidad de almacenamiento depende directamente de la cantidad de memoria RAM física disponible en la computadora EXIRION XL65, y es configurada directamente por Nova32 Development Software desde la fabricación de una computadora EXIRION XL65, es posible aumentar RAM física a cualquier modelo de computador EXIRION XL65, pero solo el personal autorizado de Nova32 puede realizar esa actualización, para conservar la garantía del producto. Tamaño del SUPER-CHARGER en algunos modelos:

MODELO COMPUTADORA EXIRION

TAMAÑO DEL SUPER-CHARGER

EXIRION XL65 MOD.BSTD001

GB DE RAM

EXIRION XL65 MOD.ENTD200

GB DE RAM

EXIRION XL65 MOD.RMBD400

16 GB DE RAM

EXIRION XE130 MOD.GOLT700

32 GB DE RAM

EXIRION XE130 MOD.SPST900

64 GB DE RAM

2.1.1 WRITEQ_TS El verbo WRITEQ_TS del API de ETM II nos permite crear una cola TS en la región activa donde se ejecute el programa COBOL. Es independiente a la sesión iniciada en la terminal por el usuario, las colas TS se mantienen en la RAM del computador EXIRION XL65, aunque el usuario finalice su sesión en la Terminal, la cola creada permanecerá accesible para otros usuarios y programas del sistema operativo EXIRION/OS. Las colas TS, permanecerán en RAM durante todo el tiempo necesario, pueden ser eliminadas por otros programas, transacciones o por el mismo sistema operativo en caso de que la región de memoria RAM del computador EXIRION XL65 se encuentre apunto de llenarse, en caso de una interrupción de alimentación eléctrica las colas TS serán eliminadas en automático ya que son bloques de datos almacenados en el “SUPER-CHARGER DE EXIRION/OS”. Command Syntax:

'-NAME-' .-FROM-. >>-WRITEQ_TS------+------+-------+------+-----+--------+-----> '-ITEMS1-' '-ITEMS2-' '-ITEMS3-' '-ITEMSN-'

.-RETURN-CODE-. >-------+-------+----------+-------------+-------->< '-RESP1-' '-RESP2-' '-RESPN-'

Command Options: NAME Nombre de la cola TS a crear, siguiendo las reglas: 1. El nombre tiene una longitud máxima de 8+1, es decir 8 caracteres y el signo “+”. 2. El primer carácter debe ser una letra 3. Es posible usar números para el nombre. 4. No se deberán usar caracteres especiales, incluyendo el guión bajo “_”, solo es posible usar las letras de la A..Z. 5. Debido a que en el sistema operativo EXIRION/OS no se distingue mayúsculas y minúsculas, esto aplica también para el nombre de la cola TS.

FROM Esta es una constante que debe pasar con el valor de “SPCH” al verbo WRITEQ_TS, ya que indica al core de EXIRION/OS que el tipo de cola a crear es TS(temporary storage). ITEMS Representa el RECORD-SET a guardar en la cola TS, generalmente es una variable de trabajo de la WORKING-STORAGE SECTION, pero puede provenir de una COPY de COBOL. Puede ser una literal simple, o una tabla COBOL, todo depende de la necesidad del dato a guardar en memoria temporal, pude guardar cuanto pueda imaginar, una variable, una tabla, una estructura de datos, un vector o conjuntos de matrices. RESP Esta variable de trabajo debe ser pasada por referencia, ya que el verbo informa mediante su uso, la cantidad de bytes que se EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 60 ]

escribieron en la cola TS, cuando el resultado es satisfactorio, en caso de un error se responderá un ABEND. RETURN-CODE Este es un registro implícito de EXIRION-COBOL, no se debe agregar al verbo, sin embargo cuando termina el proceso se informa alguno de los siguientes estados en ese registro:

DESCRIPCIÓN

CÓDIGO DE RETORNO

SUCCESS

000

INVREQ

200

IOERR

201

ISCINVREQ

202

ITEMERR

203

LENGERR

204

LOCKED

205

NOSPACE

206

NOTAUTH

207

QIDERR

208

SYSIDERR

209

PGMIDERR

210

CHANNELERR

211

Implementación COBOL:

CALL “WRITEQ_TS” USING BY BY BY BY

CONTENT CONTENT CONTENT REFERENCE

WS-NAME, WS-FROM, WS-ITEMS, WS-RESP.

2.1.2 READQ_TS

El verbo READQ_TS del API de ETM II nos permite leer una cola TS en la región activa donde se ejecute el programa COBOL. Es independiente a la sesión iniciada en la terminal por el usuario.

Command Syntax:

'--NAME-' .-INTO-. '-LENGTH-' >>-READQ_TS-------+-------+-------+------+-----+--------+-------->

>-----------+--------+-----------------> '-ITEMS1-' '-ITEMS2-' '-ITEMS3-' '-ITEMSN-'

.-RETURN-CODE-. >-------+-------+----------+-------------+-------->< '-RESP1-' '-RESP2-' '-RESPN-'

Command Options: NAME

Nombre de la cola TS a leer, siguiendo las reglas: 1. El nombre tiene una longitud máxima de 8+1, es decir 8 caracteres y el signo “+”. 2. El primer carácter debe ser una letra 3. Es posible usar números para el nombre. 4. No se deberán usar caracteres especiales, incluyendo el guión bajo “_”, solo es posible usar las letras de la A..Z. 5. Debido a que en el sistema operativo EXIRION/OS no se distingue mayúsculas y minúsculas, esto aplica también para el nombre de la cola TS. INTO Esta es una constante que debe pasar con el valor de “SPCH” al verbo READQ_TS, ya que indica al core de EXIRION/OS que el tipo de cola a leer es TS(temporary storage). LENGTH Cantidad de bytes a leer de la QUEUE, especifica el tamaño del RECORD-SET a leer de la cola almacenada en memoria temporal o RAM, mediante el uso de LENGTH es posible leer 1 o varios campos de un RECORD-SET, la lectura de los campos es secuencial. ITEMS Representa el RECORD-SET a leer de la cola TS, generalmente es una variable de trabajo de la WORKING-STORAGE SECTION, pero puede provenir de una COPY de COBOL. Puede ser una literal simple, o una tabla COBOL, todo depende de la necesidad del dato a leer en memoria temporal, pude leer cuanto pueda imaginar, una variable, una tabla, una estructura de datos, un vector o conjuntos de matrices. RESP

Esta variable de trabajo debe ser pasada por referencia, ya que el verbo informa mediante su uso, la cantidad de bytes que se pudieron leer en la cola TS, cuando el resultado es satisfactorio, en caso de un error se responderá un ABEND. RETURN-CODE Este es un registro implícito de EXIRION-COBOL, no se debe agregar al verbo, sin embargo cuando termina el proceso se informa alguno de los siguientes estados en ese registro:

DESCRIPCIÓN

CÓDIGO DE RETORNO

SUCCESS

000

INVREQ

200

IOERR

201

ISCINVREQ

202

ITEMERR

203

LENGERR

204

LOCKED

205

NOSPACE

206

NOTAUTH

207

QIDERR

208

SYSIDERR

209

PGMIDERR

210

CHANNELERR

211

Implementación COBOL: CALL “READQ_TS” USING

BY BY BY BY BY

CONTENT CONTENT CONTENT REFERENCE REFERENCE

WS-NAME, WS-INTO, WS-LENGTH, WS-ITEMS, WS-RESP.

2.1.3 DELETEQ_TS El verbo DELETEQ_TS del API de ETM II nos permite eliminar una cola TS en la región activa donde se ejecute el programa COBOL. Es independiente a la sesión iniciada en la terminal por el usuario.

Command Syntax:

'--NAME-' .-FROM-. >>-DELETEQ_TS-------+-------+-------+------+-----+-------------+--->< .-RETURN-CODE-.

Command Options: NAME Nombre de la cola TS a eliminar, siguiendo las reglas: 1. El nombre tiene una longitud máxima de 8+1, es decir 8 caracteres y el signo “+”. 2. El primer carácter debe ser una letra 3. Es posible usar números para el nombre. 4. No se deberán usar caracteres especiales, incluyendo el guión bajo “_”, solo es posible usar las letras de la A..Z. 5. Debido a que en el sistema operativo EXIRION/OS no se distingue mayúsculas y minúsculas, esto aplica también para el nombre de la cola TS. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 65 ]

FROM Esta es una constante que debe pasar con el valor de “SPCH” al verbo DELETEQ_TS, ya que indica al core de EXIRION/OS que el tipo de cola a eliminar es TS(temporary storage).

RETURN-CODE Este es un registro implícito de EXIRION-COBOL, no se debe agregar al verbo, sin embargo cuando termina el proceso se informa alguno de los siguientes estados en ese registro:

DESCRIPCIÓN

CÓDIGO DE RETORNO

SUCCESS

000

INVREQ

200

IOERR

201

ISCINVREQ

202

ITEMERR

203

LENGERR

204

LOCKED

205

NOSPACE

206

NOTAUTH

207

QIDERR

208

SYSIDERR

209

PGMIDERR

210

CHANNELERR

211

Implementación COBOL: CALL “DELETEQ_TS” USING

BY CONTENT BY CONTENT

WS-NAME, WS-FROM.

3.LLAMADAS DINÁMICAS DE PROGRAMAS Una llamada de enlace dinámico o más comúnmente “D-D-L” (sigla en inglés de data set dynamic link) es el término con el que se refiere a los data set con código ejecutable que se cargan bajo demanda de un programa por parte del sistema operativo EXIRION/OS. Esta denominación es exclusiva a los sistemas operativos EXIRION siendo "PROG" el ultimo nivel de cualificador con la que se identifican estos data set, aunque el concepto existe en prácticamente todos los sistemas operativos modernos. Las “D-D-L” son o se pueden ver como la evolución de las bibliotecas estáticas (en diversos sistemas) y de forma análoga contienen funcionalidad o recursos que utilizan otras aplicaciones. Sin embargo, su uso proporciona algunas ventajas: Reducen el tamaño de los archivos ejecutables: Gran parte del código puede estar almacenado en bibliotecas y no en el propio ejecutable lo que redunda en una mejor modularización. Pueden estar compartidas entre varias aplicaciones: Si el código es suficientemente genérico, puede resultar de utilidad para múltiples aplicaciones. Facilitan la gestión y aprovechamiento de la memoria del sistema: La carga dinámica permite al sistema operativo aplicar algoritmos que mejoren el rendimiento del sistema cuando se carguen estas bibliotecas. Además, al estar compartidas, basta con mantener una copia en memoria para todos los programas que la utilicen. Brindan mayor flexibilidad frente a cambios: Es posible mejorar el rendimiento o solucionar pequeños errores distribuyendo únicamente una nueva versión de la biblioteca dinámica. Nuevamente, esta corrección o mejora será aprovechada por todas las aplicaciones que compartan la biblioteca. Las “D-D-L” en el sistema operativo EXIRION/OS, generalmente como lo mencione en lineas anteriores se identifican por que el ultimo nivel de cualificador es “PROG”, sin embargo debido al núcleo híbrido de EXIRION/OS también existen ciertos programas de sistema generalmente utilerías del sistema operativo con un calificador “so” heredado del kernel Linux.

A diferencia de otros sistemas operativos EXIRION/OS tiene una peculiaridad en el modo de ejecutar programas y llamadas dinámicas, en otros sistemas las bibliotecas dinámicas por ejemplo: dll, so, ocx, etc., deben ser enlazadas desde un programa llamador no pueden funcionar por si solas, en cambio en el sistema operativo EXIRION/OS una DDL(data set dynamic link) puede entrar en operación al ser invocada desde un programa llamante o bien puede entrar en operación por si misma, sin necesitar de un programa llamador. En resumen podemos decir que los programas binarios del sistema operativo EXIRION/OS pueden ser enlazados dinámicamente por otros programas o pueden ejecutarse por si mismos sin necesidad de un programa llamador. Los programas ejecutables en el sistema operativo EXIRION/OS se pueden identificar por el ultimo nivel de cualificador en el nombre del data set, que es “PROG”. El formato binario para los ejecutables en EXIRION/OS versiones 4.0 a la 9.0 es ELF, las primeras versiones del kernel de EXIRION/OS estuvieron basadas en el formato “MZ” común en los sistemas basados en un DOS. El formato ELF (Executable and Linkable Format) es un formato de archivo para ejecutables, código objeto, bibliotecas compartidas y volcados de memoria. Fue desarrollado por Unix System Laboratories (USL) como parte de la ABI. En principio fue desarrollado para plataformas de 32 bits, a pesar de que hoy en día se usa en gran variedad de sistemas de 64 bits. Es el formato ejecutable usado mayoritariamente en los sistemas tipo UNIX como GNU/Linux, BSD, Solaris, Irix. Existen otros formatos soportados en algunos de estos sistemas como COFF, pero ELF es sin duda el más usado, por lo cual decidí implementar ese formato en EXIRION/OS desde la versión 4.0.

Estructura ELF: Dentro del formato ELF podemos distinguir varias partes. En primer lugar la cabecera ELF, que contiene información general sobre el ejecutable. En él se indican las posiciones de las tablas de EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 68 ]

cabeceras de sección y cabeceras de programa. Cada una de estas cabeceras indican dónde se encuentran los datos de cada una de las secciones. Las cabeceras de programa definen las regiones del ejecutable o biblioteca que es necesario cargar para crear la imagen del proceso e iniciar su ejecución. Las cabeceras de sección contienen información importante para el enlazado y la relocalización. Las secciones tienen nombres que suelen coincidir sistemas operativos incluyendo a EXIRION/OS.

todos

los

Ejemplos de secciones son:

.data

Contiene datos inicializados del programa.

.debug

Contiene información para ayudar a la depuración.

.ctors

Contiene punteros a constructores.

.dtors

Contiene punteros a destructores.

.dynamic

Contiene información relevante para el enlazado dinámico.

.dynsym

Contiene la tabla de símbolos para el enlazado dinámico.

.fini

Contiene código de finalización del programa.

.init

Contiene código de inicialización del programa.

.shstrtab Contiene una tabla de strings con los nombres de las secciones. .strtab Contiene una tabla de strings normalmente usada para nombrar los elementos de la tabla de símbolos. .symtab

Contiene una tabla de símbolos.

.text Contiene la parte ejecutable de un programa.

3.1 CALL DINÁMICO En el compilador de COBOL para EXIRION/OS la utilización del verbo CALL, es algo diferente a otros compiladores de COBOL para otras plataformas de sistemas operativos. En la mayoría de los compiladores COBOL realizar un CALL implica una llamada estática, esto no aplica para el sistema operativo EXIRION/OS. En COBOL de EXIRION, hacer un llamado con CALL puede ser tanto de enlace estático como para realizar enlaces dinámicos, es el compilador quien determina el tipo de llamado que se esta intentando realizar. El compilador de COBOL EXIRION es lo suficientemente inteligente para determinar el tipo de llamada a un programa del sistema operativo, para el programador es transparente el proceso y es el compilador quien determina el tipo de invocación. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 70 ]

¿Como puede determinar el compilador una llamada estática de una dinámica? Cuando se solicita una llamada estática, el programa llamado con CALL recibe los datos de COMMAREA en la DFHCOMMAREA declarada en la LINKAGE SECTION, en cambio cuando la llamada es dinámica los datos de COMMAREA por el programa llamado son recibidos en la LFHCOMMAREA declarada en la WORKING-STORAGE SECTION. El proceso necesario para que lo pueda determinar el compilador no es tan simple, pero podemos hacer la diferencia en términos sencillos y entendibles con la explicación anterior, para no entrar en complejos detalles técnicos de lenguaje ensamblador. En resumen debemos respetar estas reglas fundamentales para EXIRIONCOBOL: 1.Para crear programas de enlace estático siempre usaremos DFHCOMMAREA declarada en la LINKAGE SECTION como variable de trabajo para la COMMAREA del programa. 2.Para crear programas de enlace dinámico siempre usaremos LFHCOMMAREA declarada en la WORKING-STORAGE SECTION como variable de trabajo para la COMMAREA del programa. En el anexo del presente manual también se incluyen los JCL de ejemplo necesarios para compilar programas COBOL-EXIRION, donde se describen los puntos mas importantes de la utilería CLCOB64.

Command Syntax: '-PROGRAM-' >>-CALL----+---------+--------+-------+-------+----+----> .-USING-. .-BY-.

.-REFERENCE-. .-CONTENT---. >------+-----------+---------+----------+--------->< '--WS-VAR1-' '--WS-VAR2-' '--WS-VAR3-' '--WS-VAR4-' '--WS-VARN-'

Command Options: PROGRAM Programa llamado para ejecutarse en memoria. USING BY Indica el tipo de paso de parámetros. CONTENT Paso de datos por contenido. REFERENCE Paso de datos por referencia. WS-VAR Variable de trabajo declarada en la WORKING-STORAGE SECTION que contiene los datos a pasar o a recibir del programa invocado.

Implementación COBOL: CALL “PROGRAM” USING BY CONTENT BY REFERENCE

WS-VAR1, WS-VAR2.

El uso de CALL en el sistema operativo EXIRION/OS es fundamental, como podrá observar durante el transcurso de este manual, la mayoría de verbos para acceder al API de ETM utilizan una llamada de tipo CALL dinámica.

3.1.1 ALLOCATE ALLOCATE declara memoria que se reserva en tiempo de ejecución. Su principal ventaja frente a la estática, es que su tamaño puede variar durante la ejecución del programa. (En COBOL, el programador es encargado de reservar esta memoria, cuando no la utilice más el sistema operativo EXIRION/OS es quien la libera). El uso de memoria dinámica es necesario cuando a priori no conocemos el número de datos/elementos a tratar.

La memoria reservada de forma dinámica suele estar alojada en el heap o almacenamiento libre, y la memoria estática en el stack o pila (con excepción de los objetos de duración estática, que se verán más adelante, los cuales normalmente se colocan en una zona estática de datos). La pila generalmente es una zona muy limitada. El heap, en cambio, en principio podría estar limitado por la cantidad de memoria disponible durante la ejecución del programa y el máximo de memoria que el sistema operativo EXIRION/OS permita direccionar a un proceso. La pila puede crecer de forma dinámica, pero esto depende de la versión del sistema operativo EXIRION. En cualquier caso, lo único que se puede asumir es que muy probablemente dispondremos de menor espacio en la pila que en el heap. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 74 ]

Otra ventaja de la memoria dinámica es que se puede ir incrementando durante la ejecución del programa. Esto permite, por ejemplo, trabajar con arreglos dinámicos. Aunque en EXIRION-COBOL, a partir del estándar se permite la creación de arreglos cuyo tamaño se determina en tiempo de ejecución, no todos los compiladores de COBOL implementan este estándar. Además, se sigue teniendo la limitante de que su tamaño no puede cambiar una vez que se especifica, cosa que sí se puede lograr asignando memoria de forma dinámica. Una desventaja de la memoria dinámica es que es más difícil de manejar. La memoria estática tiene una duración fija, que se reserva y libera de forma automática. En contraste, la memoria dinámica se reserva de forma explícita y continúa existiendo hasta que sea liberada, generalmente por parte del sistema operativo EXIRION/OS cuando el programa llamado finaliza. La memoria dinámica puede afectar el rendimiento. Puesto que con la memoria estática el tamaño de las variables se conoce en tiempo de compilación, esta información está incluida en el código objeto generado, por lo cual el proceso es muy eficiente. Cuando se reserva memoria de manera dinámica, el sistema operativo EXIRION/OS tiene que llevar a cabo varias tareas, como buscar un bloque de memoria libre y almacenar la posición y tamaño de la memoria asignada, de manera que EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 75 ]

pueda ser liberada más adelante. Todo esto representa una carga adicional, aunque esto depende de la implementación y hay técnicas para reducir su impacto. Cuando se reciben los datos de la COMMAREA de un programa llamado de manera dinámica es necesario reservar memoria RAM para esos datos, esta es una característica propia del sistema operativo EXIRION/OS, esta acción se realiza con el verbo ALLOCATE. Los llamados de manera estática no requieren el uso de ALLOCATE, puesto que utilizan el mismo segmento de datos del programa invocador.

Command Syntax: >>----ALLOCATE--------+----------+----------->< '-COMMAREA-'

Command Options: COMMAREA Es el área de comunicación de un programa COBOL, la cual durante una invocación dinámica deberá reservar memoria RAM en el sistema operativo EXIRION/OS. La COMMAREA se debe encontrar en una variable de trabajo llamada LFHCOMMAREA declarada en la WORKING-STORAGE SECTION y debe ser pasada por referencia.

Implementación COBOL: CALL “ALLOCATE” USING BY REFERENCE LFHCOMMAREA.

3.1.2 SEND Este verbo es uno de los mas importantes cuando se esta creado un programa COBOL On-Line para ETM II, recordemos algunos de los verbos que nunca se deben usar en programas On-Line para ETM: 1.No pueden definirse archivos en los programas de aplicación ETM. En lugar de esto, los archivos se definen en una tabla ETM, la File Control Table (FCT). 2.La ENVIRONMENT DIVISION no puede incluir la INPUT-OUTPUT SECTION. 3.La DATA DIVISION no puede incluir la FILE SECTION. 4.La PROCEDURE DIVISION no puede usar los siguientes verbos de COBOL : DISPLAY OPEN CLOSE READ WRITE REWRITE DELETE START READ NEXT SORT Los verbos anteriores solo pueden ser usados en programas COBOL para trabajos BATCH en el ambiente de JEM(JOB ENTRY MODULE). El verbo SEND permite responder al programa llamador, el cual puede ser una transacción ETM II. La respuesta del comando SEND siempre debe ser la COMMAREA del programa, almacenada en la variable de trabajo LFHCOMMAREA y declarada en la WORKING-STORAGE SECTION.

Command Syntax:

.-LFHCOMMAREA-. >>-SEND-----+-------------+-----------><

Command Options: LFHCOMMAREA Es el área de comunicación de un programa COBOL. La COMMAREA se debe encontrar en una variable de trabajo llamada LFHCOMMAREA declarada en la WORKING-STORAGE SECTION y debe ser pasada por contenido al programa llamador. Implementación COBOL: CALL “SEND” USING BY CONTENT LFHCOMMAREA.

3.1.3 LINK_PROGRAM Utilizar un CALL tanto para llamadas estáticas como para llamadas dinámicas puede complicar la lectura de programas COBOL fuente por diferentes personas, tal vez quien ha creado el programa sabe en que punto hará una llamada dinámica, pero si el programa es asignado a otra persona, esta tendrá que ver también el código de los programas llamados para saber el tipo de llamada que esta haciendo el programa, cuando se trabaja en equipos de desarrollo no es muy conveniente usar un CALL para ambas formas de invocaciones, y aveces los comentarios no ayudan mucho, puede que un programador no los incluya en su código, y aunque esta es una característica poderosa del sistema operativo EXIRION/OS, se creo un verbo adicional denominado “LINK_PROGRAM” es una especie de complemento para CALL, pero esta pensado para hacer solo llamadas dinámicas, el verbo LINK_PROGRAM acompañara a CALL para indicar que es una llamada dinámica, esto facilitaría mucho la lectura y análisis de programas COBOL, por diferentes programadores en diferentes momentos. Command Syntax: '-PROGRAMN-' '-PROGRAM3-' '-PROGRAM2-' .-LINK_PROGRAM-. '-PROGRAM1-' >>-CALL----+--------------+----------+----------+------->

.-LFHCOMMAREA-. >------+-------------+---------+--------+---------> '-LENGTH-' '-RESPN-' '-RESP3-' '-RESP2-' '-RESP1-' >--------+-------+---------><

Command Options: LINK_PROGRAM Indica que se esta realizando un CALL dinámico. PROGRAM Nombre del programa a invocar de manera dinámica. LFHCOMMAREA COMMAREA que se pasara como entrada al programa. LENGTH Tamaño en bytes de la COMMAREA pasada al programa llamado. RESP COMMAREA devuelta por el programa llamado de manera dinámica.

Implementación en COBOL:

CALL “LINK_PROGRAM” USING BY BY BY BY

CONTENT CONTENT CONTENT REFERENCE

WS-PROGRAM, LFHCOMMAREA, WS-LENGTH, WS-RESP.

4.COMPILACIÓN DE PROGRAMAS COBOL Un compilador es un programa informático que traduce un programa escrito en un lenguaje de programación a otro lenguaje de programación. Usualmente el segundo lenguaje es lenguaje de máquina, pero también puede ser un código intermedio (bytecode), o simplemente texto. Este proceso de traducción se conoce como compilación. Para que un programa creado en COBOL pueda ser ejecutado en el sistema operativo EXIRION/OS es necesario someterlo al proceso de compilación para generar un programa ejecutable en formato binario ELF, fácilmente identificable por su ultimo nivel de cualificador “PROG” en el data set que lo contiene.

En el sistema operativo EXIRION/OS a diferencia de otros sistemas, los programas COBOL no pueden ser ejecutados con interpretadores, o a modo de scripting, el cargador de programas de EXIRION/OS solo puede ejecutar binarios en formato ELF, por lo cual para poder lanzar un programa creado en COBOL, se debe someter a la compilación. El ambiente ISPF(Interactive System Productivity Facility) de TSO(Time Sharing Option) en el sistema operativo EXIRION/OS ofrece 2 facilidades para realizar la compilación de un programa COBOL, el modo Foreground y el modo Batch, los cuales se detallan a continuación en el presente manual.

4.1 COMPILACIÓN EN MODO FOREGROUND

El modo foreground de ISPF en el sistema operativo EXIRION/OS nos permite compilar el programa COBOL vía primer plano, es decir mientras se este compilando el programa no podremos hacer ninguna otra actividad con nuestra Terminal de TSO, hasta que el proceso haya finalizado podremos volver a interactuar con la Terminal. Realizar la compilación en modo foreground tiene sus ventajas y desventajas, como beneficio podemos decir que si necesitamos compilar un programa COBOL pequeño, sin tener que escribir un job JCL, esta es la opción indicada, podremos compilar en unos cuantos pasos en el ambiente de ISPF. Las desventajas son que no podemos usar la Terminal hasta que el compilador termine, pudiera parecer trivial, pero cuando necesitamos compilar programas COBOL enlazados a otros programas y librerías el tiempo de compilación puede ser considerable y nosotros quedaríamos inactivos sin poder hacer otras tareas durante todo ese tiempo. Otra desventaja es que la compilación vía foreground solo permite incluir 4 librerías al programa COBOL, hay muchos casos en que esto no podría afectarnos si nuestro programa no requiere librerías adicionales o si requiere menos o la cantidad permitida para adicionar, en la práctica nuestros programas COBOL pueden fácilmente superar esa cantidad de librerías adicionales al momento de la compilación, en esos casos no es recomendable la compilación vía foreground y se debe realizar mediante proceso Batch.

Pasos para compilar COBOL desde foreground: 1.En el panel primario de ISPF debemos seleccionar la opción número 4(Foreground):

2.En el siguiente panel seleccionamos la número 2(COBOL):

3.Debemos seleccionar el tipo de compilación a realizar: 1 = Programa Ejecutable 2 = Librería de enlace estático 3 = Librería de enlace dinámico [F3] = Cancelar y salir.

4.Definimos el data set donde se encuentra nuestro programa COBOL:

5.Agregamos las librerías adicionales que requiere nuestro programa para ser compilado, en caso de no requerir ninguna librería solo pulsamos ENTER brincando por cada campo ===>. 6.Esperamos todo el tiempo que dure la compilación, si el programa es pequeño sera muy rápido, pero si el programa es grande e incluye otros programas y librerías el tiempo puede ser considerable, es aquí donde se recomienda no usar este modo de compilación y hacerlo vía proceso Batch.

7.Cuando el proceso de compilación finaliza nos devuelve el control al ISPF:

8.Debemos ir al panel de la utilidad SDSF(Ruta del Panel 1 – 8 - 3) para ver en el spool, el resultado de la compilación con la opción “Q”:

10.Si nuestro programa no tiene errores de compilación podremos ver la siguiente pantalla, en caso contrario se mostraran todos los errores de compilación y tendremos que corregir nuestro programa COBOL:

11.Si todo fue correcto, tenemos un programa ejecutable que tiene el mismo nombre que el programa fuente, con la diferencia de que el ultimo nivel de cualificador ha cambiado de “COBOL” a “PROG”, para poder ejecutarlo en el sistema operativo EXIRION/OS dependerá del ambiente para el cual fue creado: 1.-Programas COBOL para ambiente ON-LINE de ETM II, se deberá crear una transacción con CEDA para poder probarlo. 2.-Programas COBOL para ambiente BATCH de JEM II, se deberá crear un job JCL para poder ponerlo en operación con la utilidad IEBLOAD. La ejecución de programas en ambientes ON-LINE y BATCH se explican en otros manuales de EXIRION/OS. “Nova32 ETM II for EXIRION.pdf” “Nova32 Batch and JEM for EXIRION.pdf ”

4.2 COMPILACIÓN EN MODO BATCH Se conoce como sistema por lotes (en inglés batch processing), o modo batch, a la ejecución de un programa sin el control o supervisión directa del usuario (que se denomina procesamiento no interactivo). Este tipo de programas se caracterizan porque su ejecución no precisa ningún tipo de interacción con el usuario. Generalmente, este tipo de ejecución se utiliza en tareas repetitivas sobre grandes conjuntos de información, ya que sería tedioso y propenso a errores realizarlo manualmente. Los programas que ejecutan por lotes suelen especificar su funcionamiento mediante un lenguaje de programación orientado a trabajos secuenciales en los que se indica qué se quiere ejecutar y, posiblemente, qué tipo de recursos necesita reservar. El JCL (acrónimo de Job Control Language, en español Lenguaje de Control de Trabajos) es un lenguaje informático o un conjunto de especificaciones de morfología y sintaxis requeridas para la redacción de instrucciones de ejecución de programas informáticos por parte del sistema operativo de un equipo informático. Este lenguaje se usa en los Ordenadores Centrales (Mainframes) y es específico para cada sistema operativo. Las instrucciones (también llamadas "pasos" o "sentencias") del JCL son declaraciones u órdenes con las que se indica al sistema operativo EXIRION/OS qué tareas debe realizar, en qué secuencia han de ejecutarse y en qué periféricos están ubicados los ficheros de datos (de entrada y/o de salida) que requieren dichas tareas. Un procedimiento (también llamado trabajo o job) es un conjunto coherente de instrucciones para realizar un trabajo particular. El uso del JCL permite un alto grado de flexibilidad e independencia respecto a la ubicación física de los programas y ficheros involucrados.

Sintaxis General de JCL La codificación de un JCL debe empezar en las columnas 1 y 2 con //, salvo en algunos casos. El nombre que identifica cada paso del JCL deberá comenzar con un carácter alfabético de máximo de 8 caracteres a partir de la columna 3. Los parámetros utilizados en la codificación del JCL deberán ser separados por comas, y la declaración de estos no deberá exceder de la posición 71 La codificación de comentarios es con //*, los cuales deberán terminar como máximo en la columna 72. La terminación de un paso es indicada a través de /* en las columnas 1 y 2.

Principales Sentencias de JCL JOB. Identifica el inicio del job a ejecutarse. EXEC. Principio de cada paso e identifica el programa o procedimiento a ser ejecutado DD. Define las entradas y salidas del proceso

Compilación COBOL Cuando realizamos la compilación vía Batch, es necesario crear un trabajo o job en lenguaje JCL para submitirlo(enviarlo) al administrador de trabajos Batch de EXIRION/OS llamado JEM II (JOB ENTRY MODULE), JEM es el responsable de administrar la cola de trabajos en el sistema operativo EXIRION/OS, aplicando algunas reglas de prioridades y peticiones, JEM va encolando nuestras solicitudes de trabajos, los procesa y ejecuta, cuando el job que mandamos a JEM finaliza, el mismo JEM nos manda un aviso a nuestra Terminal de que nuestro job fue completado, las salidas las podemos ver nuevamente desde el spool del sistema con la utilidad SDSF. Esta es la mejor manera de compilar un programa COBOL, pueden agregarse tantas librerías como sean necesarias, no existe un limite, y podemos seguir trabajando en nuestra Terminal en otras actividades mientras JEM procesa nuestro job de compilación en modo background(segundo plano), nuestra Terminal no se congela, podemos seguir trabajando en otras cosas, y JEM nos avisara cuando el proceso finalice, aun cuando cerremos nuestra sesión de TSO y regresemos a trabajar en otro momento.

4.2.1 UTILERIA COBCL64 En el sistema operativo EXIRION/OS versiones 4.0 a 9.0, el proceso de compilación en modo Batch utilizando los servicios de JEM II, la utilería COBCL64 es la responsable de llamar al compilador de COBOL, buscar y enlazar todas las librerías tanto de usuario como de sistema necesarias para la construcción de un programa binario en formato ELF, el cual puede ser una librería estática, dinámica o un programa ejecutable relocalizable en memoria.

Command Syntax:

.-COBTYPE-. .-COBLIBS-. >>-COBCL64-----+---------+--------+---------+---------->

>-------+-------+----------+---------+-----------> '-SYSIN-' '-SYSLINK-'

.-SYSPRINT-. .-DCB-. .-DISP-. >------+--------+------+----------+------+-----+---+------+--->< '-SYSUT1-' '-SYSUT2-' '-SYSUT3-' '-SYSUT4-' '-SYSUT5-' '-SYSUT6-' '-SYSUTN-'

Command Options: COBTYPE Es necesario definir en esta variable de ambiente Batch de JEM II el tipo de compilación a realizar, pudiendo especificar: CXL, CSL y CDL. CXL

COBOL EXECUTABLE LINK PROGRAM

CSL

COBOL STATIC LIBRARY

CDL

COBOL DYNAMIC LIBRARY

COBLIBS En esta variable de ambiente podemos definir la cantidad de librerías de usuario que deseamos compilar con nuestro programa, esta variable es muy útil ya que podemos incluir del listado de nuestro job cuantas librerías serán compiladas u omitidas. SYSIN En esta definición de datos especificamos el programa fuente lenguaje COBOL que sera sometido al proceso de compilación. SYSLINK Esta definición de datos permite crear el programa resultado de la compilación, en formato binario ELF.

salida,

SYSPRINT Permite informar a la utilería COBCL64 que las salidas de Errores y Warnings sean enviadas al spool de sistema de nuestro usuario para poder verlas con la utilidad SDSF de la interfaz ISPF. DCB Define el formato de data set donde se encuentra nuestro código fuente de COBOL para poder ser leído por la utilidad COBCL64. DCB= (RECFM=FB,LRECL=72,BLKSIZE=640) DISP Nos permite indicar a la utilidad COBCL64 que el data set creado para contener el programa binario sera creado en base a la compilación, catalogado en el sistema operativo EXIRION/OS y si existe otro binario con el mismo nombre sera reemplazado. DISP= (NEW,CATLG,DELETE)

4.2.2 JCL PARA COMPILACIÓN

Para una mayor comprensión de la utilidad COBCL64, presento a continuación un ejemplo de job para compilar un programa ejecutable relocalizable en memoria:

//**************************************************** //* EXIRION/OS Operating System 9.00 * //* SDK 9.00 JCL ENGINE for JEM (Job Entry Module) * //* Remarks: Example COBOL compilation * //* * //**************************************************** // CLCOBOL1 JOB GODDES,SYS1,CLASS=C,MSGCLASS=C, pts/0 // MSGLEVEL=(1,1),REGION=64K // P01CL001 EXEC PGM= COBCL64 // SET COBTYPE= CXL // SET COBLIBS= 0 // SYSIN DD DSN= CYRBI.SYS.BCL215.COBOL // SYSLINK DD DSN= CYRBI.SYS.BCL215.PROG // SYSUT1 DD DSN= LIB1 // SYSUT2 DD DSN= LIB2 // SYSUT3 DD DSN= LIB3 // SYSUT4 DD DSN= LIB4 // SYSUT5 DD DSN= LIB5 // SYSUT6 DD DSN= LIB6 // SYSUT7 DD DSN= LIB7 // SYSUT8 DD DSN= LIB8 // SYSUT9 DD DSN= LIB9 // SYSUT10 DD DSN= LIB10 // SYSPRINT DD SYSOUT= * // DCB= (RECFM=FB,LRECL=72,BLKSIZE=640) // DISP= (NEW,CATLG,DELETE) /*

5.ANEXOS

5.1 TABLA CODIGOS DE ERROR SQL_EXEC

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS.

101

ABEND AL EJECUTAR LA CONSULTA SQL.

SQL_EXEC_SELECT

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS.

101

ABEND AL EJECUTAR LA CONSULTA SQL.

102

ABEND AL EJECUTAR EL CÓDIGO DCLGEN, COMANDO NO VALIDO O MACROS NO EXISTE.

103

ABEND AL LEER EL PROGRAMA DCLGEN, DATA SET DAÑADO O NO EXISTE.

EXEC_MSQL

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA DE BASE DE DATOS DE MS-SQL SERVER

101

ABEND AL EJECUTAR LA CONSULTA SQL.

EXEC_MSQL_SELECT

CÓDIGO DE RETORNO

SIGNIFICADO

000

OPERACIÓN REALIZADA CON ÉXITO

100

ABEND AL REALIZAR LA CONEXIÓN CON EL SISTEMA MS SQL SERVER.

101

ABEND AL EJECUTAR LA CONSULTA T-SQL.

102

ABEND AL EJECUTAR EL CÓDIGO DCLGEN, COMANDO NO VALIDO O MACROS NO EXISTE.

103

ABEND AL LEER EL PROGRAMA DCLGEN, DATA SET DAÑADO O NO EXISTE.

WRITEQ_TS, READQ_TS y DELETEQ_TS

DESCRIPCIÓN

CÓDIGO DE RETORNO

SUCCESS

000

INVREQ

200

IOERR

201

ISCINVREQ

202

ITEMERR

203

LENGERR

204

LOCKED

205

NOSPACE

206

NOTAUTH

207

QIDERR

208

SYSIDERR

209

PGMIDERR

210

CHANNELERR

211

5.2 PROGRAMA DE EJEMPLO BRP200 Programa ejemplo con acceso a bases de datos Ms SQL Server 2008. 000000 IDENTIFICATION DIVISION. 000001 PROGRAM-ID. BRP200. 000002 AUTHOR. xmh80044. 000003 INSTALLATION. CYRBI. 000004 DATE-WRITTEN. 11-19-2015. 000005 DATE-COMPILED. 11-19-2015. 000006 REMARKS. GET REPORTS ON CYRBI. 000007 ENVIRONMENT DIVISION. 000008 CONFIGURATION SECTION. 000009 SOURCE-COMPUTER. EXIRION-XL65. 000010 OBJECT-COMPUTER. EXIRION-XL65. 000011 DATA DIVISION. 000012 WORKING-STORAGE SECTION. 000013 01 WS-COMMANDS. 000014 05 COMPANY PICTURE X(10). 000015 05 DTE1-INI PICTURE X(10). 000016 05 DTE1-FIN PICTURE X(10). 000017 05 DTE2-INI PICTURE X(10). 000018 05 DTE2-FIN PICTURE X(10). 000019 01 RTCODE PICTURE 999. 000020 01 RTCODE-DESC PICTURE X(10). 000021 01 WS-QUERY PICTURE X(200). 000022 01 DCLGEN-ADB PICTURE X(70). 000023 01 AXON-TABLE PICTURE X(8192). 000024 01 LFHCOMMAREA PICTURE X(8192). 000025 01 CB-DEBUG PICTURE X(80). 000026 LINKAGE SECTION. 000027 01 DFHCOMMAREA PICTURE X(1027). 000028 PROCEDURE DIVISION. 000029****************************************************************** 000030 000-INPUT. 000031 ACCEPT LFHCOMMAREA FROM COMMAND-LINE. 000032* //EXEC ETM 000033 CALL "ALLOCATE" USING BY REFERENCE LFHCOMMAREA. 000034* //END-EXECUTE. 000035 STRING LFHCOMMAREA DELIMITED BY X"00" INTO WS-COMMANDS 000036 END-STRING. 000037 STRING "CYRBI.DATA.CASNE001.DCLGEN" X"00" DELIMITED BY SIZE 000038 INTO DCLGEN-ADB END-STRING. 000039 STRING "EXEC SP_RE001 " COMPANY ",'" DTE1-INI "','" DTE1-FIN 000040 "','" DTE2-INI "','" DTE2-FIN "' " X"00" 000041 DELIMITED BY SIZE INTO WS-QUERY 000042 END-STRING. 000043 000-PROCESSING. 000044 INITIALIZE AXON-TABLE. 000045* //EXEC SQL 000046 CALL "EXEC_MSQL_SELECT" USING BY CONTENT WS-QUERY, 000047 BY CONTENT DCLGEN-ADB, 000048 BY REFERENCE AXON-TABLE. EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 97 ]

000049* //END-EXEC. 000050 IF RETURN-CODE IS GREATER THAN ZERO THEN 000051 MOVE RETURN-CODE TO RTCODE-DESC 000052 STRING "4~1|ABEND~" RTCODE-DESC "~0~0" X"00" 000053 DELIMITED BY SIZE 000054 INTO LFHCOMMAREA END-STRING 000055 PERFORM 000-OUTPUT 000056 END-IF. 000057 STRING AXON-TABLE X"00" 000058 DELIMITED BY SIZE 000059 INTO LFHCOMMAREA 000060 END-STRING. 000061 MOVE 0 TO RETURN-CODE. 000062 000-OUTPUT. 000063* //EXEC ETM 000064 CALL "SEND" USING BY CONTENT LFHCOMMAREA. 000065* //END-EXEC. 000066 STOP RUN.

5.3 PROGRAMA DE EJEMPLO BCL215 Programa COBOL ejemplo para ilustrar creación de colas TS.

000001 IDENTIFICATION DIVISION. 000002 PROGRAM-ID. BCL215. 000003 AUTHOR. ROLANDO FERNANDEZ BENAVIDEZ. 000004 INSTALLATION. EXIRION-OS-9. 000005 DATE-WRITTEN. 11/06/2015. 000006 DATE-COMPILED. 11/06/2015. 000007 REMARKS. CREATE CATALOGS FOR CYRBI IN SUPERCHARGER. 000008 ENVIRONMENT DIVISION. 000009 CONFIGURATION SECTION. 000010 SOURCE-COMPUTER. EXIRION-XL65. 000011 OBJECT-COMPUTER. EXIRION-XL65. 000012 DATA DIVISION. 000013 WORKING-STORAGE SECTION. 000014 01 WS-RESP1 PICTURE X(40). 000015 01 WS-RESP2 PICTURE X(40). 000016 01 LFHCOMMAREA PICTURE X(100). 000017 01 WS-QUEUE PICTURE X(10). 000018 01 WS-QUEUE2 PICTURE X(10). 000019 01 WS-QFROM PICTURE X(5). 000020 01 WS-CENTERS. 000021 02 CENTERS-ROWS OCCURS 10 TIMES. 000022 05 IDCENT PICTURE 9(6). 000023 05 DESCNT PICTURE X(20). 000024 01 WS-YEARS. 000025 02 YRDES PICTURE 9(4) 000026 OCCURS 10 TIMES. 000027 01 CCENTROS PICTURE X(300). 000028 01 CCONSYEAR PICTURE X(50). 000029 LINKAGE SECTION. 000030 01 DFHCOMMAREA PICTURE X(100). 000031 PROCEDURE DIVISION. 000032 PERFORM 000-CREATE-TABLES. 000033 PERFORM 001-PROCESS-INPUT-FORMAT. 000034 PERFORM 002-SUPER-CHARGER. 000035 PERFORM 003-DATAS-OUTS. 000036 000-CREATE-TABLES. 000037********************* TBL CCENTROS *************************** 000038 MOVE 0 TO IDCENT(1). 000039 MOVE "FRANQUICIA" TO DESCNT(1). 000040 MOVE 1990 TO IDCENT(2). 000041 MOVE "POZA RICA" TO DESCNT(2). 000042 MOVE 5693 TO IDCENT(3). 000043 MOVE "TEZIUTLAN" TO DESCNT(3). 000044 MOVE 5694 TO IDCENT(4). 000045 MOVE "JALAPA" TO DESCNT(4). 000046 MOVE 5712 TO IDCENT(5). 000047 MOVE "CARDEL" TO DESCNT(5). 000048 MOVE 5714 TO IDCENT(6). EXIRION/OS and Nova32 Development Software are registered trademarks of RolandoFernández Benavidez in the México States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders. [ 99 ]

000049 MOVE "MARTINEZ" TO DESCNT(6). 000050*********************** TBL CCONSYEAR ************************ 000051 MOVE 2012 TO YRDES(1). 000052 MOVE 2013 TO YRDES(2). 000053 MOVE 2014 TO YRDES(3). 000054 MOVE 2015 TO YRDES(4). 000055 MOVE 2016 TO YRDES(5). 000056 MOVE 2017 TO YRDES(6). 000057 MOVE 2018 TO YRDES(7). 000058 MOVE 2019 TO YRDES(8). 000059 MOVE 2020 TO YRDES(9). 000060 MOVE 2021 TO YRDES(10). 000061 001-PROCESS-INPUT-FORMAT. 000062******************* CREATE CATALOGS IN SUPERCHARGER************ 000063 STRING "+CRBI1001" X"00" DELIMITED BY SIZE 000064 INTO WS-QUEUE END-STRING. 000065 STRING "+CRBI1002" X"00" DELIMITED BY SIZE 000066 INTO WS-QUEUE2 END-STRING. 000067 STRING "SPCH" X"00" DELIMITED BY SIZE 000068 INTO WS-QFROM END-STRING. 000069 STRING WS-CENTERS X"00" DELIMITED BY SIZE 000070 INTO CCENTROS END-STRING. 000071 STRING WS-YEARS X"00" DELIMITED BY SIZE 000072 INTO CCONSYEAR END-STRING. 000073 STRING "DUMMY" X"00" DELIMITED BY SIZE 000074 INTO WS-RESP1 END-STRING. 000075 STRING "DUMMY" X"00" DELIMITED BY SIZE 000076 INTO WS-RESP2 END-STRING. 000077 002-SUPER-CHARGER. 000078* //EXEC ETM 000079 CALL "WRITEQ_TS" USING 000080 BY CONTENT WS-QUEUE, 000081 BY CONTENT WS-QFROM, 000082 BY CONTENT CCENTROS, 000083 BY REFERENCE WS-RESP1. 000084 CALL "WRITEQ_TS" USING 000085 BY CONTENT WS-QUEUE2, 000086 BY CONTENT WS-QFROM, 000087 BY CONTENT CCONSYEAR, 000088 BY REFERENCE WS-RESP2. 000089* //END-EXEC. 000090 003-DATAS-OUTS. 000091 STRING "(" WS-RESP1 DELIMITED BY X"00" ")," 000092 "(" WS-RESP2 DELIMITED BY X"00" ")." 000093 X"00" DELIMITED BY SIZE 000094 INTO LFHCOMMAREA END-STRING. 000095* //EXEC ETM 000096 CALL "SEND" USING BY CONTENT LFHCOMMAREA. 000097* //END-EXEC. 000098 STOP RUN.