Re: Infinite Loops and Explicit Exits

From: Richard (riplin_at_Azonic.co.nz)
Date: 11/27/04 

Date: 26 Nov 2004 15:22:34 -0800

Robert Wagner <spamblocker-robert@wagner.net> wrote

> You're correct when you say they don't. I've never seen C written that
> way. My point is they should write it that way, because it follows the
> structure of the record layout in the spec.

No. Which 'spec' are you looking at ? a _Cobol_ one no doubt. System
specs are written for the implementation language. On Cobol systems
the 'spec' defines the records that Cobol would use.

For systems written in C/Java the 'spec' would define the record in
terms of C/Java. Once again you show your limited scope by thinking
that the world is defined in Cobol terms because that is all you have
ever seen.

> If it were an output file,
> they could send the above code to the recipient,

 who would understand
> it.

Output files sent to 'recipients' are in a form that they can
understand which may be EDIFACT, CSV, XML, or some agreed format.
Sending out file dumps is a crap way of distributing data.

> who would understand it.

What they would understand is a function of what they are used to.
Sending out an FD of a struct as a definition is a crap way of doing
it. What is required is a properly documented list of fields.

> >It is true that _Cobol_ files contain certain things, but files used
> >by C and Pascal programmers tend to be designed to suit what those
> >programmers want, not what Cobol programmers want.
>
> A good tool should be able to handle any data structure, not just
> those created by people using the same language.

Which is why a 'good tool' is SQL databases. Interestingly SQL
doesn't nest fields like you want for Cobol, but does have structured
types such as TIMESTAMP.

> How does a C programmer store a string, such as Name, in a file? His
> null-terminated memory format is unsuited to storage in a file.

Why do you think that null-terminated is unsuited to files ? Is it
because you have only ever seen Cobol files ?

> He must pad it to fixed length a'la Cobol

_Must_ he ? Why is that, is it so that it fits into the 'world as
defined by Robert Wagner' ?

> or change the file format to
> CSV. In either case, the field in the record is not a native C type.

So first you claim that he _must_ change it to non-native then you
whine that 'now it isn't native'. It must be really easy to create
these criticisms, just expose your ignorence.
 
> What kind of programming language doesn't natively support
> fixed-length fields in a file? A badly designed one.

Actually C has no problem at all outputting fixed-length fields really
easily. See fprintf().

Of course your 'badly' is simply your way of saying that it isn't like
Cobol.

> None of these languages (except PL/SQL) support SQL types. They
> require conversion to and from the language's types.

How wierd then that Cobol often has to use an extension in the form of
COMP-5 in order to emulate a C type for accessing SQL.

> When Cobol gets ANY LENGTH, there will be fewer differences. ANY
> LENGTH is a Cobolized version of SQL's VARCHAR2.

And Cobol is adding more so that it can keep up with C like languages
then.
 
> >That depends on the size of the prefixes.
>
> The universal length for identifiers, at least file names, is eight
> characters. Just in case we have to return to assembly language.

Only in some tiny corners of the world that you crawl around in.

> Yes. A NEW program used six files with the same record layout. I wrote
> one copybook for select, one FD and one record, then copied each six
> times with REPLACING. Some mainframer insisted I remove REPLACING and
> create eighteen copybooks, plus another twelve for headers and
> trailers.

Probably just to piss you off.
 
> The imposition is not dot notation, it is the requirement for
> superfluous qualification.

It isn't 'superfluous', it isn't an 'imposition'.

> Some defend that, then in the next breath call Cobol 'too verbose'.

They understand their language and don't understand Cobol, while you
are the reverse. People criticise what they fail to understand, are
you so ably demonstrate.

> They're not content with avoiding Cobol, they throw rocks at it with
> terms like verbose and dinosaur. When I point out deficiencies in
> their language, they brush them aside, saying 'What do you expect from
> a Cobol programmer?'

Exactly, and what's more, a Cobol programmer who refuses to understand
their languages.

> Then they design yet another language, hoping no one will notice they
> did it to escape flaws in the old one.

Oh, you mean like: scope terminators were added in '85 and hoped that
no one noticed that was a deficiency in older versions; and 'ANY
LENGTH' will be added in the meantime hope no one notices it is flaw ?

> I see bad logic cloaked by syntax unreadable by an outsider. If it
> were written in Cobol, the bad logic would be more visible.

The stntax is only 'unreadable' to those who refuse to understand it.
 
> If I said the sky was blue, people would argue that it's black half of
> the time. Real programmers are irritated by my defense of Cobol;
> mainframers are afraid they'll be exposed.

I suspect that you irritate most people you meet because of your style
of argument which is more like evangulising.

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... but C programmers know not to do it that way. ... not what Cobol programmers want. ... null-terminated memory format is unsuited to storage in a file. ... What kind of programming language doesn't natively support ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... like RDB, for the same reason. ... COBOL was left behind. ... businesses to keep their old language, or to go to a new language: ... they have mainframe programmers and web programmers. ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)
  • Re: 7E7 Flight Controls Electronics
    ... Cobol hit the world at a time when the only other programming language ... Ada, OTOH tried to address the needs of embedded systems programmers and ... that embedded programmers already had something - C - which was cheap ...
    (comp.lang.ada)
  • Re: Work For The Willing
    ... COBOLis just another programming language. ... I might suggest that if you *like* COBOL you should learn Python. ... impression was that it was expected that COBOL programmers would solve the ...
    (rec.arts.sf.fandom)