|
View previous topic :: View next topic
|
| Author |
Message |
Mumblez
New User
Joined: 27 Apr 2007
Posts: 7
Location: Philippines
|
|
|
|
Hi,
How can you convert 398388.53 as PD to 00000003983885C (ZD? or CH?) format?
| Code: |
//SYSIN DD *
OPTION COPY
INCLUDE COND=(1,2,CH,EQ,C'64')
OUTFIL NODETAIL,REMOVECC,
TRAILER1=(5:MIN=(5,5,UFF,M11,LENGTH=5),
20:COUNT=(M11,LENGTH=9),
-----> 29:TOT=(54,5,PD,TO=ZD,LENGTH=15),
|
398388.53 is the result of TOT which will have an output of '000000039838853' but I need to have it formatted to '00000003983885C'
Thanks in advance for your help!  |
|
| Back to top |
|
 |
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
You can just use DFSORT's ZDC format instead of ZD:
| Code: |
29:TOT=(54,5,PD,TO=ZDC,LENGTH=15),
|
ZDC gives a C sign for positive values where ZD or ZDF gives an F sign for positive values. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I may be confused here, but how can a "real" decimal point be in a packed-decimal field
| Quote: |
| How can you convert 398388.53 as PD |
If there is a '.' in the data, PD is not the correct type  |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
Dick,
I assumed the decimal point is implicit (it's not stored internally but is known to be there) as it always is in a PD value. I think many people who work with COBOL (or other languages) aren't aware of how the data is actually stored internally - they just look at the COBOL external definition which includes the decimal point. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Frank,
Yup, unfortunately
| Quote: |
| I think many people who work with COBOL (or other languages) aren't aware of how the data is actually stored internally |
this is all too true.
[sigh]Not understanding how their data is physically stored causes many of the newer folks much consternation and confusion. It also explains why trying to resolve something like an 0c7 is a more involved task than it would be if there was understanding of how data was stored.[/sigh] |
|
| Back to top |
|
|
Mumblez
New User
Joined: 27 Apr 2007
Posts: 7
Location: Philippines
|
|
|
|
Hi,
The '398388.53' stored as comp-3 is its value when the file is browsed through famvs with a display format of '000000039838853' (PD), that's what it meant.
Anyway, thank you guys very much, it worked!!!
Frank, you're awesome!!! |
|
| Back to top |
|
|
Mumblez
New User
Joined: 27 Apr 2007
Posts: 7
Location: Philippines
|
|
|
|
Hi,
follow up question.
how do i populate the rest of the trailer to high values?
right now, I am using multiple lines of X'FFFFFFFFFFFF...'
so my trailer would have an output fillers of dots as required.
is there any easier way? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello D-D,
I'm surprised that this display
| Quote: |
| famvs with a display format of '000000039838853' (PD) |
doesn't include the sign
What would be displayed via famvs if the PD number was negative? |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
how do i populate the rest of the trailer to high values?
right now, I am using multiple lines of X'FFFFFFFFFFFF...'
so my trailer would have an output fillers of dots as required.
is there any easier way? |
Yes, you can use nX'FF' where n is the number of X'FF' characters you need. n can be 1 to 4095 and you can use multiple nX'FF' characters if you need more than 4095 of them (e.g. 4095X'FF',4000X'FF'). |
|
| Back to top |
|
|
Mumblez
New User
Joined: 27 Apr 2007
Posts: 7
Location: Philippines
|
|
|
|
| Thanks a lot. |
|
| Back to top |
|
|
|
|
