DSXchange

In BASIC it would be along the lines of ConnectCommand = 'DB2 CONNECT to ':YourServer:' USER ':YourUser:' USING ':YourPassword QueryCommand = 'DB2 SELECT MAX........' EXECUTE ConnectCommand CAPTURING ScreenIO RETURNING ErrorCode ** and so on

The error message goes a long way to explaining your problem. Your metadata for "Postcode" specifies a length that is shorter than the actual data contents for the field, hence the error message.

Hmmm, don't see how a routine will be any faster than doing a singleton lookup. But you can achieve the calls by writing a routine that does a command line "DB2 CONNECT" and then executes the "DB2 {command}" and parses the captured output and passes the returned value back to the calling program.

pratyusha - normally your analysis is correct, but note that the original poster stated that the reference contained only 1 record as well, which is why I asked for a bit more information.

Why not use a DataStage server job to do this instead of writing a routine? You can use DS in several ways to effect this. A lookup stage with custom SQL is the first and easiest method that springs to mind.

Remember that if you use the COMMON block method as described above you will need to ensure that you declare your job to not use row buffering or use in-process buffering. If you do not do this, the separate TRANSform stages are started as separate processes and thus won't share the same COMMON bloc...

What do you mean by "count of entries"? Do you mean the number of log file entries for a job run?

Could you explain your lookup - what kind of object are you referencing and is your lookup key actually a key in the referenced object?

somu_june wrote:...when I try to use this file to join with other file to load in to a single file I am getting the same warning in this job...

What size and type is the other file?

If you run the job as only one instance/node does it still abort writing the sequential file and what size does that file grow to before the job aborts?

Are you sure your data size isn't "1310720"? Anyway, I think you should add a before-job call to execute the "ulimit -a" command to see if your runtime attributes are the same as those you've displayed in your post.

Thanks for the comments! I was at the Antigua Cricket Grounds and the "Sticky Wicket" bar/restaurant less than 48 hours ago, otherwise I wouldn't have recognized the term and would have thought "deep sixer" - which means something totally different.

Hallo Wolfgang & others; I just got back from being a bum in the Caribbean. Last night was the first time in a month that I slept in a bed on Terra Firma and it is strange to wear shoes and long pants again... I was sailing around and enjoying vacation - but I did have trouble connecting to the ...

What kind of an abort did you have? Normally the executable finishes with the job; perhaps the uvsh.exe you see belongs to another process or user. If you have access to the UNIX truss command you could try to trace what the "rogue" uvsh.exe is actually doing.

Do all your hashed files have the same or similar numbers of columns? If yes it is very easy to write a generic job to dump all hashed file contents to flat files.