COBOL ( / ˈ k oʊ 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 transacciones y lotes a gran escala . Muchas grandes instituciones financieras estaban desarrollando nuevos sistemas en el lenguaje en fecha tan tardía como 2006, [9] pero la mayor parte de la programación actual en COBOL es puramente para mantener aplicaciones existentes. Los programas se trasladan a nuevas plataformas, se reescriben en lenguajes modernos o se reemplazan con otro software. [10]
COBOL fue diseñado en 1959 por CODASYL y se basó en parte 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 EE. UU. para crear un lenguaje de programación portátil para el procesamiento de datos. Originalmente se consideró una solución provisional, pero el Departamento de Defensa rápidamente obligó a los fabricantes de computadoras a proporcionarlo, lo que resultó en su adopción generalizada. [11] Fue estandarizado en 1968 y ha sido revisado cinco veces. Las expansiones incluyen soporte para programación estructurada y orientada a objetos . La norma actual es ISO / IEC 1989:2023. [12]
Las declaraciones COBOL tienen una sintaxis en prosa como , que fue diseñada para ser autodocumentada y altamente legible. Sin embargo, es detallado y utiliza más de 300 palabras reservadas . Esto contrasta con la sintaxis sucinta y de inspiración matemática de otros lenguajes (en este caso, ).MOVE x TO y
y = x;
El código COBOL se divide en cuatro divisiones (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 declaraciones, 87 funciones y solo una clase.
Los informáticos académicos generalmente no estaban interesados en las aplicaciones empresariales cuando se creó COBOL y no participaron en su diseño; fue (efectivamente) diseñado desde cero como un lenguaje informático para empresas, con énfasis en entradas y salidas, cuyos únicos tipos de datos eran números y cadenas de texto. [13]
COBOL ha sido criticado por su verbosidad, proceso de diseño y soporte deficiente para la programación estructurada . Estas debilidades dan como resultado programas monolíticos que son difíciles de comprender en su conjunto, a pesar de su legibilidad local.
Durante años, COBOL se ha asumido como un lenguaje de programación para operaciones comerciales en mainframes, [14] aunque en los últimos años, muchas operaciones COBOL se han trasladado a la computación en la nube . [15]
A finales de la década de 1950, los usuarios y fabricantes de computadoras comenzaron a preocuparse por el costo creciente de la programación. Una encuesta realizada en 1959 encontró que en cualquier instalación de procesamiento de datos, la programación costaba en promedio 800.000 dólares y que traducir programas para ejecutarlos en hardware nuevo costaría 600.000 dólares. En un momento en el que proliferaban nuevos lenguajes de programación , la misma encuesta sugería que si se utilizara un lenguaje común orientado a los negocios, la conversión sería mucho más barata y rápida. [dieciséis]
El 8 de abril de 1959, Mary K. Hawes , científica informática de Burroughs Corporation , convocó una reunión de representantes del mundo académico, usuarios de ordenadores y fabricantes en la Universidad de Pensilvania para organizar una reunión formal sobre lenguajes comerciales comunes. [17] 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 . [18] [19]
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 Departamento de Defensa, [20] quien pensó que "entendían completamente" los problemas del Departamento de Defensa. El Departamento de Defensa 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 ejecutarlas. Los programas portátiles ahorrarían tiempo, reducirían costos y facilitarían la modernización. [21]
Charles Phillips acordó patrocinar la reunión y encargó a la delegación la redacción de la agenda. [22]
Los días 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 las empresas. Asistieron 41 personas y estuvo presidido por Phillips. [23] Al Departamento de Defensa le preocupaba si podí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 dichos programas. [24]
Los representantes describieron con entusiasmo un lenguaje que podría funcionar en una amplia variedad de entornos, desde banca y seguros hasta servicios públicos y control de inventario. Estuvieron de acuerdo unánimemente en que más personas deberían poder programar y que el nuevo lenguaje no debería estar restringido por las limitaciones de la tecnología contemporánea. La mayoría estuvo de acuerdo en que el idioma debería aprovechar al máximo el inglés, ser capaz de cambiar, ser independiente de las máquinas y fácil de usar, incluso a expensas de la potencia. [25]
La reunión resultó en la creación de un comité directivo y comités de corto, mediano y largo plazo. Al comité de corto plazo se le dio hasta septiembre (tres meses) para elaborar especificaciones para un lenguaje provisional, que luego sería mejorado por los otros comités. [26] [27] Su misión oficial, sin embargo, era identificar las fortalezas y debilidades de los lenguajes de programación existentes y no los dirigía explícitamente a crear un nuevo lenguaje. [24]
El comité de corto plazo acogió con incredulidad el plazo. [28] Un miembro, Betty Holberton , describió el plazo de tres meses como "gran optimismo" y dudaba que el lenguaje realmente fuera un recurso provisional. [29]
El comité directivo se reunió el 4 de junio y acordó nombrar toda la actividad como Comité de Lenguajes de Sistemas de Datos , o CODASYL , y formar un comité ejecutivo. [30]
Los miembros del comité de corto alcance representaron a seis fabricantes de computadoras y tres agencias gubernamentales. Los fabricantes de computadoras fueron Burroughs Corporation , IBM , Minneapolis-Honeywell (Honeywell Labs), RCA , Sperry Rand y Sylvania Electric Products . Las agencias gubernamentales eran la Fuerza Aérea de EE. UU ., el Modelo de Cuenca David Taylor de la Armada y la Oficina Nacional de Estándares (ahora Instituto Nacional de Estándares y Tecnología). [31] El comité estuvo presidido por Joseph Wegstein de la Oficina Nacional de Normas de Estados Unidos. El trabajo comenzó investigando la descripción de datos, declaraciones, aplicaciones existentes y experiencias de usuario. [32]
El comité examinó principalmente los lenguajes de programación FLOW-MATIC , AIMACO y COMTRAN . [24] [33] El lenguaje FLOW-MATIC fue particularmente influyente porque se había implementado y porque AIMACO era un derivado del mismo con solo cambios menores. [34] [35] La inventora de FLOW-MATIC, Grace Hopper, también sirvió como asesora técnica del comité. [28] Las principales contribuciones de FLOW-MATIC a COBOL fueron nombres largos de variables, palabras en inglés para comandos y la separación de descripciones de datos e instrucciones. [36]
A Hopper a veces se le llama "la madre de COBOL" o "la abuela de COBOL", [37] [38] [39] aunque Jean Sammet , diseñador principal de COBOL, dijo que Hopper "no era la madre, creadora o desarrolladora de Cobol". ". [40] [1]
El lenguaje COMTRAN de IBM, inventado por Bob Bemer , fue considerado un competidor de FLOW-MATIC [41] [42] por un comité de corto alcance formado por colegas de Grace Hopper. [43] Algunas de sus características no se incorporaron a COBOL para que no pareciera que IBM había dominado el proceso de diseño, [26] y Jean Sammet dijo en 1981 que había habido un "fuerte sesgo anti-IBM" por parte de algún comité. miembros (ella misma incluida). [44] 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 fomentar el uso de expresiones algebraicas, Grace Hopper envió un memorando al comité de corto alcance. reiterando los esfuerzos de Sperry Rand por crear un idioma basado en el inglés. [45]
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 afirmaría que el trabajo fue influenciado tanto por FLOW-MATIC como por COMTRAN sólo para "mantener felices a otras personas [para que] no intentaran noquearnos". [46]
Las características de COMTRAN incorporadas en COBOL incluían fórmulas, [47] la cláusula PICTURE, [48] una declaración mejorada IF
, que evitó la necesidad de GO TO y un sistema de administración de archivos más robusto. [41]
La utilidad del trabajo del comité fue objeto de un gran debate. Si bien algunos miembros pensaron que el lenguaje tenía demasiados compromisos y era el resultado del diseño del comité , otros sintieron que era mejor que los tres lenguajes examinados. Algunos sintieron que el lenguaje era demasiado complejo; otros, demasiado simples. [49]
Las características controvertidas incluyeron aquellas que algunos consideraban inútiles o demasiado avanzadas para los usuarios de procesamiento de datos. Dichas características incluían expresiones booleanas , fórmulas y subíndices de tablas (índices). [50] [51] Otro punto de controversia fue si hacer que las palabras clave sean sensibles al contexto y el efecto que eso tendría en la legibilidad. [50] 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. [52] Se prestó poca atención a la interactividad , la interacción con los sistemas operativos (existían pocos en ese momento) y las funciones. (considerado puramente matemático y sin utilidad en el procesamiento de datos). [53] [54]
Las especificaciones fueron presentadas al comité ejecutivo el 4 de septiembre. No cumplieron con las expectativas: Joseph Wegstein señaló que "contiene puntos difíciles y requiere algunas adiciones", y Bob Bemer los describió más tarde como una "mezcolanza". Al subcomité se le dio hasta diciembre para mejorarlo. [28]
En una reunión de mediados de septiembre, el comité discutió el nombre del nuevo idioma. Las sugerencias incluyeron "BUSY" (sistema empresarial), "INFOSYL" (lenguaje del sistema de información) y "COCOSYL" (lenguaje común de los sistemas informáticos). [55] No está claro quién acuñó el nombre "COBOL", [56] [57] aunque Bob Bemer afirmó más tarde que había sido sugerencia suya. [58] [59] [60]
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 ellas. [61]
Esto fue un duro golpe para el comité de corto alcance, que había logrado buenos avances en la especificación. A pesar de ser técnicamente superior, FACT no se creó teniendo en cuenta la portabilidad ni mediante el consenso del fabricante y el usuario. También carecía de una implementación demostrable, [28] que permitiera a los partidarios de un COBOL basado en FLOW-MATIC anular la resolución. El representante de RCA, Howard Bromberg, también bloqueó FACT, para que el trabajo de RCA en la implementación de COBOL no se desperdiciara. [62]
Pronto se hizo evidente que el comité era demasiado grande para poder lograr más avances rápidamente. Un frustrado Howard Bromberg compró una lápida de 15 dólares con "COBOL" grabado y se la envió a Charles Phillips para demostrar su descontento. [b] [64] [65]
Se formó un subcomité para analizar los idiomas existentes y estuvo compuesto por seis personas: [24] [66]
El subcomité hizo la mayor parte del trabajo creando la especificación, dejando que el comité de corto plazo revisara y modificara su trabajo antes de producir la especificación terminada. [24]
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 portátiles y eficientes, permitir a los usuarios pasar a nuevos sistemas con un mínimo esfuerzo y costo, y ser adecuado para programadores sin experiencia. [67]
Posteriormente, el Comité Ejecutivo de CODASYL creó el Comité de Mantenimiento de COBOL para responder preguntas de usuarios y proveedores y mejorar y ampliar las especificaciones. [68]
Durante 1960, creció la lista de fabricantes que planeaban construir compiladores COBOL. En 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 planearon integrar COBOL en sus propios lenguajes, GECOM y COMTRAN, respectivamente. Por el contrario, International Computers and Tabulators planeaba reemplazar su lenguaje, CODEL, por COBOL. [69]
Mientras tanto, RCA y Sperry Rand trabajaron en la creación de compiladores COBOL. El primer programa COBOL se ejecutó el 17 de agosto en un RCA 501. [70] Los días 6 y 7 de diciembre, el mismo programa COBOL (aunque con cambios menores) se ejecutó en una computadora RCA y una computadora Remington-Rand Univac , lo que demuestra que la compatibilidad podría ser logrado. [71]
Las influencias relativas de los idiomas que se utilizaron continúan hasta el día de hoy en el aviso recomendado impreso en todos los manuales de referencia de 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é CODASYL COBOL ofrecen ninguna garantía, expresa o implícita, en cuanto a la precisión y el funcionamiento del sistema y lenguaje de programación. Además, ningún colaborador ni el comité asumen ninguna responsabilidad 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, propiedad intelectual de 1958, 1959 de Unisys Corporation; Formulario de traductor comercial de IBM n.º F28-8013, con derechos de autor de IBM en 1959; FACT, DSI 27A5260-2760, propiedad intelectual 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 especificaciones COBOL en manuales de programación o publicaciones similares. [72]
Es bastante improbable que Cobol exista al final de la década.
Anónimo, junio de 1960 [73]
Se encontraron muchos defectos lógicos en COBOL 60 , lo que llevó a Charles Katz de General Electric a advertir que no podía interpretarse sin ambigüedades. Un comité reacio a corto plazo 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. [69]
COBOL es un lenguaje difícil para escribir un compilador, debido a la gran sintaxis y muchos 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. ups para operaciones de E/S. [74] 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 entre 11 y 1.000 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 oscilaban entre $0,23 y $18,91. [75]
A finales de 1962, IBM anunció que COBOL sería su principal lenguaje de desarrollo y que cesaría el desarrollo de COMTRAN. [75]
La especificación COBOL fue revisada tres veces en los cinco años posteriores a su publicación. COBOL-60 fue reemplazado en 1961 por COBOL-61. Luego, esto fue reemplazado por las especificaciones extendidas COBOL-61 en 1963, que introdujeron las funciones de clasificación y redacción de informes. [76] Las instalaciones adicionales corrigieron los defectos identificados por Honeywell a finales de 1959 en una carta al comité de corto alcance. [70] COBOL Edición 1965 trajo más aclaraciones a las especificaciones e introdujo funciones para manejar archivos y tablas de almacenamiento masivo . [77]
Comenzaron los esfuerzos para estandarizar COBOL para superar las incompatibilidades entre versiones. A finales de 1962, tanto la ISO como el Instituto de Normas de los Estados Unidos de América (ahora ANSI ) formaron grupos para crear normas. ANSI produjo el estándar estadounidense COBOL X3.23 en agosto de 1968, que se convirtió en la piedra angular de versiones posteriores. [78] Esta versión se conocía como American National Standard (ANS) COBOL y fue adoptada por ISO en 1972. [79]
En 1970, COBOL se había convertido en el lenguaje de programación más utilizado en el mundo. [80]
Independientemente del comité ANSI, el Comité de Lenguaje de Programación CODASYL estaba trabajando para mejorar el lenguaje. Describieron nuevas versiones en 1968, 1969, 1970 y 1973, incluidos cambios como nuevas funciones de comunicación entre programas, depuración y fusión de archivos, así como funciones mejoradas de inclusión de bibliotecas y manejo de cadenas . [81]
Aunque CODASYL era independiente del comité ANSI, ANSI utilizó el CODASYL Journal of Development para identificar características que eran lo suficientemente populares como para justificar su implementación. [82] El Comité de Lenguaje de Programación también sirvió de enlace con ECMA y el comité japonés de estándares COBOL. [81]
Sin embargo, el Comité de Lenguajes de Programación no era muy conocido. El vicepresidente William Rinehuls se quejó de que dos tercios de la comunidad COBOL no conocían la existencia del comité. También carecía de fondos para hacer que documentos públicos, como actas de reuniones y propuestas de cambio, estuvieran disponibles gratuitamente. [83]
En 1974, ANSI publicó una versión revisada de (ANS) COBOL, que contenía nuevas características como organizaciones de archivos, la DELETE
declaración [84] y el módulo de segmentación . [85] Las características eliminadas incluyeron la NOTE
declaración, la EXAMINE
declaració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 secuenciales y relativos). Se trataba de 44 cambios, que hacían que las declaraciones existentes fueran incompatibles con la nueva norma. [86] Estaba previsto que el redactor del informe fuera eliminado de COBOL, pero fue reintegrado antes de que se publicara el estándar. [87] [88] Posteriormente, ISO adoptó la norma actualizada en 1978. [79]
En junio de 1978, se inició el trabajo de revisión de COBOL-74. El estándar propuesto (comúnmente llamado COBOL-80) difería significativamente del anterior, lo que generó preocupaciones sobre incompatibilidad y costos de conversión. En enero de 1981, Joseph T. Brophy, vicepresidente senior de seguros para viajeros, amenazó con demandar al comité estándar 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 "no productivas" y un "completo desperdicio de nuestros recursos de programación". [89] 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 eran "impuestas al usuario". [90] [91]
Durante el primer período de revisión pública, el comité recibió 2.200 respuestas, de las cuales 1.700 fueron cartas negativas. [92] Otras respuestas fueron análisis detallados del efecto que COBOL-80 tendría en sus sistemas; Se predijo que los costos de conversión serían de al menos 50 centavos por línea de código. Menos de una docena de respuestas estuvieron a favor de la norma propuesta. [93]
ISO TC97-SC5 instaló en 1979 el grupo internacional de expertos 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 el entendimiento mutuo y el respeto entre ANSI y el resto del mundo con respecto a la necesidad de nuevas características 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 hizo la mayoría de las propuestas.
En 1983, la DPMA retiró su oposición a la norma, citando la capacidad de respuesta del comité a las preocupaciones del público. Ese mismo año, un estudio de la Oficina Nacional de Normas concluyó que la norma propuesta presentaría pocos problemas. [91] [94] 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 EVALUATE
declaración y en línea PERFORM
fueron particularmente bien recibidas y mejoraron la productividad, gracias al flujo de control y la depuración simplificados . [95]
La segunda revisión pública obtuvo otras 1.000 respuestas (en su mayoría negativas), mientras que la última obtuvo sólo 25, momento en el que se habían abordado muchas preocupaciones. [91]
En 1985, el Grupo de Trabajo 4 de ISO aceptó la versión entonces del estándar propuesto por ANSI, realizó varios cambios y lo estableció como el nuevo estándar ISO COBOL 85. Se publicó a finales de 1985.
Se cambiaron o desaprobaron sesenta características y se agregaron 115 [96] , como por ejemplo: [97] [98]
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 en sus valores predeterminadosPERFORM
: anteriormente, los cuerpos de bucle tenían que especificarse en un procedimiento separadoLa nueva norma fue adoptada por todos los organismos nacionales de normalización, incluido ANSI. [79]
Siguieron dos enmiendas en 1989 y 1993. La primera enmienda introdujo funciones intrínsecas y la otra proporcionó correcciones. [79]
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 comerciales. [c] [99]
A principios de la década de 1990, se comenzó a trabajar para agregar orientación a objetos en la siguiente revisión completa de COBOL. Las funciones orientadas a objetos se tomaron de C++ y Smalltalk . [2] [3]
La estimación inicial era completar esta revisión en 1997, y un borrador (CD) del Comité ISO estaba disponible en 1997. 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 fue aprobada y publicada a finales de 2002. [100]
Fujitsu/GTSoftware, [101] 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 CODASYL COBOL Journal of Development desde 1978 y habían perdido la oportunidad de ser incluidas en COBOL-85. [102] Estas otras características incluyeron: [103] [104]
SCREEN SECTION
para interfaces de usuario basadas en texto.VALIDATE
instalaciónSe publicaron tres corrigenda de la norma: dos en 2006 y uno en 2009. [105]
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. [105]
COBOL 2002 sufrió de un soporte deficiente: ningún compilador admitió completamente el estándar. Micro Focus descubrió que se debía a la falta de demanda de los usuarios por las nuevas funciones y a la abolición del conjunto de pruebas NIST , que se había utilizado para probar la conformidad del compilador. También se consideró que el proceso de normalización era lento y carecía de recursos suficientes. [106]
COBOL 2014 incluye los siguientes cambios: [107]
VALIDATE
función, el redactor de informes y la función de manejo de pantalla.El estándar COBOL 2023 agregó algunas características nuevas:
SEND
y [109]RECEIVE
COMMIT
con y ROLLBACK
[109]XOR
operador lógico [109]CONTINUE
declaración se puede ampliar para pausar el programa durante un período específico [110]DELETE FILE
declaración [110]LINE SEQUENTIAL
organización de archivos [111]PERFORM UNTIL EXIT
[110]SUBSTITUTE
función intrínseca que permite la sustitución de subcadenas de diferente longitud [110]CONVERT
función para conversión de bases [110]Hasta el momento no se conoce una implementación completa de esta norma. [ cita necesaria ]
Los programas COBOL se utilizan globalmente 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 los negocios 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. [113]
Cerca del final 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 nivel particular de esfuerzo requerido para corregir el código COBOL se ha atribuido a la gran cantidad de COBOL orientado a los negocios, ya que las aplicaciones comerciales usan mucho las fechas, y a campos de datos de longitud fija. [114] Algunos estudios atribuyen hasta "el 24% de los costos de reparación de software del año 2000 a Cobol". [115] Después del esfuerzo de limpieza realizado en estos programas para el año 2000, una encuesta de 2003 encontró que muchos seguían en uso. [116] 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". [117]
En 2006 y 2012, las encuestas de Computerworld (a 352 lectores) encontraron 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. [9] [118] El 36% de los gerentes dijeron que planeaban migrar desde COBOL, y el 25% dijeron 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 más rápido. [9]
Un testimonio ante la Cámara de Representantes en 2016 indicó que muchas agencias federales todavía utilizan COBOL. [119] Reuters informó en 2017 que el 43% de los sistemas bancarios todavía usaban COBOL con más de 220 mil millones de líneas de código COBOL en uso. [120]
Para 2019, el número de programadores COBOL se estaba reduciendo rápidamente debido a las jubilaciones, lo que provocó una inminente brecha de habilidades en las organizaciones empresariales y gubernamentales que todavía utilizan sistemas mainframe para el procesamiento de transacciones de gran volumen. Los esfuerzos para reescribir sistemas en lenguajes más nuevos han resultado costosos y problemáticos, al igual que la subcontratación del mantenimiento del código, por lo que se recomiendan propuestas para capacitar a más personas en COBOL. [121]
Durante la pandemia de COVID-19 y el consiguiente aumento del desempleo, varios estados de EE. UU. informaron de una escasez de programadores COBOL capacitados para respaldar los sistemas heredados utilizados para la gestión de prestaciones 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 quedó en suspenso. [122] 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 del Coronavirus . [123]
COBOL tiene una sintaxis similar al inglés, que se utiliza para describir casi todo lo que hay en un programa. Por ejemplo, una condición se puede expresar de forma más concisa como o . Las condiciones más complejas se pueden abreviar eliminando condiciones y variables repetidas. Por ejemplo, se puede acortar a . Para admitir esta sintaxis, COBOL tiene más de 300 palabras clave . [124] [d] Algunas de las palabras clave son grafías alternativas simples o 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, al igual que y , y y .x IS GREATER THAN y
x GREATER y
x > y
a > b AND a > c OR a = d
a > b AND c OR = d
IN
OF
TIME
TIMES
VALUE
VALUES
Cada programa COBOL se compone de cuatro elementos léxicos básicos : palabras, literales, cadenas de caracteres de imágenes (consulte la cláusula PICTURE) y separadores. Las palabras incluyen palabras reservadas e identificadores definidos por el usuario. Tienen hasta 31 caracteres y pueden incluir letras, dígitos, guiones y guiones bajos. Los literales incluyen números (p. ej. 12
) y cadenas (p. ej. 'Hello!'
). [126] Los separadores incluyen el carácter de espacio y comas y punto y coma seguidos de un espacio. [127]
Un programa COBOL se divide en cuatro divisiones: la división de identificación, la división de entorno, la división de datos y la división de procedimientos. La división de identificación especifica el nombre y 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 juegos de caracteres . La división de datos se utiliza para declarar variables y parámetros . La división de procedimientos contiene las declaraciones del programa . Cada división se subdivide en secciones, que se componen de párrafos.
La sintaxis de COBOL generalmente se describe con un metalenguaje único que utiliza llaves, corchetes, barras y subrayado. El metalenguaje fue desarrollado para las especificaciones COBOL originales. Aunque la forma Backus-Naur existía en ese momento, el comité no había oído hablar de ella. [128]
Como ejemplo, considere la siguiente descripción de una ADD
declaración:
Esta descripción permite las siguientes variantes:
SUMA 1 A x SUMA 1 , a , b A x REDONDEADO , y , z REDONDEADO AÑADIR a , b A c EN PANTALLA DE ERROR DE TAMAÑO "Error" FINAL-AÑADIR AÑADIR a A b NO PANTALLA DE ERROR DE TAMAÑO "Sin error" PANTALLA DE ERROR DE TAMAÑO "Error"
El apogeo de la popularidad de COBOL coincidió con la era de las máquinas perforadoras de llaves y las tarjetas perforadas . El programa en sí se escribía en tarjetas perforadas, luego se leía y compilaba, y los datos introducidos en el programa a veces también estaban en tarjetas. [129]
COBOL se puede escribir en dos formatos: fijo (el predeterminado) o gratuito. En formato fijo, el código debe estar alineado para caber 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. [130]
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 mediante *>
, 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 >>PAGE
directiva reemplaza al /
indicador. [130]
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. [131] La herencia y las interfaces proporcionan polimorfismo . El soporte para la programación genérica se proporciona a través de clases parametrizadas, de las que se pueden crear instancias para utilizar cualquier clase o interfaz. Los objetos se almacenan como referencias que pueden estar restringidas a un tipo determinado. Hay dos formas de llamar a un método: la INVOKE
declaración, que actúa de manera similar a CALL
, o mediante la invocación de un método en línea, que es análogo al uso de funciones. [132]
*> Estos son equivalentes. INVOCAR mi clase "foo" REGRESANDO var MOVER mi clase :: "foo" A var *> Invocación de método en línea
COBOL no proporciona una forma de ocultar métodos. Sin embargo, los datos de clase se pueden ocultar declarándolos sin una PROPERTY
cláusula, lo que deja al código externo sin posibilidad de acceder a ellos. [133] La sobrecarga de métodos se agregó en COBOL 2014. [134]
La división de entorno contiene la sección de configuración y la sección de entrada-salida. La sección de configuración se utiliza para especificar características variables como signos de moneda, configuraciones regionales y juegos de caracteres. La sección de entrada y salida contiene información relacionada con archivos.
COBOL admite tres formatos de archivos u organizaciones : secuencial, indexado y relativo. En archivos secuenciales, los registros son contiguos y deben recorrerse secuencialmente , de manera similar a una lista vinculada . Los archivos indexados tienen uno o más índices que permiten acceder a los registros de forma aleatoria y ordenarlos. 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, al igual que 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 crear 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 secuencial y aleatorio. [135]
Una extensión no estándar común es la organización secuencial de líneas , utilizada para procesar archivos de texto. Los registros de un archivo terminan con una nueva línea y pueden tener diferente longitud. [136]
La división de datos se divide en seis secciones que declaran diferentes elementos: la sección de expediente, para registros de expedientes; 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 vinculación, 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 artículo con un número de nivel superior está subordinado a un artículo 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 lo hacen se llaman elementos elementales . Los números de nivel utilizados para describir elementos de datos estándar están entre 1 y 49. [137] [138]
01 algún récord . *> Registro de grupo agregado ítem 05 num PIC 9(10) . *> Elemento elemental 05 la fecha . *> Registro de (sub)grupo agregado elemento 10 del año PIC 9(4) . *> Elemento elemental 10 PIC 99 del mes . *> Elemento elemental 10 del día PIC 99 . *> Elemento elemental
En el ejemplo anterior, el elemento elemental num
y el elemento de grupo the-date
están subordinados al registro some-record
, mientras que los elementos elementales the-year
, the-month
y the-day
son parte del elemento de grupo the-date
.
Los elementos subordinados se pueden eliminar de la ambigüedad 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 del año PIC 9(4) . 05 PIC 99 del mes . 05 el día PIC 99 .
Los nombres the-year
, the-month
y the-day
son ambiguos por sí mismos, ya que más de un elemento de datos está definido con esos nombres. Para especificar un elemento de datos en particular, por ejemplo uno de los elementos contenidos dentro del sale-date
grupo, 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 número de nivel de 66 para declarar una reagrupación de elementos previamente definidos, independientemente de cómo estén estructurados esos elementos. Este nivel de datos, al que también se hace referencia en la RENAMES
cláusula asociada , rara vez se utiliza [139] y, alrededor de 1988, se encontraba habitualmente en programas antiguos. Su capacidad para ignorar los datos de la estructura jerárquica y lógica hizo que no se recomendara su uso y muchas instalaciones prohibieron su uso. [140]
01 registro-cliente . 05 PIC X(10) con clave personalizada . 05 nombre-cliente . 10 nombre del cliente PIC X(30) . 10 apellido del cliente PIC X(30) . 05 PIC 9(8) . 05 saldo de cliente PIC 9(7)V99 . 66 detalles-personales del cliente RENOMBRA el nombre del cliente A TRAVÉS del domicilio del cliente . 66 detalles-todos-clientes RENOMBRA el nombre-cliente A TRAVÉS del-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-name
y sales-region
, que son elementos de datos que no son de grupo y que son independientes (no están subordinados a) ningún otro elemento de datos:
77 nombre de propiedad PIC X(80) . 77 región de ventas PIC 9(5) .
Un número de nivel 88 declara un nombre de condición (el llamado nivel 88) que es verdadero cuando su elemento de datos principal contiene uno de los valores especificados en su VALUE
cláusula. [141] Por ejemplo, el siguiente código define dos elementos de nombre de condición de 88 niveles que son verdaderos o falsos según el valor de datos de carácter actual del wage-type
elemento de datos. Cuando el elemento de datos contiene un valor de 'H'
, el nombre de la condición wage-is-hourly
es verdadero, mientras que cuando contiene un valor de 'S'
o 'Y'
, el nombre de la condición wage-is-yearly
es verdadero. Si el elemento de datos contiene algún otro valor, ambos nombres de condición son falsos.
01 CC-nómina PIC X . 88 salario por hora VALOR "H" . 88 el salario es anual VALOR "S" , "Y" .
COBOL estándar proporciona los siguientes tipos de datos: [142]
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 datos numéricos y de grupo. [143] Por el contrario, las referencias a objetos y los punteros solo pueden asignarse a partir de elementos del mismo tipo y sus valores pueden restringirse a un determinado tipo. [144]
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 9
indica un dígito decimal y an S
indica que el elemento está firmado . 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 colocar 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 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 sólo caracteres de dígito ( 9
) y signo ( S
) definen elementos de datos puramente numéricos , mientras que las especificaciones de imagen que contienen caracteres alfabéticos ( A
) o alfanuméricos ( ) definen elementos de datos alfanuméricos . La presencia de otros caracteres de formato define elementos de datos numéricos o alfanuméricos editados . [145]X
La USAGE
cláusula declara el formato en el que se almacenan los datos. Dependiendo del tipo de datos, puede complementar o usarse en lugar de una PICTURE
cláusula. Si bien se puede utilizar para declarar punteros y referencias de objetos, está principalmente orientado a especificar tipos numéricos. Estos formatos numéricos son: [146]
PICTURE
cláusula o por una USAGE
clá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 cadenaUSAGE NATIONAL
, donde los datos se almacenan como una cadena usando un juego 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 redactor de informes es una función declarativa para crear informes. El programador sólo necesita especificar el diseño del informe y los datos necesarios para producirlo, lo que le libera de tener que escribir código para manejar aspectos como saltos de página, formato de datos y encabezados y pies de página. [147]
Los informes están asociados con archivos de informes, que son archivos en los que solo se puede escribir a través de declaraciones del redactor del informe.
Informe 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 títulos, bases y detalles del informe. Los informes solucionan las interrupciones del control jerárquico . Las rupturas de control ocurren cuando una variable clave cambia su valor; por ejemplo, al crear un informe que detalla los pedidos de los clientes, podría producirse una interrupción del control cuando el programa llegue a los pedidos de un cliente diferente. A continuación se muestra una descripción de informe de ejemplo para un informe que proporciona las ventas de un vendedor y que advierte sobre registros no válidos:
RD informe-de-ventas LÍMITES DE PÁGINA 60 LÍNEAS PRIMER DETALLE 3 CONTROLES nombre-vendedor . 01 TIPO ENCABEZADO DE PÁGINA . 03 VALOR COL 1 "Reporte de Ventas" . 03 COL 74 VALOR "Página" . 03 COL 79 PIC Z9 FUENTE CONTADOR DE PÁGINAS . 01 DETALLE DE TIPO de ventas en el día , LÍNEA + 1 . 03 COL 3 VALOR "Rebajas en" . 03 COL 12 PIC 99/99/9999 FUENTE fecha-venta . 03 COL 21 VALOR "eran" . 03 COL 26 PIC $$$$9.99 FUENTE monto-ventas . 01 ventas no válidas TIPO DETALLE , LÍNEA + 1 . 03 VALOR COL 3 "REGISTRO NO VÁLIDO:" . 03 COL 19 PIC X(34) FUENTE registro de ventas . 01 TIPO DE ENCABEZADO DE CONTROL nombre-vendedor , LÍNEA + 2 . 03 COL 1 VALOR "Vendedor:" . 03 COL 9 PIC X(30) FUENTE nombre-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 $1000.00 Las ventas el 12/12/2008 fueron $0.00 Las ventas el 13/12/2008 fueron $31.47 REGISTRO NO VÁLIDO: Howard Bromberg XXXXYYVendedor: descuento de Howard...Informe de ventas Página 12 Las ventas el 05/08/2014 fueron $543.98 REGISTRO NO VÁLIDO: William Selden 12O52014FOOFOO Las ventas el 30/05/2014 fueron $0.00
Cuatro declaraciones controlan al redactor del informe: INITIATE
, que prepara al redactor del informe para su 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 INICIAR informe- ventas REALIZAR HASTA 1 <> 1 LEER ventas AL FINAL SALIR REALIZAR FINAL LEER VALIDAR registro -ventas SI registro -válido GENERAR ventas-el-día OTRA GENERAR ventas-inválidas END-IF END -PERFORMAR TERMINAR informe de ventas CERRAR ventas , informe .
El uso de la función Report Writer tiende a variar considerablemente; algunas organizaciones lo utilizan ampliamente y otras no lo utilizan en absoluto. [148] Además, las implementaciones de Report Writer variaron en calidad, y las del extremo inferior a veces usaban cantidades excesivas de memoria en tiempo de ejecución. [148]
Las secciones y párrafos de la división de procedimientos (llamados colectivamente procedimientos) se pueden utilizar como etiquetas y como subrutinas simples . A diferencia de otras divisiones, los párrafos no necesitan estar en secciones. [149]
La ejecución pasa por los procedimientos de un programa hasta que finaliza. [150]
Para utilizar procedimientos como subrutinas, PERFORM
se utiliza el verbo.
Una PERFORM
declaración se parece un poco a una llamada a un procedimiento en lenguajes más nuevos en el sentido de que la ejecución regresa al código que sigue a la PERFORM
declaración al final del código llamado; sin embargo, no proporciona un mecanismo para pasar parámetros o devolver un valor de resultado. Si se invoca una subrutina usando una declaración simple como , entonces el control regresa al final del procedimiento llamado. Sin embargo, es inusual porque puede usarse para llamar a un rango que abarca una secuencia de varios procedimientos adyacentes. Esto se hace con la construcción:PERFORM subroutine
PERFORM
PERFORM sub-1 THRU sub-n
PROCEDIMIENTO fulano de tal . REALIZAR ALPHA REALIZAR ALPHA A TRAVÉS DE GAMMA DETENER EJECUTAR . ALFA . PANTALLA 'A' . BETA . PANTALLA 'B' . GAMA . PANTALLA 'C' .
El resultado de este programa será: "AAB C".
PERFORM
También se diferencia de las llamadas a procedimientos convencionales en que, al menos tradicionalmente, no existe la noción de pila de llamadas. Como consecuencia, las invocaciones anidadas son posibles (una secuencia de código que se PERFORM
ejecuta puede ejecutar una PERFORM
declaración por sí misma), pero requieren cuidado adicional si ambas invocaciones ejecutan partes del mismo código. El problema surge cuando el código de 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 PERFORM
invocación que se llamó anteriormente pero que aún no se ha completado, el estándar COBOL 2002 estipula que el comportamiento no está definido .
La razón es que COBOL, en lugar de una "dirección de remitente", opera con lo que podría denominarse 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 siguiente procedimiento en el texto del programa, de modo que, si no se PERFORM
realizan declaraciones, el control fluye de arriba a abajo a través del programa. Pero cuando se PERFORM
ejecuta una declaración, modifica la dirección de continuación del procedimiento llamado (o el último procedimiento del rango llamado, si PERFORM THRU
se usó), de modo que el control regresará al sitio de llamada al final. El valor original se guarda y se restaura posteriormente, pero solo hay una posición de almacenamiento. Si dos invocaciones anidadas operan en código superpuesto, pueden interferir en la gestión mutua de la dirección de continuación de varias maneras. [151] [152]
El siguiente ejemplo (tomado de Veerman y Verhoeven 2006) ilustra el problema:
ETIQUETA1 . MOSTRAR '1' REALIZAR LA ETIQUETA 2 A TRAVÉS DE LA ETIQUETA 3 DETENER EJECUTAR . ETIQUETA2 . MOSTRAR '2' REALIZAR ETIQUETA3 A TRAVÉS DE ETIQUETA4 . ETIQUETA3 . PANTALLA '3' . ETIQUETA4 . PANTALLA '4' .
Se podría esperar que el resultado de este programa fuera "1 2 3 4 3": después de mostrar "2", el segundo PERFORM
hace 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. Más bien, la primera PERFORM
declaración establece la dirección de continuación al final de LABEL3
para que salte de regreso al sitio de llamada dentro de LABEL1
. La segunda PERFORM
declaración establece el retorno al final de LABEL4
pero 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
, vuelve a la PERFORM
declaración externa y el programa deja de imprimir solo "1 2 3". Por otro lado, en algunas implementaciones COBOL como el compilador TinyCOBOL de código abierto, las dos PERFORM
declaraciones no interfieren entre sí y el resultado es "1 2 3 4 3". Por lo tanto, el comportamiento en tales casos no sólo es (quizás) sorprendente, sino que tampoco es portátil. [152]
Una consecuencia especial de esta limitación es que PERFORM
no se puede utilizar para escribir código recursivo. Otro ejemplo sencillo para ilustrar esto (ligeramente simplificado de Veerman y Verhoeven 2006):
MOVER 1 A UNA ETIQUETA REALIZAR DETENER EJECUTAR . ETIQUETA . MOSTRAR A SI A < 3 AGREGAR 1 A UNA ETIQUETA DE REALIZACIÓN FINAL-SI MOSTRAR 'FIN' .
Se podría esperar que el resultado 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 volver a DISPLAY 'END'
. [152]
COBOL 2014 tiene 47 declaraciones (también llamadas verbos ), [153] que se pueden agrupar en las siguientes categorías amplias: flujo de control, E/S, manipulación de datos y redactor de informes. Las declaraciones del redactor del informe se tratan en la sección del redactor del informe.
Las declaraciones condicionales de COBOL son IF
y EVALUATE
. EVALUATE
es una declaración similar a un interruptor con la capacidad adicional de evaluar múltiples valores y condiciones. Esto se puede utilizar para implementar tablas de decisiones . Por ejemplo, se podría utilizar lo siguiente para controlar un torno CNC :
EVALUAR VERDADERO TAMBIÉN la velocidad deseada TAMBIÉN la velocidad actual CUANDO la tapa está cerrada TAMBIÉN la velocidad mínima A TRAVÉS de la velocidad máxima TAMBIÉN MENOS DE LA velocidad deseada REALIZAR la aceleración de la máquina CUANDO la tapa está cerrada TAMBIÉN la velocidad mínima A TRAVÉS de la velocidad máxima TAMBIÉN MAYOR QUE la deseada -velocidad REALIZAR desaceleración-máquina CUANDO se abre la tapa TAMBIÉN CUALQUIER TAMBIÉN NO CERO REALIZAR parada de emergencia CUANDO OTRA CONTINÚE FINALIZAR-EVALUAR
La PERFORM
declaración se utiliza para definir bucles que se ejecutan hasta que una condición sea verdadera (no mientras sea verdadera, que es más común en otros lenguajes). También se utiliza para llamar a procedimientos o rangos de procedimientos (consulte la sección de procedimientos para obtener más detalles). CALL
y INVOKE
llamar 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. [154] 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). [155]CANCEL
descarga subprogramas de la memoria. GO TO
hace que el programa salte a un procedimiento específico.
La GOBACK
declaración es una declaración de devolución y la STOP
declaración detiene el programa. La EXIT
declaración tiene seis formatos diferentes: se puede utilizar como declaración de retorno, declaración de interrupción , declaración de continuación , marcador de finalización o para salir de un procedimiento. [156]
Las excepciones se generan mediante una RAISE
declaración y se detectan con un controlador, o declarativo , definido en la DECLARATIVES
parte de la división de procedimientos. Los declarativos son secciones que comienzan con una USE
declaración que especifica los errores a manejar. Las excepciones pueden ser nombres u objetos. RESUME
se usa 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 detectadas no pueden finalizar el programa y el programa puede continuar sin verse afectado.
La E/S de archivos es manejada por las declaraciones autodescriptivas OPEN
, CLOSE
, READ
y WRITE
junto con otras tres: REWRITE
, que actualiza un registro; START
, que selecciona registros posteriores a los que acceder buscando 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 ACCEPT
y 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 nombres similares .SET
, que cuenta con 15 formatos: puede modificar índices, asignar referencias de objetos y alterar capacidades de tablas, entre otras funciones. [157]ADD
, SUBTRACT
, MULTIPLY
, DIVIDE
y COMPUTE
, que manejan aritmética (con COMPUTE
la asignación del resultado de una fórmula a una variable).ALLOCATE
y FREE
, que manejan la memoria dinámica .VALIDATE
, que valida y distribuye datos según lo especificado en la descripción de un elemento en la división de datos.STRING
y 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 cumpla una condición.Los archivos y tablas se ordenan usando SORT
y el MERGE
verbo fusiona y ordena archivos. El RELEASE
verbo proporciona registros para ordenar y RETURN
recupera registros ordenados en orden.
Algunas declaraciones, como IF
y READ
, pueden contener declaraciones. Dichas declaraciones pueden terminarse de dos maneras: mediante un punto ( terminación implícita ), que termina todas las declaraciones no terminadas contenidas, o mediante un terminador de alcance, que termina la declaración abierta coincidente más cercana.
*> Período de terminación ("terminación implícita") IF registro-inválido SI no hay más registros SIGUIENTE ORACIÓN MÁS LEER archivo de registro AL FINAL ESTABLECER no más registros EN VERDADERO . *> Terminadores de alcance ("terminación explícita") IF registro-inválido IF no más registros CONTINUAR DE LO CONTRARIO LEER archivo de registro AL FINAL ESTABLECER no más registros TO TRUE END-LEER END-IF END-IF
Las declaraciones anidadas terminadas con un punto son una fuente común de errores. [158] [159] Por ejemplo, examine el siguiente código:
SI x PANTALLA y . PANTALLA z .
Aquí, la intención es mostrar y
si z
la condición x
es verdadera. Sin embargo, z
se mostrará cualquiera que sea el valor de x
porque la IF
declaración finaliza con un punto erróneo después de .DISPLAY y
Otro error es el resultado del problema del else colgante , cuando dos IF
declaraciones pueden asociarse con un archivo ELSE
.
SI x SI y MOSTRAR a ELSE MOSTRAR b .
En el fragmento anterior, se ELSE
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 alcance explícitos, para evitarlos sería necesario colocarlos después del interno . [159]IF y
IF x
ELSE NEXT SENTENCE
IF
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 ejecutada después de dicha declaración significa en su lugar. Muchos compiladores todavía lo admiten, [160] pero se consideró obsoleto en el estándar COBOL 1985 y se eliminó en 2002. [161]ALTER X TO PROCEED TO Y
X
Y
GO TO
X
ALTER
GO TO Y
La ALTER
declaración fue mal vista porque socavaba la "localidad del contexto" y hacía difícil comprender la lógica general del programa. [162] Como escribió el autor del libro de texto Daniel D. McCracken en 1976, cuando "alguien que nunca antes ha visto el programa debe familiarizarse con él lo más rápido posible, a veces bajo una presión de tiempo crítica porque el programa ha fallado... la vista de una declaración GO TO en un párrafo por sí sola, que indica 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". [162]
Un "¡Hola mundo!" programa en COBOL:
DIVISIÓN DE IDENTIFICACIÓN . ID DE PROGRAMA . Hola Mundo . DIVISIÓN DE PROCEDIMIENTO . PANTALLA "¡Hola mundo!" .
Cuando el ahora famoso "¡Hola mundo!" El ejemplo de programa 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 usando un lector de tarjetas perforadas y tarjetas perforadas de 80 columnas. La siguiente lista, con una DIVISIÓN DE DATOS vacía , se probó usando Linux y el emulador System/370 Hercules ejecutando MVS 3.8J. El JCL, escrito en julio de 2015, se deriva de los tutoriales y muestras de Hercules alojados por Jay Moseley. [163] De acuerdo con la programación COBOL de esa época, HOLA, MUNDO se muestra en letras mayúsculas.
// TRABAJO COBUCLG ( 001 ), 'PRUEBA BASE COBOL' , 00010000 // CLASE = A , MSGCLASS = A , MSGLEVEL = ( 1 , 1 ) 00020000 // BASETEST EXEC COBUCLG 00030000 // COB . SYSIN DD * 00040000 00000 * VALIDACIÓN DE INSTALACIÓN BASE COBOL 00050000 01000 DIVISIÓN IDENTIFICACIÓN . 00060000 01100 ID DE PROGRAMA . 'HOLA' . 00070000 02000 DIVISIÓN MEDIO AMBIENTE . 00080000 02100 SECCIÓN DE CONFIGURACIÓN . 00090000 02110 FUENTE-COMPUTADORA . GNULINUX . 00100000 02120 OBJETO-COMPUTADORA . HÉRCULES . 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 EJECUTAR . 00180000 // LKED . SYSLIB DD NOMBREDS = 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 DEL LECTOR1 19.52.48 TRABAJO 3 MENSAJE(S) DE ADVERTENCIA IEF677I PARA EL TRABAJO COBUCLG EMITIDO 19.52.48 TRABAJO 3 $HASP373 COBUCLG INICIADO - INIT 1 - CLASE A - SYS BSP1 19.52.48 FALTA LA DECLARACIÓN DD SYSPUNCH DEL TRABAJO 3 IEC130I 19.52.48 FALTA LA DECLARACIÓN DD SYSLIB DEL TRABAJO 3 IEC130I 19.52.48 FALTA LA DECLARACIÓN DD SYSPUNCH DEL TRABAJO 3 IEC130I 19.52.48 TRABAJO 3 IEFACTRT - Código de repetición del programa Procstep de nombre de paso 19.52.48 TRABAJO 3 COBUCLG PRUEBA BASE COB IKFCBL00 RC= 0000 19.52.48 TRABAJO 3 COBUCLG BASETEST LKED IEWL RC= 0000 19.52.48 TRABAJO 3 +HOLA MUNDO 19.52.48 TRABAJO 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000 19.52.48 TRABAJO 3 $HASP395 COBUCLG TERMINADO
La 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 .
El listado del compilador asociado generó más de cuatro páginas de detalles técnicos e información de ejecución de trabajos, para una sola 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 generalizando cada vez más. Edsger Dijkstra , un destacado científico informático, escribió una carta al editor de Comunicaciones de la ACM , publicada en 1975, titulada "¿Cómo decimos verdades que podrían hacer daño?", en la que criticaba COBOL y varios otros lenguajes contemporáneos; señalando que "el uso de COBOL paraliza la mente". [164]
En un desacuerdo publicado con los comentarios de Dijkstra, el científico informático Howard E. Tompkins afirmó que el COBOL no estructurado tendía a ser "escrito por programadores que nunca habían tenido el beneficio de un COBOL estructurado bien enseñado", argumentando que el problema era principalmente de capacitación. [165]
Una de las causas del código espagueti fue la GO TO
declaración. GO TO
Sin embargo, los intentos de eliminar correos electrónicos del código COBOL dieron como resultado programas complicados y una calidad reducida del código. [166] GO TO
fueron reemplazados en gran medida por PERFORM
declaraciones y procedimientos, que promovieron la programación modular [166] y brindaron fácil acceso a potentes funciones de bucle. Sin embargo, PERFORM
solo se podía usar con procedimientos, por lo que los cuerpos de bucle no estaban ubicados donde se usaban, lo que hacía que los programas fueran más difíciles de entender. [167]
Los programas COBOL eran famosos por ser monolíticos y carecer de modularización. [168] El código COBOL sólo podía modularizarse mediante procedimientos, que resultaron inadecuados para sistemas grandes. Era imposible restringir el acceso a los datos, lo que significaba que un procedimiento podía acceder y modificar cualquier dato. Además, no había forma de pasar parámetros a un procedimiento, una omisión que Jean Sammet consideró como el mayor error del comité. [169]
Otra complicación surgió de la capacidad de seguir PERFORM THRU
una secuencia específica de procedimientos. Esto significaba que el control podía saltar y regresar de cualquier procedimiento, creando un flujo de control complicado y permitiendo al programador romper la regla de entrada única y salida única . [170]
Esta situación mejoró a medida que COBOL adoptó más funciones. COBOL-74 agregó subprogramas, brindando a los programadores la capacidad de controlar los datos a los que podía acceder cada parte del programa. Luego, COBOL-85 agregó subprogramas anidados, lo que permitió a los programadores ocultar subprogramas. [171] En 2002 se produjo 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 importante 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 maneras desconocidas. [172]
COBOL estaba destinado a ser un lenguaje "común" altamente portátil. Sin embargo, en 2001 se habían creado alrededor de 300 dialectos. [173] 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. [174]
COBOL-85 no era totalmente compatible con versiones anteriores y su desarrollo fue controvertido. Joseph T. Brophy, CIO de Travelers Insurance , encabezó un esfuerzo para informar a los usuarios de COBOL sobre los altos costos de reprogramación que implica la implementación del nuevo estándar. [175] Como resultado, el Comité ANSI COBOL recibió más de 2.200 cartas del público, en su mayoría negativas, exigiendo al comité que hiciera cambios. Por otro lado, se pensaba que la conversión a COBOL-85 aumentaría la productividad en años futuros, justificando así los costos de conversión. [176]
Un lenguaje débil, prolijo y flojo utilizado por los programadores de códigos para hacer cosas aburridas y sin sentido en computadoras centrales tipo dinosaurio. [...] Su mismo nombre rara vez se pronuncia sin expresiones rituales de disgusto u horror.
El archivo de jerga 4.4.8. [177]
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. [178] COBOL también estaba destinado a ser fácil de aprender y usar para los programadores, [179] y al mismo tiempo ser legible para el personal no técnico, como los gerentes. [180] [181] [182] [183]
El deseo de legibilidad llevó al uso de sintaxis y elementos estructurales similares al inglés, como sustantivos, verbos, cláusulas, oraciones, secciones y divisiones. Sin embargo, en 1984, los mantenedores de programas COBOL estaban luchando para lidiar con código "incomprensible" [182] y los principales cambios en COBOL-85 estaban ahí para ayudar a facilitar el mantenimiento. [92]
Jean Sammet, miembro del comité de corto alcance, señaló que "se hizo poco intento por atender al programador profesional; de hecho, las personas cuyo interés principal es la programación tienden a estar muy descontentas con COBOL", lo que atribuyó a la sintaxis detallada de COBOL. [184]
La comunidad COBOL siempre ha estado aislada de la comunidad informática. Ningún informático académico participó en el diseño de COBOL: todos los miembros del comité procedían del comercio o del gobierno. Los 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. [185] 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 el desdén por el procesamiento de datos comerciales. [186] 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é no conocía. Esto resultó en críticas "severas". [187] [188] [69]
El mundo académico tiende a considerar a COBOL como prolijo, torpe y poco elegante, y trata de ignorarlo, aunque probablemente haya más programas y programadores de COBOL en el mundo que los de FORTRAN, ALGOL y PL/I combinados. En su mayor parte, sólo las escuelas con un objetivo vocacional inmediato brindan instrucción en COBOL.
Richard Conway y David Gries , 1973 [189]
Posteriormente, COBOL sufrió escasez de material que lo cubriera; Hubo que esperar hasta 1963 para que aparecieran libros introductorios (y Richard D. Irwin publicó un libro de texto universitario sobre COBOL en 1966). [190] En 1985, había el doble de libros sobre FORTRAN y cuatro veces más sobre BASIC que sobre COBOL en la Biblioteca del Congreso . [128] Los profesores universitarios enseñaron 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 vocacional". [191] Donald Nelson, presidente del comité CODASYL COBOL, dijo en 1984 que "los académicos... odian COBOL" y que a los graduados en ciencias de la computación "se les había inculcado el 'odio a COBOL'". [192]
A mediados de la década de 1980, también hubo una significativa condescendencia hacia COBOL en la comunidad empresarial por parte de usuarios de otros lenguajes, por ejemplo FORTRAN o ensamblador , implicando que COBOL sólo podía usarse para problemas no desafiantes. [193]
En 2003, COBOL figuraba en el 80% de los planes de estudio de sistemas de información en Estados Unidos, la misma proporción que C++ y Java . [194] Diez años más tarde, una encuesta realizada por Micro Focus encontró que el 20% de los académicos universitarios pensaban que COBOL estaba desactualizado o muerto y que el 55% creía que sus estudiantes pensaban que COBOL estaba desactualizado o muerto. La misma encuesta también encontró que sólo 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. [195]
Se han planteado dudas sobre la competencia del comité de normas. Howard Bromberg, miembro del comité a corto plazo, dijo que había "poco control" sobre el proceso de desarrollo y que estaba "plagado de discontinuidad de personal y... falta de talento". [80] Jean Sammet y Jerome Garfunkel también señalaron que los cambios introducidos en una revisión de la norma se revertirían en la siguiente, debido tanto a cambios en quién estaba en el comité de la norma como a evidencia objetiva. [196]
Los estándares COBOL han sufrido repetidamente retrasos: COBOL-85 llegó cinco años más tarde de lo esperado, [197] COBOL 2002 tuvo un retraso de cinco años, [2] y COBOL 2014 tuvo un retraso de seis años. [100] [198] Para combatir los retrasos, el comité estándar permitió la creación de adendas opcionales que agregarían características más rápidamente que esperando la próxima revisión estándar. Sin embargo, algunos miembros del comité expresaron su preocupación por las incompatibilidades entre implementaciones y modificaciones frecuentes del estándar. [199]
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 REDEFINES
cláusula fue una predecesora de los registros variantes de Pascal. Las definiciones explícitas de la estructura de archivos precedieron al desarrollo de los sistemas de gestión de bases de datos y los datos agregados supusieron un avance significativo con respecto a las matrices de Fortran. [128]
PICTURE
Las declaraciones de datos se incorporaron a PL/I, con cambios menores.
La instalación de COBOL COPY
, aunque se considera "primitiva", [200] influyó en el desarrollo de directivas de inclusión . [128]
El enfoque en la portabilidad y la estandarización significó que los programas escritos en COBOL pudieran ser portátiles y facilitó la difusión del lenguaje a una amplia variedad de plataformas de hardware y sistemas operativos. [201] Además, la estructura de división bien definida restringe la definición de referencias externas a la División de Medio Ambiente, lo que simplifica en particular los cambios de plataforma. [202]
El Comité de Corto Alcance 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 Alcance 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 (incluidas algunas sesiones las 24 horas del día) en noviembre de 1959 y enviamos las especificaciones propuestas al Comité de Corto Alcance en pleno, que las aceptó casi todas. Después de algunas ediciones (por las mismas seis personas), entregamos las especificaciones como informe final en diciembre al Comité Ejecutivo, que las aceptó en enero de 1960. Después de algunas ediciones adicionales, la Imprenta del Gobierno publicó Cobol 60. [.. .] [Grace Hopper] no participó en su trabajo excepto 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 afirmaciones de que "Grace Hopper desarrolló Cobol" o "Grace Hopper fue codesarrolladora 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 extendido alternativo o a ANSI COBOL es muy difícil, si es posible
(Grace Hopper) Apodada Grandma Cobol, el código se basó en algunos de sus trabajos anteriores.
Ella dijo que, después de escuchar los rumores, uno de sus colaboradores salió y compró una lápida de granito.
"Tenía la palabra COBOL cortada en el frente. Luego lo envió urgentemente por cobrar al Sr. Phillips en el Pentágono".
La broma a Charles Phillips, 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 informático más utilizado y más duradero de la historia.
Por lo tanto, el principal problema del año 2000 es el problema de los resultados incorrectos cuando se realizan cálculos de fechas.
Varias agencias, como el Departamento de Agricultura (USDA), el DHS, el HHS, la Justicia, el Tesoro y el VA, informaron que utilizaban el lenguaje común orientado a los negocios (COBOL), un lenguaje de programación desarrollado a finales de los años cincuenta y principios de los sesenta, para programar su legado. sistemas.
Es ampliamente conocido que las agencias necesitan pasar a lenguajes más modernos y fáciles de mantener, según sea apropiado y factible.
ALTER
La fecha más temprana en la que se podría 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 web}}
: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )(Enlace va al borrador N 0147){{cite book}}
: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace ){{cite book}}
: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )