Sporatic Phantom Error

itcconsulting · Post by **itcconsulting** » Tue Jul 21, 2009 2:29 pm

Recently I converted a hashed file from 32 bit to 64 bit. This changed was prompted by an increase in data volume. Prior to converting the file to 64 bit I confirmed that it only contained the required keys and data (2.7 GB). This file is used in a major ETL process. Since the conversion to 64 bit the process sporatically aborts with the following error in the log:

Code: Select all

DataStage Job 5398 Phantom 2320
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Program "JOB.1557032271.DT.1516832810.TRANS2": Line 609, Read operation failure.  [EINVAL] Invalid argument
Job Aborted after 10 errors logged.
Attempting to Cleanup after ABORT raised in stage FSU_J_Fact_PS_FSU_F_LEDCONSOL_LOAD_GL..DRS_PS_FSU_F_LEDCONSOL_INSERT
DataStage Phantom Aborting with @ABORT.CODE = 1

As a related post recommended, I have reviewed the BASIC code that is referenced and can't identify any issues. This code from RT_BP5398 TRANS2 file (lines 591 - 613) are included below:

Code: Select all

WHILE NOT(ERROR)
	* Primary Key derivation code for pin HASH_FSU_F_LEDCONSOL_Exists
	STAGECOM.PINNO = 2
	    IF STAGECOM.TRACE.STATS THEN CALL $PERF.BEGIN(-3)
	Pin%%V0S87P7.Column%%1 = Pin%%V0S87P11.Column%%1
	Pin%%V0S87P7.Column%%2 = Pin%%V0S87P11.Column%%2
	Pin%%V0S87P7.Column%%3 = Pin%%V0S87P11.Column%%3
	Pin%%V0S87P7.Column%%4 = Pin%%V0S87P11.Column%%5
	Pin%%V0S87P7.Column%%5 = Pin%%V0S87P11.Column%%7
	Pin%%V0S87P7.Column%%6 = Pin%%V0S87P11.Column%%10
	Pin%%V0S87P7.Column%%7 = Pin%%V0S87P11.Column%%11
	Pin%%V0S87P7.Column%%8 = Pin%%V0S87P11.Column%%13
	Pin%%V0S87P7.Column%%9 = Pin%%V0S87P11.Column%%14
	Pin%%V0S87P7.Column%%10 = Pin%%V0S87P11.Column%%17
	Pin%%V0S87P7.Column%%11 = Pin%%V0S87P11.Column%%25
	Pin%%V0S87P7.Column%%12 = Pin%%V0S87P11.Column%%26
	Pin%%V0S87P7.Column%%13 = Pin%%V0S87P11.Column%%27
	    IF STAGECOM.TRACE.STATS THEN CALL $PERF.END(-3)
	GET.Pin%%V0S87P7
	* Stage variable evaluation
IF STAGECOM.TRACE.STATS THEN CALL $PERF.BEGIN(-4)
	V0S87.Stagevar%%1 =  IF (Pin%%V0S87P7.REJECTEDCODE EQ DSE.EOF) THEN 'Y' ELSE 'N'
IF STAGECOM.TRACE.STATS THEN CALL $PERF.END(-4)

The sporatic failure occurs during the nightly batch. However when I run the process individually it completes successfully. Could someone please shed some light as to what could be the culprit?

ray.wurlod · Post by **ray.wurlod** » Tue Jul 21, 2009 4:37 pm

Use fixtool (without a -fix option) to verify that the hashed file is not corrupted.

itcconsulting · Post by **itcconsulting** » Thu Jul 23, 2009 4:02 pm

Thanks Ray!

I ran the fixtool and received following:

Code: Select all

F:\Ascential\DataStage\Projects\FSCM9_EPM9_SPRDDW>F:\Ascential\DataStage\Engine\bin\fixtool -level 3 -file HASH_FSU_F_LEDCONSOL_EX
ISTS
Filename: HASH_FSU_F_LEDCONSOL_EXISTS

Start Diagnostics.
        0 Errors found in physical structure.
        0 Errors found in file header.
        0 Errors found in file groups.
        14532 Other errors found in file.

        13974446 records processed.

        14532 errors found.
Fixtool Completed.

I then ran the process again without the -fix switch but zero errors were found. Is this normal? I thought the the fixtool requires -fix for it to actually fix the errors found.

Althought I still have open questions I'd like to report that since I executed the fixtool on the this hashed file I have not experienced the Phantom error (knocking on wood).

ray.wurlod · Post by **ray.wurlod** » Thu Jul 23, 2009 4:57 pm

You've got me. The fixtool utility is supposed to operate in read-only mode - that is, it is not supposed to change the hashed file structure at all (except for updating certain counters and pointers - call them "the statistics" if you like). It may be that these were out of date and generating the spurious error messages. But that's only my guess.

itcconsulting · Post by **itcconsulting** » Fri Jul 24, 2009 6:50 am

Okay. Could the fact that these files are 64 BIT instead of 32 BIT have something to do with it.? I know that the UVFIXFILE is only operational on 32 BIT files. Could this be the case with fixtool.exe?