Entry Points

By Shawn M. Gordon

I want to start out this month by following up a bit on our recent column about using macros. I received an e-mail from Ken Thompson at MacMillan Bathhurst telling me how to solve one annoyance of macros. Ken said:

I was reading your article on COBOL macros in the latest 3000 NewsWire and noticed your comment that macros can inflate your compile listing. We’ve been using macros here for years and we found a way around that annoyance.

Try this in your macro...

$Define %xxx=
$Control Locoff
:
:body of macro
:
$Control Locon

This will leave the macro line in your listing, but suppress all of the body of the macro. (It can save a lot of paper and make your listings much more readable.)

Thanks for the tip, Ken. I’m going back and modifying all my copylibs now.

This month’s topic is yet another one of those things that you might take for granted if you know how to do it, but will be totally baffling on how to set up if you have never done it before. I had a programmer come to me the other day and ask how to create entry points in a COBOL program.

Now it’s important to note that entry points in COBOL are probably different than what you are thinking of in an SPL program when you can do a “RUN MYPROG,ENTRY.” What this provides is the ability to have one physical source program that contains “n” number of logical programs. This can be either a single object file that is linked to your program, or it can be loaded into an XL file that your program can run through.

Just like any other sub-program, you would have a single LINKAGE SECTION to contain any variable definitions that need to be passed into your routines. Each entry point can contain a USING verb to specify the variables that are being passed.

You might recall some of the examples of the new date intrinsics that I did a few months back, and I will use some of those code snippets as an example in Figure 1 below. This figure is a very cut-down version of the code, but should clearly illustrate what we are talking about.

Figure 1

$CONTROL USLINIT, BOUNDS, DYNAMIC
IDENTIFICATION DIVISION.
PROGRAM-ID. DATEMATH.
LINKAGE SECTION.
01 FROM-DATE PIC 9(8) COMP.
01 THRU-DATE PIC 9(8) COMP.
01 DAYS-DIFF PIC S9(9) COMP.
01 LS-STATUS PIC S9(9) COMP.
* 1 = invalid from date
* 2 = invalid thru date
* 3 = invalid date format
* 4 = error in one of the other date routines
01 FORMAT-DATE PIC X(20).
* the format-type has to be strung into another variable to
* put a NULL (%0) or (LOW-VALUES) into the end of the string
01 FORMAT-TYPE PIC X(20).
*01 Y2K-VALUE PIC S9(4) COMP.
PROCEDURE DIVISION.
A1000-INIT.
DISPLAY 'DATEMATH called with invalid entry point'.
GOBACK.
A2000-FORMAT-DATE.
ENTRY "FORMATDATE" USING FROM-DATE, FORMAT-DATE,
FORMAT-TYPE, LS-STATUS.
GOBACK.
*
A3000-DAYS-DIFF.
ENTRY "DAYSDIFF" USING FROM-DATE, THRU-DATE,
DAYS-DIFF, LS-STATUS.
GOBACK.
*
A4000-DATE-OFFSET.
ENTRY "DATEOFFSET" USING FROM-DATE, THRU-DATE,
DAYS-DIFF, LS-STATUS.


My use of a paragraph header is meant for clarity, but isn’t required by the COBOL system. The advantage to this approach is that it allows you to group logically related sub-routines into a single source file and have clear descriptions of each routine. Your other two options are to pass a switch that tells you what routine to execute, or have each sub-routine be in a different program.

That wraps it up for this month. I appreciate the feedback I’ve been getting, as well as the tips. Keep those cards and letters coming, and earn yourself a free 3000 Always Online hat for tips you submit, either to the NewsWire or to me at smga@compuserve.com.

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.