Question regarding perform thru and GOTO statement interaction

This may sound ridiculous, but I'm writing a cobol compiler and I have a
question on a particular construct.

Given the following code (... indicates the code content isn't important
except it has no PERFORM or GOTO statements):

1090
1100	A01.	Perform A05 through A09.
1110		Move Month-index to stable-result.
1120		...
1130
2210
2220	A02.	Add 1 to Identifier-Point.
2230		...
2440
2450	A03.	...
5220
5230	A04	...
6000
6010	A05	Move 5 to month-iindex.
6020		...
6510
6520	A06	Move 1 to Regency-Level.
6530		If regency-level > 5 go to A11.
6540		If race-value = 3 go to A12.
6550		Move 6 to identifier-point.
6560		...
6700	A07.	...
6710
6750	A08.	...
6760		...
6770    A09. 	...
6780		...
7010		...
7020	A10.	...
7040		GOTO A13.
7050
7060    A11.    move 9 to identifier-point.
7070		move 3 to race-value.
7080		goto A08.
7140
7150	A12.	Move 8 to identifier-point.
7460		go to A10
7490
7500	A13.	...
7510

Now, given the above code,  Line 1100 should execute the code from lines
6010 through 7010.

Now, if the code at line 6530 is executed and the condition is true,
then it should go to paragraph A10 at 7060.  Now, if it does that, then
returns to paragraph A08, will it exit from the perform through back to
line 1110, or would it "cancel" the perform through and continue on to
paragraph A09?

I can live with the idea that the branch out of the loop then branch
back into the loop "restores" the PERFORM THRU - and in fact, it's
easier to implement it that way - but if it's not supposed to do that
I'd like to make sure I "cancel" the perform thru once an exit out of a
PERFORM block occurs.

Is the behavior compiler specific (implementor's choice) or is there a
specification in the standard for this?

Compiler specific.

Go to:
http://supportline.microfocus.com/s...ubb.h
tm

and look for information on the (Micro Focus)
PERFORM-TYPE

compiler directive.  This describes the (different) types of behavior that M
F
supports - to "emulate" how other compilers work.

A couple of other things to think about :

1) Check out the impact of the CANCEL statement and IS INITIAL phrase on PER
FORM
"ranges" (and exits).

2) I only discovered it relatively recently, but there is NO requirement in 
the
COBOL Standard that if you have

Perform Procedure-1 thru Procedure-2

that Procedure-1 must appear BEFORE Procedure-2 in the source code.  The
implications of when they appear in the other order are interesting - to say
 the
least.

--
Bill Klein
wmklein <at> ix.netcom.com
"Paul Robinson" <paul@paul-robinson.us> wrote in message
news:00vQd.34596$Dc.9939@trnddc06...
> This may sound ridiculous, but I'm writing a cobol compiler and I have a
> question on a particular construct.
>
> Given the following code (... indicates the code content isn't important
> except it has no PERFORM or GOTO statements):
>
> 1090
> 1100 A01. Perform A05 through A09.
> 1110 Move Month-index to stable-result.
> 1120 ...
> 1130
> 2210
> 2220 A02. Add 1 to Identifier-Point.
> 2230 ...
> 2440
> 2450 A03. ...
> 5220
> 5230 A04 ...
> 6000 6010 A05 Move 5 to month-iindex.
> 6020 ...
> 6510
> 6520 A06 Move 1 to Regency-Level.
> 6530 If regency-level > 5 go to A11.
> 6540 If race-value = 3 go to A12.
> 6550 Move 6 to identifier-point.
> 6560 ...
> 6700 A07. ...
> 6710
> 6750 A08. ...
> 6760 ...
> 6770    A09. ...
> 6780 ...
> 7010 ...
> 7020 A10. ...
> 7040 GOTO A13.
> 7050
> 7060    A11.    move 9 to identifier-point.
> 7070 move 3 to race-value.
> 7080 goto A08. 7140
> 7150 A12. Move 8 to identifier-point.
> 7460 go to A10
> 7490
> 7500 A13. ...
> 7510
>
> Now, given the above code,  Line 1100 should execute the code from lines 6
010
> through 7010.
>
> Now, if the code at line 6530 is executed and the condition is true, then 
it
> should go to paragraph A10 at 7060.  Now, if it does that, then returns to
> paragraph A08, will it exit from the perform through back to line 1110, or
> would it "cancel" the perform through and continue on to paragraph A09?
>
> I can live with the idea that the branch out of the loop then branch back 
into
> the loop "restores" the PERFORM THRU - and in fact, it's easier to impleme
nt
> it that way - but if it's not supposed to do that I'd like to make sure I
> "cancel" the perform thru once an exit out of a PERFORM block occurs.
>
> Is the behavior compiler specific (implementor's choice) or is there a
> specification in the standard for this?

> will it exit from the perform through back to line 1110,

When it reaches the end of A09 it will return to after the PERFORM in
1100.

> or would it "cancel" the perform through and continue on to paragraph
A09?

It will drop from A08 to A09, you probably meant A10 in which case the
answer is no.

Note that there may be other non-overlapping constructs such as
'PERFORM A08 THRU A13' made at a time that the PERFORM in 1100 is not
active, that would drop thru the end of A09, the point that would cause
the return to 1100.

The way I see it, if the sequence of operations is A05, A06, A11 (not A10),
A08, A09, you should terminate the A05-A09 perform at 1100 successfully and
return to 1110.  It's not a matter of "restoring" the PERFORM.  The PERFORM
is either "active" or it's not, and if you get to its end it is no longer
active.  The problems come in when you do things like initiate a PERFORM
without having first terminated it.  If from within the A05-A09 range you
did a GO TO A01, on our system you'd most likely end up getting hosed by a
Stack Overflow exception.  It does not matter where you GO TO after doing
the PERFORM so long as you "come back" in such a way as to reach the
terminus of the PERFORM before executing the same PERFORM again.

-Chuck Stevens


"Paul Robinson" <paul@paul-robinson.us> wrote in message
news:00vQd.34596$Dc.9939@trnddc06...
> This may sound ridiculous, but I'm writing a cobol compiler and I have a
> question on a particular construct.
>
> Given the following code (... indicates the code content isn't important
> except it has no PERFORM or GOTO statements):
>
> 1090
> 1100 A01. Perform A05 through A09.
> 1110 Move Month-index to stable-result.
> 1120 ...
> 1130
> 2210
> 2220 A02. Add 1 to Identifier-Point.
> 2230 ...
> 2440
> 2450 A03. ...
> 5220
> 5230 A04 ...
> 6000
> 6010 A05 Move 5 to month-iindex.
> 6020 ...
> 6510
> 6520 A06 Move 1 to Regency-Level.
> 6530 If regency-level > 5 go to A11.
> 6540 If race-value = 3 go to A12.
> 6550 Move 6 to identifier-point.
> 6560 ...
> 6700 A07. ...
> 6710
> 6750 A08. ...
> 6760 ...
> 6770    A09. ...
> 6780 ...
> 7010 ...
> 7020 A10. ...
> 7040 GOTO A13.
> 7050
> 7060    A11.    move 9 to identifier-point.
> 7070 move 3 to race-value.
> 7080 goto A08.
> 7140
> 7150 A12. Move 8 to identifier-point.
> 7460 go to A10
> 7490
> 7500 A13. ...
> 7510
>
> Now, given the above code,  Line 1100 should execute the code from lines
> 6010 through 7010.
>
> Now, if the code at line 6530 is executed and the condition is true,
> then it should go to paragraph A10 at 7060.  Now, if it does that, then
> returns to paragraph A08, will it exit from the perform through back to
> line 1110, or would it "cancel" the perform through and continue on to
> paragraph A09?
>
> I can live with the idea that the branch out of the loop then branch
> back into the loop "restores" the PERFORM THRU - and in fact, it's
> easier to implement it that way - but if it's not supposed to do that
> I'd like to make sure I "cancel" the perform thru once an exit out of a
> PERFORM block occurs.
>
> Is the behavior compiler specific (implementor's choice) or is there a
> specification in the standard for this?

Paul Robinson wrote:
> Now, given the above code,  Line 1100 should execute the code from lines
> 6010 through 7010.
>
> Now, if the code at line 6530 is executed and the condition is true,
> then it should go to paragraph A10 at 7060.  Now, if it does that, then
> returns to paragraph A08, will it exit from the perform through back to
> line 1110, or would it "cancel" the perform through and continue on to
> paragraph A09?
>
> I can live with the idea that the branch out of the loop then branch
> back into the loop "restores" the PERFORM THRU - and in fact, it's
> easier to implement it that way - but if it's not supposed to do that
> I'd like to make sure I "cancel" the perform thru once an exit out of a
> PERFORM block occurs.
>
> Is the behavior compiler specific (implementor's choice) or is there a
> specification in the standard for this?

A "PERFORM THRU" only performs thru *once* in a given iteration.  So,
your logic would return to the line after 1100, and continue.  In
effect, you'd fall back through until you got to A10, which would then
jump over A11 and A12, and continue in a fallthrough manner at A13.

As an aside, this fragment is not structured very well.  That may be
because it's taken out of context, though...  :)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i wrote:
> Paul Robinson wrote:
> 
>
>
> A "PERFORM THRU" only performs thru *once* in a given iteration.  So,
> your logic would return to the line after 1100, and continue.  In
> effect, you'd fall back through until you got to A10, which would then
> jump over A11 and A12, and continue in a fallthrough manner at A13.
>
> As an aside, this fragment is not structured very well.  That may be
> because it's taken out of context, though...  :)

Okay - I'd like to have that one back.  The first sentence is correct,
but doesn't answer the question you asked - disregard the rest.  (sorry...)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Paul:

The following doesn't really answer your question, but is something I
recall from an old COBOL implementation by IBM in the OS/VS systems.

In VS/COBOL, I found that the code generated by IBM at the end of a
paragraph invoked a special routine. It appears that this routine
checks what is currently going on and either allows a fall through or
returns to the last caller.

Now it has been a very long time since I looked at this and the
ramifications, but as I recall, VS/COBOL kept a table of 100 entries.

Regards,
Steve.T