tiny-cobol-users

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David,
This now works to create a static binary, but how do I create a dynamic
loading system?
When I change the -c to -x  on the compile stage, I get the problem again.
What do I need to put in on the compile line? (htcobol ......-x or
-m.....XYZ.COB)
Thanks again.
Reg.

David Essex-2 wrote:
> 
> Reg wrote:
>  > ... followed your suggestion:-
>  > #htcobol -v -c /TinyCat/DEGRABBER.COB
>  > as -o DEGRABBER.o DEGRABBER.s
>  > #gcc -o DEGRABBER DEGRABBER.o
>  >    -L/TinyCobol/development/lib -lhtcobol
>  >    -ldb -lncurses -ldl -lm
> 
> No 'undefined reference ...' linkage error messages.
> Then one can assume that the correct version of the TC RTL was used.
> 
>  > #ldd DEGRABBER
>  > linux-gate.so.1 =>  ... (0x00110000)
>  > libdb-4.3.so => /lib/libdb-4.3.so (0x05479000)
>  > libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000)
>  > libdl.so.2 => /lib/libdl.so.2 (0x00db4000)
>  > libm.so.6 => /lib/libm.so.6 (0x00d8b000)
>  > libc.so.6 => /lib/libc.so.6 (0x00c49000)
>  > libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000)
>  > .., /lib/ld-linux.so.2 (0x00c2c000)
>  >
>  > I'm not sure what this is telling me, except that it seems
>  > to want libdb-4.3.so and I config'd htcobol without the db
>  > option at all, never mind db4, so it should have defaulted to 1.
> 
> The 'ldd' command shows the shared libraries dependencies and their
> location (if found), for binary DEGRABBER.
> 
> Note that 'ldd' did not list '-lhtcobol' (libhtcobol.a), or any static
> library (archive) used in the link.
> 
> In this case 'DEGRABBER' was linked with '/lib/libdb-4.3.so', meaning
> BDB 4.3. But the compile command used '-ldb', meaning that 'libdb.so' is
> a soft link to some other library or link.
> This is not a problem as the BDB 1.85 API is included in version 4.3.
> 
>  > Do you think I should clean the computer off and re-install
>  > from scratch, as I have 4 htcobol implementations on it at
>  > present?
> 
> No UN*X is NOT MS windows, and a clean re-install should not be necessary.
> Well, unless you corrupted the RPM database (BDB).
> But the RPM utilities will usually prevent any one from doing so.
> 
> You can have as many versions of TC installed as you wish.
> Managing this situation however can be problematic.
> 
> How to remove TC from your system depends on how it was installed.
> If for example an RPM (DEB ...) was used, use the RPM utilities to 
> un-install TC.
> If installed from source (... make install), then locate (whereis, find) 
> and remove the binaries (htcobol, htcobrun), library and config directory.
> If both methods were used, this can be problematic as the integrity of 
> the RPM database needs to be maintained.
> Maybe if both removal methods were used, RPM first.
> 
> Personally, I usually have two versions (sometimes more) on my system.
> The current release, and the CVS version.
> 
> Since I don't run any production programs, I usually do not install TC.
> If I do, I rename the binaries, library and config directory, to ensure 
> no conflicts.
> I prefer to work with TC from some '/home/user/somepath' directory and 
> set the environment variables (PATH, TCOB_OPTIONS_PATH, 
> TCOB_RTCONFIG_PATH) make files as required.
> 
> Anyway, hope this helps.
> 
> Cheers.
> 
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14301033.html
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:
 > ... followed your suggestion:-
 > #htcobol -v -c /TinyCat/DEGRABBER.COB
 > as -o DEGRABBER.o DEGRABBER.s
 > #gcc -o DEGRABBER DEGRABBER.o
 >    -L/TinyCobol/development/lib -lhtcobol
 >    -ldb -lncurses -ldl -lm

No 'undefined reference ...' linkage error messages.
Then one can assume that the correct version of the TC RTL was used.

 > #ldd DEGRABBER
 > linux-gate.so.1 =>  ... (0x00110000)
 > libdb-4.3.so => /lib/libdb-4.3.so (0x05479000)
 > libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000)
 > libdl.so.2 => /lib/libdl.so.2 (0x00db4000)
 > libm.so.6 => /lib/libm.so.6 (0x00d8b000)
 > libc.so.6 => /lib/libc.so.6 (0x00c49000)
 > libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000)
 > .., /lib/ld-linux.so.2 (0x00c2c000)
 >
 > I'm not sure what this is telling me, except that it seems
 > to want libdb-4.3.so and I config'd htcobol without the db
 > option at all, never mind db4, so it should have defaulted to 1.

The 'ldd' command shows the shared libraries dependencies and their
location (if found), for binary DEGRABBER.

Note that 'ldd' did not list '-lhtcobol' (libhtcobol.a), or any static
library (archive) used in the link.

In this case 'DEGRABBER' was linked with '/lib/libdb-4.3.so', meaning
BDB 4.3. But the compile command used '-ldb', meaning that 'libdb.so' is
a soft link to some other library or link.
This is not a problem as the BDB 1.85 API is included in version 4.3.

 > Do you think I should clean the computer off and re-install
 > from scratch, as I have 4 htcobol implementations on it at
 > present?

No UN*X is NOT MS windows, and a clean re-install should not be necessary.
Well, unless you corrupted the RPM database (BDB).
But the RPM utilities will usually prevent any one from doing so.

You can have as many versions of TC installed as you wish.
Managing this situation however can be problematic.

How to remove TC from your system depends on how it was installed.
If for example an RPM (DEB ...) was used, use the RPM utilities to 
un-install TC.
If installed from source (... make install), then locate (whereis, find) 
and remove the binaries (htcobol, htcobrun), library and config directory.
If both methods were used, this can be problematic as the integrity of 
the RPM database needs to be maintained.
Maybe if both removal methods were used, RPM first.

Personally, I usually have two versions (sometimes more) on my system.
The current release, and the CVS version.

Since I don't run any production programs, I usually do not install TC.
If I do, I rename the binaries, library and config directory, to ensure 
no conflicts.
I prefer to work with TC from some '/home/user/somepath' directory and 
set the environment variables (PATH, TCOB_OPTIONS_PATH, 
TCOB_RTCONFIG_PATH) make files as required.

Anyway, hope this helps.

Cheers.

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David, followed your suggestion:-
[root@Appserver development]# htcobol -v -c /TinyCat/DEGRABBER.COBas -o
DEGRABBER.o DEGRABBER.s
[root@Appserver development]# gcc -o DEGRABBER DEGRABBER.o
-L/TinyCobol/development/lib -lhtcobol -ldb -lncurses -ldl -lm
[root@Appserver development]# ldd DEGRABBER
        linux-gate.so.1 =>  (0x00110000)
        libdb-4.3.so => /lib/libdb-4.3.so (0x05479000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000)
        libdl.so.2 => /lib/libdl.so.2 (0x00db4000)
        libm.so.6 => /lib/libm.so.6 (0x00d8b000)
        libc.so.6 => /lib/libc.so.6 (0x00c49000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000)
        /lib/ld-linux.so.2 (0x00c2c000)
[root@Appserver development]# 

I'm not sure what this is telling me, except that it seems to want
libdb-4.3.so and I config'd htcobol without the db option at all, never mind
db4, so it should have defaulted to 1.
Do you think I should clean the computer off and reinstall from scratch, as
I have 4 htcobol implementations on it at present?
Regs.
Reg.
-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14286155.html
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

[Tiny-cobol-users] Tiny to tcl compile problem.

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

I borrowed liberally from Rildo's test program  tgui01 and associated files. I 
copied tgui02.c and renamed it bridge.c
The only difference in the two files is 
53c53
< int testgui02(char *data, int *size, char *scriptn) {
---
> int bridge(char *data, int *size, char *scriptn) {

The reference in the COBOL program is 

           CALL "bridge" USING SITE-INFO SITE-INFO-SIZE SCREEN-NAME

The script that serves the purpose of a Makefile reads:
------------------------------
htcobol -c  -P -F  -I. led003.cbl
gcc -g -I/usr/local/include  bridge.o -c bridge.c
gcc -g -o led003 led003.o bridge.o    -lhtcobol -lm  -ltcl -ltk
-----------------------------------------

The error message I get is
-----------------------------------
bridge.c: In function 'bridge':
bridge.c:58: warning: incompatible implicit declaration of built-in 
function 'memmove'
bridge.c:75: warning: assignment discards qualifiers from pointer target type
bridge.c:77: warning: incompatible implicit declaration of built-in 
function 'strlen'
gcc: bridge.o: linker input file unused because linking not done
-------------------------------------

Can anyone show me the error of my ways?

John Culleton

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

 > As you suspected, the following:-
 >
 > #htcobol -v -x /TinyCat/DEGRABBER.COB
 > as -o DEGRABBER.o DEGRABBER.s
 > gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol
 >  -ldl -ldb -lncurses -lm
 > DEGRABBER.o: In function `DEGRABBER':
 > DEGRABBER.COB:(.text+0x662):
 >  undefined reference to `tcob_read_next_seq'
 > ...
 > collect2: ld returned 1 exit status

Since there is no error message '/usr/bin/ld: cannot find -lhtcobol',
then it must be another version of the TC RTL, not version 0.63.87.

Check the 'develoment/lib' directory to see if the RTL compiled properly
(check for a file called libhtcobol.a).
If the library file exists, run the following, manually.

#htcobol -v -c /TinyCat/DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
#gcc -o DEGRABBER DEGRABBER.o -L/somepath/development/lib -lhtcobol \
   -ldb -lncurses -ldl -lm

Here the 'somepath' is the location where the TC source code is located.

If the compilation succeded, check that all libraries are found.

#ldd DEGRABBER

 > ...
 > Sorry, last two lines should have read:-
 > find / -name db1 -print
 > /usr/include/db1
 >
 > i.e. db1 is installed, and so is db4
 > For some reason, the linker cannot find db1 (or db4 if it is
 > substituted).
 > The htcobol config had no entry for --with-libdb=
 > Could it be that the OS is Fedora rather than RedHat?
 > Just downloaded the RPM, didn't compile from source for
 > the development version.

All RPM based sytems have multiple versions of BDB installed.
They also use soft links, making it difficult to determine which library 
is actually used when '-ldb' is used in a link step.

TC uses the BDB 1.85 API, which is supported in all versions of BDB, up 
to (and including) 4x (4.4 I think).

In any case the 'configure' script checks what is installed and if it 
works.
So if the 'configure' step worked, don't worry about it for the time being.

Hope this helps.

Cheers

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Sorry, last two lines should have read:-
find / -name db1 -print
/usr/include/db1

i.e. db1 is installed, and so is db4
For some reason, the linker cannot find db1 (or db4 if it is substituted).
The htcobol config had no entry for --with-libdb=
Could it be that the OS is Fedora rather than RedHat? Just downloaded the
RPM, didn't compile from source for the development version.
Regs,
Reg.


Reg wrote:
> 
> 
> Hi David, 
> As you suspected, the following:-
> 
> [root@Appserver TinyCat]# htcobol -v -x /TinyCat/DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol -ldl -ldb
> -lncurses -lm  
> DEGRABBER.o: In function `DEGRABBER':
> DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq'
> DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx'
> DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq'
> collect2: ld returned 1 exit status
> [root@Appserver TinyCat]# as -o DEGRABBER.o DEGRABBER.s
> Assembler messages:
> Error: can't open DEGRABBER.s for reading: No such file or directory
> [root@Appserver TinyCat]# htcobol -v -c /TinyCat/DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib
> -lhtcobol -ldb1 -lncurses -ldl -lm
> /usr/bin/ld: cannot find -ldb1
> collect2: ld returned 1 exit status
> [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib
> -lhtcobol -lncurses -ldl -lm -ldb1
> /usr/bin/ld: cannot find -ldb1
> collect2: ld returned 1 exit status
> [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib
> -lhtcobol -lncurses -ldl -lm 
> DEGRABBER.o: In function `DEGRABBER':
> DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq'
> DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx'
> DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq'
> collect2: ld returned 1 exit status
> [root@Appserver TinyCat]# find / -name db1 -print
> [root@Appserver TinyCat]# 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14211946
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David, 
As you suspected, the following:-

[root@Appserver TinyCat]# htcobol -v -x /TinyCat/DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol -ldl -ldb -lncurses
-lm  
DEGRABBER.o: In function `DEGRABBER':
DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq'
DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx'
DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq'
collect2: ld returned 1 exit status
[root@Appserver TinyCat]# as -o DEGRABBER.o DEGRABBER.s
Assembler messages:
Error: can't open DEGRABBER.s for reading: No such file or directory
[root@Appserver TinyCat]# htcobol -v -c /TinyCat/DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
[root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol
-ldb1 -lncurses -ldl -lm
/usr/bin/ld: cannot find -ldb1
collect2: ld returned 1 exit status
[root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol
-lncurses -ldl -lm -ldb1
/usr/bin/ld: cannot find -ldb1
collect2: ld returned 1 exit status
[root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol
-lncurses -ldl -lm 
DEGRABBER.o: In function `DEGRABBER':
DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq'
DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx'
DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq'
collect2: ld returned 1 exit status
[root@Appserver TinyCat]# find / -name db1 -print
[root@Appserver TinyCat]# 
-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14210829
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

 > Compilation worked for option -m but using option -x got:-
 >
 > # htcobol -x /TinyCat/DEGRABBER.COB
 > DEGRABBER.o: In function `DEGRABBER':
 > DEGRABBER.COB:(.text+0x662):
 >   undefined reference to `tcob_read_next_seq'
 > DEGRABBER.COB:(.text+0xa31):
 >   undefined reference to `tcob_write_idx'
 > DEGRABBER.COB:(.text+0xd40):
 >   undefined reference to `tcob_read_next_seq'
 > collect2: ld returned 1 exit status
 >
 > These are references to index sequential read, write and read next.
 > Any ideas?

This is a linkage problem.

The module creation option '-m' would not produce any errors because the 
linkage is done at run time.

For some reason, the above functions were not found in the TC RTL, or 
the TC library 'libhtcobol.a' was not found in the library paths.

I suspect that the TC RT library 'libhtcobol.a' was not found.
To confirm that the path is the problem, add the verbose option '-v' to 
the command line.

Example:
$htcobol -v -x t71202a.cob
as -o t71202a.o t71202a.s
gcc -o t71202a t71202a.o -L/usr/lib -lhtcobol -ldb1 -lncurses -ldl -lm

Or you could run the commands individually.

Example:
$htcobol -v -c t71202a.cob
as -o t71202a.o t71202a.s
$gcc -o t71202a t71202a.o -L/usr/lib -lhtcobol -ldb1 -lncurses -ldl -lm

Hope this helps.

Cheers

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David,
Compilation worked for option -m but using option -x got:-

[root@Appserver development]# htcobol -x /TinyCat/DEGRABBER.COB
DEGRABBER.o: In function `DEGRABBER':
DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq'
DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx'
DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq'
collect2: ld returned 1 exit status
[root@Appserver development]#

These are references to index sequential read, write and read next.
Any ideas?
Regards,
Reg.

Reg wrote:
> 
> Hi David,
> Have at last found some time, downloaded 0.63.87 and installed,
> compilation worked!
> Haven't got any further than that for the moment, just thought I would let
> you know.
> Will try out on some bigger programs soon.
> Thanks for your efforts.
> Regards,
> Reg.
> 
> David Essex-2 wrote:
>> 
>> Reg wrote:
>> 
>>  > David, Please accept my apologies for
>>  > not following up on this yet.
>>  > I simply cannot find the time at the moment,
>>  > but expect to get back to it in about 2 weeks.
>> 
>> No rush.
>> 
>> Please use the latest CVS version, currently at 0.63.83, as it should be
>> more stable.
>> 
>> 
>> Cheers
>> 
>> 
>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Tin...@li...
>> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14192838
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David,
Have at last found some time, downloaded 0.63.87 and installed, compilation
worked!
Haven't got any further than that for the moment, just thought I would let
you know.
Will try out on some bigger programs soon.
Thanks for your efforts.
Regards,
Reg.

David Essex-2 wrote:
> 
> Reg wrote:
> 
>  > David, Please accept my apologies for
>  > not following up on this yet.
>  > I simply cannot find the time at the moment,
>  > but expect to get back to it in about 2 weeks.
> 
> No rush.
> 
> Please use the latest CVS version, currently at 0.63.83, as it should be
> more stable.
> 
> 
> Cheers
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14156953
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Qualification of key names.

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

John Culleton wrote:

 > The followig code seems to work with OC but not with Tiny:
 >
 > SELECT INFILE ASSIGN TO "BOK001"
 >  ORGANIZATION IS INDEXED
 >  ACCESS IS SEQUENTIAL
 >  RECORD KEY IS ISBN
 >  OF INREC
 >  ALTERNATE RECORD KEY IS SHORTNAME
 >  OF INREC
 >  WITH DUPLICATES.
 >
 > If I remove the "OF INREC" phrases then it compiles OK,
 > but then I can't use "MOVE CORRESPONDING" in the
 > PROCEDURE  DIVISION which is a pain.

This is known problem (bug) with the TC grammar, with no easy solution.

I will put this on the TO DO list.

Cheers.

Re: [Tiny-cobol-users] Functions

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

John Culleton wrote:

 > David Essex wrote:
 >
 >> John Culleton wrote:
 >>> In recent versions of COBOL the functions INTEGER-OF-DATE,
 >>> INTEGER-OF-DAY, DATE-OF-INTEGER and DAY-OF INTEGER
 >>> have apparently been added.
 >>> ...
 >>> Are they in Tiny?
 >> ...
 >> Yes, these functions are available for TC.
 >> See example in 'test.code/t35' directory.
 >
 > Very good. However someone on the internet has suggested
 > code the includes the line:
 >
 > move function current-date (1:8) to today
 >
 > which line blows up on the colon.
 > I assume that the purpose is to edit the string to the first
 > 8 digits, e.g,  ccyymmdd.

Yes, it's called 'reference modification'.

 > Both Tiny and Open blow up on the colon.

TC does not currently support 'reference modification' when used in
conjuction with 'intrinsic functions'.

 > I can work around it, but is there any similar editing of
 > function current-date in either?

A simple work around would be as follows.

move function current-date to today-1
move today-1 (1:8) to today

Cheers.

[Tiny-cobol-users] Qualification of key names.

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

The followig code seems to work with OC but not with Tiny:

000170       SELECT INFILE ASSIGN TO "BOK001"
                     ORGANIZATION IS INDEXED
                    ACCESS IS SEQUENTIAL
                    RECORD KEY IS ISBN
                    OF INREC
                    ALTERNATE RECORD KEY IS SHORTNAME
                    OF INREC
                    WITH DUPLICATES. 

If I remove the "OF INREC" phrases then it compiles OK, but then I can't use 
"MOVE CORRESPONDING" in the PROCEDURE  DIVISION which is a pain. 
-- 
John Culleton

Re: [Tiny-cobol-users] Functions

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

On Wednesday 21 November 2007 09:29:09 pm David Essex wrote:
> John Culleton wrote:
>  > In recent versions of COBOL the functions INTEGER-OF-DATE,
>  > INTEGER-OF-DAY, DATE-OF-INTEGER and DAY-OF INTEGER
>  > have apparently been added.
>  > My latest text is date 2000 and it does not describe
>  > them in any detail.
>  >
>  > Are they in Tiny?
>  > ...
>  > If they exist what do the appropriate sending/receiving
>  > fields PIC terms look like?
>
> Yes, these functions are available for TC.
>
> See example in 'test.code/t35' directory.
>
> Cheers
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

Very good. However someone on the internet has suggested code the includes the 
line:

  move function current-date (1:8) to today

which line blows up on the colon.  I assume that the purpose is to edit the 
string to the first 8 digits, e.g,  ccyymmdd.   Both Tiny and Open blow up on 
the colon.  I can work around it, but is there any similar editing of 
function current-date  in either?




-- 
John Culleton

Re: [Tiny-cobol-users] Functions

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

John Culleton wrote:

 > In recent versions of COBOL the functions INTEGER-OF-DATE,
 > INTEGER-OF-DAY, DATE-OF-INTEGER and DAY-OF INTEGER
 > have apparently been added.
 > My latest text is date 2000 and it does not describe
 > them in any detail.
 >
 > Are they in Tiny?
 > ...
 > If they exist what do the appropriate sending/receiving
 > fields PIC terms look like?

Yes, these functions are available for TC.

See example in 'test.code/t35' directory.

Cheers

[Tiny-cobol-users] Functions

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

In recent versions of COBOL the functions INTEGER-OF-DATE, INTEGER-OF-DAY,  
DATE-OF-INTEGER and DAY-OF INTEGER have apparently been added.  My latest 
text is date 2000 and it does not describe them in any detail. 

Are they in Tiny?

Are they in Open COBOL? 

If they exist what do the appropriate sending/receiving fields PIC terms look 
like? 
-- 
John Culleton

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

 > David, Please accept my apologies for
 > not following up on this yet.
 > I simply cannot find the time at the moment,
 > but expect to get back to it in about 2 weeks.

No rush.

Please use the latest CVS version, currently at 0.63.83, as it should be
more stable.


Cheers

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

David, Please accept my apologies for not following up on this yet.
I simply cannot find the time at the moment, but expect to get back to it in
about 2 weeks.
Regards,
R.

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a13452878
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David,
Just something I vaguely remember about more recent gcc returning a
different OK response to older versions, but probably nothing to do with
this problem.....
Anyway, will try your new version and suggestion when I get some free time -
eventually.
Thanks for your efforts.
Regards,
Reg.


David Essex-2 wrote:
> 
> Reg wrote:
> 
>> Maybe take a look at my message of September 6th.?
> 
> Not sure to what you are specifically reffering.
> 
> Anyway, using Valgrind and with Roger's help, I uploaded some memory bug 
> fixes.
> And hopefully, I did not introduce any new bugs to TC CVS (0.63.79).
> 
> If the CVS version does not fix the problem you are encountering, then 
> the only thing I can suggest is to post a Valgrind trace.
> 
> Example:
> #valgrind --leak-check=full htcobol -c -P -I. GCMMSTMN.COB  2>&1 | 
> GCMMSTMN.trace.txt
> 
> Cheers
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a13188743
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

> Maybe take a look at my message of September 6th.?

Not sure to what you are specifically reffering.

Anyway, using Valgrind and with Roger's help, I uploaded some memory bug 
fixes.
And hopefully, I did not introduce any new bugs to TC CVS (0.63.79).

If the CVS version does not fix the problem you are encountering, then 
the only thing I can suggest is to post a Valgrind trace.

Example:
#valgrind --leak-check=full htcobol -c -P -I. GCMMSTMN.COB  2>&1 | 
GCMMSTMN.trace.txt

Cheers

Re: [Tiny-cobol-users] Segmentation Fault

[Reg <re...@ri...>]

Hi David,
Maybe take a look at my message of September 6th.?
Regards,
Reg.

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a13111175
Sent from the tiny-cobol-users mailing list archive at Nabble.com.

Re: [Tiny-cobol-users] Segmentation Fault

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

Roger While wrote:
  > ...
  > Easiest way to find out what is going on is to install
  > valgrind (http://valgrind.org)
  > ...
  > Note to David - I occasionally do this in OC for
  > the OC test suite and the ANSI85 test suite
  > (For compiles AND execution).

Thanks for the tip, Roger.

I've used Valgrind on 'htcobol' and found a memory over-write due to an
allocation size error.

But other than that error, it is reporting memory errors on what appears 
to be valid code.

Re: [Tiny-cobol-users] Sample CGI program using TC

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

John, I have never used Fedora, so I can't help much in that respect.

The only one TC specific issue I can think off hand.
There have been reports of problems with TC and GCC 4x.
I haven't run any tests using TC and GCC 4x.

The problems you are encountering are common in UN*X, and particularly 
Linux. That is that you have too many variations of the same thing.

The result of this is that there no guarantee that a binary from one 
distribution will run on another.

The approach that I would take is to build and debug TC, and your 
applications on the system you plan to deploy it.
This is not as difficult as it sound, but it would require some
work space (home directory) on the remote system.
Once the system specific issues have been resolved, then I would try to 
resolve paths specific issues by running the application on the web server.


John Culleton wrote:
 > ...
 > This helps for local use on my Slack linux system. Thanks much.
 > But my (rented) remote site is on Fedora Linux
 > and the cobol part of your sample app errors off.
 > I tried putting htcobrun in the remote cgi-bin but
 > it still errors off.

What kind of error message are you getting in the apache log files
('log/apache').

 > I made both htcobrun and the app program 777 (executable)
 > for test purposes.
 > I don't have access to /usr/local/bin remotely.
 >
 > Three possilbilities, all of which may be true:
 > 1. htcobrun needs to be recompiled for the remote site on
 > a Fedora system.
 > 2. The program proper needs to be recompiled on a Fedora
 > system.
 > 3. The program is looking for htcobrun elsewhere and not
 > finding it in the cgi-bin directory.
 >
 > Any idea which of these are true?
 > I hate to go through the labor of setting up Fedora and
 > recompiling everything if in fact it still isn't going
 > to work.

I do not think running a parallel system is a good idea. Way too much to 
try to keep it in sync.


 > Assuming for the moment that the app program can't find
 > the runtime system, how tough would it be to modify the
 > compiler so that the compiled program looks in the current
 > directory for the runtime?

It is just a question of paths and user IDs.

The TC RTL will need to be installed in a location where the system 
run-time linker can find it (ex: 'usr/lib' ...).

The applications are shared libraries so you will need to set the proper 
environment variables, so that the TC run-time can find it.

Example:
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export TCOB_LD_LIBRARY_PATH=.

As to 'htcobrun', you still have to set the environment variables and 
the name of the sub-program to call.
You could use a generic shell program as a front end.

Example:
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export TCOB_LD_LIBRARY_PATH=somepath
exec /fullpath/htcobrun $@

Note that I'm not sure that this is considered good practice, from a 
security standpoint.

Also note that you could write a COBOL program as a replacement for both 
'htcobrun' and the shell script. This could be installed it in the 
'cgi-bin' directory.
The advantage of this method is that any sub-program can be run using a 
dynamic call.

Example:
CALL identifier-1 [ USING ... ].

 > There is of course always Perl, php or javascript :<).
 > But my native lannguage is COBOL. And the app will ultimately
 > be large, G/L plus inventory plus ....

Well you could use a combination of languages.
For example Perl to display the HTML pages, and COBOL to read/write the 
data.
Use some CSS to make it look real prudy (pretty) !

Anyway, hope this helps.

Re: [Tiny-cobol-users] Sample CGI program using TC (was: CGI.BIN use)

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

On Saturday 29 September 2007 01:27:37 am David Essex wrote:
> John Culleton wrote:
>  > Has anyone used Tiny to generate a cgi-bin program?
>  > If so, what did you use on the html side, get, post,
>  > php, javascript, other?
>
> Yes, TC can be used to create a CGI program using basic ACCEPT and
> DISPLAY statements.
> One of the ways to do so, would be as follows.
>
> * Parse the query string
> ACCEPT identifier-1 FROM ENVIRONMENT-VARIABLE "QUERY_STRING".
> ...
> UNSTRING identifier-1 DELIMITED BY '?' INTO ...
> ...
> UNSTRING identifier-2 DELIMITED BY '=' INTO ...
> ...
> * If a valid query, find and display data in HTML
> * format to standard output
> DISPLAY 'Content-type: text/html' WS-CR WS-LF WS-CR
> DISPLAY '<!DOCTYPE html PUBLIC ... '
> ...
> DISPLAY '<html><HEAD><title> ...'
> ...
> DISPLAY '</body> </HTML>'
>
> I have enclosed a sample application for a NA area code lookup, using
> both a Perl and COBOL programs.
>
> Note that the NA area code database file (1) is NOT included, so no area
> code data is displayed.
>
> Hope this helps.
>
> 1) Area codes
> http://www.bennetyee.org/ucsd-pages/area.html

This helps for local use on my Slack linux system. Thanks much. But my 
(rented) remote site is on Fedora Linux and the cobol part of your sample app 
errors off. I tried putting htcobrun in the remote cgi-bin but it still 
errors off. I made both htcobrun and the app program 777 (executable) for 
test purposes.   I don't have access to /usr/local/bin remotely. 

Three possilbilities, all of which may be true:
1. htcobrun needs to be recompiled for the remote site on a Fedora system.
2. The program proper needs to be recompiled on a Fedora system.
3. The program is looking for htcobrun elsewhere and not finding it in the 
cgi-bin directory.  

Any idea which of these are true?  I hate to go through the labor of setting 
up Fedora and recompiling everything if in fact it still isn't going to work.

Assuming for the moment that the app program can't find the runtime system,
how tough would it be to modify the compiler so that the compiled program 
looks in the current directory for the runtime? 

There is of course always Perl, php or javascript :<). But my native lannguage 
is COBOL. And the app will ultimately be large, G/L plus inventory plus .... 
-- 
John Culleton

Re: [Tiny-cobol-users] Segmentation Fault

[Roger W. <si...@si...>]

<snip>
*** glibc detected *** htcobol: malloc(): memory corruption: 0x091c9278 ***
======= Backtrace: =========
/lib/libc.so.6[0xcb013c]
</snip>

Easiest way to find out what is going on is to install
valgrind (http://valgrind.org)
Grab the latest source, do the usual
./configure --prefix=/usr; make install

Then simply prefix your compile command with "valgrind" -
valgrind htcobol -z -m -C -I . GCMMSTMN.COB

Note to David - I occasionally do this in OC for
the OC test suite and the ANSI85 test suite
(For compiles AND execution).

Roger