Calling an IMS/DB2 program in COBOL

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

I'm calling an IMS/DB2 program in a plain COBOL program. I'm passing the Working Storage variables through Linkage Section to the IMS and DB2 program but I'm unable to refer any of the variables. More over I'm getting a S0C4 error when I try to do the same. They are all in correct order.

Can any one please clarify and provide a work around?

guptae · Posted: Wed Jan 18, 2006 3:03 pm

could u please send us the code of linkage section of calling program & as well as procedure division using phrase of called program.

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Calling program Work area.

+10 01 TCSCB00-REC.
+10 COPY TCSCB001 REPLACING ==:TCSCB001:== BY ==TCSCB002==.
+10 01 LAST-RUN-DTE PIC X(8) VALUE SPACES.
+10 01 REPORT-INDICATOR PIC X(1) VALUE SPACES.
+00
+00 01 BATCH-COMMAREA.
+05 COPY TCS277CB REPLACING ==:CB:== BY ==CB==.

Calling program Likage Section - Note: It's an IMS/DB2 program

+10 LINKAGE SECTION.
+10
+11 *01 BATCHPCB-MASK.
+10 COPY BATCHPCB.

Called program Linkage Section.

+00 LINKAGE SECTION.
+00
+41 01 TCSCB00-REC.
+41 COPY TCSCB001 REPLACING ==:TCSCB001:== BY ==TCSCB002==.
+41 01 LAST-RUN-DTE PIC X(8).
+41 01 REPORT-INDICATOR PIC X(1).
+00 01 BATCH-COMMAREA.
+41 COPY TCS277CB REPLACING ==:CB:== BY ==CB==.
+37 *01 BATCHPCB-MASK.
+36 COPY BATCHPCB.

Called program Procedure Division.

%+48 PROCEDURE DIVISION USING TCSCB00-REC, LAST-RUN-DTE,
%+48 REPORT-INDICATOR, BATCH-COMMAREA, PCB1-MASK.

Hope you got the required information. Let me know if you need more info.

guptae · Posted: Wed Jan 18, 2006 5:04 pm

Could u provide me calling statement to call subprogram.

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Please find the calling statesment

CALL WS-TBSI0017 USING TCSCB00-REC, LAST-RUN-DTE,
REPORT-INDICATOR, BATCH-COMMAREA, PCB1-MASK.

DavidatK · Posted: Thu Jan 19, 2006 12:28 am

Arulsatish,

You say you are calling a DB2/IMS subroutine from a ?plain? cobol program? You cannot do this. You must compile the ?plain? cobol program as a DB2 program, even though there are no ?EXEC SQL? statements in it, and I believe the same for IMS (I don?t do much in IMS). This may be some of the problems you are experiencing?

Let us know the solution,
Dave

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Dave,
Thanks for your input.
We have indeed compiled the plain COBOL as a DB2 program only.
If you find any solutions please let us know.

DavidatK · Posted: Thu Jan 19, 2006 8:02 pm

arulsatish,

Another thing to check is if the subroutine is in an accessable library. Maybe you need to add //steplib to pick up the subroutine?

Good luck,
Dave

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Dave,
Thank you once again. The call is a static call i.e stand alone executable program.

Thanks,
M Arul Satish

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Dave,
I just forgot to add a piece of info. Infact we are getting into the called program but we are unable to access the likage section variables and getting S0C4 error from the called program.

Bitneuker · Posted: Thu Jan 19, 2006 9:15 pm

This might be a link problem. Did you in your link insert INCLUDE IMS(DFSLI000) in order to tell the system it's dealing with an IMS program? It also might be caused by conflicting parameters.

Cheers,

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

George,
I'm using the utility DFSRRC00 for IMS. I'm not sure whether I still have to INCLUDE IMS(DFSLI000).

Please clarify.

Bitneuker · Posted: Fri Jan 20, 2006 3:36 pm

arulsatish,

DFSRRC00 in fact is IMS. Here's a snapshot of the JCL of one of our regions.
XXREGION EXEC PGM=DFSRRC00,REGION=&RGN,
XX PARM=(MSG,&CL1&CL2&CL3&CL4,
XX &OPT&OVLA&SPIE&VALCK&TLIM&PCB,
XX &PRLD,&STIMER,&SOD,&DBLDL,&NBA,
XX &OBA,&IMSID,&AGN,&VSFX,&VFREE,
XX &SSM)
XX*
IEFC653I SUBSTITUTION JCL - PGM=DFSRRC00,REGION=0M,PARM=(MSG,117000000

This is a part of one of our batchjobs:

//STEP01 EXEC PGM=DFSRRC00,REGION=0M,
// PARM='DLI,DSNMTV01,program,40,00'
//STEPLIB DD DSN=xxxxxxx.x.xxxxxx,DISP=SHR
//IMS DD DSN=xxxxx.xxxxx.PSBLIB,
// DISP=SHR
// DD DSN=xxxxx.xxxxx.DBDLIB,
// DISP=SHR
//DFSVSAMP DD *

Finally the link of one of our batch programs:

//LINKE01 EXEC xxxxx,
// INFILE='xxxxxx.xxxxxxx.OBJ(xxxxxx)',
// OUTFILE='xxxxxx.xxxxxxx.LOAD(xxxxxx)'
//PLKED.SYSIN2 DD *
//LKED.SYSIN DD *
INCLUDE IMS(DFSLI000)
ENTRY CEESTART
NAME xxxxxx(R)

and the link of an MPP (online) program:

//LINKE00 EXEC xxxxx,
// INFILE='xxxxxx.xxxxxxx.OBJ(xxxxx)',
// OUTFILE='xxxxxx.xxxxxxx.LOAD(xxxxx)'
//PLKED.SYSIN2 DD *
//LKED.SYSIN DD *
INCLUDE IMS(DFSLI000)
ENTRY CEESTART
NAME xxxxx(R)

I suggest you give it a try. BTW: our programs are in PL/1.

Cheers,

DavidatK · Posted: Tue Jan 24, 2006 12:10 am

arulsatish,

Have you any resolution for your problem yet. Without being closer to the problem, I don't have any other ideas, but I am interested in what the problem was.

Dave,

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Dave,
At the moment we are doing a work around - running the programs seperately. But we yet to find what the problem is. I'll update you once we find out.

Thank you for your concerns...

Regards,
M Arul Satish.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

As I recall, when I went to school they taught us that the CALLing pgm used WS fields to pass and receive data to/from the CALLed pgm which, in turn, used the fields defined in its LS to access that data.

Give it a try.

arulsatish · New User Joined: 16 Jan 2006 Posts: 12

Hi Guys,
The problem is solved. Actually it happened in Endevor. The processor group was not updated properly.

Thanks for your support.

M Arul Satish