Tanto quienes emplean DB2 para crear archivos como quienes se manejan a través de DDS, utilizan los valores por omisión para crear archivos físicos. En los valores por omisión el sistema operativo establece que el archivo va a tener un solo miembro.
Los archivos lógicos que son creados posteriormente, “apuntan” a ese miembro.
Un miembro es un espacio del archivo físico, al cual se le asigna un nombre para guardar información relacionada entre si. Por ejemplo, si deseo guardar la información contable del mes de ENERO, realizo un ADDPFM (añadir miembro) y lo llamo enero. Entonces el archivo físico tendrá un “sector lógico” asignado al mes de enero. Cuando ejecuto un programa que graba sobre ese archivo, dependiendo de la fecha de la data, puedo realizar un ovrdbf sobre el miembro ENERO y todos los write/update van a grabar en ese “sector” del archivo físico.
A medida que pasan los años, la data va creciendo y se va almacenando en el archivo, información de hace 3,5,8,10 y mas años.
Los procesos nocturnos generalmente requieren o lo registros del día o del mes. En casos excepcionales o en cierres anuales se necesita la información de todo un año.
Los procesos nocturnos se hacen cada vez mas lentos, y comandos como Reorganizar archivo RGZPFM, para reutilizar el espacio dejado por registros eliminados y CHGPF con reuse = *yes van perdiendo efecto. La reacción inmediata de los líderes de proyectos y analistas de desarrollo es impedir o limitar la creación de archivos lógicos. Se ejecutan entonces sentencias SQL y Queries, tratando de no incrementar los tiempos de respuesta. Mientras tanto los archivos siguen creciendo a medida que el tiempo pasa y eventualmente todas las curas provisionales que hemos colocado nos dejan igual que hace un año cuando se pudo “contener” el problema sin resolverlo en realidad.
En varias organizaciones donde los sistemas tienen varios años funcionando, se ha optado por trabajar con más de un miembro en un archivo. Cada miembro almacena data de un intervalo de años definido por la gerencia.
Este método de utilizar miembros agilizaría los procesos diarios que requieren un tiempo de respuesta rápido. En lugar de direccionar los lógicos a un miembro que contiene data de hace 15 años, se direcciona el lógico a un miembro que contiene data del año en curso. El tiempo de respuesta se acelera dramáticamente.
Puede ser que, en los procesos de apertura del nuevo año, se debe incorporar, para los archivos de data que están en esta modalidad, una evaluación automatizada que añada el miembro que sea necesario si se da el caso. Por supuesto, con un sistema parametrizado, no sería necesario recompilar todos los programas RPG, CLP e ILE RPG involucrados.
No habría que modificar programas de consulta, mantenimientos ni reportes en RPG habría que agregar mas bien rutinas modulares utilizables por cualquier programa que sean capaces de realizar el ovrdbr al miembro que se necesita según la información solicitada por el usuario. Con este sistema, se tiene en disco la data activa y puede cumplirse con normas gubernamentales rápidamente sin tener que bajar y subir backups.
Autor: Ing. Liliana Suárez.
Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.
Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.
No comments:
Post a Comment