Activity for Simon Sobisch
-
Simon Sobisch modified a comment on discussion Help getting started
Opening a new thread does make sense, please do so under "contrib". In general it is important to have all three of: cob_screen_accept: get a screen that commonly has multiple fields, some function keys are not returned but handled internally for navigating through the fields, some attributes likeAUTO have a different result (for example moving to the next field)( cob_field_accept: get a single field (also called from cob_accept if extended screenio is active), provides some additional function keys...
-
Opening a new thread does make sense, please do so under "contrib". In general it is important to have all three of: cob_screen_accept: get a screen that commonly has multiple fields, some function keys are not returned but handled internally for navigating through the fields, some attributes likeAUTO have a different result (for example moving to the next field)( cob_field_accept: get a single field (also called from cob_accept if extended screenio is active), provides some additional function keys...
-
Ralph just noted what commonly used "AI" models currently tell. And as noted: there are banks and government environments where GnuCOBOL is used in production, as well as a bunch of others. The models just weren't trained with this information.
-
So what is exactly missing in GnuCOBOL to be able to use these programs as-is?
-
as you've said: Some time ago we wrote about the problems and I'm going to try to find the document. so that's one of the things I'll inspect
-
I highly suggest to upgrade to GnuCOBOL 3.2 (or at least 3.1.2) as this includes a lot of changes to make using GDB directly much easier. It is also needed if you possibly want to do core-dump debugging. Version 3.1.2 is also the prerequiste for COBOLworx cbl-gdb which makes the whole debugging within GDB a lot easier. If you want to run on the terminal using PuTTY and can't move from GC2 you may try to use cobgdb - while it officially asks for GnuCOBOL 3.1.2+ it is not unlikely that it works with...
-
Getting this to work correctly means foremost to either stick to DOS (or a "well enough" emulator) and a DOS "terminal" which can handle CP860 as well as escape sequences. To move somewhere else the assembler parts need to be rewritten. Also the encoding has to be either adjusted in the source code to match the terminal or it has to be adjusted "on the fly" which may be possible soon with the upcoming iconv-integration. Giving those sources a quick compile check with cd C:\RMCOBOL mkdir gclib cd...
-
I don't see documentation on most of this; I found I had to discover it through extensive testing. For ambiguous paragraph names, the IBM compiler issues a severe error (highest besides terminating) but nonetheless finishes the compile and runs the program. It actually discards the offending PERFORM or GO TO line. But I think being more permissive is ok (maybe in the IBM dialect disallow so people don't write programs that won't work on ibm). Your final questions are correct, if you don't reference...
-
Was that RM/COBOL? If yes then -std=rm/-std=rm-strict should get you that without explicit coding it, otherwise -faccept-auto should.
-
What was the original COBOL environment that has the implicit AUTO accept (=if field is full, then skip to the next field like "TAB" would, if single-fields or on last one handle as "ENTER")? What is your current compile command?
-
Are those (partially?) RM/COBOL screens? If that's COBOL - do you mind sharing the sources enabling us to check if/how those work with GnuCOBOL?
-
please do, I especially don't understand the "how to delete, append and work with alphanumerics" part; other than that, I think that one of a single DISPLAY SPACES WITH ERASE EOS in the first program or using -faccept-auto (auto-end if field is "full") or using -faccept-update(always pre-set with the existing data, currently only auto-enabled with -std=rm/-std=rm-strict) should lead to a general working accept of single fields, with the special case of numeric fields, which could be tweaked (we can...
-
So what is exactly missing in GnuCOBOL to be able to use these programs as-is? Am 1. September 2024 20:15:03 MESZ schrieb Jack Tearle kitamanswinner@users.sourceforge.net: I think what some of you are missing is that we are converting existing programs and have budgetary constraints. I for one have a program using the screen section that has 10 accept statements for 220 fields. Changing the program to have 220 accept statements is a rewrite, not a conversion. In the end, I spent less time converting...
-
Set it to very/long/path/to/CpyBook/ and then your dir3 and all others will be found? If you have both with and without the directory path, then just prefix your setting with it.
-
The internal compiler error is always a bug. I will try to inspect this issue very soon, maybe tomorrow.
-
Normally you need to do EXEC SQL INCLUDE copybook END-EXEC That should work with any SQL preprocessor.
-
There is a topic on this board in production use of GnuCOBOL, you may want to have a look at it. concerning COBOL on PC you possibly want to check Micro Focus (they bought nearly all competitors and therefore COBOL dialects) / their customers. Oh, and if you don't knew, current mainframes for nicely into your data center, they don't need a room any more. :-)
-
With portability I've meant "between COBOL implementations".
-
Fair warning - I'll try to push to have DISPLAY WINDOW / DESTROY WINDOW handling (ACUCOBOL-GT extension) instead of new even more unportable system routines. But for testing the feature itself these builds and the CALLable routines are definitely useful until the COBOL syntax is in.
-
3.3 dev now (you may try a nightly build) or its pre-release, once available. It will also be included in 4.0.
-
Oh and for the preset: you can use the computed value and set/export that to COB_MOUSE_FLAGS.
-
The interesting question is: do we have a reason to not switch the default values of those two SCREEN configuration options? Any thoughts @btiffin? Am 25. August 2024 16:42:23 MESZ schrieb "Vincent (Bryan) Coen" vcoen@users.sourceforge.net: In my .bashrc file I have (among others) : export COBCPY=~/cobolsrc/ACAS/copybooks export COB_SCREEN_ESC=YES export COB_SCREEN_EXCEPTIONS=YES export COB_LIBRARY_PATH=~/bin export PATH= etc, etc export TMPDIR=~/tmp export DB_HOME=. Note that the export commands...
-
interesting would be cobc --version...
-
The GnuCOBOL project itself does not provide binaries - it is packaged in nearly any GNU/Linux distribution, available on MSYS2 and with most windows package managers, and there are "officially blessed" windows binaries from Arnold Trembley https://arnoldtrembley.com/GnuCOBOL.htm and OCamlPro. We do have some automated building for current development snapshots that also create downloadable binaries, see https://sourceforge.net/projects/gnucobol/files/gnucobol/nightly_snapshots/ for details. If you...
-
Enable LTO, PGO and PLO for GnuCobol
-
friendly ping @zamazan4ik for possible further checks / status updates
-
@davewall @dilodilo Do you agree that we can close this issue with the referenced feature request now being implemented?
-
There is no 4.7 version of GnuCOBOL. If you installed OCIDE, then you very likely have an included quite outdated version of GnuCOBOL. If that is OCIDE, you may use the preferences->compiler settings and click on something like "verify", which should provide you somewhere with the version output. In any case: OCIDE was marked deprecated in 2018 (and it seems its last release 7.4.6 was from 2016). If you share information on your install, we may be able to help you updating GnuCOBOL on your syste...
-
Just note that 32bit applications in 64bit Windows are often slower because of the internal translation- also see https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system#program-performance-considerations; on 64bit Linux environments this is also true, but to a bit lesser amount (the kernel calls have to always do a translation because it is a 64bit kernel in the end). The biggest performance issue in both cases will be the...
-
Just note that 32bit applications in 64bit Windows are often slower because of the internal translation- also see https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system#program-performance-considerations; on 64bit Linux environments this is also true, but to a bit lesser amount (the kernel calls have to always do a translation because it is a 64bit kernel in the end). The biggest performance issue in both cases will be the...
-
Well, as long as you have a 32bit set of libraries (and gcc) installed, then GnuCOBOL works fine there - and in some rare cases like this one (haven't checked yet, I guess that's just the parameter handling for the CBL routines used) it may even work "better". So: GnuCOBOL 32bit is maintained and still (but currently only with old MinGW and Cygwin as 32 bit) checked in the CI regularly. And before a release we normally do test on some GCC compile farm machines, some of those are 32bit only - and...
-
I would like 32bit GnuCOBOL to be maintained. There is a lot of code on mainframes that are coded with redefined pointers and other idioms that are hard to convert to 64bit. Although 32bit on Linux is getting harder to do, you can still install 32bit libraries on a 64bit machine.
-
Test 843 fails on Aarch64 when configuring with --enable-hardening
-
this is "expected" - please see the mailing list https://lists.gnu.org/archive/html/bug-gnucobol/2024-08/msg00001.html for some details on that and what to possibly do about that
-
work on ALPHABET definitions, especially ALPHABET FOR NATIONAL - C90 fix for r5310
-
added missing iconv.m4 update - follow-up to r5310
-
work on ALPHABET definitions, especially ALPHABET FOR NATIONAL
-
Nice image for a bunch of memes :-) Do you have a reference link to the post as well?
-
`-lreadline` may be missing when linking `cobfile` in `trunk`
-
I think only cobfile uses readline (and do it when available), no? Then there should be a AC_SUBST (READLINE_LIBS) or similar and this should be used in the bin/Makefile only for this program. I do wonder why Keisuke dropped the use of readline in termio (cob_accept) in 2003-06 [history:r1860] and if it would be useful to have it back for "simple ACCEPTs". In this case we could it put it to cobfile and libcob... or we have an idea why that would be useful for cobc/cobcrun. @knishida @rjnorman74 any...
-
This is a regression in GnuCOBOL; the only reason that this COBOL2002 feature (also available on IBM) is not in is because of the seldom use of floating point in COBOL. For some details see [feature-requests:#199] (yes, that's a2017 one!). Note that we do support floating-point literals since quite some time. @chaat Could you have a look to add at least the parsing for GnuCOBOL 3? When we later add the actual support libcob would need both the editing and de-editing part. Note: to store floating...
-
Sounds like IBM Watson may provide useful... After all it depends on what you need to analyze there.
-
Just to make this clear: the standard says "undefined -> unpredictable", for GnuCOBOL this is always predictable and depends on the move-ibm setting. Note: I definitely suggest to NOT change default.conf (apart from very seldom error fixes) and instead compile with a matching -std - in your case possibly -std=ibm which means "IBM behaviour, but supporting extensions from GnuCOBOL and other vendors" or -std=ibm-strict (IBM only, so also should compile there and no expected reserved words issues)....
-
reword error messages according to standard
-
See ISO/IEC JTC 001/SC 22/WG 04 "COBOL" documents -> Draft Standards - edit: the documents aren't available any more, but you find the draft document itself in the CDG documents at the internet archive.
-
What didn't work with VBISAM?
-
Don't use the header from rsxntdj, it likely isn't even BDB - and in any case you'd need the library as well; there's no "official" package from DJGPP, so try to check in the FreeDOS pacakge manager if there's a "recent enough" BDB / Berkeley DB package - if there isn't you'd need to compile that on your own or use a different package (that would be VBISAM but that doesn't work very well with GC3 on Windows, so DOS will possibly be much worse).
-
Thanks for that report as well. Checking with -g or --save-tempswe can see that the issue is on IDX/IDY - those are index-names and currently generated code initialize those to 1 to have some defined and commonly valid data in (I guess per standard its undefined) - but as the fields are never used, their storage (the b_nnn ones) is not generated and therefore the assignment breaks the compile. Workaround: drop the unused index-names while I work on the fix for this.
-
See ISO/IEC JTC 001/SC 22/WG 04 "COBOL" documents -> Draft Standards - edit: the documents aren't available any more, but you find the draft document itself at https://web.archive.org/web/20221109092121/https://isotc.iso.org/livelink/livelink?func=ll&objId=21916208.
-
See ISO/IEC JTC 001/SC 22/WG 04 "COBOL" documents -> Draft Standards - edit: the documents aren't available any more.
-
See ISO/IEC JTC 001/SC 22/WG 04 "COBOL" documents -> Draft Standards.
-
MOVE just disregards the fact that I am intentionally doing an overlapping move and trying to propagate a character. The standard is clear on this one: it is undefined behaviour. This brings a lot of fun for developing a COBOL compiler in general, especially when aiming for the option to port from other environments keeping their behaviour. Back in OpenCOBOL times this was depending on the way the used memcpy is implemented, so also "undefined". GnuCOBOL 2.x+ (if I remember correctly but the NEWS...
-
increase portability for Micro Focus and ACUCOBOL-GT
-
strings.c: move from static variables to state varialbes
-
finished with [r5302]; after some back and forth we dropped the extra functions and instead use thread-local storage now, with a new option to free memory allocated dynamically in the thread; because the tls is used in the old entry points the fix also applies to old modules overall this commit makes the code more clean (using new internal structures) Thanks Boris for finishing this travel with me :-) Side note: "someone" should check if we have more static data that should be marked as thread l...
-
Listing to include object field name of occurs depending on
-
also: missing in the symbol listing and the xref (at least with GC 3.2) are internal indexes INDEXED BY and level 78 constants; the later may should be shown with its full value for numeric variables and up to the same size the start of alphanumeric/national literals as well, but if this is done, then the conditionals may should also be shown. Side note: there should be a recheck if level 78 is made available with the COBC_GEN_DUMP_COMMENTS option (level 88 is since GC 3.2).
-
Provide configuration for returning error codes for fileio system library calls
-
This is related to configurable io status [feature-requests:#348] which is loosely planned for GC 4.0
-
"Something similar" is now "well enough" supported to be useful already: COBOL 2002 prototypes. Adding the CA realia extension which looks "strangely familiar" with this added feature should be added. To do so: minor addition in the parser to handle PROGRAM-ID. identifier _is EXTERNAL. similar to PROGRAM-ID. identifier IS PROTOTYPE. adding ca-realia calling conventions - entry prefixes "none" -> COBOL (static?), R_ "realia" dynamic calls, C_ -> static C, P_ -> static pascal, S_ -> static "system"...
-
XML PARSE
-
Ticked moved on, Ammar started this as GSOC project and after the need to withdraw from the project wants to go on with it, likely in September 2024.
-
New option to list of Internal Registers
-
I agree that a split is reasonable and can also help to catch some configuration issues. .... but I've did so back in 2017 with the last part that fixes that with [r2279], --list-reserved was distributed with GnuCOBOL 3.1, much before --list-exceptions was added. I've missed to note both in NEWS and want to fix that under this FR. Because of compatibility concerns (back then there were programs using the output of --list-reserved interactively, maybe TP debugger?) I left an internal call to the new...
-
I'm not sure about the packaging part, if you only have libdb18 in termux and want an older one, it is possibly reasonable top add a libdb-gpl one - you can get inspiration and patches at https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-db. For GnuCOBOL in general libdb18 should be fine (the resulting binary runtime library would be AGPL then, of course), as well as libdb5-3.
-
I've just seen by checking the logs and configure.ac, that the BDB inclusion for cross-compilation is broken, even if there is a libdb (which can only be guessed to be matching the header). That is possibly also the reason that VBISAM was included there for termux in the first place... You should likely be able to do the following after configure --with-db (which does the check part and otherwise aborts) to work around that:echo 'WITH_DB 1' >> config.h. As an alternative you may add LIBCOB_CPPFLAGS=-DWITH_DB...
-
I'm not sure about the packaging part, if you only have libdb18 in termux and want an older one, it is possibly reasonable top add a libdb-gpl one - you can get inspiration and patches at https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-db. For GnuCOBOL in general libdb18 should be fine (the resulting binary runtime library would be AGPL then, of course).
-
-fdefault-colseq=ebcdic is identical to OBJECT-COMPUTER. PROGRAM COLLATING SEQUENCE IS EBCDIC-CODE with the ALPHABET EBCDIC-CODE IS EBCDIC, no? The one possible addition we talked about is a way what ALPHABET ALPH IS NATIVE means (which on a PC would be identical to ASCII, while your efforts would like to have that be EBCDIC - so until something like this is implemented you'd either have to pre-process-change that or use freserved=NATIVE:EBCDIC; while that breaks OPTIONS. ARITHMETIC IS NATIVE, you...
-
Can you please send config.log? That would help (may not be needed, so if it is hard then skip that). Related note: if you build from a tarball then it is enough to 'touch bin/cobcrun.1 cobc/cobc.1' after applying patches to not need help2man.
-
The idea is that once you define a FILE STATUS or DECLARATIVES entry for a file, you have taken both the option and responsibility to handle errors for this file yourself. Do you get an error if you do not coded those?
-
If you handle screenio and ncurses wide I can handle the rest. And for PIC X / PIC U there are conversion routines to/from the ncurses wide chars.
-
Nice, so you now do have a working version! Was this cross compiled or build on FreeDOS? What is the output of cobc --info && cobcrun --verbose --info and what is your current compile command to create prog.exe?
-
No problem DECLARATIVES provide a way for exception handling outside of COBOL2002 exceptions (and since COBOL2002 also for those). If a file has neither an entry in DECLARATIVES nor the file status coded, then the runtime will abort on any fatal io status (and output the paths as it uses it). Your program has an io status, but no declaratives, so if you want to test that, then just comment out the FILE STATUS IS FS (keeping the following period, of course). To learn more about this COBOL feature,...
-
you don't have to believe me, I can obviously be always wrong, you can also have a look at the documentation and of course just have a look at libcob and you will quite likely find COB_STATUS_91_NOT_AVAILABLE... note: you may remember status 30, that's a permanent error with no more specific reason OPTIONAL files are quite useful because then an OPEN I-O (or EXTEND) will create the file only if it doesn't exist (you can of course do the same by manually checking for io status 35), it does not try...
-
As noted before: 9x is "implementor specific" and 91 in GnuCOBOL means "not available" (disabled at compile time). To get the full path "as used by libcob" just comment out the declaratives + io status, the runtime will then abort and output the filename. And as also noted: try to update to GnuCOBOL 3.2 in any case.
-
Hm, this looks like the target environment needs a full linking each time, also for indirect dependencies. We can have this done automatically, but should test that first. Please execute cobc -gvx -lgmp -lncurses hello.cob which I think will work, if it does then do the same without -x and share both logs. Oh and please also post a log from cobc --info, just to make sure that I don't confuse something on the environment.
-
As noted before: Maybe it is more reasonable to use the current svn version and adjust libcob/screenio.c itself. This removes the need to do careful coding on the application side and once your changes are working those could be integrated into GnuCOBOL and also provide different code paths for alphanumeric/national/utf-8 data items.
-
Rechecked: the biggest issue is likely that screenio.c operates on plain char*, it doesn't to any conversion before output. I guess it should be working once all functions are changed to use the wide version, and there's an explicit call to mbstowcs to do the conversion from utf8 (or other encodings depending on the locale setup - which then needs to match the source encoding) to widechars up front. If anyone wants to provide patches...
-
merge r4859 r4860 from branches/gnucobol-3.x
-
Hi Michael and welcome to GnuCOBOL. Asking in the discussion board is definitely a reasonable thing to do. I wasn't sure if the issue at hand came up before in the discussion board, but giving it a quick search, which you possibly did, returned no results. The issue itself came up in both the mailing list and the issue tracker though and is solved, please see [bugs:#941] (I've re-attributed the fix after the original commit). Your solution to the problem was correct :-) Thanks for reaching out in...
-
That would only make sense for ACCEPTas DISPLAY has no cursor, no? Having an extra clause WITH NO CURSOR would be doable (also see the related FR), but coding that would mean to create non-portable code (the upcoming runtime configuration, see [feature-requests:#474], which may be toggled with SET ENVIRONMENTwould be portable, just not doing any hiding outside of GnuCOBOL). I'm therefore not sure if it is worth to create a non-portable extension for that. A completely different thing would be if...
-
That would only make sense for ACCEPTas DISPLAY has no cursor, no? Having an extra clause WITH NO CURSOR would be doable (also see the related FR), but coding that would mean to create non-portable code (the upcoming runtime configuration, see [feature-request:#474], which may be toggled with SET ENVIRONMENTwould be portable, just not doing any hiding outside of GnuCOBOL). I'm therefore not sure if it is worth to create a non-portable extension for that. A completely different thing would be if there's...
-
I thought I made a somewhat similar 'accepted' suggestion [feature-requests:#195] - back in 2016.
-
libcob/umeric.c (cob_decimal_set_binar): C89 fix
-
Hello everyone, I am having trouble connecting to my PostgreSQL database when I precompile my COBOL code using GIXSQL. However, the same code works perfectly when I use OCESQL. Here is an example of my code: COBOL Code: >>source format is free IDENTIFICATION DIVISION. PROGRAM-ID. TestSql. DATA DIVISION. WORKING-STORAGE SECTION. EXEC SQL BEGIN DECLARE SECTION END-EXEC. 01 DBNAME PIC X(30) VALUE SPACE. 01 USERNAME PIC X(30) VALUE SPACE. 01 PASSWD PIC X(10) VALUE SPACE. 01 EMP-REC-VARS. 03 EMP-NO PIC...
-
Thanks for the update! Is it possible that you've built (or received) GixSQL with multiple backends enabled? You possibly know that apart from libpg (PostgreSQL) it can also handle MariaDB or ODBC or OCI (Oracle native Call interface) or SQLite. And at least if your GixSQL has multiple io support it needs to know which backend to use (but even then it likely should have some default). So I suggest to create an issue for that in any case: https://github.com/mridoni/gixsql/issues
-
merged r5060 + r5061 and partial r5257 from branches/gnucobol-3.x build_windows adjustments
-
merged revisions 5240,5243 from branches/gnucobol-3.x - build fixes
-
provide a runtime configuration to hide the cursor for extended screenio
-
As noted: Your codepage in cmd is commonly a dos codepage, not ANSI (you may be able to temporarily set it to that with chcp, but even then you likely want something like ISO-8859-15, which "ANSI" means in the Windows Notepad). OCIDE came with different encodings, you may be able to use something reasonable with it; its integrated console may or may not work with something outside of 7bit (which includes @ & # ~, see https://en.wikipedia.org/wiki/ASCII#Character_set) or utf8; the later is not usable...
-
it all depends on the codepage - if you want to see the euro sign on cmd (warning, extended screenio may' be different) then your COBOL source needs to be encoded using the appropriate codepage (edit with Notepad++ or VSCodium or similar, not the Windows included Editor which doesn't support those codepages); and with current GnuCOBOL ensure that this is a single-byte encoding
-
I guess you save the file as utf-8? Try with a single-byte encoding for now instead. ... and "what does not work" exactly?
-
It isn't supported in OCESQL (and previously the SQL statement was just silently dropped...) see its issue tracker (I've just searched for COMP-5 there) https://github.com/opensourcecobol/Open-COBOL-ESQL/issues/27
-
You want to put that in a code block - please edit your post surrounding it by ```cobol ``` Which will add nice syntax highlighting as well.
-
Note: to cater for truncation you could add IF tmp-var <> FUNCTION NUMVAL (inp-var) Just saying.... Simon
-
Thank you for the feedback, good to know that the workaround works fine. The fix of the issues I've mentioned are still outstanding (and possibly will for some weeks).
-
The compiler complains (internal error = that's either a missing check in some place or a missing codegen part, in any case a bug) in the codegen (= when it works on the internal AST) that there is an "INTRINSIC" in a place that's not expected. During this it does not have the line number set correctly (which is another bug) and outputs the very last line of the program instead. "INTRINSIC" in this place is a parsing-recognized intrinsic function, because of FUNCTION ALL INTRINSIC it can be multiple...
-
Julian, I've not used declarative sections or report writer, so this may not be related to the root cause. However the program appears to have nothing in the procedure division except for a declarative section. So it appears that the main logic of the program is missing. No file is opened or read. Also the report line is not generated. PROCEDURE DIVISION. DECLARATIVES. handle-errors SECTION. USE AFTER STANDARD ERROR PROCEDURE ON CALENDS. *>if ws-lock-status equals 61 then FILE IS LOCKED DISPLAY 'file...
-
Please try using v3.2 final and see if you get same results.
-
How does that change when adding -g (include debugging information and keep all files possibly needed for doing so)?
1 >