It is really interesting discussion and have a small clarification. When i change the Input file and the byte location, i didnt get your expected result, Please clarify.
Consider my Input file is 133 byte LRECL and the conversion numeric field starts at 15 th byte.
Input file is :-
Code:
=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----
****** ***************************** Top of Data **********************
000100 aaaaaarrrrrrrr89990.99 34344
000200 XXXX 89.10 20087
000300 AAAA 89 53200 20900
000400 AAAA 45.100 20900
********************************* TOP OF DATA *************
aaaaaarrrrrrrr0089990.9900.99 34344
XXXX 0000089.1000 20087
AAAA 89 0053200.0000 20900
AAAA 0000045.10000 20900
******************************** BOTTOM OF DATA ***********
I think, it looks like my understading of the byte positions are wrong.
Joined: 26 Nov 2002 Posts: 12378 Topics: 75 Location: San Jose
Posted: Sun May 18, 2008 1:02 pm Post subject:
tt_sav,
You changed the pos of the numeric field but you forgot to change the position of the other fields following the numeric field. In my example I assumed the rest of the fields start at pos 19 and the input file length is 80.
Change your input to the following. Pay attention to the contents in bold.
Great Kolusu, it is working fine. I really appriciate your "workaholic", eventhough in weekend. Thanks to everyone in part of the discussion, to know this logic.
My apologies for making this discussion to long, how ever it is very useful for me and everyone. Well, we are facing difficulties with this new input file.
Input LRECL = 128 and 11 byte conversion field starts at 11 th byte and also have other numeric field in this file, apart from the 11th byte field.
Input file is below,
Code:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
********************************* Top of Data ************************
00780.NO .00000000003.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000010.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000014.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000015.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000020.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000021.02/01/2008.12/31/9999.0000000000.04784....................
Thanks. Well, Some of the records are in the Position 11 have decimal point and most of them have whole number, since we stictly concentrate at Poision 11 with 11 byte field.
Since, i already tested with whole number and decimal numbers as well. The output, we expect
if whole numbers, it will take numeric field along with 3 digit fractional number.
if any decimal numbers, it will format it with 7 digit whole no. and decimal
point with 3 digit fraction number ie., 9(7).9(3).
Kolusu, Hope i cleared, please help me to resolve this problem.
Joined: 26 Nov 2002 Posts: 12378 Topics: 75 Location: San Jose
Posted: Thu Jul 03, 2008 3:17 pm Post subject:
sabarisavi,
The output you show has a few problems. How did you get 0000300.500 on the first record? It doesn't have any decimal positions on the record. How did you end up with .500?
Also the last numeric field you show 5 decimals on the 2 and 3 records but on the 1st record you only 4 decimals.
What are the rules governing the decimals?
Assuming that they are typos , here is a DFSORT JCL which will give the desired results
FYI - The decimal values are not amount / pricing information , they are the drug dosages, since, the drug values /drug density are differ for each fractions. that is 0.2570 differ 0.25. So, the inputs are correct and it s not a typo.
Kolusu - The suggested code, is changed the last numeric field, we want to format the 11 byte field only not all the numeric field.
I will recap my requirement here:
Input file LRECL = 128 and the Output file also the same. We have to change only the 11th byte of X(11) will format to 9(7).9(3).
We want to change the 11 byte alphanumeric field to 9(7).9(3) format which the position starts at 11th byte. The X(11) byte Unit dosage field may have any decimal field or whole number or any zeros.
For example,
Input
Code:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
********************************* Top of Data ************************
00780.NO .000000003.5.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO . 88.10.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000056.014.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000330.015.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .00000000020.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000000.002.02/01/2008.12/31/9999.0000000000.04784....................
Expected Output
Code:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
********************************* Top of Data ************************
00780.NO .0000003.500.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000088.100.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000056.014.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000330.015.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000020.000.02/01/2008.12/31/9999.0000000000.04784....................
00780.NO .0000000.002.02/01/2008.12/31/9999.0000000000.04784....................
Except the first record, all other records formatted to 9(7).9(3). But the first record, we see there was a low-value was added in the decimal field.
Ie., 0000003.5 0
I hope there is a small changes required in our existing sysin, Could please give me your valuable suggestion.
All times are GMT - 5 Hours Goto page Previous1, 2, 3Next
Page 2 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum