tiny-cobol-users

Re: [Tiny-cobol-users] Hello

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

Szemerédy Gábor wrote:

 > I made the things according to your instructions and here are my
 > observations:
 > The link between libhtcobol.so and libhtcobol.so.0.62.0 and
 > the link between libhtcobol.so.0 and libhtcobol.so.0.62.0
 > is very strange , since none of  those files are existing ,
 > only the links!
 > ...
 > By typing ldd htcobol the response was:
 > libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
 >  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 > ldd libhtcobol.so.0.62.0 answered no such file or directory.
 > ...

Yes, the problem is a defective RPM.

The shared TC run-time library is not enclosed in the RPM, only the
static one.

So remove all links 'libhtcobol.so, libhtcobol.so.0,and
libhtcobol.so.0.62.0'.

The static run-time library will be used for the link.

 > I tried to find out dependencies.
 > Typing rpm -q --requires tinycobol it responded:
 > /bin/sh
 > /bin/sh
 > db4
 > glibc-devel
 > libc.so.6
 > libc.so.6(GLIBC_2.0)
 > libc.so.6(GLIBC_2.1)
 > libc.so.6(GLIBC_2.3)
 > rpmlib(CompressedFileNames) <= 3.0.4-1
 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1

The RPM was built using DB version 4.

 > Finally I compiled successfully the little cobol program
 > with the -ldb option.

Change the resource file 'htcobolrc'.
LD_EXTRA_LIBS: -ldl -ldb

This will add the '-ldb' automatically.


 > Now I'm confused , since I'm not a cobol programmer , what do you
 > mean by file IO and in what situations I do need the DB for
 > compilation.

File IO are the read/write statements, used to access files.


 > It seems to me that this rpm type of installation is not the right
 > one for as.
 > We would like to have a fully functional compiler.
 > So I would like to ask you to tell as which tar.gz files we need?
 > How to configure on RH9 , and install them?

As far as I can tell, you do have a fully functional TC compiler.

Have you tried compiling and running any of the 'test.code' COBOL 
samples found in the 'tinycobol-devel-0.62.tar.gz' file ?

If you would like to built TC from the sources it is not difficult, and 
since you have an RPM based system you should have all the requirements 
installed on your system.

Re: [Tiny-cobol-users] Hello

[<ga...@rc...>]

Hello Mr. Essex!
Sorry for still disturbing you.
I made the things according to your instructions and here are my observat=
ions:
The link between libhtcobol.so and libhtcobol.so.0.62.0 and the link betw=
een
libhtcobol.so.0 and libhtcobol.so.0.62.0 is very strange , since none of =
those
files are existing , only the links!
I tried to find out dependencies.
Typing rpm -q --requires tinycobol it responded:
/bin/sh
/bin/sh
db4
glibc-devel
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.3)
rpmlib(CompressedFileNames) <=3D 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1
By typing ldd htcobol the response was:
libc.so.6 =3D> /lib/tls/libc.so.6 (0x42000000)
 /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
ldd libhtcobol.so.0.62.0 answered no such file or directory.
Finally I compiled successfully the little cobol program with the -ldb op=
tion.
Now I'm confused , since I'm not a cobol programmer , what do you  mean b=
y
file IO and in what situations I do need the DB for compilation.
It seems to me that this rpm type of installation is not the right one fo=
r as.
We would like to have a fully functional compiler.
So I would like to ask you to tell as which tar.gz files we need?
How to configure on RH9 , and install them?
Thanks in advance!
Gabor

David Essex wrote:

> Szemer=E9dy G=E1bor wrote:
>
>  > ...
>  > Here are my adventures with Tinycobol.
>  > When I installed tinycobol-0.62.-1.i386.rpm on my RH9 machine , the
>  > installation did not make symbolic link
>  > /usr/lib/libhtcobol.so.0 ---> libhtcobol.so.0.62.0 ,
>  > so I made it by hand.
>
> Yes that is a bug in the make file.
>
>  > When I tried to install db1-1.85.4-8.i386.rpm it claims on conflict =
on
>  > two files:
>  > libdb1.so.2 and db1_dump185.
>  > So I renamed those two files of gnome-libs-1.4.1.2.90-32 and install=
ed
>  > db1 rpm.
>  > After that I installed db1-devel-1.85.4-8.i386.rpm and
>
> It is recommended to use DB1, but the TC run-time will work with almost
> any version of DB, 1.85.4 - 4.
>
> So the binary RPM depends on what version of DB the TC run-time was lin=
ked.
> I do not think that in this case the RPM binary is linked with DB1.
>
> You can check the dependencies of the RPM using the 'rpm' command.
>
> Or extract the compiler and run-time from the RPM, and use the 'ldd'
> command.
>
> ldd ./htcobol
> and
> ldd ./libhtcobol.so.0.62.0
>
> If there is a bad or missing dependency, the 'ldd' command will list th=
e
> library and add 'not found' error message next to it.
>
> example:
>
> $ldd test10
> libhtcobol.so.0 =3D> not found
> libdb.so.3 =3D> /lib/libdb.so.3 (0x4001a000)
> libm.so.6 =3D> /lib/libm.so.6 (0x40053000)
> libc.so.6 =3D> /lib/libc.so.6 (0x4006f000)
> ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
>
>  > byacc-1.93-21bw.i386.rpm.
>
> YACC (or Bison) is only required to build (compile and link) the the TC
> compiler itself.
> It is not required to run TC, to compile a COBOL program.
>
>  > Checked all packages trough webmin and made failing symbolic links.
>  > (now certainly webmin claims on moved gnome-libs files,
>  > failed file size check for db1_dump185 and libdb1.so.2 )
>  > Now I tried to compile a simply cobol program:
>  > *
>  > IDENTIFICATION DIVISION.
>  > PROGRAM-ID.    zvonko.
>  > PROCEDURE DIVISION.
>  > DISPLAY "Sretan start buduce saradnje".
>  > STOP RUN.
>  > #htcobol zvonko.cob
>  > The result was:
>  > ... libhtcobol.a(fileio.o)(.text+0x63a):
>  > In function `tcob_open':
>  > : undefined reference to `__db185_open'
>  > Can you give me an advice what to do?
>
> That is a bug, or omission, with the compiler defaults.
>
> Due to a change in the TC run-time, DB is required for all COBOL
> programs, even when file IO is not used.
>
> Just add the following to the resource file 'htcobolrc'.
> LD_EXTRA_LIBS: -ldl -ldb
>
> Or add DB to the command line.
> htcobol -v zvonko.cob -ldb
>
> Hope this helps.
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

Re: [Tiny-cobol-users] Hello

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

Szemerédy Gábor wrote:

 > ...
 > Here are my adventures with Tinycobol.
 > When I installed tinycobol-0.62.-1.i386.rpm on my RH9 machine , the
 > installation did not make symbolic link
 > /usr/lib/libhtcobol.so.0 ---> libhtcobol.so.0.62.0 ,
 > so I made it by hand.

Yes that is a bug in the make file.


 > When I tried to install db1-1.85.4-8.i386.rpm it claims on conflict on
 > two files:
 > libdb1.so.2 and db1_dump185.
 > So I renamed those two files of gnome-libs-1.4.1.2.90-32 and installed
 > db1 rpm.
 > After that I installed db1-devel-1.85.4-8.i386.rpm and

It is recommended to use DB1, but the TC run-time will work with almost 
any version of DB, 1.85.4 - 4.

So the binary RPM depends on what version of DB the TC run-time was linked.
I do not think that in this case the RPM binary is linked with DB1.

You can check the dependencies of the RPM using the 'rpm' command.

Or extract the compiler and run-time from the RPM, and use the 'ldd'
command.

ldd ./htcobol
and
ldd ./libhtcobol.so.0.62.0

If there is a bad or missing dependency, the 'ldd' command will list the
library and add 'not found' error message next to it.

example:

$ldd test10
libhtcobol.so.0 => not found
libdb.so.3 => /lib/libdb.so.3 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x40053000)
libc.so.6 => /lib/libc.so.6 (0x4006f000)
ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


 > byacc-1.93-21bw.i386.rpm.

YACC (or Bison) is only required to build (compile and link) the the TC
compiler itself.
It is not required to run TC, to compile a COBOL program.


 > Checked all packages trough webmin and made failing symbolic links.
 > (now certainly webmin claims on moved gnome-libs files,
 > failed file size check for db1_dump185 and libdb1.so.2 )
 > Now I tried to compile a simply cobol program:
 > *
 > IDENTIFICATION DIVISION.
 > PROGRAM-ID.    zvonko.
 > PROCEDURE DIVISION.
 > DISPLAY "Sretan start buduce saradnje".
 > STOP RUN.
 > #htcobol zvonko.cob
 > The result was:
 > ... libhtcobol.a(fileio.o)(.text+0x63a):
 > In function `tcob_open':
 > : undefined reference to `__db185_open'
 > Can you give me an advice what to do?

That is a bug, or omission, with the compiler defaults.

Due to a change in the TC run-time, DB is required for all COBOL
programs, even when file IO is not used.

Just add the following to the resource file 'htcobolrc'.
LD_EXTRA_LIBS: -ldl -ldb

Or add DB to the command line.
htcobol -v zvonko.cob -ldb

Hope this helps.

Re: [Tiny-cobol-users] Hello

[<ga...@rc...>]

Thanks Mr. Essex for your answer!
Here are my adventures with Tinycobol.
When I installed tinycobol-0.62.-1.i386.rpm on my RH9 machine , the
installation
did not make symbolic link /usr/lib/libhtcobol.so.0 --->
libhtcobol.so.0.62.0 ,
so I made it by hand.
When I tried to install db1-1.85.4-8.i386.rpm it claims on conflict on
two files:
libdb1.so.2 and
db1_dump185.
So I renamed those two files of gnome-libs-1.4.1.2.90-32 and installed
db1 rpm.
After that I installed db1-devel-1.85.4-8.i386.rpm and
byacc-1.93-21bw.i386.rpm.
Checked all packages trough webmin and made failing symbolic links.
(now certainly webmin claims on moved gnome-libs files,
failed file size check for db1_dump185 and libdb1.so.2 )
Now I tried to compile a simply cobol program:
*
       IDENTIFICATION DIVISION.
       PROGRAM-ID.    zvonko.
       PROCEDURE DIVISION.
       DISPLAY "Sretan start buduce saradnje".
       STOP RUN.
typing #htcobol zvonko.cob
The result was:
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libhtcobol.a(fileio.o)(.text+0x63a):
In function `tcob_open':
: undefined reference to `__db185_open'
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libhtcobol.a(fileio.o)(.text+0x706):
In function `tcob_open':
: undefined reference to `__db185_open'
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libhtcobol.a(fileio.o)(.text+0x3c82):
In function `tcob_sort_open':
: undefined reference to `__db185_open'
collect2: ld returned 1 exit status
Can you give me an advice what to do?
Thanks again!
Gabor

Re: [Tiny-cobol-users] Hello

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

Szemerédy Gábor wrote:

 > Is this list alive?

Yes, but it is on life support.


 > Heve problems with Tinycobol installed on RH9.
 > using tiny rpm , db1 rpm, db1 devel rpm and byacc rpm.

What kind of problems ?

I would recommend building TC from the sources, as RPM binaries 
dependencies tend to be critical.

A few new features have been added to TC since the last release, so I 
would recommend down-loading the SF CVS version.

[Tiny-cobol-users] Hello

[<ga...@rc...>]

Is this list alive?
Heve problems with Tinycobol installed on RH9. using tiny rpm , db1 rpm
, db1 devel rpm and byacc rpm.
Thanks

Re: [Tiny-cobol-users] Segmentation Fault

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

 > I am getting "segmentation fault" error while I am
 > executing program.
 > The program is the result of compilation of called and
 > calling program. Compilation goes fine.
 > When I run gdb the output is as follows:

A "segmentation fault", when using main and sub-programs, can be caused 
by  improper parameter passing.


 > [Thread debugging using lib thread_db enabled]
 > [New Thread - 151214400 (LWP 7591)]
 > Program received signal SIGSEGV, segmentation fault
 > [Switching Thread - 151214400 (LWP 7591)]
 > 0x00a5e4da in memcpy () from /lib/tls/libc.so.6
 >
 > I am using TC 0.62 on Fedora Core 3 linux.

First, TC does not have any native support for 'Threads'.

Since the TC stabs generation, required by GDB, is not being maintained,
it is not recommended that GDB be used to debug TC programs.

The old fashioned 'DISPLAY' statement should work, in isolating the 
problem statement.

[Tiny-cobol-users] Segmentation Fault

[<ra...@gr...>]

<html>Hi,<BR>
<BR>
I am getting "segmentation fault" error while I am&nbsp;executing program. The program is the result of compilation of called and calling program. Compilation goes fine. When I run gdb the output is as follows:<BR>
<BR>
[Thread debugging using lib thread_db enabled]<BR>
[New Thread - 151214400 (LWP 7591)]<BR>
Program received signal SIGSEGV, segmentation fault<BR>
[Switching Thread - 151214400 (LWP 7591)]<BR>
0x00a5e4da in memcpy () from /lib/tls/libc.so.6<BR>
<BR>
I am using TC 0.62 on Fedora Core 3 linux.<BR>
<BR>
TIA<BR>
Ravi<BR>
<BR></html>

[Tiny-cobol-users] CVS update 0.62.5

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

I've made some major changes to TC, on CVS SF.

First, the command line parameters are now stored in the run-time 
library, thus enabling all (sub)programs in the run unit to access the 
parameters.
This change will also enable the 'cobrun' program to pass the command 
line parameters to the run-time, and thus all (sub)programs in the run unit.

Second, the code generation for the 'STOP RUN' statement has been 
changed to conform to the COBOL85 standard. Clean-up, terminate the run 
unit and return control to the OS.

Finally, two new command line and one resource file options have been 
added, to enable the programmer to better define the run unit enter and 
exit points.
Previous versions defined a main-program (entry point) and sub-programs, 
by the presence (or absence) of the 'LINKAGE SECTION'. The main program 
would then be renamed as the entry point function 'main'.

With these options, you can select if there is (or not) a entry point 
function 'main', and which COBOL program in the run unit will be 
executed first.


New resource file options:

# Specify the default main program (entry point) action
#
# auto  - Use the first encountered 'STOP RUN' statement,
#         and if found, generate a program entry point.
#
# first - Use the first encountered 'PROGRAM-ID' statement,
#         and if found, generate a program entry point.
#
# none  - Do not generate any program entry point.
#
PGM_ENTRY_POINT_AUTO
#PGM_ENTRY_POINT_NONE
#PGM_ENTRY_POINT_FIRST

New command line options:

-M <option> Specify main entry point option (auto|first|none)
-e <name>   Specify entry point name (first program to execute)


The compiler defaults (resource file options) have been set to mimic the 
old compiler behavior, so no (or only small) changes to the command line 
options are required.


As always comments and/or suggestions are welcomed.

Re: [Tiny-cobol-users] Help Debug

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

ravi wrote:

 >
 > I am unable to make good use of debugging feature.
 > As documented, I compile program with -g option
 > "htcobol -g xx.cob".
 > The steps are as follows:
 >
 > htcobol -g testprg.cob
 > gdb
 > file testprg
 > run

You can also use,
$gdb testprg
(gdb) r

First, the TC run-time library must be compiled with the '-g' option, 
otherwise GDB will get lost.

Unfortunatly, due to the complexity (about 10 times more code) of 
generating GCC debug symbols (stabs) in the generated assembler code, 
the TC stabs generation code has not been maintained.

Consequently GDB does not work very well with TC compiled programs or 
libraries.


 > One of the variable defined is ws-eof. But if I say print
 > ws-eof within gdb I get an error undefined symbol.
 > Could someone help me on this?

The problem is the '-' symbol, which is allowed in COBOL, but not 
allowed in many other languages, such as GNU assembler.

Try using a single or double quotes, that should work.

print 'ws-eof'


 > Also how do I debug in case of call and called program.
 > Assume x.cob is calling y.cob how do I compile and make the
 > resultant binary executable?

Create a make file which will do the following.

htcobol -g -c x.cob
htcobol -g -c y.cob
gcc -g -o exe x.o y.o ... -lhtcobol ...

$gdb exe

You can find several examples, on how to compile main and sub-programs 
to create an executable, in the 'test.code' directories (try t17).

[Tiny-cobol-users] Help Debug

[<ra...@gr...>]

Hi,

I am unable to make good use of debugging feature. As documented, I compile program with -g option "htcobol -g xx.cob". The steps are as follows:

htcobol -g testprg.cob
gdb
file testprg
run

One of the variable defined is ws-eof. But if I say print ws-eof within gdb I get an error undefined symbol. Could someone help me on this?

Also how do I debug in case of call and called program. Assume x.cob is calling y.cob how do I compile and make the resultant binary executable?

TIA
Ravi

[Tiny-cobol-users] htcobrun - executing COBOL programs as modules

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

Some users have inquired if TC has a feature, found on many COBOL
compilers (i.e. cobrun and runcbl), enabling users to run COBOL
(sub)programs as modules.

While a TC compiled COBOL program can use the 'CALL identifier ...'
statement to load and run a module, there was no special program.

A new program, called 'htcobrun', is now available on SF CVS in the
cobrun directory.

It enables TC COBOL (sub)programs, or modules, compiled with TC as
shared libraries (DLL's), to be dynamically loaded and run.

Example:
$htcobrun dyntest

Note that the (sub)programs, or module name, is the 'PROGRAM-ID' name,
not the actual shared library file name.
The actual file (shared library) may contain one or more modules.

Why use 'htcobrun' ?

The 'htcobrun' program can be compiled to fully include the full
run-time (static) library (Not currently available on MinGW version).
This approach yields substantial runtime performance improvements.

The COBOL (sub)programs can be built as shared libraries, which may
contain one or more modules, and are loaded and run dynamically.

Are there any problems in using this approach.

Currently, there is no support for passing 'LINKAGE SECTION' parameters
to sub-programs.

All comments and suggestions are welcomed.

Re: [Tiny-cobol-users] Printing

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

Ravi Katti wrote:

> My apologies as I know this is not the right forum for this question. 
> But I didnt get any info from other forums. could someone from this
> group help me get going?
> 
> I am trying to configure line printer(Dataproduct) on Fedora core 3. 
> The printer prints few strings and stops. Even the string is incomplete
> as random letters are missedout during printing.
> I tried using "Raw print queue" as well as "Generic text only" driver
> on fedora. the hardware is compaq pentium IV system. 
> Also the parallel port is set to "SPP enhanced" on this compaq system.
> 
> The same system and cable properly prints on a HP deskjet printer. 
> so is this issue related to driver settings?
> What would be typical printers.conf and /etc/printcap setting for these
> kind of line printers?
> 
> any pointers are greatly appreciated.

Printers, much like terminals, can accept commands (escape sequences) within a data stream.
These escape sequences can be used to set printer features, such as fonts.

If you are using the standard UN*X line-printer, then the traditional method would be to add
one or more entries, per printer, to the '/etc/printcap'.

Then use the input and/or output filters programs (of/if I think) to add the 'escape
sequences' depending on the filters programs options given.

Re: [Tiny-cobol-users] Lineage clause

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

Ravi Katti wrote:

> As of now TC doesn't seem to support lineage clause. could anyone 
> pls help me as to how do I print non-standard stuff like cheques/checks
> etc on a line printer. In short any workaround for lineage clause?

Use a standard control break, with an 'ADVANCING PAGE'. This will add a <FF> form-feed to
the output file.

The number of lines in a form can usually be set on the printer.
When a <FF> is encountered, it will jump to the top of the next form.


> What is the syntax for using "exec" command within cobol programs? 
> I didnt find anyhting in sample programs.

The 'exec*' are a set of functions found in the C library.

You can use the standard COBOL CALL verb (CALL 'execle' ...).

Note that all parameters must include a NULL character at the end.

Re: [Tiny-cobol-users] dynamic linked libraries

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

Burke Cabaniss wrote:

> ... 
> The COBOL I use has a "CALL PROGRAM [name]" statement that 
> works like a CALL and then a CANCEL (of the caller). The COBOL I use 
> finds programs by name in an object file directory, with no special 
> "library" setup.

Some COBOL compilers can create executables or special objects.

The 'special objects' are run using a special program which loads and then executes it.
For example MF 'cobrun' and ACU 'runcbl'.

I plan to add a program, called 'htcobrun', to CVS within the next few days.
This will enable TC (sub)programs, compiled as modules (shared-libraries, DLLs), to be
loaded and run.

One of the advantages of this method, is that all COBOL programs can be compiled as modules.
  On UN*X platforms, a complete static versions of the TC run-time library can be enclosed
in 'htcobrun', thus increasing program run performance.

Would anyone like to try (test) this program ?
If so let me know and I will forward the source and instructions.

All comments and suggestions are welcomed.

[Tiny-cobol-users] unsubcribe of the tiny cobol user group

[Julio C. U. <jul...@ya...>]

Good morning
 
I want to unsubcribe of the tiny cobol user group
 
Thanks you

<ra...@gr...> escribió:
Hi,

As of now TC doesnt seem to support lineage clause. could anyone pls help me as to how do I print non-standard stuff like cheques/checks etc on a line printer. In short any workaround for lineage clause?

What is the syntax for using "exec" command within cobol programs? I didnt find anyhting in sample programs.

TIA
Ravi Katti. 







-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Tin...@li...
https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

		
---------------------------------

Correo Yahoo!
Comprueba qué es nuevo, aquí
http://correo.yahoo.es

[Tiny-cobol-users] Printing

[<ra...@gr...>]

My apologies as I know this is not the right forum for this question. But I didnt get any info from other forums. could someone from this group help me get going?

I am trying to configure line printer(Dataproduct) on Fedora core 3. The printer prints few strings and stops. Even the string is incomplete as random letters are missedout during printing. I tried using "Raw print queue" as well as "Generic text only" driver on fedora. the hardware is compaq pentium IV system. Also the parallel port is set to "SPP enhanced" on this compaq system.

The same system and cable properly prints on a HP deskjet printer. so is this issue related to driver settings? What would be typical printers.conf and /etc/printcap setting for these kind of line printers?

any pointers are greatly appreciated.

TIA
Ravi

[Tiny-cobol-users] Lineage clause

[<ra...@gr...>]

Hi,

As of now TC doesnt seem to support lineage clause. could anyone pls help me as to how do I print non-standard stuff like cheques/checks etc on a line printer. In short any workaround for lineage clause?

What is the syntax for using "exec" command within cobol programs? I didnt find anyhting in sample programs.

TIA
Ravi Katti. 

Re: [Tiny-cobol-users] dynamic linked libraries

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

Burke Cabaniss wrote:

> I can compile and run programs with htcobol. My question is about COBOL 
> programs that CALL my other COBOL programs. I do not know about linking 
> of executables, and am asking about general direction.
>
> I have about 30 large COBOL programs that run in a combination process. 
> Some are CALL'ed and return, and some do not return. They "link" in my 
> old terminology. The latter progressively and selectively CALL other of 
> the programs. The COBOL I use has a "CALL PROGRAM [name]" statement that 
> works like a CALL and then a CANCEL (of the caller). The COBOL I use 
> finds programs by name in an object file directory, with no special 
> "library" setup.

Some COBOL compilers can create executables or special objects.

The executables can be run from the command line.

The 'special objects' are run using a special program which loads and then executes it (ex.
COBOL object-name).

This special program is really just a program linked with the COBOL run-time.
The special objects are really just shared libraries (DLL's on Win32). Or as some people
refer to them, modules.

At this time, TC does not have this special program.

But TC (GCC) can create binary objects, executables, libraries (shared and static).


> I believe I want to put all of these programs in one or two dynamic link 
> libraries. If two, one would be for "standard" functions that always 
> return to the caller. If this is the right direction, please confirm. I 
> can get the details of building dll's.

What I would do is create a library, with the "standard" functions that always
return to the caller.

For COBOL sources that do not return to the caller, I would create an executable for each one.

For programs which call other COBOL programs, but do not return, you can use one of the
'exec*' C function call.

Hope this helps.

LINK: Perl Meets COBOL - A must read for main-frame programmers
http://www.perl.com/pub/a/2000/05/cobol.html

Re: [Tiny-cobol-users] Error in I-O for line sequential file

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

Girish Modi wrote:

> Pl see attached sample/test program test12ls.cob which is not working in 
> our setup
>  
> Problem is file status 37 in i-o mode for line sequential file

IO mode for line-sequential files is not supported.

Line sequential files have variable length records, with a <LF> delimiter.
So a re-write would not work properly.

Hint:
You can create a sequential file (fixed record length) with a <LF> as the last character of
each record.
Then you can open the file in IO mode.

[Tiny-cobol-users] Re: dynamic linked libraries

[Burke C. <bu...@bs...>]

I can compile and run programs with htcobol. My question is about COBOL programs 
that CALL my other COBOL programs. I do not know about linking of executables, 
and am asking about general direction.

I have about 30 large COBOL programs that run in a combination process. Some are 
CALL'ed and return, and some do not return. They "link" in my old terminology. 
The latter progressively and selectively CALL other of the programs. The COBOL I 
use has a "CALL PROGRAM [name]" statement that works like a CALL and then a 
CANCEL (of the caller). The COBOL I use finds programs by name in an object file 
directory, with no special "library" setup.

I believe I want to put all of these programs in one or two dynamic link 
libraries. If two, one would be for "standard" functions that always return to 
the caller. If this is the right direction, please confirm. I can get the 
details of building dll's.

RE: [Tiny-cobol-users] Lockserver

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

Jim,

This piece of code and other code like this
                        /* Ok - maybe we're not creating it.  87( */
                        openlog("lockserver", LOG_PID, LOG_DAEMON);
                        syslog(LOG_ERR, "Could not create HOME =
directory.");
                        syslog(LOG_ERR, strerror(errno));
                        closelog();
                        exit(EXIT_FAILURE);
Write to the Unix Syslog. It dos not create a logfile called logserver.
It has been a long time since I have made changes to the code but I =
think
That for Windows I send the Syslog entries to the screen. Have a look at =
the
last 50 lines
Or so of lockserver to see the code I have for MINGW.

Regards
Andrew Cameron
----------------------------------------------
Ordinary people are making EXTRAORDINARY
money WORKING FROM HOME on the Internet!
Get FREE info by email. =20
Send your request to :
mailto:myo...@ge...

Andrew Cameron
e-Mail: apc...@so...
URL: http://www.myownbusinessathome.com
URL: http://www.moreinfo247.com/8763637/FREE
URL: http://www.empowerism.com/e/96001
URL: http://signups-guaranteed.us/affiliates/2887072.php
----------------------------------------------

-----Original Message-----
From: tin...@li...
[mailto:tin...@li...] On Behalf Of Jim
Morcombe
Sent: Monday, May 16, 2005 4:33 AM
To: tiny-cobol-users
Subject: [Tiny-cobol-users] Lockserver


Lockserver is now running.

I deleted everything in the directory /usr/local/lockserver and=20
installed it again.

There had been a file called ".lf" previously.  Now it is gone and I=20
have a file called "lockdump".

As far as I can see from the code, after checking the HOME directory is=20
okay, it then tries to open a lockfile.  If it can't, it then tries to=20
open a log file and write an error message to it.  Is the log file meant =

to be called "lockserver"?  What directory should it be created in?

Any clues?

Jim



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
_______________________________________________
Tin...@li...
https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

--=20
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.13 - Release Date: 5/19/2005
=20

Re: [Tiny-cobol-users] Problem with test program t33 - CALL statement using dynamic calls

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

Jim Morcombe wrote:

 > The "make" seems to fail for the test.code program "t33".
 >
 > Is this related to my previous email about the missing "libhtcobol.so"
 > shared libraries or have I got a separate problem?
 >
 > $ make
 > htcobol -c  -P -I../copybooks -I. subrots.cob
 > make: *** [subrots.o] Segmentation fault

I'm unable to duplicate this problem on my system.

Have you checked what version of 'htcobol' you are using ?

$htcobol -V
TinyCOBOL - pre alpha 0.62.0 (linux-gnu 2005/05/20)
(C) 1991, 1993, 1999-2003 Rildo Pragana et. al.

Maybe you have more that one version installed.

Anyway, if the problem persists let me know.
It could be a bug of some sort.

Re: [Tiny-cobol-users] libhtcobol.so.0

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

Jim Morcombe wrote:

 > According to the documentation, I should have a shared library called
 > "libhtcobol.so.0.62.x" and a couple of soft links to it called
 > "libhtcobol.so" amd libhtcobol.so.0"
 >
 > I expect these are meant to be in the directory "/usr/local/lib".
 >
 > I don't have these libraries.  I am not sure whether the configure
 > option "--with-dl" has anything to do with this, but I have tried both
 > with and without this flag.
 >
 > When I run my Cobol program, called "gl0010",  I get this error:
 > gl0010: error while loading shared libraries: libhtcobol.so.0: cannot
 > open shared object file: No such file or directory

You can check the shared library dependencies using the 'ldd' command.

$ldd gl0010


 > What an I doing wrong?
 >
 > Although I am missing the libhtcobol.so shared libraries, I do have
 > "libhtcobol.a" sitting in "/usr/local/lib".
 >
 > Am I meant to rename this as "libhtcobol.so.0.62.1" or something?

By default, using the sources for TC version '0.62', will build and
installs the static run-time library (libhtcobol.a) only.

To build and install the shared run-time library is easy.

$make cleandist
$./configure ... (--with-dl not required)
$make
$make slibs
$su ... (or sudo)
$make install

AND one of the following steps

$make install-slibs
$exit

OR

$cd lib
$make install-shared
$exit

One of the main problems with shared libraries is when you have programs
which are dynamically linked with different versions of the same library.
Then you would either have to re-build each program, or need to have
different versions of the shared libraries installed (not recommended).

Unless you have a high volume production environment, it's recommended
that the static run-time library is used.

Hope this helps.

[Tiny-cobol-users] Re: VBISAM Win32 port (2)

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

Roger While wrote:

 > Is that the "libtoolized" version ?

No it's the 1.04 version plus the 'isbuild' (isbuild.c) bug fix from
your "libtoolized" version.

BTW, I think the 'isbuild' bug is caused by an invalid block number
access which starts with block #3.
The current solution works, but the underling problem (invalid address
?) needs to be identified and fixed.


 > Anyway, shoot over the code and I'll diff it up with my version and
 > then push to CVS. I have been holding off on updating the VBISAM CVS
 > to see if Trevor had time to pick up on a couple of requests.

I will e-mail you a copy.

There isn't very many differences. Just some hacks which try to
substitute some UN*X features (user id's, file locks, file attributes)
which Win32 does not support or has a different implementation.

Is there any place where the source code can be uploaded to users to 
test it ?


 > (As it is C-ISAM conform and so has it's lacking)

I think that C-ISAM compatibility is important but not critical.

And this is only because C-ISAM, lacking any formally defined standard
(1, 2), has become the industry standard.


 > Total key length is restricted to 120 bytes.

I could not verify this information. But I think it is dependent on what
type of record and if compression is used.

Even if the maximum key length is 120 bytes, most applications COBOL
will not need to exceed limit.


 > Maximum number of key parts is 8.

According to the docs:

Unlimited keys per table - Late breaking news: Decided to limit key
count to 32 for now, will make it dynamic in the future.
Up to 32 parts per key. Index depth <= 65535 levels (Highly unlikely
that > 4 or 5 levels would ever exist!)

My interpretation of this is that the number of key segments may be
limited (up to32 parts per key), the number of keys (index depth <=
65535 levels) is not very limited.


 > There is no facility to specify own key comparison routine.
 > Using manual locking, there is no way to lock a record on insert.

I could not verify this information using the documentation.

However, I did notice some comments on one of the source files, which
now I can't find, indicating a way to use your own comparison routine.


 > Note : This is still not ready for use by Cobol

I agree that further tests and development will be required.

I've written a couple of C test program which mimics a simple COBOL
application.

One program creates a primary key (no dups) and a secondary key (with
duplicates), and then performs a sequential read using the primary key.

Another program, sets a starting point and then performs a sequential
read using the secondary key.

So far, my tests indicate that even in it's current state, VBISAM could
be used to support indexed files.

So the question is:
Is VBISAM a better option than the current method using BDB ?
In my view the answer is YES.



1) ISAM
Category: Data Management [DM]
Support for programs using the indexed sequential file access method.
http://www.opengroup.org/public/prods/dmm4.htm

2) D010 Indexed Sequential Access Method (ISAM) 8/90
http://www.opengroup.org/public/pubs/catalog/d010.htm
(Publication is no longer available)