|
|||||||
| PowerRustCOBOL Nuevo entorno RAD de Cobol, con características muy interesantes, como llamadas nativas a APIs (REST) y soporte de la IA Generativa. Creado y mantenido por nuestro forero Eslopes |
|||||||
 |
3 de junio de 2026, 14:02
|
Forero Junior
 
|
Citación del post de Kuk
|
|||||||||
|
|
3 de junio de 2026, 22:35
|
Administrador
|
Chicos, acabo de enterarme de que PayPal ha cerrado la cuenta del foro, sin razón aparente...
 No sé qué opciones conocéis para poder transferir sin que sea complicado. @Eslopes, tú qué opciones conoces y prefieres ? NORMAS DEL FORO - para garantizar el buen funcionamiento del Foro.  ¿Te han ayudado? NO TE OLVIDES de darle a  ¿Quieres dirigirte a alguien en tu post? Notifícale  haciendo clic en su Nick |
||||||||
|
|
|
4 de junio de 2026, 03:08
|
Creador de
PowerRustCOBOL   
|
Donaciones de tiempo y dinero
Estimados,
He creado un repositorio en GitHub y he activado la función de donaciones. Para acceder al repositorio — y tener acceso al código fuente — es necesario que ustedes: Donaciones de dinero 1. Creen una cuenta en GitHub. Es gratuita. 2. Me informen el username creado, para que pueda liberar el acceso al repositorio (email para [email protected]). 3. En la página del repositorio, hagan clic en el botón Sponsor y realicen la donación. Donaciones de tempo Necesitamos es feedback sobre el producto: qué no funciona, qué no funciona como debería, qué debería existir y todavía no fue implementado. Cualquier problema encontrado debe ser publicado en el foro. El propio agente que estoy usando hará la lectura, confirmará los problemas y generará una lista de lo que necesita ser corregido, para que yo pueda revisarlo y aprobarlo. Las sugerencias serán analizadas en cuanto a su viabilidad y puestas a votación todas las semanas. Todo dependerá de cuánto logremos recaudar para acelerar el desarrollo. Usando la cuenta básica que tengo, esto puede llevar un año. Con la ayuda de todos, podremos reducir este tiempo a cerca de 1 a 3 meses (possivelmente). Haremos campañas constantes de recaudación, con Super Chat en YouTube los sábados, para hablar sobre el proyecto, responder dudas, hacer demostraciones, etc. Las donaciones también podrán hacerse por YouTube. El proyecto está en marcha, pero dado que esta es una actividad sin fines de lucro de mi parte, necesito concentrarme durante el horario laboral en mi trabajo principal. Por lo tanto, no esperen actividad de mi parte durante el horario comercial, de lunes a viernes. Dicho esto, ya se ha hecho mucho, y muchas cosas están en desarrollo. Así que pronto tendremos una versión alpha — luego beta, release candidate y, finalmente, una versión de producción. No hay garantías de que logremos implementar un proyecto de este tamaño con los servicios actuales de inteligencia artificial. Siempre existe la posibilidad de encontrar un bloqueo importante, pero hasta ahora todo está funcionando perfectamente. Una de las cosas que ya fue implementada es el soporte al comportamiento de los archivos indexados de Fujitsu COBOL85, pero con soporte de 64 bits, lo que significa que un archivo indexado podrá tener tamaños de petabytes. Otra cosa que se está implementando es el journaling para archivos indexados, lo que permitirá operaciones de commit/rollback y aumentará la seguridad del archivo. Hay muchas otras cosas que quiero implementar, pero por ahora estoy manteniendo un roadmap factible. ¡Vamos a hacer historia juntos! Me siento como un niño en una tienda de dulces. Todos sabemos que el acceso a disco siempre es el cuello de botella de cualquier aplicación. El agent implementó un sistema de archivos indexados que funciona básicamente en memoria, descargando el contenido al disco en el COMMIT o en el CLOSE. Obviamente, esto es peligroso por el riesgo de pérdida de datos, pero es aceptable en procesos internos donde hacemos una indexación temporal de datos. Trabajar en memoria es prácticamente instantáneo. Añadí sintaxis para trabajar con almacenamiento directo en disco o en memoria. Bueno, ¿por qué detenerse aquí? También añadí una cláusula de compresión de datos usando un algoritmo RLE, que reduce el tamaño del registro en más de un 50%. Es decir, se duplica la velocidad de lectura de los registros sin ningún esfuerzo. SELECT file-name ASSIGN TO external-file-name ORGANIZATION IS INDEXED [STORAGE IS { MEMORY | DISK } [WITH COMPRESSION]] ACCESS MODE IS { SEQUENTIAL | RANDOM | DYNAMIC } RECORD KEY IS data-name [ALTERNATE RECORD KEY IS data-name [WITH DUPLICATES]] [FILE STATUS IS data-name]. El valor predeterminado es disco sin compresión, por lo que esta opción solo se aplica a archivos nuevos. Así, los datos almacenados a largo plazo residen en el disco desde el momento del WRITE/REWRITE —y se eliminan inmediatamente del disco después de un DELETE—, pero con la opción de compresión se tarda menos en leer o escribir, y el tiempo de compresión/descompresión es despreciable. Todos los recursos están siendo probados exhaustivamente, y el código de pruebas del compilador queda en el propio repositorio para que pueda ser analizado o ejecutado en cualquier momento. El enlace al repositorio será enviado por correo electrónico después de que informen su username de GitHub. |
||||||||
|
|
|
4 de junio de 2026, 08:42
|
Creador de
PowerRustCOBOL
|
Not bad, not bad at all
FILE I/O TEST SUITE =================== All files are created under /tmp Existing files with the same names may be replaced. SEQUENTIAL FILE TESTS File: /tmp/seq-test.dat PASS S001 OPEN OUTPUT SEQUENTIAL PASS S002 WRITE FIRST SEQUENTIAL RECORD PASS S003 WRITE SECOND SEQUENTIAL RECORD PASS S004 OPEN INPUT SEQUENTIAL PASS S005 READ FIRST SEQUENTIAL RECORD PASS S006 READ SECOND SEQUENTIAL RECORD PASS S007 SEQUENTIAL AT END LINE SEQUENTIAL FILE TESTS File: /tmp/lineseq-test.txt PASS L001 OPEN OUTPUT LINE SEQUENTIAL PASS L002 WRITE FIRST LINE PASS L003 WRITE MIXED CASE LINE PASS L004 WRITE LOWERCASE LINE PASS L005 OPEN INPUT LINE SEQUENTIAL PASS L006 READ FIRST LINE PASS L007 READ MIXED CASE LINE PASS L008 READ LOWERCASE LINE PASS L009 LINE SEQUENTIAL AT END INDEXED FILE TESTS File: /tmp/idx-main.dat PASS I001 OPEN OUTPUT INDEXED MAIN PASS I002 WRITE UPPERCASE PRIMARY KEY PASS I003 WRITE LOWERCASE PRIMARY KEY PASS I004 WRITE MIXED CASE PRIMARY KEY PASS I005 WRITE ALPHABETIC-ONLY PRIMARY KEY CONTENT PASS I006 DUPLICATE PRIMARY KEY RETURNS 22 PASS I007 DUPLICATE ALTERNATE KEY WITHOUT DUPLICATES PASS I008 OPEN I-O INDEXED MAIN PASS I009 RANDOM READ BY LOWERCASE PRIMARY KEY PASS I010 RANDOM READ BY UNIQUE LOWER ALTERNATE KEY PASS I011 START/READ DUPLICATE UPPER ALTERNATE KEY PASS I012 START/READ DUPLICATE MIXED ALTERNATE KEY PASS I013 START GE PRIMARY KEY PASS I014 START INVALID KEY RETURNS 23 PASS I015 REWRITE INDEXED RECORD PASS I016 READ REWRITTEN INDEXED RECORD PASS I017 DELETE CURRENT INDEXED RECORD PASS I018 READ DELETED RECORD RETURNS 23 INDEXED NUMERIC KEY TESTS File: /tmp/idx-numeric.dat PASS N001 OPEN OUTPUT NUMERIC KEY INDEXED FILE PASS N002 WRITE NUMERIC KEY 00000001 PASS N003 WRITE NUMERIC KEY 00001000 PASS N004 RANDOM READ NUMERIC DISPLAY KEY INDEXED ALPHABETIC KEY TESTS File: /tmp/idx-alpha.dat PASS A001 OPEN OUTPUT ALPHA KEY INDEXED FILE PASS A002 WRITE UPPER ALPHA KEY PASS A003 WRITE LOWER ALPHA KEY CONTENT PASS A004 WRITE MIXED ALPHA KEY CONTENT PASS A005 RANDOM READ MIXED ALPHA KEY INDEXED PERFORMANCE PROFILE File kept on disk after test. File path: /tmp/idx-perf-uuid-1m.dat Record count target: 1,000,000 Primary key size: 40 bytes Record size: 1024 bytes PASS P001 OPEN OUTPUT PERFORMANCE INDEXED FILE PASS P002 PERFORMANCE FILE WRITE LOOP COMPLETED INDEXED WRITE PERFORMANCE STATISTICS Path : /tmp/idx-perf-uuid-1m.dat Start time HHMMSSHS : 05372400 End time HHMMSSHS : 05374400 Records attempted : 1,000,000 Elapsed seconds : 20.00 Records per second : 50,000 Approx data MB : 976 Final file status : 00 PASS P003 OPEN INPUT PERFORMANCE INDEXED FILE PASS P004 PERFORMANCE FILE READ LOOP COMPLETED INDEXED READ PERFORMANCE STATISTICS (READ INVALID KEY) Path : /tmp/idx-perf-uuid-1m.dat Start time HHMMSSHS : 05374400 End time HHMMSSHS : 05380100 Records attempted : 1,000,000 Records found : 1,000,000 Elapsed seconds : 17.00 Records per second : 58,823 Final file status : 00 PASS P005 OPEN INPUT PERFORMANCE INDEXED FILE FOR SCAN PASS P006 PERFORMANCE FILE SEQUENTIAL SCAN COMPLETED INDEXED SCAN PERFORMANCE STATISTICS (READ NEXT) Path : /tmp/idx-perf-uuid-1m.dat Start time HHMMSSHS : 05380100 End time HHMMSSHS : 05380600 Records scanned : 1,000,000 Records found : 1,000,000 Elapsed seconds : 5.00 Records per second : 200,000 Final file status : 00 The indexed performance file was intentionally kept. =================== TESTS RUN : 00049 TESTS PASSED : 00049 TESTS FAILED : 00000 RESULT : PASS |
||||||||
|
|
|
5 de junio de 2026, 19:34
|
El Foro es mi casa
|
¡Estoy asombrado por el progreso casi increíble de este proyecto!
Qué tipo de archivos indexados se utilizan? C-ISAM, D-ISAM...son compatibles con Fujitsu? De qué proveedor? ¿Gratuita o de pago? El acceso SQL previsto es nativo o mediante ODBC? Gracias, buen trabajo, José |
||||||||
|
|
|
6 de junio de 2026, 02:54
|
Creador de
PowerRustCOBOL
|
El archivo indexado de RustCOBOL no es compatible con Fujitsu en términos de estructura de archivo, pero implementa el 99 % de la especificación COBOL-85 utilizada por Fujitsu COBOL85, lo que facilita la conversión de datos de un formato a otro prácticamente sin impactos en el código.
RustCOBOL y TODOS sus componentes son OPEN-SOURCE y GRATUITOS. Nada de licencias pagas, aunque en el futuro podamos ofrecer soporte pago. Nuevamente: el compilador, el RAD y las herramientas son 100 % gratuitos. ¡100 %! En este momento estamos intentando, tanto como sea posible, evitar dependencias externas. Todavía no tenemos, por ejemplo, soporte para videos H.264 por el simple hecho de que esto requiere componentes externos, aunque sean gratuitos. Queremos una implementación limpia, 100 % Rust. El widget de acceso a base de datos soporta SQLite, PostgreSQL y MySQL a través de bibliotecas Rust. Sobre el sistema de archivos indexados de RustCOBOL (ISAM) 1. Arquitectura Un único trait IndexedStore (crates/cobolt-runtime/src/indexed.rs) define la interfaz que utiliza el intérprete. Hay dos backends detrás de un Box<dyn IndexedStore>:
Sin dependencias externas — motor ISAM propio. “Sabor” de engine: Código:
--indexed-engine {rust|rm-cobol85|fujitsu}
Código:
COBOL_INDEXED_ENGINE Los verbos de archivo son despachados por la ORGANIZATION del SELECT. 2. Engine de memoria (indexed.rs) Código:
records: BTreeMap<clave-primaria, registro> // KSDS ordenado
alt_index: Vec<BTreeMap<clave-alt, BTreeSet<RecordId>>>
locks: HashMap<clave, LockMode{Shared|Exclusive}>
journal: Vec<Journal{Insert|Update|Delete}> // undo para ROLLBACK
3. Engine de disco (indexed_disk.rs) — formato PRCIDXD1 Páginas fijas de 4 KiB, con free-list. Las páginas liberadas son reutilizadas. Los punteros y contadores son u64. B+tree por clave — primaria + alternativas: hojas/internas byte-packed, split en la inserción y hojas doblemente encadenadas para barrido ordenado. Directorio de RecordId: RecordId estable → ubicación física. Un REWRITE que mueve el registro actualiza solo el directorio. Slotted data pages: varios registros por página + cadena de overflow para registros mayores que una página. WITH COMPRESSION: RLE estilo PackBits (compress.rs), rápido, y nunca crece más de 1 byte. Undo log en ejecución — nuevo en v1.8.0: soporta ROLLBACK real. Antes era no-op. 4. Transacciones COMMIT / ROLLBACK (v1.8.0) Semántica — se aplican a todos los archivos INDEXED abiertos:
Implementación: el engine acumula un undo log con operaciones inversas:
ROLLBACK reaplica los inversos en orden reverso, con guard tx_replay para no registrar nuevamente en el log, y vuelve a persistir. COMMIT descarta el log y ejecuta sync_all. COMMIT y ROLLBACK son tokens reservados. No son absorbidos por un DISPLAY anterior. Atención: es rollback a nivel de programa, dentro de la ejecución. La recuperación post-crash mediante WAL durable sigue siendo trabajo futuro. 5. Recursos implementados Claves: RECORD KEY única + N ALTERNATE RECORD KEY [WITH DUPLICATES]. Modos de acceso: Código:
ACCESS MODE SEQUENTIAL ACCESS MODE RANDOM ACCESS MODE DYNAMIC Código:
OPEN {INPUT|OUTPUT|I-O|EXTEND} [SHARING WITH …][WITH LOCK]
CLOSE
WRITE (INVALID KEY)
REWRITE
DELETE
READ (random / NEXT/PREVIOUS / KEY IS altkey / WITH [NO] LOCK)
START KEY IS {= > >= < <=}
UNLOCK
COMMIT
ROLLBACK
Código:
00, 02, 10, 22, 23, 24, 35, 46, 47/48/49, 99, … 6. Ejemplos de uso — ejecutados ahora (1) CRUD con clave primaria + alternativa, DISK WITH COMPRESSION Flujo: Código:
OPEN OUTPUT/I-O WRITE READ random INVALID KEY REWRITE START GREATER + READ NEXT READ KEY IS (alternativa, duplicados) DELETE Código:
RANDOM 0002: BRUNO 0099 INVALID KEY, ST=23 REWRITE ST=00 SEQ 0001 ANA SEQ 0002 BRUNINHO ← REWRITE aplicado; orden por clave primaria SEQ 0003 CARLOS ALT SP #1: CARLOS ← lectura por clave alternativa CIDADE="SP" ALT SP #2: BRUNINHO ← READ NEXT en el duplicado DELETE 0001 ST=00 0001 apagado, ST=23 FIM Otro proceso solo lee el archivo /tmp/clientes.idx de la ejecución anterior: Código:
Reabierto (otra ejecución). Registros persistidos: 0002 BRUNINHO SP 0003 CARLOS SP ← 0001 ANA sigue apagado; REWRITE/DELETE sobrevivieron Graba GAMMA, hace COMMIT. Después graba DELTA, altera ALPHA, borra BETA y hace ROLLBACK: Código:
OPEN I-O F MOVE 0003 ... WRITE R-REC *> GAMMA COMMIT MOVE 0004 ... WRITE R-REC *> DELTA MOVE 0001 ... READ F MOVE "ALPHAX" ... REWRITE R-REC MOVE 0002 ... DELETE F ROLLBACK Código:
Después del ROLLBACK, barrido:
0001 ALPHA ← REWRITE deshecho
0002 BETA ← DELETE deshecho
0003 GAMMA ← COMMIT anterior sobrevive
← 0004 DELTA removido (WRITE deshecho)
El acceso SQL previsto es nativo o mediante ODBC? (Drivers nativos de Rust para SQLite, MySQL y PostgreSQL)
Citación del post de Joseg
Conviértete en sponsor para descargar el código, seguir de cerca el progreso y contribuir con las pruebas. ¡Saludos! |
|||||||||||||||||||||||||||||||||||||||||
|
|
|
6 de junio de 2026, 12:49
|
El Foro es mi casa
|
OK, Ja sei que tambem falam em Portugues!!
Nao estou a conseguir fazer doaçao. Esta operacional?! GitHub - CloudLandBeta/PowerRustCOBOL-funding: Public repository for gaining access to the private PowerRustCOBOL repository containing the source code by becoming a sponsor. · GitHub Boa continuaçao.
Citación del post de Eslopes
|
|||||||||
|
|
|
6 de junio de 2026, 13:16
|
Creador de
PowerRustCOBOL
|
Grato por sua resposta. Estou aguardando a aprovação do GitHub dos dados fiscais que fui obrigado a fornecer. Deve ser liberado em breve. Colocarei um aviso no fórum.
Aquí está el esquema conceptual del motor de índice en disco implementado (DiskIndexedFile, contenedor PRCIDXD1). Este es el formato persistente; el motor en memoria es un subconjunto simplificado del mismo modelo. 1. El archivo = un array de páginas fijas de 4 KiB byte 0 end of file ┌────────┬────────┬────────┬────────┬────────┬──── ────┬───── ... ─────┐ │ Page 0 │ Page 1 │ Page 2 │ Page 3 │ Page 4 │ Page 5 │ ... │ │ HEADER │ B+tree │ B+tree │ DATA │ DATA │ DIR │ │ └────────┴────────┴────────┴────────┴────────┴──── ────┴───────────────┘ Cada página tiene exactamente PAGE_SIZE = 4096 bytes; page id = desplazamiento en bytes / 4096 Cada página después de la página 0 se identifica por su primer byte (etiqueta de tipo): | Tag | Page type | Contenido | |-----|-------------|------------------------------------------------| | 1 | PT_INTERNAL | Nodo interno de B+tree | | 2 | PT_LEAF | Nodo hoja de B+tree (doubly linked) | | 3 | PT_DATA | Página con slots que contiene varios registros | | 4 | PT_OVERFLOW | Continuación para registros demasiado grandes | | 5 | PT_DIR | Un fragmento del directorio de RecordId | Las páginas pueden liberarse y reutilizarse mediante una free list, por lo que el orden físico en disco no corresponde al orden lógico. 2. Página 0 — el encabezado (se escribe una sola vez, es el único esquema del archivo) PRCIDXD1 version page_size rec_fmt compressing record_len (8 bytes) (u16) (u32) (u8=1) (u8 0/1) (u32) ────────────────────────────────────────────────── ──────────── next_page_id free_list_head record_count data_tail (cada u64) primary_root dir_head directory_len (cada u64) ────────────────────────────────────────────────── ──────────── alt_root_count (u16) → [ alt_root : u64 ] × N (una raíz B+tree por clave alternativa) ────────────────────────────────────────────────── ──────────── KEY SCHEMA: key_count (u16) → para cada clave: duplicates_allowed (u8) part_count (u16) → [ offset:u32, length:u32 ] × partes (claves compuestas) Nota: No hay nombres de campos ni metadatos por registro. El esquema solo define la geometría de las claves (rangos de bytes). 3. Ruta de acceso (cómo se resuelve un READ) COBOL key value (bytes) │ ▼ ┌──────────────┐ primary_root / alt_roots[k] │ B+tree (uno │ por clave. Las páginas internas enrutan; │ por clave) │ las hojas contienen (key_bytes → RecordId) └──────┬───────┘ y están doubly linked para READ NEXT / PREVIOUS. │ RecordId (un entero estable) ▼ ┌──────────────┐ directory[RecordId] = RecLoc │ Directorio │ { kind, page, slot, len } │ de RecordId │ kind: 0=free/tombstone 1=inline 2=overflow └──────┬───────┘ │ (page, slot) ▼ ┌──────────────┐ slotted DATA page → slot dir → (offset,len) │ DATA page │ → imagen raw del registro (opcionalmente comprimida) └──────┬───────┘ ▼ los bytes del registro de ancho fijo → RecordLayout.distribute() los distribuye en los subcampos del FD en memoria. Todos los índices (primario + alternos) apuntan al mismo RecordId, por lo que existe exactamente una copia de cada registro. 4. Una página PT_DATA vista en detalle ┌─ byte 0 ─┬─ 1..3 ─┬─ 3..5 ──┬─ slot directory ─────┬─ ... free ... ─┬─ record data ─┐ │ type=3 │ slot_ │ free_ │ (off:u16,len:u16) ×N │ │ packed │ │ │ count │ top │ grows → │ │ ← grows │ └──────────┴────────┴─────────┴─────────────────── ───┴───────────────┴───────────────┘ El directorio de slots crece desde el frente, los registros desde el final. Los registros más grandes que una página se desbordan en una cadena PT_OVERFLOW. 5. Imagen del registro (posicional, sin nombres) Ejemplo: 01 CUST. 05 ID PIC 9(5). 05 NAME PIC X(10). 05 CITY PIC X(8).: offset: 0 5 15 23 ┌────────┬────────────────────┬────────────── ─┐ payload: │ 00001 │ John Doe │ Sao Paulo │ ← 23 bytes, fixed └────────┴────────────────────┴────────────── ─┘ ID(5) NAME(10) CITY(8) materialize() empaqueta los subcampos en este buffer; distribute() hace lo inverso. Con compresión, se aplica PackBits-RLE. 6. Estructuras transversales * Free list — free_list_head encadena las páginas liberadas para reutilizar espacio. * Directorio de RecordId — reside en RAM mientras el archivo está abierto, se persiste en páginas PT_DIR. * Transacciones — undo log en RAM (inversas de Insert/Update/Delete). ROLLBACK las aplica; COMMIT las descarta y hace flush. * Validación estricta en OPEN — compara el esquema de claves almacenado con el del programa; mismatch → file status 39. En una oración: un archivo paginado compuesto por un header + N B+trees (uno por clave) → directorio de RecordId → páginas de datos con slots de registros de ancho fijo posicionales, con free list, cadenas de overflow, compresión RLE opcional y undo log para transacciones. |
||||||||
|
|
|
10 de junio de 2026, 05:47
|
Creador de
PowerRustCOBOL
|
Estimados,
Les comparto el enlace a la página de financiación. Para contribuir, hagan clic en el botón “Sponsor”. Al realizar una donación mensual, tendrán acceso al repositorio privado con el código fuente: GitHub - CloudLandBeta/PowerRustCOBOL-funding: Public repository for gaining access to the private PowerRustCOBOL repository containing the source code by becoming a sponsor. · GitHub Conviértanse en patrocinadores hoy mismo y ayuden a construir la nueva generación de entornos gráficos para COBOL, con soporte para Generative AI, REST APIs, servicios en la nube, integración con Rust y mucho más. Con su apoyo, será posible acelerar el desarrollo, mejorar la estabilidad, crear ejemplos, ampliar la documentación y transformar PowerRustCOBOL en una plataforma moderna, abierta y útil para la comunidad COBOL. ¡Saludos! |
||||||||
|
|
|
|
| Herramientas | |
|
|
|
Archivo - Cobol Foro | Contactar con Nosotros - Cobol Foro | |
|||||
Likes
