DSXchange

Do you have auto-refresh disabled in Director?

Data type decimal will always have a decimal placeholder, even if scale is 0. To avoid, change the data type to integer or string. In the latter case use Convert() function to eliminate the "." character.

There is only a single typeface choice in the client tools. If you know the target's technique for handling "bold on" and "bold off" you could include those in the generating expression, for example svBoldON <-- Char(27) : "[5" svBoldOFF <-- Char(27) : "[0" Ex...

+-- Job B ----+ | | | V Job A --> NestedCondition --> Sequencer --> JobC You may be able to avoid the NestedCondition activity by using explicit triggers on Job A, depending on what your actual condition is.

There's no shortage of 9.1 documentation; you can get it from the IBM Information Center and, from there, you can get a link where you can go to download manuals.

Assuming you're in an SMP architecture the BASIC Transformer stage will execute in parallel.

James's suggestion of using a %x mask is also worth considering. By that means you can allot multiple readers per node.

How do you know when "end of group" has occurred? For example, are there always three input lines that have to become one, or might there be two or four or some other number?

With that information more cogent advice may be possible.

APT_STRING_PADCHAR does not affect Date data type. You need to find better specifications for extracting the date from your source, perhaps using StringToDate() and DateToString() functions. Review documentation and/or Search DSXchange for how to specify variable formats such as one- or two-digit mo...

Easiest would be a BASIC Transformer stage using Oconv() function specifying "MX0C" as the conversion.

Step 1 - decide how it is to be "fixed" (for example discard the \n character, replace the \n character with a space character, actually use two lines (two records) repeating the key, etc.)

Updating the State file is running a job that loads a new start point from which Surrogate Key values will be generated. But it will still generate them in blocks, the size of which is determined by the Block Size property.

Care to share?

I deduce that either the db2fenc1 user account was unlocked in the interim, or that you still have an expired password but have not yet attempted any fenced operations against the database.

SKG stage generates in blocks. Any values not consumed from a block are wasted.

There is no requirement for surrogate key values to be contiguous. All they have to be is unique.

Totally separate problem. Your new error is a metadata mismatch connecting to the ODBC data source. You have to fix it (make the metadata in your job match the metadata in the database). Or, perhaps, not specify precision as 0 or "".