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
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...
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...
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...
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...
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...
I'm actually trying to make it happen right now. First attempt broke the pipe and stdin/stdout tests. ;-)
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'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/...
Yes, that should be possible - do you want to give it a try on your own?
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
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...
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...
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....
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...
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.
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.
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.
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.
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...
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...
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).
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...
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...
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...
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...
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...
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...
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...
Sorry Simon, I meant to say that in your previous post you wrote REVERSEDwhen you probably meant to write REVERSE.
REVERSED is an OPEN clause ... ?!?!? You probably meant to write REVERSE
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...
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).
REVERSED is an OPEN clause ... ?!?!?
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...
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,...
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,...
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...
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...
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...
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 !
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?
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
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...
done
prog/fun name addendum
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 *> --------+---- ------- ------- ---- ---- ---...
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, ...
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.
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.
A reduced tiny version that does not fail.
testsuite environment update
Updated plus other comments re CBL, COB, and preceding with underscore. revision 5326
sect. 4 update prog & func. name usage
Note that this is true for any C library in program space, so it includes curses, gmp, possibly libm, libxml2, JSON, BDB, ...
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.
Ok thx. Nice job. Now I can start to use and test them.
File Status 31
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
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...
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...
Merged revisions 4906-4908, 4910, 4914-4918, 4920, 4927, 4939-4950, 4952, 4959-4962 from branches/gnucobol-3.x:
@vcoen: You can implement that already up-front and would therefore also correctly xref the sources from mentioned dialects :-)
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).
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...
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...
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...
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...
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...
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...
Please advise when implemented as changes will be needed in cobxref.
@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.
Implement CONSTANT SECTION
esqlOC if BEGIN DECLARE could bring in Copybooks?
so... @dwulkman what about EXEC SQL INCLUDE?
https://www.youtube.com/watch?v=ObRdUEWwCvI
Another reason is to distinguish between empty and deleted records and to allow for correct variable length handling.
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...
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.
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).
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...
documentation update
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...
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...
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.
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...
work on "make checkmanual"
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.
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...
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...
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...
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...
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...
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...
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.
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?...
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...
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...
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...