Alain Reymond

Dear Juan, If I am not mistaken, both the binaries of Gnucobol for Windows provided from Superbol or Arnold Trembley include ncurses. So it should not be a problem for the screen section. Regards

You could try a much more up-to-date environment. I assume that you work under windows (you notice dll). Try Gnucobol + VSCode + Superbol. You have a nice code editor (VScode) with a nice extension to compile, edit, debug cobol code (Superbol). https://superbol.eu/en/software/ PS : I am just a convinced user of this environment ;-))

Did you have a look at : https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/cobweb/cobweb-pipes/ Might be useful

You are absolutely right. No warning issued. I was just confused because we are porting (or trying to!) an app from MF to Gnucobol and it works without any problem under MF. Now, we know!

As follow-up, the solution is ti use the numval function : move numval(wss-test) to mydouble But the difference of behaviour of the two compilers is still astonishing.

Hello, here is a small program : 1 mydouble usage float-long. 1 wss-test pic -99.99. procedure division. move -21.42 to mydouble display "double : " mydouble move -21.42 to wss-test move wss-test to mydouble display "wss-test: " wss-test display "double : " mydouble Here is the result using Gnucobol: double : -21.42 wss-test: -21.42 double : 13224.42 and using MF: double : -.214200000000000015E 002 wss-test: -21.42 double : -.214200000000000015E 002 The result of the move from a pic -99.99 is "correct"...

Perhaps this contribution is a little late... We have a project of roughly the same size, divided into two applications, one with 150 programmes, the other with 750 programmes. It's not RM/Cpbol but MF. We're running on Linux and use VSCode + Superbol (thanks to them!) for the write/compile/debug cycle and Codeium to make writing the code easier. We were able to port the first part, which is in 'standard' Cobol, fairly easily. The characteristics of the code include * free format, * structured programming...

As ever, the devil is in the detail. The DBNAME sould be MOVE "pgsql://localhost:5432/testsql" TO DBNAMEwhen working with postgresql. But it might be confusing because ocesql asks only for the dbname...