Structure of DS Tables -- DS_JOBS
Moderators: chulett, rschirm, roy
Structure of DS Tables -- DS_JOBS
Hi,
How do you see structure of Datastage tables like DS_JOBS?
I am looking to a command similiar to Oracle's Describe <tablename>.
Thanks
Ketfos
How do you see structure of Datastage tables like DS_JOBS?
I am looking to a command similiar to Oracle's Describe <tablename>.
Thanks
Ketfos
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
No. If you do that you end up with orphan tables (though these can, in theory, be cleaned up from DS.TOOLS menu). Worse, you get lots of orphan records in DS_JOBOBJECTS, and the DS.TOOLS utility does not (as of version 7.1) clean these up.
Better is to figure out why RT_CONFIG740 is giving problems. Or simply CLEAR.FILE RT_CONFIG740 then try deleting the job from a DataStage client.
Better is to figure out why RT_CONFIG740 is giving problems. Or simply CLEAR.FILE RT_CONFIG740 then try deleting the job from a DataStage client.
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: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Reindexing will not help if one of the hashed files has become corrupted. Indeed, the reindexing will fail to complete successfully in this case.
That said, RT_CONFIGnnn is one of the least likely (smallest) hashed files in the repostory to become corrupted. It's only updated at compile time.
More to the point, RT_CONFIGnnn files are not indexed, so reindexing would not be any help at all in this case.
CLEAR.FILE wipes out all internal content, including any corruption, so is the quickest way to get a corrupted file prepared for deletion.
That said, RT_CONFIGnnn is one of the least likely (smallest) hashed files in the repostory to become corrupted. It's only updated at compile time.
More to the point, RT_CONFIGnnn files are not indexed, so reindexing would not be any help at all in this case.
CLEAR.FILE wipes out all internal content, including any corruption, so is the quickest way to get a corrupted file prepared for deletion.
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.
ketfos ran out of disk space on the project filesystem, so there's a lot of bits and pieces that could be a mess. When this happens, sometimes it's easiest to export all your jobs (and verify) then delete the project and recreate it. Then import your jobs again and continue.
Don't run out of disk space!!!! Bad things happen.
Don't run out of disk space!!!! Bad things happen.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
You ran out of disk space, you have orphaned pieces and parts of a hash file. Export this job and re-import it.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Yes, RT_CONFIG740 is so badly damaged - it was probably being written to when the disk full condition occurred - that even CLEAR.FILE won't work. This suggests that it's header block has become corrupted.
Export the job (which doesn't use RT_CONFIG740) and import it (which will generate a new set of repository files and a new job number). And make sure you don't run out of disk space!
Export the job (which doesn't use RT_CONFIG740) and import it (which will generate a new set of repository files and a new job number). And make sure you don't run out of disk space!
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: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The job you have to export is the one currently numbered 740, not "another job". Then import that one.
My point was that the export does not use RT_CONFIGnnn, rather than suggesting that you should export a different job. Sorry about the confusion.
My point was that the export does not use RT_CONFIGnnn, rather than suggesting that you should export a different job. Sorry about the confusion.
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.
Take another RT_CONFIG file/directory in your unix project and copy it to the errant/missing name. This will at least allow you to import the job or delete it. As I keep telling everyone, it's BAD to run out of disk space on your project.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
I am having a similar problem. I copied an existing RT_CONFIG file and copied it to the missing file name. I am still unable to delete the job or import the job.kcbland wrote:Take another RT_CONFIG file/directory in your unix project and copy it to the errant/missing name. This will at least allow you to import the job or delete it. As I keep telling everyone, it's BAD to run out of disk space on your project.