[*IBM}– Comienzos del TP en Venezuela / Leonardo Masina

Leonardo Masina

A veces el masoquismo humano no tiene límites, y aquí va un buen ejemplo.

Resulta que leyendo en este blog los artículos sobre Fernando Lacoste y su Paquete en Línea para Bancos, caí en cuenta de que, visto lo fácil y simple que es hoy en día enchufar un PC a un router ADSL y milagrosamente eso arranca, para mí aquélla era todavía la edad de los “tambores” (tam-tam), y señales de humo, y me entró la curiosidad de averiguar como empezó el teleproceso (TP) en IBM de Venezuela.

Preguntando, y visto lo poco que he logrado averiguar, Carlos Padrón me sugirió que escribiera algo a ver si alguien más picaba el anzuelo y soltaba prenda de lo que sabía y cuáles habían sido sus experiencias “prehistóricas” en TP.

Como de costumbre, caí por inocente y aquí me tienen.

Por eso he escrito este post como una dedicatoria y un “recuerdo al mérito” a todos esos pobres “masoquistas sufridores” (vendedores, analista y técnicos) que, con la poca o nula ayuda y herramientas disponibles, tuvieron que hacerse camino a machetazo limpio en la jungla telefónica para, contra viento y marea, poder abrir una brecha y hacer posible que el TP llegase a ser una realidad en Venezuela; una realidad de la cual yo, años después, pude aprovecharme consiguiendo ya un camino hecho.

Trataré de utilizar un lenguaje lo menos técnico posible para que pueda ser lo más comprensible, aunque estoy seguro de que meteré la pata, pero estoy disponible para aclarar dudas.

Mi experiencia real en TP fue ya a partir de 1975. Antes sabía que existía pero, como no me atañía, tampoco me importaba mucho, sobre todo porque en el Departamento Técnico de IBM de Venezuela estábamos divididos por sectores o áreas, así que había un Field Manager (Gerente de campo) que se encargaba de todas las instalaciones TP, como los había de UR (Unit Record) que eran las perforadoras y todo eso, y los de Sistemas.

Al yo estar en un grupo de Sistemas, con Uwe Petersen (“Bandido Pirata P. era una de sus formas de llamar a uno) aunque se atendía en parte también UR, de TP no sabíamos nada, pero yo veía, sobre todo cuando estábamos todos los CE (Customer engineer) en Capriles, los líos que se traían los pobres técnicos de TP, ya que esas líneas o terminales debían de ser irrompibles, porque la frase más común que se escuchaba era “Se ha caído la línea” o “Se ha caído el terminal”. Además de que tenían que volar como un cohete porque el Banco tal o cual se había caído el polling.

Recuerdo especialmente a Antonio Lalaguna, con quien luego llegué a trabajar y me fue de muchísima ayuda por su previa experiencia, y desde aquí aprovecho para agradecérselo nuevamente, y a Antonio Gatti, que recuerdo que era el especialista en TP en el Grupo de Soporte, pero cuyo rastro he perdido.

Lo que aprendí y me enseñaron es que, desde sus comienzos, el TP tuvo que acoplarse o adaptarse a una tecnología ya existente, que eran las líneas telefónicas de voz analógicas, mientras que las computadoras y terminales trabajaban de modo digital.

Inicialmente —o, por lo menos, así me lo me explicaron— el terminal era prácticamente una máquina de escribir o teletipo, y cada vez que se presionaba una tecla la codificación de esa tecla era enviada, a la espera de que la siguiente tecla fuese presionada, y así, hasta terminar el texto a enviar.

Con esta tecnología se trabajaba a la “astronómica” velocidad de 50 a 134.5 baudios (bauds), que así se llamaba lo que hoy se define como “bps”.

Ese protocolo, que imagino no habrá sido el primero pero sí el primero que conocí, se denominaba Start-Stop y se caracterizaba por tener dos estados:

El de Marca (M) o el de Espacio (S). El tiempo que el terminal estaba sin enviar nada se denominaba Idle (I).

La línea estaba normalmente en estado (M), y en cuanto se presionaba una tecla, el terminal automáticamente enviaba el bit de Start (St), los bits correspondiente al caracter y el bit de paridad (C), terminando la operación con un bit de Stop (Sp). Luego volvía a ponerse en espera hasta recibir el siguiente caracter o comando.

Otro problema era que las computadoras o terminales trabajaban con “palabras”, o sea, con una secuencia de bits, que hoy denominaríamos ASCII – BCD – EBCDIC, que podía variar de 5 a 8 bits en paralelo, mientras que en la línea telefónica, al ser de dos hilos, había que serializar los bits, o sea, ponerlos en secuencia de uno en uno para poder enviarlos o transmitirlos.

Otro problema existente era que una onda cuadrada —y aquí no entro en explicaciones de física del por qué— no se puede transmitir directamente por una línea telefónica, por tanto hacía falta un adaptador o convertidor que se llamaba módem por su función de modular-demodular, que lo que hacía era recibir unos datos en forma de onda cuadrada, modularlos en una onda sinusoidal analógica, transmitirlos por la línea telefónica al módem que estaba en la otra estación, y, cuando éste recibía la señal analógica, la demodulaba y la reconvertía de nuevo en una señal de onda cuadrada para enviársela al equipo receptor.

El primer módem que conocí fue el 3976, que era asíncrono en modulación de amplitud o ASK (como las radio en AM para simplificarlo), y del tamaño de un PC de hoy.

La modulación de amplitud consistía en enviar una onda sinusoidal en una determinada frecuencia: a una amplitud si era un 0, o a otra si era un 1.

Un par de ejemplos de Señales de Modulación de Amplitud.

La siguiente evolución del TP creo que fue la utilización del buffer de almacenamiento, o sea, que los datos a enviar se guardaban en una memoria temporal y, una vez listos, al ordenar el envío todo el paquete de datos se iba trasmitiendo secuencialmente, ahorrando así tiempo de transmisión.

La introducción del buffer supuso también otro método de verificación o control de los datos, que llamábamos CRC, que prácticamente era una sumatoria de todos los bits que se enviaba al final de la transmisión, y la estación receptora la recalculaba y comparaba si el CRC enviado y recibido eran iguales, y, de serlo, daba por válida la operación.

Pero al tratarse de comunicaciones entre dos estaciones diferentes hay que establecer un diálogo. La estación que envía necesita saber si el o los datos enviados son correctos para, si lo son, seguir enviando más.

Por ese motivo, y sin querer detallar un protocolo de transmisión específico, vamos a decir que la estación receptora, al recibir y validar los datos puede contestar con un YAK (reconocimiento positivo) a la estación que ha enviado, o con un NAK (reconocimiento negativo).

Un ejemplo podría ser el siguiente:

En el ejemplo, los datos van fluyendo correctamente hasta que al enviar el Data 3 se produce un error que ocasiona una respuesta negativa.

Automáticamente la estación A vuelve a enviar Data 3 y luego, al recibir confirmación positiva, sigue con con Data 4, etc.

Hablando de los protocolos —que podríamos llamar tipos de transmisión—, hasta los años ’70 en IBM, que yo recuerde, existían el Asíncrono, el BSC o Síncrono Binario, y el SDLC.

Para ilustrar a qué correspondía cada uno, va aquí un ejemplo práctico:

Por cada paquete de datos enviado, se enviaba el correspondiente Acknowledgement (AK).

Por cada paquete de datos enviado, se enviaba el Acknowledgement

Por cada paquete de datos enviado, que era de mayor capacidad, se enviaba el correspondiente Acknowledgement (AK).

A la recepción de una trama de envío, los paquetes eran numerados secuencialmente, y si uno de ellos había dado error, se notificaba cuál y la transmisión se reiniciaba a partir del que había dado el error.

En caso de no haber habido error, se contestaba con el Nº del siguiente paquete a recibir.

Aquí se podría hablar de transparent y otros términos o aplicaciones, pero terminaríamos enredándolo y prefiero dejarlo así.

En la época en que yo empecé, la clásica interfaz de conexión del TP era la que se denominaba RS-232, y era un conector de una forma un poco peculiar:

que tenía una serie de líneas de control llamadas:

DTR:  Data Terminal Reddy

DSR:  Data Set Ready

RQS:  Request to Send

CTS:  Clear to Send

Tx:    Transmitted Data

Rx:    Received data

CD:   Carrier detect

RI:     Ring Indicator

Hasta aquí un poco de teoría, y no sigo con ella.

Antes de esto ha habido algo más, por supuesto. Ya en la época de los griegos y romanos las comunicaciones remotas se hacían con espejos, como en la Edad Media se hacían con banderas entre torre y torre, además de que los indios de América, con sus señales de humo y sus tambores, sabían comunicarse ya hace algunos siglos. Hasta no hace mucho, también los barcos, por lo menos los de guerra, se enviaban señales por medio de banderas o luces.

Luego hay un bache que desconozco totalmente, que fueron los comienzos del TP en Venezuela, e inmediatamente después es cuando ya empezó Fernando Lacoste con su aplicación bancaria y todo lo que eso desencadenó.

Hice algunas preguntas indagatorias y recibí algunas respuestas. Aquí van unas y otras.

Preguntas

• Creo haber entendido que en Venezuela las petroleras fueron las pioneras en TP, ¿es cierto?
• Recuerdo que “Tata” Baro, andaba por ahí con uno cajón del tamaño de una vieja pantalla, y decía que era un módem, y lo utilizaba para hacer pruebas de línea. ¿Que tamaño tenían los módems en los años 60s?
• Un dato que me comentaron en mis comienzos era referente a la velocidad de transmisión (TP) de 134.5 bps. ¿Esa velocidad estaba basada en la velocidad del teclado de una máquina de escribir?
• Me suena familiar haber escuchado a Tata Baro y Barriga hablar de la 357, y luego a otros de la 1030 y 1050. Yo no las conocí pero, aparentemente, eran terminales. Vi los terminales bancarios 1060, e imagino que trabajarían inicialmente a 134.5 baudios, o sea sin buffer.
• Sé que en aquella época se utilizaba mucho el término Start-Stop —que luego nosotros llamábamos “Asíncrono” y era porque cada carácter era transmitido individualmente empezando siempre por un start, seguido de los bits del carácter y terminando con un stop, y así sucesivamente— hasta que llegaron los primeros terminales con buffer que almacenaban los datos y al dar enter se enviaba todo el paquete, permitiendo aumentar la velocidad de transmisión.

Respuestas

Fernando Lacoste le contestó a Carlos Padrón lo siguiente, referente a mis preguntas:

• El primer terminal dentro de la nomenclatura de teleproceso fue la 1050, que yo estudie en Endicott, pues yo era el encargado del "teleproceso" (nombre patentado por IBM).
• El módem de entonces era un cajoncito de aprox. unos 15x40x50 cm.
• La terminología de las velocidades de transmisión no era todavía en bits sino en baudios, usada en telegrafía.

También he recibido esta respuesta de Alfredo Carvallo, que espero no se moleste si la publico:

• «Es poco lo que puedo contestar a tus preguntas. No, las petroleras no fueron pioneras en esto, sus operaciones para la época no lo requerían. Sin embargo, usaron algunos terminales prácticamente como pruebas y no por mucho tiempo. Creole, la primera, usó la Data Transceiver, que fue una máquina perforadora que leía tarjetas y trasmitía la información a otra Data Transceiver, o sea, que reproducía tarjetas de de una a otra, y fue algo de corta duración. Ramón López trabajó con esta máquina.
• La Shell instaló una /360-20 como unidad de TP para comunicarse con Maracaibo, y eso fue también de corta duración.
• Los terminales 1030, 1050 etc. fueron usados más que todo por los Bancos en los años 70s. La velocidad de 134,5 bps se usaba porque era la velocidad estándar de los teletipos.
• Lo que Baro usaba era un Line Tester, una maleta con una unidad capaz de enviar y recibir señales no datos.
• Los módems eran bastante grandes, y tú los llegaste a conocer pues su usaron hasta con las /370s. Fueron de 600/1.200 y luego 2.400/4.800 bps. Algo más adelante aparecieron los módems integrados.

Y Ramón López me contestó así:

• El primer sistema de Teleproceso de América Latina lo instalé yo en la Creole, para comunicación entre Quiriquire y Caracas, en el año 1958. Fue una 066-068 Data Transceiver que transmitía tarjetas perforadas, y usábamos una línea del sistema de microondas de la Creole.
• Los módems no eran de IBM, pues en USA la compañía de teléfonos no permitía conectarse a sus líneas si no era con sus propios módems.
• Las líneas del módem y las secuencias eran:
  • Data set ready
  • Request to send
  • Clear to send
  • Send data
  • Receive data
  • Etc.
• Teníamos un aparato que intercalábamos en la línea telefónica para detectar y analizar las fallas. Se llamaba el Trend Tester y era una maleta.
• Otro dato. Cuando había que transmitir a 2.400 bps o más (bits, no bytes) por una línea muerta (dedicada), había que ecualizar la línea, o sea, poner ciertos inductores y condensadores,… y hoy por la línea vulgar te meten el ADSL con un montón de megas.

Y hasta aquí lo que por ahora me han comentado Fernando, Alfredo y Ramón, a los cuales les agradezco muchísimo sus aclaraciones.

Bueno, yo, como caí por inocente, empecé el tema y ahora a ver si alguien quiere colaborar aclarando, sobre todo, esa época “oscura” hasta llegar a la de Fernando que, por supuesto, es bienvenido dándome sus opiniones, como también serán bienvenidas las de todo el que tenga experiencias y anécdotas previas y posteriores.

Empiezo ya con un par de anécdotas.

Línea dedicada

Cuando La Vivienda E.A.P comenzó en el edificio de Plaza Candelaria (Caracas), teníamos muchísimos problemas con las líneas ya que, aunque fuesen líneas muertas (dedicadas), había muchos errores, y recuerdo que una vez Antonio Lalaguna me sugirió poner una grabadora de casete en alguna de las líneas que daba más errores. Asi lo ahice y luego al reproducir el casete, se escuchaban conversaciones telefónicas. ¡Vaya calidad de línea telefónica dedicada!

CANTV y la limpieza de líneas

Ante esto, Antonio Lalaguna me sugirió que llamara a una persona de CANTV para que revisara el problema. Así lo hice y, muy colaboradora, esa persona me dijo que esa misma noche limpiarían las líneas.

A la mañana siguiente, a primera hora, me llamaron de La Vivienda porque olía a cable quemado.

Llegué al cliente y, en efecto, había un olor tremendo a cable quemado. Verificando me di cuenta de que el olor venía del rack de módems, y al revisarlo encontré que todos los transformadores estaban quemados.

Llamé a CANTV para saber qué podía haber pasado, y me dijeron que habían limpiado las líneas. Cuando les pregunté cómo lo habían hecho, cándidamente me contestaron que le habían aplicado 120 voltios a cada una de ellas.

Por supuesto, una vez cambiadas todas las tarjetas quemadas no hubo más interferencias.

Eso sí, recuerdo que después me comentaron que los operadores de una camioneta de CANTV estuvieron por un par de días trabajando en el edificio, creo que algún que otro teléfono habrá quedado frito también.