View previous topic :: View next topic
|
Author |
Message |
Bhanupratap Natva
New User
Joined: 13 Jul 2007 Posts: 8 Location: Hyderabad
|
|
|
|
Hi,
Can any one let me know is there any logic to handle the
restart logic in DB2.
For ex: My program is updating a table, after some point of time my program got abended. Now when I restart my job I want to start from the record where the step got abended. I have searched the forum with the string 'DB2 Restart logic' but found nothing. Please let me know if you have any links related to this concept.
Thanks,
Bhanu. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Restart processing is implemented for individual systems or for an entire environment. This is not something "tossed in" to some code so this can be done.
Places that support this type of restart have formal procedures that mustbe followed. Due to the speed of the new cpu's and dasd, many places no longer implement this. It is faster and less error prone to simply rerun from the beginning. |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
Usually this is done by designing the query in your cursor to return rows in unique key order and by selectting rows >= to a preset value of a unique key along with other constraints that qualifies your rows.
When initially starting the job the first key value to retreive would be the lowest possible.
When you want to save the restart values of your program at certain restart points (sync points/check points) during program execution, you should save the key values.
In case of a restart, the logic should load the key data saved in the last checkpoint and insert the key value to start from in your cursor SQL expression before opening the cursor.
DB2 does not provide methods for syncronising LUWs across DB systems like e.g. IMS and CICS does.
Quote: |
Places that support this type of restart have formal procedures that mustbe followed. Due to the speed of the new cpu's and dasd, many places no longer implement this. It is faster and less error prone to simply rerun from the beginning.
|
I don't completely agree with Dick that checkpoint/restart functionality has lost it's value. If you have batch updates to data concurrently accessed in real time applications, you can free up update locks held by by commiting your updates with frequent checkpoints. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
In case of a restart, the logic should load the key data saved in the last checkpoint and insert the key value to start from in your cursor SQL expression before opening the cursor. |
And also keep in mind that any sequential data that is being written (files and/or reports) will need to be re-created and syncronized.
Then there is the possibility that some vsam data was written/updated. . .
The list can become quite extensive. |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
Quote: |
And also keep in mind that any sequential data that is being written (files and/or reports) will need to be re-created and syncronized.
Then there is the possibility that some vsam data was written/updated. . .
|
That is also within the scope of IMS checkpoint/restart logic, provided you access these datasats as GSAM databases. |
|
Back to top |
|
|
|