Exception raised in GCI subroutine:

vinaypothnis · Post by **vinaypothnis** » Thu Dec 05, 2002 11:23 pm

hi all,

i am getting this error message :

Exception raised in GCI subroutine:
Access Violation

Can you please tell explain what this meassage means and what might be wrong?

Thanks and regards
Viany

ray.wurlod · Post by **ray.wurlod** » Thu Dec 05, 2002 11:35 pm

GCI is an acronym for General Call Interface, a mechanism that allows DataStage (which is an environment with no data types) to call functions written in strongly typed languages, typically C.

Access violation is an attempt to make reference to a memory address that is not in the executing process's memory space.

The most common cause of access violation in DataStage is an attempt to put something too large into an allocated area of memory; for example 15 characters into a Char(12) data type, or the sum of SmallInt exceeding the size of a SmallInt in an Aggregator stage.

Many functions associated with DataStage stage types use GCI; chances are that it is one of these that has generated the error. However you have not provided full text of logged warnings to enable more precise diagnosis.

vinaypothnis · Post by **vinaypothnis** » Fri Dec 06, 2002 12:33 am

Hi Ray,

Thank you for ur time.
This is the complete error message i got.

DataStage Job 19 Phantom 1964
Program "DSP.ActiveRun": Line 51, Exception raised in GCI subroutine:
Access violation.
Attempting to Cleanup after ABORT raised in stage CopyOfpocXML..XMLInput1
DataStage Phantom Aborting with @ABORT.CODE = 3

Is it now possible to diagonise the error now?

Thanks and regards,
Vinay

ray.wurlod · Post by **ray.wurlod** » Fri Dec 06, 2002 3:57 pm

Well, we can certainly get a bit closer. @ABORT.CODE is just a system variable that suggests why the abort occurred (for example ABORT statement in BASIC, user-initiated, inactivity timeout, or external condition). @ABORT.CODE = 3 indicates an external (non-BASIC) condition.
Job 19 indicates that the error occurred in job number 19 (mapping from job names to job numbers is in the DS_JOBS table, however I am sure you already know the job name). Phantom 1964 tells you the user number (= pid on Windows) of the background process ("phantom" is a DataStage term meaning background process) in which the error occurred.
This process was doing something with the stage XMLInput1, which the name suggests is an XML reader stage. Something, probably in the data, has upset this stage, presumably by failing to match the metadata.
You can determine - for example from Monitor - how many rows had been processed when the error occurred, to help you to narrow down in which row of the input stream the error was triggered. After that you have to (manually) identify whether any data violate the metadata, particularly data that are too large.
If you can't find any such data there *may* be a bug in the XML reader stage; contact Ascential. However, the paucity of reports of such bugs suggests to me that the problem is either in your data or your configuration.
Were there any prior warnings in the job log, other than the one you have provided? In particular, were there sufficient warnings to trigger the "abort job after N warnings" behaviour?
Hope this helps.

vinaypothnis · Post by **vinaypothnis** » Mon Dec 09, 2002 12:36 am

Thanks a lot Ray...

We had contacted Ascential and it seems that it may be a bug.

Thanks for all the info about metadata mismatch.

Regards,
Vinay