Ver Mensaje Individual
  #9
Antiguo 31 de agosto de 2026, 15:57
Eslopes
Creador de
PowerRustCOBOL
Guru de los Gurus: Por solidos y amplios conocimientos - Issue reason: Por ámplios conocimientos en la materia Concurso: Tercer puesto: Ganador/a del Tercer puesto en un concurso - Issue reason: Juego  Innovación: Por aportar innovaciones - Issue reason: Por aportar soluciones innovadoras 
Última Actividad 27.10.2026 07:38
Posts Posts: 396
Likes enviados Enviados: 31
Likes recibidos Recibidos: 172

=== PowerRustCOBOL 1.62.51 — 2026-08-29 ===
• La Guía del Desarrollador cubre el comportamiento de ficheros indexados publicado en 1.62.49 y 1.62.50
(GOLDEN RULE #3: un cambio observable por el desarrollador actualiza la guía.) Dos secciones nuevas en "Indexed files — a first-class resource":
- Qué cambia ACCESS MODE al escribir y actualizar. Las reglas de orden que impone SEQUENTIAL y que RANDOM/DYNAMIC no imponen: WRITE en orden ascendente de RECORD KEY o 21; REWRITE/DELETE solo inmediatamente después de un READ con éxito o 43. Con un ejemplo desarrollado y las tres trampas: un WRITE rechazado no avanza la secuencia, una clave igual es 21 y no 22, y START no satisface el requisito del READ. Lleva la advertencia de que 43 es de clase 4, así que una cláusula INVALID KEY no lo capturará.
- Distinguir claves con el mismo nombre mediante OF / IN. Declarar y usar claves que comparten data-name y difieren solo por su grupo, incluyendo que la calificación es por contención y no por parentesco inmediato.

Solo el canónico en inglés: la GOLDEN RULE #8 sigue suspendida, así que no se toca ningún fichero de traducción.

=== PowerRustCOBOL 1.62.52 — 2026-08-29 ===
• Un elemento REDEFINES ya no ocupa bytes propios en un registro FD
Las aserciones de Indexed I/O de NIST CCVS85 pasan de 361 PASS / 417 FAIL a 343 PASS / 133 FAIL, elevando la tasa de aciertos del 46.4 % al 72.1 %. IX215A por sí solo cae de 297 fallos a 15.

Un elemento que redefine es otra descripción de un almacenamiento que ya existe: no añade nada al registro y no desplaza lo que le sigue. La disposición del registro ignoraba REDEFINES por completo y daba a cada uno de esos elementos bytes propios, con lo que cada uno desviaba todos los campos posteriores en su anchura. IX-FD1 de IX215A describe una clave de registro de 13 bytes y, encima de ella, IX-REDF-RECKEY REDEFINES IX-FD1-KEY: el registro crecía 13 bytes, y las dos claves alternas declaradas después indexaban las columnas equivocadas de cada registro del fichero.

El recorrido de disposición coloca ahora el elemento que redefine en el offset del elemento redefinido y continúa donde el registro ya estaba. El objetivo se busca entre los hermanos ya colocados, de modo que una redefinición de una redefinición resuelve correctamente — IX-FD1 tiene una: R-REDF-RECKEY-1-7 REDEFINES R-RECKEY-1-7, a su vez dentro de un elemento que redefine la clave de registro. Un REDEFINES que nombra algo que no está en ese nivel se dispone donde caía, como antes. Tres tests fijan la disposición: que una redefinición comparte los bytes de su objetivo y el campo siguiente no se desplaza, que una redefinición de una redefinición resuelve en su propio nivel, y que se anotan los grupos que contienen cada campo para distinguir campos homónimos en grupos distintos. 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.

=== PowerRustCOBOL 1.62.53 — 2026-08-29 ===
• Un RECORD KEY que nombra un grupo ahora indexa los bytes de ese grupo
Las aserciones de Indexed I/O de NIST CCVS85 pasan de 343 PASS / 133 FAIL a 475 PASS / 122 FAIL, elevando la tasa del 72.1 % al 79.6 % — y el número de tests que los programas borran por fallar su propia preparación cae de 108 a 1, así que ahora se ejecuta de verdad una parte mucho mayor de la suite. La mayoría de las claves de registro en COBOL nombran un grupo, no un elemento elemental: la de IX214A es IX-FS1-KEY, tres elementos subordinados a lo largo de 13 bytes. La disposición del registro solo listaba los campos elementales, así que una clave de grupo no se encontraba en ninguna parte.



Post añadido a las 09:51. Post anterior a las 09:50


Fallaban dos cosas a la vez: el motor recurría a indexar el offset 0 del registro entero, con lo que cada clave del fichero cubría la imagen completa de 240 bytes del registro; y leer el valor de la clave no encontraba ningún elemento con ese nombre y devolvía espacios, así que START buscaba en el fichero una clave en blanco y devolvía 23 cada vez. El READ posterior entregaba el registro sobre el que casualmente estuviera el cursor, y el programa informaba "TEST IMPROPERLY INITIALIZED" y se borraba a sí mismo.

La disposición anota ahora la extensión de cada grupo junto a los campos elementales, y una clave resuelve a un grupo cuando ningún campo elemental coincide — los elementos elementales se buscan primero, así que nada que ya resolvía cambia. Los bytes de un grupo se piden como grupo, puesto que un grupo no tiene valor propio: sus caracteres son los de sus hijos, concatenados. Leer y escribir registros no se toca: solo la resolución de claves consulta las nuevas extensiones de grupo. 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.

=== PowerRustCOBOL 1.62.54 — 2026-08-29 ===
• El trabajo de conformidad NIST se convierte en un bucle reanudable en lugar de un relevo por sesión
Sin cambio de runtime; es infraestructura de proceso. Dos artefactos nuevos:
- NIST/progress.json — el libro de registro de conformidad, versionado en el repositorio y desde ahora la única fuente de verdad sobre el estado de la suite. Lleva las cifras de compilación y ejecución de cada módulo, las líneas base protegidas que todo cambio futuro debe preservar, una work_queue ordenada por prioridad con la evidencia y el esbozo de arreglo de cada elemento, una lista dead_ends para que una sesión nueva nunca reintente un enfoque fallido, y el historial de versiones. Sustituye a los ficheros HANDOFF-*.md escritos a mano, que se rederivaban desde cero en cada sesión y divergían.
- .claude/skills/nist-grind/SKILL.md — el protocolo del bucle, para que cada sesión y cada subagente arranquen idénticos: orientarse desde el libro de registro, tomar el primer elemento de trabajo, diagnosticar (fan-out permitido, solo lectura), reducir a una reproducción mínima, arreglar una sola cosa, probar, ejecutar la regresión completa, pasar la puerta de las líneas base protegidas, añadir un test de regresión, subir la versión, changelog, actualizar el libro de registro, commit, push, repetir.

La puerta es lo que hace seguro ejecutarlo sin supervisión: NC 95/95 con 4 614 PASS / 0 FAIL y SQ 85/85 con 624 PASS / 0 FAIL deben mantenerse tras cada cambio, y un arreglo que rompa una de ellas se revierte y se registra como callejón sin salida en lugar de perseguirse hacia delante. La skill codifica las trampas que esta suite ya ha tendido: invocaciones de cargo separadas para rcrun y el harness, que zsh no divide en palabras las variables sin comillas, que un test borrado no es un test que pasa, y que las limitaciones del harness parecen exactamente regresiones del runtime. Fusionar a main y publicar en el foro quedan fuera del bucle: ambos requieren una petición explícita.

=== PowerRustCOBOL 1.62.55 — 2026-08-29 ===
• START acepta una clave genérica (parcial)
Las aserciones de Indexed I/O de NIST CCVS85 pasan de 475 PASS / 122 FAIL a 481 PASS / 115 FAIL, del 79.6 % al 80.7 %. COBOL-85 permite que START … KEY IS <op> data-name nombre un elemento subordinado de la clave de registro — su parte más a la izquierda — y el fichero queda entonces posicionado sobre ese prefijo. En su lugar, la clave se rellenaba con espacios hasta la anchura completa, lo que rompía ambas relaciones: EQUAL TO sobre un elemento de cinco caracteres buscaba una clave de trece bytes terminada en ocho blancos — ningún registro la tiene, así que devolvía 23 cada vez, y el READ posterior entregaba el registro sobre el que casualmente estuviera el cursor — y GREATER THAN comparaba contra esos blancos y se detenía en el primer registro que compartía el prefijo en lugar de pasarlos todos.



Post añadido a las 09:53. Post anterior a las 09:51


El posicionamiento usa ahora el prefijo: EQUAL cae en el primer registro cuya clave empieza por el valor, GREATER THAN en el primero pasados todos los registros que lo comparten, y NOT LESS THAN en el primero cuyo prefijo lo alcanza. Nombrar la clave completa es el caso particular en el que el prefijo es la clave entera, así que el START ordinario no cambia. READ … KEY IS no se toca: solo START lee una clave de forma genérica. Arreglado en los tres motores indexados — el almacén en memoria, el B+tree PRCIDXD1 y el almacén redb — puesto que cada uno implementa el posicionamiento por su cuenta.

De esto depende el START-INITIALIZE-RECORD de IX214A; al fallar, el programa borraba sus propios tests en lugar de informar de ellos. La Guía del Desarrollador gana una sección "Positioning on part of a key". 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.

=== PowerRustCOBOL 1.62.56 — 2026-08-29 ===
• Una clave de referencia puede nombrarse a través de un REDEFINES
Las aserciones de Indexed I/O de NIST CCVS85 pasan de 481 PASS / 115 FAIL a 484 PASS / 112 FAIL, del 80.7 % al 81.2 %. Una clave es el almacenamiento que nombra, no el nombre en sí, y REDEFINES da a los mismos bytes un segundo nombre. IX215A declara ALTERNATE RECORD KEY IS IX-FD1-ALTKEY1 y luego hace START sobre IX-REDF-ALTKEY1 REDEFINES IX-FD1-ALTKEY1. Cotejar el operando de START/READ solo contra los nombres declarados dejaba esa sentencia en la clave de referencia 0 — buscando en el índice primario los caracteres de una clave alterna — así que tomaba el camino de INVALID KEY cada vez.

Cuando el operando no es uno de los nombres de clave declarados, su rango de bytes en el registro se compara ahora con la extensión de cada clave declarada, y un elemento que cubre exactamente los bytes de una clave es esa clave. Nombrar directamente una clave declarada sigue coincidiendo primero por nombre, así que nada de lo que funcionaba antes cambia.

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.

=== PowerRustCOBOL 1.62.57 — 2026-08-29 ===
• Una tarjeta X se identifica por su número, no por la letra en la posición 5
Fidelidad del harness de pruebas; sin cambio de runtime. El mazo CCVS85 escribe la tarjeta 24 de tres maneras — XXXXX024 (43 veces), XXXXP024 (6) y XXXXD024 (2) — y la propia cabecera de IX103A la lista una sola vez, como "X-24 INDEXED FILE IMPLEMENTOR-NAME IN ASSGN TO CLAUSE FOR DATA FILE IX-FS1". Una instalación en proceso de validación sustituye cada tarjeta por un único nombre de implementador, así que las tres grafías son un mismo fichero. El harness las dejaba como tres, lo que rompía en silencio una cadena que la suite declara: IX102A crea IX-FS1 como XXXXP024, IX103A procesa "THE FILE USED IS THAT RESULTING FROM IX102" como XXXXD024, y cada lectura secuencial daba AT END en la primera llamada porque el fichero que abría nunca se había escrito.

Las grafías P y D colapsan ahora sobre la canónica XXXXX nnn — los mismos ocho caracteres, porque un operando más corto arrastraría el área de secuencia de las columnas 73-80 al área de contenido de un mazo de formato fijo. XXXXY382 y XXXXY066 se dejan en paz: sus números no coinciden con ninguna otra tarjeta. IX103A entra además en la tabla de productores, citando su propia cabecera.



Post añadido a las 09:54. Post anterior a las 09:53


Las aserciones de IX pasaron de 484 PASS / 112 FAIL a 482 PASS / 114 FAIL, y eso es una ganancia, no una pérdida: el barrido de borrado de IX103A alcanza ahora 35 registros en lugar de morir en el primer READ, y dos aserciones que jamás se habían ejecutado ahora corren — y fallan con verdad. Un test que nunca corrió nunca estuvo pasando; los fallos restantes de IX103A son reales y son lo siguiente a arreglar. El libro de registro fija la regla que esto zanja: la puerta de regresión es absoluta para los módulos terminados y el censo de compilación, pero el módulo en curso puede puntuar legítimamente más bajo cuando la medición se vuelve más honesta — y eso debe declararse, nunca ocultarse ni revertirse para proteger una cifra. 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.58 — 2026-08-29 ===
• Borrar durante un recorrido secuencial ya no salta el registro siguiente
Un arreglo de conformidad COBOL-85 en el motor STORAGE IS DISK, demostrado con una reproducción reducida y fijado con un test de regresión. El cursor de lectura del motor de disco era un slot (página hoja, índice de entrada), y DELETE quitaba la entrada sin tocarlo. Una hoja de B+tree desplaza sus entradas a la izquierda al eliminar, así que el registro que estaba en idx + 1 cae en idx y el siguiente READ le pasa por encima. Un recorrido que borraba uno de cada cuatro de 20 registros solo veía 16 de ellos: cada borrado costaba un registro sin leer.

El recorrido se reanuda ahora desde la clave que había alcanzado, capturada antes de que los índices se muevan: reorganice lo que reorganice el borrado, "la entrada en esta clave o después de ella" nombra después el mismo registro que antes, cosa que un índice de slot no hace. Dos detalles que la medición obligó a precisar: la reanudación compara la clave almacenada completa, no sus primeros bytes de longitud de clave — una clave alterna WITH DUPLICATES lleva un id de registro al final, y una comparación por prefijo saltaba todos los registros que compartían el valor alterno en lugar de solo la entrada borrada; seis aserciones de IX215A dejaron de ejecutarse cuando esto entró por primera vez — y la reanudación solo se arma para la forma secuencial, en la que el registro borrado es el que el recorrido acaba de leer: un DELETE por clave elimina otro registro mientras el cursor está en otra parte, esa entrada sigue existiendo y avanzar desde su slot sigue siendo correcto. Los motores en memoria y redb usan claves en sus cursores y nunca estuvieron afectados.

Las puntuaciones NIST no cambian: IX 482 PASS / 114 FAIL, 19 de 42 — los programas que mostrarían esta ganancia todavía se detienen antes por otras razones (el fichero heredado de IX103A es corto, que es lo siguiente a perseguir). Es un defecto real arreglado por su propia evidencia, no un movimiento de puntuació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.59 — 2026-08-29 ===
• Una cadena de productores se ejecuta en el directorio del propio consumidor
Fidelidad del harness de pruebas; sin cambio de runtime. Indexed I/O de NIST CCVS85 pasa de 482 PASS / 114 FAIL a 483 PASS / 113 FAIL. run_producers hacía recursión con cada productor como nuevo objetivo y derivaba el directorio de trabajo de ese nombre, así que cada generación aterrizaba en un sitio distinto. IX103A hereda de IX102A, que hereda de IX101A: IX102A corría en un directorio donde IX101A nunca había corrido, procesaba un fichero vacío y dejaba tras de sí uno corto. El barrido de IX103A alcanzaba entonces 35 registros de 500 — mientras IX101A e IX102A informaban perfectamente limpios, porque cada uno hizo exactamente lo que se le pidió en el directorio que se le dio.



Post añadido a las 09:56. Post anterior a las 09:54


La cadena es ahora plana y del más antiguo al más nuevo, y cada miembro de ella corre en el único directorio que pertenece al consumidor. Las cifras del harness para IX103A coinciden ahora exactamente con una ejecución manual de IX101A -> IX102A -> IX103A.

Esto aísla un defecto real del runtime que estaba oculto tras el del harness: IX103A lee secuencialmente su fichero de 500 registros y cuenta 502 registros; un lector manual sobre el mismo fichero cuenta exactamente 500. El recorrido entrega dos de más. Es ahora el primer elemento de runtime, registrado con tres causas ya descartadas por la evidencia: no es el fichero, no es el cursor de borrado arreglado en 1.62.58 y ya no es la cadena. 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.60 — 2026-08-29 ===
• ORGANIZATION IS y la palabra KEY son palabras opcionales

El módulo Indexed I/O de NIST CCVS85 salta de 19 a 22 de 42 programas ejecutando limpio, con aserciones 483 PASS / 113 FAIL -> 512 PASS / 81 FAIL (81.0 % -> 86.3 %) — la mayor ganancia individual de esta tanda. COBOL-85 escribe las dos cláusulas como [ORGANIZATION IS] {SEQUENTIAL | LINE SEQUENTIAL | RELATIVE | INDEXED} y RECORD [KEY] [IS] data-name. Ambas partes entre corchetes pueden omitirse, e IX103A omite las dos — su cabecera lo dice sin rodeos: "SELECT ... INDEXED ... (WITHOUT THE OPTIONAL WORD <ORGANIZATION>)".

Ninguna de las dos omisiones hacía fallar la compilación, y eso es lo que hizo caro encontrar el problema. Un INDEXED a secas caía fuera del despacho de cláusulas y se descartaba, así que el fichero conservaba la organización SEQUENTIAL por defecto y un fichero indexado se abría como un simple flujo de bytes: un recorrido de un fichero de 500 registros entregaba 870 "registros" delimitados por saltos de línea. Un RECORD data-name a secas se descartaba igual, dejando el fichero sin clave alguna, de modo que el motor indexaba el registro completo y un OPEN de un fichero escrito con una clave real informaba del desajuste de esquema con el estado 39. RECORD DELIMITER IS empieza con la misma palabra y está excluida explícitamente, para que su operando no se confunda con una clave.

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 — estos programas siempre compilaron; simplemente hacían lo incorrecto.

=== PowerRustCOBOL 1.62.61 — 2026-08-29 ===
• Se implementa SAME RECORD AREA

Indexed I/O de NIST CCVS85 pasa de 22 a 24 de 42 programas ejecutando limpio; los fallos bajan de 81 a 79. Los ficheros nombrados juntos en una cláusula SAME [RECORD] AREA de I-O-CONTROL comparten una única área de registro: sus niveles 01 describen el mismo almacenamiento, así que un READ de cualquiera de ellos es visible a través de los nombres de registro de todos. IX205A enuncia la expectativa en su propia nota — "IN TESTING THE SAME AREA CLAUSE THE RECORD AREA SHOULD BE SHARED BY BOTH FILES IX-FD1 AND IX-FD2, THEREFORE FILE IX-FD2 IS READ AND THE RECORD IDENTIFIED FOR IX-FD1 IS ACCESSED" — e IX206A prueba lo mismo.



Post añadido a las 09:57. Post anterior a las 09:56


La cláusula no estaba modelada en ninguna parte: el parser leía FILE-CONTROL y dejaba el resto de la INPUT-OUTPUT SECTION a un cajón de sastre, así que el párrafo I-O-CONTROL entero se saltaba y la cláusula no hacía nada. Igual que con las palabras opcionales de 1.62.60, esto nunca hizo fallar una compilación — los programas construían limpio y, en silencio, hacían lo incorrecto. Ahora el AST lleva los grupos, el parser lee un párrafo I-O-CONTROL y sus cláusulas SAME, y un READ con éxito deposita la imagen del registro en las descripciones de registro de todos los ficheros que comparten el área. Las palabras calificadoras son todas opcionales en cualquier combinación — IX205A la escribe en su forma más abreviada, SAME RECORD IX-FD1 IX-FD2., sin AREA ni FOR. RERUN y las demás cláusulas de I-O-CONTROL se siguen consumiendo e ignorando, como antes. El SAME AREA a secas comparte además los búferes de los ficheros y restringe cuáles pueden estar abiertos a la vez; los miembros de aquí usan la forma RECORD con ambos ficheros abiertos, así que solo esa está implementada.

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.62 — 2026-08-29 ===
• SELECT OPTIONAL se aplica también a los ficheros con clave

Indexed I/O de NIST CCVS85 pasa de 24 a 27 de 42 programas ejecutando limpio; aserciones 512 PASS / 79 FAIL -> 517 PASS / 71 FAIL (86.6 % -> 87.9 %). Un fichero declarado SELECT OPTIONAL no necesita existir cuando el programa corre: se abre de todos modos y el programa se entera por el estado 05. Esa regla estaba escrita solo para la rama secuencial de OPEN. La rama INDEXED pasaba tal cual el estado del propio motor, así que un OPEN EXTEND de un fichero que no estaba informaba un 00 liso y el programa no podía distinguir los dos casos — IX216A comprueba exactamente esa distinción.

OPEN INPUT está incluido: el motor rechazaría de otro modo un fichero ausente con 35, así que el contenedor se materializa abriéndolo I-O y las lecturas lo encuentran entonces vacío y levantan AT END — la misma respuesta que ya da la rama secuencial, donde INPUT sobre un fichero OPTIONAL usa create(true). Un fichero que sí está presente sigue abriéndose con un 00 liso; 05 significa ausente-y-creado y nada más. Tres programas quedaron limpios donde se predijo uno — IX216A, IX217A e IX218A: los otros dos fallaban por la misma regla sin que se hubiera diagnosticado por separado.

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.63 — 2026-08-29 ===
• Un REWRITE secuencial no puede cambiar la clave del registro

Indexed I/O de NIST CCVS85 pasa de 27 a 28 de 42 programas ejecutando limpio; aserciones 517 PASS / 71 FAIL -> 518 PASS / 70 FAIL. En el modo de acceso secuencial un REWRITE reemplaza el registro que entregó el último READ, así que la clave que lleva debe seguir siendo la de ese registro. Una distinta levanta la condición INVALID KEY con el estado 21. Se estaba informando 92, un error de lógica — un código de implementador de clase 9 que ninguna frase INVALID KEY maneja y que IX119A, que espera 21 o 22, no podía aceptar.

Bajo acceso RANDOM o DYNAMIC el registro se direcciona por la clave que lleva, así que no hay nada con lo que discrepar y la regla no aplica; un REWRITE con clave no se ve afectado. Corregido en los tres motores indexados — el almacén en memoria, el B+tree PRCIDXD1 y el almacén redb — puesto que cada uno comprueba la clave por sí mismo.

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.64 — 2026-08-29 ===
• La frase condicional de una sentencia cubre una condición, no cualquier fallo
Eslopes is offline   Responder Con Cita