Understanding binder programming concepts
- dialog
- A programmed session with
the binder is called a binder dialog. You begin the session with a request to start a dialog.
This request establishes the environment for binder processing during that dialog, including
obtaining work space, initializing control blocks, and specifying DD names for the standard data
sets to be used.
Your program can start more than one dialog and maintain more than one dialog at the same time. The dialogs are independent. You can perform operations on more than one dialog concurrently, but you cannot pass binder data directly from one dialog to another.
When any dialog is ended, all buffers and control information relating to that dialog are deleted.
- dialog token
- Each dialog is identified by a unique dialog token. The dialog token is created when you request a new dialog. You use the token corresponding to a specific dialog when you request services, so the binder can perform the services on the correct input and return the desired results to the correct dialog. The token is invalidated when the dialog is ended.
- workmod
- An area of working storage used
to create or operate on a program module is called a workmod. After a dialog has been
established, your program issues requests to create a workmod, to reset a workmod to the null state,
or to delete a workmod. At least one workmod must be created before any module operations can be
requested.
A dialog can have many workmods associated with it, but each workmod is associated with only one dialog. Binder-generated data cannot be passed between workmods. Ending a dialog causes any remaining workmods associated with it to be deleted.
- workmod token
- Each workmod is identified by a unique workmod token. The workmod token is created when the request for a new workmod is made. The workmod token associates the workmod with a particular dialog. Your program must pass the token as a parameter on all requests involving that workmod. The token is invalidated when either the workmod is deleted or the dialog is ended.
- processing intent
- Processing intent specifies the range of binder services that may be requested for a workmod. The processing intent is set to either bind or access when the workmod is created. Bind allows editing of the modules; access does not. See Processing intents for detailed information.
- element
- An element is a named portion of module data in a workmod that is directly addressable by the binder. Program modules logically consist of elements. Each element is identified by its data class identifier and, optionally, a section name.
- class
- A class identifier is a required descriptor for each element.
It identifies the type and the format of the data element and determines the operations that can be
performed on it. The following binder-defined classes are valid:
- B_TEXT
- Relocatable text, including executable machine instructions, constants, and, in the case of the nonreentrant programs, data areas defined within the program. See also B_TEXT24 and B_TEXT31.
- B_PRV
- Pseudoregister vector (a data area shared across compile units) that is used by high-level languages and assembler code using DXD and CXD instructions.
- B_ESD
- External Symbol Dictionary, a catalog containing all symbols that are available to the binder. These symbols include section and class names, as well as ordinary symbol definitions and references.
- B_RLD
- Relocation dictionary, containing information used to adjust addresses within the code based on where the module is loaded.
- B_IDRB
- Binder identification record, indicating the binder version, size, and how and when the program object was created.
- B_IDRL
- Language processor identification record, indicating the compilers that created the binder input, the date of compilation, and the binder size.
- B_IDRU
- User-specified identification record, containing data provided on an IDENTIFY control statement.
- B_IDRZ
- AMASPZAP identification record, for programs that have been modified at the object level.
- B_SYM
- Internal symbol table records
- B_MAP
- Module map
- B_TEXT24
- Relocatable text loaded below the 16-meg line and used in place of B_TEXT if RMODE=SPLIT is specified.
- B_TEXT31
- Relocatable text loaded above the 16-meg line and used in place of B_TEXT if RMODE=SPLIT was specified.
- B_TEXT64
- Relocatable text loaded above the 2-gigabyte bar and used in place of B_TEXT if RMODE=SPLIT and RMODEX were specified.
- B_LIT
- Load information table, containing data generated by the binder and used by the Language Environment® run time. For more information, see Accessing program object class information.
- B_IMPEXP
- IMPORT/EXPORT table, containing data generated by the binder and used by the Language Environment run time to support DLLs and DLL applications.
- B_PARTINIT
- Part initializers, containing the initial data for parts in merge classes. During bind processing, merge classes are mapped at the module level and the initial data moved from B_PARTINIT to the owning merge class.
- B_DESCR
- Linkage descriptors built by the binder for XPLINK support (Linkage Descriptors may also exist in compiler-defined classes).
In addition to the binder defined classes shown above, compiler-defined class names and class names that are defined by you (or your system programmer) can be specified on all calls. Class names are limited to 16 characters. Class names beginning with C_ should be used only for Language Environment-enabled applications.
- section
- A
section name is a programmer-, assembler-, or compiler-assigned name of a collection of one
or more elements, where each element belongs to a specified class. All binder actions referring to
sections affect all the elements in that section. For control and common sections, the section name
is the CSECT or common section name.
Some elements do not relate directly to any particular section (for example, the binder identification records). The binder assigns these elements unique section names.
Unnamed sections (sections with names consisting of all blanks), and sections whose names the user has designated as not visible to the other sections in the module ('section scope'), are given unique binder–generated names. Binder–generated names are fullword integers. They are printed in binder listings as $PRIVxxxxxx, where xxxxxx is the printable representation of the integer. The one exception is 'blank common' whose name is retained as a one-character blank.
Section names may be assigned by the user or by the binder. For each of the binder-defined classes just described, the sources of the definitions for the section names are shown in the following table:
Class Name | Section Name |
---|---|
B_TEXT | User specified |
B_PRV | User specified; binder retains them in binder-created section X'00000003' |
B_ESD | User specified |
B_RLD | User specified |
B_IDRB | Binder-created class name, in binder-created section X'00000001' |
B_IDRL | User specified |
B_IDRU | User specified |
B_IDRZ | User specified |
B_SYM | User specified |
B_MAP | Binder-created class name, in binder-created section X'00000001' |
B_TEXT24 | User specified or binder-created |
B_TEXT31 | User specified or binder-created |
B_LIT | Binder-created class name, in binder-created section IEWBLIT |
B_IMPEXP | Binder-created class name, in binder-created section IEWBCIE |
B_PARTINIT | User specified |
B_DESCR | Binder-created class name, in binder-created section X'00000003' |