Whitepaper acerca de Ryan-McFarland Company

Nota del productor (N.P.) de este informe

El siguiente artículo de 1996 resume, en las propias palabras del señor David McFarland, un poco de la historia de sus inicios, e indirectamente porqué, su runtime y compiler, fueron (y siguen siendo) tan populares hoy (2016), 42 años después.

Presentación del señor David McFarland

David E. McFarland fue uno de los cofundadores y vicepresidente de Ryan-McFarland Corporation, el más importante productor de compiladores de la industria de la computación entre 1961 y 1988. En 1988, Ryan-McFarland Corporation fue vendida y es ahora propiedad de Liant Software Corporation[i].

En 1995, McFarland fundó «The COBOL Foundation». Esta fundación está dedicada a distribuir información sobre COBOL y el desarrollo de herramientas COBOL para el mundo de desarrolladores de las aplicaciones COBOL. Tiene el sitio web http://www.cobol.org que provee de esta información al mundo.

Sumado a ello, el señor McFarland está implicado en el nivel de junta en varias empresas de nueva creación. Es también parte del equipo que produce «The COBOL Report», un informe de novedades para el programador COBOL profesional.

Lo que es pasado es prólogo

El compilador de fondo

Los involucrados en "el gran debate COBOL" podrían preocuparse de mi afiliación con el COBOL.

La Fundación se me hace irremediablemente sesgada. Y algunos miembros de la generación actual de Java, C ++, Visual Basic[2] y los programadores, pueden preguntarse si mi formación me proporciona alguna credencial para comentar acerca de los lenguajes de programación.

Por lo tanto, antes de darle mi opinión sobre COBOL, permítanme resumir rápidamente mis antecedentes: soy cofundador de Ryan McFarland-Corporation, que produjo más de 200 compiladores diferentes para la industria informática durante un período de 28 años. Y ya que tienen una larga asociación con COBOL, también debería hacer hincapié en que Ryan-McFarland pasó sus primeros 14 años en la producción de compiladores para lenguajes científicos como FORTRAN E, F y G para IBM, NCR, SDS, Digital, y aproximadamente cincuenta de otras compañías. Además, produjimos compiladores para PL/I, muchos lenguajes de control de proceso, y muchos lenguajes de propósito especial. COBOL es importante y popular, pero soy muy consciente de que no es el único lenguaje que nos rodea.

Nuestro primer COBOL

En realidad, no hicimos nuestro primer compilador COBOL hasta 1974 para el sistema IMOS NCR 8200[3]. Nos recuerdo a Ryan y a mí tratando de comprender el lenguaje COBOL de la pequeña azul 74 del libro estándar. Nuestra experiencia anterior fueron principalmente FORTRAN y lenguajes científicos; estábamos muy sorprendidos al leer las extrañas características de COBOL. Una y otra vez nos fuimos a NCR[4] preguntando por qué se necesitaba una característica específica. Cada vez, los programadores COBOL tenían una muy buena razón. A medida que la ejecución progresaba, poco a poco, rasgo por rasgo, se hizo bastante impresión. En ocasiones, fuimos al comité de normas[5] para resolver inconsistencias en cómo se suponía una característica particular de trabajar. Hemos descubierto que el documento de estándares tenía secciones en conflicto. En algunos casos, el comité no sabía la respuesta, y nos preguntó cómo nos parecía que la función debía trabajar. Así es como el comité de estándares llegó a inventar nuevas características en el lenguaje.

Los Comités estándares

Esta experiencia nos ha llevado a la conclusión de que la gente en los comités de normas no son necesariamente los autores de compiladores del mundo. Nos preguntamos una y otra vez para formar parte del comité de normas, pero estábamos demasiado ocupados y sentimos que nuestro papel era simplemente para poner en práctica a los compiladores del mundo, no definen el lenguaje. Uno tiene que pensar en volver al origen de los comités de normalización y su carta constitutiva. En la mayoría de los casos, se establecieron los primeros comités para estudiar qué características de los compiladores estaban usando, para determinar cuáles eran mejores, y para declarar las mejores características de la norma. Ciertamente, ellos no esperaban inventar el lenguaje.

Inventando el Lenguaje

Con los años, los clientes venían continuamente a nosotros con las características del lenguaje adicionales que debían incluirse en sus compiladores. Casi siempre, sus sugerencias creaban conflictos de sintaxis y perturbaban la consistencia del lenguaje. Siempre fue difícil para redirigir a los clientes hacia simplemente decirnos las capacidades que querían y dejando el diseño de las características para nosotros.

Grace Hopper, et al (es su territorio)

Si nos fijamos en otros idiomas que el mundo ha inventado, descubrimos que Grace Hopper[11], y los miembros originales del comité CODASYL, hicieron un magnífico trabajo que definió el COBOL original. Es probablemente seguro decir que  hicieron el mejor trabajo que hemos visto hasta la fecha. En concreto, su objetivo de definir un lenguaje portátil, permitiendo que las aplicaciones se muevan de una máquina a otra, estuvo por décadas por delante de su tiempo. Uno sólo tiene que comprender las dificultades que tenía C[6] para llevar a cabo esta hazaña casi 20 años después.

OOCOBOL[7]

La historia parece repetirse mucho en nuestra industria. El comité de normas ha inventado OOCOBOL. Al menos dos proveedores; Micro Focus e IBM, han publicado sus intentos iniciales al OOCOBOL. Las tres especificaciones son ligeramente diferentes. En última instancia, las características reales de implementación ganarán. Y así es como debe ser. Conseguir la aplicación hecha es lo que importa, no la promoción de uno u otro programa de empresa o agenda individual.

¿Qué ha hecho COBOL?

Es importante tener en cuenta lo que COBOL ha logrado hasta este punto. Se estima que hay alrededor de 200 mil millones de líneas de COBOL[9] que operan en el mundo. Al darse cuenta de que nadie puede comprender lo que  mil millones de líneas de código son, me puse a ver cuántas personas-año de trabajo representa esto. Todo se reduce a unos 30 millones de años-persona. Esto es bastante consistente con estimaciones de la industria de tres millones de programadores en el mundo, con dos millones sólo en los Estados Unidos. Este esfuerzo masivo ha ido en un largo camino hacia la contabilidad de las empresas del mundo. Los que están en el ámbito de desarrollo de aplicaciones COBOL, deberían levantarse y tomar un arco. Se han logrado las grandes hazañas en silencio.

La evolución del COBOL[8]

COBOL evolucionó a partir de la especificación original a través de la Norma-74 bastante bien. Entonces, para la mayor parte de los años 80, COBOL se sentó allí muy complaciente, con 80-85 por ciento de todos los programas escritos en él. A medida que las necesidades de las empresas continuaron creciendo, COBOL se quedó quieto. Mientras tanto, los nuevos conceptos fueron evolucionando en toda nuestra industria. Finalmente, en los años 90 [10], COBOL ha despertado, y ahora está adoptando el más útil de estos nuevos conceptos. Los principales avances se han producido en la velocidad de desarrollo de aplicaciones y la interconexión con otras herramientas de desarrollo[12].

¿Cambiará la industria?

Ciertamente, la gran cantidad de código COBOL por ahí, prohibirá a las compañías de volver a escribir todas sus aplicaciones en algún otro lenguaje, incluso si había un buen candidato en el horizonte. Como hemos oído hablar de los intentos de reescribir las aplicaciones, aprendemos de muchos más fracasos que de éxitos. La falta de lo que llamo "fuerza industrial", es lo más a menudo el culpable. Por ejemplo, se puede escribir un programa de demostración sencilla utilizando un lenguaje de base de datos, y mostrar la capacidad milagrosa. Sin embargo, cuando la totalidad del sistema se vuelve a escribir, el rendimiento se va en el inodoro.

Sé de una empresa en el sector bancario que hizo exactamente esto. Se llevó a la compañía desde hace varios años y varios millones de dólares a escribir la aplicación. Cuando se haya completado, se habrá tardado 10 1/2 horas para cerrar un banco, donde previamente hubiera tomado 1 3/4 horas. 

Todo esto se hizo para permitir al cliente usar productos para crear informes ad hoc. En realidad, había una solución mucho más simple, que permitió el uso de herramientas compatibles con ODBC para acceder a datos COBOL como si se tratara de una base de datos. Este último proyecto se llevó a seis meses: cinco meses para convencer a la dirección que iba a funcionar, y un mes para la aplicación.

Efecto 2000[13]

El problema del año 2000 será sin duda tentar a las organizaciones de desarrollo a cambiar su COBOL a la última salvadora. Cada vez hay más herramientas que están apareciendo en el mercado que ayudan a las organizaciones a localizar y ayudar a resolver este problema. Los que usan el problema del año 2000 como una excusa para volver a escribir sus aplicaciones más a menudo, no se encontrarán con grandes sorpresas.

DOWNSIZING

Durante años, los desarrolladores COBOL creían que estaba bien para el mainframe, pero no es factible para microordenadores. En Ryan-McFarland, estábamos sorprendidos, incluso cuando  mudamos a RM/COBOL a la Z-80. El rendimiento fue comparable a los ordenadores más grandes. Después de todo, es sólo un equipo diferente que pasa a ser un poco más pequeño.

Se habla de una historia de éxito tras otro, donde las empresas utilizan herramientas COBOL para pasar de COBOL mainframe de propiedad cliente-servidor o una operación basada en micro.

Oímos hablar de tasas como cambios de 450 programas en seis semanas. Esto es mucho más barato que volver a escribir. El proceso de prueba se simplifica enormemente, simplemente debido a los requisitos de prueba reducidos. Todos los algoritmos de negocios, que son el corazón de estos programas, se mueven en línea recta. Después del cambio, las aplicaciones de las compañías están ahora en sus opciones de hardware estándar de COBOL, y son infinitos. Esto suena como los que Grace, et al. estaban tratando de lograr hace muchos años. Una de las empresas que conozco pasó de un ordenador central con un costo anual de los cientos de miles a un ordenador que cuestan sólo $10.000.

La herramienta adecuada para el trabajo adecuado

A medida que observo empresas dando vueltas, intentando esto e intentando aquello, un mensaje parece llegar una y otra vez: la herramienta adecuada se debe utilizar para el trabajo correcto.

Si miramos hacia atrás, vemos que en los años 60 y principios de los años 70, las aplicaciones comerciales se estaban escribiendo en BASIC. Los que se veía en la organización interna y la arquitectura de estos programas -en los operadores de mantenimiento- se dieron cuenta rápidamente lo que es un lío incomprensible que estaban tratando. El plazo del «spaghetti bowl codification» puede haber sido originalmente aplicado a los programas COBOL no estructurados, pero la situación era casi siempre mucho, mucho peor con las aplicaciones básicas comerciales a gran escala. Darles crédito, sin embargo --que hicieron el trabajo y Basic Cuatro, Data General, y las computadoras digitales, se utilizan junto con las aplicaciones básicas para ejecutar en muchas pequeñas empresas. Esta era la única solución disponible en el momento. Desde COBOL se trasladó a las máquinas pequeñas y básicas, pero todo ha ido en base a la programación de aplicaciones comerciales.

Ciertamente, herramientas como Visual Basic, C, y lenguajes de desarrollo de aplicaciones ligados directamente a los DBMS suministrados por el proveedor, todos tienen su lugar en el mundo de la aplicación. La verdadera clave es el uso de la herramienta adecuada para el trabajo adecuado. Usted no consideraría escribir un programa de control de la nave espacial en COBOL. Simplemente no tiene sentido. COBOL no fue inventada para este fin. Del mismo modo, no se debe escribir una aplicación comercial importante en C, ya que se inventó para ser utilizado como lenguaje para programar sistemas portátiles

Yendo más lejos, con tantos grandes autores del informe en el mercado, puede que no sea, en este punto, conveniente utilizar COBOL para todas las tareas de escritura de informes.

La difícil decisión

El gerenciamiento del desarrollo de aplicaciones tiene una tarea muy difícil en la determinación de qué herramienta es la mejor para cada tarea. Parece que hay un número cada vez mayor de empresas que piensan que tienen su salvador. Las empresas más exitosas que veo corren pruebas de implementación significativas anteriores a la adopción de una herramienta en particular o un nuevo lenguaje. La mayoría de los que saltan sin la prueba apropiada, parecen dirigirse hacia un desastre. Utilizando y probando estas nuevas herramientas y las invenciones del lenguaje antes de su adopción es, sin duda, dinero bien gastado.

El futuro

En el futuro, la capacidad de COBOL, aún sin igual para la aplicación de las reglas de negocio, va a permitirle ser el idioma de su elección para las aplicaciones básicas de la mayoría de las empresas.

Fuente: Cutter IT Journal, August 2006 issue

N.P.

[i] El 11 de Julio de 2008 Micro Focus anunció la compra de Liant Software Corporation.

[2] BASIC era uno de los lenguajes que soportaba NCR en sus sistemas 8150, 8200 y 8250 para fines recreativos.

[3] IMOS era el sistema operativo de NCR para su línea 8200 y 8250.

[4] National Cash Register, inicialmente era una compañía dedicada a la creación de cajas registradoras.

[5] Debe referirse a CODASYL(Conference on Data Systems Languages).

[6] C es un lenguaje de programación desarrollado por Dennis M. Ritchie entre 1969 y 1972 en los Laboratorios Bell.

[7] Object-oriented programming.

[8] COBOL a evolucionado excepcionalmente en la senda de programación orientada a eventos y objetos.

[9] Diez razones para no migrar de COBOL.

[10] Comienza con el proyecto VanGui de Liant Software Corp. derivando en el Cobol-Wow de Bob England (1997).
[11]  Grace Hooper fue una científica de la computación y también una militar estadounidense, con grado de contraalmirante, considerada una pionera en el mundo de las ciencias de la computación.

[12] La utilización de ODBC, que más tarde haría que la herramienta Relativity de Liant permitiera que los archivos COBOL se pudieran representar como una Base de Datos Relacional (DBR) y ser interpretada con exactitud por otras herramientas, como Excel.
[13] Ante la llegada de 2000, existió un relativo pánico en el mundo dado que el 70% de las aplicaciones comerciales almacenaban en sus archivos a las fechas como YYMMDD en vez de YYYYMMDD, por lo que si al año 1999 se le adicionaba 1, daría como resultado 00 (00/01/01 en vez de 2000/01/01. Más abajo se expone el código fuente para su comprobación).