Bill, Sorry, but I must humbly disagree with you. The technical prowess (or lack thereof) of regular Mainframe programmers is positively on-topic for this issue.
In response to your hypothetical question, IMHO anyone who lights a match in that cellar counts as "stupid" and deserves the result that they get. Natural selection is brutal, only the smart and aware survive. Continuous self-education is a life skill that all need to learn for survival in a constantly changing world. I have never believed in "hiding away" technical sophistication. Management may or may not decide that they want such techniques to be used (I have personally had one such technique rejected by management in the last half-decade), but (again IMHO) not publicizing the sophisticated technique is never a good idea. "Business logic" is not a homogenous entity, sometimes business needs require sophisticated solutions, and programmers should be made aware of all the tools at their disposal. Whether and when they are ultimately used is a different set of issues entirely. To the topic at hand, I think I understand IBM's rejection of this part of the new COBOL standard at this point in time, for all the reasons described in this thread. Many questions and not many good answers yet. Frank S., You may be surprised at how many "ordinary" programmers will grasp the concepts and pitfalls of dynamic storage allocation if you only give them a clear exposition of the ideas and details of how to use it. I have done that here more than once with reasonable success. Plus once you introduce them to COBOL POINTER variables, many other techniques will become possible and easier to understand, including ways to avoid moving large chunks of storage around when using a pointer will do the job, thus improving performance in non-trivial ways by eliminating unnecessary MOVE's. Try it, you may find that you (and they) like it. Regards, Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Wednesday, August 03, 2016 7:16 PM To: [email protected] Subject: COBOL 2014 dynamic capacity tables Well, Peter, there is much in what you say, but be careful of quotes. "Mmm... I smell gas in this dark cellar, has anyone got a match...?" - was the person ignorant of the rapid combustion of said gas when a flame is introduced, or just stupid? Same question for the match provider, and the others with them. Given the chance to question the fleeing ghosts, you'd probably hear "we needed light, we've always done it that way". How to improve Mainframe COBOL programmers is way off this topic. Yes, explain, but also hide it away. I normally dislike the idea that "then some magic happens" in programming, but for the out-of-the-ordinary which is not part of the business logic, stick it in a sub-program (can be embedded these days, and included within a copybook, and the nice compiler will even be able to consider it for "inlining" so you may be able to have your cake and eat it. -- 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 [email protected] with the message: INFO IBM-MAIN
