At 07:06 AM 10/22/96 -0700, Dennis Handly wrote:
>>I agree with Stan, secondary entry points are indeed a useful programming
>>technique.  They are certainly more 'self-documenting' than PARM or INFO
>>parameters.
>
>I agree about PARM.  But INFO is a different story.

Hmmm...so when you don't have a list of the acceptable 'INFO=' values which
affect/drive program execution its acceptable to use FCOPY, or some other
tool and examine the object file in ASCII format, trying to locate/guess at
what appear to be the acceptable parameters.

Somehow I found utilities like EPTFIND (which simply displayed the entry
point names) a bit easier to use...especially when dialed-in late at night
from home without a full set of manuals, trying to assist in resolving a
production problem at a manufacturing plant 45 miles away....

Entry points were certainly a lot easier, especially when supporting
something you didn't author...

Too bad we weren't aware of the trade-off at the time you're were supporting
COBOL, as I would have sprung for a few dinners/etc. for your time over a
weekend to add entry points.  It certainly would have saved my staff at
least that much time, if not more in terms of the changes they had to make
in converting application code and updating documentation/training/etc..
There probably are others who also might have benefited, making the overall
payback in terms of saved effort much greater than the 1-2 days of
engineering time to carry the feature forward during classic to RISC
conversions....

/jf