|
View previous topic :: View next topic
|
| Author |
Message |
mushreyas
New User
Joined: 18 Jul 2008
Posts: 59
Location: Bangalore
|
|
|
|
Hi,
I have a question regarding the number of bytes required when we convert a signed binary data into Zoned Decimal format.
1> S9(4) USAGE COMP occupies 2 bytes but when converted to Decimal format will it occupy 4 bytes or 5 bytes.
2> S9(9) USAGE COMP occupies 4 bytes but when converted to Decimal format will it occupy 9 bytes or 10 bytes.
3> S9(18) USAGE COMP occupies 8 bytes but when converted to Decimal format will it occupy 18 byes or 19 bytes. |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
What are we talking about here? COBOL? JCL? SYNCSORT? plain old binary to decimal conversion? or what?
Now I see that this has been moved to another section of the forum but we still need to know the context. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| why don't you look here and see if you get an idea. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Your question cannot be answered completely accurately unless you specify what you are using for compiler option TRUNC. In general, you will not go wrong by using 5 bytes for a zoned decimal conversion of the 2-byte binary (COMP) value and 10 bytes for a zoned decimal conversion of the 4-byte binary (COMP) value.
There is a link to Manuals at the top of this page. Click on it, find the COBOL Application Programing Guide, and read up on the TRUNC compiler option. Once you've done so, hopefully you can answer the PIC S9(18) COMP question yourself. |
|
| Back to top |
|
|
mushreyas
New User
Joined: 18 Jul 2008
Posts: 59
Location: Bangalore
|
|
|
|
| My requirement is to convert these signed binary data to decimal format using SYNCSORT. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
OK, so follow Robert's guidance and use the appropriate lengths.
The lengths of the converted fields is not "language" dependent. . . So the target length in a COBOL program would be the same as the Zoned Decimal length specified in the sort control. |
|
| Back to top |
|
|
mushreyas
New User
Joined: 18 Jul 2008
Posts: 59
Location: Bangalore
|
|
|
|
I tried what Robert suggested but the last byte of the data was coming wrong. Below is the example
Input Data : 1 (Binary)
Sort Card
| Code: |
SORT FIELDS=COPY
INREC =(1,2,BI,ZD,LENGTH=5)
|
Output was 0000A instead of 00001. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Your input is signed. Your output (zoned decimal) is signed. Your output in hex looks like this
Which is +ve one. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| but the last byte of the data was coming wrong. |
The last byte is what the sort was told to do.
To get rid of the sign, use ZDF. From the manual:
| Quote: |
| ZDF produces the same numerical value as ZD, but uses an F for a positive sign and D for the sign of a negative value. |
|
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| mushreyas wrote: |
| Code: |
SORT FIELDS=COPY
INREC =(1,2,BI,ZD,LENGTH=5)
|
Output was 0000A instead of 00001. |
It's the correct output. Do you want the output in "readable" format to some MBA-graduate. For a(n) zOS Aplication Developer, that's already readable, as Bill explains. Follow what Dick has suggested, "it'll be +1":
vs
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| My requirement is to convert these signed binary data to decimal format using SYNCSORT. |
the tale of the traveling topic 
moved where it belongs |
|
| Back to top |
|
|
mushreyas
New User
Joined: 18 Jul 2008
Posts: 59
Location: Bangalore
|
|
|
|
Thank you all for your help. I will try the solution recommended by Dick. However i have tried the below sort card and it worked.
| Code: |
SORT FIELDS=COPY
INREC =(1,2,BI,EDIT(TTTTT),LENGTH=5)
|
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Shre,
Remember that you originally showed us Cobol-style signed-binary fields. Since you took the trouble to show us signed fields. we have assumed your fields can contain negative values.
Therefore, your solution should allow for a differentiation between positive and negative numbers.
Dick showed you how to do that without the positive numbers seeming to contain a letter of the alphabet in the right-most positiion, with an amendment to the particular sort card that your provided to us.
If your fields can contain negative values, so should your test data. You should be able to identify from the results, those that are negative and those that are positive.
There are a number of solutions to your requirement. Have a look at your Sort manual and see what other datatypes you can use with BI.
Lastly, is the above really your working sort card? "INREC =(" looks wrong. Did you re-type, introducing a typo, rather than use copy-paste? |
|
| Back to top |
|
|
mushreyas
New User
Joined: 18 Jul 2008
Posts: 59
Location: Bangalore
|
|
|
|
Hi Bill,
Its actually a typo error. It should be "INREC FIELDS=".
Thanks for your clear information. |
|
| Back to top |
|
|
|
|
