Serie ficheros virtuales

 

 

 

 

C Ficheros virtuales

 

 

 

 

A.I.10 Apunte de desarrollos adicionales (En la línea C ANSI)

 

 A.I.10.1 Apunte de desarrollos

 A.I.10.2 Estrategia del cambio

 

                                                                                                   _______

 

A.I.10.1 Apunte de desarrollos

 

Siguiendo las herramientas disponibles en aplicaciones de bases de datos físicas, SRAGM/SRRCW está abierto a desarrollar rutinas tales como:

 

SWAP Para intercambiar fragmentos de un fichero por clave

 

FILL Para inicializar un rango de ítems de un fichero

 

INTERSECTION Para intersecar ficheros

 

MERGE Para mezclar ficheros

 

DELETERANGE Para borrar por rangos completos de clave en un fichero

 

etc., que complementen a las actuales funciones globales, que se han ido desarrollando como rutinas complementarias según iban surgiendo las necesidades que las requerían y que se citan a continuación

 

SRRCW_CLRF Limpia el contenido actual de una base de datos

 

SRCW_CPY Copia el contenido de un fichero a otro

 

SRRCW_DUP Duplica una base de datos

 

SRRCW_SAVF Salva un fichero virtual a respaldo físico

 

SRRCW_RSTF Recíproca de SAVF

 

                                                                                                   _______

 

 

Por otro lado, es propósito del autor evolucionar la aplicación para convertir el desarrollo que da soporte al enlace de ficheros físicos y lógicos a un funcionamiento igual al de los verdaderos índices secundarios, sin la replicación de datos del mecanismo equivalente actual, desarrollando a la vez una indexación de doble nivel para minimizar los desplazamientos de inserción de datos y claves.

Sólo modificando ambos puntos simultáneamente se puede alcanzar un verdadero grado de optimización como se apuntó en el capítulo de caché.

 

También se indicó entonces que estas optimizaciones no son necesarias para tratamientos ordinarios, pero ciertas aplicaciones de cálculo financiero que se van extendiendo cada vez más por iniciativa oficial, incorporan cálculos estadísticos tales como matrices de correlaciones que llegan a involucrar centenares de miles de cálculos y en donde los procesos son sensibles a cualquier optimización.

 

A nivel de usuario estas mejoras son transparentes, puesto que el interfaz final no se vería afectado; sin embargo, otros desarrollos que si implicarían evolución de interfaces, concretamente del prototipo del módulo de Creación de Lógicos, sería la inclusión de condiciones de selección/omisión, implementaciones que se plantean al abordar situaciones prácticas que surgen al utilizar el producto de forma cotidiana, y cuya resolución quedaría más elegante y resultaría más efectiva si el tratamiento de selección/omisión se integrara en el producto en vez de llevarse a cabo por fuera.

 

En esta línea se puede avanzar de forma natural y desarrollar ficheros fuente de diseño de bases de datos, y utilidades que los exploten, para generar las estructuras y sus instrucciones de definición a integrar en los programas, sin necesidad de teclearlas manualmente.

Además, esta vía abre la perspectiva de poder desarrollar herramientas de tipo sql virtual.

 

 

Hablando específicamente para la plataforma iSeries, las definiciones se podrían tomar directamente del código fuente de definición de archivos estándar.

 

En este mismo entorno, pueden crearse mandatos como CRTVF para crear ficheros virtuales “físicos”, equivalente al CRTPF del OS/iSeries y un CRTLVF para crear ficheros virtuales “lógicos” también al estilo del CRTLF del sistema operativo, para crear los ficheros a nivel de trabajo en un CL de control y utilizar las herramientas apuntadas a nivel de programa RPG para desarrollos que compartan ficheros de la misma forma que se hace con sus equivalentes físicos, ganando mayor versatilidad.

 

 

En otro orden de cosas, los capítulos de la zona B del libro no tienen la amplitud de desarrollo de los primeros capítulos; es una deficiencia que se irá corrigiendo, aunque de forma simultánea con el desarrollo de la serie dedicada a los ficheros virtuales en distintos lenguajes que se lleva a cabo en el sitio ficherosvirtuales.com

 

 

                                                                                                   _______

 

A.I.10.2 Estrategia del cambio

 

Cuando un programa resulta tan útil se vuelve crítico porque se incorpora en multitud de procesos, dando más fruto cuanto más complejos sean estos, por su virtud de simplificación.

 

Por tanto, su cambio es delicado y exige una estrategia rigurosa.

 

En primer lugar, los cambios deben probarse exhaustivamente en el PC. Así, se debe superar la criba de mantener la integridad de los ejemplos que se presentan en el libro y otros adicionales dedicados al cálculo financiero avanzado en instrumentos de contado y derivados.

 

A continuación se transporta el desarrollo a los sistemas host iSeries, en donde se somete a varias etapas de prueba antes de la aplicación en explotación.

 

Primero, en un primer sistema de desarrollo iSeries, el nuevo producto debe superar un extenso banco de pruebas de integridad, una versión evolucionada del programa PruebasW que se presenta en los anexos del manual de usuario diseñada para pruebas industriales, que repasen en diversos bucles todos y cada uno de sus sistemas, verificando los resultados y sus tiempos de respuesta.

 

Seguidamente, el nuevo producto debe aplicarse a un entorno de verificación de desarrollo en donde se repiten las mismas pruebas y además también se aplique a sistemas y procedimientos reales representativos, sobre datos de prueba en situaciones de gran volumen. Es lo que se denomina comúnmente como la etapa de pruebas de calidad del desarrollo.

 

A continuación, el nuevo desarrollo se aplica a un entorno de pruebas, pero ya de usuario y en el sistema iSeries de explotación para las pruebas finales.


Sólo después de superar los pasos anteriores se puede aplicar como módulo real en explotación, sobre entornos reales.

 

De hecho, si se produce alguna incidencia en alguno de los pasos citados se debe volver a comenzar desde el principio, reelaborando las pruebas de cada etapa para que filtren la anomalía desde el inicio.

 

Aunque llega un momento del desarrollo en que los cambios son mínimos y puede parecer que estas reglas devienen en una mera imposición teórica pues, en la práctica, superados los bancos de pruebas del PC y del entorno de compilación no se producen sorpresas ni en el entorno de validación ni en el de pruebas, el esquema debe seguirse rigurosamente, convirtiendo esta estrategia de prudencia en un mecanismo automático, obteniendo así un colchón de seguridad vital frente a los cambios.

 

                                                                                                   _______