COBOL for utility program under Linux.

Richard wrote:
>
> Given that he is discussing web servers and Linux is running the
> majority of all web sites (see Netcraft) then how many are using a
> Linux desktop is irrelevant.

Good point. Looks like Apache runs about 42% vs Microsoft at about 38%.

But the trend for Apache is decidedly down since 2005 (from a high of about
70%) while it's the reverse for Microsoft (up from about 20%). See:
http://news.netcraft.com/archives/we...er_survey.html

>
> Of course the _actual_ number of Linux desktops is quite unknown, it
> is not like there many 'sales' figures. Many who bought Vista machines
> seem to be shifting to Ubuntu, or at least those who can't get XP
> install disks.

I didn't mention "actual" numbers.

The percentage of people using Linux on the desktop is measured the same way
as the percentage using Vista or XP or anything else. For example, when web
traffic is monitored, the originating OS is communicated within the data
stream. These relative numbers can be trapped and evaluated. The latest
compilation I've seen is that all varieties of Linux account for less than
1% of desktop web traffic.*

It could be that the vast majority of Linux users don't use the web or in
any other way announce their presence to the world. If, for example, only
one Linux user out of every 50 million checked weather.com once a day, that
might account for the dismal incidence of Linux in various tabulation
schemes.

Come to think on it, that may very well be the case...

--------
* See XIT stats at:
http://en.wikipedia.org/wiki/Usage_s...rating_systems

On Aug 26, 12:41*am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> I do NOT know the prices of various COBOLs and COBOL run-times for "server-side"
> applications. *However, besides the Fujitsu suggestions that others have made,
> what you want reminds me of the PerCOBOL type environment. *As I say, Idon't
> know what they would charge for a server or ISeries environment, but you might
> want to look at the information at:
>
> http://www.legacyj.com/lgcyj_perc1.html
>
> --
> Bill Klein
> *wmklein <at> ix.netcom.com"PR" <paul.rauler...@gmail.com> wrote in message
>
> news:7b5615b6-00d2-4a0b-8b8d-3c2bd3d44963@m44g2000hsc.googlegroups.com...
>
> > 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?
>
> > -Pauil

Thanks Bill! I had forgotten all about them. Last time I looked, they
were pretty expensive, but in comparison to what MicroFocus seems to
have done, exven expensive can be cheap!

On Aug 27, 12:41*am, "Michael Mattias" <mmatt...@talsystems.com>
wrote:
> "Pete Dashwood" <dashw...@removethis.enternet.co.nz> wrote in message
>
> news:6hi9jfFmcpcdU1@mid.individual.net...
>
>
>
> > "Richard" <rip...@azonic.co.nz> wrote in message
> >news:ee72723b-2d10-4566-a9bc-c32544612532@b38g2000prf.googlegroups.com....
> > On Aug 26, 11:28 am, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
>
> >> If it is CGI it is very easy to use a free COBOL compiler with a free
> >> runtime (like Fujitsu which can be downloaded from their
> >> site:www.adtools.com)
>
> > Version 3 is a) Windows only (and probably not Vista so for the 7 year
> > old XP or earlier), b) free for students, c) not suitable for
> > production code.
>
> >> CGI really only needs ACCEPT and DISPLAY, although later versions of
> >> Fujitsu
> >> (5.0 and above, if I remember correctly...) provide a full Web
> >> development
> >> environment for COBOL server side code. The full support is excellent and
>
> 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')

'UPON COMMAND LINE' is not stdin and stdout, it is the stuff following
the program name as parameters to the command.

'UPON CONSOLE' probably is stdin and stdout (depending on
implementation).

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' ?

> I don't know squat about ISAPI.

Fujitsu includes a set of CALLable routines that will interact with
the web servers in whatever way is suitable.

With CGI the program, and run-time, is loaded on every interaction,
other mechanisms allow the program to stay resident and interact by
calling a 'get request' routine.

On Aug 27, 12:43*am, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
> Richard wrote:
>
> > Given that he is discussing web servers and Linux is running the
> > majority of all web sites (see Netcraft) then how many are using a
> > Linux desktop is irrelevant.
>
> Good point. Looks like Apache runs about 42% vs Microsoft at about 38%.
>
> But the trend for Apache is decidedly down since 2005 (from a high of about
> 70%) while it's the reverse for Microsoft (up from about 20%). See:http://news.netcraft.com/archives/we...er_survey.html

Microsoft is up from 0%. The web was running for years before Bill
Gates even noticed it (edition 1 of 'The Road Ahead' makes no mention
of it), and then he tried to avoid it with the original MSN.

One of the ways in which Microsoft has made a jump in the number of
domains measured over the last couple of years is that they have given
free machines, and other 'marketing incentives' to ISPs to hold their
'parked' domains. These are registered domain names with no actual
sites, just an 'under construction' page. One machine can host tens of
thousands of these.

Several million domain names have been moved to Windows this way over
the last two or three years. You can see the results in the graphs,
but what it shows is that Windows is a great host if you don't want to
do anything.

> > Of course the _actual_ number of Linux desktops is quite unknown, it
> > is not like there many 'sales' figures. Many who bought Vista machines
> > seem to be shifting to Ubuntu, or at least those who can't get XP
> > install disks.
>
> I didn't mention "actual" numbers.
>
> The percentage of people using Linux on the desktop is measured the same way
> as the percentage using Vista or XP or anything else. For example, when web
> traffic is monitored, the originating OS is communicated within the data
> stream. These relative numbers can be trapped and evaluated. The latest
> compilation I've seen is that all varieties of Linux account for less than
> 1% of desktop web traffic.*
>
> It could be that the vast majority of Linux users don't use the web or in
> any other way announce their presence to the world.

Business computers, for example, aren't usually surfing the web all
day.

> If, for example, only
> one Linux user out of every 50 million checked weather.com once a day, that
> might account for the dismal incidence of Linux in various tabulation
> schemes.
>
> Come to think on it, that may very well be the case...

Linux users may well not bother much with Twitter or MySpace
preferring to do useful stuff rather than time wasting. Oh wait, I am
doing the latter here !!

As for weather I have my own weather station.

> --------
> * See XIT stats at:
> *http://en.wikipedia.org/wiki/Usage_s...rating_systems

On Aug 27, 12:00*am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:ee72723b-2d10-4566-a9bc-c32544612532@b38g2000prf.googlegroups.com...
> On Aug 26, 11:28 am, "Pete Dashwood"
>
>
>
> <dashw...@removethis.enternet.co.nz> wrote:
> > Sorry for previous blank post...finger trouble.
>
> > More interspersed below...
>
> > "PR" <paul.rauler...@gmail.com> wrote in message
>
> >news:7b5615b6-00d2-4a0b-8b8d-3c2bd3d44963@m44g2000hsc.googlegroups.com....
>
> > > 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.
>
> > Now, can we be clear here? Are you writing some server side CGI or are you
> > writing a desktop utility?
>
> > If it is CGI it is very easy to use a free COBOL compiler with a free
> > runtime (like Fujitsu which can be downloaded from their
> > site:www.adtools.com)
>
> Version 3 is a) Windows only (and probably not Vista so for the 7 year
> old XP or earlier), b) free for students, c) not suitable for
> production code.
>
> > CGI really only needs ACCEPT and DISPLAY, although later versions of
> > Fujitsu
> > (5.0 and above, if I remember correctly...) provide a full Web development
> > environment for COBOL server side code. The full support is excellent and
> > I
> > have written both CGI and ISAPI code in it.
>
> > > 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.
>
> > Are these all web servers or do they want a desktop utility?
> >I am not sure that VMS or iSeries are useful as desktop computers.
>
> I have written "desktop" applications for both...
>
>
>
> > > 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...
>
> > Yes, it is definitely overpriced and then you pay a runtime fee as well....
> > There is a limited marketplace, mainly comprised of people with a COBOL
> > mindset who are stuck with a large Legacy investment and no idea what to
> > do
> > about it. You can't blame MF for squeezing it.
>
> > > 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...
>
> > You could always use a language other than COBOL.
>
> > Write your utility as a Java servlet or a server side script using Python,
> > Ruby, PHP or similar. C# will run under .NET or Mono on all of the
> > platforms
> > you describe.
> >When was Mono ported to VMS or iSeries ?
>
> "Mono" is an Open Source initiative. We have port(ing)ed it to OpenVMS
> 8.3 on Alpha and Integrity to try and justify our existence (nothing better
> to
> do...*literally*)."
>
> See:http://www.archivum.info/comp.os.vms.../msg01123.html
>
> Do try and keep up, Richard... :-)

"Port(ing)ed" seems to mean they threw it at a compiler and are now
dredging through the entrails (or not bothering).

And a link to Mono on iSeries would be useful too.


> > Web server code is one of the jobs that COBOL is NOT ideally
> > suited for.
>
> Cobol is fine for web servers. As good as it is for all other types of
> applications.
>
> Nonsense! COBOL is good for COBOL applications. There are other tools MUCH
> better suited for other applications, AND much cheaper.

There may well be 'better' tools for many jobs, but Cobol is perfectly
usable for web servers.

> To recommend COBOL
> over these tools is simply irresponsible.

I was obviously _far_ too subtle with my "As good as it is for ...".

However, if you read the _actual_ question you may note that the
initial requirement is "some small interface programs to put a bit of
the data up on the web.".

So, from an existing application he want to give access to the data.
It is likely that this is using indexed files. The easiest, and
safest, way to access those data files is with Cobol. Adding a CGI web
front end to the data is probably easier than building an edifice of
Mono on VMS.

In fact I posted one to this group some years ago here:

http://groups.google.com/group/comp....fba58bcc1ab315

(or search this group for CGIDATA)


> > Just ensure that the presentation is separated from the
>
> lo>gic (ie use templating).
>
> Good advice no matter which tool you end up using...
>
> > Paying $22,000 for something, when there are better tools available for
> > free, is simply a no-brainer.
>
> > > Any suggestions?
>
> > Yes.
>
> > Don't use COBOL.

On Aug 27, 12:43*am, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
> Richard wrote:
>
> > Given that he is discussing web servers and Linux is running the
> > majority of all web sites (see Netcraft) then how many are using a
> > Linux desktop is irrelevant.
>
> Good point. Looks like Apache runs about 42% vs Microsoft at about 38%.
>
> But the trend for Apache is decidedly down since 2005 (from a high of about
> 70%) while it's the reverse for Microsoft (up from about 20%). See:http://news.netcraft.com/archives/we...er_survey.html
>
>
>
> > Of course the _actual_ number of Linux desktops is quite unknown, it
> > is not like there many 'sales' figures. Many who bought Vista machines
> > seem to be shifting to Ubuntu, or at least those who can't get XP
> > install disks.
>
> I didn't mention "actual" numbers.
>
> The percentage of people using Linux on the desktop is measured the same way
> as the percentage using Vista or XP or anything else. For example, when web
> traffic is monitored, the originating OS is communicated within the data
> stream. These relative numbers can be trapped and evaluated. The latest
> compilation I've seen is that all varieties of Linux account for less than
> 1% of desktop web traffic.*
>
> It could be that the vast majority of Linux users don't use the web or in
> any other way announce their presence to the world.

What is more likely is that a greater proportion of Linux users run
Firefox or Opera and have Adblocker and NoScript. Thus they generate a
much smaller number of connects and hits while getting the same actual
information from the sites that they _want_ to visit.

Linux users don't get infected by Spyware that is calling home or
otherwise generating traffic that is invisible to the average Windows
user.

Linux users also run far fewer zombies (none?) and thus generate
almost no unattended traffic.

What I did note was that Vista was poorly represented in the figures.
Only 10% - 15% in spite of this being on almost all computers sold for
nearly two years. This may also reflect that they get fewer spyware
and zombies and that they may use Firefox more and thus generate much
less traffic for the same amount of browsing.


> If, for example, only
> one Linux user out of every 50 million checked weather.com once a day, that
> might account for the dismal incidence of Linux in various tabulation
> schemes.
>
> Come to think on it, that may very well be the case...
>
> --------
> * See XIT stats at:
> *http://en.wikipedia.org/wiki/Usage_s...rating_systems

"Richard" <riplin@azonic.co.nz> wrote in message
news:52ec766e-ffed-44ee-931e-048ec5d1b2cc@a3g2000prm.googlegroups.com...
On Aug 27, 12:00 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:ee72723b-2d10-4566-a9bc-c32544612532@b38g2000prf.googlegroups.com...
> On Aug 26, 11:28 am, "Pete Dashwood"
>
>
>
> <dashw...@removethis.enternet.co.nz> wrote:
> > Sorry for previous blank post...finger trouble.
>
> > More interspersed below...
>
> > "PR" <paul.rauler...@gmail.com> wrote in message
>
> >news:7b5615b6-00d2-4a0b-8b8d-3c2bd3d44963@m44g2000hsc.googlegroups.com...
>
> > > 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.
>
> > Now, can we be clear here? Are you writing some server side CGI or are
> > you
> > writing a desktop utility?
>
> > If it is CGI it is very easy to use a free COBOL compiler with a free
> > runtime (like Fujitsu which can be downloaded from their
> > site:www.adtools.com)
>
> Version 3 is a) Windows only (and probably not Vista so for the 7 year
> old XP or earlier), b) free for students, c) not suitable for
> production code.
>
> > CGI really only needs ACCEPT and DISPLAY, although later versions of
> > Fujitsu
> > (5.0 and above, if I remember correctly...) provide a full Web
> > development
> > environment for COBOL server side code. The full support is excellent
> > and
> > I
> > have written both CGI and ISAPI code in it.
>
> > > 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.
>
> > Are these all web servers or do they want a desktop utility?
> >I am not sure that VMS or iSeries are useful as desktop computers.
>
> I have written "desktop" applications for both...
>
>
>
> > > 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...
>
> > Yes, it is definitely overpriced and then you pay a runtime fee as
> > well...
> > There is a limited marketplace, mainly comprised of people with a COBOL
> > mindset who are stuck with a large Legacy investment and no idea what to
> > do
> > about it. You can't blame MF for squeezing it.
>
> > > 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...
>
> > You could always use a language other than COBOL.
>
> > Write your utility as a Java servlet or a server side script using
> > Python,
> > Ruby, PHP or similar. C# will run under .NET or Mono on all of the
> > platforms
> > you describe.
> >When was Mono ported to VMS or iSeries ?
>
> "Mono" is an Open Source initiative. We have port(ing)ed it to OpenVMS
> 8.3 on Alpha and Integrity to try and justify our existence (nothing
> better
> to
> do...*literally*)."
>
> See:http://www.archivum.info/comp.os.vms.../msg01123.html
>
> Do try and keep up, Richard... :-)

"Port(ing)ed" seems to mean they threw it at a compiler and are now
dredging through the entrails (or not bothering).

And a link to Mono on iSeries would be useful too.


> > Web server code is one of the jobs that COBOL is NOT ideally
> > suited for.
>
> Cobol is fine for web servers. As good as it is for all other types of
> applications.
>
> Nonsense! COBOL is good for COBOL applications. There are other tools MUCH
> better suited for other applications, AND much cheaper.

There may well be 'better' tools for many jobs, but Cobol is perfectly
usable for web servers.

> To recommend COBOL
> over these tools is simply irresponsible.

I was obviously _far_ too subtle with my "As good as it is for ...".

However, if you read the _actual_ question you may note that the
initial requirement is "some small interface programs to put a bit of
the data up on the web.".

So, from an existing application he want to give access to the data.
It is likely that this is using indexed files. The easiest, and
safest, way to access those data files is with Cobol. Adding a CGI web
front end to the data is probably easier than building an edifice of
Mono on VMS.

In fact I posted one to this group some years ago here:

http://groups.google.com/group/comp....fba58bcc1ab315

(or search this group for CGIDATA)


> > Just ensure that the presentation is separated from the
>
> lo>gic (ie use templating).
>
> Good advice no matter which tool you end up using...
>
> > Paying $22,000 for something, when there are better tools available for
> > free, is simply a no-brainer.
>
> > > Any suggestions?
>
> > Yes.
>
> > Don't use COBOL.

A good response, and sound advice to the OP...

I having nothing to add :-)

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

On Mon, 25 Aug 2008 19:04:20 -0700 (PDT), PR <paul.raulerson@gmail.com> wrote:

>On Aug 25, 6:16*pm, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
>> Pete Dashwood 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?
>>
>> I think what Pete meant to say was that Fijutsu has a version that runs
>> under Linux.
>>
>> But why? Linux represents less than 1% of the desktop market.
>>
>> Linux DOES represent about 85% of the decibel level, so maybe that's what
>> the client is hearing.
>
>
>I tend to avoid the "desktop market" and just put all the interfaces
>on the web these days. Simpler, and people really like it. Except of
>course, for really high speed data entry screens. I use Windows or
>green-screens for those.
>
>
>I'm really talking about the server side.
>-Paul

Envyr is still selling their Interactive COBOL, with a CGI runtime:
http://www.icobol.com/products/cgiruntime.shtml

I wrote our online ordering system in it, and it's running on RHEL5.


--
tim boyer
tim@denmantire.com

"Richard" <riplin@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')

>'UPON COMMAND LINE' is not stdin and stdout, it is the stuff following
>the program name as parameters to the command.

>'UPON CONSOLE' probably is stdin and stdout (depending on
>implementation).

Woo, the seven years since I last did anything in COBOL has apparently taken
its toll. (Or maybe it's the increased number of candles on the birthday
cake?)

>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. Under Windows using my BASIC complier, you can detect
"end of file" on STDIN when reading the HTML submitted by the caller...
thereby giving you everything you need to process. Granted it's clunkier to
do that in COBOL, but it should be doable. Maybe you have to read it in a
byte at a time, but when EOF is detected, that's all there is, there ain't
no more.

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. So I guess you are
correct about ACCEPT being plenty, as long as the conpiler supports
something akin to the MF extensions.

I was just trying to help.

MCM

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')
>
> >'UPON COMMAND LINE' is not stdin and stdout, it is the stuff following
> >the program name as parameters to the command.
> >'UPON CONSOLE' probably is stdin and stdout (depending on
> >implementation).
>
> Woo, the seven years since I last did anything in COBOL has apparently taken
> its toll. (Or maybe it's the increased number of candles on the birthday
> cake?)
>
> >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.
Whether this is actually needed depends on the implementation.

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


> Under Windows using my BASIC complier, you can detect
> "end of file" on STDIN when reading the HTML submitted by the caller...
> thereby giving you everything you need to process. Granted it's clunkier to
> do that in COBOL, but it should be doable. Maybe you have to read it in a
> byte at a time, but when EOF is detected, that's all there is, there ain't
> no more.
>
> 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. *So I guess you are
> correct about ACCEPT being plenty, *as long as the conpiler supports
> something akin to the MF extensions.
>
> I was just trying to help.
>
> MCM