COBOL ( / ˈkoʊbɒl , -bɔːl / ; acrónimo de " lenguaje común orientado a los negocios") 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 comerciales, financieros y administrativos para empresas y gobiernos. COBOL todavía se usa ampliamente en aplicaciones implementadas en computadoras mainframe , como trabajos de procesamiento de lotes y transacciones a gran escala . Muchas instituciones financieras grandes 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 en comparación con la sintaxis sucinta e inspirada en las matemáticas de otros lenguajes.MOVE x TO y
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] Los representantes incluyeron a 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 había sido 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]
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 a los usuarios migrar 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 , demostrando 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]
Es bastante improbable que Cobol siga existiendo a finales de la década.
Anónimo, junio de 1960 [74]
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 Extended 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 Edition 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 mejorar el 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. El Sr. 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, la ISO TC97-SC5 creó el Grupo Internacional de Expertos en COBOL, por iniciativa de Wim Ebbinkhuijsen . 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, la 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]
END-IF, END-PERFORM, END-READ, etc.)CONTINUE, una declaración de no operaciónEVALUATE, una declaración de cambioINITIALIZE, una declaración que puede establecer grupos de datos a sus valores predeterminadosPERFORM: anteriormente, los cuerpos de bucle debían especificarse en un procedimiento separadoLa 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 a .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]
SCREEN SECTIONbasadas en textoVALIDATEinstalaciónSe 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]
VALIDATEfunción de creación de informes y la función de manejo de pantalla.El estándar COBOL 2023 agregó algunas características nuevas:
SENDand [110]RECEIVECOMMIT con y ROLLBACK[110]XORoperador lógico [110]CONTINUEdeclaración se puede ampliar para pausar el programa durante una duración específica [111]DELETE FILEdeclaración [111]LINE SEQUENTIALorganización de archivos [112]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]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 parchar 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 admitir 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:
Esta descripción permite las siguientes variantes:
![{\displaystyle {\begin{array}{l}{\underline {\text{ADD}}}\,{\begin{Bmatrix}{\text{identificador-1}}\\{\text{literal-1}}\end{Bmatrix}}\dots \;{\underline {\text{HASTA}}}\,\left\{{\text{identificador-2}}\,\left[\,{\underline {\text{REDONDEADO}}}\,\right]\right\}\dots \\[1em]\quad \left[\left|{\begin{array}{l}{\text{ON}}\,{\underline {\text{TAMAÑO}}}\,{\underline {\text{ERROR}}}\,{\text{declaración-imperativa-1}}\\{\underline {\text{NO}}}\,{\text{ON}}\,{\underline {\text{TAMAÑO}}}\,{\underline {\text{ERROR}}}\,{\text{declaración-imperativa-2}}\end{array}}\right|\right]\\[1em]\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/9bace771d005c9518bae91a76654a24c7763aba9)
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, estos 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 código de formato libre. El código de formato libre 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. Las líneas de continuación no están presentes 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 signos 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 generalmente 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 tipo-de-salario 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]
PICTUREcláusula o mediante una USAGEcláusula comoBINARY-LONGUSAGE COMPUTATIONAL, donde los datos pueden almacenarse en cualquier formato que proporcione la implementación; a menudo equivalente a USAGE BINARYUSAGE DISPLAY, el formato predeterminado, donde los datos se almacenan como una cadenaUSAGE NATIONAL, donde los datos se almacenan como una cadena utilizando un conjunto de caracteres extendidoUSAGE 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 1Vendedor: 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 XXXXYYVendedor: 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 FIN-LECTURA VALIDAR registro-de-ventas SI registro-valido GENERAR ventas-en-el-dia DE LO CONTRARIO GENERAR ventas-inválidas FIN-SI FIN-EJECUTAR 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 alcanza el 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ó anteriormente 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:
ETIQUETA1 . MOSTRAR '1' EJECUTAR ETIQUETA2 A ETIQUETA3 DETENER EJECUTAR . ETIQUETA2 . MOSTRAR '2' EJECUTAR ETIQUETA3 A ETIQUETA4 . ETIQUETA3 . MOSTRAR '3' . ETIQUETA4 . MOSTRAR '4' . Se podría esperar que la salida de este programa fuera "1 2 3 4 3": después de mostrar "2", la segunda PERFORMhace que se muestren "3" y "4", y luego la primera invocación continúa con "3". En las implementaciones COBOL tradicionales, este no es el caso. En cambio, la primera PERFORMdeclaración establece la dirección de continuación al final de LABEL3para que salte de nuevo al sitio de llamada dentro de LABEL1. La segunda PERFORMdeclaración establece el retorno al final de LABEL4pero no modifica la dirección de continuación de LABEL3, esperando que sea la continuación predeterminada. Por lo tanto, cuando la invocación interna llega al final de LABEL3, salta de nuevo a la PERFORMdeclaración externa y el programa deja de haber impreso solo "1 2 3". Por otro lado, en algunas implementaciones COBOL como el compilador TinyCOBOL de código abierto, las dos PERFORMdeclaraciones no interfieren entre sí y la salida es de hecho "1 2 3 4 3". Por lo tanto, el comportamiento en tales casos no solo es (quizás) sorprendente, sino que tampoco es portable. [153]
Una consecuencia especial de esta limitación es que PERFORMno se puede utilizar para escribir código recursivo. Otro ejemplo sencillo para ilustrar esto (ligeramente simplificado de Veerman & Verhoeven 2006):
MOVER 1 A UNA ETIQUETA DE EJECUCIÓN DETENER EJECUTAR . ETIQUETA . MOSTRAR A SI A < 3 AGREGAR 1 A UNA ETIQUETA DE EJECUCIÓN FIN SI MOSTRAR 'FIN' . Se podría esperar que la salida sea "1 2 3 END END END", y de hecho eso es lo que producirán algunos compiladores COBOL. Pero otros compiladores, como IBM COBOL, producirán código que imprime "1 2 3 END END END END ..." y así sucesivamente, imprimiendo "END" una y otra vez en un bucle sin fin. Dado que hay espacio limitado para almacenar direcciones de continuación de copias de seguridad, las copias de seguridad se sobrescriben en el curso de invocaciones recursivas, y todo lo que se puede restaurar es el salto de regreso a DISPLAY 'END'. [153]
COBOL 2014 tiene 47 sentencias (también llamadas verbos ), [154] que se pueden agrupar en las siguientes categorías generales: flujo de control, E/S, manipulación de datos y el generador de informes. Las sentencias del generador de informes se tratan en la sección del generador de informes.
Las sentencias condicionales de COBOL son IFy EVALUATE. EVALUATEes una sentencia similar a una sentencia switch con la capacidad adicional de evaluar múltiples valores y condiciones. Esto se puede utilizar para implementar tablas de decisión . Por ejemplo, lo siguiente se puede utilizar para controlar un torno CNC :
EVALUAR VERDADERO TAMBIÉN velocidad deseada TAMBIÉN velocidad actual CUANDO tapa cerrada TAMBIÉN velocidad mín. HASTA velocidad máx. TAMBIÉN MENOR QUE velocidad deseada REALIZAR acelerar máquina CUANDO tapa cerrada TAMBIÉN velocidad mín. HASTA velocidad máx. TAMBIÉN MAYOR QUE velocidad deseada REALIZAR desacelerar máquina CUANDO tapa abierta TAMBIÉN CUALQUIERA TAMBIÉN NO CERO REALIZAR parada de emergencia CUANDO OTRO CONTINUAR FIN DE EVALUAR La PERFORMdeclaración se utiliza para definir bucles que se ejecutan hasta que una condición es verdadera (no mientras sea verdadera, lo cual es más común en otros lenguajes). También se utiliza para llamar a procedimientos o rangos de procedimientos (ver la sección de procedimientos para más detalles). CALLy INVOKEllamar a subprogramas y métodos, respectivamente. El nombre del subprograma/método está contenido en una cadena que puede ser un literal o un elemento de datos. [155] Los parámetros se pueden pasar por referencia , por contenido (donde se pasa una copia por referencia) o por valor (pero solo si hay un prototipo disponible). [156]CANCEL descarga subprogramas de la memoria. GO TOhace que el programa salte a un procedimiento especificado.
La GOBACKinstrucción es una instrucción de retorno y la STOPinstrucción detiene el programa. La EXITinstrucción tiene seis formatos diferentes: puede usarse como una instrucción de retorno, una instrucción de interrupción , una instrucción de continuación , un marcador de fin o para abandonar un procedimiento. [157]
Las excepciones se generan mediante una RAISEdeclaración y se capturan con un controlador o declarativo , definido en la DECLARATIVESparte de la división de procedimientos. Los declarativos son secciones que comienzan con una USEdeclaración que especifica los errores que se deben manejar. Las excepciones pueden ser nombres u objetos. RESUMEse utiliza en un declarativo para saltar a la declaración posterior a la que generó la excepción o a un procedimiento fuera del DECLARATIVES. A diferencia de otros lenguajes, las excepciones no capturadas pueden no terminar el programa y el programa puede continuar sin verse afectado.
La E/S de archivo se maneja mediante las declaraciones autodescriptivas OPEN, CLOSE, READ, y WRITEjunto con otras tres: REWRITE, que actualiza un registro; START, que selecciona registros subsiguientes a los que se accederá encontrando un registro con una clave determinada; y UNLOCK, que libera un bloqueo en el último registro al que se accedió.
La interacción del usuario se realiza mediante ACCEPTy DISPLAY.
Los siguientes verbos manipulan datos:
INITIALIZE, que establece los elementos de datos en sus valores predeterminados.MOVE, que asigna valores a elementos de datos; MOVE CORRESPONDING asigna campos correspondientes con el mismo nombre .SET, que cuenta con 15 formatos: puede modificar índices, asignar referencias a objetos y alterar capacidades de tablas, entre otras funciones. [158]ADD, SUBTRACT, MULTIPLY, DIVIDE, y COMPUTE, que manejan operaciones aritméticas ( COMPUTEasignando el resultado de una fórmula a una variable).ALLOCATEy FREE, que manejan la memoria dinámica .VALIDATE, que valida y distribuye datos según lo especificado en la descripción de un artículo en la división de datos.STRINGy UNSTRING, que concatenan y dividen cadenas , respectivamente.INSPECT, que cuenta o reemplaza instancias de subcadenas especificadas dentro de una cadena.SEARCH, que busca en una tabla la primera entrada que satisface una condición.Los archivos y las tablas se ordenan mediante SORTel MERGEverbo y se fusionan y ordenan los archivos. El RELEASEverbo proporciona registros para ordenar y RETURNrecupera los registros ordenados en orden.
Algunas instrucciones, como IFy READ, pueden contener instrucciones. Dichas instrucciones pueden terminarse de dos maneras: con un punto ( terminación implícita ), que termina todas las instrucciones no terminadas que contienen, o con un terminador de ámbito, que termina la instrucción abierta más cercana.
*> Período de terminación ("terminación implícita") IF registro-inválido IF no-más-registros NEXT SENTENCE ELSE READ archivo-registro AT END SET no-más-registros TO TRUE . *> Terminadores de ámbito ("terminación explícita") IF registro-inválido IF no-más-registros CONTINUE ELSE READ archivo-registro AT END SET no-más-registros TO TRUE END-READ END-IF END-IF Las declaraciones anidadas terminadas con un punto son una fuente común de errores. [159] [160] Por ejemplo, examine el siguiente código:
SI x MOSTRAR y . MOSTRAR z . Aquí, la intención es mostrar yy zsi la condición xes verdadera. Sin embargo, zse mostrará cualquiera sea el valor de xporque la IFdeclaración termina con un punto erróneo después de .DISPLAY y
Otro error es el resultado del problema else colgante , cuando dos IFdeclaraciones pueden asociarse con un ELSE.
SI x SI y MOSTRAR a DE LO CONTRARIO MOSTRAR b . En el fragmento anterior, ELSEse asocia con la declaración en lugar de con la declaración, lo que provoca un error. Antes de la introducción de terminadores de ámbito explícitos, para evitarlo habría que colocarlo después del . interno . [160]IF yIF xELSE NEXT SENTENCEIF
La especificación COBOL original (1959) admitía la infame declaración, para la cual muchos compiladores generaban código automodificable . y son etiquetas de procedimiento, y la única declaración en el procedimiento ejecutado después de dicha declaración significa en su lugar. Muchos compiladores aún la admiten, [161] pero se consideró obsoleta en el estándar COBOL 1985 y se eliminó en 2002. [162]ALTER X TO PROCEED TO YXYGO TOXALTERGO TO Y
Esta ALTERafirmación no fue bien vista porque socavaba la "localidad del contexto" y hacía que la lógica general de un programa fuera difícil de comprender. [163] Como escribió el autor de libros de texto Daniel D. McCracken en 1976, cuando "alguien que nunca ha visto el programa antes debe familiarizarse con él lo más rápido posible, a veces bajo una presión crítica de tiempo porque el programa ha fallado... la visión de una declaración GO TO en un párrafo por sí sola, señalando como lo hace la existencia de un número desconocido de declaraciones ALTER en lugares desconocidos a lo largo del programa, infunde miedo en el corazón del programador más valiente". [163]
Un programa "¡Hola, mundo!" en COBOL:
DIVISIÓN DE IDENTIFICACIÓN . PROGRAM-ID . hola-mundo . DIVISIÓN DE PROCEDIMIENTO . PANTALLA "¡Hola, mundo!" . Cuando el ahora famoso ejemplo de programa "Hello, World!" en el lenguaje de programación C se publicó por primera vez en 1978, se habría enviado una muestra de programa COBOL de mainframe similar a través de JCL , muy probablemente utilizando un lector de tarjetas perforadas y tarjetas perforadas de 80 columnas. La lista a continuación, con una DATA DIVISION vacía , se probó utilizando Linux y el emulador System/370 Hercules ejecutando MVS 3.8J. El JCL, escrito en julio de 2015, se deriva de los tutoriales y muestras de Hercules alojados por Jay Moseley. [164] De acuerdo con la programación COBOL de esa era, HELLO, WORLD se muestra en letras mayúsculas.
// COBUCLG JOB ( 001 ), 'COBOL BASE TEST' , 00010000 // CLASS = A , MSGCLASS = A , MSGLEVEL = ( 1 , 1 ) 00020000 // BASETEST EXEC COBUCLG 00030000 // COB . SYSIN DD * 00040000 00000 * VALIDACIÓN DE BASE COBOL INSTALL 00050000 01000 IDENTIFICACIÓN DIVISIÓN . 00060000 01100 PROGRAM-ID . 'HELLO' . 00070000 02000 ENTORNO DIVISIÓN . 00080000 02100 CONFIGURACIÓN SECCIÓN . 00090000 02110 COMPUTADORA-FUENTE . GNULINUX . 00100000 02120 COMPUTADORA-OBJETO . HERCULES . 00110000 02200 NOMBRES- ESPECIALES . 00120000 02210 LA CONSOLA ES CONSL . 00130000 03000 DIVISIÓN DE DATOS . 00140000 04000 DIVISIÓN DE PROCEDIMIENTO . 00150000 04100 00 - PRINCIPAL . 00160000 04110 MOSTRAR 'HOLA, MUNDO' AL CONSL . 00170000 04900 DETENER EJECUCIÓN . 00180000 // LKED . SYSLIB DD DSNAME = SYS1 . COBLIB , DISP = SHR 00190000 // DD DSNAME = SYS1 . LINKLIB , DISP = SHR 00200000 // IR . SYSPRINT DD SYSOUT = A 00210000 // 00220000 Después de enviar el JCL, la consola MVS mostró:
19.52.48 TRABAJO 3 $HASP100 COBUCLG EN PRUEBA BASE COBOL READER1 19.52.48 TRABAJO 3 IEF677I MENSAJE(S) DE ADVERTENCIA PARA EL TRABAJO COBUCLG EMITIDO 19.52.48 TRABAJO 3 $HASP373 COBUCLG INICIADO - INICIO 1 - CLASE A - SISTEMA BSP1 19.52.48 TRABAJO 3 IEC130I SYSPUNCH DECLARACIÓN DD FALTANTE 19.52.48 TRABAJO 3 IEC130I SYSLIB DECLARACIÓN DD FALTANTE 19.52.48 TRABAJO 3 IEC130I SYSPUNCH DECLARACIÓN DD FALTANTE 19.52.48 TRABAJO 3 IEFACTRT - Nombre del paso Procstep Programa Retcode 19.52.48 TRABAJO 3 COBUCLG BASE DE PRUEBA COB IKFCBL00 RC= 0000 19.52.48 TRABAJO 3 COBUCLG BASE DE PRUEBA 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 FINALIZADOLa línea 10 del listado de la consola anterior está resaltada para lograr efecto; el resaltado no es parte de la salida real de la consola .
La lista del compilador asociado generó más de cuatro páginas de detalles técnicos e información de 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 estaba extendiendo cada vez más. Edsger Dijkstra , un destacado 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 a COBOL y a varios otros lenguajes contemporáneos, y señalaba que «el uso de COBOL paraliza la mente». [165]
En una disidencia publicada sobre las observaciones 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 habían tenido el beneficio de un COBOL estructurado bien enseñado", argumentando que el problema era principalmente de entrenamiento. [166]
Una de las causas del código espagueti fue la GO TOdeclaración. Sin embargo, los intentos de eliminar GO TOlas s del código COBOL dieron como resultado programas enrevesados y una calidad reducida del código. [167] GO TO Las s fueron reemplazadas en gran medida por la PERFORMdeclaración y los procedimientos, que promovieron la programación modular [167] y brindaron un acceso fácil a potentes funciones de bucle. Sin embargo, PERFORMsolo se podían 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. [168]
Los programas COBOL tenían mala fama por ser monolíticos y carecer de modularidad. [169] El código COBOL sólo podía modularizarse mediante procedimientos, que se consideraban inadecuados para sistemas grandes. Era imposible restringir el acceso a los datos, lo que significa 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é. [170]
Otra complicación surgió de la posibilidad de seguir PERFORM THRUuna secuencia específica de procedimientos. Esto significaba que el control podía saltar hacia y desde cualquier procedimiento, lo que creaba un flujo de control enrevesado y permitía a un programador romper la regla de entrada única y salida única . [171]
Esta situación mejoró a medida que COBOL adoptó más funciones. COBOL-74 agregó subprogramas, lo que les dio a los programadores la capacidad de controlar los datos a los que cada parte del programa podía acceder. Luego, COBOL-85 agregó subprogramas anidados, lo que permitió a los programadores ocultar subprogramas. [172] En 2002, se logró un mayor control sobre los datos y el código cuando se incluyeron la programación orientada a objetos, las funciones definidas por el usuario y los tipos de datos definidos por el usuario.
Sin embargo, gran parte del software COBOL heredado utiliza código no estructurado, que se ha vuelto prácticamente imposible de mantener. Puede resultar demasiado arriesgado y costoso modificar incluso una simple sección de código, ya que puede utilizarse desde lugares desconocidos y de formas desconocidas. [173]
COBOL se concibió como un lenguaje "común" y altamente portable. Sin embargo, en 2001, se habían creado alrededor de 300 dialectos. [174] 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 de los cuales contenía dos o tres niveles de soporte. Esto permitió 104.976 variantes posibles. [175]
COBOL-85 no era totalmente compatible con versiones anteriores y su desarrollo fue controvertido. Joseph T. Brophy, el CIO de Travelers Insurance , encabezó un esfuerzo para informar a los usuarios de COBOL de los altos costos de reprogramación que implicaba la implementación del nuevo estándar. [176] Como resultado, el Comité ANSI COBOL recibió más de 2200 cartas del público, en su mayoría negativas, que exigían al comité que hiciera cambios. Por otro lado, se pensaba que la conversión a COBOL-85 aumentaría la productividad en los años futuros, lo que justificaba los costos de conversión. [177]
Un lenguaje débil, verboso y flácido utilizado por los programadores para hacer cosas aburridas y sin sentido en mainframes dinosaurios. [...] Su propio nombre rara vez se pronuncia sin expresiones rituales de disgusto u horror.
El archivo de la jerga 4.4.8. [178]
La sintaxis COBOL ha sido criticada a menudo por su verbosidad. Los defensores dicen que esto tenía como objetivo hacer que el código se autodocumentara , facilitando el mantenimiento del programa. [179] COBOL también tenía como objetivo que fuera fácil de aprender y usar para los programadores, [180] y que al mismo tiempo fuera legible para el personal no técnico, como los gerentes. [181] [182] [183] [184]
El deseo de legibilidad condujo 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 encargados del mantenimiento de los programas COBOL tenían dificultades para lidiar con código "incomprensible" [183] y los principales cambios en COBOL-85 estaban destinados a facilitar el mantenimiento. [93]
Jean Sammet, miembro del comité de corto alcance, señaló que "se hicieron pocos intentos por atender a los programadores profesionales; de hecho, las personas cuyo principal interés es la programación tienden a estar muy descontentas con COBOL", lo que atribuyó a la sintaxis verbosa de COBOL. [185]
La comunidad COBOL siempre ha estado aislada de la comunidad informática. Ningún científico informático académico participó en el diseño de COBOL: todos los que formaban parte del comité provenían del comercio o del gobierno. Los científicos informáticos de la época estaban más interesados en campos como el análisis numérico, la física y la programación de sistemas que en los problemas de procesamiento de archivos comerciales que abordaba el desarrollo de COBOL. [186] Jean Sammet atribuyó la impopularidad de COBOL a una "reacción snob" inicial debido a su falta de elegancia, la falta de científicos informáticos influyentes que participaran en el proceso de diseño y un desdén por el procesamiento de datos comerciales. [187] La especificación COBOL utilizó una "notación" única, o metalenguaje , para definir su sintaxis en lugar de la nueva forma Backus-Naur que el comité desconocía. Esto dio lugar a críticas "severas". [188] [189] [70]
El mundo académico tiende a considerar que COBOL es verboso, torpe y poco elegante, y trata de ignorarlo, aunque probablemente haya más programas y programadores COBOL en el mundo que para FORTRAN, ALGOL y PL/I juntos. En su mayor parte, sólo las escuelas con un objetivo vocacional inmediato imparten instrucción en COBOL.
Richard Conway y David Gries , 1973 [190]
Más tarde, COBOL sufrió una escasez de material que lo cubriera; hubo que esperar hasta 1963 para que aparecieran libros introductorios (con Richard D. Irwin publicando un libro de texto universitario sobre COBOL en 1966). [191] Para 1985, había el doble de libros sobre FORTRAN y cuatro veces más sobre BASIC que sobre COBOL en la Biblioteca del Congreso . [129] Los profesores universitarios enseñaban lenguajes y técnicas más modernos y de última generación en lugar de COBOL, que se decía que tenía una naturaleza de "escuela de oficios". [192] Donald Nelson, presidente del comité COBOL de CODASYL, dijo en 1984 que "los académicos... odian a COBOL" y que a los graduados en ciencias de la computación "se les había inculcado el 'odio a COBOL'". [193]
A mediados de la década de 1980, también hubo una condescendencia significativa hacia COBOL en la comunidad empresarial por parte de los usuarios de otros lenguajes, por ejemplo FORTRAN o ensamblador , lo que implicaba que COBOL solo podía usarse para problemas que no representaran un desafío. [194]
En 2003, COBOL figuraba en el 80% de los planes de estudios de sistemas de información en los Estados Unidos, la misma proporción que C++ y Java . [195] Diez años después, una encuesta de Micro Focus descubrió que el 20% de los académicos universitarios pensaba que COBOL estaba obsoleto o muerto y que el 55% creía que sus estudiantes pensaban que COBOL estaba obsoleto o muerto. La misma encuesta también descubrió que solo el 25% de los académicos tenían programación COBOL en su plan de estudios, aunque el 60% pensaba que deberían enseñarla. [196]
Se han planteado dudas sobre la competencia del comité de normas. Howard Bromberg, miembro del comité por un corto tiempo, dijo que había "poco control" sobre el proceso de desarrollo y que estaba "plagado por la discontinuidad del personal y... por la falta de talento". [81] Jean Sammet y Jerome Garfunkel también observaron que los cambios introducidos en una revisión de la norma se revertirían en la siguiente, debido tanto a cambios en los integrantes del comité de normas como a evidencia objetiva. [197]
Los estándares COBOL han sufrido retrasos en repetidas ocasiones: COBOL-85 llegó cinco años más tarde de lo esperado, [198] COBOL 2002 se retrasó cinco años, [3] y COBOL 2014 se retrasó seis años. [101] [199] Para combatir los retrasos, el comité de estándares permitió la creación de adendas opcionales que agregarían características más rápidamente que si se esperara a la siguiente revisión del estándar. Sin embargo, algunos miembros del comité plantearon inquietudes sobre incompatibilidades entre implementaciones y modificaciones frecuentes del estándar. [200]
Las estructuras de datos de COBOL influyeron en los lenguajes de programación posteriores. Su estructura de registros y archivos influyó en PL/I y Pascal , y la REDEFINEScláusula fue un predecesor de los registros variantes de Pascal. Las definiciones explícitas de estructuras de archivos precedieron al desarrollo de los sistemas de gestión de bases de datos y los datos agregados fueron un avance significativo con respecto a las matrices de Fortran. [129]
PICTURELas declaraciones de datos se incorporaron a PL/I, con cambios menores.
La facilidad de uso de COBOL COPY, aunque considerada "primitiva", [201] influyó en el desarrollo de las directivas de inclusión . [129]
El enfoque en la portabilidad y la estandarización significó que los programas escritos en COBOL podían ser portables y facilitó la difusión del lenguaje a una amplia variedad de plataformas de hardware y sistemas operativos. [202] 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. [203]
El Comité de Corto Plazo trabajó diligentemente desde junio de 1959 en adelante, pero hubo grandes dificultades para que un comité bastante grande intentara crear un lenguaje de programación. En noviembre, el presidente del Comité de Corto Plazo nombró a seis personas para desarrollar especificaciones para su consideración: William Selden y Gertrude Tierney (IBM), Howard Bromberg y Norman Discount (RCA), y Vernon Reeves y Jean E. Sammet (Sylvania Electric Products). Trabajamos durante dos semanas completas (incluyendo algunas sesiones de 24 horas) en noviembre de 1959 y enviamos las especificaciones propuestas al Comité de Corto Plazo en pleno, que las aceptó casi todas. Después de algunas modificaciones (por parte de las mismas seis personas), en diciembre entregamos las especificaciones como informe final al Comité Ejecutivo, que las aceptó en enero de 1960. Después de algunas modificaciones adicionales, la Oficina de Imprenta del Gobierno publicó Cobol 60. [...] [Grace Hopper] no participó en su trabajo, salvo a través de la orientación general que dio a su personal, que eran miembros directos del comité. Por lo tanto, si bien su influencia indirecta fue muy importante, lamentablemente las frecuentes declaraciones de que "Grace Hopper desarrolló Cobol" o "Grace Hopper fue una de las codesarrolladoras de Cobol" o "Grace Hopper es la madre de Cobol" simplemente no son correctas.
El estilo COBOL orientado a objetos refleja la influencia de Smalltalk y C++.
... la conversión a un COBOL alternativo extendido o a ANSI COBOL es muy difícil, si es que es posible
(Grace Hopper) Apodada la abuela Cobol, el código se basaba en algunos de sus trabajos anteriores. Dijo que, después de escuchar los rumores, uno de sus colaboradores salió y compró una lápida de granito. "Hizo que grabaran la palabra COBOL en el frente. Luego la envió por correo urgente al Sr. Phillips en el Pentágono". La broma a Charles Phillips, un líder del proyecto en el Departamento de Defensa, llamó la atención de los poderes fácticos y fue un punto de inflexión, dijo. COBOL se convertiría en el lenguaje de programación más utilizado y más duradero de la historia.
Por lo tanto, el principal problema del Y2K es el problema de los resultados incorrectos cuando se realizan cálculos matemáticos de fechas.
Varias agencias, como el Departamento de Agricultura (USDA), el DHS, el HHS, el Departamento de Justicia, el Tesoro y el Departamento de Asuntos de los Veteranos (VA), informaron que utilizan el lenguaje común orientado a los negocios (COBOL), un lenguaje de programación desarrollado a fines de la década de 1950 y principios de la de 1960, para programar sus sistemas heredados. Es ampliamente conocido que las agencias necesitan migrar a lenguajes más modernos y fáciles de mantener, según sea apropiado y factible.
ALTERLa fecha más temprana en la que se pudo desarrollar y aprobar un nuevo estándar COBOL es el año 1980 [...].
una revisión de junio de 2008 del estándar COBOL
Micro Focus Visual COBOL ofrece la próxima generación de desarrollo e implementación de COBOL para Linux x86-64, Linux para System z, AIX, HP/UX, Solaris y Windows.
{{cite book}}: CS1 maint: numeric names: authors list (link){{cite book}}: CS1 maint: numeric names: authors list (link)
Definiciones de Wikcionario
Medios de comunicación de Commons
Libros de texto de Wikilibros
Recursos de Wikiversidad
Datos de Wikidata