agradecería la información para donar

Parabéns pela iniciativa, sem duvida que é algo muito interessante e que pode dar um novo alento.
Estou interessado em fazer doação dos 10 dolares.
Como o fazer ?

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 ?

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!

Post añadido a las 20:48. Post anterior a las 19:37

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.

Post añadido a las 21:08. Post anterior a las 20:48

El enlace al repositorio será enviado por correo electrónico después de que informen su username de GitHub.

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

¡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é

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>:

[TABLE]Backend|STORAGE IS|Archivo|Característica[/TH][/TR]
IndexedFile (memoria)|MEMORY|indexed.rs|todo en RAM; se guarda en CLOSE
DiskIndexedFile (disco)|DISK (por defecto)|indexed_disk.rs|archivo paginado persistente, leído bajo demanda
[/TABLE]

Sin dependencias externas — motor ISAM propio.

“Sabor” de engine:

o:

Actualmente, rm y fujitsu delegan al engine Rust.

Los verbos de archivo son despachados por la ORGANIZATION del SELECT.

2. Engine de memoria (indexed.rs)

BTreeMap proporciona ordenación natural para START, READ NEXT y READ PREVIOUS.

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:

[TABLE]Verbo|Efecto[/TH][/TR]
OPEN|inicia una transacción
COMMIT|hace durable todo desde el último COMMIT/OPEN e inicia una nueva transacción
ROLLBACK|deshace todo WRITE/REWRITE/DELETE desde el último COMMIT/OPEN
CLOSE|persiste los cambios mediante commit implícito
[/TABLE]

Implementación: el engine acumula un undo log con operaciones inversas:

• Insert → delete
• Update → reescribe la imagen anterior
• Delete → regraba la imagen anterior

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:

Verbos:

FILE STATUS de 2 dígitos:

Bloqueo de registros, modelo KSDS, más journal/undo, persistencia, compresión opcional y selección de almacenamiento/engine.

6. Ejemplos de uso — ejecutados ahora

(1) CRUD con clave primaria + alternativa, DISK WITH COMPRESSION

Flujo:

Salida:

(2) Persistencia entre ejecuciones

Otro proceso solo lee el archivo /tmp/clientes.idx de la ejecución anterior:

(3) Transacción COMMIT/ROLLBACK

Graba GAMMA, hace COMMIT. Después graba DELTA, altera ALPHA, borra BETA y hace ROLLBACK:

Salida idéntica en los engines de disco y memoria:

7. Cobertura de pruebas — verde ahora

[TABLE]Suite (Rust)|Resultado
test_transactions (COMMIT/ROLLBACK — disco y memoria)|2 passed
test_indexed (engine ISAM)|2 passed
test_file_locking (OPEN SHARING/LOCK, READ WITH [NO] LOCK, UNLOCK, CANCEL)|4 passed
test_fileio_storage (6 variantes: baseline + memory/disk × compression)|7 passed
[/TABLE]



El acceso SQL previsto es nativo o mediante ODBC? (Drivers nativos de Rust para SQLite, MySQL y PostgreSQL)

Por falta de créditos, no tendremos avances hasta el próximo miércoles.

Conviértete en sponsor para descargar el código, seguir de cerca el progreso y contribuir con las pruebas.

¡Saludos!

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.

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.

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!