On Fri, Aug 5, 2016 at 10:57 AM, Frank Swarbrick < [email protected]> wrote:
> To the OP, why is it so important that ENTRY be used? Would two > (non-nested) programs in the same source member be enough? i.e. a single > source member containing two programs like this? > > PROCESS NAME > ID DIVISION. > PROGRAM-ID. MAINPROG. > END PROGRAM MAINPROG. > PROCESS NAME > ID DIVISION. > PROGRAM-ID. CONDHDLR. > END PROGRAM CONDHDLR. > > > Personally, I think that COBOL should have a "package" structure like PL/I > has had for a while... > I'm going to take a wild guess that the "problem" with two programs, which link into to separate program object in the library, is that it would violate shop standards. I.e. "Only one program per source member." Most likely along with the rule that the PDS (or file name) must exactly match the name of the program (in the PROGRAM-ID.) and the name under which it is bound/linked to "tracking purposes". There are a lot of "rules" of this nature to make managing a large environment easier and require less intelligence, work, and creativity. Creativity is for artsy people. We are engineers! (last statements are a bit tongue-in-cheek - and it's very difficult to talk doing that!) > > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Bill Woodger <[email protected]> > Sent: Friday, August 5, 2016 9:13 AM > To: [email protected] > Subject: Another COBOL question > > I've already posted that for a dynamic CALL you are supposed to CANCEL the > "main" program before using the ENTRY program. > > If there is nothing in the ENTRY program which relies on WORKING-STORAGE > or LOCAL-STORAGE in the "main" program, you may ordinarily "get away with > it", even though the lack of relationship would usually obviate the use of > the ENTRY. > > I think you meant that the the LE handler *can't* be in a contained/nested > program. Because it can't. > > What that all means exactly for your handler, I don't know. I'd never have > thought to try to make the handler an ENTRY. > > The SET ... ENTRY will cause the handler (ALIAS) to be loaded as an > entirely separate executable. I can't say that that wouldn't or shouldn't > work, but it doesn't seem to. > > I think the abend you are getting is from LE attempting to locate/use the > handler. > > I don't know if the nested/contained not working is a hint that the ENTRY > won't work either. > > IBM do not recommend using an ENTRY full-stop. > > I'd use the two-program approach. It may be interesting to establish > exactly why it doesn't work with the ENTRY, but only interesting, not so > useful generally. > > ---------------------------------------------------------------------- > 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 > -- Klein bottle for rent -- inquire within. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
