Activity for GnuCOBOL

  • Chuck H. Chuck H. posted a comment on discussion GnuCOBOL

    I have a working version of GNUCOBOL which supports the RM/COBOL popup windows via the WCB (Windows Control Block). If you are interested, leave a comment and I can post a link to download it. Chuck Haatvedt

  • Eric Raskin Eric Raskin posted a comment on discussion GnuCOBOL

    OK -- I can give it a try. Thanks. On Tue, Sep 17, 2024 at 1:33 PM Simon Sobisch sf-mensch@users.sourceforge.net wrote: You likely want to debug GnuCOBOL programs in any case, so consider building GDB on that machine (we did the same for our RHEL7+RHEL8 environments in the company) as follows: Source: https://ftp.gnu.org/gnu/gdb/ - the following packages must be installed: * mpfr-devel * expat-devel * python3-devel (use python36-devel on RHEL8) * texinfo * gcc-c++ * xz-devel After that it's only...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    You likely want to debug GnuCOBOL programs in any case, so consider building GDB on that machine (we did the same for our RHEL7+RHEL8 environments in the company) as follows: Source: https://ftp.gnu.org/gnu/gdb/ - the following packages must be installed: * mpfr-devel * expat-devel * python3-devel (use python36-devel on RHEL8) * texinfo * gcc-c++ * xz-devel After that it's only a configure (possibly with --prefix, but if possible I'd install into the default one) + make + make install. In general...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    I've given up the attempt. I am working on a very old system (Oracle Linux 7) that I am trying to upgrade - which is why I'm trying to migrate off of my ancient MF Cobol compiler. I can't even debug my code - -ggdb3 won't work with my ancient gdb. I recompiled the entire system with -gdwarf-2 to make gdb load the code, but the breakpoints don't line up with the listings. I can't debug the libcob fileio.c cob_open() subroutine to see what is going wrong. I do see that it should handle the file redirection...

  • Eric Raskin Eric Raskin posted a comment on discussion GnuCOBOL

    I've given up the attempt. I am working on a very old system (Oracle Linux 7) that I am trying to upgrade - which is why I'm trying to migrate off of my ancient MF Cobol compiler. I can't even debug my code - -ggdb3 won't work with my ancient gdb. I recompiled the entire system with -gdwarf-2 to make gdb load the code, but the breakpoints don't line up with the listings. I can't debug the libcob fileio.c cob_open() subroutine to see what is going wrong. I do see that it should handle the file redirection...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    Note - I run on Linux (CentOS 7 at the moment, but trying to upgrade). I have a very old program (Group 1 List Convert Plus) written in MF Cobol. It uses EXTFH extensively. Under MF Cobol, I am able to use the <, > and | redirects in a DD_ environment variable to redirect the program to read and write from/to pipes without coding changes. I use it like this: export DD_LCCVNAM="< cat" export DD_LCCVFWD="> cat" cat myfile | cobrun LCP10 | .... This redirects to the program "cat" allowing me to put...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    I'm actually trying to make it happen right now. First attempt broke the pipe and stdin/stdout tests. ;-)

  • Juan Carlos Escartí Juan Carlos Escartí posted a comment on discussion GnuCOBOL

    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?

  • Eric Raskin Eric Raskin posted a comment on discussion GnuCOBOL

    I'm actually trying to make it happen right now. First attempt broke the pipe and stdin/stdout tests. ;-) On Mon, Sep 16, 2024 at 3:41 PM Simon Sobisch sf-mensch@users.sourceforge.net wrote: Yes, that should be possible - do you want to give it a try on your own? Add < and > redirect to EXTFH open https://sourceforge.net/p/gnucobol/discussion/cobol/thread/54006dc00c/?limit=50#2d12/a9fc Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnucobol/discussion/cobol/...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Yes, that should be possible - do you want to give it a try on your own?

  • Juan Carlos Escartí Juan Carlos Escartí posted a comment on discussion Help getting started

    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

  • Eric Raskin Eric Raskin modified a comment on discussion GnuCOBOL

    Note - I run on Linux (CentOS 7 at the moment, but trying to upgrade). I have a very old program (Group 1 List Convert Plus) written in MF Cobol. It uses EXTFH extensively. Under MF Cobol, I am able to use the <, > and | redirects in a DD_ environment variable to redirect the program to read and write from/to pipes without coding changes. I use it like this: DD_LCCVNAM = "< cat" DD_LCCVFWD = "> cat" cat myfile | cobrun LCP10 | .... This redirects to the program "cat" allowing me to put the COBOL...

  • Eric Raskin Eric Raskin modified a comment on discussion GnuCOBOL

    Note - I run on Linux (CentOS 7 at the moment, but trying to upgrade). I have a very old program (Group 1 List Convert Plus) written in MF Cobol. It uses EXTFH extensively. Under MF Cobol, I am able to use the <, > and | redirects in a DD_ environment variable to redirect the program to read and write from pipes without coding changes. I use it like this: DD_LCCVNAM = "< cat" DD_LCCVFWD = "> cat" cat myfile | cobrun LCP10 | .... This redirects to the program "cat" allowing me to put the COBOL program...

  • Eric Raskin Eric Raskin modified a comment on discussion GnuCOBOL

    Note - I run on Linux (CentOS 7 at the moment, but trying to upgrade). I have a very old program (Group 1 List Convert Plus) written in MF Cobol. It uses EXTFH extensively. Under MF Cobol, I am able to use the <, > and | redirects in a DD_ environment variable to redirect the program to read and write without coding changes. I use it like this: DD_LCCVNAM = "< cat" DD_LCCVFWD = "> cat" cat myfile | cobrun LCP10 | .... This redirects to the program "cat" allowing me to put the COBOL program in a pipe....

  • Eric Raskin Eric Raskin posted a comment on discussion GnuCOBOL

    I have a very old program (Group 1 List Convert Plus) written in MF Cobol. It uses EXTFH extensively. Under MF Cobol, I am able to use the <, > and | redirects in a DD_ environment variable to redirect the program to read and write without coding changes. I use it like this: DD_LCCVNAM = "< cat" DD_LCCVFWD = "> cat" cat myfile | cobrun LCP10 | .... This redirects to the program "cat" allowing me to put the COBOL program in a pipe. Rewriting the Group 1 code is not a great option, as it also has to...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the hint. Shall I assume that when you mention "and friends" you mean CBL_READ_FILE? I can give it a try. The CBL_READ_FILE command has an offset though, for /dev/stdin I can only think of trying setting that offset to zero. I have also read the option for handling stdin/stdout as sequential in the faq, although that can not handle reading different sized records since you define the fixed length record associsted to the file in the FD definition.

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the hint. Shall I assume that when you mention "and friends" you mean CBL_READ_FILE? I can give it a try. The CBL_READ_FILE command has an offset though, for /dev/stdin I can only think of trying setting that offset to zero. I have also read the option for handling stdin/stdout as sequential in the faq, although that can not handle reading different sized records since you define the fixed length record associsted to the file in the FD definition.

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    Thanks for the hint. Shall I assume that when you mention "and friends" you mean CBL_READ_FILE? I can give it a try. The CBL_READ_FILE command has an offset though, I can only think of trying setting that offset to zero. I have also read the option for handling stdin/stdout as sequential in the faq, although that can not handle reading different sized records since you define the fixed length record associsted to the file in the FD definition.

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    I've thought about CBL_OPEN_FILE and friends (use the "file names" /dev/stdin and /dev/stdout). As alternative you can use "normal" sequential files as well, which should be a bit more portable and "COBOL-like" for an example see https://gnucobol.sourceforge.io/faq/index.html#can-gnucobol-be-used-to-write-command-line-stdin-stdout-filters.

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    I do not see why binary data should not be passed via pipes. stdin/stdout was intended to accept both binary and text , not just lines of text. SysV IPC messaging has limitations on size, it is intended for small messages, it is cumbersome to use (I have used them in C in the past) and using to move around anything which is not a short message deviates from its purpose. Files require intermediate files. I am using the COBOL invoked via CGI, but the CGI is handled externally via a script that invokes...

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    I do not see why binary data should not be passed via pipes. stdin/stdout was intended to accept both binary , not just lines of text. SysV IPC messaging has limitations on size, it is intended for small messages, it is cumbersome to use (I have used them in C in the past) and using to move around anything which is not a short message deviates from its purpose. Files require intermediate files. I am using the COBOL invoked via CGI, but the CGI is handled externally via a script that invokes the COBOL...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Binary data should not be passed via process pipes on the command line, if you want that you are better using either "real files" or direct IPC calls like msgsnd/msgrcv. In theory you could also use the bytestream functions to read from sysing / write to sysout, but that means you need to know the size up-front / send a separate size at the front (but that would also be true for IPC if you use a single type; but of course you'd pass a message type and for example have one type per size).

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    Thanks for your answer Simon For the ACCEPT: I am using the second option (splitting fields with \n) which is, as you say, the less complicated option. But I wanted to understand if there was an option to read just the bytes required by the field. I have a follow up question on this: what if you want to include '\n' as part of the input in a field? This can happen in some scenarios, for instance: - you want to pass a binary stream (a file, image, or whatever). - you have a record WS-CUSTOMER with...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    I am trying to use GnuCOBOL to parse data using input from standard input and delivering output to standard output (in the traditional UNIX way). In particular, if I want to read a PIC9999 and then a PICXXXX. Is it possible to ask GnuCOBOL to read two records from the standard input? Which would be the minimum version of the following program? IDENTIFICATION DIVISION. PROGRAM-ID. TEST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-NUMERIC-INPUT PIC 9999. 01 WS-TEXT-INPUT PIC XXXX. 01 WS-NUMERIC-OUTPUT...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    ACCEPT operates on sysin ended with newline - the unix way. You have two options: change to bytestream function, that way you can request a size - but for sysin you possibly will wait until that gets in, which may be "never" put data with a newline separated, in this case printf "1234\nabcd\n" | ./TEST (that's much less complicated and works also with several environments, so my personally suggested solution) For the other question: DISPLAY something WITH NO ADVANCING. Fair warning: a "plain" ACCEPT...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    I am trying to use GnuCOBOL to parse data using input from standard input and delivering output to standard output (in the traditional UNIX way). In particular, if I want to read a PIC9999 and then a PICXXXX. Is it possible to ask GnuCOBOL to read two records from the standard input? Which would be the minimum version of the following program? IDENTIFICATION DIVISION. PROGRAM-ID. TEST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-NUMERIC-INPUT PIC 9999. 01 WS-TEXT-INPUT PIC XXXX. 01 WS-NUMERIC-OUTPUT...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    I am trying to use GnuCOBOL to parse data using input from standard input and delivering output to standard output (in the traditional UNIX way). In particular, if I want to read a PIC9999 and then a PICXXXX. Is it possible to ask GnuCOBOL to read two records from the standard input? Which would be the minimum version of the following program? IDENTIFICATION DIVISION. PROGRAM-ID. TEST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-NUMERIC-INPUT PIC 9999. 01 WS-TEXT-INPUT PIC XXXX. 01 WS-NUMERIC-OUTPUT...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    I am trying to use GnuCOBOL to parse data using input from standard input and delivering output to standard output (in the traditional UNIX way). In particular, if I want to read a PIC9999 and then a PICXXXX. Is it possible to ask GnuCOBOL to read two records from the standard input? Which would be the minimum version of the following program? IDENTIFICATION DIVISION. PROGRAM-ID. TEST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-NUMERIC-INPUT PIC 9999. 01 WS-TEXT-INPUT PIC XXXX. 01 WS-NUMERIC-OUTPUT...

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    I am trying to use GnuCOBOL to parse data using input from standard input and delivering output to standard output (in the traditional UNIX way). In particular, if I want to read a PIC9999 and then a PICXXXX. Is it possible to ask GnuCOBOL to read two records from the standard input? Which would be the minimum version of the following program? IDENTIFICATION DIVISION. PROGRAM-ID. TEST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-NUMERIC-INPUT PIC 9999. 01 WS-TEXT-INPUT PIC XXXX. 01 WS-NUMERIC-OUTPUT...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    Sorry Simon, I meant to say that in your previous post you wrote REVERSEDwhen you probably meant to write REVERSE.

  • Eugenio Di Lorenzo Eugenio Di Lorenzo modified a comment on discussion GnuCOBOL

    REVERSED is an OPEN clause ... ?!?!? You probably meant to write REVERSE

  • Ralph Linkletter Ralph Linkletter posted a comment on discussion GnuCOBOL

    List of Obsolete Language Elements: The elements of the COBOL language listed here are marked as obsolete in the ANSI X3.23-1985 COBOL specification. They are to be deleted at the next revision of the standard COBOL specification. They will not be enhanced, modified or maintained. They should not be used in a conforming X/Open source program. Associating the figurative constant ALL literal where literal is longer than one character with a data item that is numeric or numeric edited. The paragraphs...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Yes, OPEN REVERSED, for (line) sequential files which means every time you do a READ NEXT you actually get the previous logical record, starting from the last one. This was made obsolete in the COBOL 85 standard (so it was dropped in COBOL 2002).

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    REVERSED is an OPEN clause ... ?!?!?

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    The whole process you've described gets down to: get svn version via svn (so you can update any time later) create additional build parts (you need more of the standard dependencies, see HACKING) create multiple build environments using that source don't install but use a "pre install" environment $> svn checkout https://svn.code.sf.net/p/gnucobol/code/branches/gnucobol-3.x $> cd gnucobol-3.x $> ./autogen.sh # use "./autogen.sh install" if you get version mismatch during make $> mkdir build $> pushd...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    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,...

  • Simon Sobisch Simon Sobisch modified a comment on discussion GnuCOBOL

    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,...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Thank you for the suggestion; as that is an RM alias, also supported by ACUCOBOL-GT, I'll make that change (drop it from the default dialect and the parser for the "reverse_video" symbol, define it as an alias for those two dialects, it won't be defined in the other lax dialects either). I'll commit this together with the other RM/COBOL related changes soon (all of this "only" miss a complete automated testing, so I hope to get there VerySoonTM). Just to let you know: REVERSED is, when defined in...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo modified a comment on discussion GnuCOBOL

    I would like to point out that the REVERSE-VIDEO clause in both SCREEN SECTION and ACCEPT item statements and DISPLAY item, although not indicated in the Programmers Guide, is accepted by the cobc compiler also in the abbreviated form REVERSE. However, if the clause REPOSITORY. FUNCTION ALL INTRINSIC. is present in the program, then the compiler accepts it ( REVERSE ) in the SCREEN SECTION but does not accept it in ACCEPT item statement. It is clear that this is caused by the overlap with the intrinsic...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    I would like to point out that the REVERSE-VIDEO clause in both SCREEN SECTION and ACCEPT item statements and DISPLAY item, although not indicated in the Programmers Guide, is accepted by the cobc compiler also in the abbreviated form REVERSE. However, if the clause REPOSITORY. FUNCTION ALL INTRINSIC. is present in the program, then the compiler accepts it ( REVERSE ) in the SCREEN SECTION but does not accept it in ACCEPT item statement. It is clear that this is caused by the overlap with the intrinsic...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    I understand your point. These new functions are in my opinion very useful in developing interfaces in TUI environments. For this reason I believe that before releasing them in a final and definitive version, all the aspects that represent both errors but also imperfections, as in this case, should be fixed. Maybe we wait to complete the testing phase in all aspects and then with all the reports we make a final and unique intervention for everything. Congratulations again for this work !

  • Mickey White Mickey White posted a comment on discussion GnuCOBOL

    All good questions. I know you can run different versions on the same box See FAQ section : 3.2 What are the configure options available for building GnuCOBOL?

  • Juan Carlos Escartí Juan Carlos Escartí posted a comment on discussion GnuCOBOL

    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,...

  • Juan Carlos Escartí Juan Carlos Escartí posted a comment on discussion GnuCOBOL

    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

  • Chuck H. Chuck H. posted a comment on discussion GnuCOBOL

    Eugenio, this could be done, however at this point in time I am also working on additional changes to support the RM/COBOL PopUp window functionality and it is built on top of the Multiple Window version. So changing the architecture to remove a field on the communication parm would involve more changes than it might appear so at this point I am going to leave the HIDDEN parm as it is. This does not have any impact on the functionality. Thanks for the feedback. If there is a significant push back...

  • Vincent (Bryan) Coen Vincent (Bryan) Coen posted a comment on discussion GnuCOBOL

    done

  • Vincent (Bryan) Coen Vincent (Bryan) Coen committed [r5328] on Code

    prog/fun name addendum

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    Hi Chuck, first note. This is the parameter scheme for the functions. *> FUNCTION NUM START-X START-Y ROWS COLS FG BG HIDDEN RET-CODE *> --------+---- ------- ------- ---- ---- --- --- -------- -------- *> NEW | ret req req req req req req - ret *> MOVE | req req req - - - - - ret *> SHOW | req - - - - - - req = 0 ret *> HIDE | req - - - - - - req = 1 ret *> TOP | req - - - - - - - ret *> BOTTOM | req - - - - - - - ret *> DELETE | req - - - - - - - ret *> --------+---- ------- ------- ---- ---- ---...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    please add following phrase from Simon to the PG: Note that this is true for any C library in program space, so it includes curses, gmp, possibly libm, libxml2, JSON, BDB, ...

  • Ralph Linkletter Ralph Linkletter posted a comment on ticket #988

    Avaryseq3 I added the file structure back in - it worked ok. Add the "initialize" - it failed. (statement 63). Avaryseq4 Removed the "initialize" Added back in populating the I-O area Failed.

  • Simon Sobisch Simon Sobisch posted a comment on ticket #988

    Interesting, so what parts do you need to add to make it fail again? That would be the minimal example as well as a hint on what to watch out for during debugging.

  • Ralph Linkletter Ralph Linkletter posted a comment on ticket #988

    A reduced tiny version that does not fail.

  • Simon Sobisch Simon Sobisch committed [r5327] on Code

    testsuite environment update

  • Vincent (Bryan) Coen Vincent (Bryan) Coen posted a comment on discussion GnuCOBOL

    Updated plus other comments re CBL, COB, and preceding with underscore. revision 5326

  • Vincent (Bryan) Coen Vincent (Bryan) Coen committed [r5326] on Code

    sect. 4 update prog & func. name usage

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Note that this is true for any C library in program space, so it includes curses, gmp, possibly libm, libxml2, JSON, BDB, ...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    I think it is more than necessary to indicate in the PG at page 82 a new "point 9" as follows: In the definition of the name of PROGRAM-ID (or FUNCTION-ID) you must not use names identical to those of functions of the "libc" library. The functions of the "libc" library have names in lowercase or mixed case. Using always uppercase names for PROGRAM-ID and FUNCTION-ID avoids any possibility of overlapping.

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    Ok thx. Nice job. Now I can start to use and test them.

  • Ralph Linkletter Ralph Linkletter created ticket #988

    File Status 31

  • Chuck H. Chuck H. posted a comment on discussion GnuCOBOL

    Files refreshed as of Sept 10 --> fix issue with cursor not staying in current window. https://www.dropbox.com/scl/fo/ja8hty5mzfpblappb0ojo/AG7p1hxStQj-IH4zxVtO4hI?rlkey=1fgw5r0qtye61olk1vxenbc1b&st=jdn3qt18&dl=0 Also per Eugenio's request the callable functions were renamed. CBL_GC_WINDOW_NEW CBL_GC_WINDOW_MOVE CBL_GC_WINDOW_SHOW CBL_GC_WINDOW_HIDE CBL_GC_WINDOW_TOP CBL_GC_WINDOW_BOTTOM CBL_GC_WINDOW_DELETE

  • Chuck H. Chuck H. modified a comment on discussion GnuCOBOL

    Files refreshed as of Sept 10 --> fix issue with cursor not staying in current window. Also per Eugenio's request the callable functions were renamed. CBL_GC_WINDOW_NEW CBL_GC_WINDOW_MOVE CBL_GC_WINDOW_SHOW CBL_GC_WINDOW_HIDE CBL_GC_WINDOW_TOP CBL_GC_WINDOW_BOTTOM CBL_GC_WINDOW_DELETE I've been working on changes to the GNUCOBOL compiler to support multiple windows. This is implemented using CURSES and has been tested in both Windows with PDCURSESMOD and Linux with NCURSESW. I've created a drop box...

  • Chuck H. Chuck H. modified a comment on discussion GnuCOBOL

    Files refreshed as of Sept 10 --> fix issue with cursor not staying in current window. I've been working on changes to the GNUCOBOL compiler to support multiple windows. This is implemented using CURSES and has been tested in both Windows with PDCURSESMOD and Linux with NCURSESW. I've created a drop box folder with downloads for Windows binaries (both 32 & 64 bit versions). Also included is a short MP4 video showing the sample program colors.cbl as it executes on Windows. Also there is a PDF with...

  • David Declerck David Declerck committed [r5325] on Code

    Merged revisions 4906-4908, 4910, 4914-4918, 4920, 4927, 4939-4950, 4952, 4959-4962 from branches/gnucobol-3.x:

  • Simon Sobisch Simon Sobisch posted a comment on ticket #478

    @vcoen: You can implement that already up-front and would therefore also correctly xref the sources from mentioned dialects :-)

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    getenv is a libc function, you will have a hard time to name COBOL programs that way if you don't use upper case names or -ffold-call=upper which will do that for you (C names are commonly lowercase or, in case of Win32, mixed-case).

  • John Ritter John Ritter posted a comment on discussion GnuCOBOL

    I created a sub program called "getenv" because it grabs a bunch of environment variables. Then I spent hours trying to figure out why it wouldn't run. Everything compiles and runs with no errors. However the "getenv" program does not run. I wasted the better part of the day with this until I decided to simply name the program "getenvt" (for no particular reason) and now it runs. I can't find "getenv" anywhere in the Programmer's Guide and assuming it's not a reserved word. Found a solution, but...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the clarifications Possible answer is that other languages could be used to create / access relative files , no ? As you already know the record structure of the file, creating/accessing relative files is way much easier if there are no binary headers, since you end in just a sequence of records of X bytes each. As an example, in C would be as simple as opening the file, doing seek to the first byte of the record you want (lengthOfRecord x recordLengthInBytes) and then just reading X bytes...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the clarifications Possible answer is that other languages could be used to create / access relative files , no ? As you already know the record structure of the file, creating/accessing relative files is way much easier if there are no binary headers, since you end in just a sequence of records of X bytes each. As an example, in C would be as simple as opening the file, doing seek to the first byte of the record you want (lengthOfRecord x recordLengthInBytes) and then just reading X bytes...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the clarifications Possible answer is that other languages could be used to create / access relative files , no ? As you already know the record structure of the file, creating/accessing relative files is way much easier if there are no binary headers, since you end in just a sequence of records of X bytes each. As an example, in C would be as simple as opening the file, doing seek to the first byte of the record you want (lengthOfRecord x recordLengthInBytes) and then just reading X bytes...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    Thanks for the clarifications Possible answer is that other languages could be used to create / access relative files , no ? As you already know the record structure of the file, creating/accessing relative files is way much easier if there are no binary headers, since you end in just a sequence of records of X bytes each. As an example, in C would be as simple as opening the file, doing seek to the right record (length x record) and reading X bytes to retrieve the record. Another reason is to distinguish...

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    Thanks for the clarifications Possible answer is that other languages could be used to create / access relative files , no ? As you know how iare the records creating/accessing relative files is way much easier if there are no headers, since you end in just a sequence of records of X bytes each. As an example, in C would be as simple as opening the file, doing seek to the right record (length x record) and reading X bytes to retrieve the record. Another reason is to distinguish between empty and...

  • Vincent (Bryan) Coen Vincent (Bryan) Coen posted a comment on ticket #478

    Please advise when implemented as changes will be needed in cobxref.

  • Simon Sobisch Simon Sobisch posted a comment on ticket #478

    @nberth: I've just assigned this to you because of "GCOS" - could you please check with your team if someone of you can do this? This seems to be relative easy so may also be an option to let someone new get introduced into to the parser or GnuCOBOL in general, while improving portability for several environments.

  • Simon Sobisch Simon Sobisch created ticket #478

    Implement CONSTANT SECTION

  • Simon Sobisch Simon Sobisch modified ticket #477

    esqlOC if BEGIN DECLARE could bring in Copybooks?

  • Simon Sobisch Simon Sobisch posted a comment on ticket #477

    so... @dwulkman what about EXEC SQL INCLUDE?

  • Mickey White Mickey White posted a comment on discussion The Lounge

    https://www.youtube.com/watch?v=ObRdUEWwCvI

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    Another reason is to distinguish between empty and deleted records and to allow for correct variable length handling.

  • Vincent (Bryan) Coen Vincent (Bryan) Coen posted a comment on discussion GnuCOBOL

    On 09/09/2024 22:27, Mario Emmanuel wrote: why is the header needed? I did another test, if you write directly the relative record 1000 the file will grow to the size of 1000 records + 1000 header. Previous records would be empty. If the header only stores the length of the field, why isn't that computed from the FD associated record? By doing that you would have no header and the position in the file to read the n-th relative record could still be calculated. The file would be a plain text file...

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    why is the header needed? I did another test, if you write directly the relative record 1000 the file will grow to the size of 1000 records + 1000 header. Previous records would be empty. If the header only stores the length of the field, why isn't that computed from the FD associated record? By doing that you would have no header and the position in the file to read the n-th relative record could still be calculated. The file would be a plain text file with a sequence of records.

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    I think that's generally correct. It is likely reasonable to talk about portability between environments/compilers and the single main bug here is the 4-byte (as noted in the runtime.cfg of trunk aka 4.x GC's format always was to use a size_t which is commonly 4byte on 32bit environments and 8byte on 64bit environments).

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    The exact format of relative files are depending on the environment where they are used. Note that - currently only in GnuCOBOL 4 - there is an option to change that with a runtime setting which allows the files to be portable to other environments https://sourceforge.net/p/gnucobol/code/HEAD/tree/trunk/config/runtime.cfg#l319 I think I'd like to backport (manual-merge) the new settings COB_VARREL_FORMAT and COB_FIXREL_FORMAT along with the new values for COB_VARSEQ_FORMAT over to 3.3...

  • Simon Sobisch Simon Sobisch committed [r5324] on Code

    documentation update

  • Mickey White Mickey White posted a comment on discussion Help getting started

    Thanks. I was looking on the board at https://sourceforge.net/projects/gnucobol/files/gnucobol/ and it says to look for DEPENDENCIES "See DEPENDENCIES for a complete list of these which may be helpful if you build GnuCOBOL from source. " But it does not tell you where to look! it works Now. Thanks Simon. And Vincent (even the old compiled programs in my bin directory work without me recompiling them. ) This site is Great. This was the saving grace, not sure were it is ,but not sure why it was so...

  • Vincent (Bryan) Coen Vincent (Bryan) Coen posted a comment on discussion Help getting started

    On 09/09/2024 15:49, Mickey White wrote: I had a crash on my Linux Ubuntu box when I updated from Ubuntu 22 to 24, the new version as of 08/2024. It would not boot so I had flash the Ubuntu 24 ios file and install it on a more or less empty box. The install then went OK but I had to Mount my old drives so it would see them. I then installed berkeley db and Jason (I think). I put my old disk in the PATH statement. Then I tried to Install GnuCOBOL 3.3 dev and Got ./configure errors on Jason and Berkeley...

  • Simon Sobisch Simon Sobisch posted a comment on discussion Help getting started

    I think the build definitions for Ubuntu 22 still apply to Ubuntu 24. I guess you miss the dev packages during install. Please have a look at [7c6b048b95]. If you don't have the necessary rights to install by apt you could install all of the missing dependencies "locally" in your user directly - but in this case you'd likely have specified --prefix=$HOME or similar, so that's likely not the case.

  • Mickey White Mickey White posted a comment on discussion Help getting started

    I had a crash on my Linux Ubuntu box when I updated from Ubuntu 22 to 24, the new version as of 08/2024. It would not boot so I had flash the Ubuntu 24 ios file and install it on a more or less empty box. The install then went OK but I had to Mount my old drives so it would see them. I then installed berkeley db and Jason (I think). I put my old disk in the PATH statement. Then I tried to Install GnuCOBOL 3.3 dev and Got ./configure errors on Jason and Berkeley and perhaps XML. and the Install fails...

  • Simon Sobisch Simon Sobisch committed [r5323] on Code

    work on "make checkmanual"

  • Nicolas Berthier Nicolas Berthier posted a comment on discussion GnuCOBOL

    Hi Ralph, Very interesting project indeed. The missing element was collating sequence. For instance an EBCDIC "123" must collate after an EBCDIC "ABC". I converted the EBCDIC "123" to an ASCII "123" Hence I depend on the "collating sequence EBCDIC " to evaluate comparative expressions as if implemented by Micro Focus CHARSET "EBCDIC". That is X'414243" to be less that X'313233' ("ABC" < "123"). I can confirm this is exactly what the EBCDIC-related command-line options are doing.

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    It seems that there is an error in that description. The record header was consistently 8 bytes in my tests (see output from od command), not 4 as stated there. They seem to contain the length of the record (in the test I copied above the length of the record was 31 bytes and you see 0x1E (31 decimal) and the other 7 bytes from the header are set to zero. I created a 999998 record length file with missing element in between and then inserted the missing element. Gnucobol inserts the missing element...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    It seems that there is an error in that description. The record header was consistently 8 bytes in my tests (see output from od command), not 4 as stated there. They seem to contain the length of the record (in the test I copied above the length of the record was 31 bytes and you see 0x1E (31 decimal) and the other 7 bytes from the header are set to zero. I created a 999998 record length file with missing element in between and then inserted the missing element. Gnucobol inserts the missing element...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    It seems that there is an error in that description. The record header was consistently 8 bytes in my tests (see output from od command), not 4 as stated there. They seem to contain the length of the record (in the test I copied above the length of the record was 31 bytes and you see 0x1E (31 decimal) and the other 7 bytes from the header are set to zero. I created a 999998 record length file with missing element in between and then inserted the missing element. Gnucobol inserts the missing element...

  • Mario Emmanuel Mario Emmanuel modified a comment on discussion GnuCOBOL

    It seems that there is an error on that description. The record header was consistently 8 bytes in my tests (see output from od command), not 4 as stated there. They seem to contain the length of the record (in the test I copied above the length of the record was 31 bytes and you see 0x1E (31 decimal) and the other 7 bytes from the header are set to zero. I created a 999998 record length file with missing element in between and then inserted the missing element. Gnucobol inserts the missing element...

  • Mario Emmanuel Mario Emmanuel posted a comment on discussion GnuCOBOL

    It seems that there is an error on that description. The record header was consistently 8 bytes in my tests (see output from od command), not 4 as stated there. They seem to contain the length of the record (in the test I copied above the length of the record was 31 bytes and you see 0x1E (31 decimal) AND 7 bytes set to zero. I created a 999998 record length file with missing element in between and then inserted the missing element. Gnucobol inserts the missing element in place. Actually, now that...

  • Eugenio Di Lorenzo Eugenio Di Lorenzo posted a comment on discussion GnuCOBOL

    from PROGRAMMER'S GUIDE at page 16 (question: Is everything written correct ?) ORGANIZATION RELATIVE The contents of these files consist of a series of fixed-length data records prefixed with a four-byte record header. The record header contains the length of the data, in bytes. The byte-count does not include the four-byte record header. Records in this type of file are all the same physical length. If variable-length logical records are defined to the program, the space occupied by each physical...

  • Arnold Trembley Arnold Trembley posted a comment on discussion GnuCOBOL

    Relative files in GnuCOBOL are native to the local machine. They DO NOT require either BDB or VBISAM. I built a program to create and test a relative file, and compiled it with a Windows MinGW version of GnuCOBOL 3.2 that did not have ANY ISAM handler (neither BDB nor VBISAM) and it worked correctly. The source code is attached.

  • John Ritter John Ritter posted a comment on discussion GnuCOBOL

    RHEL 9.4, GnuCOBOL 3.2.0. GnuCOBOL all built from sources with plain "configure" and no options. If I force ".so" to the output file it works. And for now I'm avoiding COB_LIBRARY_PATH completely by using a fully qualified path name in the CALL. The problem remains that in 2 out of 3 servers it compiles with ".so" and works. It must be something on the compile side and not the runtime side. cobcrun --runtime-config is the same for all systems. Why would it compile differently on different systems?...

  • Simon Sobisch Simon Sobisch posted a comment on discussion GnuCOBOL

    I guess you use different GnuCOBOL versions... But if you specify an output file I'd suggest to also add the file extension, if any. ... but easier would be a pushd to the output directory and then leaving -o out completely and maybe use a relative path for each of Cbl, Prt (and possibly Cpy). Oh, and COB_LIBRARY_PATH is easy, that's a list of parts where libcob searches for the dynamic (not statically linked in) modules. Hint: if you link against system libraries, thenthose are resolved by the system...

  • John Ritter John Ritter posted a comment on discussion GnuCOBOL

    Well I thought I had it all figured out, then moved code to a new machine. Although I still haven't figured out all the nuances of COB_LIBRARY_PATH, I think my real problem is this: On machine A, I compile my subprogram with: cobc -fixed --tlines=82 -fmax-errors=9999 -fcontinue-after=ok -m -t /mnt/cobol/project/Prt/subc.lst -o /mnt/cobol/project/Cob/subc /mnt/cobol/project/Cbl/subc.cbl That gives me a compiled file named subc.so and all is right with the world. But when I compile on machine B with...

  • Ralph Linkletter Ralph Linkletter modified a comment on discussion GnuCOBOL

    There is not a header record. Use your SELECT for creating / writing the file both .rel and .seq files. FILE-CONTROL. 000011 SELECT CUSTOMER-FILE ASSIGN TO './data/CUSTOMER.DB' 000012 ORGANIZATION IS SEQUENTIAL 000013 ACCESS MODE IS SEQUENTIAL 000014 LOCK MODE IS EXCLUSIVE 000015 FILE STATUS IS WS-CUSTOMER-FILE-STATUS. For creating the file .REL cannot use this to write records (unless you repetitively increment record counter by 30) 000011 SELECT CUSTOMER-FILE ASSIGN TO './data/CUSTOMER.DB' 000012...

1 >