Cannot find job TEST

chulett · Post by **chulett** » Mon Sep 28, 2009 3:57 pm

We have a project that throws this message for any process that reads the entire list of jobs. OK, perhaps not "any process" but the Director sure does. I was thinking I could query DS_JOBS for that name, get the job number and copy another job's files over to that number in the project to shut it up. Problem is there's no record in DS_JOBS where NAME = 'TEST'.

The repository indexes have already been built so it's not an issue there. Now I'm wondering what else to try. Isn't there a UVFIXSCHEMA or some such command as another way to verify internal integrity? Would that be the next step?

ray.wurlod · Post by **ray.wurlod** » Mon Sep 28, 2009 8:24 pm

Is there a ROOT entry in DS_JOBOBJECTS for a job with name of TEST?

chulett · Post by **chulett** » Tue Sep 29, 2009 5:41 am

I'll check. I don't recall DS_JOBOBJECTS having 'name' in it anywhere...

ArndW · Post by **ArndW** » Tue Sep 29, 2009 6:15 am

Code: Select all

LIST DS_JOBOBJECTS WITH NAME EQ "TEST"

should suffice to see if any artefacts are left.

chulett · Post by **chulett** » Tue Sep 29, 2009 10:08 am

Looks like the answer is 'yes':

Code: Select all

LIST DS_JOBOBJECTS WITH NAME EQ "TEST" 09:57:29am  29 Sep 2009  PAGE    1

Object type........ J
Object record id... 1358
Object record name. V77S0P1
Description........

Object type........ J
Object record id... 1358
Object record name. V0S251P6
Description........

Object type........ J
Object record id... 2934
Object record name. ROOT
Description........


3 records listed.

So, do all of three of these need to go? Just the ROOT record? Do I get them into a select list and delete them from ED or some such? Not real comfortable with the syntax although I did capture most of what Karen Powers did last week for a (seemingly) similar operation on DS_JOBS, so specifics there would be greatly appreciated.

ray.wurlod · Post by **ray.wurlod** » Tue Sep 29, 2009 4:11 pm

Go back to DS_JOBS and find out what job numbers 1358 and 2934 are about. I suspect the latter is the main culprit.

Then review DS_JOBOBJECTS again, based on this number.

Code: Select all

SELECT * FROM DS_JOBOBJECTS WHERE OBJIDNO = '2934';

just to see what else is there.

chulett · Post by **chulett** » Wed Sep 30, 2009 9:22 am

I've opened up a combined PMR for my two issues with this project and will post back with the resolutions here when I have them. Being classed as the lowest priorty in their system, no clue how long before someone contacts me, however.

attu · Post by **attu** » Wed Sep 30, 2009 1:40 pm

Code: Select all

SELECT DS_JOBOBJECTS WITH NAME LIKE 'TEST'

If the output is 1 records selected, then

Code: Select all

DELETE DS_JOBOBJECTS

chulett · Post by **chulett** » Wed Sep 30, 2009 1:53 pm

As posted above, there's three records not just one... not sure I can delete all of them.

chulett · Post by **chulett** » Thu Oct 01, 2009 2:39 pm

Managed to get the one pesky ROOT record deleted and now it no longer says "Cannot find job TEST". Now I get "Cannot open executable job file RT_CONFIG1775".

Even better, although I can see all of the normal structures for that job in the project:

Code: Select all

$ ls -ld *1775*
drwxrwxr-x  2 sparker dstage 4096 Jun 26  2008 DS_TEMP1775
drwxrwxr-x  2 sparker dstage 4096 Sep 23  2008 RT_BP1775
drwxrwxr-x  2 sparker dstage 4096 Sep 23  2008 RT_BP1775.O
drwxrwxr-x  2 sparker dstage 4096 Jun 26  2008 RT_CONFIG1775
drwxrwxr-x  2 sparker dstage 4096 Jun 26  2008 RT_LOG1775
drwxrwxr-x  2 sparker dstage 4096 Jun 26  2008 RT_STATUS1775

When I lookup the details for that job number:

Code: Select all

>SELECT CATEGORY,NAME,JOBNO FROM DS_JOBS WHERE JOBNO = '1775';
Category............    Job name............    No...

Fred                    e_BAH_CLM_1222          1775

1 records listed.

Looking in that Category via both the Manager and Designer I can see a job with that name, however no trace of it is shown in the Director and it throws the error noted above about the executable file.

Opening the job in the Designer throws the same error several times before I have access to the canvas. A compile blows up with the following error and then I need to exit Designer:

Code: Select all

Error calling subroutine: DSR_JOB (Action=5); check DataStage is set up correctly in project DEV_XXX
(Subroutine failed to complete successfully (30107))

An attempt to do VERIFY.SQL just results in it giving up:

Code: Select all

>VERIFY.SQL TABLE RT_CONFIG1775
Checking file permissions.
** The VOC entry 'RT_CONFIG1775' points to a non-existent file.

1 verify operation discontinued.

Items marked with a '!' are information messages only.
Items marked with a '*' can be fixed by using the FIX option to VERIFY.SQL.
Items marked with a '**' are situations where VERIFY.SQL could not continue.

Oddly enough, running that command on any other (perfectly valid) version of that table lists problems up the wazoo, much like my other problem thread:

Code: Select all

>VERIFY.SQL TABLE RT_CONFIG1776
Checking file permissions.
Checking for duplicate VOC F pointers.
* No SQL catalog data for the table 'RT_CONFIG1776 (DEV_HDR)' in UV_TABLES.
Doing verify on table 'RT_CONFIG1776'.
! The OS table name 'RT_CONFIG1776' does not match table name 'This file is NOT
  an sql file.' found in the SICA.
! The table 'RT_CONFIG1776' is located in the schema 'DEV_HDR' rather than in
  the schema '' as specified in the SICA.
* SQL catalog data does not exist for this table, even under another name.
* SQL catalog data for table 'RT_CONFIG1776 (DEV_HDR)' should be created.

2 information-only conditions found.
2 fixable errors found.

Items marked with a '!' are information messages only.
Items marked with a '*' can be fixed by using the FIX option to VERIFY.SQL.
Items marked with a '**' are situations where VERIFY.SQL could not continue.

I get these errors no matter what 'table' I asked it to check or what project I'm in. The only one that gives a different message is the 'points to a non-existent file' one. Perhaps this command is well and truly porked in my version and I shouldn't be running it, I have no clue at the moment. Will be passing all this along to IBM for their dining and dancing pleasure soonest.

chulett · Post by **chulett** » Fri Oct 02, 2009 2:42 pm

The issue with job 1775 has been resolved.

Code: Select all

>CNAME RT_CONFIG1775 TO RT_CONFIG1775BAK
Unable to open file "RT_CONFIG1775".
Changed "RT_CONFIG1775" to "RT_CONFIG1775BAK" in your VOC file.

(at this point I manually renamed the directory under the project in
another session)

>CREATE.FILE RT_CONFIG1775 30
Creating file "RT_CONFIG1775" as Type 30.
Creating file "D_RT_CONFIG1775" as Type 3, Modulo 1, Separation 2.
Added "@ID", the default record for Retrieve, to "D_RT_CONFIG1775".
>ED VOC RT_CONFIG1775
3 lines long.

----: 3
0003: D_RT_CONFIG1775
Bottom at line 3.
----: D
Bottom at line 2.
----: I
0003= D_RT_CONFIG
0004=
Bottom at line 3.
----: FI
"RT_CONFIG1775" filed in file "VOC".
>

Afterwards I deleted the extraneous D_RT_CONFIG1775 dictionary record this created plus the renamed backup config directory as well. I supposed I should delete the renamed VOC record as well.

All seems to be back to normal even without the REINDEX they suggested I do, I'll get to that later over the weekend when there's no-one else on the system. I'm closing this topic but am leaving the other open for now to see what comes of the VERIFY.SQL issues I'm seeing.

ray.wurlod · Post by **ray.wurlod** » Fri Oct 02, 2009 4:33 pm

Could it be that someone has run VERIFY.SQL SCHEMA pathname over the project, which might put the empty schema entries into the hashed files?

chulett · Post by **chulett** » Fri Oct 02, 2009 5:27 pm

I don't believe so. The other thing to note is the issue occurs in all projects on both servers, so if someone did this they were very thorough.