COBOL- _COBOL

COBOL

El informe COBOL 60 a CODASYL (abril de 1960)
Paradigma	Procedural , imperativo , orientado a objetos , genérico
Diseñada por	Howard Bromberg , Norman Discount , Vernon Reeves , Jean E. Sammet , William Selden , Gertrude Tierney , con influencia indirecta de Grace Hopper
Desarrolladores	CODASYL , ANSI , ISO / IEC
Apareció por primera vez	1959 ; hace 64 años ( 1959 )
Liberación estable	ISO/CEI 1989:2023 / 2023
Disciplina de mecanografía	Débil , estático
Extensiones de nombre de archivo	.cbl, .cob,.cpy
Principales implementaciones
GnuCOBOL , IBM COBOL , Micro Focus Visual COBOL
Dialectos
COBOL/2, DEC COBOL-10, DEC PDP-11 COBOL, DEC PDP-11 COBOL-85, DEC VAX COBOL, DOSVS COBOL, Envyr ICOBOL, Fujitsu COBOL, Hitachi COBOL2002, HP3000 COBOL/II, IBM COBOL SAA, IBM COBOL /400, IBM COBOL/II, IBM Enterprise COBOL, IBM ILE COBOL, IBM OS/VS COBOL, ICL COBOL (VME), Micro Focus ACUCOBOL-GT, Micro Focus COBOL-IT, Micro Focus RM/COBOL, Micro Focus Visual COBOL , Microsoft COBOL, Raincode COBOL, Realia COBOL, Ryan McFarland RM/COBOL, Ryan McFarland RM/COBOL-85, Tandem (NonStop) COBOL, Tandem (NonStop) SCOBOL, UNIVAC COBOL, Unisys MCP COBOL74, Unisys MCP COBOL85, Unix COBOL X /Abierto, Veryant es COBOL, Wang VS COBOL
Influenciado por
Inicial: AIMACO , COMTRAN , FACT , FLOW-MATIC COBOL 2002: C++ , Eiffel , Smalltalk
Influenciado
CobolScript , EGL , PL/I , PL/B
COBOL en Wikilibros

COBOL ( / ˈ k oʊ b ɒ l , - b ɔː l / ; un acrónimo de "lenguaje común orientado a los negocios") es un lenguaje de programación informático similar al inglés compilado diseñado para uso comercial. 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 centrales , como trabajos de procesamiento de transacciones y lotes a gran escala . Sin embargo, debido a su popularidad decreciente y al retiro de los programadores COBOL experimentados, los programas se están migrando a nuevas plataformas, reescribiéndolos en lenguajes modernos o reemplazándolos con paquetes de software. La mayor parte de la programación en COBOL ahora es puramente para mantener las aplicaciones existentes; sin embargo, muchas instituciones financieras grandes todavía estaban desarrollando nuevos sistemas en COBOL hasta 2006.

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 fue visto como un recurso provisional, pero el Departamento de Defensa rápidamente obligó a los fabricantes de computadoras a proporcionarlo, lo que resultó en su adopción generalizada. Fue estandarizado en 1968 y desde entonces ha sido revisado cuatro veces. Las expansiones incluyen soporte para programación estructurada y orientada a objetos . El estándar actual es ISO / IEC 1989:2014 .

Las sentencias COBOL tienen una sintaxis parecida a la inglesa, que fue diseñada para ser autodocumentada y muy legible. Sin embargo, es detallado y utiliza más de 300 palabras reservadas . En contraste con la sintaxis moderna y sucinta como , COBOL tiene una sintaxis más parecida a la inglesa (en este caso, ). y = x;MOVE x TO y

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 comerciales cuando se creó COBOL y no participaron en su diseño; fue (efectivamente) diseñado desde cero como un lenguaje informático para negocios, con énfasis en entradas y salidas, cuyos únicos tipos de datos eran números y cadenas de texto.

COBOL ha sido criticado a lo largo de su vida por su verbosidad, proceso de diseño y soporte deficiente para la programación estructurada . Estas debilidades dan como resultado programas monolíticos y verbosos (que pretenden parecerse al inglés) que no son fácilmente comprensibles.

Durante años, COBOL se ha asumido como un lenguaje de programación para las operaciones comerciales en mainframes, aunque en los últimos años ha surgido un interés creciente por migrar las operaciones COBOL a la computación en la nube .

Historia y especificación

Fondo

A fines 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 de 1959 encontró que en cualquier instalación de procesamiento de datos, la programación costaba en promedio US$800.000 y que traducir programas para ejecutarlos en nuevo hardware costaría US$600.000. En un momento en que los nuevos lenguajes de programación proliferaban a un ritmo cada vez mayor, la misma encuesta sugirió que si se utilizara un lenguaje común orientado a los negocios, la conversión sería mucho más barata y rápida.

El 8 de abril de 1959, Mary K. Hawes , científica informática de Burroughs Corporation , convocó una reunión de representantes académicos, usuarios de computadoras y fabricantes en la Universidad de Pensilvania para organizar una reunión formal sobre lenguajes comerciales comunes. Los representantes incluyeron a Grace Hopper (inventora del lenguaje de procesamiento de datos similar al inglés FLOW-MATIC ), Jean Sammet y Saul Gorn .

En la reunión de abril, el grupo solicitó al Departamento de Defensa (DoD) que patrocinara un esfuerzo para crear un lenguaje empresarial común. La delegación impresionó a Charles A. Phillips, director del personal de investigación del sistema de datos del Departamento de Defensa, quien pensó que "entendía completamente" los problemas del Departamento de Defensa. El Departamento de Defensa operaba 225 computadoras, tenía 175 más ordenadas y había gastado más de $ 200 millones en la implementación de programas para ejecutarlas. Los programas portátiles ahorrarían tiempo, reducirían costos y facilitarían la modernización.

Charles Phillips acordó patrocinar la reunión y encargó a la delegación que redactara la agenda.

COBOL 60

Los días 28 y 29 de mayo de 1959 (exactamente un año después de la reunión Zürich ALGOL 58 ), se llevó a cabo una reunión en el Pentágono para discutir la creación de un lenguaje de programación común para los negocios. Asistieron 41 personas y estuvo presidido por Phillips. Al Departamento de Defensa le preocupaba 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.

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. Acordaron por unanimidad 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 del poder.

La reunión resultó en la creación de un comité directivo y comités de corto, mediano y largo alcance. Se le dio al comité de corto plazo hasta septiembre (tres meses) para producir especificaciones para un lenguaje provisional, que luego sería mejorado por los otros comités. Sin embargo, su misión oficial era identificar las fortalezas y debilidades de los lenguajes de programación existentes y no les ordenaba explícitamente que crearan un nuevo lenguaje.

La fecha límite fue cumplida con incredulidad por el comité de corto alcance. Un miembro, Betty Holberton , describió el plazo de tres meses como "gran optimismo" y dudó de que el lenguaje fuera realmente un recurso provisional.

El comité directivo se reunió el 4 de junio y acordó nombrar toda la actividad como el Comité de Lenguajes de Sistemas de Datos , o CODASYL , y formar un comité ejecutivo.

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 ., la cuenca modelo David Taylor de la Marina y la Oficina Nacional de Normas (ahora el Instituto Nacional de Normas y Tecnología). El comité estuvo presidido por Joseph Wegstein de la Oficina Nacional de Normas de EE.UU. El trabajo comenzó investigando la descripción de los datos, las declaraciones, las aplicaciones existentes y las experiencias de los usuarios.

El comité examinó principalmente los lenguajes de programación FLOW-MATIC , AIMACO y COMTRAN . El lenguaje FLOW-MATIC fue particularmente influyente porque se había implementado y porque AIMACO era un derivado de este con solo cambios menores. La inventora de FLOW-MATIC, Grace Hopper, también se desempeñó como asesora técnica del comité. 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 e instrucciones de datos.

A veces se hace referencia a Hopper como "la madre de COBOL" o "la abuela de COBOL", aunque Jean Sammet , diseñador principal de COBOL, afirmó que Hopper "no era la madre, creadora o desarrolladora de Cobol".

El lenguaje COMTRAN de IBM, inventado por Bob Bemer , fue considerado como un competidor de FLOW-MATIC por un comité de corto alcance formado por colegas de Grace Hopper. Algunas de sus funciones no se incorporaron a COBOL para que no pareciera que IBM había dominado el proceso de diseño, y Jean Sammet dijo en 1981 que había habido un "fuerte sesgo anti-IBM" por parte de algunos miembros del comité (incluida ella misma). 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 memorándum al comité de rango intermedio reiterando la recomendación de Sperry Rand. esfuerzos para crear un lenguaje basado en el inglés.

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 solo para "mantener felices a otras personas [para que] no intenten noquearnos".

Las características de COMTRAN incorporadas en COBOL incluyeron fórmulas, la PICTUREcláusulaIF , una declaración mejorada , que eliminó la necesidad de GO TO y un sistema de administración de archivos más sólido.

La utilidad del trabajo del comité fue tema de gran debate. Mientras que algunos miembros pensaron que el lenguaje tenía demasiados compromisos y fue 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.

Las características controvertidas incluían aquellas que algunos consideraban inútiles o demasiado avanzadas para los usuarios de procesamiento de datos. Tales características incluían expresiones booleanas , fórmulas y subíndices de tablas (índices). Otro punto de controversia fue si hacer que las palabras clave fueran sensibles al contexto y el efecto que tendría en la legibilidad. 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. Se prestó poca atención a la interactividad , la interacción con los sistemas operativos (pocos existían en ese momento) y las funciones (pensadas como puramente matemáticas). y de ninguna utilidad en el tratamiento de datos).

El pliego de condiciones se presentó al comité ejecutivo el 4 de septiembre. No cumplieron con las expectativas: Joseph Wegstein señaló que "contiene puntos ásperos y requiere algunas adiciones", y Bob Bemer los describió más tarde como una "mezcolanza". Al subcomité se le dio hasta diciembre para mejorarlo.

En una reunión a mediados de septiembre, el comité discutió el nombre del nuevo idioma. Las sugerencias incluyeron "BUSY" (Sistema comercial), "INFOSYL" (Lenguaje del sistema de información) y "COCOSYL" (Lenguaje común de sistemas informáticos). No está claro quién acuñó el nombre "COBOL", aunque Bob Bemer luego afirmó que había sido su sugerencia.

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 él.

Este fue un golpe para el comité de corto alcance, que había hecho un buen progreso en la especificación. A pesar de ser técnicamente superior, FACT no se creó pensando en la portabilidad o mediante el consenso del fabricante y el usuario. También carecía de una implementación demostrable, lo que permitió 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 una implementación de COBOL no se desperdiciara.

Pronto se hizo evidente que el comité era demasiado grande para avanzar rápidamente. Un frustrado Howard Bromberg compró una lápida de $15 con "COBOL" grabado y se la envió a Charles Phillips para demostrar su disgusto.

Se formó un subcomité para analizar los idiomas existentes y estuvo compuesto por seis personas:

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

El subcomité hizo la mayor parte del trabajo creando la especificación, dejando que el comité de corto alcance revisara y modificara su trabajo antes de producir la especificación final.

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 los programas portátiles y eficientes se escribieran fácilmente, permitir a los usuarios pasar a nuevos sistemas con un esfuerzo y costo mínimos, y ser adecuado para programadores sin experiencia.

Posteriormente, el Comité Ejecutivo de CODASYL creó el Comité de Mantenimiento de COBOL para responder a las preguntas de los usuarios y proveedores y para mejorar y ampliar las especificaciones.

Durante 1960, creció la lista de fabricantes que planeaban construir compiladores COBOL. 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 planearon integrar COBOL en sus propios lenguajes, GECOM y COMTRAN, respectivamente. En contraste, International Computers and Tabulators planeó reemplazar su lenguaje, CODEL, con COBOL.

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. El 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 se puede lograr la compatibilidad .

Las influencias relativas de qué lenguajes se usaron 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.

Ninguna garantía, expresa o implícita, se hace por cualquier contribuyente o por el Comité CODASYL COBOL en cuanto a la precisión y el funcionamiento del sistema de programación y el lenguaje. Además, ningún contribuyente ni el comité asumen ninguna responsabilidad en relación con esto. Los autores y titulares de los derechos de autor del material protegido por derechos de autor que se utiliza en este documento son los siguientes:

FLOW-MATIC (marca comercial de Unisys Corporation ), Programación para UNIVAC (R) I y II, Sistemas de automatización de datos, con derechos de autor de 1958, 1959, de Unisys Corporation; IBM Commercial Translator Form No. F28-8013, con derechos de autor de 1959 de IBM; HECHO, DSI 27A5260-2760, registrado en 1960 por Minneapolis-Honeywell.

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

COBOL-61 a COBOL-65

Se encontraron muchas fallas lógicas en COBOL 60 , lo que llevó a Charles Katz de General Electric a advertir que no se podía interpretar sin ambigüedades. Un comité reacio a corto plazo promulgó una limpieza total y, en marzo de 1963, se informó que la sintaxis de COBOL era tan definible como la de ALGOL , aunque permanecían las ambigüedades semánticas.

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 tipo implícitas y configuración necesaria. ups para operaciones de E/S. Los primeros compiladores de 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 de 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 extracto oscilaban entre $0,23 y $18,91.

A fines de 1962, IBM anunció que COBOL sería su principal lenguaje de desarrollo y que cesaría el desarrollo de COMTRAN.

La especificación COBOL se revisó tres veces en los cinco años posteriores a su publicación. COBOL-60 fue reemplazado en 1961 por COBOL-61. Luego, esto fue reemplazado por las especificaciones COBOL-61 Extended en 1963, que introdujeron las funciones de clasificación y redacción de informes. Las instalaciones adicionales corrigieron fallas identificadas por Honeywell a fines de 1959 en una carta al comité de corto alcance. COBOL Edition 1965 aportó más aclaraciones a las especificaciones e introdujo funciones para el manejo de tablas y archivos de almacenamiento masivo .

COBOL-68

Comenzaron los esfuerzos para estandarizar COBOL para superar las incompatibilidades entre versiones. A finales de 1962, tanto ISO como el Instituto de Normas de los Estados Unidos de América (ahora ANSI ) formaron grupos para crear normas. ANSI produjo USA Standard COBOL X3.23 en agosto de 1968, que se convirtió en la piedra angular para versiones posteriores. Esta versión se conocía como American National Standard (ANS) COBOL y fue adoptada por ISO en 1972.

COBOL-74

Para 1970, COBOL se había convertido en el lenguaje de programación más utilizado en el mundo.

Independientemente del comité de ANSI, el Comité de lenguaje de programación de 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 manejo de cadenas e inclusión de bibliotecas .

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

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 sabían de la existencia del comité. También carecía de los fondos para hacer que los documentos públicos, como las actas de las reuniones y las propuestas de cambio, estuvieran disponibles de forma gratuita.

En 1974, ANSI publicó una versión revisada de (ANS) COBOL, que contenía nuevas funciones, como organizaciones de archivos , la DELETEdeclaración y el módulo de segmentación . Las funciones 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 relativa). Estos conformaron 44 cambios, que hicieron que las declaraciones existentes fueran incompatibles con el nuevo estándar. El redactor de informes estaba programado para ser eliminado de COBOL, pero se restableció antes de que se publicara el estándar. Posteriormente, ISO adoptó la norma actualizada en 1978.

COBOL-85

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ó preocupaciones sobre la incompatibilidad y los costos de conversión. En enero de 1981, Joseph T. Brophy, vicepresidente sénior de Travelers Insurance, amenazó con demandar al comité estándar porque no era compatible con versiones posteriores de COBOL-74. El Sr. Brophy describió las conversiones anteriores de su base de código de 40 millones de líneas como "no productivas" y un "desperdicio completo de los recursos de nuestro programador". 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".

Durante el primer período de revisión pública, el comité recibió 2200 respuestas, de las cuales 1700 fueron cartas de formulario negativo. Otras respuestas fueron análisis detallados del efecto que tendría COBOL-80 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 de la norma propuesta.

ISO TC97-SC5 instaló en 1979 el Grupo de Expertos COBOL internacional, por iniciativa de Wim Ebbinkhuijsen . El grupo estaba formado por expertos en COBOL de muchos países, incluido Estados Unidos. Su objetivo era lograr la comprensión y el respeto mutuos entre ANSI y el resto del mundo con respecto a la necesidad de nuevas características de COBOL. Después de tres años, ISO cambió el estado 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 a la norma, 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 Normas concluyó que la norma propuesta presentaría pocos problemas. Un año después, DEC lanzó un VAX/VMS COBOL-80 y notó que la conversión de programas COBOL-74 planteaba pocos problemas. La nueva EVALUATEdeclaración y en línea PERFORMfueron particularmente bien recibidas y mejoraron la productividad, gracias al flujo de control simplificado y la depuración .

La segunda revisión pública atrajo otras 1000 respuestas (principalmente negativas), mientras que la última atrajo solo 25, momento en el cual se habían abordado muchas inquietudes.

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

Sesenta funciones se cambiaron o quedaron en desuso y se agregaron 115, como:

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

La nueva norma fue adoptada por todos los organismos nacionales de normalización, incluido ANSI.

Siguieron dos enmiendas en 1989 y 1993, la primera introduciendo funciones intrínsecas y la otra proporcionando correcciones.

COBOL 2002 y COBOL orientado a objetos

En 1997, Gartner Group estimó que existía un total de 200 mil millones de líneas de COBOL, que ejecutaban el 80% de todos los programas comerciales.

A principios de la década de 1990, se comenzó a trabajar para agregar la orientación a objetos en la siguiente revisión completa de COBOL. Las funciones orientadas a objetos se tomaron de C++ y Smalltalk .

La estimación inicial era tener esta revisión completada en 1997, y un Borrador del Comité ISO (CD) estaba disponible para 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 aprobada final fue aprobada y publicada a finales de 2002.

Fujitsu/GTSoftware, Micro Focus y RainCode introdujeron compiladores COBOL orientados a objetos dirigidos a .NET Framework .

Hubo 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. Estas otras características incluyen:

• código de forma libre
• Funciones definidas por el usuario
• recursividad
• Procesamiento basado en la configuración regional
• Soporte para juegos de caracteres extendidos como Unicode
• Tipos de datos binarios y de coma flotante (hasta entonces, los elementos binarios se truncaban en función de la especificación de base 10 de su declaración )
• Resultados aritméticos portátiles
• Tipos de datos de bits y booleanos
• Punteros y sintaxis para obtener y liberar almacenamiento
• para interfaces de usuario basadas enSCREEN SECTION texto
• la VALIDATEinstalación
• Interoperabilidad mejorada con otros lenguajes de programación y entornos de marco como .NET y Java .

Se publicaron tres correcciones para la norma: dos en 2006 y una en 2009.

COBOL 2014

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

COBOL 2002 sufría de un soporte deficiente: ningún compilador era completamente compatible con 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 encontró que el proceso de estandarización era lento y carecía de recursos.

COBOL 2014 incluye los siguientes cambios:

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

Legado

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, Gartner Group informó que el 80 % de los negocios del mundo se ejecutaban en COBOL con más de 200 000 millones de líneas de código y 5 000 millones de líneas más escritas anualmente.

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 los campos de datos de longitud fija. Algunos estudios atribuyen hasta "24% de los costos de reparación de software Y2K a Cobol". Después del esfuerzo de limpieza puesto en estos programas para Y2K, una encuesta de 2003 encontró que muchos seguían en uso. 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".

En 2006 y 2012, las encuestas de Computerworld (de 352 lectores) encontraron que más del 60 % de las organizaciones usaban COBOL (más que C++ y Visual Basic .NET ) y que la mitad de ellas usaba COBOL para la mayoría de su software interno. El 36 % de los gerentes dijo que planeaba migrar desde COBOL y el 25 % dijo que le gustaría hacerlo si fuera más barato. En cambio, algunas empresas han migrado sus sistemas de mainframes costosos a sistemas más modernos y económicos, mientras mantienen sus programas COBOL.

El testimonio ante la Cámara de Representantes en 2016 indicó que COBOL todavía está en uso por muchas agencias federales. Reuters informó en 2017 que el 43 % de los sistemas bancarios todavía usaban COBOL con más de 220 000 millones de líneas de código COBOL en uso.

Para 2019, la cantidad de programadores de 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 usan sistemas mainframe para el procesamiento de transacciones de gran volumen. Los esfuerzos para reescribir los 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.

Durante la pandemia de COVID-19 y el consiguiente aumento del desempleo, varios estados de EE. UU. informaron sobre la escasez de programadores COBOL calificados para respaldar los sistemas heredados que se utilizan para la administración de 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 quedó en suspenso. 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 .

Características

Sintaxis

COBOL tiene una sintaxis similar al inglés, que se usa para describir casi todo en un programa. Por ejemplo, una condición se puede expresar como   o de manera 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 similar a la inglesa, COBOL tiene más de 300 palabras clave . Algunas de las palabras clave son ortografías simples alternativas o pluralizadas de la misma palabra, lo que proporciona declaraciones y cláusulas más parecidas al inglés; por ejemplo, las palabras clave y se pueden usar indistintamente, al igual que and , and 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 (ver § 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!'). Los separadores incluyen el carácter de espacio y comas y puntos y comas seguidos de un espacio.

Un programa COBOL se divide en cuatro divisiones: la división de identificación, la división de entorno, la división de datos y la división de procedimientos. La división de identificación especifica el nombre y el tipo del elemento fuente y es donde se especifican las clases y las interfaces. La división de entorno especifica cualquier característica del programa que dependa 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 sentencias del programa . Cada división se subdivide en secciones, que se componen de párrafos.

Metalenguaje

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.

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

${\displaystyle {\begin{array}{l}{\underline {\text{AGREGAR}}}\,{\begin{Bmatrix}{\text{identificador-1}}\\{\text{literal-1} }\end{Bmatrix}}\dots \;{\underline {\text{TO}}}\,\left\{{\text{identificador-2}}\,\left[\,{\underline {\text {REDONDADO}}}\,\right]\right\}\dots \\\quad \left[\left|{\begin{array}{l}{\text{ON}}\,{\subrayado {\text {TAMAÑO}}}\,{\subrayado {\text{ERROR}}}\,{\text{declaración-imperativa-1}}\\{\subrayado {\text{NO}}}\,{\text{ ON}}\,{\subrayado {\text{TAMAÑO}}}\,{\subrayado {\text{ERROR}}}\,{\text{declaración-imperativa-2}}\\\end{matriz}} \right|\right]\\\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}$

Esta descripción permite las siguientes variantes:

ADD 1 TO x
ADD 1, a, b TO x ROUNDED, y, z ROUNDED

ADD a, b TO c
    ON SIZE ERROR
        DISPLAY "Error"
END-ADD

ADD a TO b
    NOT SIZE ERROR
        DISPLAY "No error"
    ON SIZE ERROR
        DISPLAY "Error"

Formato de código

Baraja de cartas perforadas del programa COBOL, de la década de 1970

El apogeo de la popularidad de COBOL coincidió con la era de las máquinas perforadoras y las tarjetas perforadas . El programa en sí se escribió en tarjetas perforadas, luego se leyó y compiló, y los datos introducidos en el programa a veces también estaban en tarjetas.

COBOL se puede escribir en dos formatos: fijo (el predeterminado) o gratuito. En formato fijo, el código debe alinearse 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.

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 pueden colocar en cualquier lugar y también se pueden utilizar en código fuente de formato fijo. Las líneas de continuación no están presentes y la >>PAGEdirectiva reemplaza el /indicador.

División de identificación

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

Programación orientada a objetos

Las clases y las 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. La herencia y las interfaces proporcionan polimorfismo . El soporte para la programación genérica se proporciona a través de clases parametrizadas, que se pueden instanciar para usar cualquier clase o interfaz. Los objetos se almacenan como referencias que pueden estar restringidas 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 a través de la invocación de métodos en línea, que es análoga al uso de funciones.

*> These are equivalent.
INVOKE my-class "foo" RETURNING var
MOVE my-class::"foo" TO var *> Inline method invocation

COBOL no proporciona 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 usuario sin forma de acceder a ellos. La sobrecarga de métodos se agregó en COBOL 2014.

división de medio ambiente

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 funciones variables, como signos de moneda, configuraciones regionales y juegos de caracteres. La sección de entrada y salida contiene información relacionada con el archivo.

archivos

COBOL admite tres formatos de archivo u organizaciones : secuencial, indexado y relativo. En los archivos secuenciales, los registros son contiguos y deben recorrerse secuencialmente , de forma 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 crear un registro con una clave de 5 puede requerir la creación de registros precedentes (vacíos). Los archivos relativos también permiten el acceso secuencial y aleatorio.

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

división de datos

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 .

Datos agregados

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 más alto está subordinado a un artículo con uno más bajo. 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 son se denominan elementos elementales . Los números de nivel utilizados para describir elementos de datos estándar están entre 1 y 49.

       01  some-record.                   *> Aggregate group record item
           05  num            PIC 9(10).  *> Elementary item
           05  the-date.                  *> Aggregate (sub)group record item
               10  the-year   PIC 9(4).   *> Elementary item
               10  the-month  PIC 99.     *> Elementary item
               10  the-day    PIC 99.     *> Elementary item

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-dayforman 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  sale-date.
           05  the-year       PIC 9(4).
           05  the-month      PIC 99.
           05  the-day        PIC 99.

Los nombres the-year, the-monthy the-dayson ambiguos por sí mismos, ya que con esos nombres se define más de un elemento de datos. 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 el 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.

Otros niveles de datos

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 RENAMEScláusula asociada , rara vez se usa y, alrededor de 1988, generalmente se encontraba en programas antiguos. Su capacidad para ignorar los datos de la estructura jerárquica y lógica hizo que su uso no fuera recomendado y muchas instalaciones prohibieran su uso.

       01  customer-record.
           05  cust-key            PIC X(10).
           05  cust-name.
               10  cust-first-name PIC X(30).
               10  cust-last-name  PIC X(30).
           05  cust-dob            PIC 9(8).
           05  cust-balance        PIC 9(7)V99.
           
       66  cust-personal-details   RENAMES cust-name THRU cust-dob.
       66  cust-all-details        RENAMES cust-name THRU cust-balance.

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 y , que son elementos de datos no property-namegrupales sales-regionque son independientes de (no están subordinados a) cualquier otro elemento de datos:

       77  property-name      PIC X(80).
       77  sales-region       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 VALUEcláusula. 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-typeelemento de datos. Cuando el elemento de datos contiene un valor de 'H', el nombre de la condición wage-is-hourlyes verdadero, mientras que cuando contiene un valor de 'S'o 'Y', el nombre de la condición wage-is-yearlyes verdadero. Si el elemento de datos contiene algún otro valor, ambos nombres de condición son falsos.

       01  wage-type          PIC X.
           88  wage-is-hourly VALUE "H".
           88  wage-is-yearly VALUE "S", "Y".

Tipos de datos

COBOL estándar proporciona los siguientes tipos de datos:

La seguridad de tipo 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. Por el contrario, las referencias a objetos y los punteros solo pueden asignarse desde elementos del mismo tipo y sus valores pueden estar restringidos a un determinado tipo.

Cláusula de IMAGEN

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 está firmado . Otros caracteres de imagen (llamados caracteres de inserción y edición ) especifican cómo debe formatearse un elemento. Por ejemplo, una serie de +caracteres define las posiciones de los caracteres, así como también cómo se colocará un carácter de signo principal 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 carácter 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 imágenes que contienen solo dígitos ( 9) y signos ( S) definen elementos de datos puramente numéricos , mientras que las especificaciones de imágenes 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 .X

Cláusula USO

La USAGEcláusula declara el formato en el que se almacenan los datos. Dependiendo del tipo de datos, puede complementar o usarse en lugar de una PICTUREcláusula. Si bien se puede usar para declarar punteros y referencias a objetos, está orientado principalmente a especificar tipos numéricos. Estos formatos numéricos son:

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

Redactor de informes

Report Writer es una instalación declarativa para crear informes. El programador solo necesita especificar el diseño del informe y los datos necesarios para producirlo, lo que lo libera de tener que escribir código para manejar cosas como saltos de página, formato de datos y encabezados y pies de página.

Los informes están asociados con archivos de informes, que son archivos en los que solo se pueden escribir a través de sentencias del autor de informes.

       FD  report-out REPORT sales-report.

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 y los detalles del informe. Los informes funcionan en torno a 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 ocurrir una ruptura de control cuando el programa llega a los pedidos de un cliente diferente. Aquí hay una descripción de informe de ejemplo para un informe que proporciona las ventas de un vendedor y que advierte sobre cualquier registro no válido:

       RD  sales-report
           PAGE LIMITS 60 LINES
           FIRST DETAIL 3
           CONTROLS seller-name.

       01  TYPE PAGE HEADING.
           03  COL 1                    VALUE "Sales Report".
           03  COL 74                   VALUE "Page".
           03  COL 79                   PIC Z9 SOURCE PAGE-COUNTER.

       01  sales-on-day TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "Sales on".
           03  COL 12                   PIC 99/99/9999 SOURCE sales-date.
           03  COL 21                   VALUE "were".
           03  COL 26                   PIC $$$$9.99 SOURCE sales-amount.

       01  invalid-sales TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "INVALID RECORD:".
           03  COL 19                   PIC X(34) SOURCE sales-record.

       01  TYPE CONTROL HEADING seller-name, LINE + 2.
           03  COL 1                    VALUE "Seller:".
           03  COL 9                    PIC X(30) SOURCE seller-name.

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

Sales Report                                                             Page  1

Seller: Howard Bromberg
  Sales on 10/12/2008 were $1000.00
  Sales on 12/12/2008 were    $0.00
  Sales on 13/12/2008 were   $31.47
  INVALID RECORD: Howard Bromberg             XXXXYY

Seller: Howard Discount
...
Sales Report                                                            Page 12

  Sales on 08/05/2014 were  $543.98
  INVALID RECORD: William Selden      12O52014FOOFOO
  Sales on 30/05/2014 were    $0.00

Cuatro sentencias controlan el autor del informe: INITIATE, que prepara al autor del informe 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 del informe de ventas anterior, la división de procedimientos podría verse así:

           OPEN INPUT sales, OUTPUT report-out
           INITIATE sales-report
 
           PERFORM UNTIL 1 <> 1
               READ sales
                   AT END
                       EXIT PERFORM
               END-READ
 
               VALIDATE sales-record
               IF valid-record
                   GENERATE sales-on-day
               ELSE
                   GENERATE invalid-sales
               END-IF
           END-PERFORM
 
           TERMINATE sales-report
           CLOSE sales, report-out
           .

El uso de la función Report Writer tiende a variar considerablemente; algunas organizaciones lo usan ampliamente y otras no lo usan en absoluto. Además, las implementaciones de Report Writer variaban en calidad, y las del extremo inferior a veces usaban cantidades excesivas de memoria en tiempo de ejecución.

División de procedimientos

Procedimientos

Las secciones y párrafos de la división de procedimientos (llamados colectivamente procedimientos) se pueden usar como etiquetas y como subrutinas simples . A diferencia de otras divisiones, los párrafos no necesitan estar en secciones.

La ejecución pasa por los procedimientos de un programa hasta que se termina. Para usar procedimientos como subrutinas, PERFORMse usa 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 vuelve 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 devolver un valor de resultado. Si se invoca una subrutina mediante una declaración simple como , 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 subroutinePERFORMPERFORM sub-1 THRU sub-n

PROCEDURE so-and-so.
    PERFORM ALPHA
    PERFORM ALPHA THRU GAMMA
    STOP RUN.
ALPHA.
    DISPLAY 'A'.
BETA.
    DISPLAY 'B'.
GAMMA.
    DISPLAY 'C'.

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

PERFORMtambién se diferencia de las llamadas a procedimientos convencionales en que, al menos tradicionalmente, no existe una noción de pila de llamadas. Como consecuencia, las invocaciones anidadas son posibles (una secuencia de código que se ejecuta PERFORMpuede ejecutar una PERFORMdeclaración en sí misma), pero requiere un cuidado especial si ambas invocaciones ejecutan partes del mismo código. El problema surge cuando el código de 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 ha completado, el estándar COBOL 2002 estipula que el comportamiento es indefinido .

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 se transfiere el control a esa dirección. Antes de que se ejecute el programa, la dirección de continuación de cada procedimiento se inicializa en la dirección de inicio del procedimiento que viene a continuación en el texto del programa, de modo que, si no ocurre ninguna PERFORMdeclaración, el control fluye de arriba hacia abajo a través del programa. Pero cuando se PERFORMejecuta una declaración, modifica la dirección de continuación del procedimiento llamado (o el último procedimiento del rango llamado, si PERFORM THRUse usó), de modo que el control regresará al sitio de la 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.

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

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

Uno podría esperar que la salida de este programa sea "1 2 3 4 3": después de mostrar "2", el segundo PERFORMhace que se muestren "3" y "4", y luego la primera invocación continúa con "3". . En las implementaciones tradicionales de COBOL, este no es el caso. Más bien, la primera PERFORMdeclaración establece la dirección de continuación al final de LABEL3para que vuelva al sitio de la llamada dentro de LABEL1. La segunda PERFORMinstrucció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 regreso a la PERFORMdeclaración externa y el programa deja de imprimir solo "1 2 3". Por otro lado, en algunas implementaciones de COBOL como el compilador TinyCOBOL de código abierto, las dos PERFORMdeclaraciones no interfieren entre sí y el resultado 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 portátil.

Una consecuencia especial de esta limitación es que PERFORMno se puede utilizar para escribir código recursivo. Otro ejemplo simple para ilustrar esto (ligeramente simplificado de Veerman & Verhoeven 2006 ):

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

Uno 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, mostrando "END" una y otra vez en un bucle sin fin. Dado que hay un espacio limitado para almacenar las direcciones de continuación de la copia de seguridad, las copias de seguridad se sobrescriben en el curso de las invocaciones recursivas y todo lo que se puede restaurar es volver a DISPLAY 'END'.

Declaraciones

COBOL 2014 tiene 47 declaraciones (también llamadas verbos ), que se pueden agrupar en las siguientes categorías amplias: flujo de control, E/S, manipulación de datos y escritor de informes. Las declaraciones del autor del informe se tratan en la sección del autor del informe .

Flujo de control

Las sentencias condicionales de COBOL son IFy EVALUATE. EVALUATEes 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 decisión . Por ejemplo, lo siguiente podría usarse para controlar un torno CNC :

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

La PERFORMdeclaración se usa 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 (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. Los parámetros se pueden pasar por referencia , por contenido (cuando se pasa una copia por referencia) o por valor (pero solo si hay un prototipo disponible). CANCELDescarga subprogramas de la memoria. GO TOhace que el programa salte a un procedimiento especificado.

La GOBACKdeclaración es una declaración de retorno y la STOPdeclaración detiene el programa. La EXITdeclaració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.

Las excepciones son provocadas por una RAISEdeclaración y capturadas con un controlador, o declarativo , definido en la DECLARATIVESparte de la división del procedimiento. Los declarativos son secciones que comienzan con una USEdeclaración que especifica los errores a manejar. Las excepciones pueden ser nombres u objetos. RESUMEse 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 pueden no terminar el programa y el programa puede continuar sin verse afectado.

E/S

La E/S de archivos es manejada por las declaraciones autodescriptivas OPEN, CLOSE, READy WRITEjunto con otras tres: REWRITE, que actualiza un registro; START, que selecciona registros posteriores para acceder al encontrar un registro con una determinada clave; y UNLOCK, que libera un bloqueo en el último registro al que se accedió.

La interacción del usuario se realiza mediante ACCEPTy DISPLAY.

Manipulación de datos

Los siguientes verbos manipulan datos:

• INITIALIZE, que establece los elementos de datos en sus valores predeterminados.
• MOVE, que asigna valores a los elementos de datos ; MOVE CORRESPONDING asigna los campos correspondientes con el mismo nombre .
• SET, que cuenta con 15 formatos: puede modificar índices, asignar referencias de objetos y alterar capacidades de tablas, entre otras funciones.
• ADD, SUBTRACT, MULTIPLY, DIVIDEy COMPUTE, que manejan la aritmética ( COMPUTEasignando el resultado de una fórmula a una variable).
• ALLOCATEy FREE, que manejan memoria dinámica .
• VALIDATE, que valida y distribuye datos como se especifica en la descripción de un elemento 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 cumpla una condición.

Los archivos y tablas se ordenan usando SORTy el MERGEverbo fusiona y ordena archivos. El RELEASEverbo proporciona registros para ordenar y RETURNrecupera registros ordenados en orden.

Terminación del alcance

Algunas sentencias, como IFy READ, pueden contener sentencias. Dichas sentencias pueden terminar de dos maneras: por un punto ( terminación implícita ), que termina todas las sentencias no terminadas contenidas, o por un terminador de alcance, que termina la sentencia abierta coincidente más cercana.

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

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

Las declaraciones anidadas que terminan con un punto son una fuente común de errores. Por ejemplo, examine el siguiente código:

IF x
    DISPLAY y.
    DISPLAY z.

Aquí, la intención es mostrar yy zsi la condición xes verdadera. Sin embargo, zse mostrará cualquiera que sea el valor de xporque la IFdeclaración finaliza con un punto erróneo después de . DISPLAY y

Otro error es el resultado del problema de else pendiente , cuando dos IFdeclaraciones pueden asociarse con un archivo ELSE.

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

En el fragmento anterior, los ELSEasociados con la     declaración en lugar de la     declaración, provocando un error. Antes de la introducción de terminadores de alcance explícitos, era necesario     colocarlos después del interior . IF yIF xELSE NEXT SENTENCEIF

Código auto modificable

La especificación COBOL original (1959) admitía la     declaración infame, para la cual muchos compiladores generaron código automodificable . y son etiquetas de procedimiento, y la     declaración única en el procedimiento ejecutado después de dicha declaración significa     en su lugar. Muchos compiladores aún lo admiten, pero se consideró obsoleto en el estándar COBOL 1985 y se eliminó en 2002. ALTER X TO PROCEED TO YXYGO TOXALTERGO TO Y

La ALTERdeclaración fue mal considerada porque socavaba la "localidad del contexto" y dificultaba la comprensión de la lógica general de un programa. Como escribió el autor de libros 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 un IR A declaración en un párrafo por sí misma, que señala 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".

Hola Mundo

Un programa " Hola, mundo " en COBOL:

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

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 utilizando un lector de tarjetas perforadas y tarjetas perforadas de 80 columnas. La siguiente lista, con una DIVISIÓN DE DATOS vacía , se probó con Linux y el emulador System/370 Hercules con MVS 3.8J. El JCL, escrito en julio de 2015, se deriva de los tutoriales y ejemplos de Hercules organizados por Jay Moseley. De acuerdo con la programación COBOL de esa época, HELLO, WORLD se muestra en 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* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

Después de enviar el JCL, la consola de MVS mostró:

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

La línea 10 de la lista anterior de la consola está resaltada para 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 sobre la ejecución del trabajo, para la única línea de salida de las 14 líneas de COBOL.

Recepción

falta de estructura

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 científico informático preeminente, escribió una carta al editor de Comunicaciones de la ACM , publicada en 1975 titulada "¿Cómo decimos verdades que podrían doler?", en la que criticaba COBOL y varios otros lenguajes contemporáneos; remarcando que "el uso de COBOL paraliza la mente".

En una disidencia publicada a los comentarios de Dijkstra, el científico informático Howard E. Tompkins afirmó que COBOL no estructurado tendía a ser "escrito por programadores que nunca habían tenido el beneficio de que COBOL estructurado se enseñara bien", argumentando que el problema era principalmente uno de entrenamiento.

Una de las causas del código espagueti fue la GO TOdeclaración. GO TOSin embargo, los intentos de eliminar correos electrónicos del código COBOL dieron como resultado programas complicados y una calidad de código reducida. GO TOLos s fueron reemplazados en gran medida por la PERFORMdeclaración y los procedimientos, que promovieron la programación modular y dieron fácil acceso a potentes funciones de bucle. Sin embargo, PERFORMsolo se podía usar con procedimientos, por lo que los cuerpos de bucle no se ubicaban donde se usaban, lo que dificultaba la comprensión de los programas.

Los programas COBOL eran famosos por ser monolíticos y carecer de modularización. El código COBOL solo podía modularizarse a través de procedimientos, que resultaron ser inadecuados para sistemas grandes. Era imposible restringir el acceso a los datos, lo que significaba que un procedimiento podía acceder y modificar cualquier elemento de datos. Además, no había manera de pasar parámetros a un procedimiento, una omisión que Jean Sammet consideró como el mayor error del comité.

Otra complicación provino de la capacidad de PERFORM THRUuna secuencia específica de procedimientos. Esto significaba que el control podía saltar y regresar de cualquier procedimiento, creando un flujo de control intrincado y permitiendo que un programador rompiera la regla de entrada única y salida única .

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. COBOL-85 luego agregó subprogramas anidados, lo que permitió a los programadores ocultar subprogramas. Un mayor control sobre los datos y el código llegó en 2002 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 ser demasiado arriesgado y costoso modificar incluso una simple sección de código, ya que puede usarse desde lugares desconocidos de formas desconocidas.

Problemas de compatibilidad

COBOL estaba destinado a ser un lenguaje "común" altamente portátil. Sin embargo, para 2001, se habían creado alrededor de 300 dialectos. Una fuente de dialectos era el propio estándar: el estándar de 1974 estaba compuesto por un núcleo obligatorio y once módulos funcionales, cada uno con dos o tres niveles de soporte. Esto permitió 104.976 variantes posibles.

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 sobre los altos costos de reprogramación de implementar el nuevo estándar. Como resultado, el comité ANSI COBOL recibió más de 2200 cartas del público, en su mayoría negativas, que solicitaban 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.

sintaxis detallada

La sintaxis de COBOL a menudo ha sido criticada por su verbosidad. Los defensores dicen que esto tenía la intención de hacer que el código se autodocumentara , facilitando el mantenimiento del programa. COBOL también estaba destinado a ser fácil de aprender y usar para los programadores, sin dejar de ser legible para el personal no técnico, como los gerentes.

El deseo de legibilidad condujo al uso de elementos estructurales y sintácticos similares al inglés, como sustantivos, verbos, cláusulas, oraciones, secciones y divisiones. Sin embargo, en 1984, los mantenedores de los programas COBOL luchaban por lidiar con el código "incomprensible" y los principales cambios en COBOL-85 estaban allí para ayudar a facilitar el mantenimiento.

Jean Sammet, miembro del comité de corto alcance, señaló que "se hizo un pequeño intento por atender al programador profesional, 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 detallada de COBOL.

Aislamiento de la comunidad informática.

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 el 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 comerciales de procesamiento de archivos que abordaba el desarrollo de COBOL. 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. La especificación COBOL usó 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".

Más tarde, COBOL sufrió una escasez de material que lo cubriera; los libros introductorios tardaron hasta 1963 en aparecer (con Richard D. Irwin publicando un libro de texto universitario sobre COBOL en 1966). 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 . 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 comercio". Donald Nelson, presidente del comité CODASYL COBOL, dijo en 1984 que "los académicos ... odian COBOL" y que los graduados en informática "tenían 'odio COBOL' en ellos".

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 implica que COBOL solo se puede usar para problemas que no sean desafiantes.

En 2003, COBOL figuraba en el 80 % de los planes de estudio de sistemas de información en los Estados Unidos, la misma proporción que C++ y Java . Diez años después, una encuesta de 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 solo el 25 % de los académicos tenían programación COBOL en su plan de estudios, aunque el 60 % pensó que deberían enseñarla.

Inquietudes sobre el proceso de diseño.

Se han planteado dudas sobre la competencia del comité de normas. El miembro del comité a corto plazo, Howard Bromberg, dijo que había "poco control" sobre el proceso de desarrollo y que estaba "plagado por la discontinuidad del personal y... la falta de talento". Jean Sammet y Jerome Garfunkel también señalaron que los cambios introducidos en una revisión del estándar se revertirían en la siguiente, debido tanto a los cambios en quién estaba en el comité del estándar como a la evidencia objetiva.

Los estándares COBOL han sufrido repetidamente retrasos: COBOL-85 llegó cinco años más tarde de lo esperado, COBOL 2002 llegó cinco años tarde y COBOL 2014 llegó seis años tarde. Para combatir los retrasos, el comité de estándares permitió la creación de apéndices opcionales que agregarían características más rápidamente que esperando la próxima revisión del estándar. Sin embargo, algunos miembros del comité expresaron su preocupación por las incompatibilidades entre las implementaciones y las frecuentes modificaciones del estándar.

Influencias en otros idiomas

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 administración de bases de datos y los datos agregados fueron un avance significativo con respecto a las matrices de Fortran.

PICTURElas declaraciones de datos se incorporaron a PL/I, con cambios menores.

La instalación de COBOL COPY, aunque se considera "primitiva", influyó en el desarrollo de directivas de inclusión .

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. 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 los cambios de plataforma en particular.

Ver también

• Lista alfabética de lenguajes de programación
• BLIS/COBOL
• CODASILO
• Comparación de lenguajes de programación
• Lista generacional de lenguajes de programación § Basado en COBOL
• Lista de compiladores § compiladores COBOL

notas

Referencias

Citas

Fuentes

enlaces externos

• COBOL en Curlie
• Estándar de lenguaje COBOL (1991; COBOL-85 con enmienda 1), de The Open Group