Re: Cobol calling module with non alphanumeric no longer allowed???
Could it be as simple (and as really dumb) as that the national characters ($#@) when "OR"ed with X'40' (the "quick and dirty" way to upper-case EBCDIC letters) don't change their value (they all already have the X'40' bit on)? Or worse, because the "convention" for translating underscore characters in "LONG" member-names has already pre-empted the conversion "_" => "@"? Just speculating, I have no inside knowledge about this restriction. It is odd though. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, April 10, 2023 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Quite odd, I'll say. But at least I have an answer. Thanks! I wonder why LONGUPPER has the restrictions it does. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Ah, I'm compiling with PGMNAME(COMPAT). And I misread the documentation for PGMNAME(LONGUPPER). This behavior is conforming to the documentation. It says that PGMNAME(COMPAT) can contain national characters: "All the characters used in the name must be alphabetic, digits, the hyphen, or the underscore, except that if the program-name is a literal and is in the outermost program, then the literal can also contain the extension characters @, #, and $, and the first character can be an underscore." And that for PGMNAME(LONGMIXED) it can contain any character in the range x'41' - x'FE', But PGMNAME(LONGUPPER) only allows for alphabetic, digits, hyphen, underscore. @, #, $ are not alphabetic. What's interesting is that PGMNAME(COMPAT) says that: If the first character is not alphabetic, and is not an underscore, it is converted as follows: - 1-9 are translated to A-I. - Anything else is translated to J. I think this is a documentation error. You can call literal to a name like '@SESTEST' without conversion, and you can use it as a program id as long as it is in quotes. It is true that it *used to be* that you couldn't have a program-id starting with @. I don't know at what point that restriction was lifted. Maybe with IBM COBOL? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, April 10, 2023 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Interesting. Apparently it works for both PGMNAME(COMPAT) and PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using. 19 001600 procedure division. 20 001610 call '@SEPTEST' EXT ==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid. It was processed as "0SEPTEST". ==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST". 21 001700 goback. Sounds like a bug. Though unlike what I said, E.COBOL v4.2 has the same issue. The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have PGMNAME(LONGUPPER). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of that option. What do you have for FLAGSTD? Can you post the exact compile error? Note that such a program id would need to be enclosed in quotes for that to compile. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Saturday, April 8, 2023 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? 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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 t
Re: Cobol calling module with non alphanumeric no longer allowed???
Quite odd, I'll say. But at least I have an answer. Thanks! I wonder why LONGUPPER has the restrictions it does. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Ah, I'm compiling with PGMNAME(COMPAT). And I misread the documentation for PGMNAME(LONGUPPER). This behavior is conforming to the documentation. It says that PGMNAME(COMPAT) can contain national characters: "All the characters used in the name must be alphabetic, digits, the hyphen, or the underscore, except that if the program-name is a literal and is in the outermost program, then the literal can also contain the extension characters @, #, and $, and the first character can be an underscore." And that for PGMNAME(LONGMIXED) it can contain any character in the range x'41' - x'FE', But PGMNAME(LONGUPPER) only allows for alphabetic, digits, hyphen, underscore. @, #, $ are not alphabetic. What's interesting is that PGMNAME(COMPAT) says that: If the first character is not alphabetic, and is not an underscore, it is converted as follows: - 1-9 are translated to A-I. - Anything else is translated to J. I think this is a documentation error. You can call literal to a name like '@SESTEST' without conversion, and you can use it as a program id as long as it is in quotes. It is true that it *used to be* that you couldn't have a program-id starting with @. I don't know at what point that restriction was lifted. Maybe with IBM COBOL? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, April 10, 2023 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Interesting. Apparently it works for both PGMNAME(COMPAT) and PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using. 19 001600 procedure division. 20 001610 call '@SEPTEST' EXT ==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid. It was processed as "0SEPTEST". ==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST". 21 001700 goback. Sounds like a bug. Though unlike what I said, E.COBOL v4.2 has the same issue. The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have PGMNAME(LONGUPPER). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of that option. What do you have for FLAGSTD? Can you post the exact compile error? Note that such a program id would need to be enclosed in quotes for that to compile. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Saturday, April 8, 2023 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? 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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 inten
Re: Cobol calling module with non alphanumeric no longer allowed???
Ah, I'm compiling with PGMNAME(COMPAT). And I misread the documentation for PGMNAME(LONGUPPER). This behavior is conforming to the documentation. It says that PGMNAME(COMPAT) can contain national characters: "All the characters used in the name must be alphabetic, digits, the hyphen, or the underscore, except that if the program-name is a literal and is in the outermost program, then the literal can also contain the extension characters @, #, and $, and the first character can be an underscore." And that for PGMNAME(LONGMIXED) it can contain any character in the range x'41' - x'FE', But PGMNAME(LONGUPPER) only allows for alphabetic, digits, hyphen, underscore. @, #, $ are not alphabetic. What's interesting is that PGMNAME(COMPAT) says that: If the first character is not alphabetic, and is not an underscore, it is converted as follows: - 1-9 are translated to A-I. - Anything else is translated to J. I think this is a documentation error. You can call literal to a name like '@SESTEST' without conversion, and you can use it as a program id as long as it is in quotes. It is true that it *used to be* that you couldn't have a program-id starting with @. I don't know at what point that restriction was lifted. Maybe with IBM COBOL? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, April 10, 2023 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Interesting. Apparently it works for both PGMNAME(COMPAT) and PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using. 19 001600 procedure division. 20 001610 call '@SEPTEST' EXT ==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid. It was processed as "0SEPTEST". ==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST". 21 001700 goback. Sounds like a bug. Though unlike what I said, E.COBOL v4.2 has the same issue. The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have PGMNAME(LONGUPPER). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of that option. What do you have for FLAGSTD? Can you post the exact compile error? Note that such a program id would need to be enclosed in quotes for that to compile. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Saturday, April 8, 2023 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? 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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 erro
Re: Cobol calling module with non alphanumeric no longer allowed???
Interesting. Apparently it works for both PGMNAME(COMPAT) and PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using. 19 001600 procedure division. 20 001610 call '@SEPTEST' EXT ==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid. It was processed as "0SEPTEST". ==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST". 21 001700 goback. Sounds like a bug. Though unlike what I said, E.COBOL v4.2 has the same issue. The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have PGMNAME(LONGUPPER). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, April 10, 2023 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of that option. What do you have for FLAGSTD? Can you post the exact compile error? Note that such a program id would need to be enclosed in quotes for that to compile. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Saturday, April 8, 2023 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? 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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 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 -- 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
Re: Cobol calling module with non alphanumeric no longer allowed???
I agree that you should be able to do dynamic calls under CICS to any routine, and only the EXEC CICS commands need be static. In fact, even EXEC SQL can do dynamic calls if you define the appropriate entry point (DSNHLI or DSNHLI2, I believe) as a "program". Program auto-install would likely help (though we don't use it ourselves at the moment). Also worth noting that if you use the newish COBOL compiler directive ">>CALLINTERFACE DYNAMIC" you can even use CALL literal to get dynamic calls under CICS. Only EXEC CICS and, I believe, EXEC SQL would remain static calls. (The "dynamic" SQL calls I refer to above are for programs without any EXEC CICS statements, and thus compiled using "batch rules" instead of CICS.) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Sunday, April 9, 2023 12:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? The only CICS routines that MUST be statically linked are the DFH subroutines that are called as the result of coding CICS commands like EXEC CICS LINK or EXEC SQL SELECT. AFAIK, any user-written program can be defined to RDO including those with national characters ($#@) in the name. I am curious, in what case(s) do you believe that a callable subroutine could NOT be definable in RDO? Unless it is for very high frequency user programs where maximum performance is critical, statically linked functional subroutines (under CICS or not) are a maintenance nightmare, because when (not if) those subroutines need to change, whether for new function or for defect repair, EVERY program that statically linked them must be re-linked and (more costly and more critically) MUST be re-tested for quality assurance. And even for high performance requirements, the EXEC CICS LINK (or better, a plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to execute already-loaded subroutines, and if they are being used frequently they are almost surely already loaded in memory. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Sunday, April 9, 2023 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? The other reason for the literal calls is because one wants the load module to have the subroutines statically linked that the COBOL program is using. In this way there is no LOAD done during execution time because COBOL "knows" that these are statically linked. There are a few reasons to want this behavior. The major one that comes to mind is you have to have static linkage for running in a CICS environment because the subroutines are not CICS definable (RDO) and so have to be statically linked. Steve Thompson On 4/8/2023 1:50 AM, Farley, Peter wrote: > 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 On > Behalf Of Frank Swarbrick > Sent: Friday, April 7, 2023 6:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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
Re: Cobol calling module with non alphanumeric no longer allowed???
A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of that option. What do you have for FLAGSTD? Can you post the exact compile error? Note that such a program id would need to be enclosed in quotes for that to compile. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Saturday, April 8, 2023 1:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? 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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
On Fri, 7 Apr 2023 22:07:03 +, Frank Swarbrick wrote: >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? > No. Higher level components should not presume to enforce the rules of lower level components. They should simply attempt the link (in this case) and report any errors returned, just like any unresolved symbol. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
I can see a point whereby you wouldn't use interactive RDO to define resources. We used a change control system to implement CICS resources via batch jobs running DFHCSDUP utility. It gives a better audit trail than using the CEDA transaction. We also used a separate CSD for 14 CICS regions and rolling out a common change meant more work. We also always COLD started CICS so the odd "temporary" install that should have been permanent often went missing. LOL. On Mon, Apr 10, 2023 at 7:48 AM Farley, Peter < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > OK, so this was a shop standard rather than any actual requirement. So > not "cannot be defined to RDO" but "chose not to be allowed to be defined > in RDO by management decision". > > That kind of thing is a deliberate decision to live with the consequences > for some perceived benefit. To each their own. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Steve Thompson > Sent: Sunday, April 9, 2023 4:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol calling module with non alphanumeric no longer > allowed??? > > In the case of a common routine(s) that is (are) statically linked for > Batch and CICS environments. I didn't design the system the customer had, I > just had to be aware of it when I was working on Compile support tools. > > So I thought that this aspect should be considered in this conversation. > > And, yes, if these routines changed, the causing the common > copybook(s) to be changed, that would require a recompile and linkedit of > the batch and CICS sides, QA testing, and then promotion back into > production. So that had to be coordinated across a few application groups > for each program that used one of those "dual" routine programs (dual from > the idea that they were used in both environments). > > Steve Thompson > > On 4/9/2023 2:50 PM, Farley, Peter wrote: > > The only CICS routines that MUST be statically linked are the DFH > subroutines that are called as the result of coding CICS commands like EXEC > CICS LINK or EXEC SQL SELECT. AFAIK, any user-written program can be > defined to RDO including those with national characters ($#@) in the name. > > > > I am curious, in what case(s) do you believe that a callable subroutine > could NOT be definable in RDO? > > > > Unless it is for very high frequency user programs where maximum > performance is critical, statically linked functional subroutines (under > CICS or not) are a maintenance nightmare, because when (not if) those > subroutines need to change, whether for new function or for defect repair, > EVERY program that statically linked them must be re-linked and (more > costly and more critically) MUST be re-tested for quality assurance. > > > > And even for high performance requirements, the EXEC CICS LINK (or > better, a plain COBOL CALL variable-name, even under CICS) has a fairly > efficient path to execute already-loaded subroutines, and if they are being > used frequently they are almost surely already loaded in memory. > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Steve Thompson > > Sent: Sunday, April 9, 2023 2:16 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Cobol calling module with non alphanumeric no longer > allowed??? > > > > The other reason for the literal calls is because one wants the load > module to have the subroutines statically linked that the COBOL program is > using. In this way there is no LOAD done during execution time because > COBOL "knows" that these are statically linked. > > > > There are a few reasons to want this behavior. > > > > The major one that comes to mind is you have to have static linkage for > running in a CICS environment because the subroutines are not CICS > definable (RDO) and so have to be statically linked. > > > > Steve Thompson > > > > On 4/8/2023 1:50 AM, Farley, Peter wrote: > >> 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
Re: Cobol calling module with non alphanumeric no longer allowed???
OK, so this was a shop standard rather than any actual requirement. So not "cannot be defined to RDO" but "chose not to be allowed to be defined in RDO by management decision". That kind of thing is a deliberate decision to live with the consequences for some perceived benefit. To each their own. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Sunday, April 9, 2023 4:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? In the case of a common routine(s) that is (are) statically linked for Batch and CICS environments. I didn't design the system the customer had, I just had to be aware of it when I was working on Compile support tools. So I thought that this aspect should be considered in this conversation. And, yes, if these routines changed, the causing the common copybook(s) to be changed, that would require a recompile and linkedit of the batch and CICS sides, QA testing, and then promotion back into production. So that had to be coordinated across a few application groups for each program that used one of those "dual" routine programs (dual from the idea that they were used in both environments). Steve Thompson On 4/9/2023 2:50 PM, Farley, Peter wrote: > The only CICS routines that MUST be statically linked are the DFH > subroutines that are called as the result of coding CICS commands like EXEC > CICS LINK or EXEC SQL SELECT. AFAIK, any user-written program can be defined > to RDO including those with national characters ($#@) in the name. > > I am curious, in what case(s) do you believe that a callable subroutine could > NOT be definable in RDO? > > Unless it is for very high frequency user programs where maximum performance > is critical, statically linked functional subroutines (under CICS or not) are > a maintenance nightmare, because when (not if) those subroutines need to > change, whether for new function or for defect repair, EVERY program that > statically linked them must be re-linked and (more costly and more > critically) MUST be re-tested for quality assurance. > > And even for high performance requirements, the EXEC CICS LINK (or better, a > plain COBOL CALL variable-name, even under CICS) has a fairly efficient path > to execute already-loaded subroutines, and if they are being used frequently > they are almost surely already loaded in memory. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Steve Thompson > Sent: Sunday, April 9, 2023 2:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? > > The other reason for the literal calls is because one wants the load module > to have the subroutines statically linked that the COBOL program is using. In > this way there is no LOAD done during execution time because COBOL "knows" > that these are statically linked. > > There are a few reasons to want this behavior. > > The major one that comes to mind is you have to have static linkage for > running in a CICS environment because the subroutines are not CICS definable > (RDO) and so have to be statically linked. > > Steve Thompson > > On 4/8/2023 1:50 AM, Farley, Peter wrote: >> 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 On >> Behalf Of Frank Swarbrick >> Sent: Friday, April 7, 2023 6:07 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> 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 th
Re: Cobol calling module with non alphanumeric no longer allowed???
In the case of a common routine(s) that is (are) statically linked for Batch and CICS environments. I didn't design the system the customer had, I just had to be aware of it when I was working on Compile support tools. So I thought that this aspect should be considered in this conversation. And, yes, if these routines changed, the causing the common copybook(s) to be changed, that would require a recompile and linkedit of the batch and CICS sides, QA testing, and then promotion back into production. So that had to be coordinated across a few application groups for each program that used one of those "dual" routine programs (dual from the idea that they were used in both environments). Steve Thompson On 4/9/2023 2:50 PM, Farley, Peter wrote: The only CICS routines that MUST be statically linked are the DFH subroutines that are called as the result of coding CICS commands like EXEC CICS LINK or EXEC SQL SELECT. AFAIK, any user-written program can be defined to RDO including those with national characters ($#@) in the name. I am curious, in what case(s) do you believe that a callable subroutine could NOT be definable in RDO? Unless it is for very high frequency user programs where maximum performance is critical, statically linked functional subroutines (under CICS or not) are a maintenance nightmare, because when (not if) those subroutines need to change, whether for new function or for defect repair, EVERY program that statically linked them must be re-linked and (more costly and more critically) MUST be re-tested for quality assurance. And even for high performance requirements, the EXEC CICS LINK (or better, a plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to execute already-loaded subroutines, and if they are being used frequently they are almost surely already loaded in memory. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Sunday, April 9, 2023 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? The other reason for the literal calls is because one wants the load module to have the subroutines statically linked that the COBOL program is using. In this way there is no LOAD done during execution time because COBOL "knows" that these are statically linked. There are a few reasons to want this behavior. The major one that comes to mind is you have to have static linkage for running in a CICS environment because the subroutines are not CICS definable (RDO) and so have to be statically linked. Steve Thompson On 4/8/2023 1:50 AM, Farley, Peter wrote: 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
The only CICS routines that MUST be statically linked are the DFH subroutines that are called as the result of coding CICS commands like EXEC CICS LINK or EXEC SQL SELECT. AFAIK, any user-written program can be defined to RDO including those with national characters ($#@) in the name. I am curious, in what case(s) do you believe that a callable subroutine could NOT be definable in RDO? Unless it is for very high frequency user programs where maximum performance is critical, statically linked functional subroutines (under CICS or not) are a maintenance nightmare, because when (not if) those subroutines need to change, whether for new function or for defect repair, EVERY program that statically linked them must be re-linked and (more costly and more critically) MUST be re-tested for quality assurance. And even for high performance requirements, the EXEC CICS LINK (or better, a plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to execute already-loaded subroutines, and if they are being used frequently they are almost surely already loaded in memory. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Sunday, April 9, 2023 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? The other reason for the literal calls is because one wants the load module to have the subroutines statically linked that the COBOL program is using. In this way there is no LOAD done during execution time because COBOL "knows" that these are statically linked. There are a few reasons to want this behavior. The major one that comes to mind is you have to have static linkage for running in a CICS environment because the subroutines are not CICS definable (RDO) and so have to be statically linked. Steve Thompson On 4/8/2023 1:50 AM, Farley, Peter wrote: > 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 On > Behalf Of Frank Swarbrick > Sent: Friday, April 7, 2023 6:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
The other reason for the literal calls is because one wants the load module to have the subroutines statically linked that the COBOL program is using. In this way there is no LOAD done during execution time because COBOL "knows" that these are statically linked. There are a few reasons to want this behavior. The major one that comes to mind is you have to have static linkage for running in a CICS environment because the subroutines are not CICS definable (RDO) and so have to be statically linked. Steve Thompson On 4/8/2023 1:50 AM, Farley, Peter wrote: 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 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
Re: Cobol calling module with non alphanumeric no longer allowed???
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 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 on behalf > of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> > Sent: Friday, April 7, 2023 11:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 On Behalf > Of Frank Swarbrick > Sent: Friday, April 7, 2023 6:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
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 on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 11:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 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
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 On Behalf Of Frank Swarbrick Sent: Friday, April 7, 2023 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
Try dataname: XX PROGNAME PIC X(08) VALUE 'progname'.. XX can be 77 or a regular level number. Then, CALL PROGNAME parms... On Fri, Apr 7, 2023, 5:25 PM Frank Swarbrick wrote: > Literal. The compiler flags it as not allowed. > > From: IBM Mainframe Discussion List on behalf > of Charles Hardee > Sent: Friday, April 7, 2023 4:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol calling module with non alphanumeric no longer > allowed??? > > Are you doing a call literal or call dataname? > > On Friday, April 7, 2023, Frank Swarbrick > wrote: > > > 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? > > > > -- > > 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 > > -- > 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
Re: Cobol calling module with non alphanumeric no longer allowed???
Literal. The compiler flags it as not allowed. From: IBM Mainframe Discussion List on behalf of Charles Hardee Sent: Friday, April 7, 2023 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol calling module with non alphanumeric no longer allowed??? Are you doing a call literal or call dataname? On Friday, April 7, 2023, Frank Swarbrick wrote: > 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? > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol calling module with non alphanumeric no longer allowed???
Are you doing a call literal or call dataname? On Friday, April 7, 2023, Frank Swarbrick wrote: > 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? > > -- > 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
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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
