f



COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

I no longer read here often, but because I apparently have nothing better to do I have written a probably too long document detailing why I believe that Enterprise COBOL should support an extension to COBOL to support a native syntax for unbounded loops.

See my document attached to the following post on the IBM COBOL Cafe Forum: https://www.ibm.com/developerworks/community/forums/html/topic?id=8cb11f10-03c9-4b82-9123-ba5ebc2240ff&ps=25

Frank
0
Frank
8/12/2016 12:10:29 AM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

14 Replies
431 Views

Similar Articles

[PageSpeed] 4

On Friday, August 12, 2016 at 12:10:31 PM UTC+12, Frank Swarbrick wrote:
> I no longer read here often, but because I apparently have nothing better=
 to do I have written a probably too long document detailing why I believe =
that Enterprise COBOL should support an extension to COBOL to support a nat=
ive syntax for unbounded loops.
>=20
> See my document attached to the following post on the IBM COBOL Cafe Foru=
m: https://www.ibm.com/developerworks/community/forums/html/topic?id=3D8cb1=
1f10-03c9-4b82-9123-ba5ebc2240ff&ps=3D25
>=20
> Frank

Hi Frank,

I read your paper and found it interesting, but there is a lack of perspect=
ive to it. (Often happens when we are passionate about something and too cl=
ose to it.)

If you step back from it you will realize that you are requesting action fr=
om other people over something that is a "Non-problem".

Unbounded loops can be easily implemented in COBOL and most other languages=
 and your objections are purely aesthetic. (You suggested several different=
 solutions using existing standard coding constructs, so it can hardly be a=
 "show-stopper"...)

I agree that sometimes aesthetics are a good enough reason to implement som=
ething, but when I feel that way it is generally down to me to implement it=
.... :-) You are a little peeved because a commercial organization (IBM) are=
 not prepared to make the investment into COBOL which you would like to see=
 them make, but that would cost them money and your case simply isn't stron=
g enough to warrant it.=20

The fact that other vendors have done it cuts no ice. "It's not in the stan=
dard" is an irrefutable justification for not doing it.(You pointed out tha=
t they extend the standard when it suits them, but that is down to them and=
 makes it entirely their call. If you think about it, that is fair; it is t=
hey who do the work...)

If you REALLY want this to happen, I see 2 options:

1. Reverse engineer their compiler so it accepts PERFORM FOREVER, or whatev=
er else you want it to do... (I did this once many years ago with a differe=
nt vendor's multi pass COBOL compiler. (I started out patching it to accept=
 input from magnetic media (it could only read punched card decks) but then=
 I became fascinated by the way it worked and added some "COBOL extensions"=
 of my own... :-) It really isn't as hard as you might think, given you hav=
e fluency with the Assembler. (Especially if you are motivated enough... I =
was.) The parsing of COBOL source is pretty easy to spot, and good compiler=
s use transition diagramming to speed the detection of reserved words, whic=
h makes it easy to add new words to the trees...=20

Of course, the place where you work won't let you use your non-standard com=
piler in production, but if you can demonstrate that it works as intended, =
and NOTHING else has been affected, it will give you the high moral ground =
and you could argue that it's really a trivial amendment and you'll be happ=
y to supply the code for IBM to check...

2. Identify the department at IBM charged with COBOL maintenance and tell t=
hem what you did and why you did it. Send them a copy. Sometimes, like-mind=
ed people can bypass red tape and just do something...

For myself, I thought some of your code examples were unwieldy and made bad=
 use of some of the constructs we DO have; for example, I don't like the id=
ea of your PERFORM FOREVER controlling file access (That control should be =
in the mainline, in my opinion, with AT END and NOT AT END controlling what=
 happens when records are read.) And you marked use of sections as "bad" wh=
en some sites see them as "good", but these are old chestnuts which have be=
en done to death many times.

The fact is that programmers will seldom agree on things that are matters o=
f opinion and that is why patterns are so useful.(If a site standardizes on=
 certain patterns, everyone knows where they stand) If a program works, the=
n the code is not "wrong", but perhaps some other aspects of it could be im=
proved...

Good luck!

Pete.

0
dashwood
8/15/2016 3:10:09 PM
Thanks for your thoughts, Pete.

I am curious, if I move my perform loop inside of MAIN like the following, =
do you still find this unwieldy or misusing of existing constructs?  If so,=
 please elaborate.

 MAIN.
     OPEN INPUT MY-FILE
     PERFORM UNTIL EXIT
         READ MY-FILE=20
              INTO MY-RECORD
         AT END
             EXIT PERFORM
         NOT AT END
             PERFORM PROCESS-MY-RECORD
         END-READ
     END-PERFORM
     CLOSE MY-FILE
     STOP RUN.

 PROCESS-MY-RECORD.
     DISPLAY MY-RECORD.

And no, I'm not going to hack their compiler.  Some day I might even stop o=
bsessing on it.  But don't count on it.

As for sections, now that there is EXIT SECTION and you can use it where pr=
eviously you would have just had a "section exit paragraph" with just EXIT =
in it, I dare say they have become a bit "safer".

Frank

On Monday, August 15, 2016 at 9:10:12 AM UTC-6, dash...@enternet.co.nz wrot=
e:
> On Friday, August 12, 2016 at 12:10:31 PM UTC+12, Frank Swarbrick wrote:
> > I no longer read here often, but because I apparently have nothing bett=
er to do I have written a probably too long document detailing why I believ=
e that Enterprise COBOL should support an extension to COBOL to support a n=
ative syntax for unbounded loops.
> >=20
> > See my document attached to the following post on the IBM COBOL Cafe Fo=
rum: https://www.ibm.com/developerworks/community/forums/html/topic?id=3D8c=
b11f10-03c9-4b82-9123-ba5ebc2240ff&ps=3D25
> >=20
> > Frank
>=20
> Hi Frank,
>=20
> I read your paper and found it interesting, but there is a lack of perspe=
ctive to it. (Often happens when we are passionate about something and too =
close to it.)
>=20
> If you step back from it you will realize that you are requesting action =
from other people over something that is a "Non-problem".
>=20
> Unbounded loops can be easily implemented in COBOL and most other languag=
es and your objections are purely aesthetic. (You suggested several differe=
nt solutions using existing standard coding constructs, so it can hardly be=
 a "show-stopper"...)
>=20
> I agree that sometimes aesthetics are a good enough reason to implement s=
omething, but when I feel that way it is generally down to me to implement =
it... :-) You are a little peeved because a commercial organization (IBM) a=
re not prepared to make the investment into COBOL which you would like to s=
ee them make, but that would cost them money and your case simply isn't str=
ong enough to warrant it.=20
>=20
> The fact that other vendors have done it cuts no ice. "It's not in the st=
andard" is an irrefutable justification for not doing it.(You pointed out t=
hat they extend the standard when it suits them, but that is down to them a=
nd makes it entirely their call. If you think about it, that is fair; it is=
 they who do the work...)
>=20
> If you REALLY want this to happen, I see 2 options:
>=20
> 1. Reverse engineer their compiler so it accepts PERFORM FOREVER, or what=
ever else you want it to do... (I did this once many years ago with a diffe=
rent vendor's multi pass COBOL compiler. (I started out patching it to acce=
pt input from magnetic media (it could only read punched card decks) but th=
en I became fascinated by the way it worked and added some "COBOL extension=
s" of my own... :-) It really isn't as hard as you might think, given you h=
ave fluency with the Assembler. (Especially if you are motivated enough... =
I was.) The parsing of COBOL source is pretty easy to spot, and good compil=
ers use transition diagramming to speed the detection of reserved words, wh=
ich makes it easy to add new words to the trees...=20
>=20
> Of course, the place where you work won't let you use your non-standard c=
ompiler in production, but if you can demonstrate that it works as intended=
, and NOTHING else has been affected, it will give you the high moral groun=
d and you could argue that it's really a trivial amendment and you'll be ha=
ppy to supply the code for IBM to check...
>=20
> 2. Identify the department at IBM charged with COBOL maintenance and tell=
 them what you did and why you did it. Send them a copy. Sometimes, like-mi=
nded people can bypass red tape and just do something...
>=20
> For myself, I thought some of your code examples were unwieldy and made b=
ad use of some of the constructs we DO have; for example, I don't like the =
idea of your PERFORM FOREVER controlling file access (That control should b=
e in the mainline, in my opinion, with AT END and NOT AT END controlling wh=
at happens when records are read.) And you marked use of sections as "bad" =
when some sites see them as "good", but these are old chestnuts which have =
been done to death many times.
>=20
> The fact is that programmers will seldom agree on things that are matters=
 of opinion and that is why patterns are so useful.(If a site standardizes =
on certain patterns, everyone knows where they stand) If a program works, t=
hen the code is not "wrong", but perhaps some other aspects of it could be =
improved...
>=20
> Good luck!
>=20
> Pete.

0
Frank
8/15/2016 5:08:27 PM
Frank Swarbrick wrote:
> Thanks for your thoughts, Pete.
>
> I am curious, if I move my perform loop inside of MAIN like the
> following, do you still find this unwieldy or misusing of existing
> constructs?  If so, please elaborate.
>
>  MAIN.
>      OPEN INPUT MY-FILE
>      PERFORM UNTIL EXIT
>          READ MY-FILE
>               INTO MY-RECORD
>          AT END
>              EXIT PERFORM
>          NOT AT END
>              PERFORM PROCESS-MY-RECORD
>          END-READ
>      END-PERFORM
>      CLOSE MY-FILE
>      STOP RUN.
>
>  PROCESS-MY-RECORD.
>      DISPLAY MY-RECORD.


Yes, to my eye that code is simple and clear. The point is that  the 
mainline should be controlling what happens. There could be other functions 
which are not related to data access and if the mainline is in control we 
will find them being activated in the place where we would execct to find 
them.

Maybe after writing Classes for so long, I have become used to encapsulation 
of functions. I agree it is arguable.

>
> And no, I'm not going to hack their compiler.  Some day I might even
> stop obsessing on it.  But don't count on it.

Never say "Never" :-) I think you'd enjoy it...

>
> As for sections, now that there is EXIT SECTION and you can use it
> where previously you would have just had a "section exit paragraph"
> with just EXIT in it, I dare say they have become a bit "safer".

There was never any danger provided the whole SECTION was always PERFORMed, 
and ONLY that SECTION...

I have been using SECTIONs in COBOL for over 50 years now, always with ONE 
entry point and ONE exit point. :-)

Never had a problem and many people have maintained my code without 
complaint.

However, you are right that, in the interests of "GO TO less" programming, I 
WOULD use EXIT SECTION nowadays.


>
> Frank
>
> On Monday, August 15, 2016 at 9:10:12 AM UTC-6,
> dash...@enternet.co.nz wrote:
>> On Friday, August 12, 2016 at 12:10:31 PM UTC+12, Frank Swarbrick
>> wrote:
>>> I no longer read here often, but because I apparently have nothing
>>> better to do I have written a probably too long document detailing
>>> why I believe that Enterprise COBOL should support an extension to
>>> COBOL to support a native syntax for unbounded loops.
>>>
>>> See my document attached to the following post on the IBM COBOL
>>> Cafe Forum:
>>> https://www.ibm.com/developerworks/community/forums/html/topic?id=8cb11f10-03c9-4b82-9123-ba5ebc2240ff&ps=25
>>>
>>> Frank
>>
>> Hi Frank,
>>
>> I read your paper and found it interesting, but there is a lack of
>> perspective to it. (Often happens when we are passionate about
>> something and too close to it.)
>>
>> If you step back from it you will realize that you are requesting
>> action from other people over something that is a "Non-problem".
>>
>> Unbounded loops can be easily implemented in COBOL and most other
>> languages and your objections are purely aesthetic. (You suggested
>> several different solutions using existing standard coding
>> constructs, so it can hardly be a "show-stopper"...)
>>
>> I agree that sometimes aesthetics are a good enough reason to
>> implement something, but when I feel that way it is generally down
>> to me to implement it... :-) You are a little peeved because a
>> commercial organization (IBM) are not prepared to make the
>> investment into COBOL which you would like to see them make, but
>> that would cost them money and your case simply isn't strong enough
>> to warrant it.
>>
>> The fact that other vendors have done it cuts no ice. "It's not in
>> the standard" is an irrefutable justification for not doing it.(You
>> pointed out that they extend the standard when it suits them, but
>> that is down to them and makes it entirely their call. If you think
>> about it, that is fair; it is they who do the work...)
>>
>> If you REALLY want this to happen, I see 2 options:
>>
>> 1. Reverse engineer their compiler so it accepts PERFORM FOREVER, or
>> whatever else you want it to do... (I did this once many years ago
>> with a different vendor's multi pass COBOL compiler. (I started out
>> patching it to accept input from magnetic media (it could only read
>> punched card decks) but then I became fascinated by the way it
>> worked and added some "COBOL extensions" of my own... :-) It really
>> isn't as hard as you might think, given you have fluency with the
>> Assembler. (Especially if you are motivated enough... I was.) The
>> parsing of COBOL source is pretty easy to spot, and good compilers
>> use transition diagramming to speed the detection of reserved words,
>> which makes it easy to add new words to the trees...
>>
>> Of course, the place where you work won't let you use your
>> non-standard compiler in production, but if you can demonstrate that
>> it works as intended, and NOTHING else has been affected, it will
>> give you the high moral ground and you could argue that it's really
>> a trivial amendment and you'll be happy to supply the code for IBM
>> to check...
>>
>> 2. Identify the department at IBM charged with COBOL maintenance and
>> tell them what you did and why you did it. Send them a copy.
>> Sometimes, like-minded people can bypass red tape and just do
>> something...
>>
>> For myself, I thought some of your code examples were unwieldy and
>> made bad use of some of the constructs we DO have; for example, I
>> don't like the idea of your PERFORM FOREVER controlling file access
>> (That control should be in the mainline, in my opinion, with AT END
>> and NOT AT END controlling what happens when records are read.) And
>> you marked use of sections as "bad" when some sites see them as
>> "good", but these are old chestnuts which have been done to death
>> many times.
>>
>> The fact is that programmers will seldom agree on things that are
>> matters of opinion and that is why patterns are so useful.(If a site
>> standardizes on certain patterns, everyone knows where they stand)
>> If a program works, then the code is not "wrong", but perhaps some
>> other aspects of it could be improved...
>>
>> Good luck!
>>
>> Pete.

The Notebook I normally use to access this forum has a broken keyboard and I 
spent several hours today trying to fix it. (Certain Keys don't work so it 
is probably a keyboard ribbon problem...)

I rigged up a Wireless keyboard to write this response, but it is not 
comfortable. I need to trim the ribbon but I'm scared to apply pressure to 
the motherboard connection and I'm really too busy with other stuff at the 
moment to deal with it properly...

When I have finished the current project I'll attend to it and revist here a 
bit more often.

Cheers,

Pete.


-- 
"I used to write COBOL...now I can do anything." 


0
Pete
8/18/2016 6:46:39 AM
In article <e1l3ugFptb9U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>However, you are right that, in the interests of "GO TO less" programming, I 
>WOULD use EXIT SECTION nowadays.


If there is minimal functional difference - and by this I intend 'the 
compiler-generated code is pretty much equivalent - then the only reason I 
can see for deprecating

    PERFORM PARA-NAME THRU PARA-NAME-EX
....
PARA-NAME.
    IF DONT-NEED-TO-DO
        GO TO PARA-NAME-EX
....
    .
PARA-NAME-EX.
    EXIT.

.... in favor of

PERFORM SECTION-NAME
....
SECTION-NAME.
    IF DONT-NEED-TO-DO
        EXIT SECTION

.... is a kind of prissiness.  Never mind the eternal Section v Paragraph 
War.

DD
0
docdwarf
8/18/2016 12:07:01 PM
On Thu, 18 Aug 2016 12:07:01 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <e1l3ugFptb9U1@mid.individual.net>,
>Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>[snip]
>
>>However, you are right that, in the interests of "GO TO less" programming, I 
>>WOULD use EXIT SECTION nowadays.
>
>
>If there is minimal functional difference - and by this I intend 'the 
>compiler-generated code is pretty much equivalent - then the only reason I 
>can see for deprecating
>
>    PERFORM PARA-NAME THRU PARA-NAME-EX
>...
>PARA-NAME.
>    IF DONT-NEED-TO-DO
>        GO TO PARA-NAME-EX
>...
>    .
>PARA-NAME-EX.
>    EXIT.
>
>... in favor of
>
>PERFORM SECTION-NAME
>...
>SECTION-NAME.
>    IF DONT-NEED-TO-DO
>        EXIT SECTION
>
>... is a kind of prissiness.  Never mind the eternal Section v Paragraph 
>War.
Actually at least for IBM compilers, there probably is a difference in
that the compiler can optimize the code by such things as code
movement and generating more efficient PERFORM EXIT combinations with
the EXIT PARAGRAPH / SECTION while I believe the presence of the GO TO
in the first example precludes optimization.

Clark Morris 
>
>DD
0
Clark
8/18/2016 2:41:35 PM
Here is an example (from a production program!!!!) of why some people here consider sections to be dangerous:

     [...]
     PERFORM 9500-ACCUM-BRANCH-DEBITS                 
             VARYING BRANCH-SUB FROM 1 BY 1               
              UNTIL BE-BRANCH-NO (BRANCH-SUB) EQUAL 999
     [...]


 9500-ACCUM-BRANCH-DEBITS SECTION.                                
     SKIP1                                                        
     IF BE-BRANCH-AFF-DEP-NET-POS (BRANCH-SUB) GREATER THAN -1    
         GO TO 9599-EXIT-SECTION-9500.                            
     SKIP1                                                        
     MOVE SPACES                    TO BANK-BRANCH-LOOKUP-FIELDS. 
     MOVE BE-BRANCH-NO (BRANCH-SUB) TO BBLF-OLD-BRANCH-NBR.       
                                                                  
     CALL BBLF-PROGRAM USING BANK-BRANCH-LOOKUP-FIELDS.           
                                                                  
     IF BBLF-NEW-BANK-NBR EQUAL TO BE-BANK-NO (BANK-SUB)          
         COMPUTE WORK-AMT-2 EQUAL WORK-AMT-2 -                    
             (AFF-DEP-FEE *                                       
             BE-BRANCH-AFF-DEP-NET-POS (BRANCH-SUB)).             
     SKIP1                                                        
 9599-EXIT-SECTION-9500.                                          
     EXIT.                                                        
                                                                  
 9600-CALDTE-SECTION.                                             
     CONTINUE.                                                    
     COPY CALDTEPD.                                               
     CONTINUE.                                                    
 9600-EXIT-SECTION-9600.                                          
     EXIT.                                                        

Because some erroneously included everything from 9600-CALDTE-SECTION through 9600-EXIT-SECTION-9600 within the 9500-ACCUM-BRANCH-DEBITS section, those paragraphs are being executed each time there is a PERFORM 9500-ACCUM-BRANCH-DEBITS.

Had 9599-EXIT-SECTION-9500 contained EXIT SECTION instead of the no-op EXIT the program, though still not "correct" as such, would have executed as was intended.

That's the point I was trying to make about judicious use of EXIT SECTION.

Frank
0
Frank
8/18/2016 5:40:35 PM
In article <61ibrb142l2jcjf993eka7dn05ogbjvedr@4ax.com>,
Clark F Morris  <cfmpublic@ns.sympatico.ca> wrote:

[snip]

>Actually at least for IBM compilers, there probably is a difference in
>that the compiler can optimize the code by such things as code
>movement and generating more efficient PERFORM EXIT combinations with
>the EXIT PARAGRAPH / SECTION while I believe the presence of the GO TO
>in the first example precludes optimization.

Beliefs and probabilities are one thing, Mr Morris... a PMAP can be quite 
another.

(yes, I know that IGYCRCTL uses LIST... and don't git me started on what 
those durned kids're callin' 'music' nowadays, neither!)

DD

0
docdwarf
8/18/2016 5:54:20 PM
In article <00318152-a1a0-4adc-bbc0-d8a0eef9b56c@googlegroups.com>,
Frank Swarbrick  <fswarbrick@gmail.com> wrote:
>Here is an example (from a production program!!!!) of why some people
>here consider sections to be dangerous:

[snip]

> 9600-CALDTE-SECTION.                                             

Production Pre-Implentation Code Review was scheduled right after lunch, 
yes?

DD

0
docdwarf
8/18/2016 5:56:07 PM
On Thu, 18 Aug 2016 17:54:20 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <61ibrb142l2jcjf993eka7dn05ogbjvedr@4ax.com>,
>Clark F Morris  <cfmpublic@ns.sympatico.ca> wrote:
>
>[snip]
>
>>Actually at least for IBM compilers, there probably is a difference in
>>that the compiler can optimize the code by such things as code
>>movement and generating more efficient PERFORM EXIT combinations with
>>the EXIT PARAGRAPH / SECTION while I believe the presence of the GO TO
>>in the first example precludes optimization.
>
>Beliefs and probabilities are one thing, Mr Morris... a PMAP can be quite 
>another.
>
>(yes, I know that IGYCRCTL uses LIST... and don't git me started on what 
>those durned kids're callin' 'music' nowadays, neither!)

Lacking access to an IBM mainframe,I can;t check my supposition but
the supposition is based on my experience with OS/VS COBOL Release 1.4
thru COBOL FOR MVS and VM and probably COBOL OS390.  If you have
access could you check my supposition?  I realize this is homework but
since I am retired, I have fewer mainframe (none) toys to play with.

Clark Morris
>
>DD
0
Clark
8/18/2016 7:29:08 PM
On Thursday, August 18, 2016 at 11:56:08 AM UTC-6, docd...@panix.com wrote:
> In article <00318152-a1a0-4adc-bbc0-d8a0eef9b56c@googlegroups.com>,
> Frank Swarbrick  <fswarbrick@gmail.com> wrote:
> >Here is an example (from a production program!!!!) of why some people
> >here consider sections to be dangerous:
> 
> [snip]
> 
> > 9600-CALDTE-SECTION.                                             
> 
> Production Pre-Implentation Code Review was scheduled right after lunch, 
> yes?

Nobody's perfekt.
0
Frank
8/19/2016 3:23:54 PM
On Thursday, August 18, 2016 at 1:29:10 PM UTC-6, Clark F Morris wrote:
> On Thu, 18 Aug 2016 17:54:20 +0000 (UTC), docdwarf@panix.com () wrote:
> 
> >In article <61ibrb142l2jcjf993eka7dn05ogbjvedr@4ax.com>,
> >Clark F Morris  <cfmpublic@ns.sympatico.ca> wrote:
> >
> >[snip]
> >
> >>Actually at least for IBM compilers, there probably is a difference in
> >>that the compiler can optimize the code by such things as code
> >>movement and generating more efficient PERFORM EXIT combinations with
> >>the EXIT PARAGRAPH / SECTION while I believe the presence of the GO TO
> >>in the first example precludes optimization.
> >
> >Beliefs and probabilities are one thing, Mr Morris... a PMAP can be quite 
> >another.
> >
> >(yes, I know that IGYCRCTL uses LIST... and don't git me started on what 
> >those durned kids're callin' 'music' nowadays, neither!)
> 
> Lacking access to an IBM mainframe,I can;t check my supposition but
> the supposition is based on my experience with OS/VS COBOL Release 1.4
> thru COBOL FOR MVS and VM and probably COBOL OS390.  If you have
> access could you check my supposition?  I realize this is homework but
> since I am retired, I have fewer mainframe (none) toys to play with.
> 
> Clark Morris
> >
> >DD

Can you clarify what you want tested?  With code examples?  I can test with Enterprise COBOL V4.2 and/or V5.2.
0
Frank
8/19/2016 3:25:08 PM
On Fri, 19 Aug 2016 08:25:08 -0700 (PDT), Frank Swarbrick
<fswarbrick@gmail.com> wrote:

>On Thursday, August 18, 2016 at 1:29:10 PM UTC-6, Clark F Morris wrote:
>> On Thu, 18 Aug 2016 17:54:20 +0000 (UTC), docdwarf@panix.com () wrote:
>> 
>> >In article <61ibrb142l2jcjf993eka7dn05ogbjvedr@4ax.com>,
>> >Clark F Morris  <cfmpublic@ns.sympatico.ca> wrote:
>> >
>> >[snip]
>> >
>> >>Actually at least for IBM compilers, there probably is a difference in
>> >>that the compiler can optimize the code by such things as code
>> >>movement and generating more efficient PERFORM EXIT combinations with
>> >>the EXIT PARAGRAPH / SECTION while I believe the presence of the GO TO
>> >>in the first example precludes optimization.
>> >
>> >Beliefs and probabilities are one thing, Mr Morris... a PMAP can be quite 
>> >another.
>> >
>> >(yes, I know that IGYCRCTL uses LIST... and don't git me started on what 
>> >those durned kids're callin' 'music' nowadays, neither!)
>> 
>> Lacking access to an IBM mainframe,I can;t check my supposition but
>> the supposition is based on my experience with OS/VS COBOL Release 1.4
>> thru COBOL FOR MVS and VM and probably COBOL OS390.  If you have
>> access could you check my supposition?  I realize this is homework but
>> since I am retired, I have fewer mainframe (none) toys to play with.
>> 
>> Clark Morris
>> >
>> >DD
>
>Can you clarify what you want tested?  With code examples?  I can test with Enterprise COBOL V4.2 and/or V5.2.

I was responding to Doc Dwarf's contention that there was no practical
difference between a PERFORM section-name where the section had 2
paragraphs where the first paragraph had a "GO TO THIS-SECTION-EXIT
and the second paragraph was THIS-SECTION-EXIT. EXIT." and a PERFORM
section-name where section-name had no GO TO statements and used EXIT
SECTION.  I claimed that the presence of a GO TO would prevent
optimization such as simplified PERFORM code and code movement to
place the SECTION in line eliminating the PERFORM code.

Clark Morris
0
Clark
8/19/2016 10:50:30 PM
On Friday, August 19, 2016 at 4:50:51 PM UTC-6, Clark F Morris wrote:
> I was responding to Doc Dwarf's contention that there was no practical
> difference between a PERFORM section-name where the section had 2
> paragraphs where the first paragraph had a "GO TO THIS-SECTION-EXIT
> and the second paragraph was THIS-SECTION-EXIT. EXIT." and a PERFORM
> section-name where section-name had no GO TO statements and used EXIT
> SECTION.  I claimed that the presence of a GO TO would prevent
> optimization such as simplified PERFORM code and code movement to
> place the SECTION in line eliminating the PERFORM code.

Not sure if this is what you are looking for, but both performs below are inlined and both sections produce essentially the same code.

 process nooff list opt(2)   
 identification division.    
 program-id. secttest.       
 environment division.       
 configuration section.      
 special-names.              
     upsi-1 on is skip-1     
     upsi-2 on is skip-2.    
                             
 procedure division.         
 driver section.             
 main.                       
     perform section-1       
     perform section-2       
     goback.                 
                             
 section-1 section.          
     if skip-1               
         exit section.       
     display 'section 1'     
     exit.                   
                             
 section-2 section.          
     if skip-2               
         go to exit-section. 
     display 'section 2'     
     exit.                   
                             
 exit-section.               
     exit.                   
                             
 end program secttest.       


   000160                     000011  MAIN:     EQU     *
000012:  001200     perform section-1
   000162                     000016  SECTION-1: EQU     *
000017:  001700     if skip-1
   000162  5810 8050          000017            L       R1,80(,R8)            #  GPCB_UPSIPtr 
   000166  95F1 1001          000017            CLI     1(,R1),X'F1'          #
   00016A  A784 0056          000017            JE      L0008
000019:  001900     display 'section 1'
   00016E  D217 D0E8 30A8     000019            MVC     232(24,R13),168(R3)   #
   000174  4110 D0E8          000019            LA      R1,232(,R13)          #  _ArgumentList
   000178  58F0 3080          000019            L       R15,128(,R3)          #  _ACON        
   00017C  58C0 D080          000019            L       R12,128(,R13)         #  _@CAA        
   000180  0DEF               000019            BASR    R14,R15               #  Call "IGZXDSP
000020:  002000     exit.
   000184                     000012  L0003:    EQU     *

000013:  001300     perform section-2
   000188                     000022  SECTION-2: EQU     *
000023:  002600     if skip-2
   000188  5810 8050          000023            L       R1,80(,R8)            #  GPCB_UPSIPtr 
   00018C  95F1 1002          000023            CLI     2(,R1),X'F1'          #
   000190  A784 0041          000023            JE      L0009
000025:  002800     display 'section 2'
   000194  D217 D0E8 30C0     000025            MVC     232(24,R13),192(R3)   #
   00019A  4110 D0E8          000025            LA      R1,232(,R13)          #  _ArgumentList  
   00019E  58F0 3080          000025            L       R15,128(,R3)          #  _ACON
   0001A2  58C0 D080          000025            L       R12,128(,R13)         #  _@CAA          
   0001A6  0DEF               000025            BASR    R14,R15               #  Call "IGZXDSP" 
000026:  002810     exit.
   0001AA                     000028  EXIT-SECTION: EQU     *
000029:  003110     exit.
000014:  001400     goback.   

   [...]

   000212                     000024  L0009:    EQU     *              
000024:  002700         go to exit-section.                            
   000212  A7F4 FFCC          000024            J       EXIT-SECTION   
   000216                     000018  L0008:    EQU     *              
000018:  001800         exit section.                                  
   000216  A7F4 FFB7          000018            J       L0003          
0
Frank
8/20/2016 11:12:32 PM
In article <b75dcb11-7c48-4cf5-aaa9-af482766eef4@googlegroups.com>,
Frank Swarbrick  <fswarbrick@gmail.com> wrote:
>On Thursday, August 18, 2016 at 11:56:08 AM UTC-6, docd...@panix.com wrote:
>> In article <00318152-a1a0-4adc-bbc0-d8a0eef9b56c@googlegroups.com>,
>> Frank Swarbrick  <fswarbrick@gmail.com> wrote:
>> >Here is an example (from a production program!!!!) of why some people
>> >here consider sections to be dangerous:
>> 
>> [snip]
>> 
>> > 9600-CALDTE-SECTION.                                             
>> 
>> Production Pre-Implentation Code Review was scheduled right after lunch, 
>> yes?
>
>Nobody's perfekt.

That's the tag-line from a recent, daring moving picture, isn't it?

DD

0
docdwarf
8/22/2016 4:47:34 PM
Reply: