There is a conflation of two issues, with the first being in two parts. Issue 1) Part a) Can't define enough storage for a table due to COBOL limits.
This is only an issue for "old" programs, where limits for table-size were imposed by the compiler. The "expedient" approach was to define consecutive tables, the subsequent ones being "catch-all" for overflow from the main table. More resilient approaches would have been available, but would have required "more thought". Issue 1) Part b) This table can never fill, so it doesn't matter that it is used in 20 sub-programs with no checking - it just logically can't fill Of course, for some given number of tables, it fills, and it does so at 02:30. Temporary expedient is to add an "overflow" table in the main program, and "fix it properly" some time later. Which only ever happens piecemeal, when one of the sub-programs has to change. Issue 2) the inexperienced programmer Previous to V5+, the indexes are (more) safely tucked-away in the TGT, out of immediate danger of being trashed. It was not impossible to trash, but less likely. With the V5+ change, a simple overrun using an index could trash the index, leading to a complex issue for an inexperienced programmer, even if a more experienced programmer may expend less effort identifying the issue (and, ideally, not having the issue in the first place). Prior to V5+, something else would be trashed, but the current value of the index would at least be pointing to the trashed value, rather than to somewhere wild (which may or may not have subsequently been trashed, and which may even be program code, or a system area, or whatever). Yes, absolutely, to never access storage outside the storage you've defined is the best thing to do, but when a new beginner does access something in error, it is less than hepful that something completely weird may happen (and remembering that the absolute worst situation is when something "happens", but it is not noticed/immediately connected to the problem. The frustrating thing was the up to V4.2 the "extending a table" method was covered in the Programming Guide, where OPT(FULL) was discussed (a warning to not remove innocent-looking "unused" tables that were used for this purpose). With FULL being replaced by a new option, the reference disappeared from the V5 documentation, but it cannot be argued that IBM (someone) was aware of the issue existing before it was idly changed. The reason for location was given as "performance", though I can't really visualise why an index "down there somewhere at the end of the table of length up to 999,999,999 bytes" can outperform an index "right here, immediately in front of the table" if the overwhelming need was to have the indexes defined, for the first time, intermingle with WORKING-STORAGE, user-defined, data. There's also indexes for LOCAL-STORAGE and, of course, without any possibility to locate with the table, the LINKAGE SECTION. I don't know for 100% where indexes (indices) are located, as I've not got access to V5+ nor seen a listing subsequent to the PTFs. They may or may not be in "as safe" a place as they were before, but I don't think they'll be moving again any time soon, as I think the change was substantial to apply the fix. As well as the COBOL Cafe discussion, there was a discussion on LinkedIn, which got comment from Tom Ross. In the end, the "fix" was unexpected from the results of those discussions. On Tue, 10 Jan 2017 11:27:34 +0100, Peter Hunkeler <[email protected]> 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. > > > >I understand. I also read the head of the thread that Bill posted. > > > >It seems kind of ridiculous to me to justify all this with "less experienced >programmers....". I remember when I was told how to program, I was told to >always make sure my coded does not go beyond the table. This is nothing >difficult to do. There is no excuse not to do it. > > >And as for the "standard way" to cheat the Cobol table restriction (I'm no >Cobol programmer, sorry): Cheating is cheating. Shudder.... But it explains at >least why IBM agreed to change the code. Thanks. > > > > >-- >Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
