I just created a new system using Linuxmint 20.2 and gnucobol 3.2.1
When I compile the following program, it runs but does not display the screen or wait for input.
However if I copy the compiled program to my old machine with Linuxmint 19.3 it does run correctly.
This line is missing from the new install:
extended screen I/O : ncurses, version 6.1.20180127 (CHTYPE=64, WIDE=1)
xterm with 256 colors
mouse support : yes
Thanks, will do more reading.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed libcurses-6.2-20210710 and when I re-run configure and make , I get the following error:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/libncurses.a(lib_addch.o): relocation R_X86_64_PC32 against symbol `TABSIZE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Should I go back to an older version of ncurses?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, that worked.
In retrospect it may have been easier to install Gnucobol2-2 from the software manager, and then upgraded to version 3 as the software manager would have handled all the prerequisites.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure, because a build normally needs "dev" packages (and make and ...) what the packaged versions normally don't have (those commonly have a dependency to the much smaller runtime pacakges only).
But as GC 2.2 is "outdated" I suggest to get in contact with the package managers, asking for an update to GC 3.1.2 (then adding libxml2 and jsonc - to include those additional functions of GC 3).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For Juan.
Although the . MP4 depicts CICS, the dialog also works for CLI or called.
Chuck H has created Linux / Windows versions of the primitives used by the dialog.
Ralph
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm just finishing up the last steps to post my builds for supporting multiple windows with GNUCOBOL. I should have a post with downloads ready by early evening my time.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for leading to a topic drift... let's discuss the CISAM compat in a separate new topic - please give the details above and possibly more in that. I do think that this should work out.
Please also specify the exact version of VBISAM you've used and if you configured that using --with-compatcisam which seems necessary to fully support those old files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 that you have advanced work, especially in the treatment of numeric fields. We don't plan to repeat the work that has been done. We are very interested in it. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-01
To manage a numeric field on the screen (sign, decimals ...) , I think the best way, at the moment, is described here:
Hi,
DISPLAY and ACCEPT of a screen with multiple fields present in SCREEN SECTION requires a screen management technique of the same type as that required by CICS on mainframe with its SEND and RECEIVE MAP (from a MAPSET).
The user can type just one or all of the fields of a screen before pressing ENTER and returning control to the program.
With both SCREEN SECTION and CICS MAP you could also define a SCREEN or a MAP with a single field and manage them individually (but this is not a very common choice).
Normally all the fields of the same screen are received together from the program.
The COBOL program then checks each field and reports to the user, the various errors of the individual fields if there are any.
With visual/graphical interfaces the logic is usually different.
Usually each field is checked by the program as it is typed by the user.
Normally a concept similar to SCREEN SECTION or CICS MAP on the mainframe is not used whit visual/graphical interfaces.
This behavior of managing the checks of the individual fields, as they are typed, can be replicated with the various COBOL compilers on UNIX and WINDOWS and also with GnuCOBOL using single DISPLAY and ACCEPT of the individual fields (GnuCOBOL has everything you need).
In this case the technique that I indicated in my previous post to check the numeric fields, in my opinion, is the best in the state of the art.
SCREEN SECTION is a feature that should be used when convenient, it is not a mandatory requirement to interact with the user.
A complete and working example can be found here: https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS
There is a complete and working suite of some programs GC71CRUDExxx.COB.
Among them C71CRUDECUD.COB also performs singe fields DISPLAY / ACCEPT and checks on some numeric fields with commas and decimals.
Obviously the above expresses a personal opinion and a contribution to the discussion that reflects my experience.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-01
Sometimes , Eugenio,
you make me feel... stupid!
I know that's not on purpose!
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-01
About the alternatives to SCREEN SECTION, one can use a PERFORM with a «field index»... with tables...
...with LINE/COLUMN references...
...and... colors and/or attributes!
It's fine, too!
Mário Matos
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-01
«We don't plan to repeat the work that has been done. We are very interested in it. Thanks.»
What do you expect, then?
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
'The' best way to process accepting numbers etc, is to use Chuck's routine ACCEPT_NUMERIC which is a C routine that you call having preset some variables along with the target address field.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to report my opinion on the CBL_ACCEPT_NUMERIC function created by Chuck.
This function actually replaces the ACCEPT instruction but does not have all its capabilities and features. So at the moment in my opinion it is not advisable.
This function allows the management of numeric fields with USAGE DISPLAY but also of fields with USAGE COMP etc etc. As an example I remember that the Microfocus compiler limits the accept of numeric fields to only USAGE DISPLAY. It is not necessary to complicate your life to make the user type a field that is defined as COMP in the program.
In the long run, what is needed and what is still missing in GnuCOBOL is a management of the numeric field done by the system automatically when you execute an ACCEPT of a numeric field (PIC 9) with sign and with decimal digits that is in USAGE DISPLAY format.
The document I am attaching describes how the system should behave.
Having this automatic function, it would not be necessary to do any formal program checks. As is the case for PIC X fields.
My intent was to create a simple function which could be used from a COBOL program to accept a numeric field which did all of the editing to ensure that the value input matched the COBOL field passed to it.
If there is functionality which you which you think that should be added to the ACCEPT_NUMERIC function, please expand on that. Additional functionality could be added to the existing function. It has been a while since I created this so I would have to refresh my memory of it. I think that it has implemented most of the points you have in you document, at least the major ones.
However since a number of people are using the current function, we would have to consider how to implement any changes with minimal impact to those using the current function.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just created a new system using Linuxmint 20.2 and gnucobol 3.2.1
When I compile the following program, it runs but does not display the screen or wait for input.
However if I copy the compiled program to my old machine with Linuxmint 19.3 it does run correctly.
It does not matter which system I compile the program on, it only works on the old system.
Am I missing a library, or is it something else?
Last edit: Simon Sobisch 2021-07-13
Compiled with:
cobc -x -std=mf p.cbl
What is the output of
cobcrun -v --info?I assume your old environment has extended screenio compiled into libcob, the new one doesn't.
Last edit: Simon Sobisch 2021-07-13
This line is missing from the new install:
extended screen I/O : ncurses, version 6.1.20180127 (CHTYPE=64, WIDE=1)
xterm with 256 colors
mouse support : yes
Thanks, will do more reading.
I installed libcurses-6.2-20210710 and when I re-run configure and make , I get the following error:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/libncurses.a(lib_addch.o): relocation R_X86_64_PC32 against symbol `TABSIZE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Should I go back to an older version of ncurses?
It uses the static library of ncurses, I suggest to remove that, then install libncurses5-dev, then re-
configureandmake.Thanks, that worked.
In retrospect it may have been easier to install Gnucobol2-2 from the software manager, and then upgraded to version 3 as the software manager would have handled all the prerequisites.
Not sure, because a build normally needs "dev" packages (and make and ...) what the packaged versions normally don't have (those commonly have a dependency to the much smaller runtime pacakges only).
But as GC 2.2 is "outdated" I suggest to get in contact with the package managers, asking for an update to GC 3.1.2 (then adding libxml2 and jsonc - to include those additional functions of GC 3).
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?
For Juan.
Although the . MP4 depicts CICS, the dialog also works for CLI or called.
Chuck H has created Linux / Windows versions of the primitives used by the dialog.
Ralph
Last edit: Ralph Linkletter 2024-08-25
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
The binaries of Gnucobol for Windows provided from Superbol or Arnold Trembley include pdcurses not ncurses.
Is it your intention to replicate ADIS ?
https://www.microfocus.com/documentation/object-cobol/ocu42/uiuadc.htm
I'm just finishing up the last steps to post my builds for supporting multiple windows with GNUCOBOL. I should have a post with downloads ready by early evening my time.
Sorry for leading to a topic drift... let's discuss the CISAM compat in a separate new topic - please give the details above and possibly more in that. I do think that this should work out.
Please also specify the exact version of VBISAM you've used and if you configured that using
--with-compatcisamwhich seems necessary to fully support those old files.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 that you have advanced work, especially in the treatment of numeric fields. We don't plan to repeat the work that has been done. We are very interested in it. Thanks.
To manage a numeric field on the screen (sign, decimals ...) , I think the best way, at the moment, is described here:
https://gnucobol.sourceforge.io/faq/index.html#how-can-i-properly-manage-numeric-fields-with-extended-screen-io
And I think the best way to manage «input/edit» fields is... NOT USING...
...SCREEN SECTION...
...at all!
One field at a time...
...labels...
...and with IF THEN... GO TO «label»...
...with each «field» beeing a separate entity!
If we get a «field» with an «inconsistent» or «dependent» value... (from other field)
...we can send it to... hell...
...unless, each field have implicit... exceptions «anexed» to it!
But that's just me!
Mário Matos
:-)
Hi,
DISPLAY and ACCEPT of a screen with multiple fields present in SCREEN SECTION requires a screen management technique of the same type as that required by CICS on mainframe with its SEND and RECEIVE MAP (from a MAPSET).
The user can type just one or all of the fields of a screen before pressing ENTER and returning control to the program.
With both SCREEN SECTION and CICS MAP you could also define a SCREEN or a MAP with a single field and manage them individually (but this is not a very common choice).
Normally all the fields of the same screen are received together from the program.
The COBOL program then checks each field and reports to the user, the various errors of the individual fields if there are any.
With visual/graphical interfaces the logic is usually different.
Usually each field is checked by the program as it is typed by the user.
Normally a concept similar to SCREEN SECTION or CICS MAP on the mainframe is not used whit visual/graphical interfaces.
This behavior of managing the checks of the individual fields, as they are typed, can be replicated with the various COBOL compilers on UNIX and WINDOWS and also with GnuCOBOL using single DISPLAY and ACCEPT of the individual fields (GnuCOBOL has everything you need).
In this case the technique that I indicated in my previous post to check the numeric fields, in my opinion, is the best in the state of the art.
SCREEN SECTION is a feature that should be used when convenient, it is not a mandatory requirement to interact with the user.
A complete and working example can be found here:
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS
There is a complete and working suite of some programs GC71CRUDExxx.COB.
Among them C71CRUDECUD.COB also performs singe fields DISPLAY / ACCEPT and checks on some numeric fields with commas and decimals.
Obviously the above expresses a personal opinion and a contribution to the discussion that reflects my experience.
Sometimes , Eugenio,
you make me feel... stupid!
I know that's not on purpose!
:-)
About the alternatives to SCREEN SECTION, one can use a PERFORM with a «field index»... with tables...
...with LINE/COLUMN references...
...and... colors and/or attributes!
It's fine, too!
Mário Matos
:-)
«We don't plan to repeat the work that has been done. We are very interested in it. Thanks.»
What do you expect, then?
:-)
'The' best way to process accepting numbers etc, is to use Chuck's routine ACCEPT_NUMERIC which is a C routine that you call having preset some variables along with the target address field.
I would like to report my opinion on the CBL_ACCEPT_NUMERIC function created by Chuck.
This function actually replaces the ACCEPT instruction but does not have all its capabilities and features. So at the moment in my opinion it is not advisable.
This function allows the management of numeric fields with USAGE DISPLAY but also of fields with USAGE COMP etc etc. As an example I remember that the Microfocus compiler limits the accept of numeric fields to only USAGE DISPLAY. It is not necessary to complicate your life to make the user type a field that is defined as COMP in the program.
In conclusion I confirm that, at the state of the art, the best solution is to use what is present in the FAQ at https://gnucobol.sourceforge.io/faq/index.html#how-can-i-properly-manage-numeric-fields-with-extended-screen-io
And everything in the COBOL standard and therefore completely portable.
In the long run, what is needed and what is still missing in GnuCOBOL is a management of the numeric field done by the system automatically when you execute an ACCEPT of a numeric field (PIC 9) with sign and with decimal digits that is in USAGE DISPLAY format.
The document I am attaching describes how the system should behave.
Having this automatic function, it would not be necessary to do any formal program checks. As is the case for PIC X fields.
Last edit: Eugenio Di Lorenzo 2024-09-01
Eugenio,
My intent was to create a simple function which could be used from a COBOL program to accept a numeric field which did all of the editing to ensure that the value input matched the COBOL field passed to it.
If there is functionality which you which you think that should be added to the ACCEPT_NUMERIC function, please expand on that. Additional functionality could be added to the existing function. It has been a while since I created this so I would have to refresh my memory of it. I think that it has implemented most of the points you have in you document, at least the major ones.
However since a number of people are using the current function, we would have to consider how to implement any changes with minimal impact to those using the current function.