tiny-cobol-users

[Tiny-cobol-users] CGI.BIN use.

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

Has anyone  used Tiny to generate a cgi-bin program?  If so, what did you use 
on the html side, get, post, php, javascript, other? 
-- 
John Culleton
http://wexfordpress.com
http://wexfordpress.com/tex/shortlist.pdf

Re: [Tiny-cobol-users] CGI.BIN use.

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

On Thursday 27 September 2007 05:48:01 pm you wrote:
> > Has anyone  used Tiny to generate a cgi-bin program?  If so, what did you
> > use
> > on the html side, get, post, php, javascript, other?
>
> John,
>   I am answering directly because even though I receive all the posts
> when I get nothing but rejects when I try to sned to it.
>
> I was unable to get Tiny to work as a cgi because of the lack of a way
> to get at stdin/stdout.  I always needed to put some kind of wrapper
> around it which kinda negated the idea of using Tiny for cgi.
>
> I haven't looked in a while so maybe it changed, but that was my
> experience.
>
> I am going to look at OpenCOBOL as it seems to get around this.
>
> bill

There is a Tiny test program that uses a c language bridge program, tdb03 in 
the test programs. But the c language inteface program own't compile. Other c 
language items  in the test suite do compile. So perhaps Essex or somebody 
could debug that piece of code. I haven't done enoough c to tackle it. 

I am sending a cc to the tiny list to alert someone  to your problems posting. 
Make sure you are trying to post using the same email address that is in use 
when you receive posts.

Cheers, 

-- 
John Culleton
http://wexfordpress.com
http://wexfordpress.com/tex/shortlist.pdf

Re: [Tiny-cobol-users] CGI.BIN use.

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

John Culleton wrote:

 > There is a Tiny test program that uses a c language
 > bridge program, tdb03 in the test programs.
 > But the c language inteface program own't compile.
 > Other c language items  in the test suite do compile.
 > So perhaps Essex or somebody could debug that piece of
 > code. I haven't done enoough c to tackle it.

The program found in 'test.code/tdb03' requires 'postgresql' (C headers 
and library) to compile.

Currently do not have 'postgresql' installed on any PC, so I can't test it.

Re: [Tiny-cobol-users] CGI.BIN use.

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

On Friday 28 September 2007 01:11:27 am David Essex wrote:
> John Culleton wrote:
>  > There is a Tiny test program that uses a c language
>  > bridge program, tdb03 in the test programs.
>  > But the c language inteface program own't compile.
>  > Other c language items  in the test suite do compile.
>  > So perhaps Essex or somebody could debug that piece of
>  > code. I haven't done enoough c to tackle it.
>
> The program found in 'test.code/tdb03' requires 'postgresql' (C headers
> and library) to compile.
>
> Currently do not have 'postgresql' installed on any PC, so I can't test it.
>

Aha! So that is the answer.  I should have guessed from the name "tdb3." 
I guess I will dig into the c program to find the part that deals with stdin 
and stdout. I don't need the complication and the overhead of a RDBMS; the IS 
file system works for me. 

Open COBOL has a feature that allows addressing stdin and stdout as files. 
Supposedly this permits a COBOL program to act as a cgi program.  I will 
experiment with this as time permits. 


-- 
John Culleton
http://wexfordpress.com
http://wexfordpress.com/tex/shortlist.pdf

Re: [Tiny-cobol-users] CGI.BIN use.

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

On Friday 28 September 2007 01:11:27 am David Essex wrote:
> John Culleton wrote:
>  > There is a Tiny test program that uses a c language
>  > bridge program, tdb03 in the test programs.
>  > But the c language inteface program own't compile.
>  > Other c language items  in the test suite do compile.
>  > So perhaps Essex or somebody could debug that piece of
>  > code. I haven't done enoough c to tackle it.
>
> The program found in 'test.code/tdb03' requires 'postgresql' (C headers
> and library) to compile.
>
> Currently do not have 'postgresql' installed on any PC, so I can't test it.


Addendum. There are two c programs, and one is titled cgi-util.  That does 
compile as a subroutine. I'll play with that a bit. 

-- 
John Culleton
http://wexfordpress.com
http://wexfordpress.com/tex/shortlist.pdf

[Tiny-cobol-users] Sample CGI program using TC (was: CGI.BIN use)

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

John Culleton wrote:

 > Has anyone used Tiny to generate a cgi-bin program?
 > If so, what did you use on the html side, get, post,
 > php, javascript, other?

Yes, TC can be used to create a CGI program using basic ACCEPT and
DISPLAY statements.
One of the ways to do so, would be as follows.

* Parse the query string
ACCEPT identifier-1 FROM ENVIRONMENT-VARIABLE "QUERY_STRING".
...
UNSTRING identifier-1 DELIMITED BY '?' INTO ...
...
UNSTRING identifier-2 DELIMITED BY '=' INTO ...
...
* If a valid query, find and display data in HTML
* format to standard output
DISPLAY 'Content-type: text/html' WS-CR WS-LF WS-CR
DISPLAY '<!DOCTYPE html PUBLIC ... '
...
DISPLAY '<html><HEAD><title> ...'
...
DISPLAY '</body> </HTML>'

I have enclosed a sample application for a NA area code lookup, using
both a Perl and COBOL programs.

Note that the NA area code database file (1) is NOT included, so no area
code data is displayed.

Hope this helps.

1) Area codes
http://www.bennetyee.org/ucsd-pages/area.html

Re: [Tiny-cobol-users] Sample CGI program using TC (was: CGI.BIN use)

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

On Saturday 29 September 2007 01:27:37 am David Essex wrote:
> John Culleton wrote:
>  > Has anyone used Tiny to generate a cgi-bin program?
>  > If so, what did you use on the html side, get, post,
>  > php, javascript, other?
>
> Yes, TC can be used to create a CGI program using basic ACCEPT and
> DISPLAY statements.
> One of the ways to do so, would be as follows.
>
> * Parse the query string
> ACCEPT identifier-1 FROM ENVIRONMENT-VARIABLE "QUERY_STRING".
> ...
> UNSTRING identifier-1 DELIMITED BY '?' INTO ...
> ...
> UNSTRING identifier-2 DELIMITED BY '=' INTO ...
> ...
> * If a valid query, find and display data in HTML
> * format to standard output
> DISPLAY 'Content-type: text/html' WS-CR WS-LF WS-CR
> DISPLAY '<!DOCTYPE html PUBLIC ... '
> ...
> DISPLAY '<html><HEAD><title> ...'
> ...
> DISPLAY '</body> </HTML>'
>
> I have enclosed a sample application for a NA area code lookup, using
> both a Perl and COBOL programs.
>
> Note that the NA area code database file (1) is NOT included, so no area
> code data is displayed.
>
> Hope this helps.
>
> 1) Area codes
> http://www.bennetyee.org/ucsd-pages/area.html

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

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? 

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

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.