Can "PERFORM VARYING" be Interruped

[rasETL]

Let's say the following is being executed...

PERFORM PARA1
THRU PARA1-EXIT
VARYING SUB1 FROM COUNTER BY 1
UNTIL FIELD1 (SUB1) = 'END'
OR SUB1 = TABLE-MAX.

By definition this Perform steps through data stored in a table, starting with the "COUNTER" row, and processing rows sequentially, one row at a time.

Question: Can the SUB1 subscript be changed within the PERFORM, thereby interrupting the process so rows can be skipped, or the process move back in the Table to a row that is not the next sequential row? Or does COBOL take over control of the subscript (SUB1) so it can control the "VARYING".

I know I could move control of the PERFORM to PARA1 by adding code, but I'm looking at the 80/20 rule here: 80% of the time I will not need to interrupt the processing sequence.

 

[CliveC]

WHEN condition MOVE TABLE-MAX TO SUB1

Clive

http://tubularity.com

 

[slade]

As Clive shows you can change the sub, but why do that when you can add another condition to the "until" clause? It's a lot easier to understand and and logically more direct.

Regards, Jack.

 

[k5tm]

This is a situation where you might want to know this:
faq209-1604

Tom Morrison

 

[rasETL]

CliveC and Slade

Thanks for responding, but I guess I didn't ask my question clear enough.

Let's say the COUNTER starts at 20 and the paragraph performs 4 times, on rows 20, 21,22 and 23. So now the SUB1 is 24. Now lets say I find something on this row that makes the process want to skip rows 25 thru 32 and go to row 33, or, maybe it wants to back to row 21.

Can I set the SUB1 value to something other than 24, and will the "Varying" know the value has changed and react accordingly?

I am converned the Perform...Varying somehow takes control over the value of SUB1, and any attempt to change the value will not be recognized.

Hope that explains my question a little more.

 

[k5tm]

rsaanders,

You wrote: Can I set the SUB1 value to something other than 24, and will the "Varying" know the value has changed and react accordingly?

Yes.

But caution is advised on how you code your UNTIL clause; see my previous post.

Tom Morrison

 

[3gm]

rsanders -

I believe most implementations allow changing the subscript within the PERFORMed code, but... YMMV.

Good programming practice would argue that you should do a PERFORM UNTIL and vary the subscript/index "manually" to avoid issues of modifying a VARYING subscript within the PERFORMed code. Handling it that way eliminates the question altogether.

Regards.

Glenn

 

[slade]

Hi R,

You can do what you suggest, but you might be making a complex, hard to understand perform pgraph. You might want to do something like this:

PERFORM PARA1
THRU PARA1-EXIT
VARYING SUB1 FROM COUNTER BY 1
UNTIL cond 1 is reached
OR cond 2 is reached
OR FIELD1 (SUB1) = 'END'
OR SUB1 = TABLE-MAX.
IF cond 1
PERFORM VARYING SUB1 FROM ....
.
.
.
END-PERFORM
END-IF
IF cond 2
MOVE tbl-field(21)....
or MOVE tbl-field(SUB1 - 3)....

.
.
.
END-IF
.
.

I REALIZE THIS IS A MATTER OF STYLE AND WE ALL HAVE PREFERENCES, SO IN THE END IT'S YOUR JUDGEMENT THAT PREVAILS. I always try to write code through the eyes of the guy/gal who has to maintain it.

Regards, Jack.

 

[razalas]

rsaanders,

as you will have realized by now, yes you can manipulate the object of a VARYING clause directly within the PERFORM range controlled by that VARYING clause.

However, keep in mind that the VARYING clause will cause the subscript/index field to be incremented/decremented at the end of the PERFORM range regardless of any other modifications that have occurred.

So, in your example where your code detects that it should skip to row 33 while processing row 24, it would be necessary to set the the value of COUNTER to 32 so that at the end of the PERFORM range, the "VARYING" clause will automatically increment it to 33. As Slade points out, this will be misleading to a reader of the code. So I would avoid using this technique.

"Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[webrabbit]

As earlier suggested, change your PERFORM to a simple UNTIL {condition}, and code the varying logic inside the PERFORMed paragraph. That way, there is no "magic" logic done by the PERFORM statment to worry about.

The initialization must then be done before the perform.

 

[weberm]

I believe you can tamper with the value of SUB1, but I wouldn't recomend it. Wouldn't it be easier to just put a conditional statement in PARA1 with a GOTO PARA1-EXIT?

 

[slade]

Uh oh, WB, now you did it. Beware the wrath of the GO TO bigots!

 

[hankjeff]

Yes, depending on the compiler/platform you probably could muck about with the subscript, but if you did and you worked for me, I'd probably fire you unless you left a very lengthy and precise explanation in the program as to why you were doing so. Three years later the programmer who now has to maintain your code wouldn't have the foggiest idea what was going on.
An alternative might be to, within the perform'ed paragraph, evaluate the subscript and if those special numbers are encountered simply go to (or fall through to) the paragraph exit point.

 

[webrabbit]

In some compilers, if you "GO TO" out of a perform loop, the exit is still on the stack, which could cause stack overflow problems.

 

[Crox]

1) In true COBOL there is no stack in relation to performs.

2) Some PC-compilers have an option to change a perform into a call. That is faster and should be no problem with normal programs. If someone is using a GO TO to go out of an in-line perform, the compiler should adjust that stack.

3) If someone jumps out of - a section or performed paragraph or a perform thru - into a place behind the exit, in normal COBOL the end-of-the-performed-place stays 'hot' and if an other GO TO or some drop through makes that the hotspot is hit, the executing of instructions will be continued just after the last PERFORM that activated that hotspot.

Only bad compilers will generate stack overflows. It should happen only with too much nested recursive call's and not enough memory. The runtime should give a good errormessage.

In other cases, the compiler should give a warning for possible drop through's.

 

[webrabbit]

Micro Focus COBOL is a "true" COBOL compiler. You can select the stack method for perform exits. I mentioned stacks as the simplest way of describing the problem. I learned about the "still hot" problem back in 1968 when I was new to COBOL. I had written a spaghetti code program where sometimes the logic had a "GO TO" out of the perform loop and sometimes the logic "trickled" into the performed paragraphs. Boy was that a mess. When the logic "trickled" into the hot exit, the program did some bizzare things.