Re: Called Module with File Access - where to Close

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-bin/bookmgr_OS390/BOOKS/igy3pg30/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:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/books/sc092539.pdf

--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@xxxxxxxxx> wrote in message
news:11drfram09kuu56@xxxxxxxxxxxxxxxxxxxxx
> Chuck Stevens wrote:
>> "HeyBub" <heybubNOSPAM@xxxxxxxxx> wrote in message
>> news:11dq1d1pganit74@xxxxxxxxxxxxxxxxxxxxx
>>
>>> What's "awful" about ENTRY?
>>
>> 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.
>
>
>


.

Relevant Pages

  • Re: What Smalltalk product/implementation would you use, and why?
    ... problem - the model you want does not lead to a supportable business. ... What it leads to is a vendor that goes under. ... My reason, I am sick and tired of being hosed on COBOL's prohibitive costs - and I'm talking a fully integrated IDE allowing for traditional COBOL, SQL Preprocessors and OO COBOL with general/collection and GUI classes - a superb tool - if you don't mind getting screwed by the compiler vendor on fees. ... I'm searching the Web looking at the multiplicity of options, Smalltalk in its various flavours, Java, C# and of course Visual Studio. ...
    (comp.lang.smalltalk)
  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... There are users of OO COBOL; they are just far fewer than either the vendors ... whether from the same vendor or not. ... disagreed with you that XML should be supported *first* by the OO features ... > being spent by J4 to provide these facilities through a standard that will ...
    (comp.lang.cobol)
  • Re: Standard and COBOL file formats
    ... Nor is it a creature of Cobol, ... The 'format' is actually defined, not by the operating system, but by ... the vendor uses headers or other devices to mark records, ... If you mean ORGANIZATION RELATIVE ACCESS RANDOM then you are ...
    (comp.lang.cobol)