deleting a job

attu · Post by **attu** » Thu Jun 12, 2008 8:39 am

Job was deleted by developer from client interface but

SELECT JOBNO FROM DS_JOBS WHERE NAME ='JOBNAME';

No...

6

1 records listed

where is the job? do I have to run ds.checker?
pls advise..Thanks

ArndW · Post by **ArndW** » Thu Jun 12, 2008 10:29 am

That output looks correct, you have found that the JOBNO for that job is number "6". What do you think your problem is?

attu · Post by **attu** » Thu Jun 12, 2008 10:38 am

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

ag_ram · Post by **ag_ram** » Thu Jun 12, 2008 12:57 pm

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?

ray.wurlod · Post by **ray.wurlod** » Thu Jun 12, 2008 6:33 pm

Not quite. The definition records in VOC should be deleted, not set to nothing, if the deletion is to be counted as successful.

ag_ram · Post by **ag_ram** » Thu Jun 12, 2008 11:46 pm

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.

ray.wurlod · Post by **ray.wurlod** » Fri Jun 13, 2008 12:27 am

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.

ag_ram · Post by **ag_ram** » Fri Jun 13, 2008 1:23 am

...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.

ArndW · Post by **ArndW** » Fri Jun 13, 2008 3:01 am

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.

ag_ram · Post by **ag_ram** » Sat Jun 14, 2008 1:38 pm

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.

ArndW · Post by **ArndW** » Sun Jun 15, 2008 3:33 am

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.