Error: code=-99 [General repository interface 'other error']

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
atan003
Participant
Posts: 14
Joined: Mon Nov 13, 2006 12:55 am

Error: code=-99 [General repository interface 'other error']

Post by atan003 »

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.
narasimha
Charter Member
Charter Member
Posts: 1236
Joined: Fri Oct 22, 2004 8:59 am
Location: Staten Island, NY

Post by narasimha »

Similar problem here

This could be a start to resolve your issue.
Narasimha Kade

Finding answers is simple, all you need to do is come up with the correct questions.
atan003
Participant
Posts: 14
Joined: Mon Nov 13, 2006 12:55 am

Thanks

Post by atan003 »

Thank you very much.
narasimha
Charter Member
Charter Member
Posts: 1236
Joined: Fri Oct 22, 2004 8:59 am
Location: Staten Island, NY

Post by narasimha »

Nice :D
Narasimha Kade

Finding answers is simple, all you need to do is come up with the correct questions.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

For future reference note that address 0x80000000 is 2GB.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
narasimha
Charter Member
Charter Member
Posts: 1236
Joined: Fri Oct 22, 2004 8:59 am
Location: Staten Island, NY

Post by narasimha »

ray.wurlod wrote:For future reference note that address 0x80000000 is 2GB.
Wow thats new to me!
Just curious Ray, how can we associate same address (0x80000000) to different 2GB files created.
Narasimha Kade

Finding answers is simple, all you need to do is come up with the correct questions.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

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".
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
narasimha
Charter Member
Charter Member
Posts: 1236
Joined: Fri Oct 22, 2004 8:59 am
Location: Staten Island, NY

Post by narasimha »

Sorry about that dumb question, maybe I did not put it right. :oops: I was looking for something like this link
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.
I guess now I am clear with it.
Thanks!
Narasimha Kade

Finding answers is simple, all you need to do is come up with the correct questions.
Post Reply