COBOL

A finales de la década de 1950, los usuarios y fabricantes de computadoras comenzaron a preocuparse por el creciente costo de la programación. Un estudio de 1959 reveló que, en cualquier instalación de procesamiento de datos, la programación costaba en promedio 800 000 dólares estadounidenses y que la traducción de programas para que se ejecutaran en hardware nuevo costaría 600 000 dólares estadounidenses. En un momento en que proliferaban los nuevos lenguajes de programación , el mismo estudio sugería que, si se utilizara un lenguaje común orientado a los negocios, la conversión sería mucho más económica y rápida. ^{[ 18 ]}

El 8 de abril de 1959, Mary K. Hawes , científica informática de Burroughs Corporation , convocó una reunión de representantes del mundo académico, usuarios de computadoras y fabricantes en la Universidad de Pensilvania para organizar una reunión formal sobre lenguajes comerciales comunes. ^{[ 19 ]} Entre los representantes se encontraban Grace Hopper (inventora del lenguaje de procesamiento de datos similar al inglés FLOW-MATIC ), Jean Sammet y Saul Gorn . ^{[ 20 ] [ 21 ]}

En la reunión de abril, el grupo solicitó al Departamento de Defensa (DoD) que patrocinara una iniciativa para crear un lenguaje empresarial común. La delegación impresionó a Charles A. Phillips, director del personal de investigación de sistemas de datos del DoD, ^{[ 22 ]} quien consideró que comprendían a la perfección los problemas del DoD. El DoD operaba 225 computadoras, tenía 175 más encargadas y había gastado más de 200 millones de dólares en la implementación de programas para ejecutarlas. Los programas portátiles ahorrarían tiempo, reducirían costos y facilitarían la modernización. ^{[ 23 ]}

Charles Phillips accedió a patrocinar la reunión y encargó a la delegación la elaboración del orden del día. ^{[ 24 ]}

Los días 28 y 29 de mayo de 1959 se celebró una reunión en el Pentágono para debatir la creación de un lenguaje de programación común para empresas (exactamente un año después de la reunión ALGOL 58 de Zúrich ). Asistieron 41 personas y la presidió Phillips. ^{[ 25 ]} Al Departamento de Defensa le preocupaba si podría ejecutar los mismos programas de procesamiento de datos en diferentes ordenadores. FORTRAN , el único lenguaje de uso generalizado en aquel momento, carecía de las características necesarias para escribir dichos programas. ^{[ 26 ]}

Los representantes describieron con entusiasmo un lenguaje que podría funcionar en una amplia variedad de entornos, desde la banca y los seguros hasta los servicios públicos y el control de inventarios. Coincidieron unánimemente en que más personas deberían poder programar y que el nuevo lenguaje no debería estar limitado por las restricciones de la tecnología actual. La mayoría estuvo de acuerdo en que el lenguaje debería aprovechar al máximo el inglés, ser adaptable, independiente de la máquina y fácil de usar, incluso a costa de un mayor consumo de energía. ^{[ 27 ]}

La reunión dio como resultado la creación de un comité directivo y comités de corto, mediano y largo plazo. Al comité de corto plazo se le concedió hasta septiembre (tres meses) para elaborar las especificaciones de un lenguaje provisional, que posteriormente sería mejorado por los demás comités. ^{[ 28 ] [ 29 ]} Sin embargo, su misión oficial era identificar las fortalezas y debilidades de los lenguajes de programación existentes; no se les encomendó explícitamente la creación de un nuevo lenguaje. ^{[ 26 ]}

El plazo fue recibido con incredulidad por el comité de corto plazo. ^{[ 30 ]} Una miembro, Betty Holberton , describió el plazo de tres meses como un «optimismo desmedido» y dudó de que el lenguaje realmente fuera una solución provisional. ^{[ 31 ]} El comité directivo se reunió el 4 de junio y acordó denominar a toda la actividad Comité de Lenguajes de Sistemas de Datos , o CODASYL , y formar un comité ejecutivo. ^{[ 32 ]}

Los miembros del comité de corto alcance representaban a seis fabricantes de computadoras y tres agencias gubernamentales. Los fabricantes de computadoras eran Burroughs Corporation , IBM , Minneapolis-Honeywell (Honeywell Labs), RCA , Sperry Rand y Sylvania Electric Products . Las agencias gubernamentales eran la Fuerza Aérea de los Estados Unidos , el Centro de Modelado David Taylor de la Armada y la Oficina Nacional de Estándares (ahora Instituto Nacional de Estándares y Tecnología). ^{[ 33 ]} El comité fue presidido por Joseph Wegstein de la Oficina Nacional de Estándares de los Estados Unidos. El trabajo comenzó con la investigación de descripciones de datos, declaraciones, aplicaciones existentes y experiencias de usuario. ^{[ 34 ]}

El comité examinó principalmente los lenguajes de programación FLOW-MATIC , AIMACO y COMTRAN . ^{[ 26 ] [ 35 ]} El lenguaje FLOW-MATIC fue particularmente influyente porque había sido implementado y porque AIMACO era un derivado del mismo con solo cambios menores. ^{[ 36 ] [ 37 ]} La inventora de FLOW-MATIC, Grace Hopper, también se desempeñó como asesora técnica del comité. ^{[ 30 ]} Las principales contribuciones de FLOW-MATIC a COBOL fueron los nombres de variables largos, las palabras en inglés para los comandos y la separación de las descripciones de datos y las instrucciones. ^{[ 38 ]} A Hopper a veces se la llama "la madre de COBOL" o "la abuela de COBOL", ^{[ 39 ] [ 40 ] [ 41 ]} aunque Jean Sammet , un diseñador principal de COBOL, dijo que Hopper "no fue la madre, creadora ni desarrolladora de COBOL". ^{[ 42 ] [ 1 ]}

El lenguaje COMTRAN de IBM, inventado por Bob Bemer , fue considerado un competidor de FLOW-MATIC ^{[ 43 ] [ 44 ]} por un comité de corto alcance compuesto por colegas de Grace Hopper. ^{[ 45 ]} Algunas de sus características no se incorporaron a COBOL para que no pareciera que IBM había dominado el proceso de diseño, ^{[ 28 ]} y Jean Sammet dijo en 1981 que había habido un "fuerte sesgo anti-IBM" por parte de algunos miembros del comité (incluida ella misma). ^{[ 46 ]} En un caso, después de que Roy Goldfinger, autor del manual de COMTRAN y miembro del comité de alcance intermedio, asistiera a una reunión del subcomité para apoyar su lenguaje y fomentar el uso de expresiones algebraicas, Grace Hopper envió un memorando al comité de corto alcance reiterando los esfuerzos de Sperry Rand para crear un lenguaje basado en el inglés. ^{[ 47 ]}

En 1980, Grace Hopper comentó que "COBOL 60 es 95% FLOW-MATIC" y que COMTRAN había tenido una influencia "extremadamente pequeña". Además, afirmó que alegaría que el trabajo estaba influenciado tanto por FLOW-MATIC como por COMTRAN solo para "mantener contentos a los demás [para que] no intentaran echarnos". ^{[ 48 ]}

Las características de COMTRAN incorporadas a COBOL incluyeron fórmulas, ^{[ 49 ]} la PICTUREcláusula , ^{[ 50 ]} una instrucción mejorada IFque eliminó la necesidad de GO TO , y un sistema de gestión de archivos más robusto. ^{[ 43 ]}

La utilidad del trabajo del comité fue objeto de un intenso debate. Mientras que algunos miembros consideraban que el lenguaje presentaba demasiadas concesiones y era el resultado de un diseño realizado por el comité , otros opinaban que era mejor que los tres lenguajes examinados. Algunos lo consideraban demasiado complejo; otros, demasiado simple. ^{[ 51 ]}

Entre las características controvertidas se encontraban aquellas que algunos consideraban inútiles o demasiado avanzadas para los usuarios de procesamiento de datos. Estas características incluían expresiones booleanas , fórmulas e índices de tablas . ^{[ 52 ] [ 53 ]} Otro punto de controversia fue si hacer que las palabras clave fueran sensibles al contexto y el efecto que esto tendría en la legibilidad. ^{[ 52 ]} Aunque se rechazaron las palabras clave sensibles al contexto, el enfoque se utilizó posteriormente en PL/I y parcialmente en COBOL a partir de 2002. ^{[ 54 ]} Se prestó poca atención a la interactividad , la interacción con los sistemas operativos (pocos existían en ese momento) y las funciones (consideradas puramente matemáticas y sin utilidad en el procesamiento de datos). ^{[ 55 ] [ 56 ]}

Las especificaciones se presentaron al comité ejecutivo el 4 de septiembre. No cumplieron con las expectativas: Joseph Wegstein señaló que «contienen deficiencias y requieren algunas adiciones», y Bob Bemer las describió posteriormente como una «mezcolanza». Se le dio al comité hasta diciembre para mejorarlas. ^{[ 30 ]}

En una reunión a mediados de septiembre, el comité discutió el nombre del nuevo lenguaje. Entre las sugerencias se incluyeron "BUSY" (Business System), "INFOSYL" (Information System Language) y "COCOSYL" (Common Computer Systems Language). ^{[ 57 ]} No está claro quién acuñó el nombre "COBOL", ^{[ 58 ] [ 59 ]} aunque Bob Bemer afirmó posteriormente que había sido su sugerencia. ^{[ 60 ] [ 61 ] [ 62 ]}

En octubre, el comité de rango intermedio recibió copias de la especificación del lenguaje FACT creada por Roy Nutt . Sus características impresionaron tanto al comité que aprobaron una resolución para basar COBOL en ella. ^{[ 63 ]}

Esto supuso un revés para el comité de corto plazo, que había avanzado considerablemente en la especificación. A pesar de su superioridad técnica, FACT no se había creado teniendo en cuenta la portabilidad ni mediante el consenso de fabricantes y usuarios. Además, carecía de una implementación demostrable, ^{[ 30 ]} lo que permitió a los partidarios de un COBOL basado en FLOW-MATIC revocar la resolución. El representante de RCA, Howard Bromberg, también bloqueó FACT para que el trabajo de RCA en una implementación de COBOL no se desperdiciara. ^{[ 64 ]}

Pronto se hizo evidente que el comité era demasiado grande para avanzar con rapidez. Un frustrado Howard Bromberg compró una lápida de 15 dólares (en 1959; equivalente a 170 dólares en 2025 ) ^{[ 65 ]} con la inscripción "COBOL" y se la envió a Charles Phillips para demostrar su descontento. ^{[ b ] [ 67 ] [ 68 ]}

Se formó un subcomité para analizar los idiomas existentes y estaba compuesto por seis personas: ^{[ 26 ] [ 69 ]}

• William Selden y Gertrude Tierney de IBM,
• Howard Bromberg y Howard Discount de RCA,
• Vernon Reeves y Jean E. Sammet de Sylvania Electric Products.

El subcomité realizó la mayor parte del trabajo de creación de la especificación, dejando al comité de corto plazo la tarea de revisar y modificar su trabajo antes de producir la especificación final. ^{[ 26 ]}

Las especificaciones fueron aprobadas por el comité ejecutivo el 8 de enero de 1960 y enviadas a la imprenta del gobierno, que las imprimió como COBOL 60. Los objetivos declarados del lenguaje eran permitir la escritura sencilla de programas eficientes y portátiles, facilitar la migración de los usuarios a nuevos sistemas con un mínimo esfuerzo y coste, y ser adecuado para programadores sin experiencia. ^{[ 70 ]}

El Comité Ejecutivo de CODASYL creó posteriormente el Comité de Mantenimiento de COBOL para responder a las preguntas de los usuarios y proveedores y para mejorar y ampliar las especificaciones. ^{[ 71 ]}

Durante 1960, la lista de fabricantes que planeaban desarrollar compiladores de COBOL creció. En septiembre, cinco fabricantes más se unieron a CODASYL ( Bendix , Control Data Corporation , General Electric (GE), National Cash Register y Philco ), y todos los fabricantes representados anunciaron compiladores de COBOL. GE e IBM planearon integrar COBOL en sus propios lenguajes, GECOM y COMTRAN, respectivamente. Por el contrario, International Computers and Tabulators planeó reemplazar su lenguaje, CODEL, con COBOL. ^{[ 72 ]}

Mientras tanto, RCA y Sperry Rand trabajaron en la creación de compiladores COBOL. El primer programa COBOL se ejecutó el 17 de agosto en un RCA 501. ^{[ 73 ]} El 6 y 7 de diciembre, el mismo programa COBOL (aunque con cambios menores) se ejecutó en una computadora RCA y en una computadora Remington-Rand Univac , demostrando que se podía lograr la compatibilidad. ^{[ 74 ]}

La influencia relativa de los lenguajes que se utilizaron todavía se indica en la recomendación impresa en todos los manuales de referencia de COBOL:

COBOL es un lenguaje de programación de la industria y no es propiedad de ninguna empresa o grupo de empresas, ni de ninguna organización o grupo de organizaciones.

Ningún colaborador ni el Comité CODASYL COBOL ofrecen garantía alguna, expresa o implícita, sobre la exactitud y el funcionamiento del sistema y el lenguaje de programación. Asimismo, ningún colaborador ni el comité asumen responsabilidad alguna al respecto. Los autores y titulares de los derechos de autor del material protegido por derechos de autor utilizado en este documento son los siguientes:

FLOW-MATIC (marca comercial de Unisys Corporation ), Programación para UNIVAC (R) I y II, Sistemas de automatización de datos, con derechos de autor de 1958, 1959, por Unisys Corporation; Formulario de traductor comercial de IBM n.° F28-8013, con derechos de autor de 1959 por IBM; FACT, DSI 27A5260-2760, con derechos de autor de 1960 por Minneapolis-Honeywell.

Han autorizado específicamente el uso de este material, en su totalidad o en parte, en las especificaciones de COBOL. Dicha autorización se extiende a la reproducción y el uso de las especificaciones de COBOL en manuales de programación o publicaciones similares. ^{[ 75 ]}

Se encontraron muchos fallos lógicos en COBOL 60 , lo que llevó a Charles Katz de General Electric a advertir que no podía interpretarse de forma inequívoca. Un comité temporal, aunque reacio, llevó a cabo una limpieza completa y, en marzo de 1963, se informó de que la sintaxis de COBOL era tan definible como la de ALGOL , si bien persistían algunas ambigüedades semánticas. ^{[ 72 ]}

Los primeros compiladores de COBOL eran primitivos y lentos. COBOL es un lenguaje difícil para escribir un compilador, debido a su extensa sintaxis y a la gran cantidad de elementos opcionales dentro de las construcciones sintácticas, así como a la necesidad de generar código eficiente para un lenguaje con muchas representaciones de datos posibles, conversiones de tipo implícitas y configuraciones necesarias para las operaciones de E/S. ^{[ 77 ]} Una evaluación de la Marina de los EE. UU. de 1962 encontró velocidades de compilación de 3 a 11 sentencias por minuto. A mediados de 1964, habían aumentado a 11 a 1000 sentencias por minuto. Se observó que aumentar la memoria incrementaría drásticamente la velocidad y que los costos de compilación variaban enormemente: los costos por sentencia estaban entre $0.23 y $18.91. ^{[ 78 ]}

A finales de 1962, IBM anunció que COBOL sería su lenguaje de desarrollo principal y que el desarrollo de COMTRAN cesaría. ^{[ 78 ]}

La especificación COBOL se revisó tres veces en los cinco años posteriores a su publicación. COBOL-60 fue reemplazado en 1961 por COBOL-61. Este último fue reemplazado posteriormente por las especificaciones COBOL-61 Extended en 1963, que introdujeron las funciones de ordenación y generación de informes. ^{[ 79 ]} Las funciones añadidas corrigieron fallos identificados por Honeywell a finales de 1959 en una carta al comité de corto alcance. ^{[ 73 ]} COBOL Edition 1965 aportó más aclaraciones a las especificaciones e introdujo funciones para el manejo de archivos y tablas de almacenamiento masivo . ^{[ 80 ]}

Se iniciaron esfuerzos para estandarizar COBOL y superar las incompatibilidades entre versiones. A finales de 1962, tanto la ISO como el Instituto de Estándares de los Estados Unidos (ahora ANSI ) formaron grupos para crear estándares. ANSI produjo el estándar USA COBOL X3.23 en agosto de 1968, que se convirtió en la piedra angular de las versiones posteriores. ^{[ 81 ]} Esta versión se conoció como el estándar nacional estadounidense (ANS) COBOL y fue adoptada por la ISO en 1972. ^{[ 82 ]}

Para 1970, COBOL se había convertido en el lenguaje de programación más utilizado en el mundo. ^{[ 83 ]}

Independientemente del comité ANSI, el Comité del Lenguaje de Programación CODASYL trabajaba en la mejora del lenguaje. Describieron nuevas versiones en 1968, 1969, 1970 y 1973, incluyendo cambios como nuevas funciones de comunicación entre programas, depuración y fusión de archivos, así como mejoras en el manejo de cadenas y la inclusión de bibliotecas . ^{[ 84 ]}

Aunque CODASYL era independiente del comité ANSI, ANSI utilizó la revista CODASYL Journal of Development para identificar características lo suficientemente populares como para justificar su implementación. ^{[ 85 ]} El Comité de Lenguajes de Programación también se puso en contacto con ECMA y el comité japonés de estándares COBOL. ^{[ 84 ]}

Sin embargo, el Comité de Lenguaje de Programación no era muy conocido. El vicepresidente, William Rinehuls, se quejó de que dos tercios de la comunidad COBOL desconocían su existencia. Además, carecía de fondos para que los documentos públicos, como las actas de las reuniones y las propuestas de cambio, estuvieran disponibles gratuitamente. ^{[ 86 ]}

En 1974, ANSI publicó una versión revisada de (ANS) COBOL, que contenía nuevas características como organizaciones de archivos , la DELETEinstrucción ^{[ 87 ]} y el módulo de segmentación . ^{[ 88 ]} Las características eliminadas incluyeron la NOTEinstrucción, la EXAMINEinstrucción (que fue reemplazada por INSPECT), y el módulo de acceso aleatorio definido por el implementador (que fue reemplazado por los nuevos módulos de E/S secuencial y relativo). Estos conformaron 44 cambios, que hicieron que las instrucciones existentes fueran incompatibles con el nuevo estándar. ^{[ 89 ]} El escritor de informes estaba programado para ser eliminado de COBOL, pero fue reinstaurado antes de que se publicara el estándar. ^{[ 90 ] [ 91 ]} ISO adoptó posteriormente el estándar actualizado en 1978. ^{[ 82 ]}

En junio de 1978, se inició el trabajo de revisión de COBOL-74. El estándar propuesto (conocido comúnmente como COBOL-80) difería significativamente del anterior, lo que generó preocupación por la incompatibilidad y los costos de conversión. En enero de 1981, Joseph T. Brophy, vicepresidente sénior de Travelers Insurance , amenazó con demandar al comité de estandarización porque no era compatible con COBOL-74. El Sr. Brophy describió las conversiones anteriores de su base de código de 40 millones de líneas como "improductivas" y un "desperdicio total de nuestros recursos de programadores". ^{[ 92 ]} Más tarde ese mismo año, la Data Processing Management Association (DPMA) declaró que se oponía firmemente al nuevo estándar, citando costos de conversión "prohibitivos" y mejoras que se "imponían al usuario". ^{[ 93 ] [ 94 ]}

Durante el primer período de revisión pública, el comité recibió 2200 respuestas, de las cuales 1700 fueron cartas modelo negativas. ^{[ 95 ]} Otras respuestas fueron análisis detallados del efecto que COBOL-80 tendría en sus sistemas; se predijo que los costos de conversión serían de al menos 50 centavos por línea de código. Menos de una docena de las respuestas fueron favorables al estándar propuesto. ^{[ 96 ]}

En 1979, el comité técnico ISO TC97-SC5 creó el Grupo Internacional de Expertos en COBOL, por iniciativa de Wim Ebbinkhuijsen . El grupo estaba integrado por expertos en COBOL de numerosos países, incluidos los Estados Unidos. Su objetivo era fomentar el entendimiento y el respeto mutuos entre ANSI y el resto del mundo respecto a la necesidad de nuevas funcionalidades para COBOL. Tres años después, ISO transformó el grupo en un Grupo de Trabajo formal: el Grupo de Trabajo 4 de COBOL (WG 4 COBOL) . Este grupo asumió la responsabilidad principal del desarrollo del estándar COBOL, en el que ANSI presentó la mayoría de las propuestas.

En 1983, la DPMA retiró su oposición al estándar, citando la capacidad de respuesta del comité a las inquietudes públicas. Ese mismo año, un estudio de la Oficina Nacional de Estándares concluyó que el estándar propuesto presentaría pocos problemas. ^{[ 94 ] [ 97 ]} Un año después, DEC publicó VAX/VMS COBOL-80 y señaló que la conversión de programas COBOL-74 planteaba pocos problemas. La nueva EVALUATEinstrucción y la instrucción en línea PERFORMfueron particularmente bien recibidas y mejoraron la productividad, gracias a la simplificación del flujo de control y la depuración . ^{[ 98 ]}

La segunda revisión pública obtuvo otras 1.000 respuestas (principalmente negativas), mientras que la última obtuvo solo 25, momento en el que muchas de las preocupaciones ya se habían abordado. ^{[ 94 ]}

En 1985, el Grupo de Trabajo 4 de la ISO aceptó la versión vigente de la norma propuesta por la ANSI, introdujo varios cambios y la estableció como la nueva norma ISO COBOL 85. Su publicación tuvo lugar a finales de 1985.

Sesenta características fueron modificadas o descontinuadas y 115 ^{[ 99 ]} fueron añadidas, tales como: ^{[ 100 ] [ 101 ]}

• Terminadores de ámbito ( END-IF, END-PERFORM, END-READ, etc.)
• Subprogramas anidados
• CONTINUEuna declaración de no operación
• EVALUATE, una instrucción switch
• INITIALIZE, una instrucción que puede establecer grupos de datos a sus valores predeterminados.
• Cuerpos de bucle en línea PERFORM: anteriormente, los cuerpos de bucle debían especificarse en un procedimiento separado.
• Modificación de referencia, que permite el acceso a subcadenas
• Códigos de estado de E/S.

La nueva norma fue adoptada por todos los organismos nacionales de normalización, incluido ANSI. ^{[ 82 ]}

En 1989 y 1993 se introdujeron dos enmiendas. La primera introdujo el Módulo de función intrínseca y la segunda proporcionó correcciones. ^{[ 82 ]}

En 1997, Gartner Group estimó que existían un total de 200 mil millones de líneas de COBOL, que ejecutaban el 80% de todos los programas empresariales. ^{[ c ] [ 102 ]}

A principios de la década de 1990, se comenzó a trabajar en la incorporación de la programación orientada a objetos en la siguiente revisión completa de COBOL. Las características orientadas a objetos se tomaron de C++ y Smalltalk . ^{[ 4 ] [ 5 ]}

La estimación inicial era que esta revisión estuviera terminada para 1997, y un borrador del Comité ISO (CD) estuvo disponible para ese año. Algunos proveedores (entre ellos Micro Focus , Fujitsu e IBM ) introdujeron sintaxis orientada a objetos basada en borradores de la revisión completa. La norma ISO final aprobada se publicó a finales de 2002. ^{[ 103 ]}

Fujitsu/GTSoftware, ^{[ 104 ]} Micro Focus introdujo compiladores COBOL orientados a objetos dirigidos al .NET Framework .

Hubo muchas otras características nuevas, muchas de las cuales habían estado en el CODASYL COBOL Journal of Development desde 1978 y habían perdido la oportunidad de ser incluidas en COBOL-85. ^{[ 105 ]} Estas otras características incluyeron: ^{[ 106 ] [ 107 ]}

• Código de formato libre
• Funciones definidas por el usuario
• Recursión
• Procesamiento basado en la configuración regional
• Compatibilidad con conjuntos de caracteres extendidos como Unicode.
• Tipos de datos de punto flotante y binarios (hasta entonces, los elementos binarios se truncaban según la especificación en base 10 de su declaración).
• Resultados aritméticos portátiles
• Tipos de datos de bits y booleanos
• Punteros y sintaxis para obtener y liberar almacenamiento
• Para interfaces SCREEN SECTIONde usuario basadas en texto
• Las VALIDATEinstalaciones
• Mayor interoperabilidad con otros lenguajes de programación y entornos de desarrollo como .NET y Java .

Se publicaron tres correcciones para la norma: dos en 2006 y una en 2009. ^{[ 108 ]}

Entre 2003 y 2009, se produjeron tres Informes Técnicos (TR) que describían la finalización de objetos , el procesamiento XML y las clases de colección para COBOL. ^{[ 108 ]}

COBOL 2002 sufrió de un soporte deficiente: ningún compilador era totalmente compatible con el estándar. Micro Focus descubrió que esto se debía a la falta de demanda por parte de los usuarios de las nuevas características y a la eliminación del conjunto de pruebas NIST , que se había utilizado para comprobar la conformidad de los compiladores. También se constató que el proceso de estandarización era lento y carecía de recursos suficientes. ^{[ 109 ]}

COBOL 2014 incluye los siguientes cambios: ^{[ 110 ]}

• Las funciones principales se han convertido en opcionales, como la VALIDATEinstalación, el generador de informes y la función de manejo de pantallas.
• Tablas de capacidad dinámicas (una característica eliminada del borrador de COBOL 2002) ^{[ 111 ]}
• Los resultados aritméticos portátiles han sido reemplazados por tipos de datos IEEE 754.
• Sobrecarga de métodos

El estándar COBOL 2023 añadió algunas características nuevas:

• Sintaxis de mensajería asíncrona utilizando las sentencias SENDy ^{[ 112 ]}RECEIVE
• Una instalación de procesamiento de transaccionesCOMMIT con y ROLLBACK^{[ 112 ]}
• XORoperador lógico ^{[ 112 ]}
• La CONTINUEinstrucción puede extenderse para pausar el programa durante una duración específica ^{[ 113 ].}
• Una DELETE FILEdeclaración ^{[ 113 ]}
• LINE SEQUENTIALorganización de archivos ^{[ 114 ]}
• Bucle infinito definido con PERFORM UNTIL EXIT^{[ 113 ]}
• SUBSTITUTEfunción intrínseca que permite la sustitución de subcadenas de diferente longitud ^{[ 113 ]}
• CONVERTfunción para la conversión de bases ^{[ 113 ]}
• Operadores de desplazamiento booleano ^{[ 115 ]}

gcobol, de GCC 15.1, se basa en este estándar. ^{[ 116 ]}

Hacia finales del siglo XX, el problema del año 2000 (Y2K) fue el foco de un esfuerzo significativo de programación en COBOL, a veces por los mismos programadores que habían diseñado los sistemas décadas antes. El nivel particular de esfuerzo requerido para corregir el código COBOL se ha atribuido a la gran cantidad de COBOL orientado a los negocios, ya que las aplicaciones comerciales utilizan fechas con frecuencia, y a los campos de datos de longitud fija. ^{[ 121 ]} Algunos estudios atribuyen hasta "el 24% de los costos de reparación de software del Y2K a COBOL". ^{[ 122 ]} Después del esfuerzo de limpieza realizado en estos programas para el Y2K, una encuesta de 2003 encontró que muchos seguían en uso. ^{[ 123 ]} Los autores dijeron que los datos de la encuesta sugieren "una disminución gradual en la importancia de COBOL en el desarrollo de aplicaciones durante los [siguientes] 10 años a menos que... se pueda adoptar la integración con otros lenguajes y tecnologías". ^{[ 124 ]}

En 2006 y 2012, encuestas de Computerworld (a 352 lectores) revelaron que más del 60% de las organizaciones utilizaban COBOL (más que C++ y Visual Basic .NET ) y que, para la mitad de ellas, COBOL se utilizaba para la mayor parte de su software interno. ^{[ 12 ] [ 125 ]} El 36% de los gerentes afirmó que planeaba migrar de COBOL, y el 25% indicó que lo haría si no fuera por el costo de reescribir el código heredado . Como alternativa, algunas empresas han migrado sus programas COBOL de mainframes a hardware más económico y rápido. ^{[ 12 ]}

Para 2019, el número de programadores de COBOL se reducía rápidamente debido a las jubilaciones, lo que generaba una inminente escasez de profesionales cualificados en organizaciones empresariales y gubernamentales que aún utilizaban sistemas mainframe para el procesamiento de transacciones de alto volumen. Los esfuerzos por reescribir los sistemas COBOL en lenguajes más modernos han resultado costosos y problemáticos, al igual que la externalización del mantenimiento del código; por lo tanto, se aboga por propuestas para capacitar a más personas en COBOL. ^{[ 126 ]}

Varios bancos han emprendido esfuerzos de modernización de COBOL que duran varios años, lo que en ocasiones ha provocado interrupciones generalizadas del servicio que han dado lugar a multas. ^{[ 127 ]}

Durante la pandemia de COVID-19 y el consiguiente aumento del desempleo, varios estados de EE. UU. informaron de una escasez de programadores COBOL cualificados para dar soporte a los sistemas heredados utilizados para la gestión de las prestaciones por desempleo. Muchos de estos sistemas se encontraban en proceso de conversión a lenguajes de programación más modernos antes de la pandemia, pero el proceso se suspendió. ^{[ 128 ]} De manera similar, el Servicio de Impuestos Internos de EE. UU. se apresuró a parchear su Archivo Maestro Individual basado en COBOL para poder desembolsar las decenas de millones de pagos exigidos por la Ley de Ayuda, Alivio y Seguridad Económica ante el Coronavirus . ^{[ 129 ]}

En 2024, el IRS anunció una transición de COBOL a Java gracias a la Iniciativa Digital First . ^{[ 118 ]}

COBOL tiene una sintaxis similar al inglés, que se utiliza para describir casi todo en los programas COBOL. Por ejemplo, una condición se puede expresar como o de forma más concisa como o . Las condiciones más complejas se pueden abreviar eliminando condiciones y variables repetidas. Por ejemplo, se puede acortar a . Para admitir esta sintaxis, COBOL tiene más de 300 palabras clave . ^{[ 130 ] [ d ]} Algunas de las palabras clave son simples alternativas o plurales de la misma palabra, lo que proporciona declaraciones y cláusulas más apropiadas gramaticalmente; por ejemplo, las palabras clave y se pueden usar indistintamente, como y , y y . xISGREATERTHANy xGREATERy  x>y a>bANDa>cORa=d a>bANDcOR =dINOFTIMETIMESVALUEVALUES

Cada programa COBOL se compone de cuatro elementos léxicos básicos : palabras, literales, cadenas de caracteres de imágenes y separadores. Las palabras incluyen palabras reservadas e identificadores definidos por el usuario. Tienen hasta 31 caracteres de longitud y pueden incluir letras, dígitos, guiones y guiones bajos. Los literales incluyen números (p. ej. 12) y cadenas (p. ej. 'Hello!'). ^{[ 132 ]} Los separadores incluyen el espacio y las comas y los puntos y comas seguidos de un espacio. ^{[ 133 ]}

Un programa COBOL se divide en cuatro divisiones: la división de identificación, la división de entorno, la división de datos y la división de procedimientos. La división de identificación especifica el nombre y el tipo del elemento fuente y es donde se especifican las clases e interfaces. La división de entorno especifica las características del programa que dependen del sistema en el que se ejecuta, como archivos y conjuntos de caracteres . La división de datos se utiliza para declarar variables y parámetros . La división de procedimientos contiene las instrucciones del programa . Cada división se subdivide en secciones, que a su vez se componen de párrafos.

${\displaystyle {\begin{array}{l}{\underline {\texttt {AÑADIR}}}\,{\begin{Bmatrix}{\text{identificador-1}}\\{\text{literal-1}}\end{Bmatrix}}\dots \;{\underline {\texttt {A}}}\,\left\{{\text{identificador-2}}\,\left[\,{\underline {\texttt {REDONDEADO}}}\,\right]\right\}\dots \\[1em]\quad \left[\left|{\begin{array}{l}{\texttt {EN}}\,{\underline {\texttt {TAMAÑO}}}\,{\underline {\texttt {ERROR}}}\,{\text{declaración imperativa-1}}\\{\underline {\texttt {NO}}}\,{\texttt {ON}}\,{\underline {\texttt {SIZE}}}\,{\underline {\texttt {ERROR}}}\,{\text{imperative-statement-2}}\end{array}}\right|\right]\\[1em]\quad \left[\,{\underline {\texttt {END-ADD}}}\,\right]\end{array}}}$

SUMAR 1 A x SUMAR 1 , a , b A x REDONDEADO , y , z REDONDEADOAGREGAR a , b A c EN CASO DE ERROR DE TAMAÑO MOSTRAR "Error" FIN-AGREGARAGREGAR a A b NO TAMAÑO ERROR MOSTRAR "Sin error" EN TAMAÑO ERROR MOSTRAR "Error"

El apogeo de la popularidad de COBOL coincidió con la era de las perforadoras de tarjetas y las tarjetas perforadas . El programa en sí se escribía en tarjetas perforadas, luego se leía y compilaba, y los datos que se introducían en el programa a veces también estaban en tarjetas. ^{[ 135 ]}

COBOL se puede escribir en dos formatos: fijo (el predeterminado) o libre. En formato fijo, el código debe alinearse para ajustarse a ciertas áreas (un vestigio del uso de tarjetas perforadas). Hasta COBOL 2002, estas eran:

En COBOL 2002, las áreas A y B se fusionaron para formar el área de texto del programa, que ahora termina en una columna definida por el implementador. ^{[ 136 ]}

COBOL 2002 también introdujo el código de formato libre. Este código puede ubicarse en cualquier columna del archivo, al igual que en los lenguajes de programación más recientes. Los comentarios se especifican mediante *>, que puede colocarse en cualquier lugar y también utilizarse en código fuente de formato fijo. No existen líneas de continuación, y la >>PAGEdirectiva reemplaza al /indicador. ^{[ 136 ]}

La sección de identificación identifica la siguiente entidad de código y contiene la definición de una clase o interfaz.

*> Son equivalentes. INVOKE my-class "foo" RETURNING var MOVE my-class :: "foo" TO var *> Invocación de método en línea

La sección de entorno contiene la sección de configuración y la sección de entrada/salida. La sección de configuración se utiliza para especificar características variables como símbolos de moneda, configuraciones regionales y conjuntos de caracteres. La sección de entrada/salida contiene información relacionada con los archivos.

La división de datos se divide en seis secciones que declaran diferentes elementos: la sección de archivos, para registros de archivos; la sección de almacenamiento de trabajo, para variables estáticas ; la sección de almacenamiento local, para variables automáticas ; la sección de enlace, para parámetros y el valor de retorno; la sección de informes y la sección de pantalla, para interfaces de usuario basadas en texto .

01 algún registro . *> Elemento de registro de grupo agregado 05 num PIC 9(10) . *> Elemento elemental 05 la fecha . *> Elemento de registro de (sub)grupo agregado 10 el año PIC 9(4) . *> Elemento elemental 10 el mes PIC 99 . *> Elemento elemental 10 el día PIC 99 . *> Elemento elemental

01 fecha de venta . 05 el año PIC 9(4) . 05 el mes PIC 99 . 05 el día PIC 99 .

01 registro-cliente . 05 clave-cliente PIC X(10) . 05 nombre-cliente . 10 nombre-cliente PIC X(30) . 10 apellido-cliente PIC X(30) . 05 fecha -nacimiento-cliente PIC 9(8) . 05 saldo-cliente PIC 9(7)V99 . 66 detalles-personales-cliente RENOMBRAN nombre-cliente HASTA fecha- nacimiento-cliente . 66 todos-detalles-cliente RENOMBRAN nombre-cliente HASTA saldo-cliente .

77 nombre-propiedad PIC X(80) . 77 región-ventas PIC 9(5) .

01 tipo de salario PIC X . 88 salario-es-por-hora VALOR "H" . 88 salario-es-anual VALOR "S" , "Y" .

Informe de salida FD INFORME de ventas .

Informe de ventas RD LÍMITES DE PÁGINA 60 LÍNEAS PRIMER DETALLE 3 CONTROLES nombre-del-vendedor .01 TIPO ENCABEZADO DE PÁGINA . 03 COL 1 VALOR "Informe de ventas" . 03 COL 74 VALOR "Página" . 03 COL 79 PIC Z9 ORIGEN CONTADOR DE PÁGINAS .01 ventas-en-día TIPO DETALLE , LÍNEA + 1. 03 COL 3 VALOR "Ventas en" . 03 COL 12 PIC 99/99/9999 ORIGEN fecha-ventas . 03 COL 21 VALOR "fueron" . 03 COL 26 PIC $$$$9.99 ORIGEN importe-ventas .01 invalid-sales TIPO DETALLE , LÍNEA + 1. 03 COL 3 VALOR "REGISTRO NO VÁLIDO:" . 03 COL 19 PIC X(34) ORIGEN registro -de-ventas .01 TIPO CONTROL ENCABEZADO nombre-vendedor , LÍNEA + 2. 03 COL 1 VALOR " Vendedor:" . 03 COL 9 PIC X(30) ORIGEN nombre-vendedor .

Informe de ventas Página 1Vendedor: Howard Bromberg  Ventas el 10/12/2008: $1000.00  Ventas el 12/12/2008: $0.00  Ventas el 13/12/2008: $31.47  REGISTRO NO VÁLIDO: Howard Bromberg XXXXYYVendedor: Howard Discount ... Informe de ventas Página 12 Las ventas del 08/05/2014 fueron de $543.98  REGISTRO NO VÁLIDO: William Selden 12052014FOOFOO  Las ventas del 30/05/2014 fueron de $0.00

ABRIR ENTRADA ventas , SALIDA informe-salida INICIALIZAR informe-ventas EJECUTAR HASTA 1 <> 1 LEER ventas AL FINAL SALIR EJECUTAR FIN-LECTURA VALIDAR registro-ventas SI registro-válido GENERAR ventas-en-día SINO GENERAR ventas-inválidas FIN-SI FIN-EJECUTAR TERMINAR informe-ventas CERRAR ventas , informe-salida .

Un programa "¡Hola, mundo!" en COBOL:

DIVISIÓN DE IDENTIFICACIÓN . ID DE PROGRAMA . hola-mundo . DIVISIÓN DE PROCEDIMIENTO . MOSTRAR "¡Hola, mundo!" .

Cuando el ahora famoso ejemplo de programa "Hello, World!" en The C Programming Language se publicó por primera vez en 1978, un ejemplo de programa COBOL similar para mainframe se habría enviado a través de JCL , muy probablemente usando un lector de tarjetas perforadas y tarjetas perforadas de 80 columnas. El listado a continuación, con un vacíoDATA DIVISION , se probó usando Linux y el emulador System/370 Hercules ejecutando MVS 3.8J. El JCL, escrito en julio de 2015, se deriva de los tutoriales y ejemplos de Hercules alojados por Jay Moseley. ^{[ 169 ]} En consonancia con la programación COBOL de esa época,HOLA MUNDOse muestra en mayúsculas.

// COBUCLG JOB ( 001 ), 'COBOL BASE TEST' ,// CLASS = A , MSGCLASS = A , MSGLEVEL = ( 1 , 1 )// COBRO DE EJECUCIÓN DE BASETEST// COB . SYSIN DD *00000 * VALIDACIÓN DE LA INSTALACIÓN BASE DE COBOL01000 DIVISIÓN DE IDENTIFICACIÓN .01100 ID DE PROGRAMA . 'HOLA' .02000 DIVISIÓN DE MEDIO AMBIENTE .02100 SECCIÓN DE CONFIGURACIÓN .02110 ORDENADOR DE ORIGEN . GNULINUX .02120 OBJETO-COMPUTADOR . HÉRCULES .02200 NOMBRES ESPECIALES .02210 LA CONSOLA ES CONSL .03000 DIVISIÓN DE DATOS .04000 DIVISIÓN DE PROCEDIMIENTOS .04100 00 - PRINCIPAL .04110 MOSTRAR 'HOLA, MUNDO' AL ENCENDER LA CONSOLA .04900 PARAR EJECUTAR .// LKED . SYSLIB DD DSNAME = SYS1 . COBLIB , DISP = SHR// DD DSNAME = SYS1 . LINKLIB , DISP = SHR// IR . SYSPRINT DD SYSOUT = A//

Tras enviar el JCL, la consola MVS mostró lo siguiente:

 19.52.48 TRABAJO 3 $HASP100 COBUCLG EN LECTOR1 PRUEBA BASE DE COBOL 19.52.48 TRABAJO 3 IEF677I MENSAJE(S) DE ADVERTENCIA EMITIDO(S) PARA EL TRABAJO COBUCLG 19.52.48 TRABAJO 3 $HASP373 COBUCLG INICIADO - INICIAL 1 - CLASE A - SISTEMA BSP1 19.52.48 TRABAJO 3 IEC130I SYSPUNCH FALTA LA INSTRUCCIÓN DD 19.52.48 TRABAJO 3 IEC130I SYSLIB FALTA LA DECLARACIÓN DD 19.52.48 TRABAJO 3 IEC130I SYSPUNCH FALTA LA INSTRUCCIÓN DD 19.52.48 TRABAJO 3 IEFACTRT - Nombre del paso Paso del proceso Código de retorno del programa 19.52.48 TRABAJO 3 COBUCLG BASETEST COB IKFCBL00 RC= 0000 19.52.48 TRABAJO 3 COBUCLG BASETEST LKED IEWL RC= 0000 19.52.48 TRABAJO 3 +HOLA, MUNDO 19.52.48 TRABAJO 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000 19.52.48 TRABAJO 3 $HASP395 COBUCLG FINALIZADO

La línea 10 del listado de la consola anterior está resaltada para mayor efecto; el resaltado no forma parte de la salida real de la consola .

El listado del compilador asociado generó más de cuatro páginas de detalles técnicos e información sobre la ejecución del trabajo, para la única línea de salida de las 14 líneas de COBOL.

En la década de 1970, la adopción del paradigma de programación estructurada se generalizó cada vez más. Edsger Dijkstra , un eminente científico informático, escribió una carta al editor de Communications of the ACM , publicada en 1975, titulada "¿Cómo decimos verdades que podrían doler?", en la que criticaba COBOL y otros lenguajes contemporáneos, señalando que "el uso de COBOL paraliza la mente". ^{[ 170 ]}

En una disidencia publicada a los comentarios de Dijkstra, el científico informático Howard E. Tompkins afirmó que el COBOL no estructurado tendía a ser "escrito por programadores que nunca se habían beneficiado de una buena enseñanza del COBOL estructurado", argumentando que el problema era principalmente de capacitación. ^{[ 171 ]}

Una causa del código espagueti fue la GO TOinstrucción. Sin embargo, los intentos de eliminar GO TOlas instrucciones del código COBOL dieron como resultado programas complejos y una calidad de código reducida. ^{[ 172 ]}GO TO Las instrucciones fueron reemplazadas en gran medida por la PERFORMinstrucción y los procedimientos, lo que promovió la programación modular ^{[ 172 ]} y dio fácil acceso a potentes funciones de bucle. Sin embargo, PERFORMsolo se podía usar con procedimientos, por lo que los cuerpos de los bucles no se ubicaban donde se usaban, lo que hacía que los programas fueran más difíciles de entender. ^{[ 173 ]} Desde la adopción del estándar de 1985, la necesidad de GO TOse ha eliminado por completo gracias a las ricas características del PERFORMverbo; sin embargo, GO TOse mantiene para la compatibilidad con versiones anteriores, como sucede en muchos otros lenguajes.

Los programas COBOL eran conocidos por ser monolíticos y carecer de modularización. ^{[ 174 ]} El código COBOL solo podía modularizarse mediante procedimientos, que resultaron inadecuados para sistemas grandes. De lo contrario, era necesario CALLcompilar programas por separado para lograr la modularidad. Era imposible restringir el acceso a los datos hasta el estándar COBOL-85, lo que significaba que un procedimiento podía acceder y modificar cualquier elemento de datos. Además, no había forma de pasar parámetros a un procedimiento, una omisión que Jean Sammet consideró el mayor error del comité. ^{[ 175 ]} Este problema se solucionó en el estándar COBOL-85 con la introducción del subprograma anidado, que permitió la modularidad y el aislamiento local de elementos de datos.

Otra complicación surgió de la posibilidad de ejecutar PERFORM THRUuna secuencia específica de procedimientos. Esto significaba que el control podía saltar a cualquier procedimiento y regresar de él, creando un flujo de control complejo y permitiendo que un programador rompiera la regla de entrada única y salida única . ^{[ 176 ]}

Esta situación mejoró a medida que COBOL incorporó más funcionalidades. COBOL-74 añadió subprogramas, lo que permitió a los programadores controlar los datos a los que podía acceder cada parte del programa. Posteriormente, COBOL-85 añadió subprogramas anidados, lo que permitió a los programadores ocultar subprogramas. ^{[ 177 ]} En 2002 se logró un mayor control sobre los datos y el código con la inclusión de la programación orientada a objetos, las funciones definidas por el usuario y los tipos de datos definidos por el usuario. ^{[ 178 ]}

Sin embargo, gran parte del software COBOL heredado importante utiliza código no estructurado, que se ha vuelto prácticamente imposible de mantener. Modificar incluso una sección simple de código puede ser demasiado arriesgado y costoso, ya que puede utilizarse desde lugares desconocidos y de maneras desconocidas. ^{[ 179 ]}

COBOL fue concebido como un lenguaje "común" y altamente portable. Sin embargo, para 2001, se habían creado alrededor de 300 dialectos. ^{[ 180 ]} Una fuente de dialectos fue el propio estándar: el estándar de 1974 estaba compuesto por un núcleo obligatorio y once módulos funcionales, cada uno con dos o tres niveles de soporte. Esto permitió 104.976 variantes posibles. ^{[ 181 ]}

COBOL-85 no era totalmente compatible con versiones anteriores y su desarrollo fue controvertido. Joseph T. Brophy, CIO de Travelers Insurance , lideró una iniciativa para informar a los usuarios de COBOL sobre los elevados costos de reprogramación que implicaba la implementación del nuevo estándar. ^{[ 182 ]} Como resultado, el Comité ANSI COBOL recibió más de 2200 cartas del público, en su mayoría negativas, lo que obligó al comité a realizar cambios. Por otro lado, se creía que la conversión a COBOL-85 aumentaría la productividad en los años venideros, justificando así los costos de la conversión. ^{[ 183 ]}

La sintaxis de COBOL ha sido criticada con frecuencia por su verbosidad. Sus defensores afirman que esto se pretendía para que el código fuera autodocumentado , facilitando así el mantenimiento del programa. ^{[ 185 ]} COBOL también se diseñó para que fuera fácil de aprender y usar para los programadores, ^{[ 186 ]} sin dejar de ser legible para personal no técnico, como los gerentes. ^{[ 187 ] [ 188 ] [ 189 ] [ 190 ]}

El deseo de legibilidad llevó al uso de una sintaxis y elementos estructurales similares a los del inglés, como sustantivos, verbos, cláusulas, oraciones, secciones y divisiones. Sin embargo, en 1984, los mantenedores de programas COBOL tenían dificultades para lidiar con código "incomprensible" ^{[ 189 ]} y los principales cambios en COBOL-85 estaban destinados a facilitar el mantenimiento. ^{[ 95 ]}

Jean Sammet, miembro del comité de corto alcance, señaló que "se hizo poco esfuerzo por satisfacer al programador profesional; de hecho, las personas cuyo principal interés es la programación tienden a estar muy descontentas con COBOL", lo cual atribuyó a la sintaxis verbosa de COBOL. ^{[ 191 ]}

Más tarde, COBOL sufrió una escasez de material que lo cubriera; no fue hasta 1963 que aparecieron los primeros libros introductorios (Richard D. Irwin publicó un libro de texto universitario sobre COBOL en 1966). ^{[ 193 ]} Donald Nelson, presidente del comité CODASYL COBOL, dijo en 1984 que "los académicos... odian COBOL" y que a los graduados en ciencias de la computación "les habían inculcado el odio a COBOL". ^{[ 194 ]}

A mediados de la década de 1980, también existía una condescendencia significativa hacia COBOL en la comunidad empresarial por parte de usuarios de otros lenguajes, por ejemplo FORTRAN o ensamblador , lo que implicaba que COBOL solo podía utilizarse para problemas que no supusieran un desafío. ^{[ 195 ]}

En 2003, COBOL figuraba en el 80 % de los planes de estudio de sistemas de información en Estados Unidos, la misma proporción que C++ y Java . ^{[ 196 ]} Diez años después, una encuesta de Micro Focus reveló que el 20 % de los académicos universitarios consideraba que COBOL estaba obsoleto o muerto, y que el 55 % creía que sus estudiantes pensaban lo mismo. La misma encuesta también reveló que solo el 25 % de los académicos incluía la programación en COBOL en sus planes de estudio, a pesar de que el 60 % opinaba que deberían enseñarla. ^{[ 197 ]}

Se han planteado dudas sobre la competencia del comité de normas. Howard Bromberg, miembro del comité por un corto período, afirmó que había "poco control" sobre el proceso de desarrollo y que este estaba "plagado de discontinuidad de personal y... falta de talento". ^{[ 83 ]} Jean Sammet y Jerome Garfunkel también señalaron que los cambios introducidos en una revisión de la norma se revertían en la siguiente, debido tanto a los cambios en la composición del comité de normas como a la evidencia objetiva. ^{[ 198 ]}

Los estándares COBOL han sufrido repetidos retrasos: COBOL-85 llegó cinco años más tarde de lo previsto, ^{[ 199 ]} COBOL 2002 se retrasó cinco años, ^{[ 4 ]} y COBOL 2014 se retrasó seis años. ^{[ 103 ] [ 200 ]} Para combatir los retrasos, el comité de estándares permitió la creación de adendas opcionales que añadirían características más rápidamente que esperando la siguiente revisión del estándar. Sin embargo, algunos miembros del comité plantearon inquietudes sobre las incompatibilidades entre las implementaciones y las frecuentes modificaciones del estándar. ^{[ 201 ]}

Las estructuras de datos de COBOL influyeron en lenguajes de programación posteriores. Su estructura de registros y archivos influyó en PL/I y Pascal , y la REDEFINEScláusula fue precursora de los registros variantes de Pascal. Las definiciones explícitas de la estructura de archivos precedieron al desarrollo de sistemas de gestión de bases de datos , y los datos agregados representaron un avance significativo con respecto a los arreglos de Fortran. ^{[ 202 ]}

PICTURELas declaraciones de datos se incorporaron a PL/I, con modificaciones menores.

La funcionalidad de COBOL COPY, aunque considerada "primitiva", ^{[ 203 ]} influyó en el desarrollo de las directivas include . ^{[ 202 ]}

El énfasis en la portabilidad y la estandarización significó que los programas escritos en COBOL fueran portables y facilitó la difusión del lenguaje a una amplia variedad de plataformas de hardware y sistemas operativos. ^{[ 204 ]} Además, la estructura de división bien definida restringe la definición de referencias externas a la División de Entorno, lo que simplifica los cambios de plataforma en particular. ^{[ 205 ]}