Posted: Fri Sep 07, 2007 8:12 am Post subject: DFSORT - Edit Mask Patterns
Hi All,
I am trying to figure out if the following requirement is achievable using DFSORT -
I have an amount field - S9(11)V99 COMP-3 and i need to display this field in a report as follows -
Code:
1,7,PD,EDIT=(II,III,III,III.TTS),SIGNS=(,,,-)
Code:
Input -> +123456750
Output -> 1234567.50
Input -> -532150
Output -> 5321.50-
Input -> +50
Output -> .50
Input -> +0
Output -> .00
Note : Whats bothering me are the last two cases -
I am getting
Code:
Input -> +50
Output -> 50
Input -> +0
Output -> 00
The period (.) is missing
Also 0.00 instead of .00 is not acceptable
If IIT.TTS produces 0.00 I'd bring that up with IBM.....
The way I read the EDit op-code (I've been known to be wrong) is that if the Significance starter is encountered and Previous State of Significance Indicator is off and the left 4 bits of the Source Digit is X'0000' and the right 4 bits are not a sign, then the result is the fill character and State of Significance Indicator at End of Digit Examination is turned on allowing for the Message byte (decimal point) to appear.
Heck, even my (really) old PoOp shows an example of it working the way you want.......
The way I read the EDit op-code (I've been known to be wrong) is that if the Significance starter is encountered and Previous State of Significance Indicator is off and the left 4 bits of the Source Digit is X'0000' and the right 4 bits are not a sign, then the result is the fill character and State of Significance Indicator at End of Digit Examination is turned on allowing for the Message byte (decimal point) to appear.
Sorry, I am new to this jargon But does that mean that
Joined: 26 Nov 2002 Posts: 12378 Topics: 75 Location: San Jose
Posted: Fri Sep 07, 2007 10:33 am Post subject:
Quote:
If IIT.TTS produces 0.00 I'd bring that up with IBM.....
No, it means that (if I understand the edit opcode) IIT.TT should produce .00
CICS Guy,
Hmm T indicates a significant digit. If zero, this digit will be shown. It is just similar to the 9 in cobol whereas I is equivalent to Z in cobol
so an edit mask of IIT.TT would show as 0.00
I know how it works in COBOL, but I was thinking that sort would be using the assembler opcode ED which implies that if the significance character is hit with a zero, the zero is suppressed and the significance flag is turned on after processing that zero so the following message characters (the decimal point) would be generated......
Or at least, that
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Fri Sep 07, 2007 11:00 am Post subject:
Raveendra,
A T indicates a leading zero that should not be suppressed. For all zeros, everything before the first T will be replaced by blanks. So EDIT=(IT.TT) will give ' 0.00'.
An I indicates a leading zero that should be suppressed. Again, for all zeros, everything before the first T will be replaced by blanks. So EDIT=(II.TT) will give ' 00'. The period is replaced with a blank because it is before the first T.
In order to get .dd instead of dd, you'd have to post-process the value. For example:
_________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
But I am accepting the solution with a pinch of salt
The actual requirement was to generate a report with two files as input one of which has this amount field. We have been achieving this by COBOL at our shop. But I thought of trying out the same using DFSORT.
Post-processing for the period might not 'sound convincing' to my technical superiors. Let me try my luck....
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Fri Sep 07, 2007 11:52 am Post subject:
Well, it's only "post-processing" in the sense that you have to hit the field twice. But in terms of actual processing, you're using an INREC statement to do everything in one pass. Don't call it "post-processing" when you talk to your "technical superiors".
Maybe you could ask your "technical superiors" to explain why you have to show .00 instead of 0.00 in the report. I'd guess that 0.00 is the much more generally accepted way to display a zero value. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Fri Sep 07, 2007 12:32 pm Post subject:
Quote:
Thank you in advance.
No, sorry. You're not done yet.
I can show you how to do what you want, but first we have to fix the problems in your statements. You have some blanks that shouldn't be there and too many commas in SIGNS. I can fix those up to get:
But you have an overlapping positon (28) for the PD fields - 22,7 -> 22-28 and 28,7 -> 28-34 - that can't be right. What should the positions be? _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
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
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
But does that mean that
I'd guess that 0.00 is the much more generally accepted way to display a zero value.