COBOL for utility program under Linux.

Richard wrote:
> On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
> wrote:
>> "Richard" <rip...@azonic.co.nz> wrote in message
>>
>> news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com...>MCM wrote
>>>> CGI really only needs ACCEPT and DISPLAY 'UPON COMMAND LINE'
>>>> CGI generally is reading from or writing to STDIN and STDOUT. (on unix,
>> <> 'stdin' and 'stdout')

CGI scripts (the specification calls anything that is executed by a
server via the CGI protocol a "script") only read from standard input
if the request includes a content-body. HTTP GET requests, for
example, do not include a content-body.

For a GET request, the client can pass data to the script as a
query-string, which will be passed to the script in the CGI
QUERY_STRING metavariable. Most, possibly all, implementations of CGI
use the environment for metavariables.

For GET requests that follow the ISINDEX syntax (ie, with no unescaped
"=" characters in the query-string), then if the system permits
passing command-line parameters to the script, it should also parse
the query-string into words using "+" as a delimiter and put those on
the command line.

This is per the CGI/1.1 Internet-draft Draft 03, which does not have
force as a standard, but is the closest thing to a coherent
description of CGI/1.1 practices. See http://w3.org/CGI/ for links to
various CGI specifications, including the original NCSA CGI/1.1 spec
and the I-D.

>>> When ACCEPTing from stdin (or CGI) it is usually necessary to use the
>>> length of the text (which is supplier in an environment variable) as a
>>> limit on the data as otherwise it will require a timeout or similar.
>>>> Surely there is another way to use standard handles with COBOL other than
>>>> DISPLAY/ACCEPT. (READ and WRITE come to mind) .
>>> Why would you need 'another way' ?
>> Because as you point out, you may need the length to execute the ACCEPT,
>> which you don't have.
>
> Yes you do, with CGI it is in the CONTENT_LENGTH environment variable.

Though again, this is only true if the request contains a content-body.

> Whether this is actually needed depends on the implementation.

Correct. Systems which can indicate EOF to the script, MAY do so after
writing CONTENT_LENGTH octets, but are not required to. So if the
server reliably signals EOF after writing the content-body to the
script, and it's acceptable for the script to depend on that behavior,
then the script can read until EOF.

> DISPLAY "CONTENT LENGTH" UPON Environment-Name
> ACCEPT Content-Length FROM Environment-Value
> ACCEPT Content(1:FUNCTION NUMVAL(Content-Length))
> FROM CONSOLE

Since this is simple, clear, and guaranteed to work under any
conforming implementation, it's what I'd recommend. (Probably with
some error checking, just in case.)

>> Under Windows using my BASIC complier, you can detect
>> "end of file" on STDIN when reading the HTML submitted by the caller...

Only if the server provides that behavior.

>> But I guess..... you could ACCEPT a byte at a time until there ain't no
>> more? IOr maybe is there a facility with ACCEPT to detect "no data
>> availale?" Damn, I simply can't remember anymore. I suppose I could look it
>> up.....wow, I forgot about all the MF extensions to ACCEPT... both TIME-OUT
>> and ON EXCEPTION look like they will support handilng the
>> unknown-when-you-start-variable-lengthness of the input.

I suspect ON EXCEPTION would work for detecting EOF, though I haven't
tested it.

I'd use Richard's method, though. For maximum flexibility, if
CONTENT_LENGTH is not set, empty, or zero, the script could check
QUERY_STRING; that would let it handle both GET and POST requests.
(That may require some extra processing, because the value of
QUERY_STRING is URL-encoded, while the encoding of the content-body
depends on the content-type and possibly the whims of the client program.)

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

PR wrote:
> Whoo boy - did I just walk into a minefield. Advice on how to extract
> myself with all body parts attached very welcome...
>
> I walked into a shop a few weeks ago that of all things, has some
> Alpha VMS machines still running. In fact, they have been running for
> three years without an IPL or even an administrator login - ever since
> they previous system admin got up on a high horse and left. Imagine
> that...
>
> I contracted to go into the VMS systems and write some small interface
> programs to put a bit of the data up on the web. This is usually
> trivially easy under VMS, especially since the VMS COBOL compiler
> works great for CGI. (It's a very good compiler indeed. Perfect target
> for a little utility program written in COBOL.
>
> But, my client just called up and told me they really want to run the
> software on two or three different platforms. VMS, Linux, and iSeries
> to be exact.
>
> COBOL runs on all three, so that should not be a big issue, but
> wowzers... MicroFocus COBOL is now apparently $22,000 ($22K!) PER
> SERVER. That kind of zaps the idea of putting it under Linux, unless
> there is a much less expensive COBOL compiler for Linux...
>
> A $22K utility program is not exactly what I had in mind... nor for
> that matter, what the customer had in mind. I would love to pull a
> rabbit out of my hat on this one, but I am totally stumped. It looks
> like MicroFocus has eaten up Relia and AcuCobol as well...
>
> Any suggestions?

CobolScript? $49.95, and the website claims there's a Linux version:

http://cobolscript.googlepages.com/cobolscript

(I have no connection to, or experience with, this product.)

Louis

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:g96b4i02riq@news5.newsguy.com...
> Richard wrote:
>> On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
>> wrote:
>>> "Richard" <rip...@azonic.co.nz> wrote in message
>>>
>>> news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com...>MCM
>>> wrote
>>>>> CGI really only needs ACCEPT and DISPLAY 'UPON COMMAND LINE'
>>>>> CGI generally is reading from or writing to STDIN and STDOUT. (on
>>>>> unix,
>>> <> 'stdin' and 'stdout')
>
> CGI scripts (the specification calls anything that is executed by a
> server via the CGI protocol a "script") only read from standard input
> if the request includes a content-body. HTTP GET requests, for
> example, do not include a content-body.
>
> For a GET request, the client can pass data to the script as a
> query-string, which will be passed to the script in the CGI
> QUERY_STRING metavariable. Most, possibly all, implementations of CGI
> use the environment for metavariables.
>
> For GET requests that follow the ISINDEX syntax (ie, with no unescaped
> "=" characters in the query-string), then if the system permits
> passing command-line parameters to the script, it should also parse
> the query-string into words using "+" as a delimiter and put those on
> the command line.
>
> This is per the CGI/1.1 Internet-draft Draft 03, which does not have
> force as a standard, but is the closest thing to a coherent
> description of CGI/1.1 practices. See http://w3.org/CGI/ for links to
> various CGI specifications, including the original NCSA CGI/1.1 spec
> and the I-D.
>
>>>> When ACCEPTing from stdin (or CGI) it is usually necessary to use the
>>>> length of the text (which is supplier in an environment variable) as a
>>>> limit on the data as otherwise it will require a timeout or similar.
>>>>> Surely there is another way to use standard handles with COBOL other
>>>>> than
>>>>> DISPLAY/ACCEPT. (READ and WRITE come to mind) .
>>>> Why would you need 'another way' ?
>>> Because as you point out, you may need the length to execute the ACCEPT,
>>> which you don't have.
>>
>> Yes you do, with CGI it is in the CONTENT_LENGTH environment variable.
>
> Though again, this is only true if the request contains a content-body.
>
>> Whether this is actually needed depends on the implementation.
>
> Correct. Systems which can indicate EOF to the script, MAY do so after
> writing CONTENT_LENGTH octets, but are not required to. So if the
> server reliably signals EOF after writing the content-body to the
> script, and it's acceptable for the script to depend on that behavior,
> then the script can read until EOF.
>
>> DISPLAY "CONTENT LENGTH" UPON Environment-Name
>> ACCEPT Content-Length FROM Environment-Value
>> ACCEPT Content(1:FUNCTION NUMVAL(Content-Length))
>> FROM CONSOLE
>
> Since this is simple, clear, and guaranteed to work under any
> conforming implementation, it's what I'd recommend. (Probably with
> some error checking, just in case.)
>
>>> Under Windows using my BASIC complier, you can detect
>>> "end of file" on STDIN when reading the HTML submitted by the caller...
>
> Only if the server provides that behavior.
>
>>> But I guess..... you could ACCEPT a byte at a time until there ain't no
>>> more? IOr maybe is there a facility with ACCEPT to detect "no data
>>> availale?" Damn, I simply can't remember anymore. I suppose I could
>>> look it
>>> up.....wow, I forgot about all the MF extensions to ACCEPT... both
>>> TIME-OUT
>>> and ON EXCEPTION look like they will support handilng the
>>> unknown-when-you-start-variable-lengthness of the input.
>
> I suspect ON EXCEPTION would work for detecting EOF, though I haven't
> tested it.
>
> I'd use Richard's method, though. For maximum flexibility, if
> CONTENT_LENGTH is not set, empty, or zero, the script could check
> QUERY_STRING; that would let it handle both GET and POST requests.
> (That may require some extra processing, because the value of
> QUERY_STRING is URL-encoded, while the encoding of the content-body
> depends on the content-type and possibly the whims of the client program.)
>
> --
> Michael Wojcik
> Micro Focus
> Rhetoric & Writing, Michigan State University

Thanks for a very lucid and interesting post, Michael.

I have saved this.

Pete.
--
"I used to write COBOL...now I can do anything."

See below

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:g96b4i02riq@news5.newsguy.com...
> Richard wrote:
>> On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
>> wrote:
>>> "Richard" <rip...@azonic.co.nz> wrote in message
>>>
>>> news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com...>MCM
>>> wrote
Concerning ...
> Correct. Systems which can indicate EOF to the script, MAY do so after
> writing CONTENT_LENGTH octets, but are not required to. So if the
> server reliably signals EOF after writing the content-body to the
> script, and it's acceptable for the script to depend on that behavior,
> then the script can read until EOF.
>
>> DISPLAY "CONTENT LENGTH" UPON Environment-Name
>> ACCEPT Content-Length FROM Environment-Value
>> ACCEPT Content(1:FUNCTION NUMVAL(Content-Length))
>> FROM CONSOLE
>
> Since this is simple, clear, and guaranteed to work under any
> conforming implementation, it's what I'd recommend. (Probably with
> some error checking, just in case.)
>

Well, Yes and No ....

Once upon a time and long ago <G> there was something called X/Open and the
first (only?) programming language other than C for which this consortium
provided a Standard was COBOL. As this Standard assumed (???) a "Unix-like"
"Open System" environment, they assumed that "environment variables" were an
operating system facility. THEREFORE< this COBOL Standard provide a way of
getting "environment variables" (and command-lime parameters). Many (there were
MANY in those days) "conforming implementations" provided this syntax via the
ACCEPT and DISPLAY statements.

This syntax/semantics was never adopted within the ANSI or ISO COBOL Standards.
There was "interest" expressed by WG4 (the international COBOL standards
committee) in getting facility (possibly with this syntax) into the next
revision of the ANSI/ISO COBOL Standard. The assignment for providing (and
updating) such a proposal was accepted by Micro Focus (a member of J4, not
PL22.4) the US COBOL Standards committee. However, Micro Focus failed to
provide such a proposal (with suggested updates) to J4 in a "timely" manner and,
therefore, this feature is NOT included in the working draft of the next COBOL
revision (much less in any existing ANSI/ISO COBOL Standard).

Bottom-Line:
Should any COBOL user think that this is a critical feature to include within
the NEXT revision of the COBOL Standard, they should contact their NATIONAL
STANDARDS BODY (not PL22.4 aka J4) and request that this topic be placed on the
agenda for the WG4 meeting scheduled for October of this year.
Should you think that what is and is not in the ANSI/ISO COBOL Standard is
irrelevant to how you use COBOL and if your COBOL implementation provides this
(or comparable) feature, then you may chuckle at and ignore this comp.lang.cobol
thread.

P.S. If you are interested in seeing how one implementation that (IBM mainframe
COBOL) does NOT support this syntax handles the issue, see:

http://publibz.boulder.ibm.com/cgi-b...A3180/2.2.5.34

On Aug 29, 1:55*am, Michael Wojcik <mwoj...@newsguy.com> wrote:
> Richard wrote:
> > On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
> > wrote:
> >> "Richard" <rip...@azonic.co.nz> wrote in message
>
> >>news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com....>MCMw rote
> >>>> CGI really only needs ACCEPT and DISPLAY 'UPON COMMAND LINE'
> >>>> CGI generally is reading from or writing to STDIN and STDOUT. (on unix,
> >> <> 'stdin' and 'stdout')
>
> CGI scripts (the specification calls anything that is executed by a
> server via the CGI protocol a "script") only read from standard input
> if the request includes a content-body. HTTP GET requests, for
> example, do not include a content-body.
>
> For a GET request, the client can pass data to the script as a
> query-string, which will be passed to the script in the CGI
> QUERY_STRING metavariable. Most, possibly all, implementations of CGI
> use the environment for metavariables.
>
> For GET requests that follow the ISINDEX syntax (ie, with no unescaped
> "=" characters in the query-string), then if the system permits
> passing command-line parameters to the script, it should also parse
> the query-string into words using "+" as a delimiter and put those on
> the command line.

I had to dig deep to find references to the deprecated <isindex> tag,
most of my material only goes back as far as the early 90s. ;-)


> This is per the CGI/1.1 Internet-draft Draft 03, which does not have
> force as a standard, but is the closest thing to a coherent
> description of CGI/1.1 practices. Seehttp://w3.org/CGI/for links to
> various CGI specifications, including the original NCSA CGI/1.1 spec
> and the I-D.
>
> >>> When ACCEPTing from stdin (or CGI) it is usually necessary to use the
> >>> length of the text (which is supplier in an environment variable) as a
> >>> limit on the data as otherwise it will require a timeout or similar.
> >>>> Surely there is another way to use standard handles with COBOL otherthan
> >>>> DISPLAY/ACCEPT. (READ and WRITE come to mind) .
> >>> Why would you need 'another way' ?
> >> Because as you point out, you may need the length to execute the ACCEPT,
> >> which you don't have.
>
> > Yes you do, with CGI it is in the CONTENT_LENGTH environment variable.
>
> Though again, this is only true if the request contains a content-body.
>
> > Whether this is actually needed depends on the implementation.
>
> Correct. Systems which can indicate EOF to the script, MAY do so after
> writing CONTENT_LENGTH octets, but are not required to. So if the
> server reliably signals EOF after writing the content-body to the
> script, and it's acceptable for the script to depend on that behavior,
> then the script can read until EOF.
>
> > * *DISPLAY "CONTENT LENGTH" *UPON Environment-Name
> > * *ACCEPT *Content-Length * *FROM Environment-Value
> > * *ACCEPT *Content(1:FUNCTION NUMVAL(Content-Length))
> > * * * * * *FROM CONSOLE
>
> Since this is simple, clear, and guaranteed to work under any
> conforming implementation, it's what I'd recommend. (Probably with
> some error checking, just in case.)

It didn't work on MF Cobol 3.4 on OS/2 for which I had to resort to
CALL OS2API "DosRead" USING ...

Not that this was ever used in any live situation.

> >> Under Windows using my BASIC complier, you can detect
> >> "end of file" on STDIN when reading the HTML submitted by the caller....
>
> Only if the server provides that behavior.
>
> >> But I guess..... you could ACCEPT a byte at a time until there ain't no
> >> more? IOr maybe is there a facility with ACCEPT to detect "no data
> >> availale?" *Damn, I simply can't remember anymore. I suppose I couldlook it
> >> up.....wow, I forgot about all the MF extensions to ACCEPT... both TIME-OUT
> >> and ON EXCEPTION look like they will support handilng the
> >> unknown-when-you-start-variable-lengthness of the input.
>
> I suspect ON EXCEPTION would work for detecting EOF, though I haven't
> tested it.
>
> I'd use Richard's method, though. For maximum flexibility, if
> CONTENT_LENGTH is not set, empty, or zero, the script could check
> QUERY_STRING; that would let it handle both GET and POST requests.

The 'Request Method" environment variable should contain 'POST' or
'GET' allowing this source to be determined adequately. It is possible
for "CONTENT LENGTH" to be set even when the "Query String" variable
contains the data.

There are some servers (probably obsolete) than can pass the content
in a disk file in which case the file name is passed as a variable.
Most of my Cobol CGI code was originally developed in the early 90s
and initially ran on OS/2 with an IBM server, progressed (??) to
Win3.11 with some httpd I forget, UnixWare with Netscape, and Xitami
on Linux and Windows before getting to Linux with Apache.

In this progression it found a vast array of minor issues, such as the
different spellings of the variables used (eg 'CONTENT_LENGTH' or
'Content Length'. The first thing to do with a web server is to run a
simple script to dump out the environment to see what you are getting.

Of course it would be easy for me to put together another simple Cobol
CGI system should it be required because I have all this framework
running. As Peter says, without this Cobol is much too hard to start
up from scratch for any serious application when other languages now
have complete frameworks available - for free.

The best reason for doing it in Cobol would be if there are existing
systems using indexed files where live interaction is required.

> (That may require some extra processing, because the value of
> QUERY_STRING is URL-encoded, while the encoding of the content-body
> depends on the content-type and possibly the whims of the client program.)
>
> --
> Michael Wojcik
> Micro Focus
> Rhetoric & Writing, Michigan State University

On Aug 29, 7:35*am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> See below
>
> --
> Bill Klein
> *wmklein <at> ix.netcom.com"Michael Wojcik" <mwoj...@newsguy.com> wrotein message
>
> news:g96b4i02riq@news5.newsguy.com...
>
>
>
> > Richard wrote:
> >> On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
> >> wrote:
> >>> "Richard" <rip...@azonic.co.nz> wrote in message
>
> >>>news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com....>MCM
> >>> wrote
> *Concerning ...
> > Correct. Systems which can indicate EOF to the script, MAY do so after
> > writing CONTENT_LENGTH octets, but are not required to. So if the
> > server reliably signals EOF after writing the content-body to the
> > script, and it's acceptable for the script to depend on that behavior,
> > then the script can read until EOF.
>
> >> * *DISPLAY "CONTENT LENGTH" *UPON Environment-Name
> >> * *ACCEPT *Content-Length * *FROM Environment-Value
> >> * *ACCEPT *Content(1:FUNCTION NUMVAL(Content-Length))
> >> * * * * * *FROM CONSOLE
>
> > Since this is simple, clear, and guaranteed to work under any
> > conforming implementation, it's what I'd recommend. (Probably with
> > some error checking, just in case.)
>
> Well, Yes and No ....
>
> Once upon a time and long ago <G> there was something called X/Open and the
> first (only?) programming language other than C for which this consortium
> provided a Standard was COBOL. As this Standard assumed (???) a "Unix-like"
> "Open System" environment, they assumed that "environment variables" werean
> operating system facility. *THEREFORE< this COBOL Standard provide a way of
> getting "environment variables" (and command-lime parameters). *Many (there were
> MANY in those days) "conforming implementations" provided this syntax viathe
> ACCEPT and DISPLAY statements.
>
> This syntax/semantics was never adopted within the ANSI or ISO COBOL Standards.

The syntax of 'DISPLAY .. UPON ..' and 'ACCEPT .. FROM ..' seems to be
completely conforming. The only issue is what 'Environment-Name' and
'Environment-Value' relates to in the SPECIAL-NAMES paragraph and what
the implementation does with these.

It may well be that a different implementation does nothing with these
statements, or reads a disk file, or, well, anything.

It is true that if the requirement is to read environment variables
then one will have to see how the particular implementation allows
this. With MicroSoft 4.5 on OS/2 I had to use CALL "_EXTNAME"
USING ...

But I don't think that either are non-conforming.




> There was "interest" expressed by WG4 (the international COBOL standards
> committee) in getting facility (possibly with this syntax) into the next
> revision of the ANSI/ISO *COBOL Standard. *The assignment for providing (and
> updating) such a proposal was accepted by Micro Focus (a member of J4, not
> PL22.4) *the US COBOL Standards committee. *However, Micro Focus failed to
> provide such a proposal (with suggested updates) to J4 in a "timely" manner and,
> therefore, this feature is NOT included in the working draft of the next COBOL
> revision (much less in any existing ANSI/ISO COBOL Standard).
>
> Bottom-Line:
> * *Should any COBOL user think that this is a critical feature to include within
> the NEXT revision of the COBOL Standard, they should contact their NATIONAL
> STANDARDS BODY (not PL22.4 aka J4) and request that this topic be placed on the
> agenda for the WG4 meeting scheduled for October of this year.
> * Should you think that what is and is not in the ANSI/ISO COBOL Standard is
> irrelevant to how you use COBOL and if your COBOL implementation providesthis
> (or comparable) feature, then you may chuckle at and ignore this comp.lang.cobol
> thread.
>
> P.S. *If you are interested in seeing how one implementation that (IBM mainframe
> COBOL) does NOT support this syntax handles the issue, see:
>
> *http://publibz.boulder.ibm.com/cgi-b...OKS/CEEA3180/2....

Richard wrote:
> On Aug 29, 7:35 am, "William M. Klein" <wmkl...@nospam.netcom.com>
> wrote:
>> "Michael Wojcik" <mwoj...@newsguy.com> wrote in message
>> news:g96b4i02riq@news5.newsguy.com...
>>
>>> Since this is simple, clear, and guaranteed to work under any
>>> conforming implementation, it's what I'd recommend.
>>
>> Once upon a time and long ago <G> there was something called X/Open and the
>> first (only?) programming language other than C for which this consortium
>> provided a Standard was COBOL. As this Standard assumed (???) a "Unix-like"
>> "Open System" environment, they assumed that "environment variables" were an
>> operating system facility. THEREFORE< this COBOL Standard provide a way of
>> getting "environment variables" (and command-lime parameters). Many (there were
>> MANY in those days) "conforming implementations" provided this syntax via the
>> ACCEPT and DISPLAY statements.
>>
>> This syntax/semantics was never adopted within the ANSI or ISO COBOL Standards.

I meant "any conforming CGI/1.1 implementation". Sorry about the
ambiguity; I wasn't even thinking of whether the COBOL program
supported the ENVIRONMENT-NAME and ENVIRONMENT-VALUE special registers.

> The syntax of 'DISPLAY .. UPON ..' and 'ACCEPT .. FROM ..' seems to be
> completely conforming. The only issue is what 'Environment-Name' and
> 'Environment-Value' relates to in the SPECIAL-NAMES paragraph and what
> the implementation does with these.

True, but then the construction as a whole isn't guaranteed to work
(as a method of getting the request content-body in a CGI script) in
every conforming COBOL implementation. It's not enough for the code to
be acceptable to the COBOL implementation; for it to work in this
sense (which is the sense I meant), it has to actually retrieve the
value of the CGI CONTENT_LENGTH metavariable, in a suitable form.

So I have to agree with Bill, even though the point he contests wasn't
actually the one I intended to make.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Richard wrote:
>
> The 'Request Method" environment variable should contain 'POST' or
> 'GET' allowing this source to be determined adequately.

Technically, the REQUEST_METHOD CGI metavariable, which is usually an
environment variable.

> It is possible
> for "CONTENT LENGTH" to be set even when the "Query String" variable
> contains the data.

Possible, but only legal if the request uses the POST method *and* a
query string in the Request-URI (allowed, but rare). And in that case,
the script had better be expecting data in both channels and know what
to do with it.

I was thinking of the more common case, where a script handles both
GET and POST requests (typically for different operations).

> There are some servers (probably obsolete) than can pass the content
> in a disk file in which case the file name is passed as a variable.

Sure. There are all sorts of servers, which is why I restricted my
comments to conforming CGI/1.1 implementations.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

It is true that any conforming implementation must support DISPLAY UPON and
ACCEPT FROM. (Actually, I think this was "level 2 of the Nucleus in the OLD '85
Standard - but that is semi-irrelevant). HOWEVER, what mnemonic names may be
used in the special-names paragraph is totally "implementor defined".
Therefore, there is no reason that a conforming compiler MUST support
ENVIRONMENT-NAME/VALUE in the special-names paragraph - and need not even
"cleanly compile" such a program. (An X/Open conforming implementation MUST
support these.)

FYI,
There is a "common" extension to the Standard that allows ACCEPT FROM and
DISPLAY UPON to actually directly reference the relevant mnemonic, e.g.
Accept XYZ from Environment-Value

without having ENVIRONMENT-VALUE in the special-names paragraph (associated with
the external/system device). However, that too is an extension and may or may
not be portable.

Bottom-Line:
There is no "guaranteed to be portable" way of getting an environment
variable's value (in COBOL). The ACCEPT/DISPLAY system is quite portable, but
not universally so. Check your compiler documentation for what IT supports -
and if you can't find something, check your O/S and see if it has an API that
you can access from within COBOL.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@azonic.co.nz> wrote in message
news:3e382be1-fcfa-450c-82c7-5b78dc96c7ae@w1g2000prk.googlegroups.com...
On Aug 29, 7:35 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> See below
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com"Michael Wojcik" <mwoj...@newsguy.com> wrote in
> message
>
> news:g96b4i02riq@news5.newsguy.com...
>
>
>
> > Richard wrote:
> >> On Aug 28, 12:49 am, "Michael Mattias" <mmatt...@talsystems.com>
> >> wrote:
> >>> "Richard" <rip...@azonic.co.nz> wrote in message
>
> >>>news:7305512a-f9cc-48be-96a0-c82e9ab18f5e@v26g2000prm.googlegroups.com...>MCM
> >>> wrote
> Concerning ...
> > Correct. Systems which can indicate EOF to the script, MAY do so after
> > writing CONTENT_LENGTH octets, but are not required to. So if the
> > server reliably signals EOF after writing the content-body to the
> > script, and it's acceptable for the script to depend on that behavior,
> > then the script can read until EOF.
>
> >> DISPLAY "CONTENT LENGTH" UPON Environment-Name
> >> ACCEPT Content-Length FROM Environment-Value
> >> ACCEPT Content(1:FUNCTION NUMVAL(Content-Length))
> >> FROM CONSOLE
>
> > Since this is simple, clear, and guaranteed to work under any
> > conforming implementation, it's what I'd recommend. (Probably with
> > some error checking, just in case.)
>
> Well, Yes and No ....
>
> Once upon a time and long ago <G> there was something called X/Open and the
> first (only?) programming language other than C for which this consortium
> provided a Standard was COBOL. As this Standard assumed (???) a "Unix-like"
> "Open System" environment, they assumed that "environment variables" were an
> operating system facility. THEREFORE< this COBOL Standard provide a way of
> getting "environment variables" (and command-lime parameters). Many (there
> were
> MANY in those days) "conforming implementations" provided this syntax via the
> ACCEPT and DISPLAY statements.
>
> This syntax/semantics was never adopted within the ANSI or ISO COBOL
> Standards.

The syntax of 'DISPLAY .. UPON ..' and 'ACCEPT .. FROM ..' seems to be
completely conforming. The only issue is what 'Environment-Name' and
'Environment-Value' relates to in the SPECIAL-NAMES paragraph and what
the implementation does with these.

It may well be that a different implementation does nothing with these
statements, or reads a disk file, or, well, anything.

It is true that if the requirement is to read environment variables
then one will have to see how the particular implementation allows
this. With MicroSoft 4.5 on OS/2 I had to use CALL "_EXTNAME"
USING ...

But I don't think that either are non-conforming.




> There was "interest" expressed by WG4 (the international COBOL standards
> committee) in getting facility (possibly with this syntax) into the next
> revision of the ANSI/ISO COBOL Standard. The assignment for providing (and
> updating) such a proposal was accepted by Micro Focus (a member of J4, not
> PL22.4) the US COBOL Standards committee. However, Micro Focus failed to
> provide such a proposal (with suggested updates) to J4 in a "timely" manner
> and,
> therefore, this feature is NOT included in the working draft of the next COBOL
> revision (much less in any existing ANSI/ISO COBOL Standard).
>
> Bottom-Line:
> Should any COBOL user think that this is a critical feature to include within
> the NEXT revision of the COBOL Standard, they should contact their NATIONAL
> STANDARDS BODY (not PL22.4 aka J4) and request that this topic be placed on
> the
> agenda for the WG4 meeting scheduled for October of this year.
> Should you think that what is and is not in the ANSI/ISO COBOL Standard is
> irrelevant to how you use COBOL and if your COBOL implementation provides this
> (or comparable) feature, then you may chuckle at and ignore this
> comp.lang.cobol
> thread.
>
> P.S. If you are interested in seeing how one implementation that (IBM
> mainframe
> COBOL) does NOT support this syntax handles the issue, see:
>
> http://publibz.boulder.ibm.com/cgi-b...OKS/CEEA3180/2...

On Thu, 28 Aug 2008 17:18:48 -0500, William M. Klein wrote
(in article <cvFtk.596412$3p2.149782@fe10.news.easynews.com> ):

> It is true that any conforming implementation must support DISPLAY UPON and
> ACCEPT FROM. (Actually, I think this was "level 2 of the Nucleus in the OLD
> '85
> Standard - but that is semi-irrelevant). HOWEVER, what mnemonic names may be

> used in the special-names paragraph is totally "implementor defined".
> Therefore, there is no reason that a conforming compiler MUST support
> ENVIRONMENT-NAME/VALUE in the special-names paragraph - and need not even
> "cleanly compile" such a program. (An X/Open conforming implementation MUST
> support these.)
>
> FYI,
> There is a "common" extension to the Standard that allows ACCEPT FROM and
> DISPLAY UPON to actually directly reference the relevant mnemonic, e.g.
> Accept XYZ from Environment-Value
>
> without having ENVIRONMENT-VALUE in the special-names paragraph (associated
> with
> the external/system device). However, that too is an extension and may or
> may
> not be portable.
>
> Bottom-Line:
> There is no "guaranteed to be portable" way of getting an environment
> variable's value (in COBOL). The ACCEPT/DISPLAY system is quite portable,
> but
> not universally so. Check your compiler documentation for what IT supports -

> and if you can't find something, check your O/S and see if it has an API that

> you can access from within COBOL.
>
>


Amen! UNder VMS for example, the common environment variables can be found as
"SYMBOLS" or "LOGICALS" ,which are - well - different.

I got bit by that a while back, because the VMS C runtime will look for
LOGICALS first, ten SYMBOLS but the COBOL runtime will only look for
LOGICALS. Different library call to get SYMBOLS.

And you don't WANT to know what a Wang VS system webserver does... trust me,
you REALLY don't.

-Paul