|
View previous topic :: View next topic
|
| Author |
Message |
nelson.pandian
Active User
.jpg)
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Hi Experts,
I have a requirement to convert PD values to displayable value and back again to PD in second JOB.
Input value for conversion in HEX is
I used the below code to convert PD to Displayable value.
| Code: |
| 1,3,PD,EDIT=(TTTTT) |
Displayable output value is 02003 in HEX is
The above output will be the input for the Vise versa process and CNTL card used is
| Code: |
| 1,5,UFF,TO=PD,LENGTH=3 |
Output in HEX is
In this process, Stating Input record and Final Output record are expected to be same. But its not the same. FA is changed to C. Iamb not sure whether Iamb missing some thing in the code. Can you please correct me, where Iamb going wrong?[/b] |
|
| Back to top |
|
 |
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
| In this process, Stating Input record and Final Output record are expected to be same. But its not the same. F is changed to C. I'm not sure whether I'm missing some thing in the code. Can you please correct me, where I'm going wrong? |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
In my opinion, there is nothing wrong here.
While the last half byte may be different, the value is still positive 2003.
Try examples where this value is already C or D and see if it changes. |
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Hi daveporcelan,
Thanks for the reply...
As you said there is no difference in the value. But when we compare the initial input file and last output file, its showing the difference that F as changed to C. So the business will not accept it because we will be running this job for millions of records. That is the problem here. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
By default, DFSORT uses a C sign for TO=PD. If you want an F sign, use TO=PDF.
1,5,UFF,TO=PDF,LENGTH=3
However, this would be more efficient:
1,5,ZD,TO=PDF,LENGTH=3 |
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Hi Frank,
Thanks a lot for the help. I got the output.
Can you please explain/Provide Document for the difference between Sign char C & F. It will be more useful for me. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
Don't you think any of these answers might have been documented by IBM or numerous 3rd party websites?
How did these "experts" learn it in the first place?
A bit of self-reliance will make you the expert. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
The following was deleted from the topic while the topic was being cleaned up. If you have not already done so, you should download the "Smart Tricks" document and see other things that will be quite helpful.
| Quote: |
Hello,
You might look at PDF and PDC. . .
This is from the Smart DFSORT Tricks:
Quote:
Change a C sign to an F sign in PD values
A customer asked the following question:
I have three 5-byte packed decimal fields starting in positions 1, 6 and 11.
The positive values have a C sign (e.g X'123456789C'), but I need them to have an F sign.
The negative values have a D sign which I don't want to change.
Can DFSORT change the sign from C to F for the positive values?
DFSORT's TO=PDF feature makes it easy to change the C sign to an F sign in your PD values.
In this case, we can use OVERLAY to change the signs in the three specified fields
without changing anything else in each record.
Here's the control statements we'd use:
OPTION COPY
INREC OVERLAY=(1:1,5,PD,TO=PDF,
6:6,5,PD,TO=PDF,
11:11,5,PD,TO=PDF)
TO=PDF sets an F sign for each positive PD value regardless of whether it originally had an F sign or a C sign.
TO=PDC sets a C sign for positive PD values.
TO=ZDF sets an F sign for positive ZD values.
TO=ZDC sets a C sign for positive ZD values. the D sign is kept for negative values in all cases.
Compliments of DBZ in another topic. |
|
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Thanks Phrzby Phil & Dick. Thanks a lot for the info  |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
| Can you please explain/Provide Document for the difference between Sign char C & F. It will be more useful for me. |
You can access all of the DFSORT books from:
www.ibm.com/support/docview.wss?rs=114&uid=isg3T7000080
Everything you ever wanted to know about DFSORT is documented in the DFSORT books.
| Quote: |
Don't you think any of these answers might have been documented by IBM or numerous 3rd party websites?
How did these "experts" learn it in the first place? |
Well, I learned it by doing the DFSORT development and documentation for it, but in general your point is well taken.  |
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Hi Frank,
Thanks a lot for the link |
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Can we have a PD value without sign bit C or F?
In some cases my Input file has the value as below in HEX ON format
| Code: |
003
20F
---
004
20F
---
000
000
--- |
In this case i'm able to convert the first 2 fields to Edited clause by control card shown in my first post and back to PD as Frank suggested. But incase of 3 record i'm getting the output as below HEX ON format.
So in the input file the last character is 0, but in case of output file it is of F. So the records are not matching when compared.
Can anyone help in resolving the issue? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
WIthout a valid sign, it is not a packed-decimal number. . .
When used as a packed number x'000000' usually causes an abend.
Sugesst you re-read the posted info about PDC and PDF above. |
|
| Back to top |
|
|
nelson.pandian
Active User
Joined: 09 Apr 2008
Posts: 133
Location: Phoenix, AZ
|
|
|
|
Hi Dick,
Thanks for the info. Actually i too said the same X'000000' is a low value and it is not a valid PD value. But the people here din't accept this. They said we can have PD value without sign bit. I searched Getting Started (2009) & Application Programming Guide (2009) for PD variable without sign. But i couldn't find any. So i thought you people can give me clear understanding about that. Now i got a proof to show them. Thanks a lot for the info |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| They said we can have PD value without sign bit. |
Maybe you can explain to them the the sign of a packed-decimal number is not a bit. . . It is the low-order 1/2 byte (nibble).
They also need to understand that the packed-decimal signs are:
positive (C)
negative (D)
implied positive (F) |
|
| Back to top |
|
|
|
|
