tiny-cobol-users

[Tiny-cobol-users] mistake make install compiler

[Soporte S. <sop...@ui...>]

Friends, 

 

Trying make compiler, display the next Messenger:

 

gcc -I/usr/include -I/usr/local/include -I../lib -I../ -c scan.c

scan.c:1061: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'YY_PROTO'

scan.l:744: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'YY_PROTO'

make: *** [scan.o] Error 1

 

And it doesn't create the file "htcobol", the way I can't compile, please
can you help me to resolve this problem.

 

I am using a Linux suse 10.0.x whit a language in spanish.

 

While I was executing (configure) it produce the next file:

 

This file contains any messages produced by compilers while

running configure, to aid debugging if configure makes a mistake.

 

configure:641: checking host system type

configure:662: checking target system type

configure:680: checking build system type

configure:802: checking for gcc

configure:840: checking for as

configure:883: checking for a BSD compatible install

configure:936: checking whether ln -s works

configure:957: checking whether make sets ${MAKE}

configure:988: checking for ranlib

configure:1018: checking for ar

configure:1053: checking for flex

configure:1106: checking for bison

configure:1150: checking for expand

configure:1188: checking how to run the C preprocessor

configure:1209: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1268: checking for ANSI C header files

configure:1281: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1348: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure: In function 'main':

configure:1343: warning: incompatible implicit declaration of built-in
function 'exit'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1377: checking for stdio.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for alloca.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for errno.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for fcntl.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for limits.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/time.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for unistd.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for malloc.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for stdlib.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for string.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for strings.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for utime.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for ctype.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/stat.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/types.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for getopt.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1428: checking for working const

configure:1482: gcc -c   conftest.c 1>&5

configure:1503: checking for off_t

configure:1536: checking for size_t

configure:1569: checking whether struct tm is in sys/time.h or time.h

configure:1582: gcc -c   conftest.c 1>&5

configure:1605: checking for 8-bit clean memcmp

configure:1623: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure: In function 'main':

configure:1618: warning: incompatible implicit declaration of built-in
function 'exit'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1641: checking for vprintf

configure:1669: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1653: warning: conflicting types for built-in function 'vprintf'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strcspn

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strcspn'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strdup

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strdup'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strerror

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strspn

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strspn'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for putenv

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:2020: checking for asin in -lm

configure:2039: gcc -o conftest    conftest.c -lm  -L/usr/lib
-L/usr/local/lib 1>&5

configure:2032: warning: conflicting types for built-in function 'asin'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.so when searching for -lm

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.a when searching for -lm

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:2225: checking for db_185.h

configure:2235: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:2741: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
-ldb 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:3022: checking for ncurses.h

configure:3032: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:3061: checking for addch in -lncurses

configure:3080: gcc -o conftest    conftest.c -lncurses  -L/usr/lib
-L/usr/local/lib -ldb 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.so when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.a when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:3117: checking for color_set in -lncurses

configure:3130: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
-lncurses 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.so when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.a when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

 

I didn't have problems installing the rest of the opcions, thank you to any
help.

 

Greetings, 

 

Francisco

 

[Tiny-cobol-users] mistake make install compiler

[Soporte S. <sop...@ui...>]

Friends, 

 

Trying make compiler, display the next Messenger:

 

gcc -I/usr/include -I/usr/local/include -I../lib -I../ -c scan.c

scan.c:1061: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'YY_PROTO'

scan.l:744: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'YY_PROTO'

make: *** [scan.o] Error 1

 

And it doesn't create the file "htcobol", the way I can't compile, please
can you help me to resolve this problem.

 

I am using a Linux suse 10.0.x whit a language in spanish.

 

While I was executing (configure) it produce the next file:

 

This file contains any messages produced by compilers while

running configure, to aid debugging if configure makes a mistake.

 

configure:641: checking host system type

configure:662: checking target system type

configure:680: checking build system type

configure:802: checking for gcc

configure:840: checking for as

configure:883: checking for a BSD compatible install

configure:936: checking whether ln -s works

configure:957: checking whether make sets ${MAKE}

configure:988: checking for ranlib

configure:1018: checking for ar

configure:1053: checking for flex

configure:1106: checking for bison

configure:1150: checking for expand

configure:1188: checking how to run the C preprocessor

configure:1209: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1268: checking for ANSI C header files

configure:1281: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1348: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure: In function 'main':

configure:1343: warning: incompatible implicit declaration of built-in
function 'exit'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1377: checking for stdio.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for alloca.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for errno.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for fcntl.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for limits.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/time.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for unistd.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for malloc.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for stdlib.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for string.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for strings.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for utime.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for ctype.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/stat.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for sys/types.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1377: checking for getopt.h

configure:1387: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:1428: checking for working const

configure:1482: gcc -c   conftest.c 1>&5

configure:1503: checking for off_t

configure:1536: checking for size_t

configure:1569: checking whether struct tm is in sys/time.h or time.h

configure:1582: gcc -c   conftest.c 1>&5

configure:1605: checking for 8-bit clean memcmp

configure:1623: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure: In function 'main':

configure:1618: warning: incompatible implicit declaration of built-in
function 'exit'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1641: checking for vprintf

configure:1669: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1653: warning: conflicting types for built-in function 'vprintf'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strcspn

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strcspn'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strdup

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strdup'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strerror

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for strspn

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

configure:1760: warning: conflicting types for built-in function 'strspn'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:1748: checking for putenv

configure:1776: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:2020: checking for asin in -lm

configure:2039: gcc -o conftest    conftest.c -lm  -L/usr/lib
-L/usr/local/lib 1>&5

configure:2032: warning: conflicting types for built-in function 'asin'

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.so when searching for -lm

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.a when searching for -lm

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:2225: checking for db_185.h

configure:2235: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:2741: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
-ldb 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:3022: checking for ncurses.h

configure:3032: gcc -E  conftest.c >/dev/null 2>conftest.out

configure:3061: checking for addch in -lncurses

configure:3080: gcc -o conftest    conftest.c -lncurses  -L/usr/lib
-L/usr/local/lib -ldb 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.so when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.a when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

configure:3117: checking for color_set in -lncurses

configure:3130: gcc -o conftest    conftest.c -L/usr/lib -L/usr/local/lib
-lncurses 1>&5

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.so when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libncurses.a when searching for -lncurses

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc

 

I didn't have problems installing the rest of the opcions, thank you to any
help.

 

Greetings, 

 

Francisco

 

[Tiny-cobol-users] A few questions...

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

A Jackson Smith wrote on the TC SF forum:

 > 1. Is there an Inline debugger? (meaning at execution time?)
 > 2. Is there Documentation on the following:
 > i. How to debug?

Yes and No.

TC translates COBOL into 32-bit GNU assembler (GAS) and then uses GCC to 
create the binary file (executable, shared library or DLL).

The '-g' command line option will enable the debugger code generation.

There are several debuggers available for GCC, such as GDB the GNU 
interactive debugger.

Unfortunately this part of TC has not been properly maintained,
so debugging only works partially, at best.


 > ii. Which COBOL Verbs have not been implemented at all/which
 > should work?

All of the verbs have been implemented, at least partially.
I think (UN)STRING and EVALUATE are the only two verbs which are not 
fully implemented.

Some of the items that are not implemented, are the REPORT SECTION, 
COMMUNICATION SECTION, DECLARATIVES.

Many things are only partially implemented.


 > iii. How to install cleanly in a Wind*ws Environment?
 > Some of the bits are very unix'y and unfortunately I am not! I got it
 > working but got very confused.

I'm not not aware of any way to install a console application in a 
Wind*ws GUI based environment, cleanly.
Even when then installation is done using a GUI application like INNO setup.

To complicate matters, TC requires MinGW, the GCC compiler for Wind*ws, 
and BDB and PDcureses.


 > 3. What is the recommended way to produce GUI front-ends?
 > If there is none, I have been playing with XBLite and there is an
 > addon called Vixen that works like a VB Painter and can be used
 > like Micro Focus Dialog System.
 > Are there examples/support for call conventions between languages?

Yes, there is support for the C and Pascal (WINAPI) call conventions.

There is limited support in COBOL for pointers and structures, so it is 
best to use the native API language to write GUI front-ends.
Then COBOL (sub)programs can be considered as just another function call.

Same examples can be found in the test.code directories.
A trivial Win32 example can be found in the 'test.code/tgui02' directory.


 > 4. I worked for Micro Focus Technical Support for over 12 years
 > and a further 5 for a training and consultancy company in Germany.
 > Is there any support/testing work that needs to be done?
 > 5. What interest is there for my documentation?

Any help in that department would be appreciated.

There is some limited documentation, which can be found on the TC 
resources web page (1).

Feel free to expand or rewrite it.

1) TinyCOBOL
http://tiny-cobol.sf.net/

Re: [Tiny-cobol-users] INSTALL TC ON CYGWIN

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

Antonino Midiri wrote:

  > I WANT INSTALL TC ON CYGWIN WITH DB-4.1 OR DB-4.5
  > BUT ./CONFIGURE --with-libdb=4 not work.
  > Instead OpenCobol accept ./configure make and
  > make install and compiling the programs.
  > As change configure for install TC?.

As of version 0.59 (I think), TC no longer requires Cygwin.
So TC officially dropped support for Cygwin, in favor of MinGW.

You should be able to configure and build TC on Cygwin.
There are several things you could try to fix the DB problem.

One, create a Cygwin soft link for DB (DB -> DB-4.1 OR DB-4.5).
Then run ./configure, make, and make install.

Or, two run the MinGW script 'sh tconfig.mingw.sh'. It should generate
the make files.
Some minor changes in the compiler and lib make files, such as paths,
library and binaries names (DB, mingw32-make), may be required.
Then run make and make install.

Note that TC uses the BDB 1.85 API, which is included with DB up to
version 4.5 or 4.6 I think.
Or*cle (Sleepyc*t) dropped support for the BDB 1.85 API recently.
The 'configure' script should trap and abort if this problem occurs.

Anyway, hope this helps.
Good luck.

[Tiny-cobol-users] INSTALL TC ON CYGWIN

[<ant...@vi...>]

I WANT INSTALL TC ON CYGWIN WITH DB-4.1 OR DB-4.5 BUT ./CONFIGURE --
with-libdb=4 not work. Instead OpenCobol accept ./configure make and 
make install and compiling the programms. As change configure for 
install TC?.
hi 
Antonino.

Re: [Tiny-cobol-users] installation procedure for COBOL

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

manju arumugam wrote:
 > am new to this group, and i am new to this
 > language, can i know about Installation procedure
 > for Install cobol in linux platform.

Just download the source and build TC as follows.

./configure
make
make install (as su)

Set the envirioment variables as in the following example.

TCOB_OPTIONS_PATH=/usr/local/share/htcobol
TCOB_RTCONFIG_PATH=/usr/local/share/htcobol

Then compile any test programs found in the test.code directory, as in
the following example.

Using a make file:
make

Using the command line (Fixed source format):
htcobol -v -x -F sample-program.cob


BTW, if you download version 0.63, you may run into the follwing problem.

There is a macro 'define' problem with flex versions greater that 2.5.4.

This will cause TC to fail to compile with the following error message.

  > ...
  > gcc ... -c scan.c
  > scan.c:1062: parse error before `YY_PROTO'
  > ...

This is caused by the following macro 'define', as found in scan.l:61.

#define YY_DECL int yylex2 YY_PROTO((void))

The following code will fix the problem for all version (I hope) of flex.

#ifdef YY_USE_PROTOS
#define YY_DECL int yylex2 YY_PROTO((void))
#else
#define YY_PROTO(proto) (void)
#define YY_DECL int yylex2(void)
#endif

This is not an issue with the CVS version.

Hope this helps.

[Tiny-cobol-users] installation procedure for COBOL

[manju a. <mma...@ya...>]

Hai all, 
   am new to this group, and i am new to this
language,
can i know about Installation procedure for Install
cobol in linux platform. 


Thanks in Advance,
Manju.A


      Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

Re: [Tiny-cobol-users] Accounting Software

[<jw...@we...>]

Hi John,

I have been wanting to get my software onto sourceforge for some time now,
but as with most of you out there, time seems to be something that I am
unable to find enough of.

I have a complete accounting, point of sale, Inventory etc system which I
want to get onto sourceforge to allow all the interested 'COBOL'
programmers to get involved with any future development. This is basically
to allow for the GUI interface, aswel as printing through windows and
cups.

The system has been written for microfocus and I had started to make the
necessary amendments for ACU, which has now become part of microfocus.
There will most likely be numerous changes for it to run on any of the
free COBOL compilers but the important, varyfication, IO, calculation code
etc is all there.

I need to get this code onto sourceforge for all this to happen. Have
already registered as APAC accounting on sourceforge, but need some advice
from those of you that have been using the system as to which is the best
method of moving forward.

Regards

James Lemmon


-------------------------------------------
South Africas premier free email service - www.webmail.co.za 
------------------------------------------------------------------
For super low premiums, click here http://www.webmail.co.za/dd.pwm

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

[Tim J. <te...@we...>]

On Wed, 2007-12-26 at 16:19 -0500, David Essex wrote:

> I agree that small code may have been good practice back in the
> 60s early 70s.
> 
> However, assuming this part of the urban legend is true, these
> programs were replaced by structured programming methods.
> So memory was not an issue.
> 
> Even if the programs were written back in the 60s, these
> programs could have been easily converted by the maintainers
> of these systems. Not to mention cheaper.
> 
> As to why management choose to replace these programmers, who
> knows. Maybe it was just cheaper to replace them with less paid
> programmers. Then used some excuse to justify their actions.
> Nothing new under the sun here ...
> 
> That is the thing about urban legends, you never really know
> what to believe.
> 
> 
> Cheers

At that time a typical computer ran 100,000 instructions per second. I
remember in 1977 using a "supercomputer" capable of 1,000,000
instructions per second.  

Program listings often had clock counts written next to each
instruction, so people could add up the counts to see what the impact on
performance was of a given change, such was the concern about running
times. Using an alter statement changed an evaluation followed by a
conditional branch to an unconditional branch saving at least one
instruction.

See how much work you can get done, given a budget of 1 hour of CPU time
on such a CPU (3,600 X 100,000 = 36,000,000 instructions or about 30
milliseconds on your modern computer. This amount of processing time
would have cost about $3,000).

On such a computer, a build of GCC would have taken about 6 months (if
it had fitted in memory, which it would not have by a factor of a few
hundred). 

Tim Josling

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

Binyamin Dissen wrote:

 > David Essex wrote:
 >
 >> Have you ever heard the story about some COBOL programmers
 >> employed in the financial sector.
 >
 >> Apparently these COBOL programmers had written some mission
 >> critical applications. They used so many 66 levels and ALTER
 >> statements, that it made very difficult for any else to
 >> understand the code.
 >
 >> Of course they used this code to ensure job security and what
 >> they considered a GOOD salary.
 >
 > Depends when it was done.
 >
 > Back in Ye Olde Days, not only would it have been ridiculous
 > to use 3M for a simple Hello World program, one could not even
 > guarantee 100K being available (including buffers).
 >
 > While overlays and ALTERS are most unstructured, they do allow
 > for faster and smaller code.
 >
 > So if this code was written in the 90s, yes, there is something
 > wrong.
 >
 > If this code was written in the 70s, good code. And much more
 > maintainable (by the average programmer) than assembler.

I agree that small code may have been good practice back in the
60s early 70s.

However, assuming this part of the urban legend is true, these
programs were replaced by structured programming methods.
So memory was not an issue.

Even if the programs were written back in the 60s, these
programs could have been easily converted by the maintainers
of these systems. Not to mention cheaper.

As to why management choose to replace these programmers, who
knows. Maybe it was just cheaper to replace them with less paid
programmers. Then used some excuse to justify their actions.
Nothing new under the sun here ...

That is the thing about urban legends, you never really know
what to believe.


Cheers

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

[Binyamin D. <bd...@di...>]

On Tue, 25 Dec 2007 14:51:12 -0500 David Essex <de...@us...>
wrote:

:>John Culleton wrote:

:>>  David Essex wrote:

:>>> I can assume you have encountered the '66 level ALTER statement'
:> >> merry go round. Code who's real purpose was to ensure job
:> >> security.
 
:>> There was the contract programmer who ensured job security by a) sucking up to 
:>> the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
:>> indexes, and then as accumulators for storing numeric data, all in the same 
:>> program.  He was of course fond of ALTER. 

:>Have you ever heard the story about some COBOL programmers employed in 
:>the financial sector.

:>Apparently these COBOL programmers had written some mission critical 
:>applications. They used so many 66 levels and ALTER statements, that it 
:>made very difficult for any else to understand the code.

:>Of course they used this code to ensure job security and what they 
:>considered a GOOD salary.

Depends when it was done.

Back in Ye Olde Days, not only would it have been ridiculous to use 3M for a
simple Hello World program, one could not even guarantee 100K being available
(including buffers).

While overlays and ALTERS are most unstructured, they do allow for faster and
smaller code.

So if this code was written in the 90s, yes, there is something wrong.

If this code was written in the 70s, good code. And much more maintainable (by
the average programmer) than assembler.

--
Binyamin Dissen <bd...@di...>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Re: [Tiny-cobol-users] Segmentation Fault

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

David Essex wrote:

 > Reg wrote:
 > Problem now is that lockserver doesn't work.
 > ...
 >> Well 'lockserver' is not currently supported by the run-time.
 >> ...
 >> I will reconsider support for file LOCKS for indexed file
 >> types only, using either 'lockserver' or 'MONTSUQI'.

Upon further consideration I will not add support for 'lockserver' to 
the run-time.
The principal reason is that file LOCKS (flock) are not supported by the 
BDB 185 API.
AFAIK, there is no way to ensure data integrity of the index file.

As for 'MONTSUQI', I can't read Japanese, but it does not appear to 
support Win32.

Unfortunately, this means version 0.64 of TC will not support file LOCKS.


Cheers

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

John Culleton wrote:

>  David Essex wrote:

>> I can assume you have encountered the '66 level ALTER statement'
 >> merry go round. Code who's real purpose was to ensure job
 >> security.
> 
> There was the contract programmer who ensured job security by a) sucking up to 
> the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
> indexes, and then as accumulators for storing numeric data, all in the same 
> program.  He was of course fond of ALTER. 

Have you ever heard the story about some COBOL programmers employed in 
the financial sector.

Apparently these COBOL programmers had written some mission critical 
applications. They used so many 66 levels and ALTER statements, that it 
made very difficult for any else to understand the code.

Of course they used this code to ensure job security and what they 
considered a GOOD salary.

Eventually management, frustrated by this situation, secretly hired some 
programmers to rewrite these applications using structured programming 
methods.

Once the systems were up and running, they promptly fired all these 
COBOL programmers. To ensure this situation would not repeat
itself, they mandated that all applications must be written using 
structured programming methods.

I don't know if this story is true, but none the less, an interesting tale.


 >> May be worth your while to post it on the OC forum.
 >> I don't know if the developer subscribes to the OC
 >> mailing list.

I neglected to mention that I was referring to the OC forum located on 
the OC home web page (1).


Cheers

1) OpenCOBOL home web page
http://www.opencobol.org/

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

On Monday 24 December 2007 10:46:29 pm David Essex wrote:

>  > I used to get paid decent bucks for debugging someone else's
>  > too too clever code but now I work for myself and I don't have
>  > the time.
>
> Yes, been there ...
> I can assume you have encountered the '66 level ALTER statement' merry
> go round. Code who's real purpose was to ensure job security.

There was the contract programmer who ensured job security by a) sucking up to 
the IBM SE and b) using fields called x1, x2 etc. as counters, later as 
indexes, and then as accumulators for storing numeric data, all in the same 
program.  He was of course fond of ALTER. 

-- 
John Culleton
Resources for every author and publisher:
http://wexfordpress.com/tex/shortlist.pdf
http://wexfordpress.com/tex/packagers.pdf
http://www.creativemindspress.com/newbiefaq.htm
http://www.gropenassoc.com/TopLevelPages/reference%20desk.htm

Re: [Tiny-cobol-users] ACCEPT etc. WAS Segmentation Fault

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

John Culleton wrote:

 > Unfortunately the cobcurses package contains
 > some wierd COBOL code that confuses my system.
 > Specifically there are literals full of tab characters
 > etc. that are so long that they overflow the line width.
 > This is in -free format per the Makefile.
 > Here is the first set of lines that causes the system
 > to blow up on "make":
 > 10  SCR-0015 PIC X(023)
 >     VALUE "
 >     3.Author:".

Strange.


 > The OC compiler sees the third line as an AUTHOR statement
 > (COBOL 68) and says it doesn't  meet COBOL 2002.  Well do tell.

Yes, OC defaults to the COBOL 2002 standard. Well parts of it anyway.
Have you tried using the '-std=cobol85' option.


 > Why there are tab characters in the middle of a COBOL
 > literal I cannot fully fathom.  I assume that they are
 > for positioning on the screen.
 > In legacy COBOL we used to use continuation characters
 > in column six for long literals but legacy is out of
 > style. Pity.
 >
 > So thanks for the suggestion but for me at least cobcurses
 > is more work than it is worth.

I haven't tried using 'cobcurses'. No time.

I'm surprised that you are experincing these sort of problems.
The developer is a COBOL programmer, and the application is based on a 
professional screen tool.


 > I used to get paid decent bucks for debugging someone else's
 > too too clever code but now I work for myself and I don't have
 > the time.

Yes, been there ...
I can assume you have encountered the '66 level ALTER statement' merry 
go round. Code who's real purpose was to ensure job security.

In any case it seams like a trivial but large bug of some sort.
May be worth your while to post it on the OC forum. I don't know if the 
developer subscribes to the OC mailing list.


 > My project objectives are fairly simple. Decades ago I wrote
 > a General Ledger package in RM COBOL. I have lost most of
 > the source code. The 8 inch floppies are in the bottom of
 > some landfill.
 > I want to recreate a useful GL package in COBOL and not
 > using Mysql etc.
 >
 > The one piece of code I still have is the program that created
 > a data file that when interpreted by a handler program would
 > display and accept a screen full of data.
 > It was a poor man's SCREEN SECTION if you will. RM COBOL of
 > course had positional ACCEPT and DISPLAY back in 1979 or so.
 > Basically I am starting from scratch, using the old user manual
 > and file layout as a loose guide.
 >
 > If I wanted to write the system in C or Perl, or Java, or Tcl/Tk
 > I would have done so.
 > I would like to write it in COBOL because I am far more fluent
 > in that language.

I can understand your point of view.
But using COBOL can be cumbersome and increase the amount of work.

For example you could use XHTML forms, and generate them using COBOL.


 > I am not familiar with MVC but I will google on it.

It is an acronym for Model View Controller. It was developed at X*rox 
Palo Alto, the same place were GUI's were born.

Simply put, it means that the application gets divided into 3 segments.
An interface (GUI, curses, etc.), a back end which does the actual work, 
and some glue which binds the two other segments together.


Cheers

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

 > After messing around with various alternatives,
 > I decided that passing multiple large linkage
 > parameters from program to program was too flakey,
 > so now write them to a file and read them with
 > single programs each compiled with -x and running
 > separately.
 > Works fine, segmentation errors gone.

I do not understand what kind of problem you have encountered, or what
you mean by 'large linkage parameters' (100KB, 1MB).

In any case, if you are passing the linkage parameters BY REFERENCE,
which is the default, you are only passing a pointer (4 bytes on 32bit
systems).

I ran some tests using both the '-x' and '-m' options, but I did not
encounter any problems.


 > Problem now is that lockserver doesn't work.
 > Set lockserver running in -d mode, comes up with
 > messages ending with "Server socket set-up" so
 > seems to be running fine.
 > Re-did Tiny Cobol config in development directory
 > with --enable-lockserv, make, make install.
 > Seems to completely ignore the option. No reference
 > to it in config.log, compiler chucks out error
 > message on encountering "unlock" (undefined reference
 > to tcob_unlock), no locking taking place on "read with
 > lock" according to lockserver debug, no lock (status 51)
 > encountered when expected in programs..
 > What am I doing wrong?

Well 'lockserver' is not currently supported by the run-time.
If you run './configure --help' you will notice that it is no longer an
option.

I had planned to replace 'lockserver' with 'MONTSUQI'(1). It is a small
transaction monitor which, according to the web site, works with OC.

Except for 'lockserver', file LOCKS were badly implemented on TC, for
the following reasons.
1) File LOCKS are not defined in the COBOL-85 standard.
2) Inconsistent behavior between different file types.
3) File LOCKS (flock) are not supported by the BDB 185 API.
...
There are more reasons, but suffice it to say that some sort of
transaction server would be the best way to ensure data integrity.

In any case, I had no plans to support file LOCKS considering the above
reasons.
I will reconsider support for file LOCKS for indexed file types only,
using either 'lockserver' or 'MONTSUQI'.

But first I need to finish what I started, run-time support for SORT.
So it may be a while before I can look at the code.

 > PS Sorry to hear that you intend to "retire" from the
 > TC project next year, but I guess you have done more
 > than your share........ I for one am grateful for your
 > efforts.

IMHO, except for the SCREEN (ACCEPT/DISPLAY) IO code and being Win32 
friendly, OC has surpassed TC.
So I don't see the benefit of developing two COBOL compilers.


Cheers

1) MONTSUQI (Panda) - transaction monitor
http://www.nurs.or.jp/~ogochan/panda/

Re: [Tiny-cobol-users] Segmentation Fault

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

Hi David,
After messing around with various alternatives, I decided that passing
multiple large linkage parameters from program to program was too flakey, so
now write them to a file and read them with single programs each compiled
with -x and running separately.
Works fine, segmentation errors gone.
Problem now is that lockserver doesn't work.
Set lockserver running in -d mode, comes up with messages ending with
"Server socket set-up" so seems to be running fine.
Re-did Tiny Cobol config in development directory with --enable-lockserv,
make, make install. Seems to completely ignore the option. No reference to
it in config.log, compiler chucks out error message on encountering "unlock"
(undefined reference to tcob_unlock), no locking taking place on "read with
lock" according to lockserver debug, no lock (status 51) encountered when
expected in programs..
What am I doing wrong?
Regards,
Reg.
PS Sorry to hear that you intend to "retire" from the TC project next year,
but I guess you have done more than your share........ I for one am grateful
for your efforts.
Thanks.
Reg.



David Essex-2 wrote:
> 
> Reg wrote:
> 
>  > Next problem:-
>  > Whether I compile with -m and run vis htcobrun or
>  > compile with -x for an executable,
>  > when I call the next program in the system I get:-
>  >
>  > /TinyCat/startpass1: line 4: 13359 Segmentation fault
>  > /TinyCobol/development/cobrun/htcobrun PASSCHEC1
>  >
>  > (different number for fault from -x version).
>  > This seems to occur when PASSCHEC1 calls the next
>  > program, which was compiled with -m.
>  > Could be the next program is large or the single
>  > parameter passed in linkage is too big?
>  > Anyway, seems like a memory fault similar to the
>  > compile problem prior to the CVS version.
> 
> I don't have sufficient information to determine the problem.
> 
> But usually a 'segmentation fault' with a CALL statement usually occurs 
> when the input/output paramaters are not in sync.
> Or when a dynamic call fails and input/output paramater data contains
> junk.
> 
> Did you set the following 'environment variables' ?
> 
> export TCOB_LD_LIBRARY_PATH=/TinyCat
> export LD_LIBRARY_PATH=/TinyCat
> 
> Hint:
> You can check a call statement with the following code.
> CALL ... ON EXCEPTION ...
> 
> 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
> 
> 

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

Re: [Tiny-cobol-users] TC version 0.64 and beyond

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

John Culleton wrote:

 > Another possible piece of work.
 > Let's say I have an alphanumeric field 8 characters long.
 > Initially it is filled with spaces. As part of the accept
 > of a screen  I fill in "foo" and hit return.
 > The field has "foo" in the first three positions but
 > what fills the remaining five? Ar there five spaces or
 > does a carriage return or tab character get placed in the
 > field ?
 > Perhaps there is a way to exit the field without disturbing
 > the last five characters but if so what is it?
 >
 > I have just that situation where a field is filled in
 > and then compared to another field.
 > A carriage return or tab charcter will cause the comparison
 > to be false where it should have been true.

I did not write the SCREEN (ACCEPT/DISPLAY) IO code, and I haven't 
worked on it in quite some time.

Frankly it is a real pain to work on this code, as it is OS (on UN*X 
terminal) dependent.

I had plans to work on the sources, add some user options to the 
run-time resource file 'htrtconf'.
But as it stands, I have no plans to update the SCREEN (ACCEPT/DISPLAY) 
IO sources.

Have you tried using 'cobcurses'(1) for your project.
According to the author it works with OC, so it may work with TC.

Hope this helps.

Cheers

1) cobcurses
http://sourceforge.net/projects/cobcurses

Re: [Tiny-cobol-users] TC version 0.64 and beyond

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

On Tuesday 18 December 2007 09:21:39 pm David Essex wrote:
> Some time in the new year I will release TC 0.64.
>
> Some of the new or improved features will include,
> - variable length files (including indexed)
> - RELATIVE files (including variable length)
> - File IO re-write (including SORT IO)
> - Grammar fixes
> - Memory leaks fixes
> ...
>
> Some of the features not included,
> - record key qualification
> - DECLARATIVES
> ...
>
> This will be my final contribution to the TC project.
>
> Cheers

Another possible piece of work. Let's say I have an alphanumeric field 8 
characters long. Initially it is filled with spaces. As part of the accept of 
a screen  I fill in "foo" and hit return. The field has "foo" in the first 
three positions but what fills the remaining five? Ar there five spaces or 
does a carriage return or tab character get placed in the field? Perhaps 
there is a way to exit the field without disturbing the last five characters 
but if so what is it?

I have just that situation where a field is filled in and then compared to 
another field.  A carriage return or tab charcter will cause the comparison 
to be false where it should have been true.  


-- 
John Culleton
Resources for every author and publisher:
http://wexfordpress.com/tex/shortlist.pdf
http://wexfordpress.com/tex/packagers.pdf
http://www.creativemindspress.com/newbiefaq.htm
http://www.gropenassoc.com/TopLevelPages/reference%20desk.htm

[Tiny-cobol-users] TC version 0.64 and beyond

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

Some time in the new year I will release TC 0.64.

Some of the new or improved features will include,
- variable length files (including indexed)
- RELATIVE files (including variable length)
- File IO re-write (including SORT IO)
- Grammar fixes
- Memory leaks fixes
...

Some of the features not included,
- record key qualification
- DECLARATIVES
...

This will be my final contribution to the TC project.

Cheers

Re: [Tiny-cobol-users] Qualified record key name.

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

John Culleton wrote:

 > This is more of an annoyance than a major shortcoming.
 > However it would be helpful if the the RECORD KEY
 > clause in a SELECT statement allowed for a qualified
 > name.
 > The reason? Well I often do a MOVE CORRESPONDING for
 > reports etc.  Currently I have to give the key fields
 > in the reports different names and move the current
 > values individually.

I can understand your frustration.
I have looked at a fix to the grammar on several occasions, but 
unfortunately, there is no easy solution.

Specifically, RECORD KEY identifiers are not defined until later.
Due to the way TC parses the FILE-CONTROL grammar, a fix would require a 
major re-write of the grammar and logic.

Currently, I have no plants to add a fix for record key qualification.


 > I have decided that the Tcl/Tk interface is too much
 > work so I am reverting to a SCREEN SECTION.
 > There was mention some time back of some corrections
 > to the ACCEPT/DISPLAY that were authored by Rildo.
 > David Essex responded on 01/02/07.
 >
 > Did these ever get to the source of Tiny?

Just to clarify.
Rildo's changes were made to an old version of TC, and not to the CVS on 
SF. I then manually merged some of these changes to CVS on SF.

So to answer your question, yes, some of Rildo's changes did make it to 
the sources on SF.
To verify if Rildo's ACCEPT/DISPLAY changes made it, you will have to 
download and build the current CVS version of TC on SF.

Anyway, hope this helps.

Cheers

[Tiny-cobol-users] Qualified record key name.

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

This is more of an annoyance than a major shortcoming. However it would be 
helpful if the the RECORD KEY clause in a SELECT statement allowed for a 
qualified name.  The reason? Well I often do a MOVE CORRESPONDING for reports 
etc.  Currently I have to give the key fields in the reports different names 
and move the current values individually.

I have decided that the Tcl/Tk interface is too much work so I am reverting to 
a SCREEN SECTION.  There was mention some time back of some corrections to 
the ACCEPT/DISPLAY that were authored by Rildo. David Essex responded on 
01/02/07.

Did these ever get to the source of Tiny?
-- 
John Culleton

Re: [Tiny-cobol-users] Segmentation Fault

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

Reg wrote:

 > Next problem:-
 > Whether I compile with -m and run vis htcobrun or
 > compile with -x for an executable,
 > when I call the next program in the system I get:-
 >
 > /TinyCat/startpass1: line 4: 13359 Segmentation fault
 > /TinyCobol/development/cobrun/htcobrun PASSCHEC1
 >
 > (different number for fault from -x version).
 > This seems to occur when PASSCHEC1 calls the next
 > program, which was compiled with -m.
 > Could be the next program is large or the single
 > parameter passed in linkage is too big?
 > Anyway, seems like a memory fault similar to the
 > compile problem prior to the CVS version.

I don't have sufficient information to determine the problem.

But usually a 'segmentation fault' with a CALL statement usually occurs 
when the input/output paramaters are not in sync.
Or when a dynamic call fails and input/output paramater data contains junk.

Did you set the following 'environment variables' ?

export TCOB_LD_LIBRARY_PATH=/TinyCat
export LD_LIBRARY_PATH=/TinyCat

Hint:
You can check a call statement with the following code.
CALL ... ON EXCEPTION ...

Cheers.

Re: [Tiny-cobol-users] Segmentation Fault

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

Hi David,
Decided to get rid of all the clutter, removed all versions of TC and
re-installed from CVS.
Compilations worked perfectly.
Thanks.
Next problem:-
Whether I compile with -m and run vis htcobrun or compile with -x for an
executable, 
when I call the next program in the system I get:-

/TinyCat/startpass1: line 4: 13359 Segmentation fault      
/TinyCobol/development/cobrun/htcobrun PASSCHEC1

(different number for fault from -x version).
This seems to occur when PASSCHEC1 calls the next program, which was
compiled with -m.
Could be the next program is large or the single parameter passed in linkage
is too big?
Anyway, seems like a memory fault similar to the compile problem prior to
the CVS version.
Regards,
Reg.

David Essex-2 wrote:
> 
> Reg wrote:
> 
>  > This now works to create a static binary, but
>  > how do I create a dynamic loading system?
> 
> What was created in the example was a binary linked with shared 
> libraries (DLL's) and a static TC RT library.
> The system linker will try to use a shared library, failing that it will 
> try using a static library.
> 
> So I'm not sure what you mean by a 'dynamic loading system'.
> 
> If you want to create a shared TC RT library (DLL), just change the 
> 'lib' make file.
> 
> #all: static-libs
> all: static-libs shared-libs
> ...
> #install: install-rts-config install-static-libs
> install: install-rts-config install-static-libs install-shared-libs
> 
> Then from the 'development' directory,
> make clean
> make
> make install (as root)
> 
> If you prefer to use modules (shared library), just use the '-m' option 
> then run it using 'htcobrun'.
> 
>  > 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)
> 
> The reason you are getting those linkage error messages, is that you are 
> using two different versions of TC to create a binary.
> You are using 'htcobol' from version 0.63.87 (I think), and the RTL from 
> another TC version.
> 
> The best fix would be to remove all installed TC files, then do a new TC 
> install using the source from version 0.63.87.
> 
> A quich fix is to use add the following to the xterm config ('.bashrc' 
> or '.profile'), or what ever you are using as a terminal.
> 
> export TCOB_OPTIONS_PATH=/TinyCobol/development/compiler
> export TCOB_RTCONFIG_PATH=/TinyCobol/development/lib
> export TCOB_LD_LIBRARY_PATH=/TinyCat
> export LD_LIBRARY_PATH=/TinyCobol/development/lib:/TinyCat
> 
> To the TC compile time resource file 'htcobolrc', found in the 
> 'development/compiler' directory, add the following.
> 
> LD_PATH: -L/TinyCobol/development/lib
> 
> Now do the following.
> Check the version of TC used, a test compile and run the binary created.
> You should get the following results with no linker errors.
> 
> #/TinyCobol/development/compiler/htcobol -V
> TinyCOBOL - pre alpha 0.63.87 ...
> 
> #cd /TinyCat
> 
> #/TinyCobol/development/compiler/htcobol -v -x DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> gcc -o DEGRABBER DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
>     -ldl -ldb -lncurses -lm
> 
> #./DEGRABBER
> 
> Now create a module and use 'htcobrun' to load it and run it.
> 
> #/TinyCobol/development/compiler/htcobol -v -m DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> gcc -shared -Wl,-soname,DEGRABBER.so -o DEGRABBER.so
>     DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
> 
> #/TinyCobol/development/cobrun/htcobrun DEGRABBER
> 
> 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14339835.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:

 > This now works to create a static binary, but
 > how do I create a dynamic loading system?

What was created in the example was a binary linked with shared 
libraries (DLL's) and a static TC RT library.
The system linker will try to use a shared library, failing that it will 
try using a static library.

So I'm not sure what you mean by a 'dynamic loading system'.

If you want to create a shared TC RT library (DLL), just change the 
'lib' make file.

#all: static-libs
all: static-libs shared-libs
...
#install: install-rts-config install-static-libs
install: install-rts-config install-static-libs install-shared-libs

Then from the 'development' directory,
make clean
make
make install (as root)

If you prefer to use modules (shared library), just use the '-m' option 
then run it using 'htcobrun'.

 > 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)

The reason you are getting those linkage error messages, is that you are 
using two different versions of TC to create a binary.
You are using 'htcobol' from version 0.63.87 (I think), and the RTL from 
another TC version.

The best fix would be to remove all installed TC files, then do a new TC 
install using the source from version 0.63.87.

A quich fix is to use add the following to the xterm config ('.bashrc' 
or '.profile'), or what ever you are using as a terminal.

export TCOB_OPTIONS_PATH=/TinyCobol/development/compiler
export TCOB_RTCONFIG_PATH=/TinyCobol/development/lib
export TCOB_LD_LIBRARY_PATH=/TinyCat
export LD_LIBRARY_PATH=/TinyCobol/development/lib:/TinyCat

To the TC compile time resource file 'htcobolrc', found in the 
'development/compiler' directory, add the following.

LD_PATH: -L/TinyCobol/development/lib

Now do the following.
Check the version of TC used, a test compile and run the binary created.
You should get the following results with no linker errors.

#/TinyCobol/development/compiler/htcobol -V
TinyCOBOL - pre alpha 0.63.87 ...

#cd /TinyCat

#/TinyCobol/development/compiler/htcobol -v -x DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
gcc -o DEGRABBER DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
    -ldl -ldb -lncurses -lm

#./DEGRABBER

Now create a module and use 'htcobrun' to load it and run it.

#/TinyCobol/development/compiler/htcobol -v -m DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
gcc -shared -Wl,-soname,DEGRABBER.so -o DEGRABBER.so
    DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol

#/TinyCobol/development/cobrun/htcobrun DEGRABBER

Cheers.