Decimal to EBCDIC character

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 3:46 am

In my case, I would like to convert decimal to EBCDIC character and then ftp the sequential file to M/F.

Objective

6 bytes     3 bytes       7 bytes     4 bytes
---------------------------------------------
123456 ===> 135           1234567 ==> 0246
            246                       1357
            
In M/F, it is quite a easy job,

MTCH-KEY                     C4V1-3
FILLER                       R            
    MTCH-KEY-R               X2
    FILLER                   X            
    
OR

10  MTCH-KEY                 PIC S9(4)V9 COMP-3.
10  FILLER                   REDEFINES MTCH-KEY.
  15  MTCH-KEY-R             PIC X(2).
  15  FILLER-1               PIC X(1).
  
Then if MTCH-KEY = 1234, in M/F it is 130 , so MTCH-KEY-R = 13
                                      24C                   24
                                      
How to similar this case in DS ?

I have a idea with BuildOp,
1) Convert Decimal to String
2) Separate each two digit into a string
3) Search this two digit in EBCDIC_TO_ASCII table, got the corresponding ASCII value
4) Convert ASCII value to char 
5) Concatenate each char into APT_String

In output stage (Sequential stage), 

If "Character Set" = "EBCDIC"

  When ASCII value < 128, it works well, but when it >= 128, only 0x3F return.

Else If "ASCII"
  
  All ASCII value works well.
  

So if MTCH-KEY = 12350, after the above processing("Character Set" = "EBCDIC") , MTCH-KEY-R = 035
                                                                                              1F0

ASCII	EBCDIC
0x01	0x01
0x8E	0x23
0x26	0x50

So if MTCH-KEY = 1279, after the above processing("Character Set" = "EBCDIC") , MTCH-KEY-R = 17
                                                                                             29

ASCII	EBCDIC
0x12	0x12
0x60	0x79

My question is how to solve ASCII value > 127 case ?

ArndW · Post by **ArndW** » Wed Jul 20, 2005 3:52 am

Benny,

the COBOL redefines shows that you don't need to do any conversion at all - in the job input file column definition tell DataStage PX that you are getting a CHAR(1) column and also specify that no conversion is to be done on that column and -presto- you have done the same thing as your REDEFINES.

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 4:00 am

ArndW,

Actually it is an output file (we need to ftp DS sequential file to M/F), and our COBOL Macro doesn't have redefines for this field (redefine only code in COBOL PGM)

ArndW wrote:Benny,

the COBOL redefines shows that you don't need to do any conversion at all - in the job input file column definition tell DataStage PX that you are getting a CHAR(1) column and also specify that no conversion is to be done on that column and -presto- you have done the same thing as your REDEFINES.

ArndW · Post by **ArndW** » Wed Jul 20, 2005 4:02 am

Benny,

my point is that your method takes whatever bit representation the COMP-3 field is using an breaks that up into PIC(X) without any conversion at all. So, if you were to "fake" your input or output metadata to state that this is a CHAR field (and turning off EBCDIC/ASCII conversion) you will get the exact same result.

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 4:07 am

Arnd,

you mean I should use COMP-3 rather than PIC(X) in DS ? But COMP-3 with no sign still have a 'F' in lower byte, but I don't want this sign.

Am I mis-understanding your meaning ?

ArndW wrote:Benny,

my point is that your method takes whatever bit representation the COMP-3 field is using an breaks that up into PIC(X) without any conversion at all. So, if you were to "fake" your input or output metadata to state that this is a CHAR field (and turning off EBCDIC/ASCII conversion) you will get the exact same result.

ArndW · Post by **ArndW** » Wed Jul 20, 2005 4:35 am

If you don't want the sign then declare as an unsigned COMP-3, but yes, the basic idea is to use the overlay mechanism.

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 8:21 am

Arnd,

do you mean packed no sign ?

In my understanding,

Code: Select all

Packed no sign
------------------
12345 ==> 135
          24F

Packed sign
------------------
+12345 ==> 135
           24C

-12345 ==> 135
           24D

I want
------------------
12345 ==> 024
          135

ArndW wrote:If you don't want the sign then declare as an unsigned COMP-3, but yes, the basic idea is to use the overlay mechanism.

ArndW · Post by **ArndW** » Wed Jul 20, 2005 8:23 am

Use an unsigned and declare it as PIC 9(6) COMP-3; then ensure you put the leading zeroes into the string.

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 8:30 am

Arnd,

I am not quite understand your meaning, can u explain ?

If declare it as PIC 9(6) COMP-3, then it will be 4 bytes, but 12345 or 123456 only need 3 bytes

thanks a lot!

ArndW wrote:Use an unsigned and declare it as PIC 9(6) COMP-3; then ensure you put the leading zeroes into the string.

benny.lbs · Post by **benny.lbs** » Wed Jul 20, 2005 6:53 pm

Besides, I have tried another method to do the similar thing as COBOL.

Declare it as PIC 9(6)V9 COMP-3, then use Column_Export stage to export it as PIC X(4), and then use Column_Import stage to similar the redefine function, separate into PIC X(3) and PIC X(1), but when I browse the output in Hex format, it still show me the incorrect result

Code: Select all

12350 ==> 035
          1F0

That means when ASCII value > 127, it still can't convert, what is the problem ?