Como comentaba en la “entrada anterior”, el mercado de software apenas existía en los años 70 y 80 del siglo pasado. El software básico se compraba al fabricante de la máquina (Sistema Operativo, Compilador, Sort, etc), había algún software de propósito general de fabricantes independientes (Bases de Datos, algún programa de gestión de ficheros, y poco más), y casi ningún Software de Aplicación (lo que ahora se llama pomposamente un “ERP”, es decir, la Contabilidad, la Nómina, etc.).
En una palabra, todos los programas de gestión de las empresas estaban hechos ex profeso para las propias empresas, y casi siempre por personal de las propias empresas.
Muy pocas empresas se dedicaban a ofrecer servicios profesionales en subcontratación, y las que lo hacían, era para incorporar al analista o programador al equipo del cliente y trabajar codo con codo con ellos durante una temporada, generalmente larga (lo que después se llamó “bodyshopping” (qué nombre más horroroso…pero qué bien define la actividad, pardiez). O sea, casi no se contrataban proyectos “llave en mano“, que es lo habitual en nuestros tiempos.
Eso quería decir que los Departamentos de “Proceso de Datos” (nombre que casi todas las empresas usaban en la época; con el tiempo, los nombres se fueron complicando y cambiando según las modas del momento) de las empresas o instituciones tenían personal propio y dedicado que escribía los programas para resolver las necesidades de esas empresas o instituciones.
Y… ¿Cómo se trabajaba en el Pleistoceno de la Informática?
Generalmente, aunque no siempre, había una persona (“Analista Funcional Jefe de Proyecto” era su denominación más habitual), que se ocupaba de la comunicación con usuarios, como Contabilidad, Cuentas Corrientes, Préstamos, etc. Esta figura (que casi siempre era “un figura”) se encargaba de recibir peticiones del Usuario, proponer soluciones, parir Sistemas de Información y dirigir al equipo de programadores que debían programarla. Una vez consensuada la Aplicación, realizaba el Análisis Funcional (no, no es el mismo “Análisis Funcional“ que se estudia en matemáticas, sino la descripción más o menos ordenada de las funciones que debe cubrir el Sistema de Información a diseñar).
Servilleta de Bar. Cortesía de Remo (curiosoperoinutil.com)
Solíanse usar dos medios principales para realizar tan importante tarea, a saber: Uno: la servilleta del bar (si estaba manchada de mayonesa, mejor); Dos: la comunicación verbal (en una reunión, donde contaba lo que se suponía que había que hacer, y donde algún avanzado hasta tomaba notas).
Os preguntaréis quizá que quiénes eran los “Analistas Funcionales Jefes de Proyecto” y programadores que trabajaban ya en el Banco cuando yo entré allí… porque yo era de una de las primeras promociones de Informática, y aún estaba en Tercero. Pues se trataba de personal del propio Banco, de las áreas administrativas (cajeros, auxiliares, botones, etc), que fue seleccionado –creo que mediante un examen– para ser formado específicamente en el ordenador que había adquirido el Banco, en este caso NCR, durante varios meses.
No eran universitarios (en la España de los sesenta y setenta no lo era casi nadie), pero hicieron estupendamente su trabajo: las aplicaciones más importantes (Cuentas Corrientes, Depósitos, Valores, etc) las diseñaron y escribieron ellos… y funcionaban. Y, sobre todo, ¡eran unos artistas emborronando servilletas!
Años después, en muchos casos, la vida fue injusta con esos grandes profesionales. La “titulitis” que apareció en España en los años ochenta y noventa los dejó fuera; muchos de ellos están “prejubilados” o simplemente “despedidos” de mala manera. Becario, jovenzuelo e inexperto (y sin saber una palabra de Banca) ellos me acogieron, me tutelaron y enseñaron lo que sabían. Aprendí muchísimo de estos profesionales como la copa de un pino. Quiero expresar desde estas humildes líneas mi Admiración y Respeto por ellos, y hacerles el homenaje que, que yo sepa, nadie les ha hecho. ¡Gracias, amigos!
El siguiente paso era repartir el trabajo. En realidad tampoco había mucho que repartir: lo normal es que con cada “Analista Funcional Jefe de Proyecto” hubiera uno o quizá dos programadores… ¡o tres! que atendían al área usuaria, así que no era difícil en realidad decidir quién iba a encargarse de qué.
La plantilla de Análisis y Programación de una gran empresa de la época podía componerse de entre treinta y cincuenta personas. Teniendo en cuenta que todas las Aplicaciones importantes funcionaban, y se daba servicio a las nuevas necesidades en un tiempo razonable, la productividad era muy alta, desde luego. No perdíamos mucho tiempo en documentar ni hacer interminables memorandos justificando el coste: nos limitábamos a escribir el software, ponerlo en Producción, formar a los usuarios en su uso, y dar soporte después. Se ve que éramos todos unos vagos, a los que no nos gustaba nada escribir… aunque cualquiera lo diría, viendo los ladrillos infumables que os suelto.
No existían las Bases de Datos. Bueno, sí que existían, pero con capacidades muy escasas todavía, y, que yo sepa, no había casi ninguna adecuada para los Sistemas de NCR. Es decir, los ficheros del Banco, donde estaba toda la información sensible eran… eso, ficheros. Secuenciales.
Esquema de una Actualización Padre-Hijo.
Prácticamente todos, en Cinta Magnética, y se les ponía al día mediante un proceso de actualización conocido como “Padre-Hijo“, donde se montaba en una unidad de cinta la versión actual del Fichero Maestro, en otro armario, una cinta virgen para acoger la versión siguiente del mismo Fichero, y se ejecutaba un programa de actualización (que solían ser los más complicados de la instalación) que, teniendo en cuenta el fichero de movimientos (o los ficheros de movimientos, en ocasiones se precisaba tener más de uno), generaba la versión actualizada de dicho Fichero Maestro.
Se guardaban varias versiones de cada Fichero (entre 4 y 8, según lo importante que fuera), y se guardaban también los ficheros de movimientos de esos días, para poder repetir un proceso que hubiera resultado erróneo por cualquier causa, generalmente porque el programa no hacía bien su trabajo… aunque en ocasiones (raras, la verdad) el Operador se equivocaba y montaba las cintas al revés (la de entrada donde debía estar la de salida y viceversa), y se machacaba la útlima versión del Fichero de Clientes o el que fuera… Pero no pasaba nada: siempre recuperamos los procesos y nunca perdimos información, estoy seguro. Mmm, Casi seguro.
El programador, que sabía qué programa tenía que hacer, incluso (casi siempre) lo que tenía que hacer el programa, se ponía a ello.
Organigrama típico (años 70). Lectura de un registro en un fichero indexado.
El primer paso era “hacer el mono”. O sea, el organigrama (los finos lo llamaban ordinograma, para distinguirlo del Organigrama de la Empresa, aunque éste último no hacía falta: todos sabíamos quién era quién). “Hacer el mono” en realidad era pintar en un papel (no, en muchos papeles) el diagrama de secuencia del programa. Si eras un tipo limpito (no como el guarrete que pintó el Organigrama que aparece aquí al lado, o sea, ejem, yo), utilizabas una plantilla para pintar las diferentes instrucciones, bifurcaciones, etc.
Plantilla para pintar organigramas y que quedaran bonitos
En cualquier caso, los saltos de un lado a otro del flujo, según las condiciones que se fueran satisfaciendo, se pintaban con flechitas, que tendían a entremezclarse y volar de arriba abajo, de derecha a izquierda y, en realidad, en todas direcciones … de ahí la denominación de “código spaghetti” para los programas resultantes.
Este término (lo de código spaghetti) es claramente peyorativo, según bien dice la Wikipedia, pero es que fue inventado muchos años después. En los años setenta ésa era la manera de programar. La única, no había otra. Hasta 1983 u 1984 no empezó a imponerse la “Programación estructurada”, pero aún hubo que mantener programas antiguos durante muchos, muchos años.
Hoja de Codificación Cobol. Todo programa se escribía en ellas
Una vez hecho el organigrama (más o menos detallado, según la experiencia y habilidad del programador), se comenzaba a codificarlo, es decir, a traducirlo al lenguaje que el ordenador entiende (NEAT/3, Cobol, Fortran o lo que fuera).
El programador agarraba un taco de Hojas de Codificación en blanco, y comenzaba a escribir allí el código. Ciertos inteligentes tenían fotocopias de las hojas de codificación donde casi siempre era todo igual (nombre del programa, tipo de máquina, autor, etc.), lo que nos permitía, rellenando las escasas partes que cambiaban, ahorrarnos escribir un poco. Pero poco.
Usábamos lápiz casi todos (el portaminas de 0,5 era el rey, yo me acuerdo de mi precioso Cross plateado que me birlaron, sniff) para poder corregir errores, y solíamos tener seis o siete montones de hojas con las diferentes partes del programa que se iban codificando a la vez… y todo ello, bajo la continua consulta al organigrama… ¿He dicho ya que no había pantallas, ni editores de texto, ni nada parecido?
Al cabo de varios días (dependiendo de la complejidad del programa), terminabas tu trabajo de codificación. La complejidad media de los programas que hacíamos entonces era bastante alta, comparada con la de los que se hacen ahora. Preferíamos hacer un único programa muy complicado que tres más sencillos… si seguís leyendo os daréis cuenta de por qué.
Con tu programa terminado, enviabas el taco de hojas al Departamento de Grabación, para que las perforaran. O sea, que cada línea que tú habías escrito fuera copiada literalmente a una ficha perforada, con las perforaciones equivalentes al código que tú habías parido (según el código Hollerith, así llamado por el inventor de la tarjeta perforada, Herman Hollerith).
En el Departamento de Grabación, donde una pléyade de grabadoras o perforistas (y lo digo en femenino porque en todos los sitios en que he estado, en Grabación había exclusivamente mujeres, no me preguntéis por qué) se ocupaban de recibir documentación de Oficinas, Servicios Centrales, etc. y grabarlas en cinta o tarjeta perforada, según el programa que leyera los datos.
Perforadora de Fichas
Tus hojas de codificación, con palabros extraños y nombres impronunciables, como debe ser, se ponían en la cola hasta que le tocaba su turno.
…Y tardaba. Siempre tardaba, primero porque tenía prioridad el trabajo diario (la contabilidad debía cerrar cada día, porque si no…), y segundo, porque a las perforistas no les gustaba nada perforar programas.
…Cientos o miles de fichas perforadas por programa, un trabajo muy feo, y lo digo por experiencia, porque cuando un programa te corría prisa de verdad, te ibas a Grabación, y aprovechabas que alguna perforadora estuviera libre para perforarte tú mismo el programa. Y era feo de verdad.
¿He dicho ya que a los Programadores no se nos caían los anillos si teníamos que perforar, grabar u operar en la máquina, cuando hacía falta? Y a los Analistas, tampoco, por cierto.
Además, para asegurar la máxima calidad en la grabación, todo el trabajo se verificaba. Esto consistía en volver a poner el taco de tarjetas grabadas en el alimentador de la perforadora, ponerla en “modo verificación” y volver a teclear de nuevo el programa. Ahora la máquina no perforaba, sino que se aseguraba de que lo que tecleabas coincidía con lo ya perforado. Si no era así, avisaba y había que ver dónde estaba el error (en la tarjeta, o en lo que habías tú tecleado en la verificación), y corregirlo.
Un tostón, y encima, caro, por lo que en ocasiones no se verificaban los programas… y luego se producían muchos más errores.
Bien, han pasado unos días más, y por fin te devuelven un taco de quinientas, o mil o dos mil fichas con tu programa perforadito, y atado con una goma elástica.
Taco de Fichas Perforadas... y sin gomilla!!
Más te vale que las gomas con que el taco viene sujeto no se rompan, porque si se cae al suelo y se desordena… te puedes pasar un par de días hasta recolocarlo de nuevo. Las fichas perforadas nuevas (o sea, para perforar) venían en paquetes de 2.500 fichas: cada paquete medía unos cincuenta centímetros de largo por unos veinte de ancho y diez de alto, y pesaba lo menos diez o doce kilos. O sea, un programa de 1.000 fichas, bastante normal en la época, ocupaba un espacio de unos veinte centímetros, pesaba alrededor de cinco kilos, y tardaba en ser leído por la lectora de fichas tres o cuatro minutos… si no se atascaba.
¿He dicho ya que, para ser un buen informático, además de tener una mente lúcida, también había que poseer unos buenos bíceps?
Entonces, envías al Ordenador tu taco de fichas, para compilar el programa.
“Compilación” es el proceso por el que el ordenador lee tu programa, verifica que cumple la sintaxis del lenguaje de que se trate, que los campos que has utilizado están correctamente definidos, etc… Si la compilación acaba con “cero errores”, es decir, cumple todas las normas y es, aparentemente, un programa de verdad, y no el Quijote, ni la lista de la compra, entonces el compilador traduce tus instrucciones en Cobol (o el lenguaje que sea), al código máquina que de verdad entiende el ordenador (que sólo sabe de ceros y unos, recordad).
Una compilación típica en esa época solía durar entre diez y quince minutos, con el ordenador en exclusiva. Así, tu “MOVE ZERO TO CAMPO”, se convertía en una instrucción máquina parecida a, digamos, “64002E4C0E002540, que sería la traducción en código máquina de tu estupenda MOVE.
Pues bien, repito, mandabas tu programa a compilar a la Sala del Ordenador… y vuelta a la espera. El ordenador era monotarea, es decir, hace una sola cosa a la vez. Si el Operador lo dedica a compilar, no hace otra cosa. Y si está pendiente de ejecutar el Balance de Contabilidad, o el Abono de Cupón del Banco Hispano Americano, o la Liquidación de Intereses de los Depósitos a Plazo, pues no se compila, como es lógico. Las compilaciones tenían normalmente una prioridad, digamos, baja.
Después, el ordenador fue multitarea (en realidad, bitarea), por lo que la espera media se redujo de dos o tres días a sólo uno o dos. Así que, si te corría prisa que se compilara, podías hacer dos cosas:
Una: Irte un domingo al Banco, y mientras el único Operador que iba los domingos trasteaba en uno de los ordenadores, tú encendías el otro y te lo apropiabas durante unas horas (yo esto lo hice muchas veces, y sin cobrar horas extras, ¿eh? Claro que ahora tampoco se cobran, así que no os extrañará nada).
Dos: revisarte de arriba abajo tu taco gigante de fichas para detectar errores de perforación, o tuyos. Y esto tenía guasa. Pero guasa. Te podías pasar un día entero para encontrar tres o cuatro errores (o treinta o cuarenta, si no habían verificado), que podías arreglar previamente a la primera compilación, eliminando, con suerte, una pasada (y una espera, en consecuencia).
Hasta que por fin los hados se habían conjurado con Isis y Zoroastro, y tu programa había sido compilado…
Papel contínuo. Este está sin imprimir todavía.
… con el resultado de que normalmente tenía unos pocos, o muchos, errores de compilación (sintaxis, malas perforaciones, tontadas tuyas… en fin, lo de siempre).
Recibías entonces el resultado de la compilación: el listado en papel pijama, donde el compilador había marcado gentilmente las líneas erróneas, eso sí, en ocasiones de forma tan críptica que no tenías ni idea de qué era lo que le pasaba a la dichosa línea. Entonces ibas a por más hojas de codificación, e ibas reescribiendo las líneas erróneas. También podías seleccionarlas en el taco de fichas (no podéis imaginar la habilidad de tahúr que desarrollamos manejando la baraja de fichas perforadas: ningún amigo quería jugar al poker con nosotros, por si acaso), y marcar allí mismo los errores, sobre todo si eras tú mismo quien iba a perforar las correcciones: cuando no eran muchas, generalmente tú mismo te las perforabas para ganar algo de tiempo.
Una vez solventados los errores (o, al menos, eso es lo que tú te creías), recomenzaba el ciclo: envío a perforar, recibir las nuevas fichas, recolocarlas si era preciso en el programa original, envío nuevamente a compilar…
Tras varios intentos, dependiendo de lo torpe que fueras, por fin ha llegado tu programa sin errores de compilación. Ahora, hay que probarlo. Es decir, asegurarse de que el programa, de verdad, hace lo que se supone que debe hacer (y no sólo lo que tú, programador, te crees que debe hacer, o peor, lo que en realidad has programado, que quizá no tiene nada que ver con lo que querías programar…).
Para ello, no queda más remedio que ejecutar el programa con los ficheros que luego va a utilizar de verdad (o unos similares de prueba, aunque la verdad es que nadie tenía ficheros de prueba de nada: se usaban los reales, y punto; aún no había ninguna “Ley de Protección de Datos”).
Entonces solicitabas la prueba a la Sala del Ordenador, en un papel al efecto, especificando los ficheros que necesitaba tu programa, la salida esperada y si había que contestar algo por consola (muchos programas preguntaban cosas, por ejemplo, “Diga Vd. la fecha de Proceso”, y el operador debía contestar en la propia consola la fecha pedida, que tu programa debía validar para que fuera correcta… bueno, deber, debía, pero no siempre lo hacía).
Podéis imaginar que también había que esperar para probar, claro. Por ello, era común hacer una “Prueba en Mesa” antes de probar (incluso podías hacerla durante el proceso de puesta a cero errores de compilación). Por cierto, de esto en la Wikipedia no hay nada, y no me extraña…
Esta Prueba en Mesa significaba que tú ibas a ser el ordenador y a ejecutar tu programa instrucción a instrucción, para detectar fallos antes de la costosa prueba de verdad en máquina.
Te inventabas, o tomabas de la realidad, unos datos de entrada, y pacientemente te ponías a desentrañar tu spaghetti, anotando: aquí leo el fichero A (y anotabas el contenido del siguiente registro del fichero A en su sitio), ahora comparo si F es mayor que G, si es mayor, salto a Z (y mirabas si lo que tenías apuntado en F era mayor que G, si era así seguías por Z, si no, continuabas), ibas machacando los valores de los campos con los nuevos valores… Y así durante horas.
Parecerá increíble, pero era utilísimo, no sólo porque detectabas errores lógicos, sino porque te aprendías el programa de tal manera que, una vez que lo probabas de verdad, o sea, en máquina, y no funcionaba como debía (o sea, lo normal), casi ibas derecho al sitio donde estaba el error. Es una sensación muy curiosa, que yo he tenido muchas veces y que no sé explicar, la de “intuir” en que parte exacta del código está el error… y acertar.
Bueno, al fin ibas a probar. Generalmente te avisaban para hacer la prueba, ya que muchas veces, sólo viendo cómo se encendían y apagaban las luces de la consola o los dispositivos, o cómo se movían las cintas, sabías si había algún problema (igual esto no os lo creéis, pero prometo que es cierto). O más importante, porque estando allí, eras capaz de sacar mucho más partido a la prueba, que como habéis visto, era realmente costosa de hacer.
Me explico con un ejemplo: era bastante corriente que en la primera prueba el programa se metiera en un bucle (…infinito, claro). Las cintas se paraban, los discos no se movían, y las luces se quedaban encendidas con un patrón determinado. Un bucle, sí, ya (como siempre, más bien) pero… ¿dónde? Si estabas allí, podías hacer lo siguiente:
Uno: Parar el ordenador (ya os conté que tenía un switch, una palanquita de “Halt” que, cuando la movías, dejaba al ordenador parado en la instrucción donde estuviese).
Detalle del botón Halt y las luces de contenido
Dos: Mirar las luces de la consola que te indicaban la dirección física de memoria donde estaba la instrucción que se estaba ejecutando. Por ejemplo, la 3E58.
Tres: Ibas a tu programa y mirabas (en la parte del listado de la compilación donde tenías la conversión de tu código fuente a código máquina) dónde caía la dichosa dirección 3E58, que estaría en un cierta parte del programa, por ejemplo donde estás calculando alguna cosa.
Cuatro: Si no quedaba claro qué podía estar pasando (muchas veces, con sólo saber que había un bucle en la zona, ya encontrabas el error), podías ir ejecutando instrucción a instrucción, pulsando sucesivas veces la tecla “Compute”, y observando el flujo real que seguía el programa. Podías también averiguar el contenido de ciertos campos importantes para el propio control del bucle.
Si con esto no veías qué pasaba, cancelabas la prueba, te retirabas (malhumorado) a tu mesa y allí te ponías a revisar de arriba abajo el programa hasta que encontrabas el error. Pero era común que encontraras inmediatamente lo que pasaba (por ejemplo, habías escrito IF A = B, y tenía que ser IF A NOT = B). Entonces sí que podías continuar con la prueba, para aprovecharla al máximo. Para ello, ibas al código máquina donde estaba esa instrucción errónea concreta y machacabas (a base de usar la consola de forma parecida a la que conté anteriormente) el código de instrucción (por ejemplo, sustituías un código “EA” -saltar por igual- por un “ED” -saltar por distinto-).
Y ya podías continuar la prueba como si hubieras cambiado el código (que habría que cambiar en el programa final en cualquier caso). Con los debuggers que existen ahora, esto puede parecer (y es, qué demonios) antediluviano, pero es que ése era el debugger de la época… y había que conocer la máquina de pe a pa para poder utilizarlo… Era una época realmente divertida.
Si tu prueba había fallado, lo que era (y sigue siendo) lo normal, te llevabas los listados de los ficheros de entrada y de salida a tu mesa, para allí determinar dónde estaba el error, y cuando lo localizabas, volvía a empezar el ciclo perforación-compilación-prueba, hasta que sorprendentemente…
¡El programa funcionaba correctamente! (o al menos, eso parecía, que no es lo mismo). Lo das por válido y das las instrucciones a Producción para que se ejecute cuando le toque. Ahora sí hacías un diagrama precioso de tu programa, usando la plantilla, para que quedara claro, indicando entradas y salidas, datos por consola, y qué hacer en caso de error: lo normal era poner: “llama al Programador y que resuelva el desaguisado”, en palabras más técnicas, eso sí. Sea la hora que sea. Y los que sepáis de esto sabéis que, por algún motivo ignoto, las tres de la mañana es una hora muy apetecida por los programas para cascar. ¿He dicho ya que cuando un programa cascaba, se llamaba siempre al Programador, nunca al “Analista Funcional Jefe de Proyecto”?
…Y al fin, el programa entra en Producción, y por tanto, pasa a Mantenimiento. El taco de fichas de varios kilos que representa el programa definitivo lo almacenas amorosamente en unas gavetas especiales donde se encuentran los programas en Producción. Algún día habrá que modificarlo para meter algún cambio, así que más vale que esté a buen recaudo.
El listado de la compilación definitiva lo encuadernas con unos artilugios especiales que había para tal fin, y lo almacenas, no menos amorosamente, en un armario especial para guardar listados que entonces se vendía (y que supongo que ahora, no).
En cuanto a la documentación (organigrama, servilleta de bar, apuntes, resultados de la prueba, etc), la guardas donde sólo tú sabes. O mejor, directamente la tiras… Total, lo más probable es que el programa que por fin ha quedado como definitivo no se parezca mucho a los planes iniciales…
Te vas a tu usuario, todo ufano (bueno, casi siempre, el “Analista Funcional Jefe de Proyecto” va al usuario, todo ufano…), para decirle que por fin se pueden tratar las Remesas de Letras Compensadas con Vencimiento Fuera de Plaza, que antes había que tratar a mano.
¡Una Aplicación más en marcha! ¡Qué buenos somos, hoy dormiremos felices! Y sólo hemos tardado uno o dos meses en conseguirlo, y además, en los incontables tiempos muertos, hemos ido escribiendo-compilando-probando los programas para tratar las Remesas No Compensadas con Vencimiento en Plaza, próximamente en sus pantallas… eh, no, en sus pantallas, no. En sus listados, más bien.
Es cierto, el proceso se las traía, puramente artesanal, y puede parecer que necesitábamos mucho tiempo para desarrollar el software, pero os garantizo que en la actualidad es imposible poner en marcha ninguna nueva aplicación, por sencilla que parezca, en menos de seis meses… y los que tengáis experiencia, decidme si tengo razón o no…
El próximo día hablaré de los ordenadores mayormente programados en Cobol: los mainframes de IBM… si es que aún soportáis la idea de soportarme, desde luego. Puedes seguir leyendo con esa entrada aquí: Los mainframes de IBM.
Disfrutad de la vida, mientras podáis.
The Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 69 } Comentarios
Increíble Macluskey. Me es difícil de entender cómo existían personas capaces de soportar todo ese arduo trabajo de prueba-error-encontrarelerror-prueba-error… En verdad sí que eres Admirable. Y pensar que ahora, el programador no tiene que hacer casi nada: por ejemplo, con los entornos de desarrollo integrados como Visual Studio, Eclipse, Dreamweaver, etc. ¡¡es una riza!! Con sólo escribir las primeras tres letras de una sentencia ya te la incorpora, te da sugerencias para los parámetros, te da información detalladísima sobre los errores y sugerencias para solucionarlos, etc, etc…
Y creo que exageras un poco cuando dices “os garantizo que en la actualidad es imposible poner en marcha ninguna nueva aplicación, por sencilla que parezca, en menos de seis meses” Depende mucho a qué tipo de aplicación te refieres. Pero con todos los recursos que disponemos en la acualidad, es cosa de semanas (¡o días!)…
Saludos a todos.
@Lucas:
Bueno, no sé si éramos héroes o villanos… como no había más, no se conocía otra cosa ni otra forma de hacer las cosas, pues lo hacíamos y punto. Lo que te aseguro es que era divertido. Muy divertido. Eramos capaces de, viendo sólo las luces de la consola, determinar qué le pasaba a un programa, y arreglarlo. Conocíamos los códigos máquina de memoria. Cuando había que hacer una chapuza en un fichero (como arreglar un desperfecto ocasionado por un programa en mal estado), no nos molestábamos en hacer un programa nuevo: Agarrábamos un programa que actualizara ya el fichero (para tener las definiciones de los ficheros) y después del READ del fichero, insertábamos un GOTO a otro lado, allí programábamos en código máquina lo que queríamos hacer, al final bifurcábamos al WRITE, y en diez minutos estaba el programa arreglando el fichero. Nos sentíamos omnipotentes…
Ahora WINDOWS es el omnipotente… Sólo él sabe lo que rayos pasa en la máquina…
Gracias por comentar
Es un lujazo poder conocer de primera mano como era la programación en el “viejo oeste”. Aquí tienes un incondicional de la serie. Gracias.
me encanta esta serie es historia viva y nos aclara muchas cosas a los que sólo vimos esos mastodontes en peliculas (hay una española en la que un jovencisimo Enrique San Francisco precisamente trabaja de informatico en un banco con esos trastos). hay cosas que no cambian mucho como la del “figura” del analista, y en muchos convenios sigue existiendo la categoría de perforador de datos cosa que a mi me descoloca. ah algun día nos tienes que hablar de los usuarios.
Yo fui de los que llamaba a las 3 de la madrugada, era con nocturnidad pero sin alevosía.
Nos sabia mal, muy mal, pero poca cosa podías hacer con esos “trastos” que se paraban a medio proceso marcado como crítico. De hecho casi la mitad de los procesos estaban marcados como críticos y efectivamente la única nota que nos dejaban es que si petaba llamásemos a tal o cual. Lo curioso es que la mayoría de las veces que llamabas te decían que cancelaras el proceso y que lo arreglarían por la mañana. Es curioso como baja el nivel de criticidad a esas horas de la madrugada
De hecho solo recuerdo 2 veces en las que vino alguien a arreglar algo. La primera la sufrí de mala manera ya que fue un error mío de novato (eramos 2 siempre de operador, excepto en festivos como navidad y eso). Vinieron 3 personas: el programador, después su jefe y al cabo de un rato el contable!. Que mal lo pasé.
La otra vez que recuerdo fue cuando se rompieron 2 de los 3 aires acondicionados industriales, la temperatura subía a un grado por cada 10 minutos y eso tenía pinta de petar. El gran jefe vino a parar ciertos sistemas “no críticos” (no sabíamos que existía eso
) y pudimos aguantar hasta el fin de turno. Nos comentaron que pasaron una mañana de perros hasta que pudieron arreglar el problema, por lo visto las oficinas no compartían la opinión del jefe en cuanto la criticidad de los sistemas parados.
He comentado que era del turno de noche ?
, pero a pesar de todo lo recuerdo con mucho cariño.
Gracias Macluskey por evocar estos recuerdos (aunque sean de una década posterior a lo que cuentas).
Mucho de lo que cuentas lo he hecho yo y empece a finales de los 80. Prueba de mesa incluida, codificación en las hojas de COBOL. Ordinogramas o organigramas, aunque para nosotros el organigrama era el diagrama funcional, el de poner que cinta usabas y donde se gravaba o si se usaba o no la impresora.
@javi, martín: Gracias por comentar. Como tengo pensado escribir algún capítulo más, tendremos ocasión de comentar las anécdotas.
@Sorrillo: Con que…¿fuiste tú, eh??? Grrr!
Es broma. Porque nosotros éramos tan ignorantes que, a las dos de la mañana o la hora que fuera, nos levantábamos, nos vestíamos, nos echábamos un café por la espalda, trincábamos el coche (un Seat 600 de quinta mano, qué os creéis), nos íbamos al Ordenador y a arreglar lo que fuera. Si no terminaba durante la noche, no se podían cerrar los procesos del día, y todo, todo, se retrasaba inevitablemente, así que no quedaba más remedio. Pero lo hacíamos con cariño, incluso, si era más tarde (a las seis o siete de la mañana en vez de las tres), encima de ir a arreglar el desaguisado… ¡llevábamos churros para los Operadores!!! ¡Eso es espíritu, qué rayos!!
Añoro esos días. Y no sólo porque tenía treinta años menos.
Gracias y un saludo.
Eres mi ídolo! Sigue escribiendo, estás arrojando luz sobre una época de la informática que me interesa bastante. Eso si que era informática de verdad
Muy interesante, pero flipo con lo de tener que escribir a mano el programa en el lenguaje que sea y luego tener que llevarlo a perforar. ¿Es que no existía ningún editor de líneas como el ED que venía con el DOS, donde poder escribir, editar y guardar en disco los programas?
Si yo estuviese en esa situación no dejaría de comerme la olla hasta tener uno (yo es que soy de sistemas, no de gestión :-p )
¿Es que no se podía guardar el código fuente en un fichero y que este fichero se le pasara como parámetro al compilador para generar el correspondiente fichero ejecutable?
Lo de depurar una y otra vez los programas también lo recuerdo en mi infancia, pero sin que me pagaran por ello y con la relevancia de un mero entretenimiento y el desarrollo de mi propia creatividad.
La programación espagueti esa, siempre había pensado que era por el lenguaje BASIC con sus lineas numeradas de 10 en 10 y sus instrucciones GOTO para hacer lo que hoy son bloque de código, y GOSUB número_de_linea en vez de un CALL nombre_función, pero supongo que no sería el único lenguaje que se presentase de esa manera (como espero ver en la próxima entrada).
@joel: Respondo a alguna de tus dudas:
“¿Es que no existía ningún editor de líneas como el ED que venía con el DOS, donde poder escribir, editar y guardar en disco los programas?”
No. No es que no existiera este tipo de editor. Es que en aquél sistema de NCR no había pantalla alguna donde usarlo. Si te fijas en la foto del Sistema, no hay pantalla por parte alguna. En otros sistemas (IBM, sobre todo) ya había pantallas desde 1972 o así… pero carísimas, y además, apenas había con qué usarlas: el MVS se comenzó a vender en 1974, y el SPF (el primer editor decente de IBM) no se comenzó a vender hasta 1977 o así. En una palabra: la única manera de leer un programa fuente era en ficha. No había otra posibilidad.
“¿Es que no se podía guardar el código fuente en un fichero y que este fichero se le pasara como parámetro al compilador para generar el correspondiente fichero ejecutable?”
En realidad, sí. El compilador de NCR guardaba siempre el programa fuente en disco, y allí lo dejaba (en el mismo donde luego quedaba el ejecutable). O sea, se podía recompilar en cualquier momento si se dañaba el cargable. Y ya tenía por entonces un sistema (de cuyo nombre no me acuerdo, lo siento) que permitía introducir las fichas perforadas de la modificación e incluirlas en el programa fuente original.
Pero pocos usábamos esta posibilidad: A ver si soy capaz de explicarme: El código por el que hacía fusión (entre las modificaciones y el programa almacenado) era por página/línea, es decir, por las primeras seis posiciones de cada línea. Entonces, para poder usar el sistema:
O sea, el sistema de actualizaciójn de fuentes existía, pero era un cognazo de usar. Resultaba mucho más sencillo no perforar pag/lin, y recolocar las tarjetas perforadas a mano, y era incluso menos proclive al error. Y siempre tenías tu bloque de fichas para poder comprobar cualquier cosa.
Y lo del código spaghetti… no creo que hayas visto muchos. Yo sí. Muchos. YO he programado una tonelada:
Goto p’arriba, goto p’abajo, a un párrafo donde sólo hay un goto a otro sítio, donde se pregunta si pasa algo, y si pasa goto p’alla y si no pasa goto p’aca… Incluso había desalmados (no tienen otro nombre) que usaban la sentencia ALTER del Cobol (que el demonio se lleve). Por ejemplo, tú tenías un párrafo tal como éste:
PEPITO. GO TO JUANITO.
Pero luego, cuatrocientas líneas más arriba, o quinientas más abajo tenías una instrucción que decía:
ALTER PEPITO TO FULANITO.
Cuando se ejecutaba este ALTER del infierno, PEPITO ya no era un goto a JUANITO, sino a FULANITO. O sea, cuando la lógica del programa llegaba al párrafo PEPITO, el programa seguía por FULANITO… pero claro, lo que TÚ VEIAS en el listado es que hay un GO TO a JUANITO. No a FULANITO.
Como para buscar un error ahí dentro. Porque, como puedes imaginarte, había varios ALTER esparcidos por el programa para apuntar cada vez a un sitio diferente… De verdad, no entiendo la mente de alguien que es capaz de parir un programa de esa manera… salvo para fastidiar, claro.
Perdón por el rollo.
Y yo me quejo del compilador de c++ :S
El año que viene esta serie va a ser lectura obligatoria de todos mis alumnos. A ver quien es el guapo que se queja de java y bluej!!!!!!!!!! los pongo a perforar tarjetas!!!!
Mac, perdona que sea pesado. Con lo del editor, no me refería a uno en pantalla, sino a uno de “linea de comanos” que se pudiera usar con el teletipo: teclado+impresora_papelpijama.
Me resulta curiso que con la paliza que os pegabais cada vez, no hubiera ganas de invertir algún tiempo extra en crear algún editor que os simplificase infinitamente el trabajo (y hasta de venderlo
, y que se pudiera usar desde el prompt del sistema operativo.
@ cruzki,
Mejor aún, te llevas a Mac a una clase. Puedo verlo en mi cabeza:
“¿IDEs? ¡¿IDEs?! En mis tiempos no usábamos PANTALLA ni TECLADO, ni podíamos ver NADA de lo que estábamos haciendo. Usábamos tarjetas perforadas, y no teníamos con qué perforarlas: ¡LAS PERFORÁBAMOS CON LOS DIENTES! ¡¡CUANDO TENÍAMOS SUERTE!! ¡Y NOS GUSTABA!”
Oye, oye… Sin calumniar!!
CON LOS DIENTES, NO, ¿eh? (más que nada, porque no había forma de acertar en el sitio correcto). Pero con Boli BIC, ¡ya lo creo!. Y tampoco es un sistema tan obsoleto, que los EEUU siguen votando en sus Presidenciales usando tarjetas perforadas, que perforan (supongo que a boli) los votantes para marcar lo que desean… al menos hasta 2004: acordaos del follón sin par del 2000 en Florida con las “tarjetas que perdían agujeritos por el camino cada vez que se leían…”
@joel: No te había entendido, perdona.
Pues no, la verdad es que no se nos había ocurrido, pero tienes que tener en cuenta tres cosas:
una: sólo hay dos ordenadores, que valen para todo. Si editas, no pasas los procesos, ni compilas, ni nada. Difícil de obtener tiempo para esto.
dos: es más barato usar las tarjetas, y queda constancia de lo que has hecho. Era bastante habitual que las cabezas de los discos aterrizasen en la superficie del disco, quedándote sin cabezas… y sin disco, por lo que las tarjetas eran el backup de última instancia.
tres: ¿Te has dado cuenta que el ordenador tiene 32 KB? Un programa de 1000 líneas (medio para la época) de 80 caracteres ocupa 80 Kb. Y no los hay.
… y cuatro: Caramba, éramos listos (al menos, YO era listo, je, je), pero se ve que tanto, no, de hecho no sé contar…. Además, no teníamos con qué comparar: nadie había visto aún lo que se podía hacer con un editor de línea de comandos…
Y pregunta, pregunta lo que quieras… si puedo, resolveré todas las dudas.
Saludos a todos
Muchas gracias por recordarme esa grán época de mi vida, si bien no sufrí las targetas perforadas el método de escribir, compilar, corregir e implementar programas en Cobol, Fortran 66 y RPG fue durísimo. Pero igualmente recurdo con mucho cariño esa época.
Que tiempos aquellos, yo tenia un S/32 de IBM y eramos cinco en el departamento y no tenimaos fichas perforadas pero teniamos unas grabadoras que hacian los mismo, primero se graba y luego se verificaba, despues se copiaba al ordenador y p’alante. Toda la programacion se hacia en papel con diferentes hojas, de fichero, de entrada de calculo, de salida, ademas los impresos de salida habia que hacerlos por posiciones en el impreso. Era un ordenador que tenia la impresora integrada y si imprimia, no se podía hacer nada. Yo fuí de aquellos que nos sacaron de administrativos y con unos cursos nos fuimos haciendo informaticos hasta llegar, unos a Directores y otros al INEM.
Sencillamente genial. Me estoy volviendo adicto a tus historias, y espero con impaciencia tu próximo artículo sobre el COBOL!!
Un abrazo
Si hubiérais visto las caras de los pobres cuando les expliqué lo de las tarjetas perforadas, lo de los discos duros “lavadora” y esas cosas, simplemente FLIPABAN. Llevar a un veterano de guerra a clase para que les explicara todo eso sería un honor, en serio. ¿No vivirás por Santander?
Gran serie de artículos!!
Informática artesanal! (y yo que me quejaba cuando empecé a currar primero en un ibm y luego en un bull, eso sí, cuando te acostumbras está de la ostia!!)
Salud!
Madre mía, no leía algo tan entretenido desde hacia mucho.
gracias por compartir la experiencia
He llegado a través de Meneame. ME ENCANTA. Algo de todo esto nos contaron a nosotros en clase pero claro era muy distinto a esto.
Madre mía yo ya había visto lo de las tarjetas, aunque no me imaginaba que fuese asi, y yo que creía que no había otra cosa peor que programar en Basic, ya que al menos en C si había un fallo y no compilaba pues decías hay un error y lo buscabas, pero con el basic despues de haberte tirado 3 días con sus muchas horas programando (ya imaginar la cantidad de lineas de codigo ) te tiras otros tantos días probando y piensas bien no hay fallos se lo dejas a alguien para que heche un vistazo y a los cinco minutos ya hay varios errores, eso si que era una putada xDDDD
Tus artículos, a cual más interesante, Macluskey, sobre todo para los que no concebimos ya la informática sin Windows, pantalla y ratón.
Debía de ser terrible para un programador de aquellos tiempos que se le encomendara el mantenimiento de un programa no estructurado, documentado de la forma que refieres y realizado por otro compañero que se hubiese marchado de la empresa.
Una situación parecida me sucedió a mí en los 80. Se trataba de un pequeño programa de microprocesador (Intel 8085), realizado en ensamblador, cuya documentación se limitaba a crípticos y personales comentarios en el código fuente.
No fui capaz de desenmarañarlo y tuve que optar por reescribirlo de nuevo a partir de las especificaciones.
Si existian las bases de datos para los NCR de la epoca, la BBDD se llamaba “Total” y era una base de datos en red a medio camino entre las jerárquicas y las relacionales, otro famoso constructor de este tipo de bases de datos fué Cullinet con su base de datos en red IDMS de 2ª generación, Total era bastante mas sencilla aunque era anterior en diseño.
@Claudio, Bbb, Jimmy Jazz, Macfly:
Vaya, estoy “conociendo” muchos colegas de los tiempos heroicos gracias a estos artículos. No éramos muchos todavía, pero… ¡qué buenos éramos, pardiez!
Gracias por vuestros comentarios.
@cruzki:
Pues no, no vivo en Santander (y no por falta de ganas, no creas…), pero por una zarzuela de mariscos en la Playa del Sardinero, soy capaz de hacer tropecientos kilómetros!! No, en serio, no me veo delante de tus alumnos contándoles batallitas… ¡si no me aguanta ni mi hija, y eso que con ella tengo confianza!! O quizá es por eso…
Pero gracias por la invitación. Anotada queda. Quién sabe más adelante…
@Fernando-C:
Hombre lo de mantener un programa en “spaghettino” de un propio que se había largado de la empresa no era agradable… pero tampoco nos parecía tan extraño: ¡Es que todos programábamos así! Es cierto que había “especialistas” en liar la madeja de forma temeraria (sin mala intención… casi siempre), pero má-o-meno había una cierta forma de hacer la cosas de todos (que íbamos aprendiendo sobre la marcha unos de los otros), que nos permitía seguir con relativa comodidad el código.
Ya sabes, cuando estás dentro de un barril, no sabes de qué color está pintado por fuera… (Pedro me perdonará apropiarme de esta frase suya, que me ha encantado).
Gracias a todos por comentar, y Saludos
Buenas Me as dejado helado, yo pense que de estas cosas hacia más tiempo, ahora es muy distinto, el COBOL es el mismo (si no me confundo la ultima versión es del 84), pero en vez e pegarnos con los clientes nos pegamos con los analistas, y en vez de enormes maquinas con lucecitas tenemos cojonudos dualcore para conectarnos a una maquina remota con una “bonita” pantalla en negro con las letras verdes y 24 líneas por pantalla. En fin parece que no ha cambiado tanto. Eso si los grandes sistemas siguen funcionando igual, el codigo es más legible y los programas más pequeños, eso si ni se te ocurra hacer un GOTO que te comen. Espero con ansias la entrada de COBOL!!, seguro que nos sorprendes. Un saludo
jejeje pues lo de los gotos… en el último sitio que estuve había un Bull (habían tenido un DPS-7000 creo, y ahora lo tienen como emulado, para mantener la compatibilidad 20 años de programas cobol y sus JCLs y su transaccional…), bueno, la cosa es que en esa instalación sí que permitían hacer GO TOs. Un montón de veces estaban porque se daban cuenta de quer un programa estaba funcionando mal en Producción, y no había dios que saliera de algún bucle anidado o condición rara y ahí te plantaban el GO TO para arreglar el probelma rapidamente. Luego a la gente se le “olvidaba” subir la solución elegante jeje y pillabas tu luego los programas para meter cambios y te cagabas en cristo hasta encontrar los GO TOs… hasta que empezabas a usarlos tu también… que mala costumbre…
Yo tambien me quedo esperando ese artículo sobre COBOL (que añejo es pero que bien funciona la ostia jaja)
Salud!!
Muy buen artículo, me ha enganchado desde el principio al final. Un aplauso para este “gran programador”.. Si es que no hay nada como contarlo tal y como era. Ya estoy deseando leer el articulo sobre el Cobol.. que aún se utiliza y se programa, aunque luego nadie quiere saber nada de él(Yo mismo).
Un saludo.
@Ex NCR: Tienes razón, desde luego.
En el artículo digo que “las Bases de Datos sí que existían, pero con capacidades muy escasas todavía, y, que yo sepa, no había casi ninguna adecuada para los Sistemas de NCR”. De hecho, la única que podría funcionar en un Century 200 era TOTAL de Cincom.
A finales de los 70, la probamos en el Banco. La prueba no fue bien, y se descartó su adquisición, pero es posible que en otros entornos sí fuera bien; de hecho Total fue la mejor Base de Datos multifabricante de la época, hasta la llegada de Adabas y, muchos años después, de las mil relacionales. Y sí, era una Base de Datos CODASYL, o sea, en red. Ni jerárquica como IMS/DB ni, desde luego, relacional: aún faltaban seis o siete años para la primera de ellas: DB2.
Gracias por la aclaración, de todos modos. A lo mejor arreglo la entrada para citar este hecho.
@Todos: La próxima entrada será sólo para hablar de los mainframes: es que había salido tan larga que he pensado que quedaba mejor partida en dos trocitos; será en la siguiente donde entraré en el Cobol… y no, no voy a dar un curso, vive Dios (qué horror…) pero quizá os enteréis de alguna cosilla nueva, je, je.
Y, para que lo vayáis pensando: No tengo pensado escribir nada sobre “Programación Estructurada”, porque, como el valor en la mili, la doy por supuesta… pero si queréis saber más (¡o Algo!) de esta técnica, írmelo diciendo para preparar una entrada… o no.
A vuestras órdenes, sufridos lectores.
Macluskey
Delicioso artículo. Sobre todo para los que seguimos manteniendo COBOL en un IBM… y aún arrastramos cosas de “otros tiempos”. Todavía quedan algunos programas spaghetti de hace veintitantos años a los que nadie quiere meter mano.
No me pierdo las próximas entregas. Esto promete…
Muy buen articulo. La verdad es que es la epoca dorada de la informatica, donde con medios arcaicos pero mucho coco se hacian cosas buenas.
Yo trabaje de programador un tiempo en una carnicera(colsultora) y deje ese mundo asqueado. Todo se entrega mal con errores, con prisas, la mitad de la cosas no funcionan. Normal que los bancos no cambien de cobol, es natural.
Tengo un hijo que está terminando teleco (bueno, la verdad es es que dos, gemelos que han elegido ese mundillo, pero uno de ellos “postea” con frecuencia aquí) y que se lo está pasando pipa con esta serie. No para de darme la vara reclamándome que ponga algún comentario, y la verdad es que está todo está tan bien expuesto y tan didácticamente explicado que no he escrito nada porque me parecía que me quedaba poco que aportar.
Hasta hoy. No puedo menos que agradecer, en mi nombre y en el de muchos compañeros ya jubilados o fallecidos, la referencia que hace Macluskey a los pioneros “no titulados” que se formaron desde dentro de la empresa e iniciaron sus análisis sobre servilletas de papel. ¡Sí señor!
Me he emocionado, Gracias por dejar constancia de aquellos tiempos cuasi-heróicos, y sobre todo, por haber transmitido a las generaciones posteriores esas vivencias de una forma tan amena (y rigurosa por cierto).
Gran serie.
@Ikiru:
TÚ me has emocionado a MÍ.
Habrás visto que digo las cosas como las siento; a mis añitos ya no tengo que ser políticamente correcto con nadie, y lo que he escrito es exactamente lo que recuerdo y lo que pienso. Creo, no, ESTOY SEGURO que la profesión ha sido tremendamente injusta con gente como tú, gente que, sin tener ni la más repajolera idea de ordenadores, dejaron de ser botones, o administrativos, o cajeros, para ponerse a parir las aplicaciones de las empresas… y sin red (de circo, quiero decir; de las otras…).
Seguro que en próximos posts aparecerá por aquí gente diciéndome que no están de acuerdo conmigo, y tal pascual. Vale, lo aceptaré. Pero yo contaré (si Pedro me deja) lo que yo ví y viví tal como lo recuerdo… y creo que tengo una excelente memoria.
Bueno, aquí estaré un poco tiempo más, y aquí nos veremos, si lo deseas………… ¡Gracias!
Oh tempora, oh mores …… Pues aún soy más antiguo que unos cuantos. Me tocó trabajar con un Century 200 de 32 k, si, 32 kilobytes de memoria ram, ni megas ni gigas. Tenía 4 discos (lavadoras) de los qu8e uno era el sistema operativo, otro tenía los programas y otros dos para las ejecuciones de los procesos. Para cambiar de procesos o aplicaciones o trabajos de distintos clientes en los Centros de Proceso de Datos, se sacaban los discos de la lavadora y se guardaban en un armario, se sacaban los discos de la nueva aplicación o cliente, se ponían en los tocadiscos o lavadoras y se podía comenzar el nuevo trabajo. Cuando llegaron las tarjetas a mi trabajo, llevábamos años trabajando con cinta perforada. Las líneas del programa se perforaban con unas máquinas como las de escribir pero que producían unos rollos de cinta de papel con agujeritos. Esta cinta se leía y se compilaba. A veces leíamos la cinta como si estuviera escrita normalmente. El parchear estas cintas sí que era artesania de alto nivel (cortar la cinta donde hubiera un error, quitar lo que estaba mal y añadir lo que hacía falta, pegarla con unos parches y que el lector lo admitiera). Alguno habla de programar un editor …. parq qué? si la única forma de darle datos de forma personal al ordenador era a través de la cinta perforada o de la consola del operador, que era solamente un teletipo como los que había en los periódicos. No había periféricos que pudieran soportar otras entradas de información o datos. Le escribías una orden (nextdo programa), y el cacharro buscaba el programa, empezaba a ejecutarlo y no decía nada, ni permitía que el operador diera nuevas instrucciones hasta que terminaba o sacaba algún mensaje, ya fuera normal del programa o, también a veces, por errores.
Pero os puedo hablar de otoro ordenador más antiguo que conocí. Ni siquiera tenía discos. La información se guardaba en tarjetas magnéticas (CRAM, Card Ramdom Access Memory) que para ser leidas o grabadas caían a un tambor que giraba a bastantes revoluciones donde estaban las cabezas lectograbadoras. Este ni siquiera sabía de butes u octetos. Su sistema básico de almacenamiento de información era la sílaba, con 12 bits, que servía para almacenar dos caracteres alfa o tres numéricos. Y otra cosa, la bbdd Total llegó más tarde y fue un fiasco. Multiplicaba la utilización de CPU de tal forma que ralentizaba tanto el rendimiento del ordenador que se tiró atras todo el aplicativo. Y ya vale que me enrollo. Y después llegaron los primeros dinosaurios, por el pleistoceno, o un poco antes.
Sigo esta interesante serie de artículos, pues me retrotraen 40 años atrás cuando vivía entre la sala del ordenador y la sala de perforistas. Yo no programaba, pero era el que ponia siempre al final de la cola del trabajo de las perforistas lo que traian los programadores. Luego cuando lo llevaba al ordenador también pedía que lo pusieran a la cola, pues lo primero eran los procesos que tenia que recoger y entregar a l departamento de comprobación para cuadrarlos y cerrarlos para dejar salir al personal. Para los programadores les recogía y les repartía inmensas cantidades de papel pijama con las compilaciones, pruebas y sus asuntos diversos que salían de la sala, como bien dices se hacía musculatura trabajando. También recuerdo programadores pedirme maquina para grabar mientras las perforistas iban a merendar o al final del turno. Lo de que la grabación de datos siempre era con chicas es verdad (para nosotros era un deleite y un coto de ligoteo), pero era porque realmente eran mas rapidas y mas fiables (menos errores) que los escasos chicos que habían. En fin, que por lo que veo era todo igual en todas partes. Hasta lo de ir los domingos por la mañana al banco. Y suerte que en aquel entonces solo había tres tipos de cuentas: corrientes, ahorro y a plazo. Por cierto, la calculadora a manubrio que sacas en el anterior articulo era de la marca Facit. Era perfecta para aplicar la formula del “carrete” en las liquidaciones de remesas o de cuentas. Saludos y te reitero mis felicitaciones por los artículos.
@Jotayes: ¡Qué gran verdad! El Banco donde yo estaba era un avanzado: ¡ya usaba tarjetas!, pero aún se usaban cintas perforadas en los paratos de comunicaciones con las pocas oficinas que tenían un cacharro para grabar los movimientos y transmitirlos vía teléfono, en vez de en valija. Luego esa cinta perforada con los apuntes del día se metía en una máquina que la convertía a una cinta magnética que es la que de verdad leía el ordenador en elproceso diario.
Por lo demás, efectivamente en todas partes cocían las mismas habas… el Sistema con el que te pegaste es igualico, igualico que el defunto de mi abuelico, ehh, digo que el Century 200 que describí en la entrada anterior de la serie: échale un ojo si no la has visto ya. Te gustará, supongo, porque hasta he conseguido imágenes y todo…
@Pobaix: Otra vez bienvenido. Y gracias por tus comentarios. Y sí, la calculadora era una Facit igualita que una que teníamos en mi Banco… ¿No estaríamos en el mismo, por ventura? No, no lo digas, mejor sin nombres, que si no igual nos demandan por desvelar “secretos industriales”…
…………..Al final nos vamos a juntar acá una panda de triceratops del Precámbrico…. ¡Qué gusto ver que aún quedamos por ahí algunos!
Bueno, pues yo ya no sé si decir nada, porque alguien me va a decir “¡cállate, niño!” de un momento a otro… menuda panda de viejales
Ahora en serio: esto demuestra que lo de que los jóvenes no quieren saber del pasado, que les da igual y todo eso, es mentira cochina. Según cómo y de quién, les encanta (iba a decir “nos”, pero ya estoy en el límite… o eso pensaba hasta hace unos días, tanta senectud por aquí me está haciendo sentir como un zagal). Hala, queda dicho.
Muy interesante este blog. Me encanta. Es curioso observar que los debuggers están presentes casi desde el mismo momento en que existieron los ordenadores y que el funcionamiento de éstos sigue siendo prácticamente igual. Al menos podíais depurar. Hoy día aunque parezca mentira si programas para móviles J2ME no tienes opción de usar un debugger. Hoy día creo que los sistemas modernos nos aborregan de mala manera y resulta curioso que teniendo tan buenos IDE’s hoy día se cometan taaaaaaaaaaaantos errores de programación.
Sr. MacLuskey: Con infinito agrado, y porque no, añoranza y un poquitìn de melancolìa, tuve acceso a su art “Historia de un viejo informàtico…”. Le comento que yo me iniciè en esto de las “computadoras”, alla por Marzo de 1970, haciendo un curso de “Convencionales de IBM” para ingresar a una Reparticiòn del Gobierno como Operador/Programador de esas nobles maquinitas. A partir de Diciembre, ingresè en una voràgine de capacitaciòn, en Programaciòn y posteriormente en Anàlisis de Sistemas, obviamente en IBM y NCR. Asì tuve acceso , sucesivamente, a los siguientes Equipos: NCR-Century 100 , NCR-395/300, NCR-400, IBM S/34, NCR-8250, NCR-9020, IBM-S/3, IBM S/360, IBM S/370, IBM S/4331, y NCR-TOWER 32. Para lo cual tuve que capacitarme en varios lenguajes de Programaciòn, asi como en los Sistemas Operativos correspondientes, desde FULL ANS COBOL, NEAT/3, RPG II, y desde BCD codificado en decimal, OCL, y IMOS III, hasta DOS/VSE y UNIX V, pasando por ICCF y CICS, de IBM. Obviamente, y casi contra mi voluntad, me incorporaron a toda la saga de PC’s que fueron poniendo en el mercado, hasta que, en 1992 me retire por razones de salud. Debo decir que “la posta” la tomo mi hijo, quien esta haciendo estudios universitarios en el tema, amèn de haberse involucrado desde hace varios años, por aficciòn. Como podrà observar, y sin pretender hacer ningùn parangòn con Ud, yo tambièn podrìa considerarme un “Viejo Informatico”, reconociendo, palabra por palabra, su ameno relato de los “procedimientos” y “tècnicas” de aquellos años, y porque no, “mañas”, que ud, con buen tino, prefiere guardar, pero que yo doy por asumidas… porque con seguridad eran las mismas que las mias. Como anècdota, y para consumo de su dignos lectores, le puedo relatar que, en oportunidad de estar haciendo unos procesos de Facturaciòn de Energìa Elèctrica, surgiò un error, grave, en alguno de los programas, y quien estaba a cargo del “mantenimiento” del Sistema, se encerro por mas de 72 horas, absolutamente solo, y sin permitir interrupciones de nadie, bebiendo algunas gaseosas y masticando algùn sandwich, hasta que resolviò el problema. SEñor, reconozca en mi a un “colega”, lo que significarìa un HONOR personal para mi, si asì ud lo aceptara. Le escribo desde la Ciudad de Santa Fe, Repùblica Argentina. Un abrazo….
@Patricio: Muchas gracias por el comentario… Aaah, ¡qué tiempos aquéllos!, en Argentina igual que en España… Y yo también he trabajado mucho, no sólo con NCR, también con mainframes de IBM… la próxima entrada, que ya está en el horno, hablará de ellos.
Me alegro que le guste… bueno, que TE guste, si no te importa… creo que, colegas y cuasi-ancianos, podemos tutearnos tranquilamente sin que resulte una descortesía.
Aunque digo también que es un placer, de vez en cuando, encontrar un trato educado en la red, tan desabrida en muchas ocasiones…
Muchas gracias de nuevo.
Hola. Me has hecho recordar tiempos atrás…. Tal como se dice “Te lo has bordao” . Ya ni me acordaba de todo eso.. lo he comparado con la actualidad y realmente las cosas cambian. Por aquí en casa aun tengo programas con tarjeta perforada en cobol y el código en papel pijama 11×132.
Hoy me has alegrado el día.
Saludos.
PD: Un poco mas y lo escribo en MAYUSCULAS…..
@Macluskey
Pos a mi si que me interesa la entrada de programación estructurada. Sobre todo en cuestiones sobre cómo os reciclasteis, cuando os disteis cuenta de que había que cambar el chip, de donde provino todo el tinglado, que cambio en la empresa… vamos ese tipo de cosas
@Jaume: ¿TÚ SABES LO QUE TIENES??? Un programa Cobol en tarjeta perforada, con su listado en papel pijama es un incunable que no se encuentra en la red en parte alguna: yo no conservo ninguno (Idiota de mí), ni conozco a nadie que conserve uno.
Una auténtica labor benefactora de la especie humana sería que escaneases o fotografiases ambos (no enteros, claro, por ejemplo un par de fotos del taco de fichas y del listado y dos o tres fichas y páginas escaneadas o fotografiadas… Si lo haces y me las haces llegar por cualquier medio, las incluyo en la entrada y en entradas sucesivas que vendrán.
Puedes contestar, si lo deseas, en un comentario, y hago por ponerme en contacto contigo. Y oye, si no estás, por la labor, pues vale, no hay problema.
Gracias!!
@cruzki: Vale. Me lo pienso. La verdad es que visto desde ese punto de vista, sí puede resultar interesante, porque lo de la secuencia-selección-iteración está muy visto… claro que si hablamos de programación invertida (Jackson) ya no será tan conocido, ¿no te parece?
Pues eso, me lo pienso. Y si tienes ideas, sobre esto o cualquier otro tema, no dudes en comunicármelas.
Un par de recuerdos…. 1. Los “organigramas” como uds., los españoles los denominaban, para nosotros, los argentinos eran “diagramas de flujo”, y hasta que apareciò la Programaciòn Estructurada, esos “Diagramas” eran de dos tipos, segùn las Empresas proveedoras de los Equipos. Para IBM, se diagramaba “en àrbol”, muy parecido a lo mostrado en este post. Para NCR los Diagramas de Flujo se debìan hacer “lineales”, es decir, una secuencia vertical, de arriba hacia abajo, y encolumnàndose hacia la derecha, con conectores. 2. lo que en España uds llamaban “octetos”, para nosotros eran “bytes”. El papel-pijama, era(es) “formulario contìnuo”. 3. Trabajar con las “tarjetas (fichas) perdoradas” era todo un desafìo de habilidad y fuerza. Considerando que en cada tarjeta se incluìan datos para un solo registro o ìtem, y algunos archivos(ficheros) se integraban por decenas de miles de registros, manipular esos enormes volùmenes de tarjetas implicaba que se debian tomar “lotes” de aproximadamente 500, sostenerlas apretàndolas entre el pulgar y los otros cuatro dedos de la mano derecha, ordenarlas y emparejarlas (como un mazo de naipes) con la mano izquierda, y finalmente colocarlas en la “estaciòn de lectura” con precisiòn. Las tarjetas tenìan un recubrimiento plastificado que las hacìan sumamente resbaladizas, asi que, el “mazo” de tarjetas que se sostenìa en la mano podìa deslizarse….y todas al suelo. EL desastre. 4. Desde el advenimiento del IBM S/370, ya se disponìa de una estaciòn de diàlogo con el computador, ademas de la consabida “consola” de luces, perillas y botones que aquì se muestra, que consistìa en una suerte de màquina de escribir elèctrica, que habilitaba un teclado mediante el cual se podìan dar “instrucciones” o “comandos” a la màquina, y recibir de ella mensajes y estados de los procesos que se estuvieran corriendo, o situaciones particulares del funcionamiento del computador. Perdòn por la intromisiòn….
@Patricio:
Muy cierto todo. Acá también llamábamos “diagramas de flujo” a los organigramas… aunque menos, eso sí. Y, aunque había quien hablaba de octetos, casi todos decíamos bytes.
Pero todas las apreciaciones que viertes son ciertas… olvidadas, pero ciertas.
Un placer, colega…
¡Qué sensación de angustia al leer este post! Me agobia pensar que desde que escribiais el código hasta que lo podiais compilar, y ya no digo ejecutar, podían pasar días. Acostumbrados a la inmediated de hoy en día, el ciclo de programación-compilación-prueba de hace apenas 30 años parece eterno.
Enhorabuena por la serie de posts, da gusto leer tantas buenas historias tan bien contadas.
¡Saludos!
Joder, qué recuerdos…. A mí esa época me pilló de refilón (empecé en la informática en el 82) pero todavía había un perforador de tarjetas fuera de uso en mi primer curro, y esas libretillas cuadriculadas para escribir el código (cada cosa en su columna).
Todavía en los 90 algún “gurú” se quedó flipao viendo cómo iba una aplicación COBOL sobre ficheros indexados bien hecha le daba cien vueltas en velocidad y estabilidad a su base de datos de moda con su lenguaje de moda.
@eltator: Hombre, angustia, angustia…. espero que no sea para tanto. Como no conocíamos otra cosa, pues estábamos acostumbrados. Noera tan terrible…
@supermon: ¡Y que lo digas!! Una aplicación con ficheros secuenciales o indexado bien diseñada o escrita le da cien vueltas a casi cualquier otra con Bases de Datos.
(Atención: batallita:) Recuerdo a finales de los noventa un Banco enorme que estaba cambiando una aplicación de las más grandes. Participé en el diseño de los programas de descarga de lo antiguo y carga en lo nuevo (mogollón de millones de registros). Me tuve que poner burro (y eso que se suponía que era uno de los que mandaban en el cotarro) para que se hiciera descargando la Base de Datos antigua (IMS), procesando toda la información en puro batch (ficheros secuenciales, sort, merge, padre-hijo, en fin, el tipo de diseño que cita el artículo), y al final cargar las Bases de Datos resultantes (DB2). Todos los “gurús”, como tú les llamas, avisaban que el proceso no iba a terminar nunca, que había que hacerlo como sabían ELLOS: accediendo a diestro y siniestro a Bases de Datos, y tal. Lo que hubiera requerido como tres veces más horas de desarrollo, claro…
Cuando llegó el momento, la Carga inicial se hizo en cuatro horas, sin un fallo, y todos se quedaron alelaos… hasta que, dos minutos más tarde, sacaron pecho diciendo aquello tan manido de: “Fijaos qué bien lo HEMOS HECHO NOSOTROS”. Qué te voy a contar….
Ante todo, gracias por el tiempo dedicado en esta historia, es simplemente genial.
Tengo una pregunta sobre el orden de las tarjetas, ¿cómo se numeraba su orden? ¿Qué pasaba si queríamos añadir una tarjeta por medio del programa?
Un familiar que trabajaba en una mainframe en un banco de Sevilla me dijo una vez que usaban el truco de dibujar una línea en diagonal sobre el canto del montón de tarjetas, así se podía ver de una ojeada si se mantenían en orden o no. Para ello usaban una barra de grafito blanda de dibujo, lo que permitía borrar la línea si queríamos “actualizar” el orden. ¿usabais este método?
Gracias de nuevo por una maravillosa lectura
Un buen amigo me ha enviado esto por correo, sabiendo que yo soy de la VIEJA GUARDIA. Realmente, me ha emocionado no sólo por los recuerdos (intensos, buenos y malos) sino por el magnífico “revival” que ha hecho el autor de aquellos pasajes. Comencé en el 64, con máquinas UR (Unit Record): Intercaladora, Clasificadora, Tabuladora, etc., naturalmente con tarjetas Hollerith. La programación dura sobre hard, a base de conexiones de centralita telefónica, se las traía. Luego pasamos con los ordenadores de IBM 1410, 360/20 a fichas, 360, 370, 43xx … empezando por aprender a plasmar la lógica de flujos de datos por medio de los ordinogramas y luego los lenguajes de programación… ¡Oh, qué sufrimiento y qué gozo aprender y dominar el Assembler, con sus instruciones RS, SS, RX, RR, SI, de media palabra, palabra y doble palabra! Creedme que, en mis 14 años que dediqué (en horarios nocturnos) a enseñar en las academias de Informática el arte de la programación, nunca disfruté tanto como cuando enseñaba Assembler, ya que era gratificante ver las caras de asombro de los alumnos cuando entendían el mecanismo del compilador, los registros de Base, Desplazamientos, modificaciones directas sobre los bits de una instrucción de Dato Inmediato, etc. Y de la lógica enmarañada de una secuencia de ordinogama de “servilleta”, se pasó -afortunadamente- a la programación estructurada (Jackson, Berttini…). Y, volviendo al Assembler, que por ser el de más bajo nivel, después del código de máquina, era el más económico en términos de requerimientos de memoria ejecutable, además de esto, maravilloso para elaborar módulos standares para cualquier tipo de aplicación y lenguaje. Yo he utilizado en ciertos módulos mandatos de canal (IOCS físico) para hacer diabluras con las cintas magnéticas. ¡Qué tiempos! El RPGII, el COBOL ANSI y su combinación con el lenguaje de Bases de Datos DL/I… todo suena como una sinfonía maravillosa, que es el ayer de nosotros, los pioneros, y la nada para los jóvenes de hoy. ¡Qué viejos somos! ¡Pero cómo lo pasamos entonces, y qué prestigio llegamos a tener! Muchas gracias por la iniciativa y saludos a todos los de mi generación. Por cierto, era administrativo a los 21 años, cuando me metieron en esto de la Informática, he pasado por programador de aplicaciones, de sistemas, administrador de BBDD, analista de aplicaciones y director de Informática… en 42 años. Os admiro, compañeros.
@Sherry:
Un placer escucharte, amigo.
Como verás si sigues los comentarios, todavía quedamos algunos de aquellos viejos rockeros dando guerra… ¡y lo que nos queda!
¡Y qué bien lo pasábamos trabajando catorce o dieciseis horas diarias!
En fin, muchas gracias por comentar
mil gracias por los articulos! me encantan estas historias, yo empece ingenieria informatica en 1999 y me divertia mucho haciendo practicas en emsamblador y ejecutando algoritmos a mano, aunque es complicado y tedioso al final le coges mas cariño a los ordenadores y entiendes mejor como funcionan, desde entonces nunca toco el ordenador hasta la hora de codificar en el lenguaje que sea, aunque tenga que gastar una libreta entera con esquemas y pseudocodigo.
Salut!
Gracias, Macluskey. El placer es mío y, por lo que veo, de otros muchos, de disfrutar de una exposición tan fidedigna con la que nos sentimos tan identificados. Pido disculpa por mi primer comentario, en el que me he mirado demasiado al ombligo, cuando en realidad quería sumarme a las sensaciones de cada una de tus certeras definiciones. Aprovecho para hacerlo ahora. Yo conservo como reliquias las plantillas de plástico de los organigramas y alguna ficha perforada (de 80 y de 96 columnas), así como trípticos con los códigos mnemotécnicos, formato de instrucciones de máquinas, código EBCDIC y tablas de conversiones hexadecimales y binarias. Añoro la metodología que seguíamos: el análisis funcional, con sus dossiers del estudio del sistema manual y documentos empleados, así como el flujo interdepartamental y el nuevo enfoque mecanizado (de hecho, Informática asumía también la responsabilidad de Organización Interna), el análisis orgánico con sus dossiers conteniendo el organigrama de la aplicación, los modelos y fuentes de inputs, de outputs y sus destinos… ¡y al final, los cuadernos de carga para el programador!. Cada uno en su dossier, descripciones de ficheros de entrada, de salida (hoja pautada de impresora de 132 posiciones incluída, algoritmos a desarrollar, tablas de consultas a emplear y lista y tratamiento de errores previsibles. Todo ello, con una PREDICCIÓN MANUAL de resultados con todos los casos previstos, como mandaban los cánones. ¡Vaya caña! Del calvario (y goce) de las pruebas ya lo has dicho tú todo, de forma magistral. Sólo añadir el inmenso placer que se experimentaba cuando tenías que bucear en un DUMP de memoria, vertido sobre papel pijama, de 60 ó 80 páginas… ¡leyendo directamente en hexadecimal! Bueno, sólo de recordarlo, se me pone carne de gallina. En el devenir de mi carrera he visto y hecho muchas cosas pero aseguro con toda sinceridad que la destreza que adquirimos entonces para resolver problemas no es comparable con ninguna otra sensación profesional posterior. Estaría horas hablando de ello, pero sólo añadiré una cosa sobre la documentación. La empresa donde me formé como informático (18 años) era multinacional holandesa, con verdadera vocación documental, así que debíamos documentar perfectamente ANTES y DESPUÉS de producción. Naturalmente, el coste del mantenimiento constante de la documentación era monstruosos, en recursos y en dinero. Todo el mundo sabe que un programa es un ser que surge de un doloroso parto y que sufre variaciones constantes hasta que se decide prescindir de él. Que no te falte el ánimo y sigue ilustrándonos de esa forma tan amena. Un cordialísimo saludo.
@ Sherry,
No sabes lo que acabas de hacer… Ya puedo imaginar a Mac salivando sin control según vea lo de las fichas perforadas. Si no duerme esta noche, tú serás el responsable
@Sherry, Pedro:
Ay, Ay, Ayyyyy!! ¡Fichas perforadas!
¿Por qué demonios casi todos tiramos a la basura las fichas perforadas en alguna mudanza?? No sabíamos lo que teníamos en la mano.
Lo viejo vuelve. Sin ir más lejos el otro día ví ¡Discos de Vinilo! de artistas modernos (Bruce Springstein y así) al módico precio de ¡¡¡Treinta eurazos!!! Glup!
Y pensar que tiré toda mi colección de vinilos, por inútiles!!
Pues con las tarjetas igual. Ay, Ayyyy!
Sherry: no tienes que disculparte en absoluto, pues sólo faltaba eso. Has aportado información interesante, y me has hecho sonreir recordando… y a otros muchos, seguro. Somos Legión… calladitos, pero Legión.
Saludos a todos
Hola viejo informático, soy una vieja informática. Qué coincidencia, tuvimos que ser compañeros, hice el segundo del Instituto de Informática tambien como tú en el año 1974 en la calle Vitrubio. A partir de ese año, ya hice cada año en un sitio diferente, pues al pasarlo a carrera universitaria, ya no teniamos ese edificio asignado. Recuerdo que hice el tercero en Caminos, en la Complutense. Posteriormente ya se creó la Facultad de informática. pudimos pasar directamente, allí pude acabarla, en la carretera de Valencia, km 7. Recuerdo allí una asignatura de quinto curso Reconocimiento de Formas, que guerra me dió. Al final la cambié por otra. Tengo recuerdos arcaicos guardados como las fichas perforadas, programas codificados de cobol , etc..por si alguien quiere para un museo.
en el siguiente enlace, podreis leer una nota del diario ABC del año 1976, que he encontrado. En él se habla de la creación de la Facultad de Informática y de la problemática que hubo para reconocer los títulos del Instituto de Informática que habíamos obtenido. http://hemeroteca.abc.es/nav/Navigate.exe/hemeroteca/madrid/abc/1976/08/17/012.html
La historia me recordo cuando mi papa trabajo en el servicio meteorologico, tenian una maquina ( hoy le llamo computadora) que ingresabas datos con cinta perforada, y devolvia los calculos en una tira de papel impresa, no habia pantallas ni teclado, vaya ni siquiera tenia unidades de disco. solo tenia botones y perillas parecidas al panel NCR. como era una maquina diseñada especificamente para el servicio meteorologico, imagino que la programacion estaba cableada, usaba valvulas de vacio, habia que esperar a que se calentaran, ahi me gusto la informatico, me sorprendio cuando vi una computadora con pantalla y teclado, me hubiera gustado vivir en tu epoca, definitivamente era lo mio
Despues de leer todo lo anterior he recordado un poco mi vida como tecnico de NCR en sistemas Century 100, 200, 300, 8500, Tower 850, etc. Han sido muchos años y muchos clientes en Catalunya, Bco Madrid Bca Mas Sarda, Banesto, Bco Sabadell, Regal Insurance, Caixa Girona, Layetana, Manrresa, Vilafranca, etc. Muchos y buenos recuerdos.
Me ha gustado mucho el artículo, además de muy interesante. Tengo 29 años y recientemente he empezado a trabajar como programador para banca y… ¡hay que ver cómo ha cambiado este mundo y cómo a su vez no lo ha hecho!
En el artículo se habla mucho de las esperas que había que soportar para hacer el trabajo, y pensar que cuando a veces el Host está demasiado ocupado para darnos la atención requerida a su debido tiempo ( ahora nos muestra un fantástico “SYSTEM” en la base izquierda de la pantalla) nos quejamos, pero sabemos que a lo sumo en escasos minutos volveremos a tener el control de la sesión…
O cuanto un programa tarda en compilar (tardar es que pase… 1 o 2 minutos a lo sumo). Y ahora con el editor detectamos un error y lo modificamos, compilamos y en un chasquido lo volvemos a probar, casi nada.
Aquellos tiempos tuvieron que ser complicados, pero a la vez el trabajo tenía que ser muy interesante, cómo me hubiese gustado haber vivido todo aquello.
Es el primer artículo suyo que he leído, pero voy a seguir leyendo el resto, me parece muy interesante. Un saludo y muchas gracias por compartirlo.
Qué historias, joer, es usted mi héroe Sr. Macluskey!!!
No llegué a trabajar con fichas perforadas pero mi primer trabajo fue crear un sistema comercial en un NCR-399, sistema opertivo Neat, mono tarea, con tres estaciones de cassette como almacenamiento magnético y 16 Kb de memoria. De pantalla, ni hablamos… El salto a un NCR-9020, multitarea (6 pantallas y tres impresoras) fue como empezar a trabajar en la NASA. Nada menos que 256 Kb de memoria y 27 Mb en disco… ¡Qué tiempos!
Wao, pero que delicia de artículo. Nunca me imaginé encontrar este tipo de información, pensé que toda esta información estaba perdida o que ya no habían personas de aquellas generaciones en la que se programa en código spaguetti. Pocas veces me contaron mis profesores que antes programaban en binario con 1 y 0 y yo que me imaginaba una computadora con dos teclas 1 y 0, jajajajaj. Eso de las tarjetas perforadas los leí en wikipedia pero no las entendí tanto como aquí. Mientras leo este artículo me imagino todo el trabajo que realizaban para programar. No hay comparación con ahora que todo es mucho más fácil, aunque también las necesidades y exigencias actuales son mayores. Yo que comencé con el Dev C++ en el año 2010 veo que me perdí de muchas cosas y me entran muchas ganas de haber nacido en la época del autor de este blog. Muchas felicitaciones por compartir su experiencia.
Mac, hace ya tiempo que escribiste esto pero aun en el 2013 me ha causado tantas carcajadas,…. es una super serie, en verdad todos los chicos que van a dedicarse a esta carrera deberian leerla de principio a fin…. yo voy a recomendarla a algunas personas que de seguro la van a disfrutar mucho.. Felicitaciones!!
Un abrazo desde Ecuador
Puf. Yo entré en 4B en 1979 y sufrí prácticamente todo, pero desde el grupo de Sistemas. Teníamos el S.O. En microfichas y con los dumps de S.O. íbamos a las citadas microfichas y localizábamos el error que pasábamos a Dayton. Parche y a correr. Buenos tiempos. Tengo que reconocer que como los NCR nunca llegue a conocer una máquina en mi vida como técnico.
Hola, buenos días. Yo soy una perforista jubilada de un centro de proceso de datos de una caja de ahorros. He llegado hasta aquí por una noticia sobre IBM y un pago a la dictadura de Franco, según @EdwinBlackBook que vi en Twitter. Me ha sorprendido tu sitio web. Te sigo desde hoy Un saludo
Gracias, María, por tu comentario.
En realidad toda la serie está publicada ya desde hace años, incluso se puede descargar en libro físico (lulu.com) o electrónico (lulu.com en epub; amazon en kindle). Así que todo el material está ya a tu disposición, por si te interesa.
Un saludo y feliz año.
¡Qué buen blog! Lo he encontrado ahora, después de catorce años y ¡qué bien explicado está todo! Estaba buscando el nombre de las profesiones de esa época, como las perforistas o grabadoras. ¿Había algún nombre concreto para las que se encargaban de verificarlas? ¿Puedo compartir este artículo en Facebook?
Aprovecho para dar las gracias por este trabajo tan minucioso y bien hecho.
Gemma: Gracias por tu comentario, que he editado como pedías para arreglar un par de erratas.
Las personas que verificaban la grabación eran normalmente las mismas que grababan/perforaban, por lo que no tenían un nombre concreto; en el caso de que algunas personas se dedicaran exclusivamente a verificar supongo que serían las “verificadoras”. Y digo “las” porque todas eran mujeres. Seguramente que algún hombre trabajaría también como perforista en algún sitio, pero en las varias empresas en que yo trabajé nunca vi a ninguno.
Y si quieres compartir el artículo donde te plazca, puedes hacerlo sin problema, citando la fuente. Y si de verdad te interesa toda esta historia de informático del Pleistoceno, te recuerdo que puedes adquirir el libro por un muy módico precio, en formato electrónico o en papel: https://eltamiz.com/elcedazo/biblioteca-el-cedazo/
Saludos
{ 7 } Trackbacks
Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta…
La continuacion de la saga. Después del entrada dedicada al equipamiento, ahora como se trabajaba en los setenta. ¡Muy bueno!…
[...] » noticia original [...]
[...] que tiempos mas divertidos
Link al articulo. Curioso, [...]
[...] monolíticos mainframes. Aparte os digo que otro artículo es muy bueno, uno que cuenta como era la metodología de procesamiento de los años 70, muy distinta a la actual, yo la he usado con mis primeros proyectos de soft en la [...]
[...] de los tiempos heroicos, comparta sus experiencias, ver como se ha evolucionado muchísimo en algunos aspectos, no tanto en otros, o ver el problema del el efecto 2000 contado desde las trincheras. Lectura [...]
[...] 3. El método de trabajo en Proceso de Datos en la década de los setenta [...]
[...] encantó este artículo que encontré a través de Menéame sobre El Método de trabajo en el Proceso de Datos en los 70′, leyendo cosas así uno entiende el presente: sobre todo las dificultades que han tenido las [...]
Escribe un comentario