 Posted: Thu Aug 14, 2008 6:56 am Post subject: |
 |
|
Since you apparently do not have access to any documentation, I will supply
you with some quotes from the DB2 Messages and Codes Manuel
| Quote: |
DSNU184I csect-name - DO NOT RECOVER
OBJECT qual.obj-nm UNTIL THE NEXT
TRACKER SITE RECOVERY CYCLE
Explanation: If DB2 detects an inconsistency relating
to a utility
_________________
Dick Brenholtz
American living in Varel, Germany |
|
| Back to top |
|
 |
jsharon1248
Intermediate
Joined: 08 Aug 2007
Posts: 291
Topics: 2
Location: Chicago
|
| Posted: Thu Aug 14, 2008 8:34 am Post subject: |
|
|
You probably shot yourself in the foot with the START DB ACCESS(FORCE).
| Code: | A table space or index space that is started with ACCESS(FORCE) might be in an inconsistent state.
Use of ACCESS(FORCE): The ACCESS(FORCE) option is intended to be used when data has been restored to a previous level after an error, by DSN1COPY, or by a program that is not DB2 UDB for z/OS, and the exception states resulting from the error still exist and cannot be reset. When using ACCESS(FORCE), it is up to the user to ensure the consistency of data with respect to DB2. |
As you have found, it can be very dangerous to start a DB using the ACESS(FORCE) option. Now, you'll need to restore the tables. DB2 puts table in different states for good reasons. You should avoid using the ACCESS(FORCE) option unless you have a very good reason, or plenty of time for restores. |
|
| Back to top |
|
|
Sqlcode
Intermediate
Joined: 15 Dec 2006
Posts: 157
Topics: 38
|
| Posted: Fri Aug 15, 2008 8:58 am Post subject: |
|
|
| Did you check your UTIL ID? I am not sure but you may want to terminate your TERM ID. |
|
| Back to top |
|
|
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
| Posted: Wed Aug 20, 2008 4:33 am Post subject: |
|
|
Hi all,
Thank you all for your time. Sorry, I am replying very late(was out of office). The problem was not because of the Access(Force) command. It was a very small problem.  I was checking the status of the table space all the time. But it turned out that the database was in RO mode while tablespace was in RW mode. In the job also I was referring tablespace. So when I started the database in RW mode, the job worked fine.
Thank you once again!!!!!!!!! |
|
| Back to top |
|
|
jsharon1248
Intermediate
Joined: 08 Aug 2007
Posts: 291
Topics: 2
Location: Chicago
|
| Posted: Wed Aug 20, 2008 8:55 am Post subject: |
|
|
| Glad to hear you didn't cause yourself any real problems. I would still recommend that you avoid using ACCESS(FORCE). It's too easy to create big problems. |
|
| Back to top |
|
|
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
| Posted: Thu Aug 21, 2008 5:17 am Post subject: |
|
|
Sure.
Your advice is taken. Thank you.  |
|
| Back to top |
|
|
satyenderd
Beginner
Joined: 26 Aug 2005
Posts: 144
Topics: 73
|
| Posted: Wed Aug 27, 2008 4:42 pm Post subject: |
|
|
Hi sinduja,
The following messages may occurs sometimes when the datasets are migrated.
Check the dataset or GDG which is migrated.
Before doing Load do check the datasets whether they got migrated, if so.
give HRECALL and then load the desired table.
IEF450I ADCF88GL UTILITY LOADDB04 - ABEND=S04E U0000 REASON=00E40009
DSNT500I DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00C90080
TYPE 00000100
NAME BKD2BPAC
_________________
Satya |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
