On 9/23/2013 10:55 AM, Clark Morris wrote:
On 23 Sep 2013 06:09:02 -0700, in bit.listserv.ibm-main you wrote:
Adjacent 01 levels have been used to allocate storage larger than the maximum
allowed by COBOL.
With the more recent versions of COBOL is the practice still necessary
or can the tables be large enough? Given the existence of BLOBs
(Binary Large OBjects?) of over a megabyte in size, I would think that
serious relaxation of limits was needed and I have read that major
changes have been made in that regard.
Yes. Enterprise COBOL supports table sizes up to 128MiB and COBOL 5
supports table sizes up to 999,999,999 bytes.
But folks are unlikely to change existing code to work with this
unless a program is having some other maintenance done too.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* We are going out of business effective 30 December, 2013
* To purchase a set of our training materials at terrific prices,
check out our Going Out Of Business Sale:
http://www.trainersfriend.com/SpecialSale
Clark Morris
On Sat, 21 Sep 2013 20:18:53 -0300 Clark Morris <[email protected]>
wrote:
:>On 20 Sep 2013 08:12:42 -0700, in bit.listserv.ibm-main John Gilmore
:>wrote:
:>
:>>The idea of eliminating unreferenced variables in COBOL record
:>>declarations is of course absurd, and fulminations against it are at
:>>best otiose. It is always possible to construct quietist arguments
:>>against change, any and all change; but this straw man is too
:>>obviously so to very useful to careerist obstructionists.
:>
:>Basically all COBOL can do is eliminate unreferenced 77 levels which
:>are independent (not in a structure and logically equivalent to 01
:>levels or records) and unused 01 (records) levels in Working-Storage.
:>This may also apply to LOCAL-STORAGE. While fields within a record
:>may be unused, eliminating them changes the structure and can cause
:>problems. In one sense are we straining at gnats in an era when
:>people send megabyte size pictures to each other over the Internet and
:>product files may contain 1 or more pictures of each product? I agree
:>with people that crud should be eliminated but changing record
:>structures which may be used in multiple programs can have interesting
:>results.
:>
:>Clark Morris
:>>
:>>We are left with working-storage and local-storage declarations for
:>>variables that then go unused. In many cases they were once used, but
:>>maintenance changes have made them redundant. In any case they may be
:>>eliminated safely, and they should be when an occasion to do so
:>>arises. They are individually ugly; and they add to source-program
:>>clutter, which is substantial in old COBOL programs.
:>>
:>>Whether a major undertaking, a formal project or the like, for their
:>>elimination is jusitified is another, very different question. I
:>>think not. All optimizing compilers eliminate dead code, sequences of
:>>instructions that can never be executed, and dead variables, which are
:>>never referenced.
:>>
:>>Some compilers and backends are better at these operations than
:>>others. The current IBM C/C++ and PL/I backend, for example, detects
:>>almost all aliasing schemes and even reflects these 'obscured'
:>>references in its XREF output. The current COBOL compiler does a
:>>modest but adequate job of this when full optimization is used. There
:>>is therefore almost no resource-savings argument to be made for a
:>>campaign to eliminate unreferenced variables; and further
:>>bureaucratization of this particular programming milieu is highly
:>>undesirable.
:>>
:>>John Gilmore, Ashland, MA 01721 - USA
:>>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
