Finding whether a Feild is null or not

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
hexa
Participant
Posts: 51
Joined: Sun Aug 08, 2004 6:25 am

Finding whether a Feild is null or not

Post by hexa »

Hi friends,

I want to write a before subroutine that finds out whether a field is null or not and if it is null then gives the field a value =0

i have written the following code

OPENSEQ "D:\DS325Files\SalesRecord.txt" TO H.LKEY
ELSE
ErrorCode = 1
Call DSLogInfo("Error in Open","TransformationJobs")
ABORT
END
LOOP
READ File.Rec FROM H.LKEY
ELSE
ErrorCode = 1
Call DSLogInfo("Error in Read","TransformationJobs")
ABORT
END

IF ISNULL(Field(File.Rec,",",3))
THEN
**********************
END
ELSE
ErrorCode = 1
Call DSLogInfo("Error in write","TransformationJobs")
ABORT
END
REPEAT
CLOSESEQ H.LKEY

ErrorCode = 0; * set this to non-zero to stop the stage/job

I want to know the syntax for giving the feild a value = 0
i am not clear abt the syntax to be put in *******

Can anyone guide

Thanks
tonystark622
Premium Member
Premium Member
Posts: 483
Joined: Thu Jun 12, 2003 4:47 pm
Location: St. Louis, Missouri USA

Post by tonystark622 »

hexa,

I'm not sure I completely understand, but I'll give it my best shot.

I don't understand why you would want to do this in a Before Routine. I would put it in the Derivation for the field on the output link.

The logic would be something like:

Code: Select all

If Not(IsNull(InputLink.FieldName)) Then InputLink.FieldName Else 0
Hope this helps. If I've completely missed your point, please explain further and I'll try to help.

Tony
hexa
Participant
Posts: 51
Joined: Sun Aug 08, 2004 6:25 am

Finding whether a Feild is null or not

Post by hexa »

Hi!

I need to use the routine. Its a must :(
I know there are other easier ways of doing it but i need to do it in basic

Anyway Thanks for ur reply and guide me if possible
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

All questions about why it's a "must" and you "need" to do it this way aside... :?

It seems to me your question is not so much about determining if a field is null or not. That's simple and no different than you'd do in a Derivation inside a job.

What it looks to me what you are doing is reading a flat file and wanting to update the record/field in the same flat file with a zero if it is null. If so, then the answer is no. What you can do is read it in and write it out to a new version of the file with the changes made to those fields. Then, if you wanted, remove the original file and rename the new file to the old name.

So much simpler to handle this inside a job. Perhaps you could share what problem you are trying to solve and people here could then provide you with alternative approaches or solutions. Another pair of eyes and all that.

ps. You'll need to use READSEQ, not READ. WRITESEQ is another thing you'll need. WEOFSEQ may come in handy, as well as the SEEK command, possibly. Check your BASIC manual. And me, personally... I would never code an ABORT into something like this.
-craig

"You can never have too many knives" -- Logan Nine Fingers
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Technically it's not possible in a before-stage subroutine because the first row in a stream has not been processed when the before-stage subroutine is executed.

Do you mean null in every row, null in any row, null in the first row?

How is NULL represented in this particular text file. A zero-length string is not, in and of itself, the same thing as NULL; "" is a known value, NULL is not. By default, the Sequential File stage maps "" to null, but this is only a default and can be changed on the Format tab.

Have you really thought this through? Can you post your algorithm design and test plan? This may make it easier to assist you.
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