Continuación
No mezclar ambas convenciones dentro de la misma unidad de compilación.
8. Inicializar proceduralmente las tablas cuyos valores sean diferentes
Por qué
La inicialización procedural es portable entre compiladores COBOL-85 y evita depender de sintaxis específica de un proveedor.
En COBOL-85 estándar, no inicializar las diferentes ocurrencias de una tabla mediante una lista de valores dentro de una única cláusula
.
En lugar de hacer esto:
Código:
10 ITEM-PRICE
PIC 99V99 COMP
OCCURS 3 TIMES
VALUE 7,49 8,90 6,50.
Hacer esto:
Código:
INITIALIZE-MENU-PRICES SECTION.
MOVE 7,49 TO ITEM-PRICE (1)
MOVE 8,90 TO ITEM-PRICE (2)
MOVE 6,50 TO ITEM-PRICE (3)
EXIT.
9. Crear secciones de inicialización específicas
Por qué
Separar la inicialización de la lógica de negocio mejora la legibilidad, permite reutilizar el proceso y centraliza el mantenimiento.
La lógica de inicialización debe ubicarse en una sección con un nombre descriptivo:
Código:
INITIALIZE-MENU-PRICES SECTION.
No incluir grandes bloques de inicialización directamente dentro del flujo principal.
No mezclar responsabilidades de inicialización no relacionadas.
Cuando sea necesario, crear secciones independientes:
Código:
INITIALIZE-MENU-PRICES SECTION.
...
INITIALIZE-CUSTOMER-DATA SECTION.
...
INITIALIZE-FORM-CONTROLS SECTION.
...
Los puntos suspensivos representan el código real correspondiente a cada sección.
10. Ejecutar explícitamente la inicialización al comienzo del programa
Por qué
Una secuencia inicial explícita documenta el orden de inicialización y facilita la comprensión del flujo de ejecución.
La sección principal debe ejecutar las rutinas de inicialización mediante
antes de cualquier procesamiento que dependa de esos datos:
Código:
PROCEDURE DIVISION.
MAIN SECTION.
PERFORM INITIALIZE-APPLICATION-DATA
PERFORM EXECUTE-BUSINESS-LOGIC
EXIT PROGRAM.
11. Mantener concisa la sección MAIN
Por qué
La sección principal debe leerse como un plan de ejecución.
La orquestación de alto nivel resulta más fácil de comprender, revisar y mantener que una secuencia extensa de detalles de implementación.
En lugar de hacer esto:
Código:
MAIN SECTION.
MOVE ...
COMPUTE ...
IF ...
...
END-IF
MOVE ...
Hacer esto:
Código:
MAIN SECTION.
PERFORM INITIALIZE-MENU-PRICES
PERFORM LOAD-FORM
PERFORM PROCESS-USER-ACTIONS
PERFORM FINALIZE-PROGRAM
EXIT PROGRAM.
Mover la lógica detallada a secciones o párrafos con nombres descriptivos.
12. Utilizar las secciones de forma coherente
Por qué
Asignar una responsabilidad a cada sección produce código modular, más fácil de revisar, probar y refactorizar.
Ejemplo:
Código:
MAIN SECTION.
...
INITIALIZE-MENU-PRICES SECTION.
...
CALCULATE-ORDER-TOTAL SECTION.
...
UPDATE-FORM-CONTROLS SECTION.
...
FINALIZE-PROGRAM SECTION.
...
Cada sección debe tener una única finalidad claramente definida.
13. Utilizar RustCOBOL como lenguaje objetivo
Por qué
COBOL-85 proporciona la base semántica del lenguaje, mientras que las extensiones de RustCOBOL permiten reducir la verbosidad y expresar las soluciones de forma más clara.
Generar código para RustCOBOL.
Seguir la semántica y las convenciones fundamentales de ANSI COBOL-85, pero utilizar las extensiones de RustCOBOL cuando permitan:
- simplificar el código;
- reducir la verbosidad;
- mejorar la legibilidad;
- eliminar código repetitivo;
- expresar directamente capacidades de la interfaz gráfica o del runtime.
Las extensiones de RustCOBOL no son opcionales cuando proporcionan una implementación más clara y adecuada.
Aplicar además las siguientes reglas:
- utilizar sintaxis COBOL-85 como base;
- preferir frente a usos no estándar como , salvo que exista una necesidad explícita;
- evitar inicializaciones en línea incompatibles con COBOL-85;
- identificar claramente cualquier extensión relevante utilizada.
14. Validar el código generado
Por qué
Una revisión final permite detectar incoherencias estructurales antes de entregar el código.
Antes de devolver una implementación, comprobar:
- todos los registros de aplicación de nivel están declarados como ;
- no existen campos elementales con declarados innecesariamente en nivel ;
- los elementos relacionados están agrupados bajo registros significativos;
- los elementos repetidos utilizan cuando corresponde;
- se utiliza únicamente cuando existe una vista alternativa real;
- los campos numéricos editados no están duplicados innecesariamente;
- cada campo editado coincide con el tamaño, signo y precisión de su origen;
- el formato monetario contiene un obligatorio antes del separador decimal;
- las tablas con valores diferentes se inicializan proceduralmente;
- la inicialización se encuentra en una sección específica;
- la sección de inicialización se ejecuta mediante al comienzo de ;
- contiene principalmente la orquestación;
- la terminación del programa utiliza ;
- las extensiones de RustCOBOL se utilizan cuando mejoran la implementación;
- los ejemplos fueron adaptados al requisito real y no copiados literalmente.
Principio general de diseño
Generar la solución COBOL correcta más simple posible.
Preferir implementaciones con:
- menos elementos de datos;
- menos párrafos y secciones innecesarias;
- duplicación mínima;
- tablas y elementos editados reutilizables;
- agrupación lógica clara;
- flujo de inicialización explícito;
- alta legibilidad;
- extensiones de RustCOBOL cuando proporcionen una implementación más limpia.
Organización esperada del código
Utilizar la siguiente estructura como referencia, no como una plantilla fija.
WORKING-STORAGE SECTION del formulario
Código:
01 MC-APPLICATION-DATA GLOBAL.
*> BUSINESS GROUP A
05 BUSINESS-GROUP-A.
10 BUSINESS-VALUE
PIC 99V99 COMP
OCCURS 4 TIMES.
*> CALCULATION
05 CALCULATION-DATA.
10 TOTAL-AMOUNT
PIC 999V99 COMP
VALUE ZERO.
*> FORMATTING
05 FORMATTING-DATA.
*> Formats fields declared as PIC 99V99.
10 EDITED-SMALL-CURRENCY
PIC Z9,99.
*> Formats fields declared as PIC 999V99.
10 EDITED-TOTAL-CURRENCY
PIC ZZ9,99.
Event Handler
Código:
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
MAIN SECTION.
PERFORM INITIALIZE-APPLICATION-DATA
PERFORM EXECUTE-APPLICATION
EXIT PROGRAM.
INITIALIZE-APPLICATION-DATA SECTION.
MOVE value-1 TO BUSINESS-VALUE (1)
MOVE value-2 TO BUSINESS-VALUE (2)
MOVE value-3 TO BUSINESS-VALUE (3)
MOVE value-4 TO BUSINESS-VALUE (4)
EXIT.
EXECUTE-APPLICATION SECTION.
*> Application-specific processing.
EXIT.
Los nombres, valores, dimensiones de las tablas, secciones, formatos editados y flujo de la aplicación son únicamente ilustrativos.
Generar estructuras que reflejen el dominio y los requisitos reales, respetando estas convenciones.
[hr]
Árbol de decisiones
Al generar código COBOL, aplicar las siguientes decisiones:
Código:
Inicio
│
├── ¿Se trata de datos de la aplicación?
│ ├── Sí → Colocarlos bajo un registro 01 significativo.
│ │ Declarar el registro 01 como GLOBAL.
│ └── No → Mantenerlos en el ámbito apropiado.
│
├── ¿Varios campos comparten PICTURE, USAGE y finalidad?
│ ├── Sí → Utilizar OCCURS.
│ └── No → Declarar campos individuales.
│
├── ¿Dos estructuras representan vistas diferentes
│ del mismo almacenamiento?
│ ├── Sí → Utilizar REDEFINES.
│ └── No → No utilizar REDEFINES.
│
├── ¿El campo se utiliza solamente para presentación?
│ ├── Sí → Reutilizar un campo numérico editado.
│ └── No → Almacenar el valor de negocio una sola vez.
│
├── ¿Los campos numéricos tienen formatos diferentes?
│ ├── Sí → Crear un campo reutilizable por clase de formato.
│ └── No → Reutilizar el campo existente.
│
├── ¿Una tabla necesita valores iniciales diferentes?
│ ├── Sí → Crear una sección INITIALIZE-...
│ │ Inicializarla mediante MOVE.
│ └── No → No añadir inicialización innecesaria.
│
├── ¿MAIN SECTION contiene detalles de implementación?
│ ├── Sí → Moverlos a secciones específicas.
│ └── No → Mantener MAIN como orquestador.
│
└── Antes de devolver el código:
├── validar la estructura;
├── validar los formatos;
├── validar el uso de RustCOBOL;
├── validar la inicialización;
└── validar la nomenclatura.
Referencia rápida
Código:
Situación:
Campos homogéneos repetidos
Solución:
OCCURS
Situación:
Vistas diferentes del mismo almacenamiento
Solución:
REDEFINES
Situación:
Valor utilizado solamente para presentación
Solución:
Campo numérico editado reutilizable
Situación:
Formatos numéricos diferentes
Solución:
Un campo editado reutilizable por clase de formato
Situación:
Inicialización repetida
Solución:
INITIALIZE-... SECTION ejecutada mediante PERFORM
Situación:
MAIN SECTION demasiado extensa
Solución:
Mover la implementación a secciones específicas
Situación:
Varias responsabilidades no relacionadas
Solución:
Una sección por responsabilidad
Situación:
Estado compartido de la aplicación
Solución:
Registro 01 GLOBAL
Situación:
Nuevo grupo de datos de negocio
Solución:
Crear un registro 01 significativo; no declarar un campo
elemental con PIC directamente en nivel 01
Principios orientadores
Generar código COBOL que sea:
- modular en lugar de monolítico;
- orientado a datos en lugar de repetitivo;
- estructurado en lugar de improvisado;
- legible antes de ser optimizado;
- fácil de extender con cambios mínimos;
- basado en la semántica de ANSI COBOL-85;
- modernizado mediante las extensiones de RustCOBOL.
[hr]
El texto anterior todavía es demasiado extenso.
Lo ideal es dividirlo en unidades pequeñas e independientes que puedan consultarse individualmente durante el proceso de razonamiento del modelo.
Para ello, será necesario crear un
skill conciso que indique al modelo:
- cómo implementar cada tipo de solución;
- qué convenciones debe aplicar;
- dónde consultar las referencias detalladas;
- qué reglas tienen prioridad;
- cómo validar el código antes de devolverlo.
PowerRustCOBOL ya permite este tipo de consulta estructurada.
Todavía queda bastante trabajo de optimización, pero ya contamos con un buen punto de partida.