[Eslopes]

Indexed I/O de NIST CCVS85 pasa de 28 a 29 de 42 programas ejecutando limpio. Un READ secuencial tiene AT END, que es el estado 10 y nada más; uno con clave tiene INVALID KEY, estados 21-24. Cualquier otro error — 30, 47, 48, 49, 92 — es uno que la sentencia no puede manejar: no corre ninguna de las dos frases y lo atiende la declarativa USE del fichero.

La frase de fallo se estaba ejecutando para cualquier estado distinto de cero, y ejecutarla contaba además como haber manejado la condición, lo que suprimía la declarativa. Así, un READ de un fichero que nunca se abrió tomaba el camino de AT END e IX114A nunca veía su manejador para el estado 47. El caso del 46 ya se había tratado como caso especial antes de esto; es la misma regla, ahora enunciada una sola vez.

Una aserción se movió en sentido contrario, y vale la pena decirlo con claridad. IX203A pasó de 8 fallos a 9. Su bucle de recorrido es READ IX-FD1 NEXT RECORD AT END GO TO ... con una válvula de seguridad tras 501 iteraciones, y su READ NEXT falla en todas las llamadas — el área de registro nunca se llena. La frase AT END atrapaba ese primer fallo y salía temprano del bucle; desaparecido el enmascaramiento, el bucle corre hasta su válvula y cuenta 502 registros que nunca recibió. El defecto siempre estuvo ahí y ya hacía fallar tres aserciones; una cuarta ahora lo informa con verdad. Queda registrado como el primer elemento de trabajo y es el mayor grupo restante — la misma familia de READ NEXT suma nueve fallos en cada uno de IX208A e IX209A. 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.

=== PowerRustCOBOL 1.62.65 — 2026-08-29 ===
• IX203A declara su productor y completa la cadena IX2xx

Fidelidad del arnés de pruebas; sin cambio en el runtime. Las aserciones de Indexed I/O de NIST CCVS85 van de 518 PASS / 70 FAIL -> 521 PASS / 67 FAIL, con IX203A cayendo de 9 fallos a 6. Los programas ejecutando limpio se mantienen en 29 de 42. La cabecera de IX203A dice "THE FILE USED IS THAT RESULTING FROM IX202" — la serie IX2xx refleja la IX1xx: un miembro crea el fichero y los dos siguientes lo procesan. Solo estaba registrado IX202A <- IX201A, así que IX203A corría en un directorio vacío y cada READ ... NEXT RECORD fallaba por falta de fichero.

Esto corrige un diagnóstico, no solo una puntuación. La entrega anterior registró "el READ NEXT de IX203A nunca tiene éxito" como el mayor defecto de runtime restante, razonando a partir de un recorrido que contaba 502 registros que nunca recibió. El síntoma era real y la causa era errónea: no había ningún bug de READ NEXT, solo un fichero ausente. El libro de registro ahora lo dice explícitamente, para que ninguna sesión futura salga a buscar uno. Lo que queda en IX203A es la familia DELETE-TEST-GF — seis fallos que citan IX-21 4.3.2, incluidos un desajuste de clave y un registro incorrecto encontrado.

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.

=== PowerRustCOBOL 1.62.66 — 2026-08-29 ===
• La reanudación tras un DELETE se decide por qué registro sale, no por cómo se direccionó — y un START o un READ con clave descartan la que esté pendiente

Indexed I/O de NIST CCVS85 pasa de 29 a 30 de 42 programas ejecutando limpio; aserciones 521 PASS / 67 FAIL -> 528 PASS / 60 FAIL (88.6 % -> 89.8 %). IX203A cae de seis fallos a uno, e IX212A e IX213A quedan limpios. Son dos correcciones al trabajo de cursores de 1.62.58.

Post añadido a las 10:00. Post anterior a las 09:59

La guarda comprobaba lo equivocado. Un recorrido bajo ACCESS MODE IS DYNAMIC lee con READ NEXT y luego borra, y ese borrado se direcciona por clave — pero el registro que sale sigue siendo aquel sobre el que está el cursor, así que la ranura del B+tree se desplaza bajo él exactamente igual que en la forma secuencial. Guardar sobre "¿fue un borrado con clave?" lo pasaba por alto por completo: el recorrido de IX203A perdía 96 de 500 registros y 24 de sus 125 borrados. La condición ahora es si el registro que se borra es el actual del cursor, lo que cubre ambas formas y sigue dejando en paz un borrado con clave de algún otro registro.

Una reanudación pendiente vivía más de la cuenta. La reanudación dice "continúa después del registro que acaba de salir"; un START dice dónde está el fichero ahora, y debe ganar. Nada la limpiaba, así que el START ... KEY IS EQUAL de IX213A quedaba anulado y el READ siguiente informaba FILE IS AT END en lugar del registro sobre el que se había posicionado. START y un READ con clave la descartan ahora. Los motores en memoria y redb llevan sus cursores por clave y nada de esto les afecta. 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.

=== PowerRustCOBOL 1.62.67 — 2026-08-29 ===
• Dos operandos numéricos se comparan algebraicamente, sin importar cómo se llenaron sus posiciones

Indexed I/O de NIST CCVS85 pasa de 30 a 32 de 42 programas ejecutando limpio y supera el noventa por ciento de aserciones — 528 PASS / 60 FAIL -> 528 PASS / 58 FAIL, 89.8 % -> 90.1 %. Un MOVE de grupo es un movimiento alfanumérico: transfiere caracteres y no convierte nada, así que un hijo PIC 9(6) acaba conteniendo legítimamente la cadena "000007". El ítem sigue siendo numérico y una relación entre dos operandos numéricos sigue siendo algebraica — pero nada devolvía el valor a forma numérica. Cuando ambos lados de una comparación se habían llenado así, ninguno parecía numérico, el pseudo-move no se aplicaba y se comparaban las dos cadenas de presentación: "000000007" contra "000007", desiguales.

Un lado contra un numérico con valor de literal siempre era correcto, y por eso pasó desapercibido. IX103A e IX203A comprueban ambos un número de registro contra los dígitos incrustados en la clave de ese registro, y veían cada uno de los 500 registros como un desajuste. Ahora un operando numérico se relee a través de su propia PICTURE antes de la comparación. La escala del ítem decide el valor — los mismos seis caracteres son 123456 en un PIC 9(6) y 1234.56 en un PIC 9(4)V99 — así que las posiciones decimales declaradas se llevan en el símbolo y se usan aquí. Una posición que contiene algo que no es una ristra de dígitos se deja exactamente como está; inventar un número sería peor que comparar lo que hay.

Este es el núcleo de expresiones por el que pasa Nucleus, y fue el primer cambio de esta tanda con alcance real más allá de los ficheros indexados. Ambas líneas base protegidas están exactas: NC 95/95 con 4 614 PASS / 0 FAIL, SQ 85/85 con 624 PASS / 0 FAIL. La compilación de la suite completa sigue en 422 de 434.

=== PowerRustCOBOL 1.62.68 — 2026-08-29 ===
• Una clave genérica de START puede nombrar un ítem subordinado de una clave alternativa

Indexed I/O de NIST CCVS85 pasa de 32 a 35 de 42 programas ejecutando limpio; aserciones 528 PASS / 58 FAIL -> 550 PASS / 33 FAIL (90.1 % -> 94.3 %). IX209A, IX210A e IX214A quedan limpios, e IX215A cae de ocho fallos a dos. El operando de START ... KEY IS no tiene por qué ser la clave misma. Un ítem que empieza donde empieza una clave y es más corto que ella nombra esa clave y busca por el prefijo — la forma genérica, implementada para la clave primaria en 1.62.55. El START-TEST-GF-23 de IX209A lo dice sin rodeos: "AN OPERAND IN THE KEY PHRASE WHICH IS NOT THE NAME OF AN ALTERNATE KEY BUT IS THE NAME OF A DATA ITEM WHICH IS SUBORDINATE TO THE ALTERNATE KEY."

Post añadido a las 10:01. Post anterior a las 10:00

La selección de la clave de referencia solo casaba con una extensión de bytes exacta, lo que es correcto para un REDEFINES de una clave pero erróneo para un ítem subordinado: al ser más corto, no casaba con nada y se caía a la clave 0, buscando en el índice primario los caracteres de una clave alternativa. Cada START de esa forma tomaba el camino de INVALID KEY. Una extensión exacta sigue ganando donde la hay, de modo que una clave que resulta ser la parte más a la izquierda de una clave más larga se resuelve a sí misma y no a su contenedor.

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.

=== PowerRustCOBOL 1.62.69 — 2026-08-29 ===
• AT END hace secuencial un READ incluso donde el modo de acceso no lo haría

AT END pertenece al READ secuencial e INVALID KEY al de clave, y NEXT es opcional en el formato secuencial. Un READ ... AT END bajo ACCESS MODE IS DYNAMIC es por tanto secuencial: continúa desde donde un START dejó el fichero, en lugar de releer por RECORD KEY. KEY IS sigue forzando sin más la forma con clave.

Sin movimiento en la puntuación NIST, y vale la pena decirlo con claridad. El programa que motivó el cambio, IX208A, declara ACCESS MODE IS SEQUENTIAL, así que sus lecturas ya eran secuenciales y esto no las toca. La corrección se conserva porque está validada por sí misma — un START ... KEY IS GREATER seguido de READ ... AT END bajo DYNAMIC ahora avanza a los dos registros siguientes donde antes volvía a entregar el registro que la clave aún nombraba. El defecto real de IX208A queda registrado en su lugar, con tres causas descartadas con evidencia: no es el formato del READ, no es un productor ausente y no es la forma simple de la construcción, que una repro recorre correctamente.

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. IX se mantiene en 35 de 42, 550 PASS / 33 FAIL. La compilación de la suite completa sigue en 422 de 434.

=== PowerRustCOBOL 1.62.70 — 2026-08-29 ===
• Los opt-codes T y U de CCVS85 son mutuamente excluyentes, y el harness ahora selecciona T.

El módulo Indexed I/O de NIST CCVS85 pasa de 35 a 37 de 42 programas ejecutando limpio; las aserciones van de 550 PASS / 33 FAIL a 561 PASS / 20 FAIL (94.3 % -> 96.6 %). IX207A e IX208A quedan limpios. Una línea de CCVS85 puede llevar una letra de opt-code en la columna de indicador, y la tarjeta *OPT de la instalación dice cuáles están activas. La mayoría de las letras marcan añadidos inocuos de incluir, y el harness las tomaba todas. T y U son distintas: son alternativas, y tomar ambas produce un registro más largo de lo que cualquiera de las dos lecturas pretende.

El caso más claro es IX-FS2R1-F-G-240 de IX208A. Su propio nombre dice 240 caracteres; con T sola mide 240, con U sola mide 240, y con ambas mide 250 — cada campo posterior a la primera clave desplazado cinco posiciones, razón por la que START sobre su clave alternativa se salía del final del fichero y fallaban ocho aserciones. T es la lectura para la que estos programas están escritos: IX208A construye WRK-IX-FS2-ALTKEY a partir de una línea T más un número de cinco dígitos, con lo que mide diez caracteres — la misma forma que IX-FS2-ALTKEY1 bajo T y no bajo U. El programa mueve uno dentro del otro antes de cada START, así que tienen que coincidir.

Hay exactamente diez líneas U en toda la suite, en IX107A, IX207A e IX208A. Ningún miembro de otro módulo lleva ninguna, de modo que un módulo terminado no puede verse perturbado — y no lo fue. La letra se sustituye por * en lugar de eliminarse, de modo que cada columna posterior conserva su posición. 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.

=== PowerRustCOBOL 1.62.71 — 2026-08-29 ===
• El compilador señala las construcciones de Indexed I/O que están por encima del subconjunto alto.

Post añadido a las 10:03. Post anterior a las 10:01

El módulo Indexed I/O de NIST CCVS85 pasa de 37 a 38 de 42 programas ejecutando limpio; las aserciones van de 561 PASS / 20 FAIL a 567 PASS / 14 FAIL (96.6 % -> 97.6 %). IX401M pasa de cinco errores a ninguno. Un miembro 4nn de CCVS85 no tiene maquinaria de PASS/FAIL: su veredicto son los diagnósticos que emite el compilador. IX401M enumera diez construcciones que espera ver señaladas como por encima del subconjunto alto, y cinco no se detectaban:

- ACCESS MODE IS DYNAMIC — el modo que permite leer un fichero de las dos maneras en una sola apertura, cuando el subconjunto solo tiene SEQUENTIAL y RANDOM.
- ALTERNATE RECORD KEY — una segunda clave sobre el fichero.
- RECORD IS VARYING IN SIZE — ya se señalaba, pero solo escrita sin IS: SQ401M escribe RECORD VARYING, IX401M escribe RECORD IS VARYING IN SIZE FROM 18 TO 36 CHARACTERS, y la palabra intermedia es opcional. Añadir una segunda regla para la forma larga emitía dos señalizaciones sobre la única cláusula de SQ401M, lo que consumía una expectativa de más y desalineaba su última señalización — la regla existente ahora acepta el IS opcional.
- READ ... KEY IS y START ... KEY IS — nombrar la clave de referencia, algo que solo necesita un fichero con más de una clave.

Nucleus y Sequential I/O no se mueven ni en los dos ejes ni en su propia señalización: NC 51 señalizaciones coincidentes / 0 erróneas, SQ 24 / 0, NC 95/95 con 4 614 PASS / 0 FAIL, SQ 85/85 con 624 PASS / 0 FAIL. La compilación de la suite completa sigue en 422 de 434. IX301M se deja fallando a propósito y queda registrado como cuestión de alcance: prueba la señalización del subconjunto intermedio, y cada construcción que nombra — ORGANIZATION IS INDEXED, ACCESS MODE IS RANDOM, RECORD KEY IS, las frases NOT INVALID KEY — es una que PowerRustCOBOL implementa. Un compilador de subconjunto alto no debe señalarlas.

=== PowerRustCOBOL 1.62.72 — 2026-08-29 ===
• IX301M queda excluido de la puntuación de ejecución (decisión del operador).

El módulo Indexed I/O de NIST CCVS85 se puntúa ahora sobre 41 y queda en 38 de 41, con aserciones 566 PASS / 8 FAIL — 98.6 %. La propia cabecera de IX301M dice lo que es: "TESTS THE FLAGGING OF INTERMEDIATE SUBSET FEATURES THAT ARE USED IN LEVEL 1 INDEXED INPUT-OUTPUT". Cada construcción que espera ver señalada — ORGANIZATION IS INDEXED, ACCESS MODE IS RANDOM, RECORD KEY IS y las frases NOT INVALID KEY — es una que PowerRustCOBOL implementa.

Un compilador que valida en el subconjunto alto no debe señalar una característica que soporta, así que esas siete expectativas son inalcanzables por diseño y no por defecto. Solo una validación de subconjunto mínimo las satisfaría. Compárese con IX401M, que pide señalización del subconjunto alto y puntúa 10 de 10. La exclusión afecta solo a la puntuación de ejecución: IX301M es COBOL perfectamente válido, compila limpio y sigue contando en el censo strict — que se mantiene en 422 de 434, sin moverse.

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. Quedan registradas en el ledger dos decisiones más del operador que entran en vigor a continuación: Relative I/O comienza ahora en lugar de después de IX, y redb pasa a ser el motor de disco por defecto para que el orden de recuperación de duplicados pueda corregirse allí en lugar de mediante un cambio de formato de PRCIDXD1.

=== PowerRustCOBOL 1.62.73 — 2026-08-29 ===
• redb pasa a ser el motor por defecto de ficheros indexados para STORAGE IS DISK (decisión del operador), y se corrigen dos defectos suyos de longitud de registro.

Post añadido a las 10:04. Post anterior a las 10:03

El módulo Indexed I/O de NIST CCVS85 pasa de 38 a 39 de 41; las aserciones van de 566 PASS / 8 FAIL a 568 PASS / 6 FAIL — 99.0 %. El cambio se hizo para resolver el orden de recuperación de duplicados. Cuando un REWRITE cambia el valor de una clave alternativa, el registro abandona un conjunto de duplicados y se une a otro, y debe ocupar su lugar al final del nuevo. PRCIDXD1 ordena los duplicados por RecordId, que es permanentemente el orden de escritura original, así que corregirlo allí habría exigido un cambio de formato del contenedor. redb ya mantiene una tabla seq exactamente para esto, e IX211A queda limpio sobre él.

Medir el cambio antes de hacerlo descubrió dos defectos propios, ambos de una sola palabra: fit redimensionaba cada registro a la anchura declarada en la FD, truncando cualquiera más largo — el motor de disco siempre ha usado record_len.max(rec.len()): la anchura declarada es un suelo, no un techo, y un fichero cuyos registros varían almacena cada uno con su propia longitud —, y decode_value hacía lo mismo a la vuelta, de modo que un registro almacenado entero se devolvía igualmente recortado. IX105A escribe registros largos y los relee comprobando la longitud; reportó "WRONG LENGTH OR WRONG RECORD" cuatro veces bajo redb y pasaba bajo PRCIDXD1. Ambos motores coinciden ahora.

El alias de motor default sigue al valor por defecto en lugar de quedar fijado a rust, y rcrun --indexed-engine rust sigue seleccionando PRCIDXD1 para quien lo quiera. Nucleus y Sequential I/O son exactos sobre el nuevo motor por defecto: NC 95/95 con 4 614 PASS / 0 FAIL, SQ 85/85 con 624 PASS / 0 FAIL. La compilación de la suite completa sigue en 422 de 434; 132 tests de librería del runtime y 95 suites de integración en verde.

=== PowerRustCOBOL 1.62.74 — 2026-08-29 ===
• Un REWRITE que cambia una clave alternativa se incorpora al final de su nuevo conjunto de duplicados.

El módulo Indexed I/O de NIST CCVS85 alcanza 40 de 41 — aserciones 570 PASS / 4 FAIL, 99.3 %. El único miembro que sigue fallando es IX106A, que necesita un motor RELATIVE. Un registro cuyo valor alternativo cambia abandona un conjunto de duplicados y entra en otro. No puede conservar posición en un conjunto al que acaba de unirse, así que ocupa su lugar al final. El motor reutilizaba la secuencia de inserción original del registro, lo que lo colocaba donde hubiera caído su inserción en el fichero.

IX215A gira exactamente sobre esto. Una prueba reescribe el registro 176 hacia un valor duplicado; la siguiente reescribe el registro 4 hacia ese mismo valor; un START sobre ese valor debe entregar entonces 176, cuya entrada se unió primero — aunque el registro 4 se escribió antes en el fichero. Entregaba 4.

Se almacena una secuencia por registro en lugar de por alternativa, y la eliminación reconstruye el valor del multimapa a partir de ella, de modo que cuando cambia cualquier alternativa el registro toma una secuencia nueva y todas sus entradas se reapuntan a ella. El coste es que una alternativa sin cambios también se mueve al final de su propio conjunto; una secuencia por alternativa lo evitaría, al precio de recorrer el multimapa para recuperar el valor de cada entrada al eliminar. Nada en la suite observa la diferencia. 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; 132 tests de librería del runtime y 95 suites de integración en verde.

=== PowerRustCOBOL 1.62.75 — 2026-08-29 ===
• RELATIVE KEY IS se analiza y se traslada al runtime, y Relative I/O queda con su línea base medida.

Primer paso de la construcción de RL; todavía sin movimiento en la puntuación, porque nada consume la clave. RELATIVE KEY IS data-name nombra el número entero de registro por el que se direcciona un fichero relativo. A diferencia de una RECORD KEY, no forma parte del registro: el programa lo establece antes de un READ/WRITE aleatorio, y el runtime lo rellena en una lectura secuencial. Ahora llega a FileControl y al registro de ficheros del runtime.

Post añadido a las 10:06. Post anterior a las 10:04

Esto repara además un defecto introducido en 1.62.60. Hacer opcional ORGANIZATION IS añadió un brazo de cláusula para un RELATIVE a secas, y ese brazo se tragaba RELATIVE KEY IS RL-KEY como si fuera una cláusula de organización, descartando la clave por completo. La palabra KEY después de RELATIVE es lo que distingue ambos casos.

Línea base de RL, medida por primera vez: 14 de 35 ejecutando limpio, 196 PASS / 140 FAIL (58.3 %). Cuatro miembros — RL102A, RL109A, RL202A y RL207A — agotan el tiempo en lugar de fallar, que es el bucle ya registrado: un READ que da error dentro del bucle ordinario de GO TO se repite para siempre, y sin motor RELATIVE toda lectura da error. Nucleus, Sequential I/O e Indexed I/O no se mueven: NC 95/95, SQ 85/85, IX 40/41, con 4 614, 624 y 570 aserciones pasando. La compilación de la suite completa sigue en 422 de 434.

=== PowerRustCOBOL 1.62.76 — 2026-08-29 ===
• ORGANIZATION IS RELATIVE funciona.

Relative I/O era aceptado por el parser y luego silenciosamente ignorado por el runtime — un programa que lo declaraba compilaba limpio y se comportaba mal. Ahora tiene motor, y cada verbo de fichero despacha hacia él. RL pasa de 14 a 24 de 35 ejecutando limpio, 326 PASS / 38 FAIL (el 89.6 % de sus aserciones, desde el 58.3 %), y los cuatro miembros que antes agotaban el tiempo ya no lo hacen. IX alcanza 42 de 42 compilando y 41 de 41 ejecutando limpio, 574 PASS / 0 FAIL — los últimos cuatro fallos de IX106A eran el fichero relativo que comparte con los indexados. Un fichero relativo es una tabla de ranuras numeradas, no una lista de registros: la ranura n contiene un registro o está vacía, y una ranura vacía conserva su número — borrar el registro 7 no renumera el 8. El número vive en el elemento RELATIVE KEY de WORKING-STORAGE y no dentro del registro, y por eso esto no podía ser un modo de los motores indexados: aquellos leen sus claves de los bytes del registro.

- WRITE — en modo de acceso secuencial el motor asigna la siguiente ranura y pone el número en el elemento RELATIVE KEY, que es como un programa que crea un fichero conoce sus propios números de registro. Bajo RANDOM o DYNAMIC el programa fija primero el número; una ranura ya ocupada es estado 22, y la ranura cero es 24.
- READ — aleatorio por RELATIVE KEY, o NEXT / PREVIOUS en orden de ranura, saltando las vacías. Una lectura secuencial informa de la ranura que entregó.
- START — se posiciona en la primera ranura que cumpla EQUAL / GREATER / NOT LESS (y las formas LESS) sin entregar registro, de modo que el siguiente READ NEXT la devuelve.
- REWRITE / DELETE — por número bajo acceso aleatorio o dinámico, o sobre el registro que entregó el último READ. Sin esa lectura el estado es 43. DELETE vacía la ranura y deja el número direccionable.

Dos contenedores, elegidos por STORAGE [MODE] IS MEMORY | DISK exactamente igual que eligen los suyos los motores indexados, y obligados a responder de forma idéntica: un BTreeMap en RAM, o el contenedor PRCREL1 — una cabecera fija seguida de ranuras de igual tamaño, de modo que la ranura n está a un solo seek de distancia y el fichero no necesita directorio en RAM. Cada ranura lleva un indicador de presencia y la longitud propia del registro, así que un fichero RECORD IS VARYING almacena un registro corto sin rellenarlo hasta la ambigüedad. El harness también aprendió los miembros encadenados de RL: cuatro de sus series son un creador, un actualizador y un verificador sobre un mismo fichero, y los cuatro programas que agotaban el tiempo eran consumidores ejecutándose donde su productor nunca se había ejecutado — el fichero faltaba, OPEN devolvía 35 y cada READ devolvía 47 dentro de un bucle GO TO. Diez miembros declaran ahora sus productores, como ya hacen los de IX.

=== PowerRustCOBOL 1.62.77 — 2026-08-29 ===
• Relative I/O queda terminado: 35 de 35 compilando, 34 de 34 ejecutando limpio, 354 PASS / 0 FAIL.