Page 1 of 1

How to update RT_CONFIG?

Posted: Wed Feb 24, 2010 2:26 pm
by kamesh
Hi,

I have jobs in production with multiple instance flag disabled and I need to enable it using UV commands. I know that below query provides me the flag status in the DS job executable file. I would like to know the syntax to update the RT_CONFIGxx so that the flag can be switched to "1".

$DSHOME/bin/uv "select EVAL \"@RECORD<30>\" from RT_CONFIGxx where @ID='<Job_Name>';"

Tried below sql without any success
$DSHOME/bin/uv "UPDATE RT_CONFIGxx SET RECORD<30>='1' where @ID='<Job_Name>';"

Posted: Wed Feb 24, 2010 3:55 pm
by kduke
This is also stored in the job design. I would imagine you would need to recompile the job even if you changed all the correct places.

Posted: Wed Feb 24, 2010 4:01 pm
by ray.wurlod
Recompile.

Many things are inter-related in the repository. Even I would not attempt to effect a change merely by changes to repository tables, for fear that I might miss some vital piece of the puzzle.

Posted: Wed Feb 24, 2010 5:51 pm
by kduke
I would not recommend changing these directly. Why are you not using Designer?

Posted: Wed Feb 24, 2010 7:08 pm
by chulett
Yes, please explain why you think you "need" to do this using UV commands.

Posted: Wed Feb 24, 2010 7:46 pm
by ray.wurlod
Just out of curiosity (since it won't be an obstacle), is your production a Protected project?

Posted: Wed Feb 24, 2010 8:47 pm
by kamesh
Thanks to everyone for the replies!
This is also stored in the job design. I would imagine you would need to recompile the job even if you changed all the correct places.

I would not recommend changing these directly. Why are you not using Designer?
To answer your question Duke, we do not have compiler installed on UAT/PROD environments and we move only the executables to UAT/PROD environments using the UNIX UV command DS_IMPORTDSX. We can also write the windows batch scripts to have the designs available in UAT/PROD environments but there would be difficulties in scheduling and automating the deployment tasks.
Recompile.
Many things are inter-related in the repository. Even I would not attempt to effect a change merely by changes to repository tables, for fear that I might miss some vital piece of the puzzle.

Just out of curiosity (since it won't be an obstacle), is your production a Protected project?
Ray, our prod projects are not protected projects but as I said we do not have compilers installed so we have to import all the jobs to dev environment to compile and export/import back them to PROD.

I agree that we may miss some vital pieces but just wanted to make sure, since I thought multiple instance flag as a pretty srtraight forward one without any dependecies. Anyways I will have the changes done in DEV and promote to PROD.
Yes, please explain why you think you "need" to do this using UV
commands.
chulett, I think you have my answer above, but now I think that it is not a good idea at all.

Once again I really appreciate all your quick responses.

Finally let me reframe my question though, what is the sql syntax to update the @RECORD values in the UV world?

Posted: Wed Feb 24, 2010 9:26 pm
by ray.wurlod
You can not update @RECORD, because it's a system variable. The only way you can update any field using SQL in a UV context (such as DataStage) is to have a properly defined data field in the file dictionary. Of course, that can be created with an INSERT statement with the keyword DICT preceding the table name.

Code: Select all

INSERT INTO DICT RT_CONFIG(ID, CODE, LOC, NAME, FORMAT, SM)
VALUES('MULTI_INSTANCE','D Multi-instance flag only in job record',59,'Multi','1R','S');
Now you're in a position to effect an update statement using the newly-defined column name.

Code: Select all

UPDATE RT_CONFIGxxx SET MULTI_INSTANCE = 1 WHERE ID = '<<JobName>>';
But wait, there's more.
There are instance-specific entries in RT_STATUSxx. The design metadata (recorded in DS_JOBOBJECTS) also records that the job is or isn't multi-instance. This information may also exist in DS_TEMPxx.

So there's no guarantee that merely changing the value in RT_CONFIGxx will work as you wish.

And you're on your own. Hacking the repository is one of the things that allows IBM support to refuse to assist resolving concomitant problems.

Posted: Thu Feb 25, 2010 10:02 am
by kduke
The 59 field in the ROOT record of DS_JOBOBJECTS is the multiple instance flag there.

Posted: Thu Feb 25, 2010 2:01 pm
by kamesh
Thank you Ray/Duke!

Posted: Thu Feb 25, 2010 4:04 pm
by ray.wurlod
kduke wrote:The 59 field in the ROOT record of DS_JOBOBJECTS is the multiple instance flag there.
Edited my DML accordingly.