Hey, NHNF (no harm no foul). I accuse my granddaughters all the time of terminal cuteness. Even the 7 year old has yet to complain.
Yes, I imported the semicolon from Rexx, where (I think) it's required for such constructions. So I look at the COBOL statement on one line with and without the semicolon. Scoured the Language Reference; never found where ';' is required or prohibited. If nothing else, I can use it as an ice breaker at a dull cocktail party. The other suggestions are worth exploring. I'm not thrilled with iterating the entire input file process including input open/close, but I need me some serious reiteration somehow. I don't have the wherewithal to create an elaborate file system. Most real-life applications in my world churn through a lot data, but I cannot use a smidgeon of it at this phase of testing. Thanks for the pointers. ;-) . . . 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: Saturday, April 02, 2016 3:13 PM To: [email protected] Subject: (External):COBOL Rookie Problem That would be me. The semi-colon, like the comma in code, is just "noise". It has absolutely no affect on anything. Consider this line: MOVE ; ; ; ; ; CPRIME , , , , TO , ; , ; , ARRAY-SIZE That compiles, correctly, without a peep. Since it has no point, it is pointless. In the case of the semi-colon, it is more than pointless if someone with experience of a language where a semi-colon has meaning sees it where they think it has significance. I wasn't suggesting that you were cute, or even being cute, I just thought it was cute to see the semi-colon like that. Not many COBOL coders would even think it possible to "use" a semi-colon. The same people who feel that a comma has some useful point, mainly. It is good not to use full-stops/periods. They terminate any "scope" that is currently active (so your compiler messages). If you want a one-line IF, you just type it, the compiler understands IF A = B MOVE C TO D MOVE J TO K MOVE L TO Y END-IF That's all fine for the compiler. Of course, for a program heading up the line, no-one would code it like that, but for programs like this example, who's to stop you? An IF, each IF, must be terminated. It can be terminated by a full-stop/period (my advice is not to do that), by an END-IF, or by leaving a tangle and hoping for the best (a paragraph or SECTION or end of program will terminate an outstanding scope, as will an END-PERFORM, for instance; my advice is not to to that either). If I want to ream, the reamee will know for sure. The main problem with the line of code is that it will not work the way you think. Your program runs from EXEC PGM=, so there will always be one item for the LINKAGE SECTION. That field will always have an address, it cannot be NULL with EXEC PGM= (even if you don't specify a PARM). If it *could* be NULL (you CALL your program from another program, perfectly possible, no messing about with "main" programs for COBOL on an IBM Mainframe), then you said "if the field does not have an address, move one to the filed". Which will get you a S0C4 for sure, as you know it has no address and you've not subsequently given it an address. For your situations, I'd put iterate in the WORKING-STORAGE. IF address of linkage-item = NULL, move 1 to the working-storage item, else move the linkage item to the working-storage item. Use the working-storage item in the TIMES. A more obscure way to do it: WORKING-STORAGE SECTION. 01 our-default-value PIC 9(5) VALUE 1. PROCEDURE DIVISION USING iterate. IF ADDRESS OF iterate = NULL SET ADDRESS OF iterate TO ADDRESS OF our-default-value END-IF I've got some more comments/suggestions, but I'm now wary of making them :-) On Saturday, 2 April 2016 19:45:21 UTC+1, Jesse 1 Robinson wrote: > 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
