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 < [email protected]> 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 <[email protected]> On Behalf > Of Steve Thompson > Sent: Sunday, April 9, 2023 4:14 PM > To: [email protected] > 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 <[email protected]> On > > Behalf Of Steve Thompson > > Sent: Sunday, April 9, 2023 2:16 PM > > To: [email protected] > > 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 <[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 > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
