LOS “FILE SYSTEMS”
Aquellos memoriosos que tengan registro del
DOS/360 (y si no me equivoco de la familia 1401, que no llegué a usar)
recordarán que en esa época el sistema operativo no se hacía cargo de ubicar
los archivos. Había que colocar las tarjetas de control (las barra barra, o
pleca pleca como les decían los centroamericanos) especificando las extensiones
y las características de los registros para que no se produjeran horribles
errores de superposición.
Había en los centros de cómputos los
“bibliotecarios” que tenían los mapas de los discos y de las aplicaciones y
debían controlar que no hubiera superposiciones, ya que ello implicaba la
pérdida de datos.
Las tarjetas que contenían esta información
se denominaban “job control” y eran una de las barreras tecnológicas para los
nuevos, motivo que originaba muchas de las demoras y errores.
Cuando llegó el OS/360 todo cambió! Había alocación
dinámica de archivos y algunas de las características quedaban grabadas en el
disco, disminuyendo la cantidad de errores por
ubicación o por haber indicado mal la longitud del registro. Pero como
todo tiene s
Cuando uno se iba del mundo IBM, las cosas
cambiaban. En la Bull 400, en lugar de // había que poner algo (un asterisco?)
en la columna 8 para marcar que se trataba de una tarjeta de control… Si mi
memoria falla, sabrán disculparme los de Bull!
Pero cuando se entraba en el mundo de
Burroughs todo cambiaba… casi no había job control, las especificaciones venían
incluidas en los programas, la alocación la hacía el sistema operativo y
solamente se incluían sentencias de control cuando el nombre de los archivos
era un parámetro.
Una cosa muy ingeniosa y que seguramente
simplificaba mucho la lógica del sistema operativo era que las tarjetas de
control se distinguían por tener un “carácter no válido” (es decir, una
perforación múltiple fuera de la norma EBCDIC) en la columna 1. Por lo demás
eran muy sencillas ya que no había casi información que suministrar y de
formato libre.
Cabe destacar la penosa adaptación de los
programadores Burroughs cuando iban a trabajar a equipos IBM…
LOAD o DUMP
Otra de las maravillas del lenguaje
establecido por los sistemas operativos era que los significados de LOAD y DUMP eran inversos en IBM y en Burroughs: lo que
en uno era pasar de disco a cinta, en el otro era pasar de cinta a disco…Y si
no me equivoco las cintas giraban al revés…
 |
| DEC PDP-8 con cintas |
LAS CINTAS RANDOM
Tal vez alguien haya llegado a usar las
cintas magnéticas formateadas de la Digital PDP-8: permitían buscar un registro
y regrabarlo sin alterar los registros vecinos. Lo sorprendente era que
funcionaban bien!
Había programas que eran el show del
rebobinado!
MAS COMPILADORES Y LENGUAJES ORIENTADOS
Complementando el artículo sobre la Bull 58
de Santa Rosa, que si no me equivoco tenía solamente 4K de memoria, otro de los
equipos de desarrollo de software dirigidos por Esteban di Tada hizo un
lenguaje llamado LORAC, lenguaje orientado al acero…
No fuimos muy creativos en los nombres…
Si mal no recuerdo estaban en ese proyecto
Eduardo Martínez y creo que Lito Bulwa. Aclaro que no es el Eduardo Martínez
que fue decano de Ingeniería y estuvo entre otros lugares en el INTI.
SYNAPSYS
Retomando lo comentado por Rodolfo Naveiro,
un grupo de los “Juniors” de Ingeniería nos juntamos para desarrollar sistemas.
Un primer cliente potencial era una empresa
de electromedicina con la que teníamos la fantasía de poder realizar sistemas
administrativos que interfacearan con los datos técnicos que brindaban las
aplicaciones médicas. Ese fue uno de los motivos de la elección del nombre,
pero como los nombres de las empresas no podían ser “cosas comunes” y estaban
de moda las que terminaban en “sys”, cambiamos las dos letras i de sinapsis (la
forma que se transmite la información en el cerebro) por y.
Pasó felizmente el control manual de la
Inspección de Personas Jurídicas y el registro de marcas, pero como éramos
jóvenes sin muchos recursos, no contratamos el abono de la empresa de registro
de marcas para que nos brindara sus “servicios de protección”.
Un tiempo más tarde un hábil gestor hizo
que no se revisara el archivo manual “por sonido” y así fue que aprobaron
Synapsis, que resultó ser una empresa grande y con recursos… lo más barato para nosotros fue dar de baja a
Synapsys, que ya por ese entonces tenía muy poco funcionamiento!
Charlando en Ingeniería con Eduardo Losoviz (no logro recordar fehacientemente si era
Eduardo y si se escribía así el apellido), que era una seria persona de IBM,
nos preguntó que significaba Synapsys, el nombre de nuestra empresa. Uno de
nosotros, le respondió muy suelto de cuerpo que era “sin aptitud para
sistemas”.
Lo tomó en serio y nunca nos recomendaron
para ningún cliente IBM.
Con la empresa de electro medicina no
logramos cerrar nada, éramos demasiado anticipados para la época.
Lo que recuerdo es que la única oportunidad
en la que tuve que presentar copia del título universitario de Computador
Científico en mi vida profesional fue en una licitación a la que esa empresa se
presentó, en la que necesitaba indicar quién sería el responsable técnico del
área informática!
EL COMPILADOR COBOL
Varios años más tarde de las experiencias
de LORAL y LORAC, y luego de haber finalizado la experiencia de diseño del
sistema operativo de la computadora de Fate, armamos un grupo de “alto vuelo”
tecnológico para continuar con el desarrollo de software de base, que se llamó
PROA (nos gustaba mucho navegar!).
En esa época la PDP 11 de Digital no tenía
compilador Cobol, pero sí había necesidad de disponer de uno para ingresar al
mundo de las aplicaciones comerciales.
Jorge Chorny, famoso coleccionista ya
fallecido de piezas informáticas inútiles, que usaba para decorar su oficina
(filtros quemados, tornillos cortados, integrados fundidos, etc), nos dio la
oportunidad de cotizar el desarrollo de un compilador Cobol.
Debíamos hacerlo respetando las normas ANSI
(que yo había tenido que ver detalladamente para el proyecto de FATE) y decidir
el nivel de cumplimiento, que estaba establecido en ellas. La certificación en
esa época era superar la compilación y la detección de errores de un lote de unos
mil programas elaborado por la US Navy y también la ejecución de una serie de
programas sin error cuyos resultados debían coincidir.
Luego de un par de meses de profundos
análisis, llegamos a un presupuesto de costos, tomando en cuenta que la
infraestructura informática estaría a cargo de Coasin. Como sabíamos que
nuestros salarios en dólares eran muy bajos y queríamos cubrirnos de los
imponderables que seguramente surgirían en el desarrollo, multiplicamos
nuestros costos por diez y presentamos el presupuesto, que luego de unos meses
fue rechazado en EEUU por ser una oferta extremadamente barata imposible de
cumplir. El precio que le aprobaron a quién finalmente hizo una versión mucho
más reducida que la que proponíamos nosotros fue 50 veces superior.
En el mercado local muchas veces nos
rechazaban los presupuestos porque éramos demasiado caros…
Algo similar nos ocurrió con un sistema de
reserva de pasajes aéreos, en la época previa al Amadeus. Viajó uno de nosotros
a exponer el proyecto en EEUU y nuevamente nos descartaron porque éramos
demasiado baratos y no confiaban en que con ese presupuesto pudiéramos
completar el proyecto.
Ahí dimos por cumplida nuestra sociedad y
seguimos trabajando con nombres diferentes dedicándonos a proyectos con menos
ceros! Hasta tuvimos que competir entre nosotros…
Conrado Estol dijo...
Hugo Studniz hace una referencia paréntetica a la familia 1401, con la que yo sí trabajé. Y recuerdo la primera que llegó al país a comienzos de 1961 (hacia febrero, si mi memoria no me falla – cosa que ocurre frecuentemente – y seguramente hay varios o muchos dinos que pueden corregirme, más autorizados que yo para hablar de esto). En realidad fueron dos, una para La Franco Argentina – creo – y la otra de obvio respaldo en IBM.
En http://www.ausersmanual.org/images/ibm1401_1_1.jpg
encontré una foto que, lamentablemente, no fue tomada en Diagonal Norte al 900, donde estaba IBM en esa época, pero que representa lo que más o menos recuerdo era la configuración que allí se encontraba de la primera 1401 en la Argentina. Una especie de “lavarropa” (al lado de la CPU, aunque en Diagonal Norte creo recordar estaba al otro lado de la CPU) con 4 K de RAM, más a la derecha la impresora de asombrosas 600 líneas por minuto y en el extremo derecho cuatro unidades de cinta, una de ellas para el TOS (¡TAPE OS!), ya que esa primera 1401 no tenía la unidad RAMAC de discos que apareció más tarde y por lo tanto su sistema operativo estaba en una cinta.
Conrado
En http://www.ausersmanual.org/images/ibm1401_1_1.jpg
encontré una foto que, lamentablemente, no fue tomada en Diagonal Norte al 900, donde estaba IBM en esa época, pero que representa lo que más o menos recuerdo era la configuración que allí se encontraba de la primera 1401 en la Argentina. Una especie de “lavarropa” (al lado de la CPU, aunque en Diagonal Norte creo recordar estaba al otro lado de la CPU) con 4 K de RAM, más a la derecha la impresora de asombrosas 600 líneas por minuto y en el extremo derecho cuatro unidades de cinta, una de ellas para el TOS (¡TAPE OS!), ya que esa primera 1401 no tenía la unidad RAMAC de discos que apareció más tarde y por lo tanto su sistema operativo estaba en una cinta.
Conrado
No hay comentarios:
Publicar un comentario
COMENTARIOS SON MÁS QUE BIENVENIDOS. POR FAVOR CON NOMBRE Y APELLIDO. LOS COMENTARIOS AJENOS A LA TEMÁTICA DE ESTE BLOG SERÁN ELIMINADOS.