Menu
▾
▴
[Tiny-cobol-users] [Fwd: Re: Sample for testing "backwards" perform thru (fwd)]
|
From: Bill G. <bi...@cs...> - 2008-11-14 19:11:48
|
David, Not sure if you (or anyone over here) are in a position to look at this or even care, but I gleaned this from comp.lang.cobol. bill ---------------------------- Original Message ---------------------------- Subject: Re: Sample for testing "backwards" perform thru (fwd) From: "Bill Gunshannon" <bil...@cs...> Date: Fri, November 14, 2008 1:47 pm To: bi...@cs... -------------------------------------------------------------------------- Path: uni-berlin.de!individual.net!not-for-mail From: bil...@cs... (Bill Gunshannon) Newsgroups: comp.lang.cobol Subject: Re: Sample for testing "backwards" perform thru Date: 14 Nov 2008 18:40:51 GMT Organization: Computing Sciences Dept., University of Scranton Lines: 126 Message-ID: <6o5...@mi...> References: <PB1Tk.165855$f64...@fe...> <6o5...@mi...> <b6a...@s1...> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: individual.net DDY0WBw1Wiandv4LBr0XBAKkBAPsTnkpfnb9HR0VYvshgOU3Y/ Cancel-Lock: sha1:F1AXkS1zz2ggOU28s0I5BlG/j7Y= X-Newsreader: knews 1.0b.1 Xref: uni-berlin.de comp.lang.cobol:177590 In article <b6a...@s1...>, Richard <ri...@Az...> writes: > On Nov 15, 3:26 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article <PB1Tk.165855$f64.161...@fe05.news.easynews.com>, >> "William M. Klein" <wmkl...@nospam.netcom.com> writes: >> >> > There were some comments about testing support for and behavior of >> > Perform procedure-name-1 thru procedure-name-2 >> > where Procedure-name-2 actually appears BEFORE procedure-name-1 in the source >> > code. >> >> > The following is a sample program to test whether "your" compiler supports this >> > (compiles it) and what happens. I *think* (but won't swear to it) that all >> > (most?) compilers will compile this and display "In para4" and then terminate. >> >> Boy are you in for a surprise!! >> >> >> >> > (I don't think that such compiler options as "perform-type" (MF) or OPT (IBM) >> > will impact this, but I won't swear to that). >> >> > * * * >> >> > Identification Division. >> > Program-ID. PERFTHRU. >> > Procedure Division. >> > Mainline. >> > Display "In Mainline" >> > Perform Para3 Thru Para1 >> > Display "After Perform" >> > Stop Run >> > . >> > Para1. >> > Display "In para1" >> > . >> > Para2. >> > Display "In Para2" >> > . >> > Para3. >> > Display "In para3" >> > . >> > Para4. >> > Display "In para4" >> > . >> > Alternate-End. >> > Stop Run >> > . >> >> I tried it with both OpenCOBOL and TinyCOBOL. Both compiled the code without >> comment or complaint. Here are the results: >> >> OpenCOBOL: >> >> In Mainline >> In para3 >> In para4 >> >> TinyCOBOL: >> >> In Mainline >> In para3 >> After Perform >> >> But then, isn't that what "Undefined" means? :-) > TinyCobol is very broken then. Not sure I would agree with that. Undefined is undefined. Seems that grants rather a wide latitude for interpretation. > It has made an arbitrary decision to > not execute the code in Para4. For example it may have been that in > Para4 there was a GO TO Para1 that completed the PERFORM. Ah!! Now I see what you mean. Interesting point and, I would have to agree. They probably don't care, but I will likely forward this on to them. > What _is_ clearly defined is that with a PERFORM THRU the path should > 'drop through' until the end point is reached (granted it never could > be in this test). > Cobol also states what happens when a STOP RUN is reached (in > Alternate end) or if the path falls off the end of the code (ie if the > Alternate-end paragraph was removed). > The other compilers get it right. Yeah, in light of the standard. But I think the compiler should have done like the Fuji-Siemens and at least told the programmer his code was crap and give him a chance to fix it. :-) I am also glad (even though I really don't get to do COBOL for a living anymore) that I never worked ina shop that would have allowed something like this anywhere near a compiler. >> I can't make any promises but it would be fun to try it with things like >> some of my old Ryan-McFarland compilers and maybe the one from OpenVMS >> or one of the old PDP-11 COBOL's. Could be interesting to see just how >> many different ways there are to nterpret the concept. > There is only one way to correctly interpret what happens with the > code. There is nothing to direct the path of execution back to Para1 > before the STOP RUN or 'falling off the end'. Neither of which will > cause an error message. > Would you hope to find a compiler that did it differently ? As I said, I would hope to never see code like this and I think, given the availability of resources today, that all compilers should point out the folly of this kind of code. > Do you think that TinyCobol is better ? Didn't say anything was better or worse. I just ran it thru the two compilers I have close at hand and posted the results. When I have time I will run it thru other (usually much older) compilers just to see what happens. > I certainly don't want arbitrary decisions made that make programs do > something different from what the source code indicates will happen. And, of course, the real solution to this is don't write arbitrary code. Write you programs to do what you want and only what you want and you will never have to worry about the compiler making arbitrary decisions. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bil...@cs... | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bi...@cs... | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> |
