If you were inventing CoBOL...

If you were inventing CoBOL back when, what would you do differently?

I wonder how foresight would have effected OO enhancements.

I would like a USAGE LARGE for numbers that don't fit computer architecture
(have a hundred digits, but inefficient).

Could we get away with enforced structure with the efficiencies back then?

Would you do calls differently?

I see no reason for margins on the left and in the right.

I'd standardize GOBACK type exits.

I'd really like to improve on error checking for calls and functions.

Buuuuttttt  If you were inventing COBOL would you be limited to the
hardware and memory constraints of yester year?  Makes a huge difference.

PatH...doesn't want to hurt his brain too much this morning

Howard Brazee wrote:

> If you were inventing CoBOL back when, what would you do differently?
>
> I wonder how foresight would have effected OO enhancements.
>
> I would like a USAGE LARGE for numbers that don't fit computer architectur
e
> (have a hundred digits, but inefficient).
>
> Could we get away with enforced structure with the efficiencies back then?
>
> Would you do calls differently?
>
> I see no reason for margins on the left and in the right.
>
> I'd standardize GOBACK type exits.
>
> I'd really like to improve on error checking for calls and functions.

On  2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:

> Buuuuttttt  If you were inventing COBOL would you be limited to the
> hardware and memory constraints of yester year?  Makes a huge difference.

Maybe it would be interesting to split the answer into what I asked - you we
re
inventing it back then - and a separate answer if we had today's resources b
ut
no need to have backward compatibility.

On Thu, 2 Sep 2004 13:43:54 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>If you were inventing CoBOL back when, what would you do differently?

Omit PERFORM THRU.
People wouldn't have acquired bad habits that had to be unlearned
later. The concept is flawed, and caused compilers grief in re
returns.

Make PERFORM pass parameters.

Define a DATE type.

Forget SECTIONs. They've always been unnecessary.

>I wonder how foresight would have effected OO enhancements.

??

>I would like a USAGE LARGE for numbers that don't fit computer architecture
>(have a hundred digits, but inefficient).

Don't need USAGE; pic 9(1000) says what you want.

>Could we get away with enforced structure with the efficiencies back then?

Yes. Structured has always been faster than spaghetti. Better overall
flow compensates for micro-inefficiencies.

>Would you do calls differently?

No.

But I would add better dynamic memory. You call with a structure, it
allocates memory, sets a pointer to the structure but hides it from
you.  It's like an OO constructor. Then people wouldn't be afraid of
pointers because they couldn't accidentally step on them.

>I see no reason for margins on the left and in the right.

I've been using free-form for >20 years, on >3 compilers. The
foot-dragger is IBM.

>I'd standardize GOBACK type exits.

I didn't know it was a problem, even before 2002.

>I'd really like to improve on error checking for calls and functions.

You already have that. It's called Prototypes.

Howard Brazee wrote:
>
> On  2-Sep-2004, Pat Hall <phall@notsospam.certcoinc.com> wrote:
> 
>
> Maybe it would be interesting to split the answer into what I asked - you 
were
> inventing it back then - and a separate answer if we had today's resources
 but
> no need to have backward compatibility.

Inventing it back then: most certainly include the in-line performs
(perform ...end-perform) and end-if; but I'd have to leave space
somewhere on the form for sequence numbers because we were using card
decks!  I would have a different method for indicating overlayable
sections due to memory limitations.

If I were inventing it now: I'd require AT END and INVALID KEY with READ
statements (as appropriate); I would not have some verbs, especially
EVALUATE (hey! you did say "if YOU were inventing Cobol"!  And despite
study, explanations and examples, I've yet to come across a case where
an evaluate couldn't be done more clearly and usually simpler with IF's
and/or CASE statments).  We wouldn't need most of the various numeric
formats: "usage display" with (say) 24V8 maximum  digits would suffice
for nearly everything, along with special formats for extreme precision
requirements and really big numbers.  Apart from that, I would stick to
the original goal of clarity and English-like statements.  Cobol has
stood the test of time due to its inherent strengths: smart to retain
those.

PL

On  2-Sep-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:

> Inventing it back then: most certainly include the in-line performs
> (perform ...end-perform) and end-if; but I'd have to leave space
> somewhere on the form for sequence numbers because we were using card
> decks!

But why do we need space for sequence numbers in 73-80 as well as 1-6?   I'v
e
sorted cards both ways.

See http://www.cobolportal.com/j4/files/04-0120.doc for the current state of
this capability as proposed by J4 for the 2008 COBOL standard.    WG4 will
be discussing it next month.  It doesn't require new "types" or PICTURE
character-strings -- all of its mechanisms coexist nicely with existing
COBOL USAGEs.

-Chuck Stevens

"Michael Russell" <michael.russell@spamex.dsl.pipex.com> wrote in message
news:413752b1$0$20257$cc9e4d1f@news-text.dial.pipex.com...
> The biggest omission, as far as I'm concerned - Date, DateTime & Time
types,
> plus the arithmetic functions for them.
>
> Michael
>
>

Robert Wagner wrote:

>Forget SECTIONs. They've always been unnecessary.
>
>
>
In your purview yes. But back using a Radio Shack with only 64K -
absolute necessity to prioritize by allocating Section Numbers, to
'swap' in and out, in order to achieve some objectives. To-day - I gave
up on Sections  nigh on 20 years ago when I first switched the
application to a PC - a Compaq portable.

Jimmy

"avflinsch" <avflinsch@att.net> wrote in message
news:slrncjehhn.bj7.AB2RC@homer.linux1.lan...

> and procedural statements like
>       set ws-switch-a to true       -- (I know we can do this now)
>  and  set ws-switch-a to false      -- (but we can't do this yet)

If you're talking about 88's, yes, you can, presuming a COBOL compiler
compliant with (or containing this particular feature of) the current
standard ISO/IEC 1989:2002, and presuming  that the 88 has a "WHEN SET TO
FALSE" phrase in its VALUE clause.

-Chuck Stevens

"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:413744C2.1041D866@mb.sympatico.ca...
> I would have a different method for indicating overlayable
> sections due to memory limitations.

Although memory limitations are far less an issue than they once were, it is
not clear that all architectures provide the capability of having arbitrary
large object code "blocks".  SECTIONs allow the user to have some control
over the size of such "blocks" and to avoid having "block transitions" occur
in critical-path code.   Even though I agree that the "Segmentation Module"
was way too specific and was appropriately marked as obsolete in '85, I
think retaining "SECTION" (as it still exists in 2002 COBOL) serves a useful
purpose -- whether or not the SECTIONs are ever referenced via GO TO or
PERFORM, and whether or not the implementor does "code block breaks" at
SECTION boundaries.  If nothing else, they can be used to establish a
hierarchy of procedural code between the program and the paragraph levels,
which can be helpful to the programmer (or the *next* programmer to work on
the program).

-Chuck Stevens