Although the NAME option does indicate a communication path already exists, it is a very limited context.
I'd not feel very secure that any old binder statement someone can cook up could just appear in a line of COBOL source. The argument that HLASM can do it just puts the spotlight on that. I know that's not going to change, but... A completely reasonable way to deal with compiles/binderings for different "types" is through different JCL, usually sitting under some panel-option somewhere. Non-obvious binder control statements going into Production. No. Subset of control statements? Just INCLUDE? What if I were to INCLUDE something which had an entry-point of the same name as something else, so mine gets chosen over the real one? Only able to INCLUDE from a list of "standard" names? What if I create something with a standard name? On Thursday, 10 March 2016 22:13:01 UTC, Frank Swarbrick wrote: > I was excited to see someone opened this RFE: > https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=83968 > (Make sure you are logged in to IBM before clicking the link.) > > I was then dismayed that it was already rejected. I've written some comments > to the RFE and I would encourage others to do the same, and perhaps the > original requestor could request re-consideration. > > If you think that IBM was right to reject the RFE I would be curious to know > why. > > Frank > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
