hashcount error
Moderators: chulett, rschirm, roy
hashcount error
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.
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.
You do not have an ELSE clause if your OPENPATH statement fails. In that case, you never assigned RecordCount a value.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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.
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.
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...ray.wurlod wrote: Finally, routines must always return. Never, ever, use DSLogFatal, Stop or Abort in routines.
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
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.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....
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.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
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!
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!
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.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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!
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!
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.
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
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.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!
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle