|
View previous topic :: View next topic
|
| Author |
Message |
d2
New User
Joined: 06 Jan 2021
Posts: 14
Location: INDIA
|
|
|
|
I have a vsam file having that contains some records. From position 7 to 14(* bytes) I have below value in Hex format.
.-......
06100021
00100017
I want to convert it to decimal(0060110000002117), when I am trying this SORT card -
//SYSIN DD *
SORT FIELDS=COPY
OUTREC FIELDS=(7,8,PD,TO=ZD)
I am getting this
00601100000021É
FFFFFFFFFFFFFF7
006011000000211
can anyone help -where i am going wrong. As per my understanding the field is defined as packed no sign. But there is no way to verify that. |
|
| Back to top |
|
 |
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2022
Location: USA
|
|
|
|
In your example there is no real PD (packed decimal) format.
What you have is a hexadecimal value, and highly likely you plan to unpack it to character string, AFAIU?
P.S.
1) You need to understand that after this conversion you'll have only 16 bytes character record on output. All other information will be eliminated, unless you also mention it in your BUILD= parameter.
2) FIELD= parameter is obsolete; use BUILD= instead |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| As per my understanding the field is defined as packed no sign. |
Your understanding is incorrect. A packed decimal field has 2 decimal digits per byte -- EXCEPT FOR THE LAST BYTE, WHICH HAS ONE DECIMAL DIGIT AND A SIGN. The sign may be positive (X'C'), negative (X'D') or unsigned (X'F') but it will be there. Since your value does not end with a hex value of C, D, or F then it is not a valid packed decimal field. When unpacking a packed decimal field, for the last byte the sign is moved to the zone while the decimal digit is moved to the data part of the zoned decimal byte. Hence what you showed - the computer treated your value as a packed decimal and did what you told it to do. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2022
Location: USA
|
|
|
|
| d2 wrote: |
| As per my understanding the field is defined as packed no sign. But there is no way to verify that. |
1) In the mainframe world, there is no such thing as "decimal packed, no sign". It may be a proprietary format, not supported by mainframe hardware.
2) You can easily verify this when checking your records using any hexadecimal viewing tool. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
I once wrote a program to deal with a timestamp which was in such a format. My solution was to move to a work field and suffix with a X'0C' byte to give me a valid packed decimal field. I then divided by 10 to get the desired value and was able to unpack it.
Perhaps a similar approach would work?
Garry. |
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1254
Location: Bamberg, Germany
|
|
|
|
| Garry Carroll wrote: |
| Perhaps a similar approach would work? |
It does work, used this method myself years ago. |
|
| Back to top |
|
|
d2
New User
Joined: 06 Jan 2021
Posts: 14
Location: INDIA
|
|
|
|
Thank you every one for your valuable responses. All your comments helped me to clear the concept.
For me this solution worked so did not tried to others
But now I am stuck at converting the data back to its original format after processing. As the original format of the data is not known to me.
Any help in this case? |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2022
Location: USA
|
|
|
|
| d2 wrote: |
But now I am stuck at converting the data back to its original format after processing. As the original format of the data is not known to me.
Any help in this case? |
In case "the original format of the data is not known to me" there is no chance to give you any advice. |
|
| Back to top |
|
|
|
|
