I don't look down on "mere programmers", and in fact am often quite offended when people on this list appear to be disparaging them. But I do have to be realistic to know what most COBOL programmers (at least where I work) are not "techies", but rather people who "implement automated business logic". And indeed there is nothing wrong with this, most are quite good at it, even if I often cringe at the resulting code. But any time I come up with a solution to something that "seems too technical" its generally not implemented.
My "roll my own" dynamic tables have not yet been presented in-house, but along with some copybooks I've developed to make it even more "developer friendly", I have a good feeling that people will respond well to it (especially considering how often they are called in the middle of the night because a "table ran out of room"!). We shall see. As much as I am happy with my solution, I would still prefer a COBOL language solution. Frank ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Wednesday, August 3, 2016 4:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 2014 dynamic capacity tables Now, now gentlemen, let's not look down on mere programmers (I resemble that remark!) -- Remember the saying from author Robert Heinlein's "The Moon is a Harsh Mistress": "Ignorance is curable, only stupidity is fatal." If employers have not provided sufficient training time and dollars, what else but ignorance do you expect? Try issuing a technical note or two to the ignorant telling them about the wonderful things the system can do for them (best if the notes include examples the ignoranti can try for themselves of course). We do that here (well, at least Victor and I do) and call them DYKT's (Did You Know That . . . ). The response is sometimes quite positive. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Wednesday, August 03, 2016 3:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 2014 dynamic capacity tables Because your average COBOL programmer, in my experience, knows "bupkis" abound dynamic memory allocation. Perhaps I am wrong, but as far as I know I am the only one in our shop who ever uses it. As for your concern about serializing storage between multiple concurrent tasks, I don't know of situations that would require this. This is intended for use within a single run-unit. But even if a table was shared between multiple tasks (within a CICS region I can only imagine) you have this concern with our without "dynamic tables". You'd have to serialize updates in either case, so I don't see why dynamic capacity tables would cause any additional heartache. Frank ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Victor Gil <victor....@broadridge.com> Sent: Wednesday, August 3, 2016 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 2014 dynamic capacity tables I am not sure why would you want the compiler to handle such a general case of maintaining a dynamic-size table, while this can be easily programmed by using the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a callable service. We do this kind of dynamic table management all the time, under CICS [i.e. using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here is how to safely re-size a table which has reached its allocated capacity. This shouldn't be an issue in batch where the storage is owned by a single task because it can just wait for the call to come back while the subroutine allocates a new larger size table and populates it from the old one. So if you ask the compiler to perform such a function it would have to know how to serialize storage access between multiple concurrent tasks and, moreover, let the in-flight transactions to keep accessing the old table while the new one is being allocated and populated. Pretty difficult for a general case. -Victor- ------------------------------------------------------------------ Last year I submitted an RFE (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=73693) that Enterprise COBOL be enhanced to support dynamic capacity tables as defined in the COBOL 2014 ISO standard. It was declined: "Thank you for bringing this RFE to our attention. But we believe that if implemented, it will be really slow and error prone. Some clients may have restrictions on using this. This is not in our multi-year strategy. Hence, we'll have to reject this RFE." Since the year has passed I have resubmitted the RFE, now with the following comments that I hope might address IBM's concerns: "This RFE was declined based on concerns about performance. I would like to submit the following possibilities for consideration: Would IBM be more amenable to a partial implementation? while you did not indicate in the declined RFE what performance issues you foresee, I can hazzard some guesses. One is the requirement in the standard is 8.5.1.6.3.2 Implicit changes in capacity: "When a data item in a dynamic-capacity table is referenced as a receiving item and the value of the subscript exceeds the current capacity of the table, a new element is automatically created and the capacity of the table is increased to the value given by the subscript. If this new capacity is more than one greater than the previous capacity, new intermediate occurrences are implicitly created." I believe this would require a runtime check in each of these cases to see if the subscript is greater than the current capacity, and if so to increase the current capacity. The current capacity can also be increased explicitly. 8.5.1.6.3.3 states "If the OCCURS clause specifies a CAPACITY phrase, the capacity of the dynamic-capacity table may be increased or decreased explicitly by means of the dynamic-capacity-table format SET statement." The "implicit changes" was one of the arguments I've seen against implementation of dynamic capacity tables, with the concern that one might have a bug that set a subscript to an incorrect and possibly very large value, which would cause the table to be increased to that value "improperly". So why not eliminate that requirement as part of the implementation? I can't see any problem with a simple "SET tbl-capacity UP BY 1" when intentionally adding a new row to the table. One other feature I can see that could be bypassed, at least initially, would be the behavior of the MOVE of a group containing a dynamic capacity table. Because a d.c. table would most likely not be "physically contiguous" with the rest of the items in the table, a MOVE of the entire group would at the very least be "less efficient". So how about a restriction that you can't do a group MOVE where the group contains one or more dynamic capacity tables? I don't see too many uses cases where this would cause an issue, and if we can get implementation of the most important features, that is better than nothing at all?" I still believe this would be one of the most useful enhancements that COBOL could have. Please vote if you agree. (There is also a similar SHARE requirement.) My resubmitted RFE: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92391 Share Requirement: http://www.share.org/index.php?mo=is&op=vi&iid=67&type=23 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
