gtpi1m77 | System Installation Support Reference |
The following sections describe how to code user input decks. The
decks consist of SALO input statements that contain program allocation
information, symbol definitions, default mode settings, or comments.
All statements, except comments, must be coded in uppercase.
All program, transfer vector, and symbol definition statements are placed
in the SAL table. All program and spare statements also appear in the
PAT unless function switches or subsystem switches coded for them are
false.
Programs can be allocated either normally or as dummy. Normally
allocated programs appear in both the SAL table and the PAT. Dummy
allocated programs only appear in the SAL table and indicate to the linkage
editor (LEDT) that the name of the dummy allocated program is valid and should
not be flagged as an unresolved external.
A program is allocated as dummy if the function switch name coded on the
FUNC= parameter of a program allocation statement resolves to 0 (false)
or the subsystem name coded on the SS= parameter of a program
allocation statement does not match the subsystem name coded on the SS=
parameter passed to SALO.
Function switch names are resolved by the SIP created C header file
c$idfunc. c$idfunc equates a 1 or a 0 (true or
false) with each valid function switch name.
You can intersperse comments with input statements but they must contain an
asterisk (*) in column 1. You can also put comments on the same line as
other statements but at least one space must separate the comment from the
statement.
When you want a block of programs to run in a particular addressing mode
(24-bit addressing mode or 31-bit addressing mode) without specifying this on
each individual input statement, you can use the MODE statement. This
statement provides a default mode setting for all subsequent program
statements in the input decks.
The format of the MODE statement follows:
where 24BIT is the default.
Notes:
- All programs written in the IBM C Language must be allocated in 31-bit
addressing mode. This allows them to call heap storage functions, which
return 31-bit addresses.
- The FACE, SIGT, RIAT, and SNA tables are now above 16MB. All
programs that manipulate these tables or reference the FC0TB, SI0GT, and
DCTRIT data macros must be allocated as
31-bit addressing mode.
All program records are 4KB. The order in which the programs appear
in the input decks determines their program record numbers (PRNs).
Every program allocation statement is allocated as a 4KB block.
The format of the input statements for allocating file resident (FR) and
main storage resident or core resident (CR) programs follows:
prog,FR|CR [,CLASS=SHARED|COMMON|UNPROT|ISUNIQ|PRIVATE] [,MODE=24BIT|31BIT]
[,OPTIONS=(KEY0,MONTC,RESTRICT,CMB)[,SS=ALL|EXC|ssname]
[, FUNC=1|0|fsname]
[, PRELOAD ]
[, NODBUG ]
|
where:
- prog
- The 4-character program name that is being allocated. The program
name must be four characters long and the first character must be
alphabetic.
- FR|CR
- Indicates whether the program is to be file resident (FR), main storage
resident, or core resident (CR).
Notes:
- FR replaces the MR used in previous releases.
- Core resident (CR) programs do not have a demand counter.
- Core resident programs must have CLASS values of SHARED or COMMON.
- CLASS=
- The class of program can be SHARED, COMMON, UNPROT, ISUNIQ, or
PRIVATE. The default is SHARED.
- SHARED
- Indicates that all ECBs use the same copy of the program, but only those
ECBs currently using the program can view it. In addition, all ECBs
using the program can potentially access the program at different ECB virtual
addresses. The program resides in page-protected memory and
key-protected memory. The demand counter for noncore SHARED programs is
located in the PAT entry of the program.
- COMMON
- Indicates that all ECBs use the same copy of the program and access the
program at the same address. The program resides in key-protected
storage.
The demand counter for a noncore COMMON program is located in the PAT entry of
the program.
- UNPROT
- Indicates that this is a self-modifying I-stream shared program.
All ECBs use the same copy of the program and access the program at the same
address. The program resides in unprotected storage.
The demand counter for an UNPROT program is in the 8-byte program
header.
- ISUNIQ
- Indicates that this is a self-modifying I-stream unique program.
All ECBs on the same I-stream use the same copy of the program and access the
program at the same address. All copies of the program reside in
unprotected storage. The demand counter for an ISUNIQ program is in the
8-byte program header.
Moreover, ISO-C programs cannot be allocated as private or as
IS-unique.
- PRIVATE
- Indicates that this is a private program to
be loaded to a unique unprotected working storage block each time it is
entered. PRIVATE programs do not have a demand counter.
ISO-C programs cannot be allocated as private or as IS-unique.
Table 7 summarizes the use of the CLASS attribute for file-resident
programs.
Table 7. Summary of CLASS Attribute for File Resident Programs
| I-Stream Shared
| I-Stream Unique
| ECB Unique
| Same Address
| Protected
| Unprotected
|
SHARED
| X
|
|
|
| X
|
|
COMMON
| X
|
|
| X
| X
|
|
UNPROT
| X
|
|
| X
|
| X
|
ISUNIQ
|
| X
|
| X
|
| X
|
PRIVATE
|
|
| X
|
|
| X
|
- MODE=24BIT|31BIT
- The addressing mode in which the program is entered. This parameter
overrides any preceding MODE statement for this program. All programs
written in IBM C Language must be allocated in
31-bit mode.
- OPTIONS=
- One or more of the following macro authorization options (separated by
commas):
- KEY0
- Specifies that the E-type program can issue a macro that lets the
program store into protected storage (change the protection key to 0).
- MONTC
- Specifies that the E-type program can issue a MONTC
macro that lets the program store into protected storage and execute
privileged instructions until the program issues an LMONC
macro.
- RESTRICT
- Specifies that the program can issue macros that are restricted for other
reasons.
- CMB
- Specifies that the program can issue a macro to get common blocks.
- SS=
- A valid subsystem name as declared in the SIP Stage I SSDEF macro:
- ALL
- Indicates that the program should be allocated in all subsystems.
- EXC
- Indicates that the program should be allocated in all subsystems except
the BSS.
- ssname
- A valid subsystem name as declared in the SIP Stage I SSDEF macro.
The default is ALL.
- FUNC=
- A function switch:
- 1
- Specifies that the program allocated by this statement is placed in both
the system allocator (SAL) table and the program allocation table
(PAT).
- 0
- Specifies that this program is a dummy and is put only in the system
allocator (SAL) table.
- fsname
- A valid switch name taken from the SIP-created IBM C language header file
c$idfunc.h. See Adding Your Own Function Switches for more information.
The default is 1.
- PRELOAD
- Guarantees a core resident (CR) program will be loaded before 1052
state. The number of PRELOAD programs should be minimized for
performance reasons.
- NODBUG
- Specifies that the program is not available to be debugged using the TPF
Assembler Debugger for VisualAge Client. This parameter is available
only for programs that are allocated as 31-bit core resident or file resident
with a class of SHARED or COMMON.
A transfer vector is the label name given to an entry point into
a program. The program in which the entry point is located is called
the parent. The parent can have multiple entry points (transfer
vectors) within it. An allocation statement for the parent program must
precede all its transfer vector's allocation statements. A
transfer vector has the same allocation attributes as its parent. Each
transfer vector uses 4KB of DASD.
- Note:
- Transfer vectors are not supported for ISO-C dynamic load modules
(DLMs). DLMs can have only one entry point.
The format of the input statements for allocating transfer vectors
follows:
where:
- prog
- The 4-character transfer vector name that is being allocated. The
first character must be alphabetic.
- TV
- Indicates that this is a transfer vector statement.
- parent
- The 4-character program name this transfer vector is located in.
The parent cannot be a transfer vector.
- tv#
- The transfer vector number for prog, which must be a decimal
number in the range 0 to 1023.
Spare statements interspersed throughout the program allocation table (PAT)
hold program record numbers (PRNs) and 4KB blocks of DASD so that programs can
be placed in these positions at a later time. This allows you to add
and delete programs without changing existing PRNs. Any programs you
add without using spares must be added after the last entry in the last input
deck. If programs are added in the middle, a full load must be
done.
The format of the input statements for allocating spare program slots
follows:
where:
- SPARE
- Indicates that this is a spare statement.
The format of the input statements for defining pools follows:
poolsym,TYPE=POOL,VALUE=svc
|
where:
- poolsym
- The 3-character GFS ID to be expanded. The first two characters are
the record ID and the third character is the record size attribute (L for
large records or S for small records).
- svc
- A 3-byte hexadecimal SVC interrupt code. Valid codes include:
- 0ABC nn
- SLT (small, long-term)
- OABE nn
- SST (small, short-term)
- 0AC0 nn
- SDP (small, duplicated)
- 0AC2 nn
- LLT (large, long-term)
- 0AC4 nn
- LST (large, short-term)
- OAC6 nn
- LDP (large, duplicated)
where nn stands for:
- 00
- ratio dispensing option
- 04
- DASD Device A
- 08
- DASD Device B
- 0C
- DASD Device C
- 10
- DASD Device D
Function switches determine whether a program is allocated normally
or as a dummy program.
- Update the SIP SKFUNC skeleton. Add your new switch in four
places:
- In the list of switches in the prologue section (comments) of the macro,
along with a description of the switch, for example:
.* &NEWFUNC NEW FUNCTION SWITCH
- In the section where global variables are defined, for example:
GBLB &NEWFUNC
- In the section containing SETB instructions, for example:
&NEWFUNC SETB (&SBaaaa AND &SBbbbb)
(where &SBaaaa and &SBbbbb are defined
function switches).
- In the final section that punches out the IBM C Language header file,
before the EOFL statement, for example:
PUNCH ' "NEWFUNC",&NEWFUNC,'
- Code your new function switch name on the FUNC parameter of the program
allocation statement.
- Code EXPRS=S on the SIP GENSIP macro to generate the
IBM C Language header file c$idfunc.h.
- Rerun SIP Stage I.
- Execute the JCL generated by step 3.
When adding a new function switch, avoid using names beginning with
&SB. This naming convention is reserved for IBM
use.