DSXchange

You need to have interprocess buffering turned on when you use the Link Collector stage (this is in the documentation).

A database doesn't really have a "last" record - at least not until you give it sort criteria. If you have the sort criteria and invert it your 1st record is the one you want. Sequential files need to be read to the end in DataStage jobs to get the last record. You could use the UNIX "tail" command ...

The DB/2 interface will automatically do the conversion from the internal date representation inside DataStage to the external date format for you. This is the one exception where you don't need to manually take care of this conversion.

Kumar, both Ray and I are suggesting that, if you have a service contract and provider, you let them lead you through fixing the file(s). It isn't because we can't do it, it is just that there is a very high chance that you are going to lose data and that with on-site or direct telephone support you...

Hello Kane,

you can also FTP as binary, and then do your own EBCDIC to ASCII conversion; but I'm not sure where your problem is coming exactly - the ftp will handle <cr> and <lf> conversions.

p.s. Please post in the appropriate forum, this has little to do with the "Editor's Corner"

Maybe your DS server is swapping/paging? You can do a "truss -p {pid}" of your DS process to see if there are any system calls or sleeps visible that might help you. Does you job read from a sequential source and does it have lookups ?

I don't think you have declared the metadata for your sequential file correctly, either that or the nullability. Could you perhaps post a sample of the line as it is in the file and what you expect?

Naveen, I think that was a correct answer, but to another question. JB, Option 4 should be to check the project files. Odd, it seems that sometimes the menu is different. I was looking at a version 7.1 project. I'm not at a DataStage machine so I can't check what the actual TCL command is, but perha...

I your database on the same machine as the datastage server? Does your table have indices? I would have your DBA monitor the database activity since the likelihood is very high that the cause is there.

Please go into TCL or the administrator command line and enter the DS.TOOLS menu, issue (2) and (4) to cleanup your job obects and to re-index your secondary keys. You will need to be the only user in DataStage in order for these to work correctly, but it will solve the problem you are seeing.

I think "affordable" is a tough one; it is specialized training and that always commands a price. The first things we would need to know is which part of what country are you in.

Amos, I have seen the deadlock daemon stop running after a whle. Are you sure that the process is still active on your box? If the deadlock daemon is running, the what has probably happened is that your designer client crashed but the UNIX processes associated with that program are still running. If...

I have to say that the official training is wrong on point (1) and although strictly speaking point (2) isn't incorrect it doesn't explain the major difference in how the code is executed at runtime. The initial purpose might have been to use specific data type and elements in transforms, but it is ...

Without administrative access, the only locks you might have control over are those your userid has. So the answer to your query is most likely "no"

Start off by getting all users out of the project and doing a UNIX level backup [and make sure it worked; it might be your only chance at getting a semi-useable system]. You can enter TCL as the administrator and issue a "UVFIXFILE DS_JOBOBJECTS" which won't fix anything, but will traverse the file ...