Estrategias de Desarrollo

Conversin del acceso a Datos

Roadmap IBM

WDSC: Websphere WebProductores Developmet Cliente Studio Client interno

Objetivo
Es una generar una aplicacin Web orientada a la empresa, que permita tomar ventajas de la escalabilidad y flexibilidad que ofrecen las tecnologas modernas, tanto en hardware como en software. Adaptando el acceso a Base de datos y las practicas de desarrollo para que acompaen los cambios del negocio.

Mejores Herramientas (Better tools)

Unificar y modernizar el Workbench de desarrollo para todo las tecnologas, RPG, COBOL, JAVA, SQL, etc.

Mejorar la interfaz de usuario (Better user interfase)

IBM WebFacing Tool for iSeries WebSphere Host Access Transformation Services (HATS) iSeries Access for Web Las tres herramientas permiten modernizar y extender la vida util de las aplicaciones 5250.

Mejorar la arquitectura Better Architecture

Es el primer paso para el rediseo de nuestras aplicaciones
Objetivos
Modularizar Separar las reglas de negocio de la interfaz Aislar las funciones de acceso a la base de datos e impresin Trasladar lgica que historicamente fue escrita dentro de la aplicacin y que puede trasladarse a la base de datos (Reglas de integridad referencial, procedimientos almacenados, triggers, etc)

Modernizar usando SQL

Razones del cambio
Estandarizacin Performance Desarrolladores, mayor posibilidad de encontrar skills de desarrollo en SQL vs. RPG Funcionalidad Integridad de datos Acceso a herramientas de no-IBM

Conversin - Terminologa

Consideraciones

Metologa propuesta por IBM

FASES
1.

2. 3. 4.

Aplicar ingeniera inversa para convertir DDS a definiciones SQL (DDL) Crear mdulos de acceso a BD DB2 Mover las reglas de negocio a la base de datos Implementar funciones avanzadas de base de datos

CMO?

FASE I :Reemplazo de DDS por estructuras SQL

Pasos 1. Clasificar el ambiente existente 2. Establecer la lista de DDS a ser convertidas y medir esfuerzo 3. Establecer la convencin de nombres SQL a utilizar 4. Convertir las DDS a DDL SQL 5. Revisar las descripciones generadas con DDL 6. Crear un nuevo esquema DB2 (biblioteca) 7. Re-Crear todas los indices existente sobre las tablas SQL 8. Migrar los datos y testear las aplicaciones existentes

1.Clasificar el ambiente

2. Seleccionar DDS
select table_name, table_type, file_type from qsys2.SYSTABLES where table_schema = 'APILIB' and table_type = 'P' and file_type = 'D' order by table_name

Archivo fisico

Q lgicos

Q programas Inicio

Fin

Dias

3. Convencin de nombres
Evite utilizar el tipo de objeto, como parte de el nombre del objeto. Por ejemplo, no use las palabras FILE, TABLE, INDEX o como parte del nombre. Utilice el nombre de tabla y un sufijo para SQL ndices. No se preocupe acerca de la longitud del nombre ya que los ndices no pueden ser especificados en una sentencia SQL. En el servidor iSeries, Proporcionar estadsticas de los ndices y se puede utilizar para ejecutar una consulta. Por ejemplo, CUSTMST_X001 es una indice radix de CUSTMST, o CUSTMST_V001 es un ndice de tipo Vector Encoded de CUSTMST. Usar los sufijos para los cdigos de aplicacin

4.Conversin DDS a DDL SQL

iSeries Navigator
- Generar SQL -- Generar SQL -- Versin: V5R4M0 060210 -- Versin: V5R4M0 060210 -- Generado en: 20/03/08 12:55:16 -- Generado en: 20/03/08 12:52:47 -- Base de datos relacional: LMA730 -- Base de datos relacional: LMA730 -- Opcin de estndares: DB2 UDB iSeries -- Opcin de estndares: DB2 UDB iSeries

API QSQGNDDL que puede ser llamada directamente desde un CL

CREATE TABLE COBDBF.COCAJAF ( CREATE VIEW COBDBF.COCAJAL1 ( -- SQL150B 10 REUSEDLT(*NO) en tabla COCAJAF de COBDBF ignorado. -- SQL1506 30 Clave o atributo para COCAJAL1 de COBDBF ignorado. CEMPRES NUMERIC(2, 0) NOT NULL DEFAULT 0 , CEMPRES , CSUCURS CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CSUCURS , CTCAJA CHAR(5) CCSID 284 NOT NULL DEFAULT '' , CTCAJA , NCAJA DECIMAL(8, 0) NOT NULL DEFAULT 0 , NCAJA , FCAJA DATE NOT NULL DEFAULT CURRENT_DATE , FCAJA , CCAJERO CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CCAJERO , FCIERRE DATE NOT NULL DEFAULT CURRENT_DATE , FCIERRE , NMINUTA DECIMAL(8, 0) NOT NULL DEFAULT 0 , NMINUTA , CEST_CA CHAR(10) CCSID 284 NOT NULL DEFAULT '' , CEST_CA ) -- SQL150D 10 VALUES de columna CEST_CA ignorado. AS PRIMARY KEY( CEMPRES , CSUCURS , CTCAJA , NCAJA ) ) SELECT CEMPRES , RCDFMT COCAJAR ; CSUCURS , CTCAJA , LABEL ON TABLE COBDBF.COCAJAF NCAJA , IS 'Archivo de Cajas.' ; FCAJA , CCAJERO , LABEL ON COLUMN COBDBF.COCAJAF FCIERRE , ( CEMPRES IS 'Empresa Recaudadora' , NMINUTA , CSUCURS IS 'Cdigo de Sucursal' , CEST_CA CTCAJA IS 'Tipo de Caja' , -- SQL150D 10 VALUES de columna CEST_CA ignorado. NCAJA IS 'Nmero de Caja' , FROM COBDBF.COCAJAF FCAJA IS 'Fecha de Apertura de Caja' , CCAJERO IS 'Cdigo de Cajero' , RCDFMT COCAJAR ;

5. Revisin de DDL
Palabras claves no soportadas Salvar Error de nivel (opciones)
Recompilar con LVLCHK(*NO) OVRDBF LVLCHK(*NO) CHGPF LVLCHK(*NO) OJO!! Los resultados a futuro pueden ser impredecibles

Nombre de formato de registro

Solucin para conservar el nombre de registro
1. 2. 3.

CREATE TABLE COBDBF.COCAJAR ... RENAME TABLE COBDBF.CACAJFR TO CAJAS RENAME TABLE CAJAS TO SYSTEM NAME COCAJAF

Nombre de columnas

6.Crear un nuevo Esquema

CREATE SCHEMA crea los siguientes objetos AS/400:
Biblioteca OS/400 journal and journal receiver DB2 views containing schema-wide catalog

7.Re-Crear todas los indices existente sobre las tablas SQL

Luego de creado el nuevo esquema se deben usar los script SQL revisado para crear las nuevas tablas e ndices. Adicionalmente se deben crear los LF para que los programas existentes (HLL), asegurndose que todos los LF compartan la misma va de acceso que los ndices SQL.

CMO?

Pasos para recrear LF

a)

b)

CREATE TABLE tabpf_sql (tabpf ser el nombre corto original) Modificar DDS de LF para referenciar al nuevo fsico.
R Nombre_reg pfile(tabpf_sql) format(tabpf)

a)

Los pasos anteriores aseguran que labelchek es el mismo entre lgico y pgm, por lo tanto el programa no no necesita ser recompilado y tomar las ventajas de un acceso mas rpido en ndices muy grandes.

(Para detalles ver sg246393.pdf pgina 61).

8.Recrear los datos existentes

Se debe armar un conjunto de aplicaciones para migrar los datos (CL, CPYF *MAP, SQL, etc) Validar datos Testear las aplicaciones Mover los nuevos esquemas del ambientes de Testing al ambiente productivo
Lo mejor es mover el esquema al ambiente produtivo y ejecutar todos los script de creacin nuevamente Si no es posible se puede salvar y restaurar el esquema desde el ambiente de Test al productivo.

SAV AND RESTORE SCHEMMA

1. 2. 3. 4. 5.
1.

En ambiente de Test SAVLIB TEST ACCPTH(*YES) En produccin CREATE SCHEMA PROD. RSTLIB TEST OPTION(*NEW) RSTLIB(PROD). Buscar en Test todos los objetos que se encuentran bajo Journal Asociar en produccin las tablas a los journal
STRJRNPF PROD/Tabla1 PROD/QSQJRN IMAGES(*BOTH) OMTJRNE(*OPNCLO) STRJRNPF PROD/Tabla2 PROD/QSQJRN IMAGES(*BOTH) OMTJRNE(*OPNCLO)

2.

DIFERENCIAS ENTRE PF, TABLAS SQL

Ventajas
Las restricciones (constraint) estn incluidas en el objeto tabla SQL Lee mas rpido que comparado con la lecturas desde un lenguaje de alto nivel (HLL) Es posible colocar nombre mas descriptivos a los nombres de columnas El modelado de datos puede realizarse con herramientas que soporte SQL Se asocian automaticamente a journal las tablas creadas en un nuevo esquema

Desventajas
La escritura es mas lenta que con sentencias Write de HLL No hay soporte de DDM pero SQL can utilizarse distrubuido con SQL CONNECT Tablas SQL no soportan multi-miembros pero pueden usarse ALIAS.

DIFERENCIAS ENTRE LF E INDICES

La mayor diferencia es en la tecnologa que estn diseados los indices de bsquedas. Los ndices utilizan Encoded Vector Indexes (EVIs) con pginas de 64k mientras que los LF bitmap indexes DE 8k. Ventajas
Mayor rendimiento en bsquedas con gran volumen de datos

Desventajas
Mayor requerimiento de memoria No tienen soporte de la clausula SELECT y OMIT

Vistas SQL vs LF
Las vistas SQL son como LF sin claves.
Ventajas
Las vistas son mas flexibles en trminos de seleccin y procesamiento de datos. Se permiten clusulas CASE y funciones DATE/TIME Las clusulas de agrupamiento y join que ofrecen las vistas son mas potentes que los LF Los programas nativos pueden abrir vistas como LF

Desventajas
Las vistas SQL, no pueden ser con clave SQL no pueden reemplazar archivos lgicos con multiformato

Tipos de datos SQL

En las columnas de tablas SQL se soportan mas tipos de datos como LOB (large object), datalinks y tipos definido por el usuario. Las columnas soportan nombres hasta 30 caracteres de longitud y las tablas hasta 128. Es posible particionar por temas de performance tablas de datos de gran tamao.

MODERNIZANDO EL ACCESO A LOS DATOS

Cmo crear mdulos I/O para acceder a los nuevos objetos SQL? Cmo comenzar a mover las reglas de negocio a la base de datos? Cmo tomar ventaja de uso de SQL embebido para reemplazar sentencias tradicionales de I/O? Cmo aprovechar y explotar las ventajas de triggers, procedimientos almacenados y funciones de usuario?

Mdulos I/O para acceder a los nuevos objetos SQL

ESQUEMA OBJETIVO

Crear mdulo I/O de acceso a BD

Pasos requeridos
1. Establecer reglas de nombrado 2. Crear vistas SQL basadas en requerimientos del negocio 3. Crear programas de servicio que accedan a los datos desde las vistas SQL 4. Convertir los programas legacy para que utilicen los programas de servicio.

3. Crear programas que accedan utilizando views

Imaginar la lgica solo con RPG...

4.Externalizar el acceso a base de datos I/O

No se necesitan convertir todos los programas Los candidatos son:
Pgm que usen OPNQRYF (utilizan el viejo motor CQE en lugar del nuevo SQE) PGMs que hacen lecturas y escrituras masivas en batch. Programas que controlan existencia de registros Programas que podran beneficiarse con el uso de JOIN Programas que llenen un subfile con criterios complejos