IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Running cobol/db2 batch programs from jcl


IBM Mainframe Forums -> DB2
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
pav001

New User


Joined: 02 Nov 2005
Posts: 24

PostPosted: Fri Mar 30, 2007 2:57 am
Reply with quote

Hi,

I recently joined a new firm. The MF environment is very similar to what i had worked at my previous job. i.e. batch-db2.. but i find one difference..

On the system i had worked before the cobol/db2 programs were run in jcl by directly mentioning the program name in EXEC statement of the jcl followed by the load libraries. The plan we specifed useing a certain dd name that i dont remeber.

In this new system cobol/db2 batch progams are run by passing them in SYSTSIN for IKJEFT01 utility something like this:

RUN PROGRAM(TSD0098) PLAN(MWPLAN) -
LIB('TD.PROD.BTCH.LOAD')

Why is IKJEFT01 being used here? I dont understand why we can not run the program directly.. can anyone help me out here.

TIA!PAV
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Fri Mar 30, 2007 3:06 am
Reply with quote

Hello,

Your new shop standards require the use of IKJEFT01 - IBM does not.

I'd suggest asking one of the DBAs or other senior people why the decision was made.

That choice is site specific - as you've already seen, it is not the rule everywhere.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Mar 30, 2007 4:27 am
Reply with quote

OK Dick, I see that a lot here at the duck (our affectionate term) but I still do not understand why they are executing perfectly good load modules under the "shell" of IKJEFT01?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Fri Mar 30, 2007 5:49 am
Reply with quote

FUD would be my take (Fear, Uncertainty, & Doubt).

I beleive it falls into one of those "we've always done it that way" categories and far too many are too afraid of change. There are also many places that use DB2 with no idea about database administration. If it seems to be working - don't touch it.

From posts in these forums, it also seems to be one of the things taught in certain training centers and asked on interviews. In fact, it may be the preferred answer to "How do you run a DB2 program?" at some places.

I wonder if anyone has measured the difference running inside tso batch versus executing the "perfectly good load module".
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Mar 30, 2007 6:04 am
Reply with quote

Pardon my stupidity, but IKJEFT01 is tso batch? icon_eek.gif icon_question.gif

My signature line should be something like:
Jeez, I still learning....
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Fri Mar 30, 2007 6:45 am
Reply with quote

Yup, that would be true icon_smile.gif

There are also IKJEFT1A and IKJEFT1B which are different entry points and perfom differently. All 3 are tso batch.

This from Superk from about 18 months ago. . .
Quote:
IKJEFT01 is the TSO/E program. You use it whenever you wish to perform a TSO function within a batch job. It allows you to perform any TSO function. For a general list of all TSO functions, type TSO HELP. Additionally, IKJEFT01 allows you to run programs written in TSO/E Command List (CLIST) and/or TSO/E REXX. Optionally, you can also invoke other environments, such as ISPF , allowing you to run ISPF Dialogs in a batch environment.


This from another DB2 site where someone asked about IKJEFT1A and IKJEFT1B and got incomplete/inaccurate answers.

Quote:

Judging by the other two answers you got, I don't think they really
understood your question. The IKJxxx modules are the TSO control programs.

To digress.....

DB2 uses several interfaces, an IMS ( perhaps the best of the lot), a
CICS, CAF ( Call Access Facility), and some more technical ones which
for normal application code interfaces you probably won't need (
Honest!, which is why I don't want to confuse you).
However, the Standard so-called 'Batch' interface , which allows
standalone batch job processing for DB2 is the TSO interface (Time
Sharing option), why IBM decided to do this 20 years ago is a mute point
. It works and is actually not too bad. This is why you run under TSO in
batch using the DB2 DSN control program as a TSO Command interface
program on behalf of DB2.

For the most , nobody really cares how it looks inside ,so long as the
syntax for calling your program under DSN control within TSO is not
limited.

Can you use other choices ? Yes, If you want you can even write your
own. IBM give documentation for restart services. But unless you want to
sell a product that nobody has ever thought about in the last 20 years,
why do that ?

TSO and therefore IKJEFT1A ( or B the so called batch alternative to A),
provide you with a facility to execute outside of your online tso
session, and relieve you of the embarrasment of writing really dubious
SQL calls that would lock up your screen for days on end....
Back to top
View user's profile Send private message
pav001

New User


Joined: 02 Nov 2005
Posts: 24

PostPosted: Fri Mar 30, 2007 11:00 pm
Reply with quote

Hi d.sch,

Thanks, that was very helpful.I asked one of the DBAs, and yes i was told that using IKJEFT is what is mentioned in most of ibm manuals and its been the standard way since.. dont know when.
From the posts after that now i do have some idea of why IKJEFT is used but now confused as to how 'perfectly good load module' works. If they dont run under TSO batch then where do they run.

TIA!PAV
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Sat Mar 31, 2007 12:59 am
Reply with quote

Hello Pav,

As you mentioned in your initial post, they are run by coding EXEC PGM=yourpgm rather than tso/batch.

When tso/batch is executed, it becomes just another submitted batch job. Underneath, your program is executed in the same way it would be if you were in online tso.

If you are able, you might want to call someone at your previous work and ask why they chose to use the load modules directly rather than via tso/batch (if they give reasons, we'd surely like to see them here icon_smile.gif )
Back to top
View user's profile Send private message
senthilssg

New User


Joined: 09 Dec 2005
Posts: 64
Location: USA

PostPosted: Mon Apr 02, 2007 3:14 pm
Reply with quote

Hi All ,

I thing your cobol -Db2 program is using either CAF (Call Attachment Facility ) or RRSAF (Recoverable Resource Services Attachment facility as the attachment facility for its Db2 connection . So no need to mention plan name and Db2 subsystem name in RUNJCL as like RUNJCL for prgogram which is using TSO attachement facility


Code:

//*********************************************************
//* RUNJCL for COBOL -DB2 pgm ( using TSO AF)
//*********************************************************
//SQLSTEP  EXEC PGM=IKJEFT01,DYNAMNBR=30                       
//STEPLIB  DD DSN=DSN810.SDSNLOAD,DISP=SHR                     
//         DD DSN=CEE.SCEERUN,DISP=SHR                         
//SYSTSPRT DD SYSOUT=X                                         
//SYSTSIN  DD *                                                 
 DSN SYSTEM(ssid)                                               
 RUN PROGRAM(pgm-name) PLAN(plan-name) LIB('load-lib-name')     
 END                                                           
//SYSPRINT DD SYSOUT=*   
 


You can execute cobol -db2 program as like running a cobol program .
Because all details about db2 connectivity which are embedded in program itself .

Please refer below Sample Cobol -db2 pgm using RRSAF as attachemnt facility :

Details includes name of DB2 sub system ,plan name ,collection id etc ..


Code:

Sample Cobol -DB2 pgm using RRSAF  :

000100 IDENTIFICATION DIVISION.                                         00010000
000200 PROGRAM-ID. COBCALLR.                                            00020000
000300 ENVIRONMENT DIVISION.                                            00030000
000400 DATA DIVISION.                                                   00040000
000500 WORKING-STORAGE SECTION.                                         00050000
               EXEC SQL INCLUDE SQLCA END-EXEC.                         00060000
      ******************************************************************
      * VARIABLES USED FOR RRSAF
      ******************************************************************
       01 IDFYFN            PIC X(18) VALUE 'IDENTIFY          '.       00120000
       01 SSNM              PIC X(4) VALUE 'DB1T'.                      00130000
       01 RIBTPR            PIC X(4).                                   00140000
       01 EIBPTR            PIC X(4).                                   00150000
       01 TERMECB           PIC X(4).                                   00160000
       01 STARTECB          PIC S9(9) VALUE 0 .                         00170000
       01 RETCODE           PIC S9(9) VALUE 0 .                         00180000
       01 REASCODE          PIC S9(9) VALUE 0 .                         00190000
       01 SIGNONFUNC        PIC X(18) VALUE 'SIGNON            '.       00200000
       01 CREATETHREADFUNC  PIC X(18) VALUE 'CREATE THREAD     '.       00210000
       01 CORRID            PIC X(12).                                  00220000
       01 ACCTTKN           PIC X(22).                                  00230000
       01 ACCTINT           PIC X(6).                                   00240000
       01 COLLID            PIC X(18).                                  00250000
       01 REUSE             PIC X(8) VALUE 'RESET  '.                   00260000
       01 PLAN              PIC X(8) VALUE 'PLAN01 '.                  00270000
      ******************************************************************
      * VARIABLES USED FOR APPLICATION
      ******************************************************************
       01 WS-EMPID        PIC X(6).
       LINKAGE SECTION.                                                 00280000
       01 WS-EMPNAME             PIC X(10).                             00281000
       PROCEDURE DIVISION USING WS-EMPNAME.                             00291000
      ******************************************************************
      *               MAKING  RRSAF CONNECTION
      ******************************************************************
      *                IDENTIFY
      ******************************************************************
           CALL 'DSNRLI' USING IDFYFN SSNM RIBTPR EIBPTR TERMECB        00300000
               STARTECB RETCODE REASCODE.                               00310000
             DISPLAY 'IDENTIFY-RETCODE ' RETCODE.                       00320000
             DISPLAY 'IDENTIFY-REASCODE' REASCODE.                      00330000
      ******************************************************************
      *                SIGNON
      ******************************************************************
           CALL 'DSNRLI' USING SIGNONFUNC CORRID ACCTTKN ACCTINT        00340000
              RETCODE REASCODE.                                         00350000
             DISPLAY 'SIGNON-RETCODE ' RETCODE.                         00360000
             DISPLAY 'SIGNON-REASCODE' REASCODE.                        00370000
      ******************************************************************
      *                CREATE THREAD
      ******************************************************************
           CALL 'DSNRLI' USING CREATETHREADFUNC PLAN COLLID REUSE       00380000
              RETCODE REASCODE.                                         00390000
             DISPLAY 'THREAD-RETCODE ' RETCODE.                         00400000
             DISPLAY 'THREAD-REASCODE' REASCODE.                        00410000
      ******************************************************************
      *            CALLING COBOL DB2 STORED PROCEDURE
      ******************************************************************
              MOVE '10000' TO WS-EMPID.                                 00411000
              EXEC SQL                                                  00412000
                CALL COBPROC(:WS-EMPID,:WS-EMPNAME)                     00413000
              END-EXEC.                                                 00414000
              DISPLAY 'I AM IN CALLER'.                                 00415000
              DISPLAY 'EMPID: 'WS-EMPID.                                00416000
              DISPLAY 'EMPNAME :' WS-EMPNAME.                           00417000
              IF SQLCODE = 0                                            00418000
              DISPLAY 'CALL SUCCESSFUL'.                                00419000
              DISPLAY 'SQLCA :' SQLCA.                                  00419100
              STOP RUN.                                                 00419200
      *CALL 'DSNRLI' USING TERMINATETHREADFUNC,&RETURN_CODE,&REASON_CODE00470000
      *CALL 'DSNRLI' USING TERMINATEIDENTIFYFUNC, &RETURN_CODE,&REASON_C00480000
              STOP RUN.                                                 00490000



Run JCl for above cobol -db2 pgm look like this :

Code:

//STEP1 EXEC PGM=DB2SAMP                                         
//STEPLIB DD DISP=SHR,DSN=you-load ?library
//         DD DISP=SHR,DSN=DSN810.SDSNEXIT                       
//         DD DISP=SHR,DSN=DSN810.SDSNLOAD                       
//         DD DISP=SHR,DSN=CEE.SCEERUN                           
//SYSPRINT DD SYSOUT=*                                           
//SYSOUT   DD SYSOUT=*                                       
 


Reasons for using CAF /RRASF other than TSO Attachment facilty :

1. Entire program is not dependent on availability of Db2 subsystem .
If you are using TSO attachement facility ( which is mentioned earlier like DSN (ssid) ...) , entire program should be depenent on DB2 system . if DB2 is not up , u can t able to execute your program .

2.If your cobol -DB2 program have access to non -db2 resorces such as VSAM etc ,then you need to use RRS for taking care of recovery of non DB2 resources .

3 .If you are planning to prepare and execute Db2 external procedure , Eg(Db2 stored procedure wriiten in COBOL ) then you will have to go with RRASF not TSO attachemnt facility.

Hope this help you

Thanks and Regards
Senthil
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Mon Apr 02, 2007 7:24 pm
Reply with quote

Hello Senthil,

Thank you for the info icon_smile.gif
Back to top
View user's profile Send private message
vini_srcna

Active User


Joined: 26 May 2005
Posts: 178
Location: Copenhagen, Denmark

PostPosted: Mon Apr 02, 2007 8:13 pm
Reply with quote

Quote:
Reasons for using CAF /RRASF other than TSO Attachment facilty :

1. Entire program is not dependent on availability of Db2 subsystem .
If you are using TSO attachement facility ( which is mentioned earlier like DSN (ssid) ...) , entire program should be depenent on DB2 system . if DB2 is not up , u can t able to execute your program .


What if DB2 is down..?
Back to top
View user's profile Send private message
senthilssg

New User


Joined: 09 Dec 2005
Posts: 64
Location: USA

PostPosted: Tue Apr 03, 2007 9:34 am
Reply with quote

Hi Vinay ,

Db2 system is not active due to scheduled maintanance or some other reasons .


Regards
Senthil K
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DB2

 


Similar Topics
Topic Forum Replies
No new posts MacKinney Batch to CICS upgrade causi... CICS 7
No new posts Run rexx in batch job CLIST & REXX 7
No new posts Excuting store procedure via JCL batch JCL & VSAM 1
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
Search our Forums:

Back to Top