Correcciones 1.62.0 a 1.62.129 (desde 1.61.185)

[Eslopes]

Tres correcciones, ninguna dentro del propio motor. Primera: RELATIVE data-name nombra el número de registro, con o sin la palabra KEY. La cláusula se escribe RELATIVE KEY IS RK, RELATIVE KEY RK y RELATIVE RK a secas, y solo las dos primeras se entendían. La tercera se leía como una cláusula de organización a secas, así que la clave se consumía y se descartaba en silencio — el fichero quedaba entonces sin número de registro alguno y cada WRITE aleatorio devolvía 24, una violación de límites sobre la ranura cero. Lo que distingue ambos casos es simplemente lo que sigue: una cláusula de organización está completa por sí sola, de modo que un data-name tras RELATIVE solo puede ser la clave. Esto cerró ocho programas de una vez.

Segunda: estado de fichero 14 — un número de registro relativo demasiado grande para su elemento de clave. La anchura de la PICTURE del elemento RELATIVE KEY forma parte del comportamiento del fichero, no solo de su almacenamiento: con una clave CUST-SLOT PIC 99, leer ese fichero secuencialmente funciona hasta el registro 99 y a partir de ahí no puede informar de dónde está. COBOL-85 tiene un estado exactamente para eso, y es una condición de clase at-end como 10, así que la frase AT END es la que lo maneja.

Tercera: una frase condicional sin terminar se detiene ahora en el ELSE que la engloba. Una frase escrita sin su terminador de ámbito —

           IF  WS-N < 201
                   WRITE REC-A
                   INVALID KEY GO TO BAD
           ELSE
                   WRITE REC-B
                   INVALID KEY GO TO BAD.

— leía de largo a través del ELSE, y el programa no llegaba a analizarse. El conjunto de parada propio de una frase no puede saber dentro de qué está anidada, así que la regla se aplica ahora una vez por cada cuerpo con ámbito: ELSE, END-IF, WHEN, END-EVALUATE, END-PERFORM y END-SEARCH cierran una construcción dentro de la cual el cuerpo puede estar anidado, y ninguna lista imperativa puede leer más allá de uno de ellos. Conformidad de compilación de la suite completa: de 422 a 423 de 434. Además, RL301M queda excluido de la puntuación de ejecución, la misma decisión que ya lleva IX301M: pide que una implementación de subconjunto alto señale ORGANIZATION IS RELATIVE, ACCESS MODE IS RANDOM, RELATIVE KEY IS y las frases NOT INVALID KEY como no conformes, y todas son características que PowerRustCOBOL soporta. Sigue contando en el censo de compilación, donde pasa.

=== PowerRustCOBOL 1.62.78 — 2026-08-29 ===
• Una coma separadora delante de un signo ya no se descarta, y dos programas que hacían caer el intérprete ahora se ejecutan.

IF (Conditional) pasa de 24 a 32 de 45 ejecutando limpio, de 702 a 776 aserciones pasando (87.4 % -> 91.9 %), sin caídas restantes en el módulo. Una coma seguida de espacio es un separador de COBOL-85: puede aparecer donde puede aparecer un espacio y significa exactamente lo que significa un espacio, así que el lexer la descartaba. Hay un lugar donde eso no es cierto. El estándar distingue un signo de un operador binario por el espacio que le sigue — A -3 son dos operandos, A - 3 es una resta —, de modo que descartar la coma de COMPUTE WS-NUM = FUNCTION MOD(A, -3). deja A -3, que se leía como una única resta. MOD se invocaba entonces con un solo argumento y el intérprete entraba en pánico al leer el segundo. La coma se conserva ahora cuando el token siguiente es un + o un -, lo que basta para que el parser distinga ambos casos sin enseñarle la regla de espaciado.

El punto y coma no conserva tal excepción. Nunca es un separador de listas, solo decoración, y ningún parser se come uno — MOVE ELEM3( +3; +5, +10) TO TEMP es una lista de subíndices que la suite escribe precisamente para demostrarlo. Aplicar la excepción a ambos signos de puntuación costó un programa que venía pasando, que es como se descubrió la distinción.

Post añadido a las 10:11. Post anterior a las 10:07

Una intrínseca invocada con menos argumentos de los debidos ahora se reporta en lugar de ser fatal. FUNCTION MOD needs 2 arguments, 1 given es algo sobre lo que un desarrollador puede actuar; un pánico por índice fuera de rango, no. Un programa COBOL nunca debe poder hacer caer el intérprete, diga lo que diga.

=== PowerRustCOBOL 1.62.79 — 2026-08-29 ===
• NUMVAL y NUMVAL-C leen las formas que COBOL-85 realmente permite, y las funciones intrínsecas se señalan como por encima del subconjunto alto.

IF (Conditional) pasa de 32 a 37 de 45 ejecutando limpio, de 776 a 824 aserciones pasando (91.9 % -> 97.7 %). NUMVAL: el argumento no es un literal float de Rust, y leerlo como tal devolvía cero para la mayor parte de lo que el estándar permite. El signo puede estar en cualquiera de los dos extremos y no tiene que tocar los dígitos; CR y DB son la grafía crédito-débito de un menos final; NUMVAL-C admite además una cadena de moneda y separadores de grupos de dígitos, y su segundo argumento opcional — la cadena de moneda a ignorar — no se leía en absoluto.

           COMPUTE WS-NUM = FUNCTION NUMVAL ("   -  4929.0323").
           COMPUTE WS-NUM = FUNCTION NUMVAL ("   200.0002   - ").
           COMPUTE WS-NUM = FUNCTION NUMVAL-C ("  $  90.54 -  ", "$").

Los tres devolvían cero antes. Sin segundo argumento, NUMVAL-C usa ahora el CURRENCY SIGN de SPECIAL-NAMES, y DECIMAL-POINT IS COMMA intercambia los papeles de . y , como lo hace en todas partes.

Las funciones intrínsecas están por encima del subconjunto alto de COBOL-85: llegaron con la adenda de 1989, así que un compilador que valida en el subconjunto alto reporta cada uso como no conforme — implemente o no la función. flag_high_subset no las cubría, y eso es todo lo que piden IF401M, IF402M e IF403M: 44 expectativas entre los tres, ahora todas coincidentes.

Con ello cayeron dos falsos positivos. La lista de argumentos de una función no es una lista de subíndices ni una fuente de operadores para una relación que la engloba, de modo que IF FUNCTION ORD-MAX (5, 3, 2, 8, 3, 1) = ... no son 6 subíndices e IF FUNCTION MEAN (5, -2, -14, 0) = ... no contiene aritmética — cada una atraía una segunda señalización errónea. Siete sentencias de IF402M estaban afectadas y el emparejamiento voraz del puntuador lo ocultaba: las señalizaciones espurias suplantaban a las de función intrínseca, así que los totales parecían correctos. Ambos detectores siguen disparándose sobre las construcciones genuinas, lo que ahora está cubierto por tests unitarios en ambas direcciones. Una intrínseca invocada con menos argumentos de los debidos se reporta en lugar de ser fatal — la guarda añadida en 1.62.78 cubre ahora también ANNUITY.

=== PowerRustCOBOL 1.62.80 — 2026-08-29 ===

Un cociente ya no pierde sus decimales frente a un divisor largo, y las funciones intrínsecas de lista de argumentos comparan como compara COBOL. IF (Conditional) pasa de 37 a 44 de 45 programas ejecutando limpio, 824 -> 841 aserciones superadas (97.7 % -> 99.9 %).

• Una división ya no pierde los decimales del cociente ante un divisor largo

Dar al cociente sus dígitos de guarda implica desplazar el dividendo, y ese desplazamiento tiene que caber en el entero de trabajo. Un divisor con muchos decimales lo agranda por sí solo — 1 / SQRT3, donde SQRT3 PIC S9V9(17), pide 43 dígitos — y la ruta de desbordamiento caía entonces a coma flotante a la escala del propio dividendo. El dividendo es el entero 1, así que 0.577 se redondeaba a un valor sin ninguna posición decimal y volvía como 1:

       01  SQRT3  PIC S9V9(17) VALUE 1.732050808.
...
           COMPUTE WS-NUM = FUNCTION ATAN(1 / SQRT3).

respondía atan(1): un cuarto de vuelta en lugar de un sexto. El cociente ahora descarta dígitos de guarda hasta que el desplazamiento cabe, lo que conserva la ruta entera exacta; solo una magnitud realmente enorme llega a coma flotante, y lo hace a la precisión de trabajo. Nada que antes cabía cambia: la búsqueda empieza en la precisión que la división siempre usó.

• MAX, MIN, ORD-MAX y ORD-MIN comparan como compara COBOL

Post añadido a las 10:13. Post anterior a las 10:11

Las cuatro leían todos sus argumentos como números en coma flotante, lo cual es erróneo por partida doble. Primero, el resultado de MAX/MIN es el propio argumento: cuando los argumentos son alfanuméricos la comparación se hace por la secuencia de intercalación y la respuesta es una cadena de caracteres — FUNCTION MAX("R", I, "I", "a") es "a" —, y leídos como flotantes los cuatro argumentos valían cero. Segundo, gana el primero de varios argumentos iguales: ORD-MAX y ORD-MIN devuelven una posición, así que los empates se ven — FUNCTION ORD-MAX(A, 5, 5, A) es 1 cuando A es el mayor, donde el código anterior respondía 4. La comparación ahora es cob_ordering, la misma ordenación que usan SORT y todas las relaciones.

• Se conserva una coma separadora delante de (

Por la misma razón que la que precede a un signo (1.62.78): quitarla de FUNCTION MAX(A * B, (C + 1) / 2, 3 + 4) deja B (C + 1), que es la sintaxis de una referencia con subíndice. Los dos primeros argumentos se fusionaban en uno y MAX devolvía 17.5 donde la respuesta es 35.

=== PowerRustCOBOL 1.62.81 — 2026-08-29 ===

• Un signo pegado a un literal es un signo, no un operador

El módulo Conditional queda terminado: 45 de 45 en ambos ejes, 841 aserciones, 0 fallos.

COBOL-85 distingue los dos casos por el espacio que sigue: un operador binario debe llevar espacio a ambos lados, de modo que 10.2 -0.2 son dos operandos y 10.2 - 0.2 es una resta. La suite escribe COMPUTE WS-NUM = FUNCTION RANGE(10.2 -0.2, 5.6, -15.6) sin ninguna coma entre los dos primeros argumentos, y espera cuatro: 25.8 es 10.2 menos -15.6. Leído como resta eran tres argumentos y 25.6.

La salvaguarda es deliberadamente más estrecha que la regla: solo se activa cuando el token anterior al signo es un literal numérico o un paréntesis de cierre. Un identificador delante no puede distinguirse de una palabra clave a nivel léxico, y PICTURE -9(9).9(9) y VARYING ... BY -1 son ambos "operando, hueco, signo pegado, dígitos" — ninguno es un lugar donde cambiar nada. Ampliarla es una decisión para la puerta de la suite completa, no una conjetura.

=== PowerRustCOBOL 1.62.82 — 2026-08-29 ===

• Un cambio del arnés NIST, sin ningún cambio del compilador ni del runtime detrás

El módulo Inter-program Communication trata de CALL, y sus programas llamados son miembros separados de la distribución: IC101A llama a IC102A, IC108A llama a IC109A, IC110A e IC111A. El arnés ejecutaba un fichero fuente cada vez, así que el llamante no tenía a quién llamar. La propia suite lo dice en sus tarjetas de control, con una palabra que el divisor no conocía: *HEADER,COBOL,IC101A,SUBRTN,IC102A.

SUBPRG y SUBRTN no son sinónimos, y la diferencia decide si un miembro es o no un test. SUBPRG nombra el siguiente programa del mismo grupo — cada uno es un test completo con su propio informe, e IX101A,SUBPRG,IX102A es exactamente la cadena que la tabla de productores ya describe. SUBRTN nombra un programa al que el test llama; los 24 están en IC y OBIC, y cada uno responde a un CALL literal. Confundir ambos le costó a SQ203A su puesto y llevó SQ de 85 de 85 a 84 de 84, que es como se descubrió la distinción.

Un llamante se ejecuta ahora con sus llamados concatenados en una sola unidad de ejecución, y un llamado ya no se puntúa como un test que no produjo informe. IC pasa de 6 a 10 de sus 25 tests ejecutando limpio, 134 -> 187 aserciones superadas (51.0 % -> 72.5 %). El censo de compilación no cambia: 423 de 434, porque un llamado es COBOL ordinario y ahí sigue contando. Nota: el denominador de ejecución de IC pasa de 47 a 25 con esta versión; los 47 contaban los 22 llamados como tests, que no tienen informe CCVS y, ejecutados en solitario, solo podían fallar. Las cifras comparables son 6 -> 10 de 25.

=== PowerRustCOBOL 1.62.83 — 2026-08-29 ===

• Segmentation sale del alcance NIST (decisión del operador)

SG se une a CM, RW, los tests de elementos obsoletos OB* y EXEC85 como módulo que RustCOBOL no mide.

Post añadido a las 10:14. Post anterior a las 10:13

La segmentación existe para encajar un programa en una máquina demasiado pequeña para contenerlo: las cabeceras SECTION llevan un número de segmento y el runtime superpone los segmentos independientes unos sobre otros. RustCOBOL es una solución de 64 bits sobre sistemas de 64 bits, con más espacio de direcciones del que ningún programa COBOL puede agotar — así que un número de segmento compila y no tiene ningún efecto. No hay comportamiento que el módulo pueda ejercitar, y puntuarlo sería puntuar un mecanismo que nunca existirá.

Sus 13 programas siguen compilando y se informan como N-A en lugar de eliminarse, de modo que la exclusión queda visible en el censo. La suite dentro de alcance es de 421 programas, no 434, y la conformidad de compilación pasa a leerse 410 de 421 (97.4 %) donde antes leía 423 de 434 (97.5 %).

=== PowerRustCOBOL 1.62.84 — 2026-08-29 ===

• CALL ... USING enlaza el almacenamiento del llamante, no una copia de él

Un parámetro BY REFERENCE es ahora un alias sobre su argumento, de modo que qué almacenamiento nombra un parámetro lo decide el argumento, no el nombre que el programa llamado le dé. Enlazar por nombre significaba que el parámetro del llamado era lo que el llamante tuviera bajo ese nombre: en CALL "IC202A" USING DN1, DN2, DN1, DN4 el tercer argumento es DN1; IC202A llama DN3 a su tercer parámetro y escribe a través de él — y el DN3 propio y sin relación del llamante quedaba sobrescrito, porque los dos eran la misma ranura. El informe CCVS85 lo dice con todas las letras: "DN3 VALUE CHANGED BY CALL".

Solo el parámetro se convierte en alias, deliberadamente. Los items subordinados de un parámetro de grupo siguen resolviéndose por nombre a los del llamante, que es como un programa llamado lee los campos del registro que le entregaron; darles ranuras propias recortó IC de 10 programas limpios a 5. BY CONTENT no cambia — una copia tomada a la entrada, sin escritura de vuelta — y el alias se libera cuando la llamada retorna, de modo que un programa llamado desde dentro de otro que puso alias al mismo nombre recupera su propio enlace. IC (Inter-program Communication) pasa de 187 a 194 aserciones superadas (72.5 % -> 75.8 %), 71 -> 62 fallos.

• La puerta de regresión NIST pasa a una vez por módulo (decisión del operador)

Ejecutar todos los módulos terminados tras cada cambio detectó cuatro problemas en todo el proceso, lo que no compensa volver a medir más de 7000 aserciones cada vez. La puerta completa se ejecuta ahora cuando se resuelve la última aserción fallida de un módulo, antes de declararlo terminado; por cada cambio, solo el módulo en curso y el censo de compilación. Un cambio de lexer o de parser sigue pasando la puerta de inmediato: un cambio del front-end no tiene frontera de módulo, y dos de las cuatro detecciones fueron exactamente eso.

=== PowerRustCOBOL 1.62.85 — 2026-08-29 ===

• Los campos de un parámetro de grupo se emparejan con los del argumento por posición

Los dos programas no tienen por qué usar los mismos nombres para ellos, y hasta ahora solo se enlazaba el grupo en sí — así que el programa llamado escribía en sus propias ranuras de LINKAGE y el llamante no veía cambiar nada.

      *    the caller
       01  TABLE-1.
           02  DN2 PICTURE XXX.
           02  DN3 PICTURE 99.
           02  DN4 PICTURE X(5).
...
           CALL "IC204A" USING TABLE-1, DN1.

      *    the called program
       01  SUB-TABLE-1.
           02  SUB-DN2 PIC XXX.
           02  SUB-DN3 PIC 99.
           02  SUB-DN4 PIC X(5).
       PROCEDURE DIVISION USING SUB-TABLE-1, SUB-DN1.

Los mismos bytes bajo nombres distintos. Emparejar por nombre no alcanza nada, así que los items subordinados se emparejan en orden de declaración — no hay otra cosa por la que emparejarlos — y cada uno se pone como alias del correspondiente del llamante, junto con el grupo. IC (Inter-program Communication) pasa de 194 a 206 aserciones superadas (75.8 % -> 80.5 %), 62 -> 50 fallos. IC203A por sí solo pasó de 13 fallos a 1.

=== PowerRustCOBOL 1.62.86 — 2026-08-29 ===

Post añadido a las 10:16. Post anterior a las 10:14

• BY CONTENT entrega el valor, no el almacenamiento, y la frase BY gobierna todos los operandos que la siguen

Dos defectos, un solo síntoma visible. BY CONTENT copiaba el argumento en el parámetro por nombre, así que cuando el nombre del parámetro era uno que el llamante también usaba, la copia aterrizaba en el almacenamiento del propio llamante y cada escritura pasaba directa. Y la frase se leía por operando: CALL "IC225A-1" USING BY REFERENCE DN1, DN2, CONTENT DN3, DN4 END-CALL pasa dos operandos por cada vía; leída por operando, solo DN3 era BY CONTENT y DN4 recaía en BY REFERENCE. La suite comprueba exactamente eso: "VALUE OF DN4 HAS BEEN CHANGED".

BY CONTENT enlaza ahora como BY REFERENCE y el almacenamiento del llamante — el argumento y cada uno de sus campos — se restaura cuando la llamada retorna. Dentro de una sola unidad de ejecución eso es indistinguible de una copia privada, y hereda el mecanismo de alias que ya hace alcanzables los campos de un parámetro de grupo. IC (Inter-program Communication) pasa de 206 a 212 aserciones superadas (80.5 % -> 82.8 %), 50 -> 44 fallos.

=== PowerRustCOBOL 1.62.87 — 2026-08-29 ===

• Corregido — un programa de consola ya no construye una pila TLS que nunca usa

El compañero de 1.62.9, una plataforma más abajo. Aquel cambio evitó que todas las aplicaciones compilaran SQLite; este evita que un programa de consola enlace la red. ureq y native-tls eran dependencias incondicionales de cobolt-runtime, y native-tls en Linux es OpenSSL — así que compilar allí cualquier aplicación exigía libssl-dev y un compilador de C para openssl-sys, hubiera o no oído hablar el programa de HTTP. google_maps también era incondicional: reqwest más tokio, la mayor dependencia individual que arrastra el runtime, compilada dentro de programas sin ningún control de Maps. Ambos son ahora features, activas por defecto, y el manifiesto generado las apaga para un programa que demostrablemente no alcanza ninguna de las dos. openssl-sys y tokio salen del grafo de dependencias por completo — verificado con cargo tree --target x86_64-unknown-linux-gnu, porque en macOS native-tls usa Security.framework y el problema es invisible.

Maps lo decide el formulario, no el COBOL: MAPS-1::Geocode es una llamada a método sobre un id de control, y nada en el AST la distingue de cualquier otra llamada a método — GET sobre un RestClient se lee exactamente igual que GET sobre cualquier otra cosa. Así que lo que se lee es el .cfrm: un proyecto con un control Maps o WebSearch enlaza el cliente, y uno sin él no. Ese es el cambio que más ahorra, porque una aplicación de formularios corriente no tiene ningún control de Maps. HTTP se enlaza a propósito en toda aplicación de formularios, sin inspeccionar nada: la feature render de cobolt-forms descarga las teselas del mapa base de OSM con su propio ureq, así que una aplicación de formularios enlaza la pila TLS de la plataforma decida lo que decida esto — no hay nada que ganar con ser listos y sí un programa que funciona que perder. Los programas de consola son los que de verdad pueden desprenderse de OpenSSL: no poseen controles y su HTTP llega como un CALL que la build puede leer. Un CALL cuyo destino es un item de datos en lugar de un literal enlaza ahora los tres puentes, no solo SQL: el nombre solo se conoce en tiempo de ejecución, así que podría ser cualquier verbo; la versión anterior lo concedía para SQL y lo asumía en silencio para los demás.

Las builds con un puente apagado informan por el canal de fallo que ese puente ya tenía — HTTP mediante (body, status 0), exactamente donde cae una conexión rechazada; Maps mediante el Err que usan sus propios fallos de API — y cada mensaje nombra la decisión de build y cómo revertirla, en lugar de leerse como una avería de red corriente. Aviso: todos los puentes opcionales son ahora separables, y ninguno cambia lo que enlaza una build por defecto de este workspace: rcrun, el IDE y todos los tests conservan la superficie completa.

=== PowerRustCOBOL 1.62.88 — 2026-08-29 ===

Post añadido a las 10:17. Post anterior a las 10:16

NIST CCVS85 Source Text Manipulation (SM) queda con línea base: 0 -> 4 de 17, con las aserciones pasando de 8 PASS / 15 FAIL a 25 PASS / 9 FAIL (34.8 % -> 73.5 %). Nada cambió en el compilador ni en el runtime — ambas correcciones están en el arnés de conformidad, que medía el módulo injustamente. Todos los módulos terminados quedan intactos: NC 95/95 con 4 614 aserciones, SQ 85/85 con 624, IX 41/41 con 574, IF 45/45 con 841, RL 34/34 con 354, todos con cero fallos, y el censo de compilación de la suite completa sin cambios en 410 de 421.

• Corregido — la pasada de ejecución nunca suministró los copybooks de la suite

La pasada de compilación expande COPY contra la biblioteca de copybooks de CCVS85 desde que el arnés la incorporó. La pasada de ejecución nunca lo hizo. rcrun resuelve un copybook contra el propio directorio del fichero fuente, así que la biblioteca se replica ahora allí antes de ejecutar cada programa.

El módulo Source Text Manipulation trata de COPY, y demuestra un copybook usándolo: SM101A construye un fichero de datos a partir de declaraciones de registro suministradas por COPY, y SM102A vuelve a leer esos registros. Sin la biblioteca, SM101A se expandía a nada, escribía un fichero de cero bytes y SM102A informaba EOF PREMATURELY FOUND — una entrada ausente que se lee exactamente como un defecto del runtime.

• Corregido — las parejas constructor/comprobador de SM declaran sus productores

Tres miembros de SM leen un fichero que un miembro anterior escribió y lo dicen en su propia cabecera, así que entran en la tabla de miembros encadenados: SM102A <- SM101A, SM104A <- SM103A, SM202A <- SM201A. Cada entrada está citada de la cabecera del consumidor ("PROGRAM SM102A TESTS THE OUTPUT FILE PRODUCED BY SM101A"), nunca inferida de una tarjeta X que dos programas casualmente compartan.

ST102A y ST120A leen la misma tarjeta que escribe ST101A y deliberadamente NO se encadenan: ningún miembro de ST declara un productor, y ST102A no tiene PRINT-FILE alguno, de modo que el informe de un productor quedaría atrás y se puntuaría como propio de ST102A. Eso queda fijado como test negativo, con su razón.

=== PowerRustCOBOL 1.62.89 — 2026-08-30 ===

• Corregido — el FILE STATUS de un subprograma se informaba en el almacenamiento del llamante

Un fichero puede compartirse entre programas — eso es lo que significa IS EXTERNAL en una FD, y su estado de apertura y su posición sí son una sola cosa en toda la unidad de ejecución. Su item de FILE STATUS no lo es: lo nombra el SELECT propio de cada programa, sale del almacenamiento propio de ese programa, y una operación informa en el item que pertenece al programa que la ejecutó. Dos defectos superpuestos hacían que CCVS85 IC227A fallara diez aserciones en cinco sentencias — WRITE, CLOSE, OPEN, READ y EOF — con el mismo par intercambiado cada vez.

[Eslopes]

- build_file_specs lee solo el programa más externo y nunca recorre nested_programs, así que el item de estado de un fichero era permanentemente el del programa exterior. Toda operación, la hiciera el programa que la hiciera, informaba en el item del llamante: IC227A siembra el suyo con el centinela <>, no hace E/S propia, y lo encontró sobrescrito — MAIN PROGRAM FILE STATUS UPDATED. Un NestedProgram lleva ahora sus propios enlaces, que se activan alrededor de la llamada y se retiran después, de modo que el anidamiento se deshace en orden. Un fichero que el programa en ejecución no declaró él mismo con SELECT sigue recurriendo al exterior, que es lo que necesita un programa anidado que referencia un fichero GLOBAL.
- Con eso corregido, el estado iba al nombre correcto y todavía no al almacenamiento correcto. set_file_status escribía a través de set_str, que indexa por storage_key — que sigue REDEFINES pero no los alias de parámetro que posee resolve_name. Un item de estado puede ser un item de LINKAGE, y entonces es el almacenamiento del llamante y no una ranura propia: IC227A-1 declara FILE STATUS IS LINKAGE-FS, el tercer argumento de su llamante. La escritura llenaba una ranura que nadie lee y el argumento nunca se movía — UNEXPECTED FILE STATUS VALUE RETURNED. Ahora resuelve el nombre como lo hace cualquier otra sentencia.

IC227A: 11 fallos -> 1, y sus tests que se ejecutan con éxito pasan de 8 a 18 de 23. El módulo va de 212 -> 222 aserciones superadas, 44 -> 34 fallidas, 82.8% -> 86.7%. El recuento de programas limpios se mantiene en 10 de 25: el último fallo de IC227A tiene otra causa, el área de registro EXTERNAL y no el item de estado. La suite de runtime, 99 binarios en verde; el censo de compilación de la suite completa se mantuvo exactamente en 410/421. La puerta completa de línea base protegida se ejecuta al completar el módulo, según la decisión del 2026-08-29 — este cambio está en el runtime, no en el front end.

=== PowerRustCOBOL 1.62.90 — 2026-08-30 ===

• Corregido — la facilidad inter-programa se marca como por encima del subconjunto alto

Un compilador COBOL-85 que valida en el subconjunto alto debe indicarlo cuando un programa usa algo por encima de él. Toda la facilidad de fuentes anidadas y compilación separada está por encima de esa línea — un programa que contiene a otro, las cláusulas que permiten que datos y procedimientos crucen la frontera, y las frases que dicen cómo se pasa un argumento — y nada de ello se marcaba. CCVS85 IC401M declara once de estas construcciones en setenta y cuatro líneas y solo emparejaba dos: END PROGRAM, que otro miembro ya había motivado. Las nueve añadidas ahora son IS INITIAL e IS COMMON en PROGRAM-ID, las cláusulas de datos GLOBAL y EXTERNAL, USE GLOBAL, CANCEL, las frases BY REFERENCE y BY CONTENT, y un programa fuente contenido.

Dos detalles merecieron el cuidado que exigieron. USE GLOBAL y la cláusula de datos GLOBAL comparten palabra clave y son mensajes distintos, así que se distinguen por lo que precede a la palabra. Y INITIAL, COMMON y CONTENT no son palabras clave en absoluto: el lexer no tiene mapeo para ninguna de ellas, así que llegan como palabras ordinarias — Token::Content_ existe pero nada lo produce, y emparejar sobre él no marcaba nada. Cada una queda anclada a la palabra que la precede, de modo que un ítem de datos que casualmente se llame CONTENT no se confunda con la frase. Además, la primera versión de la regla del programa contenido marcaba VALUE OF ID IS "X" en una descripción de fichero, porque ID abrevia IDENTIFICATION y se lexea al mismo token; exigir que siga DIVISION es lo que los separa, y la prueba existente fd_clauses_above_the_subset lo detectó antes de salir del crate.

Post añadido a las 10:21. Post anterior a las 10:19

IC401M: 11 de 11 emparejados, 0 erróneos. En el conjunto de los miembros de marcado de la suite el contador de errores baja 34 -> 25, y ningún otro miembro se movió — los trece que ya puntuaban perfecto lo siguen haciendo, incluidos los cuarenta de NC401M. IC pasa de 222 -> 231 aserciones superadas, 34 -> 25 fallidas, 86.7% -> 90.2%, y de 10 -> 11 de 25 programas limpios. NC se volvió a medir exacto en 95/95 y 4614 PASS / 0 FAIL; el censo de compilación se mantuvo en 410/421. flag_high_subset solo lo alcanza el puntuador del arnés de conformidad — nunca la compilación ni la ejecución — así que todo el radio de impacto son los miembros de marcado, y se midieron los veinticuatro.

=== PowerRustCOBOL 1.62.91 — 2026-08-30 ===

• Añadido — sondas que fijan las garantías del almacenamiento de un grupo

Sin cambio de comportamiento. Cinco pruebas en test_linkage_layout_probe.rs afirman las propiedades de almacenamiento de las que depende vincular un parámetro de LINKAGE por desplazamiento de bytes, porque un intento de esa vinculación falló por razones que leer el código no resolvió, y adivinar dos veces habría sido peor que medir una.

Para la forma sobre la que CCVS85 IC203A e IC205A discrepan — dos bytes declarados como 02 DN6 PIC X OCCURS 2 TIMES en un lado y como 02 TV-1 PIC X más 02 TV-2 PIC X en el otro — establecen que ambas descripciones reportan el mismo ancho, que ningún ítem reporta ancho cero (incluido el nombre sin subíndice de un ítem OCCURS), que cada ocurrencia es direccionable y contiene su propio byte, y que escribir una ocurrencia se refleja en el grupo, que es la dirección en la que escribe un programa llamado.

Las cinco se cumplen. Merece quedar registrado como pruebas y no como una nota: eran las dos explicaciones principales del fallo, ambas quedan ahora excluidas, y la siguiente persona que toque esto tendría que volver a deducirlas.

=== PowerRustCOBOL 1.62.92 — 2026-08-30 ===

• Defecto conocido registrado — un REDEFINES dentro de un programa anidado no hace nada

Aún sin corrección; dos reproducciones y una descripción precisa de un defecto que resulta ser más amplio que el fallo de conformidad que lo encontró. Perseguir los tres fallos de REDEFINES-en-LINKAGE de CCVS85 IC106A produjo primero una explicación más estrecha — que el emparejamiento del CALL omite las redefiniciones, lo cual es cierto — y después una segunda reproducción que no tiene LINKAGE, ni parámetro, ni emparejamiento de CALL en absoluto: un programa anidado redefine su propio WORKING-STORAGE, escribe las partes y lee el todo. Falla de forma idéntica, así que la causa no está en cómo se vinculan los parámetros.

push_local_scope inserta los ítems de un programa anidado en el almacén y en la tabla de símbolos y nada más. La maquinaria de redefinición — las clases de equivalencia, los alias para miembros con disposición idéntica que exceden el presupuesto, el refresco que mantiene sincronizadas las clases pequeñas — se construye cuando el entorno se levanta a partir de la DATA DIVISION del programa exterior. Los ítems de un programa anidado llegan por un camino que no construye nada de eso, así que su ítem redefinidor es una ranura independiente y las dos descripciones nunca comparten almacenamiento.

Atención: esto va más allá de la suite de pruebas. Cada manejador de eventos de un formulario RAD es un programa anidado, así que un REDEFINES en el WORKING-STORAGE de un manejador da silenciosamente dos campos sin relación en lugar de dos vistas de uno; debe tratarse como un defecto del producto que NIST encontró de pasada. Ambas reproducciones viven en test_linkage_redefines.rs, marcadas #[ignore] con el motivo para que la suite siga en verde — se ejecutan con --ignored — y están escritas como criterio de aceptación de la corrección: quitar esos atributos es lo que dirá que está terminada.

=== PowerRustCOBOL 1.62.93 — 2026-08-30 ===

• Corregido — un CALL exitoso ejecutaba su propio manejador de desbordamiento

Post añadido a las 10:22. Post anterior a las 10:21

ON es opcional antes de las frases OVERFLOW y EXCEPTION de un CALL. Escrita sin él, la frase no se reconocía: USING recolecta operandos mientras el siguiente token pueda iniciar uno, un OVERFLOW a secas es solo una palabra, así que la lista de argumentos se lo tragaba y todo lo que seguía se convertía en sentencias ordinarias tras el CALL. Una llamada que tenía éxito ejecutaba entonces el manejador escrito para el caso en que falla. ON OVERFLOW nunca tuvo el problema — Token::On no puede iniciar una expresión, así que la lista de argumentos se detenía sola. Por eso sobrevivió: la ortografía que todo el mundo escribe es la segura.

CCVS85 IC201A escribe ambas formas en un mismo párrafo, CALL-TEST-03-01 con el ON y -03-02 sin él, y reportaba OVERFLOW SHOULD NOT OCCUR para la segunda. Ninguna de las dos palabras puede ser un nombre de datos — ambas son reservadas — así que detener la lista de argumentos en ellas no cuesta nada.

IC pasa de 231 -> 292 aserciones superadas, 25 -> 21 fallidas. El total puntuado sube 256 -> 313: sesenta aserciones que antes no podían alcanzarse ahora se ejecutan, porque un programa que saltaba a su propia rama de fallo nunca llegaba a ellas. El censo de compilación de toda la suite sube 410 -> 412 de 421 (97.4% -> 97.9%): dos programas que nunca habían parseado ahora lo hacen — la misma lista de argumentos consumía la palabra clave de la frase y dejaba ilegible el resto de la sentencia. Todas las líneas base protegidas se volvieron a medir exactas: NC 95/95 con 4614 PASS / 0 FAIL, SQ 85/85 con 624/0, IX 41/41 con 574/0, RL 34/34 con 354/0, IF 45/45 con 841/0. Un cambio de parser se verifica de inmediato y no al completar el módulo, y esta es la razón.

=== PowerRustCOBOL 1.62.94 — 2026-08-30 ===

• Corregido — un nivel 88 sobre un ítem de LINKAGE comprobaba la ranura propia del llamado

Un nombre de condición declarado en la LINKAGE SECTION de un subprograma era siempre falso, pusiera lo que pusiera el llamador en el almacenamiento que nombra. Dos fallos independientes, y el primero ocultaba al segundo. Los niveles 88 de un programa anidado nunca se registraban: cond_names se construye cuando un entorno se analiza desde una DATA DIVISION, y los ítems de un programa anidado llegan al entorno compartido por push_local_scope, que llevaba valores y símbolos y nada más. IF sobre el nombre 88 no encontraba entonces ningún nombre de condición y caía al comportamiento "la ranura contiene algo distinto de cero" — falso para un ítem de LINKAGE que el llamado no ha escrito. register_nested ahora cosecha los nombres de condición del análisis que ya realiza, y el CALL los instala mientras dura la llamada. Un nombre que el entorno ya conoce se deja intacto, exactamente igual que un ítem de datos existente: esto solo puede aportar una resolución donde no había ninguna, nunca cambiar una que ya funcionaba.

Una vez registrado, el anfitrión todavía se leía por clave cruda. Un anfitrión de LINKAGE es el almacenamiento del llamador — CALL ... USING pone el parámetro como alias del argumento — y solo una búsqueda que siga el alias lo alcanza. El subíndice sobrevive a la sustitución y sigue siendo un subíndice, así que L-ITM(2) bajo el alias L-ITM -> ITM es ITM(2), una ocurrencia, nunca la tabla entera. Es el mismo fallo de composición que el defecto de FILE STATUS corregido en 1.62.89: dos caminos de resolución, cada uno correcto por separado, que no componen. CCVS85 IC207A LINK-TEST-03 dice lo que comprueba — "THIS TEST VERIFIES THAT THE CONDITION NAMES DEFINED IN THE LINKAGE SECTION OF THE SUBPROGRAM WERE PROCESSED CORRECTLY".

Comunicación inter-programa (IC), ejecución: 292 PASS / 21 FAIL -> 294 PASS / 19 FAIL, programas limpios 12 -> 15 de 25, DELETED 4. Compilación de toda la suite sin cambios en 412 / 421; NC 95/95 (4614 aserciones), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354) e IF 45/45 (841), todos exactos.

• Corregido — la prueba de aceptación asociada no podía fallar correctamente

Post añadido a las 10:24. Post anterior a las 10:22

test_linkage_condition_name.rs extraía un valor mostrado quitando el prefijo MISS=[ y dejaba puesto el corchete de cierre, de modo que trim().is_empty() nunca era verdadero y la prueba negativa fallaba igual tanto si la respuesta era correcta como si no. Consta en el libro mayor de NIST como que detectó una respuesta errónea en un intento revertido de 1.62.93; no pudo haberlo hecho. Ahora se quitan ambos delimitadores, y la corrección anterior se verifica contra el comportamiento observado.

=== PowerRustCOBOL 1.62.95 — 2026-08-30 ===

• Corregido — un REDEFINES dentro de un programa anidado era inerte

Dos descripciones de una misma área de almacenamiento no la compartían. push_local_scope inserta los ítems de un programa anidado en el almacén y en la tabla de símbolos y nada más: la maquinaria de redefinición — las clases de equivalencia y el refresco que las mantiene sincronizadas — se construye cuando un entorno se analiza desde una DATA DIVISION, y los ítems de un programa anidado llegan por un camino que nunca construyó nada de eso. Su ítem redefinidor era simplemente una ranura independiente. Esto va más allá de la suite de conformidad: cada manejador de eventos de un formulario RAD es un programa anidado, así que un desarrollador que escribiera REDEFINES en el WORKING-STORAGE de un manejador obtenía dos ranuras sin relación y datos silenciosamente erróneos.

register_nested ahora transporta las clases de refresco del programa y el CALL las adopta mientras dura, fusionándolas con la misma regla que usa la construcción original: añadir, nunca reemplazar, nunca duplicar. La deduplicación es lo que lo hace seguro para el área de informe repetitiva de CCVS85: COMPUTED-N REDEFINES COMPUTED-A y sus vecinos se declaran en el programa exterior y en cada programa anidado bajo los mismos nombres, así que los pares son idénticos y adoptarlos es un no-op en lugar de una segunda superposición viva sobre los mismos veinte bytes. pop_local_scope elimina exactamente lo que se añadió — una fuga aquí corrompería el almacenamiento de un programa sin relación en una llamada posterior.

• Corregido — el refresco de REDEFINES escribía a través de claves crudas

refresh_redefine_peers vuelve a renderizar una descripción de un área en las demás con cada escritura. Lo hacía por clave cruda, y un miembro de la clase puede ser un ítem de LINKAGE cuyo almacenamiento es el del llamador — así que el refresco leía y escribía la ranura propia e intacta del llamado. Ambos lados siguen ahora el alias del parámetro.

Por esto la primera corrección no podía aterrizar sola. Adoptar las clases sin ella llevó a CCVS85 IC106A de 3 fallos a 6: su LINK-TEST-06 seguía fallando y tres aserciones sin relación — INDEX IN LINKAGE SECTION, INDEX DATA ITEM SET IN SUBPROG, TABLES DEFINED IN LINKAGE SEC — se rompieron, porque IC107 redefine un GROUP-21 que contiene un DN2 PIC X OCCURS 10 indexado en su LINKAGE SECTION. Con el alias seguido, la regresión desaparece por completo. Es el mismo fallo de composición que el defecto de FILE STATUS (1.62.89) y el del nombre de condición de LINKAGE (1.62.94): dos caminos de resolución, cada uno correcto por separado, que no componen. Cuarta instancia, y ahora registrada en el libro mayor como candidata a una corrección general en vez de un quinto parche.

Los marcadores no cambian y ese es el resultado honesto. La comunicación inter-programa (IC) se mantiene en 294 PASS / 19 FAIL, 15 de 25 limpios; IC106A conserva sus 3 fallos, cuya causa es distinta y sigue abierta. Lo que este cambio compra es el defecto de producto de arriba, cubierto por dos reproducciones — una sin LINKAGE y sin parámetro alguno, con lo que la causa queda probada en el programa anidado y no en la vinculación. Compilación de toda la suite 412 / 421; NC 95/95 (4614 aserciones), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354) e IF 45/45 (841), todos exactos.

=== PowerRustCOBOL 1.62.96 — 2026-08-30 ===

• Corregido — leer a través de un REDEFINES de un ítem de LINKAGE veía una ranura vacía

Post añadido a las 10:25. Post anterior a las 10:24

Un subprograma que lee una redefinición de uno de sus parámetros obtenía el almacenamiento propio e intacto del ítem redefinidor en lugar de los bytes del llamador. El refresco de redefinición se activa por escritura: vuelve a renderizar una descripción en las demás que comparten su área cuando algo escribe en ella. Para una clase de LINKAGE eso llega tarde: el llamador rellena el argumento antes del CALL, así que para cuando la clase existe y el alias del parámetro apunta al almacenamiento del llamador, la escritura que habría propagado esos bytes ya ocurrió — y la descripción redefinidora nunca llegaba a poblarse.

Las clases adoptadas ahora se ceban una sola vez a la entrada, desde el miembro que efectivamente resuelva a través de un alias de parámetro. Una clase sin miembro con alias se deja en paz: es almacenamiento propio del llamado y no tiene nada que heredar.

CCVS85 IC237A-1 declara 01 L-A PIC 9. y 01 L-A1 REDEFINES L-A PIC 9. en su LINKAGE SECTION y hace MOVE L-A1 TO L-C; el llamador comprueba después WS-C = WS-A. Reducido a 25 líneas, L-A leía 1 mientras L-A1 leía 0. Es la quinta aparición de una misma forma raíz — dos caminos de resolución, cada uno correcto por separado, que no componen — tras FILE STATUS (1.62.89), el nombre de condición de LINKAGE (1.62.94) y el refresco de REDEFINES (1.62.95); el libro mayor la lleva ahora como candidata a una única corrección general en vez de un sexto parche. Comunicación inter-programa (IC), ejecución: 294 PASS / 19 FAIL -> 295 PASS / 18 FAIL, programas limpios 15 -> 16 de 25; IC237A ejecuta limpio. Compilación de toda la suite sin cambios en 412 / 421; NC 95/95 (4614 aserciones), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354) e IF 45/45 (841), todos exactos.

=== PowerRustCOBOL 1.62.97 — 2026-08-30 ===

• Corregido — los campos de un parámetro de grupo se emparejan por desplazamiento de bytes, no por posición en el árbol

COBOL-85 da a un ítem de LINKAGE una vista sobre el almacenamiento del llamador: el llamado extiende su propia descripción sobre los bytes del llamador, y ni los nombres ni la forma del árbol tienen que coincidir. Los ítems subordinados de un parámetro de grupo se emparejaban con los del argumento por posición en el árbol de declaración, así que un llamado que describía los mismos bytes con un árbol distinto solo vinculaba su primer campo. CCVS85 IC103A enuncia el caso en su propia cabecera — "THE ITEM DESCRIPTIONS ARE DIFFERENT IN THE SUBPROGRAM FROM THE MAIN PROGRAM, BUT THE NUMBER OF CHARACTERS IS IDENTICAL". Diez bytes son dos hijos de nivel superior en el llamador y tres en el llamado. Reducido a una reproducción, el NUM-DISPLAY PIC 99 del llamado recibía entero el GROUP-LEV2 de cinco bytes del llamador ("42XYZ") y su A-FIELD no recibía nada en absoluto.

Cuando ambas descripciones son planas y coinciden en el ancho total, las hojas se emparejan ahora por los bytes que cubre cada una. Cualquier otro caso conserva el emparejamiento posicional, y esa restricción es el objetivo y no un atajo: un alias solo se consulta por nombre base — resolve_name resuelve la hoja sin subíndice y el subíndice se aplica después — así que una entrada escrita DN6(1) -> TV-1 no la consulta nunca nada. Un mapeo de desplazamientos por ocurrencia vincula estrictamente menos que el emparejamiento al que sustituye, que es exactamente el intento revertido de 1.62.90 que llevó a IC203A de 1 fallo a 7. Esa propiedad queda ahora fijada por una prueba.

• Corregido — un recorrido de disposición medía valores renderizados en lugar de los PICTURE declarados

El mapeo anterior aterrizó y no movió nada, porque nunca llegaba a dispararse. Las dos descripciones discrepaban en su ancho total — 9 contra 10 — porque item_width mide lo que haya en la ranura y un PIC 99 de LINKAGE sin escribir se renderiza como 0, reportando ancho 1. La disposición lee ahora el PICTURE declarado. La sonda conservada no_leaf_reports_a_zero_width se escribió para atrapar esta clase de fallo y pasó todo el tiempo: afirmaba que ninguna hoja reportara ancho cero, y este ancho era erróneo, no cero.

Post añadido a las 10:27. Post anterior a las 10:25

Debajo hay un defecto más amplio, registrado en el libro mayor en vez de corregido aquí: los field_caps de un programa anidado nunca llegan al entorno compartido, porque push_local_scope transporta store y symbols y nada más. field_caps es lo que consulta el truncamiento numérico, así que a cada ítem numérico de LINKAGE en un programa anidado le falta actualmente su capacidad declarada.

Comunicación inter-programa (IC), ejecución: 295 PASS / 18 FAIL -> 299 PASS / 12 FAIL. IC103A pasa de 4 fallos -> 1, IC235A de 5 -> 2. Los dos que quedan en cada uno son CALL-TEST-06 .06 (ALPHANUMERIC EDITED) y .08 (SUBSCRIPTED LINKAGE DATA ITEM) — precisamente las dos formas que el recorrido rechaza, un PICTURE editado y una tabla. Programas limpios sin cambios en 16 de 25; el denominador puntuado se movió 313 -> 311 al dejar esos programas de emitir las líneas extra que produce un fallo. Compilación de toda la suite 412 / 421; NC 95/95 (4614), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354) e IF 45/45 (841), todos exactos.

=== PowerRustCOBOL 1.62.98 — 2026-08-30 ===

• Corregido — los ítems FILLER de un programa anidado no existían

El almacenamiento de un programa anidado se copia como instantánea al entorno compartido cuando se le llama. Esa instantánea venía de CobolEnvironment::iter(), que oculta deliberadamente las claves FILLER sin nombre — correcto para mostrar el almacenamiento, incorrecto para copiarlo. Un FILLER ocupa bytes, así que cada ítem declarado después de uno en un programa anidado quedaba en el desplazamiento equivocado.

CCVS85 IC107 declara, en su LINKAGE SECTION:

01  GROUP-2.
    02    GROUP-21.
        06 DN2 PIC X OCCURS 10 TIMES.
    02     GROUP-2-1 REDEFINES GROUP-21.
        03  FILLER  PICTURE X(7).
        03  DN3     PICTURE XXX.

MOVE ... TO DN3 debe superponerse a los tres últimos bytes de la tabla. El FILLER de siete bytes estaba ausente por completo del entorno — sin valor, sin símbolo — así que reportaba ancho 0 y la escritura caía al principio: 0ABC456789 donde se requería 0123456ABC. all_entries() proporciona ahora la instantánea sin filtrar; iter() queda sin cambios para los llamantes que quieren una vista legible.

La puntuación CCVS no se movió, y ese es el resultado honesto. La comunicación inter-programa (IC) se mantiene en 299 PASS / 12 FAIL, 16 de 25 limpios, e IC106A conserva sus 3 fallos — LINK-TEST-06 tiene una causa adicional que esto no alcanza. Lo que se gana es el defecto de arriba, que va más allá de la suite: un FILLER es COBOL ordinario y cada manejador de eventos de un formulario RAD es un programa anidado. Compilación de toda la suite 412 / 421; NC 95/95 (4614), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354) e IF 45/45 (841), todos exactos.

=== PowerRustCOBOL 1.62.99 — 2026-08-30 ===

• Corregido — un alias de CALL ... USING sobre una tabla escribía en una ranura que nada lee

Las ocurrencias de una tabla son ranuras de almacenamiento separadas en el runtime, y su nombre base no posee ninguna: todo lector direcciona DN2 (n). Eso es invisible para un programa, que de todos modos debe subindexar un ítem de tabla — pero un alias de CALL ... USING puede caer sobre el nombre a secas, y entonces la escritura no iba a ninguna parte. CCVS85 IC106A pasa 01 TABLE-2. 02 DN2 PIC X OCCURS 10. a IC107A, que describe esos mismos diez bytes como un grupo con una superposición:

01  GROUP-2.
    02    GROUP-21.
        06 DN2 PIC X OCCURS 10 TIMES.
    02     GROUP-2-1 REDEFINES GROUP-21.
        03  FILLER  PICTURE X(7).
        03  DN3     PICTURE XXX.

MOVE AL-CON TO DN3 tiene que superponerse a las tres últimas posiciones de la tabla. La vinculación de parámetros empareja el GROUP-21 del llamado con el DN2 del llamador, así que el refresco de REDEFINES pedía almacenar diez bytes en DN2 — el nombre base — y set_group_bytes lo rechazaba por elemental. DN2 (8), (9) y (10) volvían en blanco frente a los esperados X, Y y Z.

[Eslopes]

Una referencia sin subíndice a una tabla es ahora el grupo de sus propias ocurrencias, para leer (group_value, group_bytes), escribir (set_group_bytes, set_from_bytes) y medir (item_width). El nuevo CobolEnvironment::table_extent_keys reconoce exactamente ese caso y nada más: una clave completamente subindexada sigue nombrando una sola ocurrencia, y un grupo sigue leyendo y escribiendo a través de sus propias layout_keys. La expansión por hijo de occurrence_keys se movió a expand_occurrences para que ambos recorridos compartan una única definición de lo que es una ocurrencia, OCCURS ... DEPENDING ON incluido. Prueba de regresión: a_redefines_over_a_linkage_table_reaches_the_calle rs_occurrences en crates/cobolt-runtime/tests/test_linkage_redefines.rs. NIST CCVS85 — Comunicación inter-programa (IC): ejecución 16 -> 17 de 25 programas limpios, 299 -> 301 aserciones PASS y 12 -> 9 FAIL. Conformidad de compilación sin cambios en 47/47 para el módulo y 412 / 421 para toda la suite en alcance.

=== PowerRustCOBOL 1.62.100 — 2026-08-30 ===

• Corregido — un nombre de registro en colisión dejaba sin enlazar los hijos de un parámetro de grupo

Los miembros CCVS85 IC203A e IC205A llaman ambos TABLE-2 a su registro. El del llamador es 02 DN6 PIC X OCCURS 2; el del llamado es 02 TV-1 PIC X. 02 TV-2 PIC X. Como los nombres colisionan, push_local_scope nunca instala el 01 del llamado — gana el del llamador, correctamente — pero el emparejamiento de parámetros de grupo recorría entonces el símbolo del entorno compartido para AMBOS lados y leía dos veces el árbol del llamador. TV-1 y TV-2 del llamado nunca quedaban enlazados a nada: el MOVE "B" TO TV-2 de IC205A escribía en una ranura privada que nadie lee, y CNCL-TEST-05 reportaba COMPUTED= vacío.

Dos cambios, un solo mecanismo. El lado del parámetro del emparejamiento se recorre ahora sobre la propia tabla de símbolos del llamado (register_nested ya la lleva consigo), con los anchos leídos únicamente de la PICTURE. El lado del argumento expande las ocurrencias de una tabla fija como objetivos de alias — TV-2 -> DN6(2) —, que es la dirección consultable: una CLAVE de alias solo se busca por nombre base (a_subscripted_alias_key_is_never_consulted), pero un objetivo se almacena y se sigue textualmente. Una tabla con OCCURS DEPENDING ON sigue rechazándose; su extensión en el momento del enlace no es su extensión durante toda la llamada.

La puntuación CCVS no cambia: 301 PASS / 9 FAIL, y el motivo queda registrado con prueba. La corrección del enlace llevó el COMPUTED= de CNCL-TEST-05 de vacío a XY — las escrituras ya llegan —, pero el miembro sigue en rojo por un segundo defecto separado: una ejecución instrumentada de la cadena fiel muestra que el contador de llamadas de IC206A llega exactamente a 3, y exactamente a 1 tras CANCEL, y aun así las dos pruebas IF DN2 deciden mal. El 77 DN2 COMP privado de IC205A es en realidad el hijo PIC XXX del llamador (el defecto de colisión de nombres medido en el callejón sin salida del shadowing de 1.62.98), así que una comparación numérica se ejecuta como alfanumérica: " 3" contra "3 ". IC203A pasa por tanto al cubo de bloqueados por ámbito de activación junto a IC101A e IC225A; la semántica de comparación se dejó deliberadamente intacta: doblarla para tapar un defecto de ámbito es la vía de heurísticas de palabras que este proyecto rechaza. Compilación de la suite completa 412 / 421; suites de runtime 0 fallidas; NC/SQ/IX/RL/IF intactos por esta vía (el bucle de enlace solo se ejecuta en llamadas a programas anidados, y las comprobaciones por cambio lo cubren) — puerta completa en el límite de módulo según el dictamen del operador.

=== PowerRustCOBOL 1.62.101 — 2026-08-30 ===

• Corregido — un argumento de CALL con subíndice enlazaba la tabla entera

CALL ... USING SUBSCRIPTED-DATA (4) enlazaba el parámetro al nombre desnudo de la tabla: expr_to_name descarta el subíndice, y desde 1.62.99 una escritura a un nombre de tabla desnudo es la tabla entera — así que el valor del llamado aterrizaba en la ocurrencia 1, mientras que CALL-TEST-06-08 de CCVS85 IC235A lee la ocurrencia 4.

Post añadido a las 10:30. Post anterior a las 10:29

El subíndice se evalúa ahora en el momento del enlace, exactamente igual que BY REFERENCE fija la identidad del argumento en el CALL, y la clave con subíndice viaja como objetivo del alias — los objetivos se siguen textualmente; solo las CLAVES de alias son búsquedas por nombre base. La prueba de regresión afirma las dos mitades: la ocurrencia 4 recibe la escritura del llamado y la ocurrencia 1 queda intacta — la segunda aserción es lo que distingue la corrección del accidente de tabla entera que producía S1=[1A].

Comunicación entre programas (IC), ejecución: 301 PASS / 9 FAIL -> 302 PASS / 8 FAIL, programas limpios 17 de 25; IC235A pasa de 2 a 1 fallo, conservando solo su .06 bloqueado por ámbito de activación. Compilación de la suite completa 412 / 421; suites de runtime 0 fallidas; 13 pruebas de sonda en verde.

=== PowerRustCOBOL 1.62.102 — 2026-08-30 ===

• Corregido — un registro pasado BY REFERENCE es una vista sobre sus bytes

Un llamador puede pasar un registro que el llamado describe con un árbol completamente distinto — incluido el extremo en que el llamador no tiene ningún ítem dentro. CCVS85 IC112A pasa el 01 SQ-FS3R1-F-G-120. 02 FILLER PIC X(120). de su FD, e IC113A tiende sobre él un árbol de 120 bytes totalmente nombrado, comprobando XRECORD-NUMBER en el desplazamiento 34. Ningún emparejamiento ítem a ítem puede enlazar eso: no hay nada en el lado del llamador sobre lo que crear un alias.

Cuando el emparejamiento de un parámetro de grupo no enlaza nada por debajo del propio 01, los bytes del argumento se trocean ahora hacia las hojas del llamado a la entrada, y las hojas nombradas se parchean de vuelta sobre los bytes del argumento a la salida, conservando las posiciones FILLER lo que tenía el llamador. Los desplazamientos vienen de compute_layout, el mismo recorrido en el que ya confían los registros de FD. Tres guardas hacen la vía puramente aditiva: solo se dispara cuando cero hijos se emparejaron, escribe solo ranuras insertadas por esta llamada, y exige que el ancho declarado y el real coincidan byte a byte.

• Corregido — el nombre de un llamado podía quedar en alias sobre una ranura FILLER

El emparejamiento posicional cerraba en cremallera las claves de layout en bruto, y esas incluyen ranuras FILLER sintéticas. Que la primera hoja del llamado se emparejara con un FILLER del llamador era un bug de corrupción: un MOVE "BYE" TO HEAD a través de ese alias escribía la ranura FILLER con el ancho del propio FILLER y arrasaba un registro de 20 bytes dejándolo en "BYE" más espacios. Ningún programa puede referenciar una clave FILLER sintética — su separador no puede aparecer en un nombre COBOL —, así que un alias así solo puede fallar. Ambos lados del emparejamiento las excluyen ahora.

La puntuación CCVS no se movió — IC sigue en 302 PASS / 8 FAIL — y el diagnóstico de IC112A es el hallazgo. Con la vista en su sitio, su fallo es RECORDS-IN-ERROR = 649: todos los registros fallan las comprobaciones del llamado, porque los nombres de hoja de IC113A (XRECORD-NUMBER, XFILE-NAME, XLABEL-TYPE) colisionan todos con la tabla del andamiaje CCVS del llamador, FILE-RECORD-INFO-P1-120. Nunca se insertan, la guarda de solo-insertadas rehúsa con razón escribirlas, y las lecturas del llamado se resuelven al andamiaje del llamador en lugar de a su propio registro. Una clave, dos significados: IC112A entra en el cubo de bloqueados por ámbito de activación, que ya contiene seis de los ocho fallos restantes. Compilación de la suite completa 412 / 421; suites de runtime 0 fallidas; todas las repros anteriores re-verificadas.

=== PowerRustCOBOL 1.62.103 — 2026-08-30 ===

• Corregido — los archivos propios de un programa anidado no existían

build_file_specs recorría solo el programa externo, de modo que un SELECT/FD declarado dentro de un subprograma nunca se registraba: OPEN, READ y WRITE sobre él chocaban con unknown file y, en silencio, no hacían nada. CCVS85 IC115A crea, verifica y relee un archivo de 649 registros enteramente desde dentro de un subprograma; una repro de 40 líneas mostraba READ: unknown file.

Post añadido a las 10:32. Post anterior a las 10:30

El registro recorre ahora recursivamente los programas anidados, el más externo primero — un nombre que la unidad de ejecución ya conoce se deja en paz. Esa política es estructural para el único archivo que declara todo programa CCVS85: el PRINT-FILE de cada subprograma sigue resolviéndose al archivo de informe del programa externo, exactamente igual que FILE STATUS cae en cascada. El cursor de lectura persiste entre activaciones, y la prueba de regresión fija los tres comportamientos: registro, persistencia del cursor y AT END.

• Corregido — los símbolos solo viajaban adonde viajaban los valores

push_local_scope insertaba el símbolo de un programa anidado solo cuando existía una clave de almacenamiento con el mismo nombre. Un grupo y el nombre base de una tabla no poseen ranura de almacenamiento, así que exactamente los metadatos que necesita todo recorrido estructurado — dims, layout_keys, las PICTURE — nunca llegaban. Los símbolos se llevan ahora por sí mismos, gana el primero, y se retiran exactamente al hacer pop.

Comunicación entre programas (IC), ejecución: 302 -> 303 PASS / 8 FAIL (una prueba de archivo de IC114A); cada uno de los ocho programas que aún fallan está exactamente en un fallo. El propio LINK-TEST-12 de IC114A sigue en rojo, con un diagnóstico a nivel de byte registrado en el libro mayor: los nombres de campo del andamiaje del subprograma son los nombres de campo del registro del llamador, y los registros escritos entrelazan los campos de los dos programas — la colisión de ámbito de activación al nivel de símbolo. Siete de los ocho fallos restantes están ya en ese cubo. Compilación de la suite completa 412 / 421; suites de runtime 0 fallidas; todas las repros anteriores re-verificadas; 15 pruebas de sonda en verde.

=== PowerRustCOBOL 1.62.104 — 2026-08-30 ===

• Corregido — los datos propios de un programa llamado son suyos: el ámbito de activación

Cada uno de los ocho fallos restantes de IC se había reducido, cada cual con su propia prueba medida, a una única primitiva ausente: la WORKING-STORAGE privada de un programa anidado se fusionaba en un único entorno compartido, de modo que el contador de llamadas 77 DN2 de un llamado ERA el DN2 del llamador, el guardar-en-área-de-trabajo de un llamado destruía el argumento del llamador antes de leerlo, y un ítem numérico de un llamado se comparaba como texto porque su capacidad declarada pertenecía al nombre de otro.

La primitiva, construida a partir de las restricciones de tres intentos revertidos:
- Cualificación en el momento del registro. Todo lo que un programa declara en privado (WS/LS; no GLOBAL, no EXTERNAL, no OBJECT REFERENCE — cada uno de esos es un enlace compartido por la unidad de ejecución) pasa a claves cualificadas por programa, PROG + \u{4} + nombre, con las listas internas de claves de los símbolos, los anfitriones de nombres de condición y las clases de REDEFINES reescritos a través del mismo mapa. El entorno compartido no puede colisionarlas con nadie, por construcción.
- Desvíos por activación. En el CALL, un alias nombre -> cualificado viaja por la vía existente de resolve_name y el vec existente de guardar/restaurar. Gana ANTES de la canonicalización: mientras una activación se ejecuta, solo se ejecutan sus propias sentencias, así que una hoja desnuda que lleva un desvío es el ítem propio de ese programa, sea cual sea el árbol del mismo nombre que declare el llamador. Solo los desvíos toman la vía temprana — sus objetivos llevan el separador que ningún objetivo de SET ADDRESS puede contener.
- Estado descriptivo bajo claves cualificadas, instalado una sola vez. El acarreo total se revirtió en su día sobre claves crudas porque los hermanos podían verlo; las claves cualificadas no pueden colisionar, así que las capacidades, las plantillas de edición y BLANK WHEN ZERO se instalan ahora en la construcción y nunca se deshacen. Sin ellas, un PIC 9(6) privado no tenía capacidad e IF X (1) EQUAL TO 649 comparaba "000649" con "649 " — el bucle de creación escribió treinta megabytes antes de que fuera abortado.

Post añadido a las 10:33. Post anterior a las 10:32

Comunicación entre programas (IC), ejecución: 303 PASS / 8 FAIL -> 305 PASS / 4 FAIL, programas limpios 17 -> 21 de 25. IC101A, IC114A, IC203A, IC226A e IC227A se ejecutan limpios — tres de ellos por primera vez en la historia. Las cuatro pruebas de aceptación pasan, incluida la guarda de que los campos de un parámetro de grupo siguen llegando al llamador. Se actualizaron dos expectativas de prueba en las que los valores eran correctos y solo cambió la representación: el PIC 9(4) de un programa anidado muestra ahora 0001 exactamente igual que siempre lo ha hecho el de un programa externo, porque el ítem por fin tiene su capacidad. Compilación de la suite completa 412 / 421; NC 95/95 (4614), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354), IF 45/45 (841), todos exactos; suites de runtime 0 fallidas.

=== PowerRustCOBOL 1.62.105 — 2026-08-30 ===

• Corregido — un parámetro LINKAGE con edición edita

MOVE "ABCD" TO EDITED-FIELD, donde EDITED-FIELD PIC XXBX0X es una descripción LINKAGE del llano ALPHA-EDITED PIC X(6) del llamador, almacenaba los cuatro caracteres en crudo. La escritura sigue el alias del parámetro hasta la clave del llamador y pedía la plantilla de edición de ESA clave — que con razón no existe, pues fuera de la llamada el ítem es un X(6) llano. La edición pertenece a la descripción a través de la cual se escribe, no a aquella sobre la que se escribe.

El parámetro presta ahora su plantilla al argumento durante exactamente la duración del enlace, y la recupera a la salida. Es correcto porque, mientras está prestada, solo se ejecutan las sentencias de la activación; la segunda mitad de la prueba de regresión escribe la misma ranura después de la llamada y exige que quede sin editar — una plantilla fugada fallaría precisamente ahí.

Tres piezas tuvieron que alinearse, cada una hallada por medición: pic_char_width acepta los caracteres de inserción alfanumérica B, 0 y / (cada uno ocupa una posición almacenada — eso es lo que hace que XXBX0X mida seis), de modo que el emparejamiento por desplazamientos pueda siquiera tender el árbol de forma distinta del llamado sobre los bytes del llamador; y las plantillas de edición alfanumérica viven en su propio mapa, separado de las numéricas, que tanto la instalación descriptiva en construcción como el préstamo acarrean ahora. Comunicación entre programas (IC), ejecución: 305 PASS / 4 FAIL -> 307 PASS / 2 FAIL, programas limpios 21 -> 23 de 25 — el 99.4% de las aserciones puntuadas del módulo. IC103A e IC235A se ejecutan limpios. Compilación de la suite completa 412 / 421; NC 95/95 (4614), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354), IF 45/45 (841), todos exactos; 104 suites de runtime, 0 fallidas.

=== PowerRustCOBOL 1.62.106 — 2026-08-30 ===

• Corregido — una vista de registro sobrevive a nombres en colisión, y sus grupos son legibles

Dos remates de la vista de registro de 1.62.102, ambos aflorados por LINK-TEST-08 de CCVS85 IC112A y hallados con una sonda por registro. Los campos de la vista son la ventana privada del llamado sobre los bytes del argumento — no se emparejan con nada, por diseño —, así que un campo cuyo nombre colisiona con algo que declara el llamador toma ahora una clave de activación y un desvío, exactamente como los datos privados, con sus capacidades declaradas reflejadas sobre la clave de la vista. La vieja guarda de solo-insertadas dejaba a la vista sin sustento cada vez que los nombres de campo del llamado coincidían con el andamiaje CCVS del llamador (XRECORD-NUMBER contra el árbol FILE-RECORD-INFO): 649 de 649 registros "in error".

Y los grupos nombrados de una vista se suman a ella para lectura: IC113A comprueba REELUNIT-NUMBER-GROUP, un grupo de dos bytes sobre /0, y una vista que solo desvía hojas elementales enviaba ese nombre a la tabla del mismo nombre del llamador. Los grupos se desvían y se trocean hacia dentro; el copiado de salida sigue parcheando desde las hojas elementales.

Post añadido a las 10:35. Post anterior a las 10:33

Comunicación entre programas (IC), ejecución: 307 PASS / 2 FAIL -> 308 PASS / 1 FAIL, programas limpios 23 -> 24 de 25 — el 99.7%. IC112A se ejecuta limpio. Queda un solo miembro: IC225A. Compilación de la suite completa 412 / 421; 104 suites de runtime, 0 fallidas.

=== PowerRustCOBOL 1.62.107 — 2026-08-30 ===

• IC (Comunicación entre programas) está TERMINADO — 25/25, 309 PASS / 0 FAIL

El último miembro cayó ante la última aplicación de la primitiva de ámbito de activación: un parámetro elemental BY CONTENT es una copia privada. El viejo tratamiento de alias-y-restaurar se rompía en cuanto el mismo argumento viajaba además por referencia — CALL-TEST-02-03 de CCVS85 IC225A pasa DN1 una vez CONTENT y una vez REFERENCE en un mismo CALL, el ADD del llamado llega al llamador por la referencia, y la restauración del CONTENT volvía a poner el valor antiguo. Una copia en una clave de activación no tiene restauración que machaque nada, y una escritura a través del parámetro CONTENT alcanza solo la copia — el significado entero de la cláusula. Los grupos conservan el tratamiento de alias; sus subordinados se resuelven al almacenamiento del llamador por diseño.

La puerta de cierre del módulo, al completo: IC con 25 de 25 programas ejecutándose limpios, 309 de 309 aserciones puntuadas PASS (DELETED 4, rastreadas durante todo el módulo). NC 95/95 (4614 aserciones), SQ 85/85 (624), IX 41/41 (574), RL 34/34 (354), IF 45/45 (841) — todos exactos; compilación de la suite completa 412/421; 104 suites de runtime, 0 fallidas; las seis pruebas de ámbito de activación en verde, incluidos los dos negativos estructurales.

IC entró en el libro mayor en 1.62.81 como el módulo más débil jamás tomado como línea base: 6 de 25 limpios, 134 PASS / 129 FAIL. Veintiséis versiones después es el sexto módulo terminado y se une a las líneas base protegidas. ST (Sort-Merge) está ahora en curso, con línea base 157 PASS / 99 FAIL, 13 de 40 limpios, y con cuatro miembros que no producen informe CCVS alguno — el primer cubo por leer.

=== PowerRustCOBOL 1.62.108 — 2026-08-30 ===

• Arnés — las ocho cadenas de productores de ST, y los miembros sin informe por diseño

Dos correcciones de medición, ningún cambio de runtime. El módulo Sort/Merge está construido como ocho cadenas creador -> clasificador -> verificador, escritas en las propias cabeceras de miembro de la suite (*HEADER,COBOL,ST101A,SUBPRG,ST102A); las quince entradas de inherits_from las reflejan ahora, de modo que cada miembro se ejecuta después de su productor en el mismo directorio. Y un miembro que nunca nombra la tarjeta de impresora X-55 NO PUEDE informar: ST102A tiene setenta y ocho líneas — varios SELECT, una SD, un SORT, STOP RUN — y lo verifica el siguiente programa de su cadena. Salir con código 0 y sin informe es exactamente el aspecto de un miembro así cuando funciona, y ahora se puntúa de esa manera.

Sort/Merge (ST), ejecución: 157 PASS / 99 FAIL -> 588 PASS / 44 FAIL, programas limpios 13 -> 19 de 40 — cientos de aserciones antes inalcanzables se ejecutan ahora, una ganancia de fidelidad de medición en el sentido que registra la regla de puerta del libro mayor. Siguen abiertos: tres clasificadores que referencian la impresora y sin embargo no imprimen nada, un nuevo timeout de 20 segundos (ST127A), y los dos fallos de compilación de COLLATING SEQUENCE. Los seis módulos protegidos re-verificados exactos bajo el arnés cambiado, entre ellos el 309/0 de IC por primera vez; compilación de la suite completa 412 / 421.

=== PowerRustCOBOL 1.62.109 — 2026-08-30 ===

• Arnés — informar es ejecutar PRINT-DETAIL, no nombrar la impresora

ST110A declara PRINT-FILE sobre la tarjeta X-55 y nunca lo abre, así que el predicado de 1.62.108 — "nombra la tarjeta de impresora" — seguía llamando fallos a tres clasificadores que funcionan. La señal verdadera es la propia maquinaria CCVS: todo miembro que informa la mueve a través de PRINT-DETAIL, y un clasificador no tiene ninguno que mover.

Post añadido a las 10:36. Post anterior a las 10:35

Sort/Merge (ST), ejecución: 19 -> 22 de 40 limpios (aserciones sin cambio, en 588 / 44). Lo que queda es real: cinco verificadores de cadena, cada uno con exactamente un fallo; ST103A con cuatro; el timeout de ST127A; dos miembros mayores (ST131A con 6, ST133A con 15); y los dos fallos de compilación de COLLATING SEQUENCE.

=== PowerRustCOBOL 1.62.110 — 2026-08-30 ===
• Corregido — SORT respeta el contrato de registros de longitud variable
SORT ... USING/GIVING leía su entrada con un lector en bloque de tamaño fijo y escribía su salida en bruto, mientras que todos los demás READ y WRITE de un fichero de longitud variable hablan el contrato del prefijo de longitud. Con los registros de 50 a 100 bytes de ST110A de CCVS85, el lector cercenaba cada registro contra sus vecinos y alimentaba al ordenador de registros con basura, y los verificadores de la cadena reportaban EOF prematuro en el fichero GIVING. Ahora ambos lados del sort comprueban is_varying() y usan el prefijo.

Sort/Merge (ST), ejecución: 588 PASS / 44 FAIL -> 601 PASS / 44 FAIL; programas limpios 22 -> 24 de 40 — se despejaron las cadenas de ST109A y ST112M. Los fallos de ST137A pasaron de 1 -> 3 porque empezaron a ejecutarse aserciones antes inalcanzables. Compilación de la suite completa 412/421; 104 suites de runtime, 0 fallidas.

=== PowerRustCOBOL 1.62.111 — 2026-08-30 ===
• Corregido — INPUT/OUTPUT PROCEDURE a THRU b ejecuta el rango completo
El parser leía el extremo THRU de un procedimiento de SORT/MERGE y lo descartaba, de modo que el intérprete ejecutaba solo la primera sección del rango. ST106A de CCVS85 escribe INPUT PROCEDURE INPROC THRU INPROC-EXIT, y su bucle de RELEASE — que abarca el rango — no liberaba nada: el fichero GIVING salía vacío y todos los verificadores posteriores reportaban EOF prematuro. El AST ahora conserva el par, y exec_sort ejecuta un rango THRU exactamente igual que PERFORM a THRU b.

Sort/Merge (ST), ejecución: 601 PASS / 44 FAIL -> 660 PASS / 127 FAIL; programas limpios 24 -> 26 de 40. El crecimiento de los FAIL es del tipo honesto: ST127A dejó de agotar el tiempo y su procedimiento de salida ejecuta ahora 101 aserciones (80 fallando actualmente), y el rango de entrada de ST119A abrió 25 más. Al ser un cambio del parser, la puerta completa se ejecutó de inmediato: NC 95/95 (4614/0), SQ 85/85 (624/0), IX 41/41 (574/0), RL 34/34 (354/0), IF 45/45 (841/0), IC 25/25 (309/0), compilación 412/421, 104 suites de runtime y la suite del parser con 0 fallos.

=== PowerRustCOBOL 1.62.112 — 2026-08-30 ===
• Corregido — un campo DISPLAY con signo conserva su signo en la imagen del registro
field_bytes representaba un numérico con signo mediante unsigned_abs() y distribute convertía cada byte no numérico en '0' antes de parsear sin signo, así que un viaje de ida y vuelta por el registro borraba los signos por completo: el sort de ocho claves de ST127A de CCVS85 ordenaba -5432 después de +501, y ochenta de sus aserciones fallaban con COMPUTED= 000005432 frente a CORRECT = -000005432.

Una picture con signo (S9..., con el signo no SEPARATE) representa ahora su dígito final con el overpunch estándar — {/A-I para +0...+9, }/J-R para -0...-9 — y distribute lee de vuelta esa misma convención, respetando también un - inicial procedente de escritores con signo separado. El recorrido del layout registra la condición de signo campo a campo.

Sort/Merge (ST), ejecución: 660 PASS / 127 FAIL -> 683 PASS / 92 FAIL; programas limpios 26 -> 28 de 40. Las imágenes de registro son terreno compartido, así que se ejecutó la puerta protegida completa: NC 95/95 (4614/0), SQ 85/85 (624/0), IX 41/41 (574/0), RL 34/34 (354/0), IF 45/45 (841/0), IC 25/25 (309/0), compilación 412/421, 104 suites de runtime con 0 fallos.

[Eslopes]

=== PowerRustCOBOL 1.62.113 — 2026-08-30 ===
• Harness — ST301M se suma a la exclusión de flagging del subconjunto intermedio
"The following program tests the flagging of intermediate subset features that are used in sort-merge functions" — cabecera del propio ST301M. Sus expectativas son los SD, SAME SORT-MERGE AREA, MERGE y SORT ... GIVING que esta implementación ejecuta a diario, y un compilador que valida en el subconjunto alto no debe señalar features que soporta. La misma decisión del operador que sacó del alcance a IX301M y RL301M lo cubre; Sort/Merge se puntúa sobre 39.

Sort/Merge (ST): 28 de 39 limpios, 682 PASS / 87 FAIL de 769 aserciones puntuadas. Compilación de la suite completa 412/421 sin cambios.

=== PowerRustCOBOL 1.62.114 — 2026-08-30 ===
• Harness — se rellena el recuento de registros del sort grande (X-65)
XXXXX065 es el recuento de registros del fichero del sort grande de ST115A, un tamaño que la distribución deja en manos de la instalación. Sin rellenar, es un identificador no declarado: el MOVE hacia RECORDS-IN-FILE queda en no-op, la cota del bucle de construcción compara contra nada y sale tras UN solo registro de 507 bytes, ST116A ordena un fichero de un registro y el BIG-SORT de ST117A reporta ERROR AT RECORD 1. Cien mantiene "grande" con sentido y el barrido rápido — rellenado hasta las ocho columnas de la tarjeta, o el sello de secuencia se desliza dentro del área de código (el primer intento hizo fallar ambos miembros exactamente así).

Sort/Merge (ST), ejecución: 28 -> 29 de 39 limpios (683 PASS / 86 FAIL); ST115A y ST117A se ejecutan limpios. Compilación de la suite completa 412/421.

=== PowerRustCOBOL 1.62.115 — 2026-08-31 ===
• Un procedimiento de sort sigue un GO TO fuera de su rango — y de vuelta
El INPUT PROCEDURE de ST119A de CCVS85 salta a "código externo" fuera de su rango IN-1 THRU IN-EXIT, y ese código salta directamente de vuelta adentro (XI-19 4.4.4 GR(10)). El ejecutor ordinario de rangos PERFORM escapa ante un GO TO fuera de rango, y esa escapada se desenrollaba a través de la propia sentencia SORT: el sort corría sobre un búfer vacío, los registros liberados llegaban después por caída al nivel superior, y cada test de ordenación leía de vuelta el orden de liberación. Un INPUT/OUTPUT PROCEDURE de sort ahora sigue un GO TO adonde vaya y termina cuando completa su último párrafo; el PERFORM THRU ordinario conserva su semántica de escape.

ST119A: 9 FAIL -> 0 (27 de 27, cinco tests nunca alcanzados se ejecutan ahora). ST (Sort/Merge): 29 -> 30 de 39 limpios; aserciones 683 PASS / 86 FAIL -> 696 / 77. Compilación de la suite completa sin cambios en 412/421.

=== PowerRustCOBOL 1.62.116 — 2026-08-31 ===
• El área de registro compartida de ST131A — tres defectos y una reparación del harness
ST131A de CCVS85 (SAME RECORD AREA FOR SORT3 FILE3) fallaba 6 aserciones por tres defectos sin relación entre sí: el párrafo I-O-CONTROL es UNA sola sentencia y la lista de nombres de fichero de SAME se comía el SAME de la cláusula siguiente como si fuera un nombre de fichero, descartando en silencio el segundo grupo; RELEASE materializaba solo los campos con nombre, de modo que los bytes cubiertos por FILLER — los dígitos de orden bajo de la clave del tercer sort — iban a disco como espacios; y RETURN ... INTO era una asignación de cadena completa con pérdidas que nada vuelve a leer, y ahora es el mismo contrato de distribución de bytes que READ ... INTO (lo que también despeja ST144A). ST131A: 15 de 15. ST (Sort/Merge): 30 -> 32 de 39; aserciones 696 PASS / 77 FAIL -> 707 / 70.

Post añadido a las 10:40. Post anterior a las 10:38

La puerta protegida completa (se tocó el parser) atrapó dos cosas: una variante rechazada del fix de RETURN, que almacenaba la imagen en bruto bajo el nombre de grupo del registro, desplazaba las lecturas de grupo de ST127A (61 -> 68; revertida y registrada como callejón sin salida), y la sustitución global de XXXXX065 de 1.62.114 había corrompido los datos de prueba de clave alternativa de IX106A (...XXXXXXXXXX065ALTKEY1...). La sustitución de tarjetas X ahora está anclada a los límites. IX restaurado a 41/41, 574 PASS / 0 FAIL; NC, SQ, RL, IF, IC exactos; compilación 412/421.

=== PowerRustCOBOL 1.62.117 — 2026-08-31 ===
• El byte de signo fantasma en las imágenes de grupo
Un numérico negativo con signo (no SEPARATE) representaba sus bytes en la imagen de grupo con un - inicial — un byte para el que el ítem no tiene posición de carácter — de modo que cualquier movimiento de grupo a través de un campo negativo desplazaba todos los campos posteriores un byte a la derecha. ST127A de CCVS85 toma una instantánea de su registro de sort a través de tres campos con signo y comparaba la copia desplazada: sus 61 fallos eran todos esto. Los valores negativos se representan ahora al ancho del PICTURE con el signo en overpunch sobre el dígito final (la convención de la imagen de registro), los anchos coinciden, y el lado receptor decodifica esa forma de vuelta al valor; cualquier otro segmento sigue aterrizando literal.

ST127A: 61 FAIL -> 0 (27 de 27). ST133A, ST134A y ST136A vienen detrás — la "familia del área de registro" era en su mayoría este mismo byte. ST (Sort/Merge): 32 -> 36 de 39; aserciones 707 PASS / 70 FAIL -> 709 / 3. Puerta completa: NC, SQ, IX, RL, IF, IC todos exactos; compilación de la suite completa 412/421.

=== PowerRustCOBOL 1.62.118 — 2026-08-31 ===
• Harness — la tarjeta de la secuencia de intercalación nativa (X-63)
XXXXX063 es la declaración de la instalación del orden de intercalación nativo de su máquina, un literal entrecomillado de 51 caracteres contra el que ST137A y ST147A comparan la salida ordenada. Sin rellenar, las secuencias esperadas eran espacios — y las secuencias calculadas ya eran exactamente ASCII. Se rellenó con la tarjeta de muestra ASCII que los propios miembros documentan, con la sustitución anclada a límites porque IX106A lleva los mismos ocho bytes dentro de una serie de X en sus datos de prueba.

ST (Sort/Merge): 36 -> 37 de 39, aserciones 709 PASS / 3 FAIL -> 711 / 0 — todo lo que compila se ejecuta limpio. Los dos miembros restantes son la brecha del eje de compilación (SORT ... COLLATING SEQUENCE IS alphabet-name). IX re-verificado exacto (574/0); compilación 412/421.

=== PowerRustCOBOL 1.62.119 — 2026-08-31 ===
• ST (Sort/Merge) TERMINADO — y SORT aprende COLLATING SEQUENCE
SORT/MERGE ... [COLLATING] SEQUENCE [IS] alphabet-name ahora se parsea en las dos grafías de CCVS85 (SEQUENCE es palabra clave del lexer, así que la cláusula se reconoce por tokens y la lista de claves se detiene en ella) y ordena las claves alfanuméricas del sort según el alfabeto de SPECIAL-NAMES nombrado; las claves numéricas comparan numéricamente bajo cualquier secuencia, y NATIVE/STANDARD-1 no necesitan tabla. ST139A y ST140A compilan y se ejecutan limpios al primer intento.

ST (Sort/Merge) está completo en ambos ejes: 40/40 compilación, 39/39 ejecución, 735 PASS / 0 FAIL / 0 DELETED — desde 29/39 y 683/86 al comienzo de la sesión. Compilación de la suite completa: 412 -> 414 de 421 (98.3%). Puerta de cierre completa: NC, SQ, IX, RL, IF, IC todos exactos. Próximo módulo en curso: SM (Source text manipulation).

Post añadido a las 10:41. Post anterior a las 10:40

=== PowerRustCOBOL 1.62.120 — 2026-08-31 ===
• SM — los copybooks hablan las mismas tarjetas que los miembros
Dos reparaciones de fidelidad del arnés, sin cambio alguno en el runtime: el texto de los copybooks pasa ahora por la misma canonicalización de tarjetas X que el fuente de los miembros (SM103A escribía XXXXP001, SM104A leía XXXXD001 — cinco comprobaciones contra un archivo que nunca existió), y la pasada de ejecución expande COPY contra la biblioteca de la suite antes de juzgar la compilabilidad, como el censo hizo siempre (once de los diecisiete miembros de SM figuraban como "did not compile" en el eje de ejecución mientras catorce compilaban en el censo).

SM (Source text manipulation): 4 -> 9 de 17 limpios; aserciones 32 PASS / 9 FAIL -> 271 / 9. Puerta completa después (la puerta de compilación toca todos los módulos): NC, SQ, IX, RL, IF, IC, ST todos exactos.

=== PowerRustCOBOL 1.62.121 — 2026-08-31 ===
• El pseudotexto se empareja por palabras de texto
COPY ... REPLACING ==a== BY ==b== (y REPLACE) comparaban el pseudotexto con una comparación literal de cadenas, pero el operando y el copybook parten sus líneas de forma distinta, de modo que un operando de varias palabras nunca podía coincidir. El emparejamiento se hace ahora por secuencias de palabras de texto normalizadas en espacios, sin distinguir mayúsculas de minúsculas, con los separadores finales desprendidos como palabras propias (...X(115) coincide con el X(115). pegado del copybook).

SM (Source text manipulation): 9 -> 10 de 17 limpios (SM201A), 271 -> 281 PASS / 10 FAIL; SM208A compila — compilación de toda la suite 414 -> 415 de 421 (98.6%). Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos.

=== PowerRustCOBOL 1.62.122 — 2026-08-31 ===
• Arnés — SM204A se ejecuta después de su constructor
SM204A comprueba el archivo que escribe SM203A (el mismo par constructor/verificador que SM103A/SM104A), pero la cadena nunca se había declarado: abría un archivo que nadie había escrito y cada COPY-TEST leía ceros. Con el productor declarado, SM204A no informa de ningún fallo — el runtime nunca estuvo equivocado.

SM (Source text manipulation): 10 -> 11 de 17 limpios; aserciones 281 PASS / 10 FAIL -> 285 / 6.

=== PowerRustCOBOL 1.62.123 — 2026-08-31 ===
• COPY lee de la biblioteca que nombra
COPY member OF library selecciona qué biblioteca suministra el texto — el CCVS85 SM207A mantiene el mismo nombre de miembro en dos bibliotecas con contenidos distintos, y el expansor ignoraba el calificador y traía el mismo texto para ambas. El calificador se resuelve ahora a un subdirectorio de la ruta de copybooks (la búsqueda plana no cambia cuando está ausente), y el arnés planta las dos bibliotecas alternativas de la suite bajo los nombres de tarjeta X-47 y X-48 que usan sus programas.

SM (Source text manipulation): 11 -> 12 de 17 limpios; 285 PASS / 6 FAIL -> 286 / 5. Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos.

=== PowerRustCOBOL 1.62.124 — 2026-08-31 ===
• Un 01 FILLER REDEFINES de nivel superior comparte su almacenamiento
Una redefinición sin nombre solo se conectaba a la maquinaria de solapamiento cuando tenía un padre bajo el que registrar su ranura sintética — un FILLER de nivel 01 no lo tiene, así que la redefinición entera se descartaba en silencio y sus hijos leían espacios con independencia de lo que contuviera el elemento redefinido. El CCVS85 SM208A relee su resultado de REPLACE de 322 bytes exactamente a través de esta forma.

SM (Source text manipulation): aserciones 286 PASS / 5 FAIL -> 286 / 4. Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos; barrido del runtime limpio.

=== PowerRustCOBOL 1.62.125 — 2026-08-31 ===
• Los separadores son intercambiables en el pseudotexto
Una coma o un punto y coma aislados son separadores, no palabras de texto, así que REPLACE ==MOVE; "FAIL" , TO== debe coincidir con MOVE , "FAIL"; TO — XII-7 3.4 GR6(b), CCVS85 SM208A REP-TEST-8. El emparejamiento descarta ahora las , / ; aisladas de ambas secuencias; el punto sigue siendo significativo.

Post añadido a las 10:43. Post anterior a las 10:41

SM208A: 11 de 11. SM (Source text manipulation): 12 -> 13 de 17, 286 PASS / 3 FAIL. Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos.

=== PowerRustCOBOL 1.62.126 — 2026-08-31 ===
• Los miembros de flagging de SM quedan resueltos
flag_high_subset emite ahora NON-CONFORMING STANDARD para COPY ... REPLACING y para la sentencia REPLACE — las dos expectativas de SM401M coinciden. SM301M prueba el flagging de subconjunto intermedio del COPY simple, la misma clase inalcanzable por diseño que IX301M/RL301M/ST301M, y se une a su exclusión bajo la resolución vigente (SM se puntúa sobre 16).

SM (Source text manipulation): 288 PASS / 0 FAIL, 14 de 16 — el único hueco restante es el eje de compilación (SM202A, SM206A). Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos.

=== PowerRustCOBOL 1.62.127 — 2026-08-31 ===
• SM (Source text manipulation) TERMINADO
La última ronda de semántica de operandos de REPLACING, en un solo aterrizaje: un operando literal de cadena conserva sus comillas; un operando identificador abarca su cadena de calificación IN/OF y su subíndice entre paréntesis; todos los pares se aplican en UNA sola pasada, gana la primera coincidencia y un reemplazo nunca se vuelve a examinar (==1== BY ==5== ==5== BY ==7== se detiene en 5); el modismo de palabra parcial :TAG: es una pre-pasada de subcadenas; y una línea de depuración en el texto de biblioteca participa en el emparejamiento, de modo que el REPLACING destinado a eliminarla puede hacerlo.

SM está completo en ambos ejes: 17/17 en compilación, 16/16 en ejecución (SM301M excluido por la resolución 301M vigente), 311 PASS / 0 FAIL / 3 DELETED — los tres borrados son pruebas comentadas por la propia distribución. Desde 14/17 · 4/17 · 32 PASS / 9 FAIL en la línea base. Compilación de toda la suite: 415 -> 417 de 421 (99.0%). Puerta completa: NC, SQ, IX, RL, IF, IC, ST todos exactos. El único hueco de compilación en alcance que queda en toda la suite son los cuatro miembros de DB.

=== PowerRustCOBOL 1.62.128 — 2026-08-31 ===
• GO-TO es un nombre, no un verbo
El lexer asignaba la palabra única con guiones GO-TO al verbo GO TO. Es una palabra definida por el usuario perfectamente legal — el CCVS85 DB101A da a una SECTION el nombre GO-TO —, así que GO-TO SECTION. se analizaba como una sentencia GO TO. Una línea eliminada: el verbo son las dos palabras GO TO.

DB101A, DB102A y DB103M compilan; compilación de toda la suite 417 -> 420 de 421 (99.8%). El único fallo en alcance restante es DB205A, cuyo contenido es la maquinaria de COMMUNICATION que la resolución de alcance excluye — queda registrada para el operador una propuesta de extensión de esa resolución. Puerta completa: los ocho módulos protegidos exactos.

=== PowerRustCOBOL 1.62.129 — 2026-08-31 ===
• La campaña NIST CCVS85 se cierra al 100 %
Por resolución del operador, DB205A — DB por nombre, COMMUNICATION por contenido (DISABLE/ENABLE con CD-name bajo USE FOR DEBUGGING) — se une a la exclusión de alcance de CM y se puntúa bajo CM. El censo lee 420 / 420, el 100.0 % de la suite en alcance, 0 FAIL, y DB completa su eje de compilación 14/14.

Clasificación final en toda la suite: NC, SQ, IX, RL, IF, IC, ST y SM, todos al 100 % en ambos ejes — 8362 aserciones PASS, 0 FAIL, 3 DELETED (las pruebas comentadas por la propia distribución). Cada exclusión es una resolución del operador registrada en NIST/progress.json.

Anthropic Claude Codex Agent