Introducing Commits to batch programs - Best Approach?

Div Grad · New User Joined: 08 Apr 2005 Posts: 45

I'm in a shop where almost all batch DB2 programs do not use COMMITs. If a job abends it is just restarted from the top as everything rolls back.

This is starting to cause issues with locks in our acceptance test region (for obvious reasons). We're starting a project to introduce the use of COMMITs within our batch jobs and begin retrofitting our biggest offenders. First step is to define a common approach to use against all programs.

What kinds of options are available to consider. I'm no expert in this area but my first thoughts are:

- each job to have a commit frequency controlled via an input card of some type to allow for fine tuning (via either flat file or DB2 table)
- after each commit write out to a flat file the position for restarting

Beyond that I don't know much. Now some jobs can commit and just restart from the top (say if deleting old records) while others may be more tricky depending if they are looping over an input file or cursor or whatever.

Any advice on this? Maybe sometimes a program should be rewritten to allow for easier restart? Different ways to handle cursors vs input files to process?

Any advice appreciated or even a reference to a good article to read as background.

Rohit Umarjikar · Posted: Tue Apr 07, 2015 8:32 pm

Div,

Please have a look at this thread and the attachment, that would give your clear concept also you do not need to write a record to any file after commit and all that repositioning of a file can be found here.

ibmmainframes.com/about7691.html

Div Grad · New User Joined: 08 Apr 2005 Posts: 45

Thanks very much for the fast reply! I'll read that attachment now. Hopefully it will help me from re-inventing the wheel.

trushant.w · Posted: Wed Jun 10, 2015 11:17 am

Rohit Umarjikar · Posted: Thu Jun 11, 2015 5:21 am

The rollback process is determined by how long a unit of work has been
running. If you never commit in a batch job, you will always rollback to
the beginning of the job (unit of work). This is not a good programming
technique if you have long running jobs from both a programming perspective and DB2 resource perspective.

It is always a good practice to add Rollback after any fatal error to avoid surprises.

and also who cares if you are restarting from top as it will anyways process all the records which then reduces the performance of the application and the downtime.

enrico-sorichetti · Posted: Thu Jun 11, 2015 2:51 pm

the only thing that could become murky
is the process to reposition the output PS datasets

for large PS it could become a performance problem

better to write a program ( assembler unfortunately ) to write an end of file after having counted the number of records to skip.

vickey_dw · New User Joined: 10 Jun 2015 Posts: 51 Location: India

Hi Experts

I have one question in this topic.

If in Step3 of job my cobol-Db2 program is executing where there is no commit and this step is executed successfully.

But after this step in step4 my job got abended.

In this case will the records updated/deleted by program in step3 will be commited or rolbacked ?

RahulG31 · Active User Joined: 20 Dec 2014 Posts: 446 Location: USA

Your changes from Step3 will be committed.

Usually, the program in Step3 will end with a STOP RUN. A Stop run stops the unit of work and returns control to the operating system. And when the control is returned to the OS after a successful execution, the changes in DB2 are committed.

.

vickey_dw · New User Joined: 10 Jun 2015 Posts: 51 Location: India

Thanks Rahul G for detail explanation.

Marso · Posted: Sat Jun 27, 2015 9:31 am

I knew I had to say this long ago:

Div Grad · New User Joined: 08 Apr 2005 Posts: 45

Let me clarify my original post:

If the job abends in the step with the DB2 updates then all those updates roll back since there has been no explicit commit. The job is then restarted from top because the job steps have been structured so as to allow a restart from the top.