Hace 15 años | Por --87131-- a eltamiz.com
Publicado hace 15 años por --87131-- a eltamiz.com

[c&p] Hoy vamos a ahondar en un tema común a todas ellas, pero que, por algún motivo, pocas veces se tiene en cuenta en la formación de las nuevas generaciones de Informáticos: la Ventana Batch. Bueno, no me limitaré a hablar de la Ventana, sino también del propio diseño de los procesos batch. Es exactamente lo mismo si hablamos de Bases de Datos Relacionales que de No-Relacionales, con todas ellas habrá que tener en cuenta qué hacer cuando hay procesos batch que ejecutar contra esas Bases de Datos.

Comentarios

LadyMarian

Echo on
"Pero aseguro que era un tostón escribir programas así."
REM Sí, pero también era divertido y controlabas tú los procesos más de lo que haces ahora"
ECHO OFF

AlphaFreak

Muy buena entrada, como todas las de la serie... pero creo que nuestro amigo ha exagerado un poco cuando se refiere a la tremenda dificultad de hacer convivir el Batch con el Online.

Como siempre, se trata de tener las herramientas correctas. En el mundo del mainframe, esa "herramienta" se llama IMS...

Desde hace décadas existen los procesos BMP (Match-Message Program) capaces de tratar "como un online" los procesos batch. El control de rearranque es automático (el programador sólo tiene que llamar a unas APIs en el inicio del proceso, y codificar un área de E/S que contiene la información de "checkpoint" que se guarda en cada COMMIT). Parece complicado, pero no lo es tanto. Los BMP rearrancables son relativamente sencillos de construir. Como la mayoría de cosas en el mundo mainframe, alguien programó hace años "EL" proceso rearrancable, y a partir de ahí CC..CC

Incluso mezclar diferentes subsistemas es relativamente sencillo. En una instalación típica hablaríamos de IMS/DB, DB2, MQSeries y ficheros "planos"... todos ellos con integridad "transaccional" (en caso de uno de esos terribles casques el sistema hace rollback de todo hasta el último checkpoint).

Lo que tiene una cierta gracia es diseñar para evitar tener que cerrar en algún momento las bases de datos. Por ejemplo: es necesario tener una imagen "consistente" de todas las cuentas de ahorro a final de día. Tradicionalmene, se cerraría la aplicación, se haría un volcado y se volvería a abrir. Hoy en día eso no se puede hacer (24x7...), por lo que hay que usar truquitos diversos. En una gran, gorda y conocida institución financiera española el "cierre" de bases de datos dura menos de un segundo.

Finalmente, lo que es absolutamente cierto es que el tema de los bloqueos es una putada. Puedes tener un sysplex de tropecientas vías y ver cómo el tiempo de respuesta de tu online empieza a degenerar porque algún analisto ha diseñado una aplicación alrededor de un contador único en alguna tabla o base de datos... diseño que funciona de coña en tiempo de desarrollo y pruebas, pero que se convierte en una bomba de tiempo cuando pasas a producción y te están entrando 2000 tx/s. Puedes meter todos los MIPs del mundo, pero tu rendimiento seguirá siendo una porquería si esas 2000 tx/s tienen que serializarse!

A quien le suene a "batallitas del abuelo": probablemente en este mismo momento hay ALGUIEN analizando un problema de bloqueos así en alguna instalación de este país.