tiny-cobol-users

Re: [Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from TinyCobol (Gateway)

[Walter G. <ga...@dm...>]

Hi David,

For me no problem...how can i send it to you ?

Walter Garrote

----- Original Message ----- 
From: "David Essex" <de...@us...>
To: "tiny-cobol-users" <tin...@li...>
Cc: "walter A" <ga...@ho...>
Sent: Saturday, August 06, 2005 11:22 AM
Subject: Re: [Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from 
TinyCobol (Gateway)


> walter garrote wrote:
>
> > I tried to send the files to the list, but isn`t
> > possibile because its greater than 40kb. hehe.
> >
> > Now i`m trying to put it on sourceforge...i created it
> > named TinyCobol Sql.
> > Next week it will be there.
> >
> > I hope help someone with these feature.
>
> We could place on the TinyCOBOL SF site or the COBOL utilities SF site if 
> you wish.
>
>
>
>
> -------------------------------------------------------
> 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
> 

Re: [Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from TinyCobol (Gateway)

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

walter garrote wrote:

 > I tried to send the files to the list, but isn`t
 > possibile because its greater than 40kb. hehe.
 >
 > Now i`m trying to put it on sourceforge...i created it
 > named TinyCobol Sql.
 > Next week it will be there.
 >
 > I hope help someone with these feature.

We could place on the TinyCOBOL SF site or the COBOL utilities SF site 
if you wish.

[Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from TinyCobol (Gateway)

[walter A <ga...@ho...>]

Thanks Carlucio,

I tried to send the files to the list, but isn`t possibile because its 
greater than 40kb. hehe.

Now i`m trying to put it on sourceforge...i created it named TinyCobol Sql.
Next week it will be there.

I hope help someone with these feature.


many thanks,


walter garrote
brazil
goiania-goias

_________________________________________________________________
Chegou o que faltava: MSN Acesso Grátis. Instale Já! 
http://www.msn.com.br/discador

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.

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:

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

[Tiny-cobol-users] Fw: Access SQL Server (mysql or pgsql) from TinyCobol (Gateway)

[Carlucio L. <car...@te...>]

Hi,

i include this feature in TinyCobol (gateway for sql server).

For those that want access sql server (mysql or postgress) without change=
 any cobol program lines. Yes, using open, close, start, read, write, del=
ete, rewrite...

If you want other sql server, please send it to me...i will try to includ=
e it.

Take look at Readme-sql.txt.

I only test with linux (slackware), i didn=B4t test with mingw for (windo=
ws)...please help me with that.

Now i=B4m writing embedded sql for Tiny (mysql and postgress).

Any question or suggestion will be fine.

Many thanks for Carlucio Lopes and Fernando Wuthstrack.


Have fun.


Walter Garrote
Brazil
Goi=E2nia-Goi=E1s


--=20
Carlucio Lopes - Debian Gnu/Linux+Tinycobol+Tcl+Postgresql
compilador Cobol FREE  http://tinycobol.org site em Portugues
icq - 267274130  msn - car...@ho... linuxcounter 285056=20

Re: [Tiny-cobol-users] Screen.cpy file.

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

John R. Culleton wrote:

 > This is a very useful file with one confusing statement,
 > probably a typo:
 >
 >  NOTE: line-wor,col-wor and color-wor must be s9(.) comp fields.
 >
 > Now does this mean s9(5) or what?

I think the '.' means any number 1-18.

But 's9(5)' is adequate for most cases.

[Tiny-cobol-users] Screen.cpy file.

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

This is a very useful file with one confusing statement,
probably a typo:

 NOTE: line-wor,col-wor and color-wor must be s9(.) comp fields.

Now does this mean s9(5) or what?
-- 
John Culleton

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] Parse error on blank cards.

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

John R. Culleton wrote:

 > I have narrowed down my parse error to the following
 > circumstance. When I create a template program for COBOL
 > I cannot include the following:
 > 000150 INPUT-OUTPUT SECTION.
 > 000160 FILE-CONTROL.
 >
 > Unless I also include at least one SELECT statement. In other
 > words the following causes an error:
 >
 > 000070 ENVIRONMENT DIVISION.
 > 000080
 > 000090 CONFIGURATION SECTION.
 > 000100 SOURCE-COMPUTER.   Linux.
 > 000120 OBJECT-COMPUTER.   Linux.
 > 000140
 > 000150 INPUT-OUTPUT SECTION.
 > 000160 FILE-CONTROL.
 > 000170
 > 000180 DATA DIVISION.
 >
 > ... but the following does not:
 >
 > 000070 ENVIRONMENT DIVISION.
 > 000080
 > 000090 CONFIGURATION SECTION.
 > 000100 SOURCE-COMPUTER.   Linux.
 > 000120 OBJECT-COMPUTER.   Linux.
 > 000140
 > 000150 INPUT-OUTPUT SECTION.
 > 000160 FILE-CONTROL.
 > 000170     SELECT PRINTFILE ASSIGN TO PRINTER.
 > 000180 DATA DIVISION.
 > 000190

Actually the TC version of the 'INPUT-OUTPUT SECTION' conforms to the
COBOL 85 standard, which is as follows.

[ INPUT-OUTPUT SECTION. FILE-CONTROL. {file-control-entry} ...]

Meaning that the 'INPUT-OUTPUT SECTION' is optional, but if present it
must contain a  'FILE-CONTROL' clause and at least one or more
'file-control-entries'.


 > In the latter case the absence of a matching FD statement does
 > not cause an error.

Yes, that is a know bug.


 > OTOH OpenCobol allows the first configuration without complaint.
 > I like that better.

The specification may have changed for the COBOL 2002 standard or maybe 
added an extention.

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 .

[Tiny-cobol-users] Parse error on blank cards.

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

I have narrowed down my parse error to the following
circumstance. When I create a template program for COBOL
I cannot include the following: 
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.

Unless I also include at least one SELECT statement. In other
words the following causes an error:

000070 ENVIRONMENT DIVISION.
000080 
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.   Linux.
000120 OBJECT-COMPUTER.   Linux.
000140 
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.
000170  
000180 DATA DIVISION.

... but the following does not:

000070 ENVIRONMENT DIVISION.
000080 
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.   Linux.
000120 OBJECT-COMPUTER.   Linux.
000140 
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.
000170     SELECT PRINTFILE ASSIGN TO PRINTER.
000180 DATA DIVISION.
000190

In the latter case the absence of a matching FD statement does
not cause an error.

OTOH OpenCobol allows the first configuration without complaint.
I like that better.  
-- 
John Culleton

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:

 > 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] DB1x vs DB3x

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

John R. Culleton wrote:

 > David Essex wrote:
 >
 >> That is a known problem usually found on RPM based systems.
 > ...
 > BTW I run Slackware. NO RPMs here.

Well RPM based system is where the problem was first encountered, and
since has spread to other distributions.

The fundamental problem for the 'configure' script is how to determine
if DB1 is installed, and if so how to ensure that the TC run-time uses
only DB1.

On systems that have several versions of DB installed this is rather
difficult.

[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] DB1x vs DB3x

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

On Wednesday 03 August 2005 09:40 pm, David Essex wrote:
> John R. Culleton wrote:
>  > David Essex wrote:
>  > ...
>  >
>  >> Actually TC will work with any version of DB (1.85.4 2.x 3.x 4.x),
>  >> however it only uses the DB 185 API.
>  >
>  > ...
>  > OK, but the ./configure step blows up with the following message
>  >
>  > Beginning DB library test link sequence
>  > checking if db.h header belongs to version 1.x \(1.85-2\)... no
>  > configure: error: header db.h for library db version 1.x \(1.85-2\)
>  > not found... aborting
>  >
>  > So how do I fake out the configure?
>
> That is a known problem usually found on RPM based systems.
>
> The following configure option should fix the problem.
>
> ./configure --help
> ...
> --with-libdb=[ARG] use DB library version (2 3 4)
> ...
>
> Example:
> ./configure --with-libdb=db3

The working line is  a tad different:

 ./configure --with-libdb=3

But thanks for putting me on the right path.

BTW I run Slackware. NO RPMs here. 
-- 
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] DB1x vs DB3x

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

John R. Culleton wrote:

 > David Essex wrote:
 > ...
 >> Actually TC will work with any version of DB (1.85.4 2.x 3.x 4.x),
 >> however it only uses the DB 185 API.
 > ...
 > OK, but the ./configure step blows up with the following message
 >
 > Beginning DB library test link sequence
 > checking if db.h header belongs to version 1.x \(1.85-2\)... no
 > configure: error: header db.h for library db version 1.x \(1.85-2\)
 > not found... aborting
 >
 > So how do I fake out the configure?

That is a known problem usually found on RPM based systems.

The following configure option should fix the problem.

./configure --help
...
--with-libdb=[ARG] use DB library version (2 3 4)
...

Example:
./configure --with-libdb=db3

Re: [Tiny-cobol-users] DB1x vs DB3x

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

On Wednesday 03 August 2005 02:24 pm, David Essex wrote:
> John R. Culleton wrote:
>  > I already use OpenCobol which works with DB 3.
>  > TinyCOBOL only works with DB 1. Assuming these
>  > facts are correct, how do I install tinyCOBOL
>  > without screwing up my existing OpenCobol
>  > installation?
>
> Actually TC will work with any version of DB (1.85.4 2.x 3.x 4.x),
> however it only uses the DB 185 API.
>
> Due to licensing issues it is recommended that a DB version prior to 2.x
> be used.
>
> Most uses do not have an issue with using DB version 2.x or above.

OK, but the ./configure step blows up with the following message
---------------
Beginning DB library test link sequence
checking if db.h header belongs to version 1.x \(1.85-2\)... no
configure: error: header db.h for library db version 1.x \(1.85-2\) not 
found... aborting
----------------------
So how do I fake out the configure?
                                        
-- 
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] DB1x vs DB3x

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

John R. Culleton wrote:

 > I already use OpenCobol which works with DB 3.
 > TinyCOBOL only works with DB 1. Assuming these
 > facts are correct, how do I install tinyCOBOL
 > without screwing up my existing OpenCobol
 > installation?

Actually TC will work with any version of DB (1.85.4 2.x 3.x 4.x),
however it only uses the DB 185 API.

Due to licensing issues it is recommended that a DB version prior to 2.x
be used.

Most uses do not have an issue with using DB version 2.x or above.

If you are using an RPM based system I would suggest using what ever
version of DB is available. As configuring TC to link with DB1 can be
very cumbersome.

There should be no conflicts in using both TC and OC on the same system.


 > I want to test out TC because OpenCobol doesn't implement
 > positioning ACCEPT and DISPLAY statements and doesn't have a
 > SCREEN section.

TC does support both ACCEPT/DISPLAY AT LINE/POS statement clauses, and
the screen section.

There are some examples enclosed with the source code, in the
'test.code' directories.

Re: [Tiny-cobol-users] PDF of manual

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

John R. Culleton wrote:

 > Is there a printable version of the TC manual?
 > Flipping html pages online is not my preferred
 > method of browsing a document.

Unfortunately documentation is very limited.

It currently consists of just some information on command line options,
in a man, text and html formats.

Dean Powell is in the process of creating a manual, and recently posted
the most recent version on this mailing list.

[Tiny-cobol-users] PDF of manual

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

Is there a printable version of the TC manual? Flipping html
pages online is not my preferred method of browsing a document. 
-- 
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

[Tiny-cobol-users] DB1x vs DB3x

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

I already use OpenCobol which works with DB 3. TinyCOBOL only
works with DB 1. Assuming these facts are correct, how do I
install tinyCOBOL without screwing up my existing OpenCobol
installation?

I want to test out TC because OpenCobol doesn't implement
positioning ACCEPT and DISPLAY statements and doesn't have a
SCREEN section. 
-- 
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] CVS merge

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

Hi Rildo,

Rildo Pragana wrote:

 > ...
 >>> Unfortunately, I lost access to SF's CVS server.
 >>
 >> You still have admin status for the TC project on SF.
 >> What kind of problem are you experiencing ?
 >>
 > If I try to "cvs update" from my machine, it asks for the password
 > then stay locked for ever. The same with all other cvs commands.

Sounds like a SSH problem.

Some times generating a new random seed will fix a SSH problem.

But, I'm not familiar with your network setup.
If you use a firewall, I believe that SSH uses a special port and you 
have to adjust the firewall config.


Rildo Pragana wrote:
 > I forgot to give you the details on how I stay updated
 > (as "cvs update" don't work). First, I retrieve the full
 > cvs repository from SF, ...
 >
 > Then, I expand this and put under control of a local cvs server, so I
 > can checkout from it.  You see, this is not the best way to work...

Well CVS was never designed to merge two CVS repositories. There are 
special tools for that, such as Bitkeeper.

The only thing that I can suggest is extract a SF copy on a separate 
directory, change the 'CVS/Root' entries to your local TC repository 
name, and then do a merge (update) from your local TC repository.
Hopefully this method should do most of the work (not all) for you.