COBOL

COBOL ( / ˈkoʊbɒl , -bɔːl / ; acrónimo de " common business-oriented language") es un lenguaje de programación informático compilado similar al inglés diseñado para uso empresarial. Es un lenguaje imperativo , procedimental y, desde 2002, orientado a objetos . COBOL se utiliza principalmente en sistemas empresariales, financieros y administrativos para empresas y gobiernos. COBOL todavía se utiliza ampliamente en aplicaciones implementadas en computadoras mainframe , como trabajos de procesamiento de lotes y transacciones a gran escala . Muchas grandes instituciones financieras estaban desarrollando nuevos sistemas en el lenguaje hasta 2006, ^[10] pero la mayor parte de la programación en COBOL hoy es puramente para mantener las aplicaciones existentes. Los programas se están moviendo a nuevas plataformas, reescribiendo en lenguajes modernos o reemplazando con otro software. ^[11]

COBOL fue diseñado en 1959 por CODASYL y se basó parcialmente en el lenguaje de programación FLOW-MATIC , diseñado por Grace Hopper . Fue creado como parte de un esfuerzo del Departamento de Defensa de los EE. UU. para crear un lenguaje de programación portátil para el procesamiento de datos. Originalmente fue visto como una solución provisional, pero el Departamento de Defensa presionó rápidamente a los fabricantes de computadoras para que lo proporcionaran, lo que resultó en su adopción generalizada. ^[12] Fue estandarizado en 1968 y ha sido revisado cinco veces. Las expansiones incluyen soporte para programación estructurada y orientada a objetos . El estándar actual es ISO / IEC  1989:2023. ^[13]

Las instrucciones COBOL tienen una sintaxis en prosa , como , que fue diseñada para ser autodocumentada y muy legible. Sin embargo, es verbosa y utiliza más de 300 palabras reservadas . Esto contrasta con la sintaxis sucinta e inspirada en las matemáticas de otros lenguajes (en este caso, ). MOVE x TO yy = x;

El código COBOL se divide en cuatro partes (identificación, entorno, datos y procedimiento) que contienen una jerarquía rígida de secciones, párrafos y oraciones. Al carecer de una gran biblioteca estándar , el estándar especifica 43 sentencias, 87 funciones y solo una clase.

Los científicos informáticos académicos generalmente no estaban interesados ​​en las aplicaciones comerciales cuando se creó COBOL y no participaron en su diseño; fue (efectivamente) diseñado desde cero como un lenguaje de computadora para negocios, con énfasis en entradas y salidas, cuyos únicos tipos de datos eran números y cadenas de texto. ^[14]

Se ha criticado a COBOL por su verbosidad, su proceso de diseño y su escaso soporte para la programación estructurada . Estas debilidades dan como resultado programas monolíticos que son difíciles de comprender en su totalidad, a pesar de su legibilidad local.

Durante años, COBOL se ha asumido como un lenguaje de programación para operaciones comerciales en mainframes, ^[15] aunque en los últimos años, muchas operaciones COBOL se han trasladado a la computación en la nube . ^[16]

A finales de los años 50, los usuarios y fabricantes de ordenadores empezaron a preocuparse por el aumento del coste de la programación. Una encuesta de 1959 había descubierto que, en cualquier instalación de procesamiento de datos, la programación costaba 800.000 dólares de media y que traducir programas para que funcionaran en un nuevo hardware costaría 600.000 dólares. En una época en la que proliferaban nuevos lenguajes de programación , la misma encuesta sugería que, si se utilizase un lenguaje común orientado a los negocios, la conversión sería mucho más barata y rápida. ^[17]

El 8 de abril de 1959, Mary K. Hawes , una científica informática de Burroughs Corporation , convocó una reunión de representantes de la academia, usuarios de computadoras y fabricantes en la Universidad de Pensilvania para organizar una reunión formal sobre lenguajes comerciales comunes. ^[18] 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 . ^{[19] [20]}

En la reunión de abril, el grupo pidió al Departamento de Defensa (DoD) que patrocinara un esfuerzo para crear un lenguaje comercial común. La delegación impresionó a Charles A. Phillips, director del personal de investigación de sistemas de datos del DoD, ^[21] quien pensó que "entendían completamente" los problemas del DoD. El DoD operaba 225 computadoras, tenía 175 más en orden y había gastado más de 200 millones de dólares en implementar programas para ejecutarlos. Los programas portátiles ahorrarían tiempo, reducirían costos y facilitarían la modernización. ^[22]

Charles Phillips aceptó patrocinar la reunión y encargó a la delegación que redactara la agenda. ^[23]

El 28 y 29 de mayo de 1959 (exactamente un año después de la reunión ALGOL 58 de Zúrich ), se celebró una reunión en el Pentágono para discutir la creación de un lenguaje de programación común para empresas. Asistieron 41 personas y estuvo presidida por Phillips. ^[24] El Departamento de Defensa estaba preocupado por si podría ejecutar los mismos programas de procesamiento de datos en diferentes computadoras. FORTRAN , el único lenguaje convencional en ese momento, carecía de las características necesarias para escribir tales programas. ^[25]

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 gente debería poder programar y que el nuevo lenguaje no debería verse restringido por las limitaciones de la tecnología contemporánea. Una mayoría estuvo de acuerdo en que el lenguaje debería hacer un uso máximo del inglés, ser capaz de cambiar, ser independiente de las máquinas y fácil de usar, incluso a costa de la energía. ^[26]

La reunión dio como resultado la creación de un comité directivo y de comités de corto, mediano y largo plazo. El comité de corto plazo recibió hasta septiembre (tres meses) para producir especificaciones para un lenguaje provisional, que luego sería mejorado por los otros comités. ^{[27] [28]} Sin embargo, su misión oficial era identificar las fortalezas y debilidades de los lenguajes de programación existentes; no les ordenó explícitamente que crearan un nuevo lenguaje. ^[25]

El comité de corto plazo recibió con incredulidad la fecha límite. ^[29] Una de sus integrantes, Betty Holberton , calificó el plazo de tres meses como un "gran optimismo" y dudó de que el texto fuera realmente una solución provisional. ^[30]

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. ^[31]

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 EE. UU. , el David Taylor Model Basin de la Armada y la Oficina Nacional de Normas (ahora el Instituto Nacional de Normas y Tecnología). ^[32] El comité estaba presidido por Joseph Wegstein de la Oficina Nacional de Normas de los EE. UU. El trabajo comenzó investigando descripciones de datos, declaraciones, aplicaciones existentes y experiencias de usuario. ^[33]

El comité examinó principalmente los lenguajes de programación FLOW-MATIC , AIMACO y COMTRAN . ^{[25] [34]} El lenguaje FLOW-MATIC fue particularmente influyente porque había sido implementado y porque AIMACO era un derivado de él con solo cambios menores. ^{[35] [36]} La inventora de FLOW-MATIC, Grace Hopper, también sirvió como asesora técnica del comité. ^[29] Las principales contribuciones de FLOW-MATIC a COBOL fueron los nombres largos de variables, las palabras en inglés para comandos y la separación de descripciones de datos e instrucciones. ^[37]

A Hopper a veces se le llama "la madre de COBOL" o "la abuela de COBOL", ^{[38] [39] [40]} aunque Jean Sammet , un diseñador principal de COBOL, dijo que Hopper "no fue la madre, creadora o desarrolladora de COBOL". ^{[41] [1]}

El lenguaje COMTRAN de IBM, inventado por Bob Bemer , fue considerado como un competidor de FLOW-MATIC ^{[42] [43]} por un comité de corto alcance formado por colegas de Grace Hopper. ^[44] Algunas de sus características no se incorporaron a COBOL para que no pareciera que IBM había dominado el proceso de diseño, ^[27] y Jean Sammet dijo en 1981 que había habido un "fuerte sesgo anti-IBM" de algunos miembros del comité (incluida ella misma). ^[45] En un caso, después de que Roy Goldfinger, autor del manual COMTRAN y miembro del comité de rango intermedio, asistiera a una reunión del subcomité para apoyar su lenguaje y alentar 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. ^[46]

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, dijo que afirmaba que su trabajo estaba influenciado tanto por FLOW-MATIC como por COMTRAN sólo para "mantener felices a otras personas [para que] no intentaran eliminarnos". ^[47]

Las características de COMTRAN incorporadas a COBOL incluían fórmulas, ^[48] la cláusula PICTURE, ^[49] una IFdeclaración mejorada que eliminaba la necesidad de GO TO y un sistema de gestión de archivos más sólido. ^[42]

La utilidad del trabajo del comité fue un tema de gran debate. Mientras que algunos miembros pensaban que el lenguaje implicaba demasiados compromisos y era el resultado de un diseño del comité , otros pensaban que era mejor que los tres lenguajes examinados. Algunos pensaban que el lenguaje era demasiado complejo; otros, demasiado simple. ^[50]

Entre las características controvertidas se encontraban aquellas que algunos consideraban inútiles o demasiado avanzadas para los usuarios que procesaban datos. Entre dichas características se encontraban las expresiones booleanas , las fórmulas y los subíndices de tabla (índices). ^{[51] [52]} 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. ^[51] Aunque se rechazaron las palabras clave sensibles al contexto, el enfoque se utilizó más tarde en PL/I y parcialmente en COBOL a partir de 2002. ^[53] 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 como puramente matemáticas y sin utilidad en el procesamiento de datos). ^{[54] [55]}

El 4 de septiembre se presentaron las especificaciones al comité ejecutivo, pero no cumplieron con las expectativas: Joseph Wegstein señaló que "contiene puntos débiles y requiere algunas modificaciones", y Bob Bemer las describió más tarde como una "mezcolanza". El comité recibió plazo hasta diciembre para mejorarlas. ^[29]

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

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. ^[62]

Esto fue un golpe para el comité de corto alcance, que había avanzado mucho en la especificación. A pesar de ser técnicamente superior, FACT no había sido creado con la portabilidad en mente o por consenso entre fabricante y usuario. También carecía de una implementación demostrable, ^[29] lo que permitió a los partidarios de un COBOL basado en FLOW-MATIC revocar la resolución. El representante de la RCA, Howard Bromberg, también bloqueó FACT, para que el trabajo de la RCA en una implementación de COBOL no se desperdiciara. ^[63]

Pronto se hizo evidente que el comité era demasiado grande para hacer más progresos rápidamente. Un frustrado Howard Bromberg compró una lápida de 15 dólares con la palabra "COBOL" grabada en ella y se la envió a Charles Phillips para demostrar su descontento. ^{[b] [65] [66]}

Se formó un subcomité para analizar los idiomas existentes y estuvo integrado por seis personas: ^{[25] [67]}

• 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. ^[25]

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 que se escribieran fácilmente programas eficientes y portables, permitir que los usuarios se migraran a nuevos sistemas con un mínimo esfuerzo y costo, y ser adecuado para programadores sin experiencia. ^[68]

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

Durante 1960, la lista de fabricantes que planeaban construir compiladores COBOL creció. Para septiembre, cinco fabricantes más se habían unido a CODASYL ( Bendix , Control Data Corporation , General Electric (GE), National Cash Register y Philco ), y todos los fabricantes representados habían anunciado compiladores COBOL. GE e IBM planeaban integrar COBOL en sus propios lenguajes, GECOM y COMTRAN, respectivamente. Por el contrario, International Computers y Tabulators planeaban reemplazar su lenguaje, CODEL, con COBOL. ^[70]

Mientras tanto, RCA y Sperry Rand trabajaban en la creación de compiladores COBOL. El primer programa COBOL se ejecutó el 17 de agosto en un RCA 501. ^[71] El 6 y el 7 de diciembre, el mismo programa COBOL (aunque con cambios menores) se ejecutó en un ordenador RCA y en un ordenador Remington-Rand Univac , lo que demostró que se podía lograr la compatibilidad. ^[72]

La influencia relativa de los lenguajes utilizados todavía se indica en el aviso recomendado impreso en todos los manuales de referencia COBOL:

COBOL es un lenguaje industrial 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é COBOL de CODASYL ofrecen garantía alguna, expresa o implícita, sobre la precisión y el funcionamiento del sistema y el lenguaje de programación. Además, ningún colaborador ni el Comité asumen responsabilidad alguna en relación con ello. 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 registrada de Unisys Corporation ), Programación para UNIVAC (R) I y II, Sistemas de automatización de datos, con derechos de autor de 1958, 1959, de Unisys Corporation; Formulario de traductor comercial de IBM n.º F28-8013, con derechos de autor de 1959 de IBM; FACT, DSI 27A5260-2760, con derechos de autor de 1960 de Minneapolis-Honeywell.

Han autorizado específicamente el uso de este material, total o parcialmente, en las especificaciones COBOL. Dicha autorización se extiende a la reproducción y uso de las especificaciones COBOL en manuales de programación o publicaciones similares. ^[73]

Se encontraron muchos fallos lógicos en COBOL 60 , lo que llevó a Charles Katz de General Electric a advertir que no se podía interpretar de forma unívoca. Un comité de corto plazo reacio realizó una limpieza total y, en marzo de 1963, se informó que la sintaxis de COBOL era tan definible como la de ALGOL , aunque persistían ambigüedades semánticas. ^[70]

COBOL es un lenguaje para el que resulta difícil escribir un compilador, debido a la gran sintaxis y a los numerosos 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 tipos implícitas y configuraciones necesarias para operaciones de E/S. ^[75] Los primeros compiladores COBOL eran primitivos y lentos. Una evaluación de la Marina de los EE. UU. de 1962 encontró velocidades de compilación de 3 a 11 declaraciones por minuto. A mediados de 1964, habían aumentado a 11 a 1000 declaraciones por minuto. Se observó que aumentar la memoria aumentaría drásticamente la velocidad y que los costos de compilación variaban enormemente: los costos por declaración estaban entre $0,23 y $18,91. ^[76]

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

La especificación COBOL fue revisada tres veces en los cinco años posteriores a su publicación. COBOL-60 fue reemplazada en 1961 por COBOL-61. Esta fue luego reemplazada por las especificaciones COBOL-61 Extendidas en 1963, que introdujeron las facilidades de clasificación y escritura de informes. ^[77] Las facilidades agregadas corrigieron fallas identificadas por Honeywell a fines de 1959 en una carta al comité de corto alcance. ^[71] COBOL Edición 1965 trajo más aclaraciones a las especificaciones e introdujo facilidades para manejar archivos y tablas de almacenamiento masivo . ^[78]

Se iniciaron esfuerzos para estandarizar COBOL para superar las incompatibilidades entre versiones. A fines de 1962, tanto la ISO como el Instituto de Normas de los Estados Unidos de América (ahora ANSI ) formaron grupos para crear estándares. ANSI produjo el estándar estadounidense COBOL X3.23 en agosto de 1968, que se convirtió en la piedra angular para las versiones posteriores. ^[79] Esta versión se conoció como American National Standard (ANS) COBOL y fue adoptada por ISO en 1972. ^[80]

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

Independientemente del comité ANSI, el Comité del Lenguaje de Programación CODASYL estaba trabajando en la mejora del lenguaje. Describieron nuevas versiones en 1968, 1969, 1970 y 1973, incluyendo cambios como nuevas facilidades de comunicación entre programas, depuración y fusión de archivos, así como también mejoras en el manejo de cadenas y características de inclusión de bibliotecas . ^[82]

Aunque CODASYL era independiente del comité ANSI, el CODASYL Journal of Development fue utilizado por ANSI para identificar características que eran lo suficientemente populares como para justificar su implementación. ^[83] El Comité de Lenguaje de Programación también estuvo en contacto con ECMA y el comité del estándar COBOL japonés. ^[82]

Sin embargo, el Comité de Lenguaje de Programación no era muy conocido. El vicepresidente, William Rinehuls, se quejaba de que dos tercios de la comunidad COBOL no sabían de la existencia del comité. Además, carecía de fondos para hacer públicos documentos, como actas de reuniones y propuestas de cambio, de forma gratuita. ^[84]

En 1974, ANSI publicó una versión revisada de (ANS) COBOL, que contenía nuevas características como las organizaciones de archivos, la DELETEdeclaración ^[85] y el módulo de segmentación . ^[86] Las características eliminadas incluían la NOTEdeclaración, la EXAMINEdeclaració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 constituyeron 44 cambios, que hicieron que las declaraciones existentes fueran incompatibles con el nuevo estándar. ^[87] El escritor de informes estaba programado para ser eliminado de COBOL, pero fue restablecido antes de que se publicara el estándar. ^{[88] [89]} ISO adoptó más tarde el estándar actualizado en 1978. ^[80]

En junio de 1978, se comenzó a trabajar en la revisión de COBOL-74. El estándar propuesto (comúnmente llamado COBOL-80) difería significativamente del anterior, lo que generó inquietudes sobre incompatibilidad y costos de conversión. En enero de 1981, Joseph T. Brophy, vicepresidente senior de Travelers Insurance, amenazó con demandar al comité de estándares porque no era compatible con COBOL-74. Brophy describió las conversiones anteriores de su base de código de 40 millones de líneas como "improductivas" y un "completo desperdicio de nuestros recursos de programación". ^[90] Más tarde ese año, la Asociación de Gestión de Procesamiento de Datos (DPMA) dijo que se "oponía firmemente" al nuevo estándar, citando costos de conversión "prohibitivos" y mejoras que se "imponían al usuario". ^{[91] [92]}

Durante el primer período de revisión pública, el comité recibió 2.200 respuestas, de las cuales 1.700 eran cartas negativas. ^[93] Otras respuestas eran 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 estaban a favor del estándar propuesto. ^[94]

En 1979, por iniciativa de Wim Ebbinkhuijsen , ISO TC97-SC5 creó el Grupo Internacional de Expertos en COBOL . El grupo estaba formado por expertos en COBOL de muchos países, incluido Estados Unidos. Su objetivo era lograr un entendimiento y respeto mutuos entre ANSI y el resto del mundo con respecto a la necesidad de nuevas características de COBOL. Después de tres años, ISO cambió el estatus del grupo a un Grupo de Trabajo formal: WG 4 COBOL . El grupo asumió la propiedad principal y el desarrollo del estándar COBOL, donde ANSI realizó 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 preocupaciones del público. En el mismo año, un estudio de la Oficina Nacional de Estándares concluyó que el estándar propuesto presentaría pocos problemas. ^{[92] [95]} Un año después, DEC lanzó un VAX/VMS COBOL-80 y observó que la conversión de programas COBOL-74 planteaba pocos problemas. La nueva EVALUATEdeclaración y el código en línea fueron particularmente bien recibidos y mejoraron la productividad, gracias al flujo de control y la depuraciónPERFORM simplificados . ^[96]

La segunda revisión pública generó otras 1.000 respuestas (en su mayoría negativas), mientras que la última generó solo 25, momento en el que ya se habían abordado muchas preocupaciones. ^[92]

En 1985, el Grupo de Trabajo 4 de ISO aceptó la versión entonces propuesta del estándar ANSI, realizó varios cambios y lo estableció como el nuevo estándar ISO COBOL 85. Se publicó a fines de 1985.

Se cambiaron o dejaron de utilizarse sesenta características y se agregaron 115 ^{[97] , como por ejemplo: [98] [99]}

• Terminadores de ámbito ( END-IF, END-PERFORM, END-READ, etc.)
• Subprogramas anidados
• CONTINUE, una declaración de no operación
• EVALUATE, una declaración de cambio
• INITIALIZE, una declaració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. ^[80]

En 1989 y 1993 se introdujeron dos enmiendas. La primera introdujo funciones intrínsecas y la otra introdujo correcciones. ^[80]

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] [100]}

A principios de los años 1990, se empezó a trabajar en la incorporación de la orientación a objetos en la siguiente revisión completa de COBOL. Las características orientadas a objetos se tomaron de C++ y Smalltalk . ^{[3] [4]}

La estimación inicial era que esta revisión se completara en 1997, y en 1997 ya estaba disponible un borrador del comité ISO (CD). Algunos proveedores (incluidos Micro Focus , Fujitsu e IBM ) introdujeron una sintaxis orientada a objetos basada en borradores de la revisión completa. La norma ISO final aprobada se aprobó y publicó a fines de 2002. ^[101]

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

Había 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. ^[103] Estas otras características incluían: ^{[104] [105]}

• 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 binarios y de punto flotante (hasta entonces, los elementos binarios se truncaban según la especificación de base 10 de su declaración )
• Resultados aritméticos portátiles
• Tipos de datos de tipo bit y booleano
• Punteros y sintaxis para obtener y liberar almacenamiento
• Para interfaces de usuario SCREEN SECTIONbasadas en texto
• La VALIDATEinstalación
• Interoperabilidad mejorada con otros lenguajes de programación y entornos de framework como .NET y Java .

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

Entre 2003 y 2009, se produjeron tres informes técnicos que describen la finalización de objetos , el procesamiento XML y las clases de recopilación para COBOL. ^[106]

COBOL 2002 sufrió de un soporte deficiente: ningún compilador soportaba completamente el estándar. Micro Focus descubrió que esto se debía a una falta de demanda de las nuevas características por parte de los usuarios y a la abolición del conjunto de pruebas del NIST , que se había utilizado para probar la conformidad de los compiladores. También se descubrió que el proceso de estandarización era lento y carecía de recursos. ^[107]

COBOL 2014 incluye los siguientes cambios: ^[108]

• Los resultados aritméticos portátiles han sido reemplazados por tipos de datos IEEE 754
• Las funciones principales se han vuelto opcionales, como la VALIDATEfunción de creación de informes y la función de manejo de pantalla.
• Sobrecarga de métodos
• Tablas de capacidad dinámica (una característica eliminada del borrador de COBOL 2002) ^[109]

El estándar COBOL 2023 agregó algunas características nuevas:

• Sintaxis de mensajería asincrónica utilizando las instrucciones SENDand ^[110]RECEIVE
• Una instalación de procesamiento de transaccionesCOMMIT con y ROLLBACK^[110]
• XORoperador lógico ^[110]
• La CONTINUEdeclaración se puede ampliar para pausar el programa durante una duración específica ^[111]
• Una DELETE FILEdeclaración ^[111]
• LINE SEQUENTIALorganización de archivos ^[112]
• Bucle infinito definido con PERFORM UNTIL EXIT^[111]
• SUBSTITUTEFunción intrínseca que permite la sustitución de subcadenas de diferente longitud ^[111]
• CONVERTFunción para la conversión de base ^[111]
• Operadores de desplazamiento booleanos ^[113]

Aún no se conoce ninguna implementación completa de esta norma. ^{[ cita requerida ]}

Los programas COBOL se utilizan en todo el mundo en gobiernos y empresas y se ejecutan en diversos sistemas operativos como z/OS , z/VSE , VME , Unix , NonStop OS, OpenVMS y Windows . En 1997, el Grupo Gartner informó que el 80% de las empresas del mundo se ejecutaban en COBOL con más de 200 mil millones de líneas de código ^[c] y 5 mil millones de líneas más escritas anualmente. ^[114]

A finales del siglo XX, el problema del año 2000 (Y2K) fue el foco de un importante esfuerzo de programación COBOL, a veces por parte de los mismos programadores que habían diseñado los sistemas décadas antes. El particular nivel 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 en gran medida, y a los campos de datos de longitud fija. ^[115] Algunos estudios atribuyen hasta "el 24% de los costos de reparación del software Y2K a COBOL". ^[116] Después del esfuerzo de limpieza realizado en estos programas para Y2K, una encuesta de 2003 encontró que muchos seguían en uso. ^[117] 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". ^[118]

En 2006 y 2012, las encuestas de Computerworld (a 352 lectores) descubrieron que más del 60% de las organizaciones usaban COBOL (más que C++ y Visual Basic .NET ) y que para la mitad de ellas, COBOL se usaba para la mayoría de su software interno. ^{[10] [119]} El 36% de los gerentes dijeron que planeaban migrar desde COBOL, y el 25% dijo que lo harían si no fuera por el gasto de reescribir el código heredado. Alternativamente, algunas empresas han migrado sus programas COBOL desde mainframes a hardware más barato y rápido. ^[10]

El testimonio ante la Cámara de Representantes en 2016 indicó que muchas agencias federales todavía utilizan COBOL. ^[120] Reuters informó en 2017 que el 43% de los sistemas bancarios todavía utilizaban COBOL, con más de 220 mil millones de líneas de código COBOL en uso. ^[121]

En 2019, el número de programadores COBOL se estaba reduciendo rápidamente debido a las jubilaciones, lo que generó una brecha de habilidades inminente en las organizaciones comerciales y gubernamentales que aún utilizan sistemas mainframe para el procesamiento de transacciones de alto volumen. Los esfuerzos por reescribir los sistemas en lenguajes más nuevos han demostrado ser costosos y problemáticos, al igual que la subcontratación del mantenimiento del código, por lo que se aboga por propuestas para capacitar a más personas en COBOL. ^[122]

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

COBOL tiene una sintaxis similar al inglés, que se utiliza para describir casi todo en un programa. 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 las condiciones y variables repetidas. Por ejemplo,     se puede acortar a . Para respaldar esta sintaxis, COBOL tiene más de 300 palabras clave . ^{[125] [d]} Algunas de las palabras clave son simples alternativas o grafías pluralizadas de la misma palabra, lo que proporciona declaraciones y cláusulas gramaticalmente más apropiadas; por ejemplo, las palabras clave y se pueden usar indistintamente, como pueden y , y y . x IS GREATER THAN yx GREATER yx > ya > b AND a > c OR a = da > b AND c OR = dINOFTIMETIMESVALUEVALUES

Cada programa COBOL se compone de cuatro elementos léxicos básicos : palabras, literales, cadenas de caracteres de imagen (véase la cláusula § PICTURE) y separadores. Las palabras incluyen palabras reservadas e identificadores definidos por el usuario. Tienen una longitud de hasta 31 caracteres y pueden incluir letras, dígitos, guiones y guiones bajos. Los literales incluyen números (por ejemplo, 12) y cadenas (por ejemplo, 'Hello!'). ^[127] Los separadores incluyen el carácter de espacio y las comas y puntos y comas seguidos de un espacio. ^[128]

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 procedimiento. 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 que lo ejecuta, como archivos y conjuntos de caracteres . La división de datos se utiliza para declarar variables y parámetros . La división de procedimiento contiene las declaraciones del programa . Cada división se subdivide en secciones, que se componen de párrafos.

La sintaxis de COBOL se describe habitualmente con un metalenguaje único que utiliza llaves, corchetes, barras y subrayado. El metalenguaje se desarrolló para las especificaciones originales de COBOL. Aunque la forma Backus–Naur ya existía en ese momento, el comité no había oído hablar de ella. ^[129]

A modo de ejemplo, considere la siguiente descripción de una ADDdeclaración:

 ${\displaystyle {\begin{array}{l}{\underline {\text{ADD}}}\,{\begin{Bmatrix}{\text{identifier-1}}\\{\text{literal-1}}\end{Bmatrix}}\dots \;{\underline {\text{TO}}}\,\left\{{\text{identifier-2}}\,\left[\,{\underline {\text{ROUNDED}}}\,\right]\right\}\dots \\[1em]\quad \left[\left|{\begin{array}{l}{\text{ON}}\,{\underline {\text{SIZE}}}\,{\underline {\text{ERROR}}}\,{\text{imperative-statement-1}}\\{\underline {\text{NOT}}}\,{\text{ON}}\,{\underline {\text{SIZE}}}\,{\underline {\text{ERROR}}}\,{\text{imperative-statement-2}}\end{array}}\right|\right]\\[1em]\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}$

Esta descripción permite las siguientes variantes:

SUMA 1 A x SUMA 1 , a , b A x REDONDEADO , y , z REDONDEADO  
         

AGREGAR a , b A c EN LA PANTALLA DE ERROR DE TAMAÑO "Error" FIN-AGREGAR    
      
        


AGREGAR a A b NO TAMAÑO ERROR PANTALLA "Sin error" EN TAMAÑO ERROR PANTALLA "Error"   
      
        
      
        

El auge de la popularidad de COBOL coincidió con la era de las máquinas perforadoras de tarjetas . 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. ^[130]

COBOL se puede escribir en dos formatos: fijo (el predeterminado) o libre. En el formato fijo, el código debe estar alineado para que quepa en 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. ^[131]

COBOL 2002 también introdujo el código de formato libre, que se puede colocar en cualquier columna del archivo, como en los lenguajes de programación más nuevos. Los comentarios se especifican utilizando *>, que se puede colocar en cualquier lugar y también se puede utilizar en código fuente de formato fijo. No hay líneas de continuación y la >>PAGEdirectiva reemplaza al /indicador. ^[131]

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

Las clases e interfaces han estado en COBOL desde 2002. Las clases tienen objetos de fábrica, que contienen métodos y variables de clase, y objetos de instancia, que contienen métodos y variables de instancia. ^[132] La herencia y las interfaces proporcionan polimorfismo . Se proporciona soporte para programación genérica a través de clases parametrizadas, que se pueden instanciar para usar cualquier clase o interfaz. Los objetos se almacenan como referencias que pueden restringirse a un cierto tipo. Hay dos formas de llamar a un método: la INVOKEdeclaración, que actúa de manera similar a CALL, o mediante la invocación de método en línea, que es análoga al uso de funciones. ^[133]

*> Estos son equivalentes. 
INVOCAR mi-clase "foo" DEVOLVER var MOVER mi-clase :: "foo" A var *> Invocación de método en línea    
    

COBOL no ofrece una forma de ocultar métodos. Sin embargo, los datos de clase se pueden ocultar declarándolos sin una PROPERTYcláusula, lo que deja al código externo sin forma de acceder a ellos. ^[134] La sobrecarga de métodos se agregó en COBOL 2014. ^[135]

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

COBOL admite tres formatos de archivo u organizaciones : secuencial, indexado y relativo. En los archivos secuenciales, los registros son contiguos y se deben recorrer secuencialmente , de manera similar a una lista enlazada . Los archivos indexados tienen uno o más índices que permiten acceder aleatoriamente a los registros y que se pueden ordenar en ellos. Cada registro debe tener una clave única , pero otras claves de registro alternativas no necesitan ser únicas. Las implementaciones de archivos indexados varían entre proveedores, aunque las implementaciones comunes, como C-ISAM y VSAM , se basan en ISAM de IBM . Otras implementaciones son Record Management Services en OpenVMS y Enscribe en HPE NonStop (Tandem). Los archivos relativos, como los archivos indexados, tienen una clave de registro única, pero no tienen claves alternativas. La clave de un registro relativo es su posición ordinal; por ejemplo, el décimo registro tiene una clave de 10. Esto significa que la creación de un registro con una clave de 5 puede requerir la creación de registros anteriores (vacíos). Los archivos relativos también permiten el acceso tanto secuencial como aleatorio. ^[136]

Una extensión no estándar común es la organización secuencial de líneas , que se utiliza para procesar archivos de texto. Los registros de un archivo terminan con una nueva línea y pueden tener una longitud variable. ^[137]

La división de datos se divide en seis secciones que declaran diferentes elementos: la sección de archivo, para registros de archivo; 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 informe y la sección de pantalla, para interfaces de usuario basadas en texto .

Los elementos de datos en COBOL se declaran jerárquicamente mediante el uso de números de nivel que indican si un elemento de datos es parte de otro. Un elemento con un número de nivel superior está subordinado a un elemento con uno inferior. Los elementos de datos de nivel superior, con un número de nivel de 1, se denominan registros . Los elementos que tienen datos agregados subordinados se denominan elementos de grupo ; los que no los tienen, se denominan elementos elementales . Los números de nivel utilizados para describir elementos de datos estándar están entre 1 y 49. ^{[138] [139]}

       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                   
                         
                             
                     
                      
                        

En el ejemplo anterior, el elemento elemental numy el elemento de grupo the-dateestán subordinados al registro some-record, mientras que los elementos elementales the-year, the-monthy the-dayson parte del elemento de grupo the-date.

Los elementos subordinados se pueden desambiguar con la palabra clave IN(o OF). Por ejemplo, considere el código de ejemplo anterior junto con el siguiente ejemplo:

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

Los nombres the-year, the-month, y the-dayson ambiguos por sí mismos, ya que más de un elemento de datos se define con esos nombres. Para especificar un elemento de datos en particular, por ejemplo uno de los elementos contenidos dentro del sale-dategrupo, el programador usaría the-year IN sale-date(o su equivalente the-year OF sale-date). Esta sintaxis es similar a la "notación de puntos" admitida por la mayoría de los lenguajes contemporáneos.

Se utiliza un nivel de número 66 para declarar una reagrupación de elementos previamente definidos, independientemente de cómo estén estructurados dichos elementos. Este nivel de datos, al que también se hace referencia mediante la RENAMEScláusula asociada , se utiliza raramente ^[140] y, alrededor de 1988, se encontraba habitualmente en programas antiguos. Su capacidad para ignorar los datos de estructura lógica y jerárquica hizo que no se recomendara su uso y muchas instalaciones lo prohibieran. ^[141]

       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-de-nacimiento -cliente PIC 9(8) . 05   saldo-cliente PIC 9(7)V99 . 66   detalles-personales-cliente RENOMBRA nombre-cliente HASTA fecha-de -nacimiento-cliente . 66   todos-detalles-cliente RENOMBRA nombre-cliente HASTA saldo-cliente .                       
           
                
                 
                       
                   
           
             
                  

Un número de nivel 77 indica que el elemento es independiente y, en tales situaciones, es equivalente al número de nivel 01. Por ejemplo, el siguiente código declara dos elementos de datos de nivel 77, property-namey sales-region, que son elementos de datos no grupales que son independientes de (no subordinados a) cualquier otro elemento de datos:

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

Un número de nivel 88 declara un nombre de condición (un denominado nivel 88) que es verdadero cuando su elemento de datos padre contiene uno de los valores especificados en su VALUEcláusula. ^[142] Por ejemplo, el código siguiente define dos elementos de nombre de condición de nivel 88 que son verdaderos o falsos según el valor de datos de carácter actual del wage-typeelemento de datos. Cuando el elemento de datos contiene un valor de 'H', el nombre de condición wage-is-hourlyes verdadero, mientras que cuando contiene un valor de 'S'o 'Y', el nombre de condición wage-is-yearlyes verdadero. Si el elemento de datos contiene algún otro valor, ambos nombres de condición son falsos.

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

El estándar COBOL proporciona los siguientes tipos de datos: ^[143]

La seguridad de tipos es variable en COBOL. Los datos numéricos se convierten entre diferentes representaciones y tamaños de forma silenciosa y los datos alfanuméricos se pueden colocar en cualquier elemento de datos que se pueda almacenar como una cadena, incluidos los datos numéricos y de grupo. ^[144] Por el contrario, las referencias a objetos y los punteros solo se pueden asignar desde elementos del mismo tipo y sus valores se pueden restringir a un tipo determinado. ^[145]

Una cláusula PICTURE(o PIC) es una cadena de caracteres, cada uno de los cuales representa una parte del elemento de datos y lo que puede contener. Algunos caracteres de imagen especifican el tipo de elemento y cuántos caracteres o dígitos ocupa en la memoria. Por ejemplo, a 9indica un dígito decimal y an Sindica que el elemento tiene signo . Otros caracteres de imagen (llamados caracteres de inserción y edición ) especifican cómo se debe formatear un elemento. Por ejemplo, una serie de +caracteres define las posiciones de los caracteres, así como también cómo se debe posicionar un carácter de signo inicial dentro de los datos de caracteres finales; el carácter no numérico más a la derecha contendrá el signo del elemento, mientras que otras posiciones de caracteres correspondientes a a +a la izquierda de esta posición contendrán un espacio. Los caracteres repetidos se pueden especificar de forma más concisa especificando un número entre paréntesis después de un carácter de imagen; por ejemplo, 9(7)es equivalente a 9999999. Las especificaciones de imagen que contienen solo caracteres de dígito ( 9) y signo ( ) definen elementos de datos Spuramente numéricosA , mientras que las especificaciones de imagen que contienen caracteres alfabéticos ( ) o alfanuméricos ( X) definen elementos de datos alfanuméricos . La presencia de otros caracteres de formato define elementos de datos numéricos o alfanuméricos editados . ^[146]

La USAGEcláusula declara el formato en el que se almacenan los datos. Según el tipo de datos, puede complementar o utilizarse en lugar de una PICTUREcláusula. Si bien se puede utilizar para declarar punteros y referencias a objetos, está orientada principalmente a especificar tipos numéricos. Estos formatos numéricos son: ^[147]

• Binario, donde un tamaño mínimo se especifica mediante la PICTUREcláusula o mediante una USAGEcláusula comoBINARY-LONG
• USAGE COMPUTATIONAL, donde los datos pueden almacenarse en cualquier formato que proporcione la implementación; a menudo equivalente a  USAGE BINARY
• USAGE DISPLAY, el formato predeterminado, donde los datos se almacenan como una cadena
• Punto flotante, ya sea en un formato dependiente de la implementación o según IEEE 754
• USAGE NATIONAL, donde los datos se almacenan como una cadena utilizando un conjunto de caracteres extendido
• USAGE PACKED-DECIMAL, donde los datos se almacenan en el formato decimal más pequeño posible (normalmente decimal codificado en binario empaquetado )

El generador de informes es una herramienta declarativa para crear informes. El programador solo necesita especificar el diseño del informe y los datos necesarios para generarlo, lo que le libera de tener que escribir código para gestionar aspectos como saltos de página, formato de datos y encabezados y pies de página. ^[148]

Los informes están asociados a archivos de informes, que son archivos en los que solo se puede escribir mediante declaraciones del escritor de informes.

       Informe de FD INFORME informe de ventas .   

Cada informe se define en la sección de informes de la división de datos. Un informe se divide en grupos de informes que definen los encabezados, los pies de página y los detalles del informe. Los informes funcionan en torno a los cortes de control jerárquicos . Los cortes de control se producen cuando una variable clave cambia su valor; por ejemplo, al crear un informe que detalla los pedidos de los clientes, se puede producir un corte de control cuando el programa llega a los pedidos de un cliente diferente. A continuación se muestra un ejemplo de descripción de informe para un informe que proporciona las ventas de un vendedor y que advierte sobre cualquier registro no válido:

       Informe de ventas de 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 FUENTE CONTADOR DE PÁGINAS .  
            
            
              

       01   ventas-en-el-día TIPO DETALLE , LÍNEA + 1 . 03   COL 3                     VALOR "Ventas en" . 03   COL 12                    PIC 99/99/9999 FUENTE fecha-de-ventas . 03   COL 21                    VALOR "fueron" . 03   COL 26                    PIC $$$$9.99 FUENTE importe-de-ventas .    
            
              
            
              

       01   invalid-sales TIPO DETALLE , LÍNEA + 1 . 03   COL 3                     VALOR "REGISTRO INVÁLIDO:" . 03   COL 19                    PIC X(34) FUENTE sales-record .    
            
              

       01   TIPO CONTROL ENCABEZADO nombre-del-vendedor , LÍNEA + 2 . 03   COL 1                     VALOR "Vendedor:" . 03   COL 9                     PIC X(30) FUENTE nombre-del-vendedor .     
            
              

La descripción del informe anterior describe el siguiente diseño:

Informe de ventas Página 1

Vendedor: Howard Bromberg
  Las ventas el 12/10/2008 fueron de $1000.00
  Las ventas el 12/12/2008 fueron $0.00
  Las ventas el 13/12/2008 fueron $31,47
  REGISTRO INVÁLIDO: Howard Bromberg XXXXYY

Vendedor: Howard Discount
...
Informe de ventas Página 12

  Las ventas el 08/05/2014 fueron $543,98
  REGISTRO INVÁLIDO: William Selden 12O52014FOOFOO
  Las ventas el 30/05/2014 fueron $0.00

Cuatro instrucciones controlan el generador de informes: INITIATE, que prepara el generador de informes para la impresión; GENERATE, que imprime un grupo de informes; SUPPRESS, que suprime la impresión de un grupo de informes; y TERMINATE, que finaliza el procesamiento del informe. Para el ejemplo de informe de ventas anterior, la división de procedimientos podría verse así:

           ABRIR ENTRADA ventas , SALIDA informe-de-salida INICIAR informe-de-ventas EJECUTAR HASTA 1 <> 1 LEER ventas AL FINAL SALIR EJECUTAR FINALIZAR -LECTURA VALIDAR registro-de-ventas SI registro-valido GENERAR ventas-en-el-dia DE LO CONTRARIO GENERAR ventas-inválidas FINALIZAR-SI FINALIZAR TERMINAR informe-de-ventas CERRAR ventas , informe-de-salida .    
            
 
              
                
                    
                        
               
 
                
                
                    
               
                    
               
           
 
            
             
           

El uso de la función Report Writer tiende a variar considerablemente: algunas organizaciones la utilizan ampliamente y otras no la utilizan en absoluto. ^[149] Además, las implementaciones de Report Writer varían en calidad, y las de menor nivel a veces utilizan cantidades excesivas de memoria en tiempo de ejecución. ^[149]

Las secciones y párrafos de la división de procedimientos (denominados colectivamente procedimientos) se pueden utilizar como etiquetas y como subrutinas simples . A diferencia de otras divisiones, los párrafos no necesitan estar en las secciones. ^[150]

La ejecución recorre los procedimientos de un programa hasta que finaliza. ^[151] Para utilizar procedimientos como subrutinas, PERFORMse utiliza el verbo.

Una PERFORMdeclaración se parece un poco a una llamada a un procedimiento en los lenguajes más nuevos en el sentido de que la ejecución retorna al código que sigue a la PERFORMdeclaración al final del código llamado; sin embargo, no proporciona un mecanismo para pasar parámetros o para devolver un valor de resultado. Si se invoca una subrutina utilizando una declaración simple como , entonces el control retorna al final del procedimiento llamado. Sin embargo, es inusual en el sentido de que puede usarse para llamar a un rango que abarca una secuencia de varios procedimientos adyacentes. Esto se hace con la construcción: PERFORM subroutinePERFORMPERFORM sub-1 THRU sub-n

PROCEDIMIENTO fulano . REALIZAR ALFA REALIZAR ALFA HASTA GAMMA DETENER EJECUTAR . ALFA . MOSTRAR 'A' . BETA . MOSTRAR 'B' . GAMMA . MOSTRAR 'C' . 
     
       
     

    

    

    

La salida de este programa será: "AAB C".

PERFORMTambién difiere de las llamadas a procedimientos convencionales en que, al menos tradicionalmente, no existe la noción de una pila de llamadas. Como consecuencia, son posibles las invocaciones anidadas (una secuencia de código que se está PERFORMejecutando puede ejecutar una PERFORMsentencia por sí misma), pero requieren un cuidado adicional si partes del mismo código son ejecutadas por ambas invocaciones. El problema surge cuando el código en la invocación interna llega al punto de salida de la invocación externa. Más formalmente, si el control pasa por el punto de salida de una PERFORMinvocación que se llamó antes pero que aún no se completó, el estándar COBOL 2002 estipula que el comportamiento es undefined .

La razón es que COBOL, en lugar de una "dirección de retorno", opera con lo que podría llamarse una dirección de continuación. Cuando el flujo de control llega al final de cualquier procedimiento, se busca la dirección de continuación y el control se transfiere a esa dirección. Antes de que se ejecute el programa, la dirección de continuación de cada procedimiento se inicializa con la dirección de inicio del procedimiento que viene a continuación en el texto del programa, de modo que, si no PERFORMse produce ninguna instrucción, el control fluye de arriba a abajo a través del programa. Pero cuando PERFORMse ejecuta una instrucción, modifica la dirección de continuación del procedimiento llamado (o el último procedimiento del rango llamado, si PERFORM THRUse utilizó), de modo que el control regresará al sitio de llamada al final. El valor original se guarda y se restaura después, pero solo hay una posición de almacenamiento. Si dos invocaciones anidadas operan en código superpuesto, pueden interferir en la gestión de la dirección de continuación de cada una de varias maneras. ^{[152] [153]}

El siguiente ejemplo (tomado de Veerman y Verhoeven 2006) ilustra el problema:

LABEL1.
    DISPLAY '1'
    PERFORM LABEL2 THRU LABEL3
    STOP RUN.
LABEL2.
    DISPLAY '2'
    PERFORM LABEL3 THRU LABEL4.
LABEL3.
    DISPLAY '3'.
LABEL4.
    DISPLAY '4'.

One might expect that the output of this program would be "1 2 3 4 3": After displaying "2", the second PERFORM causes "3" and "4" to be displayed, and then the first invocation continues on with "3". In traditional COBOL implementations, this is not the case. Rather, the first PERFORM statement sets the continuation address at the end of LABEL3 so that it will jump back to the call site inside LABEL1. The second PERFORM statement sets the return at the end of LABEL4 but does not modify the continuation address of LABEL3, expecting it to be the default continuation. Thus, when the inner invocation arrives at the end of LABEL3, it jumps back to the outer PERFORM statement, and the program stops having printed just "1 2 3". On the other hand, in some COBOL implementations like the open-source TinyCOBOL compiler, the two PERFORM statements do not interfere with each other and the output is indeed "1 2 3 4 3". Therefore, the behavior in such cases is not only (perhaps) surprising, it is also not portable.^[153]

A special consequence of this limitation is that PERFORM cannot be used to write recursive code. Another simple example to illustrate this (slightly simplified from Veerman & Verhoeven 2006):

    MOVE 1 TO A
    PERFORM LABEL
    STOP RUN.
LABEL.
    DISPLAY A
    IF A < 3
        ADD 1 TO A
        PERFORM LABEL
    END-IF
    DISPLAY 'END'.

One might expect that the output is "1 2 3 END END END", and in fact that is what some COBOL compilers will produce. But other compilers, like IBM COBOL, will produce code that prints "1 2 3 END END END END ..." and so on, printing "END" over and over in an endless loop. Since there is limited space to store backup continuation addresses, the backups get overwritten in the course of recursive invocations, and all that can be restored is the jump back to DISPLAY 'END'.^[153]

COBOL 2014 has 47 statements (also called verbs),^[154] which can be grouped into the following broad categories: control flow, I/O, data manipulation and the report writer. The report writer statements are covered in the report writer section.

COBOL's conditional statements are IF and EVALUATE. EVALUATE is a switch-like statement with the added capability of evaluating multiple values and conditions. This can be used to implement decision tables. For example, the following might be used to control a CNC lathe:

EVALUATE TRUE ALSO desired-speed ALSO current-speed
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
        PERFORM speed-up-machine
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
        PERFORM slow-down-machine
    WHEN lid-open ALSO ANY ALSO NOT ZERO
        PERFORM emergency-stop
    WHEN OTHER
        CONTINUE
END-EVALUATE

The PERFORM statement is used to define loops which are executed until a condition is true (not while true, which is more common in other languages). It is also used to call procedures or ranges of procedures (see the procedures section for more details). CALL and INVOKE call subprograms and methods, respectively. The name of the subprogram/method is contained in a string which may be a literal or a data item.^[155] Parameters can be passed by reference, by content (where a copy is passed by reference) or by value (but only if a prototype is available).^[156] CANCEL unloads subprograms from memory. GO TO causes the program to jump to a specified procedure.

The GOBACK statement is a return statement and the STOP statement stops the program. The EXIT statement has six different formats: it can be used as a return statement, a break statement, a continue statement, an end marker or to leave a procedure.^[157]

Exceptions are raised by a RAISE statement and caught with a handler, or declarative, defined in the DECLARATIVES portion of the procedure division. Declaratives are sections beginning with a USE statement which specify the errors to handle. Exceptions can be names or objects. RESUME is used in a declarative to jump to the statement after the one that raised the exception or to a procedure outside the DECLARATIVES. Unlike other languages, uncaught exceptions may not terminate the program and the program can proceed unaffected.

File I/O is handled by the self-describing OPEN, CLOSE, READ, and WRITE statements along with a further three: REWRITE, which updates a record; START, which selects subsequent records to access by finding a record with a certain key; and UNLOCK, which releases a lock on the last record accessed.

User interaction is done using ACCEPT and DISPLAY.

The following verbs manipulate data:

• INITIALIZE, which sets data items to their default values.
• MOVE, which assigns values to data items ; MOVE CORRESPONDING assigns corresponding like-named fields.
• SET, which has 15 formats: it can modify indices, assign object references and alter table capacities, among other functions.^[158]
• ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE, which handle arithmetic (with COMPUTE assigning the result of a formula to a variable).
• ALLOCATE and FREE, which handle dynamic memory.
• VALIDATE, which validates and distributes data as specified in an item's description in the data division.
• STRING and UNSTRING, which concatenate and split strings, respectively.
• INSPECT, which tallies or replaces instances of specified substrings within a string.
• SEARCH, which searches a table for the first entry satisfying a condition.

Files and tables are sorted using SORT and the MERGE verb merges and sorts files. The RELEASE verb provides records to sort and RETURN retrieves sorted records in order.

Some statements, such as IF and READ, may themselves contain statements. Such statements may be terminated in two ways: by a period (implicit termination), which terminates all unterminated statements contained, or by a scope terminator, which terminates the nearest matching open statement.

*> Terminator period ("implicit termination")
IF invalid-record
    IF no-more-records
        NEXT SENTENCE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE.

*> Scope terminators ("explicit termination")
IF invalid-record
    IF no-more-records
        CONTINUE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE
        END-READ
    END-IF
END-IF

Nested statements terminated with a period are a common source of bugs.^[159][160] For example, examine the following code:

IF x
    DISPLAY y.
    DISPLAY z.

Here, the intent is to display y and z if condition x is true. However, z will be displayed whatever the value of x because the IF statement is terminated by an erroneous period after DISPLAY y.

Another bug is a result of the dangling else problem, when two IF statements can associate with an ELSE.

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

In the above fragment, the ELSE associates with the  IF y  statement instead of the  IF x  statement, causing a bug. Prior to the introduction of explicit scope terminators, preventing it would require  ELSE NEXT SENTENCE  to be placed after the inner IF.^[160]

The original (1959) COBOL specification supported the infamous  ALTER X TO PROCEED TO Y  statement, for which many compilers generated self-modifying code. X and Y are procedure labels, and the single  GO TO  statement in procedure X executed after such an ALTER statement means  GO TO Y  instead. Many compilers still support it,^[161] but it was deemed obsolete in the COBOL 1985 standard and deleted in 2002.^[162]

The ALTER statement was poorly regarded because it undermined "locality of context" and made a program's overall logic difficult to comprehend.^[163] As textbook author Daniel D. McCracken wrote in 1976, when "someone who has never seen the program before must become familiar with it as quickly as possible, sometimes under critical time pressure because the program has failed ... the sight of a GO TO statement in a paragraph by itself, signaling as it does the existence of an unknown number of ALTER statements at unknown locations throughout the program, strikes fear in the heart of the bravest programmer."^[163]

A "Hello, World!" program in COBOL:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. hello-world.
       PROCEDURE DIVISION.
           DISPLAY "Hello, world!"
           .

When the now famous "Hello, World!" program example in The C Programming Language was first published in 1978 a similar mainframe COBOL program sample would have been submitted through JCL, very likely using a punch card reader, and 80 column punch cards. The listing below, with an empty DATA DIVISION, was tested using Linux and the System/370 Hercules emulator running MVS 3.8J. The JCL, written in July 2015, is derived from the Hercules tutorials and samples hosted by Jay Moseley.^[164] In keeping with COBOL programming of that era, HELLO, WORLD is displayed in all capital letters.

//COBUCLG  JOB (001),'COBOL BASE TEST',                                 00010000
//             CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)                        00020000
//BASETEST EXEC COBUCLG                                                 00030000
//COB.SYSIN DD *                                                        00040000
 00000* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

After submitting the JCL, the MVS console displayed:

    19.52.48 JOB    3  $HASP100 COBUCLG  ON READER1     COBOL BASE TEST
    19.52.48 JOB    3  IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG  ISSUED
    19.52.48 JOB    3  $HASP373 COBUCLG  STARTED - INIT 1 - CLASS A - SYS BSP1
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSLIB   DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEFACTRT - Stepname  Procstep  Program   Retcode
    19.52.48 JOB    3  COBUCLG    BASETEST  COB       IKFCBL00  RC= 0000
    19.52.48 JOB    3  COBUCLG    BASETEST  LKED      IEWL      RC= 0000
    19.52.48 JOB    3  +HELLO, WORLD
    19.52.48 JOB    3  COBUCLG    BASETEST  GO        PGM=*.DD  RC= 0000
    19.52.48 JOB    3  $HASP395 COBUCLG  ENDED

Line 10 of the console listing above is highlighted for effect, the highlighting is not part of the actual console output.

The associated compiler listing generated over four pages of technical detail and job run information, for the single line of output from the 14 lines of COBOL.

In the 1970s, adoption of the structured programming paradigm was becoming increasingly widespread. Edsger Dijkstra, a preeminent computer scientist, wrote a letter to the editor of Communications of the ACM, published in 1975 entitled "How do we tell truths that might hurt?", in which he was critical of COBOL and several other contemporary languages; remarking that "the use of COBOL cripples the mind".^[165]

In a published dissent to Dijkstra's remarks, the computer scientist Howard E. Tompkins claimed that unstructured COBOL tended to be "written by programmers that have never had the benefit of structured COBOL taught well", arguing that the issue was primarily one of training.^[166]

One cause of spaghetti code was the GO TO statement. Attempts to remove GO TOs from COBOL code, however, resulted in convoluted programs and reduced code quality.^[167] GO TOs were largely replaced by the PERFORM statement and procedures, which promoted modular programming^[167] and gave easy access to powerful looping facilities. However, PERFORM could be used only with procedures so loop bodies were not located where they were used, making programs harder to understand.^[168]

COBOL programs were infamous for being monolithic and lacking modularization.^[169] COBOL code could be modularized only through procedures, which were found to be inadequate for large systems. It was impossible to restrict access to data, meaning a procedure could access and modify any data item. Furthermore, there was no way to pass parameters to a procedure, an omission Jean Sammet regarded as the committee's biggest mistake.^[170]

Another complication stemmed from the ability to PERFORM THRU a specified sequence of procedures. This meant that control could jump to and return from any procedure, creating convoluted control flow and permitting a programmer to break the single-entry single-exit rule.^[171]

This situation improved as COBOL adopted more features. COBOL-74 added subprograms, giving programmers the ability to control the data each part of the program could access. COBOL-85 then added nested subprograms, allowing programmers to hide subprograms.^[172] Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included.

Nevertheless, much important legacy COBOL software uses unstructured code, which has become practically unmaintainable. It can be too risky and costly to modify even a simple section of code, since it may be used from unknown places in unknown ways.^[173]

COBOL was intended to be a highly portable, "common" language. However, by 2001, around 300 dialects had been created.^[174] One source of dialects was the standard itself: the 1974 standard was composed of one mandatory nucleus and eleven functional modules, each containing two or three levels of support. This permitted 104,976 possible variants.^[175]

COBOL-85 was not fully compatible with earlier versions, and its development was controversial. Joseph T. Brophy, the CIO of Travelers Insurance, spearheaded an effort to inform COBOL users of the heavy reprogramming costs of implementing the new standard.^[176] As a result, the ANSI COBOL Committee received more than 2,200 letters from the public, mostly negative, requiring the committee to make changes. On the other hand, conversion to COBOL-85 was thought to increase productivity in future years, thus justifying the conversion costs.^[177]

COBOL syntax has often been criticized for its verbosity. Proponents say that this was intended to make the code self-documenting, easing program maintenance.^[179] COBOL was also intended to be easy for programmers to learn and use,^[180] while still being readable to non-technical staff such as managers.^{[181][182][183][184]}

The desire for readability led to the use of English-like syntax and structural elements, such as nouns, verbs, clauses, sentences, sections, and divisions. Yet by 1984, maintainers of COBOL programs were struggling to deal with "incomprehensible" code^[183] and the main changes in COBOL-85 were there to help ease maintenance.^[93]

Jean Sammet, a short-range committee member, noted that "little attempt was made to cater to the professional programmer, in fact people whose main interest is programming tend to be very unhappy with COBOL" which she attributed to COBOL's verbose syntax.^[185]

The COBOL community has always been isolated from the computer science community. No academic computer scientists participated in the design of COBOL: all of those on the committee came from commerce or government. Computer scientists at the time were more interested in fields like numerical analysis, physics and system programming than the commercial file-processing problems which COBOL development tackled.^[186] Jean Sammet attributed COBOL's unpopularity to an initial "snob reaction" due to its inelegance, the lack of influential computer scientists participating in the design process and a disdain for business data processing.^[187] The COBOL specification used a unique "notation", or metalanguage, to define its syntax rather than the new Backus–Naur form which the committee did not know of. This resulted in "severe" criticism.^{[188][189][70]}

Later, COBOL suffered from a shortage of material covering it; it took until 1963 for introductory books to appear (with Richard D. Irwin publishing a college textbook on COBOL in 1966).^[191] By 1985, there were twice as many books on FORTRAN and four times as many on BASIC as on COBOL in the Library of Congress.^[129] University professors taught more modern, state-of-the-art languages and techniques instead of COBOL which was said to have a "trade school" nature.^[192] Donald Nelson, chair of the CODASYL COBOL committee, said in 1984 that "academics ... hate COBOL" and that computer science graduates "had 'hate COBOL' drilled into them".^[193]

By the mid-1980s, there was also significant condescension towards COBOL in the business community from users of other languages, for example FORTRAN or assembler, implying that COBOL could be used only for non-challenging problems.^[194]

In 2003, COBOL featured in 80% of information systems curricula in the United States, the same proportion as C++ and Java.^[195] Ten years later, a poll by Micro Focus found that 20% of university academics thought COBOL was outdated or dead and that 55% believed their students thought COBOL was outdated or dead. The same poll also found that only 25% of academics had COBOL programming on their curriculum even though 60% thought they should teach it.^[196]

Doubts have been raised about the competence of the standards committee. Short-term committee member Howard Bromberg said that there was "little control" over the development process and that it was "plagued by discontinuity of personnel and ... a lack of talent."^[81] Jean Sammet and Jerome Garfunkel also noted that changes introduced in one revision of the standard would be reverted in the next, due as much to changes in who was in the standard committee as to objective evidence.^[197]

COBOL standards have repeatedly suffered from delays: COBOL-85 arrived five years later than hoped,^[198] COBOL 2002 was five years late,^[3] and COBOL 2014 was six years late.^[101][199] To combat delays, the standard committee allowed the creation of optional addenda which would add features more quickly than by waiting for the next standard revision. However, some committee members raised concerns about incompatibilities between implementations and frequent modifications of the standard.^[200]

COBOL's data structures influenced subsequent programming languages. Its record and file structure influenced PL/I and Pascal, and the REDEFINES clause was a predecessor to Pascal's variant records. Explicit file structure definitions preceded the development of database management systems and aggregated data was a significant advance over Fortran's arrays.^[129]

PICTURE data declarations were incorporated into PL/I, with minor changes.

COBOL's COPY facility, although considered "primitive",^[201] influenced the development of include directives.^[129]

The focus on portability and standardization meant programs written in COBOL could be portable and facilitated the spread of the language to a wide variety of hardware platforms and operating systems.^[202] Additionally, the well-defined division structure restricts the definition of external references to the Environment Division, which simplifies platform changes in particular.^[203]

• Alphabetical list of programming languages
• BLIS/COBOL
• CODASYL
• Comparison of programming languages
• Generational list of programming languages § COBOL based
• List of compilers § COBOL compilers

• COBOLStandard.info at the Wayback Machine (archived 2017-01-10)
• ISO/IEC JTC1/SC22/WG4 - COBOL at the Wayback Machine (archived 2016-08-22)
• COBOL Language Standard (1991; COBOL-85 with Amendment 1), from The Open Group