DSXchange

Welcome aboard (willkommen?) :D "Out of context" is only meaningful in the debugger. What it means is that you have items on the watch list that are not visible from the point where the debugger is currently paused. Consider the following design. Source ---> Tfmr1 ---> Tfmr2 ---> Tfrm3 ---> Target L...

The obvious question: What has changed? ("Nothing" is not the correct answer.)

Read it carefully. It is NOT the same error. The first one came from DSR_RECORD; this one comes from DSR_NLS. It suggests, however, that something is badly wrong with your project. At this stage I'd be looking at creating a new project, exporting everything from this one and importing it into the ne...

You're probably better off re-constructing it (unless you have a good backup/export). You're not going to find someone with the requisite expertise close by on a holiday weekend.

Can you open the job in development at all?

My bad. I was reviewing this diagnostic job in person yesterday and forgot about its origin.

But it remains the case that the significant part of the problem lies between the keyboard and the chair.

Just lose the Substrings() functions - the square bracket notation is sufficient to represent substringing. Also lose the Oconv() specification! StringToTimestamp(EXTRACTENDDT[1,4]:'-':EXTRACTSTARTDT[5,2]:'-':EXTRACTSTARTDT[7,2]:" 00:00:00.000","%yyyy-%mm-%dd %hh:%nn:%ss.3"&#...

I'm prepared to bet you do NOT require running totals, just the row counts at the end. These are captured for you in the log if you enable APT_PM_ROW_COUNTS (from memory). The DSGetLinkInfo() function can report the total rows on the link or the per-instance (per-node) row counts for that link. Ther...

It (the link to the design time information) can be recovered but it requires an expert consultant to re-build the ROOT record in DS_JOBOBJECTS.

This not something I would even for a moment contemplate trying to explain here.

Is there a "$" or a "#" in the password itself?

You don't - can't - have multiples of the key value in a hashed file. They way they work relies absolutely upon having unique keys. Therefore, you will need a different approach - perhaps a secondary key lookup via a UV stage from a hashed file with an artificial key. If you do that, you can readily...

It can occur when the job executables are exported/imported and the job design is not. It can occur even if both are exported but only the executable is imported. Make sure the job, as well as the job executable and source, are all exported, and re-import.

Maybe a COBOL programmer! The data you get from the mainframe is fixed width. That is the basic source of the pad characters (spaces). Look at the imported table definition - choose the Layout tab and select COBOL to see what I mean. You do need to trim the strings, even though your declared data ty...

Did not see any link.

Troubleshooting the COBOL code in DataStage can only be by inspection, because there's no means to run it there. You could, for example, modify the generated code to dump diagnostic information. You could also modify the JCL templates to do the same for particular stages.

He's "loading" them into a text file. Keys are irrelevant.

The problem here is one of expectation management (or maybe of bad math).