IBM Mainframe Forum

Hello!

I'm trying to issue a dynamic call to another program in CICS

Program A issues command:

Inside program B:

I see thet che B program is called in the Debug tool and the code of program B is shown to me.
However, the program B's fields are not allocated and the program abends on the first try to access fields.

Is there anything special it has to be done? Like, compiling options? We have never used a dynamic call on CICS in our shop.

Thank you!

However, the program B's fields are not allocated and the program abends on the first try to access fields.

Well, then look at why it abends, you get messages that tell you a lot if you look them up. And if you do not post the information about what happened (output, messages) nobody can guess what happened.

Have you looked at your compile listing for B? Has it perhaps been "translated" as a CICS program, so that your B-AREA is the third item on the PROCEDURE DIVISION USING?

mongan wrote:

However, the program B's fields are not allocated and the program abends on the first try to access fields.

Well, then look at why it abends, you get messages that tell you a lot if you look them up. And if you do not post the information about what happened (output, messages) nobody can guess what happened.

mongan, I have looked it up. And I see what is wrong in the debug tool. Commarea is not allocated. Otherwise, the abend is:

APC2
Explanation: An illegal branch has been attempted by a Language Environment user program following an abend condition with an active handle label abend. Usually an Out-Of-Block GOTO will have resulted, implying that the program tried to branch to, for example, an inactive block. System Action: The transaction is abnormally terminated and the program is disabled. User Response: Use the dump and trace to determine the cause of the error and amend the GOTO in error.
Module: DFHAPLI

and ofcourse it abends as it tries to reference a field that is not allocated.

BillyBoyo wrote:Have you looked at your compile listing for B? Has it perhaps been "translated" as a CICS program, so that your B-AREA is the third item on the PROCEDURE DIVISION USING?

Hello, BillyBoyo!

I've looked at the listing and it has only one item after USING and it's the samo as in source program.
AMODE and RMODE are the same for my wannabe module as for all other programs in the application. I have no idea what could be wrong..
Do i need to set something in language environment? Do I need differet compile options? Do I need to define program in CICS (it's auto load as all the rest) ?

I did a quick google earlier before posting my previous. I'm pretty sure it says you have to define it to CICS, though I didn't register the details.

I think the search was something like CICS DYNAMIC CALL, maybe with the word Cobol as well. What I found, from IBM, should give you the information or information about where to find the information. 'S'all I know, sorry.

And I see what is wrong in the debug tool. Commarea is not allocated.

You say the Commarea is not allocated, but there shoudnt be any, because the program is a "normal" COBOL-program, not a CICS-program, and this is what Billy just asked.
Why do you say "Commarea is not allocated" ?
I would change the Call to an EXEC CICS LINK, and make the called program a CICS-program (Translated) and just have a test.

I had a quick look at a manual, and the link is here: http://publib.boulder.ibm.com/infocente ... fhp3p9.htm

I did a test with the dynamic call. Without defining the program in the CSD, I got a U4038 abend. I dont have the debug-tool installed so I could see the detail.
After that I defined the program in the CSD , and it works fine.
FYI.

Yep, that's the link I used earlier.

CSD not needed if using autoinstall. Otherwise is. Well, Mandor?

The 4038 vs a disguised CICS abend might be pointing to a "clash" of abend-handlers in some way. The abend message (which might not be correct) seems to be something going awry "after" and abend.

Usually an Out-Of-Block GOTO will have resulted, implying that the program tried to branch to, for example, an inactive block.

Not the usual sort of stuff you'd know how to go about in a Cobol program, is it?

The advice is to use the dump and trace, but to amend the GO TO that you'd not know how to do.

Try, as Monitor suggested, with XCTL - just to see if it works, it narrows down where to look. If the XCTL works, force an abend in the module and see what happens.

Are you using a site-specific abend-handler from the CICS programs?

If all avenues fail fairly quickly, get someone who knows a CICS dump to look into it. Let us know, anyway. Could help someone else (and we learn something).