Activity for Juan Carlos Escartí
-
Juan Carlos Escartí posted a comment on discussion GnuCOBOL
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...
-
Vincent I have 500,000 lines of COBOL code working every day. 3 People continue to develop COBOL code every day. I am the first person interested in COBOL having a future. I can prove that today GC is not working. And I can prove it with data and facts. I want to help make GC an alternative to MF, COBOL-IT, and others. And I think it is a task that far exceeds the capacity of what a single person can do. Therefore I would like to know: What can we all do to make GC really the future of COBOL? Kind...
-
Eugenio I think we are on the same page. We really want our programs to work at least the way they used to, and work well. I still think that no one is thinking about writing a Cobol application from scratch. It is legacy software code that has been developed in the past and is still used today.
-
Dear Ralph Of course, displaying and managing the screen in the browser is the option for the future. Also MySQL or Postgress and not indexed files. The question is: Who wants Cobol today. I think that someone who has written a lot of code, maybe hundreds of thousands of lines, and it's working. I doubt that today from scratch anyone will consider making a new application in Cobol. We provide an easy migration solution to the 2 main environments, that code will continue working. Migrating should...
-
Hello Chuck First of all, get better. Without health we have nothing, especially those of us who are already of a certain age. Regarding an acceptable standard, I could only tell you that very old Cobol that I used before MF, they all seem to work the same. From this on I have no other experience. The problem with GC is that since version 1.1 it forgets to accept numerical fields. It accepted the numbers as strings and with the function MOVE FUNCTION NUMVAL(ACCEPT-FIELD) TO FIELD-DEST, it converted...
-
Since January 2015 I have been installing and following successive versions of first OpenCobol 1.1 and then GNUCOBOL. The first ones were missing the split secondary keys, the screen section and some other deficiencies. Since then I have seen the feasibility of moving my system to GC and I have never been able to at first due to shortcomings and now due to errors. I think that if we want GC to be a stable mature product that can replace exploited compilers, we should help Simon eliminate bugs and...
-
Chuck Regarding the observations that the errors may be from the database, I think some if not others. For example vbisam rewrites very slowly, it seems to be from VBISAM. BDB adds records very slowly when there are many keys it seems like BDB. However, the fact that the reading slows down as more records are read does not seem to be from BDB or VBISAM. I believe that every problem has a origin and a solution. I totally agree that the future is VBISAM. At least we can solve the problems since we...
-
One of the errors I'm tracking and isolating is in the part where I compare the registry to see if it has changed. IF COBRA-STATUS = I-O-OK IF COBRA-RECORD = AUX-QUERY-RECORD GO TO PROCESS-COBRADOR-02 ELSE MOVE QUERY-RECORD TO COBRA-RECORD DISPLAY "CHANGE: COBRADOR" COBRA-KEY PERFORM CHANGE-COBRADOR END-IF END-IF On numerous occasions it registers the record and at the same time indicates that it has changed, which is not possible. Others indicate modified records that I am certain have not been...
-
Sorry the GNUPDAT.cob program
-
Chuck This is the program I am using to keep up-to-date data in VBISAM and BDB from the MF C-ISAM source. It has the libraries deployed. Reads the C-ISAM .dat as if it were plain text (It actually is) and saves if it does not exist the record in the destination. In reality the entire program is the same. Reads C-ISAM sequential .dat files and writes an indexed file VBISAM o BDB depending of COBOL filehandler. Tell me what you may need and I'll prepare it for you. I would also like to know what exactly...
-
My source data changes daily (it is in exploitation), it is very difficult to reproduce exactly the same tests. To solve it I have prepared a btrfs file system with snapshots to accurately reproduce the tests and errors. They have approximately 2.5Gb of data and indexes and 2.5 million records in 80 files with many split alternative keys. Safe and tested BDB, loses information in passes. I am going to do a rigorous set of tests that will be able to detect, extract and isolate everything that could...
-
chuck All contributions are welcome. The behavior of the numbers in GC needs to be fixed, and the inconsistencies between the extended screen and the standard one as well. It behaves differently, responds differently to the same keys. I am de-oxidizing my skills in C, to collaborate in doing it. For now I am moving to VBISAM C-ISAM programs, file maintenance utilities that I will upload when it is finished in case anyone is interested. This is refreshing my C since they were made in 1988. Since then...
-
Whoever really works at Cobol usually writes a lot of numbers. Almost any numerical input works similarly. Number from left to right, cursor to move through the figures, some delete key, etc. This is an entrenched and recurring issue. Taking MF as a model can be a solution. I could provide ssh access to a machine with MF. Kind regards
-
Test Results GNUCOBOL 3.2 WITH BDB real 0m5,873s user 0m5,643s sys 0m0,074s GNUCOBOL 3.2. WITH VBISAM real 1m24,979s user 1m21,339s sys 0m3,608s MF II V 1.1 WITH C-ISAM real 0m3.205s user 0m1.564s sys 0m1.596s
-
VBISAM rewrite to slow
-
Reading your answers I almost totally agree. It seems to be a VBISAM rewrite issue BDB the rewrite is very fast. If it is a VBISAM or GNUCOBOL-VBISAM problem, I think the answer will be given by the C program that does exactly the same thing. I think the important thing is to find the origin of the problems and solve them. This will make GNUCOBOL the only alternative for the coming decades. Kind regards
-
I'm back from my outing It's 4:41 p.m., almost 12 hours The process continues Performance similar to 8-bit processors and systems from the 80s. Well that's what we have I hope we solve it soon Kind regards
-
Note on the previous ticket. At 6:33 today I started a GNUPDAT run on VBISAM. It's 09:25 I have to leave and it's not over yet. We've been there for 180 minutes so far. For other applications that I have in C with C-ISAM, with VBISAM in C exactly the same will not take more than 2/3 minutes.
-
I am creating a transpiler to fix the Cobol code to pass the READ writes to SQL statements, make automatic changes that facilitate the migration, etc. There is a version 0.1 of transpiler.awk underway and the documentation for it can be found here: https://docs.google.com/document/d/1n2-62EtM9IiUj-4LN-Er1dOJRahvRrt2zXNa7b8kNhQ/edit?usp=sharing The transpiler is very flexible and is prepared to transpile between languages Cobol -> Java, COBOL -> C etc, COBOL --> SQL etc. If anyone is interested in...
-
Dear Simon Reading your answer further it seems that this is a side effect of trying to keep many indexed handlers in the same file, see post https://sourceforge.net/p/gnucobol/bugs/928/#bd64 Everything that seems to have to be done in the C program that manages indexed files is solved by C-ISAM, VBISAM, and probably BDB natively. iswrite, isrewrite, isrewcurr etc are native functions of the isam libraries. I think putting an "extra" layer to the indexing manager will always degrade its performance,...
-
GNUPDAT Program with libraries displayed
-
Thanks for your work Simon I am going to digest your answer since I still don't understand the GNUCOBOL jargon very well and I have to familiarize myself with the C programs and the compiler. The results you get are really good and seem to solve this performance problem. The tests that I have given you are a part of a program that passes all the data, about 80 files and 2,550,000 records, and I think GNU has some problems. It is generally where I find panics (in complete passes or updates), and also...
-
Here are the tests, they are in tgz, tar gzip format. Deploy to any directory and read Reame.1st and Readme.md. They occupy 90Mb compressed and around 700Mb decompressed. The results depend on the GNU version and indexing engine. As a curious note, BDB seems to have a sleep in the write because the system time is similar to VBISAM and C-ISAM, but the total time is almost on the order of 1000 times greater. Note: The file is too large to attach to the post. I upload it to https://www.liberatusdeudas.es/test_index_gnucob.tgz...
-
That's another intensive data rewriting program. These programs are a different set of tests (TEST000/004) on a single file. I'm going to see if I can finish it today and upload the programs and data.
-
db_verify is in SuSe in the db48-utils package. But the last time I installed it, it didn't seem compatible with the libraries that GNU Cobol uses for BDB, and I currently don't have it installed.
-
Parcial result test Task write 1.388.081 records in indexed file (TEST000 program) GNU 3.2.2 with VBISAM 2.2 real 2m4,048s user 1m37,741s sys 0m25,193s GNU 3.2.2 with BDB real 199m35,132s user 197m59,859s sys 1m20,177s MF II v 1.1 with C-ISAM real 5m55.896s user 1m20.837s sys 1m55.523s Task Rewrite indexed file 1.388.081 read data from txt file (TEST001 program) GNU 3.2.2 with VBISAM 2.2 real 23m44,634s user 23m16,076s sys 0m28,450s MF II v 1.1 with C-ISAM real 0m26.588s user 0m16.189s sys 0m9.893s...
-
Continuing with the thread of your answer. I prefer with BDB to follow the standard version of the SUSE repository, which I imagine is "your official version for Linux". Frankly, Ron's VBISAM 2.1.1 is much better and faster. In the stress and balance tests VBISAM is almost perfect. BDB loses information in conversions. Changing to BDB 6.0.19 forces me to load "my libraries", do my compilation, etc. etc. This makes it very difficult to track and fix bugs, because different systems can have different...
-
Thanks for your quick response. Yes, on Monday I will have a set of tests prepared. In another sense I have been looking at the code mainly from fileio.c and screenio.c. A few years ago I had a similar problem. I had to run our programs on HP/Ux, Aix, Solaris, ATT, SCO, etc. At first we started with solutions similar to yours. Conditioning IF that will determine the actions according to the S.O.. Soon this caused multiple side effects. The solution that worked perfectly for us was to have a file...
-
Standar SUSE Linux Repositoris 15.4 Copyright (C) 2023 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 Aug 23 2023 12:00:00 Packaged Aug 23 2023 14:17:53 UTC build information build environment : x86_64-suse-linux-gnu...
-
Panic with Berkeley B.D and not with VBISAM
-
Program with libraries displayed
-
They have preparing a test data set and program. This updates a movement file of 269,000 records to 3 master files. The program simply clears the masters and sets a byte of the movements file to 0. Readings are done with blocking. The data I have is: It is in tar gz format MF -- C-ISAM --> real 0m03.204s GNU 3.2.2 - VBISAM --> real 2m19,659s The behavior is always the same, it starts fast for approximately the first 40,000 records and little by little it gets slower and slower.
-
Thanks for your answer sorry for being late I think the best way is a virtual machine configured with both MF and GNU systems with a few million real records. The format could be qcow There are also some singularities: Same program same data entry different results if you do VBISAM vs BDB. VBISAM 2.2 Ok BDB records are missing. It's strange when I find out more I will report I am in a very advanced phase of moving from MF to GNU 500,000 lines of code and about 2,500,000 data records. The main problems...
-
By carrying out extensive tests with GNU 3.1.2 and GNU 3.2, I can confirm that the sequential reading slows down as the program reads more records. Around 500,000, performance begins to drop and continues to drop as the number of registrations increases. The SuSE Linux OS different versions and Kernels. GNU has been compiled, loaded the binaries from the SuSE repositories, compiled sources and tested with VBISAM and BDB, the same thing always happens. The difference can be 1-20 times with MF COBOL,...
-
To accept fields it makes 2 different calls cob_field_accept cob_screen_accept The 2 calls respond to different function keys, which makes little sense for the same application to have different keys to handle the fields. For example if you call with cob_field_accept alt-del it deletes the entire field If you call cob_screen_accept, this doesn't happen In the same way with cob_screen_accept it fills the field with underscores "_" which does not happen with cob_field_accept If you put the locale cob_screen_accept...
1