I have PD data in the input file. Assume the value is of 3 decimals
I have round the value to 2 decimals and then convert to ZD.
Is it possible using the SORT card.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Yes, it is possible, but you haven't given enough information to make it clear what you want to do exactly.
Please show an example of the input values in your PD field and what you want for output. Do you want to round up or round down? What is the starting position and length of your PD field? What is the starting position and length you want for your ZD output field? What is the RECFM and LRECL of your input file?
So for example, 99.505 would round to 99.51, and 99.504 would round to 99.50.
I will just need to place the 3 digit past decimal place rounded number after the second number for comparison purposes / test results.
Thanks. I looked in a couple of the manuals and didn't see anything jump out at me.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
madmartinsonxx,
How about answering ALL the questions from Frank?
Frank Yaeger wrote:
What is the starting position and length of your PD field? What is the starting position and length you want for your ZD output field? What is the RECFM and LRECL of your input file?
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
madmartinsonxx wrote:
The starting position and length of the input field I would like to round is:
Code:
starting at 20 for 20 bytes
The starting position and length of the rounded output field would be:
Code:
starting at 42 for 20 bytes
The lrecl and recfm of my input and output file would be:
Code:
DCB=(RECFM=F,LRECL=080,BLKSIZE=080)
A 20 byte PD field would contain 39 digits and that would not fit in you 20 byte output field even after rounding and dropping 1 digit. I think you need to go back and review the documentation (if there is any) on the file layout.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I think he was tail-gating the original TS/OP.
Madmartin does not have PD, just the "edited" examples he has shown. It was fun to watch him "snap-to" and answer Frank's questions from years before he himself posted!
Joined: 10 Dec 2010 Posts: 96 Location: Massachusetts
heh heh. thanks Bill ! I received a hurry up email just prior to posting !what Sir Skolusu did was spot on, in time and right on. And again, as customary, thanks.
rounding with all the relative complexities...
half up,half down, half towards 0, half toward inf, half to even, half to odd
seems a good candidate for a DFSORT new builtin
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
enrico makes a good point about the rounding.
We have our "terminology". Accountants, actuaries and the likes have their own. Our terminology is "jargon" to them and vice versa.
Unfortunately, sometimes the words are the same, but mean different things in the different terminologies. "Rounding" is a good example. An accountant might ask for "rounding" and you know what "rounding" means to you. It is always worth checking what "rounding" means to them, as they might not mean the sort of stuff that Cobol does.
I remember an article, by Gerry Weinberg, from the '80s, on the problems of Jargon.
A programmer has a rush-job for a data-entry system. He's a thorough guy, so he wonders about doing an "edit" to check the validity of the part-names being loaded. He rings up the user, who is many miles away, and asks if the part names have any "special characters". The user says no. So he codes to reject non-alphanumeric characters in the part names.
System goes live. 90% of the data is rejected. Programmer looks at the data and sees lots of things like 3/4 and 5/8 (as single characters). He rings up the user and says "I thought you said there were no special characters? What are all these fractions?" The use repliers, "Oh, there's nothing special about those, we use them all the time!".
It has been an article well-worth remembering. Saved me embarrasment on a number of occasions.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Forgot to mention.
If you round to n decimal places, it is, in my experience, normal to only print those n decimal places, not the one after that gets left as zero. You'll end up with "faults" raised for "this column is always zero, why"?
