For an external routine to be accessible to GT.M, the routine, and an external call table entry defining its usage, must be linked into an M image. Use the VMS linker to combine these elements; they cannot be ZLINKed. The VMS linker produces an executable image that can be run with the DCL RUN command.

For example, if the M routine CAL.M uses external calls to obtain values from the external FORTRAN routine SQRT.F, to link the resultant object modules use the command line:

	$ LINK CAL,SQRT,GTMZCTAB
	

to produce an executable image called CAL.EXE.

If your M routine calls more than one external routine and uses several table source files, you may want to put the external routine and external call table source object modules in a VMS object library file (file type .OLB). The OpenVMS DCL Dictionary manual describes how to create object module libraries.

Using an object library simplifies the linking process because you do not have to explicitly reference the routines with the LINK command. For example, if the external routine, CAL.M requires values from SQRT1.F, SQRT2.F and SQRT3.F, you can put the object modules in the library, SQRT.OLB. To link the object modules, use the LINK qualifiers, /LIBRARY and /INCLUDE:

	$ LINK CAL,SQRT/LIB/INCLUDE=GTMZCTAB
	

The /LIBRARY qualifier indicates that SQRT is a library file. The linker searches the symbol table of the library for undefined symbols in previously processed modules (GTMZCTAB.OBJ in this case). The linker includes the library modules containing the undefined symbols (SQRT1.OBJ, SQRT2.OBJ and SQRT3.OBJ) in the linking process.

Because your M routine does not explicitly reference the external call table object module, you need to reference the object module explicitly with the LINK command. The /INCLUDE qualifier directs the linker to include the named module or modules from the library in the linking process.

For more information on the /LIBRARY and /INCLUDE qualifiers, refer to the OpenVMS Linker Utility manual.

External call tables may be placed in a shareable image. This permits independent modifications of the base image and the external call tables. If you place your external call tables in a shareable image, all the tables must be in the same image. When linking your shareable external call table image, you must declare the following universal symbols in an options file:

	gtm$startzc,gtm$endzc,gtm$startzcpack, gtm$endzcpack
	

Example:

	$ link/share=zcshr zctab1,zctab2,sys$input/opt- symbol_vector=(gtm$startzc=DATA,gtm$endzc=DATA, -gtm$startzcpack=DATA,gtm$endzcpack=DATA)
	$ library/share/create zclib zcshr
	$ link mygtm,zclib/library/include=zcshr
	$ define zcshr user:[holmes.dev]zcshr.exe
	$ run mygtm
	

This links a shareable image named zcshr.exe, which includes external call tables from zctabl.obj and zctab2.obj. It uses sys$input for in-line input of the options file, although a separate file might be more appropriate if the link occurs frequently. Then it places the universal symbols for zcshr in a shareable image library named zclib.olb. It links an M program against that library, specifically including zcshr. Then it defines a logical name for the shareable image–a step that would be unnecessary if the image were placed in sys$library. Finally, it runs the image.

Another possibility is to use an options file to include zcshr/share, rather than creating a shareable image library, as shown below.

Example:

	$ type xcall.opt
	symbol_vector= ( -
	gtm$startzc = DATA, -
	gtm$endzc = DATA, -
	gtm$startzcpack = DATA, -
	gtm$endzcpack = DATA -
	
	$ link/share=zcshr zctab1,zctab2,xcall.opt/opt
	$ link mygtm,zclib/library/include=zcshr/sys$input/opt-
	zshr/share
	$ define zcshr user:[holmes.dev]zcshr.exe
	$ run mygtm	
	

For more information on linking and shareable images in VMS, refer to the OpenVMS Linker Utility manual.