SERVICE LABELs are most often associated with EXEC CICS HANDLE or with calls to CEE3SRP.  In the first case, the programmer could be completely unaware of the presence of a SERVICE LABEL;  in the second case, it's required.

I recently encountered some code that I think contains a bad coding practice.  (I'm describing in in this forum rather than a blog because I want to give people a chance to disagree with me.)  What I saw was a short paragraph with a SERVICE LABEL and that paragraph was PERFORMed repeatedly. 

In any case where SERVICE LABEL is used, an indeterminate amount of resources are used (by CICS or LE or possibly something else in the future) to support the idea that under some circumstances control will abruptly return to the label.  These resources are used to record register state, etc.  The concept is that the low level execution state (e.g., machine registers) will be set back to what it was when control originally flowed through the service label.  Since you don't have as much control over these resources in COBOL as you would in C (where the program explicitly provides a jmp_buf) it strikes me that the best way to use SERVICE LABELs is to establish them once somewhere near the start of your program and not attempt to establish the same label multiple times (via performs or via gotos).

My opinion could be overly informed by knowing about the implementation details.  Others may see different natural use cases.

Well, this is nuts. I lost a reply to this last night, which I assumed was either a poor connection or a problem with the servers (there was a particular bugfix I couldn't look at).

Now, trying to post the text, recovered from a "Form History" plug-in, I get nothing but directed to a spam-prevention page.

Without being forced to retype everything, Yes, bad practice, Yes and No for dealing with it.

I even tried pasting the small code example. No go. Nuts.

After multiple attempts to post what I want, including retyping the whole thing, and still getting to the anti-spam page each time, I've had to take it up with talk2dw.

Yes, I would consider that bad practice. I have an aversion to doing something more than once when it would always produce the same result.

I think how it is deal with depends on the intended use. The SERVICE LABEL is positional. If the intention is just to continue as you were after normally non-resumable statement, then it has to be in the procedure. If the resume-point doesn't have to bear any relation to the procedure, then how you've suggested would be best.

Here's how I'd code it if it needed to be in the procedure:

* only get here if the whatever was successful, else jump.

    set  something-meaningful-for-what-was-done to true

    if meaningful-condition-name

        set meaningful-condition-name-off to true

        call "cee3srp" using recovery-point-1

                             omitted

        service label

* control will arrive here if the noabend handler got it.

    end-if

It may seem strange to arrive in an IF statement, but it is unproblematic. The CALL and SERVICE LABEL only get done once, no matter how many times the procedure itself is used.

I was doing this to avoid the repeated CALLs, and didn't know of overhead for SERVICE LABEL, so thanks for that information.

Well, beat the spam-blocker.

To clarify, it's not the SERVICE LABEL itself that has the overhead, that's more of a signal to the compiler about control flow possibilities at that point.

CEE3SRP creates a new machine state block on the heap every time it's executed, which LE only frees when you leave the procedure in which CEE3SRP was called. So calling CEE3SRP repeatedly without leaving the procedure is essentially a memory leak.

Bernie

Thanks. I thought I'd looked at the compile output and not noticed anything for the SERVICE LABEL :-)

I just wanted to avoid the overhead of the multiple CALLs anyway.