Juan Carlos Escartí

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.