View previous topic :: View next topic
|
Author |
Message |
Sayan Bhattacharyya
New User
Joined: 27 Jul 2014 Posts: 7 Location: India
|
|
|
|
Hello,
We are trying to dynamically call a subroutine belonging to a different system from a cobol program that is ultimately getting executed in CICS environment in our native application.
The called subprogram has no CICS statements in it.It connects to a UDB and runs a stored proc to retrieve data from a remote database.it is compiled with no-dynam option.It has NOT been translated.
The CICS job is currently failing with a protection exception;S0C4, and an ASRA abend is displayed on the CICS screen.
Upon further investigation,it was found that the call chain fails while calling DSNHLI.
Could any one please suggest if this is because the called subroutine is using default addressing parameters( 24-bit addressing) and the passed parameters are above the 16MB line;or there might be some other issue.
To test out the above theory i removed the Amode,Rmode parms from the calling program but the CICS job is still abending with the protection exception.
Please let me know your thoughts on this.
Much obliged. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
|
|
Check if DSNHLI is present in both CICS and DB2 libs and try flip flop this in steplibs as such types of errors are tough to guess. If it is brand new program then suggest you to look for all possible basic causes of S0C4.
Also as said, A 31-bit program calls a 24-bit program and passes data that the subroutine cannot access could possibly also be the cause so you may try removing AMODE(31), RMODE(ANY). |
|
Back to top |
|
|
Sayan Bhattacharyya
New User
Joined: 27 Jul 2014 Posts: 7 Location: India
|
|
|
|
Hi Rohit,
Thanks for looking into it.As i had already mentioned that i have removed the addressing and residency parms from the calling program and still receiving the same error; i am guessing its not one of the issues.
Also the CICS DFHRPL concatenation has the CICS version of DSNHLI stub, DSNCLI from within CICS library SDFHLOAD. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009 Posts: 63 Location: hyderabad
|
|
|
|
Hi Sayan.. Years back i faced similar issues when calling a non cics pgm from cics.
Could you have a look into tis one.
ibmmainframes.com/about5154.html
I tried using DFHEIBLK along with other parameters passed in the linkage section in both the called and calling program respectively and it helped me.
Just a try once. |
|
Back to top |
|
|
Sayan Bhattacharyya
New User
Joined: 27 Jul 2014 Posts: 7 Location: India
|
|
|
|
Hi Rick,
Thank you for looking into this.Since the called program is not cics translated,
i donot think there is a necessity to use DFHEIBLK DFHCOMMAREA in the linkage.
If the called program was CICS translated,then these would be inserted automatically in the PD by the CICS translator and similar dummy linkages could have been used to compensate for them in the calling program.
Just tell me this,was inserting those sufficient to solve your problem?Also did you call the subroutine statically or dynamically?And was it a cobol call or a CICS link. |
|
Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009 Posts: 63 Location: hyderabad
|
|
|
|
Hi Sayan..i agree to what u told. As far as i remeber in my scenerio, it was a static call. Yes, explicitly writing the DFHEIBLK along with commarea solved my problem. |
|
Back to top |
|
|
Sayan Bhattacharyya
New User
Joined: 27 Jul 2014 Posts: 7 Location: India
|
|
|
|
Thanks Wrick(apologies for the misspelling it the first time around).
In your particular case,were you suing a tool like an Endeavor or Change-man,where the called subroutine was an online specific Source library type,due to which it was expecting the extra linkages ?
Also ,just to be clear,the called subrotine had no CICS statements in it right? |
|
Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009 Posts: 63 Location: hyderabad
|
|
|
|
Hi..yes, the called sub program had no CICS statements in it. We used Panvalet that time..and there was nothing online specific as far as i remember. We faced this issue while LE conversion of the existing modules..the sub module being called statically was getting compiled/linked using the same compiler(the proc that was used for cics pgms).. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
|
|
SB, Are you compliant with the calling Rules as given above? if there is no CICS in the called module then DFHEIBLK DFHCOMMAREA isn't must. |
|
Back to top |
|
|
Sayan Bhattacharyya
New User
Joined: 27 Jul 2014 Posts: 7 Location: India
|
|
|
|
Hi,
Finally we were successful in calling the module.We passed the subroutine through the CICS translator which inserted the DFHEIBLK DFHCOMMAREA into the PD of the called subroutine.To compensate for the extra linkages,we created a couple of dummy linkages in the calling module which is working fine and the call was successful. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
Back to top |
|
|
|