BIZPRO Sistema DBI - SQLFire

Manual Tcnico
Version 1.0

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

Historial de Revisiones
Fecha

Confidencial

Versin

Descripcin

2015

Autor

Page 2

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

Tabla de contenido
1.

Introduccin

2.

Implementacin sistema DBI

3.

Requerimientos

4.

Manejo de accesos

5.

Comunicador

6.

Convertidor

7.

Ejecucin de Jobs

8.

Convertidor

Confidencial

2015

Page 3

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

Test Plan
1.

Introduccin
Se brinda informacin tcnica til para hacia los administradores y programadores del sistema

2.

Implementacin sistema DBI

Sea cual sea el avance en En cualquier etapa de la fase de investigacin del proyecto y suponiendo considerando
que la estrategia de desviacin ha sido exitosa, an as se ha operado sobre muy pocos programas
Por 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 produccin 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 situacin 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 estn incluso en otra plataforma.

Confidencial

2015

Page 4

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

Para alcanzar este punto debemos esta situacin 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 conversin masiva de programas fuente (ambiente origen a
ambiente alterno) del ambiente original al ambiente alterno. Esto se hace con la aplicacin repetida del convertidor
de tipo igual al tipo del comunicador implementado implantado

Confidencial

2015

Page 5

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

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 conversin masiva de jobs de ejecucin. Esto se hace mediante la aplicacin
repetida de un convertidor de jobs, el cual tiene que ser desarrollado e implementado implantado previamente

Confidencial

2015

Page 6

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

***Despus sigue la migracin de datos de las bases de datos DB2 objetivo. Esto se hace mediante la aplicacin
repetida de un migrador de datos, el cual tiene que ser desarrollado e implementado implantado previamente

Confidencial

2015

Page 7

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

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

As que en En trminos generales, general, ya se lleg ha llegado a la instancia situacin esperada.

Confidencial

2015

Page 8

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

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 desaparecern por supuesto van a desaparecer cuando el
DB2 sea proscrito.
Este mecanismo debe aceptar aceptar la entrada manual de sentencias SQL, su envo al comunicador va socket, y
luego la recepcin del resultado tambin va socket, as como y su escritura en un archivo de salida.
Tambin hay que Se debe liberar un mecanismo para tener acceso a las bases de datos por ejecucin 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 automtico de jobs como la implementacin implantacin de programas sustitutos
DSNTEP2, DSNTIAD, DSNTIAR o DSNTIAUL.
Con esto resulta Como resultado de que los dos procesos ilustrados a continuacin y usando como ejemplo
DSNTEP2 son totalmente equivalentes.

Confidencial

2015

Page 9

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

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 implantacin
implementacin:
- 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
Confidencial

2015

Page 10

Documentacin
Manual Tcnico
-

3.

Versin:
1.0
Fecha: Septiembre - 2015

El cdigo del comunicador debe estar protegido, por ejemplo, habiendo si ha sido programado en lenguaje
C o mediante un enmascarador de cdigo java, de modo que cualquier mdulo instalado en la
infraestructura del cliente sea un ejecutable indescifrable
El cdigo del convertidor debe estar protegido, digamos, usando REXX compilado, de modo que cualquier
mdulo instalado en la infraestructura del cliente sea un ejecutable indescifrable
El cdigo del convertidor de jobs de ejecucin igual debe estar protegido, digamos, usando REXX
compilado, de modo que cualquier mdulo instalado en la infraestructura del cliente sea un ejecutable
indescifrable
El cdigo del migrador de bases de datos igual debe estar protegido, digamos, usando REXX compilado, de
modo que cualquier mdulo 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

Requerimientos

Como 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 aplicativo
Los 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 va data-source.
Y en otro entorno distribuido se requiere la ejecucin del manejador de accesos y del comunicador mediante java,
garantizando que tengan comunicacin va socket.

4.

Manejo de accesos

El 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 prrafo NWCOMAX1 est vaco.
3) El prrafo run recibe una peticin y devuelve una respuesta va socket.
4) Debido a que este programa ignora totalmente el mensaje de peticin, ste es la cadena constante
TESTPROGRAMX . Por supuesto que un manejador de accesos con la funcionalidad total debe
considerar el layout de la peticin de servicio con informacin relevante y debe coordinarse desde su envo
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 direccin IP y el puerto
para acceder a un comunicador disponible. El penltimo carcter % es el delimitador de registro y el
ltimo carcter ( es el indicador de fin de respuesta.
6) El prrafo sendMessage escribe la respuesta para su devolucin va socket.
7) El prrafo 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 implementacin implantacin de este manejador de accesos, se debe asignar con toda anticipacin la
direccin y el puerto en que va a atender, pues en este estado del sistema, esta direccin y puerto del sistema se
asigna en cdigo duro a todo programa convertido.
De ser necesario, como una alternativa, se debe idear un mecanismo de para indicar en forma dinmica a los
programas en ejecucin, la direccin y puerto donde van a conectarse con el manejador de accesos.
El desarrollo e implantacin del manejador de accesos est ms all del alcance de este proyecto y es
responsabilidad del grupo tcnico de BizPro enfocado a GemFire
Confidencial

2015

Page 11

Documentacin
Manual Tcnico

5.

Versin:
1.0
Fecha: Septiembre - 2015

Comunicador

El comunicador es un programa java NWCOMBX1.java que est en un servidor distribuido y del que hay que
destacar los siguientes puntos:
El prrafo NWCOMBX1 inicia la conexin va data source con el nuevo manejador de bases de datos.
El prrafo run recibe una peticin, la enva al prrafo procstmt, espera un resultado y devuelve una respuesta va
socket.
La peticin 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 enva la sentencia al prrafo
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 tamao en que se devuelve y los datos restantes
quedan almacenados en memoria para ser a su vez enviados en una ocurrencia posterior de FETCH
El prrafo sendMessage escribe la respuesta para su devolucin va socket.
El prrafo main ejecuta NWCOMBX1 (que hace la conexin 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 prrafo 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 prrafo procstmt
inmediatamente (en el caso de SELECT) o en partes (en el caso de FETCH).
El desarrollo e implantacin del manejador de accesos est ms all del alcance de este proyecto y es
responsabilidad del grupo tcnico de BizPro enfocado a GemFire.
Aunque todo programa que sustituya al comunicador debe satisfacer la premisa bsica de la eficiencia, es decir,
mientras este programa sea el ms rpido debe seguir siendo usado.

6.

Convertidor

El 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
tambin).
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 prrafos del programa REXX tiene un mensaje indicando lo que hace.
Como resultado, tambin queda como salida un archivo reporte.
&SYSUID..PS.NWCONVX1.&PGMNAME..F&FECHA..H&HORA. En este archivo se lista el resultado parcial de
cada prrafo. Este resultado parcial consiste la mayora de las ocasiones en el llenado de matrices con informacin
del programa, hasta una matriz final que como ltimo paso es escrita fsicamente en el programa convertido Este
reporte facilita las tareas de programacin, depuracin y correccin de fallas.
Para fines documentales aqu se listan los prrafos del convertidor
000_MAIN. Es el flujo del programa
100_INICIO. Tareas iniciales
110_FIXPAR. Parmetros fijos para configuracin del proceso
120_VALINI. Validaciones iniciales
130_BORRA. Elimina el programa convertido en versiones viejas
Confidencial

2015

Page 12

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

140_CLOSE. Cierra archivos que pudieran estar abiertos

150_VARPAR. Parmetros variables para configuracin del proceso
200_PROCESO. Propiamente es el flujo de la conversin
210_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 tambin son recorridos) y cuando encuentra sentencias SQL las
unifica en una sola lnea. Este prrafo 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 numeracin consecutiva. Cada
elemento tiene una lnea de texto del respectivo componente. Como se acostumbra en REXX,
TEXT.&nombreobjeto..0 almacena la cantidad de elementos en la matriz correspondiente
220_INTEGRA. Integra todos los elementos (programa, copies e includes) en un solo programa. Llena la matriz
INTEG.&contador donde contador es una numeracin consecutiva. Cada elemento tiene una lnea de texto del
programa integrado. Como es costumbre en REXX, INTEG.0 contiene la cantidad de elementos en la matriz INTEG
Adems se llena una matriz PEND con sentencias EXEC SQL DECLARE CURSOR que estn en DATA DIVISION
y que son desplazadas a PROCEDURE DIVISION
230_SQL. Extrae todas las sentencias SQL y llena la matriz SQL.&contador donde contador es una numeracin
consecutiva. Cada elemento es una sentencia SQL. Como es costumbre en REXX, SQL.0 contiene la cantidad de
elementos en la matriz SQL
240_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 numeracin 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 numeracin
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 numeracin 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 CURS
250_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 SQL
260_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 numeracin consecutiva. Cada elemento es una variable INTO. Como es costumbre en REXX, INTO.&isql..0
contiene la cantidad de elementos en la matriz INTO.&isql
270_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 numeracin 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.&isql
280_PIC. Extrae el PICTURE de las variable host de cualquier clase de las extraidas en prrafos anteriores. Llena la
matriz PIC.&varname donde varname es el nombre de la variable. Cada elemento es el PICTURE de una variable
host
281_PICS. Auxiliar del prrafo 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 segn algunas seales del propio programa. Estas condiciones
estn en &LIBREF..PARM(CLOSESOK). Llena la matriz CLOSE.&contador donde contador es una numeracin
consecutiva. Cada elemento es una condicin de cierre de socket. Como es costumbre en REXX, CLOSE.0 contiene
la cantidad de elementos en la matriz CLOSE
300_LINTO. Determina la longitud (mxima) de cada clusula INTO. Llena la matriz LINT.&isql donde isql es el
apuntador al correspondiente elemento de la matriz SQL. Cada elemento es una longitud mxima de INTO
310_DATADIV. Genera lneas con datos de variables (propias de la conversin) que van a ser insertadas en DATA
DIVISION. Llena la matriz DDIV.&contador donde contador es una numeracin consecutiva. Cada elemento es una
lnea 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
Confidencial

2015

Page 13

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

PRE.&isql donde isql es el apuntador al correspondiente elemento de la matriz SQL. Cada elemento es una lnea
COBOL
330_POST. Genera instrucciones COBOL que deben insertarse despus 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 lnea
COBOL
340_CONV. Genera el programa convertido integrando toda la informacin y lneas COBOL generadas por los
prrafos anteriores. Llena la matriz CONV.&contador donde contador es una numeracin consecutiva. Cada
elemento es una lnea COBOL del programa convertido. Como es costumbre en REXX, CONV.0 contiene la
cantidad de elementos en la matriz CONV
350_ESCRIBE. Escribe el contenido de la matriz CONV en el archivo de salida, el cual es el resultado de la
ejecucin del convertidor
832_ESCR. Escribe un registro relacionado con bloques de instrucciones COBOL insertados por la conversin
833_RPT. Escribe un registro en el reporte de la conversin que se genera para fines documentales
900_FINAL. Tareas finales. Particularmente, cerrar el reporte de la conversin

7.

Ejecucin de Jobs

Hay que recordar que un programa cualquiera se identifica por tres caracteres PROGID
Para un programa original se tienen bsicamente dos jobs
1) Job de compilacin, cuyos pasos varan segn el programa sea con o sin CICS. Aunque la mejor prctica es
que haya un job de compilacin (segn el tipo de programa) que funcione para todos los programas y que
se distinga segn la variable JCL PROGNAME, en este entorno de investigacin y desarrollo y para fines
documentales, cada programa tiene su propio job de compilacin en &LIBPREF..JCL(C&PROGID.D)
2) Job de ejecucin. En este caso es obligado que cada programa tenga su propio job de ejecucin en
&LIBPREF..JCL(E&PROGID.D)
Para un programa convertido se tienen los correspondientes dos jobs
1) Job de compilacin, cuyos pasos varan segn el programa sea con o sin CICS. Aunque la mejor prctica es
que haya un job de compilacin (segn el tipo de programa) que funcione para todos los programas y que
se distinga segn la variable JCL PROGNAME, en este entorno de investigacin y desarrollo y para fines
documentales, cada programa tiene su propio job de compilacin en &LIBPREF..JCL(C&PROGID.G)
2) Job de ejecucin. En este caso es obligado que cada programa tenga su propio job de ejecucin 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 tambin se requiere que donde corresponda estn
habilitados los recursos infraestructurales necesarios como DB2, o manejador de accesos o bases de datos o
comunicador

8.

Convertidor

El 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 manejador
Esquemticamente su programa es un programa COBOL y su salida es otro programa COBOL y un reporte con toda
la informacin relacionada con la conversin.
El programa original tiene que ser precompilado (separacin 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 compilacin DB2 (con o sin CICS segn sea el caso).
La ejecucin 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 ejecucin mediante DB2.
Los programas COBOL-CICS-DB2 se ejecutan directamente dentro de CICS mediante una transaccin.
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 ejecucin del programa COBOL-DB2 se hace mediante otro job en el que se especifican igual los archivos de
Confidencial

2015

Page 14

Documentacin
Manual Tcnico

Versin:
1.0
Fecha: Septiembre - 2015

entrada y salida pero ya no se hace ningn llamado a DB2. Este job convertido de ejecucin 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 tambin directamente
dentro de CICS mediante una transaccin.
La conversin 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
compilacin masiva, al final se tiene el conjunto completo de programas ejecutables en el ambiente nuevo.

Confidencial

2015

Page 15