Pulling hair out with this.
Program A - open output FileA. Writes a record then closes FileA.
FileA is a simple sequential file I want to log details in.
It then 'calls' another program which crashes out as follows:
libcob: C:/TESTPROG.cbl: 56: permanent file error (status = 30) file: 'TESTPROG.LOG'
The 'called' program does the following:
Move "TESTPROG.LOG" to LOG-NAME.
Open EXTEND LOG-FILE.
The Open is the point it crashes because I put a display/accept just before and that works.
What's the correct sequence (if any) of processing log files in multiple called programs.
I can't use I-O on a sequential file & want to have all records in the same file.
What am I doing wrong here ?????
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you CLOSE the file before the sub-program CALL?
Anyway, use a sub-program, rather then spreading similar code all over the place.
CALLed initially by the "main" program to "open" and finally by the main program to "close".
CALLed at each relevant logging-time in whichever program/sub-program.
Try for a copybook to do the CALL, with REPLACING to format the message how you want, then using the logging in a CALLed program is simply a case of pasting an example copybook reference and changing the values on the REPLACING to be specific.
You'll need some WORKING-STORAGE, so another copybook.
Spend some time designing a "control block" for the sub-program. Decide what functions the sub-program needs (lots of things you may want to consider). Play with it in a small system or one you "write" for the purpose of playing with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure, not really enough code to go on. Need to see some FD and SELECT clauses.
You mention FileA and LOG-FILE, so I take it the definitions aren't just copy and paste or in a copybook?
I just tried a quick pass, and it worked here.
GCobol>>SOURCEFORMATISFREE*> ****************************************************************>****p* samples/logger*> Author:*> Brian Tiffin*> Date started:*> 20150725*> Modified: 2017-02-20/02:25-0500 btiffin*> License:*> Copyright 2015 Brian Tiffin*> GNU Library General Public License, LGPL, 3.0 (or greater)*> Purpose:*> Test subprogram logging*> Tectonics:*> cobc -xj logger.cob*> SOURCE*> ***************************************************************identificationdivision.program-id.logger.environmentdivision.configurationsection.repository.functionallintrinsic.input-outputsection.file-control.selecttestfileassignto "loggerfile.txt"organizationissequentialfilestatusistestfile-status.datadivision.filesection.fdtestfilerecordisvaryinginsizefrom0 to40 charactersdependingonactual.01 testline.05 databytespic xoccurs1 to40 timesdependingonactual.working-storagesection.01 actualpic 999value40.01 testfile-realpic xx.01 testfile-statusredefinestestfile-realpic 99.*> *****************proceduredivision.openoutputtestfiledisplay "open output: "testfile-statuswritetestlinefrom "this is a log test"display "write output: "testfile-statusclosetestfiledisplay "close output: "testfile-statuscall "appender"goback.endprogramlogger.*> ***************************************************************identificationdivision.program-id.appender.environmentdivision.configurationsection.repository.functionallintrinsic.input-outputsection.file-control.selecttestfileassigntolog-name*> variable, not a literal this timeorganizationissequentialfilestatusistestfile-status.datadivision.filesection.fdtestfilerecordisvaryinginsizefrom0 to40 charactersdependingonactual.01 testline.05 databytespic xoccurs1 to40 timesdependingonactual.working-storagesection.01 log-namepic x(14).01 actualpic 999value40.01 testfile-realpic xx.01 testfile-statusredefinestestfile-realpic 99.*> *****************proceduredivision.move "loggerfile.txt"tolog-nameopenextendtestfiledisplay "open extend: "testfile-statuswritetestlinefrom "this is an extend test"display "write extend: "testfile-statusclosetestfiledisplay "close extend: "testfile-statusgoback.endprogramappender.*>****
logger.cob
Giving
prompt$ cobc -xj logger.cob
open output: 00
write output: 00
close output: 00
open extend: 00
write extend: 00
close extend: 00
prompt$ cat -v loggerfile.txt
^@(^@^@this is a log test ^@(^@^@this is an extend test
sample loggerfile.txt
This is GNU/Linux running latest. (Tested with both 2.0-rc3 and reportwriter).
So, it'll work, we just need to find what might be triggering the status 30 on your end. You may have to show us your file control and file section phrases, David.
Cheers,
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the time Brian - Unfortunately Bill was right - I omitted to close the file before the call - that gets really messy having to close & repoen the file before each call.
Bill - given that I would have to close/reopen before/after each call - you may well be right in me creating another called routine. It's slightly less messy than the alternate.
I'm sure I did try closing the file before the call somewhere along the way - but the mind wanders.
Thanks for the time folks. - really appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The way Bill suggested the logic has many benefits:
if you ever need to log different (to a DB, an indexed file, whatever) means: changing and compiling a single module
changing the logging means mostly: changing and compiling a single module
changing the control block or the call interface means changing one or two copy books, recompile the programs that include them
A hint for the control block: add a severity (most times the four levels error, warning, information, debug are a good way to go, but you can use 0-9 or whatever you like to) and maybe a group (for example file and general). Then your logging program can decide (for example depending on an environment switch what to actually log or simply dispose.
A hint for the call way: only CANCEL the program at your main program's exit and use a "first call" check in the logger to read the environment, set up some structures, whatever - this way you get the most performance with still most usefulness. If you change the environment for the logger later you can call it with a command "re-evaluate environment".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK - I tried to create a simple logging program and get the same error - 30.
I know I'm looking stupid at this point - but the learning curve goes up at 85degrees at the moment.
I've attached the tester & logging programs - sorry guys.
If I compile 'tester.cbl' and 'logging.cbl' as separate entities:
make tester
make logging
... I get the following error in 'logging.cbl':
- logging.cbl: 20: error: executable program requested but PROCEDURE/ENTRY has USING clause
- Makefile:524: recipe for target 'logging' failed
This is expected.
If I then append 'logging.cbl' to 'tester.cbl' and then compile:
make tester
... I get this error:
- logging.cbl: 5: error: CONFIGURATION SECTION not allowed in nested programs
Next I replaced "CONFIGURATION SECTION." in 'logging.cbl' with "*>CONFIGURATION SECTION." and compiled again:
make tester.
Compiles clean. Execution produces expected result. 'LOGGFILE.LST' contains these lines:
Calling LOGGING using
Return LOGGING using
PREPARE
IMO your compile process should have mentioned the same errors - wonder why?
BTW I have a Makefile that compiles files ending with 'cbl' with 'cobc -x' ... nothing mysterious.
Carry on!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gregory, I cheated - I actually compiled a source program called logging.cLL not .cBL - I have a background batch file that will run anything with 'known' file extensions - such as .cbl .cob .cll.
The batch file for a .cll source generates a .dll whereas the .cbl & .cob create .exe's.
The two programs are still seperate - just the .cbl gets a .exe & the .cll gets a .dll.
I then renamed the .cll back to .cbl to avoid anyone asking what type of file it was - sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep - it's my pc & has been for 8 or more years - despite Windows 10 thinking otherwise.
All my other programs behave - it's just this is the first time i've tried open extend.
The file was created successfully when I passed 'PREPLOGG' & is now just sitting there with 0 bytes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cobc (GnuCOBOL) 2.0.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Feb 05 2017 12:00:51
Packaged Nov 06 2016 22:36:19 UTC
C version "5.3.0"
Results
Calling LOGGING using
Return LOGGING using
PREPARE
No Abend no fail.
cobc (GnuCOBOL) 2.0-rc3.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Dec 29 2016 22:57:24
Packaged Nov 05 2016 15:27:33 UTC
C version "4.8.3 20140911 (Red Hat 4.8.3-9)"
build information
build environment : x86_64-unknown-linux-gnu
CC : gcc -std=gnu99 C version "4.8.3 20140911 (Red
Hat 4.8.
CPPFLAGS :
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : /usr/bin/ld -m elf_x86_64
LDFLAGS : -Wl,-z,relro,-z,now,-O1
You're using cobc (GnuCOBOL) 2.0-rc3.0
The only version 2.0-rc3.0 I have was supplied by Simon - specifically for testing the debugger.
It will produce .exe's but the libcob comes up with an error when running them. see below.
I've even tried running the .dll's - they run and the LOGGFILE.LST gets created but nothing else gets written - at least I don't get any actual errors - just no data in the file.
I've just downloaded rc2 & ALL of the files are exactly the same as those I downloaded to make my version 2.0 (no rc) so I'm already running rc2.
libcob: error: version mismatch
libcob: tester.cbl has version/patch level 2.0-rc3/0
libcob: libcob has version/patch level 2.0/0
cobc info below.
cobc (GnuCOBOL) 2.0-rc3.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Jan 20 2017 17:17:57
Packaged Nov 05 2016 15:27:33 UTC
C version "5.3.0"
build information
build environment : i686-pc-mingw32
CC : gcc C version "5.3.0"
CPPFLAGS : -I/mingw/include
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : c:/mingw/mingw32/bin/ld.exe
LDFLAGS :
Where did you get the rc3 - although it may not matter if you're running linux.
I don't know if you get a libcob to worry about with Linux.
You get a .so rather than a .exe or .dll don't you ??.
Last edit: David Wall 2017-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I snatched it here from the trunk, Just download the latest version and try it i think your issue will be resolved. Those programs were compiled on Linux Centos 7. Yes on linux i get .so
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I said - You're using rc3 - the latest released rc is rc2.
I already have the 'same' Packaged date & time rc3 as you - see above.
That rc3 is 'NOT' able to compile .exe's due to the included libcob being version 2.0 (not rc3).
I'm presuming that as you create a .so - you don't need libcob to run.
I'm running Windows not Linux.
Thanks anyway..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK Bill - I'll ask you a similar question.
Ubuntu - That's Linux in a skin isn't it ??.
Does it require libcob to run .exe's or does it use something else.
Because I'm running Windows - which requires libcob - and the libcob that was released with the version rc3 that I have - isn't the same version - ie: it's not rc3.
I get a runtime error - libcob: error: version mismatch
libcob: tester.cbl has version/patch level 2.0-rc3/0
libcob: libcob has version/patch level 2.0/0
which surely shows that this version of rc3 can't run .exe's.
Funny enough - I've also generated both programs as .dll's and can run them using cobcrun.
BUT the first program runs and calls the second program - which creates the file.
Then the second program gets called again & this-time it tries to open the file Extend.
which fails without any error message - it just quits.
I expect the next proper release to be any time soon - within the next few months anyway so I'll go back to reading books till then.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
libcob is always required, even cobc uses it. It doesn't matter if you use an executable or a shared object.
@David: Obviously something is very broken in your environment, I suggest to run make clean && make check - this should solve the "rc3" issue.
BTW: "rc3" is just the version number of current development - both in the main development and in the experimental debugger branch. Everyone using a current development snapshot of one of these branches have it - and the rc3 is not planned to be released at all. ...and yes, expect a release candidate within the next weeks (as always ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just run the test program with recent svn version in old MinGW environment, both compiled as single modules with cobc -debug and run via cobcrun tester.
Result: no screen i/o, resulting file LOGGFILE.LST:
Calling LOGGING using
Return LOGGING using
PREPARE
I assume this is all fine.
Last edit: Bill Woodger 2017-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon - I found the problem - it would appear to cannot open extend a null file.
If I open output fileA, then close fileA, then open extend fileA I get the error 30.
If I just simply open extend fileA I get error 35 file doesn't exist.
If I open output fileA, write anything, then close fileA, then open extend fileA - all is good.
Additionally - and more importantly - I found a libcob-4.dll sitting in my Windows\System32 folder
which I promptly deleted - how the ^%$ it got there I don't know but after re-generating the compiler from rc3 and double checking both cobc & cobcrun were version 2.rc3 _ was still getting that libcob error so I ended up doing a complete drive search & bingo.
Sorry folks - I really am that stupid sometimes.
BUT - I still think there is an error with that open extend - perhaps it should create the file if it doesn't already exist - but certainly it shouldn't require data already in the file before an open extend works.
Last edit: David Wall 2017-02-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is a bug - you should be able to open as extend a null byte file.
There is another one that I reported some years ago with opening in
extend would not create a non existing file.
Same applies to opening non existing file in I/O.
Vince
On 22/02/17 03:11, David Wall wrote:
Simon - I found the problem - it would appear to cannot open extend a
null file.
If I open output fileA, then close fileA, then open extend fileA I get
the error 30.
If I open output fileA, write anything, then close fileA, then open
extend fileA - all is good.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pulling hair out with this.
Program A - open output FileA. Writes a record then closes FileA.
FileA is a simple sequential file I want to log details in.
It then 'calls' another program which crashes out as follows:
libcob: C:/TESTPROG.cbl: 56: permanent file error (status = 30) file: 'TESTPROG.LOG'
The 'called' program does the following:
Move "TESTPROG.LOG" to LOG-NAME.
Open EXTEND LOG-FILE.
The Open is the point it crashes because I put a display/accept just before and that works.
What's the correct sequence (if any) of processing log files in multiple called programs.
I can't use I-O on a sequential file & want to have all records in the same file.
What am I doing wrong here ?????
Did you CLOSE the file before the sub-program CALL?
Anyway, use a sub-program, rather then spreading similar code all over the place.
CALLed initially by the "main" program to "open" and finally by the main program to "close".
CALLed at each relevant logging-time in whichever program/sub-program.
Try for a copybook to do the CALL, with REPLACING to format the message how you want, then using the logging in a CALLed program is simply a case of pasting an example copybook reference and changing the values on the REPLACING to be specific.
You'll need some WORKING-STORAGE, so another copybook.
Spend some time designing a "control block" for the sub-program. Decide what functions the sub-program needs (lots of things you may want to consider). Play with it in a small system or one you "write" for the purpose of playing with it.
Not sure, not really enough code to go on. Need to see some FD and SELECT clauses.
You mention FileA and LOG-FILE, so I take it the definitions aren't just copy and paste or in a copybook?
I just tried a quick pass, and it worked here.
logger.cob
Giving
sample loggerfile.txt
This is GNU/Linux running latest. (Tested with both 2.0-rc3 and reportwriter).
So, it'll work, we just need to find what might be triggering the status 30 on your end. You may have to show us your
file controlandfile sectionphrases, David.Cheers,
Brian
Thanks for the time Brian - Unfortunately Bill was right - I omitted to close the file before the call - that gets really messy having to close & repoen the file before each call.
Bill - given that I would have to close/reopen before/after each call - you may well be right in me creating another called routine. It's slightly less messy than the alternate.
I'm sure I did try closing the file before the call somewhere along the way - but the mind wanders.
Thanks for the time folks. - really appreciated.
The way Bill suggested the logic has many benefits:
A hint for the control block: add a severity (most times the four levels error, warning, information, debug are a good way to go, but you can use 0-9 or whatever you like to) and maybe a group (for example file and general). Then your logging program can decide (for example depending on an environment switch what to actually log or simply dispose.
A hint for the call way: only
CANCELthe program at your main program's exit and use a "first call" check in the logger to read the environment, set up some structures, whatever - this way you get the most performance with still most usefulness. If you change the environment for the logger later you can call it with a command "re-evaluate environment".OK - I tried to create a simple logging program and get the same error - 30.
I know I'm looking stupid at this point - but the learning curve goes up at 85degrees at the moment.
I've attached the tester & logging programs - sorry guys.
Last edit: David Wall 2017-02-20
David,
If I compile 'tester.cbl' and 'logging.cbl' as separate entities:
... I get the following error in 'logging.cbl':
- logging.cbl: 20: error: executable program requested but PROCEDURE/ENTRY has USING clause
- Makefile:524: recipe for target 'logging' failed
This is expected.
If I then append 'logging.cbl' to 'tester.cbl' and then compile:
... I get this error:
- logging.cbl: 5: error: CONFIGURATION SECTION not allowed in nested programs
Next I replaced "CONFIGURATION SECTION." in 'logging.cbl' with "*>CONFIGURATION SECTION." and compiled again:
Compiles clean. Execution produces expected result. 'LOGGFILE.LST' contains these lines:
Calling LOGGING using
Return LOGGING using
PREPARE
IMO your compile process should have mentioned the same errors - wonder why?
BTW I have a Makefile that compiles files ending with 'cbl' with 'cobc -x' ... nothing mysterious.
Carry on!
Gregory, I cheated - I actually compiled a source program called logging.cLL not .cBL - I have a background batch file that will run anything with 'known' file extensions - such as .cbl .cob .cll.
The batch file for a .cll source generates a .dll whereas the .cbl & .cob create .exe's.
The two programs are still seperate - just the .cbl gets a .exe & the .cll gets a .dll.
I then renamed the .cll back to .cbl to avoid anyone asking what type of file it was - sorry.
Thinking about it, for the "file already open" you should get a FILE STATUS of 41, not the 30, so you probably did have the CLOSE earlier.
Are you writing somehwere you are allowed to write to?
Yep - it's my pc & has been for 8 or more years - despite Windows 10 thinking otherwise.
All my other programs behave - it's just this is the first time i've tried open extend.
The file was created successfully when I passed 'PREPLOGG' & is now just sitting there with 0 bytes.
What does
cobc --infosays?cobc (GnuCOBOL) 2.0.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Feb 05 2017 12:00:51
Packaged Nov 06 2016 22:36:19 UTC
C version "5.3.0"
build information
build environment : i686-pc-mingw32
CC : gcc
CPPFLAGS : -I/mingw/include
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : c:/mingw/mingw32/bin/ld.exe
LDFLAGS :
GnuCOBOL information
COB_CC : gcc
COB_CFLAGS : -I/mingw/include -I/mingw/include -pipe
COB_LDFLAGS :
COB_LIBS : -L/mingw/lib -lcob -lm -lgmp -L/mingw/lib
-lintl -lpdcurses -ldb-6.2
COB_CONFIG_DIR : /mingw/share/gnu-cobol/config
COB_COPY_DIR : /mingw/share/gnu-cobol/copy
COB_MSG_FORMAT : GCC
COB_MODULE_EXT : dll
COB_EXEEXT : .exe
64bit-mode : no
BINARY-C-LONG : 4 bytes
extended screen I/O : pdcurses
variable format : 0
sequential handler : built-in
ISAM handler : BDB
Would
SHARING WITH ALLin theSELECTalso fix this? It would save having to close and re-open the file on everyCALL.cobc -m logging.cbl
cobc -x tester.cbl
Results
Calling LOGGING using
Return LOGGING using
PREPARE
No Abend no fail.
cobc (GnuCOBOL) 2.0-rc3.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Dec 29 2016 22:57:24
Packaged Nov 05 2016 15:27:33 UTC
C version "4.8.3 20140911 (Red Hat 4.8.3-9)"
build information
build environment : x86_64-unknown-linux-gnu
CC : gcc -std=gnu99 C version "4.8.3 20140911 (Red
Hat 4.8.
CPPFLAGS :
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : /usr/bin/ld -m elf_x86_64
LDFLAGS : -Wl,-z,relro,-z,now,-O1
GnuCOBOL information
COB_CC : gcc -std=gnu99
COB_CFLAGS : -I/usr/local/include -Wno-unused
-fsigned-char -Wno-pointer-sign -pipe
COB_LDFLAGS :
COB_LIBS : -L/usr/local/lib -lcob -lm -lvbisam -lgmp
-lncursesw -ldl
COB_CONFIG_DIR : /usr/local/share/gnucobol/config
COB_COPY_DIR : /usr/local/share/gnucobol/copy
COB_MSG_FORMAT : GCC
COB_OBJECT_EXT : o
COB_MODULE_EXT : so
COB_EXE_EXT :
64bit-mode : yes
BINARY-C-LONG : 8 bytes
extended screen I/O : ncursesw
variable format : 0
sequential handler : built-in
ISAM handler : VBISAM
mathematical library : GMP
You're using cobc (GnuCOBOL) 2.0-rc3.0
The only version 2.0-rc3.0 I have was supplied by Simon - specifically for testing the debugger.
It will produce .exe's but the libcob comes up with an error when running them. see below.
I've even tried running the .dll's - they run and the LOGGFILE.LST gets created but nothing else gets written - at least I don't get any actual errors - just no data in the file.
I've just downloaded rc2 & ALL of the files are exactly the same as those I downloaded to make my version 2.0 (no rc) so I'm already running rc2.
libcob: error: version mismatch
libcob: tester.cbl has version/patch level 2.0-rc3/0
libcob: libcob has version/patch level 2.0/0
cobc info below.
cobc (GnuCOBOL) 2.0-rc3.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Jan 20 2017 17:17:57
Packaged Nov 05 2016 15:27:33 UTC
C version "5.3.0"
build information
build environment : i686-pc-mingw32
CC : gcc C version "5.3.0"
CPPFLAGS : -I/mingw/include
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : c:/mingw/mingw32/bin/ld.exe
LDFLAGS :
GnuCOBOL information
COB_CC : gcc
COB_CFLAGS : -I/mingw/include -Wno-unused -fsigned-char
-Wno-pointer-sign -I/mingw/include -pipe
COB_LDFLAGS :
COB_LIBS : -L/mingw/lib -lcob -lm -lgmp -L/mingw/lib
-lintl -lpdcurses -ldb-6.2
COB_CONFIG_DIR : /mingw/share/gnucobol/config
COB_COPY_DIR : /mingw/share/gnucobol/copy
COB_MSG_FORMAT : GCC
COB_OBJECT_EXT : o
COB_MODULE_EXT : dll
COB_EXE_EXT : .exe
64bit-mode : no
BINARY-C-LONG : 4 bytes
extended screen I/O : pdcurses
variable format : 0
sequential handler : built-in
ISAM handler : BDB
mathematical library : MPIR - GMP
Where did you get the rc3 - although it may not matter if you're running linux.
I don't know if you get a libcob to worry about with Linux.
You get a .so rather than a .exe or .dll don't you ??.
Last edit: David Wall 2017-02-21
I snatched it here from the trunk, Just download the latest version and try it i think your issue will be resolved. Those programs were compiled on Linux Centos 7. Yes on linux i get .so
As I said - You're using rc3 - the latest released rc is rc2.
I already have the 'same' Packaged date & time rc3 as you - see above.
That rc3 is 'NOT' able to compile .exe's due to the included libcob being version 2.0 (not rc3).
I'm presuming that as you create a .so - you don't need libcob to run.
I'm running Windows not Linux.
Thanks anyway..
I can run your code on Ubuntu, and all works as expected.
If I deliberately leave the file open, there's a FILE STATUS of 41.
Your code should work (I'd do it differently) but there is something amiss with your setup.
OK Bill - I'll ask you a similar question.
Ubuntu - That's Linux in a skin isn't it ??.
Does it require libcob to run .exe's or does it use something else.
Because I'm running Windows - which requires libcob - and the libcob that was released with the version rc3 that I have - isn't the same version - ie: it's not rc3.
I get a runtime error - libcob: error: version mismatch
libcob: tester.cbl has version/patch level 2.0-rc3/0
libcob: libcob has version/patch level 2.0/0
which surely shows that this version of rc3 can't run .exe's.
Funny enough - I've also generated both programs as .dll's and can run them using cobcrun.
BUT the first program runs and calls the second program - which creates the file.
Then the second program gets called again & this-time it tries to open the file Extend.
which fails without any error message - it just quits.
I expect the next proper release to be any time soon - within the next few months anyway so I'll go back to reading books till then.
libcob is always required, even cobc uses it. It doesn't matter if you use an executable or a shared object.
@David: Obviously something is very broken in your environment, I suggest to run
make clean && make check- this should solve the "rc3" issue.BTW: "rc3" is just the version number of current development - both in the main development and in the experimental debugger branch. Everyone using a current development snapshot of one of these branches have it - and the rc3 is not planned to be released at all. ...and yes, expect a release candidate within the next weeks (as always ;-)
I have just run the test program with recent svn version in old MinGW environment, both compiled as single modules with
cobc -debugand run viacobcrun tester.Result: no screen i/o, resulting file LOGGFILE.LST:
I assume this is all fine.
Last edit: Bill Woodger 2017-02-21
Simon - I found the problem - it would appear to cannot open extend a null file.
If I open output fileA, then close fileA, then open extend fileA I get the error 30.
If I just simply open extend fileA I get error 35 file doesn't exist.
If I open output fileA, write anything, then close fileA, then open extend fileA - all is good.
Additionally - and more importantly - I found a libcob-4.dll sitting in my Windows\System32 folder
which I promptly deleted - how the ^%$ it got there I don't know but after re-generating the compiler from rc3 and double checking both cobc & cobcrun were version 2.rc3 _ was still getting that libcob error so I ended up doing a complete drive search & bingo.
Sorry folks - I really am that stupid sometimes.
BUT - I still think there is an error with that open extend - perhaps it should create the file if it doesn't already exist - but certainly it shouldn't require data already in the file before an open extend works.
Last edit: David Wall 2017-02-22
That is a bug - you should be able to open as extend a null byte file.
There is another one that I reported some years ago with opening in
extend would not create a non existing file.
Same applies to opening non existing file in I/O.
Vince
On 22/02/17 03:11, David Wall wrote:
Thanks Vincent - I've reported it as such.
Was this bug fixed? I am having this problem with the latest GnuCOBOL version.