DSXchange

To add to what Ray has stated, the 64BIT option is not available from the hashed file stage creation menu. This can only be done from the TCL or UNIX level.

Perhaps the hashed file is broken. Do you have the "clear file" switch turned on in your job? If not, could you try setting it to see if the error goes away (if you can easily re-create the data).

I rather enjoyed writing that answer; it is more fun to say "that's easy to do" than having to explain that it can't be done. Just add the column to the end of your metadata (not anywhere else, as hashed files are positional). This is one of the aspects of hashed files and the UniVerse system which ...

Just "do it". You can add columns to hashed files without any problems. All values for all records existing in the file are going to be the empty string, but that is the only issue you should have.

Always have a complete backup before trying anything that might compromise the installation. I would do a complete backup of all the projects. That way, if this doesn't work you can do a complete re-install with the new license key. When you reinstall you can specify the project paths to the existi...

Unfortunately, there is no builtin or documented way to do this dynamically. The column information is stored in the job details and (if used) in the table definitions file. Neither location is documented or described by Ascential. Instead of "hacking" that information from the repository, could you...

You might also do this from UNIX level. Ensure your "dsenv" is set and that your current working directory is $DSHOME, then issue a

DataStage server is not restricted when it comes to data types. There is no "CHAR" datatype inside DS server, everything is a string. If you read a string with length of 5 into DS and write it to a sequential file with a type of CHAR(10) it will not automatically convert that string and pad it with ...

If you are at version 7.5 you should be able to change all the licensing information from the Administrator.

In DataStage server jobs, the lookup is done via a reference link in a transform stage.

I just re-read your post and saw that you are using INFORMIX. You need to use the internal date format, so just the ICONV() part to convert your date.

I've not seen that error message before. Can you go into your director and "reset" this job; chances are high that you will have an entry title "from previous run" in your log file after doing this and that it might contain additional information.

OCONV(ICONV(In.DateStringColumn,'D4MDY'),'D4/DMY[2,2,4]') Note that this does not check for valid dates. Or, as a string solution, In.DateStringColumn[4,3]:In.DateStringColumn[1,3]:In.DateStringColumn[7,4] The latter is faster as it just manipulates string portions.

You should do this checking in a sequence. You can write your own routine using the following logic:

- call DSAttachJob() to attach to the job
- call the routine DSGetJobInfo() with DSJ.JOBLASTTIMESTAMP
- call DSExecute() to return the file date/timestamp
- compare

Remember to handle the popular "Llada 4.3L Turbo Tractor" as well.