This may help.
It is a program to call cob_init using Windows API(s)
I do not know where this would fit in with the Realia RTS.
However the program:
Loads the coblib-4.dll (LoadLibraryA)
Gets the address of cob_init (GetProcAddress)
Calls cob_init (Call Procedure Pointer)
I have used something similar to it when my .EXE is from PL/I.
The program is currently in GnuCOBOL form.
I would make a .DLL from the code (Realia ?)
Ralph
compiled CALLCOBINIT.cob with cobc. With realia compiler it gave lots of errors. e.g.
8 E Unrecognizable word or literal 'IS'
9 E EBCDIC or STANDARD-N expected; found 'CALL-CONVENTION'
9 E Unrecognizable word or literal '74'
9 E Unrecognizable word or literal 'IS'
9 E EBCDIC or STANDARD-N expected; found '.'
15 E Unrecognizable word or literal '78'
15 E Unrecognizable word or literal 'ABSOLUTE-RUNTIME-MIN-VAL'
15 E Unrecognizable word or literal 'VALUE'
cobc -c CALLCOBINIT.COB
Created CALLCOBINIT.dll & CALLCOBINIT.lib
LINK /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:WINDOWS /DLL /machine:X86 /NODEFAULTLIB:LIBC /DEBUG:FULL /OUT:CALLCOBINIT.DLL CALLCOBINIT.obj libcob.lib /LIBPATH:C:\OCVS\lib
Creating library CALLCOBINIT.lib and object CALLCOBINIT.exp
compiled program1 with Realia compiler.
COBOL /HVWEL:E C:\OCVS\Programs\Program1\Program1.cob C:\OCVS\Programs\Program1\Program1.obj C:\OCVS\Programs\Program1\Program1.lst
Created Program1.exe. Here I added CALLCOBINIT.lib. Without CALLCOBINIT.lib, I get error"unresolved external symbol _CALLCOBINIT"
link.exe /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /machine:X86 "/DEBUG:FULL" /ENTRY:_RealiaCOBOLexeentry /OUT:Program1.EXE Program1.obj CALLCOBINIT.lib carclw62.lib /LIBPATH:C:\ccch\AdvantageCARealia33\Lib
c:\OCVS\Programs\Program1>Program1.EXE
IN PROGRAM1 ENTRY
libcob: error: cob_init() has not been called
So it seems I need to convert CALLCOBINIT.cob from GnuCobol form to Realia form and try compiling with Realia compiler?
Regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the benefit of no C calls at all and possible switch between 32/64 bit, but that only privides untyped parameter passing and only a return code back.
Note: as a third alternative you can also compile your entry programs on the GnuCOBOL side with -fimplicit-init and drop the init call on the C side. In this case you'd either have to do a C call to cob_tidy after your GC compiled program or use STOP RUN there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
compile your entry programs on the GnuCOBOL side with -fimplicit-init and drop the init call
Why is -fimplicit-init and/or cob_init necessary? Why not make -fimplicit-init automatic, make the flag a no-op, and have cob_init return immediately (doing nothing) when called explicitly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Calling cob_init internally at the start of every program just looks quite wrong.
Adjusting the code generation in a way that always calls it if necessary (if I remember correctly it already has a simple check now for implicit-init) would be possible, but this initialization has to be considered "dirty", for example libcob could not provide meaningful argv when requested.
Calling cob_init "external" via C API is a different issue. Actually it is an error to do so before cob_tidy was called. Doing a hard abort leads to caller be fixed once and everything is fine, raising a runtime warning won't break anything and still lead to awareness (if not suppressed or redirected somewhere no one looks at as long as nothing breaks).
For 4.0 we could change to have cob_init only be used for the C API, returning an int instead of void to possibly be more "library-like" and move the codegen code to cob_init_internal and abort there. We still need to ensure that we ideally keep a compatible C API to the compilers we already have, of course...
MF has no "only cob_init", how does it handle a double cobcall without a cobtidy in between (GnuCOBOL will abort with a runtime error)?
Last edit: Simon Sobisch 2020-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Calling cob_init internally at the start of every program just looks quite wrong.
If so, what does -fimplicit-init do?
I remind you both elf and Windows support functions that run
automatically on load/unload.
I'm unsure cob_init or cob_exit is actually needed. If needed, I don't see why they can't be automatic. If they can't be automatic, I don't see why they can't be idempotent.
for example libcob could not provide meaningful argv when requested
I don't understand this objection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Calling cob_init internally at the start of every program just looks
quite wrong.
I remind you both elf and Windows support functions that run
automatically on load/unload.
I'm also unsure anything in cob_init or cob_exit is actually needed.
Adjusting the code generation in a way that always calls it if
necessary (if I remember correctly it already has a simple check now for implicit-init) would be possible, but this initialization
has to be considered "dirty", for example libcob could not provide
meaningful argv when requested.
I don't understand that objection.
Calling cob_init "external" via C API
is a different issue. Actually it is an error to do so before
cob_tidy was called. Doing a hard abort leads to caller be fixed once
and everything is fine, raising a runtime warning won't break
anything and still lead to awareness (if not suppressed or redirected
somewhere no one looks at as long as nothing breaks). For 4.0 we
could change to have cob_init only be used for the C API, returning
an int instead of void to possibly be more "library-like" and move
the codegen code to cob_init_internal and abort there. We still need
to ensure that we ideally keep a compatible C API to the compilers we
already have, of course...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just another note to the COBINIT program: if you link libcob on the Realia side you don't need to manually load the program via win32api (actually your program should not even start then when libcob is not in PATH.
To work good you'd have to ensure that cob_init, cob_external_init or whatever libcob function you CALL from Realia:
uses the "C" call convention including the return code size (howevr this si done in Realia)
ideally also uses a static call-convention, which ensures that the functions are already resolved at link time (= you get a link error message instead a runimte error message)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cob_tidy() cleans up everything, if you do STOP RUN within GnuCOBOL it is done automatically, If you only use GOBACK in your main program you can enter it again keeping the same state, which is the way it should be - so there's no option to do a cob_tidy() (or cob_cancel() automatically).
Note: if you always want to auto-cancel the cobol program afterwards (still leaving the runtime initialized) you may call cob_func() instead, if you want to ensure the init is done but no automatic cancel just compile your program normally and use cob_call() instead of a manual initialization (but be aware that you need to tidy after that before calling the next one with the same approach - or initialize with cob_extern_init as mentioned above.
Actually this is another point why I feel a cob_init to just go through or return back without any error bad, if you explicit call it twice, you may assume it does the "necessary" cob_tidy() = re-initialize itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ron is working on a "interface with C" documentation, which will solve all this, until then - minmal stuf is found in the manual (including the init and tidy and dynamic and shared linking) [GnuCOBOL.pdf shipped under "docs"] and you can have a look at libcob/common.h and manually investigate the functions near cob_init (and the redefine cobinit, which is added for MF compatibility, but as it is a define not useable as-is from COBOL).
Many of the functions have equivalents in Microfocus (see the defines mentioned) so you may have a look for those names in the MF docs, too.
Note: the data types may map differently in Realia...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying one test where I am calling Cobc compiled COBOL program from Realia compiled COBOL program.
I have written a simple COBOL program. without the COB_INIT functions I was getting "libcob: error: cob_init() has not been called" error.
So I added COB_INIT function. For now I have commented CALL to Program2.
I have created Program1.obj using realia compiler.
Then I am trying this Link command to create Program1.exe. but I get below errors.
I am using libcob.lib library in the LINK command but I am not sure if I am missing anything else.
Regards,
Abhijeet
Last edit: Simon Sobisch 2020-07-15
This may help.
It is a program to call cob_init using Windows API(s)
I do not know where this would fit in with the Realia RTS.
However the program:
Loads the coblib-4.dll (LoadLibraryA)
Gets the address of cob_init (GetProcAddress)
Calls cob_init (Call Procedure Pointer)
I have used something similar to it when my .EXE is from PL/I.
The program is currently in GnuCOBOL form.
I would make a .DLL from the code (Realia ?)
Ralph
Last edit: Ralph Linkletter 2020-07-15
Hi,
Thank you. I am getting error as below.
I tried this. I kept just one call in Program1 i.e. call to CALLCOBINIT
compiled CALLCOBINIT.cob with cobc. With realia compiler it gave lots of errors. e.g.
8 E Unrecognizable word or literal 'IS'
9 E EBCDIC or STANDARD-N expected; found 'CALL-CONVENTION'
9 E Unrecognizable word or literal '74'
9 E Unrecognizable word or literal 'IS'
9 E EBCDIC or STANDARD-N expected; found '.'
15 E Unrecognizable word or literal '78'
15 E Unrecognizable word or literal 'ABSOLUTE-RUNTIME-MIN-VAL'
15 E Unrecognizable word or literal 'VALUE'
cobc -c CALLCOBINIT.COB
Created CALLCOBINIT.dll & CALLCOBINIT.lib
LINK /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:WINDOWS /DLL /machine:X86 /NODEFAULTLIB:LIBC /DEBUG:FULL /OUT:CALLCOBINIT.DLL CALLCOBINIT.obj libcob.lib /LIBPATH:C:\OCVS\lib
Creating library CALLCOBINIT.lib and object CALLCOBINIT.exp
compiled program1 with Realia compiler.
COBOL /HVWEL:E C:\OCVS\Programs\Program1\Program1.cob C:\OCVS\Programs\Program1\Program1.obj C:\OCVS\Programs\Program1\Program1.lst
Created Program1.exe. Here I added CALLCOBINIT.lib. Without CALLCOBINIT.lib, I get error"unresolved external symbol _CALLCOBINIT"
link.exe /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /machine:X86 "/DEBUG:FULL" /ENTRY:_RealiaCOBOLexeentry /OUT:Program1.EXE Program1.obj CALLCOBINIT.lib carclw62.lib /LIBPATH:C:\ccch\AdvantageCARealia33\Lib
c:\OCVS\Programs\Program1>Program1.EXE
IN PROGRAM1 ENTRY
libcob: error: cob_init() has not been called
So it seems I need to convert CALLCOBINIT.cob from GnuCobol form to Realia form and try compiling with Realia compiler?
Regards,
Yes, that's the point of this program.
Obviously (alternative 2) you can start an executable from Realia as another option, something like
With the benefit of no C calls at all and possible switch between 32/64 bit, but that only privides untyped parameter passing and only a return code back.
Note: as a third alternative you can also compile your entry programs on the GnuCOBOL side with -fimplicit-init and drop the init call on the C side. In this case you'd either have to do a C call to cob_tidy after your GC compiled program or use STOP RUN there.
Why is
-fimplicit-initand/or cob_init necessary? Why not make-fimplicit-initautomatic, make the flag a no-op, and have cob_init return immediately (doing nothing) when called explicitly?Calling cob_init internally at the start of every program just looks quite wrong.
Adjusting the code generation in a way that always calls it if necessary (if I remember correctly it already has a simple check now for implicit-init) would be possible, but this initialization has to be considered "dirty", for example libcob could not provide meaningful argv when requested.
Calling cob_init "external" via C API is a different issue. Actually it is an error to do so before cob_tidy was called. Doing a hard abort leads to caller be fixed once and everything is fine, raising a runtime warning won't break anything and still lead to awareness (if not suppressed or redirected somewhere no one looks at as long as nothing breaks).
For 4.0 we could change to have cob_init only be used for the C API, returning an int instead of void to possibly be more "library-like" and move the codegen code to cob_init_internal and abort there. We still need to ensure that we ideally keep a compatible C API to the compilers we already have, of course...
MF has no "only cob_init", how does it handle a double
cobcallwithout acobtidyin between (GnuCOBOL will abort with a runtime error)?Last edit: Simon Sobisch 2020-07-17
Rechecked:
MF has no "only cob_init", how does it handle a double
cobcallwithout acobtidyin between (GnuCOBOL will abort with a runtime error)?Note:
cob_extern_initmay be called instead ofcob_init, that initializes GnuCOBOL only if necessary and sets argc/argv to nothing in this case.If so, what does -fimplicit-init do?
I remind you both elf and Windows support functions that run
automatically on load/unload.
I'm unsure cob_init or cob_exit is actually needed. If needed, I don't see why they can't be automatic. If they can't be automatic, I don't see why they can't be idempotent.
I don't understand this objection.
On Fri, 17 Jul 2020 06:04:45 -0000
"Simon Sobisch" sf-mensch@users.sourceforge.net wrote:
I remind you both elf and Windows support functions that run
automatically on load/unload.
I'm also unsure anything in cob_init or cob_exit is actually needed.
I don't understand that objection.
Calling cob_init "external" via C API
Just another note to the COBINIT program: if you link libcob on the Realia side you don't need to manually load the program via win32api (actually your program should not even start then when libcob is not in
PATH.To work good you'd have to ensure that
cob_init,cob_external_initor whatever libcob function youCALLfrom Realia:Yes, I agree, it would be good to have cob_init, cob_tidy, etc run automatically whenever needed.
cob_tidy()cleans up everything, if you doSTOP RUNwithin GnuCOBOL it is done automatically, If you only useGOBACKin your main program you can enter it again keeping the same state, which is the way it should be - so there's no option to do acob_tidy()(orcob_cancel()automatically).Note: if you always want to auto-cancel the cobol program afterwards (still leaving the runtime initialized) you may call
cob_func()instead, if you want to ensure the init is done but no automatic cancel just compile your program normally and usecob_call()instead of a manual initialization (but be aware that you need to tidy after that before calling the next one with the same approach - or initialize withcob_extern_initas mentioned above.Actually this is another point why I feel a
cob_initto just go through or return back without any error bad, if you explicit call it twice, you may assume it does the "necessary"cob_tidy()= re-initialize itself.Thank you for your help. Using the C calling convention removed the linker error I mentioned in my query.
Where do I see information about cob_extern_init, cob_func, cob_call functions? I do not see details of these functions in the GnuCobol manual.
Also, may I ask about the details of the call and various parameter data types when I call cob_init or above functions from Cobol programs?
Ron is working on a "interface with C" documentation, which will solve all this, until then - minmal stuf is found in the manual (including the init and tidy and dynamic and shared linking) [GnuCOBOL.pdf shipped under "docs"] and you can have a look at libcob/common.h and manually investigate the functions near cob_init (and the redefine cobinit, which is added for MF compatibility, but as it is a define not useable as-is from COBOL).
Many of the functions have equivalents in Microfocus (see the defines mentioned) so you may have a look for those names in the MF docs, too.
Note: the data types may map differently in Realia...
@abhijeet-chavan Did you made some progress with this project?