hashcount error

nag0143 · Post by **nag0143** » Wed Apr 14, 2004 6:34 am

When I am counting hashfile records ... why i am getting this following error in my routine

OpenPath "Path/HF" To HF.fvar
Then
RecordCount = 0
Select HF.fvar
Loop
While ReadNext ID
RecordCount += 1
Repeat
Close HF.fvar
End
Ans = RecordCount

error:
TEST #1
*******

Arg1 = /dvl/etledw2/data/edwint/Hash
Arg2 = UDBEDWtccdmbrakaDELissue.hsh

Test completed.

Result = Program "TSThc.B": Line 4, Variable "ANS" previously undefined. Empty string used.

kcbland · Post by **kcbland** » Wed Apr 14, 2004 6:58 am

You do not have an ELSE clause if your OPENPATH statement fails. In that case, you never assigned RecordCount a value.

ray.wurlod · Post by **ray.wurlod** » Wed Apr 14, 2004 4:17 pm

When writing DataStage routines whose type is "transform function", every path through the code must cause the Ans variable to have a value set.
In your code you could initialize the RecordCount variable ahead of the OpenPath statement. However, this could be misleading if initialized to zero. Better would be to initialize it to -1 (an impossible count).
Ken's suggestion is best; you really should code to handle all possible error conditions, since DataStage jobs run as background processes (that is, unattended).
Finally, routines must always return. Never, ever, use DSLogFatal, Stop or Abort in routines.

nag0143 · Post by **nag0143** » Thu Apr 15, 2004 7:35 am

ray.wurlod wrote: Finally, routines must always return. Never, ever, use DSLogFatal, Stop or Abort in routines.

I am curious why shouldn't i use DSLogFatal, Stop or Abort in routines in the routines ... mainly in my case if i found zero records anyhow i need to abort the job...
and also instead of writing a basic routine to check for zerorecords in a file can i do the same using @INROWNUM OR @OUTROWNUM ... what is the difference between 2 methods....

Thanks
Nag

kcbland · Post by **kcbland** » Thu Apr 15, 2004 7:47 am

nag0143 wrote: I am curious why shouldn't i use DSLogFatal, Stop or Abort in routines in the routines ... mainly in my case if i found zero records anyhow i need to abort the job...
and also instead of writing a basic routine to check for zerorecords in a file can i do the same using @INROWNUM OR @OUTROWNUM ... what is the difference between 2 methods....

In your case, the effect accomplishes what you desire. But in most cases, people don't want the job to blowup. You should set the return code so that the job dies because the return value is non-zero, rather than you blowup the job yourself.

As for @INROWNUM and @OUTROWNUM, those are variables local to each transformer stage and not accessible to BEFORE/AFTER routines without doing some monkey business, which I won't recommend or describe.

deep · Post by **deep** » Thu Apr 15, 2004 2:06 pm

HI

I have a routine(I call it fom the Transformer) which checks the validity of a coulmn and call Abort if the value of the column is not valid.
The Business Requirement is to error out the job if we get a invalid value without any further processing.

Ray has mentioned that it is not a good practice,so i was wondering if you can suggest some other way to do this.

Thank You!

kcbland · Post by **kcbland** » Thu Apr 15, 2004 2:10 pm

Put your verification as the derivation in a stage variable. Then, use the stage variable in the constraint to an exception link. In the exception link, capture the offending row to a file for review. Set the abort job row limit in the constraint to 1. The first row to qualify for that link will abort the job for you using inherent functionality.

ray.wurlod · Post by **ray.wurlod** » Thu Apr 15, 2004 3:55 pm

Essentially, my recommendation was because it's a decided nuisance to have to reset jobs.
I prefer that the controlling job can retain control, report anything that needs to be reported can be reported, and perhaps even other tasks executed to remedy a situation that might otherwise have generated an apparent need to abort.
We have the technology! We can build it!

deep · Post by **deep** » Thu Apr 15, 2004 4:31 pm

Thanks Kenneth and Ray!

We avoid having stage variable solutions if possible b'coz the code is not re-usable.Actually the Routine does a lot of verifications(lengthy code) and its kinda hard to implement it as a stage variable.

Anyway, now that Ray has passed it,I will use it in peace

regards

ray.wurlod wrote:Essentially, my recommendation was because it's a decided nuisance to have to reset jobs.
I prefer that the controlling job can retain control, report anything that needs to be reported can be reported, and perhaps even other tasks executed to remedy a situation that might otherwise have generated an apparent need to abort.
We have the technology! We can build it!

kcbland · Post by **kcbland** » Thu Apr 15, 2004 7:33 pm

deep wrote:Thanks Kenneth and Ray!

We avoid having stage variable solutions if possible b'coz the code is not re-usable.Actually the Routine does a lot of verifications(lengthy code) and its kinda hard to implement it as a stage variable.

Anyway, now that Ray has passed it,I will use it in peace

regards

ray.wurlod wrote:Essentially, my recommendation was because it's a decided nuisance to have to reset jobs.
I prefer that the controlling job can retain control, report anything that needs to be reported can be reported, and perhaps even other tasks executed to remedy a situation that might otherwise have generated an apparent need to abort.
We have the technology! We can build it!

My suggestion did not say to stop using your routine. I said to PUT YOUR ROUTINE CALL INTO THE DERIVATION of the stage variable, not put your logic into the derivation of the stage variable. Please re-read my suggestion, as it should now show you that it's a pretty darn good one if I may say so.