Emma
I assume you are doing a ps and looking at the processes running. phantom is Universe process to run a process in the background. When you start a DataStage job then it uses this command to run unattended in the background. The phantom command creates a record in the &PH& directory below the project. This record contains what would of went to the screen if you ran this command in the foreground. Sometimes this may help you debug a job. If the user that kicks off a job cannot write to &PH& then the job will die.
Sometimes a phantom can get locked up because a hash file is corrupted. You do not need admin right to analize a hash file. The best thing to do is have the job delete and create the hash file.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
More about Phantoms
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
"Phantom" is just DataStage's name for a background process.
All DataStage jobs run as background processes (executing DSD.RUN), and some active stages within jobs run as child processes of these (executing DSD.StageRun). You will see these, for example, in a listing of processes (ps -ef in UNIX, Task Manager Processes in Windows). They are perfectly normal. Don't worry about them.
Historical note: the term "phantom" was coined by the authors of the database/IDE called Prime INFORMATION, which was a precursor to UniVerse (the original DataStage engine). The Prime systems were also the origin of directory names encased in "&" characters, which can be the bane of UNIX users (because "&" is a special character to the shell, for example a final "&" initiates a process as a background process). So these names need to be encased in single quote characters, for example cd '&PH&'.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
All DataStage jobs run as background processes (executing DSD.RUN), and some active stages within jobs run as child processes of these (executing DSD.StageRun). You will see these, for example, in a listing of processes (ps -ef in UNIX, Task Manager Processes in Windows). They are perfectly normal. Don't worry about them.
Historical note: the term "phantom" was coined by the authors of the database/IDE called Prime INFORMATION, which was a precursor to UniVerse (the original DataStage engine). The Prime systems were also the origin of directory names encased in "&" characters, which can be the bane of UNIX users (because "&" is a special character to the shell, for example a final "&" initiates a process as a background process). So these names need to be encased in single quote characters, for example cd '&PH&'.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
What release of DataStage on what type of platform?
When you see phantoms, what are you talking about? Are you referring to the yellow messages in a job log that say something about phantoms?
Or are you looking at "phantom" process names if you're looking at either task manager or doing "ps -ef"? Not knowing your platform or version of DataStage makes helping you very difficult.
As you can see, phantom means different things depending on what you are asking.
If you are running a job and getting yellow phantom messages in the job log, maybe you could paste the message here for us to see. There are releases of DataStage that have had bugs that put silly yellow phantom messages into the log when nothing was wrong. Not knowing your version doesn't help.
Thanks,
Kenneth Bland
When you see phantoms, what are you talking about? Are you referring to the yellow messages in a job log that say something about phantoms?
Or are you looking at "phantom" process names if you're looking at either task manager or doing "ps -ef"? Not knowing your platform or version of DataStage makes helping you very difficult.
As you can see, phantom means different things depending on what you are asking.
If you are running a job and getting yellow phantom messages in the job log, maybe you could paste the message here for us to see. There are releases of DataStage that have had bugs that put silly yellow phantom messages into the log when nothing was wrong. Not knowing your version doesn't help.
Thanks,
Kenneth Bland
What is your problem, Emma?
Having such phantoms during a job is runing is quite normal, so don't mind having them.
If the Job doesn't work or hash-files are not filled, the you have a problem, which you have to analyse.
In the &PH&-directory, Kim and Ray have mentioned you may find hints for errors, read the actual file in this directory or any subdirectories of it.
Please tell more clearly, what problem you do have.
Have an nice day
Wolfgang Huerter
=====================
Cologne, Germany
Having such phantoms during a job is runing is quite normal, so don't mind having them.
If the Job doesn't work or hash-files are not filled, the you have a problem, which you have to analyse.
In the &PH&-directory, Kim and Ray have mentioned you may find hints for errors, read the actual file in this directory or any subdirectories of it.
Please tell more clearly, what problem you do have.
Have an nice day
Wolfgang Huerter
=====================
Cologne, Germany
Since jobs are running in the background, and screen i/o is captured and appears in the "phantom" messages in the job log. A job should not be producing any screen i/o outside a normal expected set of messages. Therefore, anything extra causes that screen output to be placed into your job log as a yellow warning message.
In your case, there appears to be 2 instances where something occurred involving a DataStage BASIC syntax error. My guess would be that a DS or BASIC function was called and a NULL value was passed where you shouldn't pass one. Are you doing any functions or logic in the column derivations?
Kenneth Bland
In your case, there appears to be 2 instances where something occurred involving a DataStage BASIC syntax error. My guess would be that a DS or BASIC function was called and a NULL value was passed where you shouldn't pass one. Are you doing any functions or logic in the column derivations?
Kenneth Bland
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
"Phantom" simply means "background process" (see earlier), so you shouldn't be concerned about it.
These processes redirect their output to a file in a sub-directory called &PH& in the project directory. DataStage internally, and therefore some posters to this forum, refer to &PH& as a "Type 19 file". Again, don't be concerned by this terminology.
When a job ends, any non-standard entries in the file in &PH& are moved to the DataStage job log. If a job aborts, this cannot occur and the entries are left in &PH&.
Resetting the job will usually move the information from &PH& to the job log, into an informational entry whose text begins "From previous run...".
John, I am surprised that "syntax error" appears in a job log. It is not likely to be a DataStage syntax error, as these are captured when things are compiled. It may be that the SQL generated by the ODBC stage has generated a recoverable syntax error; the fact of the syntax error is logged, but the ODBC driver recovers and executes something against your Teradata database. Is there anything else reported?
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
These processes redirect their output to a file in a sub-directory called &PH& in the project directory. DataStage internally, and therefore some posters to this forum, refer to &PH& as a "Type 19 file". Again, don't be concerned by this terminology.
When a job ends, any non-standard entries in the file in &PH& are moved to the DataStage job log. If a job aborts, this cannot occur and the entries are left in &PH&.
Resetting the job will usually move the information from &PH& to the job log, into an informational entry whose text begins "From previous run...".
John, I am surprised that "syntax error" appears in a job log. It is not likely to be a DataStage syntax error, as these are captured when things are compiled. It may be that the SQL generated by the ODBC stage has generated a recoverable syntax error; the fact of the syntax error is logged, but the ODBC driver recovers and executes something against your Teradata database. Is there anything else reported?
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
Hi,
After all said and done.
You might want to try and copy the sql you have in your stage and paste it to a sql query client to the teradata and run it.
( don't forget to change parameters and the likes of it to the DB syntax)
If there is somethign wrong there you should get an error.
I hope this helps,
Roy R.
After all said and done.
You might want to try and copy the sql you have in your stage and paste it to a sql query client to the teradata and run it.
( don't forget to change parameters and the likes of it to the DB syntax)
If there is somethign wrong there you should get an error.
I hope this helps,
Roy R.