|
View previous topic :: View next topic
|
| Author |
Message |
pav001
New User
Joined: 02 Nov 2005
Posts: 24
|
|
|
|
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 |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Pardon my stupidity, but IKJEFT01 is tso batch?  
My signature line should be something like:
Jeez, I still learning.... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Yup, that would be true 
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 |
|
|
pav001
New User
Joined: 02 Nov 2005
Posts: 24
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 ) |
|
| Back to top |
|
|
senthilssg
New User
Joined: 09 Dec 2005
Posts: 64
Location: USA
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello Senthil,
Thank you for the info |
|
| Back to top |
|
|
vini_srcna
Active User
Joined: 26 May 2005
Posts: 178
Location: Copenhagen, Denmark
|
|
|
|
| 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 |
|
|
senthilssg
New User
Joined: 09 Dec 2005
Posts: 64
Location: USA
|
|
|
|
Hi Vinay ,
Db2 system is not active due to scheduled maintanance or some other reasons .
Regards
Senthil K |
|
| Back to top |
|
|
|
|
