DSXchange

The line numbers alone will tell you that something is missing. Investigate what is not in the file compared to what's received from the mainframe.

I can also ship DSXchange Learning Center DVDs. The price is the same whether shipped from USA or Australia. Postage is included.

DRSET is a variable that, presumably, had its value set earlier in your routine. @FM is a system variable that contains the value of "field mark", the top-level field delimiter in records in hashed files (the local job logs are hashed files). "//PURGE.SETTINGS" is the record ID o...

Kel wrote:Cant find anywhere else to ask for help.

How about your official support provider?

Rather than rely on us to spoon-feed you a solution, please suggest what YOU have tried, and allow us to guide you. There are probably several solutions - I would tend to one that encoded the CODE field into a sortable value, sort by that value, then use a Remove Duplicates stage. Paying close atten...

It's normal behaviour for DataStage. If even one field does not conform to the metadata, then it cannot be certain that subsequent fields are being correctly parsed. So the default behaviour for DataStage is to drop the record. If you really want, you could read the file using a Sequential File stag...

The code snippet you posted changes the purge settings for one job's log file only. To change all jobs you would need to run the same code against every job's log.

Yes. Use the HDFS stage.

You could use the IsValid() function to filter records in which the incoming value is convertible to Decimal data type. "DU 2015F21" is not one of this class. You need to design a strategy to capture and process invalid data, even if it's only to initiate remediation of source data.

No.

You are connecting to Cache, which is itself returning an error (code 452).
Consult your Cache documentation to learn what error code 452 means. It might also suggest remedial action.

At a guess, based on the error message that you posted, the issue is likely to be a permissions error with the reporting directory /tmp/InformationServer

The load side probably not, as noted, but you could certainly use RCP on the read side. You would have to make very sure that, at whatever point you transition to not using RCP (possibly a Transformer or Copy stage) that you have sufficient columns named identically to those required on the output.

That character is not covered by ASCII, even extended ASCII. Therefore you would need NLS enabled, and to use a map that handles the character - perhaps ISO8859-15.

That solution would involve n! schema files to accommodate every possible schema file. 10! = 3,628,800.