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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> 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
