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

[Brian Tiffin]

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.

Cheers,
Brian
> -----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.