Bloque y Bloquecito - Arreglando bases de datos con programas C


Corrían los primeros años de los 90, y estábamos trabajando con Raúl y Gustavo en una empresa que tenía una red de 9 equipos VAX/VMS, conectados en una WAN que cubría algunos departamentos de Uruguay.   Las aplicaciones estaban programadas en COBOL y usaban una base de datos de Digital que se llamaba RDB. La interfaz de usuario era de sólo texto y se ejecutaban en terminales VT320, las cuales era terminales tontas. Recuerdo más de una vez, haber soldado los conectores a los cablecitos. El soldador y el estaño, estaban en todos los lugares donde había terminales. 

 

Después de algunos años de encargarnos del desarrollo de un grupo de empresas habíamos logrado una automatización bastante buena. Teníamos scripts que corrían de noche y compilaban todo lo que se había modificado en el día, avisaban cuando algo daba errores. 

 

Como dije antes, usábamos RDB que fue una base de datos relacional, que era buena, pero muuy lenta. Usaba SQL y otro dialecto anterior (RDO) para la consulta de datos.   Hoy es una lengua muerta, pues le gano SQL, pero en vez de DELETE, se escribía REMOVE, en vez de INSERT, se ponía STORE, y MODIFIY, en vez de UPDATE. 

 

El problema

Un día nos llamaron de la empresa que tenía la base de datos mas grande (siempre pasan en las más grandes), que un programa de impresión de asientos cancelaba. 

En esa época, la Dirección General Impositiva exigía que las empresas entregaran los libros contables impresos y copiados. Eran resmas y resmas de papel que nadie leería jamás. 

 

El programa que cancelaba, lo que hacía era leer datos históricos e imprimía en una impresora muy rápida, que hacia un ruido espantoso (tenía una aislación especial para el sonido).  Cuando fuimos a ver la causa de la cancelación vimos que el problema era que un sector de la base de datos, estaba dañada y el checksum daba errores. La solución que recomendaban los manuales (en esa época no había internet y teníamos que leer manuales) era levantar un backup  de la base y aplicar los cambios desde la fecha del backup, hasta el último cambio.  Los discos de esa época no eran tan confiables como los de ahora, por lo que este procedimiento ya lo teníamos bastante practicado. 

 

Teníamos un plan de backup bien pensado, por lo que teníamos cambios de los últimos 15 días, y cintas de backup mensuales hasta 6 meses para atrás y otras anuales. 

 

Cuando empezamos a levantar backup viejos, con terror, vimos que las bases de datos restauradas, también tenían la misma página corrupta. O sea, el backup no hacia ningún chequeo de si la páginas salvadas dañaban, por lo que teníamos un problema grave. 

 

Después de varios días de restaurar base de datos, encontramos una base de más de 6 meses atrás, que no tenía ninguna pagina corrupta. No teníamos los archivos de transacciones realizadas desde hacía tres meses, pero era un comienzo. 

 

Podíamos ver que haciendo un select de una tabla daba un error al llegar a determinado registro en la base actual (con la pagina corrupta) y no daba en la base de datos vieja (levantada del backup).  Por suerte, era un dato que no había sufrido modificaciones en los últimos tiempos, porque era asientos contables de periodos cerrados.  Si hubiese sido en alguna tabla mas usada, hubiésemos detectado antes el problema. 

 

Con este panorama, nos enfrentamos al dilema, de copiar una página de la base de datos vieja, y sobreescribir la base de datos actual.  De mas esta decir, que nada de esto podía realizarse con las herramientas y/o utilitarios de la base de datos, pues todo programa de RDB que pasara cerca de la pagina corrupta, cancelaba. 

 

La solución

Con paciencia, tiempo y ayuda del soporte de Coasin (empresa que daba soporte a VAX/Digital en Uruguay),  nos pusimos a programar en C, para lograr leer un sector de disco (donde estaba la base de datos vieja) y guardar el contenido del mismo.  Este programa se llamo BLOQUE.

Luego había que hacer otro programa que permitiera escribir el contenido de esa pagina, a otro sector del disco (donde estaba la base actual), que se llamó BLOQUECITO

 

No me pregunten porque elegimos esos nombres, estábamos muy cansados en ese momento. 

 

Después de MUCHAS corridas y MUCHOS cálculos en hexa, para poder calcular la posición exacta del bloque en el disco, pudimos remachar el contenido de la página correcta, sobre la base de datos dañada  y logramos eliminar la  página corrupta. 

 




Comentarios

  1. Fantástica la historia.
    Esta bueno estar "cerca del hardware" a veces...

    ResponderBorrar
  2. Que historias las de Digital !!!
    Recuerdo haberme pasado toda una noche levantado AIJs, porque los señores encargados del Backup hacía 6 meses que no respaldaban la base entera porque "era muy grande".
    De todos modos una maravilla RDB y Rally (que era un 4GL para desarrollar aplicaciones).
    Algo que me quedó siempre del VMS y no se ve actualmente eran las versiones de los archivos, guardadabas cualquier cantidad de versiones y siempre podías echar mano a las anteriores. Cuando no las necesitabas más dabas PURGE / KEEP=n y te quedabas solo con las ultimas n.

    Que tiempos!!

    ResponderBorrar
  3. Este blog ha sido eliminado por un administrador de blog.

    ResponderBorrar
  4. Gabriel:
    El File System de VMS, es el mejor con el que he trabajado. Era jerarquico, soportaba versiones de archivos, era rapido para busquedas... De lo mejor en lo que he trabajado.

    Tambien recuerdo el excelente manejo de "nombres logicos", que eran especies de variables de ambiente, a nivel de sistema o de usuario, lo cual permitia definir sistemas muy dinamicos y adaptables.

    Un buen sistema operativo que quedo por el camino.

    ResponderBorrar
  5. Decir que OpenVMS todavía está dando caña. Mi trabajo consiste en manter servidores VMS y si algo he de destacar de este sistema operativo (que puede ser todo) me inclino por el protocolo de red DECnet y el sistema de clustering, no superado por nadie a día de hoy.

    ResponderBorrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.