View previous topic :: View next topic |
Author |
Message |
Sara1977 Beginner
Joined: 25 Apr 2004 Posts: 7 Topics: 4
|
Posted: Sun Apr 25, 2004 10:43 pm Post subject: DB2: RETRY Parameter |
|
|
Hi,
BIND step came down with the message of DB2 NOT OPERATIONAL. I think there is a RETRY parameter that we can give in the BIND card so that there will be n number of tries b4 error out.
Can anyone gimme the syntax of RETRY parameter in BIND card?
Regards,
Sara.. |
|
Back to top |
|
|
Sara1977 Beginner
Joined: 25 Apr 2004 Posts: 7 Topics: 4
|
Posted: Mon Apr 26, 2004 1:43 am Post subject: |
|
|
Thanks Ravi. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Mon Apr 26, 2004 9:38 am Post subject: |
|
|
Sara1977,
I don't think RETRY parameter will make any difference. Can you run queries in spufi for the same DB2 region for which you are getting the error that it is not operational?
The reason you are getting that error might be due to the fact that you are running the job in a class where the initiators are not attached to DB2. So if you are able to run queries in spufi then change the jobclass to a different class and re-run the job.
If you still want to know about retry parameter then here is the syntax and explanation of the parameter.
Code: |
DSN SYSTEM(YOUR DB2 REGION) RETRY(nnn)
|
RETRY integer Specifies the maximum number of retries that can be attempted. nnn Values can be from 0 to 255. If the keyword is omitted, then no retries will be attempted.
Note that specifying RETRY can lead to increased processing costs and can result in multiple or extended periods of read-only access.
Hope this helps...
Cheers
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
Sara1977 Beginner
Joined: 25 Apr 2004 Posts: 7 Topics: 4
|
Posted: Mon May 03, 2004 6:40 am Post subject: |
|
|
Kolusu,
We have a CLIST panel that would generate the PRECOMPILE-COMPILE-BIND JCL for the program passing in the screen and we just submit it. Sometimes the BIND step alone came down with return code 12 stating DB2 not operational.
If we resubmit or restart from BIND step again, it is running.So obviously it is not a job class issue in which case it wont run successfully second time also.
Hence I thought of adding RETRY parameter. When I added, it gave invalid bind parameter error. So posted here for syntax (actually i should have checked on manuals).
When going thru Ravi's response, I found that I have misplaced the RETRY parameter along with BIND options and it should have been next to DSN DB2 regions specifications. When I placed it so, the problem is solved.
Kolusu,
You have mentioned your mail that 'Note that specifying RETRY can lead to increased processing costs and can result in multiple or extended periods of read-only access.'
Since RETRY is going to act only when the first try is failed, how it would increase the processing costs?..
Regards,
Sara.. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Mon May 03, 2004 8:31 am Post subject: |
|
|
Sara,
Quote: |
Kolusu,
You have mentioned your mail that 'Note that specifying RETRY can lead to increased processing costs and can result in multiple or extended periods of read-only access.'
Since RETRY is going to act only when the first try is failed, how it would increase the processing costs?..
|
Retry is basically a parameter which specifies the maximum number of retries that can be attempted. Let us say your query fails and you coded the retry parameter to be 10, then the system tries 10 times finish off the task.
The default time between retry is 300 seconds, so your job will sitting in the queue idle for 5 mins without doing anything. If you have 10 similar jobs then the entire resource is being eaten up with jobs doing nothing but sitting idle. This is considered a resource hog and it will increase the procession costs considerably.
Hope this helps...
Cheers
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
|
|