Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/26/04 

Date: Fri, 26 Nov 2004 16:28:59 GMT

On 25 Nov 2004 23:58:18 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>> >If you want to you can in C:
>> >
>> > struct {
>> > struct { char GivenName[20];
>> > char SurName[20];
>> > } RealName;
>> > struct { int year, month, da;
>> > } DateofBirth;
>> > int Age;
>> > } person;
>> >
>> >but why would you - unless you were a Cobol programmer.
>>
>> Because the input file is in that format.
>
>You missed the point. You wanted to contruct the whole record in one
>piece with having to define the inner bits first. Here I just did
>that. It can be done, but C programmers know not to do it that way.

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. If it were an output file,
they could send the above code to the recipient, who would understand
it.

>> I concur when it comes to common types like Date.
>> But files typically
>> contain many custom types. Strings and numbers come in various sizes.
>
>The only reason being that Cobol programmers want to save a few bytes
>here and there, something that you have been ranting against.

>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.

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. He
must pad it to fixed length a'la Cobol or change the file format to
CSV. In either case, the field in the record is not a native C type.

What kind of programming language doesn't natively support
fixed-length fields in a file? A badly designed one.

>In between there are SQL databases. Your argument is based on what
>Cobol did in the 60s thru 80s and what Pascal did in the 70s. When
>both go to SQL there are fewer difference.

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

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

>> After three levels they bump into
>> the 30-byte limit on name size.
>
>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.

>> No, REPLACING is also forbidden. ...
>
>> I'm not making this up. I just removed REPLACING and created twenty
>> copybooks.
>
>Who wrote the REPLACING ? You ?

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.

>> >I see not a lot of difference between:
>> >
>> > In-DeliveryName
>> >and
>> > In.Delivery.Name
>>
>> There isn't. Block languages force us to program like mainframers. The
>> only difference the limit on 30-byte names.
>
>The only difference is that you don't like it. I don't see the dotted
>notation as an imposition. Nor, it seems, do C like or OO
>programmers.

The imposition is not dot notation, it is the requirement for
superfluous qualification. Some defend that, then in the next breath
call Cobol 'too verbose'. I'm pointing out there's a contradiction
between the two.

>> No, I avoid using those languages .. and provide an explanation of
>> why.
>
>And those languages would probably avoid you, too.

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

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

>That may be _your_ opinion, probably based on not being used to seeing
>C++ or Java. It probably all looks like hen scratching to you.

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

Occasionally, I see elegant style and logic. The logic would be
elegant in Cobol as well, but people and shops interested in good code
have largely abandoned Cobol.

>But to someone that is used too seeing Java or C++ your best Cobol
>probably looks clunky.

They don't say it's clunky; they say 'Wow. I didn't know Cobol could
do that.' and 'My professor said Cobol couldn't handle that.'

>It is all what one is used to. I am used to Cobol and to C and to
>Python and I switch to styles suitable to those. I don't write Cobol
>code in Python.

I do write C code in Cobol. I don't think of it as C; I think of it as
generic language-independent programming.

>> Here you expect readers to believe I spent a lifetime working only on
>> trivial programs.
>
>While you have obviously worked on substancial amounts of Cobol, you
>have only worked on trivial C

No. I've worked on large production systems.

> and Pascal, and probably less on C++, Java or Python, as you agree.

That's true.

>They may question any and all of what I say, or even disagree with me
>if they wish. I don't expect my words to be accepted uncritically as
>your seem to for yours.

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.

Relevant Pages

  • Re: GoTo in Java
    ... were a year or two down the track and everybody was very happy with OCaml. ... > language switch would pay off in faster development (due in part to ... COBOL as a scripting language for .NET. ... Compare this with COBOL programmers discussing Java... ...
    (comp.lang.cobol)
  • Re: Declining Cobol job market
    ... pursuing Cobol jobs. ... server side programming in PL/SQ. ... A lot of COBOL programmers (and RPG programmers, and Assembler ...
    (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: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... possible that Cobol programmers see themselves as defenders of an intellectual lost cause?The last hangers-on of an idea whose time has passed. ... The absolute power was a corrupting influence, just as it has been in certain other religions. ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... people to think about why COBOL is in the state it's in. ... a dollar for every time I have seen Business people put down by programmers. ... >> There are certainly parallels with religion in that. ...
    (comp.lang.cobol)