@DEFINE

Use the @DEFINE control statement to define system settings.

The following figure shows the syntax for the @DEFINE control statement section of the loader input file. In this figure, the double arrowhead (►►) indicates that the information must begin on a new line.
Figure 1. @DEFINE control statement section of the loader input file
Read syntax diagramSkip visual syntax diagram@DEFine
Note: This must be the first line of the @DEFINE control statement section.
Read syntax diagramSkip visual syntax diagram1& searchpath=:2path& previouslydefinedsearchpath
Notes:
  • 1 If you have more than one search path to define, use this line as many times as you need. Each time you use it, start the next occurrence on a new line.
  • 2 The definition of a search path can span more than one line. To continue on a new line, end your current line with a colon (:), which indicates there is more information in the definition.
Read syntax diagramSkip visual syntax diagramCWD= path
Read syntax diagramSkip visual syntax diagramSYSID= bssnameSYSID= ssname
Figure 2. Additional syntax for specific uses of the @DEFINE control statement section
Additional syntax for an OLDR or a TLDR load
Read syntax diagramSkip visual syntax diagramDEBUGFILES=YESDEBUGFILES=NO
Additional syntax for a TLDR load
Read syntax diagramSkip visual syntax diagramELDRCLEAR=NOELDRCLEAR=YESOVERLAY_IPAT=NOOVERLAY_IPAT=YESPROGCLEAR=NOPROGCLEAR=YESFCTBCLEAR=NOFCTBCLEAR=YES
Additional syntax for an ALDR load
Read syntax diagramSkip visual syntax diagramIMGCLEAR=NOIMGCLEAR=YES
&searchpath
Specifies the name of a path, where searchpath is the name you want associated with the path. The path must start with an ampersand (&). If you specify more than one directory, use a colon (:) to separate directories.
path
An absolute or relative directory that you can specify to search.
&previouslydefinedsearchpath
An absolute or relative directory that was defined previously with the @DEFINE control statement section to search.
The following example shows a path named &CIMRPATH that has three path definitions. 
@DEFINE 
&CIMRPATH=/u/ztpf/cp:/u/ztpf/fctb:/u/ztpf/cimrobj
Using this definition, if you specify the path name of &CIMRPATH anywhere in the loader input file, the offline loader will attempt to locate the object that it applies to by searching the following directories in order:
  1. /u/ztpf/cp
  2. /u/ztpf/fctb
  3. /u/ztpf/cimrobj
Note: Path names are case sensitive.
CWD=path
Specifies the current working directory, where path is the name of the absolute directory that relative directories are appended to. For other control statements, the following apply:
  • Any relative paths are assumed to be relative to this directory.
  • The directory specified here is used as the search directory if neither a default location nor a specific location is specified for the control statement.
Note: You can specify CWD as both a system setting in the @DEFINE control statement and as a command-line argument when you are performing an offline load on Linux®. However, if you specify both the command-line argument and the system setting, these values must be consistent.
SYSID
Specifies the subsystem ID.
bssname
The name of the basic subsystem (BSS). You can define your own BSS name by specifying the BSSNAME parameter on the SSDEF macro.
ssname
The name of the subsystem.
DEBUGFILES
Specifies whether the shared object is written to the desired storage medium with or without debug data.
YES
Writes the shared object with debug data.
NO
Writes the shared object without debug data.
ELDRCLEAR
Specifies whether E-type loader record definitions are cleared.
YES
Clears and reinitializes all E-type loader records and versioned files for the target image.
Attention: When ELDRCLEAR=YES is specified, all programs and files that were loaded using the E-type loader (except those that were accepted) are cleared from the online system.
NO
Does not clear or reinitialize E-type loader record definitions.
Attention: Use this line for the @DEFINE control statement section only when performing a TLDR load.
FCTBCLEAR
Specifies whether the alternate FACE table (FCTB) is cleared.
YES
Clears the alternate FCTB for the target image.
Attention: When FCTBCLEAR=YES is specified, the alternate FCTB that was loaded by using the ZFCTB LOAD command is cleared from the online system unless it had already been accepted.
NO
Does not clear the alternate FCTB.
Attention: Use this line for the @DEFINE control statement section only when performing a TLDR load.
IMGCLEAR
Specifies whether image-related records are cleared.
YES
Clears and initializes various image-related records. When IMGCLEAR=YES is specified, IPLA, IPLB, CTKX, and all the CIMR components need to be loaded.
Attention: When IMGCLEAR=YES is specifed, all image definitions are cleared from the online system.
NO
Does not clear or initialize various image-related records.
Attention: Do not use this line for the @DEFINE control statement section when performing an OLDR load. If you do, you will receive an error message and a return code of 8. For more information about offline loader return codes, see Return codes.
Note: If you specify this line for the @DEFINE control statement section when performing a TLDR load, it is ignored. You will receive a return code of 4.
OVERLAY_IPAT
Specifies whether to merge or replace the program attribute table (PAT).
YES
Replaces the PAT in core and requires that all programs get reloaded.
NO
Merges the existing PAT with the PAT that is being loaded.
Attention: Use this line for the @DEFINE control statement section only when performing a TLDR load.
PROGCLEAR
Specifies whether a program base is cleared.
YES
Clears and reinitializes the main extra program record for the target image so that all extra program records (#XPRGn fixed file records, where n is the program base number for the image you are loading to) are available to be dispensed.

Additionally, the program base unique file directory (/sys/tpf_pbfiles) is cleared. If get file storage (GFS) is not active when the online load is performed, the target program base indicates that its program base unique file directory has not been cleared. In this case, the directory will be cleared the next time GFS activation occurs on any processor.

If GFS activation does not occur before an initial program load (IPL) is performed on the target image, the program base unique file directory is cleared when GFS is activated following the IPL of the target image.

References to program base unique files that occur before GFS activation are intercepted by the z/TPF system and the directory appears empty to an application.

Note: Only files in the program base unique file directory are cleared. Other files that are loaded by using the loader are not part of the program base and are not cleared.
NO
Does not clear or reinitialize the main extra program record or the program base unique file directory.
Attention: Use this line for the @DEFINE control statement section only when performing a TLDR load.
Note:
  1. You must specify PROGCLEAR=YES to initialize a program base before you can load any real-time programs to an image for the first time.
  2. All real-time programs must be reloaded when you specify PROGCLEAR=YES.