IMPORT statement

The IMPORT statement specifies an external symbol name to be imported and the library member or z/OS UNIX file name where it can be found. An imported symbol is one that is expected to be dynamically resolved. The syntax of the IMPORT statement is:

IMPORT          {CODE | DATA | CODE64 | DATA64},
                        dllname,import_name[,offset]

{CODE | DATA | CODE64 | DATA64}

Mutually exclusive keywords that specify the type of symbol being imported.

If CODE or CODE64 is specified, the import_name must represent the name of a code section or entry point. Specify CODE64 when using 64-bit addressing mode or specify CODE for any other addressing mode.

If DATA or DATA64 is specified, the import_name must represent the name of a variable or data type definition to be imported. Specify DATA64 when using 64-bit addressing mode or specify DATA for any other addressing mode.

dllname

The name of the DLL module that contains the import_name to be imported. If it is a member of a PDS or PDSE, it must be a primary name or an alias. The length is limted to eight bytes unless it is an alias name in a PDSE directory. In that case, the limit is 1024 bytes. If it is a z/OS UNIX file, the file name is limited to 255 bytes.

import_name

The symbol name to be imported. In programming terms, it represents a function or method definition, or a variable or data type definition. This distinction is made by specifying either CODE, CODE64, DATA, or DATA64. The import_name can be up to 32767 bytes in length.

offset

Offset consists of up to 8 hexadecimal characters. The offset will be stored with the DLL information for an imported function. This is primarily for the use of Language Environment®.

In order to continue a dllname or an import_name, code a nonblank character in column 72. Either blanks or commas will be accepted as delimiters between parameters.

Placement: The IMPORT statement can be placed before, between, or after object modules or other control statements.

Note:

The DYNAM(DLL) binder option must be specified for IMPORT statements to take effect (see Table 1).
IMPORT statements are processed as they are received by the binder. However, symbol resolution is not done against the imported symbols until the binder's final autocall is finished.
A bind job for a DLL application should include an IMPORT control statement for any DLLs that the application expects to use. Otherwise, if the DLL name is unresolved at static bind time, it will not be accessible at run time.
Ensure that the dllname matches the actual name of the DLL. Otherwise, import names will not be resolved.
Typically, a dynamic link library will have an associated side file of IMPORT control statements, and you will include this side file when statically binding a module that imports functions or variables from that library. However, you can also edit the records in the side file or substitute your own IMPORT control statements so that some symbols are imported from DLLs in a different library.
Modules with imported symbols can be saved only in PM3 or later format.
When you rebind a DLL, you must include the IMPORT statements. Information from the IMPORT control statements is not retained from one bind to another if the object is stored as a PO1, PO2, or PO3 format program objects. If you rebind a PO4 or higher program object, the IMPORT information msaved from the previous bind will be brought in, unless the -NOIMPORTS option is specified.
Import control statements generated by the binder will contain quotation marks around both the symbol name and the DLL name.