DSXchange

The z/OS stage still requires a connection channel which your source platform must support, and on which they must grant your application access. FTP, however, is simpler. All they need to do is grant your ftpid authority to logon to their system, and give it access to the file you need. FTP Enterpr...

Is this 18 jobs that run one at a time sequentially, or do they kick off simultaneously, or in groups? In any case, what is your job recovery requirement? Do you rerun jobs that already completed okay, or do you want to skip them? Terminator stages are part of the mix. If you want spot recoverabilit...

The simple part is that DataStage does not handle OCCURS DEPENDING. I don't know the details for that, but it just doesn't.

Ernie's suggestion is to use the Server sequential file stage, because it is less restrictive than the Parallel stage.

At this point, I have an unhelpful observation to make: you are not dealing with standard COBOL formatting. You are dealing with undisciplined formatting out of COBOL coding. They have set for you an impossible obstacle: reading a file with inconsistent record lengths. One more thing you might check...

If you have a delimiter setting, you should delete it. That's the only reason I can think of for the warning.

I suppose a transformer loop would be a good approach. You need to do several things here. You have to know how many instances of the OCCURS you need to use for each input row. Will it always be the same number? Is there a direct link between the number of address columns in the .csv file and the ou...

Assumptions: Input record length is 16336 bytes. First 10 bytes is record type indentifier. Every record is consistently of that length. You must preserve the EBCDIC character set. Sample table definition: REC_TYPE Char(10). DATA_COLUMN Binary(16326). You can use Sequential File stage for this. Set ...

Rumu, The lack of cooperation with you is a serious problem. I'm sorry that you have to deal with it. You can try to do the split yourself. It won't be easy. If you have a consistent record length for each record type, the "split" job would just identify the record type and write it to its...

Rumu, There's too much going on here for you to keep up with the details. I strongly recommend sitting with your mainframe developer and going through an exercise in simplification. On the copybook, as they created it, get help with flattening the groups manually. Edit the copybook before importing ...

Rumu, Please confirm that the following is accurate: FROM TO FIELD LENGTH PICTURE 1 75 CHD-RECORD 75 X(75) 76 77 CHD-NO-SEG 2 S9(4)V COMP 78 79 CHD-ALP-SEG 2 S9(4)V COMP If it is accurate, those are not packed decimal fields. They are binary numeric fields that are sql type integer or double or of t...

The reference you found is incorrect. COMP-3 storage length -- the bytes it takes up on the file -- is number of integer places divided by two and add one, round up for odd number of places. PIC S9(4) COMP-3: 4 divided by 2, add 1, storage length is 3. Storage, hexadecimal representation: 1,234 (or ...

Novak, our protocol as an example: Code and unit test in DEV, export design only. Import design to INT (integration), compile and test. Export design and executable from INT. Import design and executable to SAT/CAT (test). Run final tests. Export design and executable from SAT/CAT (or, with no test ...

Rumu, Read the using mainframe FAQ linked below for details on handling packed decimal. Your column length for PIC S9(4)V COMP-3 is 3 bytes: counting the integer places you would see in the file 01 23 4F. As for parsing, you can define the file stage input single column as Char, even though it doesn...

You need to parse the packed decimal fields before using raw to string. Use position and length to derive it to a decimal column defined for its format. Raw to string is always going to fail for packed decimal.

Packed decimal is an exact format. It cannot be translated except by "unpacking" it according to the format. The first problem is that it's not hexadecimal. Each half-byte contains a decimal value -- 0 to 9 -- with the final half-byte reserved for the sign -- C for positive, D for negative...