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 ?
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.
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.
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.
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.
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