Home > Archive > Cobol > September 2005 > COBOL as CGI
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| John Culleton 2005-09-02, 6:55 pm |
| I have seen examples of linking COBOL programs to TclTk. Does anyone have an
example of using a COBOL program for a cgi program in conjunction with
html?
--
John Culleton
Able Indexers and Typesetters
| |
| Oliver Wong 2005-09-02, 6:55 pm |
|
"John Culleton" <john@wexfordpress.com> wrote in message
news:CIydnYwmx-2w7oXeRVn-sg@adelphia.com...
>I have seen examples of linking COBOL programs to TclTk. Does anyone have
>an
> example of using a COBOL program for a cgi program in conjunction with
> html?
From my understanding of CGI, the webserver shouldn't be making any
assumptions about the language that the CGI program is written in. Rather,
the webserver should just run the program, passing along the arguments as
command-line arguments or environment variables (depending on whether the
HTTP request was submitted via POST or GET). It then takes whatever output
the CGI program emits, and sends that to the browser.
If you can write a normal COBOL program to read from the command line
arguments or from environment variables, and to print text to the standard
output, then you shouldn't have any problems using COBOL to write a CGI
program.
- Oliver
| |
| Richard 2005-09-02, 6:55 pm |
| > If you can write a normal COBOL program to read from
> the command line arguments or from environment
> variables, and to print text to the standard
> output, then you shouldn't have any problems using
> COBOL to write a CGI program.
That is generaly true, and I have been doing this for several years on
several OSes and web servers.
There are some technical issues, such as ensuring that the Cobol is, in
fact, using stdin and stdout and getting the ACCEPT of GETted data to
terminate correctly (hint: ACCEPT get-data[1:get-length]).
For an easy webserver on Windows try Xitami.
| |
| yogibear 2005-09-02, 6:55 pm |
| <HTML><H1> ENTER PASSWORD</H1>
<FORM METHOD="POST" ACTION="/cgi-bin/name.xxx">
Please enter your name or leave the entry field
blank for "anonymous":
<INPUT TYPE="text" NAME="CGI-VAR1" SIZE=60>
<INPUT TYPE="submit" VALUE="Submit">
</FORM> </HTML>
The ACTION attribute tells the browser where to send the encoded form
information, typically the URL (uniform resource locator) of the CGI
program that will process the form. You need to configure the web
server so that is knows how to process name.xxx or whatever script may
execute the COBOL program.
With ACUCOBOL-GT you can use the ACCEPT phrase to get the input from
the HTML
ACCEPT external-form-item
where external-form-item is an input record for an HTML, XML, or WML
form. It is a group data item (declared with the IS EXTERNAL-FORM
clause) that has one or more elementary items associated with CGI
variables. For "input forms," the association is made using the
IDENTIFIED BY clause in the description of the elementary item. The
value of external-name is the name of the CGI variable. If the
IDENTIFIED BY phrase is omitted, the data item's own name (data-name)
is used as the name of the CGI variable.
External-form-item may also be an output record for an HTML, XML, or
WML form. In this case, the group item is declared with both the IS
EXTERNAL-FORM and IDENTIFIED BY clauses.
The "external form" is called an "output form" if the IDENTIFIED BY
clause is used in the description of the group item to associate it
with a template file.
For example, the following is an input form:
01 CGI-FORM IS EXTERNAL-FORM.
03 CGI-VAR1 PIC X(10).
03 CGI-VAR2 PIC X(10).
The ACCEPT verb treats input and output forms the same. ACCEPT sets the
value of each elementary item in the external form, in order, to the
value of its associated CGI variable, padding with trailing spaces.
ACCEPT automatically decodes and translates the CGI input data before
moving it to the elementary items of external-form-item. The value of
each CGI variable is converted to the appropriate COBOL data type when
it is moved to the external form.
I hope this helps.
| |
| Michael Wojcik 2005-09-07, 6:55 pm |
|
In article <Xt_Re.221796$HI.14405@edtnps84>, "Oliver Wong" <owong@castortech.com> writes:
> "John Culleton" <john@wexfordpress.com> wrote in message
> news:CIydnYwmx-2w7oXeRVn-sg@adelphia.com...
Some COBOL implementations (including ours) have special support for
CGI programs, and come with samples. Have you checked your COBOL
documentation?
[color=darkred]
> From my understanding of CGI, the webserver shouldn't be making any
> assumptions about the language that the CGI program is written in.
That's true, broadly speaking. The CGI/1.1 draft specification (it
has not yet gotten past the Internet-Draft stage) is available at [1].
> Rather,
> the webserver should just run the program, passing along the arguments as
> command-line arguments or environment variables (depending on whether the
> HTTP request was submitted via POST or GET).
Not quite. Input to CGI programs comes via one of three channels,
depending on the type of request:
- For an ISINDEX request, the request data appears on the command line.
ISINDEX requests are produced from URLs which include a query-string
(a string at the end of the URL following the "?" character) that does
not contain a equals sign ("="). ISINDEX is a deprecated mechanism.
- If the Script-URI includes a query string that does contain an equals
sign, the query string will be made available through the QUERY_STRING
environment variable. HTTP GET requests can only pass request data
through a query string, so this is typically seen with GET requests
(eg forms with METHOD="GET", or URLs with "?name=value").
- If the request includes a content-body, the content-body must be made
available to the CGI program. The usual (universal?) mechanism is
standard input, but that's not actually required by the draft spec.
The amount of data to be read from standard input is in the environment
variable CONTENT_LENGTH; the CGI program MUST read only this many bytes,
as the server is NOT required to close standard input after writing the
request content-body data. HTTP POST requests usually include a
content-body, so this method is seen with POST requests (eg forms with
METHOD="POST").
> It then takes whatever output
> the CGI program emits, and sends that to the browser.
Almost. The CGI program should emit one or more headers, followed by
a body separator (a blank line), followed by the content to be sent
back to the client, if any. If there's content, the CGI program
should emit at least a Content-type header. (A case where there isn't
any content is when a CGI program emits a Location header to redirect
the request rather than providing content itself, for example.)
There's also NPH (non-parsed header) mode, but that's a special case
that's not widely used and can generally be ignored.
> If you can write a normal COBOL program to read from the command line
> arguments or from environment variables, and to print text to the standard
> output, then you shouldn't have any problems using COBOL to write a CGI
> program.
Agreed. CGI programs are actually quite easy. Besides [1], there
are examples at [2].
[1] http://cgi-spec.golux.com/
[2] http://hoohoo.ncsa.uiuc.edu/cgi/
--
Michael Wojcik michael.wojcik@microfocus.com
Shakespeare writes bombast and knows it; Mr Thomas writes bombast and
doesn't. That is the difference. -- Geoffrey Johnson
| |
| Richard 2005-09-07, 6:55 pm |
| > The usual (universal?) mechanism is
> standard input, but that's not actually required by the draft spec.
Some webservers can optionally pass the POST data in a file and pass
the name of the file in an environment variable. They may also take
the output in a file that they supply the name of. This was probably
all back when I was trying WinHTTPD web server on Win 3.1 and PWS on
Win95 also did it this way. I recall it was referred to as WinCGI and I
think MS was pushing it before they bought IIS.
Xitami can be configured to do this, probably from when it too was
Win3.x:
"""Visual Basic programs:. Use the CGI_STDIN and CGI_STDOUT environment
variables to read the HTTP form data, and write the HTML output. You
may want to set cgi:form-fields to 0, since you can pick-up the HTTP
form data from the stdin file instead of the environment. ..."""
Xitami runs on OS/2, any Windows since 3.x, any Unix/Linux, OpenVMS and
is really easy to set up and run. It's free so you can all have a
webserver running on your desktop.
| |
| Richard 2005-09-07, 6:55 pm |
| > Does anyone have an example of using a COBOL
> program for a cgi program in conjunction with html?
Search for CGIINPUT.CBL on Google in this group. I had posted some
Cobol code that does the input processing for CGI.
| |
| John Culleton 2005-09-08, 6:55 pm |
| Michael Wojcik wrote:
>
> In article <Xt_Re.221796$HI.14405@edtnps84>, "Oliver Wong"
> <owong@castortech.com> writes:
>
> Some COBOL implementations (including ours) have special support for
> CGI programs, and come with samples. Have you checked your COBOL
> documentation?
>
>
> That's true, broadly speaking. The CGI/1.1 draft specification (it
> has not yet gotten past the Internet-Draft stage) is available at [1].
>
>
> Not quite. Input to CGI programs comes via one of three channels,
> depending on the type of request:
>
> - For an ISINDEX request, the request data appears on the command line.
> ISINDEX requests are produced from URLs which include a query-string
> (a string at the end of the URL following the "?" character) that does
> not contain a equals sign ("="). ISINDEX is a deprecated mechanism.
>
> - If the Script-URI includes a query string that does contain an equals
> sign, the query string will be made available through the QUERY_STRING
> environment variable. HTTP GET requests can only pass request data
> through a query string, so this is typically seen with GET requests
> (eg forms with METHOD="GET", or URLs with "?name=value").
>
> - If the request includes a content-body, the content-body must be made
> available to the CGI program. The usual (universal?) mechanism is
> standard input, but that's not actually required by the draft spec.
> The amount of data to be read from standard input is in the environment
> variable CONTENT_LENGTH; the CGI program MUST read only this many bytes,
> as the server is NOT required to close standard input after writing the
> request content-body data. HTTP POST requests usually include a
> content-body, so this method is seen with POST requests (eg forms with
> METHOD="POST").
>
>
> Almost. The CGI program should emit one or more headers, followed by
> a body separator (a blank line), followed by the content to be sent
> back to the client, if any. If there's content, the CGI program
> should emit at least a Content-type header. (A case where there isn't
> any content is when a CGI program emits a Location header to redirect
> the request rather than providing content itself, for example.)
>
> There's also NPH (non-parsed header) mode, but that's a special case
> that's not widely used and can generally be ignored.
>
>
> Agreed. CGI programs are actually quite easy. Besides [1], there
> are examples at [2].
>
>
> [1] http://cgi-spec.golux.com/
> [2] http://hoohoo.ncsa.uiuc.edu/cgi/
>
At hte latter URL I had trouble finding anything in COBOL. Can you give me a
more precise address?
I use TinyCOBOL on Linux but I am interested in a very generic approach if
possible.
--
John Culleton
Able Indexers and Typesetters
| |
| John Culleton 2005-09-08, 6:55 pm |
| Richard wrote:
>
> That is generaly true, and I have been doing this for several years on
> several OSes and web servers.
>
> There are some technical issues, such as ensuring that the Cobol is, in
> fact, using stdin and stdout and getting the ACCEPT of GETted data to
> terminate correctly (hint: ACCEPT get-data[1:get-length]).
>
> For an easy webserver on Windows try Xitami.
Your ACCEPT statement just above with the reference modification parameter
provokes another question. How does the programmer know in advance just how
long the data transmitted by the GET or POST statement will be? Or do I
just put the length of the "get-data" field as described in the COBOL
program?
BTW thus far using TinyCOBOL I can send text to the html page with DISPLAY
but ACCEPT returns blanks. This is on a local apache server, Slackware
Linux.
--
John Culleton
Able Indexers and Typesetters
| |
| John Culleton 2005-09-08, 6:55 pm |
| yogibear wrote:
> <HTML><H1> ENTER PASSWORD</H1>
> <FORM METHOD="POST" ACTION="/cgi-bin/name.xxx">
> Please enter your name or leave the entry field
> blank for "anonymous":
> <INPUT TYPE="text" NAME="CGI-VAR1" SIZE=60>
> <INPUT TYPE="submit" VALUE="Submit">
> </FORM> </HTML>
>
> The ACTION attribute tells the browser where to send the encoded form
> information, typically the URL (uniform resource locator) of the CGI
> program that will process the form. You need to configure the web
> server so that is knows how to process name.xxx or whatever script may
> execute the COBOL program.
>
> With ACUCOBOL-GT you can use the ACCEPT phrase to get the input from
> the HTML
>
> ACCEPT external-form-item
> where external-form-item is an input record for an HTML, XML, or WML
> form. It is a group data item (declared with the IS EXTERNAL-FORM
> clause) that has one or more elementary items associated with CGI
> variables. For "input forms," the association is made using the
> IDENTIFIED BY clause in the description of the elementary item. The
> value of external-name is the name of the CGI variable. If the
> IDENTIFIED BY phrase is omitted, the data item's own name (data-name)
> is used as the name of the CGI variable.
>
> External-form-item may also be an output record for an HTML, XML, or
> WML form. In this case, the group item is declared with both the IS
> EXTERNAL-FORM and IDENTIFIED BY clauses.
>
> The "external form" is called an "output form" if the IDENTIFIED BY
> clause is used in the description of the group item to associate it
> with a template file.
>
> For example, the following is an input form:
>
> 01 CGI-FORM IS EXTERNAL-FORM.
> 03 CGI-VAR1 PIC X(10).
> 03 CGI-VAR2 PIC X(10).
>
> The ACCEPT verb treats input and output forms the same. ACCEPT sets the
> value of each elementary item in the external form, in order, to the
> value of its associated CGI variable, padding with trailing spaces.
> ACCEPT automatically decodes and translates the CGI input data before
> moving it to the elementary items of external-form-item. The value of
> each CGI variable is converted to the appropriate COBOL data type when
> it is moved to the external form.
>
> I hope this helps.
One question: the parameter "IS EXTERNAL FORM" does not appear in any of my
COBOL manuals. Is this a compiler-specific extension?
--
John Culleton
Able Indexers and Typesetters
| |
| Richard 2005-09-08, 6:55 pm |
| > Your ACCEPT statement just above with the reference modification parameter
> provokes another question. How does the programmer know in advance just how
> long the data transmitted by the GET or POST statement will be?
Because the environment variable CONTENT-LENGTH provides this.
> BTW thus far using TinyCOBOL I can send text to the html page with DISPLAY
> but ACCEPT returns blanks. This is on a local apache server, Slackware
> Linux.
You can send data to a CGI program using the URL such as:
<a href="/cgi-bin/prog?function=getdata&key=123456">Click here</a>
and this will do an html GET which will put the string
"function=getdata&key=123456" in the environment variable QUERY-STRING.
You will know this because the environment variable REQUEST-METHOD
will have "GET" in it.
If you have a form:
<form action="/cgi-bin/prog" method="GET">
<input type="hidden" name="function" value="getdata">
<input type="text" name="key">
<input type="submit" value="get data">
</form>
You will get an input field and a button key in 123456 and press the
button and, because it is GET method the same data will be in the
QUERY-STRING as before.
If the form has method="POST" then this value will be in
REQUEST-METHOD, the length will be in CONTENT-LENGTH and you will use
ACCEPT to get the data.
Get a simple book on CGI.
| |
| Richard 2005-09-08, 6:55 pm |
| > One question: the parameter "IS EXTERNAL FORM" does not appear in any of my
> COBOL manuals. Is this a compiler-specific extension?
What was described was specific to ACUCOBOL-GT.
When the form has a POST method the ACCEPT will get a string in the
form:
name=value&name=value&name=value
where the 'name' comes from the 'name' attribute of the input tag and
the 'value' is either the value attribute or what was typed in to a
text field. You will have to process this into your own data areas.
Note that there will be certain substitutions made because you can't
have '&' '=' '?' or space in the name or value parts. These will be %nn
where nn is the hex value of the ASCII, eg %20 is space.
| |
| Oliver Wong 2005-09-08, 6:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1126207506.436988.200530@g49g2000cwa.googlegroups.com...
> Note that there will be certain substitutions made because you can't
> have '&' '=' '?' or space in the name or value parts. These will be %nn
> where nn is the hex value of the ASCII, eg %20 is space.
Coincidentally, I was posting about this issue in another newsgroup. If
you care about standards conformance, you might want to read RFC1738,
particularly section 2.2 on what characters "must" be encoded.
http://www.faqs.org/rfcs/rfc1738.html
In practice though, most servers I've encountered have been very lenient
in accepting non-encoded characters, so your program may still work even if
it doesn't abide to the specifications in RFC1738.
- Oliver
|
|
|
|
|