Hi all,
Can pls tell me the importance and precautions while handling .profile,.uvconfig,.dsenv,dsrpcservices,uv.account,voc in Datastage adminstration?
Your comments appreciated
Datastage administartion
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
There is a .profile file (on UNIX) for each user who can log in. It is the "auto start" script for that user, and typically sets environment variables, alias definitions and the like. If the interactive user is likely to need DataStage commands on the server then you might like to include the DataStage bin directory in PATH, and perhaps to source the dsenv shell script, which does much the same thing as .profile but for all DataStage processes (which run as background process and so do not have a .profile to execute).
Don't ever touch .uvconfig - this is the result of a uvregen process to "compile" configuration from the uvconfig file (and some licensing information), and is the image of the shared memory segment that holds everything together in DataStage.
There is no file called .dsenv for DataStage. See above for dsenv shell script.
In general you would not need to edit the dsrpcservices file unless you want to restrict the nodes from which clients can connect or change the default inactivity timeout. The latter is more easily accomplished from the Administrator client General tab.
UV.ACCOUNT is one of many "system tables". It records the existence and location of DataStage projects. It is edited when you Add or Delete projects using the Administrator client, and should not be edited directly.
VOC is the name of the "vocabulary" hashed file maintained in each project. Again, in general, you should not need to access this directly; compiling a routine will, for example, create a vocabulary (or "catalog") entry in the VOC file indicating the existence and location of that routine's object code. The SETFILE command can be used to create a pointer to a hashed file that was created in a directory, so that the table definition may be imported.
And, as Kim says, all of these things are "system" files/tables. Make sure you have them (and others, such as uvodbc.config) backed up before effecting edits. That way you can always revert to a "last known good" situation.
Don't ever touch .uvconfig - this is the result of a uvregen process to "compile" configuration from the uvconfig file (and some licensing information), and is the image of the shared memory segment that holds everything together in DataStage.
There is no file called .dsenv for DataStage. See above for dsenv shell script.
In general you would not need to edit the dsrpcservices file unless you want to restrict the nodes from which clients can connect or change the default inactivity timeout. The latter is more easily accomplished from the Administrator client General tab.
UV.ACCOUNT is one of many "system tables". It records the existence and location of DataStage projects. It is edited when you Add or Delete projects using the Administrator client, and should not be edited directly.
VOC is the name of the "vocabulary" hashed file maintained in each project. Again, in general, you should not need to access this directly; compiling a routine will, for example, create a vocabulary (or "catalog") entry in the VOC file indicating the existence and location of that routine's object code. The SETFILE command can be used to create a pointer to a hashed file that was created in a directory, so that the table definition may be imported.
And, as Kim says, all of these things are "system" files/tables. Make sure you have them (and others, such as uvodbc.config) backed up before effecting edits. That way you can always revert to a "last known good" situation.
Last edited by ray.wurlod on Sun May 28, 2006 1:32 am, edited 1 time in total.
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.
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
