the sequence log is :
-------------------------
11:53:30: StartLoop_Activity_dailbigX_btm_source loop iteration 4 started
11:53:30: dailbigX_to_btm_source_main_prev6 (JOB dailbigX_to_btm_source_main_prev6) started
11:54:29: Exception raised: @dailbigX_to_btm_source_main_prev6, Error calling DSRunJob(dailbigX_to_btm_source_main_prev6), code=-99 [General repository interface 'other error']
11:54:29: Exception handler started
11:54:35: dailbigX_to_acm_account_dt_1_base (JOB dailbigX_to_acm_account_dt_1_base) finished, status=2 [Finished with warnings]
11:58:56: blfmaster_mstr_to_cus_water_meter_rel (JOB blfmaster_mstr_to_cus_water_meter_rel) finished, status=2 [Finished with warnings]
11:58:57: Sequence failed (restartable)
-------------------------
the exception happened when sequence called job to run.
so I run Director to get the log of the job "dailbigX_to_btm_source_main_prev6"
but it failed ,and the error message is :
-------------------------
Error selecting from log file RT_LOG6345
Command was: SSELECT RT_LOG6345 WITH @ID LIKE '1N0N' COUNT.SUP
Error was: Internal data error.
File 'C:\Ascential\DataStage\Projects\BISETL/RT_LOG6345/DATA.30':
Computed blink of 0xDEC does not match expected blink of 0x0!
Detected within group starting at address 0x80000000!
-------------------------
I don't know what is wrong.
Can you help me.
It is sometimes OK, sometimes Fail.
Error: code=-99 [General repository interface 'other error']
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
When you get a BLINK (backward link) error at this address it typically indicates an attempt to take a hashed file beyond 2GB, which is not possible with 32-bit pointers (and which, therefore, is why the structure becomes corrupted).
You must monitor your hashed files and convert them to 64-bit addressing before they get near 2GB - maybe at around 1.5GB.
I have no idea at all what you mean by "associate same address (0x80000000) to different 2GB files created".
You must monitor your hashed files and convert them to 64-bit addressing before they get near 2GB - maybe at around 1.5GB.
I have no idea at all what you mean by "associate same address (0x80000000) to different 2GB files created".
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.
Sorry about that dumb question, maybe I did not put it right.
I was looking for something like this link
Thanks!
![Embarassed :oops:](./images/smilies/icon_redface.gif)
I guess now I am clear with it.The virtual addresses that a process uses do not represent the actual physical location of an object in memory. Instead, the system maintains a page map for each process, which is an internal data structure used to translate virtual addresses into corresponding physical addresses. Each time a thread references an address, the system translates the virtual address to a physical address.
Thanks!
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.
Finding answers is simple, all you need to do is come up with the correct questions.