- 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.
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
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
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
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.
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:
Código:
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:
Código:
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.