DSXchange

Varun,

if your pad character is the default value of 0x00 then the answer I supplied in the previous post will do what you asked for.

Varun, DB/2 is most likely using 0x000 to pad the char fields unless you've explicitly made it do something else, for instance by changing the $APT_STRING_PADCHAR. Since the target column is also a fixed length character field, you normally don't need to do anything here; but if you want to explicit...

Hello Varun,

start off with telling us the source data type, the target data type and what you have tried so far. Then someone here can perhaps make a suggestion.

The macros ought to work, but I think you have missed one "#" in your code, it should read

Hello vick, Willkommen to DSXchange. Offhand I would assume that the data declaration in DataStage is smaller than that declared in Oracle. Can you compare your DDL with metadata declarations? Have you changed your DataStage job by successively removing columns until you have found out which column ...

Wahil, Since the problem is difficult to localize, can you take out the the DB/2 write stage and test to see if that might be causing your problems in the non-development environments? Are you writing to the same DB/2 instance in development? Can you monitor the database locks or have the DBA to thi...

The separator that DataStage uses with composite hashed file keys is the @TM (text mark). So if in a DataStage job you have a composite key for Country and City and you wish to read this record from a BASIC program, you would use a key value such as 'London':@TM:'England' to get a record.

No, this is a new observation.

What does a diff show is the per line difference?

According to your columns, you should have 76 bytes of information on that line, but the line read from the file contained 77 bytes. So you have a discrepancy between your metadata and data. Once you discover where your problem lies you can modify that column description. When data comes from mainfr...

Mark Balwin, is that you posting under Ray's name? I'd recognize that sense of humour anywhere

Rao, Transform stages in Px can and should be avoided where possible. That is why Jay asked if it could be done any other way - the modify and copy stages are the most likely candidates; but the INDEX function isn't built into either of them, and their intrinsic function sets are more geared toward ...

I took a look at the functions available to you in a modify stage and there is nothing that will do this for you on a numeric datatype. I would use a transform stage and (if it is a string datatype) using the FIELD function; if it is a decimal field then INT() and ({Original}-INT({Original})*{precis...

Maryann,

can you modify your job to see which part of the OR isn't working as expected? My suspicion is that the

(ENDOFDATA IS FALSE)

part isn't doing it - but it is unfounded and I don't have a 390 to try out.

By default read-only objects are omitted (you can change that in the options for your export). The read-only objects in question are probably all of the built-in DataStage objects and can be safely ignored. Unless you specifically marked some of your DataStage objects as "read only" and need them yo...

Could you post your config file, and also check to make sure that all the paths in Node2 actually exist and have appropriate permissions set?