tiny-cobol-users

[Tiny-cobol-users] Up and running.

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

Well I have TC up and running and have recompiled some of my
recent OpenCobol efforts. The ncurses bit works as expected. 

I find that TC is less forgiving than either OpenCobol or some
commercial complers I have used about things like legacy names
and blank lines, at least in fixed (-F) format. I suppose I can
make all the blank lines into comments with an asterisk in
column 7. And I find I have to comment things like AUTHOR,
INSTALLATION etc. But one must take the bitter with the sweet.

I have a general question even at this early stage. If I wish to 
move programs to another Linux system what must I take along beyond
the program itself? I presume Berkeley DB is essential. How much
more? Is it required to do a complete install similar to the
devlopment machine? 
-- 
John Culleton

Re: [Tiny-cobol-users] Up and running.

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

John R. Culleton wrote:

 > Well I have TC up and running and have recompiled some of my
 > recent OpenCobol efforts. The ncurses bit works as expected.
 >
 > I find that TC is less forgiving than either OpenCobol or some
 > commercial complers I have used about things like legacy names
 > and blank lines, at least in fixed (-F) format. I suppose I can
 > make all the blank lines into comments with an asterisk in
 > column 7. And I find I have to comment things like AUTHOR,
 > INSTALLATION etc. But one must take the bitter with the sweet.

You should not have to place asterisk in column 7 for statements like 
AUTHOR, INSTALLATION, or blanks lines.

What kind of problems have you encountered, and could give an example.

BTW, if like to work with fixed format, you can set it as the default 
using the TC compiler resource file 'htcbolrc'.

# Specify COBOL program default input format
# free format  -> PGM_FORMAT_FREE
# fixed format -> PGM_FORMAT_FIXED
# (compiler default=free format)
#PGM_FORMAT_FREE
PGM_FORMAT_FIXED


 > I have a general question even at this early stage. If I wish to
 > move programs to another Linux system what must I take along beyond
 > the program itself? I presume Berkeley DB is essential. How much
 > more? Is it required to do a complete install similar to the
 > devlopment machine?

Once compiled, a TC compiled program is just another binary executable.
And as with other binaries, is dependent on which shared libraries were 
used to compile/link the source.

Example:
$ldd test19a
libhtcobol.so.0 => /usr/local/lib/libhtcobol.so.0 (0x40014000)
libdb.so.3 => /lib/libdb.so.3 (0x4001a000)
libdl.so.2 => /lib/libdl.so.2 (0x40053000)
libm.so.6 => /lib/libm.so.6 (0x40056000)
libc.so.6 => /lib/libc.so.6 (0x40072000)
ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


If the other Linux system is only used to run the COBOL programs, then 
only the TC run-time (if compiled as a shared library) and the run-time 
config file 'htrtconf'.
The location of the run-time config file is set when TC is configured 
(ex: /usr/local/share/htcobol), but can be also set using the 
'TCOB_RTCONFIG_PATH' environment variable.

Example:
export TCOB_RTCONFIG_PATH=/usr/share/htcobol
export TCOB_OPTIONS_PATH=/usr/share/htcobol

Hope this helps.

Re: [Tiny-cobol-users] Up and running.

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

On Thursday 04 August 2005 11:44 am, David Essex wrote:
> John R. Culleton wrote:
>  > Well I have TC up and running and have recompiled some of my
>  > recent OpenCobol efforts. The ncurses bit works as expected.
>  >
>  > I find that TC is less forgiving than either OpenCobol or some
>  > commercial complers I have used about things like legacy names
>  > and blank lines, at least in fixed (-F) format. I suppose I can
>  > make all the blank lines into comments with an asterisk in
>  > column 7. And I find I have to comment things like AUTHOR,
>  > INSTALLATION etc. But one must take the bitter with the sweet.
>
> You should not have to place asterisk in column 7 for statements like
> AUTHOR, INSTALLATION, or blanks lines.
>
> What kind of problems have you encountered, and could give an example.
>
> BTW, if like to work with fixed format, you can set it as the default
> using the TC compiler resource file 'htcbolrc'.
>
> # Specify COBOL program default input format
> # free format  -> PGM_FORMAT_FREE
> # fixed format -> PGM_FORMAT_FIXED
> # (compiler default=free format)
> #PGM_FORMAT_FREE
> PGM_FORMAT_FIXED
>
>  > I have a general question even at this early stage. If I wish to
>  > move programs to another Linux system what must I take along beyond
>  > the program itself? I presume Berkeley DB is essential. How much
>  > more? Is it required to do a complete install similar to the
>  > devlopment machine?
>
> Once compiled, a TC compiled program is just another binary executable.
> And as with other binaries, is dependent on which shared libraries were
> used to compile/link the source.
>
> Example:
> $ldd test19a
> libhtcobol.so.0 => /usr/local/lib/libhtcobol.so.0 (0x40014000)
> libdb.so.3 => /lib/libdb.so.3 (0x4001a000)
> libdl.so.2 => /lib/libdl.so.2 (0x40053000)
> libm.so.6 => /lib/libm.so.6 (0x40056000)
> libc.so.6 => /lib/libc.so.6 (0x40072000)
> ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
>
> If the other Linux system is only used to run the COBOL programs, then
> only the TC run-time (if compiled as a shared library) and the run-time
> config file 'htrtconf'.
> The location of the run-time config file is set when TC is configured
> (ex: /usr/local/share/htcobol), but can be also set using the
> 'TCOB_RTCONFIG_PATH' environment variable.
>
> Example:
> export TCOB_RTCONFIG_PATH=/usr/share/htcobol
> export TCOB_OPTIONS_PATH=/usr/share/htcobol
>
> Hope this helps.

It helps a great deal! I had fun going through the htcobolrc
file and setting things to my preference---program listings and
everything! 

I set the link options to link to a static library to ensure
greater portability. So to transport such a binary I need the
binary, the htcobolrc file, a path to the htcobolrc file, and
what else? 

TIA

-- 
John Culleton

Re: [Tiny-cobol-users] Up and running.

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

John R. Culleton wrote:

 > I set the link options to link to a static library to ensure
 > greater portability. So to transport such a binary I need the
 > binary, the htcobolrc file, a path to the htcobolrc file, and
 > what else?

The 'htcobolrc' file is only used by TC at compile time to create a
binary from a COBOL source.
So I'm confused as to what you mean by 'such a binary'.
Are you trying to move the TC compiler and run-time, or just the TC
compiled COBOL programs.

If you are only moving the TC compiled programs, since you are using a
static TC run-time, all you need are the COBOL program binary(s) and the
run-time config file 'htrtconf'.

Optional if different from default:
export TCOB_RTCONFIG_PATH=/usr/local/share/htcobol

On the other hand if you are trying to move (install) the TC compiler
and run-time, it is best to build it and install it on the system where
it will be used.

./configure ...
make
Change 'htcobolrc' and 'htrtconf' files as required.
su ...
make install
exit

Note that the Linux linker will use shared libraries by default, if
available. To avoid this problem compile, and install, only the static
version of the TC run-time .

Re: [Tiny-cobol-users] Up and running.

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

On Friday 05 August 2005 02:48 am, David Essex wrote:
> John R. Culleton wrote:
>  > I set the link options to link to a static library to ensure
>  > greater portability. So to transport such a binary I need the
>  > binary, the htcobolrc file, a path to the htcobolrc file, and
>  > what else?
>
> The 'htcobolrc' file is only used by TC at compile time to create a
> binary from a COBOL source.
> So I'm confused as to what you mean by 'such a binary'.
> Are you trying to move the TC compiler and run-time, or just the TC
> compiled COBOL programs.
>
> If you are only moving the TC compiled programs, since you are using a
> static TC run-time, all you need are the COBOL program binary(s) and the
> run-time config file 'htrtconf'.
>
First my goal is to move as little as possible, to give the
user an application that will run on any Linux system without
much fuss and feathers. 

Given that goal, is the compiled static binary and the control
file sufficient? Does Berkeley DB need to be moved also or is
that included in the static compiled binary?

Also I need a little help with the htcobolrc file compile
options. Here are the options:
# Specify the compiler default action
# P     - preprocess
# PC    - preprocess,compile
# PCA   - preprocess,compile,assemble
# PCAL  - preprocess,compile,assemble,link to executable
# PCAX  - preprocess,compile,assemble,link to executable
# PCAS  - Preprocess, compile, assemble, link to static library
# PCAM  - Preprocess, compile, assemble, link to shared library
# (compiler default=PCAL)
COMPILE_DEFAULT: PCAL
#COMPILE_DEFAULT: PCAS
#COMPILE_DEFAULT: PCAM
#

Assuming that I want everything rolled into one binary, is the
correct choice PCAS or PCAX?

Also, what is the difference between PCAL and PCAX? They have
identical definitions above. 






> Optional if different from default:
> export TCOB_RTCONFIG_PATH=/usr/local/share/htcobol
>
> On the other hand if you are trying to move (install) the TC compiler
> and run-time, it is best to build it and install it on the system where
> it will be used.
>
> ./configure ...
> make
> Change 'htcobolrc' and 'htrtconf' files as required.
> su ...
> make install
> exit
>
> Note that the Linux linker will use shared libraries by default, if
> available. To avoid this problem compile, and install, only the static
> version of the TC run-time .
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

-- 
John Culleton
Books with answers to marketing and publishing questions:
http://wexfordpress.com/tex/shortlist.pdf

Book coaches, consultants and packagers:
http://wexfordpress.com/tex/packagers.pdf

Re: [Tiny-cobol-users] Up and running.

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

John R. Culleton wrote:

 > David Essex wrote:
 > ...
 >
 >> If you are only moving the TC compiled programs, since you
 >> are using a static TC run-time, all you need are the COBOL
 >> program binary(s) and the run-time config file 'htrtconf'.
 >
 > First my goal is to move as little as possible, to give the
 > user an application that will run on any Linux system without
 > much fuss and feathers.
 >
 > Given that goal, is the compiled static binary and the control
 > file sufficient?

The short answer is YES, that is all you need.
Once copy of the run-time config file 'htrtconf' placed in the default 
install location.


 > Does Berkeley DB need to be moved also or is that included in
 > the static compiled binary?

Yes, the TC run-time uses the Berkeley DB and the ncurses (if the screen 
section and/or display/accept AT ... are used) libraries.
You can check for for missing library dependencies using the 'ldd 
program' command.



 > Also I need a little help with the htcobolrc file compile
 > options. Here are the options:
 > # Specify the compiler default action
 > # P     - preprocess
 > # PC    - preprocess,compile
 > # PCA   - preprocess,compile,assemble
 > # PCAL  - preprocess,compile,assemble,link to executable
 > # PCAX  - preprocess,compile,assemble,link to executable
 > # PCAS  - Preprocess, compile, assemble, link to static library
 > # PCAM  - Preprocess, compile, assemble, link to shared library
 > # (compiler default=PCAL)
 > COMPILE_DEFAULT: PCAL
 > #COMPILE_DEFAULT: PCAS
 > #COMPILE_DEFAULT: PCAM
 > #
 >
 > Assuming that I want everything rolled into one binary, is the
 > correct choice PCAS or PCAX?

The PCAS/PCAX options do not roll everything into one binary.

These options create a library (static or shared) from the COBOL sources.


 > Also, what is the difference between PCAL and PCAX? They have
 > identical definitions above.

Yes, The PCAL and PCAX options are identical.


TC generates GNU assembler form the COBOL sources then uses the GCC tool 
chain to create objects, libraries or binary executables.

Are trying to create a binary executable, form the COBOL sources, 
without any shared libraries dependencies.
If so then yes, in theory that can be done.
Assuming that the static libraries are available on your system for all 
dependencies.

Re: [Tiny-cobol-users] Up and running.

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

On >  >
>  > Given that goal, is the compiled static binary and the control
>  > file sufficient?
>
> The short answer is YES, that is all you need.
> Once copy of the run-time config file 'htrtconf' placed in the default
> install location.
>
>
OK and get that do I use PCAX? Or what? Sorry to be such a bore
but this option business is confusing. 
-- 
John Culleton
Books with answers to marketing and publishing questions:
http://wexfordpress.com/tex/shortlist.pdf

Book coaches, consultants and packagers:
http://wexfordpress.com/tex/packagers.pdf

Re: [Tiny-cobol-users] Up and running.

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

John R. Culleton wrote:

 > ...
 >> The short answer is YES, that is all you need.
 >> Once copy of the run-time config file 'htrtconf' placed
 >> in the default install location.
 >
 > OK and get that do I use PCAX? Or what?

Yes, you can use PCAX or PCAL.

FYI, what does 'PCAL' mean ?
P - pre-process the COBOL source
C - convert the COBOL source into assembler
A - compile the assembler code into object code
L - link the object code to create an executable

Hint:
To see all the steps use the verbose ('-v') command line option.


 > Sorry to be such a bore but this option business
 > is confusing.

The compiler options are basically user defined defaults, most of which 
can be overidden by the command line options.