|
View previous topic :: View next topic
|
| Author |
Message |
prgrmr
New User
Joined: 26 Jun 2010
Posts: 3
Location: swiper
|
|
|
|
Hi,
I need to convert alphanumeric to comp-3 as below. Can any of you help me with it, please?
Data moved from
007300 05 ALPHANUMERIC PIC X(26).
Data moved to
05 Num-key
10 Num-abc PIC 9(12) COMP-3.
10 Num-def PIC 9(14) COMP-3.
Here is what I get out of displays when I redefine X(26) to 9(12) and 9(14) and another redefine to abc - 9(12) comp-3 and def- 9(12) comp-3.
KEY 50005000000000000123001234
-----------------------------------
Output – Num-key 50005000000000000123001234
abc 5 0 0 0 5 0
def 0 0 0 0 0 0 0
I also tried redefining X(26) to 9(12) and 9(14) and moving data from numeric to comp-3. Still doesnt seem to work.
I have verified several posts in net, before sending this. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| You are moving 26 bytes to 15 bytes (7 for num-abc, 8 for num-def). It is not at all clear why you are doing this. Perhaps if you explained more it would help us understand. |
|
| Back to top |
|
|
prgrmr
New User
Joined: 26 Jun 2010
Posts: 3
Location: swiper
|
|
|
|
Yes. This value is the key. In one file it is in alphanumeric and in another in COMP-3.
For some calculation, I need to match the keys in the two files, to work on.
Hope that clarifies. My concern is on where the fillers will have to be inserted - providing FILLERS at the end did not work. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
No, it hasn't been clarified yet. . .
Is this one value or is it 2 values? Why not define the input as 9(12) and 9(14) and them move the individual fields?
Usually, comp-3 (packed-decimal) fields do not make good keys due to the signs. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
This does not clarify it.
You need to show that key data in both of the files. Please use code tag since actual positions are important.
My guess is that a redifine from X(26) to a group containing
9(12) and 9(14) elementary levels is fine.
I think you need to do two individual moves from 9(12) to 9(12) comp3
and 9(14) to 9(14) comp3 to pack the data.
This is the best I can do since my crystal ball is already at happy hour. |
|
| Back to top |
|
|
prgrmr
New User
Joined: 26 Jun 2010
Posts: 3
Location: swiper
|
|
|
|
Alpha is in X(26) and Numeric is 9(12) COMP-3 and 9(14) COMP-3.
That is how it is in the system - a very old but largely used system. We cannot change anything about it. Both the formats are already in use.
I would think atleast 9(12) should be convenient to move to 9(12) COMP-3 - but in actual scenario it doesnt seem to work. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
You are making this more difficult than necessary. . .
| Quote: |
| We cannot change anything about it. |
You can redefine data without changing anything. . .
Redefine the x(26) as 2 numeric fields 9(12) and 9(14) - or create a new working-storage field that contains these and move the entire x(26) field to this new field. Then move the 2 numeric fields to the comp-3 fields. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| I would think atleast 9(12) should be convenient to move to 9(12) COMP-3 - but in actual scenario it doesnt seem to work. |
What does this mean -- the move worked but the data is not numeric? the move worked and the data is numeric but not what you expected? the move generated an abend? the move generated some kind of return code? Saying "it doesn't (sic) seem to work" is not providing any useful information.
Does the alphanumeric variable have just numbers in it -- or can it have non-numeric characters as well? You say in one file it is alphanumeric and another it is COMP-3 -- do you mean it is a single 26-byte packed decimal variable (which is allowed under the COBOL ARITH(EXTEND) option)?
Let's start at the beginning since you have so far managed to completely confuse a large number of people -- please describe the key field as defined in both programs (use the CODE button to post the actual descriptions from the programs), and describe what transformation rule(s) you are expecting to use to go between the two keys. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
prgrmr
My crystal ball tells me that if your file layout looks like:
| Code: |
01 FILE-1-DATA.
05 ALPHA-FIELD PIC X(26).
05 KEY-FIELD REDEFINES ALPHA-FIELD.
10 KEY-FIELD-1 PIC 9(12).
10 KEY-FIELD-2 PIC 9(14).
01 FILE-2-DATA.
05 KEY-FIELD-GROUP1 PIC X(15).
05 KEY-FIELD-GROUP2 REDEFINES KEY-FIELD-GROUP1.
10 KEY-FIELD-1 PIC 9(12) COMP-3.
10 KEY-FIELD-2 PIC 9(14) COMP-3.
|
Then your data would like like this (if you were actually show it to help every one out):
| Code: |
FILE-1-DATA.
PIC X(26) FIELD
----+----1----+----2----+----3---
50005000000000000123001234
PIC 9(12) FIELD
500050000000
PIC 9(14) FIELD
00000123001234
FILE-2-DATA.
PIC 9(12) COMP-3 FIELD
----+----1----+----2----+----3---
0000000
505000F
PIC 9(14) COMP-3 FIELD
----+----1----+----2----+----3---
00013024
0002013F |
From my experience, COMP-3 fields are generally an odd number in length. This is because the last half-byte is an F, C, or D depending on sign/unsign.
In your case as an even number, I would guess there is a leading zero in the first half byte, and a trailing F in the last half byte.
If you were to show your data (I know high expectations on my part), with HEX ON and CODE tag, my guess would be confirmed.
HELP US HELP YOU or respond: 'I no longer need your help'. |
|
| Back to top |
|
|
|
|
