Call variable messes up the impact analysis tools used by the programmers in our shop.
We use DYNAM and call literal except where the called program name is truly variable, pulled from a table for example. I am surprised that call literal does not support names with national characters. I have not run into that. It is either a new restriction or an old one that wasn’t being enforced. On Sat, Apr 8, 2023 at 2:25 AM Frank Swarbrick <[email protected]> wrote: > I am indeed using DYNAM. > > I have no great need for this to work. Just something I noticed and was > curious about. > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Farley, Peter <[email protected]> > Sent: Friday, April 7, 2023 11:50 PM > To: [email protected] <[email protected]> > Subject: Re: Cobol calling module with non alphanumeric no longer > allowed??? > > Not true for non-static calls. We are past COBOL 5 (V6.2 at the moment) > and "CALL variable USING . . . " where "variable" has any of the "national" > characters ($#@) works every time. We have multiple dynamically called > utility subroutines with those characters in the program name. > > Why in the world are you using literal calls? Or are you using the DYNAM > option to convert literal calls to dynamic ones? If so, bite the bullet - > convert them to "CALL variable" and you are done. > > The only legitimate case I have seen for using literal CALL's is when you > are using nested subroutine programs in the same source file as the calling > program. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Frank Swarbrick > Sent: Friday, April 7, 2023 6:07 PM > To: [email protected] > Subject: Cobol calling module with non alphanumeric no longer allowed??? > > I've tried calling modules (that exist!) with both '@' and '#' signs in > them and Enterprise COBOL 5+ does not allow this. COBOL 4 allowed this. > Is there any good reason why this is the case? > -- > > 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 > > ---------------------------------------------------------------------- > 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
