learn language desde cero language-design cobol

language design - language - ¿Por qué COBOL tiene tanto ''SECTION'' como ''PARAGRAPH''?



fortran language (8)

Aprendí COBOL alrededor de 1978, en una ICL 2903. Tengo una memoria vaga de que a los encabezados de SECCIÓN se les podría asignar un rango de números, lo que significa que esos encabezados de SECCIÓN podrían intercambiarse dentro y fuera de la memoria, cuando el programa era demasiado grande para la memoria .

¿Por qué COBOL tiene SECTION y PARAGRAPH ?

¿Alguien puede explicar por qué los diseñadores de COBOL crearon las SECTION y los PARAGRAPH ? Estos han existido desde el lanzamiento inicial de COBOL, así que sospecho que la verdadera razón de su existencia desapareció hace mucho tiempo (similar a NEXT SENTENCE que todavía se encuentra en la especificación del lenguaje para la compatibilidad con versiones anteriores, pero ya no es necesario desde la introducción de terminadores de alcance).

Mi conjetura es que se puede haber introducido a SECTION para admitir las superposiciones de programas. SECTION tiene un número de PRIORIDAD opcional asociado para identificar la superposición del programa del que forma parte. Sin embargo, la mayoría de las implementaciones modernas de COBOL ignoran o han eliminado los números de PRIORIDAD (y las superposiciones).

Actualmente, veo que las SECTION todavía son necesarias en la parte DECLARATIVE de la PROCEDURE DIVISION , pero no pueden encontrar una justificación para esto. No veo ninguna diferencia semántica entre SECTION y PARAGRAPH aparte de que PARAGRAPH está subordinado a SECTION .

Algunas tiendas COBOL prohíben el uso de SECTION a favor de PARAGRAPH (parece común en América del Norte). Otros prohíben PARAGRAPH a favor de la SECTION (parece común en Europa). Aún otros tienen pautas sobre cuándo cada una es apropiada. Todo esto me parece muy arbitrario, lo que plantea la pregunta: ¿por qué se pusieron en la especificación del lenguaje en primer lugar? Y, ¿tienen alguna relevancia hoy?

Si responde a esta pregunta, sería genial si también pudiera señalar una referencia para respaldar su respuesta.

Gracias


Bueno, la razón más simple es que las SECCIONES le proporcionan la "modularidad", al igual que las funciones en C, una necesidad en los programas "estructurados". Usted notaría que el código escrito usando SECCIONES parece mucho más legible que el código escrito solo en los párrafos, ya que cada sección debe tener una "SALIDA", un punto de salida único y muy explícito de una SECCIÓN (el punto de salida de una paragrpah está lejos más vago e implícito, es decir, hasta que se encuentre una nueva declaración de párrafo). Considere este ejemplo y puede sentirse tentado a usar secciones en su código:

*================== MAINLINE SECTION. *================== PERFORM SEC-A PERFORM SEC-B PERFORM SEC-C GOBACK. *================== MAINLINE-EXIT. *================== EXIT. *================== SEC-A SECTION. *================== ..... ..... ..... ..... IF <cond> go to A-EXIT end-if ..... ..... ..... ..... . *================== A-EXIT. *================== EXIT.

No piense que tendría este tipo de privilegio al escribir sus códigos en párrafos. Es posible que haya tenido que escribir una gran declaración ELSE para encubrir las declaraciones que no quiso ejecutar cuando se alcanza una determinada condición (considere que el conjunto de declaraciones se ejecutará en 2-3 páginas ... un conjunto adicional de SI / ELSE te calambre para la sangría). Por supuesto, tendrá que usar "IR A" para lograr esto, pero siempre puede dirigir a sus profesionales para que no usen GO TO, excepto cuando salga, lo cual es un trato justo, creo.

Así que, aunque también estoy de acuerdo en que cualquier cosa que pueda escribirse usando SECCIONES también puede escribirse usando párrafos (con pocos o ningún retoque), mi elección personal sería optar por una implementación que pueda facilitar un poco el trabajo de mis desarrolladores. ¡futuro!


Cobol fue desarrollado a mediados de los 50''s. Como alude el nombre completo, se desarrolló para la programación empresarial, ya que es un lenguaje más relevante para fines comerciales que los lenguajes "científicos" o "técnicos" existentes (de todos modos había muy pocos "lenguajes" y "código de máquina" ( , por supuesto, a una arquitectura particular (casi dije "chip específico", antes de pensar en los tubos de vacío)) que puede tener que configurarse a través de interruptores / diales físicos en algunas máquinas) y si tiene suerte con un "Ensamblador". Cobol fue muy avanzado para su día, para su propósito.

La intención era que los programas escritos en Cobol se parecieran mucho más al inglés que a un conjunto de "códigos" que significan algo para los iniciados.

Si observa alguna de las nomenclaturas relacionadas con el idioma (párrafo, oración, verbo, cláusula), está siguiendo deliberadamente los patrones atribuidos al idioma inglés.

SECCIÓN no encaja bien en esto, hasta que se relacionan las cosas con un documento comercial formal.

Tanto las SECCIONES como los párrafos también aparecen fuera de la DIVISIÓN DE PROCEDIMIENTOS. Al igual que en el inglés escrito, los párrafos pueden existir por sí solos o pueden ser parte de una SECCIÓN.

Las SECCIONES pueden tener un número de prioridad que se relaciona con la "característica de segmentación". Esto solía incluir la "superposición" de SECCIONES para proporcionar un nivel primitivo de administración de memoria. Esta es una "función informática" en lugar de una versión en inglés :-) La "característica de segmentación" tiene algo de un efecto restante, pero nunca lo he visto realmente usado.

Sin DECLARATIVAS (que no uso, y acabo de notar que el manual no está claro), entonces es "una elección" si se usan SECCIONES o párrafos para REALIZAR.

Si se usa GO TO, racionalmente, se puede lograr la "equivalencia" con PERFORM ... TRHU ... Si no, y no hay un uso gratuito de PERFORM ... THRU ..., entonces ya existe la equivalencia.

Las comparaciones con el código "estructurado" y los lenguajes modernos son "leer la historia al revés" o simplemente esbozar una "práctica" particular. Desde la reputación alcanzada por el "código de espagueti" y ALTERO ... PARA PROCEDER A ... puede ser que durante 20 años sea "común" no hacer mucho con PERFORM a menos que necesite la "administración de memoria", pero No tengo referencias ni conocimientos que respalden esto.

Las SECCIONES permiten nombres de párrafo duplicados, de lo contrario los nombres de párrafo deben ser únicos.

No puedo poner un dedo específico sobre uno sobre el otro todo el tiempo.

Si utilizara GO TO, usaría SECCIONES. Si no, párrafos. Con DECLARATIVOS usaría SECCIONES. Si utilizara SECCIONES, comenzaría la DIVISIÓN DE PROCEDIMIENTOS con una SECCIÓN para evitar un mensaje de diagnóstico.

Las normas locales pueden dictar, pero no necesariamente sobre una base "moderna" (o incluso "racional"). Mucho es "conocido", pero en realidad no se comprende bien sobre las SECCIONES y los párrafos, en mi experiencia.

Para el rendimiento (donde se procesan masas de datos, y me refiero a masas), un PERFORM de una SECCIÓN en lugar de varios párrafos individuales vería mejoras. El efecto sería el mismo que con PERFORM ... THRU ..., pero prefiero no recomendarlo. IR A Fuera del rango de un PERFORM es 1) malo 2) puede perder la "optimización". No debería ser un problema * excepto "cuando VAYA A cancelar / excepción y no esperar ningún retorno lógico. Si se considera que el uso de esto es necesariamente" inmediato ", entonces es mejor hacerlo con un PERFORM a pesar de la" contra-intuición ". "aspecto (así lo documenta).


No hay referencias sobre esto, ya que escuché que me lo transmitió uno de los temporizadores antiguos de mi tienda, pero ...

En los antiguos compiladores COBOL, al menos para IBM y Unisys, las secciones se podían cargar en la memoria de una en una. En los viejos tiempos, cuando la memoria escaseaba, un programa que era demasiado grande para cargarse en la memoria de una sola vez podía modularizarse para el uso de la memoria usando secciones. Tener secciones y párrafos permitieron al programador decidir qué partes de código se cargaron juntas en la memoria si no podían cargarse todas a la vez; querría que dos partes del mismo bucle de ejecución se cargaran juntas por razones de eficiencia. Hoy en día es más o menos discutible.

Mi tienda usa solo párrafos, prohíbe GOTO y requiere párrafos de salida, por lo que todos nuestros PERFORMES son PERFORMAR 100-PÁRRAFO A TRAVÉS DE 100-EXIT o algo similar, lo que parece hacer que los párrafos se parezcan más a las secciones para mí. Pero no creo que haya mucha diferencia ahora.


Por un lado, los nombres de los párrafos deben ser únicos a menos que estén en secciones separadas, por lo que las secciones permiten el "espacio de nombres" de los párrafos.

Si recuerdo correctamente, la única razón por la que debe usar una SECTION es para DECLARATIVES . Aparte de eso, son opcionales y principalmente útiles para agrupar párrafos. Creo que es común (en términos relativos, en cualquier caso) requerir que PERFORM se use en párrafos solo cuando están en la misma sección.


Sé que esta es una pregunta antigua, pero el OP solicitó información sobre la justificación original del uso de SECTION y PARAGRAPH en COBOL.

No puede obtener mucho más "original" que la documentación del Diario CODASYL.

en la sección 8 de la especificación de la revista para el idioma,

"La segmentación COBOL es una instalación que proporciona un medio por el cual el usuario puede comunicarse con el compilador para especificar los requisitos de superposición del programa objeto"

(página 331, sección 8.1 "Segmentación - Descripción general")

"Aunque no es obligatorio, la División de Procedimientos para un programa fuente generalmente se escribe como un grupo consecutivo de secciones, cada una de las cuales se compone de una serie de operaciones estrechamente relacionadas que están diseñadas para realizar colectivamente una función particular. Sin embargo, cuando la segmentación se utiliza, toda la División de Procedimientos debe estar en secciones. Además, cada sección debe clasificarse como perteneciente a la parte fija oa uno de los segmentos independientes del programa objeto. La segmentación de ninguna manera afecta la necesidad de la calificación del procedimiento -Nombres para asegurar la singularidad ".

(p 331, sección 8.1.2.1 "Segmentos de programa")

En su libro sobre lenguajes de programación comparativos ("Programming Languages: History and Fundamentals", 1969) Jean Sammet (quien formó parte del comité de CODASYL, representando a Sylvania Electric) afirma:

"... La asignación de almacenamiento es manejada automáticamente por el compilador. La unidad principal para asignar el código ejecutable es un grupo de secciones llamado segmento. El programador combina secciones especificando un número de prioridad con el nombre de cada sección. ... Se requiere el compilador para ver que se proporcionan las transferencias de control adecuadas para que pueda tener lugar el control entre segmentos que no se almacenan simultáneamente ... "

(p 369 - 371 V.3 COBOL)


Una sección puede tener varios párrafos en ella. Cuando realiza una sección, ejecuta todos los párrafos de la sección. Dentro de la sección puede usar PERFORM o GOTO para derivar a los párrafos dentro de la sección.


Utilizamos la codificación COBOL SECTION en todos nuestros programas COBOL por lotes de 37K MVS. Utilizamos esta técnica para obtener tiempos de ejecución mucho más rápidos y reducir significativamente la sobrecarga de la CPU. Esta técnica de codificación COBOL es muy similar al ensamblador por lotes de alto rendimiento.

Llámelo Programación COBOL Funcionalmente Estructurada de Alto Rendimiento.

Una vez que se define una SECCIÓN, todo PERFORM xxxxx regresará a la siguiente SECCIÓN codificada, no al siguiente párrafo de la SECCIÓN. Si los párrafos se codifican antes de la primera SECCIÓN, entonces se pueden ejecutar normalmente. (Pero no permitimos esto)

El uso de una SECCIÓN tiene una sobrecarga mayor que la de usar y REALIZAR solo párrafos, A MENOS QUE , se utiliza la lógica GOTO para omitir el código que debe ejecutarse de forma condicional. Nuestra regla es que un GOTO solo puede apuntar a una Tag-Line en la misma SECCIÓN. (un párrafo) Todos los párrafos de una SECCIÓN deben ser una subfunción de la función de la SECCIÓN. La instrucción EXIT es una instrucción NOP de ensamblador. Permite colocar una línea de identificación antes de la siguiente SECCIÓN: una salida / devolución rápida.

La ejecución de un PERFORM xxxx THRU yyyy tiene más sobrecarga de CPU que la ejecución de una SECCIÓN sin los GOTO .

ADVERTENCIA: la ejecución de una línea de etiquetado PERFORM xxxx en una SECCIÓN pasará por todo el código de la SECCIÓN hasta que se encuentre la siguiente SECCIÓN. Una Línea de Etiqueta GOTO fuera de la SECCIÓN actual pasará por todo el código en la nueva SECCIÓN de aterrizaje hasta que se encuentre la siguiente SECCIÓN. (Pero no permitimos esto)