Re: [Tiny-cobol-users] Sample CGI program using TC

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

John, I have never used Fedora, so I can't help much in that respect.

The only one TC specific issue I can think off hand.
There have been reports of problems with TC and GCC 4x.
I haven't run any tests using TC and GCC 4x.

The problems you are encountering are common in UN*X, and particularly 
Linux. That is that you have too many variations of the same thing.

The result of this is that there no guarantee that a binary from one 
distribution will run on another.

The approach that I would take is to build and debug TC, and your 
applications on the system you plan to deploy it.
This is not as difficult as it sound, but it would require some
work space (home directory) on the remote system.
Once the system specific issues have been resolved, then I would try to 
resolve paths specific issues by running the application on the web server.


John Culleton wrote:
 > ...
 > This helps for local use on my Slack linux system. Thanks much.
 > But my (rented) remote site is on Fedora Linux
 > and the cobol part of your sample app errors off.
 > I tried putting htcobrun in the remote cgi-bin but
 > it still errors off.

What kind of error message are you getting in the apache log files
('log/apache').

 > I made both htcobrun and the app program 777 (executable)
 > for test purposes.
 > I don't have access to /usr/local/bin remotely.
 >
 > Three possilbilities, all of which may be true:
 > 1. htcobrun needs to be recompiled for the remote site on
 > a Fedora system.
 > 2. The program proper needs to be recompiled on a Fedora
 > system.
 > 3. The program is looking for htcobrun elsewhere and not
 > finding it in the cgi-bin directory.
 >
 > Any idea which of these are true?
 > I hate to go through the labor of setting up Fedora and
 > recompiling everything if in fact it still isn't going
 > to work.

I do not think running a parallel system is a good idea. Way too much to 
try to keep it in sync.


 > Assuming for the moment that the app program can't find
 > the runtime system, how tough would it be to modify the
 > compiler so that the compiled program looks in the current
 > directory for the runtime?

It is just a question of paths and user IDs.

The TC RTL will need to be installed in a location where the system 
run-time linker can find it (ex: 'usr/lib' ...).

The applications are shared libraries so you will need to set the proper 
environment variables, so that the TC run-time can find it.

Example:
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export TCOB_LD_LIBRARY_PATH=.

As to 'htcobrun', you still have to set the environment variables and 
the name of the sub-program to call.
You could use a generic shell program as a front end.

Example:
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export TCOB_LD_LIBRARY_PATH=somepath
exec /fullpath/htcobrun $@

Note that I'm not sure that this is considered good practice, from a 
security standpoint.

Also note that you could write a COBOL program as a replacement for both 
'htcobrun' and the shell script. This could be installed it in the 
'cgi-bin' directory.
The advantage of this method is that any sub-program can be run using a 
dynamic call.

Example:
CALL identifier-1 [ USING ... ].

 > There is of course always Perl, php or javascript :<).
 > But my native lannguage is COBOL. And the app will ultimately
 > be large, G/L plus inventory plus ....

Well you could use a combination of languages.
For example Perl to display the HTML pages, and COBOL to read/write the 
data.
Use some CSS to make it look real prudy (pretty) !

Anyway, hope this helps.