Errors from custom routine but only when running job

[RodBarnes]

[I've seen several of these type of posts but none helped to explain how to associate the error statements with the actual values. ]

Are the line numbers (below) references into the DS generated code (i.e., the stage module in RT_BP1131)? If so, the line numbers don't match up with anything that makes sense. Is there an offset that I need to figure in when looking at the lines? I can easily find the DEFFUN line and the line where the function is used. But I can't make any sense out of the errors.

The error lines all appear under the same log entry "DataStage Job 1131 Phantom 1836" so that leads me to believe it is not row specific. However, there are 996 error lines so that makes me think it is row specific.

Testing the routine directly, I haven't been able to do anything that makes it produce these errors. I assume it must be something that happens in the interface between the routine and generated code.

I tried running it with the limits set to abort upon first error (thinking that might help me pin down a culprit) but that didn't make any difference; I got the same output when running the job.

Ideas?

Code: Select all

Project:Orbit_rod (plzatdev002)
Program "DSU.ConvertIP": Line 73, Nonnumeric data when numeric required.  Zero used.
...
Program "DSU.ConvertIP": Line 130, Nonnumeric data when numeric required.  Zero used.
Program "DSU.ConvertIP": Line 130, Nonnumeric data when numeric required.  Zero used.
...
Program "DSU.ConvertIP": Line 73, Nonnumeric data when numeric required.  Zero used.
Program "DSU.ConvertIP": Line 73, Nonnumeric data when numeric required.  Zero used.
...

[ArndW]

Yes, the line numbers are referring to the generate code. And yes, there is an offset that sometimes needs to be applied. Ever since the dawn of time (well, call it 1982 when I started using UniVerse) there has been an issue with the compiler getting its line numbers incorrect on some lines (stupidly, it has issues with lines over 255 bytes and miscounts). So you need to look up a couple of lines and this error you are getting is going to be pretty clear once you have identified the line since you are going to have some sort of operation or argument to a function where a number is expected and you are using a value passed in as a paramter or generated from the. Since you know your data, you could always just pass those values in from a test run in the manager as well.

Another approach is to look at the generated pseudocode using the VLIST command, this will tell you the 'correct' line number for the command, but you will need to decode the pseudocode ops (very similar to simple mode assembler). I wouldn't recommend going that far.

[ray.wurlod]

You'll probably find that the line number (plus or minus a few, depending on how many header files have been $INCLUDEd) refers to the line in the code generated by the Transformer stage in which your routine (ConvertIP) is called.

Put a test into ConvertIP that uses the Num() function to check that a numeric value has been passed.

[RodBarnes]

Well, of course after creating a very large post explaining everything, I actually found a couple rows with data that were causing the error. They weren't null or empty but had content that couldn't convert to numeric. Yeah, I know... Sheesh...

Thanks to both for the info.

P.S. I did learn that the line number is actually referencing the internal of my routine. Just doesn't do it any more accurately than other variants of Pick I've been familiar with over the years.