Strange Warning with DataStage 5.2.2 on SUN Solaris

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
afortmann
Participant
Posts: 6
Joined: Wed Apr 02, 2003 6:53 am
Location: Austria
Contact:

Strange Warning with DataStage 5.2.2 on SUN Solaris

Post by afortmann »

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
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Variable not assigned in Routine.

Post by ray.wurlod »

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.)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
afortmann
Participant
Posts: 6
Joined: Wed Apr 02, 2003 6:53 am
Location: Austria
Contact:

Re: Variable not assigned in Routine.

Post by afortmann »

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".

:?:
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.)
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Bulletproofing Routines

Post by ray.wurlod »

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)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
afortmann
Participant
Posts: 6
Joined: Wed Apr 02, 2003 6:53 am
Location: Austria
Contact:

Re: Bulletproofing Routines

Post by afortmann »

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 :roll:
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)
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply