I need closure on one point. Someone (can't find the post) reamed me for this line:
IF ADDRESS OF exec-parm = NULL THEN MOVE 1 TO iterate; END-IF I was accused of being 'cute'. I have not been cute since before the war; no, I mean the war before that one. The object of humiliation was the semicolon. If not semicolon, then what? I don't want to waste a line. Can the semicolon simply be omitted? Can END-IF simply be omitted? There is no ELSE in the logic. There is also no period here, nor do I want one after trying to insert periods that drove the complier nuts. Please advise. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jesse 1 Robinson Sent: Friday, April 01, 2016 5:09 PM To: [email protected] Subject: Re: COBOL Rookie Problem An update for anyone who cares. My motivation was to get a preview of how real application programs might benefit from ABO. As an electric utility, we have millions of customers and millions of account records. We don't do elaborate calculations for most customers. Think what it might take to produce your monthly bill. Many factors are included, but neither astronomical nor particle physics gets dragged in to determine how much juice you burned and what you're on the hook for. I beefed up my program a bit to add more arithmetic so that each O/P record now involves addition, multiplication, division, and square root (just for fun). And a lot of records. I also took David Jousma's prime number program (thanks!) to use as a second test case. Running bare metal, David's program uses about 1/3 second of CPU time on a z12. Mine takes a little over half a minute. How these results compare with real-life work is still a guess, but the application folks are totally saturated with another project right now. For me it's either try something or do nothing. ABO results are pending. P.S. my COBOL is now 1000% better than it was a week ago! . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Friday, April 01, 2016 1:04 AM To: [email protected] Subject: (External):COBOL Rookie Problem I know what you're saying, and would normally agree where "incremental" performance benefits were expected - knocking up a couple of test programs may not reflect what would normally occur. However, this is far from incremental. V4 generates "ESA" machine-code. ABO can do ARCH 10 or 11. In the example, DFP (if used by ABO) is going to provide substantial performance improvements on arithmetic with zoned-decimal. There is still improved performance with packed-decimal. Leads to the idea that all decimal arithmetic will improve. I few verification programs before tossing it at real programs seems to me a good idea, in this type of case. If something doesn't work as expected, it can be investigated in isolation, without having to untie it from other stuff, or, more likely, miss it altogether. On Friday, 1 April 2016 08:49:21 UTC+1, Andrew Rowley wrote: > On 01/04/2016 06:26 PM, Bill Woodger wrote: > > Andrew, I don't think it would be difficult at all. Especially for ARCH 11, > > there's some substantial differences in that example of what code would be > > possible (with V5 or V6), so it will be interesting to see if the ABO takes > > full advantage. > > I'm not doubting that there would be benefits, just whether you could > quantify them from a test program. It's hard to predict whether the > benefits would be more, less or the same. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
