Multiple Entry Points Considered Harmful

Even the IBM manual (OK, I forget which one, but I'm pretty sure it's one of the two cobol manuals) discourages entry points.

I completely agree. When you're trying to follow program logic and all of a sudden you have to pull up some lousy subroutine, that's bad enough. But then trying to figure out exactly which portion of the subroutine belongs to this particular entry point only makes it worse.

Our application had a large program with about ten subroutines, each with up to five entry points. The subroutines, by the way, were called by only one program, so why they were subroutines at all escapes me. The actual procedure code for each piece was usually quite small, but most of the code in each subroutine was wasted on communication.

The main program and all of its subroutines were rewritten into main programs. The code is now 3 times more readable. When you're doing a find command on a field name, for example, you actually find it, without having to search x-number of subroutines!

Bottom line: entry points merely cloud the issue. A better solution, I feel, is to simply pass a code through linkage to trigger different execution. The code could then be considered a quasi transaction code, a perfectly legit way of handling things.

In the subprograms he complains of, the various entry points may have been widely separated by relatively large chunks of code, possibly even including fall-through logic. In that case it could indeed be difficult to figure out which code belonged to which entry point.

I put all my entry points up at the top of the PROCEDURE DIVISION. Each one is typically two lines long: a PERFORM of a paragraph that does the real work, followed by a GOBACK. Sometimes there are a few more lines, depending on the situation, but the logic at this level is always trivial. With this approach the code is no more difficult to follow than an EVALUATE statement branching on a transaction code.

COBOL Home

COBOL Style Forum