The wherefores of using a main program and an ENTRY versus 2 programs is a political battle I am not prepared or willing to fight. When initially assigned this project I was hoping that my Systems status within the company would grant me some carte blanche in how I engineered the solution but, alas, I was mistaken.
Suffice it to say, until/unless I find a technical problem to warrant the multiple program construct, or even the multiple programs per member construct, I am stuck with using the COBOL language verbs as they have been engineered. If, and when, they fail to function, I will have the ammunition I need to push for one of the other programming constructs. I do appreciate all of your narratives of what was occurring. Chuck Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 [email protected] | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Wednesday, August 10, 2016 6:50 AM To: [email protected] Subject: How does COBOL detect a recursive call? Hi Chuck, Thanks. Yes, I was able to recreate the issue after making the post with the questions in. RENT,REUS or REUS or RENT, ie any combinaton, on the linkediting/bindering causes no new executable to be loaeded in this case, so tha ALIASed ENTRY is in the same executable as the CALL. This causes COBOL to notice that the program has been entered again, before control has left the program (entered a subsequent time, prior to a GOBACK). This causes the IGZ0064S message to be attempted, which causes the handler (ENTRY) to be entered again, which causes (attempts) the IGZ message again, until LE reaches its defined limit for the number of "nested" conditions it is supposed to be able to deal with (user option). Making the program RECURSIVE (PROGR-ID. xxxx IS RECURSIVE) effectively removes the COBOL check that the program has been subsequently re-entered before a GOBACK has been processed, so that handler is not entered a second time. So, you have a situation which "works", or more than one. Without RENT or REUS on the linkedit/bindering, you should get a new executable for the SET for the ENTRY and not have a problem with IGZ0064S. With RENT or REUS and using PROGRAM-ID .... IS RECURSIVE you should not have a problem, as long as you bear in mind that you are now "sharing" the WORKING-STORAGE, and that there are special-registers which you are not sharing. The IBM-recommended way to use the ENTRY for a dynamic CALL is to use CANCEL for the PROGRAM-ID to be able to use the ENTRY and for the ENTRY to be able to use the PROGRAM-ID (or another ENTRY). You can't do the CANCEL from *within* the program, so that is out. There are at least two ways that a CALL to an ENTRY within the same program *should* be able to be made to work, even though there is no documentation for the CALL to an ENTRY within the same program, and I've never heard of it being done on the Mainframe, those outline above. I'd personally feel exposed with "we can kind of get it working, it is not straightforward to understand, and isn't documented by IBM". Note, I've reproduced with an "ordinary" CALL to a an ENTRY, not with an ENTRY which is established as a handler. I'd do it as two programs, unless there is an absolute, paramount, overriding reason to do it as one program. It is difficult for me to imagine what that reason may be. You currently have the "already needs a CBL/PROCESS/PARM for NAME(ALIAS), now also needs IS RECURSIVE or not to use RENT or REUS on the linkedit/binder". ---------------------------------------------------------------------- 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
