DSXchange

(Well that was pretty silly of me! Sorry, Craig.) I typically telnet to the server to do most of my Universe level work rather than working through the DS Administrators' Command ability. (I've been working with PICK-like OSs for years and am very comfortable at that level.) Upon connecting, it prom...

This message began appearing on our production server a while back. I've been ignoring it and living with using the command ability in DS Adminstrator. But I really need to get this working again because I do quite a bit of work at the Universe level, especially during promotions. I've confirmed tha...

Using this in a transformer stage variable I was successful at getting the LinkLastError info on a link to an MSOLEDB stage : DSGetLinkInfo(DSJ.ME, DSJ.ME, 'insert', DSJ.LINKLASTERR) I've not had any luck using the DSJ.LINKSQLSTATE or DSJ.LINKDBMSCODE information. Apparently not available from an MS...

Well, I may not be using it correctly. According to the docs, the syntax is: DSGetJobInfo( JobHandle, StageName, LinkName, InfoType ) It states that the DSJ.ME constant may be used for the first three parameters to access the current job, current stage, and current link. The job has a transformer st...

I was exploring the use of DSGetLinkInfo() to obtain the DSJ.LINKSQLSTATE, DSJ.LINKDBMSCODE, or DSJ.LINKLASTERR values for a link that applies data to an MSOLEDB stage. I would like to capture this and then write it to a seq file for troubleshooting later. So, the link the value would be written to ...

Looking through each stage of the sequence I found there was actually another job inserting into this same hashed table. This was a cut/paste error: the second job had been created from the first and I neglected to create a separate check table. Since they were both attempting to update the same has...

The table is created by a Hashed File stage as part of the job. I had considered non-printing characters since it is an obvious candidate but didn't see how that could be given that the exact same criteria works successfully when used immediately after the failure. This job is very simple and does o...

Yeah, I figured this wasn't going to be simple. I've tried everything I can think of. I've recreated the table but that made no difference. The reset doesn't provide any additional info: Resetting Job ODS_ExportSystemCastanet. Resetting stage ODS_ExportSystemCastanet..xfm. ODS_ExportSystemCastanet.....

The log begins with the usual messages about "Starting job...", "Environment variables...", "Active stage starting...", and "Write caching disabled", then it shows the error message: ODS_ExportSystemCastanet..ins_CASTANET_CHECK.insert: ds_uvput() - Write faile...

I know, I know: this topic has been covered several times before. But I've been unable to find a post that matches what I am experiencing. (Please be gentle :wink: ) I am occasionally getting a fatal error like this on an attempt to insert a record into a table: ds_uvput() - Write failed for record ...

datastageETL wrote:were you able to solve this issue?

I don't believe so but it has been a while since I was working on this. We opted to not move to 8.1 at the time (for this and several other reasons) but still plan to at some point in the future. So, this may come back to haunt me.

Well, in my case anyway, I've determined that it has to do with having a sequence stage be the immediate precursor to the startloop stage. If I eliminate the sequence stage and just change the two prior stages (which were joined at the sequence stage) to be inline to the startloop stage, it works fi...

This is really sad. Jobs which have worked fine for a long time now, when recompiled, will exhibit this. Yet a new job I just created to test a loop and promoted it forward, works in both locations. Clearly something has changed on the system or in DataStage but I haven't a clue where to begin to lo...

What did you end up doing to resolve it? I am now seeing this in other jobs, too. Ones that worked fine -- and still do in earlier versions. For example, I have one sequence that still works fine but if I simply recompile the job in my work area, then re-import it to a test area, it will now exhibit...

[I'm not even sure what I'd search for on this. If there is a known thread on this, please direct me.] I have a sequence that invokes a job and, like any other sequence, when it does the sequence log reports: StatisticsLogs -> (jobImportVM): Job run requested StatisticsLogs..JobControl (DSRunJob): W...