z/TPF Program Management - IBM

More documents

Recommendations

Info

Figure 2. BAL repackaging Entry points Note: R10 - R13 are available for program use. Figure 2 shows how multiple programs (PGM1, PGM2, and PGM3) are packaged into one BSO. The result is a BSO with multiple entry points. The initial packaging will convert each assembler program into its own BSO. It is possible for an assembler program to reside in more than one BSO, but its entry point name can only be externalized from one of the BSOs. Entry points are listed in the entry point linkage table (EPLT). The following shared objects and entry points are included in the EPLT: v All shared objects (real-time programs) v Entry points that are coded for BEGIN macros in BSO source files – Primary entry points that are specified for the NAME= parameter – Transfer vectors that are specified for the TV= parameter. Executable and linking format (ELF) 12 z/TPF Program Management PGM1 PGM2 PGM3 PGM1.so Entry point PGM1 Entry point PGM2 Entry point PGM3 ELF is the standard binary format on operating systems such as Linux. Some of the capabilities of ELF are dynamic linking, dynamic loading, imposing run-time control on a program, and an improved method for creating shared libraries. The ELF representation of control data in an object file is platform independent, which is an additional improvement over previous binary formats. The ELF representation permits object files to be identified, parsed, and interpreted similarly, making the ELF object files compatible across multiple platforms and architectures of different size. The three main types of ELF files are: v Executable v Relocatable v Shared object These file types hold the code, data, and information about the program that the operating system and linkage editor need to perform the appropriate actions on these files.
Archives Visibility in shared objects Archives are a collection of ELF objects that are link-edited into a shared object. If your calling program has an ARCHIVES:= statement coded in the associated makefile, the archives specified by the statement get link-edited into the shared object. This way, the link to the functions contained in the archive is static. Use archives if you have a library of functions that frequently change and you are interested in changing the functions themselves without impacting the application programming interfaces (APIs) contained in the shared object or the calling program. A tape library is an example of an archive. See “Create an archive for online programs” on page 67 and “Create an archive for offline Linux programs” on page 68 for more information about creating archives. See “Create an offline Linux program” on page 67 for an example of a program that calls functions in an archive. In the GNU compiler collection (GCC) environment, the term that is used for exporting is visibility. As it applies to functions and variables in a shared object, visibility refers to the ability of other shared objects to call a C/C++ function. Functions with default visibility have a global scope and can be called from other shared objects. Functions with hidden visibility have a local scope and cannot be called from other shared objects. Visibility can be controlled by using either compiler options or visibility attributes. The -fvisibility=default compiler option (used in conjunction with the -fvisibility inlines=default compiler option for C++ programs) is used to define all of the functions in a shared object as visible (global scope). These compiler options are available on all z/TPF-supported compilers. Adding the visibility attribute can override a compiler option. Using the z/TPF MakeTPF tool makes it relatively easy to control the visibility of functions by changing the makefile to specify APP_EXPORT or to use the visibility attribute in the program. MakeTPF and visibility The maketpf APP_EXPORT variable controls which functions are local to the shared object and which functions can be called from other shared objects, where APP_EXPORT can be set to: ALL, VISIBILITY, LIST, orENTRY. v ALL is used to make all functions visible by default at compile time, by adding the -fvisibility=default compiler option (used in conjunction with the -fvisibility inlines=default compiler option for C++ programs) to the compile commands. Individual functions can be hidden by using the visibility attribute; add __attribute__ ((visibility("hidden")) to the functions you want to hide. Note: Avoid adding __attribute__ ((visibility("hidden")) to C++ code unless it is essential for class member functions to be hidden. For more information about potential problems when you use visibility with C++ classes, see “Special considerations for C++ classes” on page 15. v VISIBILITY is used to hide all functions by default at compile time, by adding the -fvisibility=hidden compiler option (used in conjunction with the -fvisibility inlines=hidden compiler option for C++ programs) to the compile commands. z/TPF program types and linkage 13
Page 1: z/Transaction Processing Facility E
Page 4 and 5: | | | | | Common deployment . . . .
Page 6 and 7: vi z/TPF Program Management Linux l
Page 8 and 9: 2 z/TPF Program Management
Page 10 and 11: Makefiles Control files 4 z/TPF Pro
Page 12 and 13: | | | | | | | | loadtpf utility Rel
Page 14 and 15: 8 z/TPF Program Management There ar
Page 20 and 21: 14 z/TPF Program Management Individ
Page 22 and 23: Transfer vectors Program linkage 16
Page 26 and 27: Images Loadsets 20 z/TPF Program Ma
Page 28 and 29: present, the program or programs ar
Page 30 and 31: ELF objects and libraries from the
Page 32 and 33: ELF objects and libraries from the
Page 34 and 35: Data loader Pilot Tape (SDF) ZSLDR
Page 36 and 37: Alternate FCTB loader benefits Use
Page 40 and 41: | | | | | | | | | | | | | | | | | |
Page 44 and 45: | | | | | | | | | | | | | | | | | |
Page 46 and 47: | | | | | | | | | | | | | | | 40 z/
Page 52 and 53: | | | | | | | | | | | | | | | | | |
Page 56 and 57: | | | | | | | | | | | | | | | | | |
Page 64 and 65: zos/ obj/ src/ bin/ lst/ obj/ src/
Page 66 and 67: APPL_ROOT := /home/joe/mywork APPL_
Page 68 and 69:
Create a single-segment BSO using a
Page 70 and 71:
Adding the line APP_EXPORT := LIST
Page 72 and 73:
66 z/TPF Program Management v CTBX
Page 74 and 75:
3. Update the user control file and
Page 76 and 77:
Update export files this, when an e
Page 78 and 79:
72 z/TPF Program Management Note: I
Page 80 and 81:
3. The JCL also references the form
Page 82 and 83:
76 z/TPF Program Management
Page 84 and 85:
To logically copy CIMR components f
Page 86 and 87:
Page 88 and 89:
offldr programs, as necessary, to c
Page 90 and 91:
84 z/TPF Program Management User: Z
Page 92 and 93:
Page 94 and 95:
Activate a loadset of E-type progra
Page 96 and 97:
v All loadsets containing a particu
Page 98 and 99:
Terminal Addr Index into Selective
Page 100 and 101:
| | | | | | | | | | | | | | | | | |
Page 102 and 103:
| | | | | | | | | | | | | | | | | |
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
| 104 z/TPF Program Management For
Page 112 and 113:
Page 114 and 115:
108 z/TPF Program Management Table
Page 116 and 117:
110 z/TPF Program Management Table
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
118 z/TPF Program Management user e
Page 126 and 127:
120 z/TPF Program Management -outpu
Page 128 and 129:
0 8 0 v A return code indicating th
Page 130 and 131:
124 z/TPF Program Management The fo
Page 132 and 133:
►► 126 z/TPF Program Management
Page 134 and 135:
@CIMR 128 z/TPF Program Management
Page 136 and 137:
The default location is searched fo
Page 138 and 139:
@CTKX 132 z/TPF Program Management
Page 140 and 141:
@DEFINE 134 z/TPF Program Managemen
Page 142 and 143:
136 z/TPF Program Management Additi
Page 144 and 145:
IMGCLEAR specifies whether image-re
Page 146 and 147:
-d specify this parameter, the sour
Page 148 and 149:
@GFKEYPOINT 142 z/TPF Program Manag
Page 150 and 151:
144 z/TPF Program Management v CTKM
Page 152 and 153:
►► @IPL 146 z/TPF Program Manag
Page 154 and 155:
@KEYPOINT Note: The length of the d
Page 156 and 157:
%cpuid loads the specified keypoint
Page 158 and 159:
152 z/TPF Program Management defaul
Page 160 and 161:
information must begin on a new lin
Page 162 and 163:
Page 164 and 165:
Input files The following examples
Page 166:
show all

z/TPF Program Management - IBM

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?