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)).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.
...
DataTypePicComp
Moderators: chulett, rschirm, roy
Hello again JezT,
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
JezT,
please do a "TRIM(YourDataNumber)" or put it into the routine; extraneous spaces mess up the routine.
please do a "TRIM(YourDataNumber)" or put it into the routine; extraneous spaces mess up the routine.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Arnd
I have put the following into the transformer that calls the routine
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
I have put the following into the transformer that calls the routine
Code: Select all
COMPConversion(trim(DSLink338.CDU_CIN))
Should that be sufficient to remove the extraneous spaces ?
Cheers
JezT
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.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Arnd
Should this be sufficent then within the routine ?
With Arg1 being the Customer Number
Or should I also trim ANS ?
Cheers
Jez
Should this be sufficent then within the routine ?
Code: Select all
WorkString = OCONV(trim(Arg1),"MX")
Or should I also trim ANS ?
Cheers
Jez
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).
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
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
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 (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,
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.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
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:
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
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:
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 ?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
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
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>.
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>.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.