If you are expecting this type of table to non-contiguous in any way, then that breaks things.
You couldn't REDEFINES (you could "ban" it. No you can't. REDEFINES is banned for OCCURS DEPENDING ON yet I use it a lot). OK, for SEARCH, you could have special versions of the library routines (great, two places to maintain stuff). But what about INSPECT, STRING, UNSTRING? Ban those as well. What about the code an-entry ( a-subscript + n ) where + is +/- n is a literal numeric value. OK ban it. What about CALL? Ban it. What about anything except the particulars of the dynamic capacity table? So, forget non-contiguous storage. So make the performance issue that of keeping the table contiguous, implicitly. Like with any acquiring of storage, "adding to it" can be a heavy process. An implicit process. Which newly-trained CS people are not used to either knowing about or being concerned about. Where in the DATA DIVISION would it be? LINKAGE SECTION again (non-Standard). WORKING-STORAGE or LOCAL-STORAGE (breaks how they work currently)? I don't think everything (by a long stretch) in the current COBOL Standard (2014, replacing 2002) is a "good fit" for what we (that's me saying "I" and hoping not to look entirely isolated) expect for a Mainframe COBOL. Also, performance was not the only reason. There is "error prone" and also these: "Some clients may have restrictions on using this. This is not in our multi-year strategy." It would be good, but perhaps not possible, if IBM were to outline their multi-year strategy for COBOL. Avoids the rejection of RFEs which stood no chance for that reason. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
