Activity for Juan Carlos Escartí
-
Juan Carlos Escartí posted a comment on discussion GnuCOBOL
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
-
Thanks Chuck. I prefer to focus on solutions with critical mass like PostgreSQL/MariaDB. No licensing costs, universal standard, millions of users, guaranteed future."
-
Hi Chuck, Currently, my data storage is C-ISAM Standard Engine version 1.07. Without a doubt, future storage has to be PostgreSQL or MariaDB, PostgreSQL being preferable. Surely, on either of these two platforms, your data will be safe and secure. On either of these two platforms, the critical mass of interested parties is in the millions; they will never be left in a dead end. It's possible to create a driver (I'm quite far along in this one) that doesn't replace COBOL READ and WRITE operations...
-
Hi Simon, The data porting was done in November 2023 with COBOL 3.1, VBISAM version 2.0, and a 32-bit Linux Kernel 3.2 operating system. One of the many errors was: "Attempts to reference unallocated memory (signal SIGSEGV)" 1982 Segmentation fault. The main issue I remember, as "very important," seems to be register loss when accessing data via secondary storage. Slowness increased as reads or writes accumulated. When you decide to tackle VBISAM, I can prepare a test suite with a more up-to-date...
-
Chuck, Thank you for your detailed and honest response. It helps clarify both the technical landscape and the human reality behind GnuCOBOL. After reading your message, I want to share a thought with you. You mentioned you are 74 and not looking for long time commitments. I completely understand and respect that. But here is the thing: your knowledge is irreplaceable. You understand CURSES deeply — both PDCURSES and NCURSES, their differences, their quirks. You understand why screenio.c is the way...
-
My experience, in case it's helpful to anyone: About three years ago, I made a strong push to put GNUCOBOL into production. For the database, I tried VBISAM because I have many C routines for reading C-ISAM files. It failed the stress tests, and I had to abandon VBISAM. With BDB, I still maintain the C-ISAM data in parallel with BDB GNUCOBOL program, and it works correctly. Regards
-
Thank you Chuck for your response. Far from being offensive, I think it is very kind, respectful, and focused on the facts. COBOL is possibly an exception among compiled languages available in the world. If we look at the TIOBE index, perhaps only ABAP, and a few others I'm not aware of, have been affected by the need for expensive licenses for their use. This means that millions of lines of code in production are trapped between the very high cost of maintaining COBOL or migrating to another environment....
-
Thanks, Stephen. I've been trying to get GNU COBOL into production for some time now. I think it needs a push to focus on the Linux platform, PostgreSQL, Curses Screen, VBISAM, BDB, and MF compatibility. Would there be any development group interested in pushing this forward?
-
To Ralph The high interest in FreeDOS is truly anachronistic. Operating system usage on: 🖥️ SERVERS Linux - 63.10% Windows Server - ~30% Unix/Other - ~7% 🚀 SUPERCOMPUTERS (Top 500) Linux - 100.00% In 2026, COBOL will be of interest to: ✅ Large corporations - because they CAN'T abandon it (too big to fail) ✅ Senior programmers - the last generation that knows it ✅ Young opportunists - well-paid niche markets ✅ Governments - critical systems with no viable alternative ✅ Consulting firms - modernization...
-
In Open SuSE 16.0, in the repository for GNU COBOL we have Copyright (C) 2024 Free Software Foundation, Inc. License LGPLv3+: GNU LGPL version 3 or later https://gnu.org/licenses/lgpl.html This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart Built Nov 27 2025 20:13:37 Packaged Nov 26 2025 17:52:54 UTC build information build...
-
I'm upgrading from OpenSUSE 15.5 to 15.6 and then to 16.0. I'm experiencing similar stability issues with 16.0 as I did with SUSE Tumbleweed. Is anyone else going through this process and could share some of their experience? Thanks
-
Regarding the .int and .gnt files from MF: I'm not sure if SCO, being 32-bit, will run directly with a 64-bit MF runtime or compiler; I haven't tested it. In any case, the intermediate code, the .int files, will likely have many problems running with a very different runtime. If you have an MF compiler for Linux, I would definitely recompile everything. You might have to migrate the data because different versions of C-ISAM use different IDX structures. If you want everything to remain exactly the...
-
Since this thread is about SCO to Linux, I'll explain what I know in case it helps someone. To run SCO applications, you need to enable IBCS. What exactly is IBCS? The Intel Binary Compatibility Standard (iBCS) is a standardized application binary interface (ABI) for Unix operating systems on Intel-386 compatible computers. Published by AT&T, Intel, and SCO in 1988 and updated in 1990, it extends source-level standards like POSIX and XPG3 by standardizing various operating system interfaces, including...
-
ANTLR (Another Tool for Language Recognition) is the most recommended and robust option for this type of project. Purpose: ANTLR is a parser generator that can build an Abstract Syntax Tree (AST) from grammars. Advantages in COBOL: Existing Grammar: You are very likely to find pre-existing COBOL grammars for ANTLR, saving you the enormous task of writing one from scratch. COBOL's format is fixed and complex, so a well-defined grammar is crucial. Parser Generation in Multiple Languages: You can generate...
-
Like people, LLMs know a little, a little, a lot, or a great deal, depending on their training. My experience with Claude: He knows a lot about SQL, PHP, and Python. He knows quite a bit about bash, awk, Linux commands, and configuration. He knows some C, but gets lost quickly. He knows some COBOL, but also gets lost quickly. He gets lost with complex regular expressions. He knows very little about formal grammars like Yacc, Lex, and Bison. If you can maintain context, he can be very useful. When...
-
Description of the transpiler.awk program The transpiler.awk program is designed to allow you to specify a simple grammar and then convert it into another grammar of any arbitrary type. Fundamentals of our transpiler An unlimited number of rules can be specified; they must be numbered from 1 to xxx. Regular expression recognition is the standard feature of awk. Rules are recognized in the order they are expressed, so if a previous rule is recognized, the next one is not applied. The source and target...
-
Building a preprocessor, especially a robust and efficient one for a language like COBOL, requires advanced or expert-level programming skills. It is not a typical task for a beginner or intermediate programmer. Developing a preprocessor involves complex tasks that require specific skills in several areas: Required Skills In-depth Knowledge of the Target Language (COBOL): A thorough understanding of the syntax, structure, and rules of standard COBOL is necessary, as well as the specific extensions...
-
Ralph, Thank you for sharing your experience with Claude, although I'd like to clarify a few points. It's true that current AI tools have limitations with advanced COBOL features such as OCCURS DEPENDING ON, COMP-3 fields, pointers, and indexed files. These are complex functionalities that require in-depth knowledge of the specific environment (compiler, operating system, data organization). However, saying that "nothing beyond 'Hello World' works" is an untenable generalization. Thousands of developers...
-
Document 72048-ERP-02 presents the Fundamental Axioms for a New ERP, establishing a business model highly focused on data immutability and historical traceability, which can be interpreted as an extreme Event Sourcing system. Instead of a traditional relational database model (fixed tables), the truth of the business resides in the historical and immutable flow of Events (Axiom 3), with the State of any Entity (business object/record) being the result of the sequence of these events (Corollary 3.3)....
-
Thanks Chuck for your reply. The terminal I use supports multiple modes. For my application, I'm generally using scoansi with an old emulator and xterm-256color with Linux consoles. I don't think it's related to the emulator, but rather to the locale. On CP850 I use: LANG=es_ES LC_CTYPE="es_ES" On UTF-8: LANG=es_ES.UTF-8 LC_CTYPE="es_ES.UTF-8" All the programs are consistent with this, and many are based on curses, vi, dialog, etc. In general, everything works as expected, although when you convert...
-
How LLMs can help, my experience And this is what Claude Sonnet 4.5 proposes to fix the bugs Personally, I'm getting a lot of productivity out of Claude Sonnet 4.5. Since September, if you know how to use it, with instructions to go slowly, for example: "DON'T WRITE CODE" until you fully understand the problem ✋ "Slow down" - think before you program 🧠 "Let's go point by point" - reach a consensus on each decision 📋 "Memento mori" - design for the forgetful future 💀 "One question at a time" - I find...
-
I tested LLM Gemini 3.0 to analyze the errors in screenio.c. It gave me this diagnosis: He tested it by cross-referencing it with a 2012 version of Open COBOL that handled CP850 better. 1. Arrow Problem (Navigation Block) Status: UNRESOLVED The database reported: "The up/down arrows don't work... if an escape sequence isn't sent, the program doesn't function." In code 2025, the logic that blocks the arrows remains intact and is identical to the 2012 version. Evidence: Look at the cob_convert_key...
-
To Eugenio I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible. For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue. Right now, I'm more urgent about getting out of C-ISAM, which is at its limit, than anything else. I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me. When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I have...
-
To Eugenio I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible. For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue. Right now, I'm more urgently trying to get out of C-ISAM, which is at its limit, than anything else. I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me. When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I...
-
To Ralph There may be misunderstandings or differences in our visions, and I'd like to better understand your perspective. I believe open and honest communication can help us align our goals and ensure we're all working together for the good of the project. Don't you think the GNUCOBOL compiler should be a direct replacement for the more popular COBOL compilers?
-
Resources are precisely the necessary condition for the advancement of any project. We must remember that the Linux Foundation spent €300 million on the project last year. If we want GNUCOBOL to advance, we cannot ignore the necessary material conditions. Thinking that only altruistic programmers, free of charge, will solve all the problems of a production COBOL compiler is a seemingly impossible dream. Seeking alternative resources from stakeholders is, I believe, the only way to have a fully profiled,...
-
-
And by the way, there's a full description of the SCREEN SECTION in the OPEN GROUP's Technical Standard for COBOL Language. https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf "The existence of a "Screen Section" does not belong in a COBOL compiler.", seems to me to be a statement lacking in rigor, if it is defined in the XOPEN group standard.
-
And by the way, there's a full description of the SCREEN SECTION in the OPEN GROUP's Technical Standard for COBOL Language. https://pubs.opengroup.org/onlinepubs/009680799/toc.pdf "The existence of a "Screen Section" does not belong in a COBOL compiler.", seems to me to be a statement lacking in rigor, if it is defined in the XOPEN group standard.
-
All the Cobol compilers I've worked with for over 40 years have solved the problem of screen handling. Transparent SQL handling is clearly a "fiction." ISAM and SQL database files have different logic, and you necessarily "must tweak the code." Virtually any compiler has a multitude of libraries to solve a multitude of problems. From screen management to network management, etc. I don't quite understand why this isn't addressed in GNUCOBOL. If GNU is never going to handle the screen correctly, its...
-
Hello again After a really busy 2024 that has kept me very busy, my 600,000 lines of code are still in production, as are the 8,000,000 C-ISAM records. VB-ISAM doesn't seem to be evolving, and I don't think BDD is an option for much of a future. It seems like I'll have to migrate to PG or MariaDB. My C-ISAM files are reaching their limits in many ways. The SCREEN problems seem to come from the different versions of the CURSES libraries, which seems like a chronic problem that's difficult to solve....
-
Looks like Erik is working on this with Simon https://sourceforge.net/p/gnucobol/discussion/cobol/thread/54006dc00c/?limit=25#2d12
-
Thanks Ralph The problem is that my MF is so old (1988), that EXTFH didn't even exist, so I can't call what doesn't exist. Thanks Gregory In MF you can read and write to a pipe with the following mechanism Example of sqlin input file, exported as export dd_sqlin="<(sh /tmp/argc.10741)" In cobol MOVE "sqlin" TO INFILE READ INFILE RECORD The result enters via pipe to the COBOL program Likewise for the output So by putting the correct handler in the bash script with this mechanism you can communicate...
-
Hi all I'm virtually finished with a driver that uses MySQL so that COBOL handles MySQL as if they were ISAM files. I know this is similar to EXTFH, but I can't get EXTFH into the old MF. The trick is to replace the I/O libraries I have, ES, with a mechanism similar to embedded SQL outputting through the dd handler that allows writing and reading pipes. In the old MF it works perfectly. Does anyone know where I can find information on GNUCOBOL's dd_ and pipe handling? Thanks
-
Thanks to you, the truth is that I'm having a difficult year. Now the only Cobol programmer I had left the company on Monday, September 23, and I also took care of administration and payments. Now I'll have to deal with finding resources for the day-to-day running of the company, and or transfer a Web programmer to learn Cobol. Finding Cobol experts in this city is very difficult. I'm the boss and it seems that I'm always putting out fires Anyway, reality is hard Regards P.S. Eugenio, I can't move...
-
Addendum: I have in mind to write a short article entitled "Why Cobol should never die". And it will be written by a person who has written more than 1,500,000 lines of programming between Assembler, Cobol, C, Bash, SQL, Awk, Basic, Java, Perl, Mumps, Python, PHP for more than 45 years, and most of that code is still in use.
-
To Simon: NoSQL Applications is the way to go I imagine you are talking about MongoDB Cassadra Allegro Neptune and others. I have always thought that modeling the real world with the relational model is a constraint that often does not represent this reality well. I have tried to find a better solution for some problems from MongoDB, but without success. The few problems that the relational model (generally AI) did not solve, I have resorted to brute force. Data in memory in associative arrays. Since...
-
To pottmi SQL is from 1974, Unix/Linux from 1968 and the first computer from 1945. Human language is unknown in origin and we are still using it. The future is written every day, we live in a continuous present. In 1988 I was told that COBOL was the past and the future was in 4GL, specifically Informix. Today year 2024 Informix does not exist and here we are talking about COBOL. I think what you say " Relying on the user executable to back out an update is a fool's errand." is correct and that is...
-
To Vicent A Cobol-only system in 1988 had many limitations. Reading data and doing binary searches, adding and deleting indexes, reading them in a cgi-bin and a long list of limitations that at least the old MF had and some still exist in GNU and that force us at least to program in C. How do you add an index to a file from Cobol? How do you read your data from bash, perl, awk, java or any other language if you don't have a or know a driver ? How do you manage a TCP messaging service from Cobol?...
-
In fact, the most interesting thing I've seen in BDB is that it has a generator that converts SQL statements to a C source program that you can compile.
-
I know the VBISAM driver for C because I have been programming C-ISAM for many years. Frankly, I have no interest in learning the BDB driver.
-
MySQL, Postgres will probably outlast any of us. I don't think BDB or VBISAM are of much interest right now. If your data is in MySQL you can probably say that you will have support "forever" and drivers for almost all existing languages. Where is your data in VBISAM? And in BDB? Surely your data is worth as much or more than your programs.
-
To Mario "I am aware that SQL would bring such capability, but I find the possibility of not having to use a database convenient." Staying with BDB or VBISAM is staying in the past. Personally I think we should all leave our comfort zone and update our code to handle SQL. I think the past is indexed file systems and the future is SQL databases. If we all push in the same direction we will surely make further progress.
-
Be thankful when things are done well Kudos to the GNUCOBOL developers I'm compiling and testing COBOL programs. They compile simultaneously in MF and GNU. Errors are displayed significantly better in GNUCOBOL Hats off to the GNUCOBOL team, congratulations
-
It will take me a few weeks to prepare this but I'm sure you'll have it before Christmas. I'm interested in working with VBISAM and not BDB so this topic is not going to fall on deaf ears. I have to obfuscate the data and there are many files with a lot of data. Regards
-
I did not have the same experience with VBISAM. The stress tests with about 5 million records showed many differences with VBISAM. BDB can be said to have passed them successfully.
-
Thanks Simon, as always clear and informative Another question, if it's not a bother, since I haven't programmed in C for over 30 years, I used to use ctrace for debugging, now I think GDB is being used. What debugging is more interesting for studying how to trace GNUCOBOL code? What do you use?
-
I found this article about ncursesw https://www.roguebasin.com/index.php/Ncursesw It explains the difficulties of the library to correctly represent wide or Unicode characters and the solutions respect to a Linux development platform running Debian Linux. If it doesn't call setlocale, your program will remain in the 'C' locale, which assumes that the terminal cannot display any characters outside the ASCII set Could it be a clue? Greetings
-
To Simon or Brian In order to start contributing we have downloaded GNU COBOL from source and compiled it on a clean OpenSuse 15.6 machine. We know there is a SVN that is continuously being updated What scripts do we have/can we run to keep this version fully up to date? Is there a method in place to keep our modified version in parallel with the official version until our changes are incorporated into it? Is there an easy way to have versions with BDB VBISAM NCURSES and NCURSESW etc. running simultaneously,...
-
For Chuck Sorry for the delay in replying This week I'm assigning a resource to make a full report with screenshots of the expected behavior and the behavior of GNUCOBOL. Thanks
-
No my C-ISAM is a very old version from 1988. I think it's 1.07. When you open these files in I/O with VBISAM the indexes get corrupted. You can only open them in read mode, which is not really very useful. My experience with VBISAM at first (very little data) was good, fast etc. When I loaded the mass of data (Files with 1.5/2 million records and many indexes), there were big differences between what was supposed to be there and what the program running VBISAM underneath said there was. The differences...
-
Sorry, I posted the post without being logged in. Please delete it and I will upload it logged in. All our programs are generated but not dynamic. The code generation menu contains: APPLICATION GENERATORS 1.-MAINTENANCE 2.-BODY 3.-LISTING 4.-COPY 5.-MENUS 6.-SCREENS 7.-ADD FILE TO PROGRAM 8.-ADD SCREEN TO BODY 9.-ADD QUERY TO PROGRAM 10.-SCREEN CONFIGURATION 11.-MAINTENANCE WITH SCREEN This generates a body, and from this point the programmer must continue manually. This scheme is beneficial because...
-
For Eugenio I'll give you an example screen They are apparently simple, however they have dozens of fields related between tables. An awk device allows full text searches to be performed with a combination of a dd_ pipe output and a C program that reads the CISAM files. I can move through the fields with CURSOR-UP and CURSOR-DOWN and the program handles it. They are all generated by an awk script that takes a base or body that we call with the extension _PA. It is done field by field, never in b...
-
Perhaps because it is legacy code and the screen section was added later, accepts and displays are made for fields from both the SCREEN and the Working. Is this what causes the compiler to call different functions? In the application, DISPLAY AT is used interchangeably for fields from the Working and SCREEN SECTION displays.
-
Very clear and illustrative explanation, thanks. In my case I don't use block input, and I don't need stdin input either because I use the pipe mechanism. How can I get the compiler to only call cob_field_accept ?, without using cob_screen_accept and cob_accept. I think I could ensure that MF always calls curses when you do a DISPLAY or ACCEPT. Regards
-
Dear Simon, I plan to make a huge inventory of problems and not solve any, we will not make much progress. Reference one, solve it and move on to the next, I think we can make more progress. cob_field_accept cob_screen_accept Either one of the 2 calls is eliminated or they must act exactly the same. A program cannot have different behaviors when using the same code. The 2 calls respond to different function keys, it does not make sense for the same application to have different keys to handle fields....
-
For Simon Before Monday I will prepare the list of errors that we have detected. I will also document how we have solved the problem of compiling the programs in MF and GNUCOBOL simultaneously without errors. These are simple scripts, simple ideas that can be useful for other conversions. Regards
-
For Ralph I think it's great that you have and continue to push for GNUCOBOL to work for Z/OS. I've been working on Unix for about 38 years and on Linux for about 30 years and I'm interested in getting it to work on this system. I think it may be of interest to many because Z/OS or Windows are not open systems when Linux is.
-
For Pottmi These are comments that discourage focusing on solving problems and making the system more compatible. I think it's foolish to focus on the differences, it's not moving forward. Anyway, Simon, as the leader of GNUCOBOL, is the one who should evaluate this and decide. It has been said that Ralph transcribes what the AI says, in this discussion and in the SCREEN SECTION discussion Ralph seems to try to discourage moving towards the solution. What interests me is that GNUCOBOL works and...
-
I really believe that there are people on the forum whose real intention is to prevent this from moving forward.
-
Ralph Says Choose GNU COBOL if: You need a free and open-source compiler. You are learning COBOL or working on small projects. You value community support. Choose Micro Focus COBOL if: You need extensive features and support for various platforms. You are working on enterprise-level COBOL applications. You require performance optimization and integration with other languages. According to Ralph, if you want a "real" compiler, choose MF I hope that GNUCOBOL can serve as a compiler for large-scale...
-
For Ralph The problem is not that GNUCOBOL does not support SCREEN SECTION, it is that it does not seem to behave as expected. Programs compile without problems. So it is not about accepting the "new" screen handling, it is about trying to make screens work as expected or work fine..
-
Simon There are many problems that have been dragging on for a long time. From how it handles numeric fields, how it displays the different CP850, ISO, UTF encodings, to how to delete, append and work with alphanumerics. The extend screen made the problem worse Some time ago we wrote about the problems and I'm going to try to find the document.
-
The framework of the infinite possibilities of COBOL allows us to write perhaps hundreds of thousands of pages. Our reality is that we have approximately 1,000,000 lines of legacy code that we do not wish to reform. We do not use the SCREEN SECTION to accept fields in bulk, we process each field individually. The screen problems have been widely mentioned but are not solved. My purpose is to write the necessary code to solve this and my proposal is if anyone is interested in collaborating on the...
-
To Ralph I don't know CICS, I don't know how exactly the source code that compiles the CICS processing routines can help the SCREEN SECTION work as MF does. Help is welcome. Thanks. To Alain and Eugenio I think Pdcurses and Ncurses don't work exactly the same as what I know of ncurses, the edited numeric and many functionalities require a lot of specific code. To Jack From what I know ADIS is an extension of MF to increase compatibility. We don't plan to incorporate it, for now. To Chuck I've seen...
-
Hello As part of our migration from MF to GNUCOBOL we need the SCREEN SECTION to work the same as MF. We can only address this for NCURSES and LINUX. We do not have the resources or knowledge to address this for Windows. Would anyone be interested in starting a collaboration for this?
-
I think COBOL is alive because it does some things better than other languages. Managing tables with a large number of fields is natural for COBOL. Maybe not so much for C, Java, Php, Python among others. Most Cobol applications handle many fields, many data and quite related. Another interesting thing about COBOL is that since it is easy to read, even if it has been written for a long time, the code is easy to maintain. You must make a significant effort with programs in other languages , if you...
-
I think the ideal environment would be to clone a virtual machine just as I have it. You would have the data and the programs in MF and GNU, you could compile and test the programs and compare what they do. It is a real scenario of legacy code with a lot of data and many programs in operation. Currently the script that compiles compiles both the program in GNU and MF. At night a program updates the data from C-ISAM to BDB. If you are really interested, I would occupy a 10Gb virtual machine and obfuscate...
-
I do not continue with the standard that I download from OpenSuSE Software. I need to have a little time and become proficient in downloading all the dependencies and compiling GNU with the patches since we have updated the OS versions of the servers. I hope to soon have more time and give a push to the migration to GNU. It's a shame that I can't pass the data to you without obfuscating it, because it would be very interesting if you had that entire set of data for testing. Obfuscating them also...
-
Note of interest May 2024: VBISAM is not giving me stress tests. BDB is happening almost all of them. Total files 155 Total Records: About 15 millions Total Index: Primary and alternate 421 Notes: My C-ISAM is standar C-ISAM not MF-CISAM The stress tests are carried out by randomly reading records from differents index. Some errors may probably come from C-ISAM itself. The tests with the ODBC driver against MySQL were very depressing, since it lost a lot of information. We are finalizing a connection...
-
Time sequential read a rewrite with lock and unlock for 315.315 records Record Size 384 bytes Rewrite Index : 1 Index MF with C-ISAM 32 bits 64 bits machine (Program 32) real 0m3,668s user 0m1,945s sys 0m1,721s GNU with BDB 64 bits 3.2 real 0m0,795s user 0m0,643s sys 0m0,061s GNU 4.6 times faster
-
Time sequential read a rewrite with lock and unlock for 1.500.000 Records same program Record Size 445 bytes Rewrite Index : No MF with C-ISAM 32 bits real 0m23.118s user 0m6.420s sys 0m16.685s GNU with BDB 64 bits 3.2 real 0m4.507s user 0m1.008s sys 0m3.084s The same program with GNU 6 times faster Good
-
Hello John https://sourceforge.net/p/gnucobol/discussion/help/thread/bd8650f07a/?limit=25#a592 In this link you have a similar problem and the solution You can send to the terminal everything you say using the mechanism explained in the link If you have any problem or it doesn't work, leave me a comment and I'll help you. Greetings
-
Hi Simon I have verified that records that have null values cause erratic behavior Do you have any news about this? Thank you
-
Thank you very much Eugenio I'm going to take a look at your program and prepare the sample that replaces cobscroll. The point is not having to reform the legacy code, and in this case replace cobscroll with a mechanism that provides the same functionality.
-
Hi Simon Advancement in "solutions" for GNU COBOL we have tested a mechanism to generate scrolling screens in those terminals that support it. It's not very "clean" but it works. The solution is to define the scroll area with its escape sequence, for example: 01 DEFINE-SCROLL-SCREEN. 02 FILLER PIC 99 COMP VALUE 27. 02 FILLER PIC X(6) VALUE "[" 02 SCROLL-START PIC 99 VALUE 1. 02 FILLER PIC X VALUE ";". 02 SCROLL-END PIC 99 VALUE 24. 02 FILLER PIC X VALUE "r". And move this to the screen. The problem...
-
In a quick way Alt-Clear Full Field key doesn't work Cursor-UP and Cursor-Down do not work The insert key does not work, it does not move the field to be able to write PgUp, PgDn, PrtSc (ImPan) Does not display special characters correctly Numeric fields are not treated well by the screen section The date field of the screen section is blocked Scrolls are not resolved Same keys return different values depending on whether they are called from the screen section or normal display
-
Well, from the organization I work for, I myself have a very rusty C and very little time. But I would not like to separate from the GNU COBOL project.
-
Dear Simon I am freer again and I have been thinking about how to put GNUCOBOL into operation. The only solution that I consider viable given the resources we have, our total ignorance of Windows and other COBOL compilers, is to make a version that fully supports the X/OPEN standard with the clean (rewritten) SCREEN SECTION compatible only with MicroFocus Cobol, and only for linux (Rated Distributions) with ESQL,BDD,VBISAM, clarifying the internationalization of characters and the use of UTF. This...
-
Hello everyone, after some time updating the S.O. where are my applications, I have migrated the operation from Kernel 3.4.63 to 5.14.21. Suse 12.2 to SuSe Leap 15.5 I'm going to see if we put GNU Cobol into operation. How can this solution be generalized to all languages? My experience: With the old S.O. A 32-bit Cobol 3.1 version worked for me with CP850 In all new versions, the 2 null characters appear in both CP850 and UTF-8 Thank you
-
Congratulations
-
-
Dear Simon I'm looking at ocsql2's prnerr function. I think that simply always returning the value of err to OC_SQLCODE whenever err != 0, would return the error to the program that returned the handler. Then in the COBOL program you can handle the Error codes according to your convenience. Why pass some yes and others no? Why report errors in standard error and variables? Also, according to the level of OCSQL_LOGLEVEL, it uses 1,9,190,901 as levels that I have not been able to make sense of. I think...
-
My tests OCSQL_LOGLEVEL=999;export OCSQL_LOGLEVEL After insertion DISPLAY "KEY-PART=" KEY-PART ", SQLSTATE=" SQLSTATE ", SQLCODE=" SQLCODE ", SQLERRML" SQLERRML ", SQLERRML WARNING " SQLERRMC(1:SQLERRML) Values returned in all erroneous records PART-KEY=XXXXXXXXX, SQLSTATE=00000, SQLCODE=+0000000000, SQLERRML+00000, SQLERRML WARNING In none of the variables you mention does it return values other than zero. What am I missing? Thank you
-
Thanks for your help I'm going to study the instructions and try esqlOC. I have downloaded GixSQL but it seems complicated to install since it does not respond to ./configure, make etc and I do not see clear instructions. You also comment that the errors will be the same in all of them. I'm going to go deeper because it seems "obvious" that the default configuration should transfer "all" the errors from the D.B. to the user program. Thanks again
-
I have seen this post by Simon https://sourceforge.net/p/gnucobol/discussion/help/thread/8ac15a9083/?limit=25#0398/2189/bb4d which clarifies quite a bit about SQL drivers. What I've looked at from esqlOC it seems that the ODBC layer hides errors from the driver. According to Simon GixSQL is the best alternative
-
I have tried the same data from MySQL cli and the error Incorrect string value: '\x82s. What...' for column 'descrip' at row xx, it's because the original data is in CP850 latin1 and MySQL doesn't seem to like it. The problem that worries me is that esqlOC fails silently, which makes me question the reliability of the driver. Can anyone report experiences on existing precompilers for GNUCOBOL?
-
I continue with the conversion from MF to GNU. Once the data has been passed and trying to keep it updated, it seems that BDB works better than VBISAM. I'm preparing a full suite of tests. As I intend to switch to SQL, I have been testing esqlOC, the version is: esqlOC: ESQL for GnuCOBOL/OpenCOBOL Version 3 (2022.01.15) Build Jan 4 2022. In the first data passes of a file of 1,423,165 records, it records 1,140,245. It fails silently and seems to generally leave logs that have special characters....
-
Sorry, I was looking for a screen ticket and in the end I don't know how I was on this one. The drawback of using these public utilities is that they have their limitations, and it seems that the created ticket cannot be moved. I'm sorry
-
Hi Simon I am writing to you in this ticket because of the comment that does not proceed to follow the same in the improvement Chuck. Regarding the possible ways of treating the screen in a Cobol program, I think this link perfectly clarifies all of them, their advantages and disadvantages. http://www.3kranger.com/HP3000/mpeix/doc3k/BB243390049.15066/54.htm Screen Section, although not from the Ansi standard, is included in X/OPEN. In my opinion, if for now we cannot make the SCREEN SECTION work...
-
Ralph As for eliminating ACCEPT and DISPLAY in the code, I have 29437 Display and 9599 Accepts. I do not see it viable to undertake this modification. At most, if it is not possible to fix the SCREEN-SECTION, changing it to DISPLAY AT could be a more viable task since it would not be very difficult to automate this change. 95% of the application has a lot of interaction with the user. With respect to file management, although in the medium term I plan to move to SQL, from file logic to set logic,...
-
Ralph Tank you very much for your ofreciment. Just to start, some code examples and instructions on where and how to compile it could help me. Screen issues are just some of the problems. I have a lot of problems with the file handlers and serious inconsistencies when passing the information. The same program compiled in an old MF compiler seems to do all the work perfectly in about 20 seconds on average and with GC, apart from taking forever, the errors pile up in so many places that it scares you...
-
Chuck My opinion: I think all efforts to fix and improve things should be valued and supported. What I think should be taken into account in any project that we want to move forward is: Where I am, where I am going, what I intend to be and for whom. And it is very important how I can add resources for the project to advance. I admire Gary Cutler's work on the OpenCobol 1.1 manual. Orderly and methodical, focusing well on what he does. According to the ChangeLog since the beginning of 2016 of 142...
1 >
