Manual de Técnico v.1

BIZPRO Sistema DBI - SQLFireManual Técnico

Version 1.0

Documentación Versión: 1.0Manual Técnico Fecha: Septiembre - 2015

Historial de RevisionesFecha Versión Descripción Autor

Confidencial 2023 Page 2


Tabla de contenido1. Introducción 4

2. Implementación sistema DBI 4

3. Requerimientos 11

4. Manejo de accesos 11

5. Comunicador 12

6. Convertidor 12

7. Ejecución de Jobs 14

8. Convertidor 14



Test Plan1. Introducción

Se brinda información técnica útil para hacia los administradores y programadores del sistema

2. Implementación sistema DBISea cual sea el avance en En cualquier etapa de la fase de investigación del proyecto y suponiendo considerando que la estrategia de desviación ha sido exitosa, aún así se ha operado sobre muy pocos programasPor otro lado, el entorno aplicativo de en un cliente debe abarcar cientos o miles de programas y tablas.

El ambiente de desarrollo de ese del entorno contempla programas fuente que mediante jobs generan programas carga, y paquetes y planes DB2:

Y el El ambiente de producción contempla programas carga, que junto con planes son ejecutados por jobs o por CICS. Estos programas acceden a las bases de datos mediante DB2:

La situación final esperada en el cliente es un ambiente alterno, con conjuntos con un conjunto de diferentes de programas, jobs y bases de datos,; las cuales, como ya se sabe, se encuentran están incluso en otra plataforma.



Para alcanzar este punto debemos esta situación hay que seguir esta secuencia de pasos:

En una plataforma distribuida hay que se debe implementar implantar y habilitar el DBMS GemFire, y así como un programa comunicador del tipo apropiado requerido para los al tipo de programas del cliente

Luego hay que hacer Posteriormente realizar una conversión masiva de programas fuente (ambiente origen a ambiente alterno) del ambiente original al ambiente alterno. Esto se hace con la aplicación repetida del convertidor de tipo igual al tipo del comunicador implementado implantado



Estos Los programas luego de ser convertidos ya no son DB2. Luego Posteriormente son compilados y linked mediante jobs adecuados para tal fin

Luego sigueContinuamos con la conversión masiva de jobs de ejecución. Esto se hace mediante la aplicación repetida de un convertidor de jobs, el cual tiene que ser desarrollado e implementado implantado previamente



***Después sigue la migración de datos de las bases de datos DB2 objetivo. Esto se hace mediante la aplicación repetida de un migrador de datos, el cual tiene que ser desarrollado e implementado implantado previamente



Ahora ya En este punto se tiene el ambiente alterno completo, en cuanto a infraestructura, programas, jobs y bases de datos específicos.

Así que en En términos generales, general, ya se llegó ha llegado a la instancia situación esperada.



Adicional a esto, hay que se debe liberar un mecanismo para acceso interactivo a las bases de datos

Un ejemplo de estos accesos es el SPUFI o el QMF, que desaparecerán por supuesto van a desaparecer cuando el DB2 sea proscrito.

Este mecanismo debe aceptar aceptará la entrada manual de sentencias SQL, su envío al comunicador vía socket , y luego la recepción del resultado también vía socket, así como y su escritura en un archivo de salida.

También hay que Se debe liberar un mecanismo para tener acceso a las bases de datos por ejecución batch de SQL.

Por ejemplo, desviando los jobs que usan los programas DSNTEP2, DSNTIAD, DSNTIAR o DSNTIAUL.

Estos programas acceden directamente a tablas DB2.

Se requiere tanto un convertidor automático de jobs como la implementación implantación de programas sustitutos DSNTEP2, DSNTIAD, DSNTIAR o DSNTIAUL.

Con esto resulta Como resultado de que los dos procesos ilustrados a continuación y usando como ejemplo DSNTEP2 son totalmente equivalentes.



Por último, hay que considerar los accesos remotos a la base de datos.

En este caso no existe problema alguno, hay gran problema, porque ya que un acceso remoto se hace mediante un data source:

y basta con cambiar el data source para que el acceso sea desviado a GemFire:

Hay que Se tienen que considerar las siguientes premisas para una fase cualquiera de implantación implementación:

- Se debe tener disponibilidad de todos los programas fuente del sistema- Se debe tener la disponibilidad de recursos de infraestructura como todo el hardware, software, espacio de

almacenamiento y permisos requeridos



- El código del comunicador debe estar protegido, por ejemplo, habiendo si ha sido programado en lenguaje C o mediante un enmascarador de código java, de modo que cualquier módulo instalado en la infraestructura del cliente sea un ejecutable indescifrable

- El código del convertidor debe estar protegido, digamos, usando REXX compilado, de modo que cualquier módulo instalado en la infraestructura del cliente sea un ejecutable indescifrable

- El código del convertidor de jobs de ejecución igual debe estar protegido, digamos, usando REXX compilado, de modo que cualquier módulo instalado en la infraestructura del cliente sea un ejecutable indescifrable

- El código del migrador de bases de datos igual debe estar protegido, digamos, usando REXX compilado, de modo que cualquier módulo instalado en la infraestructura del cliente sea un ejecutable indescifrable

- Las pruebas deben empezar con un paralelo entre los programas y datos originales junto con los programas y datos alternos, hasta que el cliente quede totalmente satisfecho

3. RequerimientosComo se ha mencionado en diversos momentos, se requiere el entorno z/OS con CICS, DB2, TCP/IP y soporte COBOL para soportar los programas COBOL del ambiente aplicativoLos programas aplicativos acceden a datos en tablas DB2 y usan archivos de entrada y salida.En un entorno distribuido se requiere un servidor de datos (manejador de bases de datos) al que se acceda simplemente vía data-source.Y en otro entorno distribuido se requiere la ejecución del manejador de accesos y del comunicador mediante java, garantizando que tengan comunicación vía socket.

4. Manejo de accesosEl manejador de accesos es un programa java NWCOMAX1.java que está en un servidor distribuido y del que hay que destacar los siguientes puntos:

1) Este manejador en realidad es un simulador. Pero cualquier manejador que sea implementado implantado debe tener la misma funcionalidad en cuanto a lo que recibe y lo que devuelve.

2) El párrafo NWCOMAX1 está vacío.3) El párrafo run recibe una petición y devuelve una respuesta vía socket.4) Debido a que este programa ignora totalmente el mensaje de petición, éste es la cadena constante

‘TESTPROGRAMX’ . Por supuesto que un manejador de accesos con la funcionalidad total debe considerar el layout de la petición de servicio con información relevante y debe coordinarse desde su envío desde el programa COBOL convertido con el formato que se requiera en su momento.

5) La respuesta que da este programa es la cadena fija ‘0000012000000000000adcd|5677|%)’ en la que los primeros siete caracteres indican la longitud del mensaje útil, los segundos siete caracteres son la cadena fija ‘0000000’ la cual es utilizada en el programa COBOL, los siguientes cinco caracteres son la cadena fija ‘00000’ que para el caso de sentencias SQL es el SQLCODE y finalmente viene el mensaje útil el cual consta de dos campos delimitados por pipe ‘|’. Los campos son respectivamente la dirección IP y el puerto para acceder a un comunicador disponible. El penúltimo carácter ‘%’ es el delimitador de registro y el último carácter ‘(‘ es el indicador de fin de respuesta.

6) El párrafo sendMessage escribe la respuesta para su devolución vía socket.7) El párrafo main ejecuta NWCOMAX1 ***(que no hace nada) y posteriormente luego hace un loop para

llamar a run, es decir, para estar continuamente recibiendo peticiones y enviando respuestas.

En una implementación implantación de este manejador de accesos, se debe asignar con toda anticipación la dirección y el puerto en que va a atender, pues en este estado del sistema, esta dirección y puerto del sistema se asigna en código duro a todo programa convertido.De ser necesario, como una alternativa, se debe idear un mecanismo de para indicar en forma dinámica a los programas en ejecución, la dirección y puerto donde van a conectarse con el manejador de accesos.El desarrollo e implantación del manejador de accesos está más allá del alcance de este proyecto y es



responsabilidad del grupo técnico de BizPro enfocado a GemFire

5. ComunicadorEl comunicador es un programa java NWCOMBX1.java que está en un servidor distribuido y del que hay que destacar los siguientes puntos:El párrafo NWCOMBX1 inicia la conexión vía data source con el nuevo manejador de bases de datos.El párrafo run recibe una petición, la envía al párrafo procstmt, espera un resultado y devuelve una respuesta vía socket.La petición que se recibe es una sentencia SQL. Esta sentencia está en el conjunto limitado {‘DECLARE CURSOR’, ’OPEN CURSOR’, ’FETCH’, ’CLOSE CURSOR’, ’INSERT’, ’UPDATE’, ’DELETE’, ’SELECT’}. Cuando la sentencia requiere ser atendido por el manejador de base de datos, se envía la sentencia al párrafo sendSQLSentence.La respuesta que da este programa es una cadena en la que los primeros siete caracteres indican la longitud del mensaje útil, los segundos siete caracteres son la cadena fija ‘0000000’ la cual es utilizada en el programa COBOL, los siguientes cinco caracteres son el SQLCODE y finalmente viene el mensaje útil.Para todas las sentencias excepto SELECT y FETCH el mensaje útil solo son los caracteres delimitadores de registro y mensaje ‘%)’.Para las sentencias SELECT y FETCH el mensaje útil son los campos de la consulta delimitados por pipe ‘|’ y para el caso de FETCH el delimitador de registros ‘%’ y en ambos casos el delimitador de mensaje ‘)’ (indicador de fin de respuesta). Este mensaje útil crece hasta exceder unos 80 Kb de tamaño en que se devuelve y los datos restantes quedan almacenados en memoria para ser a su vez enviados en una ocurrencia posterior de FETCHEl párrafo sendMessage escribe la respuesta para su devolución vía socket.El párrafo main ejecuta NWCOMBX1 (que hace la conexión a la base de datos) y luego hace un loop para llamar a run, es decir, para estar continuamente recibiendo peticiones y enviando respuestas.El párrafo sendSQLSentence hace el acceso a la base de datos y cuando se trata de una consulta (sentencias SELECT u OPEN CURSOR) deja la tabla resultado en memoria lista para ser devuelta por el párrafo procstmt inmediatamente (en el caso de SELECT) o en partes (en el caso de FETCH).El desarrollo e implantación del manejador de accesos está más allá del alcance de este proyecto y es responsabilidad del grupo técnico de BizPro enfocado a GemFire.Aunque todo programa que sustituya al comunicador debe satisfacer la premisa básica de la eficiencia, es decir, mientras este programa sea el más rápido debe seguir siendo usado.

6. ConvertidorEl convertidor es un programa REXX que se encuentra en &LIBPREF..REXXCONV(NWCONVX1).Su funcionamiento es muy simple: se especifica un programa de entrada (que está en la biblioteca. &LIBPREF..SRCE, aunque ésta es configurable) mediante la variable PGMNAME y al final deja de salida el programa convertido con el mismo nombre (en la biblioteca &LIBPREF..SRCECONV, aunque ésta es configurable también).Se asume que el original es un programa COBOL con acceso a tablas DB2 y el convertido es un programa COBOL con la misma funcionalidad pero con acceso a tablas en el manejador de bases de datos nuevo.Cada uno de los párrafos del programa REXX tiene un mensaje indicando lo que hace.Como resultado, también queda como salida un archivo reporte. &SYSUID..PS.NWCONVX1.&PGMNAME..F&FECHA..H&HORA. En este archivo se lista el resultado parcial de cada párrafo. Este resultado parcial consiste la mayoría de las ocasiones en el llenado de matrices con información del programa, hasta una matriz final que como último paso es escrita físicamente en el programa convertido Este reporte facilita las tareas de programación, depuración y corrección de fallas.Para fines documentales aquí se listan los párrafos del convertidor000_MAIN. Es el flujo del programa100_INICIO. Tareas iniciales110_FIXPAR. Parámetros fijos para configuración del proceso120_VALINI. Validaciones iniciales



130_BORRA. Elimina el programa convertido en versiones viejas140_CLOSE. Cierra archivos que pudieran estar abiertos150_VARPAR. Parámetros variables para configuración del proceso200_PROCESO. Propiamente es el flujo de la conversión210_LISTELEM . Lista elementos y alinea SQL. En un primer recorrido del programa determina el conjunto completo de copies e includes (los cuales a su vez también son recorridos) y cuando encuentra sentencias SQL las unifica en una sola línea. Este párrafo llena las matrices TEXT.&nombreobjeto..&contador donde nombreobjeto es el nombre del programa y de cada uno de los copies e includes y contador es una numeración consecutiva. Cada elemento tiene una línea de texto del respectivo componente. Como se acostumbra en REXX, TEXT.&nombreobjeto..0 almacena la cantidad de elementos en la matriz correspondiente220_INTEGRA. Integra todos los elementos (programa, copies e includes) en un solo programa. Llena la matriz INTEG.&contador donde contador es una numeración consecutiva. Cada elemento tiene una línea de texto del programa integrado. Como es costumbre en REXX, INTEG.0 contiene la cantidad de elementos en la matriz INTEG Además se llena una matriz PEND con sentencias EXEC SQL DECLARE CURSOR que están en DATA DIVISION y que son desplazadas a PROCEDURE DIVISION230_SQL. Extrae todas las sentencias SQL y llena la matriz SQL.&contador donde contador es una numeración consecutiva. Cada elemento es una sentencia SQL. Como es costumbre en REXX, SQL.0 contiene la cantidad de elementos en la matriz SQL240_VARS1. Extrae los datos de las tablas DB2 de las sentencias SQL DECLARE TABLE y llena las siguientes matrices: matriz TABLAS.&contador donde contador es una numeración consecutiva. Cada elemento es una tabla usada en el programa. Como es costumbre en REXX, TABLAS.0 contiene la cantidad de elementos en la matriz TABLAS; matriz COLS.&tbname.&contador donde tbname es el nombre de la tabla y contador es una numeración consecutiva. Cada elemento es una columna de la tabla tbname. Como es costumbre en REXX, COLS.&tbname.0 contiene la cantidad de entradas en la matriz COLS.&tbname; matriz DDL.&colname donde colname es un nombre de columna. Cada elemento son los atributos de la columna colname; matriz CURS.&contador donde contador es una numeración consecutiva. Cada elemento es un cursor usado en el programa. Como es costumbre en REXX, CURS.0 contiene la cantidad de elementos en la matriz CURS250_VARS2. Extrae las variables SELECT, es decir, los campos que son consultados en las sentencias SELECT u DECLARE CURSOR y llena la matriz SELECT.&isql donde isql es el apuntador al correspondiente elemento de la matriz SQL260_VARS3. Extrae las variables host INTO, es decir, las variables que van a recibir datos de consultas. Llena la matriz INTO.&isql..&contador donde isql es el apuntador al correspondiente elemento de la matriz SQL y contador es una numeración consecutiva. Cada elemento es una variable INTO. Como es costumbre en REXX, INTO.&isql..0 contiene la cantidad de elementos en la matriz INTO.&isql270_VARS4. Extrae las variables host no INTO, es decir, las variables host que deben ser sustituidas en sentencias SQL. Llena la matriz HOST.&isql..&contador donde isql es el apuntador al correspondiente elemento de la matriz SQL y contador es una numeración consecutiva. Cada elemento es una variable host no INTO. Como es costumbre en REXX, HOST.&isql..0 contiene la cantidad de elementos en la matriz HOST.&isql280_PIC. Extrae el PICTURE de las variable host de cualquier clase de las extraidas en párrafos anteriores. Llena la matriz PIC.&varname donde varname es el nombre de la variable. Cada elemento es el PICTURE de una variable host281_PICS. Auxiliar del párrafo anterior 280_PIC. Se usa cuando las variables tienen estructura (por ejemplo una variable 01 que consta de varias variables 10)290_CLOSE. Extrae condiciones de cierre de socket según algunas señales del propio programa. Estas condiciones están en &LIBREF..PARM(CLOSESOK). Llena la matriz CLOSE.&contador donde contador es una numeración consecutiva. Cada elemento es una condición de cierre de socket. Como es costumbre en REXX, CLOSE.0 contiene la cantidad de elementos en la matriz CLOSE300_LINTO. Determina la longitud (máxima) de cada cláusula INTO. Llena la matriz LINT.&isql donde isql es el apuntador al correspondiente elemento de la matriz SQL. Cada elemento es una longitud máxima de INTO310_DATADIV. Genera líneas con datos de variables (propias de la conversión) que van a ser insertadas en DATA DIVISION. Llena la matriz DDIV.&contador donde contador es una numeración consecutiva. Cada elemento es una línea COBOL de DATA DIVISION. Como es costumbre en REXX, DDIV.0 contiene la cantidad de elementos en la matriz DDIV



320_PREV. Genera instrucciones COBOL que deben insertarse antes de cada sentencia SQL. Llena la matriz PRE.&isql donde isql es el apuntador al correspondiente elemento de la matriz SQL. Cada elemento es una línea COBOL330_POST. Genera instrucciones COBOL que deben insertarse después de cada sentencia SQL. Llena la matriz POS.&isql donde isql es el apuntador al correspondiente elemento de la matriz SQL. Cada elemento es una línea COBOL340_CONV. Genera el programa convertido integrando toda la información y líneas COBOL generadas por los párrafos anteriores. Llena la matriz CONV.&contador donde contador es una numeración consecutiva. Cada elemento es una línea COBOL del programa convertido. Como es costumbre en REXX, CONV.0 contiene la cantidad de elementos en la matriz CONV350_ESCRIBE. Escribe el contenido de la matriz CONV en el archivo de salida, el cual es el resultado de la ejecución del convertidor832_ESCR. Escribe un registro relacionado con bloques de instrucciones COBOL insertados por la conversión833_RPT. Escribe un registro en el reporte de la conversión que se genera para fines documentales900_FINAL. Tareas finales. Particularmente, cerrar el reporte de la conversión

7. Ejecución de JobsHay que recordar que un programa cualquiera se identifica por tres caracteres PROGIDPara un programa original se tienen básicamente dos jobs

1) Job de compilación, cuyos pasos varían según el programa sea con o sin CICS. Aunque la mejor práctica es que haya un job de compilación (según el tipo de programa) que funcione para todos los programas y que se distinga según la variable JCL PROGNAME, en este entorno de investigación y desarrollo y para fines documentales, cada programa tiene su propio job de compilación en &LIBPREF..JCL(C&PROGID.D)

2) Job de ejecución. En este caso es obligado que cada programa tenga su propio job de ejecución en &LIBPREF..JCL(E&PROGID.D)

Para un programa convertido se tienen los correspondientes dos jobs1) Job de compilación, cuyos pasos varían según el programa sea con o sin CICS. Aunque la mejor práctica es

que haya un job de compilación (según el tipo de programa) que funcione para todos los programas y que se distinga según la variable JCL PROGNAME, en este entorno de investigación y desarrollo y para fines documentales, cada programa tiene su propio job de compilación en &LIBPREF..JCL(C&PROGID.G)

2) Job de ejecución. En este caso es obligado que cada programa tenga su propio job de ejecución en &LIBPREF..JCL(E&PROGID.G)

Evidentemente, para ejecutar cualquiera de los jobs se requiere que se tengan todos los permisos (privilegios y/o autoridades) necesarios sobre todos los recursos involucrados y también se requiere que donde corresponda estén habilitados los recursos infraestructurales necesarios como DB2, o manejador de accesos o bases de datos o comunicador

8. ConvertidorEl convertidor es un proceso que convierte transforma programas aplicativos originales (programas COBOL-DB2 o COBOL-CICS-DB2) a programas convertidos que van a acceder a las bases de datos en el nuevo manejadorEsquemáticamente su programa es un programa COBOL y su salida es otro programa COBOL y un reporte con toda la información relacionada con la conversión.El programa original tiene que ser precompilado (separación de COBOL y SQL), compilado, linkeado para obtener un programa ejecutable y luego debe hacerse bind package y bind plan para obtener un paquete DB2 y un plan DB2. Todo esto se hace con un job de compilación DB2 (con o sin CICS según sea el caso).La ejecución del programa ejecutable COBOL-DB2 se hace mediante otro job en el que se especifican todos sus archivos de entrada y salida y sobre todo, el llamado a la ejecución mediante DB2.Los programas COBOL-CICS-DB2 se ejecutan directamente dentro de CICS mediante una transacción.En cambio, el programa convertido solo tiene que ser compilado y linkeado para obtener un ejecutable y los otros



pasos se omiten porque este programa ya no tiene sentencias SQL con acceso a DB2.La ejecución del programa COBOL-DB2 se hace mediante otro job en el que se especifican igual los archivos de entrada y salida pero ya no se hace ningún llamado a DB2. Este job convertido de ejecución se obtiene a partir del job original mediante el convertidor de jobs del sistema DBI.Los programas ejecutables convertidos desde un programa COBOL-CICS-DB2 se ejecutan también directamente dentro de CICS mediante una transacción.La conversión de programas puede hacerse masivamente a partir de todos los programas del ambiente aplicativo original. El resultado es el conjunto completo de programas en el ambiente aplicativo nuevo. Y si se hace una compilación masiva, al final se tiene el conjunto completo de programas ejecutables en el ambiente nuevo.


Documents

Manual de Técnico v.1