Using Cobol when writing CGI's for the OSU web server.

[Jan-Erik Söderholm]

Hi.
The "docs" that comes with the OSU web server kit has examples
files for C, Java, Perl and I think also Fortran in the latest kit.

Now, does anyone see any particular reason why one shouldn't
be able to use Cobol against the CGI API's ?

I'm evaluating adding a few simple web "statistics" pages
to an factory control system where the bulk of the logic
in the applications are in Cobol using VT-interfaces
(through a form management tool I've forgotted the name
of, but is was not FMS or TDMS at least...)

The plan is to keep the bulk program logic in Cobol but
create som html instead of writing to the VT-interface.

If the Cobol-way of doing thing isn't compatible with
the OSU CGI APi's, I guess one can write a few C-stubs,
right ?

Best Regards,
Jan-Erik.

[b***@instantwhip.com]

I do it with Dibol all the time ... but with Purveyor ...

[Paul Sture]

In article <K5TZg.20396$***@newsb.telia.net>,
Jan-Erik Söderholm <jan-***@telia.com> wrote:

> Hi.
> The "docs" that comes with the OSU web server kit has examples
> files for C, Java, Perl and I think also Fortran in the latest kit.
>
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?
>
> I'm evaluating adding a few simple web "statistics" pages
> to an factory control system where the bulk of the logic
> in the applications are in Cobol using VT-interfaces
> (through a form management tool I've forgotted the name
> of, but is was not FMS or TDMS at least...)
>
> The plan is to keep the bulk program logic in Cobol but
> create som html instead of writing to the VT-interface.
>
> If the Cobol-way of doing thing isn't compatible with
> the OSU CGI APi's, I guess one can write a few C-stubs,
> right ?
>

COBOL should be fine. No need to write anything in C-stubs.

--
Paul Sture

[Arne Vajhøj]

Jan-Erik Söderholm wrote:
> The "docs" that comes with the OSU web server kit has examples
> files for C, Java, Perl and I think also Fortran in the latest kit.
>
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?

> The plan is to keep the bulk program logic in Cobol but
> create som html instead of writing to the VT-interface.
>
> If the Cobol-way of doing thing isn't compatible with
> the OSU CGI APi's, I guess one can write a few C-stubs,
> right ?

Any language should work for CGI.

BTW, the CGI standard was created to be language neutral.

You can either call an EXE written in COBOL directly or
use a wrapper. If you want wrapper, then I would suggest
DCL.

Arne

[Jan-Erik Söderholm]

Arne Vajhøj wrote:

> You can either call an EXE written in COBOL directly or
> use a wrapper. If you want wrapper, then I would suggest
> DCL.

Absolutely, DCL is what I use today, but I thought one could
get a more "clean" environment buy letting the server talk to
the Cobol EXE's directly.

Anyway, from other replies it's clear that this shouldn't
be any major problem...

Thanks all !

Jan-Erik.

[JF Mezei]

Jan-Erik Söderholm wrote:
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?

Because COBOL isn't considered trendy/modern and many younger folks will
laugh at you ? :-)


One way to interface with the OSU server is via decnet. Your COBOL app
gets a DECNET link , opend read write SYS$NET and you can then issue
commands to the OSU server to get the connection details (look at the
bottom of WWWEXEC.COM for list of commands you can issue and the
responses you can expect).

Once the initial dialogue is done, you then send the contents one line
at a time.

One issue that is important to consider is of line terminators. The HTTP
system really wants to see CR/LF ends to the lines. There is a mode
where OSU will add those for you. But it is best if your COBOL app can
do that. (not sure about the COBOL run time handling of end of records
when the output is a network device.

[Richard Maher]

Hi Jan-Erik,

Just out of curiosity, what exactly are the advantages of using a web server
in this case, as opposed to connecting to an INETd (or other) server on your
VMS box via TCP/IP sockets?

Security? No VPN and sick of waiting for IPsec?

Don't like stateful, and context-rich, connection-oriented protocols that
map almost directly to what the existing Cobol programs are already doing?

You think it's cutting edge technology that your CGI script can be cajoled
into not opening/closing it's files and creating a new process everytime for
each request?

You think it's a wonderful idea to shut down your server processes after an
arbitrary amount of time or requests (even at busy periods) just so you can
flush out those memory/resource leaks?

Still, I marginally prefer this type of crap to JDBC, but am surprised why
you haven't gone for that equally thoughtless approach?

Maybe, in a perfect world we'd only need *one* TCP/IP port number 'cos
everyting else like Telnet, FTP and Mail and App1-to-n could be done through
a ubiquitous Web Server and a scripting language. What could possibly more
optimal for performance, security and functionality?

Given that, these days, no one gets paid for planning and designing stuff,
and as long as you can show the accountants a Web Page from a stealth
project knocked up in someone's lunch break, then we'll shove the
fencing-wire and insulating tape in later. *God forbid anyone from asking
for the ACID properties of a true two-phase commit!* But with bugger-all
support from anyone in HP/VMS who can blame you? - Bridgeworks my arse! How
much money have those self-serving crooks squandered?

> Because COBOL isn't considered trendy/modern and many younger folks will
> laugh at you ? :-)

And these same illumni look upon VMS with awe and respect? But I concede
that COBOL is about as fashionable as doing the job correctly. But I guess I
just never shared evryone else's pashion for failerd-pants, shoulder-pads,
tattoos, ear-rings and a shit-load of metal in my face! (Neither do I wear
sandals or have a ponytail. Sorry Brian :-)

Regards Richard Maher

"JF Mezei" <***@teksavvy.com> wrote in message
news:***@teksavvy.com...
> Jan-Erik Söderholm wrote:
> > Now, does anyone see any particular reason why one shouldn't
> > be able to use Cobol against the CGI API's ?
>
> Because COBOL isn't considered trendy/modern and many younger folks will
> laugh at you ? :-)
>
>
> One way to interface with the OSU server is via decnet. Your COBOL app
> gets a DECNET link , opend read write SYS$NET and you can then issue
> commands to the OSU server to get the connection details (look at the
> bottom of WWWEXEC.COM for list of commands you can issue and the
> responses you can expect).
>
> Once the initial dialogue is done, you then send the contents one line
> at a time.
>
> One issue that is important to consider is of line terminators. The HTTP
> system really wants to see CR/LF ends to the lines. There is a mode
> where OSU will add those for you. But it is best if your COBOL app can
> do that. (not sure about the COBOL run time handling of end of records
> when the output is a network device.

[Jan-Erik Söderholm]

Richard Maher skrev:
> Hi Jan-Erik,
>
> Just out of curiosity, what exactly are the advantages of using a web server
> in this case,

A user interface that is available everyware.
And, I don't thing you know enough about "this case"...

Best Regards,
Jan-Erik.

[Richard Maher]

Hi Jan-Erik,

First, let me appologize for what (having re-read my post) appeared to be a
pretty personal/specific attack. I was, in fact, ranting at the whole world
and not you, your company, or your application specifically.

> A user interface that is available everyware.

I am by no means trying to take that away from you! I simply suggest that
once your web page has been displayed (and whatever button clicked) that a
second pipe be opened (via Java sockets or ActiveX controls or whatever) to
your server to obtain the COBOL controlled data that you spoke of. Look, I'm
not a Web developer and I have no idea what tools you are using or what
security restrictions you're under, but the infrastructure to create a
Socket, Connect to your server and then Send/Recv data is all there
somewhere.

How you keep track of (or tear down) the Socket(s) that you created when
flicking from Web page to page is up to your Web developers. But rest
assured that they are not required to be Christopher Columbus or Neil
Armstrong with this. Maybe it could be like Oracles JDBC Thin Driver where
you download a mini-application to your user PC's. Again, the security and
performance issues are down to the application.

I'm just saying that it's one thing to have Fat-Client Syndrome but most
people's appear to be positively anorexic! By all means use the ubiquitous
web interface to inroduce the couple to each other, use the internet, just
stop trying to fit the cammel through the eye of the browser!

> And, I don't thing you know enough about "this case"...

I agree 100% which is why I was asking questions. (But again, not necessary
at you, but of anyone who is doing similar things)

Cheers Richard Maher

PS. I hope "skrev" is good :-)

"Jan-Erik Söderholm" <jan-***@telia.com> wrote in message
news:wL_Zg.20409$***@newsb.telia.net...
> Richard Maher skrev:
> > Hi Jan-Erik,
> >
> > Just out of curiosity, what exactly are the advantages of using a web
server
> > in this case,
>
> A user interface that is available everyware.
> And, I don't thing you know enough about "this case"...
>
> Best Regards,
> Jan-Erik.

[Arne Vajhøj]

Richard Maher wrote:
>> A user interface that is available everyware.
>
> I am by no means trying to take that away from you! I simply suggest that
> once your web page has been displayed (and whatever button clicked) that a
> second pipe be opened (via Java sockets or ActiveX controls or whatever) to
> your server to obtain the COBOL controlled data that you spoke of. Look, I'm
> not a Web developer and I have no idea what tools you are using or what
> security restrictions you're under, but the infrastructure to create a
> Socket, Connect to your server and then Send/Recv data is all there
> somewhere.

Very likely only port 80 and 443 are open in the firwall for
HTTP and HTTPS.

> How you keep track of (or tear down) the Socket(s) that you created when
> flicking from Web page to page is up to your Web developers. But rest
> assured that they are not required to be Christopher Columbus or Neil
> Armstrong with this. Maybe it could be like Oracles JDBC Thin Driver where
> you download a mini-application to your user PC's.

Oracle thin JDBC driver are usually run server side.

JDBC client side is not widely used (for good reasons).

> I'm just saying that it's one thing to have Fat-Client Syndrome but most
> people's appear to be positively anorexic! By all means use the ubiquitous
> web interface to inroduce the couple to each other, use the internet, just
> stop trying to fit the cammel through the eye of the browser!

Often the requirements are:
- able to run in browser
- single sign on
- only HTTP(S)

If you want to be fancy then it is AJAX.

And that is 100 times worse than normal web technology.

>> And, I don't thing you know enough about "this case"...
>
> I agree 100% which is why I was asking questions. (But again, not necessary
> at you, but of anyone who is doing similar things)
>
> Cheers Richard Maher
>
> PS. I hope "skrev" is good :-)

That means "wrote" in scandinavia.

Arne

[Richard Maher]

Hi Arne,
>
> Very likely only port 80 and 443 are open in the firwall for
> HTTP and HTTPS.

Ah, ye cannay change the laws o' firewalls cap'n! She'll no' take another
port number!

> JDBC client side is not widely used (for good reasons).

Please wander over to Oracle and tell them they (and their customers) are
all dickheads for using it.

> Often the requirements are:
> - able to run in browser
> - single sign on
> - only HTTP(S)

Well far be it from me to buck the trend. That's it then; I.T. has plateaued
with what Arne says the masses are doing today! Down the pub it is!

Regards Richard Maher

PS. How many web pages that you go to require a sign-on? And then only one
for VISA, British Airways, Hertz and Holiday Inn? I want to live in Arne
world!

"Arne Vajhøj" <***@vajhoej.dk> wrote in message
news:OaB_g.22709$***@dukeread09...
> Richard Maher wrote:
> >> A user interface that is available everyware.
> >
> > I am by no means trying to take that away from you! I simply suggest
that
> > once your web page has been displayed (and whatever button clicked) that
a
> > second pipe be opened (via Java sockets or ActiveX controls or whatever)
to
> > your server to obtain the COBOL controlled data that you spoke of. Look,
I'm
> > not a Web developer and I have no idea what tools you are using or what
> > security restrictions you're under, but the infrastructure to create a
> > Socket, Connect to your server and then Send/Recv data is all there
> > somewhere.
>
> Very likely only port 80 and 443 are open in the firwall for
> HTTP and HTTPS.
>
> > How you keep track of (or tear down) the Socket(s) that you created when
> > flicking from Web page to page is up to your Web developers. But rest
> > assured that they are not required to be Christopher Columbus or Neil
> > Armstrong with this. Maybe it could be like Oracles JDBC Thin Driver
where
> > you download a mini-application to your user PC's.
>
> Oracle thin JDBC driver are usually run server side.
>
> JDBC client side is not widely used (for good reasons).
>
> > I'm just saying that it's one thing to have Fat-Client Syndrome but most
> > people's appear to be positively anorexic! By all means use the
ubiquitous
> > web interface to inroduce the couple to each other, use the internet,
just
> > stop trying to fit the cammel through the eye of the browser!
>
> Often the requirements are:
> - able to run in browser
> - single sign on
> - only HTTP(S)
>
> If you want to be fancy then it is AJAX.
>
> And that is 100 times worse than normal web technology.
>
> >> And, I don't thing you know enough about "this case"...
> >
> > I agree 100% which is why I was asking questions. (But again, not
necessary
> > at you, but of anyone who is doing similar things)
> >
> > Cheers Richard Maher
> >
> > PS. I hope "skrev" is good :-)
>
> That means "wrote" in scandinavia.
>
> Arne

[Jan-Erik Söderholm]

Richard Maher wrote :

> Hi Jan-Erik,
>
> First, let me appologize for what (having re-read my post) appeared to be a
> pretty personal/specific attack. I was, in fact, ranting at the whole world
> and not you, your company, or your application specifically.

OK, no problem. I've enjoyed reading many other post from you, so
I didn't took it to personal :-)

I fully understand what you're saying.

But, the fact is that if you'd like to add some
"bells-n-whisles" to a application that is regarded as
something old and "closed" using weird VT-something
interfaces, the far most easiest route is to add a few
web-pages with "management-info". That's a fact.

And the bulk of the business-logic is written in Cobol,
so my plan it to help them intereface that code with
the OSU server.

I have described what can quite easily be done, and they
are very positive, I'd say. Which turns into consulting
hours for me...

Now, that might not be the most perfect solution from
a technical standpoint, but that is what is regarded as
state-of-the-art today (maybe not by you and me, but who
cares about *that* ?) and it's also pretty fast/cheap to have
something running.

> PS. I hope "skrev" is good :-)

As Arne write, "skrev" is the imperfect of "skriva", or
"write/wrote" in English. *But* "skrev" is one of those
words in Swedish with double meaning, it also translates
into "crutch" or "crotch", with was *not* what I ment in this
case :-)

Best Regards,
Jan-Erik.

[Richard Maher]

Hi Jan-Erik,

At the end of the day, if that's what the customer wants and you're able to
fulfill the requirement, then it sounds like a match made in heaven! (None
of us are doing this for love after all :-)

But please let me leave you with a couple of pointers and other info I
stumbled across this arvo: -

1) It looks like you have to create a Java Applet for the Socket stuff. This
seems secure and kosher and de rigueur for everyone outside of the VMS "chip
on each shoulder" brigade.

http://java.sun.com/sfaq/#socket

2) This from some Java Socket discussion page on what the Applet(s) should
contain: -

Creating a client

To talk to a server, open a socket to the machine and port:

Socket s = new Socket("mastercard.com", 303); // port 303

When this returns, you can get input/output streams:

OutputStream out = s.getOutputStream();
PrintStream pout = new PrintStream(out);
pout.println("hi from java client");
pout.close();
s.close();

The client's input stream is pulling from the server's output stream and
vice versa.

3) See the following link for a COBOL example of an INETd server listening
on port# 303. The truly amazing bit about this example is that it shows a
VMS server participating in a ACID proof 2PC with a transaction started on a
W2K server! But let's ignore that for the moment and concentrate on the
simple message passing mechanism. What could be easier than this: -

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=966410

Please look at my COBOL code in this thread as an example of how easy it
would be to fire-up your existing COBOL functionality from a Web client.

I don't think I'm going out on a limb here to ask "What could be easier?".
Many people here are all pushing their own barrows with
Python/CGI/OSU/Apache but, if you find that (for whatever reason) you are
unable to locate the skill level in this, or any other forum, to show you
how to build a simple Java applet then I guess that you'll have to resort to
your clients support contract :-( I'm available for free to help you out
with any trouble on the VMS side.

Q: "I'd like to write a Java Applet that can talk to my VMS/UCX server"

A: Stuffed if I'd know! I wonder where you'd get help with that? (If the
low-life scum of VMS support has finished crying into their beers and to the
tabloids, then maybe they'd forget their self-obsession long enough to
consider nuturing the client base?) Nah, stick to your scorched-earth
policy; If you go down the you're taking VMS down with ya. (Wankers!)

Cheers Richard Maher

"Jan-Erik Söderholm" <jan-***@telia.com> wrote in message
news:TKJ_g.20581$***@newsb.telia.net...
> Richard Maher wrote :
>
> > Hi Jan-Erik,
> >
> > First, let me appologize for what (having re-read my post) appeared to
be a
> > pretty personal/specific attack. I was, in fact, ranting at the whole
world
> > and not you, your company, or your application specifically.
>
> OK, no problem. I've enjoyed reading many other post from you, so
> I didn't took it to personal :-)
>
> I fully understand what you're saying.
>
> But, the fact is that if you'd like to add some
> "bells-n-whisles" to a application that is regarded as
> something old and "closed" using weird VT-something
> interfaces, the far most easiest route is to add a few
> web-pages with "management-info". That's a fact.
>
> And the bulk of the business-logic is written in Cobol,
> so my plan it to help them intereface that code with
> the OSU server.
>
> I have described what can quite easily be done, and they
> are very positive, I'd say. Which turns into consulting
> hours for me...
>
> Now, that might not be the most perfect solution from
> a technical standpoint, but that is what is regarded as
> state-of-the-art today (maybe not by you and me, but who
> cares about *that* ?) and it's also pretty fast/cheap to have
> something running.
>
> > PS. I hope "skrev" is good :-)
>
> As Arne write, "skrev" is the imperfect of "skriva", or
> "write/wrote" in English. *But* "skrev" is one of those
> words in Swedish with double meaning, it also translates
> into "crutch" or "crotch", with was *not* what I ment in this
> case :-)
>
> Best Regards,
> Jan-Erik.

[Richard Maher]

Hi (again) Jan-Erik,

Things have moved on quite a bit since we last spoke. Please see the
following ITRC thread on Java applets: -

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1071300

I just can't help thinking that if you run away from this opportunity now
then you'll be running for the rest of your life :-)

Vanilla, light-weight, full function, context-rich and connection-oriented
TCP/IP Sockets *ARE* the future of VMS server interaction with the web, and
Java applets are the key to those sockets! This *IS* the turning point!
We're *NOT* running any more! I'm right beside you! Let's go forward and
rape, pillage and plunder the I.T. landscape! Let's free VMS from the
*NIX,/NT tyranny of mediocrity! ARE YOU WITH ME?

Cheers Richard Maher

PS. "Rape" in this sense, is being used as a metaphor for the liberation of
oodles of cosultancy and license fee dollars from the I.T. customer base at
large. If you feel that you've been affected by the issues raised in this
post please dial 1-800-Get-a-Life.

"Richard Maher" <***@hotspamnotmail.com> wrote in message
news:ehl54u$3ja$***@news-02.connect.com.au...
> Hi Jan-Erik,
>
> At the end of the day, if that's what the customer wants and you're able
to
> fulfill the requirement, then it sounds like a match made in heaven! (None
> of us are doing this for love after all :-)
>
> But please let me leave you with a couple of pointers and other info I
> stumbled across this arvo: -
>
> 1) It looks like you have to create a Java Applet for the Socket stuff.
This
> seems secure and kosher and de rigueur for everyone outside of the VMS
"chip
> on each shoulder" brigade.
>
> http://java.sun.com/sfaq/#socket
>
> 2) This from some Java Socket discussion page on what the Applet(s) should
> contain: -
>
> Creating a client
>
> To talk to a server, open a socket to the machine and port:
>
> Socket s = new Socket("mastercard.com", 303); // port 303
>
> When this returns, you can get input/output streams:
>
> OutputStream out = s.getOutputStream();
> PrintStream pout = new PrintStream(out);
> pout.println("hi from java client");
> pout.close();
> s.close();
>
> The client's input stream is pulling from the server's output stream and
> vice versa.
>
> 3) See the following link for a COBOL example of an INETd server listening
> on port# 303. The truly amazing bit about this example is that it shows a
> VMS server participating in a ACID proof 2PC with a transaction started on
a
> W2K server! But let's ignore that for the moment and concentrate on the
> simple message passing mechanism. What could be easier than this: -
>
>
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=966410
>
> Please look at my COBOL code in this thread as an example of how easy it
> would be to fire-up your existing COBOL functionality from a Web client.
>
> I don't think I'm going out on a limb here to ask "What could be easier?".
> Many people here are all pushing their own barrows with
> Python/CGI/OSU/Apache but, if you find that (for whatever reason) you are
> unable to locate the skill level in this, or any other forum, to show you
> how to build a simple Java applet then I guess that you'll have to resort
to
> your clients support contract :-( I'm available for free to help you out
> with any trouble on the VMS side.
>
> Q: "I'd like to write a Java Applet that can talk to my VMS/UCX server"
>
> A: Stuffed if I'd know! I wonder where you'd get help with that? (If the
> low-life scum of VMS support has finished crying into their beers and to
the
> tabloids, then maybe they'd forget their self-obsession long enough to
> consider nuturing the client base?) Nah, stick to your scorched-earth
> policy; If you go down the you're taking VMS down with ya. (Wankers!)
>
> Cheers Richard Maher
>
> "Jan-Erik Söderholm" <jan-***@telia.com> wrote in message
> news:TKJ_g.20581$***@newsb.telia.net...
> > Richard Maher wrote :
> >
> > > Hi Jan-Erik,
> > >
> > > First, let me appologize for what (having re-read my post) appeared to
> be a
> > > pretty personal/specific attack. I was, in fact, ranting at the whole
> world
> > > and not you, your company, or your application specifically.
> >
> > OK, no problem. I've enjoyed reading many other post from you, so
> > I didn't took it to personal :-)
> >
> > I fully understand what you're saying.
> >
> > But, the fact is that if you'd like to add some
> > "bells-n-whisles" to a application that is regarded as
> > something old and "closed" using weird VT-something
> > interfaces, the far most easiest route is to add a few
> > web-pages with "management-info". That's a fact.
> >
> > And the bulk of the business-logic is written in Cobol,
> > so my plan it to help them intereface that code with
> > the OSU server.
> >
> > I have described what can quite easily be done, and they
> > are very positive, I'd say. Which turns into consulting
> > hours for me...
> >
> > Now, that might not be the most perfect solution from
> > a technical standpoint, but that is what is regarded as
> > state-of-the-art today (maybe not by you and me, but who
> > cares about *that* ?) and it's also pretty fast/cheap to have
> > something running.
> >
> > > PS. I hope "skrev" is good :-)
> >
> > As Arne write, "skrev" is the imperfect of "skriva", or
> > "write/wrote" in English. *But* "skrev" is one of those
> > words in Swedish with double meaning, it also translates
> > into "crutch" or "crotch", with was *not* what I ment in this
> > case :-)
> >
> > Best Regards,
> > Jan-Erik.
>
>

[JF Mezei]

Richard Maher wrote:
> You think it's cutting edge technology that your CGI script can be cajoled
> into not opening/closing it's files and creating a new process everytime for
> each request?

At least with OSU, it is quite possible to have a server process create
a non transparent DECNET object and handle multiple requests from the
OSU web server.

For instance:

exec /scr/* velo::"0=OAJFOSU"$disk2:[www_cakes.scr]

This makes requests such as /scr/chocolate.scp to the OAJFOSU decnet
object on node VELO. That object is then able to ask OSU for the script
file specification and get $disk2:[www_wap.scr]chocolate.scp

No process is created since the network object is already existant. And
if the network application is structured properly, it can handle
multiple connections at the same time with threads or ASTs.

(the neat thing about this is that the CGI app can actually run opn a
different node.)

[Richard Maher]

Hi JF,

> At least with OSU, it is quite possible to have a server process create
> a non transparent DECNET object and handle multiple requests from the
> OSU web server.

Hoorah! But why would you want to? Why do you have that OSU
Man-in-the-middle Mr.10% What value does it add?

>
> For instance:
>
> exec /scr/* velo::"0=OAJFOSU"$disk2:[www_cakes.scr]
>
> This makes requests such as /scr/chocolate.scp to the OAJFOSU decnet
> object on node VELO. That object is then able to ask OSU for the script
> file specification and get $disk2:[www_wap.scr]chocolate.scp
>
> No process is created since the network object is already existant. And
> if the network application is structured properly, it can handle
> multiple connections at the same time with threads or ASTs.
>
> (the neat thing about this is that the CGI app can actually run opn a
> different node.)

How about you have a VMS server process up and running on TCP/IP Port#1234
that is capable of handling multiple inbound request and passing them off to
a VMS System Manager defined and prestarted/initialized group of server
processes that are ready to service the application-specific client requests
directly? Please explain what's wrong with that eh?

Tell me, with this Web Services Integration Urinal/Money-Pit (that some have
managed to keep their job at HP with) and VMS1.AU is hosting a Web Service
that does multiplication and UNIX2.UK is hosting the Commission Calculation
Service are we expecting UNIX2 only to be available for processing via VMS1?
Can it not be contacted directly if the application requires? Can, and is it
not desirable, for the CoordinationContext to be propagated from the client
to any number of services? Are they straying from the fold here JF?

Look, I could be wrong but it just appears to me as though everyone is
trying to shoe-horn square-pegs into round-holes just 'cos it's easier to
hit it with a mallet than to think about doing what's right. I see bullshit
scripting languages and Web-BROWSERs being implemented as application
middleware as being analogous to the ODBC to Strored Procedure (Poor-man's
RPC) strategy of the last 10 years. Let Web-Browsers browse. Let them "pimp"
for you services. But then, for fuck-sake ley VMS take over and deliver the
goods!

Cheers richard Maher

"JF Mezei" <***@teksavvy.com> wrote in message
news:***@teksavvy.com...
> Richard Maher wrote:
> > You think it's cutting edge technology that your CGI script can be
cajoled
> > into not opening/closing it's files and creating a new process everytime
for
> > each request?
>
> At least with OSU, it is quite possible to have a server process create
> a non transparent DECNET object and handle multiple requests from the
> OSU web server.
>
> For instance:
>
> exec /scr/* velo::"0=OAJFOSU"$disk2:[www_cakes.scr]
>
> This makes requests such as /scr/chocolate.scp to the OAJFOSU decnet
> object on node VELO. That object is then able to ask OSU for the script
> file specification and get $disk2:[www_wap.scr]chocolate.scp
>
> No process is created since the network object is already existant. And
> if the network application is structured properly, it can handle
> multiple connections at the same time with threads or ASTs.
>
> (the neat thing about this is that the CGI app can actually run opn a
> different node.)

[Phillip Helbig---remove CLOTHES to reply]

In article <***@teksavvy.com>, JF Mezei
<***@teksavvy.com> writes:

> One issue that is important to consider is of line terminators. The HTTP
> system really wants to see CR/LF ends to the lines. There is a mode
> where OSU will add those for you. But it is best if your COBOL app can
> do that. (not sure about the COBOL run time handling of end of records
> when the output is a network device.

Quote of the day:

Nearly every internet application protocol (HTTP, FTP, NNTP, SMTP) specifies
<CR><LF> as the line terminator and nearly every unix-derived application
screws it up at some point it its development.

---David Jones

[Bob Gezelter]

Jan-Erik Söderholm wrote:
> Hi.
> The "docs" that comes with the OSU web server kit has examples
> files for C, Java, Perl and I think also Fortran in the latest kit.
>
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?
>
> I'm evaluating adding a few simple web "statistics" pages
> to an factory control system where the bulk of the logic
> in the applications are in Cobol using VT-interfaces
> (through a form management tool I've forgotted the name
> of, but is was not FMS or TDMS at least...)
>
> The plan is to keep the bulk program logic in Cobol but
> create som html instead of writing to the VT-interface.
>
> If the Cobol-way of doing thing isn't compatible with
> the OSU CGI APi's, I guess one can write a few C-stubs,
> right ?
>
> Best Regards,
> Jan-Erik.

[Bob Gezelter]

Jan-Erik Söderholm wrote:
> Hi.
> The "docs" that comes with the OSU web server kit has examples
> files for C, Java, Perl and I think also Fortran in the latest kit.
>
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?
>
> I'm evaluating adding a few simple web "statistics" pages
> to an factory control system where the bulk of the logic
> in the applications are in Cobol using VT-interfaces
> (through a form management tool I've forgotted the name
> of, but is was not FMS or TDMS at least...)
>
> The plan is to keep the bulk program logic in Cobol but
> create som html instead of writing to the VT-interface.
>
> If the Cobol-way of doing thing isn't compatible with
> the OSU CGI APi's, I guess one can write a few C-stubs,
> right ?
>
> Best Regards,
> Jan-Erik.

Jan-Erik,

So long as you respect the parameter standards of the interface, the
language (or mixture of languages) used does not matter.

For maintenance purposes, I would also recommend splitting the existing
application into two components, a screen IO component and a business
logic component. Then, using the business logic as an underlying
shareable libary (see "OpenVMS Shareable Libraries: An Implementor's
Guide" from the 2000 Compaq Enterprise Technology Symposium; notes at
http://www.rlgsc.com/cets/2000/460.html ). Using a shareable libary for
the business logic ensures that the two versions of the businesss logic
ARE identical, and reduces maintenance.

- Bob Gezelter, http://www.rlgsc.com

[David Jones]

In message <K5TZg.20396$***@newsb.telia.net>,
<jan-***@telia.com> writes:
>Now, does anyone see any particular reason why one shouldn't
>be able to use Cobol against the CGI API's ?

The easiest way is to use a wrapper command procedure for the script that runs
CGI_SYMBOLS to generate the standard CGI environment variables as DCL symbols
and then run your COBOL program with output directed to net_link:. You'll
probably also want to have the procedure put the link in 'record mode' since
COBOL will be writing RMS records.

A slightly more efficient technique would be to have COBOL executables call the
functions in cgilib.c and cgilib_form.c (via stubs) to get the request
information and send the output. The efficiency gain comes from internal
buffering of the writes to the net_link: network mailbox.

I'll skip desciprition of the more esoteric scriptserver options also available.


David L. Jones | Phone: [phone]
Ohio State University | Internet:
140 W. 19th St. | ***@er6s1.eng.ohio-state.edu
Columbus, OH 43210 | [e-mail]

Disclaimer: I'm looking for marbles all day long.

[Jan-Erik Söderholm]

David Jones skrev:

> The easiest way is to use a wrapper command procedure for the script that runs
> CGI_SYMBOLS to generate the standard CGI environment variables as DCL symbols
> and then run your COBOL program with output directed to net_link:.

Yes, that's definitely an option. I was a *litte* worried about the
DCL overhead, but this is an DS20e so the DCL overhead should probably
not be any problem...

> A slightly more efficient technique would be to have COBOL executables call the
> functions in cgilib.c and cgilib_form.c (via stubs) to get the request
> information and send the output.

Yes, that was actualy was I ment to ask in the first place. :-)
Can Cobol be setup to call those cgi functions directly or
does one need C-stubs ? I guess from what you wrote above
that C-stube *are* needed.

> I'll skip desciprition of the more esoteric scriptserver options also available.

Right, I'll take that as "homework"... :-)

Thanks a lot !!
Jan-Erik.



>
>
> David L. Jones | Phone: [phone]
> Ohio State University | Internet:
> 140 W. 19th St. | ***@er6s1.eng.ohio-state.edu
> Columbus, OH 43210 | [e-mail]
>
> Disclaimer: I'm looking for marbles all day long.

[JF Mezei]

Jan-Erik Söderholm wrote:
> Can Cobol be setup to call those cgi functions directly or
> does one need C-stubs ? I guess from what you wrote above
> that C-stube *are* needed.

Back in the 1980s, I had COBOL main program call up some C routines.

The main bone of contention are strings. COBOL passes fixed length
strings (whether as a pointer to the actually buffer, or as a pointer to
a descriptop which points to the buffer). This means in practice you are
passing around blank padded fixed length strings. C likes null
terminated strings.

For binary data, it is no problem, as long as you know which definition
in cobol generates a binary short word and a binary long word.

[Bill Gunshannon]

In article <***@vaxination.ca>,
JF Mezei <***@vaxination.ca> writes:
> Jan-Erik Söderholm wrote:
>> Can Cobol be setup to call those cgi functions directly or
>> does one need C-stubs ? I guess from what you wrote above
>> that C-stube *are* needed.
>
> Back in the 1980s, I had COBOL main program call up some C routines.
>
> The main bone of contention are strings. COBOL passes fixed length
> strings (whether as a pointer to the actually buffer, or as a pointer to
> a descriptop which points to the buffer). This means in practice you are
> passing around blank padded fixed length strings. C likes null
> terminated strings.

Actually, C doesn't care about null terminated strings any more than
any other language. You are free to create arrays of char that contain
strings in any format you prefer. All you have to do is write routines
to deal with them. It would not be particularly difficult to write a
library of string functions that did not allow the dreaded buffer-overrun.
The only reason I can think of why this has never been done is lack of
interest.

And for all of you who feel much more comfortable with Ada, now that we
know there is no longer a DEC Ada and GNAT is the future, try writting a
program with a few strings in it, compile it with GNAT and then pass the
executable thru the Unix "strings" command. For those of you not familiar
with it, it will find and print out the strings in a binary file. It does
this by looking for strings of ASCII that end in a null. It usually returns
a lot of bogus strings cause lots of null terminated ASCII happens by pure
chance, but it also returns all the real strings. Why do I mention this?
Because it will print out all the strings in your Ada program. Anybody
want to take a guess at what that means?

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> Actually, C doesn't care about null terminated strings any more than
> any other language. You are free to create arrays of char that contain
> strings in any format you prefer. All you have to do is write routines
> to deal with them.

Not quite true.

The compiler itself generate null terminated char arrays for
string literals.

> And for all of you who feel much more comfortable with Ada, now that we
> know there is no longer a DEC Ada and GNAT is the future, try writting a
> program with a few strings in it, compile it with GNAT and then pass the
> executable thru the Unix "strings" command. For those of you not familiar
> with it, it will find and print out the strings in a binary file. It does
> this by looking for strings of ASCII that end in a null. It usually returns
> a lot of bogus strings cause lots of null terminated ASCII happens by pure
> chance, but it also returns all the real strings. Why do I mention this?
> Because it will print out all the strings in your Ada program. Anybody
> want to take a guess at what that means?

The format is not a C string.

The format appears to be (based on a hex dump):

* N bytes
* 0-7 nul bytes padding length to multipla of 8
* 4 bytes with 1
* 4 bytes with N

Arne

[Bill Gunshannon]

In article <wbf_g.22664$***@dukeread09>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> Actually, C doesn't care about null terminated strings any more than
>> any other language. You are free to create arrays of char that contain
>> strings in any format you prefer. All you have to do is write routines
>> to deal with them.
>
> Not quite true.
>
> The compiler itself generate null terminated char arrays for
> string literals.

And, as I stated later on, so does the Ada compiler. It is not the
composition of the character array that is the problem, it is the
handling of it. As I have also stated in the past, MACRO-11 created
null terminated strings and I am willing to bet it was doing this
before the first C compiler was ported to the PDP-11. I can't say,
as I have no experience with it, but perhaps someone here can answer
this. Did the systems prior to the PDP-11 support the Macro Directive
.ASCIZ? Does VAX MACRO? Do any of them have the .PRINT Macro in
their libraries? What does it expect as the format for a string?

>
>> And for all of you who feel much more comfortable with Ada, now that we
>> know there is no longer a DEC Ada and GNAT is the future, try writting a
>> program with a few strings in it, compile it with GNAT and then pass the
>> executable thru the Unix "strings" command. For those of you not familiar
>> with it, it will find and print out the strings in a binary file. It does
>> this by looking for strings of ASCII that end in a null. It usually returns
>> a lot of bogus strings cause lots of null terminated ASCII happens by pure
>> chance, but it also returns all the real strings. Why do I mention this?
>> Because it will print out all the strings in your Ada program. Anybody
>> want to take a guess at what that means?
>
> The format is not a C string.
>
> The format appears to be (based on a hex dump):
>
> * N bytes
> * 0-7 nul bytes padding length to multipla of 8
> * 4 bytes with 1
> * 4 bytes with N

Sure looks like one to the strings command. :-) My point is that it
is not the constitution of the string that causes the problem, it is
the way the string is handled by the language. As I stated, there is
nothing in the world stopping people from changing that constitutes a
"string" in C. You can easily use the UCSD definition and make the first
byte (or more, depending on the size limitation you want to impose) a
length indicator and then write replacements for the standard string
manipulation routines to deal with them. Or use the VMS Descriptor
concept with the same requirement for new routines. The source to
numerous C compilers are available. One could easily make all of this
totally transparent to the developer. Why has it not been done? Apparently,
not enough people really care.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bill Gunshannon]

In article <***@individual.net>,
***@cs.uofs.edu (Bill Gunshannon) writes:
>
> As I have also stated in the past, MACRO-11 created
> null terminated strings and I am willing to bet it was doing this
> before the first C compiler was ported to the PDP-11. I can't say,
> as I have no experience with it, but perhaps someone here can answer
> this. Did the systems prior to the PDP-11 support the Macro Directive
> .ASCIZ? Does VAX MACRO? Do any of them have the .PRINT Macro in
> their libraries? What does it expect as the format for a string?

Answered my own question on this. MACRO-10, VAX MACRO, Sun4 Asm, GNU
GAS all have the ASCIZ directive and the routines to manipulate it.
I'll bet there are even more if I wanted to do a more exhaustive search.
For such an evil concept there sure are a lot of people using it. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <wbf_g.22664$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> Actually, C doesn't care about null terminated strings any more than
>>> any other language. You are free to create arrays of char that contain
>>> strings in any format you prefer. All you have to do is write routines
>>> to deal with them.
>> Not quite true.
>>
>> The compiler itself generate null terminated char arrays for
>> string literals.
>
> And, as I stated later on, so does the Ada compiler.

Yep, but that was wrong too.

> It is not the
> composition of the character array that is the problem, it is the
> handling of it.

To make it safe there should be a length.

And if there is a length, then the null bytes is not needed.

>>> And for all of you who feel much more comfortable with Ada, now that we
>>> know there is no longer a DEC Ada and GNAT is the future, try writting a
>>> program with a few strings in it, compile it with GNAT and then pass the
>>> executable thru the Unix "strings" command. For those of you not familiar
>>> with it, it will find and print out the strings in a binary file. It does
>>> this by looking for strings of ASCII that end in a null. It usually returns
>>> a lot of bogus strings cause lots of null terminated ASCII happens by pure
>>> chance, but it also returns all the real strings. Why do I mention this?
>>> Because it will print out all the strings in your Ada program. Anybody
>>> want to take a guess at what that means?
>> The format is not a C string.
>>
>> The format appears to be (based on a hex dump):
>>
>> * N bytes
>> * 0-7 nul bytes padding length to multipla of 8
>> * 4 bytes with 1
>> * 4 bytes with N
>
> Sure looks like one to the strings command. :-)

Probably because the 1 bytes is not printable.

> As I stated, there is
> nothing in the world stopping people from changing that constitutes a
> "string" in C.

Ofcourse there are.

The C standard section 6.4.5 defines how a string literal
is stored as bytes.

> You can easily use the UCSD definition and make the first
> byte (or more, depending on the size limitation you want to impose) a
> length indicator and then write replacements for the standard string
> manipulation routines to deal with them. Or use the VMS Descriptor
> concept with the same requirement for new routines. The source to
> numerous C compilers are available. One could easily make all of this
> totally transparent to the developer. Why has it not been done? Apparently,
> not enough people really care.

It would no longer be C.

And if you are making a new language, then you can just as easily
fix a few other things.

And that has been done.

None of the big languages invented after 1990 (primarily Java and C#)
uses the null terminated string concept. They use objects. Which
are in reality equivalent to VMS descriptors.

Arne

[Bill Gunshannon]

In article <3xs_g.22687$***@dukeread09>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <wbf_g.22664$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> Actually, C doesn't care about null terminated strings any more than
>>>> any other language. You are free to create arrays of char that contain
>>>> strings in any format you prefer. All you have to do is write routines
>>>> to deal with them.
>>> Not quite true.
>>>
>>> The compiler itself generate null terminated char arrays for
>>> string literals.
>>
>> And, as I stated later on, so does the Ada compiler.
>
> Yep, but that was wrong too.

OK, if you say so. But all the examples I had here (we used to use
Ada and the gnat compiler as the basic beginner programming language)
come have ASCII characters with at least one null at the end. Ada
may not use that null for anything, but it's still there.

>
>> It is not the
>> composition of the character array that is the problem, it is the
>> handling of it.
>
> To make it safe there should be a length.

True.

>
> And if there is a length, then the null bytes is not needed.

Also true. So, why does the Ada compiler put them there? Probably just
wasting space as it does in may other ways as well.

>
>>>> And for all of you who feel much more comfortable with Ada, now that we
>>>> know there is no longer a DEC Ada and GNAT is the future, try writting a
>>>> program with a few strings in it, compile it with GNAT and then pass the
>>>> executable thru the Unix "strings" command. For those of you not familiar
>>>> with it, it will find and print out the strings in a binary file. It does
>>>> this by looking for strings of ASCII that end in a null. It usually returns
>>>> a lot of bogus strings cause lots of null terminated ASCII happens by pure
>>>> chance, but it also returns all the real strings. Why do I mention this?
>>>> Because it will print out all the strings in your Ada program. Anybody
>>>> want to take a guess at what that means?
>>> The format is not a C string.
>>>
>>> The format appears to be (based on a hex dump):
>>>
>>> * N bytes
>>> * 0-7 nul bytes padding length to multipla of 8
>>> * 4 bytes with 1
>>> * 4 bytes with N
>>
>> Sure looks like one to the strings command. :-)
>
> Probably because the 1 bytes is not printable.

After it has seen the first null, the rest means nothing until it finds
the next thing that looks like a string. Four 1's and four byres of
relative garbage would not trigger this. If I can find a machine with
GNAT still on it I will have to try a few tests to see if I can get it
to create a string with no null at the end. (Just curious!)

>
> > As I stated, there is
>> nothing in the world stopping people from changing that constitutes a
>> "string" in C.
>
> Ofcourse there are.
>
> The C standard section 6.4.5 defines how a string literal
> is stored as bytes.

OK, and who wrote that definition? And why can't they re-define it
otherwise? And, if the null terminated string was such a problem.
why didn't they redefine it in the first place?

>
>> You can easily use the UCSD definition and make the first
>> byte (or more, depending on the size limitation you want to impose) a
>> length indicator and then write replacements for the standard string
>> manipulation routines to deal with them. Or use the VMS Descriptor
>> concept with the same requirement for new routines. The source to
>> numerous C compilers are available. One could easily make all of this
>> totally transparent to the developer. Why has it not been done? Apparently,
>> not enough people really care.
>
> It would no longer be C.

If the ANSI C committee defines it that way, it would most certainly be
C. (Not my opinion, but when I complain to people about ANSI C not being
C because it diverged from K&R I am always told the above!)

>
> And if you are making a new language, then you can just as easily
> fix a few other things.

True, there are already languages that don't have this problem, like PL/1.
(Hi Tom! :-)

But if the ANSI C Committee makes the change, it would still be C by
virtue of their blessing. So, why has this not been fixed? Comes
right back to my statement about interest. Obviously, not enough
people care to make the move. Heck, it would even be possible to do
it in such a manner that you could maintain complete compatability
with existing source code if you really wanted to. After all, the
data type "string" doesn't currently exist in C. The ANSI C Committee
could add it. And the language would still be C in the opinions of
the majority of the world.

>
> And that has been done.
>
> None of the big languages invented after 1990 (primarily Java and C#)
> uses the null terminated string concept. They use objects. Which
> are in reality equivalent to VMS descriptors.

Take som time to search for some of the recent comments from experts in
the OO field. Even they are starting to realize the emperor has no clothes.
(Not saying VMS Descriptors are wrong, because I think they are a good
idea, just pointing out that even the OO community is beginning to
come to the realization that OO is no more the universal answer than
any other pardigm we have come up with inthe industry in the past.)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <3xs_g.22687$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> And if there is a length, then the null bytes is not needed.
>
> Also true. So, why does the Ada compiler put them there? Probably just
> wasting space as it does in may other ways as well.

Somebody apparently put a 4 byte code of something in it.

A 4 byte integer with small values tend to always contain null bytes.

>>>> The format appears to be (based on a hex dump):
>>>>
>>>> * N bytes
>>>> * 0-7 nul bytes padding length to multipla of 8
>>>> * 4 bytes with 1
>>>> * 4 bytes with N
>>> Sure looks like one to the strings command. :-)

> After it has seen the first null, the rest means nothing until it finds
> the next thing that looks like a string. Four 1's and four byres of
> relative garbage would not trigger this.

It is not 4 bytes with 1 in each. It is 4 bytes with a single 1.
Longword !

Which makes it that all Ada strings either has a padding null
byte or a trailing byte with 1 plus 3 trailing null bytes.

I dont know if that constant i salways 1, but is was in my test.

> If I can find a machine with
> GNAT still on it I will have to try a few tests to see if I can get it
> to create a string with no null at the end. (Just curious!)

with Ada.Text_IO;

use Ada.Text_IO;

procedure Test is

begin
Put_Line("1");
Put_Line("22");
Put_Line("333");
Put_Line("4444");
Put_Line("55555");
Put_Line("666666");
Put_Line("7777777");
Put_Line("88888888");
Put_Line("999999999");
Put_Line("AAAAAAAAAA");
Put_Line("BBBBBBBBBBB");
Put_Line("CCCCCCCCCCCC");
Put_Line("DDDDDDDDDDDDD");
Put_Line("EEEEEEEEEEEEEE");
Put_Line("FFFFFFFFFFFFFFF");
end Test;

00000001 00000001 00000000 00000031 1............... 0000D0
00000002 00000001 00000000 00003232 22.............. 0000E0
00000003 00000001 00000000 00333333 333............. 0000F0
00000004 00000001 00000000 34343434 4444............ 000100
00000005 00000001 00000035 35353535 55555........... 000110
00000006 00000001 00003636 36363636 666666.......... 000120
00000007 00000001 00373737 37373737 7777777......... 000130
00000008 00000001 38383838 38383838 88888888........ 000140
00000000 00000039 39393939 39393939 999999999....... 000150
41414141 41414141 00000009 00000001 ........AAAAAAAA 000160
0000000A 00000001 00000000 00004141 AA.............. 000170
00000000 00424242 42424242 42424242 BBBBBBBBBBB..... 000180
43434343 43434343 0000000B 00000001 ........CCCCCCCC 000190
0000000C 00000001 00000000 43434343 CCCC............ 0001A0
00000044 44444444 44444444 44444444 DDDDDDDDDDDDD... 0001B0
45454545 45454545 0000000D 00000001 ........EEEEEEEE 0001C0
0000000E 00000001 00004545 45454545 EEEEEE.......... 0001D0
00464646 46464646 46464646 46464646 FFFFFFFFFFFFFFF. 0001E0
00000000 000089E0 0000000F 00000001 ........à....... 0001F0

which is

'1', 7 traling null bytes, 1, 1
'2', '2', 6 traling null bytes, 1, 2
...
'8', '8', '8', '8', '8', '8', '8', '8', 1, 8
...

>>> As I stated, there is
>>> nothing in the world stopping people from changing that constitutes a
>>> "string" in C.
>> Ofcourse there are.
>>
>> The C standard section 6.4.5 defines how a string literal
>> is stored as bytes.
>
> OK, and who wrote that definition? And why can't they re-define it
> otherwise?

You don't change the language definition in a way that will
break so much code.

> And, if the null terminated string was such a problem.
> why didn't they redefine it in the first place?

When it became acknowledges as a problem it was too late.

> But if the ANSI C Committee makes the change, it would still be C by
> virtue of their blessing. So, why has this not been fixed? Comes
> right back to my statement about interest. Obviously, not enough
> people care to make the move. Heck, it would even be possible to do
> it in such a manner that you could maintain complete compatability
> with existing source code if you really wanted to. After all, the
> data type "string" doesn't currently exist in C. The ANSI C Committee
> could add it. And the language would still be C in the opinions of
> the majority of the world.

Enough people care about it.

They have switched to Java, C# and even C++ with STL strings.

>> None of the big languages invented after 1990 (primarily Java and C#)
>> uses the null terminated string concept. They use objects. Which
>> are in reality equivalent to VMS descriptors.
>
> Take som time to search for some of the recent comments from experts in
> the OO field. Even they are starting to realize the emperor has no clothes.
> (Not saying VMS Descriptors are wrong, because I think they are a good
> idea, just pointing out that even the OO community is beginning to
> come to the realization that OO is no more the universal answer than
> any other pardigm we have come up with inthe industry in the past.)

I think it is rather universal accepted that OOP was the way to go.

I do not forsee any mainstream languages being created that are
not object oriented.

Use of a non object oriented language for a new project is
an exception.

It has been realized that OOP is not the final solution.

So we are heading towards AOP.

Arne

[Bill Gunshannon]

In article <_Jt_g.22692$***@dukeread09>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <3xs_g.22687$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> As I stated, there is
>>>> nothing in the world stopping people from changing that constitutes a
>>>> "string" in C.
>>> Ofcourse there are.
>>>
>>> The C standard section 6.4.5 defines how a string literal
>>> is stored as bytes.
>>
>> OK, and who wrote that definition? And why can't they re-define it
>> otherwise?
>
> You don't change the language definition in a way that will
> break so much code.

I have already posted a method that would allow future code to be
string safe as well as make slow conversion (as bugs are found and
fixed) without breaking existing code.

>
>> And, if the null terminated string was such a problem.
>> why didn't they redefine it in the first place?
>
> When it became acknowledges as a problem it was too late.

It is never too late. If the problem is seen as serious enough it
will be fixed. Do you realize how much BASIC code was already
written and running (in production environments!) before ANSI decided
to even take on defining ANSI Standard BASIC?

>
>> But if the ANSI C Committee makes the change, it would still be C by
>> virtue of their blessing. So, why has this not been fixed? Comes
>> right back to my statement about interest. Obviously, not enough
>> people care to make the move. Heck, it would even be possible to do
>> it in such a manner that you could maintain complete compatability
>> with existing source code if you really wanted to. After all, the
>> data type "string" doesn't currently exist in C. The ANSI C Committee
>> could add it. And the language would still be C in the opinions of
>> the majority of the world.
>
> Enough people care about it.

Apparently not, or they would either fix it themselves or be clamoring
for the standards bodies to fix it. Or, as a minimum, some entrepreneur
would be making a fortune selling "The Safe C Compiler".

>
> They have switched to Java, C# and even C++ with STL strings.

Java is certainly no replacement for C. Ever try writting an OS in
Java? Don't really know much about C# except the driving force behind
it was corporate politics rather than technical superiority. And as
for C++, doesn't it still support null terminated strings alongside
better ways to do it?

>
>>> None of the big languages invented after 1990 (primarily Java and C#)
>>> uses the null terminated string concept. They use objects. Which
>>> are in reality equivalent to VMS descriptors.

And neither of the examples provided are suitable or were intended to
do the things C was created to do. Prove me wrong, rewrite any Unix
kernel in either language. I'll make it easy for you, you can use
Ultrix-11 as your guinea pig. It's relatively small as Unix kernels go
and all the sources are available. Oh wait. You can't write an OS in
Java. It only runs in a Virtual Machine which requires an OS and a
very limited subset of existing hardware in order to run it!!

>>
>> Take som time to search for some of the recent comments from experts in
>> the OO field. Even they are starting to realize the emperor has no clothes.
>> (Not saying VMS Descriptors are wrong, because I think they are a good
>> idea, just pointing out that even the OO community is beginning to
>> come to the realization that OO is no more the universal answer than
>> any other pardigm we have come up with inthe industry in the past.)
>
> I think it is rather universal accepted that OOP was the way to go.

Many of the big names in OO are beginning to disagree.

>
> I do not forsee any mainstream languages being created that are
> not object oriented.
>
> Use of a non object oriented language for a new project is
> an exception.
>
> It has been realized that OOP is not the final solution.
>
> So we are heading towards AOP.

Yeah, and RISC was the answer no wait, EPIC is the answer, no wait.......

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[John Santos]

Bill Gunshannon wrote:
> In article <_Jt_g.22692$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>
>>Bill Gunshannon wrote:
>>
>>>In article <3xs_g.22687$***@dukeread09>,
>>> Arne Vajhøj <***@vajhoej.dk> writes:
>>>
>>>>Bill Gunshannon wrote:
>>>>
>>>>> As I stated, there is
>>>>>nothing in the world stopping people from changing that constitutes a
>>>>>"string" in C.
>>>>
>>>>Ofcourse there are.
>>>>
>>>>The C standard section 6.4.5 defines how a string literal
>>>>is stored as bytes.
>>>
>>>OK, and who wrote that definition? And why can't they re-define it
>>>otherwise?
>>
>>You don't change the language definition in a way that will
>>break so much code.
>
>
> I have already posted a method that would allow future code to be
> string safe as well as make slow conversion (as bugs are found and
> fixed) without breaking existing code.
>
>
>>> And, if the null terminated string was such a problem.
>>>why didn't they redefine it in the first place?
>>
>>When it became acknowledges as a problem it was too late.
>
>
> It is never too late. If the problem is seen as serious enough it
> will be fixed. Do you realize how much BASIC code was already
> written and running (in production environments!) before ANSI decided
> to even take on defining ANSI Standard BASIC?

Really really bad example. The ANSI standard for BASIC is useless,
and no existing programs (literally none of them) were compliant,
and I doubt any one wasted any effort beyond and initial exploration
attempting to port them. And virtually no new code was written to
the ANSI standard. Try compiling a DEC BASIC program with /ANSI
some time. (On Alpha and IA64, it says "The ANSI qualifier is not
supported" and ignores it. On VAX, it flags every line for something
or other. The "LET" verb is required. INPUT "PROMPT"; VARIABLE is
illegal (no prompting on INPUT statements.) Integer variables aren't
allowed, only strings and floats. Etc. etc. etc.

In other words, a really really good example of what happens when a
standards committee ignores existing practice.



>
>
>>>But if the ANSI C Committee makes the change, it would still be C by
>>>virtue of their blessing. So, why has this not been fixed? Comes
>>>right back to my statement about interest. Obviously, not enough
>>>people care to make the move. Heck, it would even be possible to do
>>>it in such a manner that you could maintain complete compatability
>>>with existing source code if you really wanted to. After all, the
>>>data type "string" doesn't currently exist in C. The ANSI C Committee
>>>could add it. And the language would still be C in the opinions of
>>>the majority of the world.
>>
>>Enough people care about it.
>
>
> Apparently not, or they would either fix it themselves or be clamoring
> for the standards bodies to fix it. Or, as a minimum, some entrepreneur
> would be making a fortune selling "The Safe C Compiler".

This is really nonsense. It isn't just a matter of creating a C compiler
that uses counted or descriptored strings for string constants and includes
substitute routines for printf, fgets, strcpy, strncmp, etc. that
use the safe data types. Tons of existing code would break in the new
compiler, because of things like stepping through strings as arrays of
chars looking for nulls. Every line would have to be looked at by
something a lot smarter than any compiler.

>
>
>>They have switched to Java, C# and even C++ with STL strings.
>
>
> Java is certainly no replacement for C. Ever try writting an OS in
> Java? Don't really know much about C# except the driving force behind
> it was corporate politics rather than technical superiority. And as
> for C++, doesn't it still support null terminated strings alongside
> better ways to do it?
>
>
>>>>None of the big languages invented after 1990 (primarily Java and C#)
>>>>uses the null terminated string concept. They use objects. Which
>>>>are in reality equivalent to VMS descriptors.
>
>
> And neither of the examples provided are suitable or were intended to
> do the things C was created to do. Prove me wrong, rewrite any Unix
> kernel in either language. I'll make it easy for you, you can use
> Ultrix-11 as your guinea pig. It's relatively small as Unix kernels go
> and all the sources are available. Oh wait. You can't write an OS in
> Java. It only runs in a Virtual Machine which requires an OS and a
> very limited subset of existing hardware in order to run it!!
>
>
>>>Take som time to search for some of the recent comments from experts in
>>>the OO field. Even they are starting to realize the emperor has no clothes.
>>>(Not saying VMS Descriptors are wrong, because I think they are a good
>>>idea, just pointing out that even the OO community is beginning to
>>>come to the realization that OO is no more the universal answer than
>>>any other pardigm we have come up with inthe industry in the past.)
>>
>>I think it is rather universal accepted that OOP was the way to go.
>
>
> Many of the big names in OO are beginning to disagree.
>
>
>>I do not forsee any mainstream languages being created that are
>>not object oriented.
>>
>>Use of a non object oriented language for a new project is
>>an exception.
>>
>>It has been realized that OOP is not the final solution.
>>
>>So we are heading towards AOP.
>
>
> Yeah, and RISC was the answer no wait, EPIC is the answer, no wait.......
>
> bill
>


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

[Bill Gunshannon]

In article <dKL_g.7481$***@trnddc06>,
John Santos <***@egh.com> writes:
> Bill Gunshannon wrote:
>> In article <_Jt_g.22692$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>
>>>Bill Gunshannon wrote:
>>>
>>>>In article <3xs_g.22687$***@dukeread09>,
>>>> Arne Vajhøj <***@vajhoej.dk> writes:
>>>>
>>>>>Bill Gunshannon wrote:
>>>>>
>>>>>> As I stated, there is
>>>>>>nothing in the world stopping people from changing that constitutes a
>>>>>>"string" in C.
>>>>>
>>>>>Ofcourse there are.
>>>>>
>>>>>The C standard section 6.4.5 defines how a string literal
>>>>>is stored as bytes.
>>>>
>>>>OK, and who wrote that definition? And why can't they re-define it
>>>>otherwise?
>>>
>>>You don't change the language definition in a way that will
>>>break so much code.
>>
>>
>> I have already posted a method that would allow future code to be
>> string safe as well as make slow conversion (as bugs are found and
>> fixed) without breaking existing code.
>>
>>
>>>> And, if the null terminated string was such a problem.
>>>>why didn't they redefine it in the first place?
>>>
>>>When it became acknowledges as a problem it was too late.
>>
>>
>> It is never too late. If the problem is seen as serious enough it
>> will be fixed. Do you realize how much BASIC code was already
>> written and running (in production environments!) before ANSI decided
>> to even take on defining ANSI Standard BASIC?
>
> Really really bad example. The ANSI standard for BASIC is useless,
> and no existing programs (literally none of them) were compliant,
> and I doubt any one wasted any effort beyond and initial exploration
> attempting to port them. And virtually no new code was written to
> the ANSI standard. Try compiling a DEC BASIC program with /ANSI
> some time. (On Alpha and IA64, it says "The ANSI qualifier is not
> supported" and ignores it. On VAX, it flags every line for something
> or other. The "LET" verb is required. INPUT "PROMPT"; VARIABLE is
> illegal (no prompting on INPUT statements.) Integer variables aren't
> allowed, only strings and floats. Etc. etc. etc.
>
> In other words, a really really good example of what happens when a
> standards committee ignores existing practice.

I didn't say it was a good thing. I only meant to point out that
ANSI has had no problem in the past with changing the definition
of a language while keeping the same name. While many VMS people
are sure to disagree, using BASIC for anything is a bad idea (IMHO!)

>
>
>
>>
>>
>>>>But if the ANSI C Committee makes the change, it would still be C by
>>>>virtue of their blessing. So, why has this not been fixed? Comes
>>>>right back to my statement about interest. Obviously, not enough
>>>>people care to make the move. Heck, it would even be possible to do
>>>>it in such a manner that you could maintain complete compatability
>>>>with existing source code if you really wanted to. After all, the
>>>>data type "string" doesn't currently exist in C. The ANSI C Committee
>>>>could add it. And the language would still be C in the opinions of
>>>>the majority of the world.
>>>
>>>Enough people care about it.
>>
>>
>> Apparently not, or they would either fix it themselves or be clamoring
>> for the standards bodies to fix it. Or, as a minimum, some entrepreneur
>> would be making a fortune selling "The Safe C Compiler".
>
> This is really nonsense. It isn't just a matter of creating a C compiler
> that uses counted or descriptored strings for string constants and includes
> substitute routines for printf, fgets, strcpy, strncmp, etc. that
> use the safe data types. Tons of existing code would break in the new
> compiler, because of things like stepping through strings as arrays of
> chars looking for nulls. Every line would have to be looked at by
> something a lot smarter than any compiler.

You must not have read what I said. I said you modify the language to
add a dat type called "string". You design the string data type in such
a manner that the buffer overrun problem does not exist. You provide all
the routines needed to handle these strings in a safe manner. You do
not remove the old way of doing it. Now, there is a method of developing
new programs that are "string safe". Existing programs can have the bad
parts re-written as bugs are found or at the desire of the programmer.
Eventually (one would hope) the problem goes away as all programs migrate
to the safe method. You need never remove the old method, you just
discourage its use (like GOTO).

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Dave Froble]

Bill Gunshannon wrote:

> I didn't say it was a good thing. I only meant to point out that
> ANSI has had no problem in the past with changing the definition
> of a language while keeping the same name. While many VMS people
> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)

Yeah, many will disagree with that statement. Not interested in arguing
the issue. However, I'd like to know just why you'd make this comment.
Staying away from issues such as VAX/DEC BASIC being limited to a VMS
environment, and Basic Plus being limited to RSTS/E, issues not limited
to these languages, what are your reasons for your statement?

> You need never remove the old method, you just
> discourage its use (like GOTO).

What are your issues with GOTO? What really gets to me is people
badmouthing something that every computer language is dependent upon.
Name just one commercial computer system that could exist without a
branch instruction.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dan Foster]

In article <***@libcom.com>, Dave Froble <***@tsoft-inc.com> wrote:
> Bill Gunshannon wrote:
>
>> You need never remove the old method, you just
>> discourage its use (like GOTO).
>
> What are your issues with GOTO? What really gets to me is people
> badmouthing something that every computer language is dependent upon.
> Name just one commercial computer system that could exist without a
> branch instruction.

Yeah, well, the issue with GOTO is that it sometimes encourages new
developers to use unstructured coding practices, at will.

GOTO by itself is not _inherently_ evil; misuse of it is.

With that said, GOTOs are occasionally needed even in structured
languages, in certain situations.

Use of GOTO-type stuff for certain ISRs (interrupt service routines)
comes to mind for simplifying error code paths or for reducing byte
count on a particularly constrainted hardware platform.

Still, one does not want to _encourage_ use of GOTOs as a crutch for
more structured programs that can do without them and is often cleaner.

As to the issue with use of BASIC itself... I'm not sure I understand
where Bill is coming from and would defer further comment until I better
understand his perspective.

(I'm honestly curious; I'm not even a BASIC programmer.)

-Dan

[JF Mezei]

Dan Foster wrote:
> With that said, GOTOs are occasionally needed even in structured
> languages, in certain situations.

Not just NEEDED. It is sometimes far better to use a GOTO rather than
some overly complex "structured programming" techniques with a gazillion
nested IF/ELSE just so that you can handle that one case where you want
to exit from the loop.

[Paul Sture]

In article <***@teksavvy.com>,
JF Mezei <***@teksavvy.com> wrote:

> Dan Foster wrote:
> > With that said, GOTOs are occasionally needed even in structured
> > languages, in certain situations.
>
> Not just NEEDED. It is sometimes far better to use a GOTO rather than
> some overly complex "structured programming" techniques with a gazillion
> nested IF/ELSE just so that you can handle that one case where you want
> to exit from the loop.

DCL anybody?

:-)

--
Paul Sture

[Richard B. Gilbert]

Dave Froble wrote:
> Bill Gunshannon wrote:
>
>> I didn't say it was a good thing. I only meant to point out that
>> ANSI has had no problem in the past with changing the definition
>> of a language while keeping the same name. While many VMS people
>> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)
>
>
> Yeah, many will disagree with that statement. Not interested in arguing
> the issue. However, I'd like to know just why you'd make this comment.
> Staying away from issues such as VAX/DEC BASIC being limited to a VMS
> environment, and Basic Plus being limited to RSTS/E, issues not limited
> to these languages, what are your reasons for your statement?
>
>> You need never remove the old method, you just
>> discourage its use (like GOTO).
>
>
> What are your issues with GOTO? What really gets to me is people
> badmouthing something that every computer language is dependent upon.
> Name just one commercial computer system that could exist without a
> branch instruction.
>

The history on this is that someone (I forget his name) wrote a paper
with a title something like "GOTO Considered Harmful". In those days
people wrote spaghetti code using GOTOs to get from one meatball to
another! It's not JUST a branch instruction, it's an UNCONDITIONAL
branch. There is really nothing wrong with GOTO, just with the way some
spaghetti minded programmers use(d) it. Believe it or not, some
"programmers" out there are still writing spaghetti code.

If you don't have GOTO you have to think a little harder before you
code. Sometimes this additional thought results in better code.

[Jean-Marc Bourguet]

"Richard B. Gilbert" <***@comcast.net> writes:

> The history on this is that someone (I forget his name) wrote a paper
> with a title something like "GOTO Considered Harmful".

Dijkstra see: http://www.acm.org/classics/oct95/

--
Jean-Marc

[Bill Gunshannon]

In article <***@news.bourguet.org>,
Jean-Marc Bourguet <***@bourguet.org> writes:
> "Richard B. Gilbert" <***@comcast.net> writes:
>
>> The history on this is that someone (I forget his name) wrote a paper
>> with a title something like "GOTO Considered Harmful".
>
> Dijkstra see: http://www.acm.org/classics/oct95/

Thank you, I mis-spelled his name. (No dis-respect meant, but we
don't always agree either. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bill Gunshannon]

In article <***@libcom.com>,
Dave Froble <***@tsoft-inc.com> writes:
> Bill Gunshannon wrote:
>
>> I didn't say it was a good thing. I only meant to point out that
>> ANSI has had no problem in the past with changing the definition
>> of a language while keeping the same name. While many VMS people
>> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)
>
> Yeah, many will disagree with that statement. Not interested in arguing
> the issue. However, I'd like to know just why you'd make this comment.
> Staying away from issues such as VAX/DEC BASIC being limited to a VMS
> environment, and Basic Plus being limited to RSTS/E, issues not limited
> to these languages, what are your reasons for your statement?

BASIC is and always was a toy language. It (like Pascal) was designed for
a specific purpose and then found itself used for everything else. There
were always better languages for any task.

>
>> You need never remove the old method, you just
>> discourage its use (like GOTO).
>
> What are your issues with GOTO?

Not my idea. It is people of much greater stature in the discipline
than I. For example Dykstra. :-)

> What really gets to me is people
> badmouthing something that every computer language is dependent upon.
> Name just one commercial computer system that could exist without a
> branch instruction.

I believe the argument has to do with level of abstraction. It is not
that a computer should not be able to "GOTO" but that good programming
practice using any fairly modern language dictates that no programmers
logic should have a need for it.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> BASIC is and always was a toy language. It (like Pascal) was designed for
> a specific purpose and then found itself used for everything else. There
> were always better languages for any task.

Better is a very subjective terms.

You think there are better languages.

The IT managers who set 1.6 million software developers to
produce VB code apparently thought otherwise.

Arne

[Bill Gunshannon]

In article <KQR_g.22729$***@dukeread09>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> BASIC is and always was a toy language. It (like Pascal) was designed for
>> a specific purpose and then found itself used for everything else. There
>> were always better languages for any task.
>
> Better is a very subjective terms.
>
> You think there are better languages.
>
> The IT managers who set 1.6 million software developers to
> produce VB code apparently thought otherwise.

Yeah, VB is to programming languages what XP is to operating systems.
But then, look where it came from. Market superiority should never
be mistaken for technical superiority especially when it involves a
Microsoft product.

bill

--
bIll Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <KQR_g.22729$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> BASIC is and always was a toy language. It (like Pascal) was designed for
>>> a specific purpose and then found itself used for everything else. There
>>> were always better languages for any task.
>> Better is a very subjective terms.
>>
>> You think there are better languages.
>>
>> The IT managers who set 1.6 million software developers to
>> produce VB code apparently thought otherwise.
>
> Yeah, VB is to programming languages what XP is to operating systems.
> But then, look where it came from. Market superiority should never
> be mistaken for technical superiority especially when it involves a
> Microsoft product.

Market superiority means that the product gives consumers
what the consumers they need.

That is called good business.

Those IT managers did not look at VB for its beauty as language.
They looked at as something that could provide the client GUI's
they needed at a minimal cost.

So MS made a ton of money supplying what the market needed.

Arne

[Mark Daniel]

Arne Vajhøj wrote:
> Bill Gunshannon wrote:
>
>> In article <KQR_g.22729$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>
>>> Bill Gunshannon wrote:
>>>
>>>> BASIC is and always was a toy language. It (like Pascal) was
>>>> designed for
>>>> a specific purpose and then found itself used for everything else.
>>>> There
>>>> were always better languages for any task.
>>>
>>> Better is a very subjective terms.
>>>
>>> You think there are better languages.
>>>
>>> The IT managers who set 1.6 million software developers to
>>> produce VB code apparently thought otherwise.

At the risk of an outsider (me) quoting an insider (H.L.Mencken),
"Nobody ever went broke underestimating the taste of the American
public", the same could probably be said of the software development
community.

>> Yeah, VB is to programming languages what XP is to operating systems.
>> But then, look where it came from. Market superiority should never
>> be mistaken for technical superiority especially when it involves a
>> Microsoft product.
>
>
> Market superiority means that the product gives consumers
> what the consumers they need.

^ think

> That is called good business.
>
> Those IT managers did not look at VB for its beauty as language.
> They looked at as something that could provide the client GUI's
> they needed at a minimal cost.
>
> So MS made a ton of money supplying what the market needed.

Sounds a lot like The Sopranos philosophy of business.

> Arne

Who am I to be critical? I write in Cb :-)

[Dave Froble]

Bill Gunshannon wrote:
> In article <***@libcom.com>,
> Dave Froble <***@tsoft-inc.com> writes:
>> Bill Gunshannon wrote:
>>
>>> I didn't say it was a good thing. I only meant to point out that
>>> ANSI has had no problem in the past with changing the definition
>>> of a language while keeping the same name. While many VMS people
>>> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)
>> Yeah, many will disagree with that statement. Not interested in arguing
>> the issue. However, I'd like to know just why you'd make this comment.
>> Staying away from issues such as VAX/DEC BASIC being limited to a VMS
>> environment, and Basic Plus being limited to RSTS/E, issues not limited
>> to these languages, what are your reasons for your statement?
>
> BASIC is and always was a toy language. It (like Pascal) was designed for
> a specific purpose and then found itself used for everything else. There
> were always better languages for any task.

You're still spouting opinion.

Is this informed opinion?

Have you ever looked at VAX Basic?

Are you aware of it's capabilities?

>>> You need never remove the old method, you just
>>> discourage its use (like GOTO).
>> What are your issues with GOTO?
>
> Not my idea. It is people of much greater stature in the discipline
> than I. For example Dykstra. :-)
>
>> What really gets to me is people
>> badmouthing something that every computer language is dependent upon.
>> Name just one commercial computer system that could exist without a
>> branch instruction.
>
> I believe the argument has to do with level of abstraction. It is not
> that a computer should not be able to "GOTO" but that good programming
> practice using any fairly modern language dictates that no programmers
> logic should have a need for it.

Any dispatch type of logic can make good use of GOTO. In the case where
the dispatch is unconditional and there will be no return, GOTO is the
best method for implementing the logic.

I'm not trying to defend abuses, but keep in mind just about anything
can be abused. Does that make everything bad?

As for Dykstra, those who can, do, those who can't, teach, and those who
cannot teach, write, and try to tell others how to do things.

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Bill Gunshannon]

In article <naSdnbT79-***@libcom.com>,
Dave Froble <***@tsoft-inc.com> writes:
> Bill Gunshannon wrote:
>> In article <***@libcom.com>,
>> Dave Froble <***@tsoft-inc.com> writes:
>>> Bill Gunshannon wrote:
>>>
>>>> I didn't say it was a good thing. I only meant to point out that
>>>> ANSI has had no problem in the past with changing the definition
>>>> of a language while keeping the same name. While many VMS people
>>>> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)
>>> Yeah, many will disagree with that statement. Not interested in arguing
>>> the issue. However, I'd like to know just why you'd make this comment.
>>> Staying away from issues such as VAX/DEC BASIC being limited to a VMS
>>> environment, and Basic Plus being limited to RSTS/E, issues not limited
>>> to these languages, what are your reasons for your statement?
>>
>> BASIC is and always was a toy language. It (like Pascal) was designed for
>> a specific purpose and then found itself used for everything else. There
>> were always better languages for any task.
>
> You're still spouting opinion.

What was J&W stated purpose for creating Pascal?
What was Kemeny & Kurtz's reasoning for creating BASIC?

>
> Is this informed opinion?

Of course it's opinion. But opinion based on 40 years of
computer experience.

>
> Have you ever looked at VAX Basic?

Yes.

>
> Are you aware of it's capabilities?

Yes.

>
>>>> You need never remove the old method, you just
>>>> discourage its use (like GOTO).
>>> What are your issues with GOTO?
>>
>> Not my idea. It is people of much greater stature in the discipline
>> than I. For example Dykstra. :-)
>>
>>> What really gets to me is people
>>> badmouthing something that every computer language is dependent upon.
>>> Name just one commercial computer system that could exist without a
>>> branch instruction.
>>
>> I believe the argument has to do with level of abstraction. It is not
>> that a computer should not be able to "GOTO" but that good programming
>> practice using any fairly modern language dictates that no programmers
>> logic should have a need for it.
>
> Any dispatch type of logic can make good use of GOTO. In the case where
> the dispatch is unconditional and there will be no return, GOTO is the
> best method for implementing the logic.
>
> I'm not trying to defend abuses, but keep in mind just about anything
> can be abused. Does that make everything bad?
>
> As for Dykstra, those who can, do, those who can't, teach, and those who
> cannot teach, write, and try to tell others how to do things.

Talk about informed opinion. I think the industry is much more likely
to side with Dykstra than you or me. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bob Koehler]

In article <***@zappy.catbert.org>, Dan Foster <***@evilphb.org> writes:
>
> GOTO by itself is not _inherently_ evil; misuse of it is.
>
> With that said, GOTOs are occasionally needed even in structured
> languages, in certain situations.

BLISS is still the only compiler I've used that doesn't have a GOTO,
and it's constructs which handle the same funtionality are hard to
abuse.

digital had it way back when?

[Arne Vajhøj]

Bob Koehler wrote:
> In article <***@zappy.catbert.org>, Dan Foster <***@evilphb.org> writes:
>> GOTO by itself is not _inherently_ evil; misuse of it is.
>>
>> With that said, GOTOs are occasionally needed even in structured
>> languages, in certain situations.
>
> BLISS is still the only compiler I've used that doesn't have a GOTO,
> and it's constructs which handle the same funtionality are hard to
> abuse.

I thought you did Java as well.

Arne

[Richard Maher]

Hi,

"Arne Vajhøj" <***@vajhoej.dk> wrote in message
news:67d%g.22757$***@dukeread09...
> Bob Koehler wrote:
> > In article <***@zappy.catbert.org>, Dan Foster
<***@evilphb.org> writes:
> >> GOTO by itself is not _inherently_ evil; misuse of it is.
> >>
> >> With that said, GOTOs are occasionally needed even in structured
> >> languages, in certain situations.
> >
> > BLISS is still the only compiler I've used that doesn't have a GOTO,
> > and it's constructs which handle the same funtionality are hard to
> > abuse.
>
> I thought you did Java as well.
>
> Arne

Java is a compiler?

Regards Richard Maher

[Arne Vajhøj]

Richard Maher wrote:
> "Arne Vajhøj" <***@vajhoej.dk> wrote in message
> news:67d%g.22757$***@dukeread09...
>> Bob Koehler wrote:
>>> In article <***@zappy.catbert.org>, Dan Foster
> <***@evilphb.org> writes:
>>>> GOTO by itself is not _inherently_ evil; misuse of it is.
>>>>
>>>> With that said, GOTOs are occasionally needed even in structured
>>>> languages, in certain situations.
>>> BLISS is still the only compiler I've used that doesn't have a GOTO,
>>> and it's constructs which handle the same funtionality are hard to
>>> abuse.
>> I thought you did Java as well.
>>
>> Arne
>
> Java is a compiler?

I would say so.

Arne

[Bob Koehler]

In article <67d%g.22757$***@dukeread09>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
> Bob Koehler wrote:
>> In article <***@zappy.catbert.org>, Dan Foster <***@evilphb.org> writes:
>>> GOTO by itself is not _inherently_ evil; misuse of it is.
>>>
>>> With that said, GOTOs are occasionally needed even in structured
>>> languages, in certain situations.
>>
>> BLISS is still the only compiler I've used that doesn't have a GOTO,
>> and it's constructs which handle the same funtionality are hard to
>> abuse.
>
> I thought you did Java as well.

The Java language may not have a goto, but I'm sure the JIT has
the equivalent bytecode. Don't ask me exactly which to consider the
"compiler".

Actually I thought of Java right after I posted that, but I like
BLISS' syntax better than C/C++/Java "break" et. al.

[JF Mezei]

Bill Gunshannon wrote:
> of a language while keeping the same name. While many VMS people
> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)

Warning: Dave Froble is known to threathen people with his aluminium
baseball bats... If I don't mention that 4 digit word starting with 8
and ending with 086 for a while, Mr Froble may redirect his bats to you
because you mention BASIC was bad...

:-)

[Dave Froble]

JF Mezei wrote:
> Bill Gunshannon wrote:
>> of a language while keeping the same name. While many VMS people
>> are sure to disagree, using BASIC for anything is a bad idea (IMHO!)
>
> Warning: Dave Froble is known to threathen people with his aluminium
> baseball bats... If I don't mention that 4 digit word starting with 8
> and ending with 086 for a while, Mr Froble may redirect his bats to you
> because you mention BASIC was bad...
>
> :-)

And it's so well known that I don't even have to issue my own warnings
anymore. :-)

--
David Froble Tel: [phone]
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <_Jt_g.22692$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> You don't change the language definition in a way that will
>> break so much code.
>
> I have already posted a method that would allow future code to be
> string safe as well as make slow conversion (as bugs are found and
> fixed) without breaking existing code.

The string type approach.

If you keep the char and just add a string type, then you will
not break any existing code.

This what C++ did.

STL string must be around 15 years old. And it has not
nearly replaced null terminated char arrays yet.

But maybe in another 15 years.

It doesn't work.

>> When it became acknowledges as a problem it was too late.
>
> It is never too late. If the problem is seen as serious enough it
> will be fixed.

People realize the problem.

And they are changing to other languages.

Non OO languages are considered obsolete in most areas, so
noone sees the need for this feature.

>> Enough people care about it.
>
> Apparently not, or they would either fix it themselves or be clamoring
> for the standards bodies to fix it. Or, as a minimum, some entrepreneur
> would be making a fortune selling "The Safe C Compiler".

The explanation followed in next sentence, so rather poor quoting.

>> They have switched to Java, C# and even C++ with STL strings.
>
> Java is certainly no replacement for C. Ever try writting an OS in
> Java? Don't really know much about C# except the driving force behind
> it was corporate politics rather than technical superiority. And as
> for C++, doesn't it still support null terminated strings alongside
> better ways to do it?

C# was definatetly technology driven to provide MS with an
alternative to Java.

What is wrong with writing an OS in Java ? To be more precisely: most
of the OS in Java ?

MS has already made a toy OS with most of the code being
managed (equivalent to running in a JVM).

>>>> None of the big languages invented after 1990 (primarily Java and C#)
>>>> uses the null terminated string concept. They use objects. Which
>>>> are in reality equivalent to VMS descriptors.
>
> And neither of the examples provided are suitable or were intended to
> do the things C was created to do. Prove me wrong, rewrite any Unix
> kernel in either language. I'll make it easy for you, you can use
> Ultrix-11 as your guinea pig. It's relatively small as Unix kernels go
> and all the sources are available. Oh wait. You can't write an OS in
> Java. It only runs in a Virtual Machine which requires an OS and a
> very limited subset of existing hardware in order to run it!!

Your view about OS's are outdated.

Arne

[Bill Gunshannon]

In article <mOR_g.22728$***@dukeread09>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <_Jt_g.22692$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>> You don't change the language definition in a way that will
>>> break so much code.
>>
>> I have already posted a method that would allow future code to be
>> string safe as well as make slow conversion (as bugs are found and
>> fixed) without breaking existing code.
>
> The string type approach.
>
> If you keep the char and just add a string type, then you will
> not break any existing code.

That's exactly what I said. Let the bad code die out by attrition.

>
> This what C++ did.
>
> STL string must be around 15 years old. And it has not
> nearly replaced null terminated char arrays yet.

Because no one has bothered to add it to the "offending" language.
All of the legacy code is C, not C++. In order for the change to
take effect it has to be implemented in C, not C++. The fact that
it has not is what leads me to the opinion that the majority of the
industry just doesn't care or see it as a problem as big as some
vocal minority sees it. I admit, in hindsight, that it is a problem.
But then, hindsight is always 20/20. if you can come up with a
working time machine I volunteer to go back and I am sure I could
convince K&R that it will be a bad idea and they can do it a different
way in that first C Compiler. :-)

>
> But maybe in another 15 years.

Not in 50 if someone (with the ability) doesn't decide that it is a
serious enough problem to actually do something about.

>
> It doesn't work.

What doesn't work? My string approach? Won't know that til someone
tries it.

>
>>> When it became acknowledges as a problem it was too late.
>>
>> It is never too late. If the problem is seen as serious enough it
>> will be fixed.
>
> People realize the problem.
>
> And they are changing to other languages.
>
> Non OO languages are considered obsolete in most areas, so
> noone sees the need for this feature.

Speaking of opinion!!

>
>>> Enough people care about it.
>>
>> Apparently not, or they would either fix it themselves or be clamoring
>> for the standards bodies to fix it. Or, as a minimum, some entrepreneur
>> would be making a fortune selling "The Safe C Compiler".
>
> The explanation followed in next sentence, so rather poor quoting.
>
>>> They have switched to Java, C# and even C++ with STL strings.
>>
>> Java is certainly no replacement for C. Ever try writting an OS in
>> Java? Don't really know much about C# except the driving force behind
>> it was corporate politics rather than technical superiority. And as
>> for C++, doesn't it still support null terminated strings alongside
>> better ways to do it?
>
> C# was definatetly technology driven to provide MS with an
> alternative to Java.

No, C# was politics driven. MS was damned if they were going to let
Sun hog the spotlight and control the direction programming was going.

>
> What is wrong with writing an OS in Java ? To be more precisely: most
> of the OS in Java ?

How about the fact that in order to run Java you have to already have
an OS on which to run the VM? Although the Gnu people are fighting it,
Sun has been pretty adamant that Java compilers not generate native
code but only Java Byte Code. Sure, you could write an OS is Java,
but it would be running on top of some other OS which kind of makes it
moot.

>
> MS has already made a toy OS with most of the code being
> managed (equivalent to running in a JVM).

And it runs where? In Windows? On top of a Windows kernel?

>
>>>>> None of the big languages invented after 1990 (primarily Java and C#)
>>>>> uses the null terminated string concept. They use objects. Which
>>>>> are in reality equivalent to VMS descriptors.
>>
>> And neither of the examples provided are suitable or were intended to
>> do the things C was created to do. Prove me wrong, rewrite any Unix
>> kernel in either language. I'll make it easy for you, you can use
>> Ultrix-11 as your guinea pig. It's relatively small as Unix kernels go
>> and all the sources are available. Oh wait. You can't write an OS in
>> Java. It only runs in a Virtual Machine which requires an OS and a
>> very limited subset of existing hardware in order to run it!!
>
> Your view about OS's are outdated.

Really? In what way? Do you have a Java VM that can run directly on
an Alpha with no underlying OS? And we won't even go into things like
the VAX or PDP-11 which can never run Java.

Hey, here's an even better idea. Convince HP to re-write VMS in Java.
That would be the last port that would ever have to be done. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Paul Sture]

In article <***@individual.net>,
***@cs.uofs.edu (Bill Gunshannon) wrote:

<snip>

>
> But then, hindsight is always 20/20. if you can come up with a
> working time machine I volunteer to go back and I am sure I could
> convince K&R that it will be a bad idea and they can do it a different
> way in that first C Compiler. :-)
>

And they might just tell you to mind your own business, because their
compiler is only for their own use. :-)

--
Paul Sture

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <mOR_g.22728$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> But maybe in another 15 years.
>
> Not in 50 if someone (with the ability) doesn't decide that it is a
> serious enough problem to actually do something about.
>
>> It doesn't work.
>
> What doesn't work? My string approach? Won't know that til someone
> tries it.

Guess what. Sentences are placed in a certain order for for
a reason.

That sentence is related to the previous sentences.

>> People realize the problem.
>>
>> And they are changing to other languages.
>>
>> Non OO languages are considered obsolete in most areas, so
>> noone sees the need for this feature.
>
> Speaking of opinion!!

No. That is easy to document if you look at what skills
are required in job ads.

>> C# was definatetly technology driven to provide MS with an
>> alternative to Java.
>
> No, C# was politics driven. MS was damned if they were going to let
> Sun hog the spotlight and control the direction programming was going.

No.

They needed something more structured than VB6 and something
easier than C++ COM.

>> What is wrong with writing an OS in Java ? To be more precisely: most
>> of the OS in Java ?
>
> How about the fact that in order to run Java you have to already have
> an OS on which to run the VM? Although the Gnu people are fighting it,
> Sun has been pretty adamant that Java compilers not generate native
> code but only Java Byte Code. Sure, you could write an OS is Java,
> but it would be running on top of some other OS which kind of makes it
> moot.

Wrong.

>> MS has already made a toy OS with most of the code being
>> managed (equivalent to running in a JVM).
>
> And it runs where? In Windows? On top of a Windows kernel?

In itself. No. No.

>> Your view about OS's are outdated.
>
> Really? In what way? Do you have a Java VM that can run directly on
> an Alpha with no underlying OS?

No. But MS had an OS where the native part is (quote from wikipedia):
"interrupt dispatch code".

Of the 50 million lines of code in a modern OS maybe 10000 needs
to be native.

I think it is a rather safe bet that the next big OS will not be
written in C.

If there ever will be a new big OS. There are not much evidence
of such happening.

IBM have created a JVM where most of the JVM is written in Java.
They just bootstrap in in native and off they go.

> And we won't even go into things like
> the VAX or PDP-11 which can never run Java.

No. And ? That means that they are dead !

Arne

[Tom Linden]

On Sat, 21 Oct 2006 07:50:30 -0700, Bill Gunshannon <***@cs.uofs.edu>
wrote:

> In article <wbf_g.22664$***@dukeread09>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> Actually, C doesn't care about null terminated strings any more than
>>> any other language. You are free to create arrays of char that contain
>>> strings in any format you prefer. All you have to do is write routines
>>> to deal with them.
>>
>> Not quite true.
>>
>> The compiler itself generate null terminated char arrays for
>> string literals.
>
> And, as I stated later on, so does the Ada compiler. It is not the
> composition of the character array that is the problem, it is the
> handling of it. As I have also stated in the past, MACRO-11 created
> null terminated strings and I am willing to bet it was doing this
> before the first C compiler was ported to the PDP-11. I can't say,
> as I have no experience with it, but perhaps someone here can answer
> this. Did the systems prior to the PDP-11 support the Macro Directive
> .ASCIZ? Does VAX MACRO? Do any of them have the .PRINT Macro in
> their libraries? What does it expect as the format for a string?
>
>>
>>> And for all of you who feel much more comfortable with Ada, now that we
>>> know there is no longer a DEC Ada and GNAT is the future, try writting
>>> a
>>> program with a few strings in it, compile it with GNAT and then pass
>>> the
>>> executable thru the Unix "strings" command. For those of you not
>>> familiar
>>> with it, it will find and print out the strings in a binary file. It
>>> does
>>> this by looking for strings of ASCII that end in a null. It usually
>>> returns
>>> a lot of bogus strings cause lots of null terminated ASCII happens by
>>> pure
>>> chance, but it also returns all the real strings. Why do I mention
>>> this?
>>> Because it will print out all the strings in your Ada program. Anybody
>>> want to take a guess at what that means?
>>
>> The format is not a C string.
>>
>> The format appears to be (based on a hex dump):
>>
>> * N bytes
>> * 0-7 nul bytes padding length to multipla of 8
>> * 4 bytes with 1
>> * 4 bytes with N
>
> Sure looks like one to the strings command. :-) My point is that it
> is not the constitution of the string that causes the problem, it is
> the way the string is handled by the language. As I stated, there is
> nothing in the world stopping people from changing that constitutes a
> "string" in C. You can easily use the UCSD definition and make the first
> byte (or more, depending on the size limitation you want to impose) a
> length indicator and then write replacements for the standard string
> manipulation routines to deal with them. Or use the VMS Descriptor
> concept with the same requirement for new routines. The source to
> numerous C compilers are available. One could easily make all of this
> totally transparent to the developer. Why has it not been done?
> Apparently,
> not enough people really care.

Why not just use a language that handles strings correctly?

>
> bill
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Bill Gunshannon]

In article <***@hyrrokkin>,
"Tom Linden" <***@kednos-remove.com> writes:
> On Sat, 21 Oct 2006 07:50:30 -0700, Bill Gunshannon <***@cs.uofs.edu>
> wrote:
>
>> In article <wbf_g.22664$***@dukeread09>,
>> Arne Vajhøj <***@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> Actually, C doesn't care about null terminated strings any more than
>>>> any other language. You are free to create arrays of char that contain
>>>> strings in any format you prefer. All you have to do is write routines
>>>> to deal with them.
>>>
>>> Not quite true.
>>>
>>> The compiler itself generate null terminated char arrays for
>>> string literals.
>>
>> And, as I stated later on, so does the Ada compiler. It is not the
>> composition of the character array that is the problem, it is the
>> handling of it. As I have also stated in the past, MACRO-11 created
>> null terminated strings and I am willing to bet it was doing this
>> before the first C compiler was ported to the PDP-11. I can't say,
>> as I have no experience with it, but perhaps someone here can answer
>> this. Did the systems prior to the PDP-11 support the Macro Directive
>> .ASCIZ? Does VAX MACRO? Do any of them have the .PRINT Macro in
>> their libraries? What does it expect as the format for a string?
>>
>>>
>>>> And for all of you who feel much more comfortable with Ada, now that we
>>>> know there is no longer a DEC Ada and GNAT is the future, try writting
>>>> a
>>>> program with a few strings in it, compile it with GNAT and then pass
>>>> the
>>>> executable thru the Unix "strings" command. For those of you not
>>>> familiar
>>>> with it, it will find and print out the strings in a binary file. It
>>>> does
>>>> this by looking for strings of ASCII that end in a null. It usually
>>>> returns
>>>> a lot of bogus strings cause lots of null terminated ASCII happens by
>>>> pure
>>>> chance, but it also returns all the real strings. Why do I mention
>>>> this?
>>>> Because it will print out all the strings in your Ada program. Anybody
>>>> want to take a guess at what that means?
>>>
>>> The format is not a C string.
>>>
>>> The format appears to be (based on a hex dump):
>>>
>>> * N bytes
>>> * 0-7 nul bytes padding length to multipla of 8
>>> * 4 bytes with 1
>>> * 4 bytes with N
>>
>> Sure looks like one to the strings command. :-) My point is that it
>> is not the constitution of the string that causes the problem, it is
>> the way the string is handled by the language. As I stated, there is
>> nothing in the world stopping people from changing that constitutes a
>> "string" in C. You can easily use the UCSD definition and make the first
>> byte (or more, depending on the size limitation you want to impose) a
>> length indicator and then write replacements for the standard string
>> manipulation routines to deal with them. Or use the VMS Descriptor
>> concept with the same requirement for new routines. The source to
>> numerous C compilers are available. One could easily make all of this
>> totally transparent to the developer. Why has it not been done?
>> Apparently,
>> not enough people really care.
>
> Why not just use a language that handles strings correctly?

I agree!!! I have always been an advocate of the idea the one of the
earliest stages of true Software Engineering is picking the right
language for the job. Programming is not "one size fits all" . But,
sadly, most of the world does not agree with me and still chooses the
language for a project more on what is currently in vogue rahter than
the actual capabilities of the language.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[JF Mezei]

> > Why not just use a language that handles strings correctly?

Yes, good suggestion. But unfortunatly, one which cannot be implemented anymore.

Consider this very example. Person wants to use what is essentially an
industry standard CGI lib interface. Like it or not, ood or bad, the
fact is that the standard CGILIB is written with null terminated strings
in mind. That is the cost of adopting "industry standards" which do not
take advantage of the added features of VMS (such as descriptors which
are well supported by COBOL).

[Bob Koehler]

In article <wbf_g.22664$***@dukeread09>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> Actually, C doesn't care about null terminated strings any more than
>> any other language. You are free to create arrays of char that contain
>> strings in any format you prefer. All you have to do is write routines
>> to deal with them.
>
> Not quite true.
>
> The compiler itself generate null terminated char arrays for
> string literals.

And the ANSI language standard includes a library full of routines
to process null terminated strings. So C does care, but you can
program around it.

Getting back to the OP's issue with COBOL (or did I cross threads
somewhere): it's also possible to generate null terminated strings
from DEC's compilers other than C (I've done it), and if you look
at the Cobol User's Guide you'll probably find out how. It's just
not as easy as declaring a native COBOL string.

[John Santos]

Bill Gunshannon wrote:
> In article <***@vaxination.ca>,
> JF Mezei <***@vaxination.ca> writes:
>
>>Jan-Erik Söderholm wrote:
>>
>>>Can Cobol be setup to call those cgi functions directly or
>>>does one need C-stubs ? I guess from what you wrote above
>>>that C-stube *are* needed.
>>
>>Back in the 1980s, I had COBOL main program call up some C routines.
>>
>>The main bone of contention are strings. COBOL passes fixed length
>>strings (whether as a pointer to the actually buffer, or as a pointer to
>>a descriptop which points to the buffer). This means in practice you are
>>passing around blank padded fixed length strings. C likes null
>>terminated strings.
>
>
> Actually, C doesn't care about null terminated strings any more than
> any other language. You are free to create arrays of char that contain
> strings in any format you prefer. All you have to do is write routines
> to deal with them. It would not be particularly difficult to write a
> library of string functions that did not allow the dreaded buffer-overrun.
> The only reason I can think of why this has never been done is lack of
> interest.
>

A much more likely reason is that it in fact has been done hundreds of
times, by hundreds of different programmers, with no standards and no
way to get anyone else to use the same format, and the complete lack
of compiler support makes such packages harder to use for quick and
dirty code, so none of this has ever been adopted by anyone but the
original implementor.



> And for all of you who feel much more comfortable with Ada, now that we
> know there is no longer a DEC Ada and GNAT is the future, try writting a
> program with a few strings in it, compile it with GNAT and then pass the
> executable thru the Unix "strings" command. For those of you not familiar
> with it, it will find and print out the strings in a binary file. It does
> this by looking for strings of ASCII that end in a null. It usually returns
> a lot of bogus strings cause lots of null terminated ASCII happens by pure
> chance, but it also returns all the real strings. Why do I mention this?
> Because it will print out all the strings in your Ada program. Anybody
> want to take a guess at what that means?
>
> bill
>


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

[David Jones]

In message <pi7_g.20437$***@newsb.telia.net>,
<jan-***@telia.com> writes:
>Yes, that was actualy was I ment to ask in the first place. :-)
>Can Cobol be setup to call those cgi functions directly or
>does one need C-stubs ? I guess from what you wrote above
>that C-stube *are* needed.

I don't think wrappers are strictly needed, but it is probably less cumbersome
performing a function than converts between COBOL native strings and C-style
strings than setting up the arguments every time for direct calls to the cgi_*
functions.



David L. Jones | Phone: [phone]
Ohio State University | Internet:
140 W. 19th St. | ***@er6s1.eng.ohio-state.edu
Columbus, OH 43210 | [e-mail]

Disclaimer: I'm looking for marbles all day long.

[Doug]

Jan-Erik Söderholm wrote:
> Hi.
> The "docs" that comes with the OSU web server kit has examples
> files for C, Java, Perl and I think also Fortran in the latest kit.
>
> Now, does anyone see any particular reason why one shouldn't
> be able to use Cobol against the CGI API's ?
>
> I'm evaluating adding a few simple web "statistics" pages
> to an factory control system where the bulk of the logic
> in the applications are in Cobol using VT-interfaces
> (through a form management tool I've forgotted the name
> of, but is was not FMS or TDMS at least...)
>
> The plan is to keep the bulk program logic in Cobol but
> create som html instead of writing to the VT-interface.
>
> If the Cobol-way of doing thing isn't compatible with
> the OSU CGI APi's, I guess one can write a few C-stubs,
> right ?
>
> Best Regards,
> Jan-Erik.