Yes, a deliberate area left specifically to catch any overflow and for no other purpose, similar to a patch-area.
Technique arises before SSRANGE exists. If SSRANGE were subsequently used, it would/could catch the problem, but it is not as simple as the APAR text makes out (from memory of the text). So SSRANGE would "help" but not necessarily be sufficient, and remember that in cases the originally code is deliberately overflowing (to overcome an old compiler limitation). Then you get into "change that costs (development/testing/implementation) but achieves nothing, which is sometimes difficult (but important) to "sell" to management. Those who didn't buy (and who migrated early to V5+) reaped that whirlwind. Note that with V5+, the LE runtime option CHECK no longer influences anything. You can't deploy with SSRANGE(ON) and run with CHECK(OFF). Amusingly (to me anyway) people who run CHECK(ON) in Production complained about the additional "overhead" of the check for CHECK being ON or OFF. On Tue, 10 Jan 2017 04:10:12 -0600, Elardus Engelbrecht <[email protected]> wrote: >Gibney, Dave wrote: > >>A frequent, even standard way to get past the size limit of a COBOL array, or >>more appropriately table, was to define more "empty" space after it. Since >>subscript bounds checking was always turned off for performance reasons, you >>could effectively address substantially larger than the size limit of any >>single 01 item. > >Hmmm, it reminds me of a sort of patch area? > >I'm curious, what about usage of SSRANGE compile option and CHECK(ON) runtime >option to avoid going over an array/table and getting an ABEND? Or will that >subscript bounds checking not help you here? > >I'm also puzzled by that APARs and the comments in this thread. (We're still >at COBOL v4, 5655-S71) > >Just following this thread out of curiousity. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
