gtpi1m77System Installation Support Reference

Creating the Input Deck

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.

Comments

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.

Specifying the Addressing Mode

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:




MODE=24BIT|31BIT

where 24BIT is the default.

Notes:

  1. 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.

  2. 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.

Allocating Programs

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:

  1. FR replaces the MR used in previous releases.

  2. Core resident (CR) programs do not have a demand counter.

  3. 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.

Allocating Transfer Vectors

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:




prog,TV,parent,tv#

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.

Allocating Spare Program Slots

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:




SPARE

where:

SPARE
Indicates that this is a spare statement.

Defining Pools

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

Adding Your Own Function Switches

Function switches determine whether a program is allocated normally or as a dummy program.

To Add Your Own Function Switches

  1. Update the SIP SKFUNC skeleton. Add your new switch in four places:
  2. 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
    
  3. In the section where global variables are defined, for example:
          GBLB &NEWFUNC
    
  4. In the section containing SETB instructions, for example:
          &NEWFUNC    SETB    (&SBaaaa AND &SBbbbb)
    
    (where &SBaaaa and &SBbbbb are defined function switches).
  5. In the final section that punches out the IBM C Language header file, before the EOFL statement, for example:
          PUNCH '             "NEWFUNC",&NEWFUNC,'
    
  1. Code your new function switch name on the FUNC parameter of the program allocation statement.
  2. Code EXPRS=S on the SIP GENSIP macro to generate the IBM C Language header file c$idfunc.h.
  3. Rerun SIP Stage I.
  4. 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.