Hi Simon, all, I'd like to propose a crowdfunding mechanism for funding specific GnuCOBOL improvements. The idea: 1. Define a specific enhancement (e.g., better Micro Focus SCREEN SECTION compatibility) 2. A company provides a fixed quote for implementation 3. Open a public collection 4. If the target amount is reached, development begins 5. Result is contributed back to GnuCOBOL Questions: What platform could serve as a trusted intermediary? I believe this could help fund improvements that benefit...
Simon: Personally, I prefer ISAM because I have many C programs for ISAM. I don't use the MF ISAM, but rather the Informix Standard Engine. Since I see you prefer ISAM over BDB, when you decide to implement it in the standard version, I'm here to help in any way I can. Regards
Thanks, Mickey. I'm facing over 50,000 screen operations (Display, Accept). If it can't work as is, I prefer to wait. As I mentioned to Simon, I don't have the resources to undertake the migration until Spring 2027. The only viable option would be a "turnkey" solution (like opening an Excel spreadsheet in OpenOffice, for example), but it seems we're a long way from that. I appreciate your good wishes. Juan Carlos
Thanks, Chuck. I think the only unusual exception I use is MF's cobscroll, and I've fixed that. I'm not sure if MF's dd_FILE mechanism is standard (probably not), but GNUCOBOL theoretically supports it, but I can't get it to work. For me, with SCREEN-SECTION working, incorporating UTF-8, and correctly handling any charset, and with dd_FILE and CALL working, I think I'd have 99% of the problem solved.
Thanks, Simon. MS-COBOL, I'm thinking of the number one in the COBOL market, so anything that's compatible with it has to be interesting for someone who wants to make a living from the COBOL market. If Jim from COBOLwork is interested, I can also help to the best of my ability; you can contact me. My email address is in the links. Throughout 2026, I don't have the resources to resume the migration. We'll be able to address this at the earliest in Spring 2027. Regarding the secondary keys, if you...
Any human activity requires resources. The Linux world is what it is because someone pays the Linux Foundation and can afford a €300 million budget. Based on this, we must unite our wills and efforts, such as through companies like COBOLworx or OCamlPro. The GNU/COBOL project thrives on this. I think it's right. But fixing the screen section, I've calculated it will take over 1,000 hours if we add UTF-8 support, and that's just part of it. In the 21st century, not having UTF-8 support seems primitive....
Berkeley DB (BDB) - My Analysis Pros: - Mature and proven (decades of development) - Stable, passes stress tests - Excellent key-value performance - Embedded (no server required) - ACID compliant - Included in standard GnuCOBOL distributions - Well documented Cons: - AGPL v3 license since 2013 (if you distribute the software, you must release the source code) - Oracle as the owner (license change history) - Minimal active development - Not SQL (only key-value) - No native remote access - Concurrency...
Hello Simon "You recommend commercial support. Who exactly has SCREEN SECTION, DISPLAY and ACCEPT working identically to Micro Focus COBOL? Can you provide a reference customer or case study?" BDB passes all stress tests successfully; my motto is "If it ain't broke, don't fix it." PostgreSQL or MariaDB is the destination