Anyone seen this one or a similar one?
Program "DSU.nmz": Line 2, Variable previously undefined. Zero length string used.
It's strange because when I copy the jobdesign, compile the copy and debug the copy, I don't get the warning (same dataset used for the job as for the copy).
Any help for that one around ???
Would be greatly appreciated !
BTW - this is a known one to 5.1 release and should be fixed in 5.2.2:
>Topic:
>Variable "Pin%%V0S8P3.REJECTEDCODE"previously undefined. Zero >used.
>Product: DataStage
>Release: 5.1A
>Date Entered: 05/22/2002 Fixed in Release: 5.2r2,5.2.1,6.0
>Date Closed: 12598,12598,12598
>Full Description:
>The job has enable transaction grouping- receive
>warning
>Program "JOB.1638052852.DT.1251464021.TRANS5":
>Line 396, Variable "Pin%%V0S8P3.REJECTEDCODE"
>previously undefined. Zero used.
>Resolution:
>Fixed compiler to preinitialise variables
thx,
afortmann
Strange Warning with DataStage 5.2.2 on SUN Solaris
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Variable not assigned in Routine.
Don't think that's related to the fix you quoted.
DSU.nmz refers to a Routine called nmz. It's in this Routine (in line 2) that the problem is occurring. Find it in the Routines branch of your repository, and identify a variable name being used as an rvalue, but which does not have a value assigned.
For example, an expression such as variable += 1 will generate this error because variable has not yet been assigned any value. It may be as simple as a mistyped variable or argument name.
(The "DSU" prefix stands for "DataStage User-written" Routine.)
DSU.nmz refers to a Routine called nmz. It's in this Routine (in line 2) that the problem is occurring. Find it in the Routines branch of your repository, and identify a variable name being used as an rvalue, but which does not have a value assigned.
For example, an expression such as variable += 1 will generate this error because variable has not yet been assigned any value. It may be as simple as a mistyped variable or argument name.
(The "DSU" prefix stands for "DataStage User-written" Routine.)
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.
Re: Variable not assigned in Routine.
Ray, thanks for the answer.
The routine itself is quite simple - here's the source:
FUNCTION nmz(Arg1)\(D)\(A)if isnull(Arg1) or (Arg1='') then Ans='-0|' else Ans =Arg1 : '|'\(D)\(A)RETURN(Ans)
Can be tested, returns expected values (i.e. -0| for NULL or empty Arg1).
The job that uses this routine (to calculate crc32-values of several concatenated nullable values) runs without errors in debug mode and raises the described warning when invoced in "normal batch processing".
The routine itself is quite simple - here's the source:
FUNCTION nmz(Arg1)\(D)\(A)if isnull(Arg1) or (Arg1='') then Ans='-0|' else Ans =Arg1 : '|'\(D)\(A)RETURN(Ans)
Can be tested, returns expected values (i.e. -0| for NULL or empty Arg1).
The job that uses this routine (to calculate crc32-values of several concatenated nullable values) runs without errors in debug mode and raises the described warning when invoced in "normal batch processing".
ray.wurlod wrote:Don't think that's related to the fix you quoted.
DSU.nmz refers to a Routine called nmz. It's in this Routine (in line 2) that the problem is occurring. Find it in the Routines branch of your repository, and identify a variable name being used as an rvalue, but which does not have a value assigned.
For example, an expression such as variable += 1 will generate this error because variable has not yet been assigned any value. It may be as simple as a mistyped variable or argument name.
(The "DSU" prefix stands for "DataStage User-written" Routine.)
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Bulletproofing Routines
From the code it looks like the only variable that could be unassigned is Arg1. Somehow or other the variable used as the argument in the calling routine (that is, the code generated by the Transformer stage, not one of yours) has managed to create a code path that fails to assign - presumably the column value - to the argument.
Get around this by "bulletproofing" your routine code with an extra test using the Unassigned() function.
Get around this by "bulletproofing" your routine code with an extra test using the Unassigned() function.
Code: Select all
FUNCTION nmx(Arg1)
if Unassigned(Arg1) or IsNull(Arg1) or Arg1="" Then Ans = "-0|" Else Ans = Arg1:"|"
RETURN(Ans)
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.
Re: Bulletproofing Routines
Ray, many thanks for the help!
Problem is solved.
BTW: Added the Unassigned(Arg1) - Check to the routine, Job still produced the same warning. Had a closer look to the Calling Statement in the Job itself and found an unresolved link to a parameter from the input-link (well hidden in a crc32(...) statement with 16 parameters) ...
Still wondering why that job didn't produce the warning in debug mode, though
Problem is solved.
BTW: Added the Unassigned(Arg1) - Check to the routine, Job still produced the same warning. Had a closer look to the Calling Statement in the Job itself and found an unresolved link to a parameter from the input-link (well hidden in a crc32(...) statement with 16 parameters) ...
Still wondering why that job didn't produce the warning in debug mode, though
ray.wurlod wrote:From the code it looks like the only variable that could be unassigned is Arg1. Somehow or other the variable used as the argument in the calling routine (that is, the code generated by the Transformer stage, not one of yours) has managed to create a code path that fails to assign - presumably the column value - to the argument.
Get around this by "bulletproofing" your routine code with an extra test using the Unassigned() function.Code: Select all
FUNCTION nmx(Arg1) if Unassigned(Arg1) or IsNull(Arg1) or Arg1="" Then Ans = "-0|" Else Ans = Arg1:"|" RETURN(Ans)
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Thanks for the feedback.
The Debugger does have the tendency to make sure all variables are assigned, so that it can do what it does. The process of preparing them for potential inclusion on a watchlist has this effect.
The Debugger does have the tendency to make sure all variables are assigned, so that it can do what it does. The process of preparing them for potential inclusion on a watchlist has this effect.
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.