Page 1 of 1
deleting a job
Posted: Thu Jun 12, 2008 8:39 am
by attu
Job was deleted by developer from client interface but
SELECT JOBNO FROM DS_JOBS WHERE NAME ='JOBNAME';
where is the job? do I have to run ds.checker?
pls advise..Thanks
Posted: Thu Jun 12, 2008 10:29 am
by ArndW
That output looks correct, you have found that the JOBNO for that job is number "6". What do you think your problem is?
Posted: Thu Jun 12, 2008 10:38 am
by attu
Issue was resolved.
earlier the job could not be found in director or designer but it was present in manager. I tried to delete it from Manager and got this error message " cannot open executable job file RT_CONFIG6"
From adminsitrator i tried this query
SELECT COUNT (@ID) FROM RT_CONFIG6; but it didnt give me the count.
Later on job was deleted from adminsitrator
DELETE DS_JOBS JOBNAME
Thanks
Posted: Thu Jun 12, 2008 12:57 pm
by ag_ram
ArndW wrote:That output looks correct, you have found that the JOBNO for that job is number "6". What do you think your problem is?
Is that true that If we delete a Job through Designer, the corresponding record entries in DataStage files DS_JOBS, DS_JOBOBJECTS would be deleted and all respective run time files (RT_CONFIGnnn, RT_STATUSnnn, RT_LOGnnn, RT_BPnnn, RT_BPnnn.O[,RT_SCnnn,RT_SCTEMPnnn]) would be deleted and the corresponding file(runtime) definition records in VOC file would be set to nothing?
Posted: Thu Jun 12, 2008 6:33 pm
by ray.wurlod
Not quite. The definition records in VOC should be deleted, not set to nothing, if the deletion is to be counted as successful.
Posted: Thu Jun 12, 2008 11:46 pm
by ag_ram
Correct.
But the Server side tracing messages like this while deleting a Job.
2006-06-13 00:17:04: DSR_MESSAGE =Deleting file RT_BP5.O
Deleting file RT_BP5.O
DELETEd "RT_BP5.O", Type 19.
Field 2 in file definition record "RT_BP5.O" has been set to nothing.
The correponding records would be deleted in VOC file as well.
Posted: Fri Jun 13, 2008 12:27 am
by ray.wurlod
Not true in this case because all the RT_xxxnnn hashed files share common file dictionaries. Because the dictionary name does not correspond to the VOC entry name, the VOC entry is not deleted, instead the data file pathname (field #2) is set to nothing, as per the message. These entries will serve no further useful purposes and can be cleaned up (carefully!) when maintenance is being performed.
Posted: Fri Jun 13, 2008 1:23 am
by ag_ram
...all the RT_xxxnnn hashed files share common file dictionaries
True.
Because the dictionary name does not correspond to the VOC entry name, the VOC entry is not deleted, instead the data file pathname (field #2) is set to nothing, as per the message
Can you please verify that this is the reason for the statement that VOC entry is not deleted?
These entries will serve no further useful purposes and can be cleaned up (carefully!) when maintenance is being performed.
A few questions: When the maintenance is being performed? Is it a manual work or automatic one? If automatic, how often this ocurs in the Server?
Though all,
I fired this query in Admistrator as soon as i deleted the Job.
Code: Select all
SELECT F2 FROM VOC WHERE FILE.NAME='RT_CONFIG6'
Output:
SQL+
0 records listed.
This confirms that corresponding VOC entries are deleted as soon as the Job is deleted through the Designer.
Still mulling over the meaning of the server side trace lines.
Posted: Fri Jun 13, 2008 3:01 am
by ArndW
Ag_ram,
ag_ram wrote:
RayW wrote:Because the dictionary name does not correspond to the VOC entry name, the VOC entry is not deleted, instead the data file pathname (field #2) is set to nothing, as per the message
Can you please verify that this is the reason for the statement that VOC entry is not deleted?
Why should Ray, or anyone else for that matter, need to convince or prove to you that this is the case? It should take you no more than a minute, or perhaps 2, to test this out to your own satisfaction. If it turns out that the original statement is incorrect then I am sure you will bring this to the attention of thread.
Posted: Sat Jun 14, 2008 1:38 pm
by ag_ram
OK ArndW,
ray.wurlod wrote:Not true in this case because all the RT_xxxnnn hashed files share common file dictionaries. Because the dictionary name does not correspond to the VOC entry name, the VOC entry is not deleted, instead the data file pathname (field #2) is set to nothing, as per the message. These entries will serve no further useful purposes and can be cleaned up (carefully!) when maintenance is being performed.
What i infer from these statements is that runtime hashed files(RT_CONFIGnnn, RT_STATUSnnn, RT_LOGnnn) generated by the Job share a respective common dictionary file(D_RT_CONFIG, D_RT_STATUS, D_RT_LOG) and nothing else.
The reason provided is invalid indeed as it is confirmed that the corresponding file definition entries in file VOC are immediately deleted once the Job is deleted.
Here i dont say that the statement is incorrect but would say that there is no need to deduce that statement.
Posted: Sun Jun 15, 2008 3:33 am
by ArndW
ag_ram - As suggested in my initial post, have you tried this before posting your inferences? If not - don't bother replying to this thread as you will have nothing to add to it.
Once you have confirmed that a VOC file entry is kept upon DELETE.FILE when the DICT portion is empty or doesn't match the VOC file name you will realize that when a job is deleted through the DataStage client it obviously must perform an additional manual removal of entries from the VOC file, since the file definitions are, in fact, removed from the VOC.