DSXchange

So Craig, by resetting the job that job will run again when the sequence is fired ?
Isnt the checkpoint history recorded by the sequence ? and if you mean resetting the sequence thats as good as compiling and again will inturn lose the checkpointed history. Me confused

sudhakar_viswa wrote:Hi,

Invalid timestamp value in getInputFieldAsString()for field '9'
sudhakar

The hint is right there in the warning message. The timestamp is invalid. Try to investigate into it and see why its invalid.

ecclesr , please start a new thread. I know your problem is the same as the OP but you guys are on different paltforms and hence the solution will be different.

There is no way to do that. The only way to do it is to recompile the sequence which will clear all checkpoints. The best way to handle such a situation is to abort the job when a single warning occurs. You can do that by passing the warning limit in your command dsjob -run -warn 1...... OR better y...

Better yet, reverse sort it and pass it through the hashed file. You dont need to make your design more complicated just to get a last record in your hashed file.

Take a look at the Index() function or the Matches operand. That will get you your desired result.

You dont even need to write a whole shell for it. Take a look at DSExecute() routine. Pass in the test() command with either a -z or -n to check if the file is empty. And if it is empty return 1 else 0. Use this DSExecute() as the derivation of the required column of the hashed file.

Yes you need to hardcode it. Try it out. I know for sure it works in server jobs, but try it and let me know. Thats what even Ray was wondering if it worked in a px job.
You are right, you need to provide
#path#Msg.XML#DSJobStartDate#
See if it works.

AHA. The answer to your problem might be right there. How the load works is that it drops the indices and rebuilds them. If you dont have privilege to do that then there is a good possiblilty that your job hangs. They really dont seem to match but ask your DBA to give you that privilege for just a t...

Its "Load Intermediate" am sorry for the typo. Again a typo. Its Load Immediate and not Intermediate. You need to rest buddy. Tomorrow's another day Why your job finishes successfully when Load Immediate is set to No is because it doesnt load. It actually just builds the INPUTDATA.DAT file, the CMD...

There are a couple of different ways you can try. If the meta data of all the five files is identical then: 1) Make your job Multi-instance and execute 5 instances for the 5 files 2) do a cat of the five files at the unix level and combine them into one file 3) Reference all the five files by five s...

Read the DS manual. Or go to the routine itself in your repository view and read the description. Here, this is directly from the routine's description Short Description : Convert an ASCII COBOL PIC 9(n) data type into a number Long Description : COBOL PIC 9 in ASCII is in reality the same thing as ...

But what i noticed is that changing 'Intermediate files' What option is that. The only option i see over here with the word 'Intermediate' is 'Remove Intermediate Datafile'. That option is to remove the INPUTDATA.DAT file that it creates once the load is done. Whether the job works or not, that is ...

Search for the word Netezza. I think there are a couple of posts besides yours out there. You will find a hand full to be in the same boat as you.

O no. The job is running fine but did you actually take a look at the table whether the records got loaded ? I seriously doubt it. Load immediate (not intermediate) setting to NO means the data gets copied to INPUTDATA.DAT for delayed loading. Then the bat file is used to load the data. Setting the ...