DataStage Job 378 Phantom 8288
DataStage Phantom Aborting with @ABORT.CODE = 1
Phantom Aborting with @ABORT.CODE = 1
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Welcome aboard! :D
Every job in your project has a unique number; the job where this problem occurred is job number 378. (You can map names to job numbers in the DS_JOBS table, but I'm sure you know which job it is - its status is Aborted.)
"Phantom" is simply DataStage's name for a background process; the user number (process ID) that executed your job was 8288.
@ABORT.CODE is an internal system variable that identifies what kind of abort condition occurred; you can read about this in the DataStage BASIC manual.
And that's where we run out of information. Take Craig's and Arnd's advice - reset the job using Director then look in the job log for a message "from previous run...". It will contain additional diagnostic information.
Every job in your project has a unique number; the job where this problem occurred is job number 378. (You can map names to job numbers in the DS_JOBS table, but I'm sure you know which job it is - its status is Aborted.)
"Phantom" is simply DataStage's name for a background process; the user number (process ID) that executed your job was 8288.
@ABORT.CODE is an internal system variable that identifies what kind of abort condition occurred; you can read about this in the DataStage BASIC manual.
And that's where we run out of information. Take Craig's and Arnd's advice - reset the job using Director then look in the job log for a message "from previous run...". It will contain additional diagnostic information.
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.