View previous topic :: View next topic |
Author |
Message |
Ramkumarinfo Beginner
Joined: 06 Jun 2007 Posts: 5 Topics: 3
|
Posted: Thu Jun 07, 2007 2:11 am Post subject: closing and reopening of datasets in a batch program |
|
|
Hi,
I am new to the mainframe environment. As I was reading
the batch programs I noticed that before explicitly commiting data to db2 tables,
All the datasets are closed and re-opended after the commit.
Can anybody explain why the datasets need to be closed before an
explicit commit in batch programs?
Thanks and Regards,
Ram |
|
Back to top |
|
|
dbzTHEdinosauer Supermod
Joined: 20 Oct 2006 Posts: 1411 Topics: 26 Location: germany
|
Posted: Thu Jun 07, 2007 4:34 am Post subject: |
|
|
Ramkumarinfo,
Back in the days the stability of operating systems required (not required, if you did not want to spend all night trying to restart!) this behaviour.
reason: Dataset reading/writing is mostly done in the buffer, only when the buffers are full is data written to DASD. Earlier releases of operating systems software could not guarantee a flush of the buffers to DASD after an ABEND in the run-unit. Thus, restart was a pain, because the DB2 and the qsam/vsam did not match (something had been left in the buffer).
I personnally do not close/reopen with a commit, mainly because the sites that I work at have up-to-date/state-of-the-art operating systems and such silliness as losing stuff in the buffer does not happen.
but, if that is the shop standard, I would follow it! _________________ Dick Brenholtz
American living in Varel, Germany |
|
Back to top |
|
|
Ramkumarinfo Beginner
Joined: 06 Jun 2007 Posts: 5 Topics: 3
|
Posted: Thu Jun 07, 2007 5:58 am Post subject: |
|
|
Thanks for your reply,
I am not able to understand still one thing with these code.
They close even the datasets that are opened for read only before
an explicit commit and re-open after the commit is succesfull.
Why they do this? Is it just blindly doing things uniformly or they
have resons for?
Thanks and Regards,
Ram |
|
Back to top |
|
|
dbzTHEdinosauer Supermod
Joined: 20 Oct 2006 Posts: 1411 Topics: 26 Location: germany
|
Posted: Thu Jun 07, 2007 6:26 am Post subject: |
|
|
I always have a checkpoint/restart row in some table. Contained in the row was data indicating how many reads had been accomplished, was used to reposition the read dataset during restart.
your run-unit must have some repositioning logic after the close/open which probably is also used during restart. Saves having two types of open logic. the read counter is either zero (begining of new job) or a number indicating restart/reopen after commit.
Quote: | Is it just blindly doing things uniformly or they have resons for? |
a word to the wise....don't assume they do things without thinking. You are new to group, 'just blindly' assuming may make your stay short or difficult.
The buffering problem was a real PITA; that's why I don't work at a site where you have to constantly program around a system shortcoming. 3 in the morning is a really bad time to have learned that the opsys did not do what it should have. I would venture to say there is only about 10% of running COBOL code that isn't legacy. You will find all kinds of oddities; be careful of the attitude that you display to your co-workers. _________________ Dick Brenholtz
American living in Varel, Germany |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
|
Posted: Thu Jun 07, 2007 6:56 am Post subject: |
|
|
Quote: |
As I was reading the batch programs I noticed that before explicitly commiting data to db2 tables, All the datasets are closed and re-opended after the commit.
|
wow are these IMS BMP programs? AFAIK IBM has removed the need of opening/closing GSAM datasets.
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
|
|