Re: Called Module with File Access - where to Close

Chuck Stevens wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:11dq1d1pganit74@news.supernews.com...
> 
>
> One thing about ENTRY is that it ties the architecture of the
> *program* to the architecture of the *system*.  ENTRY is not part of
> standard COBOL (be it '68, '74, '85, '02 or even the current working
> draft for the '08 standard) and an application that is dependent on
> the presence of this syntax will not compile in any environment
> *except* those that support this particular vendor extension.

That notion has been banded about, like, forever. In over thirty years of
COBOL programming, I've yet to run into anyone who gives a fig. But, of
course, I don't get out much. Does anyone know of a vendor who does NOT
support this extension? Do they have any business?

>
> If one of the purposes of writing in COBOL in the first place is to
> provide at least a modicum of portability to a variety of platforms
> that run COBOL, tying an application design to a particular vendor
> extension goes contrary to that purpose.   It does not matter if the
> code is only going to be used in a single operating environment, but
> some managers think in terms of protecting their investment in
> home-grown software by limiting the vendor extensions that may be
> used in its development.

You're correct. But it's a big "IF." I've developed systems on big iron to
PCs. I've never met a manager who was concerned about porting a new
development to a yet-unknown hunk of hardware in the amorphous future. Such
managers COULD exist, but I suspect no one pays them much mind anyway.

I certainly know of vendors who handle ENTRY statements differently.  If you
check out the Micro Focus "STICKY-LINKAGE" directive, you will see (at least
one) problem with how ENTRY statements work.

I also know several IBM mainframe shops/programmers that have been "bitten" 
by
the restrictions IBM documents at:

http://publibz.boulder.ibm.com/cgi-...gy3pg30/4.1.6.2

I also see no evidence that IBM's COBOL for the OS/400 environment supports 
an
ENTRY statement (but I might have missed it).  I checked:

[url]http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/books/sc092539.pdf[/u
rl]

--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11drfram09kuu56@news.supernews.com...
> Chuck Stevens wrote: 
>
> That notion has been banded about, like, forever. In over thirty years of
> COBOL programming, I've yet to run into anyone who gives a fig. But, of
> course, I don't get out much. Does anyone know of a vendor who does NOT
> support this extension? Do they have any business?
> 
>
> You're correct. But it's a big "IF." I've developed systems on big iron to
> PCs. I've never met a manager who was concerned about porting a new
> development to a yet-unknown hunk of hardware in the amorphous future. Suc
h
> managers COULD exist, but I suspect no one pays them much mind anyway.
>
>
>

On Tue, 19 Jul 2005 22:05:21 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
wrote:

>Chuck Stevens wrote: 
>
>That notion has been banded about, like, forever. In over thirty years of
>COBOL programming, I've yet to run into anyone who gives a fig. But, of
>course, I don't get out much. Does anyone know of a vendor who does NOT
>support this extension? Do they have any business?
Liant RM/COBOL do not support it, and they DO have MANY business.

IBM AS400 COBOL/400 and ILE-COBOL do not support it either (as Bill
mentioned on another thread)

Not sure now, but AcuCOBOL didn't support it either.

hope this answer your question.


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11drfram09kuu56@news.supernews.com...
> Does anyone know of a vendor who does NOT
> support this extension?

Yes.

> Do they have any business?

Yes.

> You're correct. But it's a big "IF." I've developed systems on big iron to
> PCs. I've never met a manager who was concerned about porting a new
> development to a yet-unknown hunk of hardware in the amorphous future.
Such
> managers COULD exist, but I suspect no one pays them much mind anyway.

I agree that just about every vendor has extensions and just about every
installation uses them in some form or another.  But I have run into a
*significant* number of sites in which the extensions are strictly isolated
such that the bulk of the application code doesn't need to make direct use
of them, precisely so that if the site decides to switch vendors the
migration is relatively painless.

-Chuck Stevens