If you have Backup of the project Just delete the project and and Re-import the Project fresh. In my past project when we had this problem we have deleted the Project and imported it again. It worked ( We did it in v6)
It might work for you
Urgent: Project has been corrupted
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Then again, you might have a corrupted DS_JOBOBJECTS on your backup.
Even so you're in a better position to attempt repairs. uvfixfile without the -fix option will tell you whether repairs are necessary. You can then use either uvfixfile or the newer fixtool to effect repairs. However the danger still exists that you may truncate a group.
DS_JOBOBJECTS has a number of indexes, so you need to be wary of these too. You may prefer to disconnect them while repairing the main file and reconnect them afterwards (see SET.INDEX command).
Arnd, DS_JOBOBJECTS tends to have many oversized records, so it may well be the case that OVER.30 is larger than DATA.30.
Even so you're in a better position to attempt repairs. uvfixfile without the -fix option will tell you whether repairs are necessary. You can then use either uvfixfile or the newer fixtool to effect repairs. However the danger still exists that you may truncate a group.
DS_JOBOBJECTS has a number of indexes, so you need to be wary of these too. You may prefer to disconnect them while repairing the main file and reconnect them afterwards (see SET.INDEX command).
Arnd, DS_JOBOBJECTS tends to have many oversized records, so it may well be the case that OVER.30 is larger than DATA.30.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 82
- Joined: Wed Jul 14, 2004 7:21 am
- Location: India
The problem has been solved by importing the entire 6.0 code into a new project and making the changes again, as the changes were not many.
I can easily get the DS_JOBOBJECTS file from this new project and put it in the old projet to try and fix it, but I want to try it the hard way.
I also did not get a reply to one of my earlier questions: is tarring and moving hash files the correct way to transfer them between servers.
Thanks Ray,ArndW and others.
Vinod
I can easily get the DS_JOBOBJECTS file from this new project and put it in the old projet to try and fix it, but I want to try it the hard way.
So what exactly do I have to do before running UVFIXFILE? And what is this fix tool, can it be run from manager / director?DS_JOBOBJECTS has a number of indexes, so you need to be wary of these too. You may prefer to disconnect them while repairing the main file and reconnect them afterwards (see SET.INDEX command).
Arnd, DS_JOBOBJECTS tends to have many oversized records, so it may well be the case that OVER.30 is larger than DATA.30.
I also did not get a reply to one of my earlier questions: is tarring and moving hash files the correct way to transfer them between servers.
Thanks Ray,ArndW and others.
Vinod
Integrity is what you do when no one is watching
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Code: Select all
SET.INDEX DS_JOBOBJECTS INFORM
Code: Select all
SET.INDEX DS_JOBOBJECTS TO NULL
Now effect your repair. fixtool is $DSHOME/bin/fixtool - executed alone or with -H command line option it will generate syntax help.
Code: Select all
SET.INDEX DS_JOBOBJECTS TO pathname
This makes DS_JOBOBJECTS believe once again that it has indexes.
Code: Select all
BUILD.INDEX DS_JOBOBJECTS ALL
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Hi Ray,
As per Vinod the project is corrupted after importing to V7 from V6. Then there is a good Chance that V6 Import is Good.
One other thing is say you have project X and it is been courrupted. ( At present client place smtimes the Jobs are not getting compiled & we can not open the Jobs in this case we Export the Which has problem from project X and we delet the Job from project and reimport the Job it Clears all the Errors and we can compile the Job) It works Ray. When we delete the Job or project it deletes all the Underlying system files also and creates a new one when you import.
I have learned this hard way and it works
Thank you
As per Vinod the project is corrupted after importing to V7 from V6. Then there is a good Chance that V6 Import is Good.
One other thing is say you have project X and it is been courrupted. ( At present client place smtimes the Jobs are not getting compiled & we can not open the Jobs in this case we Export the Which has problem from project X and we delet the Job from project and reimport the Job it Clears all the Errors and we can compile the Job) It works Ray. When we delete the Job or project it deletes all the Underlying system files also and creates a new one when you import.
I have learned this hard way and it works
Thank you
ray.wurlod wrote:Then again, you might have a corrupted DS_JOBOBJECTS on your backup.
Even so you're in a better position to attempt repairs. uvfixfile without the -fix option will tell you whether repairs are necessary. You can then use either uvfixfile or the newer fixtool to effect repairs. However the danger still exists that you may truncate a group.
DS_JOBOBJECTS has a number of indexes, so you need to be wary of these too. You may prefer to disconnect them while repairing the main file and reconnect them afterwards (see SET.INDEX command).
Arnd, DS_JOBOBJECTS tends to have many oversized records, so it may well be the case that OVER.30 is larger than DATA.30.
ram1899