Optimizar los programas COBOL

Muchas de las técnicas de codificación eficiente no pueden ser aplicadas a todos los procesos de una instalación. Sería un proyecto costoso y un riesgo para negocio modificar miles de programas en cientos de procesos.

Sin embargo pueden aplicarse perfectamente en los programas y procesos nuevos.

Hablamos de programas y procesos porque en batch están profundamente relacionados: ningún programa se ejecuta fuera de un proceso batch, sea planificado o esporádico.

La reducción del tiempo de proceso de un programa COBOL no depende solamente de la forma en que esté codificado el programa ni de la forma en que utilice la entrada / salida. También depende de cómo el compilador de COBOL de IBM haya generado el código ejecutable.

Aunque hay muchas opciones para optimizar el código compilado, vamos a centrarnos en técnicas que dependen de la codificación y la entrada / salida (las opciones de compilación tienen como audiencia no a los desarrolladores sino a personal de Soporte o de Sistemas).

Factores que afectan la velocidad de ejecución de un programa

Existe un conjunto de factores que afectan la velocidad de ejecución de un programa. Entre ellos:

La entrada / salida. Un programa batch por lo general consume y produce ficheros
El uso de bases de datos. Las bases de datos en dependencia del volumen de información a consultar/modificar tienen un tiempo de respuesta. Este tiempo de respuesta multiplicado por el volumen de registros a procesar puede representar un porcentaje importante del tiempo de ejecución del programa
Uso de memoria. El uso eficiente de la memoria de un programa comienza por utilizar los tipos de datos adecuados, tanto simples como estructurados (incluidas las tablas en memoria)
La codificación del flujo de control
La estructura o arquitectura correcta del programa para procesamiento en batch

Restricciones de diseño

Partiendo de normas aceptadas en muchas empresas y en otras instalaciones, vamos a asumir las siguientes restricciones para un programa batch:

Un programa batch no contendrá SORTs internos. Es más fácil mantener los procesos cuando tareas con grandes cantidades de datos (ordenar, filtrar, modificar, verificar) son realizadas por la utilidad DFSORT
El programa no contendrá sentencias GO TO ni GO TO DEPENDING ON. Todos sabemos el efecto pernicioso que trae el uso de estas instrucciones en la buena programación estructurada
Un programa batch por lo general consumirá datos con origen en DB2 o ficheros
El programa batch por lo general producirá datos con destino en DB2 o ficheros
Todo programa batch deberá producir estadísticas de proceso en su clase de salida de mensajes
Ningún programa batch producirá ninguna salida por la consola del operador
Ningún programa batch en entorno de Producción, producirá ningún tipo de salida por SYSOUT a menos que no sea para clarificar un error grave y antes de interrumpir de forma lógica su ejecución
Si algún programa batch tiene que clarificar sus errores lógicos sin interrumpir el proceso deberá escribir la información en su propio fichero de trazas (log). En estos casos la traza debe poder activada y desactivada por parámetros.

Partiendo de este conjunto de restricciones, ya podemos diseñar como debería ser un programa batch.

Patrón básico de diseño

Los programas COBOL se crean siguiendo el modelo elemental de procesamiento de datos: cada programa recibe unos datos de entrada, los transforma y produce unos datos de salida.

Estos tres pasos como suelen ser repetitivos se incluyen en un bucle de proceso donde las iteraciones se van a repetir mientras que existan datos de entrada que tengamos que tratar.

A este bucle de proceso se añade un paso previo para tratar o inicializar variables globales, tales como contadores de proceso, fecha del día, tratar parámetros pasados por la línea de comandos, etc.

Y por último se añade un paso final antes de terminar con STOP RUN, para escribir las estadísticas de proceso.

Un patrón básico sería:

Un esquema más detallado a partir del anterior sería:

En cuanto al tratamiento de la entrada / salida (de donde vienen los datos de entrada y hacia donde van los datos de salida), las formas más comunes son:

Entrada / Salida	Descripción
DB2 a fichero	Lectura de base de datos, procesamiento de la información y escritura de los resultados en fichero
Fichero a fichero	Lectura de un fichero de entrada, procesamiento de la información y escritura de resultados en un fichero de salida
Fichero a DB2	Lectura de un fichero de entrada, procesamiento de la información y escritura de los resultados en una base de datos

Como la lectura / escritura en base de datos tiene un coste mayor, se utilizan descargas de tablas de DB2 como ficheros de entrada para hacer más rápidos los procesos.

Eso implica que previamente tenemos que tener descargada la tabla que necesitamos antes de poder utilizarla como parte de un proceso. Estas descargas de tabla solo nos valen si tenemos que realizar consultas de datos.

Si hay que leer y actualizar datos en tablas no nos queda otro camino que acceder a DB2.

Patrón con reposicionamiento

Teniendo en cuenta la necesidad de crear programas que permitan relanzar el proceso en el paso en que se produjo un cancelamiento, tenemos que evolucionar este patrón para permitir reposicionamiento sobre los datos de entrada.