tiny-cobol-users

Re: [Tiny-cobol-users] changes in accept using ncurses/screen section.

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

Pam & Harold Norris wrote:

 > I have been a firm believer in tc for years and it
 > hasn't failed me yet.
 > I am, however, having a time with changes which went
 > into effect between versions .58 and .62/.63
 >
 > I am accepting data on the screen using ACCEPT ON EXCEPTION.
 > According to what I saw in screenio.c, this means that the
 > data is being accepted using the SCREEN mode.
 > What the problem is, is: if data is displayed on
 > the screen at line 1 position 5 and I accept a 14 character
 > variable at line 1 position 1, the data located at position
 > is instantly erased.
 > Using the same accept commands with tc version .58, the existing
 > data stays put until you input NEWdata at its location.
 >
 > Is there any way to fix this, either by modifying tc or my program??

If I understand your query correctly, the problem is that the 14 
variable at line 1 position 1 gets initialized with blanks, assuming it 
is an alphanumeric identifier.

First of all are you using 'ACCEPT screen-n ...' or 'ACCEPT identifier-n 
AT LINE/POS ...' ?

Second is this expected behavior as found with other compilers, or 
defined on some COBOL standard ?

And finally, I don't think the behavior you are suggesting would work 
for numeric variables, as these should display from RIGHT to LEFT.
It is not what TC currently does, but it is the behavior on I*M mainframes.

In any case using group variables will not work, as the variable gets 
initialized with blanks.
And I don't see an option that disables the initialization.
Maybe the variable should not get initialized with blanks (zeros), but 
let the user do so, or not (risky).

Re: [Tiny-cobol-users] options for subprogram linkages.

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

John R. Culleton wrote:

> David Essex wrote:
> ...
>> You can check which one TC is using the following commands.
>>
>> $env | grep 'TCOB_'
>> TCOB_OPTIONS_PATH=/usr/local/share/htcobol
>> TCOB_RTCONFIG_PATH=/usr/local/share/htcobol
>  
> It doesn't seem to be using any of them.  
 > Do I need a statement in my /etc/profile per the above?

At compile-time TC (htcobol) will try find the compile-time resource 
file 'htcobolrc'.
At run-time the TC RTL will load the run-time resource file 'htrtconf'.

The search sequence is as follows:

1) Use the environment variables TCOB_OPTIONS_PATH and 
TCOB_RTCONFIG_PATH, and if the files exist load those files.

2) If the environment variables are not defined, or the resource files 
are not found in that path, use the a default path set at TC configure 
in the file 'htconfig.h'.

3) If the above two methods fail to locate and load the files, use the 
internal defaults set when TC is configured.
This method will print a warning, as follows.

$htcobol -V
Cobol parameter file '/usr/local/share/htcobol/htcobolrc' not found - 
using configure defaults
...

The advantage of using environment variables is that you can have 
multiple resource files.
For example you can have a global (i.e. /etc/profile) and local
(i.e. $HOME/.profile or .bashrc) definitions.

The TC install process will not automatically add these 'TCOB_*' 
environment variables to the any of the profile files.

How to add these environment variables.
Bash example:
export TCOB_OPTIONS_PATH=/usr/local/share/htcobol
export TCOB_RTCONFIG_PATH=/usr/local/share/htcobol

In your case, TC is most likely using a path defined when the sources 
were configured.
The problem with this approach is that, currently, there is no way to 
echo this path. So it could be an old file.

Actually, there is one way to find the current resource path.
Temporarily move the resource directory, and then issue a 'htcobol' 
version command and see if it prints a warning, as above.

example:
$mv -i /usr/local/share/htcobol /usr/local/share/htcobol0
$htcobol -V
...

But to answer your question, do you need them NO. Should I use them, YES.

Hope this helps.

[Tiny-cobol-users] changes in accept using ncurses/screen section.

[Pam & H. N. <phn...@ve...>]

Hi all,

I have been a firm believer in tc for years and it hasn't failed me 
yet.  I am, however, having a time with changes which went into effect 
between versions .58 and .62/.63

I am accepting data on the screen using ACCEPT ON EXCEPTION.  According 
to what I saw in screenio.c, this means that the data is being accepted 
using the SCREEN mode.  What the problem is, is: if data is displayed on 
the screen at line 1 position 5 and I accept a 14 character variable at 
line 1 position 1, the data located at position is instantly erased.  
Using the same accept commands with tc version .58, the existing data 
stays put until you input NEWdata at its location.

Is there any way to fix this, either by modifying tc or my program??

Thanks for the help

Harold Norris

Re: [Tiny-cobol-users] options for subprogram linkages.

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

On Saturday 30 December 2006 15:13, David Essex wrote:
> John R. Culleton wrote:
>  > I fixed this in one htcobolrc but the system is
>  > finding another. So I will change all of them.
>
> You can check which one TC is using the following commands.
>
> $env | grep 'TCOB_'
> TCOB_OPTIONS_PATH=/usr/local/share/htcobol
> TCOB_RTCONFIG_PATH=/usr/local/share/htcobol

It doesn't seem to be using any of them.  Do I need a statement in 
my /etc/profile per the above?

-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] options for subprogram linkages.

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

John R. Culleton wrote:

 > I fixed this in one htcobolrc but the system is
 > finding another. So I will change all of them.

You can check which one TC is using the following commands.

$env | grep 'TCOB_'
TCOB_OPTIONS_PATH=/usr/local/share/htcobol
TCOB_RTCONFIG_PATH=/usr/local/share/htcobol


 >> If you are working with libraries, same youself
 >> some work by using make files.
 >
 > A script also helps such as:
 > htcobol -c -P -F -I../copybooks -I. testmain.cbl
 > htcobol -c -P  -F -I../copybooks -I. testcalled.cbl
 > gcc -o testprog testmain.o \
 > testcalled.o   -L/usr/local/lib -lhtcobol -ldb -ldl -lm
 >
 > I will generalize this to take different filenames
 > using $1, $2 etc.

Yes, that will work.

However make files will do a lot of the work for you, once setup.
They really are indispensable for projects with more than one or two 
sources.

For example if you have one sub-program which is used (statically
linked) in 5 modules (programs).
If you change that sub-program you have find and rebuild all of the
modules.
Make can detect the change and re-compile and link the dependencies
where necessary.

A trivial example can be found in 'test.code/t15'.

$make test15
htcobol -c -P -I../copybooks -I. test15.cob
htcobol -c -P -I../copybooks -I. test15a.cob
gcc -I/usr/local/include -o test15b.o -c test15b.c
gcc -o test15 test15.o test15a.o test15b.o \
     -L/usr/local/lib -lhtcobol -ldb1 -ldl -lm

$touch test15a.cob

$make test15
htcobol -c -P -I../copybooks -I. test15a.cob
gcc -o test15 test15.o test15a.o test15b.o  \
     -L/usr/local/lib -lhtcobol -ldb1 -ldl -lm

Hint:
If you plan to use make files for COBOL projects, copy the 
'test.code/config/COB.rules.in' file to 'config' directory 
(/usr/local/config ?).
Adding the following lines to the make file will enable make to build 
objects from files with COBOL suffixes.

COB=htcobol
COPYBOOKS= -I../copybooks
COBFLAGS=-P ${COPYBOOKS}
...
include ${prefix}/config/COB.rules.in

# contents of 'COB.rules.in'
# Rules for compiling COBOL sources
.SUFFIX: .cob .cbl .o
%.o: %.cob
	$(COB) -c  $(COBFLAGS) $<
#	$(COB) $(COBFLAGS) $<
%.o: %.cbl
	$(COB) -c $(COBFLAGS) $<
#	$(COB) $(COBFLAGS) $<


Hope this helps.

Re: [Tiny-cobol-users] options for subprogram linkages.

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

On Friday 29 December 2006 18:24, David Essex wrote:

> # 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 fixed this in one htcobolrc but the system is finding another. So I will 
change all of them.
> If you are working with libraries, same youself some work by using make
> files.

>
A script also helps such as:
htcobol -c -P -F -I../copybooks -I. testmain.cbl
htcobol -c -P  -F -I../copybooks -I. testcalled.cbl
gcc -o testprog testmain.o \ 
testcalled.o   -L/usr/local/lib -lhtcobol -ldb -ldl -lm

I will generalize this to take different filenames using $1, $2 etc. 


 
> Hope this helps.
>
It surely does. Thanks for your patience. 

John Culleton

Re: [Tiny-cobol-users] options for subprogram linkages.

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

John R. Culleton wrote:

 > ...
 > That didn't work so I built two toys and compiled/linked them thus:
 >
 > htcobol -F -c testmain.cbl
 > htcobol -F -c testcalled.cbl
 > gcc -o testprog testmain.o testcalled.o
 >
 > On the gcc step I got multiple errors, such as:
 > .....
 > testcalled.o(.text+0x92): In function `TESTCALLED':
 > : undefined reference to `tcob_move'
 > testcalled.o(.text+0xb7): In function `TESTCALLED':
 > : undefined reference to `tcob_stop_run'
 > ...
 > I think I am missing a library call somewhere.
 > Which library and on which compile command string?
 > Or is it something else?

You neglected to add the libraries for the link step.

Normally TC (htcobol) will add the libraries to the linkage, as shown below.

If however you choose to use GCC directly, you have to add the libraries
for the link step.

$make
htcobol -c -P -I../copybooks -I. test03.cob
gcc -o test03 test03.o  -L/usr/local/lib -lhtcobol -ldb1 -lm -ldl

$htcobol -v -test03.cob
as -o test03.o test03.s
gcc -o test03 test03.o -L/usr/local/lib -lhtcobol -ldb1 -ldl -lm

$make -n test15
htcobol -c -P -I../copybooks -I. test15.cob
htcobol -c -P -I../copybooks -I. test15a.cob
gcc -I/usr/local/include -o test15b.o -c test15b.c
gcc -o test15 test15.o test15a.o test15b.o \
-L/usr/local/lib -lhtcobol -ldb -ldl -lm

Hint:
If you prefer to use a specific format (fixed or free) for your source
files, change the default to that format in the TC resource file
(htcobolrc).

# 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

If you are working with libraries, same youself some work by using make
files.

Hope this helps.

Re: [Tiny-cobol-users] Error while loading shared libraries

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

Vince Coen wrote:

 > ...

The problems you have encountered with shared libraries are not TC, or 
COBOL, specific.
This is a UN*X administration issue, and chances are that you will 
encounter this problem again.

A quick solution is to move the relavent objects from the their 
'/usr/local' to the '/usr' sub-directories.

As for running the test_suite perl script, in the 'lib' directory type 
'make clean' and then 'make static-libs'.
This should enable you to run the test_suite perl script with out any 
modifications.

 > ...
 > I'm assuming the RT shared libs are similar to MF?

I'm not familiar with MF products, so I can't comment.


 > Allowing for strong Ram facilities Can I not just
 > compile the whole program to link all required
 > modules and libraries together and would this be the
 > fastest way to load and run?

I'm not sure what mean.
Have you looked at the 'htcobrun' in the 'cobrun' directory.


 > Also using the configure option of MF compatable what
 > exactly does this do?

There is only two options, really.

The first relates to the 'ACCEPT identifier FROM COMMAND-LINE' verb.
In UN*X the first command line parameter is always the actual program 
name (argv[0]).
Some COBOL compilers do include the program name (ARGV[1] ... argv[n]).
See 'test.code/test17' for an example.

The second relates to the 'SELECT file-name ASSIGN TO EXTERNAL 
{identifier | literal}' verb. The 'EXTERNAL' option relates the internal 
file-name to actual file-name using environment variables.
Some COBOL compilers add a prefix, such as 'DD_' to the environment 
variables.
See 'test.code/test19' for an example.


There is also the 'DISPLAY/ACCEPT LINE/POS' variation, which is MF 
specific. But that is always usable.


 > I cannot see any documentation on this or what language set
 > is available in the compiler at this time.

Well, English only I'm afraid.

There is an configure option for some languages. But even those are 
limited to man, command line help files but no run-time.
And even the very limited documentation translations are not very 
current, as I could not get any volunteers to do the translations.


 > Is the CVS version more up to date and reasonably stable or
 > is it best to stick to the archives in the download area?

Well, the CVS version is relatively stable, but there is not much 
difference between the CVS and 0.63 versions.


 > Out of interest what problems would there be to use tc
 > on a 64 bit system
 > i.e., Dual 2 core E6600 using a mandriva x86-64 Linux system
 > install (It uses both 32 and 64 bit libraries?

I have no idea even if TC will compile an run properly on a 64-bit system.
Personally, I have no plans to do any work on TC for 64-bit systems.

Re: [Tiny-cobol-users] Error while loading shared libraries

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

Vince Coen wrote:

 > ...
 > Now with LD_LIBRARY_PATH set I have run the
 > test_suite make file and programs.
 >
 > The Only failures I get are with srt03, srt05, perf06
 > but both srtio03/05
 > compile and execute showing the following respectively:
 > ...
 > As for perf06 I get:
 > $ htcobol perf06
 > perf06.cob: Assembler messages:
 > perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined
 > perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined
 >
 > I am running gcc v 4.1.1.
 >
 > Any Ideas for these.

It compiles and runs without these problems on GCC 2x - 3x.

AFAIK, no tests have been done with GCC 4x.

So I can only assume that there are some problems related to the GCC 4x
tool-chain, specifically with GAS.

Unfortunatly, I do not have access to a system with GCC 4x installed,
and thus no way to test this assertion.

Re: [Tiny-cobol-users] options for subprogram linkages.

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

On Friday 29 December 2006 02:40, David Essex wrote:
> John R. Culleton wrote:
>  > I am converting a batch of programs from a Microfocus
>  > for Unix system to TinyCobol (Linux) and am having
>  > trouble with subprogram linkages.

> As per you example above, you could use the following:
>
> htcobol -c general.cbl
> htcobol -c maps03.cbl
> gcc -o what-ever general.o maps03.o -L ...
>

That didn't work so I built two toys and compiled/linked them thus:

htcobol -F -c testmain.cbl
htcobol -F -c testcalled.cbl
gcc -o testprog testmain.o testcalled.o    
------------------------------------------------------------
On the gcc step I got multiple errors, such as:
.....
testcalled.o(.text+0x92): In function `TESTCALLED':
: undefined reference to `tcob_move'
testcalled.o(.text+0xb7): In function `TESTCALLED':
: undefined reference to `tcob_stop_run'

Here is the source of the calling program:
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. TESTMAIN.
000070 ENVIRONMENT DIVISION.
000080 
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.  
000110      Linux.
000120 OBJECT-COMPUTER. 
000230      Linux.
000140 
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.
000170     SELECT PRINTFILE ASSIGN TO PRINTER.
000180 DATA DIVISION.
000190
000200 FILE SECTION.
000210
000220 WORKING-STORAGE SECTION.
000230
             01  TESTSTRING PIC X(80).
000240 PROCEDURE DIVISION.
000250 001-MAIN-PROCEDURE.
000260     DISPLAY "testmain".
             CALL "TESTCALLED" USING TESTSTRING.
              DISPLAY TESTSTRING.   
000270          STOP RUN.
----------------------------------------------------
...and here is the called program:
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. TESTCALLED.
000070 ENVIRONMENT DIVISION.
000080 
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.  
000110      Linux.
000120 OBJECT-COMPUTER. 
000230      Linux.
002014 DATA DIVISION.
000150 LINKAGE SECTION.
000230  01 TESTIT PIC X(80).
000240 PROCEDURE DIVISION USING TESTIT.
000250 001-MAIN-PROCEDURE.
000260     DISPLAY "testcalled".
                 MOVE "made it!" to TESTIT.
                 EXIT PROGRAM. 
-------------------------------------------------------

I think I am missing a library call somewhere.  Which library and on which 
compile command string? Or is it something else? 

Thanks again for all the help.
-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Comparing TC and OC

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

On Friday 29 December 2006 09:40, vince coen wrote:
> Hi All;
>
> Has anyone compared the facilities and functionality between Open Cobol and
> Tiny Cobol?
>
> If so is it documented anywhere?
>
> Vince.

I know the following:
1. Tiny is no longer under development by the original creator.
2. Tiny has both positional DISPLAY statements and the SCREEN SECTION.
3. There is an example in the test.code library of Tiny of interface via C 
code to the Tcl/Tk package, which opens up the prospect of a windowed GUI.
4. Documentation in English on Tiny is sparse and for some features only 
available in Portugese. The creator is a Brazilian.
5. Tiny is built to COBOL 85 which is fine with me.  Open is over time 
incorporating some of the newer features in later standards, while not 
implementing the older interface features mentioned above. 

Anent point 5 above, in my not humble opinion COBOL started downhill in COBOL 
73 and has continued to stray from the original concept of a self-documenting 
natural language business application tool. Just look at the unnecesary 
butchery on the IDENTIFICATION DIVISION.  But I digress... 

Overall I prefer Tiny for its superior interactive capablities. But Open is 
the one that is under active development AFAIK.  I am working on the code you 
lent me using Tiny. Open would be impractical for those programs. 

Others with more background will undoubtedly add to/correct my analysis above. 
 

-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Error while loading shared libraries (was: Your COBOL G/L etc. system)

[vince c. <vb...@bt...>]

Hi;


Now with LD_LIBRARY_PATH set I have run the test_suite make file and programs.

The Only failures I get are with srt03, srt05, perf06  but both srtio03/05 
compile and execute showing the following respectively:

[vince@study sortio_tests]$ export LD_LIBRARY_PATH=/usr/local/lib
[vince@study sortio_tests]$ ./srtio03
001,10

00,A0
DD;,A8
DD;,A8
DDV,A8
D
0,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA8,A8
AA0,A8
A03,A8
5D;,A8
04;,A8
SRTIO03:( 0001):( 0020):Record no  0001
SRTIO03:(-3800):( 0010):Record no  0002
SRTIO03:( 2220):( 0019):Record no  0003
SRTIO03:( 2220):( 0009):Record no  0004
SRTIO03:( 2162):( 0018):Record no  0005
SRTIO03:( 1620):( 0008):Record no  0006
SRTIO03:( 1887):( 0017):Record no  0007
SRTIO03:( 1887):( 0007):Record no  0008
SRTIO03:( 1887):( 0016):Record no  0009
SRTIO03:( 1887):( 0006):Record no  0010
SRTIO03:( 1887):( 0015):Record no  0011
SRTIO03:( 1887):( 0005):Record no  0012
SRTIO03:( 1887):( 0014):Record no  0013
SRTIO03:( 1887):( 0013):Record no  0014
SRTIO03:( 1887):( 0004):Record no  0015
SRTIO03:( 1887):( 0003):Record no  0016
SRTIO03:( 1870):( 0012):Record no  0017
SRTIO03:( 1703):( 0002):Record no  0018
SRTIO03:( 0720):( 0011):Record no  0019
SRTIO03:( 0060):( 0001):Record no  0020
[vince@study sortio_tests]$ 

and for srtio05
[vince@study sortio_tests]$ ./srtio05
SRTIO05:( 0001):( 0020):Record no  0001
SRTIO05:(-3800):( 0010):Record no  0002
SRTIO05:( 2220):( 0019):Record no  0003
SRTIO05:( 2220):( 0009):Record no  0004
SRTIO05:( 2162):( 0018):Record no  0005
SRTIO05:( 1620):( 0008):Record no  0006
SRTIO05:( 1887):( 0017):Record no  0007
SRTIO05:( 1887):( 0007):Record no  0008
SRTIO05:( 1887):( 0016):Record no  0009
SRTIO05:( 1887):( 0006):Record no  0010
SRTIO05:( 1887):( 0015):Record no  0011
SRTIO05:( 1887):( 0005):Record no  0012
SRTIO05:( 1887):( 0014):Record no  0013
SRTIO05:( 1887):( 0013):Record no  0014
SRTIO05:( 1887):( 0004):Record no  0015
SRTIO05:( 1887):( 0003):Record no  0016
SRTIO05:( 1870):( 0012):Record no  0017
SRTIO05:( 1703):( 0002):Record no  0018
SRTIO05:( 0720):( 0011):Record no  0019
SRTIO05:( 0060):( 0001):Record no  0020
[vince@study sortio_tests]$ 

As for perf06 I get:
[vince@study perform_tests]$ htcobol perf06
perf06.cob: Assembler messages:
perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined
perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined
[vince@study perform_tests]$ 

I am running gcc v 4.1.1.

Any Ideas for these.

Vince.

[Tiny-cobol-users] Comparing TC and OC

[vince c. <vb...@bt...>]

Hi All;

Has anyone compared the facilities and functionality between Open Cobol and 
Tiny Cobol?

If so is it documented anywhere?

Vince.

Re: [Tiny-cobol-users] options for subprogram linkages.

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

On Friday 29 December 2006 02:40, David Essex wrote:
> John R. Culleton wrote:
>  > I am converting a batch of programs from a Microfocus
>  > for Unix system to TinyCobol (Linux) and am having
>  > trouble with subprogram linkages.
>  > Here is the situation:
>  >
>  > In main program "general" I have calls to subprogram
>  > maps03 in the form:
>  > CALL "maps03" USING MAPS03-WS.
>  > ...
>  > The subprogram contains the line:
>  > ...
>  > PROCEDURE DIVISION USING MAPA03-WS.
>  > ...
>  > Let's assume static linkage (simpler?) and Legacy
>  > layout
>  >
>  > 1. What options should I have on the compile of maps03.cbl?
>  >
>  > 2. What options should I have on the compile of general.cbl?
>
> It really not difficult, once you understand some basics.
>
> First of all COBOL, unlike other languages such as C, does not have a
> default entry point. Meaning the first program (function) to be executed
> withing the binary.
>
> TC will try to determine which is a main-program, and which are
> sub-programs. It does so by using the 'STOP RUN', for main, and 'EXIT
> PROGRAM', for sub-programs.
> Once TC detects a main-program, it will automatically generate a entry
> point 'main', and the code to call the COBOL main-program.
>
> Since this method does not work 100% of the time, you can override this
> behaviour using the command line, or resourse file options. Then it will
> up to the programmer to define the entry point.
>
> Note that TC version 0.63, does not allow the use of '-' (dash) in a
> program name (PROGRAM-ID). This is due to a x86 assembler limitation.
>
> Finally, the type of COBOL CALL will determine which type of linkage used.
> If you use CALL 'literal', then compile time linkage is used.
> If you use CALL identifier, then run-time linkage is used. Meaning that
> the TC run-time library will try to find and load the library containing
> the sub-program.
>
> Note that run-time linkage works well on UN*X (ELF), but not so well on
> Win32 (PE-COFF).
>
>  > Currently when compiled general.cbl can't find subprogram
>  > maps03 which was compiled with the -a option.
>  > I also compiled it with the -c option.
>  > All are in the same directory.
>  > The assembler pass says:
>  >
>  > general.o(.text+0x3dc): In function `general':
>  > : undefined reference to `maps03'
>
> Actually that is a linker error.
>
> As per you example above, you could use the following:
>
> htcobol -c general.cbl
> htcobol -c maps03.cbl
> gcc -o what-ever general.o maps03.o -L ...
>
> Or if you have a library of routines, you could use the following:
>
> htcobol -c sub01.cbl
> ...
> htcobol -c subNN.cbl
> ar cr libsubs.a sub01.o ... subNN.o
> ranlib libsubs.a
>
> gcc -o what-ever general.o -L... -lsubs ...
>
>
> There are some examples in the 'test.code/t07' and 'test.code/t15'
> directories.
> Or if you would like some advanced examples see the 'test.code/t33' and
> 'cobrun/test.code' directories.
>
>
> Hope this helps.
>
>
>

Thanks much. My next question was going to be: "Which examples in test.code 
show linkages to subprograms?" But you answered it ahead of time.

The Tiny-Cobol manual remains unfinished, which is a pity. I'll substitute 
your message above for the missing piece. 
-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Error while loading shared libraries (was: Your COBOL G/L etc. system)

[vince c. <vb...@bt...>]

Hi;

On Friday 29 December 2006 07:36, David Essex wrote:
> Vince Coen wrote:
>  > I Have now installed tc .63  but getting a lot of errors.
>  > Can't run the test_suite without a lot of errors.
>  > Ditto when compiling hello world.
>  > Can someone help?
>  > ...
>  > When running ./hello
>  >
>  > It gives me:
>  >
>  > ./hello: error while loading shared libraries:
>  > libhtcobol.so.0: cannot open
>  > shared object file: No such file or directory
>
> This seams to be a very common problem for some reason.
>
> The linker needs to locate the RT shared library 'libhtcobol.so.0'.
>
> The TC configure will install to a prefix='/usr/local' by default, so
> the shared library 'libhtcobol.so.0' should be located in the
> 'usr/local/lib' directory.

Yep, its in /usr/local/lib as in:
[vince@study ~]$ ls -la /usr/local/lib/libhtcobol.*
-rwxr-xr-x 1 root root 152812 Dec 27 22:40 /usr/local/lib/libhtcobol.a*
lrwxrwxrwx 1 root root     35 Dec 27 
16:22 /usr/local/lib/libhtcobol.so -> /usr/local/lib/libhtcobol.so.0.63.0*
lrwxrwxrwx 1 root root     35 Dec 27 
16:22 /usr/local/lib/libhtcobol.so.0 -> /usr/local/lib/libhtcobol.so.0.63.0*
-rwxr-xr-x 1 root root 153405 Dec 27 
16:22 /usr/local/lib/libhtcobol.so.0.63.0*
[vince@study ~]$ 


>
> Unfortunatly, some of the distributions do not use the 'usr/local ...'
> directories, thus the linker is not set up to search that path.
>
> So you can you can do either of the following:
>
> 1) Set the 'LD_LIBRARY_PATH' enviroment variable (bash: export
> LD_LIBRARY_PATH=usr/local/lib), which is a temporary solution.

Now done that.

> 2) Use the 'ldconf' command to add the path to the linker search path.

I do not seem to have that command. Where is it from?

> 3) Configure TC using the `--prefix=/usr' option, then compile and
> install it.

have added --prefix=/usr/local

>  > I need to solve this first before attempting the
>  > test suite again as most of
>  > the test produce similar to this:
>  > ...
>
> The test suite on version 0.63 is set up to expect to find the compiler,
> RTL and resouce files in the source code sub-directories above the
> 'test_suite' directory (i.e. ../compiler, ../lib, etc.).
>
> So it is best to just configure and compiler TC, then run the test suite.
> Otherwise, modifications to the perl script are required.

Nope, on this you have lost me. I understand the bit about modding the perl 
script though.

>
> Hint: Before you run the test suite, remove the RT shared library (and
> links) or compile the RTL a static library only.

Lost me on this as well.

I'm assuming the RT shared libs are similar to MF?  Allowing for strong Ram 
facilities Can I not just compile the whole program to link all required 
modules and libraries together and would this be the fastest way to load and 
run?

Also using the configure option of MF compatable what exactly does this do?

I cannot see any documentation on this or what language set is available in 
the compiler at this time.

Is the CVS version more up to date and reasonably stable or is it best to 
stick to the archives in the download area?

Out of interest what problems would there be to use tc on a 64 bit system 
i.e., Dual 2 core E6600 using a mandriva x86-64 Linux system install (It uses 
both 32 and 64 bit libraries?

Vince.

Re: [Tiny-cobol-users] Open source COBOL G/L?

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

On Friday 29 December 2006 02:48, David Essex wrote:
> John R. Culleton wrote:
>  > Unfortunately the source files and the executables
>  > are at the bottom of our landfill, along with the
>  > 8 inch floppies and the Tandy 6000.

>  > All I have left is some docementation and the source
>  > listings from two utilities, a screen writer and a
>  > menu maker.
>  > I threw out most of the source about 15 years ago.
>
> Seams to be common practice, even with mainframe shops, to discard the
> sources.
>
Usually this happens when the outfit is reorganized and/or moves to new space.
In my case the (new) wife insisted that the basement be converted from dungeon 
to family room, which meant covering over my ugly but useful built in 
shelving, which meant---. But I should have squirreled away the source 
listings nevertheless. Who knew?

-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Section and printing

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

Larry Jungers wrote:

 > Greetings to all. I tested OC and TC a couple of
 > years ago but gave up because some of the batch
 > programs where just to large to compile and
 > there was the issue of talking to a windows printer.
 >
 > Have remained on the list all this time and read
 > with interest what various people are trying to accomplish.
 > So maybe some changes have been made that might get
 > me back to testing once again.
 >
 > The programs where all written in M*cro F*cus Cobol
 > and several of the programs performed edits and file
 > updates.
 > Due to there size the programs where broken up into
 > SECTIONS. Is this now supported?

Yes, SECTIONS have been supported for quite a while.

However, they have not substantially tested, so I'm not sure if TC
conforms to the COBOL standard.


 > The other issue I had was the printer side.
 > Would like to have a way to set the document name, port,
 > and copies.
 > In the old batch system a print spooler was used and
 > that allowed for report name, copies, hold Y/N and a
 > few other parameters before the Cobol program was run.
 > With windows the way it is today and a print spooler (the
 > two I know of) can not coexist together and function.
 > Has the print side been addressed or is there a work around?

Even on the old batch system spooler (CICS also) the OS, or rather some
sub-system, sends the file to the printer. All the COBOL program has to
do is ASSIGN the file to some device defined by the system as a (vitual) 
printer.

On Win32 (and UN*X), some other program, or the COBOL program itself,
has to send the file to the print spooler.

On UN*X it is easy as you can either emulate the 'batch system' with
some script, or just add a CALL 'system' ... within the COBOL program.

On Win32 it's more compilcated, as command line and GUI programs are
handled differently by the OS. Either way you have to deal with the 
Win32 API.

The Win32 work around ? Compile the COBOL programs as DLL's, and write 
some sort of GUI front end as batch substitute.

Hint: To define a COBOL program as a Win32 GUI program, just add the
'-mwindows' GCC command line option to the link step.


 > Would love to convert this to run on Linux but that's
 > another issue.

In my experience, COBOL programs compiled with TC, will run faster on UN*X.

Hope this helps.

Re: [Tiny-cobol-users] Open source COBOL G/L?

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

John R. Culleton wrote:

 > Unfortunately the source files and the executables
 > are at the bottom of our landfill, along with the
 > 8 inch floppies and the Tandy 6000.

Unfortunate, as some of these old and rare machines are now
considered antiques, and may be worth some money.

Did you know that you can now buy kits to assemble your own vintage era 
Apple I.

And in some parts of silicon valley, it is Geek-sheik to attend seminars 
were you can assemble and test one of these kits.

... one too many cafe-latte, I think.

 > All I have left is some docementation and the source
 > listings from two utilities, a screen writer and a
 > menu maker.
 > I threw out most of the source about 15 years ago.

Seams to be common practice, even with mainframe shops, to discard the
sources.

Re: [Tiny-cobol-users] options for subprogram linkages.

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

John R. Culleton wrote:

 > I am converting a batch of programs from a Microfocus
 > for Unix system to TinyCobol (Linux) and am having
 > trouble with subprogram linkages.
 > Here is the situation:
 >
 > In main program "general" I have calls to subprogram
 > maps03 in the form:
 > CALL "maps03" USING MAPS03-WS.
 > ...
 > The subprogram contains the line:
 > ...
 > PROCEDURE DIVISION USING MAPA03-WS.
 > ...
 > Let's assume static linkage (simpler?) and Legacy
 > layout
 >
 > 1. What options should I have on the compile of maps03.cbl?
 >
 > 2. What options should I have on the compile of general.cbl?

It really not difficult, once you understand some basics.

First of all COBOL, unlike other languages such as C, does not have a
default entry point. Meaning the first program (function) to be executed
withing the binary.

TC will try to determine which is a main-program, and which are
sub-programs. It does so by using the 'STOP RUN', for main, and 'EXIT
PROGRAM', for sub-programs.
Once TC detects a main-program, it will automatically generate a entry
point 'main', and the code to call the COBOL main-program.

Since this method does not work 100% of the time, you can override this
behaviour using the command line, or resourse file options. Then it will
up to the programmer to define the entry point.

Note that TC version 0.63, does not allow the use of '-' (dash) in a
program name (PROGRAM-ID). This is due to a x86 assembler limitation.

Finally, the type of COBOL CALL will determine which type of linkage used.
If you use CALL 'literal', then compile time linkage is used.
If you use CALL identifier, then run-time linkage is used. Meaning that
the TC run-time library will try to find and load the library containing
the sub-program.

Note that run-time linkage works well on UN*X (ELF), but not so well on
Win32 (PE-COFF).


 > Currently when compiled general.cbl can't find subprogram
 > maps03 which was compiled with the -a option.
 > I also compiled it with the -c option.
 > All are in the same directory.
 > The assembler pass says:
 > general.o(.text+0x3dc): In function `general':
 > : undefined reference to `maps03'

Actually that is a linker error.

As per you example above, you could use the following:

htcobol -c general.cbl
htcobol -c maps03.cbl
gcc -o what-ever general.o maps03.o -L ...

Or if you have a library of routines, you could use the following:

htcobol -c sub01.cbl
...
htcobol -c subNN.cbl
ar cr libsubs.a sub01.o ... subNN.o
ranlib libsubs.a

gcc -o what-ever general.o -L... -lsubs ...


There are some examples in the 'test.code/t07' and 'test.code/t15'
directories.
Or if you would like some advanced examples see the 'test.code/t33' and
'cobrun/test.code' directories.


Hope this helps.

[Tiny-cobol-users] Error while loading shared libraries (was: Your COBOL G/L etc. system)

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

Vince Coen wrote:

 > I Have now installed tc .63  but getting a lot of errors.
 > Can't run the test_suite without a lot of errors.
 > Ditto when compiling hello world.
 > Can someone help?
 > ...
 > When running ./hello
 >
 > It gives me:
 >
 > ./hello: error while loading shared libraries:
 > libhtcobol.so.0: cannot open
 > shared object file: No such file or directory

This seams to be a very common problem for some reason.

The linker needs to locate the RT shared library 'libhtcobol.so.0'.

The TC configure will install to a prefix='/usr/local' by default, so
the shared library 'libhtcobol.so.0' should be located in the
'usr/local/lib' directory.

Unfortunatly, some of the distributions do not use the 'usr/local ...'
directories, thus the linker is not set up to search that path.

So you can you can do either of the following:

1) Set the 'LD_LIBRARY_PATH' enviroment variable (bash: export
LD_LIBRARY_PATH=usr/local/lib), which is a temporary solution.

2) Use the 'ldconf' command to add the path to the linker search path.

3) Configure TC using the `--prefix=/usr' option, then compile and
install it.


 > I need to solve this first before attempting the
 > test suite again as most of
 > the test produce similar to this:
 > ...

The test suite on version 0.63 is set up to expect to find the compiler,
RTL and resouce files in the source code sub-directories above the
'test_suite' directory (i.e. ../compiler, ../lib, etc.).

So it is best to just configure and compiler TC, then run the test suite.
Otherwise, modifications to the perl script are required.

Hint: Before you run the test suite, remove the RT shared library (and
links) or compile the RTL a static library only.

Hope this helps.

[Tiny-cobol-users] Section and printing

[Larry J. <lju...@sb...>]

Greetings to all. I tested OC and TC a couple of years ago but gave up because some of the batch programs where just to large to compile and there was the issue of talking to a windows printer.

Have remained on the list all this time and read with interest what various people are trying to accomplish. So maybe some changes have been made that might get me back to testing once again.

The programs where all written in Micro Focus Cobol and several of the programs performed edits and file updates. Due to there size the programs where broken up into SECTIONS. Is this now supported?

The other issue I had was the printer side. Would like to have a way to set the document name, port, and copies.  In the old batch system a print spooler was used and that allowed for report name, copies, hold Y/N and a few other parameters before the Cobol program was run. With windows the way it is today and a print spooler (the two I know of) can not coexist together and function.
Has the print side been addressed or is there a work around?

Would love to convert this to run on Linux but that's another issue.

Thanks in advance

[Tiny-cobol-users] Fwd: Re: Your COBOL G/L etc. system.

[vince c. <vb...@bt...>]

Hi all;


I Have now installed tc .63  but getting a lot of errors.
Can't run the test_suite without a lot of errors. Ditto when compiling hello
world.   Can someone help?

I have in my ,bash_profile

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

export TCOB_DIR=3D/home/vince
export TCOB_PPDIR=3D/usr/local/share/htcobol
export TCOB_OPTIONS_PATH=3D/usr/local/share/htcobol
export TCOB_LD_LIBRARY_PATH=3D/home/vince/cobolsrc/libs
CCX=3Dgcc; export CCX
LD=3Dgcc; export LD
ASM=3Das; export ASM

There is nothing in cobolsrc/libs

In htcobolrc :
COPYBOOK_PATH: /usr/local/share/htcobol/copybooks;.;

PGM_SUFFIXES: .cob:.COB:.cbl:.CBL:
PGM_FORMAT_FREE
PGM_ENTRY_POINT_AUTO
COMPILE_DEFAULT: PCAL
NODEBUG_LINES
NOLIST
PGMLIST_SUFFIX: .lst
XREF
ASX_CMD: as
CCX_CMD: gcc
ARX_CMD: ar
RANLIBX_CMD: ranlib
SHLIB_NAME_DEFAULT: lib$.so
LD_PATH: -L/usr/local/lib -L/usr/lib -L/opt/cobol/lib
#LD_PATH:
#LD_PATH: -L/home/vince/temp/lib
LD_HT1_LIBS: -lhtcobol
LD_MATH_LIBS: -lm
LD_READLINE_LIBS: -lreadline
LD_EXTRA_LIBS: -ldl
LD_DCALL_LIBS: -ldl
LD_TERM_LIBS: -lncurses
LD_IO_LIBS: -ldb-4
#
LD_FLAGS:


When running htcobol it produces:

[vince@study development]$ ls -la hello*
=2Drwxr-xr-x 1 vince vince 8136 Dec 28 16:32 hello*
=2Drw-r--r-- 1 vince vince   98 Dec 28 00:37 hello.cbl
=2Drw-r--r-- 1 vince vince 1470 Dec 28 15:46 hello.lst

When running ./hello

It gives me:

=2E/hello: error while loading shared libraries: libhtcobol.so.0: cannot op=
en
shared object file: No such file or directory

I need to solve this first before attempting the test suite again as most of
the test produce similar to this:

########################################################################
# Validate Alph to Alphanumeric moves                                  #
# Test Directory: format_tests              Test File test01           #
########################################################################

Program test01 returned an unexpected return code
  Validate Alph to Alphanumeric moves                                : FAIL=
ED

########################################################################
# Validate Alpha to Formatted Alphanumeric (space) moves               #
# Test Directory: format_tests              Test File test01a          #
########################################################################

Program test01a returned an unexpected return code
  Validate Alpha to Formatted Alphanumeric (space) moves             : FAIL=
ED

########################################################################
# Validate Alpha to Formatted Alphanumeric (slash) moves               #
# Test Directory: format_tests              Test File test01b          #
########################################################################

Program test01b returned an unexpected return code

The log looks like this (when running make > test.log 2> test.err:
perl cobol_test.pl

Cobol test suite version v010712


Checking to see if your kit is complete
Your kit looks complete.
+++++++++++++++++++++++++

#######################################################
# Testing compiler:                                   #
#       .version        "01.01"  #
#######################################################
Compiling program ctest01 ... Compile return code =3D 16
Compiling program ctest01a ... Compile return code =3D 12
Compiling program ctest01b ... Compile return code =3D 12
Compiling program ctest01c ... Compile return code =3D 0
Compiling program ctest01d ... Compile return code =3D 12
Compiling program ctest01e ... Compile return code =3D 0
Compiling program ctest02 ... Compile return code =3D 16
Compiling program ctestws01 ... Compile return code =3D 0
Compiling program ctestws02 ... Compile return code =3D 0

and the error log like this:

foo_c.c: In function =E2=80=98main=E2=80=99:
foo_c.c:4: warning: incompatible implicit declaration of built-in
function =E2=80=98prin
tf=E2=80=99
Program ctest01 failed to properly compile
Program ctest01a failed to properly compile
Program ctest01b failed to properly compile
Program ctest01d failed to properly compile
Program ctest02 failed to properly compile
Program ctestws03 failed to properly compile
Program ctest04 failed to properly compile
Program ctest05 failed to properly compile
Program ctestsl02 failed to properly compile
Program ctestsl04 failed to properly compile
Program ctestsl06 failed to properly compile
Program ctestsl08 failed to properly compile
Program ctestp-initialize1 failed to properly compile
=2E/test01: error while loading shared libraries: libhtcobol.so.0: cannot o=
pen
sha
red object file: No such file or directory
Program test01 returned an unexpected return code

gcc -v produces:

[vince@study Desktop]$ gcc -v
Using built-in specs.
Target: i586-mandriva-linux-gnu
Configured=20
with: ../configure --prefix=3D/usr --libexecdir=3D/usr/lib --with-slibdir=
=3D/lib --mandir=3D/usr/share/man=20
=2D-infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --en=
able-checking=3Drelease=20
=2D-enable-languages=3Dc,c++,ada,fortran,objc,obj-c++,java --host=3Di586-ma=
ndriva-linux-gnu --with-cpu=3Dgeneric=20
=2D-with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-cloc=
ale=3Dgnu --disable-libunwind-exceptions=20
=2D-enable-java-awt=3Dgtk --with-java-home=3D/usr/lib/jvm/java-1.4.2-gcj-1.=
4.2.0/jre --enable-gtk-cairo --enable-ssp=20
=2D-disable-libssp
Thread model: posix
gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)


Any Ideas?

Thanks for any help,

Vince.

=2D------------------------------------------------------

[Tiny-cobol-users] options for subprogram linkages.

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

I am converting a batch of programs from a Microfocus for Unix system to 
TinyCobol (Linux)  and am having trouble with subprogram linkages.  Here is 
the situation:

In main program "general" I have calls to subprogram maps03 in the form:
 CALL     "maps03" USING MAPS03-WS. 

This is a WORKING STORAGE copybook with the contents
 310     61 [00]: 000000 COPY "wsmaps03.cob".
   311      1 [01]: 774001**********
   312      2 [01]: 774002* MAPS03 *
   313      3 [01]: 774003**********
   314      4 [01]: 774004
   315      5 [01]: 774005 01  MAPS03-WS.
   316      6 [01]: 774006     03  U-DATE          PIC x(10).
   317      7 [01]: 774007     03  FILLER  REDEFINES  U-DATE.
   318      8 [01]: 774008       05  U-DAYS        PIC 99.
   319      9 [01]: 774009       05  FILLER        PIC X.
   320     10 [01]: 774010       05  U-MONTH       PIC 99.
   321     11 [01]: 774011       05  FILLER        PIC X.
   322     12 [01]:              05  u-cc          pic 99.
   323     13 [01]: 774012       05  U-YEAR        PIC 99.
   324     14 [01]: 774013     03  U-BIN           PIC 9(8)       comp.

 
The subprogram contains the line:

PROCEDURE	       DIVISION  USING	MAPA03-WS.

and in the linkage section:
000860 LINKAGE SECTION.
    73     73 [00]: 000870*---------------
    74     74 [00]: 000880*
    75     75 [00]: 000890**********
    76     76 [00]: 000900* MAPS03 *
    77     77 [00]: 000910**********
    78     78 [00]: 000920
    79     79 [00]: 000930 01  MAPA03-WS.
    80     80 [00]: 000940     03  A-DATE             PIC X(10).
    81     81 [00]: 000950     03  FILLER  REDEFINES  A-DATE.
    82     82 [00]: 000960       05  A-DAYS           PIC 99.
    83     83 [00]: 000970       05  FILLER           PIC X.
    84     84 [00]: 000980       05  A-MONTH          PIC 99.
    85     85 [00]: 000990       05  FILLER           PIC X.
    86     86 [00]:              05  A-CC             pic 99.
    87     87 [00]: 001000       05  A-YEAR           PIC 99.
    88     88 [00]: 001010     03  A-BIN              PIC 9(8)       comp.

 
Let's assume static linkage (simpler?) and Legacy layout  

1. What options should I have on the compile of maps03.cbl?

2. What options should I have on the compile of general.cbl?

Currently when compiled general.cbl can't find subprogram maps03 which was 
compiled with the -a option.  I also compiled it with the -c option. All are 
in the same directory.  The assembler pass says:

general.o(.text+0x3dc): In function `general':
: undefined reference to `maps03'

John Culleton

Re: [Tiny-cobol-users] Open source COBOL G/L?

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

On Sunday 24 December 2006 20:12, David Essex wrote:
> John R. Culleton wrote:
>  > Eons ago (well about 20 years ago) I developed my own
>  > version of a G/L system in RM COBOL and offered it for
>  > sale even.
>  > Well, I have lost all the source code and don't have
>  > the energy or perhaps even the skill level to start all over.
>  > ...
>
> If per chance you still have the binaries, and they happen to be DOS
> binaries (16 bit), you may still be able to use them on Linux and Win32.
>
> I have an old 16-bit (DOS) COBOL compiler, I picked up at a yard sale.
> Using DOSEMU and freeDOS, I can compile and run COBOL 16-bit DOS
> programs on Linux.
>
> It will also run on Win32, well Win9x, I have not tried it on W2K/XP.
> It does require a special 16-bit linker to create executables on Win32,
> which can (or useto) be found on one of the MS web sites for free.
>
> Still, a lot of these COBOL compilers create some sort of object code,
> which require a run-time program, and this does complicate matters.
> But still, DOSEMU and freeDOS are easy to install and run, so it may be
> worth a try.
>
> Anyway, hope this helps.

Unfortunately the source files and the executables are at the bottom of our 
landfill, along with the 8 inch floppies and the Tandy 6000.  All I have left 
is some docementation and the source listings from two utilities, a screen 
writer and a menu maker.  I threw out most of the source about 15 years ago. 
I also have the file layout from the orginal ledger accounts file. But I used 
an hierachical file comprising a linked list, physically based on an IS file 
with one alternate key. It was deucedly clever and I doubt if I am that 
clever any more.  worst ase I will try to relive  

But thanks for your reply, and Merry Christmas.

-- 
John Culleton
Able Indexing and Typesetting
Precision typesetting (tm) at reasonable cost.
Satisfaction guaranteed. 
http://wexfordpress.com

Re: [Tiny-cobol-users] Open source COBOL G/L?

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

John R. Culleton wrote:

 > Eons ago (well about 20 years ago) I developed my own
 > version of a G/L system in RM COBOL and offered it for
 > sale even.
 > Well, I have lost all the source code and don't have
 > the energy or perhaps even the skill level to start all over.
 > ...

If per chance you still have the binaries, and they happen to be DOS 
binaries (16 bit), you may still be able to use them on Linux and Win32.

I have an old 16-bit (DOS) COBOL compiler, I picked up at a yard sale.
Using DOSEMU and freeDOS, I can compile and run COBOL 16-bit DOS 
programs on Linux.

It will also run on Win32, well Win9x, I have not tried it on W2K/XP.
It does require a special 16-bit linker to create executables on Win32, 
which can (or useto) be found on one of the MS web sites for free.

Still, a lot of these COBOL compilers create some sort of object code, 
which require a run-time program, and this does complicate matters.
But still, DOSEMU and freeDOS are easy to install and run, so it may be 
worth a try.

Anyway, hope this helps.