Determining Program Entry Points
When you load a single TEXT file or a TXTLIB member into storage to run, the default entry point is the first CSECT name in the object module loaded. You can specify an alternate entry point on the LOAD, INCLUDE, or START commands.
When you load multiple TEXT files (either explicitly or implicitly by allowing the loader to resolve external references), you also have the option of specifying the entry point on the LOAD, INCLUDE, or START command lines.
If you do not specifically name an entry point, the loader determines the entry point for you according to the following hierarchy:
- An entry point specified on the START command
- The last entry specified with the RESET option on a LOAD or INCLUDE command
- The name on the last ENTRY statement that was read
- The name on the last LDT statement that contained an entry name that was read
- The name on the first assembler- or compiler-produced END statement that was read
- The first byte of the first control section loaded.
For example, if you load a series of TEXT files that contain no control statements and do not specify an entry point on the LOAD, INCLUDE, or START commands, execution begins with the first file that you loaded. If you want to control the execution of program subroutines, you should be aware of this hierarchy when you load programs or when you place them in TXTLIBs.
An area of particular concern is when you issue a dynamic load (with the OS/MVS LINK, LOAD, or XCTL macros) from a program, and you call members of CMS TXTLIBs. The CMS loader determines the entry point of the called program and returns the entry point to your program. If a TXTLIB member that you load has a VCON to another TXTLIB member, the LDT card from the second member may be the last LDT card read by the loader. If this LDT card specifies the name of the second member, CMS may return that entry point address to your program rather than the address of the first member.