• Corregido — un elemento FILE STATUS declarado como grupo recibe el código
COBOL-85 permite que el elemento sea un grupo de dos caracteres, y SQ132A declara 01 SQ-FS1-STATUS sobre dos hijos PIC X. Un grupo se relee desde sus hijos, no desde su propio slot, así que escribir el código en la clave del grupo dejaba a los hijos con lo que el programa hubiera sembrado: IF SQ-FS1-STATUS = "42" comparaba contra esa siembra, y todas las pruebas de estado sobre tal fichero fallaban. Esto es lo que más movió el módulo — 14 -> 38 programas limpios por sí solo — y con ello se despejó también el timeout de 20 segundos de SQ121A.
• Corregido — un OPEN de un fichero ya abierto es 41
Devolvía 00 y reabría el fichero, lo que truncaba silenciosamente un fichero OUTPUT que el programa acababa de escribir. El estado es ahora 41, el fichero queda exactamente como estaba y la declarativa del fichero se dispara (SQ139A, SQ140A, SQ131A).
• Corregido — un READ secuencial tras AT END es 46
Seguir leyendo tras el final devolvía un segundo 10. El AT END no dejó registro siguiente válido, así que el siguiente READ secuencial es 46 — un estado de clase 4, lo que significa que para él no corre ni AT END ni NOT AT END y que la declarativa USE es la que lo maneja. Un OPEN nuevo, o un START con éxito, restablece un registro (SQ136A–SQ138A).
• Corregido — un solo OPEN puede llevar varios grupos de modo
OPEN INPUT SQ-FS1, SQ-FS3 OUTPUT SQ-FS4. es el OPEN multifrase de COBOL-85. El parser leía exactamente un modo y luego recogía nombres de fichero, así que OUTPUT — una palabra clave, no un identificador — quedaba sin consumir y la sentencia se rechazaba: unexpected token in statement: Output. Cada grupo abre ahora en su propio modo, con SHARING / WITH LOCK / REGISTERED USER aplicando a la sentencia. Esto es la totalidad de la ganancia de compilación (SQ128A, SQ206A).
• Corregido — un TextBox declara la PICTURE COBOL que obedece su contenido
La propiedad Picture existía en las primeras versiones y se eliminó en algún momento sin causa, lo que dejaba a un TextBox generando PIC X(512) fuera cual fuera el propósito de la caja: una caja que recogía un importe producía un elemento alfanumérico, toda comparación contra ella seguía las reglas alfanuméricas y el operador podía teclear cualquier cosa dentro.
La propiedad vuelve al TextBox y se respeta en todos los sitios donde el control se dibuja o se genera. Hace dos trabajos. Como validador decide, por posición de carácter, qué bytes son legales — PIC A(3) letras y espacios, PIC 9(3) dígitos, PIC X(3) cualquier cosa —, la lectura de COBOL-85, no la permisiva; la entrada sigue siendo texto plano validado por pulsación, nunca una máscara de separadores que pre-siembra caracteres de agrupación y pasea el cursor por encima de ellos. Como máscara muestra la forma editada en reposo y el valor almacenado plano bajo el cursor, de modo que PIC ZZ9.99 con 12.34 se lee " 12.34" hasta recibir el foco. El separador decimal y el carácter de moneda salen del SPECIAL-NAMES del formulario, así que un formulario en ejecución y el COBOL que genera no pueden discrepar sobre DECIMAL-POINT IS COMMA.
El elemento generado lleva ahora esa misma picture, con lo que una comparación contra él es correcta por construcción y no por una coerción en tiempo de ejecución. Un .cfrm existente no se ve afectado: una Picture vacía significa "no establecida", y la picture efectiva es entonces X(n) derivada de MaximumLength exactamente como antes; donde sí hay picture, su propio ancho es la autoridad y MaximumLength ya no acota el campo. El motor de PICTURE numérico-editada se movió de cobolt-runtime a cobolt-forms (numedit.rs, acompañado del nuevo picture.rs) para que el TextBox y el intérprete editen por el mismo código; cobolt-runtime lo reexporta, dejando intacto cada sitio de llamada crate::numedit::...
• Pruebas
crates/cobolt-runtime/tests/test_declaratives_and_status.rs — seis casos: un manejador haciendo PERFORM y saltando a sus propios párrafos (y no ejecutando el que su GO TO omite), el cuerpo principal sin caer en una declarativa, un FILE STATUS de grupo, el 41 dejando intacto el contenido del fichero, el 46 y su liberación por un OPEN nuevo, y un OPEN de dos grupos. crates/cobolt-codegen/tests/textbox_picture.rs — la picture que declara un TextBox llega al elemento de datos generado, y un formulario escrito sin la propiedad sigue generando lo que siempre generó.
• Documentación
docs/cobol85-supported-syntax-en.md — la entrada de declarativas enuncia ahora la regla de espacio de nombres y la entrada/salida acotada por sección; OPEN gana la forma multigrupo y el 41; READ gana el 46. El marcador incorpora una tabla de ejecución de SQ junto a la de NC, la tabla por módulo y el historial de conformidad se re-miden, y el resumen obsoleto "tres cuartos / 102 restantes" se corrige a 97,2 % / 12. docs/developers-guide-en.md — la nota "un manejador declarativo es lineal, GO TO no está soportado" era errónea y se sustituye por un manejador multipárrafo desarrollado, la salvedad de que las dos porciones nunca se invaden mutuamente, y una tabla de los tres estados de error que solo una declarativa hace visibles.
=== PowerRustCOBOL 1.62.44 — 2026-08-28 ===
NIST CCVS85 Sequential I/O (SQ) pasa de 44 -> 67 de 85 en ejecución, con las aserciones subiendo de 471 PASS / 162 FAIL a 560 PASS / 60 FAIL (74,4 % -> 90,3 %). La compilación se queda en 85 de 85 para SQ y 422 de 434 para el conjunto completo. Nucleus no cambia: 95 de 95 en ambos ejes, 4 614 aserciones sin ninguna fallida (GOLDEN RULE #9: SQ es el módulo en curso, y el techo de NC se re-mide tras cada cambio). Seis correcciones a cómo viaja un registro entre un programa COBOL y un fichero secuencial, todas ellas comportamiento COBOL-85 que faltaba y no capacidad nueva.
• Corregido — registros de longitud variable
La cláusula RECORD del FD se saltaba por completo, así que todo fichero secuencial era una tirada de registros de igual tamaño. Las tres grafías se leen y respetan ahora: RECORD CONTAINS n CHARACTERS — longitud fija, comportamiento sin cambios; RECORD CONTAINS n TO m CHARACTERS — variable, la descripción de registro que nombra el WRITE da la longitud; RECORD [IS] VARYING [IN SIZE] [FROM n] [TO m] [DEPENDING ON item] — el elemento de datos ES la longitud: fijado antes de un WRITE es el número de caracteres escritos, y tras un READ contiene la longitud del registro leído.
Código:
FD CUSTOMER-FILE
RECORD IS VARYING IN SIZE FROM 120 TO 151 CHARACTERS
DEPENDING ON RECORD-LENGTH.
01 SHORT-RECORD.
02 CUST-KEY PIC X(120).
01 LONG-RECORD.
02 CUST-KEY-2 PIC X(120).
02 CUST-NOTES PIC X(31).
Un FD cuyos registros 01 son de tamaños distintos es de longitud variable lo diga o no, que es lo que COBOL-85 exige y de lo que depende SQ107A. Un fichero de longitud variable lleva la longitud de cada registro junto al registro; los bytes de un fichero de longitud fija no cambian.
• Corregido — las descripciones de registro de un FD comparten una sola área de registro
Cada 01 bajo un FD describe el mismo almacenamiento. Un WRITE envía ahora esa área entera — donde el registro nombrado tiene FILLER, se trasluce lo que otra descripción de registro puso allí — y un READ entrega los bytes a través de todas las descripciones de registro, así que un FD con un registro corto y uno largo devuelve también los campos extra del largo.
• Corregido — un FILLER ocupa sus bytes en un registro de FD
Un FILLER se saltaba junto con su anchura, así que cada campo posterior quedaba en el offset equivocado: 03 FILLER PIC X(120). 03 EXT-18 PIC X(18). medía 18 bytes con EXT-18 en el offset cero. Un registro que no es más que FILLER — 01 PRINT-LINE. 02 FILLER PIC X(120). — se escribía como 120 espacios por mucho que el programa hubiera movido dentro.
• Corregido — SIGN IS SEPARATE CHARACTER ensancha el elemento en un registro
PIC S9(5) SIGN IS LEADING SEPARATE CHARACTER ocupa seis posiciones de carácter, no cinco. El trazado del registro contaba cinco, así que cada campo posterior quedaba desplazado un byte respecto al área de registro.
• Corregido — READ ... INTO sigue las reglas del movimiento de grupo
READ file INTO identifier es el READ seguido de un MOVE de grupo, así que el registro se distribuye entre los elementos subordinados del receptor y se corta a la anchura propia del receptor. Se escribía en el slot propio del grupo, que nada relee, dejando a los hijos del receptor con sus valores antiguos. Un receptor con subíndice (READ f INTO TABLE-ENTRY (1)) aterriza ahora en el elemento subindexado y no en el primero, y el registro se mueve como bytes, así que un registro que contiene un byte que no es un carácter llega intacto.
• Corregido — REWRITE sobre un fichero secuencial por registros
REWRITE estaba implementado solo para ficheros indexados; sobre un fichero secuencial informaba de un error de E/S permanente y no cambiaba nada. Ahora reemplaza en el sitio el registro que entregó el último READ y no toca la posición de lectura, así que un bucle de leer-modificar-reescribir recorre el fichero exactamente una vez.
Con los estados que el estándar exige: 49 cuando el fichero no está abierto en I-O, 43 cuando ningún READ con éxito estableció un registro — tras AT END, o en un segundo REWRITE sin un READ entre medias — y 44 cuando el registro nuevo no tiene la misma longitud que el leído. En un fichero RECORD ... DEPENDING ON el valor del elemento ES esa longitud, así que cambiarlo y reescribir es la manera en que un programa pide otra longitud, y 44 es la respuesta.
• Corregido — el arnés NIST no podía leer un informe con bytes crudos
nist_conformance run leía el fichero de impresión de cada programa como texto UTF-8. NC107A imprime las constantes figurativas, así que su informe lleva legítimamente bytes HIGH-VALUE (0xFF) y LOW-VALUE (0x00) — el fichero entero se rechazaba y sus 177 aserciones superadas puntuaban como "no report printed". Los informes se leen ahora como bytes y se decodifican con pérdida controlada: un runtime que escribe fielmente el byte que se le mandó escribir ya no parece un fallo.
=== PowerRustCOBOL 1.62.45 — 2026-08-28 ===
NIST CCVS85 Sequential I/O (SQ) pasa de 67 -> 79 de 85 en ejecución, aserciones 560 PASS / 60 FAIL -> 595 PASS / 25 FAIL (90,3 % -> 96,0 %). La compilación no cambia: 85 de 85 para SQ y 422 de 434 para el conjunto completo; Nucleus sigue en 95 de 95 en ambos ejes con 4 614 aserciones y ninguna fallida. De los seis miembros de SQ aún cortos, tres (SQ302M, SQ303M, SQ401M) son pruebas de flagging: no llevan aserciones y puntúan los diagnósticos OBSOLETE / NON-CONFORMING del compilador, 24 de los cuales aún no se emiten. Esos 24 componen la mayor parte del FAIL restante. Cinco piezas más de COBOL-85 que los verbos de fichero le debían al programa.
• Corregido — ON es opcional en una declarativa USE
USE AFTER STANDARD ERROR PROCEDURE OUTPUT. se leía como un cajón de sastre — el parser se saltaba todo hasta ON, y sin un ON presente la palabra de modo de apertura se iba con lo saltado. Un programa que declaraba un manejador para OUTPUT y otro para INPUT ejecutaba por tanto el manejador de OUTPUT sobre un fichero de entrada.
Código:
DECLARATIVES.
OUTPUT-ERRORS SECTION.
USE AFTER STANDARD ERROR PROCEDURE OUTPUT.
...
INPUT-ERRORS SECTION.
USE AFTER ERROR PROCEDURE ON INPUT.
Ambas grafías — con ON y sin él — seleccionan ahora por modo.
• Corregido — CLOSE ... REEL / CLOSE ... UNIT no cierra el fichero
REEL y UNIT terminan un volumen de una cinta multivolumen, no el fichero. Se parseaban y se descartaban, así que el fichero se cerraba del todo y el siguiente WRITE o CLOSE fallaba sobre un fichero que el programa aún creía abierto. En disco no hay volúmenes, para lo que el estándar tiene un estado — 07, con éxito pero el fichero no está en un medio de carrete/unidad — y el fichero permanece abierto.
• Corregido — solo OPEN OUTPUT crea un fichero
OPEN I-O y OPEN EXTEND se abrían con "crear si falta", así que abrir un fichero que no estaba informaba de éxito. Ambos informan ahora 35, como ya hacía OPEN INPUT. SELECT OPTIONAL file-name es la excepción, y ahora se respeta: el fichero no necesita estar presente, uno ausente se crea, y el OPEN informa 05 para que el programa lo sepa. OPEN INPUT de un fichero OPTIONAL ausente se comporta como un fichero vacío: el primer READ levanta AT END.
• Corregido — LINAGE-COUNTER vale uno cuando el fichero se abre
Se dejaba en lo que hubiera alcanzado la página anterior, así que un programa que cerraba y reabría su fichero de impresión veía un número de línea rancio. Abrir el fichero lo posiciona en la línea uno.
• Corregido — una longitud de registro fuera del rango declarado es una violación de límites
Los valores de RECORD ... DEPENDING ON se recortaban al rango FROM ... TO del FD, lo que convertía calladamente una longitud que el FD prohíbe en una legal. La longitud se usa ahora tal como la fijó el programa, y una fuera del rango es 44 sin que nada se escriba — que es también lo que permite que un REWRITE pida una longitud distinta y reciba un no.
=== PowerRustCOBOL 1.62.46 — 2026-08-28 ===
NIST CCVS85 Sequential I/O (SQ) alcanza 84 de 85 en ejecución — aserciones 595 PASS / 25 FAIL -> 623 PASS / 1 FAIL (99,8 %) — con todos los programas corriendo ya hasta el final. La compilación sigue en 85 de 85 para SQ y 422 de 434 para el conjunto completo; Nucleus sigue en 95 de 95 en ambos ejes, 4 614 aserciones, ninguna fallida. El único miembro aún corto, SQ203A, necesita XXXXD001 — un fichero de datos que suministra la instalación del CCVS85. Ningún miembro del conjunto lo escribe, así que la mitad "fichero presente" de su prueba de SELECT OPTIONAL no puede correr aquí; la mitad "fichero ausente" pasa.
• Corregido — una cláusula LINAGE puede nombrar elementos de datos, no solo números
Código:
FD PRINT-FILE
LINAGE LINAGE-CTR
FOOTING FOOT-CTR
TOP TOP-CTR
BOTTOM BOTTOM-CTR.
Cada parte de la cláusula puede nombrar un elemento en lugar de declarar un entero, de modo que un programa puede dimensionar su página en tiempo de ejecución. Exigir enteros hacía que la cláusula entera no parseara, y el fichero quedaba entonces sin página alguna: AT END-OF-PAGE nunca podía hacerse verdadero, así que un informe escrito con WRITE PRINT-REC AFTER ADVANCING 1 LINE AT END-OF-PAGE PERFORM PAGE-TRAILER END-WRITE, en bucle hasta el fin de página, no paraba nunca. Los NIST SQ208M y SQ210M escribieron cada uno gigabytes antes de que el arnés los matara; ambos corren ahora hasta el final. La página se mide a partir de los elementos nombrados en cada escritura, así que cambiar uno entre escrituras cambia la página.
• Añadido — flagging de conformidad para los elementos de E/S secuencial
nist_conformance flag informa de las construcciones que COBOL-85 lista como obsoletas o por encima del subconjunto alto. Los elementos de E/S secuencial no se detectaban en absoluto; ahora se detectan todos, sin ningún flag espurio en todo el conjunto.
- Obsoletos — RERUN, MULTIPLE FILE TAPE, LABEL RECORDS, VALUE OF, DATA RECORDS, OPEN ... REVERSED.
- Por encima del subconjunto alto — SELECT OPTIONAL, RESERVE, PADDING CHARACTER, RECORD DELIMITER, SAME AREA, MULTIPLE FILE TAPE, BLOCK CONTAINS n TO m (el fijo BLOCK CONTAINS n está dentro del subconjunto), RECORD VARYING, LINAGE, VALUE OF, CLOSE ... FOR REMOVAL, OPEN/CLOSE ... WITH NO REWIND, CLOSE ... WITH LOCK, OPEN ... REVERSED, OPEN EXTEND, READ ... NEXT RECORD, WRITE ... AT END-OF-PAGE.
Nada de esto cambia lo que compila o corre: cada construcción listada sigue funcionando exactamente igual que antes. El flagging solo informa de dónde la sitúa el estándar, y sigue siendo un punto de entrada opcional y no parte de una compilación ordinaria. SQ302M pasa de 0 -> 4 de 4, SQ303M de 0 -> 2 de 2 y SQ401M de 0 -> 18 de 18; NC401M no cambia: 40 de 40.
=== PowerRustCOBOL 1.62.47 — 2026-08-29 ===
NIST CCVS85 Sequential I/O (SQ) está completo — 85 de 85 en ambos ejes —, con las aserciones en 624 PASS / 0 FAIL (100 %), desde 623 PASS / 1 FAIL. Nucleus no se mueve: 95 de 95 en ambos ejes, 4 614 aserciones, ninguna fallida, y el censo de compilación del conjunto completo sigue en 422 de 434.
El último miembro, SQ203A, prueba SELECT OPTIONAL con el fichero tanto presente como ausente. La mitad presente lee XXXXD001, un fichero de datos que suministra la instalación del CCVS85 — ningún miembro del conjunto lo escribe, así que en un directorio recién creado esa mitad no podía correr en absoluto y el programa informaba, correctamente, de la ausencia como un fallo.
El arnés de pruebas planta ahora el fichero, de la misma manera en que ya suministra los mazos de operador, los ajustes de interruptores externos y la tarjeta RERUN XXXXX053. El registro es del propio conjunto, no de las aserciones: el READ-TEST-GF-04 del propio SQ203A construye unos párrafos más adelante un fichero exactamente de esta forma para SQ-FS3, y cada campo se fija tal como lo fija ese párrafo contra el esqueleto FILE-RECORD-INFO del programa. Solo dos difieren, ambos forzados por cuál es este fichero: XFILE-NAME nombra SQ-FS1, y RECORDS-IN-FILE dice 1 porque el fichero contiene un registro.
Tres pruebas fijan el registro: que es exactamente un registro ASCII de 120 bytes (un byte de más caería pasado todo lo que SQ203A lee, dando por bueno un fichero malformado), que cada campo nombrado está donde lo colocan las anchuras PICTURE del esqueleto, y que ningún otro miembro recibe un fichero plantado. El comportamiento del runtime no cambia: esta versión mueve la medición, no el compilador.
=== PowerRustCOBOL 1.62.48 — 2026-08-29 ===
NIST CCVS85 Indexed I/O (IX) sube de 13 a 16 de 42 en ejecución — aserciones 341 PASS / 439 FAIL -> 354 PASS / 424 FAIL — sin ningún cambio en el runtime. Esta versión corrige la medición, no el compilador.
Unos pocos programas del CCVS85 son la segunda mitad de una pareja: leen un fichero de datos que escribió un miembro anterior, y cada uno lo dice en el comentario de su propia cabecera. IX110A abre con "THE ROUTINE USES THE FILE IX-FS3 WHICH HAS BEEN CREATED BY IX109", y una docena de miembros IX comparten el fichero XXXXX024 que escribe IX109A. El arnés ejecutaba cada programa en un directorio propio, así que cada consumidor abría un fichero que no estaba y reportaba, correctamente, la ausencia como fallo. IX110A puntúa 2 FAIL / 2 PASS en solitario y 4 PASS / 0 FAIL con su productor ejecutado primero, contra un runtime sin cambios.
Cada miembro de este tipo declara ahora su productor, citado de su propia cabecera, y el arnés ejecuta ese productor — transitivamente — dentro del directorio del consumidor primero. Diez miembros declaran uno: IX102A, IX110A, IX114A–IX120A e IX202A.
Compartirlo todo habría sido un error, y medirlo lo zanjó: dar a un módulo entero un único directorio compartido llevó IX a 15, pero rompió miembros que necesitan que un fichero esté ausente — IX111A ("THIS PROGRAM USES THE FILE IX-NOP WHICH DOES NOT EXIST", esperando el estado 35) e IX216A (OPEN EXTEND sobre un fichero OPTIONAL, esperando 05) se pusieron en rojo contra restos de otros programas. Una instalación validadora borra los ficheros entre programas salvo donde un miembro declara que hereda uno, que es lo que la tabla codifica — así que todos los demás programas conservan el directorio limpio que tenían. Dos pruebas guardan la tabla: que ninguna cadena de productores forma ciclos ni deja de terminar, y que un miembro autocontenido no declara nada — IX111A, IX112A, IX113A e IX216A entre ellos, donde un fichero plantado es exactamente lo que la prueba prohíbe.
Nucleus y Sequential I/O no se mueven: NC 95/95 y SQ 85/85 en ambos ejes, 4 614 y 624 aserciones, ninguna fallida.
=== PowerRustCOBOL 1.62.49 — 2026-08-29 ===
Los ficheros indexados obedecen las reglas de ordenación del modo de acceso secuencial — NIST CCVS85 Indexed I/O (IX) pasa de 16 a 19 de 42 en ejecución, aserciones 354 PASS / 424 FAIL -> 358 PASS / 420 FAIL. Tres reglas de COBOL-85 que un fichero INDEXED declarado ACCESS MODE IS SEQUENTIAL no estaba imponiendo:
- WRITE exige orden ascendente de RECORD KEY. Una clave que no es mayor que la anterior es el estado 21 y el registro no se escribe. Una escritura rechazada no hace avanzar la secuencia, así que la clave siguiente se juzga contra la última clave realmente escrita. Bajo acceso RANDOM o DYNAMIC se sigue permitiendo cualquier orden, y un choque con un registro existente sigue siendo 22.
- REWRITE reemplaza el registro que entregó el READ anterior, así que tiene que haber uno: sin un READ ejecutado con éxito inmediatamente antes, el estado es 43. El REWRITE consume el registro, así que un segundo REWRITE sin un READ intermedio es 43 otra vez.
- DELETE sigue la misma regla, y es 43 en los mismos términos.
START posiciona el fichero pero no entrega registro, así que un REWRITE o DELETE tras uno sigue siendo 43 — igual que la primera sentencia de ese tipo tras OPEN, tras un WRITE y tras un READ sin éxito. Esto es lo que IX120A comprueba reescribiendo con sus READ comentados y esperando que su declarativa USE AFTER EXCEPTION se entre con el estado 43, y lo que IX109A comprueba escribiendo las claves 1...50 y luego la 49. IX109A, IX119A e IX120A corren ahora limpios.
Cinco pruebas cubren las reglas directamente, incluida que una escritura rechazada deja el fichero sin cambios y que el acceso DYNAMIC no se ve afectado. Nucleus y Sequential I/O no se mueven: NC 95/95 y SQ 85/85 en ambos ejes, 4 614 y 624 aserciones, ninguna fallida. La compilación del conjunto completo sigue en 422 de 434.
=== PowerRustCOBOL 1.62.50 — 2026-08-29 ===
• Las claves de registro de un fichero se distinguen por su calificador OF/IN
Las aserciones de Indexed I/O de NIST CCVS85 pasan de 358 PASS / 420 FAIL a 361 PASS / 417 FAIL; los programas que ejecutan limpio se mantienen en 19 de 42. COBOL permite que un fichero declare varias claves cuyos data-names son idénticos y que solo se separan por el grupo en el que se encuentra cada una. IX-FD3 de IX215A hace exactamente eso: RECORD KEY IS IX-FD3-KEY IN IX-FD3-RECKEY-AREA, y después dos claves alternas también llamadas IX-FD3-KEY, calificadas en IX-FD3-ALTKEY1-AREA e IX-FD3-ALTKEY2-AREA. El parser descartaba el calificador y toda búsqueda iba por el nombre a secas, así que las tres claves resolvían al primer campo: el fichero llevaba tres índices sobre un mismo conjunto de bytes, y una lectura por una clave alterna buscaba su valor en los caracteres de la clave primaria.
El calificador forma ahora parte de la identidad de la clave de extremo a extremo:
- El parser conserva la cadena OF/IN escrita tras RECORD KEY IS y tras cada ALTERNATE RECORD KEY IS.
- La disposición de bytes del registro anota los grupos que contienen cada campo, de modo que un campo puede encontrarse por nombre y por ascendencia. La coincidencia es por contención, como exige el estándar — B OF D nombra el campo incluso cuando está en B, dentro de C, dentro de D — y un nombre sin calificar sigue tomando el primer campo con ese nombre.
- Leer y escribir un campo pasa por su clave de almacenamiento calificada, así que un registro que tiene el mismo nombre en varios grupos ya no dirige todos ellos al que casualmente quedó almacenado bajo el nombre a secas.
- READ … KEY IS y START … KEY IS eligen la clave de referencia por data-name y calificador juntos, que es lo único que distingue las tres claves de IX-FD3.
Una clave cuyo calificador no nombra ningún grupo de la disposición sigue resolviendo por el nombre a secas, así que nada de lo que funcionaba antes se pierde. Nucleus y Sequential I/O no se mueven: NC 95/95 y SQ 85/85 en ambos ejes, 4 614 y 624 aserciones, ninguna fallando. La compilación de la suite completa sigue en 422 de 434, y la suite de cobolt-runtime está en verde.