DataTypePicComp

ArndW · Post by **ArndW** » Fri Jan 07, 2005 9:27 am

Hello again JezT,

JezT wrote:Arnd

We have a Customer Number:

0123456789
0122222222
0999999999

We need to convert these within DS to be in the format:

PIC S9(9) COMP.
...

I just took the 3 numbers you listed above, ran them through the routine that I sent you and then put the resultant data into the builtin sdk routine "DataTypePicComp " and the resulting numbers were identical to the original customer numbers. So I have to admit I don't understand your issues now (apart from the null padding to S9(9)).

ArndW · Post by **ArndW** » Fri Jan 07, 2005 9:47 am

JezT,

please do a "TRIM(YourDataNumber)" or put it into the routine; extraneous spaces mess up the routine.

JezT · Post by **JezT** » Mon Jan 10, 2005 2:29 am

Arnd

I have put the following into the transformer that calls the routine

Code: Select all

COMPConversion(trim(DSLink338.CDU_CIN))

Where "COMPConversion" is the name of the routine and "DSLink338.CDU_CIN" is the Customer Number I am passing into the routine.

Should that be sufficient to remove the extraneous spaces ?

Cheers
JezT

ArndW · Post by **ArndW** » Mon Jan 10, 2005 2:36 am

Yes, that should be sufficient; although it would make more sense to put the TRIM(<string>) command into the routine itself. I am assuming this will solve your problem, since when I first cut-and-pasted your number I had an extra space in the string and received the same nonsensical results.

JezT · Post by **JezT** » Mon Jan 10, 2005 2:56 am

Arnd

Should this be sufficent then within the routine ?

Code: Select all

WorkString = OCONV(trim(Arg1),"MX")

With Arg1 being the Customer Number

Or should I also trim ANS ?

Cheers
Jez

ArndW · Post by **ArndW** » Mon Jan 10, 2005 3:02 am

I meant that if you put it into the routine it won't be possible for you to forget to put it into the derivation in the DataStage job - just removing a possible source of error in the future. No, if you TRIM(Ans) then you will likely change the string and make it function incorrectly (the output is binary).

JezT · Post by **JezT** » Mon Jan 10, 2005 3:08 am

So will the trim I have put on Arg1 within the routine be sufficient then ?

ArndW · Post by **ArndW** » Mon Jan 10, 2005 3:12 am

JezT · Post by **JezT** » Mon Jan 10, 2005 9:05 am

Found the problem but on't have the answer.

Your routine works perfectly..

the problem we have is:

List of Numbers:
40
44
74

When your routine converts them we get:
(
,
J

Which have the following hex values:
28
2C
4A

When we transfer this to mainfrme via NDM (either bin or text) we get the following on mainframe:
(
,
J

hex values:
4D
6B
D1

We have tried to convert these values using the EBCDIC and ASCII to EBCDIC DS conversions to no avail in either binary or text transfer..

Any ideas??

Cheers

T42 · Post by **T42** » Mon Jan 10, 2005 10:07 am

*gets a neck strain from watching the tennis chat match*

ArndW · Post by **ArndW** » Mon Jan 10, 2005 10:40 am

T42 (we are just doing this to boost our points in this forum, so that we can surpass Ray and get a free <something>

)

JezT,

try using FTP in binary mode;I haven't used NDM but it looks like it is doing an ASCII->EBCDIC conversion. Take a look at your mainframe's version of ABCDIC (no, they are not all the same) and see what Hex 28 gets mapped to. But since your data is correct on the UNIX box and incorrect on the host it should narrow down your diagnostics.

JezT · Post by **JezT** » Tue Jan 11, 2005 1:43 am

Arnd

Another issue that has come to light is that when we run the job and the output file of the converted Customer Numbers is created, one of the lines has the following error:

UKWHCustSegtIntCDUXtct3Job..CDURefreshFile.DSLink335:read_fixedwidth() - row 55, column CDU_CIN, column unexpectedly ended by EOR

UKWHCustSegtIntCDUXtct3Job..CDURefreshFile.DSLink335:read_fixedwidth() - row 55, column FILLER, column unexpectedly ended by EOR

This then splits the line in two and causes the error. Is this because the Binary Character that the CDU Number is converted into is the symbol for a carriage return or something similar ?

If you look at the file in DataStage it looks okay (once you OK the above message) but we are having problems when transferring the file to the mainframe because of this.

JezT

ArndW · Post by **ArndW** » Tue Jan 11, 2005 1:50 am

Jezt,

please look back in this thread - I mentioned that you should be careful because you are going to get binary data. So you have to define your metadata (i.e. Column Definitions) to allow terminators. This is what the error message means - the binary COMP field contains the representation of a <CR> or <LF>.

JezT · Post by **JezT** » Tue Jan 11, 2005 1:59 am

Arnd

So does that mean that within my DS Job, I need to import a specific file definition for my output file that will accept line terminators as a character and not actually action the line termination ?

Any suggestions ?

JezT

ray.wurlod · Post by **ray.wurlod** » Tue Jan 11, 2005 2:31 am

Not necessarily.

If you scroll to the right in the Columns grid of the Sequential File stage, you will find the ability to inform the stage that a column may contain terminator characters, and thereby incorporate the ability to handle them gracefully.