DSXchange

I'm running 7.5.1A. Smells like a 7.5.2 bug and maybe something they fixed in 7.5.3, but you'd have to ask IBM that to find out.

Mine sure won't behave in that manner. What exact 7.x version do you have?

Why the heck not? Push back on stupid and arbitrary limitations like that that hobble your ability to do your job.

There ya go.

Or just a Server job with a hashed file being read from and written to by the same transformer. Easy Peasy.

cherry wrote:I have enough space in the specified drive.

No, you don't. Or didn't.

You need to be more than 'pretty sure', you need to be certain. What does the file look like if you open it in 'vi', type a colon and then "set list"?

No. What kind of 'join' are you doing in the Merge stage? My preference is to load the files into work tables in my database of choice and do the join there.

It should have been changed automatically and if it hadn't it wouldn't compile, so more than likely something else is going on.

The Merge stage uses hashed files under the covers so if I had to hazard a guess, I'd say you've hit the 2GB barrier. You'll need to use a different method for those kinds of volumes.

No clue, but you could Google for it or ask your Sybase DBA. Seems like it could be a "database log almost full" message, from what I saw out there.

Or 'null'.

Resource problem? Don't ask exactly what resource, just seems like a reasonable stretch to me as I found some mention of UniData and shared memory segments mentioning an errno=24. Edited to add: Ray, aren't you supposed to be either in a lecture or out enjoying the sights and sounds of Sin City?

All entries? Is that safe or should it be more of a tactical strike?

Didn't ask "where" but rather "what". Regardless, you'll need to roll your own - and if you can do that in DS BASIC, then a transformer routine is in your future. Otherwise, it may be more... problematic. I've integrated with Java-based MD5 encryption in "batch" mode - dump records to a file with th...