[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] [open-Cobol-list] ENTRY statement: obsolete?

From: Brian Tiffin
Subject: Re: [open-cobol-list] [open-Cobol-list] ENTRY statement: obsolete?
Date: Wed, 27 Aug 2014 01:49:45 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1

William M Klein wrote:
Right after I sent my note, I realized I was wrong. The ENTER statement was
designated as OBSOLETE in the '85 Standard. I don't think the ENTRY
statement was Standard (at least after the '68 Standard). My explanation of
what OBSOLETE means is correct as is my technique for avoiding it a
"structure" and "conforming " program. However, it was ENTER not ENTRY that
was made OBSOLETE in '85.

By the way, thanks for that Bill. I was pondering how to word the FAQ entry on ENTRY.

I couldn't find a reference to ENTRY, other than compiler specific pages.

The keyword is marked Obsolete in the default configuration file (which causes a warning), but I think it would be more accurate to describe it as 'extension' or 'not-standard'.

Regardless, I'll rail against dropping support for ENTRY (the verb), and
for SET a-program-pointer TO ENTRY "dso-name". Too handy for consise code blocks, ala getters, setters and callbacks.


-----Original Message-----
From: William M Klein [mailto:address@hidden
Sent: Sunday, August 24, 2014 9:59 AM
To: Brian Tiffin; address@hidden
Subject: RE: [open-Cobol-list] ENTRY statement: obsolete?

                I think it would be useful to have an explanation of what
"OBSOLETE" means.

This is an ANSI/ISO Standard term with a specific meaning.  It means that it
will be removed from the next official Standard. The "ENTRY" statement was
designated as obsolete in the '85 Standard and was removed from the '02
Standard (and is still gone in the '14 Standard).

There is a requirement that a conforming implementation provide a flagging
mechanism to identify any obsolete feature used in a program. I don't know
if OC usually run '85 NIST OBSOLETE tests, but they do exist.

There is no requirement that a conforming implementation  ever remove this
features, however there is no expectation that they are portable to other
conforming implementations.

The "expected" technique that you can use without ENTRY is to start your
program with an EVALUATE statement that does a CALL to nested program
depending on the function that you want.  You can then use a nested program
with the COMMON attribute for functions that are needed by multiple nested
programs. The OMITTED keyword can be used if you have a different number of
parameters for different functions.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]