tiny-cobol-users

Re: [Tiny-cobol-users] Error while loading shared libraries

[David E. <de...@us...>]

I think we need to isolate the problem, so I will require more information.

Vince Coen wrote:

 > David Essex wrote:
 >
 >> Vince Coen wrote:
 >>
 >>> I am still not able to run all tests without some failures
 >>> despite using various versions of gcc including 4.1.1 , 3.3.6
 >>> amd 2.96.
 >>> What is the corrent one to use?

Well GCC 3.3.6 should work.

Do you have 3 GCC versions on one system ?

If so, so you have 3 versions of the back end (GAS and Linux linker) ?


 >> Version 0.63 should compile and run on 32-bit systems
 >> using GCC 2.x - 3.x.
 >> I have no information about 32-bit (or 64-bit) systems using
 >> GCC 4.x.
 >>
 >> I think the problem you have encountered is related to 64-bit
 >> systems.
 >> Since I have no experience with 64-bit systems, I really can't
 >> help.
 >
 > Nope running in a 32 bit Mandriva environment only.
 > Want to get the basics working first.

When you use GCC version 3.x, do you still get the following errors ?

As for perf06 I get:
$ htcobol perf06
perf06.cob: Assembler messages:
perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined
perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined

Actually could you try the following command and list the output.
$htcobol -v perf06.cob

If the above problem persists, issue the following command and send me
(not the list) the assembler file in a ZIP or TAR/GZ archive.
$htcobol -v -S perf06.cob

David Essex

Re: [Tiny-cobol-users] [open-cobol-list] CALL SYSTEM OR CALL "SYSTEM"

[John R. C. <jo...@we...>]

On Friday 05 January 2007 08:45, John R. Culleton wrote:
> I recal that some COBOL variants had  a statement like
> CALL "SYSTEM" USING FIELDX
> for passing comand line strings to the CLI. I know I could link in a C
> language module to do this but I just wonderd if there was a built in
> function.

Never mind, found it. 
CALL "system" USING "cal". 
gotta be lower case "system". 
-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

[Tiny-cobol-users] CALL SYSTEM OR CALL "SYSTEM"

[John R. C. <jo...@we...>]

I recal that some COBOL variants had  a statement like 
CALL "SYSTEM" USING FIELDX
for passing comand line strings to the CLI. I know I could link in a C 
language module to do this but I just wonderd if there was a built in 
function.
-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Error while loading shared libraries

[vince c. <vb...@bt...>]

Hi;

On Thursday 04 January 2007 19:54, David Essex wrote:


>  > I am still not able to run all tests without some failures
>  > despite using various versions of gcc including 4.1.1 , 3.3.6
>  > amd 2.96.
>  > What is the corrent one to use?
>
> Version 0.63 should compile and run on 32-bit systems using GCC 2.x - 3.x.
> I have no information about 32-bit (or 64-bit) systems using GCC 4.x.
>
> I think the problem you have encountered is related to 64-bit systems.
> Since I have no experience with 64-bit systems, I really can't help.

Nope running in a 32 bit Mandriva environment only. Want to get the basics 
working first.

Vince.

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[Nilo <nil...@gm...>]

Hi, David.

On 1/4/07, David Essex <de...@us...> wrote:
>
> Nilo,
>
> If you wish, why not run some tests with these GAS directives that
> permit the exporting of symbols.


These are exactly the tests I'm doing now. Wel, it's difficult to find docs
about it, and I'm not a GAS expert...

When testing some assembler code, I usually generate an assembler file
> using 'htcobol -S prog.cob'.
> You can then modify the assembler file manually, and use it as the input
> to GCC.


That's the way I'm trying to do... ;-)

David Essex


By the way... Just curious: where are you from?

Thanks.

Nilo R C Paim
Porto Alegre - RS - Brazil

Re: [Tiny-cobol-users] Tiny Cobol Syntax and Language

[David E. <de...@us...>]

Vince Coen wrote:

 > Where is a list of Cobol Language and syntax as used
 > in TinyCobol to be found?
 >
 > This would help in knowing what changes I need to make
 > to some old MF cobol sources.

There is no COBOL syntax documentation for TC.

If you use COBOL-85 syntax and avoid MF specific extensions, most
programs should compile and run.

Some areas or problems you may encounter.

1) No report generator.
2) Limited support for curses based screen IO
3) Using very large/small numbers can be problematic.

I'm sure there are many others.

Hope this helps.

David Essex

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[David E. <de...@us...>]

Nilo,

If you wish, why not run some tests with these GAS directives that
permit the exporting of symbols.

When testing some assembler code, I usually generate an assembler file
using 'htcobol -S prog.cob'.
You can then modify the assembler file manually, and use it as the input
to GCC.


David Essex

Re: [Tiny-cobol-users] Error while loading shared libraries

[David E. <de...@us...>]

Vince Coen wrote:

 > David Essex wrote:
 > ...
 >> I'm not sure what mean.
 >
 > I mean to link all the program elements / routines /
 > sub programs etc together with all runtime libraries
 > to make a complete running program that can be
 > transferred to any linux system and run as a standalone program.

I think you mean a completly statically linked program.
Yes you can do that, but it is generally not done (on UN*X) except by 
some system utilities.

The only dependencies used by TC programs are TC-RTL, BDB and (n/pd)curses.

UN*X:
Except for the TC RTL, all other dependencies including BDB and 
(n)curses, are usually part of the UN*X (Linux/BSD) distribution

Distributing binaries on UN*X (especially Linux) can be problematic.
But this is not specific to TC, but a very common problem.

Win32:
The best approach is to create a TC-RTL DLL which includes BDB and PDcurses.
Then all TC dependencies are resolved by the TC-RTL DLL.
Down side, 3 different licenses in one DLL.

On UN*X, you can check the dependencies using the LDD command.

 > ...
 > I am still not able to run all tests without some failures
 > despite using various versions of gcc including 4.1.1 , 3.3.6
 > amd 2.96.
 > What is the corrent one to use?

Version 0.63 should compile and run on 32-bit systems using GCC 2.x - 3.x.
I have no information about 32-bit (or 64-bit) systems using GCC 4.x.

I think the problem you have encountered is related to 64-bit systems.
Since I have no experience with 64-bit systems, I really can't help.

David Essex

Re: [Tiny-cobol-users] Error while loading shared libraries

[vince c. <vb...@bt...>]

Hi David

On Friday 29 December 2006 23:23, David Essex wrote:
>
> A quick solution is to move the relavent objects from the their
> '/usr/local' to the '/usr' sub-directories.
>
> As for running the test_suite perl script, in the 'lib' directory type
> 'make clean' and then 'make static-libs'.
> This should enable you to run the test_suite perl script with out any
> modifications.
>
>  > Allowing for strong Ram facilities Can I not just
>  > compile the whole program to link all required
>  > modules and libraries together and would this be the
>  > fastest way to load and run?
>
> I'm not sure what mean.
> Have you looked at the 'htcobrun' in the 'cobrun' directory.

I mean to link all the program elements / routines / sub programs etc together 
with all runtime libraries to make a complete running program that can be 
transferred to any linux system and run as a standalone program.

>  > I cannot see any documentation on this or what language set
>  > is available in the compiler at this time.
>
> Well, English only I'm afraid.

I mean here the Cobol Language and syntax as used in Tiny Cobol.

I am still not able to run all tests without some failures despite using 
various versions of gcc including 4.1.1 , 3.3.6 amd 2.96.  What is the 
corrent one to use?


Vince.
 

[Tiny-cobol-users] Tiny Cobol Syntax and Language

[vince c. <vb...@bt...>]

Hi All;

Where is a list of Cobol Language and syntax as used in Tiny Cobol to be 
found?

This would help in knowing what changes I need to make to some old MF cobol 
sources.


Thanks,

Vince

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[Nilo <nil...@gm...>]

On 1/3/07, David Essex <de...@us...> wrote:
>
> Nilo Paim wrote:
>
> > ...
> > Well, that way the DLL is not dynamic as it could be... What's the
> > advantage of using DLL's if I need link it together (except for the
> > resulting size of the animal, of course)?
>
> Actually that was just an example similar that found in 't25'.
> An example of run-time linking can be found in 't33'.
>
> It all depends on what kind of COBOL CALL is made.
>
> CALL { indenfier-1 | literal-1 } ...
>
> If 'indenfier-1' is used, then run-time linking is used. Meaning
> load-library, and link to function.
>
> If 'literal-1' is used, then compile-time linking is used. Both static
> libraries and DLL's can be used in the link. With GCC the default is a
> DLL if the export library 'lib_name.dll.a' is present.
>
>
> > ...
>
> The TC command line does not accept multiple input sources for any
> option. That was done by design, otherwise the interface becomes too
> complex.


Yes, I agree.

> That's the point. I suggest that TC should do it, using as
> > export'ed functions all the PROGRAM-ID's names from the Cobol
> > sources.
> > The result I expect is the same as I would if I code the
> > equivalent using '__declspec(dllexport)' in C, if you
> > understand me...
> > And I think we could emit Win32 directives to the assembly
> > code...
>
> Yes, I'm aware of the '__declspec(dllexport)' C macros.
> I'm no Win32 expert, but these macros define only the functions which
> need to be exported.
> As I understand it, this means only functions which are called by other
> functions outside the DLL. Not all functions in the DLL must be exported.


Yes. Just the entry point must be exported, i. e, the functions named as
PROGRAM-ID clause.

The COBOL language does not have these 'macros'.
> But you can define which functions to export in the export defines
> 'lib_name.def' file. And then use the MinGW-GCC tool-chain to create the
> export library (in MinGW it is usually called 'lib_name.dll.a') and DLL.
>
> If TC generates Win32 directives in the assembly code, then all
> COBOL functions are exported. You still have create a export defines
> 'lib_name.def' file, and you still have use the MinGW-GCC tool-chain to
> create the export library and DLL.


That way I'll link the Cobol program with the export library. I would like
not to link the Cobol program anyway. Just call the functions of the DLL...


So what is the advantage ?


I was thinking that TC could be used to generate Win32 standard DLL's. That
way, it could be usable from another languages, like C,  Delphi, Lazarus,
etc... any language that can use DLL's...

Also when you create a Win32 DLL in C, you must define a Win32 API
> function 'DLL_Entry ...' (I think is called).
> I'm NOT positive, but I think GCC (MinGW) does include that code segment
> in the DLL.


I think I really need to think more about...

Frankly, I have no objection to TC generating Win32 DLL directives in
> the assembly code.
> However, I think letting the MinGW-GCC tool-chain do the work is a
> better approach.
>
> Anyway, as I mentioned above, I'm no Win32 expert.
> So as always, all comments, suggestions and pizza coupons are welcomed.
>
> David Essex


Thanks for your hints and prompt responses, David.

Nilo R C Paim
Porto Alegre - RS - Brazil

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[David E. <de...@us...>]

Nilo Paim wrote:

 > ...
 > Well, that way the DLL is not dynamic as it could be... What's the
 > advantage of using DLL's if I need link it together (except for the
 > resulting size of the animal, of course)?

Actually that was just an example similar that found in 't25'.
An example of run-time linking can be found in 't33'.

It all depends on what kind of COBOL CALL is made.

CALL { indenfier-1 | literal-1 } ...

If 'indenfier-1' is used, then run-time linking is used. Meaning
load-library, and link to function.

If 'literal-1' is used, then compile-time linking is used. Both static
libraries and DLL's can be used in the link. With GCC the default is a
DLL if the export library 'lib_name.dll.a' is present.


 > ...

The TC command line does not accept multiple input sources for any
option. That was done by design, otherwise the interface becomes too
complex.

 > That's the point. I suggest that TC should do it, using as
 > export'ed functions all the PROGRAM-ID's names from the Cobol
 > sources.
 > The result I expect is the same as I would if I code the
 > equivalent using '__declspec(dllexport)' in C, if you
 > understand me...
 > And I think we could emit Win32 directives to the assembly
 > code...

Yes, I'm aware of the '__declspec(dllexport)' C macros.
I'm no Win32 expert, but these macros define only the functions which 
need to be exported.
As I understand it, this means only functions which are called by other 
functions outside the DLL. Not all functions in the DLL must be exported.

The COBOL language does not have these 'macros'.
But you can define which functions to export in the export defines 
'lib_name.def' file. And then use the MinGW-GCC tool-chain to create the 
export library (in MinGW it is usually called 'lib_name.dll.a') and DLL.

If TC generates Win32 directives in the assembly code, then all
COBOL functions are exported. You still have create a export defines
'lib_name.def' file, and you still have use the MinGW-GCC tool-chain to 
create the export library and DLL.

So what is the advantage ?

Also when you create a Win32 DLL in C, you must define a Win32 API
function 'DLL_Entry ...' (I think is called).
I'm NOT positive, but I think GCC (MinGW) does include that code segment
in the DLL.

Frankly, I have no objection to TC generating Win32 DLL directives in
the assembly code.
However, I think letting the MinGW-GCC tool-chain do the work is a 
better approach.

Anyway, as I mentioned above, I'm no Win32 expert.
So as always, all comments, suggestions and pizza coupons are welcomed.

David Essex

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[Nilo <nil...@gm...>]

On 1/3/07, David Essex <de...@us...> wrote:
>
> Nilo Paim wrote:
>
> > ...
> > Unfortunately I've no access to a Linux box now...
>
> You are aware that to use SF CVS you will require some package which has
> SSH available, such as Putty.


Oh, yes. No problems here...

> ...
> >> Basically the export/import defines, and '.def' files are
> auto-generated
> >> by the MinGW compiler.
> >
> > Well, that's the problem... a Cobol program doesn't have generated the
> > GAS directives that permits the exporting of symbols...
> >
> > So, the MinGW compiler does not know what symbols to export...
> > ...
> > Well, I made some tests and modifications on my local copy... when I
> > call DLL's written in C or something like that it works like a charm,
> > without 'CALL-LOADLIB' extension. All my problems begins when I try to
> > call DLL's generated by TinyCobol... I'm able to find the DLL, but not
> > the sub-programs ( functions ), just because there are no functions
> > exported...
> >
> > Maybe should the compiler export all PROGRAM-ID's identifiers as
> > functions names, i. e, put the '.section .drectve' and '.ascii "
> > -export:prog-id-name"' clauses on generated code?
> >
> > Well, at least this is my first tough about... ;-)
>
> First we need to isolate the problem.
>
> What version of GCC (MinGW) are you using ?


 gcc 3.2.3

Have you tried to compile (using the Makefile.mingw) and run the
> examples found in t25 and t33 ?
> If these examples do not work, then we have a problem because they do
> work on GCC 3.x (MinGW).


Not yet. I'll do it tonight at home.

Regarding the export/import defines, the TC compiler does not generate
> any Win32 directives.
> The TC front end will spawn a process and let GCC worry about the details.


Well, that's exactly the point where I'm going to...

So if you try using 'htcobol -v -m ...' command, TC should spawn a
> process with the equivalent command.
> gcc -shared \
> -Wl,--out-implib,${lib_name2}.dll.a,--output-def,${lib_name2}.def \
> -o ${SHARED_LIB} $(OBJS) ${LIBS}


Yes, I've noted that...

So the basic method for compile time linking is as follows.
> 1) Create the DLL(s) using the sub-programs.
> 2) Create the an object from the main-program.
> 3) Add the main object and library (DLL) to the link step
>     using the '-ldll-name' GCC option.
> 4) Add the CWD to the path, and run the executable.


Well, that way the DLL is not dynamic as it could be... What's the advantage
of using DLL's if I need link it together (except for the resulting size of
the animal, of course)?

Normally I recommend using make files for DLL's because of these
> complexities.
> And because when using the TC command line you can't create DLL's
> (modules) with multiple COBOL sources (htcobol -m s1.cob s2.cob).


That's the point. I suggest that TC should do it, using as export'ed
functions all the PROGRAM-ID's names from the Cobol sources. The result I
expect is the same as I would if I code the equivalent using
'__declspec(dllexport)' in C, if you understand me...

And I think we could emit Win32 directives to the assembly code...

Anyway, have a look and let me know what you think.
>
> David Essex


Thanks a lot for your responses.

Nilo R C Paim
Porto Alegre - RS - Brazil

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[David E. <de...@us...>]

Nilo Paim wrote:

> ... 
> Unfortunately I've no access to a Linux box now...

You are aware that to use SF CVS you will require some package which has 
SSH available, such as Putty.


> ... 
>> Basically the export/import defines, and '.def' files are auto-generated
>> by the MinGW compiler.
> 
> Well, that's the problem... a Cobol program doesn't have generated the 
> GAS directives that permits the exporting of symbols...
> 
> So, the MinGW compiler does not know what symbols to export...
> ...
> Well, I made some tests and modifications on my local copy... when I 
> call DLL's written in C or something like that it works like a charm, 
> without 'CALL-LOADLIB' extension. All my problems begins when I try to 
> call DLL's generated by TinyCobol... I'm able to find the DLL, but not 
> the sub-programs ( functions ), just because there are no functions 
> exported...
> 
> Maybe should the compiler export all PROGRAM-ID's identifiers as 
> functions names, i. e, put the '.section .drectve' and '.ascii " 
> -export:prog-id-name"' clauses on generated code?
> 
> Well, at least this is my first tough about... ;-)

First we need to isolate the problem.

What version of GCC (MinGW) are you using ?

Have you tried to compile (using the Makefile.mingw) and run the 
examples found in t25 and t33 ?
If these examples do not work, then we have a problem because they do 
work on GCC 3.x (MinGW).

Regarding the export/import defines, the TC compiler does not generate 
any Win32 directives.
The TC front end will spawn a process and let GCC worry about the details.

So if you try using 'htcobol -v -m ...' command, TC should spawn a 
process with the equivalent command.
gcc -shared \
-Wl,--out-implib,${lib_name2}.dll.a,--output-def,${lib_name2}.def \
-o ${SHARED_LIB} $(OBJS) ${LIBS}

So the basic method for compile time linking is as follows.
1) Create the DLL(s) using the sub-programs.
2) Create the an object from the main-program.
3) Add the main object and library (DLL) to the link step
    using the '-ldll-name' GCC option.
4) Add the CWD to the path, and run the executable.

Normally I recommend using make files for DLL's because of these 
complexities.
And because when using the TC command line you can't create DLL's 
(modules) with multiple COBOL sources (htcobol -m s1.cob s2.cob).

Anyway, have a look and let me know what you think.

David Essex

Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[Nilo <nil...@gm...>]

>> David, I suppose the main environment for all the development of the
>> compiler is Linux.
>> Otherwise I would like to direct my work on the use of
>> MinGW under Windows.

>Great, I'm been waiting for a TC developer with Win32 experience for
>looong time.

I hope I can help... ;-)

>Generally speaking, compiler functionality is developed on UN*X mainly
>because it easier. Later equivalent functionality (if possible) is
>developed on Win32 using MinGW.

>The development setup I use, to keep the MinGW/UN*X TC versions in sync,
>is to have two machines on a (closed) network.
>Then using samba and Win32 shares with write access, I use the same file
>system directories.

Unfortunately I've no access to a Linux box now...

>> So I've look the portions of code related to it and have made some tests.
>>
>> During these tests I've discover that I can't call a DLL written in
TinyCobol
>> from another TinyCobol program.
>>
>> Please, could you shed me some light about the way TinyCobol generates
code
>> for Cobol written DLL's using switch '-m'? It seems to me that the
generated
>> DLL doesn't export any symbols.
>> Am I right? How should I use he compiler in order to do that?

>Have a look at the samples in the test.code/t25 and t33 directories, and
>the source code in 'htglobals.c'.
>
>Basically the export/import defines, and '.def' files are auto-generated
>by the MinGW compiler.

Well, that's the problem... a Cobol program doesn't have generated the GAS
directives that permits the exporting of symbols...

So, the MinGW compiler does not know what symbols to export...

>
>On Win32 calling a sub-program (function) in a DLL is problematic.
>
>The reason being that a DLL can contain many sub-programs (functions),
>and the name of the DLL may not have any relation to the name of the
>sub-program being called.
>
>On UN*X, there are functions calls you can use that will search the
>shared library paths and load that sub-program (function).
>On Win32 (MinGW) there is no equivalent functionality (that I am aware
>of), so you have to write your own.

Well, I made some tests and modifications on my local copy... when I call
DLL's written in C or something like that it works like a charm, without
'CALL-LOADLIB' extension. All my problems begins when I try to call DLL's
generated by TinyCobol... I'm able to find the DLL, but not the sub-programs
( functions ), just because there are no functions exported...

Maybe should the compiler export all PROGRAM-ID's identifiers as functions
names, i. e, put the '.section .drectve' and '.ascii "
-export:prog-id-name"' clauses on generated code?

Well, at least this is my first tough about... ;-)

>
>On TC version 0.63, I could not find a way to create that equivalent
>functionality. So you have to first load a specific DLL using the
>'CALL-LOADLIB identifier' extension.
>
>On TC CVS, I found a way which seams to work.
>Basically it finds, loads and checks DLL's in the 'TCOB_LD_LIBRARY_PATH'
>paths for that sub-program (function).
>See 'lib/dyncall.c' for details.

I saw your code. I would like to test it more, but the problem related to
exported symbols I told you persists....

>
>Hope this helps.
>If you have any further questions do not hesitate to ask.

Thanks, my friend. I'll try not to abuse... :-D

>
>David Essex

Nilo R C Paim
Porto Alegre - RS - Brazil

[Tiny-cobol-users] TC updates (was: changes in accept ...)

[David E. <de...@us...>]

Nilo Paim wrote:

 > David Essex wrote:
>>
>> Is Nilo aware that the 'test_suite' must be run before and after the
>> changes without any errors, or change in the results ?
> 
> Yes, certainly I am.

Some information about the 'test_suite'.

It will not fully test the compiler or run-time, but it does a fair job 
of trapping many problems.

One of the things it does not do is check any CURSES based programs, as 
STDIN/STDOUT/STDERR are not displayed.
On UN*X you can use pseudo-terminals (X-Win) in combination with GDB to 
debug and test CURSES based programs.
On Win32 I'm not aware of any way to test and debug CURSES based programs.

One final note, the 'test_suite' will run on Win32, but you need the DTK 
and MSYS (if I remember correctly).
Actually, the version of Perl which came with the DTK, is the only 
version I could ever get to run properly on Win32.


> David, I suppose the main environment for all the development of the
> compiler is Linux. 
 > Otherwise I would like to direct my work on the use of
 > MinGW under Windows.

Great, I'm been waiting for a TC developer with Win32 experience for 
looong time.

Generally speaking, compiler functionality is developed on UN*X mainly 
because it easier. Later equivalent functionality (if possible) is 
developed on Win32 using MinGW.

The development setup I use, to keep the MinGW/UN*X TC versions in sync, 
is to have two machines on a (closed) network.
Then using samba and Win32 shares with write access, I use the same file 
system directories.


> So I've look the portions of code related to it and have made some tests.
> 
> During these tests I've discover that I can't call a DLL written in TinyCobol
 > from another TinyCobol program.
 >
> Please, could you shed me some light about the way TinyCobol generates code
> for Cobol written DLL's using switch '-m'? It seems to me that the generated
> DLL doesn't export any symbols. 
 > Am I right? How should I use he compiler in order to do that?

Have a look at the samples in the test.code/t25 and t33 directories, and 
the source code in 'htglobals.c'.

Basically the export/import defines, and '.def' files are auto-generated 
by the MinGW compiler.

On Win32 calling a sub-program (function) in a DLL is problematic.

The reason being that a DLL can contain many sub-programs (functions), 
and the name of the DLL may not have any relation to the name of the 
sub-program being called.

On UN*X, there are functions calls you can use that will search the 
shared library paths and load that sub-program (function).
On Win32 (MinGW) there is no equivalent functionality (that I am aware 
of), so you have to write your own.

On TC version 0.63, I could not find a way to create that equivalent 
functionality. So you have to first load a specific DLL using the 
'CALL-LOADLIB identifier' extension.

On TC CVS, I found a way which seams to work.
Basically it finds, loads and checks DLL's in the 'TCOB_LD_LIBRARY_PATH' 
paths for that sub-program (function).
See 'lib/dyncall.c' for details.

Hope this helps.
If you have any further questions do not hesitate to ask.

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

[David E. <de...@us...>]

David Essex wrote:

> Fernando Wuthstrack wrote:
> 
>> In 2006, Rildo Pragana correct a lot of bugs in the
>> ACCEPT/DISPLAY verbs. He did the necessary changes, but
>> didn't upload the sources to SourceForge CVS.
> ... 
> I have no objection to the addition of Rildo's code to TC.
> ... 
> However there is a problem.
> SF and Rildo's CVS trees are no longer in sync.

Fernando, Nilo, I nearly forgot.

Any changes you decide to make, you will also need to test on Win32 
using PDcurses and MinGW.
I do not think these changes will be a problem, but you will need to check.

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

[David E. <de...@us...>]

Andrew Cameron wrote:

 > ...
 > Perhaps after the merge a new release may be a good idea.
 >
 > Also if someone has time the fileio can be enhanced to
 > have full support for Variable IO as I never got to finish
 > that part.

Well there are too msny changes to make to TC, and not enough time.

So I will finish what I started, but after that I will not have much 
time to devote to this project.

As for a new release, well we will see.

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screenssection

[Andrew C. <apc...@so...>]

David,

I agree and think it would be great if we could merge the code from
Sourceforge and Rildo's version.

I have not had much time to do any further work on TC myself.

Perhaps after the merge a new release may be a good idea.

Also if someone has time the fileio can be enhanced to have full support for
Variable IO as I never got to finish that part.

Regards
Andrew Cameron

-----Original Message-----
From: tin...@li...
[mailto:tin...@li...] On Behalf Of David
Essex
Sent: Tuesday, January 02, 2007 2:04 PM
To: tiny-cobol-users
Subject: Re: [Tiny-cobol-users] changes in accept using
ncurses/screenssection

Fernando Wuthstrack wrote:

 > In 2006, Rildo Pragana correct a lot of bugs in the
 > ACCEPT/DISPLAY verbs. He did the necessary changes, but
 > didn't upload the sources to SourceForge CVS.

Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.


 > I have this and other changes here and I will do the
 > upload on next week, but, before this, I need verify
 > with David when I can do this, considering that it
 > also is changing the TC source code.

I have no objection to the addition of Rildo's code to TC.
And I have downloaded Rildo's code from his CVS server on several occasions.

However there is a problem.
SF and Rildo's CVS trees are no longer in sync.

This means the you can no longer merge the two sources. And if you 
could, there is no guarantee that the code will work properly, and that 
new bugs are not introduced.

In short you have to do it manually.
Rildo and I discussed merging his code to SF CVS, but due to a number of 
reasons this never got done.

In any case Rildo's changes do not fix all the problems with CURSES-IO.


 > In December/2006, more one brazilian developer was
 > joined to the project. His name is Nilo Paim and he
 > is a great guy. He work with COBOL since 1978 and
 > C since 1984. He who will make upload for the CVS.
 > Welcome Nilo and thanks for your help!

Fernando, Nilo, please wait until I complete the my changes.
I should be finished in about 2-4 weeks.


 > David, I will write soon for you, OK?

Fernando, I have some questions.

First, is Nilo ware that the 'upload' will require more that a simple 
CVS merge ?

Is Nilo aware that the 'test_suite' must be run before and after the 
changes without any errors, or change in the results ?

Finally, is the most recent version of available on Rildo's CVS server ? 
And if not where can it be found ?

David Essex



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Tin...@li...
https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

Re: [Tiny-cobol-users] changes in accept using ncurses/screen section.

[Nilo <nil...@gm...>]

>
> Fernando Wuthstrack wrote:
>
>  > In 2006, Rildo Pragana correct a lot of bugs in the
>  > ACCEPT/DISPLAY verbs. He did the necessary changes, but
>  > didn't upload the sources to SourceForge CVS.
>
> Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.
>
>
>  > I have this and other changes here and I will do the
>  > upload on next week, but, before this, I need verify
>  > with David when I can do this, considering that it
>  > also is changing the TC source code.
>
> I have no objection to the addition of Rildo's code to TC.
> And I have downloaded Rildo's code from his CVS server on several
occasions.
>
> However there is a problem.
> SF and Rildo's CVS trees are no longer in sync.
>
> This means the you can no longer merge the two sources. And if you
> could, there is no guarantee that the code will work properly, and that
> new bugs are not introduced.
>
> In short you have to do it manually.
> Rildo and I discussed merging his code to SF CVS, but due to a number of
> reasons this never got done.
>
> In any case Rildo's changes do not fix all the problems with CURSES-IO.
>
>
>  > In December/2006, more one brazilian developer was
>  > joined to the project. His name is Nilo Paim and he
>  > is a great guy. He work with COBOL since 1978 and
>  > C since 1984. He who will make upload for the CVS.
>  > Welcome Nilo and thanks for your help!
>
> Fernando, Nilo, please wait until I complete the my changes.
> I should be finished in about 2-4 weeks.

Sure I'll wait your changes. I'm studying the code right now and I don't
wanna change anything until I've gain more knowledge about the compiler.

>
>
>  > David, I will write soon for you, OK?
>
> Fernando, I have some questions.
>
> First, is Nilo ware that the 'upload' will require more that a simple
> CVS merge ?

Sure I am.

>
> Is Nilo aware that the 'test_suite' must be run before and after the
> changes without any errors, or change in the results ?

Yes, certainly I am.

>
> Finally, is the most recent version of available on Rildo's CVS server ?
> And if not where can it be found ?

I'm not sure about it. Fernando can answer these questions.

>
> David Essex
>

David, I suppose the main environment for all the development of the
compiler is Linux. Otherwise I would like to direct my work on the use of
MinGW under Windows. So I've look the portions of code related to it and
have made some tests.

During these tests I've discover that I can't call a DLL written in Tiny
Cobol from another Tiny Cobol program.

Please, could you shed me some light about the way TinyCobol generates code
for Cobol written DLL's using switch '-m'? It seems to me that the generated
DLL doesn't export any symbols. Am I right? How should I use he compiler in
order to do that?

Thanks in advance.

Nilo R C Paim
Porto Alegre - RS - Brazil

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

[David E. <de...@us...>]

Fernando Wuthstrack wrote:

 > In 2006, Rildo Pragana correct a lot of bugs in the
 > ACCEPT/DISPLAY verbs. He did the necessary changes, but
 > didn't upload the sources to SourceForge CVS.

Actually, Rildo created a new CVS branch based on TC 0.62.x, I think.


 > I have this and other changes here and I will do the
 > upload on next week, but, before this, I need verify
 > with David when I can do this, considering that it
 > also is changing the TC source code.

I have no objection to the addition of Rildo's code to TC.
And I have downloaded Rildo's code from his CVS server on several occasions.

However there is a problem.
SF and Rildo's CVS trees are no longer in sync.

This means the you can no longer merge the two sources. And if you 
could, there is no guarantee that the code will work properly, and that 
new bugs are not introduced.

In short you have to do it manually.
Rildo and I discussed merging his code to SF CVS, but due to a number of 
reasons this never got done.

In any case Rildo's changes do not fix all the problems with CURSES-IO.


 > In December/2006, more one brazilian developer was
 > joined to the project. His name is Nilo Paim and he
 > is a great guy. He work with COBOL since 1978 and
 > C since 1984. He who will make upload for the CVS.
 > Welcome Nilo and thanks for your help!

Fernando, Nilo, please wait until I complete the my changes.
I should be finished in about 2-4 weeks.


 > David, I will write soon for you, OK?

Fernando, I have some questions.

First, is Nilo ware that the 'upload' will require more that a simple 
CVS merge ?

Is Nilo aware that the 'test_suite' must be run before and after the 
changes without any errors, or change in the results ?

Finally, is the most recent version of available on Rildo's CVS server ? 
And if not where can it be found ?

David Essex

Re: [Tiny-cobol-users] changes in accept using ncurses/screenssection

[Fernando W. - I. S. I. Ltda. <fer...@in...>]

Hi David
Hi Harold

        In 2006, Rildo Pragana correct a lot of bugs in the ACCEPT/DISPLAY 
verbs. He did the necessary changes, but didn't upload the sources to 
SourceForge CVS. I have this and other changes here and I will do the upload 
on next week, but, before this, I need verify with David when I can do this, 
considering that it also is changing the TC source code.
        In December/2006, more one brazilian developer was joined to the 
project. His name is Nilo Paim and he is a great guy. He work with COBOL 
since 1978 and C since 1984. He who will make upload for the CVS. Welcome 
Nilo and thanks for your help!
        David, I will write soon for you, OK?
        Bye!

                                                                             
                Fernando Wuthstrack
                                                                             
                InfoCont Sistemas Integrados Ltda.
                                                                             
                Diretor
                                                                             
                Fone: (47) 3422-3536
----- Original Message ----- 
From: "David Essex" <de...@us...>
To: "tiny-cobol-users" <tin...@li...>
Sent: Monday, January 01, 2007 8:36 PM
Subject: Re: [Tiny-cobol-users] changes in accept using 
ncurses/screenssection


> Harold Norris wrote:
>
>> Is there any way to modify the compiler so it
> > doesn't initialize a PIC X variable with spaces.
>
> After a quick look at the code, it appears that the SCREEN and LINE/POS
> methods are coded differently.
>
> With the LINE/POS method if you use the 'UPDATE' attribute, the contents
> of variable are displayed, otherwise the screen locations are blanked.
>
> I'm not sure that this inconsistent behavior between SCREEN and LINE/POS
> methods is a good approach. Maybe the code was not finished.
>
> Anyway, I think I found a way to fix your problem.
> Following your example.
> ...
> 01 INPUT-NUMBER PIC X(14) JUST RIGHT.
> ...
> MOVE ... TO INPUT-NUMBER
> ACCEPT INPUT-NUMBER AT line 1 position 2 UPDATE
>
> All you have to do is use either groups or a combination of moves, and
> your desired effect can be achieved.
> See example in 'test.code/t26'.
>
> I still don't think leaving the contents on the screen from a previous
> 'ACCEPT/DISPLAY', when the new fields are using the same screen
> location, is correct behavior.
> So I will not change this behavior.
>
> Hope this helps.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users 

Re: [Tiny-cobol-users] changes in accept using ncurses/screens section

[David E. <de...@us...>]

Harold Norris wrote:

> Is there any way to modify the compiler so it 
 > doesn't initialize a PIC X variable with spaces.

After a quick look at the code, it appears that the SCREEN and LINE/POS 
methods are coded differently.

With the LINE/POS method if you use the 'UPDATE' attribute, the contents 
of variable are displayed, otherwise the screen locations are blanked.

I'm not sure that this inconsistent behavior between SCREEN and LINE/POS 
methods is a good approach. Maybe the code was not finished.

Anyway, I think I found a way to fix your problem.
Following your example.
...
01 INPUT-NUMBER PIC X(14) JUST RIGHT.
...
MOVE ... TO INPUT-NUMBER
ACCEPT INPUT-NUMBER AT line 1 position 2 UPDATE

All you have to do is use either groups or a combination of moves, and 
your desired effect can be achieved.
See example in 'test.code/t26'.

I still don't think leaving the contents on the screen from a previous 
'ACCEPT/DISPLAY', when the new fields are using the same screen 
location, is correct behavior.
So I will not change this behavior.

Hope this helps.

Re: [Tiny-cobol-users] changes in accept using ncurses/screen section.

[David E. <de...@us...>]

Harold Norris wrote:

 > I am accepting data via a 14 character variable
 > "INPUT-NUMBER PIC X(14) JUST RIGHT".

I will assume that you are using some thing similar to the example below.

...
01 INPUT-NUMBER PIC X(14) JUST RIGHT.
...
ACCEPT INPUT-NUMBER AT line 1 position 2.
...

 > This same process using tc version .58 apparently
 > does not initialize the variable with spaces as the
 > previous data is not overwritten.

I do not think that the input variable should be blanked. The current 
contents of the variable should be displayed.

In my view this is a bug. So unless some one objects, for some valid 
reason, I will try to change the code.

However, I don't think leaving the contents on the screen from a 
previous 'ACCEPT/DISPLAY', when the new fields are using the same screen 
location, is correct behavior.

There have been some modifications to the SCREEN-IO sources, between 
version 0.58 - 0.63.
I could be wrong, but I think what may have been happening in the past 
was unexpected behavior, and not what the programmer intended.

 > ...
 > Is there any way to modify the compiler so it doesn't
 > initialize a PIC X variable with spaces.

Actually, it is the RTL doing the work.

Have you tied using 'ACCEPT/DISPLAY screen-n'. It seams to work better, 
and this method will not blank fill the input-variable. The contents of 
variable will be displayed.

Using either groups or a combination of moves, your desired effect could 
be achieved.
See examples in 'test.code/t23' or 'test.code/t26'.

Hope this helps.

Re: [Tiny-cobol-users] Tiny-cobol-users Digest, Vol 7, Issue 9

[Pam & H. N. <phn...@ve...>]

Hi David,

I am accepting data via a 14 character variable "INPUT-NUMBER PIC X(14) 
JUST RIGHT".

This same process using tc version .58 apparently does not initialize 
the variable with spaces as the previous data is not overwritten.

As my customer got use to the behavior of the earlier version, he wants 
it to work again.  It doesn't bother me (or my customer) to have a 
unique compiler.

Is there any way to modify the compiler so it doesn't initialize a PIC X 
variable with spaces.

Thanks

Harold


> Subject:
> [Tiny-cobol-users] changes in accept using ncurses/screen section.
> From:
> Pam & Harold Norris <phn...@ve...>
> Date:
> Sat, 30 Dec 2006 19:51:08 -0500
> To:
> tin...@li...
>
> To:
> tin...@li...
>
>
> Hi all,
>
> I have been a firm believer in tc for years and it hasn't failed me 
> yet.  I am, however, having a time with changes which went into effect 
> between versions .58 and .62/.63
>
> I am accepting data on the screen using ACCEPT ON EXCEPTION.  
> According to what I saw in screenio.c, this means that the data is 
> being accepted using the SCREEN mode.  What the problem is, is: if 
> data is displayed on the screen at line 1 position 5 and I accept a 14 
> character variable at line 1 position 1, the data located at position 
> is instantly erased.  Using the same accept commands with tc version 
> .58, the existing data stays put until you input NEWdata at its location.
>
> Is there any way to fix this, either by modifying tc or my program??
>
> Thanks for the help
>
> Harold Norris
>
>
> If I understand your query correctly, the problem is that the 14 
> variable at line 1 position 1 gets initialized with blanks, assuming 
> it is an alphanumeric identifier.
>
> First of all are you using 'ACCEPT screen-n ...' or 'ACCEPT 
> identifier-n AT LINE/POS ...' ?
>
> Second is this expected behavior as found with other compilers, or 
> defined on some COBOL standard ?
>
> And finally, I don't think the behavior you are suggesting would work 
> for numeric variables, as these should display from RIGHT to LEFT.
> It is not what TC currently does, but it is the behavior on I*M 
> mainframes.
>
> In any case using group variables will not work, as the variable gets 
> initialized with blanks.
> And I don't see an option that disables the initialization.
> Maybe the variable should not get initialized with blanks (zeros), but 
> let the user do so, or not (risky).
>
>
>
>