En la entrada anterior vimos cómo comenzaron a ser lo que hoy en día son las Bases de Datos Relacionales, que sustituyeron a las Bases de Datos Jerárquicas o en Red que funcionaban hasta el momento, de las que habíamos hablado en la entrada previa.
Por cierto, como la serie ya va teniendo bastantes capítulos, en esta página tenéis un enlace directo a todos los artículos publicados.
Volviendo a las Bases de Datos, y más concretamente a las Aplicaciones que en ellas se basan, 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. En esta entrada, el amigo Rabade me sugirió en un comentario que hablara de ella, y lo hago aquí, porque estoy completamente de acuerdo con él, y creo que es importante… y en cierto modo, desconocida.
En toda instalación grande se distingue entre el proceso online y el proceso batch. Esto, que es tan obvio para los viejos rockeros, no lo es en absoluto para las nuevas generaciones.
Ventana batch (recreación artística)
Casi todas las aplicaciones modernas tienen un gran (de tamaño), e importante (de… ejem, importancia), componente online, en el que se captura toda o casi toda la información, se atienden las consultas, se actualizan datos, se toman decisiones… Pero existe también la necesidad de realizar ciertos procesos que afectan, en lectura solamente, o también actualizando, a una buena parte (o a toda) la Base de Datos.
Ejemplos hay en todas las áreas de negocio, pero usaré uno evidente: La Liquidación de Cuentas, en Banca, donde se liquidan todas las cuentas (al menos las de cierto tipo, pero muchas), que requiere tratar todos los movimientos del periodo a liquidar y generar los propios apuntes resultado de la liquidación, que se incorporan a la propia cuenta (y a la contabilidad), se actualiza el saldo, se marcan como liquidados los movimientos tratados… en fin, es un proceso muy pesado y complejo, que lee y actualiza buena parte, o toda la Base de Datos, requiere clasificar los movimientos por fecha de valor (pues de ninguna manera están así ordenados en la Base de Datos), y que suele durar horas. Esto no se puede hacer “online” (en realidad, no es que no se pueda, es que es complicadísimo), entre otras causas por:
1 Los bloqueos. Una Liquidación es un proceso que actualiza muchos (o todos) los registros de una o varias Bases de Datos. Si, simultáneamente existen transacciones online que actualizan esas mismas filas, se pueden producir infinidad de bloqueos, que, aunque se resuelvan todos correctamente, ralentizarían mucho a ambos procesos: el batch y el online.
2 Además, es posible que el proceso batch casque a mitad de su ejecución; entonces habría que recuperar los datos modificados por el proceso hasta el momento del error y dejarlos como antes de ejecutar nada, hasta revisar el motivo del fallo y solventarlo. Pero, si simultáneamente se están ejecutando transacciones online… ¿qué saldo hay que dejar? Si una transacción ha utilizado unos dineros que han sido abonados por la Liquidación, y ahora echamos ésta atrás… ¿qué hacemos con dicho saldo? Estos problemas de integridad son los más complicados de resolver.
3 Luego, el propio proceso de recuperación de los datos a partir del log es tremendamente pesado: implica ir recorriendo dicho log hacia atrás, e ir reponiendo los datos previos a cada actualización… ¿toda una liquidación de cuentas? Mala idea…
4 Pero es que además, la propia ejecución de procesos batch de cualquier tipo a la vez que el online genera problemas de integridad. Por ejemplo, se puede hacer una transacción que implique actualizar dos registros diferentes de la Base de Datos, que están físicamente en sitios diferentes (digamos, de dos oficinas distintas). Puede ocurrir que uno de estos registros haya sido ya modificado por el batch y el otro, todavía no, porque aún no han llegado ahí los programas del batch, por lo que la decisión tomada por la transacción puede ser completamente equivocada.
5 Por fin, hay que tener en cuenta la sencillez de los procesos. En informática, generalmente sencillez significa fiabilidad y rendimiento. Complicar mucho los procesos no suele ser buena idea a largo plazo…
No sé si ha quedado claro, pero el punto más importante que el diseñador técnico tiene que tener en cuenta a la hora de diseñar un proceso batch no es lo que tiene que hacer dicho proceso (las especificaciones funcionales), sino qué hacer si falla el proceso (por un casque incontrolado, vaya, de esos que tontamente ocurren de vez en cuando).
Así que la solución que todo el mundo toma (siempre que puede) para simplificar los sistemas, evitar interferencias y minimizar el impacto de un casque es aislar los procesos batch del online.
Es decir, se mantienen las aplicaciones online funcionando durante la mayor parte del día, pero a cierta hora, pactada con los usuarios, se cierran (ojo: se cierran las aplicaciones, lo que significa que se paran las bases de datos de la aplicación, y que no se pueden lanzar transacciones de esa aplicación, pero sí de otras: los gestores de teleproceso en sí nunca, o casi nunca, se paran).
Muy poco tiempo para el batch...
Esas horitas en las que no hay online (distintas para cada aplicación) constituyen lo que se conoce como Ventana Batch. Ventana que, por cierto, cada vez es más pequeña, es casi un ventanuco, una claraboya, pues por requerimientos de negocio cada vez deben estar más tiempo las aplicaciones online.
Lo primero que se hace tras parar el online, y por tanto parar las bases de datos, es hacer copia de seguridad de las bases de datos. Con esto quedan consolidados los cambios realizados por el online, y se usa la copia como salvaguarda. En el mundo mainframe de IBM, se suelen hacer “Image Copies”, es decir, no se salva el contenido de la base de datos de forma lógica, registro a registro, sino que se hace una copia física de los ficheros que forman la base de datos (datos, índices, etc), tal y como están: con sus huecos, sus registros borrados, sus desorganizaciones, etc. Pero es que así es mucho más rápido (tanto el proceso de backup, como el eventual de recovery). Para volver a dejar las Bases de Datos limpitas, sin huecos, con los índices sin saltos, etc, se pasa periódicamente un proceso de “REORG“, que reorganiza la Base de Datos y la deja como los chorros del oro… hasta que arrancamos el online de nuevo, y comienza de nuevo el espectáculo…
Bien, una vez obtenidas las copias de seguridad, se comienzan a lanzar los procesos batch. Y una cosa que se deberá especificar es qué hacer si el programa casca (pensaréis: ¡qué pesadito, con los casques…! Los que estéis en esto, decidme si tengo o no razones para ser pesado).
En principio, ante un casque de un programa que actualiza una Base de Datos, hay dos alternativas: dejar que el Gestor de Base de Datos recupere el error de forma standard, usando el log, o recuperar de la última copia de seguridad, ignorando el log. Para esto último, por ejemplo en IBM, se define el fichero del log como DUMMY, es decir, que en realidad no existe, así que al estar vacío, no se ha grabado nada en él (ahorrando el tiempo de esa grabación), y el Gestor de Base de Datos no tiene nada que recuperar. Entonces se vuelca (externamente, claro; suele ser el Planificador quien lo hace automáticamente) la última copia de seguridad sobre la Base de Datos, y listo. Tomar una opción u otra depende de muchas cosas, si es el primer proceso que actualiza o ya ha habido varios, en qué punto del proceso se hizo la última copia, cuántas filas actualiza de media el programa, etc.
Los procesos batch deben pasarse en el orden lógico que han determinado los Analistas de la Aplicación, que son los que saben bien cuáles son las relaciones lógicas entre procesos… o, al menos, les pagamos para que lo sepan, pero ésa es otra historia, y será contada en otro momento.
Habrá procesos que podrán correr en paralelo; otros no, pues habrá dependencias funcionales entre ellos: por ejemplo, no se podrá pasar el proceso de Abono de Dividendo hasta que no se haya terminado el proceso de Consolidación de Carteras de Valores (que es el que determina finalmente cuántas acciones de qué compañía tiene cada cliente al final del día). Si no lo haces en su orden correcto, podrás pagar el dividendo a un cliente al que no debes hacerlo, pues ya no tiene acciones de esa compañía al haberlas vendido ese mismo día.
En los tiempos heroicos, eran los Operadores los que lanzaban los procesos desde la Consola del Sistema, mirando qué procesos iban acabando, y consultando unos esquemas que ayudaban a saber qué iba antes de qué… Ahora es imposible. Ni con un ejército de operadores podría hacerse.
Cualquier gran instalación española puede lanzar a diario cientos de procesos para cada Aplicación: unos son diarios, otros, semanales, mensuales, decenales, bimestrales… Otros son a petición (o sea, el usuario decide cuándo se pueden ejecutar; los típicos son los procesos de cierre contable). Otros se deben ejecutar si no sé qué cosa ha pasado en un proceso anterior… Una locura, y cada vez en menos tiempo.
Así que ya no es el sufrido operador quien lanza los procesos: es la propia máquina quien lo hace, gracias a los Planificadores (Control/M, de BMC y Tivoli Workload Scheduler –lo que toda la vida se llamaba OPC-, de IBM, son los más usados en el mundo del mainframe), donde se establecen las condiciones de ejecución, prioridades y dependencias entre los procesos, qué hacer si cascan, etc. El resultado es que lo normal es ver seiscientos o setecientos procesos batch ejecutándose simultáneamente durante la ventana batch (que suele ser nocturna, como es lógico), con la CPU todo el rato al 100%… La noche es el periodo más ajetreado de los modernos mainframes, con diferencia… bueno, y de los antiguos, también.
Seguro, seguro que, mientras leéis esto, muchos de vosotros estáis pensando: …Pero, vamo-a-véeh, si yo puedo hacer operaciones con mi “Banco en Casa” durante todo el santo día… y la noche. …Y yo puedo comprar artículos en cualquier tienda online a cualquier hora. …Y puedo usar un Cajero Automático a las tres de la mañana… ¿Pero…qué demonios me está contando este anciano aquí?
... y encima, el tiempo se contrae...
Efectivamente, las necesidades de negocio han hecho que los horarios de atención a los clientes deban ser de veinticuatro horas, así que muchas aplicaciones críticas para el negocio han debido evolucionar para adaptarse.
¿Cómo lo han resuelto las Compañías? De diversas maneras, según el ámbito de actividad.
Es muy normal que a las Bancas en Casa, Cajeros Automáticos, etc, no les atiendan las Bases de Datos “reales” durante todo el tiempo, sino sólo mientras esté el online principal (el de las Oficinas) abierto. Cuando se cierra el online, se sigue atendiendo con una copia de la Base de Datos: para el cliente es la misma cosa… pero las operaciones no se realizan de verdad, se van “apuntando” y al arrancar el online el día siguiente, se consolidan inmediatamente. Para que el cliente no perciba nada raro, las entidades han tenido que montar una buena movida, duplicar bases de datos, aplicaciones… ¡todo sea por el cliente!
En las tiendas online es más fácil, aunque también tiene lo suyo: se vende con las existencias del final del día anterior, por lo que puedes vender la misma lata de tomate a dos clientes diferentes, al no actualizar el stock tras cada operación. Pero como alguien tiene físicamente que buscar en los anaqueles la lata de tomate Albo que has pedido para meterla en tu paquete, no hay ningún problema. Porque si están agotadas, seguramente alguien te llamará a casa para decirte “¿Señor Fernández? Mire, que temporalmente no tenemos tomate Albo… ¿Le enviamos Apis, o prefiere anular el pedido del tomate?” Y Santas Pascuas…
…Y, además, seguro que hay entidades (o determinadas aplicaciones de las entidades) que realmente hacen convivir el batch y en online.
Ah, pero…¿pueden convivir? La respuesta es sí, pero mediante un procedimiento muy, muy complicado. La idea es gestionar el batch como si fuesen transacciones individuales, emitiendo COMMIT (las sentencias de consolidación de los datos en la Base de datos, con ellas avisamos al Gestor: “Hasta aquí, estoy bien“) cada x actualizaciones (siendo x pequeñita, quizá cinco o diez). Hay que tener un cuidado extraordinario con la programación de estos sistemas, hacer todos los procesos rearrancables (menudo tostón), es decir, que si fallan se pueda arrancar el proceso por el punto exacto donde se quedó… lo que exige una serie de precauciones y procesos adicionales, que encarecen mucho el consumo de recursos. Pero sobre todo, exige tener fe ciega en la calidad de los programas batch, y asumir que si fallan en cierto punto, todo lo que hicieron antes estaba, no obstante, bien hecho. Y eso… jo, eso es mucho asumir, amigos.
Convivencia Batch-Online
Claro que, si no queda más remedio… pues no queda más remedio, pero los informáticos huimos de la “Convivencia Batch-Online” como de la peste.
Quizá os preguntéis a qué se refiere este viejo carcamal con “Procesos rearrancables“, y sobre todo, por qué me refiero a ellos con tanta prevención, casi animosidad…
Si un proceso (un programa, en realidad) debe ser rearrancable, debe tener en cuenta no sólo el diseño de sus procesos propios (como liquidar cuentas y estas tontadas), sino que tiene que llevar toda la información que le permita rearrancar cuando falla. Para hacernos una idea, pensemos en un programa más o menos standard de los afectados por esta problemática: Por ejemplo, lee tres ficheros secuenciales y graba dos; accede a diez tablas, de las que actualiza cuatro, y genera un listado con las incidencias encontradas.
Algunos igual pensáis que me he pasado, que los programas de hoy en día no tienen tanto fichero ni base de datos a que acceder… ¡estáis equivocados, amigos! Cuando es preciso hacer convivir batch y online, la tendencia es acumular las actualizaciones críticas en cuantos menos programas mejor, para minimizar los puntos de fallo; los programas resultantes a veces son monstruosos, pero bien estructurados y documentados, son perfectamente mantenibles… yo he llegado a ver programas que acceden a cuarenta y cinco tablas, de las que actualizan veintitantas, y tienen diez mil y pico líneas de código, y, sin embargo, son perfectamente comprensibles y mantenibles.
Bueno, tenemos nuestro hermoso programa batch que tiene que convivir con el online, o sea, ejecutarse mientras el online está abierto, así que pueden producirse actualizaciones provenientes de transacciones en cualquier punto y momento. Y tenemos que preparar el programa para que, en caso de fallo por el motivo que sea, pueda rearrancar y continuar el proceso exactamente por el punto donde se quedó. Veamos los puntos que hay que tener en cuenta:
1 Además de los propios ficheros y bases de datos que use para su proceso primario, hay que definir unos ficheros especiales para el control del rearranque. Mejor fichero que base de datos, pero también podría ser. En este fichero hay que guardar toda la información de por dónde íbamos, que nos permita rearrancar; en cada caso será distinta, puede bastar con la clave del registro por el que vamos (por ejemplo, la cuenta), o añadir alguna información adicional, según las necesidades concretas. Este fichero debe ser borrado antes de la ejecución del programa de marras (de la primera ejecución, quiero decir).
2 La estructura del programa es muy distinta a la que tendría sin “rearrancabilidad”. En primer lugar debe leer su fichero de control de rearranque, para ver cuál es la situación de su ejecución. Si está vacío, significa que tiene que comenzar por el principio. Pero si tiene contenido, significa que ya ha procesado parte de la información, y tiene que seguir por donde iba. Así que tiene que posicionar todos los ficheros y bases de datos en el mismo punto donde cascó la llamada anterior… Habrá que leer ficheros hasta que la clave coincida con (o sea superior a, segun el diseño que se haga) la que se encuentra en el fichero de control. A las Bases de Datos habrá que hacerles lecturas para dejar cursores o posicionamientos en el mismo punto exacto en que se quedó cuando falló… En fin, un proceso complejo, laborioso, y en el que hay que ser muy cuidadoso, para no llevarse sorpresas.
3 Una vez “posicionados” en el lugar correcto de los datos (bien por estar al principio de todo, bien mediante el proceso de reposicionamiento anterior), hay que empezar el proceso de verdad (hasta ahora no eran más que juegos florales). Pero también la estructura de la parte mollar del programa debe sufrir cambios importantes: ahora, cada pocos registros (cuentas, movimientos, etc, depende de cada programa) se debe emitir una sentencia de consolidación de las Bases de Datos: un COMMIT. Y se debe, además, escribir en el fichero de control por dónde vamos. Es decir, abrir el fichero, escribir el registro de control, y cerrarlo, para consolidarlo igual que las bases de datos. He dicho “cada pocos registros” (quizá 5 ó 10), aunque también se puede hacer a cada uno de ellos, pero el propio proceso de COMMIT consume bastantes recursos, así que se llega a un compromiso. Salvar cada diez registros, nos garantiza que, en caso de fallo, sólo hemos perdido el trabajo de como mucho los últimos nueve, y a cambio hemos reducido mucho el tiempo de proceso.
4 Naturalmente, hay que elegir muy bien el punto exacto donde se realiza la consolidación, para no dejar nada a medias, es decir, hay que convertir el proceso batch, de alguna manera, en un proceso transaccional por lotes o algo así…
No sé si ha quedado claro, pero incluir la capacidad de rearrancar en un programa es un tostón. Y no creáis que esto de la rearrancabilidad se inventó con las Bases de Datos, no… Yo ya hacía programas rearrancables para el venerable NCR Century 200, pero esta vez por motivos muy distintos: ¡ahorrar papel!
Papel contínuo. Este está sin imprimir todavía.
Vale, vale, ya me explico: tú tenías un magnífico programa que imprimía el Balance de Cuentas Corrientes, sin ir más lejos… un tocho de papel pijama de ochenta centímetros de altura (y lo mismo cuarenta o cincuenta kilos de peso) con todas las posiciones de las Cuentas Corrientes de todas las Oficinas. Y el programa hacía impresión directa: estamos en monoprogramación, no hay SPOOL (que no es un nombre de nada, por cierto, es el acrónimo de “Simultaneous Peripheral Operating On Line“), y cuando el programa dice “WRITE LINEA”, la línea se imprime físicamente por la impresora. Sin más.
Todo va como la seda… y de pronto ¡se rompe el papel continuo! (o se va la luz, o el operador se equivoca y aprieta inopinadamente la tecla de Stop…). Y ya llevaba impresos sesenta y cinco de los ochenta centímetros de papel… Volver a empezar el listado por el principio significa tener que enviar a destruir kilos y kilos de papel que está ya impreso, y encima con la información correcta, lo que no parece muy lógico, ni desde el punto de vista económico, ni desde el ecológico. Aunque en realidad, en los años setenta, yo creo que ni siquiera sabíamos qué era eso de la ecología.
Entonces el operador buscaba en el papel la última cuenta que había quedado bien impresa, la introducía al arrancar el programa de nuevo, y ahora el programa lee registros hasta colocarse en ese punto exacto y comenzaba a imprimir por donde se quedó la vez anterior… A grandes problemas, ¡grandes soluciones! Pero aseguro que era un tostón escribir programas así.
Y hasta aquí el proceloso mundo del batch y sus ventanitas… No os quejaréis, que para mis costumbres, este ha sido un episodio cortito.
En la próxima entrada, como os amenacé en entradas anteriores, os hablaré de cómo afectó al Desarrollo de Aplicaciones la aparición, introducción y consolidación de las Metodologías de Desarrollo, y junto con ellas, las herramientas CASE que ayudaban (o no, que de todo había en la Viña del Señor) a utilizarlas. Si es que todavía queréis que siga dando la lata…
Disfrutad de la vida, mientras podáis.
The Historia de un Viejo Informático. La Ventana Batch. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 16 } Comentarios
Glorioso batch. Trabajo automatizando procesos y es la mejor herramienta que se ha podido inventar (sí, todavía hoy día) Un poco tuneada, con las pstools y alguna utilidad más en una carpeta referenciada en el path, pero saca de más apuros que el VBScript y el programa que tenemos para automatizar
Mira que soy un informático reciente (acabé la carrera hace un par de años), pero me ha tocado pegarme con la ventana y los procesos batchs en 3 trabajos distintos, y desde 3 puntos de vista distintos (operador, administrador de sistemas y programador).
De operador era en turnos 24×7, con la ventana del Control-M y sus cientos (o miles) de jobs encadenados. Era un entorno sobre todo UNIX, y la mayoría de las veces cuando fallaba algún job la solución era llamar a la guardia de turno (BBDD, SAP, Sistemas, etc…). Muchas de las veces eran llamadas que se podrían haber evitado, si el programador hubiese sido un poco menos perezoso. La verdad es que daba penar tener que llamar a la gente a las 4 o 5 de la mañana, excepto a algunos adminstradores un poco bordes, que a veces les llamabamos aunque no hiciera estrictamente falta.
De administrador de sistemas en otra empresa me he visto en el otro lado, recibiendo llamadas nocturnas y con alevosía por parte de los operadores. Yo estaba administrando sistemas UNIX y me llamaban cada 2 por 3, en cambio a los de mainframe (tenían un zSeries con TWS, que era el que nos planificaba los jobs a todos) no les llamaban casi nunca. Los jobs o no fallaban, o estaban preparados para poder seguir.
De programador, aunque no eran procesos batch de verdad (era programación J2EE, puro online, con persistencia de datos en serializando los objetos a fichero, en vez de en BBDD) de vez en cuando al cliente le daba por cambiar la estructura de los datos. En esos caso nos teníamos que currar un programa que sustituyera los ficheros serializados antiguos por ficheros con la estructura nueva pero con los datos antiguos que fueran reutilizables. Para ello los operadores tenían que lanzar 3 procesos distintos, que iban modificando los ficheros en 3 pasadas sucesivas. Me acuerdo que la primera vez se me olvidó explicarles lo que había que hacer si cascaba, y como no falló. Lo peor es que cada proceso había funcionado sobre una serie de ficheros por separado. Me pasé todo el día siguiente arreglando el desaguisado, recomponiendo los datos de cada usuario en base a 3 o 4 ficheros distintos, teniendo que programar sobre la marcha procesos que fueran capaces de leer cualquiera de las versiones, y todo por no especificar que si fallaba se machacaran los ficheros con la copia de seguridad.
Asi que te doy toda la razón con lo de los casques, nunca se es suficientemente pesado con este tema, si no lo planificas bien a alguien le va a tocar currar mucho.
Yo he sido de los que sufrían llamadas a las 5 de la mañana. Por eso cuando teníamos que hacer procesos nuevos (que eran las menos veces) intentábamos que todos los procesos relanzables. Lo peor era que los programas más importantes, que formaban parte de una cadena que no había dios que entendiera, apenas ninguno era relanzable, y cuando les daba por cascar aquello era horrible. Hablar con otros operadores para recuperar las copias de los ficheros del día anterior; ir lanzando los procesos viendo que acababan correctamente, aguantar las llamadas del usuario que tenía parada a un montón de gente porque los procesos no habían terminado y no podía trabajar, según el problema había que retrasar la puesta en marcha del online porque bloqueaba el acceso a los ficheros, o había que tirarlo y levantarlo con los ficheros ya actualizados (como ya he comentado en más de una ocasión por aquí, el cacharro de Bull era un poco arcaico)… la verdad es que estaba muy bien cuando pasaba eso, y así dejabas de resolver las típicas incidencias de todos los días jeje
La verdad es que gran parte de lo que comentas se parece un huevo a los sistemas de journaling de los sitemas de ficheros actuales… aunque pensándolo bien, un sistemas de ficheros no es más que una base de datos
Macluskey: ¿Por qué no dedicas un artículo de tu serie a la frase “el software está en crisis”, repetida desde hace años en casi todos los prefacios de casi todos los libros del tema? La primera vez que la leí fue en un manual de Bull de programación lógica, escrito por un español cuyo nombre ya no recuerdo porque fue allá por 1979. Saludos, y lo de la ventana Batch, casi, casi, un gol de Messi.
Respecto a meter el rearranque en procesos… yo no lo veo tan complicado, siempre que el diseño inicial lo tenga en cuenta claro. La clave está en que el fichero de rearranque no esté en un fichero, si no en una tabla DB2 que contenga el último registro leído (o su clave) y que esta tabla sea accedida por una rutina (para que todo el mundo haga el mismo acceso). Y por supuesto nada de ficheros de salida, que si no hay que jugar con REWRITE. Y si el proceso tiene que actualizar 1 o 20 tablas, se debe hacer en un mismo programa rarrancable y partiendo de ficheros dejados por los anteriores programas (mejor eso que tirar de cursores que lo complican todo).
Eso sí, como te toque convertir un proceso a rearrancable cuando el diseño inicial no lo tuvo en cuenta es una auténtica putada. Sobre todo si tiene ficheros de salida, porque tienes que jugar con la apertura de ficheros en modo EXTEND o en modo I-O y hacer WRITE o REWRITE… uf. ¿Se nota que me comí unos cuantos de esos?
Acabo de leer varios de tus artículos y tengo una extraña sensación. Si no es indigestión, debe ser de gratitud! En serio, estimado Macluskey: Merci, thank you, gracias por lo que cuentas y como lo cuentas, no sé quien decía que la experiencia de cada uno es el tesoro de todos. Tus artículos son unos tesoros sin precio, trozos de la historia de la informática, de la historia real, la vivida …otra vez, gracias, me ha encantado leerte, ¡por favor! sigue escribiendo, sigue dándonos esta visión ordenada, perspicaz, cuidada, argumentada, inteligente y como guinda, llena de los sentimientos de un viejo informático a quien, no cabe la menor duda, le gusta su profesión y algo se nos pega… ¡Viva la informática y los informáticos! (los buenos que sean viejos o menos viejos)
Hola, chicos: sólo meto la cabeza para deciros que el Venerable (es decir, Mac) está de vacaciones. Así que no es que no quiera contestaros, simplemente tendréis que esperar hasta que vuelva (no será mucho tiempo)
En la oficina donde trabajo, aún tenemos uno de los sistemas con ficheros DBF (por cierto más que suficiente para lo que debe hacer…) en una red pequeña, y también se hacen batchs de vez en cuando; eso si, no se pide opinión a los usuarios, ya que en pocos minutos está terminado todo; esto indica que los procesos batch son universales e imprescindibles, tanto para sistemas enormes como para pequeñitos.
Un poco tarde (acabo de aterizar en Madrid y lo primero que he hecho ha sido conectarme para poder leeros…), pero muchas gracias a todos por vuestros comentarios.
@piluso: ¿El software en crisis? Caramba, no se me había ocurrido… viendo cuáles son las empresas más grandes del mundo mundial, y los tipos más ricos del universo, quién diría que el software está en crisis… Claro que, según como se mire. Los que hacen software pueden estar en crisis, dada la tendencia cada vez mayor de las empresas a comprar SAP’s, Peoplesofts, Oracles Financials (o como rayos se llame ahora) y compañía para resolver los problemas que antes hacíamos unos cuantos piraos tirando líneas de código… en este sentido puede que sí que lo esté, pero yo creo que no: hay software en las cámaras de fotos, los lavaplatos, las cafeteras, las cisternas de los sanitarios, hasta las planchas tienen ya software…
@yomismo: ¿Estás seguro que es una buena idea usar una única tabla para que todos los procesos apunten ahi por dónde van para rearrancar si hay un fallo?? Porque… ¿qué pasa si la que casca es la propia tabla de los rearranques…?
Además, salvo truco que desconozco, varios procesos simultáneos accediendo para actualizar contínuamente pocas filas (cada uno la suya) provocan una contención tremenda… claro que hace algunos añitos que ya no programo y quizá la última versión tenga algún dispositivo mágico para tal cosa… Y es que la informática adelanta que es una barbaridad…
Mac: gracias por la respuesta, pero la frase a la que hago alusión no se refería a que haya software por todos lados- lo que es cierto- o a que su producción es una actividad muy, pero muy redituable- lo que sin duda es así- sino a que el software está muy por atrás de las posibilidades que da el actual desarrollo del hardware. Además -y esto lo agrego yo- a que el software que vemos es casi sin excepción de mala calidad y lleno de errores. No se invierte en mejorarlo porque se gana lo mismo-apoyado en una gran campaña publicitaria- sacando a la venta versiones menos que una beta 1. Mas allá de eso, ¡saludos!, y que hayas disfrutado de tus vacaciones.
@Piluso: Ah, ya!
Lo que tú quieres decir no es que el software esté en crisis, sino que: el método de concepción y realización del software está en crisis. Completamente de acuerdo, claro que sí. No sé si lo he dicho así de claro en alguna entrada, pero creo que se deduce de mis impresiones y comentarios.
Hace treinta años, nuestro objetivo era escribir aplicaciones que tenían que hacer cosas imposibles en máquinas ineficientes, y conseguir que funcionaran cada día y encima fueran eficientes. Se necesitaba una gran formación, una enorme motivación y olvidarse de los horarios. Y lo logramos. Ahí están los resultados.
Pero, claro, con el tiempo el negocio del software se convirtió en un negocio… y con la llegada del negocio llegaron los contables, los marketinianos y los gestores de recursos. Lo importante ya no fue que las aplicaciones funcionaran perfectamente, sino que se ganara dinero escribiéndolas… Y calidad impica casi siempre, esfuerzo y tiempo. Y esfuerzo y tiempo implican dinero. Utilizar el dinero en aumentar la calidad reduce los beneficios…. ergo la solución es obvia: entre maximizar la calidad y maximizar los beneficios………. no sigo, ¿ok?, que creo que ya queda bastante claro.
Gracias por tus comentarios, colega.
Tranquilo no son memorias de viejo informático bancario de los mundos del host, es el día a día también los modernos entornos distribuidos de las telecomunicaciones con sus middleware y procesos de conciliación y cálculo.
Y los que nos dedicamos al data warehouse tenemos ya callo con estos temas.
Echo de menos un artículo al mejor algoritmo de encriptación jamas realizado: El EBCDIC
Muchas gracias por compartir tu conocimiento desde hace tantos años. Me ayudo, porque estoy buscando soluciones para poder ejecutar el 24×7 en el mundo Mainframe, a pesar de lo que implica.
Estoy desarrollando un Diseño de Procesos Batch en 24 x 7 (conviviendo online y batch), por lo que agradecería una colaboración. Cuento lo contemplado:
o Para tratamiento de Batch con gran volumen se realiza lo siguiente: Dividir el fichero de entrada en N ficheros de entrada, la condición puede ser cada 5 o 10 registros cree un fichero. Esto se consigue con un programa que a su vez creara N jcl´s en el momento de ejecución, que ejecutan el programa con la funcionalidad que tenia el JCL con un gran volumen de datos.
o ¿Como se deben tratar las LOAD /UNLOAD en procesos de 24 horas?
¿Que más debería de contemplar?
Muchas gracias
Cristina, me halaga tu confianza, pero, como supongo que comprenderás, no puedo recomendarte nada especial desde esta atalaya…
Cada caso es diferente y requiere de un estudio específico, y tu caso seguro que lo es. Diferente, quiero decir. Especial.
Eso sí, un par de cosas que debes tener en cuenta:
Uno: Diseña el sistema pensando lo que va a pasar cuando falle. En la informática moderna todo el mundo diseña y programa maravillosos sistemas que funcionan estupendamente bien en Powerpoint, incluso en pequeños entornos controlados, y luego explotan sin el menor miramiento cuando se dan de bruces con el proceloso mundo real… Insisto: ten siempre como la regla de oro del diseño responder ante fallos. En eso tienes una ventaja: el mainframe (supongo que z/OS con DB2, por lo que dices) te ayudará mucho. No quiero imaginar lo que debe ser diseñar un sistema 24×7 en una granja de servidores UNIX…
Dos: Consigue involucrar a los técnicos de sistemas de DB2. Vale, ya sé que son tipos muy raros, que hablan una jerga casi incomprensible llena de siglas y términos extraños, pero de DB2 saben un rato. Si les adulas un poco y les das cancha, seguramente conseguirás interesarles y que derramen sus conocimientos para optimizar el diseño del sistema. Hay que comprenderlos, claro: están habituados a que les lleguen para implantar horrorosos sistemas diseñados por desertores del Visual Basic, con multitud de tablas con claves autonuméricas (¿quién demonios habrá inventado semejante barbaridad, olvidando… no, pisoteando todas las técnicas de diseño y modelado de datos que tanto nos ha costado obtener a los informáticos…?) y diseños que podrían haber sido hechos mejor por mi sobrino de siete años, aplicaciones que casi no hay forma de meter en cintura, así que sienten un especial repelús hacia los actuales Analistas de Desarrollo. Sin embargo, tienen su corazoncito, y si les propones el reto y te lo compran, seguramente lo asumirán encantados. ¡Eso espero!
Y, por fin, no olvides que, de momento, nadie sabe tanto como tú sobre el sistemas que estás diseñando, así que lo más seguro es que nadie (vale: casi nadie) pueda darte soluciones mágicas que tú no hayas visto antes.
¡Suerte!
Grande. Un día fui a mi jefe con un problema que no era capaz de resolver, y cuando termino de explicárselo le digo “¿qué hago?”. Y me responde: “¿y yo qué sé? Tú llevas estudiándolo dos días y no tienes solución, ¿por qué crees que voy a encontrarla yo en 5 minutos?”. Me enseñó que ser jefe (al menos en mi sector) no es saber más que tus subordinados, solo saber cosas distintas.
{ 1 } Trackback
Historia de un Viejo Informático. La Ventana Batch…
[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 ta…
Escribe un comentario