Can a COBOL batch program CALL to COBOL batch db2 program?

[Zalek Bloom]

Actually I would like to know what additional JCL I will need if a
COBOL non-DB2 program is calling to a COBOL/DB2 program. The original
non-DB2 program is executed using:
//STEP1 EXEC PGM=PROG1

I know I have to supply database name/plan to my program, but how?

Another question: what happens is the PROG1 program is a DB2 program
and is calling to another DB2 program with a different database and a
different plan?
What kind of JCL I need then? Do I need a special BIND?

Thanks,

Zalek

[Don Leahy]

"Zalek Bloom" <za********@hot mail.com> wrote in message
news:e8******** *************** ***@posting.goo gle.com...

Actually I would like to know what additional JCL I will need if a
COBOL non-DB2 program is calling to a COBOL/DB2 program. The original
non-DB2 program is executed using:
//STEP1 EXEC PGM=PROG1

I know I have to supply database name/plan to my program, but how?

Another question: what happens is the PROG1 program is a DB2 program
and is calling to another DB2 program with a different database and a
different plan?
What kind of JCL I need then? Do I need a special BIND?

Thanks,

Zalek

If the DB2 program uses Call Attach, then you don't have to do anything to
your JCL. However, Call Attach programs are uncommon, so it is far more
likely that you will have to change your JCL to run PROG1 under TSO attach
via program IKJEFT01. The JCL would resemble something like:

//STEP1 EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=yo ur.DB2.load.lib
//SYSTSIN DD *
DSN SYS(db2 subsystem name)
RUN PROGRAM(PROG1) LIB(your.applic ation.load.lib) PLAN(your plan name)
PARM(if required)
END

[Paul Vader]

za********@hotm ail.com (Zalek Bloom) writes:

Actually I would like to know what additional JCL I will need if a
COBOL non-DB2 program is calling to a COBOL/DB2 program. The original
non-DB2 program is executed using:
//STEP1 EXEC PGM=PROG1

I know I have to supply database name/plan to my program, but how?

It doesn't really matter whether the calling or called COBOL program is the
one using DB2 - the critical point is establishing the connection to DB2.
And there's at least two ways to do this:

- The most common is to run the program under the control of tso batch,
using the DSN command. This means you will have to change your JCL to
run program IKJEFT01 instead of your application program's name, add some
extra DDs like SYSTSIN, and you'll also (assuming you use procs, which is
a fairly safe assumption) need to maintain a control card library
containing the invocation commands for your application program.
Alternatively, you could somewhat do away with that last part by writing a
generic CLIST/exec which would do the necessary allocations and
executions for you, and then you could put the program name into a parm,
something like this:

//CLIST EXEC PGM=IKJEFT01,PA RM='%DB2ALC &DB2ID PROGRAM &PARMS'

DB2ALC would consist of a couple alloc statements and a DSN command.
pretty simple.

- The other, and I think superior, way to do it is by linking the call attach
facility into your code (module DSNALI). In that case, the JCL will stay
just like it is (with the possible exception of adding SDSNLOAD to your
steplib), and the connection will happen automatically, using a plan
name equal to the CSECT name first accessing DB2, and the database name
defined in the plan. If you don't have to do anything particularly fancy
to get a DB2 program to run, and you've standardized your plans to be
your program names (which is pretty sensible), I would go with this
method. *

P.S. If you're mixing, IMS with DB2, the CAF or TSO process isn't needed
at all, it's built into the IMS invocation. You could, if you were a
little wacky, do all your programs as IMS-controlled. There's even a
neat feature (the RTT) which would let you use any plan or package
that you like.
--
* PV something like badgers--something like lizards--and something
like corkscrews.