DSXchange

Gokul, the DELETE statement only works on hashed files; sequential files can only be read sequentially, so DELETEing a row using this statement cannot work. The only way to delete a line from a sequential file is to make a copy - meaning you can't update the file, but need to read and then write row...

The first step is to find out which part of the whole "flow" is causing the bottleneck. If you remove the load to Teradata and write to a sequential file the speed should go up tremendously if the load to Teradata is the bottleneck. (this also answers DeepakCorning's question to get a maximum rate)

Deepesh, I think you have just made the record for the shortest error post. What are you doing in which stage/job/package; are you reading/writing, do other ODBC connections to this DB work? What columns, datatypes? Is this a once-off error? Is the warning on each row and is the data actually read f...

singhald, as Ray has already pointed out, hash files tend not to show this type of problem. If you could change your job to write to a sequential stage instead of a hash stage for testing purposes and the error goes away, then we would need to look at the hashed file a bit closer. Could you try that...

The link is there, potentially.

When you declare the jobs are multi-instance, do you also start these jobs with multiple instances and in parallel; or does the error depend only upon ticking the multi-instance box in the designer and then no other changes?

I did a quick and dirty test that did work - in a routine do an MathExpression= '1+2+3+4=9' EXECUTE "LIST VOC FIRST 1 ID.SUP COL.SUP HDR.SUP EVAL '":MathExpression:"'" CAPTURING ScreenIO RETURNING ERRORCODE And it will work when you parse the resultant ScreenIO string. Not pretty...

I suspect that you might have specified a "reject link" in the stage, which does require an output stream.

Luk, I think that now your RT_LOG40 is unusable. Best to export the job, delete it, and re-import it. The RT_LOG40 is a hashed type 30 file, the directory contained a DATA.30 and OVER.30 plus a hidden file, which are now gone and are not automatically created. In a pinch you can do a complete copy f...

Luk, go to the Administrator or to the DS command line and execute a "CLEAR.FILE RT_LOG40".

Divine, your only easy choice here is to write it in BASIC, or shell out and use a UNIX command. The subroutine in BASIC is quite simple. The TIME() function returns either an integer or a real number for seconds since midnight. Your function would have a dummy parameter and contain: Ans = INT(T...

Kim,

no, I checked and couldn't find an EVAL or similar in BASIC - but somehow I think that I've done something like this before, I just can't remember how. The ITYPE() call will work on a dummy file, but it is rather slow. I wonder if there is a FMT() alternative to get this done...

Dynamically parsing this string at runtime is difficult. The PERFORM engine has a keyword EVAL which does this, but it is not present in BASIC, and to use the ITYPE() function would also be a bit complex and quite slow. It might be worth your time to write a dict entry I-Type that uses EVAL and then...

You can also use the contents in the DS_AUDIT Hash file to get this information. If you are not comfortable using the Administrator or command line, you could create a job and declare the DS_AUDIT hashed file along with importing the metadata for it's contents.

At first look I would remove the decimal seconds from the string.