unisys

Application Development Solutions

Application Development Programming Guide

ClearPath OS 2200 Release 14.0

February 2013 7831 4077–009

NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information
described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to
purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the
products described in this document are set forth in such agreement. Unisys cannot accept any financial or other
responsibility that may be the result of your use of the information in this document or software material, including
direct, special, or consequential damages.

You should be very careful to ensure that the use of this information and/or software material complies with the
laws, rules, and regulations of the jurisdictions with respect to which it is used.

The information contained herein is subject to change without notice. Revisions may be issued to advise of such
changes and/or additions.

Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed
at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard
commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract
data rights clauses.

Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries.
All other brands and products referenced in this document are acknowledged to be the trademarks or registered
trademarks of their respective holders.
Contents
Section 1. UCS Application Programming Overview

1.1. Document Updates.............................................................................1–1

1.2. About This Guide .................................................................................1–1
1.3. Extended Mode .................................................................................. 1–4
1.4. Compiling UCS Programs ................................................................. 1–7
1.4.1. Compilation Output in the Object Module ....................... 1–11
1.4.2. Linking UCS Programs with the Linking System ............ 1–12
1.4.2.1. Object Module Output Routines (OMOR) ............. 1–14
1.4.2.2. Dynamic Linker ............................................................. 1–15
1.4.2.3. LINK Processor (@LINK) ............................................. 1–18
1.4.2.4. The Subsystem Definition Processor
(@SSDP) ..................................................................... 1–25
1.4.2.5. The Subsystem Information Processor.................. 1–25
1.4.3. Supporting Program Execution with the UCS
Runtime System ................................................................ 1–26
1.4.4. Debugging UCS Programs with PADS .............................. 1–27
1.4.5. Debugging UCS Programs with MONITOR ..................... 1–28
1.4.6. UCS Application Development Summary ........................ 1–29
1.5. Developing User Applications ...................................................... 1–31
1.6. Benefits of Extended Mode Hardware and Software............1–34

Section 2. Compiling UCS Programs

2.1. Specifying Compiler Options .......................................................... 2–2

2.1.1. Letter Options ........................................................................... 2–2
2.1.2. Keyword Options .....................................................................2–3
2.1.3. Keyword Options Element ................................................... 2–4
2.2. UCS Compiler Listings ......................................................................2–5
2.2.1. Sign-On Line...............................................................................2–6
2.2.2. Options Listing ..........................................................................2–6
2.2.3. Bank Sizes Line ......................................................................... 2–7
2.2.4. Sign-Off Line ..............................................................................2–8

Section 3. Application Programming in a Batch or Demand

Environment

3.1. Basic Information for Batch and Demand

Programming .................................................................................. 3–1
3.1.1. Coding Batch and Demand Programs ................................ 3–4
3.1.2. Compiling Batch and Demand Programs .......................... 3–6
3.1.3. Linking Batch and Demand Programs in the
Development Phase .......................................................... 3–9

7831 4077–009 iii

Contents

3.1.3.1. Dynamic Linking Only ................................................... 3–9

3.1.3.2. Partial Static Linking and Partial Dynamic
Linking ........................................................................ 3–12
3.1.3.3. Static Linking Only (Total Resolution) ..................... 3–15
3.1.3.4. Resolving References Using Library
Search Chains in LINK$PF.SSDEF$ and
SYS$*DATA$.SSDEF$ ............................................ 3–16
3.1.3.5. Understanding the Output of a Static Link ........... 3–20
3.1.4. Examples of Batch and Demand Programs ................... 3–26
3.1.4.1. Example of a Stand-Alone COBOL
Program .................................................................... 3–26
3.1.4.2. Source Listing of the Program (COBOLEX) .......... 3–27
3.1.4.3. Source Listing of Runstream ................................... 3–28
3.1.4.4. Execution of the Source Runstream ...................... 3–29
3.1.4.5. Example of a COBOL Main Program and
Two Subprograms ................................................. 3–33
3.2. Coding, Compiling, and Linking Batch and Demand
Programs That Access UDS Databases ............................... 3–46
3.2.1. Using DMS 2200 Databases ............................................... 3–50
3.2.1.1. DMS 2200 Schemas .................................................... 3–51
3.2.1.2. DMS 2200 Database Procedures ............................ 3–53
3.2.1.3. DMS 2200 Subschemas............................................. 3–54
3.2.1.4. Example of a DMS 2200 Database
Definition .................................................................. 3–57
3.2.1.5. Coding UCS DML Programs ..................................... 3–66
3.2.1.6. Compiling UCS DML Programs ................................ 3–67
3.2.1.7. Basic Linking Information for UCS DML
Programs .................................................................. 3–69
3.2.1.8. Example of a UCS Program Containing
DML Statements .................................................... 3–74
3.2.2. Using RDMS 2200 Databases ............................................ 3–83
3.2.2.1. RDMS 2200 Tables ...................................................... 3–84
3.2.2.2. Example of an RDMS 2200 Database
Definition .................................................................. 3–86
3.2.2.3. Coding with the RDMS 2200 Embedded
SQL Interface .......................................................... 3–94
3.2.2.4. Dynamic ESQL Commands for UCS
COBOL and UCS C ............................................... 3–103
3.2.2.5. Coding with the RDMS 2200 Module SQL
Interface.................................................................. 3–105
3.2.2.6. Using the SQL Module Preprocessor .................. 3–105
3.2.2.7. Coding with the RDMS 2200 SQL
Interpreter Interface ............................................ 3–109
3.2.2.8. Defining RDMS 2200 Columns as Program
Variables ...................................................................3–111
3.2.2.9. Compiling UCS Programs That Access
RDMS 2200 Databases ........................................ 3–113
3.2.2.10. Basic Linking Information for UCS RDMS
2200 Programs ....................................................... 3–115
3.2.2.11. Example of a UCS Program Containing
RDMS 2200 Statements ..................................... 3–120
3.2.2.12. DISPLAYFAM ............................................................... 3–121

iv 7831 4077–009
 Contents

3.2.3. Using SFS 2200 Databases ............................................... 3–156

3.2.3.1. Defining SFS 2200 Files and Storage Areas ........3–157
3.2.3.2. Example of an SFS 2200 Database
Definition ................................................................ 3–160
3.2.3.3. Coding UCS Programs That Access SFS
2200 Databases .................................................... 3–162
3.2.3.4. Compiling UCS Programs That Access SFS
2200 Databases .................................................... 3–163
3.2.3.5. Basic Linking Information for UCS SFS
2200 Programs ...................................................... 3–163
3.2.3.6. Executing UCS Programs That Access SFS
2200 Databases .................................................... 3–167
3.2.3.7. Example of a UCS Program That Accesses
an SFS 2200 Database......................................... 3–169
3.2.4. Accessing Multiple UDS Database Models.................. 3–178
3.2.4.1. Source Listing of the Program
(DISPLAYALL) ........................................................ 3–180
3.2.4.2. Source Listing of Runstream ................................. 3–187
3.2.4.3. Execution of the Source Runstream .................... 3–188
3.3. Using DPS 2200 with UCS ............................................................ 3–191
3.3.1. Example of a DPS 2200 Form Definition ....................... 3–193
3.3.2. Examples of the Working Storage Definition for
a DPS 2200 Form ............................................................ 3–199
3.3.3. Coding UCS Programs That Use DPS 2200
Functions .......................................................................... 3–210
3.3.4. Compiling UCS Programs That Use DPS 2200.............. 3–211
3.3.5. Basic Linking Information for UCS DPS 2200
Programs ...........................................................................3–213
3.3.6. Example of a UCS COBOL Program Using DPS
2200 Functions ................................................................ 3–216
3.3.7. Example of a UCS C Program Using DPS 2200 ........... 3–226
3.3.7.1. Source Listing of the DPS 2200 C Program
(CDPSDSPLY) ......................................................... 3–227
3.3.7.2. Source Listing of Runstream to Compile ............ 3–230
3.3.7.3. Execution of the Source Runstream to
Compile ....................................................................3–231
3.3.7.4. Execution in Demand Mode ................................... 3–232
3.3.8. Using DPS 2200 with the UDS Database Models ....... 3–233
3.3.8.1. Source Listing of the Program
(DPSDSPLYALL) .................................................... 3–235
3.3.8.2. Source Listing of the Runstream to
Compile and Statically Link ................................ 3–244
3.3.8.3. Execution of the Source Runstream to
Compile and Statically Link ................................ 3–245
3.3.8.4. Execution of the Program in Demand
Mode ....................................................................... 3–246
3.4. Accessing the Unisys Repository Manager (UREP)
with UCS COBOL ...................................................................... 3–247
3.5. Improving Batch and Demand Execution-Time
Performance .............................................................................. 3–249
3.5.1. Coding for Batch and Demand Execution-Time
Performance .................................................................... 3–249

7831 4077–009 v
Contents

3.5.2. Compiling for Batch and Demand Execution-

Time Performance ......................................................... 3–252
3.5.3. Linking for Batch and Demand Execution-Time
Performance .................................................................... 3–253
3.5.3.1. Basic Static Linking Suggestions .......................... 3–253
3.5.3.2. URTS$TABLES Operation ........................................ 3–253
3.5.3.3. Static Linking with RDMS 2200 ............................. 3–255
3.5.3.4. Static Linking with DPS 2200.................................. 3–256
3.5.3.5. Setting the Initial Size of the ALS .......................... 3–258

Section 4. Linking to Application Groups by Using Library

Search Chains

4.1. Application Groups ............................................................................ 4–1

4.2. Overview of Linking to Application Groups ............................... 4–2
4.3. Dynamically Linking to Application Groups ................................ 4–5
4.4. Statically Linking to Application Groups ...................................... 4–6
4.5. Building and Using Search Chains That Include DPS
2200 ................................................................................................. 4–6
4.5.1. Building DPS 2200 Library Search Chains ......................... 4–6
4.5.2. Using DPS 2200 Library Search Chains .............................. 4–7
4.6. How the System Sets Up Library Search Chains for
Application Groups ...................................................................... 4–8
4.6.1. Library Search Chains in SYS$*DATA$.SSDEF$ .............. 4–8
4.6.1.1. LSCs in SYS$*DATA$.SSDEF$ That Define
Software in an Application Group ........................ 4–8
4.6.1.2. LSCs in SYS$*DATA$.SSDEF$ That Define
the Active Application Group ................................ 4–9
4.6.2. Library Search Chains in
SYS$LIB$*APP$n.SSDEF$ ............................................... 4–11
4.6.3. Specifying Use of Application Group LSCs ..................... 4–12

Section 5. Application Programming in a TIP Environment

5.1. Basic Information for TIP Transaction Programming ................ 5–1

5.1.1. Coding TIP Transactions .........................................................5–2
5.1.1.1. Using DPS 2200 Functions ...........................................5–3
5.1.1.2. Using MCB Functions ....................................................5–5
5.1.1.3. Using the Non-Message-Handling
Primitives .................................................................... 5–8
5.1.1.4. Using the COBOL INITIAL Clause .............................. 5–9
5.1.1.5. UCS Language Coding Considerations .................... 5–9
5.1.1.6. Setting Up a TIP Transaction ..................................... 5–10
5.1.2. Compiling TIP Transaction Programs ................................ 5–12
5.1.3. Basic Static Linking of TIP Transaction
Programs .............................................................................5–14
5.1.3.1. Basic Static Linking for a TIP Transaction
Program .....................................................................5–14
5.1.4. Examples of TIP Transaction Programs ........................... 5–17
5.1.4.1. Example Using DPS 2200 Functions ....................... 5–17
5.1.4.2. Example Using MCB Functions ............................... 5–29

vi 7831 4077–009
 Contents

5.2. TIP Transactions That Access UDS Databases ....................... 5–48

5.2.1. Using DMS 2200 Databases ................................................ 5–51
5.2.1.1. DMS 2200 Schemas .................................................... 5–51
5.2.1.2. DMS 2200 Subschemas............................................. 5–53
5.2.1.3. Using UDS-TIP Files .................................................... 5–55
5.2.1.4. Example of a DMS 2200 Database
Definition .................................................................. 5–56
5.2.1.5. Coding UCS DML Transaction Programs .............. 5–72
5.2.1.6. Compiling UCS DML Transaction
Programs .................................................................. 5–73
5.2.1.7. Basic Linking Information for UCS DML
Transaction Programs ........................................... 5–75
5.2.1.8. Example of a UCS Transaction Program
Containing DML Statements ............................... 5–78
5.2.2. Using RDMS 2200 Databases ............................................ 5–95
5.2.2.1. RDMS 2200 Tables ...................................................... 5–95
5.2.2.2. Using UDS-TIP Files .................................................... 5–97
5.2.2.3. Example of an RDMS 2200 Database
Definition .................................................................. 5–97
5.2.2.4. Coding RDMS 2200 TIP Transactions ................... 5–112
5.2.2.5. Compiling UCS Transaction Programs That
Access RDMS 2200 Databases ......................... 5–113
5.2.2.6. Basic Linking Information for UCS RDMS
2200 Transaction Programs ................................ 5–118
5.2.2.7. Example of a UCS COBOL Transaction
Program Containing RDMS 2200
Statements .............................................................5–120
5.2.3. Using SFS 2200 Databases ............................................... 5–153
5.2.3.1. Defining SFS 2200 Files and Storage Areas ....... 5–154
5.2.3.2. Using UDS/TIP Files .................................................. 5–156
5.2.3.3. Example of an SFS 2200 Database
Definition ................................................................ 5–156
5.2.3.4. Coding UCS Transaction Programs That
Access SFS 2200 Databases .............................. 5–161
5.2.3.5. Explicit Thread Control in UCS SFS 2200
Transaction Programs ..........................................5–162
5.2.3.6. Compiling UCS Transaction Programs That
Access SFS 2200 Databases ..............................5–162
5.2.3.7. Basic Linking Information for UCS SFS
2200 Transaction Programs ............................... 5–163
5.2.3.8. Example of a UCS Transaction Program
That Accesses an SFS 2200 Database............ 5–165
5.2.4. Coding, Compiling, and Linking Multiple
Database Models in TIP Transactions....................... 5–183
5.2.4.1. Source Listing of the Program (DPSALL) ............ 5–185
5.2.4.2. Source Listing of the Runstream to
Compile and Statically Link ................................ 5–195
5.2.4.3. Execution of the Source Runstream to
Compile and Statically Link ................................ 5–198
5.2.4.4. Execution of the DPS DMS RDMS SFS
Transaction Program ........................................... 5–203

7831 4077–009 vii

Contents

5.3. Improving TIP Transaction Execution-Time

Performance .............................................................................. 5–204
5.3.1. Coding for Standard TIP Execution-Time
Performance .................................................................... 5–204
5.3.2. Compiling for Standard TIP Execution-Time
Performance .................................................................... 5–207
5.3.3. Linking UCS Standard TIP Transactions for
Performance .................................................................... 5–208
5.3.3.1. Basic Static-Linking Suggestions .......................... 5–208
5.3.3.2. URTS$TABLES Operation ........................................ 5–209
5.3.3.3. C malloc Calls Under TIP (TIPMALLOC) ................ 5–211
5.3.3.4. Static Linking with RDMS 2200 .............................. 5–211
5.3.3.5. Static Linking with DPS 2200................................... 5–212
5.3.3.6. Space Optimization ................................................... 5–214
5.3.3.7. Example Application ................................................. 5–214
5.3.3.8. Setting the Initial Size of the Heap
(URTS$TABLES) .................................................... 5–223
5.3.4. Transaction Processing Techniques for
Improving Performance ................................................ 5–225

Section 6. Application Programming in an HVTIP Environment

6.1. Basic Information for HVTIP Transaction

Programming .................................................................................. 6–1
6.1.1. The HVTIP-II Environment ......................................................6–2
6.1.2. Coding HVTIP Transactions .................................................. 6–4
6.1.2.1. Designating a Transaction ZOOM as an
ICP or a Subprogram ............................................... 6–5
6.1.2.2. Defining Storage in HVTIP Transactions ................. 6–6
6.1.2.3. Coding HVTIP Transactions That Use DPS
2200 Functions .......................................................... 6–9
6.1.2.4. Coding HVTIP Transactions That Use MCB
Functions ................................................................... 6–11
6.1.2.5. Coding HVTIP Transactions That Use the
Non-Message-Handling Primitives ..................... 6–13
6.1.2.6. UCS Language Coding Considerations ...................6–14
6.1.2.7. Setting Up an HVTIP Transaction
Sequence ...................................................................6–14
6.1.2.8. Using the COBOL INITIAL Clause ............................ 6–28
6.1.2.9. Using the COBOL CANCEL Statement .................. 6–29
6.1.3. Compiling HVTIP ICPs and Subprograms ......................... 6–31
6.1.4. Basic Static Linking of HVTIP Transactions .................... 6–33
6.1.4.1. Basic Static Linking for an ICP ................................. 6–34
6.1.4.2. Basic Static Linking for HVTIP
Subprograms ........................................................... 6–38
6.1.5. Examples of HVTIP Transactions .......................................6–41
6.1.5.1. Example Using DPS 2200 Functions ...................... 6–42
6.1.5.2. Example Using MCB Functions ................................ 6–61
6.1.6. HVTIP Subprograms with Multiple Entry Points ........... 6–83
6.1.6.1. Example Transaction .................................................. 6–83

viii 7831 4077–009

 Contents

6.1.6.2. Step 1: Coding the MASM Jump Vector

Routine ...................................................................... 6–86
6.1.6.3. Step 2: Statically Linking the Subprogram
with Multiple Entry Points .................................... 6–88
6.1.6.4. Step 3: Creating the HVCALLS Element ............... 6–88
6.1.6.5. Step 4: Statically Linking the Calling
Program .................................................................... 6–89
6.1.7. Example of an HVTIP Subprogram with Multiple
Entry Points ........................................................................ 6–90
6.1.8. Mixed-Mode HVTIP.............................................................. 6–117
6.1.8.1. Simple Mixed-Mode Example................................. 6–119
6.1.8.2. Mixed-Mode Example 2 .......................................... 6–124
6.1.8.3. Mixed-Mode Example 3 .......................................... 6–130
6.1.9. Releasing Subprogram Storage....................................... 6–178
6.1.10. Creating HVTIP Transaction Programs Greater
Than 65K ............................................................................ 6–181
6.2. Coding, Compiling, and Linking HVTIP Transactions
That Access UDS Databases................................................. 6–182
6.2.1. Using DMS 2200 in HVTIP Transactions ........................ 6–182
6.2.1.1. Using UDS/TIP Files .................................................. 6–182
6.2.1.2. Processing Subschemas Used by HVTIP
Transactions .......................................................... 6–183
6.2.1.3. Coding DMS 2200 HVTIP Transactions ................ 6–183
6.2.1.4. Compiling DMS 2200 HVTIP Transactions .......... 6–185
6.2.1.5. Linking DMS 2200 HVTIP Transactions................ 6–185
6.2.2. Using RDMS 2200 in HVTIP Transactions ..................... 6–186
6.2.2.1. Using UDS/TIP Files .................................................. 6–186
6.2.2.2. Coding RDMS 2200 HVTIP Transactions ............. 6–186
6.2.2.3. Compiling RDMS 2200 HVTIP Transactions ....... 6–188
6.2.2.4. Linking RDMS 2200 HVTIP Transactions ............. 6–188
6.2.3. Using SFS 2200 in HVTIP Transactions .......................... 6–189
6.2.3.1. Using UDS/TIP Files .................................................. 6–189
6.2.3.2. Coding SFS 2200 HVTIP Transactions .................. 6–189
6.2.3.3. Compiling SFS 2200 HVTIP Transactions ............ 6–189
6.2.3.4. Linking SFS 2200 HVTIP Transactions .................. 6–189
6.2.4. Coding, Compiling, and Linking Multiple
Database Models in HVTIP Transactions ................. 6–190
6.3. Improving HVTIP Transaction Execution-Time
Performance ............................................................................... 6–191
6.3.1. Coding for HVTIP Execution-Time Performance .......... 6–191
6.3.2. Coding for Efficient Memory Usage............................... 6–192
6.3.3. Compiling for HVTIP Execution-Time
Performance .................................................................... 6–194
6.3.4. Linking UCS HVTIP Transactions for
Performance .................................................................... 6–195
6.3.4.1. Static-Linking with RDMS 2200 ............................. 6–196
6.3.4.2. Static Linking with DPS 2200.................................. 6–197
6.3.4.3. HVTIP ZOOM Structure ........................................... 6–199
6.3.4.4. HVTIP Transaction Execution ................................. 6–202
6.3.4.5. Space Optimization ................................................... 6–205
6.3.4.6. Example Application ................................................. 6–207

7831 4077–009 ix
Contents

6.3.4.7. Setting the Initial Size of the Activity-Local

Stack (ALS) ..............................................................6–217
6.3.4.8. Indexing Common Block Banks............................. 6–218
6.3.4.9. Setting LOWADR for HVTIP$$DSEG of the
Initial Control Program .........................................6–221
6.3.4.10. Setting LOWADR for Common Block
Banks ....................................................................... 6–224
6.3.4.11. Setting the Size of HVTIP$$DBANK ..................... 6–227
6.3.4.12. Setting EXPANSION_SIZE for
HVTIP$$DBANK .................................................... 6–230
6.3.4.13. Setting RELOAD_SKIP_SIZE .................................... 6–230
6.3.4.14. Initial Control Program Static Link
Runstream and Listing ........................................ 6–232
6.3.4.15. Subprogram Static Link Runstream and
Listing ...................................................................... 6–240
6.4. HVTIP and FLSS Error Messages .............................................. 6–242
6.5. The HVTIP-II Environment Details ............................................. 6–243
6.5.1. HVTIP-II VALTAB .................................................................. 6–243
6.5.2. HVTIP-II BDI Allocation ....................................................... 6–244
6.5.3. HVTIP-II Linking System Commands .............................. 6–244

Section 7. Using the COBOL CALL identifier Statement

7.1. The COBOL CALL identifier Statement ....................................... 7–1

7.2. Using CALL identifier with Standard Object Modules ............ 7–2
7.3. Using CALL identifier with TIP and HVTIP ZOOMs ................. 7–4
7.3.1. Listing of SYS$LIB$*LINK.LSI$RES-NAME ........................7–6
7.3.2. Specifying DECLARE Directives in LSI$RES-
NAME .....................................................................................7–9
7.3.3. Specifying CANCEL identifier Names .............................. 7–12
7.4. Using the LSI$RES-NAME Method with Object
Modules ......................................................................................... 7–13
7.5. Examples of Using CALL identifier with ZOOMs ................... 7–15
7.5.1. Standard (Batch/Demand) ZOOM Calling Two
Subprograms ...................................................................... 7–16
7.5.1.1. Source Listing of the Main Program
(PROGRAM1) ............................................................. 7–17
7.5.1.2. Partial Source Listing of Edited LSI$RES-
NAME Element ......................................................... 7–18
7.5.1.3. Source Listing of Subprograms ................................ 7–21
7.5.1.4. Source Listing of Runstream ................................... 7–23
7.5.1.5. Execution of the Source Runstream ...................... 7–25
7.5.2. TIP ZOOM Calling Two Subprograms .............................. 7–28
7.5.2.1. Source Listing of the Main Program
(PRGRM1) .................................................................. 7–29
7.5.2.2. Partial Source Listing of Edited LSI$RES–
NAME Element ........................................................ 7–30
7.5.2.3. Source Listing of Subprograms ............................... 7–33
7.5.2.4. Source Listing of Runstream ................................... 7–35
7.5.2.5. Execution of the Source Runstream ...................... 7–38

x 7831 4077–009
 Contents

7.5.2.6. Execution of the TIP Transactions in This

Example .................................................................... 7–40
7.5.3. HVTIP ZOOM ICP Calling Two Subprograms .................. 7–41
7.5.3.1. Source Listing of the ICP (MCBICP) ........................ 7–43
7.5.3.2. Partial Source Listing of MCBPKT-UCOB .............. 7–45
7.5.3.3. Source Listing of the ICP HVCALLS
Element ..................................................................... 7–49
7.5.3.4. Partial Source Listing of Edited LSI$RES-
NAME Element ........................................................ 7–49
7.5.3.5. Source Listing of First Subprogram........................ 7–52
7.5.3.6. Source Listing of Jump Vector Element
for Subprogram MCBSUBA ................................. 7–54
7.5.3.7. Source Listing of Second Subprogram .................. 7–55
7.5.3.8. Source Listing of Runstream ................................... 7–57
7.5.3.9. Execution of the Source Runstream ...................... 7–63
7.5.3.10. Execution of the HVTIP Transactions in
This Example ............................................................7–72

Section 8. Planning for Use of UCS in New and Existing

Applications

8.1. Implementing New User-Developed Applications ....................8–2

8.2. Coexistence of UCS and Non-UCS Programs in an
Existing Application ......................................................................8–2
8.2.1. Software and File Sharing by UCS and Non-UCS
Programs .............................................................................. 8–3
8.2.1.1. UDS Database and Software Sharing ...................... 8–5
8.2.1.2. PCIOS File Sharing ......................................................... 8–5
8.2.1.3. TIPUTILs for UCS and Non-UCS ..................................8–7
8.2.1.4. MCB Software Sharing ................................................ 8–8
8.2.1.5. DPS Form and Software Sharing ............................... 8–9
8.2.1.6. TIP FCSS File Sharing ...................................................8–10
8.2.2. Coexistence of UCS and Non-UCS Programs in
Different Environments ................................................... 8–11
8.2.2.1. Coexistence in Batch and Demand
Environments ........................................................... 8–11
8.2.2.2. Coexistence in TIP and HVTIP
Environments ........................................................... 8–11
8.2.2.3. Coexistence in the SX 1100 Environment ..............8–14
8.3. Upgrading Existing Programs to UCS ......................................... 8–15
8.3.1. Upgrading COBOL Programs .............................................. 8–17
8.3.2. Upgrading FORTRAN Programs .........................................8–19
8.3.3. Upgrading C Programs .......................................................... 8–21
8.3.4. Upgrading Other Languages .............................................. 8–22
8.3.5. Upgrading MASM Programs .............................................. 8–22
8.3.6. Upgrading User-Written Libraries ..................................... 8–23
8.3.7. High-Level Language Interfaces ........................................ 8–30
8.3.8. Common Bank Considerations ........................................... 8–31
8.3.9. Upgrading UDS Applications .............................................. 8–32
8.3.9.1. Upgrading Existing DMS 2200 Applications
to UCS ....................................................................... 8–32

7831 4077–009 xi
Contents

8.3.9.2. Upgrading Existing RDMS 2200

Applications to UCS ............................................... 8–34
8.3.9.3. Upgrading Existing SFS 2200 Applications
to UCS ....................................................................... 8–35
8.3.10. Upgrading Existing Programs That Access
PCIOS Files ......................................................................... 8–36
8.3.11. Converting Old Data Files.................................................... 8–36
8.3.12. Upgrading Applications That Use DPS 2200 .................. 8–37
8.3.12.1. Forms.............................................................................. 8–37
8.3.12.2. Coding ............................................................................ 8–37
8.3.12.3. Compiling ....................................................................... 8–37
8.3.12.4. Linking ............................................................................ 8–38
8.3.13. Upgrading TIP and HVTIP Transactions ........................... 8–38
8.3.13.1. Coding ............................................................................ 8–38
8.3.13.2. Compiling ........................................................................8–41
8.3.13.3. Linking .............................................................................8–41
8.3.13.4. Setup ...............................................................................8–41
8.3.14. Handling TIP Files .................................................................. 8–42
8.4. HVTIP Restrictions Lifted by UCS ............................................... 8–43
8.4.1. UCS FORTRAN and HVTIP ................................................... 8–43
8.4.2. DPS 2200, HVTIP, and UCS ................................................. 8–43
8.5. Preparation for Sites Without UCS Applications .................... 8–44
8.6. Checklists for Upgrading Existing ASCII COBOL
Applications to UCS ................................................................... 8–46
8.6.1. Upgrading ASCII COBOL DMS Applications to
UCS COBOL DMS ............................................................. 8–46
8.6.1.1. Review Related Documentation ............................. 8–46
8.6.1.2. Set Up Software .......................................................... 8–47
8.6.1.3. Verify Schema Code ................................................... 8–48
8.6.1.4. Define Subschema ...................................................... 8–48
8.6.1.5. Update DML Program Code ..................................... 8–48
8.6.1.6. Compile DML Program .............................................. 8–49
8.6.1.7. Use UCS Repository ................................................... 8–49
8.6.1.8. Link DML Program ...................................................... 8–49
8.6.1.9. Create Transaction Program VALTAB ..................... 8–51
8.6.1.10. Convert UCS DMS Database Procedures .............. 8–51
8.6.2. Upgrading ASCII COBOL DPS Transaction
Programs to UCS COBOL (Non-HVTIP) ........................ 8–51
8.6.2.1. Review Related Documentation ............................. 8–52
8.6.2.2. Set Up Software .......................................................... 8–52
8.6.2.3. Verify Schema Code (if using DMS) ....................... 8–53
8.6.2.4. Define Subschema (if using DMS) .......................... 8–53
8.6.2.5. Define Form .................................................................. 8–54
8.6.2.6. Update DPS Transaction Program Code ............... 8–54
8.6.2.7. Compile DPS Transaction Program ........................ 8–54
8.6.2.8. Link DPS Transaction Program ................................ 8–55
8.6.2.9. Create DPS Transaction Program VALTAB........... 8–56
8.6.3. Upgrading ASCII COBOL MCB Transaction
Programs to UCS COBOL (Non-HVTIP) ....................... 8–56
8.6.3.1. Review Related Documentation ............................. 8–57
8.6.3.2. Set Up Software .......................................................... 8–57
8.6.3.3. Verify Schema Code (If Using DMS) ....................... 8–58

xii 7831 4077–009

 Contents

8.6.3.4. Define Subschema (If Using DMS) ......................... 8–58

8.6.3.5. Update MCB Transaction Program Code .............. 8–58
8.6.3.6. Compile MCB Transaction Program ....................... 8–59
8.6.3.7. Link MCB Transaction Program ............................... 8–59
8.6.3.8. Create MCB Transaction Program VALTAB ......... 8–60

Section 9. Shared Subsystems in a Transaction Environment

9.1. Object Module Split Fixed-Gate Subsystems .............................9–2

9.2. Self-Contained Subsystems ............................................................9–2
9.3. Fast-Load Self-Contained Subsystems........................................ 9–3

Appendix A. Data Definitions

Index ..................................................................................................... 1

7831 4077–009 xiii

Contents

xiv 7831 4077–009

Figures

1–1. UCS Compilation Process ............................................................................................ 1–10

1–2. Application Development for UCS Programs ......................................................... 1–29

4–1. Using Library Search Chains to Link to Application Groups ................................. 4–4

5–1. Standard TIP Transaction—Generic ............................................................................ 5–1

5–2. Compilation of a UCS Transaction Program Using DPS 2200
Functions ..................................................................................................................... 5–13
5–3. Compilation of a UCS Transaction Program Using MCB Functions .................. 5–13
5–4. Example TIP Transaction Using DPS 2200 ............................................................... 5–17
5–5. Example TIP Transaction Using MCB Functions ................................................... 5–29

6–1. Example HVTIP Transaction—Generic ....................................................................... 6–1

6–2. HVTIP Subprogram with Multiple Entry Points ..................................................... 6–84
6–3. Example Showing HVTIP Subprogram with Multiple Entry Points .................. 6–90

7–1. COBOL CALL identifier.................................................................................................... 7–2

7831 4077–009 xv
Figures

xvi 7831 4077–009

Tables

1–1. Benefits of the UCS Hardware/Software Platform ...............................................1–34

3–1. Interfaces from UCS Languages ................................................................................. 3–4

3–2. UDS Interfaces from UCS Languages ...................................................................... 3–47
3–3. UCS Data Types Allowed for RDMS Column Definitions .................................. 3–112
3–4. SFS 2200 File Access Methods Supported for UCS Languages ..................... 3–156
3–5. UCS COBOL Data Structures in the Unisys Repository .................................... 3–247
3–6. UCS C and UCS FORTRAN Structures in the Unisys Repository.................... 3–248

5–1. Transaction Processing Interfaces from UCS Languages .....................................5–2

5–2. UDS Interfaces from UCS Languages in TIP Transactions ................................. 5–49
5–3. SFS 2200 File Access Methods Supported for UCS TIP Transaction
Programs .................................................................................................................. 5–153

6–1. Transaction Processing Interfaces from UCS Languages .................................... 6–4

8–1. Interfaces Supported in the UCS and Non-UCS Environments........................... 8–4

8–2. PCIOS File Access Methods and Organization ........................................................ 8–6
8–3. Steps to Upgrade an Existing Program to UCS ...................................................... 8–15
8–4. Keyword Options for Upgrading COBOL Programs .............................................8–18
8–5. Keyword Options for Upgrading FORTRAN Programs ....................................... 8–20
8–6. Basic Mode ERs and Extended Mode Services for UCS Languages .............. 8–24
8–7. Tools to Aid Upgrading ................................................................................................ 8–45

9–1. FLSS Object Module and HVTIP ZOOM Comparison ............................................. 9–4

A–1. Data Definitions Supplied or Produced by Unisys for UCS Interface

Products........................................................................................................................ A–1

7831 4077–009 xvii

Tables

xviii 7831 4077–009

Examples

2–1. Sample Compiler Listing .................................................................................................2–6

3–1. Example @LINK Output ............................................................................................... 3–20

3–2. Source Listing of the Program (QUAL*UCSTST COBOLEX) ............................... 3–27
3–3. Runstream to Compile, Link, and Execute (QUAL*UCSTST COBOLEX) ......... 3–28
3–4. Execution of Source Runstream—COBOL Program ........................................... 3–29
3–5. Source Listing of the Main Program (QUAL*UCSTST.MAIN) ............................ 3–34
3–6. Source Listing of First Subprogram (QUAL*UCSTST.SUB1)............................... 3–35
3–7. Source Listing of Second Subprogram (QUAL*UCSTST.SUB2) ........................ 3–36
3–8. Runstream to Compile, Link, and Execute—COBOL Main Program
with Subprograms ................................................................................................... 3–37
3–9. Execution of Source Runstream--COBOL Main Program with
Subprograms ..............................................................................................................3–41
3–10. Source Listing of the Schema (QUAL*UCSTST.PERSONNEL) ........................... 3–57
3–11. Source Listing of the Schema (QUAL*UCSTST.PERSONSUB) .......................... 3–60
3–12. Runstream to Process Schema and Subschema ................................................... 3–61
3–13. Execution of Source Runstream—DMS Database Setup .................................. 3–63
3–14. Source Listing of DML Program (QUAL*UCSTST.DISPLAYIND) ....................... 3–75
3–15. Runstream to Compile, Link, and Execute—COBOL DMS Program ............... 3–78
3–16. Execution of Source Runstream—COBOL DMS Program ................................. 3–80
3–17. Source Listing of the Table Definitions (QUAL*UCSTST.TABLES) ................... 3–86
3–18. Source Listing of the Load Data for INDIVIDUALR Table
(QUAL*INDLOAD) ..................................................................................................... 3–87
3–19. Source Listing of the Load Data for SCHOOL Table
(QUAL*SCHLOAD) .................................................................................................... 3–87
3–20. Source Listing of the Load Data for CHILD Table (QUAL*CHILDLOAD) ......... 3–88
3–21. Runstream to Define Storage Areas and Tables and Load Tables .................. 3–89
3–22. Execution of Source Runstream—RDMS Database Setup ................................ 3–91
3–23. Coding RDMCA and SQLSTATE Variables for UCS COBOL ............................... 3–98
3–24. Source Listing of the Embedded SQL Program
(QUAL*UCSTST.DISPLAYFAM/ESQL) ................................................................3–122
3–25. Runstream to Compile, Link, and Execute COBOL Embedded SQL
Program .....................................................................................................................3–127
3–26. Source Listing of the Embedded SQL Program
(QUAL*UCSTST.DISPLAYFAM/ESQL) ............................................................... 3–128
3–27. Source Listing of Embedded SQL Program (CDSPFAMESQL) ........................ 3–130
3–28. Source Listing of Runstream—CDSPFAMESQL ................................................. 3–134
3–29. Execution of Source Runstream—CDSPFAMESQL ........................................... 3–135
3–30. Source Listing of FORTRAN Module Language Program ................................. 3–136
3–31. Source Listing of the FORTRAN Host Language Application Program......... 3–138
3–32. Source Listing of Runstream—DISPLAYFAM/MSQL-FMOD and
DISPLAYFAM/MSQL-FHOST ............................................................................... 3–142

7831 4077–009 xix

Examples

3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-FMOD and

DISPLAYFAM/MSQL-FHOSTE ............................................................................. 3–143
3–34. Source Listing of the Interpreted SQL Program
(QUAL*UCSTST.DISPLAYFAM/ISQL) ................................................................. 3–149
3–35. Runstream to Compile, Link, and Execute COBOL Interpreter SQL
Program .................................................................................................................... 3–154
3–36. Execution of Source Runstream—COBOL Interpreted SQL Program .......... 3–155
3–37. Runstream to Define the SFS 2200 File and Storage Area .............................. 3–160
3–38. Execution of Source Runstream—SFS Database Setup ................................... 3–161
3–39. Source Listing of the Program (QUAL*UCSTST.DISPLAYSPT) ........................ 3–170
3–40. Runstream to Compile, Link, and Execute—COBOL SFS Program ................3–173
3–41. Execution of Source Runstream—COBOL SFS Program ..................................3–175
3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL) ........................ 3–180
3–43. Runstream to Compile, Link, and Execute—COBOL DMS/ESQL/SFS
Program .................................................................................................................... 3–187
3–44. Execution of Source Runstream—COBOL DMS/ESQL/SFS Program ........... 3–188
3–45. Listing of Example FORMGEN Form ...................................................................... 3–194
3–46. Example of FORMGEN COBOL Working Storage .............................................. 3–200
3–47. Example of FORMGEN C Structure ........................................................................ 3–203
3–48. Source Listing of DPS Program (QUAL*UCSTST.DPSDSPLY) ..........................3–217
3–49. Runstream to Compile COBOL DPS Program ..................................................... 3–220
3–50. Execution of Compilation Source Runstream—COBOL DPS Program ..........3–221
3–51. Source Listing of Runstream to Compile and Static Link— COBOL
DPS Program ........................................................................................................... 3–223
3–52. Execution of Source Runstream to Compile and Static Link—COBOL
DPS Program ........................................................................................................... 3–224
3–53. Source Listing of DPS 2200 C Program ................................................................. 3–227
3–54. Source Listing to Compile—CDPSDSPLY ............................................................. 3–230
3–55. Execution of Source Runstream—CDPSDSPLY ..................................................3–231
3–56. Source Listing of the Program (DPSDSPLYALL).................................................. 3–235
3–57. Runstream to Compile and Static Link—COBOL DPS/DMS/ESQL/SFS
Program .................................................................................................................... 3–244
3–58. Execution of Source Runstream to Compile and Static Link—COBOL
DPS/DMS/ESQL/SFS Program............................................................................. 3–245

4–1. LSCs in SYS$*DATA$.SSDEF$ That Define Software in an Application

Group ............................................................................................................................. 4–9
4–2. LSCs in SYS$*DATA$.SSDEF$ That Define the Active Application
Group ............................................................................................................................4–10
4–3. LSC in SYS$LIB$*APP$7.SSDEF$ ............................................................................... 4–12

5–1. Generic Static Linking Runstream for a TIP Transaction Program .................... 5–15
5–2. Source Listing of the Transaction (QUAL*UCSTST.DPSTIP) ............................... 5–18
5–3. Runstream to Set Up, Compile, and Link COBOL DPS TIP Transaction
Program ....................................................................................................................... 5–21
5–4. Execution of Source Runstream—COBOL DPS TIP Transaction
Program ...................................................................................................................... 5–24
5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP) ............................. 5–30
5–6. Partial Source Listing of MCBPKT-UCOB Routine
(QUAL*UCSTST.MCBPKT-UCOB) ......................................................................... 5–38
5–7. Runstream to Set Up, Compile, and Link—COBOL MCB TIP
Transaction Program ................................................................................................5–41

xx 7831 4077–009
 Examples

5–8. Execution of Source Runstream—COBOL MCB TIP Transaction

Program ...................................................................................................................... 5–43
5–9. Source Listing of the Schema (QUAL*UCSTST.PERSONNELTIP) ..................... 5–57
5–10. Source Listing of the Subschema (QUAL*UCSTST.PERSONSUBTIP) .............. 5–60
5–11. Runstream to Process Schema and Subschema ................................................... 5–61
5–12. Execution of Source Runstream—DMS Database Setup .................................. 5–65
5–13. Source Listing of DML Transaction Program
(QUAL*UCSTST.DPSDMS) ..................................................................................... 5–79
5–14. Runstream to Compile, Link, and Execute—COBOL DPS DMS
Transaction Program ............................................................................................... 5–85
5–15. Execution of Source Runstream—COBOL DPS DMS Transaction
Program ...................................................................................................................... 5–88
5–16. Source Listing of the Table Definitions (QUAL*UCSTST.TIPTABLES) ............. 5–98
5–17. Source Listing of the Load Data for INDIVIDUALR Table
(QUAL*INDLOAD.) .................................................................................................... 5–99
5–18. Source Listing of the Load Data for SCHOOL Table
(QUAL*SCHLOAD.)................................................................................................. 5–100
5–19. Source Listing of the Load Data for CHILD Table
(QUAL*CHILDLOAD.) .............................................................................................. 5–101
5–20. Runstream to Define Storage Areas and Tables and Load Tables .................5–102
5–21. Execution of Source Runstream—RDMS Database Setup ............................. 5–106
5–22. Source Listing of the Embedded SQL Transaction Program
(QUAL*UCSTST.MCBESQ/RDMS) ....................................................................... 5–121
5–23. Runstream to Compile, Link, and Execute—COBOL MCB ESQL
Transaction Program ..............................................................................................5–132
5–24. Execution of Source Runstream—COBOL MCB ESQL Transaction
Program .................................................................................................................... 5–134
5–25. Source Listing of the Embedded SQL Transaction Program (DPSESQ)........ 5–140
5–26. Runstream to Set Up Transaction Program DPSESQ ........................................ 5–147
5–27. Execution of Source Runstream—COBOL DPSESQ Transaction
Program .................................................................................................................... 5–148
5–28. Runstream to Define the SFS 2200 File and Storage Area ...............................5–157
5–29. Execution of Source Runstream—SFS Database Setup .................................. 5–159
5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS) ................................. 5–167
5–31. Runstream to Compile, Link, and Execute—COBOL DPS SFS
Transaction Program ..............................................................................................5–173
5–32. Execution of Source Runstream—COBOL DPS SFS Transaction
Program .................................................................................................................... 5–176
5–33. Source Listing of the Program (DPSALL) .............................................................. 5–185
5–34. Runstream to Compile and Static Link—COBOL DPS DMS/ESQL/SFS
Transaction Program ............................................................................................. 5–195
5–35. Execution of Source Runstream to Compile and Static Link—COBOL
DPS DMS/ESQL/SFS Transaction Program...................................................... 5–198

6–1. Source Code to Create HVCALLS Object Module (HV$CALL) ........................... 6–23
6–2. Source Code to Create HVCALLS Object Module (HV$XFR$CANCL) ............. 6–26
6–3. Generic Static Linking Runstream for an HVTIP ICP ............................................ 6–34
6–4. Generic Static Linking Runstream for an HVTIP Subprogram ........................... 6–38
6–5. Source Listing of the ICP (QUAL*UCSTST.DPSICP) .............................................. 6–43
6–6. Source Listing of the ICP HVCALLS Element
(QUAL*UCSTST.HVCALLSDEF/DPSSUBX) ......................................................... 6–43
6–7. Source Listing of the First Subprogram (QUAL*UCSTST.DPSSUBX)............... 6–44

7831 4077–009 xxi

Examples

6–8. Source Listing of the HVCALLS Element for First Subprogram

(QUAL*UCSTST.HVCALLSDEF/DPSSUBY) ......................................................... 6–46
6–9. Source Listing of the Second Subprogram
(QUAL*UCSTST.DPSSUBY) .................................................................................... 6–47
6–10. Runstream to Set Up, Compile, and Link—COBOL DPS HVTIP
Transaction Sequence............................................................................................. 6–48
6–11. Execution of Source Runstream—COBOL DPS HVTIP Transaction
Sequence .................................................................................................................... 6–53
6–12. Source Listing of the ICP (QUAL*UCSTST.MCBICP) ............................................. 6–61
6–13. Partial Source Listing of MCBPKT-UCOB Routine
(QUAL*UCSTST.MCBPKT-UCOB) ......................................................................... 6–63
6–14. Source Listing of the ICP HVCALLS Element
(QUAL*UCSTST.HVCALLSDEF/MCBSUBX) ........................................................ 6–65
6–15. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBX) .................... 6–66
6–16. Source Listing of the HVCALLS Element for First Subprogram
(QUAL*UCSTST.HVCALLSDEF/MCBSUBY) ........................................................ 6–68
6–17. Source Listing of the Second Subprogram
(QUAL*UCSTST.MCBSUBY)................................................................................... 6–69
6–18. Runstream to Set Up, Compile, and Link—COBOL MCB HVTIP
Transaction Sequence............................................................................................. 6–70
6–19. Execution of Source Runstream—COBOL MCB HVTIP Transaction
Sequence .................................................................................................................... 6–74
6–20. MASM Jump Vector Routine to Define Multiple Entry Points .......................... 6–87
6–21. Creating the HVCALLS Element for the Calling Program .................................... 6–89
6–22. Source Listing of the ICP (QUAL*UCSTST.MCBICP/MULTEP) ............................ 6–91
6–23. Source Listing of the ICP HVCALLS Element
(QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA) ............................................. 6–93
6–24. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA) .................... 6–94
6–25. Source Listing of the MASM Jump Vector Routine
(QUAL*UCSTST.JUMPVECTOR/MCBSUBA) ...................................................... 6–96
6–26. Source Listing of the Second Subprogram
(QUAL*UCSTST.MCBSUBX/NOCALLS) ............................................................... 6–97
6–27. Runstream to Set Up, Compile, and Link—COBOL MCB HVTIP
Transaction Program Sequence Using Multiple Entry Points ....................... 6–98
6–28. Execution of Source Runstream—COBOL MCB HVTIP Transaction
Sequence Using Multiple Entry Points ............................................................. 6–105
6–29. Simple Mixed-Mode Example................................................................................... 6–119
6–30. Mixed-Mode Example 2 ............................................................................................ 6–124
6–31. MIXEDMODESKL, and Creating the AFCB and FGSS ......................................... 6–132
6–32. Creating the ACOB HVTIP Absolutes ...................................................................... 6–141
6–33. Creating the UCOB HVTIP ZOOMs ......................................................................... 6–148
6–34. Installing the HVTIP ZOOMs and Absolutes ......................................................... 6–164
6–35. BMICP Output .............................................................................................................. 6–169
6–36. JMHHVT Output .......................................................................................................... 6–170
6–37. JMHEP1 Output............................................................................................................. 6–171
6–38. JMHEP2 Output ........................................................................................................... 6–174
6–39. JMHEP3 Output ........................................................................................................... 6–176
6–40. Output of DPS HELPER Processor ......................................................................... 6–197

7–1. Listing of SYS$LIB$*LINK.LSI-RES-NAME .................................................................7–6

7–2. Source Listing of Main Program (QUAL*UCSTST.PROGRAM1) ......................... 7–17

xxii 7831 4077–009

 Examples

7–3. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/STANDARD) ................................................... 7–19
7–4. Source Listing of First Subprogram (QUAL*UCSTST.SUBPRGA) ...................... 7–21
7–5. Source Listing of Second Subprogram (QUAL*UCSTST.SUBPRGB).................7–22
7–6. Runstream to Set Up, Compile, Link and Execute—COBOL Standard
ZOOM .......................................................................................................................... 7–23
7–7. Execution of Source Runstream—COBOL Standard ZOOM ............................. 7–25
7–8. Source Listing of Main Program (QUAL*UCSTST.PRGRM1) .............................. 7–29
7–9. Partial Source Listing of Edited LSI$RES-NAME Element
(QUAL*UCSTST.LSI$RES-NAME/TIP) ................................................................... 7–31
7–10. Source Listing of First Subprogram (QUAL*UCSTST.SUBPRGC)...................... 7–33
7–11. Source Listing of Second Subprogram (QUAL*UCSTST.SUBPRGD) ............... 7–34
7–12. Runstream to Set Up, Compile, and Link—COBOL TIP ZOOM ......................... 7–35
7–13. Execution of Source Runstream—COBOL TIP ZOOM ........................................ 7–38
7–14. Source Listing of ICP (QUAL*UCSTST.MCBICP/CALLID) .................................... 7–43
7–15. Partial Source Listing of MCBPKT-UCOB ................................................................ 7–45
7–16. Source Listing of ICP HVCALLS Element
(QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA) ............................................. 7–49
7–17. Partial Source Listing of Edited LSI$RES-NAME Element
(QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP) ................................................... 7–50
7–18. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA) .................... 7–52
7–19. Source Listing of Jump Vector Element for Subprogram MCBSUBA
(QUAL*UCSTST.JUMPVECTOR/MCBSUBA) ...................................................... 7–54
7–20. Source Listing of Second Subprogram
(QUAL*UCSTST.MCBSUBX/NOCALLS) ............................................................... 7–55
7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM ................... 7–57
7–22. Execution of Source Runstream—COBOL HVTIP ZOOM .................................. 7–63

7831 4077–009 xxiii

Examples

xxiv 7831 4077–009

Section 1
UCS Application Programming
Overview

The Universal Compiling System (UCS) is a foundation for applications development

that enables application development using extended mode.

1.1. Document Updates

This document contains all the information that was available at the time of
publication. Changes identified after release of this document are included in problem
list entry (PLE) 18893924. To obtain a copy of the PLE, contact your Unisys
representative or access the current PLE from the Unisys Product Support Web site:

http://www.support.unisys.com/all/ple/18893924

Note: If you are not logged into the Product Support site, you will be asked to
do so.

1.2. About This Guide

Purpose
This guide is a starting point for the applications programmer who is new to the
Universal Compiling System (UCS). This guide has the following main purposes:
• Introduces UCS. This guide describes the steps involved in developing and
executing UCS programs. It identifies and describes the software used for each
step.
• Describes how to code and create UCS programs. This guide provides specific
instructions, guidelines, and examples for writing applications programs for
execution in batch and demand, Transaction Processing (TIP), and High-Volume
Transaction Processing (HVTIP) environments. Coding examples aid the
applications programmer in understanding how to turn a design specification into
a working program or transaction.
• Describes how to plan for upgrading to UCS. This guide discusses developing new
programs in UCS, how UCS and non-UCS programs coexist on a system by sharing
Unisys software and files, and how to upgrade non-UCS programs to UCS.

7831 4077–009 1–1

UCS Application Programming Overview

• Describes how to set up the required UCS environment. This guide describes
installation and generation requirements for UCS products, supporting products,
and interface products.
• Describes how to get more in-depth information on specific topics.

Scope
Early sections give a general conceptual overview of UCS. Later sections give specific
instructions and guidelines for writing programs and include actual detailed program
examples and the output they produce.

This guide is intended to give enough detailed programming instructions and

guidelines concerning UCS so that a programmer can in many cases use it to create,
compile, link, and execute programs, without necessarily having to reference other
UCS documentation.

For more detailed information about a specific UCS product, refer to the
documentation for that product.

However, this guide does not attempt to be an introduction to all aspects of

application development (for example, how to set up a transaction, design a Universal
Data System database, handle messages, or use the Display Processing System).
Although examples of such activities are shown, the reader must consult the
appropriate documentation for complete instructions on how to perform these
activities. This guide merely discusses these activities in relation to UCS programming.

The UCS Conceptual Overview introduces UCS. It describes UCS software

components and discusses how they are used to develop user applications in high-
level programming languages. It is intended for data processing managers and
potential UCS users.

The UCS Evaluation Overview describes the features of UCS and supporting software
products. This overview includes features of the UCS languages, the Linking System,
and PADS. This overview is for programmers, analysts, managers, or consultants who
are evaluating UCS capabilities and features.

Audience
The primary audience for this guide is the applications programmer or systems analyst
who actually writes, compiles, executes, and debugs programs. The secondary
audience is the site administrator. Site administrators will find information on the
following topics useful:
• Library search chains
• Subsystems
• Planning new and existing applications
• Setting up the environment

Programming managers will generally not require the detail in this document. The UCS
Conceptual Overview is designed for programming managers.

1–2 7831 4077–009

 UCS Application Programming Overview

Prerequisites
This guide assumes the reader has at least a basic familiarity with OS 2200 systems
and their job control language. Knowledge of one or more programming languages is
also assumed.

You need not have specific knowledge of UCS to use this guide. This guide is intended
to give enough detailed programming instructions and guidelines concerning UCS so
that a programmer can in many cases use it to create, compile, link, and execute
programs, without necessarily having prior instruction in UCS and without having to
reference other UCS documentation. For more detailed information about a specific
UCS product, refer to the documentation for that product.

Notation Conventions
The following conventions are used in this guide:
• Highlighting (bold copy) represents important lines of programming in examples
and illustrations and user input in a user/system dialog
• Italics represent a variable value
• UPPERCASE letters represent a literal value
• Changes made since the last version of the manual are shown with yellow
highlighting in the online version (and may appear as shading in the printed
version).
How to Use This Guide
Programmers should use Sections 3, 5, 6, and 7 as a model for coding UCS programs.
Sections are organized according to the different execution environments: batch and
demand, TIP, and HVTIP. Examples have been set up to be as realistic as possible.
Complete programs are shown, along with runstreams that set up, compile, link, and
execute them. The actual output from these programs is also illustrated.

Note the following about the organization of this guide:

• This guide is organized so that you learn the most basic information quickly. For
example, batch and demand programming is discussed with a minimum of
introductory sections, allowing programmers to become productive in a UCS
environment as quickly as possible.
• Later sections build upon the information presented in earlier sections. For
example, you must understand the information on batch and demand
programming before reading the information on TIP or HVTIP programming.

7831 4077–009 1–3

UCS Application Programming Overview

1.3. Extended Mode

In the 1990s, the development of user applications became more solution-oriented.
The decision-making support software involved in this process is a critical business
tool.

To meet this need, Unisys has provided a new foundation of advanced hardware and
software with OS 2200 extended mode systems:
• The hardware architecture for this foundation was introduced with the 1100/90 and
2200 systems and continues today as the 2200 ClearPath systems.
• The software platform that takes advantage of the capabilities of this architecture
consists of
− The extended mode operating system
− The Universal Compiling System (UCS), which consists of the high-level
language compilers and their supporting software

This software platform can be used

• Directly, by coding user-written application programs
• Indirectly, by using CASE tools provided by Unisys, such as LINC II

User-Written
CASE Tools
Applications

Universal Compiling System

Extended Mode Operating System

Extended Mode Hardware

1–4 7831 4077–009

 UCS Application Programming Overview

This hardware/software foundation provides the most powerful solution-oriented

working environment available on OS 2200 systems today, and is the hub of all new
software developed for these and future systems.

This new environment does not prohibit use of the existing basic mode environment.
The two environments coexist peacefully, sharing both software and files. Interfaces
are provided from the new software to
• UDS database products and files
• Transaction files
• Transaction handling software

Very little has changed for the applications programmer. Instead, UCS provides
extended capabilities beyond what existed previously. UCS provides an efficient
application development environment, thus increasing programmer productivity and
more effectively meeting the needs of users.

The following table summarizes the benefits provided by the extended mode
hardware and its extended mode software platform. UCS currently provides these
high-level programming languages: UCS COBOL, UCS FORTRAN, and UCS C.

Product Name Supported Standard

UCS COBOL ANSI COBOL X3.23-1985 with Intrinsic Function

Addendum X3.23-A-1989
UCS FORTRAN ANSI FORTRAN X3.9-1978 with FORTRAN 90
Extensions
UCS C ANSI C X3.159-1989
ISO/IEC - 9899-1990

7831 4077–009 1–5

UCS Application Programming Overview

• UCS COBOL
Supports the COBOL 1985 American National Standard with the 1989 Intrinsic
Function Addendum.
• UCS FORTRAN
Supports the FORTRAN 1978 American National Standard. Also has implemented
many extensions of the Fortran 90 standard.
• UCS C
Supports the X3.159-1989 American National Standard and the ISD/IEC 9899-1990
standard. SB5R1 UCS C was the first release to validate against these standards.

In addition to providing a variety of programming languages, UCS also offers

standardized communication between the languages. Each language has implemented
a standard calling sequence that makes it easy to transfer between programs written
in different languages. This capability provides the flexibility to use the most
appropriate language for each programming task.

Each language makes use of extended mode addressing capabilities, without the
programmer’s intervention. Everything is done automatically. Also, each language
executes a call to the operating system whenever possible, instead of a costly system
interrupt. The number of implemented calls is growing with each release of the
extended mode operating system.

These languages have a broad base of product interfaces from which to choose. The
commands used by these product interfaces have embedded syntax that the UCS
compilers accept without any preprocessing.

1–6 7831 4077–009

 UCS Application Programming Overview

1.4. Compiling UCS Programs

Each of the high-level languages is processed by its own compiler, using the following
compiler call statements. (Note that the “U” in each compiler call name refers to the
Universal Compiling System.)
• UCS COBOL: @UCOB
• UCS FORTRAN: @UFTN
• UCS C: @UC
UCS compilers are actually composed of two separate products:
• The language-specific front-end processor
• The common back-end processor

The front-end processors are identified by the following product designators at

installation time: UCOB, UFTN, UC.

7831 4077–009 1–7

UCS Application Programming Overview

Front-End Processors

Compiler
Products Programming
Language Front-End LSS Code
UCS C (UC) Source Processor Generator

UCS COBOL (UCOB)

USC FORTRAN (UFTN)

Characteristics
Perform front-end processing

Provide architecture independence

Perform all syntax analysis

Produce intermediate code and a data dictionary

002314

These front-end processors are architecture independent. This means their output is
not limited to a particular hardware system in the 2200 ClearPath family. The front-end
processors perform syntax analysis that is dependent on the structures of the
particular high-level language being analyzed. They produce intermediate code, static
flags, tables, and a data dictionary that are independent of the language being
analyzed.

1–8 7831 4077–009

 UCS Application Programming Overview

The output of the front-end processor is passed to a back-end processor, the UCS
Language Support System (LSS), for transformation into architecture-specific output:

LSS is another product in the Universal Compiling System. LSS is the part of the
compiler that generates the code. It is a single back-end processor used in common
by all of the front-end processors. It is architecture dependent, meaning that it
generates hardware level instructions that may be limited to one or more particular
hardware systems. The programmer is unaware of the existence of LSS because it is
called internally during compilation.

LSS also does the following:

• Produces all listings requested on the compiler call
• Generates a symbolic debugging dictionary used during interactive debugging (if
requested through compiler options)

7831 4077–009 1–9

UCS Application Programming Overview

Figure 1–1 illustrates the UCS compilation process:

Architecture Independent Architecture Dependent

Intermediate
Output
Dictionary
Source LSS
Front-End Object
Program Text Code Generator
Processor Module
and Optimizer
Static Flags
COBOL UCOB
and Tables
FORTRAN UFTN
C UC

002321A

Figure 1–1. UCS Compilation Process

1–10 7831 4077–009

 UCS Application Programming Overview

1.4.1. Compilation Output in the Object Module

The output produced by the UCS compilation process is an absolute element with a
new subtype. It is called an object module.

An object module has properties that are similar to both a basic mode relocatable and
a basic mode absolute element. It contains symbolic references and relative
addresses like a relocatable element, but is directly executable like an absolute
element.

In addition to the front-end processor and LSS, the Linking System Object Module
Output Routines (see 1.4.2) are also involved in the creation of object modules. In
some circumstances, the following products may also be involved:
• The UCS Runtime System (see 1.4.3)
• The Extended Language Message System (see A.3.5)
• S$WORK element created by processing the DMS 2200 subschema source using
the Subschema Data Definition Language (SDDL) processor

For more information on object modules, including descriptions of different types of

object modules, refer to “LINK Processor (@LINK)” in 1.4.2.

7831 4077–009 1–11

UCS Application Programming Overview

1.4.2. Linking UCS Programs with the Linking System

Once an object module has been created, it may need to be linked to other object
modules. (Linking was referred to as collection for previous 1100 and 2200 system
software, and is also known in the industry as binding.) UCS programs are linked by
the Linking System. Many new linking features and capabilities are introduced with
UCS.

Linking System

Characteristics
Unites separately-compiled object modules into a new object module or whole
executing program

Loads modules at execution time

Aids LSS in producing object module output

Defines secure units of shared code and data (extended mode software
subsystems)

Automates multibanking

Components
Dynamic Linker

LINK Processor (@LINK)

Object Module Output Routines (OMOR)

Subsystem Definition Processor (@SSDP)

Subsystem Information Processor (@SSINFO)

Object Module Cross-Reference Utility (@OMCR)

The Linking System offers a more flexible method of linking programs and resolving
references for execution. You do not have to prepare UCS programs before
execution with the Collector (@MAP). Instead, the Linking System links separately
compiled UCS object modules into a single program either at load time, dynamically
during execution, or (optionally) before execution in a process similar to collection.
The same program can even use all three types of linking.

1–12 7831 4077–009

 UCS Application Programming Overview

The Linking System

• Unites separately compiled object modules into a new object module or “whole
executing program”
• Loads object modules at execution time
• Aids the LSS code generator by producing the object module output during
compilation
• Automatically handles multibanking. Programmers no longer have to specify
complicated banking statements to create multibanked programs (however, the
programmer still has control over the bank structures if desired)
• Automatically uses the expanded addressing space of extended mode hardware
• Provides a method for defining secure units of software code and data

The Linking System is actually made up of five distinct components:

• The Object Module Output Routines (OMOR)
• The dynamic linker
• The LINK Processor (@LINK)
• The Subsystem Definition Processor (@SSDP)
• The Subsystem Information Processor (@SSINFO)

The following subsections briefly explore these components and their capabilities.

It is worthwhile for a site to learn the concepts of the Linking System and how it
works, in order to choose the type of linking most suited to the task at hand. Sections
3, 5, and 6 provide sample links for batch/demand, TIP, and HVTIP environments. For
complete information, see the following documents:
• Linking System Programming Guide
• Linking System Programming Reference Manual
• Linking System Subsystems Programming Guide

7831 4077–009 1–13

UCS Application Programming Overview

1.4.2.1. Object Module Output Routines (OMOR)

The LSS code generator calls OMOR during compilation to produce the object module
output.

This means that when the programmer issues a compiler call, three software products
are actually involved in the creation of the object module:
• The front-end processor
• LSS
• The Linking System Object Module Output Routines

1–14 7831 4077–009

 UCS Application Programming Overview

1.4.2.2. Dynamic Linker

The linking process used by UCS has greater flexibility and capabilities than previous
linking methods.

The most noticeable added capability is a linking method specifically intended for the
program development phase. Programs do not require a separate linking phase
(formerly referred to as collection). When you execute (@XQT) an object module
produced by a UCS compiler, references within the object module to other object
modules are automatically resolved during execution. This process is performed by
the dynamic linker.

A comparison can be made between the older style “separate-collection-required”

method and this new “compile-and-try-it” method. Before UCS, code was
1. Written
2. Compiled
3. Collected
4. Executed

If an error was found in execution, the code was corrected and the process repeated,
as shown in the following figure:

With UCS, there is a short cut that eliminates the collection phase. UCS supports the
“compile-and-try-it” method, thus removing the programmer-invoked collection step
and shortening development time. UCS code can be
1. Written

7831 4077–009 1–15

UCS Application Programming Overview

2. Compiled
3. Executed

The dynamic linker links the program during execution, as shown in the following
figure:

This process is most useful during debugging and program development for the
following reason: After each recompilation, the programmer does not have to
perform a separate linking step before each new test execution.

Programmer-invoked linking (called static linking) still results in the best execution-
time performance because execution is not interrupted while linking occurs. Static
linking is therefore most efficient for production environments. Static linking also
means linking overhead is incurred only once, rather than each time the program is
executed. Furthermore, static linking is required for all transactions, whether they are
in the development or production phase.

1–16 7831 4077–009

 UCS Application Programming Overview

The following sequence occurs when a compiler-generated object module is executed

without being linked beforehand:
1. The dynamic linker loads the executed object module (@XQT), acquiring needed
main storage banks in the process.
2. During execution, an unresolved reference to another object module may be
encountered. This event triggers what is known as a link fault.
3. The link fault causes the operating system to call the dynamic linker to resolve the
reference.
4. The dynamic linker locates and loads the called object module.
5. The operating system is informed that the instruction that caused the link fault
should be re-executed.
6. Program execution resumes

This method of linking provides development flexibility. The modules of a program are
brought together only as they are needed.

7831 4077–009 1–17

UCS Application Programming Overview

1.4.2.3. LINK Processor (@LINK)

For the production environment, a parallel to the collection phase exists: static linking.
The LINK Processor (also known as the static linker) performs static linking.

Static linking can resolve some or all of a program’s external references before
execution:
• It can produce totally resolved object modules. These are efficient for programs
in a production environment because linking does not interrupt execution.
• It can produce partially resolved object modules. These are useful for programs
still in development:
− References to tested, stable object modules can be resolved during static
linking. This improves performance for that part of the program.
− References to untested, unstable object modules can be resolved during
execution. The “collection” step is not required for these parts of the
program.

The LINK Processor is called using the @LINK statement. The LINK Processor has a
simple command language for performing static linking.

1–18 7831 4077–009

 UCS Application Programming Overview

Static linking can produce one of three types of object modules:

• Standard object modules (OM)
• Bound object modules (BOM)
• Zero overhead object modules (ZOOM)

Standard Object Modules (OM)

The first type of object module produced by static linking is a standard object module.
Standard object modules produced by static linking are similar to object modules
produced by compilation. Standard object modules (also known merely as object
modules) are mainly used during application development.

7831 4077–009 1–19

UCS Application Programming Overview

In the following figure, the LINK Processor links together the object modules produced
by two separate compilations to produce a standard object module.

Standard object modules normally contain unresolved references; at execution time,

the dynamic linker is called when required for further resolution. Therefore, standard
object modules are normally produced only when the program is still in the
development phase.

Standard object modules are loaded by the Linking System at execution time. Note
that standard object modules may themselves serve as input to other static links; that
is, they may be statically linked to other object modules.

1–20 7831 4077–009

 UCS Application Programming Overview

Bound Object Modules (BOM)

The second type of object module produced by static linking is a bound object module
(sometimes referred to as a BOM). Bound object modules have some references
resolved and others unresolved. They are similar to standard object modules except
that the main program must be included during the static link.

Bound Object Modules (BOM)

Characteristics
Are partially-resolved object Compiler Executable
@LINK
modules that include their Output Code
main programs

Are loaded by the Linking System

Are most useful during application development

Allow stable, tested object modules to be bound together

Can be dynamically linked to object modules still being developed

002294

Bound object modules can be used during the development phase to link together
stable object modules. References to object modules still in development are
resolved by the dynamic linker during execution, just as for standard object modules;
however, bound object modules have better performance than standard object
modules.

7831 4077–009 1–21

UCS Application Programming Overview

In the following figure, the LINK Processor links together the object modules produced
by three separate compilations to produce a bound object module. The bound object
module is then executed; references to other object modules are resolved during
execution.

Bound object modules are loaded by the Linking System at execution time. Note that
bound object modules cannot serve as input to other static links.

1–22 7831 4077–009

 UCS Application Programming Overview

Zero Overhead Object Modules (ZOOM)

The last type of object module produced by static linking is the zero overhead object
module (ZOOM). ZOOMs are totally resolved object modules. They are loaded by the
extended mode operating system, not the dynamic linker. They cannot call upon the
dynamic linker for reference resolution. ZOOMs are performance-oriented and are
recommended for all production environment programs. Transactions must always be
ZOOMs.

7831 4077–009 1–23

UCS Application Programming Overview

In the following figure, the LINK Processor links together the object modules produced
by two separate compilations to produce a ZOOM. The ZOOM is then executed.

1–24 7831 4077–009

 UCS Application Programming Overview

1.4.2.4. The Subsystem Definition Processor (@SSDP)

The next component of the Linking System is the Subsystem Definition Processor
(@SSDP).

The Subsystem Definition Processor performs the following main functions:

• It provides a method for defining code and data access restrictions in order to
provide security, through extended mode software subsystems. Subsystems
provide shared banks, known in non-UCS programming as common banks.
Subsystem definition work is usually performed by the site administrator, not the
applications programmer.
• It defines the library search chains that identify which files are to be searched
when the Linking System resolves references (during both static and dynamic
linking). These library search chains specify the files available to an extended
mode software subsystem:
− Default library search chains are created as part of the installation of the
Linking System and placed in the element SYS$*DATA$.SSDEF$. This element
reflects the Unisys system software installed on that system.
− Users can optionally control resolution of references by using the Subsystem
Definition Processor to define their own library search chains. These library
search chains can be used to resolve references not covered by default library
search chains.

1.4.2.5. The Subsystem Information Processor

This is a linker processor that provides information about subsystems and AFCBs. Call
the help screens by doing an @SSINFO,HP.

SSINFO is meant to be used in demand, and is a window into the state of the fixed-
gate subsystems on your system.

7831 4077–009 1–25

UCS Application Programming Overview

1.4.3. Supporting Program Execution with the UCS Runtime

System
The last step in program development is to execute the program or transaction.
Execution of a UCS program or transaction implicitly calls the UCS Runtime System.
(The UCS Runtime System is sometimes identified by the name URTS.)

UCS Runtime System

Characteristics trancd

Provides common interfaces and services

UCS Transaction
Provides execution-time interfaces to the Environment
Runtime
operating system System

Performs program initialization Executable

and termination @XQT
Code

Handles standard input/output

and database interfaces Demand
Environment
Supplies data conversion routines

Supplies built-in math functions

Batch
Provides a service library Environment

002293

The UCS Runtime System provides common interfaces and services to all UCS
programs. These include
• Interfaces to the UDS products
• Input/output interfaces
• Data conversion routines
• Built-in math functions
• Service libraries

The UCS Runtime System also performs program initialization and termination.

Previous compilers each had their own run-time system. In UCS, the similar tasks
performed by the multiple run-time systems have been combined into a single run-
time system used by all executing programs.

1–26 7831 4077–009

 UCS Application Programming Overview

1.4.4. Debugging UCS Programs with PADS

The Programmers Advanced Debugging System (PADS) provides an interactive,
execution-time command language that controls program execution. PADS allows
interaction with an executing program at programmer-selected points or at the point
of detection of an exception condition. PADS can serve as an extremely useful
testing and debugging tool.

By compiling with the appropriate compiler keyword options, DEBUG/FULL and

NO-OPTIM, the applications programmer can debug at a symbolic level without having
to know the low-level peculiarities of the architecture. (For information on keyword
options, see Section 2.)

PADS allows the programmer to

• Trace the logic flow of the program
• Set traps for certain conditions within the code
• Display any aspects of the program state at trap points
• Display and change the contents of data items
• Reference positions within the code, using symbolic names, labels, and line
numbers within the program

References to program entities, such as statement labels, procedure names, or

variables, generally take the same form as in the language used to code the program.
PADS requires no debugging statements in the program source and supports all UCS
high-level languages.

For details on using PADS, see the PADS Programming Guide.

7831 4077–009 1–27

UCS Application Programming Overview

1.4.5. Debugging UCS Programs with MONITOR

The UCS MONITOR feature provides a program execution-time interface for
debugging. MONITOR is available in UCS COBOL, UCS FORTRAN, and UCS C.

UCS MONITOR is enabled by the following compiler keyword options:

• MONITOR
Displays entries when
− Paragraph or section names change (COBOL), or statement labels or numbers
are encountered (C or FORTRAN).
− Data items are referenced.
• MONITOR/LABEL
− Displays entries when a paragraph or section name changes (COBOL), or
statement labels or numbers are encountered (C or FORTRAN).

The MONITOR feature can be dynamically controlled using the explicitly defined
MCFLAG data item.

Monitor

Characteristics
1 dataname-1 PIC
Produces a program execution-time trace 01 dataname-2 PIC
PROCEDURE DIVISIO
label1
Displays entries when: MOVE ALL 'y' T
label2.
paragraph or section name changes ADD dataname2
data item is referenced DIVIDE datana

Enabled by compiler keyword option

Dynamically controlled

1–28 7831 4077–009

 UCS Application Programming Overview

1.4.6. UCS Application Development Summary

Figure 1–2 shows a review of the application development process for UCS programs.

trancd

Transaction
Environment
Dynamic Linker

@XQT
Programming
Language Static Linking Executable
Compiler Output
Source Process Code

UCS COBOL @UCOB LSS Code Object @LINK Object Demand

UCS FORTRAN @UFTN Generator Module Module Environment
UCS C @UC OMOR
Bound
OM
ZOOM
Batch
Environment
UCS
Runtime
System
002322

Figure 1–2. Application Development for UCS Programs

The elements in Figure 1–2 are as follows:

• The UCS high-level languages are UCS COBOL, UCS FORTRAN, and UCS C,.
• Compilation is a two-stage process involving first the language-dependent front-
end processor and then the architecture-dependent back-end processor, the
Language Support System (LSS). For the other languages, the front-end step is
done on the 2200. The LSS portion is always on the 2200.
• The Linking System Object Module Output Routines (OMOR) also assist in
compilation.
• The output of the compilation is an object module. This object module is directly
executable, with no explicit linking phase (unless it is to be a transaction). This
capability is most useful during the program development phase.
• When standard object modules are executed, the Linking System dynamic linker
acquires needed main storage banks, loads the object module, and resolves any
references to other object modules during execution.
• Execution of an unresolved reference to another object module triggers an event
known as a link fault; when this occurs, the operating system calls the dynamic
linker to find and load the called object module.

7831 4077–009 1–29

UCS Application Programming Overview

• If static linking is required, the programmer calls the LINK Processor (@LINK) and
supplies simple commands specifying which object modules should be linked and
the type of object module to be produced.
There are three types of object modules produced by static linking:
− Standard object modules (OM)
− Bound object modules (BOM)
− Zero overhead object modules (ZOOM)
Standard object modules and bound object modules are primarily useful during the
program development phase. Standard object modules and bound object modules
use the dynamic linker for
− Bank acquisition and loading at execution time
− Reference resolution if a link fault occurs during execution
ZOOMs are efficient, totally resolved object modules. They provide very fast
execution and are meant for production environments. They are loaded by the
extended mode operating system, not the dynamic linker. All transaction
programs must be ZOOMs.
• During execution, the UCS Runtime System handles common interfaces and
services, such as program initialization and termination, database interfaces,
input/output interfaces, and service library access.
• UCS programs can be tested and debugged using the Programmers Advanced
Debugging System (PADS).
• UCS COBOL, FORTRAN, and C programs can be tested and debugged using the
MONITOR feature.

1–30 7831 4077–009

 UCS Application Programming Overview

1.5. Developing User Applications

UCS provides an advanced set of programming tools that improve programmer
productivity and enhance performance of existing and future applications. All new
user-written applications should be implemented using UCS.

Existing applications should gradually be upgraded to UCS. For example, in the

following circumstances it is a good idea to convert an existing program to UCS:
• If maintenance is required on an existing program and it must be recoded and
recompiled anyway
• If the new features available in UCS and the extended mode architecture would
increase the performance or capabilities of the existing program

A site can gradually upgrade programs to UCS because UCS is designed to coexist
with the older, non-UCS environment. Coexistence is accomplished by sharing the
following resources:
• Interface software
• Database files

7831 4077–009 1–31

UCS Application Programming Overview

As the following figure shows, the interface software for UDS, DPS 2200, MCB, and
TIP can be shared by UCS and non-UCS applications. Only one copy of each product is
required on the extended mode hardware in order to support both environments.
Also, the UDS, PCIOS, and transaction processing file control superstructure (FCSS)
database files can be shared by programs from both environments, as long as no
Fieldata exists in the files. The DPS 2200 form files and the forms within them can
also be shared.

Because UCS and non-UCS programs share interface software and database files, a
single user-written application can consist of a mixture of UCS and non-UCS programs.
For example, an inventory control application might consist of
• A non-UCS program that updates a data file of parts in stock
• A UCS program that writes a report showing out of stock items

This capability allows you to upgrade an application to UCS gradually: You can
upgrade some programs in an application to UCS, while other programs in the
application remain non-UCS.

1–32 7831 4077–009

 UCS Application Programming Overview

The only restriction for user-written programs is that any one particular program must
be all UCS or all non-UCS at the linking/collection level. Any one particular user-written
program cannot consist of some non-UCS relocatable elements and some UCS object
modules (for example, ACOB relocatables and UCS COBOL object modules).

Upgrading high-level language programs is simple for the applications programmer

because very little has changed. The coding interfaces are basically untouched. Only
MCB coding has changed. It has been simplified.

For more complete details on coexistence of UCS and non-UCS programs and
upgrading non-UCS programs to UCS, refer to Section 8.

7831 4077–009 1–33

UCS Application Programming Overview

1.6. Benefits of Extended Mode Hardware and

Software
In summary, Unisys now offers advanced new technology composed of
• Extended mode architecture available on 2200 ClearPath systems
• Enhanced new software, including the operating system, the Universal Compiling
System, and its supporting software, that exercises this architecture to its fullest
potential

Table 1–1 summarizes the benefits provided by the extended mode hardware and its
extended mode software platform:

Table 1–1. Benefits of the UCS Hardware/Software Platform

Benefits Features

Enhanced architecture User access to extended mode hardware

Dramatically increased addressing space
Architecture-independent programs
Built-in automatic multibanking for
programs
Better system security and data
protection through subsystems
Better program protection
Improved programming Ease of program construction
Versatility in linking programs
Ease of debugging and maintaining
programs
Programming language conformance to
ANSI standards
New language offerings
Standard calling sequence across
programming languages and the
operating system
Compatibility Consistency and compatibility with
existing programs
Extended mode interfaces with other
Unisys products

1–34 7831 4077–009

 UCS Application Programming Overview

This new hardware and software technology serves as a new foundation upon which
users can develop custom-built applications. It provides an efficient application
development environment, thus increasing programmer productivity and more
effectively meeting the needs of users.

User-Written
CASE Tools
Applications

Universal Compiling System

Extended Mode Operating System

Extended Mode Hardware

7831 4077–009 1–35

UCS Application Programming Overview

1–36 7831 4077–009

Section 2
Compiling UCS Programs

This section provides general information on the mechanics of using all UCS
compilers.

For more detailed information, refer to the appropriate compiler manual, as follows:
• C Compiler Programming Reference Manual Volume 2
• COBOL Compiler Programming Reference Manual Volume 2
• FORTRAN Compiler Programming Reference Manual Volume 2

Compiler Call Format

• All UCS compilers use the same basic compiler call statement, as follows:
@Uxxx,letter-options source-program,object-program,,keyword-options-
element,keyword-option,...

• where Uxxx represents the appropriate compiler call: UCOB, UFTN, or UC.

Example
@UCOB QUAL*FILE.SOURCE,QUAL*FILE.OM/COMP

In this example
• The UCS COBOL compiler is called.
• The source program found in the element QUAL*FILE.SOURCE is being compiled.
• The object module output from this compilation is placed in the element
QUAL*FILE.OM/COMP.
The version name COMP is used in the element name in this example because the
output of the UCS compilers and the output of the LINK Processor (static linker)
are both object modules. This means that the @LINK output will delete the
compiler’s output if the following conditions are true:
− The output of the compilation and the output of the @LINK are given the same
element name
− The compilation is performed first
Using a version name such as COMP helps clarify whether the object module
element was produced by the compiler or LINK Processor, and thus helps ensure
name conflicts will not occur.

7831 4077–009 2–1

Compiling UCS Programs

(In this guide, all compilation outputs include the version name COMP to avoid
potential name conflicts.)

The following subsections describe in detail each syntax item in the compiler call.

2.1. Specifying Compiler Options

When using UCS compilers, there are three methods for supplying compiler options:
• Letter options
• Keyword options
• A keyword options element

Conflicts may arise between options specified by these different methods. For
example, the keyword options WIDE and NARROW control the width of compiler
output. A conflict would occur if a keyword option specifies WIDE, but the keyword
options element specifies NARROW. In such a case, the order of precedence is as
follows.

Precedence of Compiler Options

1. Keyword options specified in the compiler call
2. Letter options specified in the compiler call
3. Keyword options specified in the keyword options element

2.1.1. Letter Options

The letter option method of specifying control information for the UCS compilers uses
letters that have specific meanings. For example, the following UCS COBOL compiler
call uses the S letter option to indicate that a copy of the source program listing found
in QUAL*FILE.SOURCE should be printed:

@UCOB,S QUAL*FILE.SOURCE,QUAL*FILE.OM/COMP

These letter options were introduced by previous compilers and have been carried
over to the UCS compilers. Refer to the appropriate UCS compiler manual for the
letter options supported by that compiler.

2–2 7831 4077–009

 Compiling UCS Programs

2.1.2. Keyword Options

Keyword options are a new method of directing the compiler to perform certain tasks
during the compilation process. Keyword options have fairly descriptive English
language names and are self-explanatory in many cases. This makes them easier to
understand and remember than letter options.

You specify keyword options in the fifth and following fields on the compiler call
statement, separating different keyword options by commas. For example, the
following compiler call uses three keyword options: SOURCE, NO-REMARK, and
NARROW:

@UCOB QUAL*FILE.SOURCE,QUAL*FILE.OM/COMP,,,SOURCE, NO-REMARK, ;

NARROW

In this example
• The SOURCE keyword option directs the compiler to produce a source listing of
the element QUAL*FILE.SOURCE.
• The NO-REMARK keyword option indicates that no remarks are to be printed in
the listing. (Remarks are informational compiler messages.)
• The NARROW keyword option limits the print width to 79 characters.
• The semicolon (;) is used as a continuation character on compiler calls.

Each keyword option has a related keyword option that has the opposite meaning. For
example
• SOURCE has an opposite called NO-SOURCE that indicates that the source listing
is not to be printed.
• NARROW has an opposite called WIDE that indicates that the listing has a width of
132 characters.

For a complete listing of the keyword options available, refer to the appropriate UCS
compiler manual.

7831 4077–009 2–3

Compiling UCS Programs

2.1.3. Keyword Options Element

The second method for specifying keyword options on the UCS compiler call
statement is by using a keyword options element. A keyword options element
contains a list of keyword options that are in effect for a compilation. If you use a
keyword options element, specify it in the fourth field.

In the following example, an @PRT,S statement lists the contents of a keyword

options element named QUAL*FILE.OPTIONS. This element contains the keyword
options SOURCE, NO-REMARK, and NARROW. User input is in bold.

@PRT,S QUAL*FILE.OPTIONS
QUAL*FILE(1).OPTIONS(0)
1 SOURCE
2 NO-REMARK, NARROW

The following example of a UCS COBOL compiler call shows this keyword options
element being specified in the fourth field:

@UCOB QUAL*FILE.SOURCE,QUAL*FILE.OM/COMP,,QUAL*FILE.OPTIONS

Once you set up a keyword options element, it can be used over and over; many
programs created by different programmers can be compiled with the same set of
keyword options. This eliminates the need to specify all the options all the time.

2–4 7831 4077–009

 Compiling UCS Programs

2.2. UCS Compiler Listings

When you compile a UCS program, a listing is produced that describes the
compilation. Example 2–1 shows a compiler listing produced using the following
compiler call:

@UCOB QUAL*FILE.SOURCE,QUAL*FILE.OM/COMP,,,SOURCE, NO-REMARK, ;

NARROW, OPTIONS

Note that the SOURCE, NO-REMARK, NARROW, and OPTIONS keyword options affect
the format of the compiler listing.

Sign-on UCOB- 6R2(931119) LSS- 8R2(931209) 940205 23:28:02

line

OPTIONS: NO-ALLOC, APPLICATION/UDSSRC, NO-AUXPROLOG, CACHE/D0,

NO-CLEAR, CODE, NO-CODE-LVE, NO-COMPAT, NO-COMP-BIN,
Options DEBUG/WALKBACK, DOUBLEQUOTE, SINGLESPACE, ERRCHECK, NO-ERREXIT,
Listing EXTENDED, NO-IR-DIFF, NO-LEVEL, NO-LINKINFO, LISTCOPY, NO-LITERAL,
MAIN-PROGRAM, MAX-ERRORS/100000, NO-MONITOR, MULTI-PF, NO-OBJECT,
NO-OBJ-PKT, OPTIM, OPTIONS, NO-PARMCHECK, NO-POSIX-IO, NO-REMARK,
REORDER, NO-RUNCHECK, SEARCH-PF-SI, NO-SEGCODE, NO-SHIFT, SIGNON,
SOURCE, NO-TRACECOPY, NO-TRACEMSG, NO-TRANSFORM, NO-UREP-XREF,
WARNING, NARROW, NO-XREF

1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. EXAMPLE.
3 ENVIRONMENT DIVISION.
4 CONFIGURATION SECTION.
5 SOURCE-COMPUTER. UNISYS-2200.
6 SPECIAL-NAMES.
7 PRINTER IS PRINTER.
8 DATA DIVISION.
Source 9 COMMON-STORAGE SECTION.
Listing 10 01 COMMON-FIELD-1 PIC X(6) VALUE 'COMMON'.
11 WORKING-STORAGE SECTION.
12 01 WORKING-FIELD-1 PIC X(25)
13 VALUE 'THIS IS A WORKING FIELD'.
14 PROCEDURE DIVISION.
15 START-UP-PARA.
16 DISPLAY 'COMMON-FIELD-1 = ' COMMON-FIELD-1
17 UPON PRINTER.
18 DISPLAY 'WORKING-FIELD-1 = ' WORKING-FIELD-1
19 UPON PRINTER.
20 STOP RUN.

Bank
Sizes SIZES: CODE(EM6): 76 DATA: 138 COMMON: 3
Line

Sign-off END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) Line

7831 4077–009 2–5

Compiling UCS Programs

Example 2–1. Sample Compiler Listing

The following subsections describe the components identified in Example 2–1.

2.2.1. Sign-On Line

The sign-on line is present for all UCS compilations. The following sign-on line is from
Example 2–1:
UCOB- 6R2(931119) LSS- 8R2(931209) 940205 23:28:02

The sign-on line identifies

• The level of the compiler
(6R2 in this example)

• The level of LSS, the code generator portion of the compiling system
(8R2 in this example)

• The date that the software was created by the development center or generated
by the user site; this appears in parentheses following each of the level numbers.
(In this example, 931119 for UCOB and 931209 for LSS)

• The date and time when this compilation began

(In this example, 940205 at 23:28:02)

2.2.2. Options Listing

The Options Listing follows the sign-on line. It is present if your compilation uses the
keyword option OPTIONS.

The Options Listing displays all compiler keyword options in effect for this
compilation, including the keyword options in effect by default.

The following Options Listing is from Example 2–1:

OPTIONS: NO-ALLOC, APPLICATION/UDSSRC, NO-AUXPROLOG, CACHE/D0,
NO-CLEAR, CODE, NO-CODE-LVE, NO-COMPAT, NO-COMP-BIN,
DEBUG/WALKBACK, DOUBLEQUOTE, SINGLESPACE, ERRCHECK, NO-ERREXIT,
EXTENDED, NO-IR-DIFF, NO-LEVEL, NO-LINKINFO, LISTCOPY, NO-LITERAL,
MAIN-PROGRAM, MAX-ERRORS/100000, NO-MONITOR, MULTI-PF, NO-OBJECT,
NO-OBJ-PKT, OPTIM, OPTIONS, NO-PARMCHECK, NO-POSIX-IO, NO-REMARK,
REORDER, NO-RUNCHECK, SEARCH-PF-SI, NO-SEGCODE, NO-SHIFT, SIGNON,
SOURCE, NO-TRACECOPY, NO-TRACEMSG, NO-TRANSFORM, NO-UREP-XREF,
WARNING, NARROW, NO-XREF

For information on these keyword options, see the appropriate compiler manual.

2–6 7831 4077–009

 Compiling UCS Programs

2.2.3. Bank Sizes Line

The bank sizes line precedes the final line of the compilation, the sign-off line. It
specifies the following:
• The storage usage (type and size of banks produced by the compilation)
• The class of machine for which the compiled code has been generated

The following designations represent the classes of machines:

Designation Definition

EM0 Generic code executable on any extended mode hardware system has been
produced.
EM2 Code specifically designed for execution on an 1100/90, 2200/600, or
2200/400 system has been produced.
EM4 Code specifically designed for execution on a 2200/100 or 2200/200 system
has been produced.
EM6 Code specifically designed for execution on a 2200/XPA system (2200/900
and 2200/500 and all ClearPath systems) has been produced. This code
executes only on a 2200/XPA or ClearPath system.

You can use another keyword option, EXTENDED/n, to specify the class of hardware
for which your program’s compiled code is to be generated; see the appropriate
compiler manual for a description of this keyword option. Note the following when
using this keyword option:
• When executing on the class of system for which it was designed, EM2 and EM4
code may be more efficient than the EM0 generic code.
• When not executing on the class of system for which it was designed, EM2 and
EM4 code may be less efficient than the EM0 generic code, or it may not work at
all.
• EM6 code executes only on 2200/XPA systems (2200/900, 2200/500, and all
ClearPath systems). This code will not execute successfully on the 1100/90,
2200/600, 2200/400, 2200/200, or 2200/100.

The bank sizes line is present for all UCS compilations.

The following bank sizes line is from Example 2-1:

SIZES: CODE(EM6): 76 DATA: 138 COMMON: 3

7831 4077–009 2–7

Compiling UCS Programs

In this example
• Code targeted for a 2200 ClearPath system has been generated (EM6).
• The code bank size is 76 words.
• The data bank size is 138 words.
• The common block bank size is 3 words.

2.2.4. Sign-Off Line

The sign-off line is the last line of any UCS compiler listing. It identifies the number of
errors encountered by the compilation process, classified by
• Class (ERROR, WARNING, or REMARK)
• Subclass (for example, INTERNAL, FATAL, MAJOR, or MINOR for class ERROR, or
USAGE for class WARNING)

The sign-off line is present for all UCS compilations.

The following sign-off line is from Example 2–1:

END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)

In this example, there are no errors of any type.

2–8 7831 4077–009

Section 3
Application Programming in a Batch or
Demand Environment

This section discusses topics relating to application programming in a batch or

demand environment.

3.1. Basic Information for Batch and Demand

Programming
This subsection discusses coding, compiling, and linking batch and demand programs.
It discusses both dynamic linking and static linking techniques for functional testing.
The information in this subsection is a foundation for understanding later subsections
on
• Coding, compiling, and linking programs that access UDS databases
• Coding, compiling, and linking programs that use DPS 2200
• Coding, compiling, and static linking for performance

Two simple UCS COBOL examples are used throughout 3.1. Except where noted,
everything discussed regarding these examples also applies to UCS FORTRAN and
UCS C.

7831 4077–009 3–1

Application Programming in a Batch or Demand Environment

Example 1: COBOLEX
The first example shows one UCS COBOL program called COBOLEX. This program
performs data manipulations and displays the data before and after updating.

COBOLEX
IDENTIFICATION DIVISION.
PROGRAM-ID. COBOLEX INITIAL.
.
.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DATANAME1 PIC X(8) VALUE ALL 'x'.
01 DATANAME2 PIC 9(5) VALUE 6.
01 DATANAME3 PIC 9(5) VALUE 12.
PROCEDURE DIVISION.
DISPLAYs ....
data manipulation
DISPLAYs ...
STOP RUN

Example 2: MAIN, SUB1, and SUB2

The second example shows three UCS COBOL programs:
• One main program, called MAIN
• Two subprograms, called SUB1 and SUB2

The execution sequence of these three programs is as follows:

1. MAIN executes.
2. MAIN calls SUB1.
3. SUB1 executes.
4. SUB1 returns to MAIN.
5. MAIN calls SUB2.
6. SUB2 executes.
7. SUB2 returns to MAIN.
8. MAIN terminates.

Each program contains DISPLAY statements to track the execution.

The following figure summarizes this program.

3–2 7831 4077–009

 Application Programming in a Batch or Demand Environment

7831 4077–009 3–3

Application Programming in a Batch or Demand Environment

3.1.1. Coding Batch and Demand Programs

UCS programming supports the following languages for batch and demand programs:
• COBOL
• FORTRAN
• C

Table 3–1 shows the interfaces supported for these languages.

Table 3–1. Interfaces from UCS

Languages

UCS COBOL UCS FORTRAN UCS C

PCIOS PCIOS PCIOS

Sequential (SDF) Sequential SDF Text
Relative Direct SDF (Sequential SDF)
(Direct SDF) ANSI Tape Binary
Indexed (MSAM) ANSI interchange (Direct SDF)
ANSI Tape Tape
ANSI Interchange
Tape
EBCDIC Tape
(IBM)

DMS 2200 DMS 2200

RDMS 2200 RDMS 2200 RDMS 2200

Interpreter SQL Interpreter SQL Interpreter SQL
Embedded SQL Module SQL Embedded SQL

SFS 2200 SFS 2200 SFS 2200

Relative Direct SDF Binary
Indexed (MSAM)

TIP/HVTIP TIP/HVTIP TIP/HVTIP

MCB MCB MCB

DPS 2200 DPS 2200 DPS 2200

FCSS files FCSS files FCSS files

UREP INVOKE UREP INVOKE UREP INVOKE

3–4 7831 4077–009

 Application Programming in a Batch or Demand Environment

Table 3–1. Interfaces from UCS

Languages

UCS COBOL UCS FORTRAN UCS C

UREP INVOKE UREP INVOKE UREP INVOKE

UREP Cross UREP Cross UREP Cross

Reference Reference Reference

OS 2200 OS 2200
Sort/Merge Sort/Merge

PCFP PCFP PCFP

SLIB functions SLIB functions

2200 POSIX.1

ER Interface ER Interface ER Interface

Contingency Contingency Contingency

Handling Handling Handling

As Table 3–1 shows, the following interfaces are supported:

• Each of these languages supports Processor Common Input/Output System
(PCIOS) files.
• You can access each of the UDS database models through UCS programs:
− UCS COBOL and UCS FORTRAN support the network/hierarchical database
model (DMS 2200).
− UCS COBOL, UCS FORTRAN, and UCS C support the interpreter SQL interface
for accessing the relational database model (RDMS 2200).
− UCS COBOL and UCS C support the SQL 92 standards relational database
interface, RDMS 2200 embedded SQL (ESQL).
− UCS FORTRAN supports the SQL 92 standard module SQL interface for
accessing the relational database model (RDMS 2200).
− The Shared File System (SFS 2200) is supported by all UCS languages.
• Transaction Processing is supported by UCS COBOL, UCS FORTRAN, and UCS C.
− Transactions written in UCS COBOL, UCS FORTRAN, and UCS C can use the
Message Control Bank (MCB) functions.
− Transactions written in UCS COBOL, UCS FORTRAN, and UCS C can use the
Display Processing System (DPS 2200).
• UCS FORTRAN and UCS C can use the Unisys Repository Manager (UREP) INVOKE
capability. At compilation time, these languages can invoke source code from the
repository and store cross reference information into the repository.
• Programs written in UCS COBOL and UCS FORTRAN can use the OS 2200
Sort/Merge interface.

7831 4077–009 3–5

Application Programming in a Batch or Demand Environment

• UCS COBOL, UCS FORTRAN, and UCS C provide the capability to execute FURPUR
operations from within a program using a new interface, Program-Callable
FURPUR (PCFP).
• UCS COBOL and UCS C support an extended mode version of selected SYSLIB
functions using SLIB.
• UCS C provides the 2200 POSIX.1 interface.
• All UCS languages provide direct high-level language access to most of the
Executive requests (ER).
• UCS COBOL, UCS FORTRAN, and UCS C can be used to write contingency
handlers.

These interfaces provide great flexibility and the means to utilize the most appropriate
high-level language and interface to meet user application needs. Note that UCS
programs written in a language without access to a specific product can gain access
by calling a subroutine coded in a UCS language with the necessary access.

3.1.2. Compiling Batch and Demand Programs

In UCS programming, the compilation process involves the following products:

• The appropriate language-dependent front-end processor (UCOB, UFTN, or UC.

• Oriented COBOL Compiler Programming Reference Manual Volume 4.
• The common architecture-dependent back-end processor (LSS)
• A component of the Linking System used to produce the object module output,
the Object Module Output Routines (OMOR)

The following figure represents the basic compilation process.

@USE COB$PF.,qual*procfile. Multiple $PF files are

@USE FTN$PF.,qual*procfile. available for these
@USE UC$PF.,qual*procfile. languages

@UCOB . . . .
or
UCS @UFTN . . . . UCS
Source or Compiled
Program @UC . . . . Object Module

qual*ucstst.source qual*ucstst.om/comp

002323

Notice that you can designate procedure files (using the @USE names COB$PF,
FTN$PF, and UC$PF) for UCS COBOL, FORTRAN, and C to satisfy their COPY or
INCLUDE statements. Each compiler by default searches the system procedure file
SYS$LIB$*PROC$ as a last resort for procs that satisfy COPY or INCLUDE statements.

3–6 7831 4077–009

 Application Programming in a Batch or Demand Environment

For more information on this feature, see the reference manual for the appropriate
language.

To make the compilation process easier, the UCS compilers support a standardized
compiler call used across all languages. Examples follow.

Example 1: COBOLEX
In the example using the source program COBOLEX, the compiler call statement is as
follows:

@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS

• QUAL*UCSTST.COBOLEX is the symbolic element containing the source program.

• QUAL*UCSTST.COBOLEX/COMP is the object module output to be produced by
compilation.
Note: The version name COMP appears on all compilation outputs in this
guide. This is to differentiate an object module produced by a UCS compiler
from one produced by static linking. Refer to Appendix C for a suggested set of
element and runstream naming conventions.

• The NO-OPTIONS keyword option is used to shorten the listing produced by

compilation; it suppresses printing of the Options Listing (see 2.2.2).

7831 4077–009 3–7

Application Programming in a Batch or Demand Environment

Example 2: MAIN, SUB1, and SUB2

Three compilations are required for the second example. The following are the
compiler call statements used:

@UCOB QUAL*UCSTST.MAIN,.MAIN/COMP,,,NO-OPTIONS

@UCOB QUAL*UCSTST.SUB1,.SUB1/COMP,,,SUBPROGRAM,NO-OPTIONS

@UCOB QUAL*UCSTST.SUB2,.SUB2/COMP,,,SUBPROGRAM,NO-OPTIONS

• QUAL*UCSTST.MAIN, QUAL*UCSTST.SUB1, and QUAL*UCSTST.SUB2 are the

symbolic elements containing the source programs.
• QUAL*UCSTST.MAIN/COMP, QUAL*UCSTST.SUB1/COMP, and
QUAL*UCSTST.SUB2/COMP are the object modules to be produced by
compilation.
• The NO-OPTIONS keyword option is used to shorten the listing produced by
compilation.
• The SUBPROGRAM keyword option is used to indicate to the UCS COBOL
compiler that SUB1 and SUB2 are subprograms.

The preceding example shows how to specify that a UCS COBOL compilation is a
subprogram. Each of the languages identifies whether a compilation is a main
program or subprogram/subroutine in a different way:
• UCS COBOL
− If not explicitly specified, the compilation is a main program by default. It may
be called by another UCS object module or executed with @XQT.
− A subprogram is created if the PROCEDURE DIVISION statement includes a
USING clause. It may be called by another UCS object module but not
executed with @XQT.
− Alternatively, you can produce a subprogram by specifying the SUBPROGRAM
keyword option on the UCS COBOL compiler call. The subprogram may be
called by another UCS object module but not executed with @XQT.
• UCS FORTRAN
− If not explicitly specified, the compilation is a main program by default.
− You produce a subprogram by coding a SUBROUTINE statement or a
FUNCTION statement in the UCS FORTRAN program.
• UCS C
− Any program containing a function named "main" is a main program.
− All other programs are subprograms.

3–8 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.1.3. Linking Batch and Demand Programs in the

Development Phase
Linking is a generic term used to describe the process that is known in the industry as
binding and in non-UCS programming as collection.

The linking phase of batch and demand programming provides maximum flexibility to
the applications programmer. UCS programs can be executed in any of the following
ways:
• Directly after compilation, with no separate linking phase
This method resolves all references using dynamic linking only.

• After being partially linked

This method resolves some references using static linking, and some references using
dynamic linking.

• After being completely linked

This method resolves all references using static linking only.

See 1.3.2 for an overview of these linking methods.

The following subsections show examples of each of these linking methods. In all
cases, the methods reflect the development phase of application programming. See
3.5.3 for information regarding production-oriented linking.

3.1.3.1. Dynamic Linking Only

In UCS, there is a shortcut that eliminates the static linking phase. UCS supports the
"compile-and-try-it" method, removing the explicit linking step and shortening
development time. You can merely compile a program and then execute it. There
does not have to be a programmer-invoked static linking step.

In this method, the dynamic linker component of the Linking System performs the
linking (reference resolution) during execution. Execution is interrupted as the
dynamic linker locates and loads object modules as they are called.

Note that this process is most effective for program development only; programmer
invoked linking (static linking) still provides the most efficient execution time
performance for the production environment (see 3.5.3). Examples of the dynamic
linking only method follow.

Example 1: COBOLEX
The following is an example of the source statements used to compile and execute
the program COBOLEX, using dynamic linking only. Note that execution immediately
follows compilation.

@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS

@XQT QUAL*UCSTST.COBOLEX/COMP

7831 4077–009 3–9

Application Programming in a Batch or Demand Environment

Duplicate Entry Point Definitions

During dynamic linking, the dynamic linker searches files for external entry points. It is
possible that, without your knowledge, more than one object module with the desired
external entry point exists in the file being searched. The following occurs in this
case:
1. The link fault occurs; the Linking System searches for the entry point in the
appropriate file or files.
2. The Linking System encounters object modules with duplicate definitions.
3. The Linking System chooses one of these object modules.
4. The Linking System issues a warning identifying the object module that it used to
resolve the reference.

Note that the object module chosen may not be the one wanted.

The following example shows this occurring. File QUAL*UCSTST contains the
following object modules:
• SUB1SUB2/OM
Produced by previous static linking. Contains duplicate definitions of SUB1 and SUB2.

• SUB1 and SUB2

Produced by the compiler.

Either SUB1SUB2/OM or the compiler outputs, SUB1 and SUB2, could be chosen at
execution time to satisfy the calls to SUB1 and SUB2. In the following example,
SUB1SUB2/OM is chosen. User input is in bold.

@XQT QUAL*UCSTST.MAIN/COMP

THIS IS THE MAIN PROGRAM

*WARNING(LINK 244)* More than one definition of entry point SUB1 exists
in
file QUAL*UCSTST(1).The definition in element
QUAL*UCSTST(1).SUB1SUB2/OM
will be used to satisfy references; the others will be ignored.
THIS IS THE SUB1 PROGRAM

RETURN FROM SUBPROGRAM SUB1

THIS IS THE SUB2 PROGRAM

RETURN FROM SUBPROGRAM SUB2

END OF THE MAIN PROGRAM

Example 2, which follows, shows one way to avoid this problem: by creating a new
file and copying the object modules to this file. Note that this is only one method
among many for avoiding this problem.

3–10 7831 4077–009

 Application Programming in a Batch or Demand Environment

Example 2: MAIN, SUB1, and SUB2

The following is an example of the source statements used to
1. Compile a main program and two subprograms
2. Ensure problems with duplicate definitions do not occur, by creating a special
execution file
3. Execute the main program

The source runstream ensures there will be no duplicate entry points in the file or files
searched by the dynamic linker by
• Cataloging a new file
• Copying the object modules to be used to this file

This ensures there are no duplicate external entry points. Execution takes place from
this new file.

The first call to each of the subprograms causes a link fault to occur. The operating
system invokes the Linking System to locate and load the requested subprogram.

(1) @UCOB QUAL*UCSTST.MAIN,.MAIN/COMP,,,NO-OPTIONS

(1) @UCOB QUAL*UCSTST.SUB1,.SUB1/COMP,,,SUBPROGRAM,NO-OPTIONS
(1) @UCOB QUAL*UCSTST.SUB2,.SUB2/COMP,,,SUBPROGRAM,NO-OPTIONS

(2) @DELETE,C QUAL*EXECUTE.

(3) @CAT,P QUAL*EXECUTE.
(4) @COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
(4) @COPY,A QUAL*UCSTST.SUB1/COMP,QUAL*EXECUTE.
(4) @COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.

(5) @XQT QUAL*EXECUTE.MAIN/COMP

Explanation
1. These statements compile the main program and subprograms.
2. This statement deletes the latest cycle of the named file. Assuming this file has
only one cycle, this statement ensures that the @CAT,P statement will be
successful and not cause an error.
3. This statement creates the new file, from which execution is to take place.
4. These statements copy the object modules into the execution file.
5. This statement executes the main program. During execution, the dynamic linker
will resolve references to the subprograms.

7831 4077–009 3–11

Application Programming in a Batch or Demand Environment

LSC Tracing
If you precede the @XQT in the preceding Example 2 with the following statements,
you will get LSC trace output from the dynamic linker. This shows the process the
linker uses to resolve references and find entry points:

@USE LINK$PF, QUAL*EXECUTE

@SSDP,IE LINK$PF.SSDEF$
CONTROL PARAMETERS ARE LSC_TRACES_ON
@EOF

3.1.3.2. Partial Static Linking and Partial Dynamic Linking

A second method of linking uses both
• A separate static linking phase before execution
• A dynamic linking phase during execution

This method allows you to get the benefits of both linking methods:
• You can statically link all stable routines together; execution-time performance for
these parts of the program is thus improved compared to dynamic linking.
• At the same time, you can skip the extra linking phase for all routines still in
development. Such routines are dynamically located and loaded at execution time.

In this subsection, the main program (MAIN) and two subprograms (SUB1 and SUB2)
are used to demonstrate two different examples of this dual type of linking.

3–12 7831 4077–009

 Application Programming in a Batch or Demand Environment

Example 1
In this example
• The two subprograms are the stable routines; they are linked together to produce
a standard object module.
Note that standard object modules produced by static linking can in turn be input to
another static link.

• The main program is still in development.

• The object module produced by the static link (.SUB1SUB2/OM) and the main
program object module produced by the compiler are copied to a new file. This is
to avoid problems with duplicate definitions, that is, to make sure the object
module produced by the static link is dynamically linked at execution time, and not
the object modules produced by the compiler (.SUB1/COMP and .SUB2/COMP).

The following is the source runstream for this example.

(1) @LINK ,QUAL*UCSTST.SUB1SUB2/OM

(2) INCLUDE QUAL*UCSTST.SUB1/COMP
(2) INCLUDE QUAL*UCSTST.SUB2/COMP
(3) RESOLVE ALL REFERENCES USING LIBCODENAME
(4) PROCESS FOR EXTENDED OM
(5) DELETE ALL DEFINITIONS EXCEPT SUB1, SUB2
(6) @EOF

(7) @DELETE,C QUAL*EXECUTE.

(7) @CAT,P QUAL*EXECUTE.
(7) @COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
(7) @COPY,A QUAL*UCSTST.SUB1SUB2/OM,QUAL*EXECUTE.

(8) @XQT QUAL*EXECUTE.MAIN/COMP

Explanation
1. This statement calls the Linking System LINK Processor. The output object
module produced by static linking is placed in the element
QUAL*UCSTST.SUB1SUB2/OM.
2. These commands supply the compiler-generated object modules used as input by
the static link process. There is an INCLUDE command for each object module
that is to be statically linked. Because this static link produces a standard object
module, the main program may or may not be supplied by an INCLUDE command.
In this case, it is not.
3. This command resolves external references, including those to the UCS Runtime
System library.
4. This command serves two purposes:
• It implicitly causes extensive bank merging, thus producing an efficient object
module.
• It specifies the type of object module to be produced. In this example, a
standard object module (OM) is to be produced.

7831 4077–009 3–13

Application Programming in a Batch or Demand Environment

5. This command deletes all entry point definitions except the starting addresses for
the two programs. This greatly decreases the size of the object module produced.
The EXCEPT clause of the DELETE command should contain all external entry points
that can be called. Any not listed are deleted. SUB1 and SUB2 are the only external
entry points in this example.
The starting entry point of a main program is always called START$. Because there is
no main program in this static link, there is no START$.
6. This statement ends the static link.
7. These statements prevent problems with duplicate definitions.
8. This statement executes the main program, now located in the execution file. The
subprograms, now contained in the single statically linked object module, are
located using dynamic linking.

Example 2
In this next example
• The main program (MAIN) and one of the subprograms (SUB1) are the stable
routines.
• They are statically linked together to produce a special type of object module
called a bound object module. A bound object module must always include the
main program. This allows bound object modules to be loaded faster than
standard object modules.
Note that bound object modules cannot be used as input to another static link.
• The other subprogram (SUB2), still in development, is dynamically located and
loaded during execution, just as for standard object modules.
• The object module produced by the static link (MAINSUB1/BOM) and the
subprogram object module produced by the compiler (SUB2/COMP) are copied to
a new file. This is to avoid problems with duplicate definitions, that is, to ensure
that the subprogram dynamically linked at execution time is the compiler-
produced object module and not the object module from the previous linking
example (SUB1SUB2/OM). Both contain the external entry point SUB2.

The following is the source runstream for this example.

@LINK ,QUAL*UCSTST.MAINSUB1/BOM
(1) INCLUDE QUAL*UCSTST.MAIN/COMP
(1) INCLUDE QUAL*UCSTST.SUB1/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
(2) PROCESS FOR EXTENDED BOUND OM
(3) DELETE ALL DEFINITIONS EXCEPT START$
@EOF

@DELETE,C QUAL*EXECUTE.
@CAT,P QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.MAINSUB1/BOM,QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.

@XQT QUAL*EXECUTE.MAINSUB1/BOM

3–14 7831 4077–009

 Application Programming in a Batch or Demand Environment

Explanation
This static link differs from the static link of a standard object module in the following
commands:
1. You must supply the main program (MAIN/COMP) with one of these INCLUDE
commands because a bound object module is being produced.
2. The PROCESS command specifies that the type of output is a bound object
module (BOUND OM).
3. In this example, the entry point of the main program, START$, is the only external
entry point not deleted.

This static link will receive the following warning because the main program contains a
call to SUB2, whose object module is not found in any of the files searched by this
static link. This warning is expected and does not indicate a problem. The call to
SUB2 will be resolved at execution time by dynamic linking.
*WARNING(LINK 108)*The definition for name SUB2 (referenced by object
module QUAL*UCSTST(1).MAIN/COMP) could not be found in the files that
were searched.

3.1.3.3. Static Linking Only (Total Resolution)

The last method of linking produces a totally resolved object module called a zero
overhead object module (ZOOM). A ZOOM is loaded by the 2200 operating system,
not the Linking System. It cannot rely upon dynamic linking for reference resolution.
ZOOMs are performance-oriented and are recommended for all programs in
production environments.

Note that ZOOMs cannot be used as input to another static link.

Examples of this linking method follow.

Example 1: COBOLEX
The following example shows how to statically link the stand-alone program COBOLEX
as a ZOOM and then execute it.

@LINK,S ,QUAL*UCSTST.COBOLEX
INCLUDE QUAL*UCSTST.COBOLEX/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

@XQT QUAL*UCSTST.COBOLEX

Example 2: MAIN, SUB1, and SUB2

The following example shows how to statically link a main program and two
subprograms as a ZOOM and then execute it.

7831 4077–009 3–15

Application Programming in a Batch or Demand Environment

@LINK ,QUAL*UCSTST.MAINSUB1SUB2/ZOOM
(1) INCLUDE QUAL*UCSTST.MAIN/COMP
(1) INCLUDE QUAL*UCSTST.SUB1/COMP
(1) INCLUDE QUAL*UCSTST.SUB2/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
(2) PROCESS FOR EXTENDED ZOOM
(3) DELETE ALL DEFINITIONS EXCEPT START$
@EOF

@XQT QUAL*UCSTST.MAINSUB1SUB2/ZOOM

Explanation
This static link differs from the static link of a standard object module in the following
commands:
1. You must supply the main program and all subprograms with one of these
INCLUDE commands because a ZOOM is being produced. With ZOOMs, dynamic
linking cannot be used.
2. The PROCESS command specifies that the type of output is a ZOOM.
3. In this example, the entry point of the main program, START$, is the only external
entry point not deleted.

3.1.3.4. Resolving References Using Library Search Chains in

LINK$PF.SSDEF$ and SYS$*DATA$.SSDEF$
The Linking System resolves references during linking by using library search chains
(LSC). A library search chain is a list of files and other library search chains that the
Linking System searches for entry point definitions needed to resolve external
references.

The element SYS$*DATA$.SSDEF$ exists on all systems using UCS. It contains

default library search chains; the files in these library search chains represent installed
Unisys system software. These files are used to resolve references as a last resort.
All links, both dynamic and static, shown in 3.1 use only these library search chains.

A site may wish to define its own set of files (its own library search chain) that the
Linking System searches to resolve references before searching the default library
search chains in SYS$*DATA$.SSDEF$. Such a library search chain is called a user-
defined library search chain. User-defined library search chains are created using the
Subsystem Definition Processor (@SSDP). The Subsystem Definition Processor
produces an element named SSDEF$ that is a special subtype (SSD) of an absolute
element. Every library search chain must reside in an element named SSDEF$.

These user-defined library search chains are typically defined and managed by the site
administrator. For details on how library search chains are defined and managed and
how references are resolved, refer to the Linking System Programming Reference
Manual.

If you are going to use user-defined library search chains during dynamic or static
linking, you must identify the file containing the library search chains. Do this by giving
the file an @USE name of LINK$PF before

3–16 7831 4077–009

 Application Programming in a Batch or Demand Environment

• The @XQT statement for the dynamic link

• The @LINK statement for the static link

The @USE statement has the following format:

@USE LINK$PF,qual*libsearchain.

where qual*libsearchain. is the name of the file containing the user-defined library
search chain’s SSDEF$ element. Examples follow.

Dynamic Linking
In the following example, user-defined library search chains located in
QUAL*LIBSEARCHAIN.SSDEF$ are used during dynamic linking:
@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS
@USE LINK$PF,qual*libsearchain.
@XQT QUAL*UCSTST.COBOLEX/COMP

Static Linking
In the following example, user-defined library search chains located in
QUAL*LIBSEARCHAIN.SSDEF$ are used during static linking:
@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS
@USE LINK$PF,qual*libsearchain.
@LINK,S ,QUAL*UCSTST.COBOLEX
INCLUDE QUAL*UCSTST.COBOLEX/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@XQT QUAL*UCSTST.COBOLEX

Search Order for Resolving References

When a user-defined library search chain is specified, references are first resolved
using the files specified in this library search chain; any remaining references are
resolved using the library search chains in SYS$*DATA$.SSDEF$.

Dynamic Linking
During dynamic linking, the file containing the object module being executed is also
searched to resolve references. This file is known as HOME$. It is always searched
first, before the library search chains identified by LINK$PF and the default library
search chains in SYS$*DATA$.SSDEF$. In summary, references are resolved during
dynamic linking using the following search order:
1. HOME$-the file in which execution begins
2. User-defined library search chains residing in a LINK$PF element
3. Default library search chains residing in SYS$*DATA$.SSDEF$

7831 4077–009 3–17

Application Programming in a Batch or Demand Environment

Static Linking
In static linking, the USING clause on the RESOLVE command determines the order in
which references are resolved. The USING clause may contain a list that includes any
or all of the following:
• File names
File names indicate specific files that the programmer wishes to have searched to
resolve references. A file name must end with a period.

• The LOCAL_DEFS option

The LOCAL_DEFS option specifies that references are explicitly resolved using object
modules supplied by INCLUDE commands. (Without the LOCAL_DEFS option, the
object modules supplied by INCLUDE commands are only implicitly used for resolution
at the end of static linking, after all other object modules have been used. You might
INCLUDE a special version of a runtime routine, only to have it ignored by the linker
and another system copy pulled in if you do not use the LOCAL_DEFS option.)

• The LIBCODENAME option

LIBCODENAME indicates that the LINK$PF library search chains, if present, should be
merged with the default library search chains in SYS$*DATA$.SSDEF$ to form a
composite library search chain. This composite library search chain is then used to
resolve references.
(LIBCODENAME may be abbreviated to LCN.)

• Individual library code names

Individual library code names specify that references are explicitly resolved using the
object modules represented by the listed library code names.

The order in which these items are listed in the USING clause is the order in which
they are searched. This means once LCN is encountered, the composite SSDEF$
library search chain is searched.

3–18 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following static linking example demonstrates the search order.

@USE LINK$PF,qual*libsearchain.
@LINK ,QUAL*UCSTST.ZOOM
INCLUDE QUAL*UCSTST.X/COMP
INCLUDE QUAL*UCSTST.Y/COMP
INCLUDE QUAL*UCSTST.Z/COMP
RESOLVE ALL REFERENCES
USING LOCAL_DEFS, QUAL*FILEA., QUAL*FILEB., LCN
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

In this example, the RESOLVE command specifies that references are resolved using
the following search order:
1. All object modules supplied by INCLUDE commands (as specified by LOCAL_DEFS)
2. Object modules in file QUAL*FILEA.
3. Object modules in file QUAL*FILEB.
4. The composite library search chain (as specified by LCN) created by merging
a. The library search chains in LINK$PF
b. The default library search chains in SYS$*DATA$.SSDEF$

Note that during static linking, HOME$ has no meaning.

For complete information on resolving references, refer to the Linking System

Programming Reference Manual.

7831 4077–009 3–19

Application Programming in a Batch or Demand Environment

3.1.3.5. Understanding the Output of a Static Link

This subsection describes the output of a static link. It is primarily for background
information.

Example 3–1 illustrates static linking output. The example

• Is the static link for the simple program COBOLEX
• Is produced by using the S option on the @LINK call
• Produces a zero overhead object module (ZOOM)
• Uses the following @LINK source runstream:
@LINK,S ,QUAL*UCSTST.COBOLEX
INCLUDE QUAL*UCSTST.COBOLEX/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

Example 3–1 shows the output listing produced by these static link commands. Items
identified by numbers in parentheses are explained following the listing. User input is
in bold.

For more information on @LINK output, refer to the Linking System Programming
Reference Manual.

@LINK,S ,QUAL*UCSTST.COBOLEX
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1353:45 (1)
1 INCLUDE QUAL*UCSTST.COBOLEX/COMP (2)
2 RESOLVE ALL REFERENCES USING LIBCODENAME (2)
3 PROCESS FOR EXTENDED ZOOM (2)
5 Bank(s) merged resulting in bank EM$$CODE . (3)
1 Bank(s) merged resulting in bank EM$$CODE_$A . (3)
1 Bank(s) merged resulting in bank EM$$DATA . (3)
1 Bank(s) merged resulting in bank EM$$LINK_VECTOR . (3)
3 Bank(s) merged resulting in bank EM$$LINK_VECTOR_$A . (3)
1 Bank(s) merged resulting in bank EM$$LINK_VECTOR_$B . (3)
4 DELETE ALL DEFINITIONS EXCEPT START$ (2)
834 Definition(s) deleted after resolution. (4)

1 BANK GROUP EM$$GROUP. 10 banks. (5)

1 Name: EM$$CODE (new bank) (6)

Bank_type = Code; LBN = 0

Example 3–1. Example @LINK Output

3–20 7831 4077–009

 Application Programming in a Batch or Demand Environment

L,BDI = 0400004; Addr Range: 000001000 - 000005641 (16)

5 bank parts:
1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23
Name: COBOLEX$1 000001000 - 000001231
2 SYS$LIB$*EMOMRTS(856).RTS-GCLSINT 1993 Dec 23 1138:55
Name: RTS-GCLSINT 000001232 - 000002230
3 SYS$LIB$*PADS(97).PADS$EMRTS 1994 Jan 7 1438:18
Name: PADS$CODE 000002231 - 000004410
4 SYS$LIB$*LINKOMLIB(227).LS$RES-NAME 1993 OCT 4 1808:11
Name: LS$RES-NAME$01 000004411 - 000004416
5 SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT 1993 Dec 17 1417:57
Name: LS$INTERCEPT$01 000004417 - 000005641

2 Name: EM$$CODE_$A (new bank) (7)

Bank_type = Code; LBN = 01
L,BDI = 0400005; Addr Range: 000001000 - 000001053 (16)

1 bank part:
1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37
Name: I_BANK 000001000 - 000001053

3 Name: EM$$DATA (new bank) (8)

Bank_type = Data; LBN = 02
L,BDI = 0600001; Addr Range: 000000000 - 000000474 (16)

1 bank part:
1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23
Name: COBOLEX$0 000000000 - 000000474

4 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04 (9)

Name: URTS$TABLES
Bank_type = Data; LBN = 03
L,BDI = 0400006; Addr Range: 000060000 - 000107036 (16)

5 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04 (10)

Name: SS$CGY_LIST
Bank_type = Data; LBN = 04
L,BDI = 0400007; Addr Range: 000000000 - 000000001 (16)

6 Name: EM$$DATA_$A (new bank) (11)

Bank_type = Data; LBN = 05
L,BDI = 0600002; Addr Range: 000050000 - 000050005 (16)

1 bank part:
1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37
Name: DBNK 000050000 - 000050005

Example 3–1. Example @LINK Output

7831 4077–009 3–21

Application Programming in a Batch or Demand Environment

7 Name: EM$$LINK_VECTOR (new bank) (12)

Bank_type = Link_vector; LBN = 06
L,BDI = 0400010; Addr Range: 000000000 - 000000007 (16)

1 bank part:
1 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04
Name: URTS$TABLES$17 000000000 - 000000007 (16)

8 Name: EM$$LINK_VECTOR_$A (new bank) (13)

Bank_type = Link_vector; LBN = 07
L, BDI = 0400011; Addr Range: 000000000 - 000000343 (16)

3 bank parts:
1 SYS$LIB$*EMOMRTS(856).RTS-GCLSINT 1993 Dec 23 1138:55
Name: LV$GCLSINT 000000000 - 000000013
2 SYS$LIB$PADS(97).PADS$EMRTS 1994 Jan 7 1438:18
Name: PADS$LV 000000014 - 000000213
3 SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT 1993 Dec 17 1417:57
Name: LS$INTERCEPT$04 000000214 - 000000343

9 Name:EM$$LINK_VECTOR_$B (new bank) (14)

Bank_type = Link_vector: LBN = 010
L,BDI = 0600003; Addr Range: 000000000 - 000000003 (16)

1 bank part:
1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37
Name: RSAC-UCSEMOM$17 000000000 - 000000003

10 SYS$LIB$*PADS(97).PADS$EMRTS 1994 Jan 7 1438:18 (15)

Name: PADS$DATADB
Bank_type = Data; LBN = 012
E,BDI = 012; Addr Range: 000100000 - 000377777 (16)

2 BANK GROUP SDD$$GROUP. 1 bank. (5)

1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23

Name: COBOLEX$3
Bank_type = SDD; LBN = 011
Addr Range: 000000000 - 000000113

END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0. (17)

Example 3–1. Example @LINK Output

3–22 7831 4077–009

 Application Programming in a Batch or Demand Environment

Explanation
1. This is the LINK Processor call line. It identifies
• The level of the Linking System software
• In parentheses, the date and time this Linking System software was generated
• The date and time that this static link took place (not in parentheses)
2. These are an echo of the static linking commands input from the source
runstream.
3. As a result of the PROCESS command, banks were merged in order to produce a
more production-efficient ZOOM. These statements identify the results of this
automatic bank merging. The names of the new banks that were created are
shown (for example, EM$$CODE). Later in this @LINK output, each of these new
banks is described, showing which input banks were merged together during the
formation of the new output bank.
4. This line provides the number of entry points that were deleted as a result of the
DELETE ALL DEFINITIONS command. The DELETE command decreases the size of
the ZOOM produced by the static link.
5. These statements identify the bank groups created by this static link. A bank
group is a collection of one or more related banks that are grouped together for
efficient loading at execution time. An entire bank group is loaded as a single unit.
This static link produced two bank groups:
• EM$$GROUP
Contains the executable code and data. It represents the COBOLEX program.

• SDD$$GROUP
Is a special bank group not used during error-free execution of the COBOLEX
program. It is a symbolic debugging dictionary. It provides information that
allows PADS to reference data and code statements in the user program,
using symbolic names. It is only used when PADS is invoked.

6. EM$$CODE is the first bank created by the automatic bank merging. The
specification "Bank_type" indicates it is a code bank. It was created by merging
the five banks (now referred to as "bank parts") listed on the lines following the
"Addr Range."
The first line for these bank parts specifies the input object module containing the
original bank; the second line specifies the bank name. The following lines are for the
code bank of the user program COBOLEX:
QUAL*UCSTST(1).COBOLEX/COMP
Name: COBOLEX$1

This is a UCS Runtime System code bank used as the interface to the Linking System
from the generated code and the UCS Runtime System.
SYS$LIB$*EMOMRTS(856).RTS-GCLSINT
Name: RTS-GCLSINT

7831 4077–009 3–23

Application Programming in a Batch or Demand Environment

The following lines are for the PADS code bank. SYS$LIB$*PADS(97).PADS$EMRTS
provides interfaces to the PADS common banks and the PADS extended mode
contingency handler.
SYS$LIB$*PADS(97).PADS$EMRTS
Name: PADS$CODE

The following lines are for a Linking System code bank.

SYS$LIB$*LINKOMLIB(227).LS$RES-NAME provides the entry point that the UCS
Runtime System uses to perform explicit resolution of entry points.
SYS$LIB$*LINKOMLIB(227).LS$RES-NAME
Name: LS$RES-NAME$01

The following lines are for a Linking System code bank.

SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT provides the entry points for the program-
callable interfaces in the Linking System used by PADS and FLIT.
SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT
Name: LS$INTERCEPT$01

7. EM$$CODE_$A is the second bank created by the automatic bank merging. The
specification "Bank_type" indicates it is a code bank. It was created by merging
one bank, which is shown here as the bank part:
SYS$LIB$*RSA(22).RSAC-UCSEMOM
Name: I_BANK

This is the entry point virtual address information for the RDMS application group
software defined by ACTIVE$APP in the library search chains.

8. EM$$DATA is the third bank created by the automatic bank merging. The
specification "Bank_type" indicates it is a data bank. It was created by merging
one bank, which is shown here as the bank part:
QUAL*UCSTST(1).COBOLEX/COMP
Name: COBOLEX$0

This is the data bank for the user program COBOLEX.

9. URTS$TABLES is the fourth bank.

SYS$LIB$*EMOMRTS(856).URTS$TABLES
Name: URTS$TABLES

This is a UCS Runtime System data bank. It contains the UCS Runtime System tables,
I/O buffers and packets, entry point definitions, and the storage management reserve.

10. SS$CGY_LIST is the fifth bank.

SYS$LIB$*EMOMRTS(856).URTS$TABLES
Name: SS$CGY_LIST

3–24 7831 4077–009

 Application Programming in a Batch or Demand Environment

This is a UCS Runtime System data bank. It is a dummy bank used to satisfy
SS_CGY_REF in URTS$TABLES, when the user does not supply a contingency routine
for a chameleon subsystem to access its unshared data. If chameleon subsystems
are not being used, this bank is not used.

11. EM$$DATA_$A is the sixth bank.

SYS$LIB$*RSA(22).RSAC-UCSEMOM
Name: DBNK

This is an RDMS data bank.

12. EM$$LINK_VECTOR is the seventh bank created by the automatic bank merging.
The specification "Bank_type" indicates it is a Link_vector bank. This is a special bank
that contains link vectors. A link vector is a structure used to link references to their
definitions. (For more information, see the Linking System Programming Reference
Manual.)

EM$$LINK_VECTOR contains one bank that is shown here as a bank part. The
following lines are for the link vector bank for the UCS Runtime System bank
URTS$TABLES.

SYS$LIB$*EMOMRTS(856).URTS$TABLES
Name: URTS$TABLES$17

13. EM$$LINK_VECTOR_$A is the eighth bank and the second link vector bank. It was
created by merging 3 banks, that are now called bank parts.
The following lines are for the link vector bank part for the UCS Runtime System
contingency processing routine.
SYS$LIB$*EMOMRTS(856).RTS-GCLSINT
Name: LV$GCLSINT

The following lines are for the link vector bank part for PADS.
SYS$LIB$*PADS(97).PADS$EMRTS
Name: PADS$LV

The following lines are for the link vector bank part for the Linking System.
SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT
Name: LS$INTERCEPT$04

14. EM$$LINK_VECTOR_$B is the ninth bank and the third link vector bank.
The following lines are for the link vector bank for RDMS.
SYS$LIB$RSA(22).RSAC-UCSEMOM
Name: RSAC-UCSEMOM$17

15. PADS$DATADB is the tenth bank.

SYS$LIB$*PADS(97).PADS$EMRTS
Name: PADS$DATADB

7831 4077–009 3–25

Application Programming in a Batch or Demand Environment

This is the PADS data bank.

16. This is the address range for the corresponding bank.

17. This is the sign-off line for the LINK Processor. It identifies
• The number of lines of @LINK commands entered by the user (LINES : 4)
• The number of errors that occurred in this @LINK session (ERRORS : 0)
• The number of warnings that were issued in this @LINK session (WARNINGS : 0)
• The number of external references not resolved during the @LINK session
(XREFS : 0)
External references not resolved by static linking must be resolved by the dynamic
linker during execution. In the case of a ZOOM, the number of external references
should always be zero.

3.1.4. Examples of Batch and Demand Programs

The following subsections present two examples of compiling, linking, and executing
COBOL programs in the batch and demand environments:
• The first example shows a stand-alone program.
• The second example shows a main program and two subprograms.

For both examples, the following are shown:

1. A source listing of the program or programs
2. A source listing of a runstream to compile, link, and execute the example program
(for example, with an @START or @ADD statement)
3. The execution of the runstream (output saved by an @BRKPT statement)

3.1.4.1. Example of a Stand-Alone COBOL Program

This example shows one COBOL program called COBOLEX. This program performs
data manipulations and displays the data before and after updating. The following
example summarizes this program.

COBOLEX
IDENTIFICATION DIVISION.
PROGRAM-ID. COBOLEX INITIAL.
.
.
.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DATANAME1 PIC X(8) VALUE ALL 'x'.
01 DATANAME2 PIC 9(5) VALUE 6.
01 DATANAME3 PIC 9(5) VALUE 12.
PROCEDURE DIVISION.
DISPLAYs ....

3–26 7831 4077–009

 Application Programming in a Batch or Demand Environment

data manipulation
DISPLAYs ...
STOP RUN.

3.1.4.2. Source Listing of the Program (COBOLEX)

Example 3–2 shows the complete source listing of the program COBOLEX. In this
example, the program resides in element QUAL*UCSTST.COBOLEX. Noteworthy lines
are bolded.

IDENTIFICATION DIVISION.
******************************************************************
* *
* EXAMPLE OF A SIMPLE COBOL PROGRAM *
* *
******************************************************************
PROGRAM-ID. COBOLEX INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DATANAME1 PIC X(8) VALUE ALL 'x'.
01 DATANAME2 PIC 9(5) VALUE 6.
01 DATANAME3 PIC 9(5) VALUE 12.
PROCEDURE DIVISION.
******************************************************
*** DISPLAY OF INITIAL VALUES ***
******************************************************
START-PARA.
DISPLAY '*** INITIAL DATA VALUES ***' UPON PRINTER.
DISPLAY ' DATANAME1 = ' DATANAME1 UPON PRINTER.
DISPLAY ' DATANAME2 = ' DATANAME2 UPON PRINTER.
DISPLAY ' DATANAME3 = ' DATANAME3 UPON PRINTER.
*********************************************************
*** MANIPULATION OF THE DATA ***
*********************************************************
DATAMANIPULATION.
DISPLAY '*** DATA MANIPULATION BEING DONE ***' UPON PRINTER.
ADD DATANAME2 TO DATANAME3.
MOVE 'aaaa' TO DATANAME1 (3:4).
******************************************************
*** DISPLAY OF FINAL VALUES ***
******************************************************
ENDPARA.
DISPLAY '*** FINAL DATA VALUES ***' UPON PRINTER.
DISPLAY ' DATANAME1 = ' DATANAME1 UPON PRINTER.
DISPLAY ' DATANAME2 = ' DATANAME2 UPON PRINTER.
DISPLAY ' DATANAME3 = ' DATANAME3 UPON PRINTER.
STOP RUN.

Example 3–2. Source Listing of the Program (QUAL*UCSTST COBOLEX)

7831 4077–009 3–27

Application Programming in a Batch or Demand Environment

3.1.4.3. Source Listing of Runstream

Example 3–3 shows the source listing of the runstream used to compile, link, and
execute the example program COBOLEX. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION *********************
@ . ***
@ . ***
@ . *** THIS EXAMPLE SHOWS THE COMPILATION OF A SIMPLE COBOL
@ . *** PROGRAM - COBOLEX, ITS LINKING USING TWO METHODS, AND
@ . *** THE MATCHING EXECUTIONS
@ . ***
@ . *** COMPILE OF COBOL PROGRAM 'COBOLEX'
@ . ***
@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** METHOD 1: TOTALLY DYNAMIC LINKING
@ . *** EXECUTION OF THE COBOL PROGRAM 'COBOLEX1' USING
@ . *** DYNAMIC LINKING
@ . ***
@XQT QUAL*UCSTST.COBOLEX/COMP
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** METHOD 2: STATIC LINKING TO PRODUCE A ZERO OVERHEAD
@ . *** OBJECT MODULE
@ . ***
@LINK,S ,QUAL*UCSTST.COBOLEX
INCLUDE QUAL*UCSTST.COBOLEX/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL PROGRAM 'COBOLEX'
@ . ***
@XQT QUAL*UCSTST.COBOLEX
@ . ***
@ . ***
@ . ** EXAMPLE IS COMPLETE

Example 3–3. Runstream to Compile, Link, and Execute (QUAL*UCSTST COBOLEX)

3–28 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.1.4.4. Execution of the Source Runstream

Example 3–4 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION *********************
@ . ***
@ . ***
@ . *** THIS EXAMPLE SHOWS THE COMPILATION OF A SIMPLE COBOL
@ . *** PROGRAM - COBOLEX, ITS LINKING USING TWO METHODS, AND
@ . *** THE MATCHING EXECUTIONS
@ . ***
@ . *** COMPILE OF COBOL PROGRAM 'COBOLEX'
@ . ***
@UCOB QUAL*UCSTST.COBOLEX,.COBOLEX/COMP,,,NO-OPTIONS
UCOB- 6R2(931119) LSS- 8R2(931209) 940128 13:53:15
SIZES: CODE(EM6): 154 DATA: 317
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** METHOD 1: TOTALLY DYNAMIC LINKING
@ . *** EXECUTION OF THE COBOL PROGRAM 'COBOLEX1' USING
@ . *** DYNAMIC LINKING
@ . ***
@XQT QUAL*UCSTST.COBOLEX/COMP

*** INITIAL DATA VALUES ***

DATANAME1 = xxxxxxxx

DATANAME2 = 00006

DATANAME3 = 00012

*** DATA MANIPULATION BEING DONE ***

*** FINAL DATA VALUES ***

DATANAME1 = xxaaaaxx

DATANAME2 = 00006

DATANAME3 = 00018

Example 3–4. Execution of Source Runstream—COBOL Program

7831 4077–009 3–29

Application Programming in a Batch or Demand Environment

@ . **
@ . ***
@ . ****************************************************************
@ . ***
@ . *** METHOD 2: STATIC LINKING TO PRODUCE A ZERO OVERHEAD
@ . *** OBJECT MODULE
@ . ***
@LINK,S ,QUAL*UCSTST.COBOLEX
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1353:45
1 INCLUDE QUAL*UCSTST.COBOLEX/COMP
2 RESOLVE ALL REFERENCES USING LIBCODENAME
3 PROCESS FOR EXTENDED ZOOM
5 Bank(s) merged resulting in bank EM$$CODE .
1 Bank(s) merged resulting in bank EM$$CODE_$A .
1 Bank(s) merged resulting in bank EM$$DATA .
1 Bank(s) merged resulting in bank EM$$LINK_VECTOR .
3 Bank(s) merged resulting in bank EM$$LINK_VECTOR_$A .
1 Bank(s) merged resulting in bank EM$$LINK_VECTOR_$B .
4 DELETE ALL DEFINITIONS EXCEPT START$
834 Definition(s) deleted after resolution .

1 BANK GROUP EM$$GROUP. 10 banks.

1 Name: EM$$CODE (new bank)

Bank_type = Code; LBN = 0
L,BDI = 0400004; Addr Range: 000001000 - 000005641

5 bank parts:
1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23
Name: COBOLEX$1 000001000 - 000001231
2 SYS$LIB$*EMOMRTS(856).RTS-GCLSINT 1993 Dec 23 1138:55
Name: RTS-GCLSINT 000001232 - 000002230
3 SYS$LIB$*PADS(97).PADS$EMRTS 1994 Jan 7 1438:18
Name: PADS$CODE 000002231 - 000004410
4 SYS$LIB$*LINKOMLIB(227).LS$RES-NAME 1993 OCT 4 1808:11
Name: LS$RES-NAME$01 000004411 - 000004416
5 SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT 1993 Dec 17 1417:57
Name: LS$INTERCEPT$01 000004417 - 000005641

2 Name: EM$$CODE_$A (new bank)

Bank_type = Code; LBN = 01
L,BDI = 0400005; Addr Range: 000001000 - 000001053

1 bank part:
1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37
Name: I_BANK 000001000 - 000001053
3 Name: EM$$DATA (new bank)
Bank_type = Data; LBN = 02

Example 3-4. Execution of Source Runstream—COBOL Program

3–30 7831 4077–009

 Application Programming in a Batch or Demand Environment

L,BDI = 0600001; Addr Range: 000000000 - 000000474

1 bank part:
1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23
Name: COBOLEX$0 000000000 - 000000474

4 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04

Name: URTS$TABLES
Bank_type = Data; LBN = 03
L,BDI = 0400006; Addr Range: 000060000 - 000107036

5 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04

Name: SS$CGY_LIST
Bank_type = Data; LBN = 04
L,BDI = 0400007; Addr Range: 000000000 - 000000001

6 Name: EM$$DATA_$A (new bank)

Bank_type = Data; LBN = 05
L,BDI = 0600002; Addr Range: 000050000 - 000050005

1 bank part:
1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37
Name: DBNK 000050000 - 000050005

7 Name: EM$$LINK_VECTOR (new bank)

Bank_type = Link_vector; LBN = 06
L,BDI = 0400010; Addr Range: 000000000 - 000000007

1 bank part:
1 SYS$LIB$*EMOMRTS(856).URTS$TABLES 1993 Dec 23 1139:04
Name: URTS$TABLES$17 000000000 - 000000007

8 Name: EM$$LINK_VECTOR_$A (new bank)

Bank_type = Link_vector; LBN = 07
L, BDI = 0400011; Addr Range: 000000000 - 000000343

3 bank parts:
1 SYS$LIB$*EMOMRTS(856).RTS-GCLSINT 1993 Dec 23 1138:55
Name: LV$GCLSINT 000000000 - 000000013
2 SYS$LIB$PADS(97).PADS$EMRTS 1994 Jan 7 1438:18
Name: PADS$LV 000000014 - 000000213
3 SYS$LIB$*LINKOMLIB(227).LS$INTERCEPT 1993 Dec 17 1417:57
Name: LS$INTERCEPT$04 000000214 - 000000343

9 Name:EM$$LINK_VECTOR_$B (new bank)

Bank_type = Link_vector: LBN = 010
L,BDI = 0600003; Addr Range: 000000000 - 000000003

1 bank part:

Example 3–4. Execution of Source Runstream—COBOL Program

7831 4077–009 3–31

Application Programming in a Batch or Demand Environment

1 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1993 Nov 23 2240:37

Name: RSAC-UCSEMOM$17 000000000 - 000000003

10 SYS$LIB$*PADS(97).PADS$EMRTS 1994 Jan 7 1438:18

Name: PADS$DATADB
Bank_type = Data; LBN = 012
E,BDI = 012; Addr Range: 000100000 - 000377777

2 BANK GROUP SDD$$GROUP. 1 bank.

1 QUAL*UCSTST(1).COBOLEX/COMP 1994 Jan 28 1353:23

Name: COBOLEX$3
Bank_type = SDD; LBN = 011
Addr Range: 000000000 - 000000113

END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.

@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL PROGRAM 'COBOLEX'
@ . ***
@XQT QUAL*UCSTST.COBOLEX

*** INITIAL DATA VALUES ***

DATANAME1 = xxxxxxxx

DATANAME2 = 00006

DATANAME3 = 00012

*** DATA MANIPULATION BEING DONE ***

*** FINAL DATA VALUES ***

DATANAME1 = xxaaaaxx

DATANAME2 = 00006

DATANAME3 = 00018

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–4. Execution of Source Runstream—COBOL Program

3–32 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.1.4.5. Example of a COBOL Main Program and Two Subprograms

This example shows three COBOL programs:
• One main program, called MAIN
• Two subprograms, called SUB1 and SUB2

The execution sequence of these programs is as follows:

1. MAIN executes.
2. MAIN calls SUB1.
3. SUB1 executes.
4. SUB1 returns to MAIN.
5. MAIN calls SUB2.
6. SUB2 executes.
7. SUB2 returns to MAIN.
8. MAIN terminates.

Each program contains DISPLAY statements to track the execution.

The following figure summarizes this program.

7831 4077–009 3–33

Application Programming in a Batch or Demand Environment

Source Listing of the Main Program (MAIN)

Example 3–5 shows the complete source listing of the main program, MAIN. In this
example, this program resides in element QUAL*UCSTST.MAIN. Noteworthy lines are
bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SIMPLE COBOL MAIN PROGRAM *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MAIN.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** DISPLAY OF MAIN PROGRAM ***
******************************************************
START-PARA.
DISPLAY 'THIS IS THE MAIN PROGRAM' UPON PRINTER.
CALL 'SUB1'.
DISPLAY 'RETURN FROM SUBPROGRAM SUB1' UPON PRINTER.
CALL 'SUB2'.
DISPLAY 'RETURN FROM SUBPROGRAM SUB2' UPON PRINTER.
DISPLAY 'END OF THE MAIN PROGRAM' UPON PRINTER.
STOP RUN.

Example 3–5. Source Listing of the Main Program (QUAL*UCSTST.MAIN)

3–34 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Subprograms

Example 3–6 shows the complete source listing of the first subprogram, SUB1. In this
example, this program resides in element QUAL*UCSTST.SUB1. Noteworthy lines are
bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SIMPLE COBOL SUB1 PROGRAM *
* *
******************************************************************
******************************************************************
PROGRAM-ID. SUB1.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** DISPLAY OF SUB1 PROGRAM ***
******************************************************
START-PARA.
DISPLAY 'THIS IS THE SUB1 PROGRAM' UPON PRINTER.
EXIT PROGRAM.

Example 3–6. Source Listing of First Subprogram (QUAL*UCSTST.SUB1)

7831 4077–009 3–35

Application Programming in a Batch or Demand Environment

Example 3-7 shows the complete source listing of the second subprogram, SUB2. In
this example, this program resides in element QUAL*UCSTST.SUB2. Noteworthy lines
are bolded.

IDENTIFICATION DIVISION.
***********************************************************
***********************************************************
* *
* EXAMPLE OF A SIMPLE COBOL SUB2 PROGRAM *
* *
***********************************************************
***********************************************************
PROGRAM-ID. SUB2.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** DISPLAY OF SUB2 PROGRAM ***
******************************************************
START-PARA.
DISPLAY 'THIS IS THE SUB2 PROGRAM' UPON PRINTER.
EXIT PROGRAM.

Example 3–7. Source Listing of Second Subprogram (QUAL*UCSTST.SUB2)

3–36 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–8 shows the source listing of the runstream used to compile, link, and
execute the example program in the previous subsections. Noteworthy lines are
bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION *********************
@ . ***
@ . ***
@ . *** THIS EXAMPLE SHOWS THE COMPILATION OF THREE COBOL PROGRAMS -
@ . *** ONE MAIN PROGRAM 'MAIN' AND TWO SUBPROGRAMS 'SUB1' AND 'SUB2',
@ . *** THE LINKING USING FOUR CASES, AND THE MATCHING EXECUTIONS.
@ . ***
@ . ***
@ . ***
@ . *** COMPILE OF COBOL MAIN PROGRAM 'MAIN'
@ . ***
@UCOB QUAL*UCSTST.MAIN,.MAIN/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** COMPILE OF COBOL SUBPROGRAM 'SUB1'
@ . ***
@UCOB QUAL*UCSTST.SUB1,.SUB1/COMP,,,SUBPROGRAM,NO-OPTIONS
@ . ***
@ . ***
@ . *** COMPILE OF COBOL SUBPROGRAM 'SUB2'
@ . ***
@UCOB QUAL*UCSTST.SUB2,.SUB2/COMP,,,SUBPROGRAM,NO-OPTIONS
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 1: TOTALLY DYNAMIC LINKING
@ . *** EXECUTION OF THE COBOL MAIN PROGRAM 'MAIN' USING
@ . *** DYNAMIC LINKING TO LOCATE AND LOAD THE SUBPROGRAMS.
@ . ***
@ . ***
@ . *** ******* COPY *******
@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT
@ . *** STATIC LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
@CAT,P QUAL*EXECUTE.

Example 3–8. Runstream to Compile, Link, and Execute—COBOL Main Program

with Subprograms

7831 4077–009 3–37

Application Programming in a Batch or Demand Environment

@COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.SUB1/COMP,QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.
@PRT,T QUAL*EXECUTE.
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@XQT QUAL*EXECUTE.MAIN/COMP
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 2: STATIC LINKING TO PRODUCE A STANDARD OBJECT MODULE
@ . *** INCLUDING BOTH SUBPROGRAMS BUT NOT THE MAIN PROGRAM
@ . ***
@LINK ,QUAL*UCSTST.SUB1SUB2/OM
INCLUDE QUAL*UCSTST.SUB1/COMP
INCLUDE QUAL*UCSTST.SUB2/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED OM
DELETE ALL DEFINITIONS EXCEPT SUB1, SUB2
@EOF
@ . ***
@ . ***
@ . *** ******* COPY *******
@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT
@ . *** STATIC LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
@CAT,P QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.SUB1SUB2/OM,QUAL*EXECUTE.
@PRT,T QUAL*EXECUTE.
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL OM 'MAIN/COMP'
@ . ***
@XQT QUAL*EXECUTE.MAIN/COMP
@ . ***
@ . ***
@ . ****************************************************************

Example 3–8. Runstream to Compile, Link, and Execute—COBOL Main

Program with Subprograms

3–38 7831 4077–009

 Application Programming in a Batch or Demand Environment

@ . ***
@ . *** CASE 3: STATIC LINKING TO PRODUCE A BOUND OBJECT MODULE
@ . *** INCLUDING THE MAIN PROGRAM AND ONE SUBPROGRAM
@ . ***
@LINK ,QUAL*UCSTST.MAINSUB1/BOM
INCLUDE QUAL*UCSTST.MAIN/COMP
INCLUDE QUAL*UCSTST.SUB1/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED BOUND OM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ******* COPY *******
@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT STATIC
@ . *** LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
@CAT,P QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.MAINSUB1/BOM,QUAL*EXECUTE.
@COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.
@PRT,T QUAL*EXECUTE.
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL BOM 'MAINSUB1/BOM'
@ . ***
@XQT QUAL*EXECUTE.MAINSUB1/BOM
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 4: STATIC LINKING TO PRODUCE A ZERO OVERHEAD OBJECT
@ . *** MODULE INCLUDING THE MAIN PROGRAM AND BOTH
@ . *** SUBPROGRAMS
@ . ***
@LINK ,QUAL*UCSTST.MAINSUB1SUB2/ZOOM
INCLUDE QUAL*UCSTST.MAIN/COMP
INCLUDE QUAL*UCSTST.SUB1/COMP
INCLUDE QUAL*UCSTST.SUB2/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$

Example 3–8. Runstream to Compile, Link, and Execute—COBOL Main

Program with Subprograms

7831 4077–009 3–39

Application Programming in a Batch or Demand Environment

@EOF
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL ZOOM 'MAINSUB1SUB2/ZOOM'
@ . ***
@XQT QUAL*UCSTST.MAINSUB1SUB2/ZOOM
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–8. Runstream to Compile, Link, and Execute—COBOL Main

Program with Subprograms

3–40 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–9 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THIS EXAMPLE SHOWS THE COMPILATION OF THREE COBOL PROGRAMS -
@ . *** ONE MAIN PROGRAM 'MAIN' AND TWO SUBPROGRAMS 'SUB1' AND 'SUB2',
@ . *** THE LINKING USING FOUR CASES, AND THE MATCHING EXECUTIONS
@ . ***
@ . ***
@ . *** COMPILE OF COBOL MAIN PROGRAM 'MAIN'
@ . ***
@UCOB QUAL*UCSTST.MAIN,.MAIN/COMP,,,NO-OPTIONS
UCOB- 6R2(931119) LSS- 8R2(931209) 940128 14:09:16
SIZES: CODE(EM6): 92 DATA: 179
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** COMPILE OF COBOL SUBPROGRAM 'SUB1'
@ . ***
@UCOB QUAL*UCSTST.SUB1,.SUB1/COMP,,,SUBPROGRAM,NO-OPTIONS
UCOB- 6R2(931119) LSS- 8R2(931209) 940128 14:09:22
SIZES: CODE(EM6): 50 DATA: 89
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** COMPILE OF COBOL SUBPROGRAM 'SUB2'
@ . ***
@UCOB QUAL*UCSTST.SUB2,.SUB2/COMP,,,SUBPROGRAM,NO-OPTIONS
UCOB- 6R2(931119) LSS- 8R2(931209) 940128 14:09:27
SIZES: CODE(EM6): 50 DATA: 89
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 1: TOTALLY DYNAMIC LINKING
@ . *** EXECUTION OF THE COBOL MAIN PROGRAM 'MAIN' USING
@ . *** DYNAMIC LINKING TO LOCATE AND LOAD THE SUBPROGRAMS
@ . ***
@ . ***

Example 3–9. Execution of Source Runstream--COBOL Main Program with

Subprograms

7831 4077–009 3–41

Application Programming in a Batch or Demand Environment

@ . *** ******* COPY *******

@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT
@ . *** STATIC LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1409:34
@CAT,P QUAL*EXECUTE.
I:002333 CAT complete.
@COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1409:34
1 ABS
@COPY,A QUAL*UCSTST.SUB1/COMP,QUAL*EXECUTE.
1 ABS
@COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.
1 ABS
@PRT,T QUAL*EXECUTE.
STD#QUAL*EXECUTE(1)
OM MAIN/COMP
OM SUB1/COMP
OM SUB2/COMP
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@XQT QUAL*EXECUTE.MAIN/COMP

THIS IS THE MAIN PROGRAM

THIS IS THE SUB1 PROGRAM

RETURN FROM SUBPROGRAM SUB1

THIS IS THE SUB2 PROGRAM

RETURN FROM SUBPROGRAM SUB2

END OF THE MAIN PROGRAM

@ . ***
@ . ***
@ . ****************************************************************
@ . ***

Example 3–9. Execution of Source Runstream—COBOL Main Program

with Subprograms

3–42 7831 4077–009

 Application Programming in a Batch or Demand Environment

@ . *** CASE 2: STATIC LINKING TO PRODUCE A STANDARD OBJECT MODULE

@ . *** INCLUDING BOTH SUBPROGRAMS BUT NOT THE MAIN PROGRAM
@ . ***
@LINK ,QUAL*UCSTST.SUB1SUB2/OM
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1409:53
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ******* COPY *******
@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT
@ . *** STATIC LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1410:02
END DELETE.
@CAT,P QUAL*EXECUTE.
I:002333 CAT complete.
@COPY,A QUAL*UCSTST.MAIN/COMP,QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1410:02
1 ABS
@COPY,A QUAL*UCSTST.SUB1SUB2/OM,QUAL*EXECUTE.
1 ABS
@PRT,T QUAL*EXECUTE.
STD#QUAL*EXECUTE(1)
OM MAIN/COMP
OM SUB1SUB2/OM
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL OM 'MAIN/COMP'
@ . ***
@XQT QUAL*EXECUTE.MAIN/COMP

THIS IS THE MAIN PROGRAM

THIS IS THE SUB1 PROGRAM

RETURN FROM SUBPROGRAM SUB1

THIS IS THE SUB2 PROGRAM

RETURN FROM SUBPROGRAM SUB2

Example 3–9. Execution of Source Runstream—COBOL Main Program

with Subprograms

7831 4077–009 3–43

Application Programming in a Batch or Demand Environment

END OF THE MAIN PROGRAM

@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 3: STATIC LINKING TO PRODUCE A BOUND OBJECT MODULE
@ . *** INCLUDING THE MAIN PROGRAM AND ONE SUBPROGRAM
@ . ***
@LINK ,QUAL*UCSTST.MAINSUB1/BOM
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1410:21
*WARNING(LINK 108)*The definition for name SUB2 (referenced by object
module QUAL*UCSTST(1).MAIN/COMP) could not be found in the files that
were searched.
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 1 , XREFS : 1.
@ . ***
@ . ***
@ . *** ******* COPY *******
@ . ***
@ . *** COPY THE OBJECT MODULES THAT WILL BE DYNAMIC LINKED
@ . *** TO A NEW FILE TO ENSURE THAT THE COMPILER-PRODUCED
@ . *** OBJECT MODULES ARE USED BY THE DYNAMIC LINKER AND NOT STATIC
@ . *** LINKER OUTPUTS WITH THE SAME ENTRY POINTS.
@ . ***
@DELETE,C QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1410:58
END DELETE.
@CAT,P QUAL*EXECUTE.
I:002333 CAT complete.
@COPY,A QUAL*UCSTST.MAINSUB1/BOM,QUAL*EXECUTE.
FURPUR 30R5 (930309 0913:33) 1994 Jan 28 Fri 1410:59
1 ABS
@COPY,A QUAL*UCSTST.SUB2/COMP,QUAL*EXECUTE.
1 ABS
@PRT,T QUAL*EXECUTE.
STD#QUAL*EXECUTE(1)
BOM MAINSUB1/BOM
OM SUB2/COMP
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL BOM 'MAINSUB1/BOM'
@ . ***
@XQT QUAL*EXECUTE.MAINSUB1/BOM

Example 3–9. Execution of Source Runstream—COBOL Main Program

with Subprograms

3–44 7831 4077–009

 Application Programming in a Batch or Demand Environment

THIS IS THE MAIN PROGRAM

THIS IS THE SUB1 PROGRAM

RETURN FROM SUBPROGRAM SUB1

THIS IS THE SUB2 PROGRAM

RETURN FROM SUBPROGRAM SUB2

END OF THE MAIN PROGRAM

@ . ***
@ . ***
@ . ****************************************************************
@ . ***
@ . *** CASE 4: STATIC LINKING TO PRODUCE A ZERO OVERHEAD OBJECT
@ . *** MODULE INCLUDING THE MAIN PROGRAM AND BOTH
@ . *** SUBPROGRAMS
@ . ***
@LINK ,QUAL*UCSTST.MAINSUB1SUB2/ZOOM
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1411:11
END LINK , LINES : 6 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ******* EXECUTION *******
@ . ***
@ . *** EXECUTION OF COBOL ZOOM 'MAINSUB1SUB2/ZOOM'
@ . ***
@XQT QUAL*UCSTST.MAINSUB1SUB2/ZOOM

THIS IS THE MAIN PROGRAM

THIS IS THE SUB1 PROGRAM

RETURN FROM SUBPROGRAM SUB1

THIS IS THE SUB2 PROGRAM

RETURN FROM SUBPROGRAM SUB2

END OF THE MAIN PROGRAM

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–9. Execution of Source Runstream—COBOL Main Program

with Subprograms

7831 4077–009 3–45

Application Programming in a Batch or Demand Environment

3.2. Coding, Compiling, and Linking Batch and

Demand Programs That Access UDS
Databases
This subsection augments the basic information covered in 3.1. It describes how to
code, compile, and link batch and demand programs that access UDS databases. This
subsection uses simple UCS COBOL, UCS FORTRAN, and UCS C examples throughout.

The UDS suite of database products is totally supported in UCS programming. These
products include the following:
• DMS 2200
This is the hierarchical and network architectural database system, based on a record
and set structure.
DMS 2200 is supported only for UCS COBOL and UCS FORTRAN.

• RDMS 2200
This is the relational database system, based on tables composed of rows and
columns that support parent-child relationships.
RDMS 2200 databases can be accessed through all UCS languages.

• SFS 2200
This is the conventional shared file system, based on sequential and multi-indexed file
structures.
SFS 2200 databases can also be accessed through all UCS languages.

Table 3–2 is a summary of the UDS interfaces supported by the UCS host languages.

3–46 7831 4077–009

 Application Programming in a Batch or Demand Environment

Table 3–2. UDS Interfaces from UCS Languages

UCS COBOL UCS FORTRAN UCS C

DMS 2200 DMS 2200

RDMS 2200 RDMS 2200 RDMS 2200
Interpreter SQL Interpreter SQL Interpreter SQL
Embedded SQL Module SQL Embedded SQL
SFS 2200 SFS 2200 SFS 2200
Relative Direct SDF Binary
(Direct SDF) (Direct SDF)
Indexed (MSAM)

The UCS interfaces to UDS databases are designed to be compatible with older UDS
interfaces. UCS and non-UCS programs can share the same
• UDS software
• Database files

Both UCS and non-UCS programs also support the same functional capabilities. In
other words, UCS programs and non-UCS programs with the same data manipulation
language (DML) command syntax can access the same database files using the same
UDS software, simultaneously. As far as compatibility is concerned, very little has
changed for the applications programmer.

7831 4077–009 3–47

Application Programming in a Batch or Demand Environment

In order to describe how UCS programs access these UDS data models, the following
subsections show three very simple databases, one for each of the data models:
• DMS 2200
• RDMS 2200
• SFS 2200

The three databases shown are interrelated by the common denominator of an

individual. The universe for this database is the company for which the individual
works. The individual is uniquely identified in each database by his or her employee
number. Also, to make the example simple, the following is assumed:
• The individual’s spouse does not work for the same company.
• No individual participates in more than three sports.
• No individual has more than three children.

The databases store the following information about the employee:

• The DMS 2200 database contains information about the individual’s current job.
• The RDMS 2200 database contains information about the individual’s home and
family.
• The SFS 2200 database contains information about the individual’s participation in
company sports.

3–48 7831 4077–009

 Application Programming in a Batch or Demand Environment

For each database model, a subsection describes each of the following processes:
• Creating the database
• Loading information into the database
• Accessing information from the database

All of the examples use alternate application group 7 (UDS$$SVN).

7831 4077–009 3–49

Application Programming in a Batch or Demand Environment

3.2.1. Using DMS 2200 Databases

UCS programming first supported DMS 2200 software in SBR 2R1. UCS COBOL was
the supported host language. This release supported both batch and demand
processing modes.

In SB3R1, support for the following was added:

• UCS FORTRAN was added as a host language.
• TIP and HVTIP transactions were supported for both host languages.

The following subsections describe the steps involved in creating and accessing a
DMS 2200 database using UCS. They discuss
• DMS 2200 schemas
• DMS 2200 subschemas
• DML application programs

3–50 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.1.1. DMS 2200 Schemas

A DMS 2200 schema describes a DMS 2200 database as it exists on mass storage.
The schema describes
• All record types and the data items within these record types
• The storage areas in which these record types reside
• The set relationships between these record types

The coding of a DMS 2200 schema to be used by UCS programs must comply with the
following conditions:
• The schema cannot contain any Fieldata data items or records. Fieldata is not
supported by any UCS compiler. Schemas that contain no Fieldata can be shared
by both UCS and non-UCS programs.

Therefore, most existing schemas built for non-UCS programs can be shared with UCS
programs. This means you do not need to recode or reprocess schemas.

• The schema cannot contain any of the following new UCS COBOL USAGE clauses:
− BINARY-1
− BINARY
These USAGE clauses are not supported by the schema processor (@DDL),
unless the syntax SOURCE IS UCS appears in the schema definition (available
in DMS level 17R1 and later).

• All area names, record names, data item names, set names and database names
must be unique. For example, a schema cannot contain a record and an area with
the same name. Also, these names must be unique within the COBOL program.

Refer to the DMS DDL Administration, Operations, and Programming Guide for more
information on DMS 2200 schemas.

7831 4077–009 3–51

Application Programming in a Batch or Demand Environment

The schema used in the example for this section uses the following record and set
diagram:

The following is a brief description of the record types in this database:

EMPNUMBER
A direct record type that is keyed off the individual’s unique employee number.

INDIVIDUAL
An indexed sequential record type that is keyed off the individual’s name;
duplicates are allowed.

JOBINFO
A calc record type that is keyed off job titles; no duplicates are allowed.

DEPARTMENT
A calc record type that is keyed off department numbers; no duplicates are
allowed.

3–52 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.1.2. DMS 2200 Database Procedures

ASCII COBOL, ASCII FORTRAN, UCS COBOL, and UCS FORTRAN application programs
can use database procedures that are coded using ASCII COBOL or basic mode Meta-
Assembler (MASM). These database procedures can also be used by the QLP and
DMU processors, and as of SB7R1, UCS COBOL DMS database procedures can be
accessed by ASCII COBOL DML programs, QLP, and DMU.

7831 4077–009 3–53

Application Programming in a Batch or Demand Environment

3.2.1.3. DMS 2200 Subschemas

A DMS 2200 subschema describes the part of the database that is visible to the
application program. It details the portion of the database that the application program
can reference.

UCS programs require their own subschemas, with a new HOST LANGUAGE value for
both UCS COBOL and UCS FORTRAN. For UCS COBOL, the following clause is
required:
HOST LANGUAGE IS UCS COBOL

For UCS FORTRAN, the following clause is required:

HOST LANGUAGE IS UCS FORTRAN

The following figure compares subschema source code of UCS COBOL and UCS
FORTRAN.

Remember the following requirements, in addition to the new HOST LANGUAGE

clause settings:
• When coding a UCS subschema, the applications programmer must remember
that no Fieldata characters are allowed. This means that the subschema
REDEFINES clause, if used, cannot contain either of the following:
− USAGE COMP-4
− USAGE DISP-1
If the SDDL processor finds any Fieldata data definitions in the schema or the
subschema when any UCS subschema is processed, it produces no output and prints
a fatal error message.

• The T option is not permitted on the SDDL processor call. This option converts
USAGE clauses to Fieldata or ASCII, depending upon the current values of the
clauses.

3–54 7831 4077–009

 Application Programming in a Batch or Demand Environment

When a UCS subschema is processed, the SDDL processor produces three output
elements:

The following describes these output elements:

• Object subschema
This is an absolute element used during compilation by the UCS compilers and during
execution by DMS 2200.

• S$PROC
This is a symbolic element containing information describing records and data items.
It is used by the UCS compilers while they process an INVOKE statement. The record
and data item layouts are copied from S$PROC into the program during compilation.

• S$WORK
When a subschema contains a HOST LANGUAGE clause for a UCS language, S$WORK
is generated as an object module. You statically or dynamically link S$WORK to the
program (as described later in this subsection).

Note: The F option is no longer required on the SDDL processor call when the Host
Language is UCS COBOL (as of DMS level 16R1). The SDDL processor automatically
converts ASCII COBOL item PICTURE and USAGE clauses (in S$PROC) to those
acceptable to the UCS COBOL compiler.

7831 4077–009 3–55

Application Programming in a Batch or Demand Environment

ASCII COBOL UCS COBOL

USAGE COMP USAGE BINARY

PIC 1 USAGE BINARY-1

The following example shows the SDDL processor call for the UCS COBOL example
subschema:
@UDS$$SVN*DMRMT$.SDDL,DN
QUAL*UCSTST.PERSONSUB,UDS$$SVN*SCHFILE.PERSONSUB

The HOST LANGUAGE IS UCS FORTRAN clause requires no special SDDL processor
call options. The following example shows the SDDL processor call in this case:
@UDS$$SVN*DMRMT$.SDDL,DN
QUAL*UCSTST.PERSONSUB,UDS$$SVN*SCHFILE.PERSONSUB

Refer to the DMS SDDL Administration, Operations, and Programming Guide for
more information on DMS 2200 subschemas.

3–56 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.1.4. Example of a DMS 2200 Database Definition

The following example shows a sample schema and subschema being set up for UCS
program use. The schema can be used by both UCS and non-UCS programs. The
subschema is for UCS COBOL host language programs.

Source Listing of the DMS 2200 Schema

Example 3–10 shows a source listing of the schema PERSONNEL. The schema resides
in the element QUAL*UCSTST.PERSONNEL and can be used by both UCS and non-UCS
programs.

IDENTIFICATION DIVISION
SCHEMA NAME IS PERSONNEL IN FILE SCHFILE
DATA DIVISION
DATA NAME SECTION.
01 CALC-AREA-NAME USAGE IS AREA-NAME
01 EMPNO-AREA-NAME USAGE IS AREA-NAME
01 EMPNO-AREA-KEY USAGE IS AREA-KEY
AREA SECTION.
AREA LOOKS INCLUDE QUICK-BEFORE-LOOKS AFTER-LOOKS
AREA NAME IS DEPTAREA
AREA CODE IS 1
MODE IS DATA
ALLOCATE 12 PAGES
PAGES ARE 448 WORDS
CALC USES 1 CHAINS LINKED PRIOR
AREA NAME IS JOBAREA
AREA CODE IS 2
MODE IS DATA
ALLOCATE 10 PAGES 2 OVERFLOW AT END
PAGES ARE 448 WORDS
CALC USES 1 CHAINS LINKED PRIOR
AREA NAME IS EMPNOAREA
AREA CODE IS 3
MODE IS DATA
ALLOCATE 1000 PAGES
PAGES ARE 448 WORDS
AREA NAME IS INDAREA
AREA CODE IS 4
MODE IS DATA
ALLOCATE 1000 PAGES
PAGES ARE 1792 WORDS
AREA NAME IS INDINDEX
AREA CODE IS 5
MODE IS INDEX

Example 3–10. Source Listing of the Schema (QUAL*UCSTST.PERSONNEL)

7831 4077–009 3–57

Application Programming in a Batch or Demand Environment

ALLOCATE 10 PAGES
PAGES ARE 112 WORDS
RECORD SECTION.
RECORD DEPARTMENT
CODE IS 101
LOCATION MODE IS CALC DMSCALC
IN CALC-AREA-NAME
USING DEPT-NO
DUPLICATES ARE NOT ALLOWED
WITHIN DEPTAREA
MODE IS ASCII
05 DEPT-NO PIC X(4)
05 DEPT-NAME PIC X(24)
05 DEPT-DESCRIPTION PIC X(55)
RECORD JOBINFO
CODE IS 102
LOCATION MODE IS CALC DMSCALC
IN CALC-AREA-NAME
USING JOB-TITLE
DUPLICATES ARE NOT ALLOWED
WITHIN JOBAREA
MODE IS ASCII
05 JOB-TITLE PIC X(20)
05 JOB-DESCRIPTION PIC X(50)
05 JOB-SALARY PIC X(5)
RECORD EMPNUMBER
CODE IS 103
LOCATION MODE IS DIRECT EMPNO-AREA-KEY, EMPNO-AREA-NAME
WITHIN EMPNOAREA
MODE IS ASCII
05 EMP-NUMBER PIC X(5)
RECORD INDIVIDUAL
CODE IS 104
LOCATION MODE IS INDEX SEQUENTIAL
USING ASCENDING KEY IND-LAST-NAME, IND-FIRST-NAME
INDEX AREA IS INDINDEX
LINKS ARE NEXT AND PRIOR
DUPLICATES ARE NOT ALLOWED
WITHIN INDAREA
MODE IS ASCII
05 IND-LAST-NAME PIC X(20)
05 IND-FIRST-NAME PIC X(12)
SET SECTION.
SET DEPT-IND
CODE IS 201
MODE IS CHAIN
ORDER IS SORTED

Example 3–10. Source Listing of the Schema (QUAL*UCSTST.PERSONNEL)

3–58 7831 4077–009

 Application Programming in a Batch or Demand Environment

OWNER IS DEPARTMENT
MEMBER IS INDIVIDUAL AUTOMATIC
LINKED TO OWNER
ASCENDING KEY IS IND-LAST-NAME, IND-FIRST-NAME
DUPLICATES ARE LAST
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET
SET JOB-IND
CODE IS 202
MODE IS CHAIN
ORDER IS SORTED
OWNER IS JOBINFO
MEMBER IS INDIVIDUAL AUTOMATIC
LINKED TO OWNER
ASCENDING KEY IS IND-LAST-NAME, IND-FIRST-NAME
DUPLICATES ARE LAST
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET
SET EMPNO-IND
CODE IS 203
MODE IS CHAIN
ORDER IS NEXT
OWNER IS EMPNUMBER
MEMBER IS INDIVIDUAL AUTOMATIC
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET

Example 3–10. Source Listing of the Schema (QUAL*UCSTST.PERSONNEL)

7831 4077–009 3–59

Application Programming in a Batch or Demand Environment

Source Listing of the DMS 2200 Subschema

Example 3–11 shows a source listing of the subschema PERSONSUB. The subschema
resides in the element QUAL*UCSTST.PERSONSUB. The subschema is for UCS
COBOL host language programs.

IDENTIFICATION DIVISION
SUBSCHEMA NAME IS PERSONSUB IN FILE SCHFILE
OF SCHEMA PERSONNEL
HOST LANGUAGE IS UCS COBOL
DATA DIVISION
DATA NAME SECTION.
DATA NAMES ARE ALL
AREA SECTION.
AREAS ARE ALL
RECORD SECTION.
RECORDS ARE ALL
SET SECTION.
SETS ARE ALL

Example 3–11. Source Listing of the Schema (QUAL*UCSTST.PERSONSUB)

3–60 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–12 shows the source listing of the runstream used to process the schema
PERSONNEL and the subschema PERSONSUB. (This runstream could, for example, be
executed using an @START or @ADD statement.) Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE DMS DATABASE DEFINITION SECTION **********
@ . ***
@ . ***
@ . *** CATALOG: THE FILE THAT WILL HOLD THE SCHEMA AND SUBSCHEMA
@ . *** THE DATABASE STORAGE AREA FILES
@ . ***
@CAT,P UDS$$SVN*SCHFILE.,F///5000
@CAT,P UDS$$SVN*DEPTAREA.,F/3//3
@CAT,P UDS$$SVN*JOBAREA.,F/3//3
@CAT,P UDS$$SVN*EMPNOAREA.,F/250//250
@CAT,P UDS$$SVN*INDAREA.,F/1000//1000
@CAT,P UDS$$SVN*INDINDEX.,F/1//1
@ . ***
@ . ***
@ . *** USE THE DDL PROCESSOR TO PRODUCE ABSOLUTE SCHEMA TABLES AND
@ . *** TO PLACE INFORMATION ABOUT THE SCHEMA IN THE REPOSITORY DATABASE
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
@UDS$$SVN*DMRMT$.DDL,DN QUAL*UCSTST.PERSONNEL,UDS$$SVN*SCHFILE.PERSONNEL
@ . ***
@ . ***
@ . *** USE THE SDDL PROCESSOR TO PRODUCE SUBSCHEMA TABLES AND TO PLACE
@ . *** INFORMATION ABOUT THE SUBSCHEMA IN THE REPOSITORY DATABASE
@ . ***
@ . *** COBOL: NOTE THAT THE F-OPTION IS NO LONGER REQUIRED ON THE SDDL
@ . *** CALL FOR UCS COBOL SUBSCHEMAS.
@ . ***
@ . ***
@ . *** THE SDDL PROCESSOR CREATES A PROC THAT CONTAINS THE DATA DIVISION
@ . *** ENTRIES FOR THE DATABASE DATA NAMES AND THE DATABASE RECORDS THAT
@ . *** WILL BE COPIED INTO THE USER PROGRAM BY THE UCS COMPILER. AS
@ . *** PART OF THE SDDL PROCESS THIS PROC IS AUTOMATICALLY PDP'ED.
@ . ***
@UDS$$SVN*DMRMT$.SDDL,DN QUAL*UCSTST.PERSONSUB,UDS$$SVN*SCHFILE.PERSONSUB
@ . ***
@ . ***
@ . *** USE THE INFORMATION PLACED IN THE REPOSITORY DATABASE BY THE DDL

Example 3–12. Runstream to Process Schema and Subschema

7831 4077–009 3–61

Application Programming in a Batch or Demand Environment

@ . *** AND SDDL PROCESSORS TO CREATE SCHEMA AND SUBSCHEMA INFORMATION

@ . *** IN THE REPOSITORY AND PRODUCE THEIR FILE DESCRIPTION TABLES (FDTs).
@ . ***
@UDS$$SVN*UREP$ABS.DD,ES ,,APPSVN
PROCESS SCHEMA PERSONNEL INSTALL.
PROCESS SUBSCHEMA PERSONSUB FOR SCHEMA PERSONNEL INSTALL.
EXIT.
@ . ***
@ . ***
@ . *** ******** END OF THE DMS DATABASE DEFINITION SECTION ***********

Example 3–12. Runstream to Process Schema and Subschema

3–62 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–13 shows the execution of the runstream used to process the schema and
subschema. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . ***
@ . *** ******** START OF THE DMS DATABASE DEFINITION SECTION **********
@ . ***
@ . ***
@ . *** CATALOG: THE FILE THAT WILL HOLD THE SCHEMA AND SUBSCHEMA
@ . *** THE DATABASE STORAGE AREA FILES
@ . ***
@CAT,P UDS$$SVN*SCHFILE.,F///5000
I:002333 CAT complete.
@CAT,P UDS$$SVN*DEPTAREA.,F/3//3
I:002333 CAT complete.
@CAT,P UDS$$SVN*JOBAREA.,F/3//3
I:002333 CAT complete.
@CAT,P UDS$$SVN*EMPNOAREA.,F/250//250
I:002333 CAT complete.
@CAT,P UDS$$SVN*INDAREA.,F/1000//1000
I:002333 CAT complete.
@CAT,P UDS$$SVN*INDINDEX.,F/1//1
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** USE THE DDL PROCESSOR TO PRODUCE ABSOLUTE SCHEMA TABLES AND
@ . *** TO PLACE INFORMATION ABOUT THE SCHEMA IN THE REPOSITORY DATABASE
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
I:002333 ASG complete.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
I:002333 USE complete.
@UDS$$SVN*DMRMT$.DDL,DN QUAL*UCSTST.PERSONNEL,UDS$$SVN*SCHFILE.PERSONNEL
DDL PROCESSOR LEVEL :
DMS 1100 BUILD ID

END DDL 0 WARNING 0 FATAL 0 SYNTAX

TIME: TOTAL: 00:00:08.620 CLOCK TIME: 00:00:08.881

CPU: 00:00:00.517 I/O: 00:00:05.359

CC/ER: 00:00:02.746

Example 3–13. Execution of Source Runstream—DMS Database Setup

7831 4077–009 3–63

Application Programming in a Batch or Demand Environment

@ . ***
@ . ***
@ . *** USE THE SDDL PROCESSOR TO PRODUCE SUBSCHEMA TABLES AND TO PLACE
@ . *** INFORMATION ABOUT THE SUBSCHEMA IN THE REPOSITORY DATABASE
@ . ***
@ . *** COBOL: NOTE THAT THE F-OPTION IS NO LONGER REQUIRED ON THE SDDL
@ . *** CALL FOR UCS COBOL SUBSCHEMAS.
@ . ***
@ . ***
@ . *** THE SDDL PROCESSOR CREATES A PROC THAT CONTAINS THE DATA DIVISION
@ . *** ENTRIES FOR THE DATABASE DATA NAMES AND THE DATABASE RECORDS THAT
@ . *** WILL BE COPIED INTO THE USER PROGRAM BY THE UCS COMPILER. AS
@ . *** PART OF THE SDDL PROCESS THIS PROC IS AUTOMATICALLY PDP'ED.
@ . ***
@UDS$$SVN*DMRMT$.SDDL,DN QUAL*UCSTST.PERSONSUB,UDS$$SVN*SCHFILE.PERSONSUB
SDDL PROCESSOR LEVEL :
DMS 1100 BUILD ID

END SDDL 0 WARNING 0 FATAL 0 SYNTAX

TIME: TOTAL: 00:00:08.758 CLOCK TIME: 00:00:10.345

CPU: 00:00:00.382 I/O: 00:00:03.707

CC/ER: 00:00:04.670
@PDP,CN DSF$.X$PROC/PERSONSUB,PDP$$$SO$$$.S$PROC/PERSONSUB
PDP 13R1J (931108 0108:39) 1994 Jan 28 Fri 1417:06
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 22 Entry Points: 2 Time: 1.164 Storage: 7070/0/7070/0106210
@FREE,A PDP$$$SO$$$.
I:002333 FREE complete.
@ . ***
@ . ***
@ . *** USE THE INFORMATION PLACED IN THE REPOSITORY DATABASE BY THE DDL
@ . *** AND SDDL PROCESSORS TO CREATE SCHEMA AND SUBSCHEMA INFORMATION
@ . *** IN THE REPOSITORY AND PRODUCE THEIR FILE DESCRIPTION TABLES (FDTs).
@ . ***
@UDS$$SVN*UREP$ABS.DD,ES ,,APPSVN
UREP 3R2 (11/04/93 10:17:39) 01/28/94 14:17:08
1 PROCESS SCHEMA PERSONNEL INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA SCHEMA VERSION ABS for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA DEPTAREA VERSION ' ' for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA JOBAREA VERSION ' ' for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA EMPNOAREA VERSION ' ' for SCHEMA

Example 3–13. Execution of Source Runstream—DMS Database Setup

3–64 7831 4077–009

 Application Programming in a Batch or Demand Environment

PERSONNEL was SUCCESSFUL.

*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDAREA VERSION ' ' for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDINDEX VERSION ' ' for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4039 The PROCESS SCHEMA PERSONNEL is successfully completed.
2 PROCESS SUBSCHEMA PERSONSUB FOR SCHEMA PERSONNEL INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA PERSONSUB VERSION ABS for SCHEMA
PERSONNEL was SUCCESSFUL.
*REMARK* DSD4039 The PROCESS SUBSCHEMA PERSONSUB is successfully completed.
3 EXIT.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 9 )REMARKS .
@ . ***
@ . ***
@ . *** ******** END OF THE DMS DATABASE DEFINITION SECTION ***********

Example 3–13. Execution of Source Runstream—DMS Database Setup

7831 4077–009 3–65

Application Programming in a Batch or Demand Environment

3.2.1.5. Coding UCS DML Programs

The data manipulation language (DML) provides a set of commands for accessing a
DMS 2200 database.

A UCS DML program must identify a subschema that contains a HOST LANGUAGE IS
UCS clause in the INVOKE statement.

The syntax for DML commands in UCS programs is identical to the syntax supported
for non-UCS programs.

The following figure summarizes a simple UCS DML program described in the
following subsections. The program
1. Reads an employee number
2. Accesses information about that individual from the DMS 2200 database
3. Displays the data
IDENTIFICATION DIVISION.
PROGRAM-ID. DISPLAYIND.
.
.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE .....
.
.
WORKING-STORAGE SECTION.
01 EMPLOYEE-NUMBER ....
PROCEDURE DIVISION.
ACCEPT EMPLOYEE-NUMBER
IMPART
OPEN .... RETRIEVAL
FETCHs ....
DISPLAYs .....
DEPART
STOP RUN.

Refer to the DMS CDML Operations and Programming Reference Manual for more
information on coding UCS COBOL DML programs. Refer to the DMS FDML
Operations and Programming Reference Manual for more information on coding UCS
FORTRAN DML programs.

3–66 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.1.6. Compiling UCS DML Programs

UCS compilers directly process DML source statements, converting them into an
executable form. The UCS compilers parse both
• The host language syntax
• The DML syntax

The ASCII COBOL DML (ADML) and FORTRAN DML (FDML) preprocessors required for
non-UCS programs are not needed and no longer exist in UCS.

Since there is no preprocessing, no independent D$WORK element is created.

Instead, D$WORK is an integral part of the object module produced by the UCS
compiler.

As shown in the preceding figure, compilation of a UCS program containing DML

statements involves the following steps:
1. When you compile a UCS DML program, the subschema file (UDS$$SVN*SCHFILE.
in the illustration) must be available to the UCS compiler. This means that prior to
calling the compiler, you must
a. Assign the subschema file
b. Attach an @USE name to the subschema file
The @USE name is required if the compilation is taking place under a project-id
different from the qualifier of the subschema file. Since the INVOKE
statement has no syntax to identify the qualifier of the subschema file, the
following occurs:

7831 4077–009 3–67

Application Programming in a Batch or Demand Environment

1) The compiler first looks for a file with the @USE name of the subschema
file name.
2) If it does not find such a file, the compiler tries to assign the subschema
file, using the run’s project-id as the subschema file’s qualifier.
2. When compiling a UCS COBOL program containing DML statements, you must
specify the COMPAT keyword option on the compiler call (only if including COMP-1
or COMP-2 items in the subschema). The COMPAT keyword option causes the
compiler to interpret these as if they were the correct COBOL 85 format.
No special keyword options are required for compilation of UCS FORTRAN DML
programs.

3. The UCS compilers access the object subschema and the S$PROC symbolic
element from the subschema file while parsing the DML syntax.
4. The output of the compiler is an object module that includes the D$WORK
information.

The following statements show how to compile the UCS COBOL DML program
illustrated in this section.
@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE,UDS$$SVN*SCHFILE.
@UCOB,S QUAL*UCSTST.DISPLAYIND,QUAL*UCSTST.DISPLAYIND/COMP,,,;
NO-OPTIONS, NO-REMARK

3–68 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.1.7. Basic Linking Information for UCS DML Programs

When statically or dynamically linking a UCS program containing DML statements, you
must specify use of a special application group library search chain by using an @USE
LINK$PF statement. This library search chain causes the Linking System to resolve
references using the DMS 2200 software for a particular application group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the DMS 2200 interface
during static linking

The following generic format shows how to specify use of the appropriate application
group library search chain:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program containing DML statements to the system software
in application group 7, use the following statement:
@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to DMS 2200 software would be resolved using
UDS$$SVN*D$MR.

For more information on these library search chains, see Section 4.

7831 4077–009 3–69

Application Programming in a Batch or Demand Environment

Ensuring That the Linking System Finds S$WORK

When linking a UCS program containing DML statements, the Linking System needs to
locate the S$WORK object module.

Dynamic Linking
For dynamic linking, you can use one of the following ways to ensure that the Linking
System can locate S$WORK:
• Copy the S$WORK object module to the program file from which the UCS
compiler-generated object module is executed. This is the file represented by
HOME$. (This method is used in the dynamic linking example shown in
“Dynamically Linking a UCS DML Program” which follows.)
• Set up a user-defined library search chain that searches both
− The file containing S$WORK
− The files containing the system software for the appropriate application group
Then specify an @USE LINK$PF statement to identify this library search chain.
You must include the files containing the system software for the appropriate
application group in the user-defined library search chain because only one @USE
LINK$PF statement is allowed. If you specify a LINK$PF that represents a
user-defined library search chain, it cannot also represent the application group library
search chain built by the system.

Static Linking
For static linking, you can use one of the following ways to ensure that the Linking
System can locate S$WORK:
• Explicitly supply (INCLUDE) the S$WORK object module from the subschema file.
(This method is used in the static linking example shown in "Statically Linking a
UCS DML Program," which follows.)
• Specify the file containing S$WORK in the USING clause of the RESOLVE
command.
• Set up a user-defined library search chain that searches both
− The file containing S$WORK
− The files containing the system software for the appropriate application group
Then specify an @USE LINK$PF statement to identify this library search chain.

3–70 7831 4077–009

 Application Programming in a Batch or Demand Environment

Dynamically Linking a UCS DML Program

When you execute a UCS program containing DML statements, you can use dynamic
linking. This requires the following:
1. Copy the S$WORK object module to the file where the object module produced
by the UCS compiler resides.
This is done so the dynamic linker can locate S$WORK. When resolving references,
the dynamic linker always searches the file from which the program is executed (this
file is known as HOME$).

2. Before executing the program, specify use of the application group library search
chain by using the @USE LINK$PF statement.
3. Now the UCS compiler-produced object module is ready for execution.

The following example shows how to compile and execute a UCS DML program, using
dynamic linking.

@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE,UDS$$SVN*SCHFILE.
@UCOB QUAL*UCSTST.LOADDMSDB,QUAL*UCSTST.LOADDMSDB/COMP,,, ;
NO-OPTIONS

@COPY,A UDS$$SVN*SCHFILE.S$WORK/PERSONSUB,QUAL*UCSTST.

@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*UCSTST.LOADDMSDB/COMP

7831 4077–009 3–71

Application Programming in a Batch or Demand Environment

Statically Linking a UCS DML Program

You can statically link a UCS program containing DML statements. The following
steps are involved:
1. Specify use of the application group library search chain, using an @USE LINK$PF
statement.
2. Call the LINK Processor (@LINK).
3. Specify static linking commands, including commands that identify
• The program’s compiler-produced object module
• The subschema’s S$WORK object module

The output of this static link can be a standard object module, a bound object module,
or a zero overhead object module.

3–72 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following example shows how to statically link a UCS program containing DML
statements, producing a zero overhead object module:

(1) @USE LINK$PF,SYS$LIB$*APP$7.

(2) @LINK ,QUAL*UCSTST.DISPLAYIND
(3) INCLUDE QUAL*UCSTST.DISPLAYIND/COMP
(4) INCLUDE UDS$$SVN*SCHFILE.S$WORK/PERSONSUB
(5) RESOLVE ALL REFERENCES USING LIBCODENAME
(6) PROCESS FOR EXTENDED ZOOM
(7) DELETE ALL DEFINITIONS EXCEPT START$
(8) @EOF

Explanation:
1. This statement ensures that the program is statically linked using the DMS 2200
software located in the desired application group. (It ensures that the library
search chain for the correct application group is used.) In this example, this
program is to execute in application group 7.
2. This statement calls the Linking System LINK Processor. The zero overhead object
module (ZOOM) to be produced is named QUAL*UCSTST.DISPLAYIND.
3. This command identifies the compiler-generated object module containing the
UCS DML program.
4. This command identifies the object module generated by SDDL that contains the
subschema’s S$WORK element.
5. This command resolves external references, including those to the UCS Runtime
System library.
6. This command merges banks and produces a zero overhead object module.
7. This command deletes all definitions except the program’s starting address,
START$. This decreases the size of the ZOOM.
8. This statement ends static linking.

7831 4077–009 3–73

Application Programming in a Batch or Demand Environment

3.2.1.8. Example of a UCS Program Containing DML Statements

The following subsections show an example of compiling, linking, and executing the
following:
• A database load program
The load program uses dynamic linking.
(Due to the length of the load program, its source listing is not provided.)

• A database retrieval program

The retrieval program is statically linked to produce a zero overhead object module.

3–74 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of the UCS DML Program (DISPLAYIND)

Example 3–14 shows the source listing of the UCS DML program DISPLAYIND. This
program accepts an employee number as input and displays the information contained
in this database about this individual’s job. In this example, this program resides in
element QUAL*UCSTST.DISPLAYIND. Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DISPLAYIND INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL DML PROGRAM - DISPLAYIND *
* *
* reads the input data *
* imparts to the PERSONNEL database *
* retrieves the requested information from the database *
* displays this on the printer *
* departs from the PERSONNEL database *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUB IN FILE SCHFILE
OF SCHEMA PERSONNEL
COPYING RECORDS INTO WORKING
COPYING DATA-NAMES INTO WORKING
RUN-UNIT-ID DSPIND
DMCA IS WORKING
ERROR DMS-GENERAL-ERROR-PARA.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 INVALID-EMPLOYEE-NUMBER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER.

Example 3–14. Source Listing of DML Program (QUAL*UCSTST.DISPLAYIND)

7831 4077–009 3–75

Application Programming in a Batch or Demand Environment

05 EMP-PAGE PIC 9(3).

05 EMP-RECORD PIC 9(2).
*
PROCEDURE DIVISION.
************************************************************
* PROGRAM FLOW
************************************************************
MAIN-PROGRAM-FLOW.
DISPLAY 'ENTER EMPLOYEE NUMBER' UPON PRINTER.
ACCEPT EMPLOYEE-NUMBER.
IF EMP-PAGE > 99 AND EMP-RECORD > 0
PERFORM IMPART-TO-DMS
PERFORM DATABASE-RECORD-RETRIEVAL
PERFORM DISPLAY-INDIVIDUAL-DATA
PERFORM DATABASE-DEPART-PARA
ELSE DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
END-IF.
PERFORM TERMINATION-PARA.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
* OPEN ALL DATABASE STORAGE AREAS FOR RETRIEVAL OF
* DATA ONLY, NO DATA UPDATE IS ALLOWED
************************************************************
IMPART-TO-DMS.
IMPART.
OPEN ALL USAGE-MODE IS RETRIEVAL.
************************************************************
* RETRIEVE THE INDIVIDUAL'S INFORMATION FROM THE
* DATABASE
************************************************************
DATABASE-RECORD-RETRIEVAL.
MOVE 'EMPNOAREA' TO EMPNO-AREA-NAME.
MOVE EMP-PAGE TO PAGE-NUM OF EMPNO-AREA-KEY.
MOVE EMP-RECORD TO RECORD-NUM OF EMPNO-AREA-KEY.
FETCH EMPNUMBER RECORD.
FETCH NEXT RECORD WITHIN EMPNO-IND SET.
FETCH OWNER RECORD WITHIN DEPT-IND SET.
FETCH OWNER RECORD WITHIN JOB-IND SET.
************************************************************
* DISPLAY THE INDIVIDUAL'S INFORMATION TO THE PRINTER
************************************************************
DISPLAY-INDIVIDUAL-DATA.
DISPLAY 'INDIVIDUAL DATA ' UPON PRINTER.
DISPLAY ' EMPLOYEE NUMBER IS ' EMP-NUMBER UPON PRINTER.
DISPLAY ' LAST NAME: ' IND-LAST-NAME UPON PRINTER.
DISPLAY ' FIRST NAME: ' IND-FIRST-NAME UPON PRINTER.

Example 3–14. Source Listing of DML Program (QUAL*UCSTST.DISPLAYIND)

3–76 7831 4077–009

 Application Programming in a Batch or Demand Environment

DISPLAY ' THIS INDIVIDUAL WORKS IN THE ' DEPT-NAME

' DEPARTMENT' UPON PRINTER.
DISPLAY ' DEPARTMENT NUMBER: ' DEPT-NO UPON PRINTER.
DISPLAY ' THIS DEPARTMENT ' DEPT-DESCRIPTION UPON PRINTER.
DISPLAY ' THIS INDIVIDUAL IS A ' JOB-TITLE UPON PRINTER.
DISPLAY ' WHO ' JOB-DESCRIPTION UPON PRINTER.
DISPLAY ' AND IS PAID $' JOB-SALARY ' A YEAR.'
UPON PRINTER.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************
DATABASE-DEPART-PARA.
DEPART.
************************************************************
* TERMINATE PROGRAM
************************************************************
TERMINATION-PARA.
DISPLAY 'PROGRAM HAS COMPLETED' UPON PRINTER.
STOP RUN.
*
*
************************************************************
* CHECK FOR A '0013' ERROR,
* IF THIS ERROR OCCURRED THE
* INVALID-EMPLOYEE-NUMBER MESSAGE IS PRINTED
* ELSE THE ERROR MESSAGE IS RETURNED ON THE PRINTER
* FOR DEBUGGING.
************************************************************
DMS-GENERAL-ERROR-PARA.
IF ERROR-NUM = '0013'
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
ELSE DISPLAY 'DMS-GENERAL-ERROR-PARA.' UPON PRINTER
DISPLAY 'AREA = ' ERROR-AREA UPON PRINTER
DISPLAY 'RECORD = ' ERROR-RECORD UPON PRINTER
DISPLAY 'SET = ' ERROR-SET UPON PRINTER
DISPLAY 'ROLLBACK = ' RB-ERROR-CODE UPON PRINTER
DISPLAY 'FUNCTION = ' ERROR-FUNCTION UPON PRINTER
DISPLAY 'ERR NUM = ' ERROR-NUM UPON PRINTER
END-IF.
IF IMPART-DEPART EQUAL TO 1 PERFORM DATABASE-DEPART-PARA.
PERFORM TERMINATION-PARA.

Example 3–14. Source Listing of DML Program (QUAL*UCSTST.DISPLAYIND)

7831 4077–009 3–77

Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–15 shows the source listing of a runstream used to compile, link, and
execute the database load program LOADDMSDB and the database retrieval program
DISPLAYIND. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE SECTION *************************
@ . ***
@ . ***
@ . *** COMPILE OF THE INITIAL LOAD PROGRAM AND THE DML RETRIEVAL PROGRAM
@ . ***
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE,UDS$$SVN*SCHFILE.
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADDMSDB,QUAL*UCSTST.LOADDMSDB/COMP,,, ;
NO-OPTIONS
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.DISPLAYIND,QUAL*UCSTST.DISPLAYIND/COMP,,,;
NO-OPTIONS
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE SUBSCHEMA ABSOLUTE IS COPIED TO QUAL*UCSTST. (HOME$)
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@COPY,A UDS$$SVN*SCHFILE.S$WORK/PERSONSUB,QUAL*UCSTST.

Example 3–15. Runstream to Compile, Link, and Execute—COBOL DMS Program

3–78 7831 4077–009

 Application Programming in a Batch or Demand Environment

@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*UCSTST.LOADDMSDB/COMP
@ . ***
@ . ***
@ . *** STATIC LINK OF THE RETRIEVAL PROGRAM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DISPLAYIND
INCLUDE QUAL*UCSTST.DISPLAYIND/COMP
INCLUDE UDS$$SVN*SCHFILE.S$WORK/PERSONSUB
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THE RETRIEVAL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DISPLAYIND
10211
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–15. Runstream to Compile, Link, and Execute—COBOL DMS Program

7831 4077–009 3–79

Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–16 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE SECTION *************************
@ . ***
@ . ***
@ . *** COMPILE OF THE INITIAL LOAD PROGRAM AND THE DML RETRIEVAL PROGRAM
@ . ***
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
W:120533 filename not unique.
W:120133 file is already assigned.
@USE SCHFILE,UDS$$SVN*SCHFILE.
I:002333 USE complete.
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADDMSDB,QUAL*UCSTST.LOADDMSDB/COMP,,, ;
NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 14:22:02
SIZES: CODE(EM6): 1701 DATA: 2098
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.DISPLAYIND,QUAL*UCSTST.DISPLAYIND/COMP,,,;
NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 14:22:19
SIZES: CODE(EM6): 465 DATA: 1231
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE SUBSCHEMA ABSOLUTE IS COPIED TO QUAL*UCSTST. (HOME$)

Example 3–16. Execution of Source Runstream—COBOL DMS Program

3–80 7831 4077–009

 Application Programming in a Batch or Demand Environment

@ . *** APPLICATION GROUP:

@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@COPY,A UDS$$SVN*SCHFILE.S$WORK/PERSONSUB,QUAL*UCSTST.
FURPUR 30R5 (930309 0913:23) 1994 Jan 28 Fri 1422:27
1 ABS
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@XQT QUAL*UCSTST.LOADDMSDB/COMP

IMPARTED

DATABASE AREAS ARE OPEN FOR INITIAL LOAD

DEPARTMENT RECORDS ARE LOADED

JOBINFO RECORDS ARE LOADED

EMPNUMBER RECORDS ARE LOADED

INDIVIDUAL RECORDS ARE LOADED

INITIAL LOAD COMPLETED

*******************

DATABASE VALIDATION

EMPNO FIRST NAME LAST NAME DEPARTMENT NAME JOB TITLE

24101 MARY ANDERSON APPLICATION DEVELOPMENT CONSULTANT

26504 JOHN BLAKE APPLICATION SUPPORT PROGRAMMER

26510 GEORGE CARR APPLICATION SUPPORT SYSTEMS ANALYST

10211 STEVEN FIELDING APPLICATION DEVELOPMENT PROGRAMMER

10215 JENNIFER HELLER APPLICATION DEVELOPMENT PROGRAMMER

32009 JAKE KAISER APPLICATION DEVELOPMENT SYSTEMS ANALYST

26503 RALPH MILLER APPLICATION DEVELOPMENT TEAM LEADER

10223 KAREN RALSTON APPLICATION SUPPORT TEAM LEADER

Example 3–16. Execution of Source Runstream—COBOL DMS Program

7831 4077–009 3–81

Application Programming in a Batch or Demand Environment

****

**** 0008 INDIVIDUAL RECORDS ARE LOADED

DATABASE LOAD HAS BEEN VALIDATED

@ . ***
@ . ***
@ . *** STATIC LINK OF THE RETRIEVAL PROGRAM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DISPLAYIND
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1423:18
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THE RETRIEVAL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DISPLAYIND

ENTER EMPLOYEE NUMBER

INDIVIDUAL DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

THIS INDIVIDUAL WORKS IN THE APPLICATION DEVELOPMENT DEPARTMENT

DEPARTMENT NUMBER: 4124

THIS DEPARTMENT DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION CODE

THIS INDIVIDUAL IS A PROGRAMMER

WHO DESIGNS, WRITES, AND TESTS CODE

AND IS PAID $4000 A YEAR.

Example 3–16. Execution of Source Runstream—COBOL DMS Program

3–82 7831 4077–009

 Application Programming in a Batch or Demand Environment

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–16. Execution of Source Runstream—COBOL DMS Program

3.2.2. Using RDMS 2200 Databases

UCS programming supports the Relational Data Management System (RDMS 2200)
software:
• Both batch and demand processing modes
• The interpreter (non-embedded) SQL form
• Embedded SQL interface (entry level SQL92)
• Module SQL interface (entry level SQL92).

The following table describes features within each UCS product:

Software Interface Type

UCS COBOL Interpreter SQL
UCS COBOL Embedded SQL
UCS FORTRAN Interpreter SQL
UCS FORTRAN Module SQL
UCS C Interpreter SQL
UCS C Embedded SQL
UCS TIP/HVTIP Interpreter SQL (for COBOL,
FORTRAN, C)
UCS TIP/HVTIP Embedded SQL (for COBOL)
UCS TIP/HVTIP Embedded SQL (for C)
UCS TIP/HVTIP Module SQL (for FORTRAN)

7831 4077–009 3–83

Application Programming in a Batch or Demand Environment

The following subsections describe the steps involved in creating and accessing an
RDMS 2200 database using UCS. They discuss
• Table definitions
• SQL application programs

The implementation of both embedded SQL and module SQL as implemented by UCS
and RDMS 2200 conform to the following standards:
• ANSI Systems—Database Language—Embedded SQL (ANSI number: X3.168-1988
(Revised)).
• ANSI Systems—Database Language—SQL (ANSI number: X3.135.1-1989 (Revised))
• Federal Information Processing Standards Publication 127-2 (FIPS 127-2)
• ANSI Systems—Database Language—Embedded SQL (ANSI number: X3.135-1992
(entry-level)).

3.2.2.1. RDMS 2200 Tables

Relational databases are composed of two-dimensional tables with rows and columns.

RDMS 2200 tables are kept in storage areas. You define storage areas by using the
Unisys Repository Manager (UREP).

Once you have defined the storage areas for the tables, you can define the tables
themselves using one of the following ways:
• By using the IPF SQL Interface
• By coding an SQL program
• By using the MAPPER Relational Interface (MRI)

When you define a table, UREP makes an entry in the Unisys repository that
symbolically describes the table’s characteristics (for example, table names and
column names).

Coding an RDMS 2200 table definition has no special constraints in UCS. Existing table
definitions being used by non-UCS SQL programs can be used without change by UCS
interpreted SQL, embedded SQL, and module language SQL programs.

RDMS 2200 tables can be loaded by using one of the following:

• By the RDMS 2200 load utility, RDMUTL
• By an SQL program
• By using the MAPPER Relational Interface (MRI)

Refer to the RDMS Administration Guide for more information on RDMS 2200 storage
areas and tables.

The following figure shows the tables that are used in the RDMS 2200 example for
this section.

3–84 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following is a brief description of the table types in this database.

INDIVIDUALR
is a table whose primary key is the individual’s employee number (INDR-EMP-
NUMBER). The table also has a secondary index consisting of the individual’s
name (indr-last-name, indr-first-name).

SCHOOL
is a table whose a primary key is the school’s unique number (SCH-NUMBER).

CHILD
is a table whose primary key is the individual’s employee number (CHILD-EMP-
NUMBER) and the sequential number of the child in the family (CHILD-NUMBER).
The table also has a secondary index consisting of the child’s name (child-last-
name, child-first-name). The child’s school number (child-school-number) is a
foreign key to the SCHOOL table. The child’s employee number (CHILD-EMP-
NUMBER) is a foreign key to the INDIVIDUALR table. To keep the programs
simple, this example assumes that no individual will have more than three children.

7831 4077–009 3–85

Application Programming in a Batch or Demand Environment

3.2.2.2. Example of an RDMS 2200 Database Definition

The following subsections show a sample set of tables being set up for use by UCS
programs:
• The IPF SQL interface is used to define the tables.
• The RDMS 2200 load utility, RDMUTL, is used to load the data into the tables.

Source Listing of the Table Definitions (INDIVIDUALR, SCHOOL, CHILD)

Example 3–17 shows the source listing of the table definitions for the tables
INDIVIDUALR, SCHOOL, and CHILD. This source is used as input to the IPF SQL
interface. In this example, these table definitions reside in element
QUAL*UCSTST.TABLES.

SQL USE DEFAULT QUALIFIER FAMILY

SQL CREATE TABLE INDIVIDUALR IN FAMILY.INDRAREA &
COLUMNS ARE INDR_EMP_NUMBER : CHARACTER (5) NOT NULL, &
INDR_LAST_NAME : CHARACTER (20) NOT NULL, &
INDR_FIRST_NAME : CHARACTER (12) NOT NULL, &
INDR_BIRTH_DATE : CHARACTER (6) NOT NULL, &
INDR_SPOUSE_LAST_NAME : CHARACTER (20), &
INDR_SPOUSE_FIRST_NAME : CHARACTER (12) &
PRIMARY KEY PRI_INDR IS INDR_EMP_NUMBER ASCENDING &
INDEX SEC_INDNAME ON INDR_LAST_NAME ASCENDING, &
INDR_FIRST_NAME ASCENDING
SQL CREATE TABLE SCHOOL IN FAMILY.SCHOOLAREA &
COLUMNS ARE SCH_NUMBER : CHARACTER (4) NOT NULL, &
SCH_NAME : CHARACTER (25) NOT NULL, &
SCH_START_GRADE : CHARACTER (2) NOT NULL, &
SCH_END_GRADE : CHARACTER (2) NOT NULL &
PRIMARY KEY PRI_SCH IS SCH_NUMBER ASCENDING
SQL CREATE TABLE CHILD IN FAMILY.CHILDAREA &
COLUMNS ARE CHILD_EMP_NUMBER : CHARACTER (5) NOT NULL, &
CHILD_NUMBER : CHARACTER (3) NOT NULL, &
CHILD_LAST_NAME : CHARACTER (20) NOT NULL, &
CHILD_FIRST_NAME : CHARACTER (12) NOT NULL, &
CHILD_BIRTH_DATE : CHARACTER (6) NOT NULL, &
CHILD_SCHOOL_NUMBER : CHARACTER (4), &
CHILD_GRADE_AVERAGE : NUMERIC (5.3) &
PRIMARY KEY PRI_INDR IS CHILD_EMP_NUMBER ASCENDING, &
CHILD_NUMBER ASCENDING &
FOREIGN KEY FOR_SCH IS CHILD_SCHOOL_NUMBER &
REFERS TO SCH_NUMBER OF SCHOOL &
FOREIGN KEY FOR_EMP IS CHILD_EMP_NUMBER &
REFERS TO INDR_EMP_NUMBER OF INDIVIDUALR &
INDEX SEC_CHDNAME ON CHILD_LAST_NAME ASCENDING, &
CHILD_FIRST_NAME ASCENDING

Example 3–17. Source Listing of the Table Definitions (QUAL*UCSTST.TABLES)

3–86 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of the Table Load Data

Example 3–18 is the source listing of the load data for the INDIVIDUALR table. For this
example, the INDIVIDUALR load data resides in the file QUAL*INDLOAD.

>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.
COLUMNS FIELD NAME RDMS FORMAT
======= ========== ===========
1-5 INDR_EMP_NUMBER CHARACTER (5) NOT NULL primary key
7-26 INDR_LAST_NAME CHARACTER (20) NOT NULL
28-39 INDR_FIRST_NAME CHARACTER (12) NOT NULL
41-46 INDR_BIRTH_DATE CHARACTER (6) NOT NULL
48-57 INDR-SPOUSE_LAST_NAME CHARACTER (20) NULLS ALLOWED
59-70 INDR-SPOUSE_FIRST_NAME CHARACTER (12) NULLS ALLOWED

>END DESCRIPTION<
10211 FIELDING STEVEN 480719 FIELDING KATHY
10215 HELLER JENNIFER 590529 * *
10223 RALSTON KAREN 580910 EASTMAN JOHN
24101 ANDERSON MARY 520803 ANDERSON FRED
26503 MILLER RALPH 470317 * *
26504 BLAKE JOHN 650714 * *
26510 CARR GEORGE 561123 CARR SUSAN
32009 KAISER JAKE 531008 WRIGHT ANGEL

Example 3–18. Source Listing of the Load Data for INDIVIDUALR Table
(QUAL*INDLOAD)

Example 3–19 is the source listing of the load data for the SCHOOL table. For this
example, the SCHOOL load data resides in the file QUAL*SCHLOAD.

.>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.

COLUMNS FIELD NAME RDMS FORMAT

======= ========== ===========
1-4 SCH_NUMBER CHARACTER (4) NOT NULL primary key
6-30 SCH_NAME CHARACTER (25) NOT NULL
32-33 SCH_START_GRADE CHARACTER (2) NOT NULL
35-36 SCH_END_GRADE CHARACTER (2) NOT NULL

>END DESCRIPTION<
1349 WOODBURY SENIOR HIGH 09 12
1361 EAGAN MIDDLE SCHOOL 06 08
2188 WESTERLY ELEMENTARY 01 05
3703 GLENVIEW ELEMENTARY 01 05

Example 3–19. Source Listing of the Load Data for SCHOOL Table
(QUAL*SCHLOAD)

7831 4077–009 3–87

Application Programming in a Batch or Demand Environment

Example 3–20 is the source listing of the load data for the CHILD table. For this
example, the CHILD load data resides in the file QUAL*CHILDLOAD.

>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.

COLUMNS FIELD NAME RDMS FORMAT

======= ========== ===========
1-5 CHILD_EMP_NUMBER CHARACTER (5) NOT NULL primary key
7-8 CHILD_NUMBER CHARACTER (2) NOT NULL primary key
10-29 CHILD_LAST_NAME CHARACTER (20) NOT NULL
31-42 CHILD_FIRST_NAME CHARACTER (12) NOT NULL
44-49 CHILD_BIRTH_DATE CHARACTER (6) NOT NULL
51-54 CHILD_SCHOOL_NUMBER CHARACTER (4) NULLS ALLOWED foreign key
56-60 CHILD_GRADE_AVERAGE NUMERIC (5.3) NULLS ALLOWED

>END DESCRIPTION<
10211 01 FIELDING STEVEN JR 680108 * *
10211 02 FIELDING DANIEL 710708 * *
10211 03 FIELDING JANE 760411 1349 3.500
10215 01 HELLER VANESSA 851002 * *
10223 01 EASTMAN JAMES 880912 * *
24101 01 ANDERSON SEAN 800611 3703 2.850
24101 02 ANDERSON MICHELLE 800611 3703 4.000
32009 01 KAISER JASON 780213 1361 3.500
32009 02 KAISER SHARON 830228 2188 3.250

Example 3–20. Source Listing of the Load Data for CHILD Table
(QUAL*CHILDLOAD)

3–88 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Runstream Example

Example 3–21 shows the source listing of the runstream used to define the RDMS
2200 storage areas and tables. The runstream also loads the table data. Noteworthy
lines are bolded.

@ . *** ******** START OF THE RDMS DATABASE DEFINITION SECTION **********

@ . ***
@ . *** CATALOG THE DATABASE STORAGE AREA FILES.
@ . ***
@CAT,P UDS$$SVN*INDRAREA.,F/20//20
@CAT,P UDS$$SVN*SCHOOLAREA.,F/5//5
@CAT,P UDS$$SVN*CHILDAREA.,F/20//20
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE RDMS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD ,,APPSVN
CREATE SCHEMA FAMILY.
CREATE STORAGE-AREA INDRAREA FOR SCHEMA FAMILY.
ADD FILE-TYPE IS EXEC.
ADD DATA-FORMAT IS RSM.
ADD FILE-NAME IS INDRAREA.
ADD QUALIFIER IS UDS$$SVN.
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 40.
ADD CHECKSUM IS NO.
CREATE STORAGE-AREA SCHOOLAREA FOR SCHEMA FAMILY.
ADD FILE-TYPE IS EXEC.
ADD DATA-FORMAT IS RSM.
ADD FILE-NAME IS SCHOOLAREA.
ADD QUALIFIER IS UDS$$SVN.
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 448.
ADD MAXIMUM-PAGES IS 20.
ADD CHECKSUM IS NO.
CREATE STORAGE-AREA CHILDAREA FOR SCHEMA FAMILY.
ADD FILE-TYPE IS EXEC.
ADD DATA-FORMAT IS RSM.

Example 3–21. Runstream to Define Storage Areas and Tables and Load Tables

7831 4077–009 3–89

Application Programming in a Batch or Demand Environment

ADD FILE-NAME IS CHILDAREA.

ADD QUALIFER IS UDS$$SVN
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 40.
ADD CHECKSUM IS NO.
PROCESS STORAGE-AREA ALL FOR SCHEMA FAMILY INSTALL.
EXIT.
@ . ***
@ . ***
@ . *** USE IPF SQL TO DEFINE THE RDMS TABLES
@ . ***
@IPF
MODE LINE
$DATAMANAGER := RDMS
SQL BEGIN THREAD DEFINETABLES FOR APPSVN UPDATE(COMMANDLOOK)
SQL FILE QUAL*UCSTST.TABLES
SQL END THREAD
LOGOFF
@ . ***
@ . ***
@ . *** LOAD THE RDMS DATABASE
@ . ***
@SYS$LIB$*RDMS.RDMUTL,S APPSVN
LOAD EXTERNAL FILE "QUAL*INDLOAD"
SORTED YES
LOAD FACTOR 50
INTO TABLE FAMILY.INDIVIDUALR
FORMAT INDR_EMP_NUMBER(1:5),
INDR_LAST_NAME(7:26),
INDR_FIRST_NAME(28:39),
INDR_BIRTH_DATE(41:46),
INDR_SPOUSE_LAST_NAME(48:57) NULLIF((48:48) = '*'),
INDR_SPOUSE_FIRST_NAME(59:70) NULLIF((59:59) = '*') ;
LOAD EXTERNAL FILE "QUAL*SCHLOAD"
SORTED YES
LOAD FACTOR 50
INTO TABLE FAMILY.SCHOOL
FORMAT SCH_NUMBER(1:4),
SCH_NAME(6:30),
SCH_START_GRADE(32:33),
SCH_END_GRADE(35:36) ;
LOAD EXTERNAL FILE "QUAL*CHILDLOAD"
SORTED YES

Example 3–21. Runstream to Define Storage Areas and Tables and Load Tables

3–90 7831 4077–009

 Application Programming in a Batch or Demand Environment

LOAD FACTOR 50
INTO TABLE FAMILY.CHILD
FORMAT CHILD_EMP_NUMBER(1:5),
CHILD_NUMBER(7:8),
CHILD_LAST_NAME(10:29),
CHILD_FIRST_NAME(31:42),
CHILD_BIRTH_DATE(44:49),
CHILD_SCHOOL_NUMBER(51:54) NULLIF((51:51) = '*'),
CHILD_GRADE_AVERAGE(56:60) NULLIF((56:56) = '*');
@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE RDMS DATABASE DEFINITION SECTION *************
@ . ***

Example 3–21. Runstream to Define Storage Areas and Tables and Load Tables

Execution of the Source Runstream

Example 3–22 shows the execution of the source runstream used to define the RDMS
2200 storage areas and tables, and load the table data. Output has been saved by an
@BRKPT statement.

Noteworthy lines are bolded.

@ . *** ******** START OF THE RDMS DATABASE DEFINITION SECTION **********

@ . ***
@ . ***
@ . *** CATALOG THE DATABASE STORAGE AREA FILES.
@ . ***
@CAT,P UDS$$SVN*INDRAREA.,F/20//20
I:002333 CAT complete.
@CAT,P UDS$$SVN*SCHOOLAREA.,F/5//5
I:002333 CAT complete.
@CAT,P UDS$$SVN*CHILDAREA.,F/20//20
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE RDMS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD ,,APPSVN
UREP 3R2 (11/04/93 10:17:39) 01/28/94 14:28:28
*REMARK* DSD4023 The INSTALL for STORAGE-AREA CHILDAREA VERSION ' ' for SCHEMA
FAMILY was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDRAREA VERSION ' ' for SCHEMA

Example 3–22. Execution of Source Runstream—RDMS Database Setup

7831 4077–009 3–91

Application Programming in a Batch or Demand Environment

FAMILY was SUCCESSFUL.

*REMARK* DSD4023 The INSTALL for STORAGE-AREA SCHOOLAREA VERSION ' ' for
SCHEMA FAMILY was SUCCESSFUL.
*REMARK* DSD4036 Your PROCESS STORAGE-AREA ALL command was successful.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 4 )REMARKS .
@ . ***
@ . ***
@ . *** USE IPF SQL TO DEFINE THE RDMS TABLES
@ . ***
@IPF
IPF 1100 6R3 01/28/94 14:28:59
SQL USE DEFAULT QUALIFIER FAMILY
The USE command completed successfully.
SQL CREATE TABLE INDIVIDUALR IN FAMILY.INDRAREA &
COLUMNS ARE INDR_EMP_NUMBER : CHARACTER (5) NOT NULL, &
INDR_LAST_NAME : CHARACTER (20) NOT NULL, &
INDR_FIRST_NAME : CHARACTER (12) NOT NULL, &
INDR_BIRTH_DATE : CHARACTER (6) NOT NULL, &
INDR_SPOUSE_LAST_NAME : CHARACTER (20), &
INDR_SPOUSE_FIRST_NAME : CHARACTER (12) &
PRIMARY KEY PRI_INDR IS INDR_EMP_NUMBER ASCENDING &
INDEX SEC_INDNAME ON INDR_LAST_NAME ASCENDING, &
INDR_FIRST_NAME ASCENDING
The CREATE TABLE command completed successfully.
SQL CREATE TABLE SCHOOL IN FAMILY.SCHOOLAREA &
COLUMNS ARE SCH_NUMBER : CHARACTER (4) NOT NULL, &
SCH_NAME : CHARACTER (25) NOT NULL, &
SCH_START_GRADE : CHARACTER (2) NOT NULL, &
SCH_END_GRADE : CHARACTER (2) NOT NULL &
PRIMARY KEY PRI_SCH IS SCH_NUMBER ASCENDING
The CREATE TABLE command completed successfully.
SQL CREATE TABLE CHILD IN FAMILY.CHILDAREA &
COLUMNS ARE CHILD_EMP_NUMBER : CHARACTER (5) NOT NULL, &
CHILD_NUMBER : CHARACTER (3) NOT NULL, &
CHILD_LAST_NAME : CHARACTER (20) NOT NULL, &
CHILD_FIRST_NAME : CHARACTER (12) NOT NULL, &
CHILD_BIRTH_DATE : CHARACTER (6) NOT NULL, &
CHILD_SCHOOL_NUMBER : CHARACTER (4), &
CHILD_GRADE_AVERAGE : NUMERIC (5.3) &
PRIMARY KEY PRI_INDR IS CHILD_EMP_NUMBER ASCENDING, &
CHILD_NUMBER ASCENDING &
FOREIGN KEY FOR_SCH IS CHILD_SCHOOL_NUMBER &
REFERS TO SCH_NUMBER OF SCHOOL &
FOREIGN KEY FOR_EMP IS CHILD_EMP_NUMBER &
REFERS TO INDR_EMP_NUMBER OF INDIVIDUALR &
INDEX SEC_CHDNAME ON CHILD_LAST_NAME ASCENDING, &
CHILD_FIRST_NAME ASCENDING

Example 3–22. Execution of Source Runstream—RDMS Database Setup

3–92 7831 4077–009

 Application Programming in a Batch or Demand Environment

The CREATE TABLE command completed successfully.

END IPF
@ . ***
@ . ***
@ . *** LOAD THE RDMS DATABASE
@ . ***
@SYS$LIB$*RDMS.RDMUTL,S APPSVN
RDMS 6R2 RELATIONAL UTILITY PROCESSOR 01/28/94 14:29:23

......... Begin thread ........

PLEASE ENTER RELATIONAL UTILITY COMMAND, FOLLOWED BY A SEMICOLON(;)
1 LOAD EXTERNAL FILE "QUAL*INDLOAD"
2 SORTED YES
3 LOAD FACTOR 50
4 INTO TABLE FAMILY.INDIVIDUALR
5 FORMAT INDR_EMP_NUMBER(1:5),
6 INDR_LAST_NAME(7:26),
7 INDR_FIRST_NAME(28:39),
8 INDR_BIRTH_DATE(41:46),
9 INDR_SPOUSE_LAST_NAME(48:57) NULLIF((48:48) = '*'),
10 INDR_SPOUSE_FIRST_NAME(59:70) NULLIF((59:59) = '*');

RDM is processing your request at 01/28/94 14:29:23.

Thread committed after reading line 22 of the input file at time 14:29:25

The loading of file "QUAL*INDLOAD" is completed at 01/28/94 14:29:25.

The total number of lines read is 22
The total number of rows loaded is 8

11 LOAD EXTERNAL FILE "QUAL*SCHLOAD"

12 SORTED YES
13 LOAD FACTOR 50
14 INTO TABLE FAMILY.SCHOOL
15 FORMAT SCH_NUMBER(1:4),
16 SCH_NAME(6:30),
17 SCH_START_GRADE(32:33),
18 SCH_END_GRADE(35:36) ;
RDM is processing your request at 01/28/94 14:29:26.
Thread committed after reading line 16 of the input file at time 14:29:26

The loading of file "QUAL*SCHLOAD" is completed at 01/28/94 14:29:26.

The total number of lines read is 16
The total number of rows loaded is 4
19 LOAD EXTERNAL FILE "QUAL*CHILDLOAD"
20 SORTED YES

Example 3–22. Execution of Source Runstream—RDMS Database Setup

7831 4077–009 3–93

Application Programming in a Batch or Demand Environment

21 LOAD FACTOR 50
22 INTO TABLE FAMILY.CHILD
23 FORMAT CHILD_EMP_NUMBER(1:5),
24 CHILD_NUMBER(7:8),
25 CHILD_LAST_NAME(10:29),
26 CHILD_FIRST_NAME(31:42),
27 CHILD_BIRTH_DATE(44:49),
28 CHILD_SCHOOL_NUMBER(51:54) NULLIF((51:51) = '*'),
29 CHILD_GRADE_AVERAGE(56:60) NULLIF((56:56) = '*') ;

RDM is processing your request at 01/28/94 14:29:27.

Thread committed after reading line 24 of the input file at time 14:29:29

The loading of file "QUAL*CHILDLOAD" is completed at 01/28/94 14:29:29.

The total number of lines read is 24
The total number of rows loaded is 9
.......... End thread .........
END RELATIONAL UTILITY PROCESSOR --- 0 ERRORS
@ . ***
@ . ***
@ . *** ******** END OF THE RDMS DATABASE DEFINITION SECTION *************
@ . ***

Example 3–22. Execution of Source Runstream—RDMS Database Setup

3.2.2.3. Coding with the RDMS 2200 Embedded SQL Interface

RDMS 2200 provides three methods for accessing relational databases from UCS
programs:
• Embedded SQL
This interface is supported by UCS COBOL and UCS C.

• Module SQL
This interface is supported by UCS FORTRAN.

• The SQL interpreter interface

This interface is supported by UCS C, UCS COBOL, and UCS FORTRAN.

The embedded and module language SQL implemented by UCS and RDMS 2200
conform to the following standards:
• ANSI Systems—Database Language—Embedded SQL (ANSI number: X3.168-1988
(Revised)).
• ANSI Systems—Database Language—SQL (ANSI number: X3.135.1-1989 (Revised)).
• ANSI Systems—Database Language—Embedded SQL (ANSI number: X3.135-1992
(entry-level)).
• Federal Information Processing Standards Publication 127-2 (FIPS 127-2).

3–94 7831 4077–009

 Application Programming in a Batch or Demand Environment

The embedded SQL (ESQL) interface provides syntax parsing and optimization during
compilation. The UCS compiler works with the RDMS 2200 software and the Unisys
Repository Manager (UREP) to verify command syntax. These capabilities provide
significantly faster execution than the SQL interpreter interface.

You envelop each embedded SQL command in an ESQL command packet. In UCS
COBOL, the command packet starts with the SQL prefix EXEC SQL and ends with the
SQL terminator END-EXEC. In UCS C, the command packet starts with EXEC SQL and
ends with a semi-colon (;). This command packet is required by the SQL standard. It
makes ESQL commands easily identifiable to the UCS COBOL and UCS C compilers.
The following example shows the format of this command packet, followed by an
example of its use with the USE DEFAULT QUALIFIER command.

UCS COBOL
Syntax
EXEC SQL sql-command END-EXEC.

Example
EXEC SQL
USE DEFAULT QUALIFIER FAMILY
END-EXEC.

Several embedded UCS COBOL SQL commands can be used without these packet
delimiters, as long as they are stand-alone commands. In other words, to be used
without packet delimiters, these commands
• Must end with a period
• Must not be part of a larger command structure

These commands are

• BEGIN THREAD
• END THREAD
• COMMIT
• ROLLBACK
• GETERROR

Five embedded SQL commands are compilation-time statements. These commands

are as follows:
• DEBUG (static format only)
• DECLARE CURSOR
• SET STATISTICS
• USE DEFAULT
• WHENEVER

7831 4077–009 3–95

Application Programming in a Batch or Demand Environment

During compilation, these commands affect commands that physically follow them in
the source input. When you use these commands, you must consider their physical
location in relation to the commands they affect.

In the following example, the USE DEFAULT QUALIFIER command is in effect for the
DECLARE CURSOR command that physically follows it in the source code.

.
.
.
BEGIN THREAD
EXEC SQL USE DEFAULT QUALIFIER FAMILY END-EXEC.
EXEC SQL DECLARE CURSOR... END-EXEC.
.
.
.
STOP RUN.

In the following example, the USE DEFAULT QUALIFIER command has no effect on the
DECLARE CURSOR command, because it does not physically precede DECLARE
CURSOR in the source code.

.
.
.
BEGIN THREAD
PERFORM DEFAULT-QUAL-PARA.
EXEC SQL DECLARE CURSOR ... END-EXEC.
.
.
.
STOP RUN.
.
.
.
DEFAULT-QUAL-PARA.
EXEC SQL USE DEFAULT QUALIFIER FAMILY END-EXEC.

When you use these commands in embedded SQL, carefully consider their physical
coding order.

COBOL variables used in embedded SQL commands can be coded in any section of
the Data Division, in accordance with COBOL coding conventions. The only exception
to this rule is a special group item, RDMCA. RDMCA must be located in a new
section, the Declare Section. The rule for the location of the Declare Section is that
the Declare Sections may be located in any section within the Data Division and there
can be multiple Declare Sections. They cannot be nested and cannot overlap.

The Declare Section always starts with the statement

EXEC SQL BEGIN DECLARE SECTION END-EXEC

3–96 7831 4077–009

 Application Programming in a Batch or Demand Environment

and always ends with

EXEC SQL END DECLARE SECTION END-EXEC.

These statements must start in area B of the COBOL source line. The following is an
example showing the format of this section.

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.

RDMCA and another new variable, SQLSTATE, are used to return embedded SQL
command statuses for all commands except GETERROR. They must be coded exactly
as shown in Example 3-23, so that they can be found by embedded SQL processing.

Unlike RDMCA, the SQLSTATE variable is not required to be in the Declare Section of
the COBOL program.

Example 3–23 is an example of the definition of the variables for a FETCH command
and the general error buffers:
• SQLSTATE and RDMCA are the embedded SQL error buffers. The variable names
must be SQLSTATE, RDMCA, ERROR-STATUS, and AUX-INFO. Their declarations
must be as shown in the example.
• In this example, ERROR-TEXT is the buffer used by the GETERROR command for
returning error message text.
• In this example, all COBOL variables used by embedded SQL commands are
located in the Working-Storage Section.

7831 4077–009 3–97

Application Programming in a Batch or Demand Environment

WORKING-STORAGE SECTION.
.
.
.
***********************************************
* RELATIONAL DATABASE INFORMATION FOR A FETCH
***********************************************
01 INDR-LAST-NAME PIC X(20).
01 INDR-FIRST-NAME PIC X(12).
***********************************************
* ESQL STATEMENT STATUS
***********************************************
01 SQLSTATE PIC X(5).
***********************************************
* RELATIONAL COMMAND ERROR BUFFERS
***********************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
***********************************************
* GETERROR BUFFERS
***********************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
***********************************************
* INDEX FOR GETERROR DISPLAYS
***********************************************
01 ERR-INDEX PIC 9.
***********************************************
* ALLERROR INDICATOR *
***********************************************
01 xx PIC 9 VALUE 0.
88 ALLERR VALUE 1.

Example 3–23. Coding RDMCA and SQLSTATE Variables for UCS COBOL

The FETCH command that uses these variables is coded as follows:

EXEC SQL
FETCH NEXT INDRDATA INTO :INDR-LAST-NAME, :INDR-FIRST-NAME
END-EXEC.

You can detect embedded SQL errors by either

• Using the global command WHENEVER
• Checking explicitly for an error condition after each embedded SQL command

The global command WHENEVER is in effect from the point at which it is encountered
in the source program.

3–98 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following is an example of a global command to catch all errors except the NOT
FOUND condition. The NOT FOUND condition (SQLSTATE = “02000”) can be detected
by explicitly coding a check, or by coding a different form of this global error-detecting
command.

SQL-ERROR-PROCESSING.
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.

If you use global error checking, you should code a new WHENEVER command in the
global error-handling paragraph, before any embedded SQL commands. This
WHENEVER command prevents the possibility of entering an infinite loop, if
embedded SQL commands in this paragraph cause errors.

The format of this WHENEVER command is as follows:

EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.

Each embedded SQL command except GETERROR in this paragraph should be

followed by explicit error checking.

The following is an example of a global embedded SQL error-handling paragraph:

RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY '***SQLSTATE = ' SQLSTATE UPON PRT.
DISPLAY '***RDMCA AUX-INFO = ' AUX-INFO UPON PRT.
DISPLAY '***ERROR STATUS = ' ERROR-STATUS UPON PRT.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT
EXEC SQL
GETERROR INTO :ERR(1), :ERR(2),:ERR(3),:ERR(4),:ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.
END-THREAD.
STOP RUN.

7831 4077–009 3–99

Application Programming in a Batch or Demand Environment

UCS C
Syntax
EXEC SQL sql-command;

Example
EXEC SQL
USE DEFAULT QUALIFIER FAMILY;

All embedded UCS C commands require the command packet.

Five embedded SQL commands are compilation-time statements. These commands

are as follows:
• DEBUG (static format only)
• DECLARE CURSOR
• SET STATISTICS
• USE DEFAULT
• WHENEVER

During compilation, these commands affect commands that physically follow them in
the source input. When you use these commands, you must consider their physical
location in relation to the commands they affect.

In the following example, the USE DEFAULT QUALIFIER command is in effect for the
DECLARE CURSOR command that physically follows it in the source code.

.
.
.
EXEC SQL BEGIN THREAD ...;
EXEC SQL USE DEFAULT QUALIFIER FAMILY;
EXEC SQL DECLARE CURSOR...;
.
.
.
return(0);

In the following example, the USE DEFAULT QUALIFIER command has no effect on the
DECLARE CURSOR command because it does not physically precede DECLARE
CURSOR in the source code.

.
.
.
EXEC SQL BEGIN THREAD...;
default_qual();
EXEC SQL DECLARE CURSOR...;
.
.

3–100 7831 4077–009

 Application Programming in a Batch or Demand Environment

.
return(0);
.
.
.
void default_qual(void)
{
EXEC SQL USE DEFAULT QUALIFIER FAMILY;
return;
}

When you use these commands in embedded SQL, carefully consider their physical
coding order.

C variables used in embedded SQL commands should be coded within the SQL
Declare Section. The Declare Section always starts with the statement:

EXEC SQL BEGIN DECLARE SECTION;

and always ends with

EXEC SQL END DECLARE SECTION;

The following is an example showing the format of this section.

EXEC SQL BEGIN DECLARE SECTION;

char employee_number[6];
char indr_last_name[21];
char indr_firs_name[13];
EXEC SQL END DECLARE SECTION;

SQLSTATE is used to return embedded SQL command statuses for all commands
except GETERROR. It must be coded exactly as shown in the following example, so
that it can be found by embedded SQL processing.

The following is an example of the variable for a FETCH command and general error
buffers:
• SQLSTATE is the embedded SQL error buffer. Its variable name must be
SQLSTATE. Its declaration must be shown as in the example.
• NO_FIND_STATUS is defined with the value returned if the FETCH finds no
row/record occurrence that satisfies the selection criteria. This value is "02000".
/* *****************************************
* ESQL STATEMENT STATUS
***************************************** */
char SQLSTATE[6];
#define NO_FIND_STATUS "02000"
/* *****************************************
* RELATIONAL DATABASE INFORMATION
***************************************** */
EXEC SQL BEGIN DECLARE SECTION;

7831 4077–009 3–101

Application Programming in a Batch or Demand Environment

char employee_number[6];
char indr_last_name[21];
char indr_first_name[13];
EXEC SQL END DECLARE SECTION;

The FETCH command that uses these variables is coded as follows:

EXEC SQL FETCH NEXT INDRDATA INTO :indr_last_name, :indr_first_name;

You can detect embedded SQL errors by either

• Using the global command WHENEVER
• Checking explicitly for an error condition after each embedded SQL command

The global command WHENEVER is in effect from the point at which it is encountered
in the source program.

The following is an example of a global command to catch all errors except the NOT
FOUND condition. The NOT FOUND condition (SQLSTATE = "02000") can be detected
by explicitly coding a check, or by coding a different form of this global error-detecting
command.

EXEC SQL WHENEVER SQLERROR GO TO:HANDLE_SQL_ERROR;

.
.
.
HANDLE_SQL_ERROR;
handle_sqlerror();
return(0);

If you use global error checking, you should code a new WHENEVER command in the
global error-handling function. This WHENEVER command prevents the possibility of
entering an infinite loop if embedded SQL commands in this function cause errors.

The format of this WHENEVER command is as follows:

EXEC SQL WHENEVER SQLERROR CONTINUE;

Each embedded SQL command except GETERROR in this paragraph should be

followed by explicit error checking.

3–102 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following is an example of a global embedded SQL error-handling function.

void handle_sqlerror(void)
{
char msg[133];
EXEC SQL WHENEVER SQLERROR CONTINUE;
printf("***SQLSTATE = %p\n", SQLSTATE);
printf("GETERROR returned the following text for
SQLSTATE:\n\n");
do
{
EXEC SQL GETERROR INTO :msg;
printf("%s/n",msg);
}
while(msg[0] != '/0');
EXEC SQL END THREAD;
}

3.2.2.4. Dynamic ESQL Commands for UCS COBOL and UCS C

Dynamic ESQL commands provide a method for creating commands that are not
compiled until program execution time. This is similar to the interpreter SQL interface.
The types of dynamic ESQL commands are
• The PREPARE and EXECUTE commands. Use these commands if the SQL
command will be executed more than once.
• The EXECUTE IMMEDIATE command. Use this command if an SQL command will
be executed only once within a program.

PREPARE and EXECUTE

When coding a dynamic ESQL command that will be executed more than once, use
the PREPARE and EXECUTE commands. An example of when to use these commands
is if the command is part of a loop.

The PREPARE and EXECUTE commands work as follows:

• At runtime, the PREPARE command parses, optimizes, and names a dynamic SQL
statement. This named SQL statement is saved for later execution.
• The named SQL statement can be executed a number of times using the EXECUTE
command.

Syntax parsing or optimizing does not occur each time the EXECUTE command is
processed. All EXECUTE commands use the PREPARE statement until the next
THREAD CONTROL command is executed or a ROLLBACK occurs.

7831 4077–009 3–103

Application Programming in a Batch or Demand Environment

You can use the PREPARE and EXECUTE commands on the following commands:
DELETE
INSERT
LOCATE
LOCK
SET STATISTICS
UNLOCK
UPDATE
USE DEFAULT

You can also use PREPARE and EXECUTE commands on query specifications used
with the ALLOCATE CURSOR command.

For a dynamic SELECT, the OPEN CURSOR command performs the function of the
EXECUTE command. The EXECUTE command is not used.

COMMIT, ROLLBACK, and END THREAD can be prepared and executed from an
implicit thread only.

EXECUTE IMMEDIATE
You should use the EXECUTE IMMEDIATE command when coding a dynamic ESQL
command that the program will use only once. The EXECUTE IMMEDIATE command
parses, optimizes, and executes an SQL statement at runtime.

The following ESQL commands can be used with the EXECUTE IMMEDIATE statement:
DEBUG
DELETE
INSERT
LOCATE
LOCK
SET STATISTICS
UNLOCK
UPDATE
USE DEFAULT

For more information on coding RDMS 2200 embedded SQL programs, refer to the
following documents:
• COBOL Compiler Programming Reference Manual Volume 2
• RDMS SQL Programming Reference Manual

3–104 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.2.5. Coding with the RDMS 2200 Module SQL Interface

The module SQL interface is another method for accessing RDMS 2200 databases
from UCS programs. With the module SQL interface, you code SQL commands in a
separate module program as defined by the American National Standard Database
Language SQL (X3.135?1992), or SQL 92. RDMS parses the SQL commands as each
command is compiled. Each command is then executed at run time.

The module SQL interface is supported by UCS FORTRAN.

The module SQL interface provides better execution time than the interpreter
interface.

When you use the module SQL language interface, UCS FORTRAN and accesses
RDMS indirectly by calling procedures generated by the SQL Module Preprocessor.

3.2.2.6. Using the SQL Module Preprocessor

The module source language implemented by the OS 2200 Universal Compiling
System SQL Module Language Preprocessor (SMLP) conforms to the following
standards:
• ANSI Systems—Database Language—Embedded SQL (ANSI number: X3.168-1988
(Revised))
• ANSI Systems—Database Language—SQL (ANSI number X3.135.1-1989 (Revised))
• ANSI Systems—Database Language—Embedded SQL (ANSI X3.135-1992 (entry-
level))
• Federal Information Processing Standards Publication 127-2 (FIPS 127-2)

An SQL module implementation consists of at least two program units that you must
develop:
• The module language source program
• The UCS FORTRAN host application program

The module language defines modules and procedures. Only one module is permitted
per host application program. An optional set of cursor declarations and a set of
procedures make up the module. A procedure consists of a procedure name, a list of
parameter declarations, and a single SQL statement. The SQLSTATE parameter must
be included in the parameter list. The following is an example of a FORTRAN module
language program.

MODULE SQLPROCS
LANGUAGE FORTRAN
AUTHORIZATION FAMILY
--
-- ***********************************************************************
-- This module defines the cursor and procedure definitions
-- called by FORTRAN host application program
-- ***********************************************************************

7831 4077–009 3–105

Application Programming in a Batch or Demand Environment

--
-- Individual's children cursor definition
--
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMPLOYEE_NUMBER
--
-- Procedure to begin thread with UDS
--
PROCEDURE BEGINTHREAD
(SQLSTATE);
BEGIN THREAD FDSPDATA FOR APPSVN RETRIEVE;
--
-- Procedure to perform singleton select
--
PROCEDURE SINGLESELECTIND
(SQLSTATE,
:EMPLOYEE_NUMBER CHAR(5),
:IDR_LAST_NAME CHAR(20),
:INDR_FIRST_NAME CHAR(12));
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :INDR_LAST_NAME, :INDR_FIRST_NAME
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :EMPLOYEE_NUMBER;
--
-- Procedure to open the individual's children cursor
--
PROCEDURE OPENCHILDCURSOR
(SQLSTATE,
:EMPLOYEE_NUMBER CHAR(5));
OPEN CHILDDATA;
--
-- Procedure to fetch the children of an individual using the CHILDDATA
-- cursor
--
PROCEDURE FETCHCHILD
(SQLSTATE,
:CHILD_LAST_NAME CHAR(20),
:CHILD_FIRST_NAME CHAR(12));
FETCH NEXT CHILDDATA INTO :INDR_LAST_NAME, :INDR_FIRST_NAME;
--
-- Procedure to end thread with UDS
--
PROCEDURE ENDTHREAD
(SQLSTATE);
END THREAD;
--
-- Procedure to call GETERROR to obtain message description for
-- SQLSTATE status
--
PROCEDURE GETERRORTEXT

3–106 7831 4077–009

 Application Programming in a Batch or Demand Environment

(SQLSTATE,
:MSG1 CHAR(132),
:MSG2 CHAR(132),
:MSG3 CHAR(132),
:MSG4 CHAR(132),
:MSG5 CHAR(132));
GETERROR INTO :MSG1, :MSG2, :MSG3, :MSG4, :MSG5;

To execute an SQL statement, the host application program calls the module
procedure associated with a particular SQL statement in the same way it calls any
other subroutine or subprogram. The name of the subprogram or subroutine is the
module procedure name.

The following is a sample of part of a UCS FORTRAN host program using the
preceding FORTRAN module language program.

PROGRAM HOST_SQL
IMPLICIT NONE

CHARACTER INDR_LAST_NAME*20
CHARACTER INDR_FIRST_NAME*12
CHARACTER CHILD_LAST_NAME*20
CHARACTER CHILD_FIRST_NAME*12

CHARACTER SQLSTATE*5
CHARACTER GOOD_STATUS*5
PARAMETER (GOOD_STATUS = '00000')
CHARACTER NO_FIND_STATUS*5
PARAMETER (NO_FIND_STATUS = '02000')

.
.
.

CALL BEGINTHREAD(SQLSTATE)
IF (SQLSTATE.NE.GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF

CALL SINGLESELECTIND
& (SQLSTATE,EMPLOYEE_NUMBER,INDR_LAST_NAME,INDR_FIRST_NAME)
IF (SQLSTATE.EQ.NO_FIND_STATUS) THEN
PRINT*,'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER ',
& EMPLOYEE_NUMBER
CALL ENDTHREAD(SQLSTATE)
IF (SQLSTATE.NE.GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
PRINT *,'PROGRAM HAS COMPLETED'
STOP
.

7831 4077–009 3–107

Application Programming in a Batch or Demand Environment

.
.

The SMLP interprets the module source language and generates a COBOL
subprogram element that must be compiled using the UCS COBOL compiler. The
COBOL subprogram combines with the host application program to manipulate the
RDMS database.

The following describes the steps involved in setting up an application that uses the
module SQL language to access an RDMS database and how the subprogram and host
program work together.
1. You develop a FORTRAN host application program and module language source
program as follows:
• The host application program contains the calls to the module language source
procedures to execute SQL statements.
• The module language source program defines procedures that contain the
SQL statements that the host program executes.
2. You call the SMLP preprocessor to convert the module language source program
to a new source element that consists of COBOL subprograms.
3. Use the UCS COBOL compiler to compile the COBOL subprograms. This step can
be performed either automatically by the SMLP preprocessor or manually by the
user. The UCS COBOL compiler processes embedded SQL statements by
interfacing with RDMS. The compilation produces an object module for each
COBOL subprogram.
4. You call the UCS FORTRAN compiler to compile the host application program.
5. You either dynamically or statically link and execute the program.

The following figure shows an overview of this process.

3–108 7831 4077–009

 Application Programming in a Batch or Demand Environment

Table/View
Definitions

ESQL Syntax RDMS RDT$FILE

Analysis

Module COBOL UCS COBOL

Language Subprograms Subprogram
@SMLP @UCOB
Source Source OMs

@LINK

UCS FORTRAN UCS FORTRAN Executable

Host @UFTN Host UCS FORTRAN
Program Source OM MSQL Program

002324

3.2.2.7. Coding with the RDMS 2200 SQL Interpreter Interface

The SQL interpreter interface is another method for accessing RDMS 2200 databases
from UCS programs. With the SQL interpreter interface, all syntax is parsed when the
command is executed.

The SQL interpreter interface is supported by these UCS languages:

• UCS COBOL
• UCS FORTRAN
• UCS C

The coding format for COBOL and FORTRAN is the same for UCS and non-UCS
programs.

The following shows the generic syntax of SQL interpreter commands for each
language, followed by an example of a USE DEFAULT QUALIFIER command.

UCS COBOL
Syntax
ENTER MASM 'ACOB$RDMR' USING sql-command, error-status, auxiliary-info
[,program-variable-1] ... .

7831 4077–009 3–109

Application Programming in a Batch or Demand Environment

Example
ENTER MASM 'ACOB$RDMR' USING 'USE DEFAULT QUALIFIER FAMILY ;',
error-status, auxiliary-info.

UCS FORTRAN
Syntax
CALL F$RDMR (sql_command, error_status, auxiliary_info
& [,program_variable_1] ... )

Example
CALL F$RDMR ('USE DEFAULT QUALIFIER FAMILY ;', error_status,
& auxiliary_info)

UCS C
Syntax
rsa(sql_command, error_status, &auxiliary_info [,&program_variable_1] ... )

Example
rsa("use default qualifier family ;", error_status, &auxiliary_info)

Passing Program Variables

To pass program variables, you use special $P variables as placeholders. The
following example shows this type of coding, using a FETCH command with UCS
COBOL. $P1 and $P2 represent the two program variables INDR-LAST-NAME and
INDR-FIRST-NAME. They receive the values fetched from the relational table being
read.

ENTER MASM 'ACOB$RDMR' USING 'FETCH NEXT INDRDATA INTO $P1, $P2 ;',
error-status, auxiliary-info,
INDR-LAST-NAME, INDR-FIRST-NAME.

3–110 7831 4077–009

 Application Programming in a Batch or Demand Environment

Error Status and Auxiliary Information

Note the following about error status and auxiliary information:
• You should explicitly check the error status and auxiliary information after each
command.
• You should define error status and auxiliary information in the program’s data area.

The following is an example of their definition in UCS COBOL. ERROR-STATUS and

AUX-INFO are the SQL command error buffers. ERROR-TEXT is the buffer used by the
GETERROR command for returning error message text.

01 ERROR-STATUS PIC 9999.

01 AUXILIARY-INFO PIC S1(36) USAGE BINARY-1.
01 ERROR-TEXT.
05 ERR-S PIC X(132) OCCURS 5 TIMES.

Refer to the following Error documents for more information on coding RDMS 2200
SQL programs using the interpreter interface:
• The programming reference manual for the appropriate UCS language (for UCS
COBOL, FORTRAN, and C) is Volume 2
• RDMS SQL Programming Reference Manual

RSA$PARAM Usage
The RSA$PARAM feature was integrated for UCS COBOL and UCS C as of SB4R6.

3.2.2.8. Defining RDMS 2200 Columns as Program Variables

RDMS and the UCS languages each define specific data types. Some data types
require conversion when passed; other data types are equivalent and do not require
conversion. Table 3-3 shows the equivalent data structures of the different UCS
languages. To avoid unnecessary conversion and resulting overhead, use equivalent
types for corresponding data items.

7831 4077–009 3–111

Application Programming in a Batch or Demand Environment

Table 3–3. UCS Data Types Allowed for RDMS Column Definitions

RDMS 2200
Column UCS COBOL Data UCS FORTRAN UCS C Data
Definition Definition Data Definition Definition

CHARACTER(n) X(n) CHARACTER*n char var[n+1]

A(n)

NCHARACTER(n) X(n) NCHARACTER*n short var[n+1]

usage disp-2

DECIMAL(d,s) S9(d-s-1)v9(s) INTEGER (1) int (1)

sign leading separate(3) REAL (1) float (1)

DOUBLE PRECISION (1) double (1)

NUMERIC(d,s) S9(d-s)v9(s) INTEGER (1) int (1)

sign leading separate (3) REAL (1) float (1)

DOUBLE PRECISION (1) double (1)

INTEGER S9(10) INTEGER int

usage binary

S9(9) usage comp-5

S1 (36)

usage binary-1

SMALLINT S9(5) INTEGER (1) short

usage binary

S9(4)usage comp-5

S1 (18)

usage binary-1

REAL usage comp-1 REAL float

DOUBLE PRECISION usage comp-2 DOUBLE PRECISION double

FLOAT(p) usage comp-1 (2) REAL (2) float (2)

usage comp-2 (2) DOUBLE PRECISION (2) double (2)

DATE X(n) (4) CHARACTER*n (4) char var[n+1] (4)

TIME A(n)
TIMESTAMP

BLOB (n) usage is sql type is blob (n) sql type is blob(n)

3–112 7831 4077–009

 Application Programming in a Batch or Demand Environment

1. RDMS 2200 performs the necessary conversion.

2. Dependent upon the value of p as follows:
• If p > 27, use usage comp-2, DOUBLE PRECISION, double.
• If p ≤ 27, use usage comp-1, REAL, float, real.
• If p is not specified, use usage comp-2,DOUBLE PRECISION,double.
3. UCS COBOL supports only a value of d < 19.
4. See the RDMS SQL Programming Reference Manual for the values of n.

3.2.2.9. Compiling UCS Programs That Access RDMS 2200 Databases

Compiling UCS programs that access RDMS 2200 databases is straightforward.

Embedded SQL Programs

When compiling UCS COBOL or UCS C programs containing embedded SQL, you must
specify the special keyword option APPLICATION/application-name. This keyword
option identifies the application group whose RDMS and related RDT$FILE file is
referenced while the compiler parses the RDMS 2200 commands. This is the same
application group that the program is linked to and executed within. The default
setting of this keyword option is APPLICATION/UDSSRC.

The following statement is a sample UCS COBOL compiler call used to compile an
embedded SQL program that uses application group 7:

@UCOB QUAL*UCSTST.DISPLAYFAM/ESQL,QUAL*UCSTST.DSPFAMESQL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN

The following figure represents the process used to compile an embedded SQL
program.
1. The embedded SQL commands are passed to RDMS 2200 for parsing.
2. RDMS 2200 accesses the table and view definitions in the RDT$FILE belonging to
the application group specified in the APPLICATION/application-name keyword
option.

7831 4077–009 3–113

Application Programming in a Batch or Demand Environment

Module SQL Source Programs and Host Language Application Programs

The SMLP generates a COBOL subprogram element from the module language source
program.

The COBOL subprogram element generated by the SMLP contains a COBOL

subprogram for each procedure in the module. The SQL operation defined in the
original module language has been converted to an embedded SQL statement in the
associated COBOL subprogram. All the COBOL subprograms are contained in the
same output symbolic element as back-to-back programs. The element generated for
the COBOL subprograms is the same as the output element specified on the SMLP
invocation, with a version name of COB attached.

The SMLP automatically compiles the generated COBOL subprograms element by

calling the UCS COBOL compiler. The UCS COBOL compiler call line includes
• The keyword options element, if one was specified on the SMLP call line in the
fourth field. This element should include the APPLICATION/application-name
keyword option to identify the correct application group.
• The MODULE keyword option.

Specifying the C option on the SMLP call line disables the automatic COBOL
compilation. You must then compile the generated COBOL subprogram element using
the APPLICATION/application-name and MODULE compiler keyword options.

The following example contains

• A sample SMLP call that inhibits the automatic UCS COBOL compiler call.
• A user-invoked call to the UCS COBOL compiler.
• A call to the UCS FORTRAN compiler to compile the host application program.

Application group seven is being used.

@SMPL,C QUAL*UCSTST.DISPLAYFAM/MSQL-FMOD,QUAL*UCSTST.FMOD

@UCOB,S QUAL*UCSTST.FMOD/COB,QUAL*UCSTST.,,,NO-OPTIONS,NARROW;
APPLICATION/APPSVN,MODULE

@UFTN QUAL*UCSTST.DISPLAYFAM/MSQL-FHOST,QUAL*UCSTST.FHOST,,,NO-OPTIONS

The following figure represents the process used to preprocess and compile the
module language source program and to compile the host application program.

3–114 7831 4077–009

 Application Programming in a Batch or Demand Environment

Table/View
Definitions

ESQL Syntax RDMS RDT$FILE

Analysis

Module COBOL UCS COBOL

Language Subprograms Subprogram
@SMLP @UCOB
Source Source OMs

UCS FORTRAN
Host UCS FORTRAN
@UFTN Host
Program Source
OM 002325

Interpreter SQL Programs

When you compile a UCS program using the SQL interpreter interface, only a call to
the correct UCS compiler is required. No special options or keyword options are
required for any of the host languages (UCS COBOL, FORTRAN, or C).

The following statement is a sample UCS COBOL compiler call used to compile a
program using the SQL interpreter interface.

@UCOB QUAL*UCSTST.DISPLAYFAM/SQL,QUAL*UCSTST.DSPFAMSQL/COMP,,, ;
NO-OPTIONS

The following figure represents the process used to compile a program using the SQL
interpreter interface. Notice that only the compiler is used. This is because all RDMS
2200 command syntax is parsed at execution time.

3.2.2.10. Basic Linking Information for UCS RDMS 2200 Programs

When statically or dynamically linking a UCS program that accesses an RDMS 2200
database using interpreted SQL, you must specify use of a special application group
library search chain by using an @USE LINK$PF statement. This library search chain

7831 4077–009 3–115

Application Programming in a Batch or Demand Environment

causes the Linking System to resolve references using the RDMS 2200 software for a
particular application group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the RDMS 2200 interface
during static linking

The following generic format shows how to specify use of the appropriate application
group library search chain:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program containing RDMS 2200 interpreted SQL statements
to the system software in application group 7, use the following statement:
@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to RDMS 2200 software would be resolved using
UDS$$SVN*RSA.

Embedded SQL programs and module SQL programs are compiled for a specific
application group. The default is application UDSSRC or application group 3 (APP$3).
Use of the APPLICATION/appname keyword option on the compilation can target it for
any application group you wish. You also should use the @USE
LINK$PF,SYS$LIB$*APP$n. statement specifying the file for the same application
group when either dynamically linking or static linking these programs. If you wish to
change the application that your compiled ESQL/Module-SQL object modules link to,
you must follow the static linking procedure in "Portable Embedded and Module
Language SQL Programs" later in this subsection.

For more information on these library search chains, see Section 4.

Dynamically Linking a UCS RDMS 2200 Program

When you execute a UCS program containing RDMS 2200 statements, you can use
dynamic linking. The only requirement is that before execution, you must specify use
of the application group library search chain by using the @USE LINK$PF statement. If
the program uses embedded or module SQL, this file must be for the same application
group that the program was compiled for.
@USE LINK$PF,SYS$LIBS*APP$7.
@XQT QUAL*PROGFILE.OM/COMP

3–116 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following statements show an example of a compilation and execution using

dynamic linking. This compilation did not use an APPLICATION/appname keyword
option. The @USE statement specifies the SSDEF$ file for application 7, which is not
the default app3. So, the program must be an interpreted SQL program, since any
Embedded SQL statements would be targeted for the default application 3:
@UCOB QUAL*UCSTST.DISPLAYFAM/SQL,QUAL*UCSTST.DSPFAMSQL/COMP,,, ;
NO-OPTIONS

@USE LINK$PF,SYS$LIB$*APP$7.

@XQT QUAL*UCSTST.DSPFAMSQL/COMP

Statically Linking a UCS RDMS 2200 Program

You can statically link a UCS program containing RDMS 2200 statements. The
following steps are involved:
1. Specify use of the appropriate application group library search chain using an
@USE LINK$PF statement.
2. Call the LINK Processor (@LINK).
3. Specify static linking commands, including a command that identifies the
program’s compiler-produced object module.
The output of this static link can be a standard object module, a bound object module,
or a ZOOM.

The following example shows how to statically link a UCS program containing RDMS
2200 statements, producing a zero overhead object module (a ZOOM):

(1) @USE LINK$PF,SYS$LIB$*APP$7.

(2) @LINK ,QUAL*UCSTST.DSPFAMESQL
(3) INCLUDE QUAL*UCSTST.DSPFAMESQL/COMP
(4) RESOLVE ALL REFERENCES USING LIBCODENAME
(5) PROCESS FOR EXTENDED ZOOM
(6) DELETE ALL DEFINITIONS EXCEPT START$
(7) @EOF

7831 4077–009 3–117

Application Programming in a Batch or Demand Environment

Explanation
1. This statement ensures that the program is statically linked using the RDMS 2200
software located in the desired application group. (It ensures that the library
search chain for the correct application group is used.) In this example, this
program is to execute in application group 7. Any embedded SQL or module SQL
programs input to this static link must also have been compiled for this application
group.
2. This statement calls the Linking System LINK Processor. The ZOOM to be
produced is named QUAL*UCSTST.DSPFAMESQL.
3. This command identifies the compiler-generated object module containing the
UCS RDMS 2200 program. For the module SQL interface, this is the UCS
FORTRAN compiler-created object from the host application program.
4. This command resolves external references, including those to the UCS Runtime
System library.
If you are statically linking a module SQL program, you must identify the file where the
output of the UCS COBOL back-to-back compilations exists on the RESOLVE
command. This file name must be specified prior to LIBCODENAME or LCN.
5. This command merges banks and produces a ZOOM.
6. This command deletes all definitions except the program’s starting address,
START$. This decreases the size of the ZOOM.
7. This statement ends static linking.

3–118 7831 4077–009

 Application Programming in a Batch or Demand Environment

Portable Embedded and Module Language SQL Programs

Embedded and module SQL programs are compiled for a specific application group,
the default being application 3 (UDSSRC). Doing an @USE LINK$PF on the SSDEF file
for another application group before static linking your application is not sufficient to
target that application group. However, ESQL and MSQL programs can be ported
from one application group to another application group on the same or another
OS 2200 system without program recompilation. ESQL and MSQL program
recompilations are still necessary when RDMS schema definitions are changed.

When the schema definitions are equivalent, the portable embedded and module
language SQL programs feature provides the capability to
• Port from one application group and execute on another OS 2200 system in the
same application group
• Execute on a different application group on the same OS 2200 system or another
OS 2200 system

The porting of UCS ESQL and MSQL programs is handled by relinking these programs
to the new application group on the target OS 2200 system. This is accomplished by
making the following two changes to the static link runstreams for the programs:
1. Identify the new library search chain for the new application group on the target
OS 2200 system prior to the static link. To do so, use the following statement.
@USE LINK$PF,SYS$LIB$*APP$n

where n is the new application group number.

2. Add the following CHANGE LCN command to the static link input following the
INCLUDE command and before the RESOLVE command. Note that you must
INCLUDE all code object modules that have embedded or module SQL statements
before this CHANGE LCN command:
CHANGE LCN FOR RSA$APP$NAME, RSA$RUNTIME TO APP$n

where n is the new application group number.

The static link must be performed on the target OS 2200 system. Here is the previous
RDMS static link example adjusted to target a different application group than the
code was compiled for:
@USE LINK$PF,SYS$LIB$*APP$8.
@LINK ,QUAL*UCSTST.DSPFAMESQL
INCLUDE QUAL*UCSTST.DSPFAMESQL/COMP
CHANGE LCN FOR RSA$APP$NAME,RSA$RUNTIME TO APP$8
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

7831 4077–009 3–119

Application Programming in a Batch or Demand Environment

You get static linker warnings like the following if you did not have any embedded or
module SQL object modules in your program:
*WARNING (LINK 603)* No REFERENCES found for RSA$RUNTIME.
*WARNING (LINK 603)* No REFERENCES found for RSA$APP$NAME.
*WARNING (LINK 605)* CHANGE statement cannot be performed.

Getting these warnings means that you probably had only interpreted SQL programs
included in this static link, or perhaps you misspelled the RSA$xxx entry point names.

For information on how to port the table definitions (RDTs) and database data, refer to
the Relational Database Server for ClearPath OS 2200 Administration Guide.

3.2.2.11. Example of a UCS Program Containing RDMS 2200

Statements
The following subsections show four program examples:
1. An embedded SQL program using UCS COBOL
2. An embedded SQL program using UCS C
3. A module SQL program and a UCS FORTRAN host application program
4. A SQL interpreter interface program using UCS COBOL

All programs have the same functional capabilities; all are compiled using the UCS
compilers. However, for variety, this example shows use of different linking methods
for the four programs:
• The embedded SQL programs and module SQL program use static linking to
produce zero overhead object modules.
• The program using the SQL interpreter interface uses dynamic linking.

The following example summarizes the simple UCS RDMS 2200 program used in the
example. The program
1. Reads an employee number
2. Accesses information about that individual from the RDMS 2200 database
3. Displays the data

3–120 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.2.12. DISPLAYFAM
IDENTIFICATION DIVISION.
PROGRAM-ID. DISPLAYFAM.
.
.
DATA DIVISION.
WORKING-STORAGE SECTION.
table definitions
.
.
.
01 EMPLOYEE-NUMBER ....
PROCEDURE DIVISION.
ACCEPT EMPLOYEE-NUMBER
BEGIN THREAD
USE DEFAULT QUALIFIER
SINGLETON SELECT
DISPLAYS .....
DECLARE CURSOR
OPEN CURSOR
FETCHs ....
DISPLAYs .....
END THREAD
STOP RUN.

7831 4077–009 3–121

Application Programming in a Batch or Demand Environment

Source Listing of the COBOL Embedded SQL Program (DSPFAMESQL)

Example 3-24 shows the complete source listing of the COBOL embedded SQL
program, DSPFAMESQL. This program accepts an employee number as input and
displays the information contained in this database about this individual’s family.
In this example, this program resides in element QUAL*UCSTST.DISPLAYFAM/ESQL.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DSPFAMESQL.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL RDMS EMBEDDED SQL PROGRAM - DSPFAMESQL *
* *
* reads the input data *
* begins thread with UDS *
* retrieves the requested information from the database *
* displays this information on the printer *
* ends thread with UDS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 INVALID-EMPLOYEE-NUMBER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* RDMS WORK AREA SIZE
************************************************************
01 WORK-AREA-SIZE PIC 1(36) USAGE BINARY-1 VALUE 2000.
************************************************************
* UDS THREAD STATUS FLAG

Example 3–24. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

3–122 7831 4077–009

 Application Programming in a Batch or Demand Environment

************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 INDR-LAST-NAME PIC X(20).
01 INDR-FIRST-NAME PIC X(12).
01 CHILD-LAST-NAME PIC X(20).
01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* ESQL STATEMENT STATUS
************************************************************
01 SQLSTATE PIC X(5).
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
************************************************************
* GETERROR BUFFERS
************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************
01 ERR-INDEX PIC 9.
************************************************************
* ALLERR INDICATOR
************************************************************
01 XX PIC 9 VALUE 0.
88 VALUE 1.
*
PROCEDURE DIVISION.
************************************************************
* PROGRAM FLOW
************************************************************
MAIN-PROGRAM-FLOW.
DISPLAY 'ENTER EMPLOYEE NUMBER' UPON PRINTER.
ACCEPT EMPLOYEE-NUMBER.
************************************************************
* RSA WORK AREA SIZE

Example 3–24. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

7831 4077–009 3–123

Application Programming in a Batch or Demand Environment

************************************************************
CALL 'RSA$INIT' USING WORK-AREA-SIZE.
************************************************************
* GENERAL ERROR PROCESSING FOR A NEGATIVE SQL ERROR
************************************************************
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.
PERFORM BEGIN-THREAD-TO-UDS.
PERFORM SINGLETON-SELECT-INDRDATA.
IF SQLSTATE = "02000"
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
PERFORM END-THREAD-TO-UDS
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF.
PERFORM DISPLAY-INDIVIDUAL-DATA.
PERFORM SETUP-CHILDDATA-CURSOR.
PERFORM FETCH-FROM-CHILDDATA-CURSOR
WITH TEST AFTER UNTIL SQLSTATE = "02000"
PERFORM END-THREAD-TO-UDS
PERFORM TERMINATION-PARA.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
* SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
************************************************************
BEGIN-THREAD-TO-UDS.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
MOVE 1 TO THREAD-FLAG.
EXEC SQL
USE DEFAULT QUALIFIER FAMILY
END-EXEC.
************************************************************
* SINGLETON SELECT OF THE INDIVIDUAL'S DATA
************************************************************
SINGLETON-SELECT-INDRDATA.
EXEC SQL
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :INDR-LAST-NAME, :INDR-FIRST-NAME
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :EMPLOYEE-NUMBER
END-EXEC.
************************************************************
* DISPLAY THE INDIVIDUAL'S INFORMATION TO THE PRINTER
************************************************************

Example 3–24. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

3–124 7831 4077–009

 Application Programming in a Batch or Demand Environment

DISPLAY-INDIVIDUAL-DATA.
DISPLAY 'INDIVIDUAL DATA' UPON PRINTER.
DISPLAY ' EMPLOYEE NUMBER IS ' EMPLOYEE-NUMBER UPON PRINTER.
DISPLAY ' LAST NAME: ' INDR-LAST-NAME UPON PRINTER.
DISPLAY ' FIRST NAME: ' INDR-FIRST-NAME UPON PRINTER.
************************************************************
* DEFINE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN CURSOR
************************************************************
SETUP-CHILDDATA-CURSOR.
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMPLOYEE-NUMBER
END-EXEC.
EXEC SQL
OPEN CHILDDATA
END-EXEC.
************************************************************
* RETRIEVE DATA FROM THE CURSOR
************************************************************
FETCH-FROM-CHILDDATA-CURSOR.
EXEC SQL
FETCH NEXT CHILDDATA INTO
:CHILD-LAST-NAME, :CHILD-FIRST-NAME
END-EXEC.
IF SQLSTATE NOT = "02000"
DISPLAY ' CHILD NAME: ' CHILD-FIRST-NAME, ' ',
CHILD-LAST-NAME UPON PRINTER
ELSE CONTINUE
END-IF.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************
END-THREAD-TO-UDS.
END THREAD.
MOVE 0 TO THREAD-FLAG.
************************************************************
* TERMINATE PROGRAM
************************************************************
TERMINATION-PARA.
*
DISPLAY 'PROGRAM HAS COMPLETED' UPON PRINTER.
STOP RUN.

Example 3–24. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

7831 4077–009 3–125

Application Programming in a Batch or Demand Environment

************************************************************
* RETURN AN ERROR MESSAGE ON THE PRINTER IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY ***SQLSTATE = ' SQLSTATE UPON PRINTER.
DISPLAY '***RDMCA AUX-INFO = ' AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = ' ERROR-STATUS UPON PRINTER.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT
EXEC SQL
GETERROR INTO :ERR(1), :ERR(2), :ERR(3), :ERR(4), :ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.
END-THREAD.
STOP RUN.
PERFORM END-THREAD-TO-UDS.
PERFORM TERMINATION-PARA.

Example 3–24. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

3–126 7831 4077–009

 Application Programming in a Batch or Demand Environment

Example 3–25 shows the source listing of a runstream used to compile, link, and
execute the example program DSPFAMESQL. Noteworthy lines are bolded.

@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *********************

@ . ***
@ . *** UCOB COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UCOB QUAL*UCSTST.DISPLAYFAM/ESQL,QUAL*UCSTST.DSPFAMESQL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** STATIC LINK OF THE EMBEDDED SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DSPFAMESQL
INCLUDE QUAL*UCSTST.DSPFAMESQL/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THE EMBEDDED SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DSPFAMESQL
10211
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–25. Runstream to Compile, Link, and Execute COBOL Embedded SQL
Program

7831 4077–009 3–127

Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–26 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *********************

@ . ***
@ . *** UCOB COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UCOB QUAL*UCSTST.DISPLAYFAM/ESQL,QUAL*UCSTST.DSPFAMESQL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 14:39:25
SIZES: CODE(EM6): 514 DATA: 512
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING (LEVEL)
@ . ***
@ . ***
@ . *** STATIC LINK OF THE EMBEDDED SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DSPFAMESQL
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1439:37
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THE EMBEDDED SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DSPFAMESQL

ENTER EMPLOYEE NUMBER

INDIVIDUAL DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

Example 3–26. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

3–128 7831 4077–009

 Application Programming in a Batch or Demand Environment

CHILD NAME: STEVEN JR FIELDING

CHILD NAME: DANIEL FIELDING

CHILD NAME: JANE FIELDING

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–26. Source Listing of the Embedded SQL Program

(QUAL*UCSTST.DISPLAYFAM/ESQL)

7831 4077–009 3–129

Application Programming in a Batch or Demand Environment

Source Listing of the C Embedded SQL Program (CDSPFAMESQL)

Example 3–27 shows the complete source listing of the C embedded SQL program
CDSPFAMESQL. This program accepts an employee number as input and displays the
information contained in this database about this individual’s family.

In this example, this program resides in element QUAL*UCSTST.DISPLAYFAM/ESQL-C.

Noteworthy lines are bolded.

/* ***************************************************************
* *
* SIMPLE BATCH C RDMS EMBEDDED SQL PROGRAM - CDSPFAMESQL *
* *
* reads the input data *
* begins thread with UDS *
* retrieves the requested information from the database *
* displays this information on the printer *
* ends thread with UDS *
* *
*************************************************************** */

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <rsa.h>

/* ************************************************************
* ESQL STATEMENT STATUS
************************************************************ */
char SQLSTATE[6];
#define NO_FIND_STATUS "02000"
/* ************************************************************
* RDMS WORK AREA SIZE
************************************************************ */
int work_area_size = 2000;
/* ************************************************************
* UDS THREAD STATUS FLAG
************************************************************ */
int thread_flag = 0;
/* ************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************ */
EXEC SQL BEGIN DECLARE SECTION;
char employee_number[6];
char indr_last_name[21];
char indr_first_name[13];

Example 3–27. Source Listing of Embedded SQL Program (CDSPFAMESQL)

3–130 7831 4077–009

 Application Programming in a Batch or Demand Environment

char child_last_name[21];
char child_first_name[13];
EXEC SQL END DECLARE SECTION;
int main(void)
{
/* ************************************************************
* READ EMPLOYEE NUMBER
************************************************************ */
printf ("Enter employee number:");
fflush(stdout);
scanf ("%5s",&employee_number);
/* ************************************************************
* RSA WORK AREA SIZE
************************************************************ */
rsa_init (&work_area_size);
/* ************************************************************
* GENERAL ERROR PROCESSING FOR A NEGATIVE SQL ERROR
************************************************************ */
EXEC SQL WHENEVER SQLERROR GO TO: HANDLE_SQL_ERROR;
/* ************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
* SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
************************************************************ */
EXEC SQL BEGIN THREAD CDSPDATA FOR APPSVN RETRIEVE;
thread_flag = 1;
EXEC SQL USE DEFAULT QUALIFIER FAMILY;
/* ************************************************************
* SINGLETON SELECT OF THE INDIVIDUAL'S DATA
************************************************************ */
EXEC SQL
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :indr_last_name, :indr_first_name
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :employee_number;
if (strcmp(SQLSTATE,NO_FIND_STATUS) == 0)
{ printf("NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER: %s\n",
employee_number);
printf("PROGRAM HAS COMPLETED");
EXEC SQL END THREAD;
thread_flag = 0;
return(0);
}
else
{ printf("INDIVIDUAL DATA \n");
printf(" EMPLOYEE NUMBER IS %s\n",employee_number);
printf(" LAST NAME: %s\n",indr_last_name);
printf(" FIRST NAME: %s\n",indr_first_name);

Example 3–27. Source Listing of Embedded SQL Program (CDSPFAMESQL)

7831 4077–009 3–131

Application Programming in a Batch or Demand Environment

}
/* ************************************************************
* DEFINE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN CURSOR
************************************************************ */
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :employee_number;
EXEC SQL OPEN CHILDDATA;

/* ************************************************************
* RETRIEVE DATA FROM THE CURSOR
************************************************************ */
while(1)
{ EXEC SQL
FETCH NEXT CHILDDATA INTO :child_last_name, :child_first_name;
if (strcmp(SQLSTATE, NO_FIND_STATUS) != 0)
printf(" CHILD NAME: %s %s\n",
child_first_name, child_last_name);
else break;
}
/* ************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************ */
EXEC SQL END THREAD;
thread_flag = 0;
/* ************************************************************
* TERMINATE PROGRAM
************************************************************ */
printf("PROGRAM HAS COMPLETED\n");
return(0);
/* ************************************************************
* RETURN AN ERROR MESSAGE ON THE PRINTER IF A
* DATABASE ERROR OCCURS
************************************************************ */
HANDLE_SQL_ERROR:
handle_sqlerror();
return(0);
}
void handle_sqlerror(void)
{
char msg[133];
EXEC SQL WHENEVER SQLERROR CONTINUE;
printf("***SQLSTATE = %p\n", SQLSTATE);
printf("GETERROR returned the following text for SQLSTATE:\n\n");
do

Example 3–27. Source Listing of Embedded SQL Program (CDSPFAMESQL)

3–132 7831 4077–009

 Application Programming in a Batch or Demand Environment

{
EXEC SQL GETERROR INTO :msg;
printf("%s\n",msg);
}
while(msg[0] != '\0');
EXEC SQL END THREAD;
thread_flag = 0;
}

Example 3-27. Source Listing of Embedded SQL Program (CDSPFAMESQL)

7831 4077–009 3–133

Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–28 shows the source listing of a runstream to compile, link, and execute
the example program CDSPFAMESQL. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** UC COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UC QUAL*UCSTST.DISPLAYFAM/ESQL-C,QUAL*UCSTST.CDSPFAMESQL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** STATIC LINK OF THE EMBEDDED SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.CDSPFAMESQL
INCLUDE QUAL*UCSTST.CDSPFAMESQL/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THE EMBEDDED SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.CDSPFAMESQL
10211
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–28. Source Listing of Runstream—CDSPFAMESQL

3–134 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–29 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** UC COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UC QUAL*UCSTST.DISPLAYFAM/ESQL-C,QUAL*UCSTST.CDSPFAMESQL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
UC- 4R2(931119) LSS- 8R2(931209) 940209 10:51:27
SIZES: CODE(EM6): 657 DATA: 1071
END UC- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING(LEVEL)
@ . ***
@ . ***
@ . *** STATIC LINK OF THE EMBEDDED SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.CDSPFAMESQL
LINK 5R2 (940112 1230:40) 1994 Feb 09 Wed 1052:03
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THE EMBEDDED SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.CDSPFAMESQL
Enter employee number:
INDIVIDUAL DATA
EMPLOYEE NUMBER IS 10211
LAST NAME: FIELDING
FIRST NAME: STEVEN
CHILD NAME: STEVEN JR FIELDING
CHILD NAME: DANIEL FIELDING
CHILD NAME: JANE FIELDING
PROGRAM HAS COMPLETED
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–29. Execution of Source Runstream—CDSPFAMESQL

7831 4077–009 3–135

Application Programming in a Batch or Demand Environment

Source Listing of the FORTRAN Module Language Program

Example 3-30 shows the complete source listing of the FORTRAN Module Language
program DISPLAYFAM/MSQL-FMOD.

This program defines the cursor and procedure definitions called by the FORTRAN
host language application program DISPLAYFAM/MSQL-FHOST. In this example, this
program resides in element QUAL*UCSTST.DISPLAYFAM/MSQL-FMOD. Noteworthy
lines are bolded.

MODULE SQLPROCS
LANGUAGE FORTRAN
AUTHORIZATION FAMILY
--
-- *******************************************************************
-- This module defines the cursor and procedure definitions called
-- by the FORTRAN host application program
-- *******************************************************************
--
-- Individual's children cursor definition
--
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMPLOYEE_NUMBER
--
-- Procedure to begin thread with UDS
--
PROCEDURE BEGINTHREAD
(SQLSTATE);
BEGIN THREAD FDSPDATA FOR APPSVN RETRIEVE;
--
-- Procedure to fetch the requested individual
--
PROCEDURE SINGLESELECTIND
(SQLSTATE,
:EMPLOYEE_NUMBER CHAR(5),
:INDR_LAST_NAME CHAR(20),
:INDR_FIRST_NAME CHAR(12));
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :INDR_LAST_NAME, :INDR_FIRST_NAME
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :EMPLOYEE_NUMBER;
--
-- Procedure to open the individual's children cursor
--
PROCEDURE OPENCHILDCURSOR
(SQLSTATE,

Example 3–30. Source Listing of FORTRAN Module Language Program

3–136 7831 4077–009

 Application Programming in a Batch or Demand Environment

:EMPLOYEE_NUMBER CHAR(5));
OPEN CHILDDATA;
--
-- Procedure to fetch the children of an individual using the
-- CHILDDATA cursor
--
PROCEDURE FETCHCHILD
(SQLSTATE,
:CHILD_LAST_NAME CHAR(20),
:CHILD_FIRST_NAME CHAR(12));
FETCH NEXT CHILDDATA INTO :CHILD_LAST_NAME, :CHILD_FIRST_NAME;
--
-- Procedure to end thread with UDS
--
PROCEDURE ENDTHREAD
(SQLSTATE);
END THREAD;
--
-- Procedure to call GETERROR to obtain message description for
-- SQLSTATE status
--
PROCEDURE GETERRORTEXT
(SQLSTATE,
:MSG1 CHAR(132),
:MSG2 CHAR(132),
:MSG3 CHAR(132),
:MSG4 CHAR(132),
:MSG5 CHAR(132));
GETERROR INTO :MSG1, :MSG2, :MSG3, :MSG4, :MSG5;

Example 3-30. Source Listing of FORTRAN Module Language Program

7831 4077–009 3–137

Application Programming in a Batch or Demand Environment

Source Listing of the FORTRAN Host Language Application Program

Example 3–31 shows the complete source listing of the FORTRAN host language
application program, DISPLAYFAM/MSQL-FHOST. This program accepts an employee
number as input and displays the information contained in this database about this
individual’s family.

In this example, this program resides in element QUAL*UCSTST.DISPLAYFAM/MSQL-

FHOST. Noteworthy lines are bolded.

PROGRAM HOST_SQL
IMPLICIT NONE
C *******************************************************************
C *******************************************************************
C *
C * SIMPLE BATCH FORTRAN RDMS MODULE SQL PROGRAM - DSPFAMMSQL
C *
C * reads the input data
C * calls the module program to begin the thread with UDS
C * calls the module program to retrieve the requested information
C * from the database
C * prints this information on the printer
C * calls the module program to begin the thread with UDS
C *
C *******************************************************************
C *******************************************************************
C *
C *
C * Variable to hold employee number input
C *
CHARACTER EMPLOYEE_NUMBER*5
C *
C * UDS thread status flag
C *
INTEGER THREAD_FLAG
C *
C * Relational database information
C *
CHARACTER INDR_LAST_NAME*20
CHARACTER INDR_FIRST_NAME*12
CHARACTER CHILD_LAST_NAME*20
CHARACTER CHILD_FIRST_NAME*12
C *
C * ESQL statement status
C *
CHARACTER SQLSTATE*5

Example 3–31. Source Listing of the FORTRAN Host Language Application Program

3–138 7831 4077–009

 Application Programming in a Batch or Demand Environment

CHARACTER GOOD_STATUS*5
PARAMETER (GOOD_STATUS = '00000')
CHARACTER NO_FIND_STATUS*5
PARAMETER (NO_FIND_STATUS = '02000')
C *
C * Initialize UDS thread status flag
C *
DATA THREAD_FLAG/0/

C *
C *******************************************************************
C *
C * Input employee number
C *
PRINT *,'ENTER EMPLOYEE NUMBER'
READ *,EMPLOYEE_NUMBER
C *
C * Initialize with the database system
C *
CALL BEGINTHREAD(SQLSTATE)
IF (SQLSTATE .NE. GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
THREAD_FLAG = 1
C *
C * Retrieve individual data
C *
CALL SINGLESELECTIND
& (SQLSTATE,EMPLOYEE_NUMBER,INDR_LAST_NAME,INDR_FIRST_NAME)
IF (SQLSTATE .EQ. NO_FIND_STATUS) THEN
PRINT *,'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER ',
& EMPLOYEE_NUMBER
CALL ENDTHREAD(SQLSTATE)
IF (SQLSTATE .NE. GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
THREAD_FLAG = 0
PRINT *,'PROGRAM HAS COMPLETED '
STOP
ELSE IF (SQLSTATE .NE. GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
ELSE
PRINT*, 'INDIVIDUAL DATA'
PRINT*, ' EMPLOYEE NUMBER IS ', EMPLOYEE_NUMBER
PRINT*, ' LAST NAME: ', INDR_LAST_NAME
PRINT*, ' FIRST NAME: ', INDR_FIRST_NAME
END IF

Example 3–31. Source Listing of the FORTRAN Host Language Application Program

7831 4077–009 3–139

Application Programming in a Batch or Demand Environment

C *
C * Open cursor to be used for data retrieval(CHILDDATA)
C *
CALL OPENCHILDCURSOR(SQLSTATE,EMPLOYEE_NUMBER)
IF (SQLSTATE .NE. GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
C *
C * Retrieve data from the cursor
C *
100 CALL FETCHCHILD(SQLSTATE,CHILD_LAST_NAME,CHILD_FIRST_NAME)
IF (SQLSTATE .EQ. GOOD_STATUS) THEN
PRINT *, ' CHILD NAME: ',
& CHILD_FIRST_NAME, ' ',
& CHILD_LAST_NAME
GOTO 100
ELSE IF (SQLSTATE .NE. NO_FIND_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
C *
C * Terminate with the database system
C *
CALL ENDTHREAD(SQLSTATE)
IF (SQLSTATE .NE. GOOD_STATUS) THEN
CALL HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
END IF
THREAD_FLAG = 0
STOP

C ******************************************************************

SUBROUTINE HANDLE_BAD_SQLSTATE_STATUS(SQLSTATE)
C *******************************************************************
C * ESQL STATEMENT STATUS
C *******************************************************************
CHARACTER SQLSTATE*5
C *******************************************************************
C * GETERROR BUFFERS
C *******************************************************************
CHARACTER SQL_ERR_MSG(5)*132
C *******************************************************************
C * INDEX FOR GETERROR PRINTS
C *******************************************************************
INTEGER I
C *
C * Returns an error message on the printer if a database error occurs
C *

Example 3–31. Source Listing of the FORTRAN Host Language Application Program

3–140 7831 4077–009

 Application Programming in a Batch or Demand Environment

PRINT *, '*PROGRAM TERMINATED IN ERROR'

PRINT *, '*SQLSTATE = ', SQLSTATE
PRINT *, '*GETERROR returned the following text for SQLSTATE:'

200 DO 300 I = 1, 5
SQL_ERR_MSG(I) = ' '
300 CONTINUE

CALL GETERRORTEXT(SQLSTATE,
& SQL_ERR_MSG(1),
& SQL_ERR_MSG(2),
& SQL_ERR_MSG(3),
& SQL_ERR_MSG(4),
& SQL_ERR_MSG(5))

DO 400 I = 1, 5
IF (SQL_ERR_MSG(I) .NE. ' ') THEN
PRINT *, SQL_ERR_MSG(I)
IF (I .EQ. 5) GO TO 200
END IF
400 CONTINUE
C *
C * Terminate with the database system
C *
CALL ENDTHREAD(SQLSTATE)
THREAD_FLAG = 0
STOP
END

Example 3–31. Source Listing of the FORTRAN Host Language Application Program

7831 4077–009 3–141

Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–32 shows the source listing of a runstream used to compile, link, and
execute the example programs DISPLAYFAM/MSQL-FMOD and DISPLAYFAM/MSQL-
FHOST. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** UFTN MODULE SQL PROGRAM PREPROCESSING
@ . ***
@SMLP,C QUAL*UCSTST.DISPLAYFAM/MSQL-FMOD,QUAL*UCSTST.FMOD
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UCOB,S QUAL*UCSTST.FMOD/COB,QUAL*UCSTST.,,,NO-OPTIONS,NARROW, ;
APPLICATION/APPSVN,MODULE
@ . ***
@ . ***
@ . *** UFTN COMPILE OF THE MODULE SQL HOST PROGRAM
@ . ***
@UFTN QUAL*UCSTST.DISPLAYFAM/MSQL-FHOST,QUAL*UCSTST.FHOST,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** STATIC LINK OF THE MODULE SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DSPFAMMSQL
INCLUDE QUAL*UCSTST.FHOST
RESOLVE ALL REFERENCES USING QUAL*UCSTST.,LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THE MODULE SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DSPFAMMSQL
'10211'
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–32. Source Listing of Runstream—DISPLAYFAM/MSQL-FMOD and

DISPLAYFAM/MSQL-FHOST

3–142 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–33 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** UFTN MODULE SQL PROGRAM PREPROCESSING
@ . ***
@SMLP,C QUAL*UCSTST.DISPLAYFAM/MSQL-FMOD,QUAL*UCSTST.FMOD
SMLP 8R2 02/10/94 22:34:31
***** 163 line COBOL program produced ****
END SMLP 0 ERRORS 0 WARNINGS
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE EMBEDDED SQL PROGRAM
@ . ***
@UCOB,S QUAL*UCSTST.FMOD/COB,QUAL*UCSTST.,,,NO-OPTIONS,NARROW, ;
APPLICATION/APPSVN,MODULE
UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31
1 * This source was generated by the 2200 SQL Module Language Processor.
2 * Edit at your own risk.
3
4
5 IDENTIFICATION DIVISION.
6 PROGRAM-ID. BEGINTHREAD.
7 ENVIRONMENT DIVISION.
8 CONFIGURATION SECTION.
9 SOURCE-COMPUTER. UNISYS-2200.
10 OBJECT-COMPUTER. UNISYS-2200.
11 DATA DIVISION.
12 FILE SECTION.
13 WORKING-STORAGE SECTION.
14 LINKAGE SECTION.
15 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
16 01 SQLSTATE PIC X(5).
17 EXEC SQL END DECLARE SECTION END-EXEC.
18 PROCEDURE DIVISION USING SQLSTATE.
19 P0.
20 EXEC SQL
21 USE DEFAULT QUALIFIER FAMILY
22 END-EXEC.
23 EXEC SQL

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-FMOD and

DISPLAYFAM/MSQL-FHOSTE

7831 4077–009 3–143

Application Programming in a Batch or Demand Environment

*WARNING(NONSTANDARD) UCOB7010: RSA SQL STANDARD WARNING FOLLOWS:

*WARNING 7002: The application name on your BEGIN THREAD will be ignored.
The application name specified on the keyword APPLICATION option
will be used for the runtime execution of this command.
v
24 21 BEGIN THREAD FDSPDATA FOR APPSVN RETRIEVE
25 END-EXEC.
26 END PROGRAM BEGINTHREAD.
27
** OBJECT MODULE FMOD/COB GENERATED
SIZES: CODE(EM6): 70 DATA: 108

UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31

28 IDENTIFICATION DIVISION.
29 PROGRAM-ID. SINGLESELECTIND.
30 ENVIRONMENT DIVISION.
31 CONFIGURATION SECTION.
32 SOURCE-COMPUTER. UNISYS-2200.
33 OBJECT-COMPUTER. UNISYS-2200.
34 DATA DIVISION.
35 FILE SECTION.
36 WORKING-STORAGE SECTION.
37 LINKAGE SECTION.
38 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
39 01 SQLSTATE PIC X(5).
40 01 EMPLOYEE-NUMBER PIC X(5).
41 01 INDR-LAST-NAME PIC X(20).
42 01 INDR-FIRST-NAME PIC X(12).
43 EXEC SQL END DECLARE SECTION END-EXEC.
44 PROCEDURE DIVISION USING SQLSTATE EMPLOYEE-NUMBER INDR-LAST-NAME
45 INDR-FIRST-NAME.
46 P0.
47 EXEC SQL
48 USE DEFAULT QUALIFIER FAMILY
49 END-EXEC.
50 EXEC SQL
51 30 SELECT INDR_LAST_NAME, INDR_FIRST_NAME
52 31 INTO :INDR-LAST-NAME, :INDR-FIRST-NAME
53 32 FROM INDIVIDUALR
54 33 WHERE INDIVIDUALR.INDR_EMP_NUMBER = :EMPLOYEE-NUMBER
55 END-EXEC.
56 END PROGRAM SINGLESELECTIND.
57
** OBJECT MODULE FMOD/$$$$1 GENERATED
SIZES: CODE(EM6): 97 DATA: 285

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-

FMOD and DISPLAYFAM/MSQL-FHOSTE

3–144 7831 4077–009

 Application Programming in a Batch or Demand Environment

UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31

58 IDENTIFICATION DIVISION.
59 PROGRAM-ID. OPENCHILDCURSOR.
60 ENVIRONMENT DIVISION.
61 CONFIGURATION SECTION.
62 SOURCE-COMPUTER. UNISYS-2200.
63 OBJECT-COMPUTER. UNISYS-2200.
64 DATA DIVISION.
65 FILE SECTION.
66 WORKING-STORAGE SECTION.
67 LINKAGE SECTION.
68 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
69 01 SQLSTATE PIC X(5).
70 01 EMPLOYEE-NUMBER PIC X(5).
71 EXEC SQL END DECLARE SECTION END-EXEC.
72 PROCEDURE DIVISION USING SQLSTATE EMPLOYEE-NUMBER.
73 P0.
74 EXEC SQL
75 USE DEFAULT QUALIFIER FAMILY
76 END-EXEC.
77 EXEC SQL
78 12 DECLARE CHILDDATA CURSOR
79 13 SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
80 14 FROM CHILD
81 15 WHERE CHILD.CHILD_EMP_NUMBER = :EMPLOYEE-NUMBER
82 END-EXEC.
83 EXEC SQL
84 40 OPEN CHILDDATA
85 END-EXEC.
86 END PROGRAM OPENCHILDCURSOR.
87
** OBJECT MODULE FMOD/$$$$2 GENERATED
SIZES: CODE(EM6): 93 DATA: 301
UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31
88 IDENTIFICATION DIVISION.
89 PROGRAM-ID. FETCHCHILD.
90 ENVIRONMENT DIVISION.
91 CONFIGURATION SECTION.
92 SOURCE-COMPUTER. UNISYS-2200.
93 OBJECT-COMPUTER. UNISYS-2200.
94 DATA DIVISION.
95 FILE SECTION.
96 WORKING-STORAGE SECTION.
97 LINKAGE SECTION.
98 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
99 01 SQLSTATE PIC X(5).

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-

FMOD and DISPLAYFAM/MSQL-FHOSTE

7831 4077–009 3–145

Application Programming in a Batch or Demand Environment

100 01 CHILD-LAST-NAME PIC X(20).

101 01 CHILD-FIRST-NAME PIC X(12).
102 EXEC SQL END DECLARE SECTION END-EXEC.
103 PROCEDURE DIVISION USING SQLSTATE CHILD-LAST-NAME CHILD-FIRST-NAME
104 .
105 P0.
106 EXEC SQL
107 USE DEFAULT QUALIFIER FAMILY
108 END-EXEC.
109 EXEC SQL
110 49 FETCH NEXT CHILDDATA INTO :CHILD-LAST-NAME, :CHILD-FIRST-NAME
111 END-EXEC.
112 END PROGRAM FETCHCHILD.
113
** OBJECT MODULE FMOD/$$$$3 GENERATED
SIZES: CODE(EM6): 86 DATA: 146
UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31
114 IDENTIFICATION DIVISION.
115 PROGRAM-ID. ENDTHREAD.
116 ENVIRONMENT DIVISION.
117 CONFIGURATION SECTION.
118 SOURCE-COMPUTER. UNISYS-2200.
119 OBJECT-COMPUTER. UNISYS-2200.
120 DATA DIVISION.
121 FILE SECTION.
122 WORKING-STORAGE SECTION.
123 LINKAGE SECTION.
124 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
125 01 SQLSTATE PIC X(5).
126 EXEC SQL END DECLARE SECTION END-EXEC.
127 PROCEDURE DIVISION USING SQLSTATE.
128 P0.
129 EXEC SQL
130 USE DEFAULT QUALIFIER FAMILY
131 END-EXEC.
132 EXEC SQL
133 55 END THREAD
134 END-EXEC.
135 END PROGRAM ENDTHREAD.
136
** OBJECT MODULE FMOD/$$$$4 GENERATED
SIZES: CODE(EM6): 70 DATA: 108
UCOB- 6R2(931119) LSS- 8R2(931209) 940210 22:34:31
137 IDENTIFICATION DIVISION.
138 PROGRAM-ID. GETERRORTEXT.

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-

FMOD and DISPLAYFAM/MSQL-FHOSTE

3–146 7831 4077–009

 Application Programming in a Batch or Demand Environment

139 ENVIRONMENT DIVISION.

140 CONFIGURATION SECTION.
141 SOURCE-COMPUTER. UNISYS-2200.
142 OBJECT-COMPUTER. UNISYS-2200.
143 DATA DIVISION.
144 FILE SECTION.
145 WORKING-STORAGE SECTION.
146 LINKAGE SECTION.
147 EXEC SQL BEGIN DECLARE SECTION END-EXEC.
148 01 SQLSTATE PIC X(5).
149 01 MSG1 PIC X(132).
150 01 MSG2 PIC X(132).
151 01 MSG3 PIC X(132).
152 01 MSG4 PIC X(132).
153 01 MSG5 PIC X(132).
154 EXEC SQL END DECLARE SECTION END-EXEC.
155 PROCEDURE DIVISION USING SQLSTATE MSG1 MSG2 MSG3 MSG4 MSG5.
156 P0.
157 EXEC SQL
158 USE DEFAULT QUALIFIER FAMILY
159 END-EXEC.
160 EXEC SQL
161 67 GETERROR INTO :MSG1, :MSG2, :MSG3, :MSG4, :MSG5
162 END-EXEC.
163 END PROGRAM GETERRORTEXT.
** OBJECT MODULE FMOD/$$$$5 GENERATED
SIZES: CODE(EM6): 77 DATA: 42
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING(LEVEL)
@ . ***
@ . ***
@ . *** UFTN COMPILE OF THE MODULE SQL HOST PROGRAM
@ . ***
@UFTN QUAL*UCSTST.DISPLAYFAM/MSQL-FHOST,QUAL*UCSTST.FHOST,,,NO-OPTIONS
UFTN- 5R2(931119) LSS- 8R2(931209) 940210 22:34:42
SIZES: CODE(EM6): 263 DATA: 716
END UFTN- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 22 WARNINGS(LEVEL)
@ . ***
@ . ***
@ . *** STATIC LINK OF THE MODULE SQL PROGRAM TO PRODUCE A ZOOM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-

FMOD and DISPLAYFAM/MSQL-FHOSTE

7831 4077–009 3–147

Application Programming in a Batch or Demand Environment

@LINK ,QUAL*UCSTST.DSPFAMMSQL
LINK 5R2 (940112 1230:40) 1994 Feb 10 Thu 2234:45
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THE MODULE SQL PROGRAM
@ . ***
@XQT QUAL*UCSTST.DSPFAMMSQL
ENTER EMPLOYEE NUMBER
INDIVIDUAL DATA
EMPLOYEE NUMBER IS 10211
LAST NAME: FIELDING
FIRST NAME: STEVEN
CHILD NAME: STEVEN JR FIELDING
CHILD NAME: DANIEL FIELDING
CHILD NAME: JANE FIELDING
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–33. Execution of Source Runstream—DISPLAYFAM/MSQL-

FMOD and DISPLAYFAM/MSQL-FHOSTE

3–148 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of a Program Using the SQL Interpreter Interface (DSPFAMISQL)

Example 3-34 shows the complete source listing of DSPFAMISQL, a program using
the SQL interpreter interface. This program accepts an employee number as input
and displays the information contained in this database about this individual’s family.

In this example, this program resides in element QUAL*UCSTST.DISPLAYFAM/ISQL.

Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DSPFAMISQL.
DATE-COMPILED.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL RDMS NONEMBEDDED SQL PROGRAM - DSPFAMISQL *
* *
* reads the input data *
* begins thread with UDS *
* retrieves the requested information from the database *
* displays this information on the printer *
* ends thread with UDS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 INVALID-EMPLOYEE-NUMBER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 INDR-LAST-NAME PIC X(20).
01 INDR-FIRST-NAME PIC X(12).

Example 3–34. Source Listing of the Interpreted SQL Program

(QUAL*UCSTST.DISPLAYFAM/ISQL)

7831 4077–009 3–149

Application Programming in a Batch or Demand Environment

01 CHILD-LAST-NAME PIC X(20).

01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* RELATIONAL COMMAND LINE
************************************************************
01 RCOM-AREA.
10 R-LINE PIC X(40) OCCURS 30 TIMES.
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
01 ERROR-STATUS PIC 9999.
01 AUX-INFO PIC S1(36) USAGE BINARY-1.
01 ERROR-TEXT.
05 ERR-S PIC X(132) OCCURS 5 TIMES.
************************************************************
* UDS THREAD STATUS FLAG
************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* INDEX FOR THE ERROR-DISPLAY PERFORM
************************************************************
01 ERR-INDEX PIC 9.
***********************************************************
* ALLERROR INDICATOR
************************************************************
01 XX PIC 9 VALUE 0.
88 ALLERR VALUE 1.

PROCEDURE DIVISION.
************************************************************
* PROGRAM FLOW
************************************************************
MAIN-PROGRAM-FLOW.
DISPLAY 'ENTER EMPLOYEE NUMBER' UPON PRINTER.
ACCEPT EMPLOYEE-NUMBER.
PERFORM BEGIN-THREAD-TO-UDS.
IF ERROR-STATUS = ZERO
MOVE 1 TO THREAD-FLAG.
PERFORM SET-DEFAULT-QUALIFIER.
IF ERROR-STATUS = ZERO
PERFORM SINGLETON-SELECT-INDRDATA.
IF ERROR-STATUS = 6001
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
PERFORM END-THREAD-TO-UDS
PERFORM TERMINATION-PARA.
IF ERROR-STATUS = ZERO

Example 3–34. Source Listing of the Interpreted SQL Program

(QUAL*UCSTST.DISPLAYFAM/ISQL)

3–150 7831 4077–009

 Application Programming in a Batch or Demand Environment

PERFORM DISPLAY-INDIVIDUAL-DATA
PERFORM DEFINE-CHILDDATA-CURSOR.
IF ERROR-STATUS = ZERO
PERFORM OPEN-CHILDDATA-CURSOR.
IF ERROR-STATUS = ZERO
PERFORM FETCH-FROM-CHILDDATA-CURSOR
WITH TEST AFTER UNTIL ERROR-STATUS NOT = ZERO.
IF ERROR-STATUS NOT = 6001 AND ERROR-STATUS NOT = ZERO
PERFORM RDMS-ERROR-PARA.
PERFORM END-THREAD-TO-UDS.
PERFORM TERMINATION-PARA.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
************************************************************
BEGIN-THREAD-TO-UDS.
ENTER MASM 'ACOB$RDMR' USING
'BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE ;'
ERROR-STATUS, AUX-INFO.
************************************************************
* SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
************************************************************
SET-DEFAULT-QUALIFIER.
ENTER MASM 'ACOB$RDMR' USING
'USE DEFAULT QUALIFIER FAMILY ;'
ERROR-STATUS, AUX-INFO.
************************************************************
* SINGLETON SELECT OF THE INDIVIDUAL'S DATA
************************************************************
SINGLETON-SELECT-INDRDATA.
MOVE SPACES TO RCOM-AREA.
MOVE 'SELECT ' TO R-LINE (1).
MOVE ' INDR_LAST_NAME, INDR_FIRST_NAME ' TO R-LINE (2).
MOVE ' INTO $P1, $P2 ' TO R-LINE (3).
MOVE ' FROM INDIVIDUALR ' TO R-LINE (4).
MOVE ' WHERE INDIVIDUALR.INDR_EMP_NUMBER ' TO R-LINE (5).
MOVE ' = $P3 ; ' TO R-LINE (6).
ENTER MASM 'ACOB$RDMR' USING RCOM-AREA,
ERROR-STATUS, AUX-INFO,
INDR-LAST-NAME, INDR-FIRST-NAME, EMPLOYEE-NUMBER.
************************************************************
* DISPLAY THE INDIVIDUAL'S INFORMATION TO THE PRINTER
************************************************************
DISPLAY-INDIVIDUAL-DATA.
DISPLAY 'INDIVIDUAL DATA' UPON PRINTER.
DISPLAY ' EMPLOYEE NUMBER IS ' EMPLOYEE-NUMBER UPON PRINTER.
DISPLAY ' LAST NAME: ' INDR-LAST-NAME UPON PRINTER.
DISPLAY ' FIRST NAME: ' INDR-FIRST-NAME UPON PRINTER.

Example 3–34. Source Listing of the Interpreted SQL Program

(QUAL*UCSTST.DISPLAYFAM/ISQL)

7831 4077–009 3–151

Application Programming in a Batch or Demand Environment

************************************************************
* DEFINE CURSOR TO BE USED FOR DATA RETRIEVAL
************************************************************
DEFINE-CHILDDATA-CURSOR.
MOVE SPACES TO RCOM-AREA.
MOVE 'DECLARE CHILDDATA CURSOR ' TO R-LINE (1).
MOVE ' SELECT ' TO R-LINE (2).
MOVE ' CHILD_LAST_NAME, CHILD_FIRST_NAME ' TO R-LINE (3).
MOVE ' FROM CHILD ' TO R-LINE (4).
MOVE ' WHERE CHILD.CHILD_EMP_NUMBER ' TO R-LINE (5).
MOVE ' = $P1 ; ' TO R-LINE (6).
ENTER MASM 'ACOB$RDMR' USING RCOM-AREA,
ERROR-STATUS, AUX-INFO, EMPLOYEE-NUMBER.
************************************************************
* OPEN CURSOR
************************************************************
OPEN-CHILDDATA-CURSOR.
ENTER MASM 'ACOB$RDMR' USING
'OPEN CHILDDATA USING $P1 ;'
ERROR-STATUS, AUX-INFO, EMPLOYEE-NUMBER.
************************************************************
* RETRIEVE DATA FROM THE CURSOR
************************************************************
FETCH-FROM-CHILDDATA-CURSOR.
ENTER MASM 'ACOB$RDMR' USING
'FETCH NEXT CHILDDATA INTO $P1, $P2, ;'
ERROR-STATUS, AUX-INFO,
CHILD-LAST-NAME, CHILD-FIRST-NAME.
IF ERROR-STATUS = ZERO
DISPLAY ' CHILD NAME: ' CHILD-FIRST-NAME, ' ',
CHILD-LAST-NAME UPON PRINTER
END-IF.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************
END-THREAD-TO-UDS.
ENTER MASM 'ACOB$RDMR' USING
'END THREAD ;'
ERROR-STATUS, AUX-INFO.
MOVE 0 TO THREAD-FLAG.
************************************************************
* TERMINATE PROGRAM
************************************************************
TERMINATION-PARA.
DISPLAY 'PROGRAM HAS COMPLETED' UPON PRINTER.
STOP RUN.

Example 3–34. Source Listing of the Interpreted SQL Program

(QUAL*UCSTST.DISPLAYFAM/ISQL)

3–152 7831 4077–009

 Application Programming in a Batch or Demand Environment

*
************************************************************
* RETURN AN ERROR MESSAGE ON THE PRINTER IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
DISPLAY 'ERROR STATUS = ' ERROR-STATUS UPON PRINTER.
DISPLAY 'AUXILIARY INFORMATION = ' AUX-INFO UPON PRINTER.
MOVE 'GETERROR INTO $P1, $P2, $P3, $P4, $P5 ;' TO RCOM-AREA.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT
ENTER MASM 'ACOB$RDMR' USING RCOM-AREA,
ERROR-STATUS, AUX-INFO, ERR (1), ERR (2), ERR (3),
ERR (4), ERR (5)
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.

Example 3–34. Source Listing of the Interpreted SQL Program

(QUAL*UCSTST.DISPLAYFAM/ISQL)

7831 4077–009 3–153

Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–35 shows the source listing of a runstream used to compile, link, and
execute the example program. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *********************
@ . ***
@ . ***
@ . *** UCOB COMPILATION OF THE INTERPRETER SQL PROGRAM
@ . ***
@UCOB QUAL*UCSTST.DISPLAYFAM/ISQL,QUAL*UCSTST.DSPFAMISQL/COMP,,, ;
NO-OPTIONS
@ . ***
@ . ***
@ . *** EXECUTION OF THE INTERPRETIVE SQL PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*UCSTST.DSPFAMISQL/COMP
10211
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–35. Runstream to Compile, Link, and Execute COBOL Interpreter SQL
Program

3–154 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–36 shows the execution of the source runstream used to compile, link,
and execute this example. Output has been saved by an @BRKPT statement.
Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *********************
@ . ***
@ . ***
@ . *** UCOB COMPILATION OF THE INTERPRETER SQL PROGRAM
@ . ***
@UCOB QUAL*UCSTST.DISPLAYFAM/ISQL,QUAL*UCSTST.DSPFAMISQL/COMP,,, ;
NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 15:12:04
SIZES: CODE(EM6): 520 DATA: 1404
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** EXECUTION OF THE INTERPRETIVE SQL PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@XQT QUAL*UCSTST.DSPFAMISQL/COMP

ENTER EMPLOYEE NUMBER

INDIVIDUAL DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

CHILD NAME: STEVEN JR FIELDING

CHILD NAME: DANIEL FIELDING

CHILD NAME: JANE FIELDING

Example 3–36. Execution of Source Runstream—COBOL Interpreted SQL Program

7831 4077–009 3–155

Application Programming in a Batch or Demand Environment

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–36. Execution of Source Runstream—COBOL Interpreted SQL

Program

3.2.3. Using SFS 2200 Databases

The Shared File System (SFS 2200) is a Universal Data System (UDS) software product
that consists of a collection of file access routines. SFS 2200:
• Provides shared access to a file by more than one program at a time
• Has all the recovery and locking features provided by the UDS environment

SFS 2200 provides access to both of the following types of UCS COBOL files:
• Relative files
A UCS COBOL relative file is an SFS 2200 direct system data format (DSDF) file.

• Indexed files
A UCS COBOL indexed file is an SFS 2200 multi-indexed sequential access method
(MSAM) file.

SFS 2200 also provides support for direct SDF files for UCS FORTRAN and UCS C. In
UCS C, direct sequential data files are called binary files. Table 3-4 shows the SFS
2200 file access methods (file organization methods) supported for the UCS
languages.

Table 3–4. SFS 2200 File Access Methods

Supported for UCS Languages

UCS COBOL UCS FORTRAN UCS C

Relative Direct SDF Binary

(Direct SDF) (Direct SDF)
Indexed (MSAM)

3–156 7831 4077–009

 Application Programming in a Batch or Demand Environment

The SFS 2200 example in the following subsections uses an indexed (MSAM) COBOL
file that contains information about an individual’s participation in company-organized
sports:
• It is assumed that no individual will participate in more than three sports.
• The SPT-ACTIVE-COUNT field identifies the number of company sports the
individual currently plays.
• The individual’s employee number (SPT-EMP-NUMBER) uniquely identifies each
record occurrence.
• A second index exists on the last name of the individual (the last name is stored in
data item SPT-IND-LAST-NAME).

The following is the data definition of the SPORTS record.

FD SPORTS.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).

3.2.3.1. Defining SFS 2200 Files and Storage Areas

In order to set up an SFS 2200 file system, the following steps must occur:
1. Catalog the SFS 2200 files.
The following statement catalogs the SPORTS file for the example in the following
subsections.
@CAT,P LEISURE*SPORTS.,F/5//5

2. Define the UDS storage areas that map to the SFS 2200 files, using UREP.
• There must be one storage area per SFS 2200 file.
• The DATA-FORMAT attribute for the storage area must have a value of one of
the following:
− DSDF (direct system data format)
− MSAM (multi-indexed sequential access method file)
• The QUALIFIER attribute must be the same as the name of the SCHEMA for
this file.

7831 4077–009 3–157

Application Programming in a Batch or Demand Environment

3. After you define the storage areas, create the file description tables (FDT) required
by UDS by using the PROCESS STORAGE-AREA...INSTALL command.

The following runstream defines and processes the storage area for the SFS 2200 file,
SPORTS.
@UDS$$SVN*UREP$ABS.DD ,,APPSVN
CREATE SCHEMA LEISURE.
CREATE STORAGE-AREA SPORTS FOR SCHEMA LEISURE.
ADD FILE-TYPE IS EXEC.
ADD DATA-FORMAT IS MSAM.
ADD QUALIFIER IS LEISURE.
ADD DOMAIN IS UDS.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 10.
PROCESS STORAGE-AREA ALL FOR SCHEMA LEISURE INSTALL.
PROCESS STORAGE-AREA ALL FOR SCHEMA LEISURE REPORT.
EXIT.

UCS COBOL and UCS FORTRAN SFS 2200 files require no further processing for
program use. In fact, the same COBOL and FORTRAN SFS 2200 files can be used by
both UCS and non-UCS programs, as long as they contain no Fieldata characters.

UCS C SFS 2200 (binary) files require one more step in their setup, however. The
additional step is required because C does not have language syntax for specifying an
SFS 2200 file. You must create an external file description for C SFS 2200 files, using
the Define File Processor (DFP), a stand-alone preprocessor. You create this external
file description as a define-file-block omnibus element in a program file. The following
runstream creates this omnibus element in a file called UDS$$SVN*DFP$.

(1) @CAT,P UDS$$SVN*DFP$.

(2) @USE DFP$,UDS$$SVN*DFP$.
(3) @DFP,LE UDS$$SVN*data-file-name.,DFP$.data-file-name
(4) SHARE = YES
(5) @EOF

Explanation
1. This statement catalogs a file to hold the define-file-block omnibus element
created by DFP. The file in this example might be used to hold all of the define-
file-block omnibus elements for application group 7.
2. This statement places the @USE name of DFP$ on the file into which DFP is to
place its output. This @USE name is required by the Define File Processor.

3–158 7831 4077–009

 Application Programming in a Batch or Demand Environment

3. This statement calls the Define File Processor. The LE options specify that:
• A define-file-block omnibus element containing the description of the external
data file is to be built.
• A listing is to be produced.
The first field on the processor call identifies the SFS 2200 data file for which
this block is being built.
The second field identifies the file name (which must be DFP$) and element
name (which must be the same as the name of the data file) where the define-
file-block omnibus element is to be placed.
4. This input parameter identifies this file as an SFS 2200 (shared) file.
5. This statement terminates the runstream.

During execution of a UCS C SFS 2200 program, whenever the program opens an SFS
2200 file, the UCS Runtime System reads the define-file-block. This means that prior
to execution of a UCS C SFS 2200 program, you must do the following:
1. Assign the program file containing the define-file-block omnibus element to the
run.
2. Give the file an @USE name of DFP$.

This process is necessary so that when an SFS 2200 file is opened, the UCS Runtime
System knows where to locate the define-file-block omnibus element.

The following is an example of the commands required.

@ASG,A UDS$$SVN*DFP$.
@USE DFP$,UDS$$SVN*DFP$.

Remember that a define-file-block is not required by UCS COBOL and UCS FORTRAN
programs.

For more information on SFS 2200 programming, refer to the SFS Administration and
Support Reference Manual.

For more information on using DFP, refer to the DFP Administration and
Programming Reference Manual.

7831 4077–009 3–159

Application Programming in a Batch or Demand Environment

3.2.3.2. Example of an SFS 2200 Database Definition

The following subsections show an example of an SFS 2200 database definition. For
this example, one indexed (MSAM) file is set up. The file holds information about the
participation of an individual in company-sponsored sports. All employees have a
record occurrence in the file, even if they do not participate in any sport.

Source Listing of Runstream to Define the SFS 2200 File and Storage Area
Example 3–37 shows the source listing of a runstream used to define the SFS 2200 file
and storage area. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE SFS DATABASE DEFINITION SECTION ************
@ . ***
@ . ***
@ . *** CATALOG THE DATABASE STORAGE AREA FILES.
@ . ***
@CAT,P LEISURE*SPORTS.,F/5//5
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE SFS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD ,,APPSVN
CREATE SCHEMA LEISURE.
CREATE STORAGE-AREA SPORTS FOR SCHEMA LEISURE.
ADD FILE-TYPE IS EXEC.
ADD DATA-FORMAT IS MSAM.
ADD QUALIFIER IS LEISURE.
ADD DOMAIN IS UDS.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 10.
PROCESS STORAGE-AREA ALL FOR SCHEMA LEISURE INSTALL.
PROCESS STORAGE-AREA ALL FOR SCHEMA LEISURE REPORT.
EXIT.
@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE SFS DATABASE DEFINITION SECTION *************
@ . ***

Example 3–37. Runstream to Define the SFS 2200 File and Storage Area

3–160 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–38 shows the execution of the source runstream used to define the SFS
2200 file and storage area for this example. Output has been saved by an @BRKPT
statement. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE SFS DATABASE DEFINITION SECTION ************
@ . ***
@ . ***
@ . *** CATALOG THE DATABASE STORAGE AREA FILES.
@ . ***
@CAT,P LEISURE*SPORTS.,F/5//5
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE SFS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD ,,APPSVN
UREP 3R1 (11/04/93 10:17:39) 01/28/94 14:47:25
*REMARK* DSD4023 The INSTALL for STORAGE-AREA SPORTS VERSION ' ' for SCHEMA
LEISURE was SUCCESSFUL.
*REMARK* DSD4036 Your PROCESS STORAGE-AREA ALL command was successful.

*** Report for Storage-area SPORTS for Schema LEISURE ***

Preamble Length: 14 FDT Length: 20 Total Length: 34 Format: 5

File-Type: EXEC Data-Format: MSAM

File-Name: SPORTS #characters in name: 6
Qualifier: LEISURE #characters in name: 7
Read-Key: #characters in name: 0
Write-Key: #characters in name: 0

File-Status: UP Recovery: RECOVERED AUDITED

Checksum: NO
Maximum-Pages: 10 Page-Size: 896
Darp-Sarp: SARP Lock-Strategy: PAGE
Domain: UDS Keep-Assigned: FALSE
Merge-Factor: 40 Compression: ON
Data-Page_Factor: 100 Index-Page-Factor: 100
Directory: NULL
Rel-Index-Conc: FALSE
*REMARK* DSD4036 Your PROCESS STORAGE-AREA ALL command was successful.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 3 )REMARKS .

Example 3–38. Execution of Source Runstream—SFS Database Setup

7831 4077–009 3–161

Application Programming in a Batch or Demand Environment

@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE SFS DATABASE DEFINITION SECTION *************
@ . ***

Example 3–38. Execution of Source Runstream—SFS Database Setup

3.2.3.3. Coding UCS Programs That Access SFS 2200 Databases

SFS 2200 files used by UCS COBOL and UCS FORTRAN require special program syntax
to identify these files as SFS 2200 files.

(For UCS C, this is accomplished instead by use of the Define File Processor; refer to
"SFS 2200 Files and Storage Areas.")

UCS COBOL
UCS COBOL identifies SFS 2200 files by using the A-SHARED-FILE syntax in the
SELECT clause. The following SELECT clauses show the syntax for identifying a
relative (DSDF) file and an indexed (MSAM) file for COBOL:

Relative (DSDF) File

SELECT file01 ASSIGN TO A-SHARED-FILE...RELATIVE....

Indexed (MSAM) File

SELECT file02 ASSIGN TO A-SHARED-FILE...INDEXED....

UCS FORTRAN
UCS FORTRAN identifies SFS 2200 files by the RFORM setting in the OPEN statement.
A value of LS, MS, ES, FS, US, or VS identifies the file as an SFS 2200 file. (The "S"
stands for shared.)

The following OPEN statement shows an example of this syntax:

OPEN (UNIT=10,ACCESS='DIRECT',RFORM='ES',RECL=132)

3–162 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.3.4. Compiling UCS Programs That Access SFS 2200 Databases

Compiling a UCS program that accesses an SFS 2200 database is straightforward. You
merely call the appropriate UCS compiler, identify the element containing the source
input, and specify the element to contain the output object module, as usual.

@UCOB . . . .
or
@UCOB . . . . ,,,COMPAT
UCS SFS or UCS SFS
Source @UFTN . . . . Object
Program or Module
@UC . . . .
qual*progfile.source
qual*progfile.om/comp

002326

Only UCS COBOL might require a special keyword option. If the program uses the
ASCII COBOL usage clauses in the file definitions, you must use the COMPAT keyword
option to ensure an error-free compilation.

The following statement shows an example of a compilation:

@UCOB QUAL*UCSTST.DISPLAYSPT,QUAL*UCSTST.DISPLAYSPT/COMP,,,NO-OPTIONS

3.2.3.5. Basic Linking Information for UCS SFS 2200 Programs

When statically or dynamically linking a UCS program that accesses an SFS 2200
database, you must specify use of a special application group library search chain by
using an @USE LINK$PF statement. This library search chain causes the Linking
System to resolve references using the SFS 2200 software for a particular application
group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the SFS 2200 interface
during static linking

7831 4077–009 3–163

Application Programming in a Batch or Demand Environment

The following generic format shows how to specify use of the appropriate application
group library search chain:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program that accesses an SFS 2200 database to the system
software in application group 7, use the following statement:
@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to SFS 2200 software would be resolved using
UDS$$SVN*SFS.

For more information on these library search chains, see Section 4.

Before SB4, you had to use the Relational Syntax Analyzer (RSA) and the BEGIN
THREAD/END THREAD commands in an SFS 2200 program in order for the program to
execute in an alternate application group. In SB4, SFS 2200 directly supports alternate
application groups and their system-defined application group library search chains.
RSA and the BEGIN THREAD/END THREAD commands are no longer necessary.

Dynamically Linking a UCS SFS 2200 Program

You can use dynamic linking in all UCS languages.. When you execute a UCS program
that accesses an SFS 2200 database, you can use dynamic linking. The following
requirements exist:
• Before execution, you must specify use of the appropriate application group
library search chain by using the @USE LINK$PF statement.
@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*PROGFILE.OM/COMP

• If either of the following are true, you must before execution specify an @USE
name that identifies the SFS 2200 file (by its external name) to the executing
program:
− The qualifier on the file does not match the qualifier that you are running
under.
− The external file name specified by the program is different from the OS 2200
Exec file name.

The following statements show an example of compilation and execution using

dynamic linking:

(1) @UCOB QUAL*UCSTST.LOADSFSDB,QUAL*UCSTST.LOADSFSDB/COMP,,,NO-OPTIONS

(2) @USE LINK$PF,SYS$LIB$*APP$7.

(3) @USE SFSSPORTS.,LEISURE*SPORTS.
(4) @XQT QUAL*UCSTST.LOADSFSDB/COMP

3–164 7831 4077–009

 Application Programming in a Batch or Demand Environment

Explanation
1. This statement compiles the program.
2. This statement allows use of the correct application group library search chains.
3. In this example, the file name specified by the program is different from the
OS 2200 Exec file name. The OS 2200 Exec file name is LEISURE*SPORTS.
However, in this case the executing COBOL program uses the file name
SFSSPORTS, specified in the following statement:
SELECT SPORTS ASSIGN TO A-SHARED-FILE SFSSPORTS

Therefore, the @USE statement is necessary.

4. This statement executes the compiled program.

Statically Linking a UCS SFS 2200 Program

You can statically link a UCS program that accesses an SFS 2200 database. The
following steps are involved:
1. Specify use of the application group library search chain using an @USE LINK$PF
statement.
2. Call the LINK Processor.
3. Specify static linking commands, including a command that identifies the
program’s compiler-produced object module.

The output of the static link can be a standard object module, a bound object module,
or a ZOOM.

The following example shows how to statically link a UCS program that accesses an
SFS 2200 database, producing a ZOOM:

(1) @USE LINK$PF,SYS$LIB$*APP$7.

(2) @LINK ,QUAL*UCSTST.DISPLAYSPT
(3) INCLUDE QUAL*UCSTST.DISPLAYSPT/COMP
(4) RESOLVE ALL REFERENCES USING LIBCODENAME
(5) PROCESS FOR EXTENDED ZOOM
(6) DELETE ALL DEFINITIONS EXCEPT START$
(7) @EOF

7831 4077–009 3–165

Application Programming in a Batch or Demand Environment

Explanation
1. This statement ensures that the program is statically linked using the SFS 2200
software in the desired application group. (It ensures that the library search chain
for the correct application group is used.) In this example, this program is to
execute in application group 7.
2. This statement calls the Linking System LINK Processor. The ZOOM to be
produced is named QUAL*UCSTST.DISPLAYSPT.
3. This command identifies the compiler-generated object module containing the
UCS program that accesses the SFS 2200 database.
4. This command resolves external references, including those to the UCS Runtime
System library.
5. This command merges banks and produces a ZOOM.
6. This command deletes all definitions except the program’s starting address,
START$. This decreases the size of the ZOOM.
7. This statement ends static linking.

3–166 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.3.6. Executing UCS Programs That Access SFS 2200 Databases

Before executing a UCS program that accesses an SFS 2200 database, you must do
the following:
• In some cases, you must attach an @USE name to the SFS 2200 file that identifies
the file (by its external name) to the executing program.
• In some cases, you must also assign the SFS 2200 file to the run or ensure that the
file is not assigned to the run.
• For UCS C programs, you must assign the file containing the define-file-block
omnibus element and give it an @USE name of DFP$.
Attaching an @USE Name to the SFS 2200 File
If either of the following are true, you must before execution specify an @USE name
that identifies the SFS 2200 file (by its external name) to the executing program:
• The qualifier on the file does not match the qualifier that you are running under.
• The external file name specified by the program is different from the OS 2200
Exec file name.

For example, assume a program contains the following COBOL SELECT statement:
SELECT SPORTS ASSIGN TO A-SHARED-FILE SFSSPORTS

Assuming the file’s OS 2200 Exec file name is LEISURE*SPORTS, the following @USE
statement would be used in this case:
@USE SFSSPORTS,LEISURE*SPORTS.

Assigning or Not Assigning the File

In some cases, you must also assign the SFS 2200 file to the run or ensure that the file
is not assigned to the run. This requirement depends on the setting of the file
storage-area’s DOMAIN attribute:
• DOMAIN has a value of UDS
If the storage-area for the file has a DOMAIN attribute with the value UDS, the file
must not be assigned to the run.

• DOMAIN has a value of USER

If the storage-area for the file has a DOMAIN attribute with the value USER, the file
must be assigned to the run.
Assuming the file’s name is LEISURE*SPORTS, the following @ASG statement would
be used in this case:
@ASG,A LEISURE*SPORTS.

• DOMAIN has a value of USER-UDS

If the storage-area for the file has a DOMAIN attribute with the value USER-UDS,
either method can be used. In other words, the file can be assigned to the run, but
need not be.

7831 4077–009 3–167

Application Programming in a Batch or Demand Environment

Assigning the Define-File-Block Omnibus Element (UCS C)

Before execution of a UCS C program, you must do the following:
1. Assign the program file containing the define-file-block omnibus element to the
run.
(For information on this file, refer to "Defining SFS 2200 Files and Storage Areas" earlier
in this section.)

2. Give the file an @USE name of DFP$.

This process is necessary so that the UCS Runtime System can know where to locate
the define-file-block omnibus element when an SFS 2200 file is opened.
The following runstream shows an example.
@ASG,A UDS$$SVN*DFP$.
@USE DFP$,UDS$$SVN*DFP$.

Complete Example
The following execution runstream would be used for a UCS COBOL program with the
following characteristics:
• Object module name of QUAL*UCSTST.LOADSFSDB/COMP
• OS 2200 Exec file name of LEISURE*SPORTS
• A-SHARED-FILE name of SFSSPORTS
• Storage-area DOMAIN attribute of USER
@ASG,A LEISURE*SPORTS.
@USE SFSSPORTS,LEISURE*SPORTS.
@XQT QUAL*UCSTST.LOADSFSDB/COMP

3–168 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.3.7. Example of a UCS Program That Accesses an SFS 2200

Database
The following subsections show an example of compiling, linking, and executing the
following:
• An SFS 2200 database load program
The load program uses dynamic linking.
(Due to the length of the load program, its listing is not provided.)

• An SFS 2200 database retrieval program

The retrieval program is statically linked to produce a zero overhead object module.

The following example summarizes the retrieval program used in the example. The
program
1. Accepts an employee number as input
2. Accesses information about that individual’s sports activities from the SFS 2200
database
3. Displays the data

IDENTIFICATION DIVISION.
PROGRAM-ID. DSPSPORTS.
.
.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file-name
ASSIGN TO A-SHARED-FILE ....
.
.
FILE SECTION.
FD file-name
file definition ....
WORKING-STORAGE SECTION.
01 EMPLOYEE-NUMBER ....
.
.
PROCEDURE DIVISION.
ACCEPT EMPLOYEE-NUMBER
OPEN FILE
READ FILE
DISPLAYs .....
CLOSE FILE
STOP RUN.

7831 4077–009 3–169

Application Programming in a Batch or Demand Environment

Source Listing of the Program (DSPSPORTS)

Example 3–39 shows the complete source listing of the database retrieval program,
DSPSPORTS. This program
1. Accepts an employee number as input
2. Accesses information about that individual’s participation in company sports from
the SFS 2200 database
3. Displays the data

In this example, this program resides in element QUAL*UCSTST.DISPLAYSPT.

Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DSPSPORTS.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL SFS PROGRAM - DISPLAYSPT *
* *
* reads the input data *
* opens the SPORTS SFS database file *
* retrieves the requested information from the database *
* displays this on the printer *
* closes the SPORTS SFS database file *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SPORTS
ASSIGN TO A-SHARED-FILE SFSSPORTS
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS SPT-EMP-NUMBER
ALTERNATE RECORD KEY IS SPT-IND-LAST-NAME WITH DUPLICATES.
DATA DIVISION.
FILE SECTION.
FD SPORTS.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).

Example 3–39. Source Listing of the Program (QUAL*UCSTST.DISPLAYSPT)

3–170 7831 4077–009

 Application Programming in a Batch or Demand Environment

05 SPT-IND-LAST-NAME PIC X(20).

05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 INVALID-EMPLOYEE-NUMBER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
*
PROCEDURE DIVISION.
************************************************************
* PROGRAM FLOW
************************************************************

MAIN-PROGRAM-FLOW.
DISPLAY 'ENTER EMPLOYEE NUMBER' UPON PRINTER.
ACCEPT EMPLOYEE-NUMBER.
PERFORM OPEN-SFS-FILE-SPORTS.
PERFORM RETRIEVE-SPORTS-RECORD.
PERFORM DISPLAY-INDIVIDUAL-DATA.
IF SPT-ACTIVE-COUNT = 0
DISPLAY ' THIS EMPLOYEE DOES NOT PARTICIPATE IN ANY',
' COMPANY-SPONSORED SPORTS.' UPON PRINTER
ELSE DISPLAY ' COMPANY SPORTS PARTICIPATION: '
UPON PRINTER
PERFORM DISPLAY-SPORTS-DATA
VARYING I FROM 1 BY 1 UNTIL I > SPT-ACTIVE-COUNT
END-IF.
PERFORM CLOSE-SFS-FILE-SPORTS.
PERFORM TERMINATION-PARA.
************************************************************
* OPEN SFS DATABASE FILE - SPORTS
************************************************************
OPEN-SFS-FILE-SPORTS.
OPEN INPUT SPORTS.

Example 3–39. Source Listing of the Program (QUAL*UCSTST.DISPLAYSPT)

7831 4077–009 3–171

Application Programming in a Batch or Demand Environment

************************************************************
* RETRIEVE THE INDIVIDUAL'S SPORTS RECORD FROM THE
* DATABASE
************************************************************
RETRIEVE-SPORTS-RECORD.

MOVE EMPLOYEE-NUMBER TO SPT-EMP-NUMBER.

READ SPORTS RECORD
KEY IS SPT-EMP-NUMBER
INVALID KEY PERFORM BAD-KEY.
************************************************************
* DISPLAY THE INDIVIDUAL'S DATA
************************************************************
DISPLAY-INDIVIDUAL-DATA.
DISPLAY 'SPORTS DATA ' UPON PRINTER.
DISPLAY ' EMPLOYEE NUMBER IS ' SPT-EMP-NUMBER UPON PRINTER.
DISPLAY ' LAST NAME: ' SPT-IND-LAST-NAME UPON PRINTER.
DISPLAY ' FIRST NAME: ' SPT-IND-FIRST-NAME UPON PRINTER.

************************************************************
* DISPLAY THE INDIVIDUAL'S SPORTS DATA
************************************************************
DISPLAY-SPORTS-DATA.
DISPLAY ' ', SPT-NAME (I), ' ', SPT-LEAGUE-TYPE (I)
UPON PRINTER.
************************************************************
* CLOSE SFS DATABASE FILE - SPORTS
************************************************************
CLOSE-SFS-FILE-SPORTS.

CLOSE SPORTS.

************************************************************
* TERMINATE PROGRAM.
************************************************************
TERMINATION-PARA.
DISPLAY 'PROGRAM HAS COMPLETED' UPON PRINTER.

STOP RUN.

*
************************************************************
* DISPLAY OF BAD INPUT KEY
************************************************************
BAD-KEY.
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER.
CLOSE SPORTS.
STOP RUN.

Example 3–39. Source Listing of the Program (QUAL*UCSTST.DISPLAYSPT)

3–172 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Runstream

Example 3–40 shows the source listing of a runstream used to compile, link, and
execute the example program DSPSPORTS. Noteworthy lines are bolded.

@ . *** ******** START OF THE EXAMPLE SECTION *************************

@ . ***
@ . ***
@ . *** COMPILE OF THE INITIAL LOAD PROGRAM AND THE SFS RETRIEVAL PROGRAM
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADSFSDB,QUAL*UCSTST.LOADSFSDB/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.DISPLAYSPT,QUAL*UCSTST.DISPLAYSPT/COMP,,, ;
NO-OPTIONS
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@USE SFSSPORTS,LEISURE*SPORTS.
@XQT QUAL*UCSTST.LOADSFSDB/COMP
@ . ***
@ . ***
@ . *** STATIC LINK OF THE RETRIEVAL PROGRAM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DISPLAYSPT
INCLUDE QUAL*UCSTST.DISPLAYSPT/COMP

Example 3–40. Runstream to Compile, Link, and Execute—COBOL SFS Program

7831 4077–009 3–173

Application Programming in a Batch or Demand Environment

RESOLVE ALL REFERENCES USING LIBCODENAME

PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THE RETRIEVAL PROGRAM
@ . ***
@USE SFSSPORTS,LEISURE*SPORTS.
@XQT QUAL*UCSTST.DISPLAYSPT
10211
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3-40. Runstream to Compile, Link, and Execute—COBOL SFS Program

3–174 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Source Runstream

Example 3–41 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . *** ******** START OF THE EXAMPLE SECTION *************************

@ . ***
@ . ***
@ . *** COMPILE OF THE INITIAL LOAD PROGRAM AND THE SFS RETRIEVAL PROGRAM
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADSFSDB,QUAL*UCSTST.LOADSFSDB/COMP,,,NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 14:49:58
SIZES: CODE(EM6): 686 DATA: 1025
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.DISPLAYSPT,QUAL*UCSTST.DISPLAYSPT/COMP,,, ;
NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 14:50:08
SIZES: CODE(EM6): 276 DATA: 586
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@USE SFSSPORTS,LEISURE*SPORTS.
I:002333 USE complete.
@XQT QUAL*UCSTST.LOADSFSDB/COMP

SFS FILE SPORTS OPEN

SPORTS RECORDS ARE LOADED

Example 3–41. Execution of Source Runstream—COBOL SFS Program

7831 4077–009 3–175

Application Programming in a Batch or Demand Environment

SFS FILE SPORTS CLOSED

INITIAL LOAD COMPLETE

*******************

DATABASE VALIDATION

*******************

EMPNO FIRST NAME LAST NAME SPORTS PARTICIPATION

----- ------------ -------------------- ---------------------------------

10211 STEVEN FIELDING GOLF VOLLEYBALL

10215 JENNIFER HELLER

10223 KAREN RALSTON GOLF SOFTBALL VOLLEYBALL

24101 MARY ANDERSON TENNIS

26503 RALPH MILLER TENNIS GOLF

26504 JOHN BLAKE TENNIS BOWLING SOFTBALL

26510 GEORGE CARR VOLLEYBALL TENNIS SOFTBALL

32009 JAKE KAISER

****

**** 0008 INDIVIDUAL RECORDS ARE LOADED

DATABASE LOAD HAS BEEN VALIDATED

@ . ***
@ . ***
@ . *** STATIC LINK OF THE RETRIEVAL PROGRAM
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DISPLAYSPT

Example 3–41. Execution of Source Runstream—COBOL SFS Program

3–176 7831 4077–009

 Application Programming in a Batch or Demand Environment

LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1450:27

END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THE RETRIEVAL PROGRAM
@ . ***
@USE SFSSPORTS,LEISURE*SPORTS.
I:002333 USE complete.
@XQT QUAL*UCSTST.DISPLAYSPT
ENTER EMPLOYEE NUMBER

SPORTS DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

COMPANY SPORTS PARTICIPATION:

GOLF ADVANCED

VOLLEYBALL INTERMEDIATE

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . ***EXAMPLE IS COMPLETE

Example 3–41. Execution of Source Runstream—COBOL SFS Program

7831 4077–009 3–177

Application Programming in a Batch or Demand Environment

3.2.4. Accessing Multiple UDS Database Models

You can access more than one UDS database model from the same program. UCS
supports all combinations of multiple UDS data model usage (for example, RDMS 2200
and SFS 2200 together, RDMS 2200 and DMS 2200 together, all three together, and so
forth).

This type of program requires use of BEGIN THREAD and END THREAD commands, no
matter which of the data models are used. The other UDS commands (for example,
the DMS 2200 IMPART and DEPART commands and the SFS 2200 OPEN and CLOSE
commands) must follow the BEGIN THREAD command and precede the END THREAD
command. Specifying the BEGIN THREAD and END THREAD commands is known as
using explicit thread control. Programs that access multiple database models require
explicit thread control.

The following subsections show an example of a program that uses the three
database models discussed earlier. This is possible because the databases all contain
data about a group of individuals, each one of whom is uniquely identified in each
database by the same employee number.

3–178 7831 4077–009

 Application Programming in a Batch or Demand Environment

This example is a COBOL program that is a combination of the DMS 2200, RDMS 2200,
and SFS 2200 programs shown previously (see 3.2.1, 3.2.2, and 3.2.3). The program is
1. Compiled using UCS COBOL
2. Executed first using dynamic linking
3. Executed again using static linking (a ZOOM is produced)

The following listing summarizes this program.

IDENTIFICATION DIVISION.
PROGRAM-ID. DISPLAYALL.
.
.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file-name
ASSIGN TO A-SHARED-FILE ....
.
.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE .....
.
.
FILE SECTION.
FD file-name
file definition ....
WORKING-STORAGE SECTION.
table definitions ...
.
.
01 EMPLOYEE-NUMBER ....
.
PROCEDURE DIVISION.
ACCEPT EMPLOYEE-NUMBER
BEGIN THREAD
OPEN FILE
IMPART
OPEN DMS areas .... RETRIEVAL
FETCHs ....
DISPLAYs .....
READ FILE
DISPLAYs .....
DEFINE CURSOR
OPEN CURSOR
FETCHs ....
DISPLAYs .....
DEPART
CLOSE FILE
END THREAD
STOP RUN.

7831 4077–009 3–179

Application Programming in a Batch or Demand Environment

3.2.4.1. Source Listing of the Program (DISPLAYALL)

Example 3-42 shows the complete source listing of the program, DISPLAYALL. This
program accepts an employee number as input and displays the information contained
in all three databases about this individual. In this example, this program resides in
element QUAL*UCSTST.DISPLAYALL. Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DISPLAYALL INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL DMS/SFS/RDMS PROGRAM - DISPLAYALL *
* *
* reads the input data *
* begins thread with UDS *
* opens the SPORTS SFS database file *
* imparts to the PERSONNEL database *
* retrieves the requested information from the DMS database *
* retrieves the requested information from the SFS database *
* retrieves the requested information from the RDMS database *
* displays the data on the printer *
* departs from the PERSONNEL database *
* closes the SPORTS SFS database file *
* ends thread with UDS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SPORTS
ASSIGN TO A-SHARED-FILE SFSSPORTS
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS SPT-EMP-NUMBER
ALTERNATE RECORD KEY IS SPT-IND-LAST-NAME WITH DUPLICATES.
DATA DIVISION.

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

3–180 7831 4077–009

 Application Programming in a Batch or Demand Environment

SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUB IN FILE SCHFILE
OF SCHEMA PERSONNEL
COPYING RECORDS INTO WORKING
COPYING DATA-NAMES INTO WORKING
RUN-UNIT-ID DSPIND
DMCA IS WORKING
ERROR DMS-GENERAL-ERROR-PARA.
FILE SECTION.
FD SPORTS.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 INVALID-EMPLOYEE-NUMBER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER.
05 EMP-PAGE PIC 9(3).
05 EMP-RECORD PIC 9(2).
************************************************************
* RDMS WORK AREA SIZE
************************************************************
01 WORK-AREA-SIZE PIC 1(36) USAGE BINARY-1 VALUE 2000.
************************************************************
* UDS THREAD STATUS FLAG
************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 CHILD-LAST-NAME PIC X(20).
01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* ESQL STATEMENT STATUS
************************************************************

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

7831 4077–009 3–181

Application Programming in a Batch or Demand Environment

01 SQLSTATE PIC X(5).

************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.

05 ERROR-STATUS PIC 9(4).

05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
************************************************************
* GETERROR BUFFERS
************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************
01 ERR-INDEX PIC 9.
************************************************************
* ALLERROR INDICATOR
************************************************************
01 XX PIC 9 VALUE 0.
88 ALLERR VALUE 1.
************************************************************
* COUNTER FOR CHILDREN
************************************************************
01 CHILD-COUNT PIC 9(1) VALUE 0.
************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
*
PROCEDURE DIVISION.
************************************************************
* PROGRAM FLOW
************************************************************
MAIN-PROGRAM-FLOW.

DISPLAY 'ENTER EMPLOYEE NUMBER' UPON PRINTER.

ACCEPT EMPLOYEE-NUMBER.
CALL 'RSA$INIT' USING WORK-AREA-SIZE.
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

3–182 7831 4077–009

 Application Programming in a Batch or Demand Environment

IF EMP-PAGE > 99 AND EMP-RECORD > 0

PERFORM CONNECT-TO-DATABASES
PERFORM DMS-RETRIEVE-INDIVIDUAL-DATA
PERFORM DMS-DISPLAY-INDIVIDUAL-DATA
PERFORM SFS-RETRIEVE-SPORTS-DATA
IF SPT-ACTIVE-COUNT = 0
DISPLAY ' THIS EMPLOYEE DOES NOT PARTICIPATE IN ANY',
' COMPANY-SPONSORED SPORTS.' UPON PRINTER
ELSE DISPLAY ' COMPANY SPORTS PARTICIPATION: '
UPON PRINTER
PERFORM SFS-DISPLAY-SPORTS-DATA
VARYING I FROM 1 BY 1 UNTIL I > SPT-ACTIVE-COUNT
END-IF
PERFORM RDMS-SET-DEFAULT-QUALIFIER
PERFORM RDMS-SETUP-CHILDDATA-CURSOR
PERFORM RDMS-FETCH-DISPLAY-CHILD-DATA
WITH TEST AFTER UNTIL SQLSTATE = "02000"
PERFORM DMS-DEPART-PARA
PERFORM SFS-FILE-CLOSE-PARA
PERFORM UDS-END-THREAD-PARA
ELSE DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
END-IF.
PERFORM TERMINATION-PARA.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEMS
************************************************************
CONNECT-TO-DATABASES.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
MOVE 1 TO THREAD-FLAG.
OPEN INPUT SPORTS.
IMPART.
OPEN ALL USAGE-MODE IS RETRIEVAL.
************************************************************
* DMS - RETRIEVE THE INDIVIDUAL INFORMATION
* DISPLAY THE INDIVIDUAL INFORMATION
************************************************************
DMS-RETRIEVE-INDIVIDUAL-DATA.
MOVE 'EMPNOAREA' TO EMPNO-AREA-NAME.
MOVE EMP-PAGE TO PAGE-NUM OF EMPNO-AREA-KEY.
MOVE EMP-RECORD TO RECORD-NUM OF EMPNO-AREA-KEY.
FETCH EMPNUMBER RECORD.
FETCH NEXT RECORD WITHIN EMPNO-IND SET.
FETCH OWNER RECORD WITHIN DEPT-IND SET.
FETCH OWNER RECORD WITHIN JOB-IND SET.
DMS-DISPLAY-INDIVIDUAL-DATA.
DISPLAY 'INDIVIDUAL DATA ' UPON PRINTER.

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

7831 4077–009 3–183

Application Programming in a Batch or Demand Environment

DISPLAY ' EMPLOYEE NUMBER IS ' EMP-NUMBER UPON PRINTER.

DISPLAY ' LAST NAME: ' IND-LAST-NAME UPON PRINTER.
DISPLAY ' FIRST NAME: ' IND-FIRST-NAME UPON PRINTER.
DISPLAY ' THIS INDIVIDUAL WORKS IN THE ' DEPT-NAME
' DEPARTMENT' UPON PRINTER.
DISPLAY ' DEPARTMENT NUMBER: ' DEPT-NO UPON PRINTER.
DISPLAY ' THIS DEPARTMENT ' DEPT-DESCRIPTION UPON PRINTER.
DISPLAY ' THIS INDIVIDUAL IS A ' JOB-TITLE UPON PRINTER.
DISPLAY ' WHO ' JOB-DESCRIPTION UPON PRINTER.
DISPLAY ' AND IS PAID $' JOB-SALARY ' A YEAR.'
UPON PRINTER.
************************************************************
* SFS - RETRIEVE THE SPORTS INFORMATION
* DISPLAY THE SPORTS INFORMATION
************************************************************
SFS-RETRIEVE-SPORTS-DATA.
MOVE EMP-NUMBER TO SPT-EMP-NUMBER.
READ SPORTS RECORD
KEY IS SPT-EMP-NUMBER
INVALID KEY PERFORM BAD-KEY.
SFS-DISPLAY-SPORTS-DATA.
DISPLAY ' ', SPT-NAME (I), ' ', SPT-LEAGUE-TYPE (I)
UPON PRINTER.
************************************************************
* RDMS - SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
* DEFINE THE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN THE CURSOR
* RETRIEVE DATA FROM THE CURSOR
************************************************************
RDMS-SET-DEFAULT-QUALIFIER.
EXEC SQL
USE DEFAULT QUALIFIER FAMILY
END-EXEC.
RDMS-SETUP-CHILDDATA-CURSOR.
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMP-NUMBER
END-EXEC.
EXEC SQL
OPEN CHILDDATA
END-EXEC.
RDMS-FETCH-DISPLAY-CHILD-DATA.
EXEC SQL
FETCH NEXT CHILDDATA INTO
:CHILD-LAST-NAME, :CHILD-FIRST-NAME

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

3–184 7831 4077–009

 Application Programming in a Batch or Demand Environment

END-EXEC.
IF SQLSTATE NOT = "02000"
ADD 1 TO CHILD-COUNT
IF CHILD-COUNT = 1
DISPLAY ' EMPLOYEE''S CHILDREN: ' UPON PRINTER
END-IF
DISPLAY ' CHILD NAME: ' CHILD-FIRST-NAME, ' ',
CHILD-LAST-NAME UPON PRINTER
ELSE CONTINUE
END-IF.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEMS
************************************************************
DMS-DEPART-PARA.
DEPART.
SFS-FILE-CLOSE-PARA.
CLOSE SPORTS.
UDS-END-THREAD-PARA.
END THREAD.
MOVE 0 TO THREAD-FLAG.
************************************************************
* TERMINATE PROGRAM
************************************************************
TERMINATION-PARA.
DISPLAY 'PROGRAM HAS COMPLETED' UPON PRINTER.
STOP RUN.
*
*
************************************************************
* DMS - CHECK FOR A '0013' ERROR,
* IF THIS ERROR OCCURRED THE
* INVALID-EMPLOYEE-NUMBER MESSAGE IS PRINTED
* ELSE THE ERROR MESSAGE IS RETURNED TO THE PRINTER
* FOR DEBUGGING.
************************************************************
DMS-GENERAL-ERROR-PARA.
IF ERROR-NUM = '0013'
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER
ELSE DISPLAY 'DMS-GENERAL-ERROR-PARA.' UPON PRINTER
DISPLAY 'AREA = ' ERROR-AREA UPON PRINTER
DISPLAY 'RECORD = ' ERROR-RECORD UPON PRINTER
DISPLAY 'SET = ' ERROR-SET UPON PRINTER
DISPLAY 'ROLLBACK = ' RB-ERROR-CODE UPON PRINTER
DISPLAY 'FUNCTION = ' ERROR-FUNCTION UPON PRINTER
DISPLAY 'ERR NUM = ' ERROR-NUM UPON PRINTER
END-IF.

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

7831 4077–009 3–185

Application Programming in a Batch or Demand Environment

IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.

PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM TERMINATION-PARA.
*
************************************************************
* SFS - DISPLAY OF BAD INPUT KEY
************************************************************
BAD-KEY.
DISPLAY INVALID-EMPLOYEE-NUMBER, EMPLOYEE-NUMBER
UPON PRINTER.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM TERMINATION-PARA.
*
************************************************************
* RDMS - RETURN AN ERROR MESSAGE TO THE PRINTER FILE IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY '***SQLSTATE = ' SQLSTATE UPON PRINTER.
DISPLAY '***RDMCA AUX-INFO = ' AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = ' ERROR-STATUS OF RDMCA
UPON PRINTER.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT
EXEC SQL
GETERROR INTO :ERR(1),:ERR(2),:ERR(3),:ERR(4),:ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM TERMINATION-PARA.

Example 3–42. Source Listing of the Program (QUAL*UCSTST.DISPLAYALL)

3–186 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.2.4.2. Source Listing of Runstream

Example 3–43 shows the source listing of a runstream used to compile, link, and
execute the example program DISPLAYALL. Noteworthy lines are bolded.
@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE MULTIPLE DATA MODEL (DMS, SFS, ESQL) PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
@ . ***
@UCOB QUAL*UCSTST.DISPLAYALL,QUAL*UCSTST.DISPLAYALL/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** EXECUTION OF THIS PROGRAM USING DYNAMIC LINKING
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@USE SFSSPORTS,LEISURE*SPORTS.
@XQT QUAL*UCSTST.DISPLAYALL/COMP
10211
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DISPLAYALL
INCLUDE QUAL*UCSTST.DISPLAYALL/COMP
INCLUDE UDS$$SVN*SCHFILE.S$WORK/PERSONSUB
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXECUTION OF THIS ZOOM
@ . ***
@USE SFSSPORTS,LEISURE*SPORTS.
@XQT QUAL*UCSTST.DISPLAYALL
10211
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–43. Runstream to Compile, Link, and Execute—COBOL DMS/ESQL/SFS

Program

7831 4077–009 3–187

Application Programming in a Batch or Demand Environment

3.2.4.3. Execution of the Source Runstream

Example 3–44 shows the execution of the source runstream used to compile, link, and
execute this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE MULTIPLE DATA MODEL (DMS, SFS, ESQL) PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
I:002333 ASG complete.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
I:002333 USE complete.
@ . ***
@UCOB QUAL*UCSTST.DISPLAYALL,QUAL*UCSTST.DISPLAYALL/COMP,,, ;
NO-OPTIONS,COMPAT,APPLICATION/APPSVN
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940128 15:30:53
SIZES: CODE(EM6): 1043 DATA: 2218
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING (LEVEL)
6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** EXECUTION OF THIS PROGRAM USING DYNAMIC LINKING
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@USE SFSSPORTS,LEISURE*SPORTS.
I:002333 USE complete.
@XQT QUAL*UCSTST.DISPLAYALL/COMP

ENTER EMPLOYEE NUMBER

INDIVIDUAL DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

THIS INDIVIDUAL WORKS IN THE APPLICATION DEVELOPMENT DEPARTMENT

Example 3–44. Execution of Source Runstream—COBOL DMS/ESQL/SFS Program

3–188 7831 4077–009

 Application Programming in a Batch or Demand Environment

DEPARTMENT NUMBER: 4124

THIS DEPARTMENT DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION CODE

THIS INDIVIDUAL IS A PROGRAMMER

WHO DESIGNS, WRITES, AND TESTS CODE

AND IS PAID $40000 A YEAR.

COMPANY SPORTS PARTICIPATION:

GOLF ADVANCED

VOLLEYBALL INTERMEDIATE

EMPLOYEE'S CHILDREN:

CHILD NAME: STEVEN JR FIELDING

CHILD NAME: DANIEL FIELDING

CHILD NAME: JANE FIELDING

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DISPLAYALL
LINK 5R2 (940112 1230:40) 1994 Jan 28 Fri 1531:16
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXECUTION OF THIS ZOOM
@ . ***
@USE SFSSPORTS,LEISURE*SPORTS.
I:002333 USE complete.
@XQT QUAL*UCSTST.DISPLAYALL

ENTER EMPLOYEE NUMBER

Example 3–44. Execution of Source Runstream—COBOL DMS/ESQL/SFS Program

7831 4077–009 3–189

Application Programming in a Batch or Demand Environment

INDIVIDUAL DATA

EMPLOYEE NUMBER IS 10211

LAST NAME: FIELDING

FIRST NAME: STEVEN

THIS INDIVIDUAL WORKS IN THE APPLICATION DEVELOPMENT DEPARTMENT

DEPARTMENT NUMBER: 4124

THIS DEPARTMENT DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION CODE

THIS INDIVIDUAL IS A PROGRAMMER

WHO DESIGNS, WRITES, AND TESTS CODE

AND IS PAID $40000 A YEAR.

COMPANY SPORTS PARTICIPATION:

GOLF ADVANCED

VOLLEYBALL INTERMEDIATE

EMPLOYEE'S CHILDREN:

CHILD NAME: STEVEN JR FIELDING

CHILD NAME: DANIEL FIELDING

CHILD NAME: JANE FIELDING

PROGRAM HAS COMPLETED

@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–44. Execution of Source Runstream—COBOL DMS/ESQL/SFS Program

3–190 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3. Using DPS 2200 with UCS

The Display Processing System (DPS 2200) provides an easy method for defining
forms (screens) and incorporating them into application programs. DPS 2200
separates the development and use of forms from the other tasks in an application
program. This promotes the following:
• Hardware device independence
• Faster program development with fewer errors
• Automatic handling of input errors
• Display security

DPS 2200 provides the following major services:

• Creates and edits forms
• Provides DPS 2200 run-time routines that operate in both the demand and
transaction processing environments
• Provides form definitions that interface with applications and DPS 2200 run-time
routines

DPS 2200 provides three methods for creating and editing forms (screens):
• The FORMGEN processor (FORMGN)
The FORMGEN processor provides an interactive method for defining forms. It
includes learning aids and extensive online help screens.

• The Form Language Definition Processor (FLDP)

The Form Language Definition Processor is a batch mode equivalent to FORMGEN. To
define forms using the Form Language Definition Processor, you specify a series of
commands.

• The D$DEF routines

The D$DEF routines provide the ability to define and edit forms within an application
program.

7831 4077–009 3–191

Application Programming in a Batch or Demand Environment

UCS COBOL, UCS FORTRAN, and UCS C support DPS 2200 in all programming
environments (batch, demand, TIP, and HVTIP).

DPS 2200 provides the same programming interface for both UCS and non-UCS
programs. The same copy of DPS 2200 software can simultaneously be used by UCS
and non-UCS programs.

Furthermore, UCS supports all methods for defining forms. The same DPS 2200 forms
from the same forms file can simultaneously be used by both UCS and non-UCS
programs.

3–192 7831 4077–009

 Application Programming in a Batch or Demand Environment

For complete information on DPS 2200, refer to the following documents:

• DPS 2200 Run-Time Programming Reference Manual
• DPS 2200 Form Design Programming Guide
• DPS 2200 Administration Guide

3.3.1. Example of a DPS 2200 Form Definition

This subsection shows an example of a DPS 2200 form built using the FORMGEN
processor. The form contains a display of information about an individual. The
information to be displayed on the form includes the following:
• The input data to the program (employee number)
• The individual's name
• Information about the individual’s job, which is retrieved from a DMS 2200
database
• Information about the individual’s children, which is retrieved from an RDMS 2200
database
• Information about the individual's participation in company sports, which is
retrieved from an SFS 2200 database

This form will be used by two different programs:

The First Program

1. Reads an individual’s employee number
2. Retrieves the form to be displayed from the form file
3. Moves the employee number to the form
4. Displays the form on the terminal screen
No database access occurs in this program.

The Second Program

1. Reads an individual’s employee number
2. Retrieves the form to be displayed from the form file
3. Moves the employee number to the form
4. Accesses information about the individual from the DMS 2200, RDMS 2200,
and SFS 2200 databases
5. Moves this information to the form
6. Displays the form on the terminal screen
This program is a combination of the multiple-database-model program shown in
3.2.4 and the first DPS 2200 program in this subsection.

Example 3–45 shows a listing of the form used in the examples. This listing was
produced by selecting the FORMGEN "print form" option.

7831 4077–009 3–193

Application Programming in a Batch or Demand Environment

GENERAL FORM INFORMATION

========================
FORM LIBRARY NAME: FORMS
FORM NAME: DSPLYIND
FORM NUMBER: 50
TEST MODE: NO
INITIAL CONVERSATION: NO
FUNCTION KEYS ALLOWED: NONE
FORM SECURITY LEVEL: 1
FORM SECURITY TYPE: SOFT
PREFIXES GENERATED: YES
GENERATED BY: XXX
GENERATED AT: 29 JUL 90 17:26:53
LAST UPDATED AT: ** NO UPDATES YET **
CHECK NUMBER: 149411
CHECK NUMBER VALIDATE: YES
DELIMITER : ,
DECIMAL POINT : .
START IMAGE CHARACTER: [
STOP IMAGE CHARACTER: ]
FIELD CHARACTER: _
2ND FIELD CHARACTER: NONE
CONTROL CHARACTERS ALLOWED: NONE
SOE CHARACTER: NONE
MARKING CHARACTER: NONE
FINAL COORDINATES: 24.1
FORM ENDS AT LINE: 23
DISPLAY ATTRIBUTES FOR TEXT
===========================
INTENSITY: 'N' - HIGHLIGHT: 'N'
BACKGROUND: 'E' - FOREGROUND: 'W'
EMPHASIS: 'N' - FONT: 'N'

PRINTOUT OF FORM AS DEFINED WITH FIELD CHARACTERS

=================================================
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
--------------------------------------------------------------------------------
LINE 1: ******** INDIVIDUAL DATA ******** :
2: :
3: EMPLOYEE NUMBER: _____ NAME: ____________ ____________________ :
4: :
5: :

Example 3–45. Listing of Example FORMGEN Form

3–194 7831 4077–009

 Application Programming in a Batch or Demand Environment

6: *** DEPARTMENT INFORMATION *** :

7: NAME: ________________________ NUMBER: ____ :
8: FUNCTION ______________________________________________ :
9: :
10: *** JOB INFORMATION *** :
11: TITLE: ____________________ EARLY SALARY: $ _____ :
12: FUNCTION: ______________________________________________ :
13: :
14: :
15: _____________________________________________________________ :
16: __________ _____________ :
17: __________ _____________ :
18: __________ _____________ :
19: :
20: ___ [*** CHILDREN ***] :
21: _____ ____________________ :
22: ____________ ____________________ :
23: ____________ ____________________ :
24: :
--------------------------------------------------------------------------------

Example 3–45. Listing of Example FORMGEN Form

7831 4077–009 3–195

Application Programming in a Batch or Demand Environment

PRINTOUT OF FORM WITH CONTENTS OF WORKING-STORAGE (IV)

======================================================
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
--------------------------------------------------------------------------------
LINE 1: ******** INDIVIDUAL DATA ******** :
2: :
3: EMPLOYEE NUMBER: NAME: :
4: :
5: :
6: *** DEPARTMENT INFORMATION *** :
7: NAME: NUMBER: :
8: FUNCTION: :
9: :
10: *** JOB INFORMATION *** :
11: TITLE: YEARLY SALARY: $ :
12: FUNCTION: :
13: :
14: :
15: *** COMPANY SPORTS PARTICIPATION *** :
16: :
17: :
18: :
19: :
20: *** CHILDREN *** :
21: :
22: :
23: :
24: :
-------------------------------------------------------------------------------:

Example 3–45. Listing of Example FORMGEN Form

3–196 7831 4077–009

 Application Programming in a Batch or Demand Environment

LIST OF FIELDS SORTED BY POSITION ON FORM (Y AND X)

===================================================
FIELD- FID FIELD- SIZE SIZE SEC TEST SCREEN
NUMBER NUMBER FIELD-NAME TYPE EXTERNAL INTERNAL LEVEL MODE POSITION ATTRIBUTES
------ ------ ---------- ---- ------- -------- ----- ---- -------- ----------

1 1 EMP-NUMBER O/O-'X' 5 5 1/S NO 3.19 00=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,

EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
--------------------------------------
2 2 IND-FIRST-NAME O/O-'X' 12 12 1/S NO 3.36 OO=Y,SECT=S,SECL=1,TDEP=N,RJ=Y,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,PRO=Y,
MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,EMP=N,
FONT=N
---------------------------------------
3 3 IND-LAST-NAME O/O-'X' 20 20 1/S NO 3.49 OO=Y,SECT=S,SECL=1,TDEP=N,LJ=Y,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,PRO=Y,
MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,EMP=N,
FONT=N
----------------------------------------
4 4 DEPT-NAME O/O-'X' 24 24 1/S NO 7.20 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
----------------------------------------
5 5 DEPT-NO O/O-'X' 4 4 1/S NO 7.56 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
----------------------------------------
6 6 DEPT-DESCRIPTION O/O-'X' 56 56 1/S NO 8.20 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
----------------------------------------
7 7 JOB-TITLE O/O-'X' 20 20 1/S NO 11.20 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
----------------------------------------
8 8 JOB-SALARY O/O-'X' 5 5 1/S NO 11.65 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
---------------------------------------

Example 3–45. Listing of Example FORMGEN Form

7831 4077–009 3–197

Application Programming in a Batch or Demand Environment

9 9 JOB-DESCRIPTION O/O-'X' 50 50 1/S NO 12.20 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,

EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
---------------------------------------
10 10 SPORTS-ACTION O/O-'X' 71 71 1/S NO 15.5 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
--------------------------------------
*** VERTICAL REPEAT *** REP --- --- --- --- 16.1 REPEAT COUNTER: 3 - REPEAT TEXT: NO
SPACING: 0 - INDEX-NAME: SPORT-INDEX
--------------------------------------

11 11 SPT-NAME O/O-'X' 10 10 1/S NO 16.20 0O=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,

EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
--------------------------------------
12 12 SPT-LEAGUE-TYPE O/O-'X' 13 13 1/S NO 16.31 OO=Y,SECT=S,SECL=1,TDEP=N,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,NJ=Y,
PRO=Y,MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,
EMP=N,FONT=N
--------------------------------------
*** END VERTICAL REPEAT *** --- --- --- --- 18.80 END OF VERTICAL REPEAT AT: 16.1
--------------------------------------
13 17 CHILDREN-ON ON-'ON' 18 18 1/S NO 20.4 CON=S,SECT=S,SECL=1,TDEP=N,FI=N,HI=N,
BC=E,FC=W,EMP=N,FONT=N
--------------------------------------
*** OFF-13 *** OFF --- --- --- --- 20.21 END OF ON-IMAGE AT: 20.4
--------------------------------------
*** VERTICAL REPEAT *** REP --- --- --- --- 21.1 REPEAT COUNTER: 3 - REPEAT TEXT: NO
SPACING: 0 - INDEX-NAME: CHILD-INDEX
--------------------------------------
14 18 CHILD-FIRST-NAME O/O-'X' 12 12 1/S NO 21.20 OO=Y,SECT=S,SECL=1,TDEP=N,RJ=Y,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,PRO=Y,
MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,EMP=N,
FONT=N
--------------------------------------
15 19 CHILD-LAST-NAME O/O-'X' 20 20 1/S NO 21.33 OO=Y,SECT=S,SECL=1,TDEP=N,LJ=Y,F=N,TAB=N,
EC=Y,REPN=N,VWID=N,VPOS=Y,SECF=N,PRO=Y,
MOD=N,CON=S,FI=N,HI=N,BC=E,FC=W,EMP=N,
FONT=N
---------------------------------------
*** END VERTICAL REPEAT *** --- --- --- --- 23.80 END OF VERTICAL REPEAT AT: 21.1

---------------------------------------

Example 3–45. Listing of Example FORMGEN Form

3–198 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.2. Examples of the Working Storage Definition for a DPS

2200 Form
Example 3–46 shows an abbreviated listing of the COBOL Working Storage generated
by the FORMGEN processor for the form shown in Example 3–46.

Notice that when DPS 2200 generates a form for COBOL using SB4 or later software,
it now generates only one 01 level, instead of generating multiple 01 levels as in the
past. The following are now generated as 02 levels:
• The form header area (SCREEN-DSPLYIND-50-HEADER)
The form header area serves the following purposes:
− DPS 2200 uses it to check the validity of the calls to open, send, or read the
form.
− It contains fields that the program can test or set.

• The form field control area (SCREEN-DSPLYIND-50-FCA)

The form field control area contains information about each field on the form. This
area also contains display-control indicators that the program can optionally use to
control specific field attributes.

• The form field data area (SCREEN-DSPLYIND-50-DATA)

The form field data area contains a data item definition for each output-only field and
input/output field defined on the form.

Notice that when DPS 2200 generates working storage for COBOL using SB5R2 or
later software, if UCS COBOL source is requested, the COBOL '85 and UCS COBOL
data definitions are used. This eliminates the need for the COMPAT keyword option
on the UCS COBOL compiler call for DPS 2200.

Example 3–46 shows an abbreviated listing of the Working Storage generated by the
FORMGEN processor. Noteworthy lines are bolded.

Example 3–47 shows an abbreviated #include listing of C declarations and definitions

generated by the FORMGEN processor for the form shown in Example 3-45.

7831 4077–009 3–199

Application Programming in a Batch or Demand Environment

SCREEN-DSPLYIND-50 PROC.
/
*
* THIS PROCEDURE DEFINES THE FOLLOWING FORM:
* ******************************************
*
* NAME : DSPLYIND
* NUMBER : 50
*
* GENERATED BY : XXX
* GENERATED AT : 29 JUL 90 17:26:53
* LAST UPDATED AT : FORM NOT YET UPDATED
*
01 SCREEN-DSPLYIND-50.
*
02 SCREEN-DSPLYIND-50-HEADER.
*
05 FILLER PIC X(2) VALUE SPACES.
05 FILLER PIC 9(5) BINARY VALUE ZERO.
05 FILLER PIC X(4) VALUE SPACES.
05 S50-FILLER PIC X(8) VALUE '$DPS$SWS'.
05 S50-NUMBER PIC 9(4) VALUE 50.
05 S50-NAME PIC X(8) VALUE 'DSPLYIND'.
05 S50-CHECK-NUMBER PIC 9(10) BINARY VALUE 149411.
.
. (additional source statements)
*
02 SCREEN-DSPLYIND-50-FCA.
.
. (additional source statements)
.
*
05 S50-CHILDREN-ON-STAT PIC 9(2) BINARY VALUE 0.
05 S50-CHILDREN-ON-TYPE PIC 9(2) BINARY VALUE 4.
05 S50-CHILDREN-ON-YCO PIC 9(2) BINARY VALUE 20.
05 S50-CHILDREN-ON-XCO PIC 9(2) BINARY VALUE 4.
05 S50-CHILDREN-ON-CHAR PIC 9(5) BINARY VALUE ZERO.
05 S50-CHILDREN-ON-FID PIC 9(5) BINARY VALUE 17.
05 S50-CHILDREN-ON-VAL PIC X(1) VALUE 'V'.
05 S50-CHILDREN-ON-DYN PIC X(1) VALUE 'O'.
.
. (additional source statements)
.
*
02 SCREEN-DSPLYIND-50-DATA.
*
05 S50-EMP-NUMBER PIC X(5) VALUE SPACES.
05 FILLER PIC X(3).

Example 3–46. Example of FORMGEN COBOL Working Storage

3–200 7831 4077–009

 Application Programming in a Batch or Demand Environment

*
05 S50-IND-FIRST-NAME PIC X(12) VALUE SPACES.
*
05 S50-IND-LAST-NAME PIC X(20) VALUE SPACES.
*
05 S50-DEPT-NAME PIC X(24) VALUE SPACES.
*
05 S50-DEPT-NO PIC X(4) VALUE SPACES.
*
05 S50-DEPT-DESCRIPTION PIC X(56) VALUE SPACES.
*
05 S50-JOB-TITLE PIC X(20) VALUE SPACES.
*
05 S50-JOB-SALARY PIC X(5) VALUE SPACES.

05 FILLER PIC X(3).

05 S50-JOB-DESCRIPTION PIC X(50) VALUE SPACES.

05 FILLER PIC X(2).
*
05 S50-REPEAT-1-DATA-ST.
*
15 FILLER PIC X(10) VALUE SPACES.
15 FILLER PIC X(2).
*
15 FILLER PIC X(13) VALUE SPACES.
15 FILLER PIC X(3).
*
15 FILLER PIC X(10) VALUE SPACES.
15 FILLER PIC X(2).
*
15 FILLER PIC X(13) VALUE SPACES.
15 FILLER PIC X(3).
*
15 FILLER PIC X(10) VALUE SPACES.
15 FILLER PIC X(2).
*
15 FILLER PIC X(13) VALUE SPACES.
15 FILLER PIC X(3).
*
05 S50-SPORTS-ACTION PIC X(71) VALUE
'*** COMPANY SPORTS PARTICIPATION ***
- ' '.
05 FILLER PIC X(1).
*
05 S50-REPEAT-1-DATA-END
REDEFINES S50-REPEAT-1-DATA-ST.
*

Example 3–46. Example of FORMGEN COBOL Working Storage

7831 4077–009 3–201

Application Programming in a Batch or Demand Environment

10 S50-REPEAT-1-DATA OCCURS 3 TIMES

INDEXED BY S50-SPORT-INDEX-DATA.
*
15 S50-SPT-NAME PIC X(10).
15 FILLER PIC X(2).
15 S50-SPT-LEAGUE-TYPE
PIC X(13).
15 FILLER PIC X(3).
*
05 S50-REPEAT-2-DATA-ST.
*
15 FILLER PIC X(12) VALUE SPACES.
*
15 FILLER PIC X(20) VALUE SPACES.
*
15 FILLER PIC X(12) VALUE SPACES.
*
15 FILLER PIC X(20) VALUE SPACES.
*
15 FILLER PIC X(12) VALUE SPACES.
*
15 FILLER PIC X(20) VALUE SPACES.
*
05 S50-REPEAT-2-DATA-END
REDEFINES S50-REPEAT-2-DATA-ST.
*
10 S50-REPEAT-2-DATA OCCURS 3 TIMES
INDEXED BY S50-CHILD-INDEX-DATA.

*
15 S50-CHILD-FIRST-NAME
PIC X(12).
*
15 S50-CHILD-LAST-NAME
PIC X(20).
END

Example 3–46. Example of FORMGEN COBOL Working Storage

3–202 7831 4077–009

 Application Programming in a Batch or Demand Environment

#pragma eject
/*
THIS STRUCTURE DEFINES THE FOLLOWING FORM:
******************************************

NAME : DSPLYIND
NUMBER : 50

GENERATED BY : 2HOLLY
GENERATED AT : 21 MAY 91 21:54:34
LAST UPDATED AT : FORM NOT YET UPDATED
*/
struct tag_screen_dsplyind_50 {

struct {

unsigned char s50_unused_1[2] ;

unsigned short s50_unused_2 ;
unsigned char s50_unused_3[4] ;
unsigned char s50_filler[8] ;
unsigned char s50_number[4] ;
unsigned char s50_name[8] ;
unsigned int s50_check_number ;
.
. (additional source statements)
.
} screen_dsplyind_50_header ;

union {

struct {
.
. (additional source statements)
.
unsigned char s50_children_on_stat ;
unsigned char s50_children_on_type ;
unsigned char s50_children_on_yco ;
unsigned char s50_children_on_xco ;
unsigned short s50_children_on_char ;
unsigned short s50_children_on_fid ;
unsigned char s50_children_on_val ;
unsigned char s50_children_on_dyn ;
unsigned char s50_children_on_back ;
unsigned char s50_children_on_fore ;
unsigned char s50_children_on_int ;
unsigned char s50_children_on_high ;
unsigned char s50_children_on_font ;

Example 3–47. Example of FORMGEN C Structure

7831 4077–009 3–203

Application Programming in a Batch or Demand Environment

unsigned char s50_children_on_emph ;

struct {

unsigned char s50_child_first_name_stat ;

unsigned char s50_child_first_name_type ;
unsigned char s50_child_first_name_yco ;
unsigned char s50_child_first_name_xco ;
unsigned short s50_child_first_name_char ;
unsigned short s50_child_first_name_fid ;
unsigned char s50_child_first_name_val ;
unsigned char s50_child_first_name_dyn ;
unsigned char s50_child_first_name_back ;
unsigned char s50_child_first_name_fore ;
unsigned char s50_child_first_name_int ;
unsigned char s50_child_first_name_high ;
unsigned char s50_child_first_name_font ;
unsigned char s50_child_first_name_emph ;

unsigned char s50_child_last_name_stat ;

unsigned char s50_child_last_name_type ;
unsigned char s50_child_last_name_yco ;
unsigned char s50_child_last_name_xco ;
unsigned short s50_child_last_name_char ;
unsigned short s50_child_last_name_fid ;
unsigned char s50_child_last_name_val ;
unsigned char s50_child_last_name_dyn ;
unsigned char s50_child_last_name_back ;
unsigned char s50_child_last_name_fore ;
unsigned char s50_child_last_name_int ;
unsigned char s50_child_last_name_high ;
unsigned char s50_child_last_name_font ;
unsigned char s50_child_last_name_emph ;

} s50_child_index_fca[3] ;

} screen_dsplyind_50_fca_def ;

struct {

unsigned char s50_fca_stat ;

unsigned char s50_fca_type ;
unsigned char s50_fca_yco ;
unsigned char s50_fca_xco ;
unsigned short s50_fca_char ;
unsigned short s50_fca_fid ;
unsigned char s50_fca_val ;

Example 3-47. Example of FORMGEN C Structure

3–204 7831 4077–009

 Application Programming in a Batch or Demand Environment

unsigned char s50_fca_dyn ;

unsigned char s50_fca_back ;
unsigned char s50_fca_fore ;
unsigned char s50_fca_int ;
unsigned char s50_fca_high ;
unsigned char s50_fca_font ;
unsigned char s50_fca_emph ;

} screen_dsplyind_50_fca_redef[23] ;

} screen_dsplyind_50_fca ;

struct {

unsigned char s50_emp_number[5] ;

unsigned char s50_unused_12[3] ;

unsigned char s50_ind_first_name[12] ;

unsigned char s50_ind_last_name[20] ;

unsigned char s50_dept_name[24] ;

unsigned char s50_dept_no[4] ;

unsigned char s50_dept_description[56] ;

unsigned char s50_job_title[20] ;

unsigned char s50_job_salary[5] ;

unsigned char s50_unused_13[3] ;

unsigned char s50_job_description[50] ;

unsigned char s50_unused_14[2] ;

unsigned char s50_sports_action[71] ;

unsigned char s50_unused_15 ;

struct {

unsigned char s50_spt_name[10] ;

unsigned char s50_unused_16[2] ;

unsigned char s50_spt_league_type[13] ;

unsigned char s50_unused_17[3] ;

Example 3-47. Example of FORMGEN C Structure

7831 4077–009 3–205

Application Programming in a Batch or Demand Environment

} s50_sport_index_data[3] ;

struct {

unsigned char s50_child_first_name[12] ;

unsigned char s50_child_last_name[20] ;

} s50_child_index_data[3] ;

} screen_dsplyind_50_data ;

} screen_dsplyind_50 = {

" ", 0, " ", "$DPS$SWS", "0050",

"DSPLYIND", 149411, 92, 23, 24,
0, 24, 80, 6, 0,
0, 0, 116, 114, 0,
0, 0, 24, 1, 0,
0, 0, 0, 'V', 'D',
'E', 'W', 'N', 'N', 'N',
'N', 'Y', " ", "FORMS ", " ",

0, 2, 3, 19, 0, 1, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 3, 36, 0, 2, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 3, 49, 0, 3, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 7, 20, 0, 4, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 7, 56, 0, 5, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 8, 20, 0, 6, 'V',
'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 11, 20, 0, 7, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 11, 65, 0, 8, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

Example 3-47. Example of FORMGEN C Structure

3–206 7831 4077–009

 Application Programming in a Batch or Demand Environment

0, 2, 12, 20, 0, 9, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 15, 5, 0, 10, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 16, 20, 0, 11, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 16, 31, 0, 12, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 17, 20, 0, 13, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 17, 31, 0, 14, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 18, 20, 0, 15, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 18, 31, 0, 16, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 4, 20, 4, 0, 17, 'V',

'O', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 21, 20, 0, 18, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 21, 33, 0, 19, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 22, 20, 0, 20, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 22, 33, 0, 21, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 23, 20, 0, 22, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

0, 2, 23, 33, 0, 23, 'V',

'D', 'E', 'W', 'N', 'N', 'N', 'N',

Example 3-47. Example of FORMGEN C Structure

7831 4077–009 3–207

Application Programming in a Batch or Demand Environment

" ",
" ",

" ",

" ",

" ",

" ",

" ",

" ",

" ",
" ",

" ",

" ",

"*** COMPANY SPORTS PARTICIPATION *** "

" ",
' ',

" ",
" ",

" ",
" ",

" ",
" ",

" ",
" ",

" ",
" ",

" ",
" ",

" ",

" ",

Example 3-47. Example of FORMGEN C Structure

3–208 7831 4077–009

 Application Programming in a Batch or Demand Environment

" ",

" ",

" ",

" ",

} ;

Example 3-47. Example of FORMGEN C Structure

7831 4077–009 3–209

Application Programming in a Batch or Demand Environment

3.3.3. Coding UCS Programs That Use DPS 2200 Functions

DPS 2200 provides a simple CALL interface to perform its work. The syntax for a call
is the same for both UCS and non-UCS programs; it consists of the following:
• A mandatory function name that identifies the entry point into DPS 2200
• The mandatory DPS 2200 status argument (DPS-STATUS in COBOL, DS$STA in
FORTRAN, and &dps_status in C)
• Optional arguments whose values depend upon the function being called

The generic DPS 2200 standard calling sequence is as follows:

UCS COBOL
CALL 'function-name' USING DPS-STATUS, arg2, arg3, ...

UCS FORTRAN
CALL function-name (DS$STA, arg2, arg3, ...)

UCS C
function_name (&dps_status, arg2,arg3...);

For more information on DPS 2200 coding, refer to the DPS 2200 Run-Time
Programming Reference Manual

3–210 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.4. Compiling UCS Programs That Use DPS 2200

After a DPS 2200 program is coded, it must be compiled. Predefined form procedures
generated for COBOL have only one 01 level, thus assuring the allocation of
contiguous storage without the use of any special keyword options.

DPS 2200 system procs are placed in the system proc file, SYS$LIB$*PROC$.
Therefore, no special @USE COB$PF or @USE FTN$PF statement is required when
compiling UCS COBOL or UCS FORTRAN programs using DPS 2200. The compiler
always searches the system proc file (if necessary). The UCS C procs are added to the
system proc file, SYS$LIB*PROC$ when a mode C installation is used for
SYS$LIB$*DPS.

The DPS 2200 form procs are supplied by COPY, INCLUDE, or #include statements in
the program. You can ensure that the form procs are located by using an @USE
COB$PF, @USE FTN$PF, or @USE C$PF statement. (For information on how the
compiler searches for COPY, INCLUDE, or #include procs, see Volume 2 of the
appropriate programming reference manual.)

7831 4077–009 3–211

Application Programming in a Batch or Demand Environment

The following figure illustrates compilation of a UCS COBOL, UCS FORTRAN, or UCS C
program using DPS 2200 functions.

The following runstream shows a typical compilation:

(1) @PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50

@EOF

(2) @UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS

Explanation
1. The Procedure Definition Processor (PDP) takes an element of symbolic procs
(defining DPS 2200 screens) and prepares it for use by the compiler. UCS C forms
do not require use of the PDP.
2. This statement compiles the UCS COBOL program that uses DPS 2200 functions.
In this example, the file containing the form procs is the same as the file
containing the program, so the procs are successfully located. SB5R2 or later
software that supports UCS is being used, therefore compatibility keyword
options are not required.

3–212 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.5. Basic Linking Information for UCS DPS 2200 Programs

When you link a UCS program that uses DPS 2200 functions, the linking process must
locate the following object modules:
• UCS/INTERFACE
This object module provides the interface to UCS programs.

• EMCBEP$$DPS
This object module supplies the BDI entry into the DPS 2200 configuration common
bank.

The standard DPS 2200 installation file is SYS$LIB$*DPS. When you use the DPS 2200
software located in this file, the system default library search chains located in
SYS$*DATA$.SSDEF$ include a search of SYS$LIB$*DPS; therefore, references
requiring UCS/INTERFACE and EMCBEP$$DPS are resolved using this file.

You might want to link to alternate DPS 2200 software located in a different file (for
example, DPS 2200 software belonging to a particular application group). In this case,
you should do one of the following to ensure that these object modules are available:
• Build a user-defined library search chain that uses the desired version of DPS 2200
to resolve references
The system-defined library search chains built for application groups do not serve this
purpose: They do not contain a file for resolving the DPS 2200 references. See 4.5 for
instructions on how to build a new library search chain that includes a search of both
of the following:
− A file for resolving references to DPS 2200
− Any files already included in the application group library search chains
provided by Unisys

• Explicitly make the object modules available, by doing the following:

− For dynamic linking, copy them into the file from which execution is to take
place.
− For static linking, use INCLUDE commands to supply them to the LINK
Processor.

7831 4077–009 3–213

Application Programming in a Batch or Demand Environment

Dynamically Linking a DPS 2200 Program

If DPS 2200 is being used from the file SYS$LIB$*DPS, you can immediately execute
the compiler-produced object module and the program will be dynamically linked.

However, if DPS 2200 resides in a different file, you must do one of the following.

• Use a user-defined library search chain:

1. Create a user-defined library search chain that causes a search of that DPS
2200 file. This way, the dynamic linker can find the correct UCS/INTERFACE
and EMCBEP$$DPS object modules in order to resolve references.
2. Specify an @USE LINK$PF statement that identifies this library search chain,
before you execute the UCS compiler-produced program.
• Another option is to copy these two object modules, UCS/INTERFACE and
EMCBEP$$DPS, to the file from which the execution will take place. That way
they will be located when the dynamic linker searches HOME$.

The following runstream shows the first method: use of a user-defined library search
chain, as described in 4.5. The library search chain is defined in
SYS$LIB$*APP$7DPS.SSDEF$.

@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF

@UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS

@USE LINK$PF,SYS$LIB$*APP$7DPS.
@XQT QUAL*UCSTST.DPSDSPLY

Statically Linking a DPS 2200 Program

If DPS 2200 is being used from the file SYS$LIB$*DPS, you can statically link a UCS
program containing DPS 2200 functions with no extra setting up.

However, if DPS 2200 resides in a different file, then you must do one of the following:
• Use INCLUDE commands to explicitly supply the object modules UCS/INTERFACE
and EMCBEP$$DPS (this method is used in the example that follows).
• Specify use of a user-defined library search chain that identifies the file where
UCS/INTERFACE and EMCBEP$$DPS reside, by using an @USE LINK$PF statement
(see 4.5).

3–214 7831 4077–009

 Application Programming in a Batch or Demand Environment

The following example shows how to statically link a UCS program containing DPS
2200 functions, using the first method just described. This example produces a zero
overhead object module:

(1) @LINK ,QUAL*UCSTST.DPSDSPLY

(2) INCLUDE QUAL*UCSTST.DPSDSPLY/COMP
(3) INCLUDE qual*dpsfile.UCS/INTERFACE,.EMCBEP$$DPS
(4) RESOLVE ALL REFERENCES USING LIBCODENAME
(5) PROCESS FOR EXTENDED ZOOM
(6) DELETE ALL DEFINITIONS EXCEPT START$
(7) @EOF

Explanation
1. This statement calls the Linking System LINK Processor. The ZOOM to be
produced is named QUAL*UCSTST.DPSDSPLY.
2. This command identifies the compiler-generated object module containing the
UCS DPS 2200 program.
3. This command identifies the two object modules required for using DPS 2200. In
the examples in this guide, the DPS 2200 file for application group 7 is APP7*DPS.
Therefore, in the examples in this guide, this command appears as
INCLUDE APP7*DPS.UCS/INTERFACE,.EMCBEP$$DPS

4. This command resolves external references, including those to the UCS Runtime
System library.
5. This command merges banks and produces a ZOOM.
6. This command deletes all definitions except the program’s starting address,
START$. This decreases the size of the ZOOM.
7. This statement ends static linking.

7831 4077–009 3–215

Application Programming in a Batch or Demand Environment

3.3.6. Example of a UCS COBOL Program Using DPS 2200

Functions
The following subsections show an example of a UCS COBOL program that uses DPS
2200 functions. The example is shown first using a user-defined library search chain
and dynamic linking, then using static linking (the two required DPS 2200 object
modules are supplied with INCLUDE commands).

The following figure summarizes the simple UCS DPS 2200 program used in the
example. The program
1. Reads an individual employee number.
2. Retrieves the form to be displayed from the form file.
3. Moves the employee number to the form.
4. Displays the form on the terminal screen.

DPSDSPLY
IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDSPLY.
.
.
DATA DIVISION.
WORKING-STORAGE SECTION.
form definition
.
.
.
01 EMPLOYEE-NUMBER ....
PROCEDURE DIVISION.
CALL 'D$INIT1' ...
CALL 'D$GETIN' ...
CALL 'D$GETFL' ...
MOVE GET-FIELD-TEXT TO EMPLOYEE-NUMBER
CALL 'D$OPEN' ...
MOVE EMPLOYEE-NUMBER TO form definition
CALL 'D$SEND' ...
CALL 'D$TERM' ...
STOP RUN.

3–216 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of the DPS 2200 COBOL Program (DPSDSPLY)

Example 3–48 shows the complete source listing of the program, DPSDSPLY. In this
example, this program resides in element QUAL*UCSTST.DPSDSPLY. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDSPLY.
******************************************************************
******************************************************************
* *
* SIMPLE DPS COBOL PROGRAM - DPSDSPLY *
* *
* initializes with DPS *
* reads the input employee number *
* opens the DPS form *
* moves the employee number to the form *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.

Example 3–48. Source Listing of DPS Program (QUAL*UCSTST.DPSDSPLY)

7831 4077–009 3–217

Application Programming in a Batch or Demand Environment

COPY GETFIELD.
COPY SENDERROR.
COPY SCREEN-DSPLYIND-50.
PROCEDURE DIVISION.
************************************************************
* DEMAND INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL 'D$INIT1' USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-GET-INPUT.
CALL 'D$GETIN' USING DPS-STATUS.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
DPS-FREE-FORMAT-READ.
CALL 'D$GETFL' USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.
IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER
************************************************************
DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN' USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA

Example 3–48. Source Listing of DPS Program (QUAL*UCSTST.DPSDSPLY)

3–218 7831 4077–009

 Application Programming in a Batch or Demand Environment

PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* SENDS THE SCREEN TO THE USER
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND' USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* TERMINATION OF THE PROGRAM
************************************************************
TERMINATION-PARA.
CALL 'D$TERM' USING DPS-STATUS.
STOP RUN.
*
*
************************************************************
* RETURNS AN ERROR MESSAGE TO THE USER IF THE INPUT
* MESSAGE WAS IN ERROR AND TERMINATES WITH THE
* TRANSACTION PROCESSING SYSTEM
************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR' USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*
*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO
* TO A DPS INTERNAL ERROR.
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG' USING DPS-STATUS.

Example 3–48. Source Listing of DPS Program (QUAL*UCSTST.DPSDSPLY)

7831 4077–009 3–219

Application Programming in a Batch or Demand Environment

Source Listing of Runstream to Compile

Example 3–49 shows the source listing of a runstream used to compile the example
program DPSDSPLY. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A SIMPLE DPS COBOL PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
@UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–49. Runstream to Compile COBOL DPS Program

3–220 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution of the Compilation Source Runstream

Example 3–50 shows the execution of the source runstream used to compile this
example. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13R1J (931108 0108:39) 1994 Feb 03 Thu 2141:41
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 2.615 Storage:7070/0/7070/0106210
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A SIMPLE DPS COBOL PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
I:002333 USE complete.
@UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940203 21:41:44
SIZES: CODE(EM6): 218 DATA: 428
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–50. Execution of Compilation Source Runstream—COBOL DPS Program

7831 4077–009 3–221

Application Programming in a Batch or Demand Environment

Execution of the Program in Demand Mode

The following screens show execution of this program in demand mode, using
dynamic linking. User input is bolded.

@use link$pf,sys$lib$*ap$7dps.
I:002333 USE complete.
@xqt qual*ucstst.dpsdsply/comp

10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME:

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY: $
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

3–222 7831 4077–009

 Application Programming in a Batch or Demand Environment

Source Listing of Runstream to Compile and Statically Link

Example 3–51 shows the source listing of a runstream used to compile and statically
link this example. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A SIMPLE DPS COBOL PROGRAM
@ . ***
@USE COB$PF, APP7*DPS.
@UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@LINK ,QUAL*UCSTST.DPSDSPLY
INCLUDE QUAL*UCSTST.DPSDSPLY/COMP
INCLUDE APP7*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–51. Source Listing of Runstream to Compile and Static Link— COBOL
DPS Program

7831 4077–009 3–223

Application Programming in a Batch or Demand Environment

Execution of the Source Runstream to Compile and Statically Link

Example 3–52 shows the execution of the source runstream used to compile and
statically link this example. Output has been saved by an @BRKPT statement.
Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13R1J (931108 0108:39) 1994 Feb 03 Thu 2152:04
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 2.583 Storage:7070/0/7070/0106210
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A SIMPLE DPS COBOL PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
I:002333 USE complete.
@UCOB QUAL*UCSTST.DPSDSPLY,.DPSDSPLY/COMP,,,NO-OPTIONS
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940203 21:52:07
SIZES: CODE(EM6): 218 DATA: 428
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@LINK ,QUAL*UCSTST.DPSDSPLY
LINK 5R2 (940112 1230:40) 1994 Feb 03 Thu 2152:25
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–52. Execution of Source Runstream to Compile and Static Link—

COBOL DPS Program

3–224 7831 4077–009

 Application Programming in a Batch or Demand Environment

Execution in Demand Mode

The following screens show the execution of this program in demand mode (the
program has already been statically linked). User input is bolded.

@xqt qual*ucstst.dpsdsply

10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME:

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY: $
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

7831 4077–009 3–225

Application Programming in a Batch or Demand Environment

3.3.7. Example of a UCS C Program Using DPS 2200

The following subsections show an example of a UCS C program that uses DPS 2200
functions. The example is shown using static linking.

The following example summarizes the simple UCS DPS 2200 program used in the
example. The program
• Reads an individual’s employee number.
• Retrieves the form to be displayed.
• Moves the employee number to the form.
• Displays the form on the terminal screen.

CDPSDSPLY
.
.
.
#include "form definition"
.
.
.
char employee_number[5];
.
.
.
d-init1... ;
d-getin... ;
d-getfl... ;
d-open... ;
strncpy getfield_text to form definition
d-send... ;
d-term... ;
return(0);

3–226 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.7.1. Source Listing of the DPS 2200 C Program (CDPSDSPLY)

Example 3–53 shows the complete source listing of the program CDPSDPSLY. In this
example, this program resides in element QUAL*UCSTST.CDPSDSPLY. Noteworthy
lines are bolded.

/* ***************************************************************
* *
* SIMPLE DPS C PROGRAM - CDPSDSPLY *
* *
* initializes with DPS *
* reads the input employee number *
* opens the DPS form *
* moves the employee number to the form *
* displays the DPS form *
* terminates with DPS *
* *
*************************************************************** */
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <dpsfunc-def.h>
#include <dps-stat-def.h>
#include <info-buf-def.h>
#include <get-fld-def.h>
#include <senderr-def.h>
#include "screen-50.h"
/* ************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT *
************************************************************ */
char employee_number[5];
char err_employee_number[41];

int main(void)
{
/* ************************************************************
* DEMAND INITIALIZATION WITH DPS *
************************************************************ */
d_init1(&dps_status, &info_buffer);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER *
* RETURNS THE EMPLOYEE NUMBER *
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT *
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH *
************************************************************ */

Example 3–53. Source Listing of DPS 2200 C Program

7831 4077–009 3–227

Application Programming in a Batch or Demand Environment

d_getin(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_getfl(&dps_status, &get_field);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();

if(get_field.u_1.s_1.getfield_type == 1)
{ strcpy(error_message.error_text,
"NO EMPLOYEE NUMBER WAS SPECIFIED");
d_senderr(&dps_status, &error_message, &error_coordinates);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
return(0);
}
else { if(get_field.u_1.s_1.getfield_length != 5)
{ strncpy(err_employee_number,
get_field.getfield_text, sizeof(err_employee_number));
err_employee_number[40] = '\0';
sprintf(error_message.error_text,
"NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER %s",
err_employee_number);
d_senderr(&dps_status, &error_message, &error_coordinates);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
return(0);
}
}
/* ************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER *
************************************************************ */
d_open(&dps_status, &screen_dsplyind_50);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION *
************************************************************ */
strncpy(screen_dsplyind_50.screen_dsplyind_50_data.s50_emp_number,
get_field.getfield_text, sizeof(employee_number));
/* ************************************************************
* SENDS THE SCREEN TO THE USER *
************************************************************ */

Example 3–53. Source Listing of DPS 2200 C Program

3–228 7831 4077–009

 Application Programming in a Batch or Demand Environment

d_send(&dps_status, &screen_dsplyind_50);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* TERMINATION OF THE PROGRAM *
************************************************************ */
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
return(0);
}
/* ************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS *
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF *
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO *
* TO A DPS INTERNAL ERROR. *
************************************************************ */
void error_exit(void)
{
d_dump();
d_errmsg(&dps_status);
d_term(&dps_status);
exit(1);
}

Example 3–53. Source Listing of DPS 2200 C Program

7831 4077–009 3–229

Application Programming in a Batch or Demand Environment

3.3.7.2. Source Listing of Runstream to Compile

Example 3–54 shows the source listing of a runstream used to compile and statically
link this example. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** UC COMPILE OF A SIMPLE DPS C PROGRAM
@ . ***
@USE C$PF,APP7*DPS.
@UC QUAL*UCSTST.CDPSDSPLY,QUAL*UCSTST.CDPSDSPLY/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@LINK ,QUAL*UCSTST.CDPSDSPLY
INCLUDE QUAL*UCSTST.CDPSDSPLY/COMP
INCLUDE APP7*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–54. Source Listing to Compile—CDPSDSPLY

3–230 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.7.3. Execution of the Source Runstream to Compile

Example 3–55 shows the execution of the source runstream used to compile and
statically link this example. Output has been saved by an @BRKPT statement.
Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** UC COMPILE OF A SIMPLE DPS C PROGRAM
@ . ***
@USE C$PF,APP7*DPS.
I:002333 USE complete.
@UC QUAL*UCSTST.CDPSDSPLY,QUAL*UCSTST.CDPSDSPLY/COMP,,,NO-OPTIONS
UC- 4R2(931119) LSS- 8R2(931209) 940209 10:32:05
SIZES: CODE(EM6): 377 DATA: 387
END UC- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@LINK ,QUAL*UCSTST.CDPSDSPLY
LINK 5R2 (940112 1230:40) 1994 Feb 09 Wed 1032:36
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** SETUP IS COMPLETE

Example 3–55. Execution of Source Runstream—CDPSDSPLY

7831 4077–009 3–231

Application Programming in a Batch or Demand Environment

3.3.7.4. Execution in Demand Mode

The following screens show the execution of this program in demand mode (the
program has already been statically linked). User input is bolded.

@xqt qual*ucstst.cdpsdsply

10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME:

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY: $
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

3–232 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.8. Using DPS 2200 with the UDS Database Models

DPS 2200 can be used in conjunction with the UDS database models to provide a
complete application programming environment.

When using DPS 2200 with any of the UDS database interfaces, it is recommended
that you code the DPS 2200 initialization command (D$INIT, D$INIT1) before coding the
UDS initialization commands (BEGIN THREAD, IMPART). At the end of the program,
termination with the UDS database interfaces (DEPART, END THREAD) must precede
termination with DPS 2200 (D$TERM, D$CLOSE).

This is the way code must be written for transactions; therefore, it is a good idea to
code using this method for demand mode DPS 2200 programs.

The following subsections show an example of a DPS 2200 program that accesses all
three UDS database models:
• DMS 2200
• RDMS 2200
• SFS 2200

To produce this example, DPS 2200 code has been added to the multiple-database-
model program found in 3.2.4. For this example, static linking is used to produce a
zero overhead object module.

The following figure summarizes the UCS program used in the example. The program
1. Reads an individual’s employee number
2. Retrieves the form to be displayed from the form file
3. Moves the employee number to the form
4. Accesses information about the individual from the DMS 2200, RDMS 2200, and
SFS 2200 databases
5. Moves this information to the form
6. Displays the form on the terminal screen

7831 4077–009 3–233

Application Programming in a Batch or Demand Environment

DPSDSPLYALL
IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDSPLYALL INITIAL.
.
.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file-name
ASSIGN TO A-SHARED-FILE ....
.
.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE .....
.
.
FILE SECTION.
FD file-name
file definition ....
WORKING-STORAGE SECTION.
table definitions ...
form definition
.
.
01 EMPLOYEE-NUMBER ....
.
PROCEDURE DIVISION.
CALL 'D$INIT1' ...
CALL 'D$GETIN' ...
CALL 'D$GETFL' ...
MOVE GET-FIELD-TEXT TO EMPLOYEE-NUMBER
CALL 'D$OPEN' ...
MOVE EMPLOYEE-NUMBER TO form
BEGIN THREAD
OPEN FILE
IMPART
OPEN DMS areas .... RETRIEVAL
FETCHs ....
MOVE DMS data TO form
READ FILE
MOVE SFS data TO form
DEFINE CURSOR
OPEN CURSOR
FETCHs ....
MOVE RDMS data TO form
DEPART
CLOSE FILE
END THREAD
CALL 'D$SEND' ...
CALL 'D$TERM' ...
STOP RUN.

3–234 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.8.1. Source Listing of the Program (DPSDSPLYALL)

Example 3–56 shows the complete source listing of the program DPSDSPLYALL. This
program uses DPS 2200 for screen control while accessing a DMS 2200, RDMS 2200,
and SFS 2200 database.

In this example, this program resides in element QUAL*UCSTST.DPSDSPLYALL.

Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDSPLYALL INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE BATCH COBOL DPS/DMS/SFS/RDMS PROGRAM - DPSDSPLYALL *
* *
* initializes with DPS *
* reads the input data *
* opens the DPS form *
* moves the employee number to the form *
* begins thread with UDS *
* opens the SPORTS SFS database file *
* imparts to the PERSONNEL database *
* retrieves the requested information from the DMS database *
* moves the DMS information to the form *
* retrieves the requested information from the SFS database *
* moves the SFS information to the form *
* retrieves the requested information from the RDMS database *
* moves the RDMS information to the form *
* departs from the PERSONNEL database *
* closes the SPORTS SFS database file *
* ends thread with UDS *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SPORTS
ASSIGN TO A-SHARED-FILE SFSSPORTS
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

7831 4077–009 3–235

Application Programming in a Batch or Demand Environment

RECORD KEY IS SPT-EMP-NUMBER

ALTERNATE RECORD KEY IS SPT-IND-LAST-NAME WITH DUPLICATES.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUB IN FILE SCHFILE
OF SCHEMA PERSONNEL
COPYING RECORDS INTO WORKING
COPYING DATA-NAMES INTO WORKING
RUN-UNIT-ID DSPIND
DMCA IS WORKING
ERROR DMS-GENERAL-ERROR-PARA.

FILE SECTION.
FD SPORTS.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).

WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* NO SPORTS MESSAGE
************************************************************
01 NO-SPORTS PIC X(78)
VALUE '*** NO COMPANY-SPONSORED SPORTS PARTICIPATION
************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
COPY GETFIELD.
COPY SENDERROR.
COPY SCREEN-DSPLYIND-50.
************************************************************

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

3–236 7831 4077–009

 Application Programming in a Batch or Demand Environment

* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT

************************************************************
01 EMPLOYEE-NUMBER.
05 EMP-PAGE PIC 9(3).
05 EMP-RECORD PIC 9(2).
************************************************************
* RDMS WORK AREA SIZE
************************************************************
01 WORK-AREA-SIZE PIC 1(36) USAGE BINARY-1 VALUE 2000.
************************************************************
* UDS THREAD STATUS FLAG
************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 CHILD-LAST-NAME PIC X(20).
01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* ESQL STATEMENT STATUS
************************************************************
01 SQLSTATE PIC X(5).
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
************************************************************
* GETERROR BUFFERS
************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************
01 ERR-INDEX PIC 9.
************************************************************
* ALLERROR INDICATOR
************************************************************
01 XX PIC 9 VALUE 0.
88 ALLERR VALUE 1.
************************************************************
* COUNTER FOR CHILDREN
************************************************************
01 CHILD-COUNT PIC 9(1) VALUE 0.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

7831 4077–009 3–237

Application Programming in a Batch or Demand Environment

************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
*
PROCEDURE DIVISION.
************************************************************
* DEMAND INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL 'D$INIT1' USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-GET-INPUT.
CALL 'D$GETIN' USING DPS-STATUS.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
DPS-FREE-FORMAT-READ.
CALL 'D$GETFL' USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.
IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

3–238 7831 4077–009

 Application Programming in a Batch or Demand Environment

************************************************************
* EMPLOYEE NUMBER VALIDATION
************************************************************
VALID-EMPLOYEE-NUMBER.
IF EMP-PAGE <= 99 OR EMP-RECORD <= 0
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER
************************************************************
DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN' USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* RDMS - SETS UP RDMS WORK AREA
* SETS UP RDMS GENERAL ERROR HANDLING
************************************************************
RDMS-SETUP.
CALL 'RSA$INIT' USING WORK-AREA-SIZE.
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEMS
************************************************************
CONNECT-TO-DATABASES.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
MOVE 1 TO THREAD-FLAG.
OPEN INPUT SPORTS.
IMPART.
OPEN ALL USAGE-MODE IS RETRIEVAL.
************************************************************
* DMS - RETRIEVE THE INDIVIDUAL INFORMATION
* MOVE THE INDIVIDUAL INFORMATION TO THE DPS FORM
************************************************************
DMS-RETRIEVE-INDIVIDUAL-DATA.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

7831 4077–009 3–239

Application Programming in a Batch or Demand Environment

MOVE 'EMPNOAREA' TO EMPNO-AREA-NAME.

MOVE EMP-PAGE TO PAGE-NUM OF EMPNO-AREA-KEY.
MOVE EMP-RECORD TO RECORD-NUM OF EMPNO-AREA-KEY.
FETCH EMPNUMBER RECORD.
FETCH NEXT RECORD WITHIN EMPNO-IND SET.
FETCH OWNER RECORD WITHIN DEPT-IND SET.
FETCH OWNER RECORD WITHIN JOB-IND SET.
DMS-MOVE-INDIVIDUAL-DATA.
MOVE IND-LAST-NAME TO S50-IND-LAST-NAME.
MOVE IND-FIRST-NAME TO S50-IND-FIRST-NAME.
MOVE DEPT-NAME TO S50-DEPT-NAME.
MOVE DEPT-NO TO S50-DEPT-NO.
MOVE DEPT-DESCRIPTION TO S50-DEPT-DESCRIPTION.
MOVE JOB-TITLE TO S50-JOB-TITLE.
MOVE JOB-DESCRIPTION TO S50-JOB-DESCRIPTION.
MOVE JOB-SALARY TO S50-JOB-SALARY.
************************************************************
* SFS - RETRIEVE THE SPORTS INFORMATION
* MOVE THE SPORTS INFORMATION TO THE DPS FORM
************************************************************
SFS-RETRIEVE-SPORTS-DATA.
MOVE EMP-NUMBER TO SPT-EMP-NUMBER.
READ SPORTS RECORD
KEY IS SPT-EMP-NUMBER
INVALID KEY PERFORM BAD-KEY.
IF SPT-ACTIVE-COUNT = 0
MOVE NO-SPORTS TO S50-SPORTS-ACTION
ELSE PERFORM VARYING I FROM 1 BY 1 UNTIL I > SPT-ACTIVE-COUNT
MOVE SPT-NAME (I) TO S50-SPT-NAME (I)
MOVE SPT-LEAGUE-TYPE (I) TO S50-SPT-LEAGUE-TYPE (I)
END-PERFORM
END-IF.
************************************************************
* RDMS - SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
* DEFINE THE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN THE CURSOR
* RETRIEVE DATA FROM THE CURSOR
* MOVE THE CHILD INFORMATION TO THE DPS FORM
************************************************************
RDMS-SET-DEFAULT-QUALIFIER.
EXEC SQL
USE DEFAULT QUALIFIER FAMILY
END-EXEC.
RDMS-SETUP-CHILDDATA-CURSOR.
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

3–240 7831 4077–009

 Application Programming in a Batch or Demand Environment

WHERE CHILD.CHILD_EMP_NUMBER = :EMP-NUMBER

END-EXEC.
EXEC SQL
OPEN CHILDDATA
END-EXEC.
RDMS-FETCH-MOVE-CHILD-DATA.
PERFORM WITH TEST AFTER UNTIL SQLSTATE = "02000"
EXEC SQL
FETCH NEXT CHILDDATA INTO
:CHILD-LAST-NAME, :CHILD-FIRST-NAME
END-EXEC
IF SQLSTATE NOT = "02000"
ADD 1 TO CHILD-COUNT
MOVE CHILD-FIRST-NAME
TO S50-CHILD-FIRST-NAME (CHILD-COUNT)
MOVE CHILD-LAST-NAME
TO S50-CHILD-LAST-NAME (CHILD-COUNT)
END-IF
END-PERFORM.
IF CHILD-COUNT = 0 MOVE 'C' TO S50-CHILDREN-ON-DYN.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEMS
************************************************************
DMS-DEPART-PARA.
DEPART.
SFS-FILE-CLOSE-PARA.
CLOSE SPORTS.
UDS-END-THREAD-PARA.
END THREAD.
MOVE 0 TO THREAD-FLAG.
************************************************************
* SENDS THE SCREEN TO THE USER
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND' USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* TERMINATION WITH DPS
************************************************************
DPS-TERMINATION.
CALL 'D$TERM' USING DPS-STATUS.
************************************************************
* PROGRAM TERMINATION
************************************************************
TERMINATION-PARA.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

7831 4077–009 3–241

Application Programming in a Batch or Demand Environment

STOP RUN.
*
*
************************************************************
* DMS - CHECK FOR A '0013' ERROR,
* IF THIS ERROR OCCURRED THE
* INVALID-EMPLOYEE-NUMBER MESSAGE IS PRINTED
* ELSE THE ERROR MESSAGE IS RETURNED TO THE PRINTER
* FOR DEBUGGING.
************************************************************
DMS-GENERAL-ERROR-PARA.
IF ERROR-NUM = '0013'
MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
ELSE DISPLAY 'DMS-GENERAL-ERROR-PARA.' UPON PRINTER
DISPLAY 'AREA = ' ERROR-AREA UPON PRINTER
DISPLAY 'RECORD = ' ERROR-RECORD UPON PRINTER
DISPLAY 'SET = ' ERROR-SET UPON PRINTER
DISPLAY 'ROLLBACK = ' RB-ERROR-CODE UPON PRINTER
DISPLAY 'FUNCTION = ' ERROR-FUNCTION UPON PRINTER
DISPLAY 'ERR NUM = ' ERROR-NUM UPON PRINTER
END-IF.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
************************************************************
* SFS - DISPLAY OF BAD INPUT KEY
************************************************************
BAD-KEY.
MOVE EMP-NUMBER TO ERR-EMPLOYEE-NO.
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE.
PERFORM INVALID-INPUT-PARA.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
************************************************************
* RDMS - RETURN AN ERROR MESSAGE TO THE PRINTER FILE IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

3–242 7831 4077–009

 Application Programming in a Batch or Demand Environment

DISPLAY '***SQLSTATE = ' SQLSTATE UPON PRINTER.

DISPLAY '***RDMCA AUX-INFO = ' AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = ' ERROR-STATUS OF RDMCA
UPON PRINTER.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TXT
EXEC SQL
GETERROR INTO :ERR(1),;ERR(2),:ERR(3),:ERR(4),:ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
*
************************************************************
* RETURNS AN ERROR MESSAGE TO THE USER IF THE INPUT
* MESSAGE WAS IN ERROR AND TERMINATES WITH THE
* TRANSACTION PROCESSING SYSTEM
************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR' USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*
*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO
* TO A DPS INTERNAL ERROR.
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG' USING DPS-STATUS.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
IF THREAD-FLAG = 1 PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.

Example 3–56. Source Listing of the Program (DPSDSPLYALL)

7831 4077–009 3–243

Application Programming in a Batch or Demand Environment

3.3.8.2. Source Listing of the Runstream to Compile and Statically

Link
Example 3–57 shows the source listing of a runstream used to compile and statically
link the example program DPSDSPLYALL. Noteworthy lines are bolded.
@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *****************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE MULTIPLE DATA MODEL (DMS, SFS, ESQL) PROGRAM
@ . *** THAT USES DPS FOR TERMINAL OUTPUT
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
@USE COB$PF,APP7*DPS.
@ . ***
@UCOB QUAL*UCSTST.DPSDSPLYALL,QUAL*UCSTST.DPSDSPLYALL/COMP,,, ;
NO-OPTIONS, COMPAT, APPLICATION/APPSVN

@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.DPSDSPLYALL
INCLUDE QUAL*UCSTST.DPSDSPLYALL/COMP
INCLUDE UDS$$SVN*SCHFILE.S$WORK/PERSONSUB
INCLUDE APP7*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–57. Runstream to Compile and Static Link—COBOL

DPS/DMS/ESQL/SFS Program

3–244 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.3.8.3. Execution of the Source Runstream to Compile and

Statically Link
Example 3–58 shows the execution of the source runstream used to compile and
statically link this example. Output has been saved by the @BRKPT statement.
Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION *********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13R1J (931108 0108:39) 1994 Feb 03 Thu 2209:23
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 2.743 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@ . *** UCOB COMPILE OF THE MULTIPLE DATA MODEL (DMS, SFS, ESQL) PROGRAM
@ . *** THAT USES DPS FOR TERMINAL OUTPUT
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILE.
W:120133 file is already assigned.
@USE SCHFILE.,UDS$$SVN*SCHFILE.
I:002333 USE complete.
@USE COB$PF,APP7*DPS.
I:002333 USE complete.
@ . ***
@UCOB QUAL*UCSTST.DPSDSPLYALL,QUAL*UCSTST.DPSDSPLYALL/COMP,,, ;
NO-OPTIONS,COMPAT,APPLICATION/APPSVN
UCOB- 6R2 (931119) LSS- 8R2 (931209) 940203 22:09:25
SIZES: CODE(EM6): 1906 DATA: 1626
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** STATIC LINK OF THIS PROGRAM TO PRODUCE A ZOOM
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.

Example 3–58. Execution of Source Runstream to Compile and Static Link—

COBOL DPS/DMS/ESQL/SFS Program

7831 4077–009 3–245

Application Programming in a Batch or Demand Environment

@LINK ,QUAL*UCSTST.DPSDSPLYALL
LINK 5R2 (940112 1230:40) 1994 Feb 03 Thu 2209:52
END LINK , LINES : 6 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** EXAMPLE IS COMPLETE

Example 3–58. Execution of Source Runstream to Compile and Static

Link—COBOL DPS/DMS/ESQL/SFS Program

3.3.8.4. Execution of the Program in Demand Mode

The following screens show the execution of the example program in demand mode.
User input is bolded.

@use sfssports,leisure*sports.
I:0023333 USE complete.
@xqt qual*ucstst.dpsdsplyall

10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: APPLICATION DEVELOPMENT NUMBER: 4124
FUNCTION: DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION

*** JOB INFORMATION ***

TITLE: PROGRAMMER YEARLY SALARY: $40000
FUNCTION: DESIGNS, WRITES, AND TESTS CODE

*** COMPANY SPORTS PARTICIPATION ***

GOLF ADVANCED
VOLLEYBALL INTERMEDIATE

*** CHILDREN ***

STEVEN JR FIELDING
DANIEL FIELDING
JANE FIELDING

3–246 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.4. Accessing the Unisys Repository Manager

(UREP) with UCS COBOL
The Unisys Repository Manager (UREP) is the product that you directly use to create,
update, and store definitions for the following types of Universal Data System (UDS)
databases:
• Networks (DMS)
• Relational (RDMS)
• Conventional file (SFS)

In addition to creating and storing databases definitions, you can use UREP directly
from your UCS COBOL, UCS FORTRAN, and UCS C programs to perform the following
functions:
• Insert code into your UCS source program with the INVOKE or #pragma command.
These INVOKE commands cause UREP to generate file descriptions, data
declarations, RDMS table and view data declarations, and DPS 2200 form
definitions from definitions that you previously created and stored in UREP. UREP
places the generated code in the source program at the point of the INVOKE or
#pragma command.

Table 3–5. UCS COBOL Data Structures in the Unisys

Repository

Unisys Repository Structure UCS COBOL Structure

SELECT statement INVOKE SELECT

File descriptions INVOKE ALL FILE
Data item definitions INVOKE RECORD
RDMS table definitions INVOKE TABLE
RDMS view definitions INVOKE VIEW
DPS form definitions INVOKE FORM
Source code INVOKE SOURCE

In Table 3–5, all of the structures were available in the SB4 release except INVOKE
SOURCE, which was available in SB5.

7831 4077–009 3–247

Application Programming in a Batch or Demand Environment

Table 3–6. UCS C and UCS FORTRAN Structures in the Unisys

Repository

Unisys Repository
Structure UCS C UCS FORTRAN

Data item definitions #pragma invoke record = INVOKE (RECORD =

RDMS table definitions #pragma invoke table = INVOKE (TABLE =
RDMS view definitions #pragma invoke view = INVOKE (VIEW =
DPS FORM definitions #pragma invoke form = Not available
Source code #pragma invoke source = INVOKE (SOURCE =

• Store cross-reference information into UREP using the UREP-XREF keyword

option, to track definitions that UREP or COPY/INCLUDE/#include procedures
insert into the UCS source program.

For more information on using UREP with UCS COBOL programs, refer to the
appropriate UCS programming reference manual, Volume 2.

3–248 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.5. Improving Batch and Demand Execution-Time

Performance
The following subsections provide suggestions for producing batch and demand
programs that provide optimal execution-time performance. The topics covered
include
• Coding suggestions
• Compiling suggestions
• Linking suggestions

3.5.1. Coding for Batch and Demand Execution-Time

Performance
To achieve the best execution-time performance for a batch or demand program,
observe the following suggestions during coding:
• If you plan to use a static database design, code UCS COBOL and UCS C
programs that access RDMS 2200 databases using embedded SQL commands,
rather than the interpreter SQL interface (non-embedded SQL commands).
Embedded SQL commands are parsed at compilation time, whereas interpreter
SQL commands are parsed during each program execution.
• If you plan to use a static database design, code all UCS FORTRAN programs that
access RDMS 2200 databases using module SQL commands rather than the
interpreter SQL interface. Module SQL commands are parsed at compilation time,
whereas interpreter SQL commands are parsed during each program execution.
• A work area is provided for UCS programs (interpreted, module, and embedded
SQL) that access RDMS 2200 databases. This work area has a default initial
allocation of 14,000 words. The system acquires more space dynamically, as
needed.
However, the overhead incurred by obtaining additional space is expensive.
Therefore, for best performance, if the work area of your UCS RDMS 2200
program exceeds the default of 14,000 words, you should determine the amount
of space required by the program and set the work area size accordingly.
To do this, you should include in the program a call to RSA$INIT that allocates the
space desired for the RDMS 2200 work area. This call must precede the first
RDMS 2200 command in the program. You should make only one call to
RSA$INIT.

The syntax for this call is as follows:

− UCS COBOL
CALL "RSA$INIT" [USING work-area-size].

− UCS FORTRAN
CALL RSA$INIT [(work-area-size)]

7831 4077–009 3–249

Application Programming in a Batch or Demand Environment

− UCS C
rsa_init ([work-area-size]);

(UCS C requires #include <rsa.h>)

where work-area-size is a 36-bit binary integer declared in a UCS program as
follows:

− UCS COBOL
PIC 1(36) USAGE BINARY-1

− UCS FORTRAN
INTEGER

− UCS C
int

To determine the size of the work area, code a DEBUG DUMP SIZES command
immediately after the program's END THREAD command.

The following represents the syntax for an embedded SQL DEBUG DUMP SIZES
command in UCS COBOL:

EXEC SQL EXECUTE IMMEDIATE

'DEBUG DUMP SIZES'
END-EXEC.

The following represents the syntax for a UCS COBOL interpreter SQL DEBUG
DUMP SIZES command:

ENTER MASM 'ACOB$RDMR' USING

'DEBUG DUMP SIZES;'
ERROR-STATUS, AUX-INFO.

Similar syntax is available for the other UCS interfaces.

Execute the program and check the output of the DEBUG DUMP SIZES. It will
have the following format:
RSA Dbank Size is 13970 words.

Use the value listed previously in the call to RSA$INIT. Also remember to remove
the DEBUG DUMP SIZES command from the program. Note that this process also
is valid for TIP and HVTIP programs.

• Combine small frequently called subprograms or subroutines into a single

compilation unit with the program or subprograms that call them, whenever this is
feasible.

3–250 7831 4077–009

 Application Programming in a Batch or Demand Environment

• When coding UCS COBOL programs:

− Use the inline PERFORM statement for loops
− Avoid using the CANCEL statement to place a program in its initial state.
Instead, use the INITIAL clause on the PROGRAM-ID statement to establish
the program's initial state.
− Define all parameters to be passed as 01 level data items and use the
COMPAT/ARGUMENTS compiler keyword option when compiling these
programs
− Use the SQRT intrinsic function instead of n**.5 to figure square roots
• When coding UCS C programs:
− Use the alternate calling sequence (ACS) instead of the standard calling
sequence (SCS) when C programs call C functions. This can be accomplished
by using the ALT-CALL compiler keyword option for a global effect or by using
the "#pragma alternate function-name" statement for a specific function call.
− Use the "#pragma expand" and the "#pragma inline function-name" statements
to expand function calls inline. This should be done only if
− The function is small
− The function executes for a short period of time
− The function call is called many times
• The URTS “heap” bank URTS$TABLES may be a performance concern. If space in
the URTS$TABLES bank runs out, then it will either be expanded or another bank
allocated. This expansion/create-bank-call can be expensive. To prevent the
URTS$TABLES bank from being expanded or having another bank allocated at
execution time, you should consider the following:
− Closing PCIOS files when you are finished using them. This releases the space
that they were using.
− Using extended mode SORT (EM SORT). This moves the major portion of
space used by SORT processing to a separate bank so that it is no longer
located in the Heap Data Bank.
− Use the "CALL RSA$INIT" routine to initially allocate all RDMS space so that it is
allocated as contiguous space.

7831 4077–009 3–251

Application Programming in a Batch or Demand Environment

For more information on how to code UCS programs for performance, refer to the
programming reference manual for the appropriate UCS language (for UCS COBOL,
FORTRAN, and C, this information is in Volume 2.

3.5.2. Compiling for Batch and Demand Execution-Time

Performance
To achieve the best execution-time performance for a batch or demand program,
observe the following suggestions during compilation:
• Use the OPTIM compiler keyword option. (OPTIM is on by default.) This keyword
option increases the optimization performed by the LSS code generator, producing
code that is more efficient at execution time.
• Use the REORDER compiler keyword option. (REORDER is on by default.) This
keyword option increases the optimization performed by the LSS code generator,
producing code that is more efficient at execution time.
• For UCS COBOL, use the COMPAT/ARGUMENTS keyword option if you can
guarantee that all parameters are 01 levels. This insures that they are word-
aligned, which permits improved code generation for parameter references.
• Avoid use of the RUNCHECK keyword option on production-oriented compilations.
RUNCHECK performs functions such as the following:
− Subscript range checking on all array references
− Range checking on COBOL reference modification
− Range checking on FORTRAN substring variables
• Avoid use of the CLEAR keyword option. It initializes all uninitialized data to zeros.
This function can be performed more efficiently by program code.
• When using UCS FORTRAN or UCS C, consider using the compiler keyword option
EXPAND, for all routines that are small and frequently called. This keyword option
causes subprograms or subroutines to be generated inline (that is, inline expanded
at each of their calls).

For more information on these keyword options and other ways to compile UCS
programs for performance, refer to the programming reference manual for the
appropriate UCS language (for UCS COBOL, FORTRAN, and C).

3–252 7831 4077–009

 Application Programming in a Batch or Demand Environment

3.5.3. Linking for Batch and Demand Execution-Time

Performance
To achieve the best execution-time performance for a batch or demand program,
observe the following suggestions during linking.

3.5.3.1. Basic Static Linking Suggestions

• Statically link (@LINK) all programs.
• Use static linking to produce an object module whose banks have been merged.
This is accomplished with the following static linking command:
PROCESS FOR EXTENDED ZOOM

• Do not include PADS code in production programs. You can prevent inclusion of
PADS code by using a static linking RESOLVE command that lists the file
SYS$LIB$*EMOMRTS in the USING clause, before it lists LIBCODENAME (LCN). By
specifying this file in the USING clause, C$NPADS is included in the program
instead of PADS. C$NPADS is a PADS stub.
The following shows the required RESOLVE command:
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS., LIBCODENAME

Note that interactive PADS debugging cannot be done on a program linked in this
manner. PADS postmortem debugging is still available using a DIAG$ file.

• If your program is doing COBOL call-identifier (CALL progname.), consider using

the more-efficient LSI$RES-NAME method. Take a copy of either the LSI$RES-
NAME or LSI$RES-NAMH symbolic from the file SYS$LIB$*LINK. and edit the
source. Put the names of the procedures you may be calling into the source in
DECLARE statements. (The comments in the elements explain how to do it.)
Then MASM the resulting source element, and INCLUDE the object module in your
static links. See Section 7 for more details.

3.5.3.2. URTS$TABLES Operation

There is a URTS object module that is linked into every executable program called
URTS$TABLES. Within this object module is defined a bank whose bank-name is also
URTS$TABLES. (Often referred-to as the URTS “heap” bank.) URTS$TABLES is a
program-level bank. It defaults to starting at 060000, with an initial size of about
10,000 decimal words and with a max-limit of 0777777. It is used to hold key URTS
information on the state of the executing program, including many URTS data
structures and buffers and space for dynamic allocations. It starts at 060000 and does
not extend past 0777777 so that it can be referenced from basic mode code from
products such as PCIOS. Many things can cause space to be allocated in
URTS$TABLES, including:
• Opening files
• Using SORT
• Calling RDMS
• Using DPS

7831 4077–009 3–253

Application Programming in a Batch or Demand Environment

• Using C malloc (only if done in a TIP transaction)

• Starting up a new activity (TSKSTART and tskstart calls)
The URTS$TABLES bank will be expanded during execution as more space is needed.
If it runs out of room, other banks will be allocated and linked to the original so that
the capacity is somewhat open-ended. If the URTS$TABLES bank is expanded, or
others allocated, this will inhibit TIP “sticking” and RESTART for TIP transactions. It is
also relatively expensive for non-TIP executions if the execution time is short.
Therefore, it may be desirable when you static link your executable programs to set
the size of the URTS$TABLES bank to the maximum that your programs need, or could
possibly need. The new ClearPath 2200 machines have virtual memory and large real
memories, and it is no longer productive to attempt to keep the size of your programs
small with memory reserves just barely large enough to keep them running. If your
programs can run with URTS$TABLES at its max-limit of 0777777, then set its size
accordingly. ( 0777777 - 060000 + 1 or 0720000). Put the following statement into the
static link sources of your executable programs, after all INCLUDE and RESOLVE
statements:
SET SIZE = 0720000 FOR URTS$TABLES

Programs that use DPS may not run with this max size if it calls the basic mode MCB.
So, for DPS you might want to keep your URTS$TABLES upper limit to 0577777 or
less. This would be a size of 0577777 - 060000 + 1, or 0520000 words. (Check the
DPS documentation to see if this is necessary.) To get your URTS$TABLES at an initial
limit of 0577777, put the following static linker statement in your static link source,
after all INCLUDE statements and RESOLVE statements:
SET SIZE = 0520000 FOR URTS$TABLES

(Do not set the size of URTS$TABLES in HVTIP links, as HVTIP memory management
is done differently.)

Once the URTS$TABLES bank is expanded to its maximum limit and all space within it
has been allocated, a new bank will be allocated if more space is needed. Note that
there may be several URTS space allocations done for something such as opening a
file. If one or more buffers is obtained for opening a given file, and then a new
URTS$TABLES bank is acquired and another buffer needs to be allocated to finish
opening the file, an error will occur. This is because all the buffers needed for a
specific use such as handling of a given file must be in the same bank.

In order to keep this error from happening you must use a keyword option on the
compilation of the main program for your executable program. The keyword is
URTS$TABLES, and you give it a size which is a reserve for “same-bank” space
allocations within the URTS$TABLES bank. This reserve is used when a
URTS$TABLES allocation is done and must be in the same bank as another allocation
and the “normal” space in the bank is used up. The initial reserve is treated as an
octal number, so do not use the digits 8 or 9 in the reserve value. Here is a main
program compilation with the recommended URTS$TABLES “same-bank” reserve of
050000 words:
@UCOB COBMAIN2,,,,URTS$TABLES/50000 . Reserve 050000 words

3–254 7831 4077–009

 Application Programming in a Batch or Demand Environment

You probably should not use this option if your program is not running out of
URTS$TABLES space since putting in a “same-bank” reserve virtually guarantees that
your program will acquire another URTS$TABLES bank at runtime. You also may not
want to use this mechanism if your program uses a product that requires that
URTS$TABLES not grow past some limit such as 0577777, since the URTS runtime will
expand URTS$TABLES to 0777777 and use that space before it will acquire another
bank.

If the heap data bank space is tight, and you wish to minimize its size, you should
consider the following:
• Closing PCIOS files when you are finished using them. This releases the space
that they were using.
• Using extended mode SORT (EM SORT). This moves the major portion of space
used by SORT processing to a separate bank so that it is no longer located in the
heap data bank. The EM SORT is also much faster than the older basic mode
SORT.
• Use the "CALL RSA$INIT" routine to initially allocate all RDMS space so that it is
allocated as contiguous space.

3.5.3.3. Static Linking with RDMS 2200

When you use interpreted or embedded SQL in a batch or demand program, RDMS
acquires its work space using C malloc calls. The space comes from banks
dynamically allocated by the UCS run-time system. This space can be more efficiently
supplied by a static heap bank in your executable if you supply the TIPMALLOC
keyword option when compiling your main program. The TIPMALLOC keyword option
was intended to help TIP programs retain their TIP sticking and restart capabilities, but
it can also make batch and demand programs a bit more efficient.

7831 4077–009 3–255

Application Programming in a Batch or Demand Environment

3.5.3.4. Static Linking with DPS 2200

When you use DPS 2200 in demand or batch programs, the addition of one static
linking command can improve program performance by avoiding expansion of
URTS$TABLES during execution. During static linking, you should set the size for
URTS$TABLES to reflect its default size, plus the size obtained by calling the DPS 2200
HELPER processor.

You can do this most easily by setting the size of URTS$TABLES to a selected
maximum size according to the previous general “URTS$TABLES Operation”
discussion. However, the following older more difficult method is still valid, though
not recommended due to its complexity.

The following example shows the HELPER output for the DPS 2200 software in file
APP7*DPS that was used in the examples in this section. Noteworthy lines are
bolded.

@APP7*DPS.HELPER
HELPER 5R1 DPS5R1 DPS Helper Utility Processor 1990 Aug 02 Thu 1109:54

RES 2102,478400,28,$$TERMFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE TERMINAL FILE MUST BE 7475 TRACKS

RES 2105,200,112,$$PASSFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PASSWORD FILE MUST BE 13 TRACKS

RES 2103,5001,2016,$$PAGEFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PAGING FILE MUST BE 5627 TRACKS

** IF ONE EXECFILE CONTAINS THE TERMINAL, PASSWORD AND PAGING FILE,

THE SIZE OF THE EXECFILE MUST BE 13115 TRACKS

RES 2108,126000,28,ALT$SCRNFILE,ALT$SCRNFILE,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS

RES 2109,126000,28,FORMS,FORMS,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS

DPS MEMORY USAGE REQUIREMENTS

ACOB, FTN, PL1 -

RUNTIME BLOCK SIZE: 9902 DECIMAL WORDS
D$DEF BLOCK SIZE: 9956 DECIMAL WORDS

UCS - RUNTIME BLOCK SIZE: 10048 DECIMAL WORDS

UCS - D$DEF BLOCK SIZE: 9984 DECIMAL WORDS
UCS - PARAM BLOCK SIZE: 5376 DECIMAL WORDS
UCS/INTERFACE data bank size requirements:
DYNAMIC link without D$DEFs 15424 DECIMAL WORDS
DYNAMIC link with D$DEFs 25408 DECIMAL WORDS
STATIC link without D$DEFs 10048 DECIMAL WORDS

3–256 7831 4077–009

 Application Programming in a Batch or Demand Environment

STATIC link with D$DEFs 20032 DECIMAL WORDS

.
. (additional lines)
.

Using this output, do the following:

1. In the HELPER output, locate the information with the following title:
UCS/INTERFACE data bank size requirements:

2. Below this are four lines of output. The third and fourth lines apply to static
linking:
• If D$DEF routines are used in the program, refer to the fourth line.
• Otherwise, refer to the third line.

3. Take the size shown on the appropriate line and use it in a static linking SET SIZE
command, as follows:
SET SIZE = SIZE + dps-helper-size FOR URTS$TABLES

where dps-helper-size is the size indicated in the HELPER output.

For this example, assuming the program does not use D$DEF routines, the following
command would be used:
SET SIZE = SIZE + 10048 FOR URTS$TABLES

Note that the SET SIZE command must

• Follow the RESOLVE command
• Precede the use of a PROCESS command

7831 4077–009 3–257

Application Programming in a Batch or Demand Environment

3.5.3.5. Setting the Initial Size of the ALS

During static linking, set the initial size of the activity-local stack (ALS) so that
expansion of the ALS does not occur during program execution.
The ALS is where all UCS automatic program storage resides. The upper limit of the
ALS is set by the Exec at 0677777. The initial size is currently 010000 by default. Note
that the ALS grows downwards, from high addresses towards lower addresses.
Automatic storage is used internally by the UCS Runtime System and externally by
certain user-defined variables. All the UCS languages (UCS COBOL, UCS FORTRAN,
and UCS C) allow the programmer to define storage as automatic:
• In UCS COBOL, all WORKING-STORAGE is automatic and is placed on the ALS, if
the PROGRAM-ID statement includes the INITIAL clause.
• In UCS C, all storage defined as automatic is always placed on the ALS.
• In UCS FORTRAN, local procedure-level variables are allocated on the ALS if
− the variable is not declared as STATIC, is not in COMMON, and does not have
a DATA statement on it, and
− the MIN-DBANK keyword option is used on the compilation of the FORTRAN
program.
Since there is plenty of memory available on the newer ClearPath machines, it is
recommended that you simply set the initial size of the ALS to a fairly large size and
then not worry about it. An initial size of 0400000 should be sufficient for most
programs. It is not recommended that you set it to the full maximum size of 0700000,
since then its lower limit would overlap that of basic mode code and some programs
may no longer operate. You should not therefore set an initial size of over 0600000.
Put the following statement in the static link of your executable program to set it to
the recommended 0400000:
SET ALS_INIT_SIZE = 0400000

3–258 7831 4077–009

Section 4
Linking to Application Groups by Using
Library Search Chains

This section discusses topics relating to the use of application groups with the
Universal Compiling System.

4.1. Application Groups

An application group is a partitioning of system software, data files, user programs,
their associated messages, and their executions. The purpose of application group
partitioning is to create multiple working environments. These working environments
act as independent recoverable systems on a single OS 2200 system. Currently, there
can be up to 64 different application groups on one system.

Such application groups can share the services of some system software products,
such as the following:
• The Executive system
• Compilers
• The Linking System
• Interactive Processing Facility (IPF 1100)

However, each application group acts as an independent, isolated system. Each

application group
• Is configured with the operating system
• Has its own
− System files
− Database files
− Caching memory
− Integrated Recovery Utility (IRU) history file
− Step control periodic savefile
− Audit trail
− Message retention files

7831 4077–009 4–1

Linking to Application Groups by Using Library Search Chains

• Includes a copy of one or more of the following Unisys software products:

− MCB
− DPS 2200
− The UDS suite of products
These software products are application-group-dependent software products.

A site can do either of the following:

• Place all of its business applications into one application group.
• Isolate different business applications and their associated database files and
programs into separate application groups.

Access to application group files is controlled within the application group. This allows
you to isolate sensitive data by placing it in its own application group.

For more information on application groups, see the Universal Database Control
Configuration Guide.

4.2. Overview of Linking to Application Groups

You must link a program or transaction that uses application-group-dependent system
software to the system software in the appropriate application group. Such a
program or transaction executes only within the application group; it can access only
database files that are within that application group.

You link a program or transaction to the appropriate application group by using a

library search chain. A library search chain (LSC) is a list of files (or other library search
chain names representing files) searched by the system to locate a desired unit of
software. The Subsystem Definition Processor (@SSDP) is used to define library
search chains, using DEFINE LSC and SEARCH commands:
• DEFINE LSC command
Specifies the name of the library search chain being defined.

• SEARCH command
Specifies the files or other library search chains represented by the library search
chain name in the preceding DEFINE LSC command. These are the files and other
library search chains searched for a unit of software when that library search chain
is used.

4–2 7831 4077–009

 Linking to Application Groups by Using Library Search Chains

Currently, there can be up to 64 different application groups on one system. To make

linking to application groups as easy as possible for you, the system sets up library
search chains for your use. This process works as follows:
1. In each of 64 files named SYS$LIB$*APP$n (where n represents one of the 64
application group numbers), the system sets up a library search chain for linking to
one of the 64 application groups. These library search chains are set up as part of
the installation of the Linking System.
2. In the element SYS$*DATA$.SSDEF$, the system sets up other library search
chains that define which products are in each application group. These library
search chains are set up as each product is installed.
3. Before executing your program or transaction, you specify use of the desired
library search chain by using the following statement:
@USE LINK$PF,SYS$LIB$*APP$n.

where n represents the application group number.

4. Together, the library search chains in the file SYS$LIB$*APP$n. and the element
SYS$*DATA$.SSDEF$ ensure the program or transaction is linked to the system
software in the correct application group.

The following figure represents this process:

SYS$LIB$*APP$1.

LSCs for
Linking to
Application
Group 1
SYS$*DATA$.SSDEF$
SYS$LIB$*APP$2.
LSCs That Program or
LSCs for Define Which Transaction
Program or @USE LINK$PF., Linking to Products Are Linked to a
Transaction SYS$LIB$*APP$n. Application in Which Particular
Group 2 Application Application
Groups Group

SYS$LIB$*APP$64.

LSCs for
Linking to
Application
Group 64

Figure 4–1. Using Library Search Chains to Link to Application Groups

7831 4077–009 4–3

Linking to Application Groups by Using Library Search Chains

Note: DPS 2200 is the only application-group-dependent product that does not use
this process. Therefore, you must handle library search chains for DPS 2200
yourself. Refer to 4.5 for information on this process.

The following subsections briefly describe how to use the appropriate library search
chain to link programs and transactions to a particular application group so the
interface software for MCB, DPS 2200, and the UDS suite of software are all from the
same application group.

For optional information on how the system sets up these library search chains for
your use, see 4.6.

Note that all examples in this manual that use application-group-dependent software
products use the library search chains described in this section.

4.3. Dynamically Linking to Application Groups

This subsection describes how to dynamically link a program to the system software
in an application group.

Before executing a UDS program that uses dynamic linking, you must specify use of a
library search chain that accesses the desired application group. This ensures that the
system uses the UDS interface software appropriate for that application group.
Specify use of the library search chain using the following statement:
@USE LINK$PF,SYS$LIB$*APP$n.

where n represents the application group number.

As an example, a dynamic link to application group 7 would use the following

runstream:
@USE LINK$PF,SYS$LIB$*APP$7.
@XQT qual*file.om

where qual*file.om is the user program to be dynamically linked and executed, using
the software in application group 7. Note that if any of the programs use embedded
or module SQL, those programs must have been compiled for this application group
with an APPLICATION/appname keyword option. ESQL programs are targeted for a
specific application group at compilation time. See the discussion on "Portable
Embedded and Module Language SQL Programs" in 3.2.2.10.

4–4 7831 4077–009

 Linking to Application Groups by Using Library Search Chains

4.4. Statically Linking to Application Groups

This subsection describes how to statically link a program or transaction to the system
software in an application group.

Before statically linking a program or transaction that uses UDS, MCB, or both, you
must specify use of a library search chain that accesses the desired application group.
This ensures that the system uses the UDS and/or MCB interface software
appropriate for that application group. Specify use of the library search chain using
the following statement:
@USE LINK$PF,SYS$LIB$*APP$n.

where n represents the application group number.

As an example, a static link to application group 7 would use the following runstream:
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK,S ,qual*file.zoom
.
. (@LINK commands)
.
@EOF

where qual*file.zoom is the user program to be produced by static linking, using the
software in application group 7. Again, note that if any of the programs use
embedded or module SQL, those programs must have been compiled for this
application group with an APPLICATION/appname keyword option.

4.5. Building and Using Search Chains That Include

DPS 2200
This subsection describes how to build and use library search chains for application
groups that include DPS 2200 software.

4.5.1. Building DPS 2200 Library Search Chains

If your site wishes to link to DPS 2200 software residing in an application group, you
must create new library search chains for that application group. These library search
chains must ensure that the file containing the desired version of DPS 2200 is included
in the library search chain for the desired application group.

Example
As an example, assume the following:
• A site wishes to include DPS 2200 in its library search chain for application group
7.
• This copy of DPS 2200 resides in the file APP7*DPS.

7831 4077–009 4–5

Linking to Application Groups by Using Library Search Chains

The following runstream would be used for this example:

(1) @CAT,P SYS$LIB$*APP$7DPS.
(2) @SSDP,I SYS$LIB$*APP$7DPS.SSDEF$
(3) DEFINE LSC DPS$LIB
(3) SEARCH APP7*DPS.
(4) DEFINE LSC ACTIVE$APP
(4) SEARCH APP$7
(5) @EOF

Explanation
1. Creates a file to contain the new library search chains for DPS$LIB, for application
group 7.
2. Calls SSDP, which defines the library search chains. The library search chains will
reside in the element SYS$LIB$*APP$7DPS.SSDEF$. The I option writes a source
copy of the input commands to the file specified in the @SSDP statement.
3. Redefines DPS$LIB to represent the DPS 2200 software residing in file APP7*DPS.
(The system initially defined DPS$LIB when you installed DPS 2200 in
SYS$LIB$*DPS.)
4. Defines application group 7 as the active application group, that is, the one to be
linked to when these library search chains are used.
5. Begins SSDP processing.

Output
The preceding runstream produces the following output:

*REMARK(CLAR) 2190: Item 2 of the FaE names LSC APP$7 which has not been
defined.
END SSDP. 1 Clarification remark(s).

This message is expected because SSDP does not check SYS$*DATA$.SSDEF$ to see
if the library search chain APP$n (APP$7 in this example) is defined.

4.5.2. Using DPS 2200 Library Search Chains

After you have built the required library search chains, you can use them to link a user
program or transaction to the appropriate application group. Specify use of the library
search chains described in 4.5.1 with the following statement. (Note that this example
is for application group 7):
@USE LINK$PF,SYS$LIB$*APP$7DPS.

When you statically link a program or transaction that uses DPS 2200 library search
chains in this way, the following @LINK command is not required in the static link:
INCLUDE APP7*DPS.UCS/INTERFACE,.EMCEBEP$$DPS

4–6 7831 4077–009

 Linking to Application Groups by Using Library Search Chains

4.6. How the System Sets Up Library Search

Chains for Application Groups
This subsection describes how the system sets up library search chains for application
groups. This information is optional and is of most use to site administrators.

For complete information on defining and using library search chains, see the Linking
System Programming Reference Manual.

4.6.1. Library Search Chains in SYS$*DATA$.SSDEF$

At installation time, SOLAR creates library search chains that control how to link to
Unisys products. These library search chains reside and are maintained in the element
SYS$*DATA$.SSDEF$. For complete information on SYS$*DATA$.SSDEF$, see the
Linking System Programming Reference Manual.

4.6.1.1. LSCs in SYS$*DATA$.SSDEF$ That Define Software in an

Application Group
The system automatically defines library search chains in SYS$*DATA$.SSDEF$ that
represent each of the 64 application groups. This occurs at the time the Linking
System is installed. The names of these library search chains are APP$1, APP$2, ...,
APP$7, APP$8,...APP$64.

Other library search chains represent the file into which an application-group-
dependent software product is installed. For example
• The library search chain MCB$APP1 represents the file containing the version of
MCB installed into application group 1.
• The library search chain DMS$APP7 represents the file containing the version of
DMS 2200 installed into application group 7.

As MCB, DMS 2200, RDMS 2200, or SFS 2200 is installed into an application group, the
system updates the library search chain for that application group so that it includes
the library search chain that represents the file into which that version of the product
has been installed.

For example, when DMS 2200 is installed into application group 7, the system updates
the library search chain for application group 7 (APP$7) so that it includes the library
search chain that represents the file into which that version of DMS 2200 has been
installed (DMS$APP7). In this way, the library search chain for the application group
will represent all of the files containing products installed into that application group.

Note: DPS 2200 is the only application-group-dependent product that does not
update these library search chains; therefore, you must do so yourself. Refer to 4.5
for information on this process.

Example 4–1 shows an example of a portion of SYS$*DATA$.SSDEF$ that defines the

library search chains for application groups 1, 2, 3, and 7.

7831 4077–009 4–7

Linking to Application Groups by Using Library Search Chains

(1) DEFINE LSC APP$1

SEARCH $LOCAL
SEARCH DMS$APP1
SEARCH RSA$APP1
(2) DEFINE LSC APP$2
SEARCH $LOCAL
(3) DEFINE LSC APP$3
SEARCH $LOCAL
SEARCH DMS$APP3
SEARCH RSA$APP3
SEARCH SFS$APP3
SEARCH MCB$APP3
.
. (more statements)
.
(4) DEFINE LSC APP$7
SEARCH $LOCAL
SEARCH DMS$APP7
SEARCH RSA$APP7
SEARCH SFS$APP7
SEARCH MCB$APP7
.
. (more statements)
.

Example 4–1. LSCs in SYS$*DATA$.SSDEF$ That Define Software in an

Application Group

Explanation
1. DMS 2200 and RDMS 2200 have been installed in application group 1. (RSA
represents RDMS 2200.)
2. None of the application-group-dependent products have been installed in
application group 2.
3. DMS 2200, RDMS 2200, SFS 2200, and MCB have been installed in application
group 3.
4. DMS 2200, RDMS 2200, SFS 2200, and MCB have been installed in application
group 7.

4.6.1.2. LSCs in SYS$*DATA$.SSDEF$ That Define the Active

Application Group
The library search chain ACTIVE$APP represents the active application group, that is,
the application group to which a program or transaction will be statically or
dynamically linked. ACTIVE$APP represents the active application group because the
system includes it in the library search chain for UCS$EMUSER, a special library search
chain automatically attached by the compiler to references to application group
software. (For information on UCS$EMUSER, refer to the Linking System
Programming Reference Manual.)

4–8 7831 4077–009

 Linking to Application Groups by Using Library Search Chains

The application group whose library search chain name is included in the library search
chain for ACTIVE$APP becomes the active application group (the one linked to). For
example, if ACTIVE$APP includes the library search chain name for application group 7
(APP$7), application group 7 is the active application group.

When the Linking System is installed, application group 3 is automatically defined as

the active application group. That is, SYS$*DATA$.SSDEF$ sets ACTIVE$APP equal to
APP$3; whenever the definition of ACTIVE$APP in SYS$*DATA$.SSDEF$ is used,
programs will link to application group 3 by default.

Example 4–2 shows the default definition of ACTIVE$APP in SYS$*DATA$.SSDEF$:

(1) DEFINE LSC UCS$EMUSER

SEARCH $LOCAL
SEARCH ACTIVE$APP
.
.
.
(2) DEFINE LSC ACTIVE$APP
SEARCH APP$3

Example 4–2. LSCs in SYS$*DATA$.SSDEF$ That Define the Active Application

Group

Explanation
1. UCS$EMUSER is a library search chain name attached by the compiler to all
references to user programs unknown to the compiler (including references to
application group software). The system places the following in the library search
chain for UCS$EMUSER:
• $LOCAL
$LOCAL is a system-defined default library search chain representing the file
containing the main program.

• ACTIVE$APP
ACTIVE$APP represents the active application group because it is in the library
search chain for UCS$EMUSER.

2. Application group 3 (APP$3) is specified as the active application group. Thus,

when a reference to application group software occurs, the definition of
UCS$EMUSER causes application group 3 to be linked to.
Note: In SB5R2, SOLAR allows the default active application group, represented by
ACTIVE$APP, to be changed. This is accomplished using the SOLAR configuration
SGS DEFAULT_APPLICATION_GROUP. Refer to the SOLAR End Use Reference
Manual for more information.

7831 4077–009 4–9

Linking to Application Groups by Using Library Search Chains

4.6.2. Library Search Chains in SYS$LIB$*APP$n.SSDEF$

The system sets up special application group library search chains that allow you to
link a program or transaction to the software in a particular application group. These
library search chains are set up as part of the installation of the Linking System.

Each application group has an associated file containing the library search chain for
that application group. The names of these files all have the following format:
SYS$LIB$*APP$n

where n represents the application group number. The element name is always
SSDEF$.

As an example, the following table shows the file.element name containing the library
search chains for application groups 1, 3, and 7, along with the definition of the library
search chains for each one.

Application
Group File.Element Name Library Search Chain

1 SYS$LIB$*APP$1.SSDEF$ DEFINE LSC ACTIVE$APP

SEARCH APP$1
3 SYS$LIB$*APP$3.SSDEF$ DEFINE LSC ACTIVE$APP
SEARCH APP$3
7 SYS$LIB$*APP$7.SSDEF$ DEFINE LSC ACTIVE$APP
SEARCH APP$7

4–10 7831 4077–009

 Linking to Application Groups by Using Library Search Chains

Example 4–3 describes how these library search chains work, using application group
7 as an example.

(1) DEFINE LSC ACTIVE$APP

(2) SEARCH APP$7

Example 4–3. LSC in SYS$LIB$*APP$7.SSDEF$

Explanation
1. This command defines the library search chain for ACTIVE$APP (which represents
the active application group).
2. This command specifies that the library search chain representing application
group 7 is used for the active application group (in other words, it defines
application group 7 as the active application group).

4.6.3. Specifying Use of Application Group LSCs

You can link to an application group by using the SYS$LIB$*APP$n file containing the
library search chains for that application group. To do this, give this file the @USE
name of LINK$PF. The system then uses a library search chain defined in the SSDEF$
element of that file, instead of the one defined in SYS$*DATA$.SSDEF$.

This same process is described in 4.2 through 4.5.

The files that contain the library search chains for the application groups are described
in 4.6.2.

For example, to link to application group 7, merely specify the following:

@USE LINK$PF,SYS$LIB$*APP$7.

This causes the following to occur:

1. The definition of ACTIVE$APP in SYS$LIB$*APP$7.SSDEF$ is used (APP$7), rather
than the definition in SYS$*DATA$.SSDEF$ (APP$3). Refer to Example 4–2 and
Example 4–3.
2. SYS$*DATA$.SSDEF$ defines APP$7 as representing the files containing the
application-group-dependent software located in application group 7. Refer to
Example 4–1.

Thus, the program or transaction is linked to the system software in application group
7. Again, note that if any of the programs use embedded or module SQL, those
programs must have been compiled for this application group with an
APPLICATION/appname keyword option. Doing an @USE of LINK$PF is not sufficient
to change the targeted application group for ESQL programs.

7831 4077–009 4–11

Linking to Application Groups by Using Library Search Chains

4–12 7831 4077–009

Section 5
Application Programming in a TIP
Environment

This section discusses topics relating to application programming using standard TIP
transactions.

All examples in Section 5 show UCS COBOL and UCS C transactions. Unless
otherwise indicated, the same techniques also apply to UCS FORTRAN TIP
transactions.

5.1. Basic Information for TIP Transaction

Programming
TIP transactions must be statically linked zero overhead object modules (ZOOM).

This subsection covers the following topics about creating TIP ZOOMs:
• Coding, compiling, and establishing the TIP environment for standard TIP
transaction programs
• Linking for functional testing
The information in this subsection is a foundation for understanding later subsections.

One central example is used throughout this subsection. It is expanded upon as new
topics are discussed. Figure 5–1 illustrates the TIP transaction sequence for this
example.

Figure 5–1. Standard TIP Transaction—Generic

7831 4077–009 5–1

Application Programming in a TIP Environment

In this example
1. The transaction code xxxTRX followed by an employee number represents the
transaction input.
2. xxxTIP is scheduled and execution begins.
3. xxxTIP does the following:
a. Reads the employee number input.
b. Validates the employee number.
c. Moves the employee number to the output message.
d. Sends the output message to the terminal that initiated the transaction
execution.
e. Terminates the transaction execution.
In the actual examples, the string xxx is replaced with either "DPS" or "MCB,"
depending upon which function calls are being used in the example. The examples
describe any differences that exist between using DPS 2200 functions or MCB
functions.

Examples in Section 5 show UCS COBOL and UCS C transactions. Except where
noted, everything discussed regarding these examples also applies to UCS FORTRAN.

5.1.1. Coding TIP Transactions

UCS programming supports the following host languages for TIP transactions:
• COBOL
• FORTRAN
• C

Table 5–1 shows the interfaces supported for these host languages.

Table 5–1. Transaction Processing Interfaces from UCS

Languages

UCS COBOL UCS FORTRAN UCS C

DPS 2200 DPS 2200 DPS 2200

MCB MCB MCB
Non- Non-message- Non-message-handling primitives
message- handling primitives
handling
primitives
DMS 2200 DMS 2200
RDMS 2200 RDMS 2200 RDMS 2200
Interpreter Interpreter SQL Interpreter SQL
SQL

5–2 7831 4077–009

 Application Programming in a TIP Environment

Table 5–1. Transaction Processing Interfaces from UCS

Languages

UCS COBOL UCS FORTRAN UCS C

Embedded Module SQL Embedded SQL
SQL
SFS 2200 SFS 2200 SFS 2200
Relative Direct access Binary access
access (Direct SDF) (Direct SDF)
(Direct SDF)
Indexed
access
(MSAM)
PCIOS PCIOS PCIOS
FCSS FCSS FCSS

When using TIP transactions

• DPS 2200 functions are supported for UCS COBOL, UCS FORTRAN, and UCS C.
• MCB functions are supported for all host languages.
• Most non-message-handling primitives are supported for all host languages.
• The COMPOOL message-buffering primitives are not supported in UCS
programming for any language.
• DMS 2200, the network/hierarchical database model, is supported for UCS COBOL
and UCS FORTRAN only.
• UCS COBOL, UCS FORTRAN, and UCS C host languages can access the relational
database model RDMS 2200 using interpreted SQL.
• UCS COBOL and UCS C have an embedded SQL interface for the relational
database model RDMS 2200.
• UCS FORTRAN can access the relational database module RDMS 2200 using
module language SQL.
• All host languages can access the conventional shared file model SFS 2200.
• All host languages support access to PCIOS files.
• All host languages support access to FCSS files.

7831 4077–009 5–3

Application Programming in a TIP Environment

5.1.1.1. Using DPS 2200 Functions

DPS 2200 provides a simple CALL interface to perform its work.

DPS 2200 supports transactions written in UCS COBOL, UCS FORTRAN, and UCS C.

The code used to call DPS 2200 is the same in UCS programming as it was in non-UCS
programming. The same DPS 2200 software and forms files can be used in both
environments simultaneously.

5–4 7831 4077–009

 Application Programming in a TIP Environment

UCS DPS 2200 TIP transactions can use either COMPOOL or MCB message buffering,
depending on
• The VALTAB STATUS (STA) keyword setting
• The availability of the MCB software
• The designation of MCB message buffering in the CMS 1100 configuration

If all of the following are true, DPS 2200 uses MCB message buffering:
• STA,J is specified in the VALTAB entry.
• MCB software is available.
• MCB message buffering is designated in CMS 1100.

If no J is specified on the STA keyword, then DPS 2200 uses COMPOOL message
buffering.

For more information on DPS 2200 coding, refer to the DPS 2200 Run-Time
Programming Reference Manual.

5.1.1.2. Using MCB Functions

The same MCB system software can be used in both UCS and non-UCS programming,
simultaneously.

UCS COBOL, UCS FORTRAN, and UCS C all support calls to MCB functions. MCB
functions can be directly called from all UCS TIP transactions.

7831 4077–009 5–5

Application Programming in a TIP Environment

The generic call syntax for these MCB calls is as follows:

UCS COBOL
CALL 'MCB$ENT'USING mcb-packet, mcb-status,
msg-buffer, multi-dest-list.

UCS FORTRAN
CALL MCB$ENT(mcb_packet, mcb_status, msg_buffer, multi_dest_list)

UCS C
mcb_ent(&mcb_packet, &mcb_status, &msg_buffer, &multi_dest_list);

Notice that these calls to MCB differ from their non-UCS counterparts. They include
two additional optional parameters:
• msg-buffer, msg_buffer, MSG_BUFFER
Identifies the storage area into which messages are read, and from which
messages are sent by the transaction. For UCS COBOL, this parameter eliminates
the need for the ASCII COBOL CLOCTE call (which sets up this buffer's address).
• multi-dest-list, multi_dest_list, MULTI_DEST_LIST
Provides a simple method for identifying a multiple-destination list of position
identifiers (PID). For UCS COBOL, this parameter eliminates the need for the ASCII
COBOL CLOCTE call (which sets up the buffer's address).

Transactions that use MCB functions require the following:

• Declarations of the MCB functions
• Allocation of storage space for the MCB packet
• MCB error message handling buffers
• In some cases, a message buffer

5–6 7831 4077–009

 Application Programming in a TIP Environment

To aid the UCS programmer in coding these, the MCB release tape includes precoded
sample UCS COBOL and UCS FORTRAN procedures for these buffers. The two
elements containing these procedures are found in the MCB installation file. They are
also found in the Unisys-supplied system procedure file SYS$LIB$*PROC$. They have
the following names:

Language Procedure Name

UCS COBOL MCBDEF-UCOB

UCS FORTRAN MCBDEF-UFTN

For UCS C, the following #include statement provides the definitions for the MCB
information. This element is found in the C include file.
#include <mcb.h>

For more information on MCB coding, refer to the MCB Programming Reference
Manual.

5.1.1.3. Using the Non-Message-Handling Primitives

UCS programming supports the following list of non-message-handling primitives for
COBOL, FORTRAN, and C:
• CONECT and DISCON
• COMMIT and ROLLBACK
• ALL FCSS file handling functions
• The TIMER primitives for scheduling transaction execution at a future time:
TIMABS, TIMDEL, TIMREL, TIMUPA, and TIMUPR
• The execution-option-indicator primitives: UOPAND, UOPGET, and UOPTOR

UCS does not support

• The COMPOOL message-handling primitives
• The KONS primitives

7831 4077–009 5–7

Application Programming in a TIP Environment

Primitive coding has not changed in UCS, except for the function names for the UCS
COBOL version.

Previous Name UCS Name

CCONET CONECT
CDISCN DISCON
CCMMIT COMMIT
CRLBAK ROLLBACK
CFCSS FCSS
CUOPND UOPAND
CUOPGT UOPGET
CUOPTR UOPTOR
CTMABS TIMABS
CTMDEL TIMDEL
CTMREL TIMREL
CTMUPA TIMUPA
CTMUPR TIMUPR

UCS COBOL still supports the previous name of each of these calls in transactions;
however, when you code new UCS transactions or upgrade existing transactions to
UCS, it is recommended that you use the new name.

New TIP primitive procedures for UCS COBOL and UCS FORTRAN that require no
special keyword options are available as of SB4. The new procedure names are
USYSDF and UCMPDF. They can be found in TIP$*TIPLIB$.

For UCS C, the following #include statement provides the definitions for the TIP
primitives. This element is found in the C include file.
#include <tip.h>

For more information on TIP primitives, refer to the Transaction Processing

Programming Reference Manual.

5–8 7831 4077–009

 Application Programming in a TIP Environment

5.1.1.4. Using the COBOL INITIAL Clause

The COBOL INITIAL clause is part of the PROGRAM-ID statement. The following is an
example of the COBOL INITIAL clause:
PROGRAM-ID. xxxTIP INITIAL.

In the TIP environment, the COBOL INITIAL clause automatically initializes all data
defined with the VALUE clause, every time the transaction program containing the
INITIAL clause is called.

5.1.1.5. UCS Language Coding Considerations

The programming reference manual for each UCS language includes a section on
transaction processing. This section gives specific information about using that
language in the TIP environments.

These documents are as follows:

• COBOL Compiler Programming Reference Manual Volume 2
• FORTRAN Compiler Programming Reference Manual Volume 2
• C Compiler Programming Reference Manual Volume 2

5.1.1.6. Setting Up a TIP Transaction

In TIP processing, the end user enters a transaction code at the terminal or
workstation. This transaction code is identified by a precoded entry known as a
VALTAB entry. Entering the transaction code causes the transaction to be scheduled;
this in turn causes the transaction program to be loaded, and execution to begin.

The transaction program can schedule another transaction through

• A conversational link
• A pass-off message

Coding TIP VALTABs

Each transaction has at least one VALTAB entry defining its storage location and
execution time options.

Setting up a transaction VALTAB entry is the same in UCS programming as in non-UCS

programming. For a detailed description of the format of a VALTAB entry, refer to the
Transaction Processing Administration and Operations Reference Manual.

The following example shows the VALTAB entry for the example transaction program
DPSTIP:
904 NAM,DPSTIP ACT,DPSTRX PRG,3 STF,0 STA,J QPR,1 OPT,TV
904 REC,Z AUD,7 PRT,PR

7831 4077–009 5–9

Application Programming in a TIP Environment

The following example shows the VALTAB entry for the example transaction program
MCBTIP:
924 NAM,MCBTIP ACT,MCBTRX PRG,3 STF,0 STA,J QPR,1 OPT,TV
924 REC,Z AUD,7 PRT,PR

A brief definition of the VALTAB keywords used in these examples follows:

904 and 924

Identify a unique number for the VALTAB entry. The number is required at the
start of each line for the VALTAB entry.
NAM,xxxxxx

Identifies the program name.

ACT,xxxxxx

Identifies the transaction code.

PRG,3
Identifies the Program Type as reentrant. UCS TIP transactions can also have values
of
1 Self-destructive
2 Self-initializing
4 Online-batch
5 HVTIP (See Section 6 for information about HVTIP transactions.)

STF,0
Sets the Standard File number to denote the use of SUPUR files and the SUPUR
utility. UCS transactions cannot use the online files. SUPUR files must be used
instead. SUPUR files offer better performance and online update capability than
the standard TIP online files.

STA,J
Denotes that MCB message buffering will be used if the Communication
Management System (CMS 1100) is configured for MCB message buffering and
the MCB software is available.

QPR,1
Specifies the location in the input queuing tree structure where input requests are
to be queued for this transaction program.

REC,Z
Denotes that this is a recoverable step.

AUD,7
Identifies the audit trail number (application group number).

5–10 7831 4077–009

 Application Programming in a TIP Environment

PRT,PR
Identifies the transaction printer queue.

OPT,TV
Allows the TIPDIAG$ file to be created for diagnostics upon termination.
(TIPTRACE must also be set to ON in the FLAGBOX to receive a TIPDIAG$ file.)
The use of the options ROPL allows MCB to use a reduced output path length
(ROPL) for nonrecoverable output messages.

Using SUPUR Files

All UCS transaction programs ready for execution must be stored in special TIP files
known as SUPUR files. The SUPUR utility
• Sets up SUPUR files
• Loads the transaction program ZOOMs into the SUPUR files

The DPS 2200 standard TIP transaction (DPSTIP) and the MCB standard TIP transaction
(MCBTIP) used in the examples in this section both use the same SUPUR file. The
SUPUR file is TIP file number 810, which is associated with Executive file
QUAL*TIPSUPUR.

For detailed information on how to set up and handle SUPUR files, refer to the
Transaction Processing Administration and Operations Reference Manual.

5.1.2. Compiling TIP Transaction Programs

Compiling a TIP transaction program is no different from compiling any other UCS
program. Predefined DPS form procedures generated for COBOL have only one 01
level, thus assuring the allocation of contiguous storage without the use of any special
keyword options.
• The DPS 2200 system procs are placed in the Unisys-supplied system proc file,
SYS$LIB$*PROC$. Therefore, no special @USE ...$PF statement is required when
compiling UCS COBOL or UCS FORTRAN programs using DPS 2200 functions. The
compiler always searches the system proc file.
• The UCS C procs are added to the system proc file (SYS$LIB$*PROC$) when a
mode C install is used for SYS$LIB$*DPS.
• MCB procs for UCS COBOL and UCS FORTRAN are placed in the system proc file
SYS$LIB$*PROC$, which is supplied by Unisys.

7831 4077–009 5–11

Application Programming in a TIP Environment

Figure 5–2 illustrates compilation of a UCS COBOL, FORTRAN, or C transaction

program using DPS 2200 functions. (Notice that the output of the compilation is an
object module element called DPSTIP/COMP.)

Figure 5–2. Compilation of a UCS Transaction Program Using DPS 2200 Functions

Figure 5–3 illustrates compilation of a UCS COBOL, C, or FORTRAN transaction

program using MCB functions. (Notice that the output of the transaction program
compilation is an object module element called MCBTIP/COMP.)

5–12 7831 4077–009

 Application Programming in a TIP Environment

MCB MCB
Proc or Proc

SYS$LIB$*PROC$. qual*ucstst.

MCB
@UCOB . . . . Interface
UCS MCB or
Transaction @UCOB . . . . ,,,COMPAT
Source or
Code @UFTN . . . .
or UCS MCB
qual*ucstst.MCBTIP @UC . . . . Object
Module

qual*ucstst.MCBTIP/COMP
002327

Figure 5–3. Compilation of a UCS Transaction Program Using MCB Functions

5.1.3. Basic Static Linking of TIP Transaction Programs

The following subsections present basic information on how to statically link TIP
transaction programs. The basic static linking described here permits function testing
of the transaction program. Once the functional requirements are satisfied, you
should relink the transaction program for performance.

All TIP transaction programs must be statically linked TIP ZOOMs. The following
subsections show how to create TIP ZOOMs with static linking.

5.1.3.1. Basic Static Linking for a TIP Transaction Program

The following subsections describe
• A generic static linking runstream for transaction programs
• The specific static linking runstreams for the example transaction programs
DPSTIP and MCBTIP

7831 4077–009 5–13

Application Programming in a TIP Environment

Generic Static Linking Runstream for a TIP Transaction Program

Example 5–1 shows a generic static linking runstream for a TIP transaction program.

(1) @USE LINK$PF.,SYS$LIB$*APP$n

(2) @LINK ,QUAL*FILE.TIPPRG
(3) INCLUDE QUAL*FILE.TIPPRG/COMP
(4) INCLUDE QUAL*DPSFILE.UCS/INTERFACE,.EMCBEP$$DPS
(5) RESOLVE ALL REFERENCES USING LIBCODENAME
(6) PROCESS FOR EXTENDED FAST LOAD
(7) DELETE ALL DEFINITIONS EXCEPT START$
(8) @EOF

Example 5–1. Generic Static Linking Runstream for a TIP Transaction Program

Explanation
1. This statement ensures that the transaction program is statically linked using the
system software located in the desired application group. (It ensures that the
library search chain for the correct application group is used.)
Replace n in "SYS$LIB$*APP$n" with the desired application group number. As an
example, use the following statement for application group number 7:
@USE LINK$PF.,SYS$LIB$*APP$7

This statement thus identifies the desired MCB interface software and the UDS
interface software; therefore, you do not need to use static linking INCLUDE
commands specifying the specific MCB and UDS product files. The desired files
are indicated by the library search chain.
For a complete discussion of how these library search chains are created and
used, see Section 4.
2. This statement calls the Linking System LINK Processor. The output TIP ZOOM to
be created is named QUAL*FILE.TIPPRG.
3. This command supplies the compiler-generated object module for the transaction
program as input to static linking.
4. This command supplies the appropriate interface object modules for transaction
programs that use DPS 2200. (The SYS$LIB$*APP$n application group library
search chains supplied by Unisys do not supply DPS 2200 interface information.)
A site may update the application group library search chains supplied by Unisys
so that they include the DPS 2200 interface information for that application group.
Then this INCLUDE command is not necessary (see 4.5).
5. This command resolves external references, including those to the UCS Runtime
System library.

5–14 7831 4077–009

 Application Programming in a TIP Environment

6. This command serves two purposes:

• It implicitly causes extensive bank merging, thus producing an efficient object
module.
• It specifies the type of object module to be produced. In this example, the
Linking System will attempt to create a FAST LOAD zero overhead object
module (FAST LOAD ZOOM). A FAST LOAD ZOOM is created if the Linking
System can merge the static link input into no more than four banks whose
total (collective) size is no more than 262K words. If the Linking System
cannot create a FAST LOAD ZOOM, a standard ZOOM is created and the
following warning message is supplied:
*WARNING (LINK 687)* The Linking System could not create a ZOOM
that conforms to the FAST LOAD format restriction of four banks or
less. This is due to incompatibilities in the attributes (e.g.
merge order, mode, locality) of certain banks, which prevent them
from being merged. Such merging is required to reduce the number
of banks that are output. The ZOOM that is created will be of the
standard form.

All standard transactions should request FAST LOAD ZOOM processing

because this causes extra bank merging to occur even if a FAST LOAD ZOOM
cannot be created.
However, it also merges URTS$TABLES with other DATA banks.
(URTS$TABLES is normally NOT merged with other DATA banks.) If this
causes the available space in URTS$TABLES to be insufficient to meet the
needs of your transaction, then another URTS$TABLES bank may be allocated.
Either the expansion of URTS$TABLES or acquiring another bank will cause
your transaction to lose TIP “sticking” and RESTART. If this occurs you may
want to try a regular ZOOM (OUTPUT ZOOM) instead of a FAST LOAD ZOOM
(OUTPUT FAST LOAD) and see then if your transaction retains its TIP “sticking”
and RESTART capabilities.
A FAST LOAD ZOOM is required by the SUPUR FAST LOAD process. (The
COPY,F SUPUR command.) If you do not have a FAST LOAD format ZOOM,
you should use the SUPUR COPY,A command instead.
7. This command deletes all entry point definitions except the starting address of the
transaction program.
8. This statement ends static linking.

Specific Transaction Program Static Linking Examples

The following static linking runstream is used to link DPSTIP:

@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK ,QUAL*UCSTST.DPSTIP
INCLUDE QUAL*UCSTST.DPSTIP/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

7831 4077–009 5–15

Application Programming in a TIP Environment

The following static linking runstream is used to link MCBTIP:

@USE LINK$PF.,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.MCBTIP
INCLUDE QUAL*UCSTST.MCBTIP/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

5.1.4. Examples of TIP Transaction Programs

Two examples are shown in this subsection:
The first example uses COBOL and DPS 2200 functions.
The second example uses COBOL and MCB functions.

Each example is composed of the following general components:

1. Source listing of the transaction program
2. Partial source listing of the MCBPKT-UCOB routine (MCB example only)
3. A source listing of a runstream to set up, compile, and link the example
transaction (for example, with an @START or @ADD statement)
4. The execution of the source runstream (output saved by an @BRKPT statement)
5. An example of execution of the transactions

5.1.4.1. Example Using DPS 2200 Functions

The following figure illustrates the example in this subsection. This example uses
• COBOL and DPS 2200 functions.
• A DPS 2200 predefined form.
This is the same predefined form used in 3.3.1, "Example of a DPS 2200 Form
Definition," and 3.3.2, "Examples of the Working Storage Definition for a DPS 2200
Form." Refer to these other subsections for the form layout and working storage
definition.

Figure 5–4. Example TIP Transaction Using DPS 2200

5–16 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of the Transaction Program (DPSTIP)

Example 5–2 shows the complete source listing of the transaction program DPSTIP. In
this example, this program resides in element QUAL*UCSTST.DPSTIP. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSTIP INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE DPS COBOL TRANSACTION PROGRAM - DPSTIP *
* *
* initializes with DPS *
* reads the input employee number *
* opens the DPS form *
* moves the employee number to the form *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.

Example 5–2. Source Listing of the Transaction (QUAL*UCSTST.DPSTIP)

7831 4077–009 5–17

Application Programming in a TIP Environment

COPY GETFIELD.
COPY SENDERROR.
SCREEN-DSPLYIND-50.
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL INIT'USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE TRANSACTION CODE
************************************************************
DPS-FREE-FORMAT-READ1.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-FREE-FORMAT-READ2.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.
IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5 OR
GETFIELD-TYPE NOT EQUAL 3
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* OPENS THE FORM TO BE SENT AS THE OUTPUT MESSAGE
************************************************************

Example 5–2. Source Listing of the Transaction (QUAL*UCSTST.DPSTIP)

5–18 7831 4077–009

 Application Programming in a TIP Environment

DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* SENDS THE FORM AS THE OUTPUT MESSAGE
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM TERMINATION-PARA.
************************************************************
* TIP TERMINATION WITH DPS
* TERMINATION OF THE PROGRAM
************************************************************
TERMINATION-PARA.
CALL 'D$TERM'USING DPS-STATUS.
STOP RUN.
*
*

************************************************************
* RETURNS AN ERROR MESSAGE IF THE INPUT MESSAGE WAS IN ERROR
************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR'USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*
*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG'USING DPS-STATUS.

Example 5–2. Source Listing of the Transaction (QUAL*UCSTST.DPSTIP)

7831 4077–009 5–19

Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–3 shows the source listing of a runstream used to set up, compile, and link
the standard TIP transaction shown in this example. Noteworthy lines are bolded.

@ . ***
@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A STANDARD TIP DPS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS
@UCOB QUAL*UCSTST.DPSTIP,.DPSTIP/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSTIP'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK ,QUAL*UCSTST.DPSTIP
INCLUDE QUAL*UCSTST.DPSTIP/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.

Example 5–3. Runstream to Set Up, Compile, and Link COBOL DPS TIP Transaction
Program

5–20 7831 4077–009

 Application Programming in a TIP Environment

@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.

@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
904 NAM,DPSTIP ACT,DPSTRX PRG,3 STF,0 QPR,1 STA,J OPT,TV
904 REC,Z AUD,7 PRT,PR
@EOF

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810

Example 5–3. Runstream to Set Up, Compile, and Link COBOL DPS TIP Transaction
Program

7831 4077–009 5–21

Application Programming in a TIP Environment

@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY DPSTIP FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810
EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–3. Runstream to Set Up, Compile, and Link COBOL DPS TIP
Transaction

5–22 7831 4077–009

 Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5-4 shows the execution of the source runstream used to set up, compile,
and link this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13R1J (931108 0108:39) 1994 Feb 16 Wed 1439:22
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 3.766 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A STANDARD TIP DPS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
I:002333 USE complete.
@UCOB QUAL*UCSTST.DPSTIP,.DPSTIP/COMP,,,NO-OPTIONS
UCOB- 6R2(940210) LSS- 8R2 (940209) 940216 14:39:32
SIZES: CODE(EM6): 928 DATA: 96
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSTIP'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DPSTIP
LINK 5R2 (940207 1635:57) 1994 Feb 16 Wed 1440:24
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***

Example 5–4. Execution of Source Runstream—COBOL DPS TIP Transaction

Program

7831 4077–009 5–23

Application Programming in a TIP Environment

@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940216 1440:57
*VALCHG M

KEYWORDS FOR VALTAB FIELDS

LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

904 NAM,DPSTIP ACT,DPSTRX PRG,3 STF,0 QPR,1 STA,J OPT,TV

904 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 904 TRANSACTION CODE: DPSTRX
NAM: DPSTIP RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TVZ IND: NONE SET PCT: 1
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
*** CHANGED VALTAB ***
PROGRAM NUMBER: 904 TRANSACTION CODE: DPSTRX
NAM: DPSTIP RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV:

Example 5–4. Execution of Source Runstream—COBOL DPS TIP

Transaction Program

5–24 7831 4077–009

 Application Programming in a TIP Environment

STA: J OPT: TV IND: NONE SET PCT: 1

AUD: 7 REC: Z QPR: 1 MAS: NONE SET

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940216 1440:58
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940216 1440:58
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940216 1440:58
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/16/94 14:40:59 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 14:40:59 16 FEB 94
TP REGISTER FINISHED 14:40:59 16 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC

Example 5–4. Execution of Source Runstream—COBOL DPS TIP

Transaction Program

7831 4077–009 5–25

Application Programming in a TIP Environment

TP RESERVE STARTED 14:40:59 16 FEB 94

TP RESERVE FINISHED 14:40:59 16 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-16 1441:00
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY DPSTIP FROM QUAL*UCSTST TO 810
Program DPSTIP copied to TIP file 810 in ZOOM fast-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: DPSTIP TIP Program File: 810

Element Format: ZOOM fast-load Created on: 94-02-16 1440:50
Record Number: 2 Area Size: 250 records
Start Address: 400004001003, Program Mode: 3rd, NA, 64-Gran
Program Number: 904
Bank Index: 3,1 2,5 2,6 2,4
Bank Type: EM, D-bank EM, D-Bank BM,D-Bank EM, I-Bank
Lower Limit: 050000 060000 100000 001000
Bank Size: 000160 027531 300000 011037
GAP/SAP: RW/RW RW/RW ERW/ERW ER/ER

Processing completed successfully for LIST

EXIT
SUPUR Processor Terminated. Date-Time: 94-02-16 1441:10
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–4. Execution of Source Runstream—COBOL DPS TIP

Transaction Program

5–26 7831 4077–009

 Application Programming in a TIP Environment

Execution of the Standard TIP Transaction in This Example

The following screens show an execution of the standard TIP transaction described
previously. User input is bolded.

>DPSTRX 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME:

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY: $
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

7831 4077–009 5–27

Application Programming in a TIP Environment

5.1.4.2. Example Using MCB Functions

The following figure illustrates the example in this subsection. This example uses
COBOL and MCB functions.

Figure 5–5. Example TIP Transaction Using MCB Functions

5–28 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of the Transaction Program (MCBTIP)

Example 5–5 shows the complete source listing of the transaction program MCBTIP.
In this example, the program resides in element QUAL*UCSTST.MCBTIP. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. MCBTIP INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE MCB COBOL TRANSACTION PROGRAM - MCBTIP *
* *
* initializes with MCB *
* reads the input employee number *
* moves the employee number to the output message *
* sends the output message *
* terminates with MCB *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER
SYMBOLIC CHARACTERS EXT IS 4.
******************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* WORK AREA BUFFERS
************************************************************
01 IN-TEXT PIC X(60) VALUE SPACES.
01 TRAN-CODE PIC X(6) VALUE SPACES.
************************************************************
* BUFFER TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-TEXT VALUE SPACES.
02 EMPLOYEE-NUMBER PIC X(5).
02 FILLER PIC X(55).
************************************************************
* UNSTRING COUNTER
************************************************************
01 EMP-COUNT PIC 99 VALUE ZERO.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

7831 4077–009 5–29

Application Programming in a TIP Environment

01 ERROR-MESSAGE PIC X(85) VALUE SPACES.

*
01 ERR-MISSING-INPUT.
* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 24
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
*
01 INVALID-EMPLOYEE-NUMBER.
* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 24
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
02 FILLER PIC X(28) VALUE SPACES.
************************************************************
* MCB PROCEDURE
************************************************************
COPY MCBPKT-UCOB.
************************************************************
* OUTPUT MESSAGE BUFFER
************************************************************
01 OUTPUT-MSG.
* Cursor to home
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'e'.
* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 1 Column 1 - Start protection
02 FILLER PIC 1(9) BINARY-1 VALUE 31.
02 FILLER PIC X(2) VALUE SPACES.
02 FILLER PIC X(1) VALUE '%'.
02 FILLER PIC X(1) VALUE '3'.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

5–30 7831 4077–009

 Application Programming in a TIP Environment

* Line 1
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(33)
VALUE '******** INDIVIDUAL DATA ********'.
* Line 3
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"!'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(17) VALUE 'EMPLOYEE NUMBER: '.
02 OUT-EMP-NUMBER PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"='.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(6) VALUE 'NAME: '.
02 OUT-IND-FIRST-NAME PIC X(12) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"P'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-IND-LAST-NAME PIC X(20) VALUE SPACES.
* Line 6
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '%$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(30)
VALUE '*** DEPARTMENT INFORMATION ***'.
* Line 7
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '&-'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(6) VALUE 'NAME: '.
02 OUT-DEPT-NAME PIC X(24) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '&O'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(8) VALUE 'NUMBER: '.
02 OUT-DEPT-NO PIC X(4) VALUE SPACES.
* Line 8
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

7831 4077–009 5–31

Application Programming in a TIP Environment

02 FILLER PIC X(2) VALUE "')".

02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(10) VALUE 'FUNCTION: '.
02 OUT-DEPT-DESCRIPTION PIC X(56) VALUE SPACES.
* Line 10
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE ")$".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(23)
VALUE '*** JOB INFORMATION ***'.
* Line 11
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "*,".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(7) VALUE 'TITLE: '.
02 OUT-JOB-TITLE PIC X(20) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "*O".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(17) VALUE 'YEARLY SALARY: $ '.
02 OUT-JOB-SALARY PIC X(5) VALUE SPACES.
* Line 12
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "+)".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(10) VALUE 'FUNCTION: '.
02 OUT-JOB-DESCRIPTION PIC X(50) VALUE SPACES.
* Line 15
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '.$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPORTS-ACTION PIC X(71) VALUE SPACES.
* Line 16
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '/3'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME1 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '/>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE1 PIC X(13) VALUE SPACES.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

5–32 7831 4077–009

 Application Programming in a TIP Environment

* Line 17
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '03'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME2 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '0>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE2 PIC X(13) VALUE SPACES.
* Line 18
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '13'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME3 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '1>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE3 PIC X(13) VALUE SPACES.
* Line 20
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '3$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILDREN PIC X(16) VALUE '*** CHILDREN ***'.
* Line 21
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '43'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-FIRST-NAME1 PIC X(12) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '4@'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-LAST-NAME1 PIC X(20) VALUE SPACES.
* Line 22
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '53'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-FIRST-NAME2 PIC X(12) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

7831 4077–009 5–33

Application Programming in a TIP Environment

02 FILLER PIC X(2) VALUE '5@'.

02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-LAST-NAME2 PIC X(20) VALUE SPACES.
* Line 23
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '63'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-FIRST-NAME3 PIC X(12) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '6@'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILD-LAST-NAME3 PIC X(20) VALUE SPACES.
* Line 24 Column 1 - Cursor position
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
* Line 24 Column 1 - End protection
02 FILLER PIC 1(9) BINARY-1 VALUE 31.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC X(1) VALUE '%'.
02 FILLER PIC X(1) VALUE '0'.
*
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH MCB
* READ OF THE INPUT MESSAGE
************************************************************
MCB-INITIALIZATION.
MOVE SPACES TO P-TRXBUFF.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 1 TO P-BIT2.
MOVE 2 TO P-NODE.
MOVE 1 TO P-LVL.
MOVE P-TRINIT TO P-FUNC.
MOVE 1820 TO P-LENGTH.
MOVE 63 TO P-AUX.
CALL 'MCB$ENT'USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
************************************************************
* EXTRACTING THE EMPLOYEE NUMBER FROM THE INPUT MESSAGE
* VALIDATING THE EMPLOYEE NUMBER
************************************************************
MCB-INPUT-MESSAGE-ANALYSIS.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

5–34 7831 4077–009

 Application Programming in a TIP Environment

MOVE P-TRXBUFF (P-AUXTXN:60) TO IN-TEXT.

UNSTRING IN-TEXT DELIMITED BY ALL SPACES
INTO TRAN-CODE, EMPLOYEE-TEXT COUNT IN EMP-COUNT.
IF EMPLOYEE-TEXT (1:1) = EXT
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE IF EMP-COUNT NOT EQUAL 5 OR
EMPLOYEE-NUMBER IS NOT NUMERIC
MOVE EMPLOYEE-TEXT (1:10) TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.

************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE OUTPUT MESSAGE
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO OUT-EMP-NUMBER.
************************************************************
* SENDS THE OUTPUT MESSAGE
************************************************************
MCB-SEND-MESSAGE.
MOVE 0 TO P-MCB-STATUS.
MOVE P-SENDD TO P-FUNC.
MOVE 0 TO P-ID.
MOVE 769 TO P-LENGTH.
MOVE 1 TO P-START.
MOVE 4 TO P-AUX.
MOVE 0 TO P-FLAGS.
MOVE 1 TO P-BIT0.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, OUTPUT-MSG.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
************************************************************
* TIP TERMINATION WITH MCB
* PROGRAM TERMINATION
************************************************************
TERMINATION-PARA.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
STOP RUN.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

7831 4077–009 5–35

Application Programming in a TIP Environment

*
*
************************************************************
* RETURNS AN ERROR MESSAGE IF THE INPUT MESSAGE WAS IN ERROR
************************************************************
INVALID-INPUT-PARA.
MOVE 0 TO P-MCB-STATUS.
MOVE P-SENDD TO P-FUNC.
MOVE 0 TO P-ID.
MOVE 85 TO P-LENGTH.
MOVE 1 TO P-START.
MOVE 4 TO P-AUX.
MOVE 0 TO P-FLAGS.
MOVE 1 TO P-BIT0.
CALL 'MCB$ENT'USING P-MCB-PACKET, P-MCB-STATUS,
ERROR-MESSAGE.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
*
*
************************************************************
* ONLY EXECUTED WHEN A MCB ERROR OCCURS
************************************************************
MCB-ERROR-EXIT.
DISPLAY '********* MCB ERROR *********'UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = 'P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = 'P-ERRCODE UPON PRINTER.
DISPLAY 'ERROR CODE Q3 = 'P-ERRCODEQ3 UPON PRINTER.
DISPLAY 'ERROR CODE Q4 = 'P-ERRCODEQ4 UPON PRINTER.
MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 5–5. Source Listing of the Transaction (QUAL*UCSTST.MCBTIP)

5–36 7831 4077–009

 Application Programming in a TIP Environment

Partial Source Listing of the MCBPKT-UCOB Routine

Example 5–6 shows a partial source listing of the MCBPKT-UCOB routine. This is a
version of the procs contained in the MCBDEF-UCOB element from the MCB release
tape that has been tailored for this example. (For more information, refer to 5.1.1.2,
"Using MCB Functions.")

In this example, the routine resides in element QUAL*UCSTST.MCBPKT-UCOB.

Noteworthy lines are bolded.

MCBPKT-UCOB PROC
/
*
* Sample MCB procedure for use in UCOB transactions
*
************************************************
** TRANSACTION CODE BUFFER **
************************************************
01 P-TRXCODE PIC X(6).
************************************************
** INPUT BUFFER **
** This buffer will hold a 24 X 80 screen. **
** The maximum size is PIC X(262143). **
************************************************
01 P-INMSG PIC X(1920).
**************************************************
** BUFFER ADDRESS **
**************************************************
01 P-MSG-LENGTH PIC 9(10) BINARY.
01 P-SAVEPID PIC 1(18) BINARY-1.
01 P-TRXBUFF PIC X(1920) VALUE SPACES.
**************************************************
** MCB ERROR STATUS RETURN **
**************************************************
01 P-MCB-STATUS.
02 P-STATBIT PIC S9(5) BINARY.
02 P-ERRCODE PIC 9(5) BINARY.
02 P-ERRCODEQ REDEFINES P-ERRCODE.
04 P-ERRCODEQ3 PIC 1(9) BINARY-1.
04 P-ERRCODEQ4 PIC 1(9) BINARY-1.
/
*************************************************
** FUNCTION CODES FOR INTERFACES TO THE MCB **
*************************************************
* TRINIT VALUE 2. initialize
* TERM VALUE 10. terminate

Example 5–6. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

7831 4077–009 5–37

Application Programming in a TIP Environment

* COMMIT VALUE 11. Commit

* ROLBAK VALUE 12. rollback
* RECV VALUE 13. read input
* INPREL VALUE 14. release input
* CANCELL VALUE 15. cancel output
* SENDD VALUE 16. store output
* PASOFF VALUE 17. store passoff
* CHKPT VALUE 18. store checkpoint
* ENQUE VALUE 19. enqueue message
* AUDIT VALUE 20. audit
* DISREC VALUE 21. discrete receive
*****************************************************************
01 P-TRINIT PIC 9(2) BINARY VALUE 2.
01 P-TERM PIC 9(2) BINARY VALUE 10.
01 P-COMMIT PIC 9(2) BINARY VALUE 11.
01 P-ROLBAK PIC 9(2) BINARY VALUE 12.
01 P-RECV PIC 9(2) BINARY VALUE 13.
01 P-INPREL PIC 9(2) BINARY VALUE 14.
01 P-CANCELL PIC 9(2) BINARY VALUE 15.
01 P-SENDD PIC 9(2) BINARY VALUE 16.
01 P-PASOFF PIC 9(2) BINARY VALUE 17.
01 P-CHKPT PIC 9(2) BINARY VALUE 18.
01 P-ENQUE PIC 9(2) BINARY VALUE 19.
01 P-AUDIT PIC 9(2) BINARY VALUE 20.
01 P-DISREC PIC 9(2) BINARY VALUE 21.
/
*************************************************
** PACKET FOR MCB CALL **
*************************************************
01 P-MCB-PACKET.
02 P-WORD00.
* P-FUNC function code
* P-OFF data offset
* P-ID msg identifier
03 P-FUNC PIC 9(2) BINARY.
03 P-OFF PIC 9(2) BINARY.
03 P-ID PIC 9(5) BINARY.
02 P-WORD01.
* P-LENGTH request char count
* P-BUFF data buffer address
03 P-LENGTH PIC 9(5) BINARY.
03 P-BUFF PIC 9(5) BINARY.
02 P-WORD02.
* P-START start char point
* P-RTN return point

Example 5–6. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

5–38 7831 4077–009

 Application Programming in a TIP Environment

03 P-START PIC 9(5) BINARY.

03 P-RTN PIC 9(5) BINARY.
02 P-WORD03.
* P-AUX aux data
* P-FAC facilities
* P-VER version
03 P-AUX PIC 1(6) BINARY-1.
03 P-FAC PIC 1(6) BINARY-1.
03 P-VER PIC 1(6) BINARY-1.
****
03 P-FLAGS.
.
. (additional statements)

Example 5–6. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

7831 4077–009 5–39

Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–7 shows the source listing of the runstream used to set up, compile, and
link the standard TIP transaction shown in this example. Noteworthy lines are bolded.

@ . ***
@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A STANDARD TIP MCB COBOL TRANSACTION PROGRAM
@ . ***
@UCOB QUAL*UCSTST.MCBTIP,.MCBTIP/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'MCBTIP'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, THE APPLICATION
@ . *** GROUP SEVEN SEARCH CHAIN FOUND IN SYS$LIB$*APP$7.SSDEF$ IS
@ . *** SPECIFIED USING AN "@USE LINK$PF" COMMAND.
@ . *** THiS SEARCH CHAIN SETS ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.MCBTIP
INCLUDE QUAL*UCSTST.MCBTIP/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
924 NAM,MCBTIP ACT,MCBTRX PRG,3 STF,0 QPR,1 STA,J OPT,TV
924 REC,Z AUD,7 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY

Example 5–7. Runstream to Set Up, Compile, and Link—COBOL MCB TIP
Transaction Program

5–40 7831 4077–009

 Application Programming in a TIP Environment

OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY MCBTIP FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810

Example 5–7. Runstream to Set Up, Compile, and Link—COBOL MCB TIP
Transaction Program

7831 4077–009 5–41

Application Programming in a TIP Environment

EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–7. Runstream to Set Up, Compile, and Link—COBOL MCB TIP
Transaction Program

Execution of the Source Runstream

Example 5-8 shows the execution of the source runstream used to set up, compile,
and link this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** UCOB COMPILE OF A STANDARD TIP MCB COBOL TRANSACTION PROGRAM
@ . ***
@UCOB QUAL*UCSTST.MCBTIP,.MCBTIP/COMP,,,NO-OPTIONS
UCOB- 6R2(940210) LSS- 8R2 (940209) 940216 15:28:24
SIZES: CODE(EM6): 1027 DATA: 431
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'MCBTIP'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, THE APPLICATION
@ . *** GROUP SEVEN SEARCH CHAIN FOUND IN SYS$LIB$*APP$7.SSDEF$ IS
@ . *** SPECIFIED USING AN "@USE LINK$PF" COMMAND.
@ . *** THIS SEARCH CHAIN SETS ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.MCBTIP
LINK 5R2 (940207 1635:57) 1994 Feb 16 Wed 1528:57
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***

Example 5–8. Execution of Source Runstream—COBOL MCB TIP

Transaction Program

5–42 7831 4077–009

 Application Programming in a TIP Environment

@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940216 1529:20
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

924 NAM,MCBTIP ACT,MCBTRX PRG,3 STF,0 QPR,1 STA,J OPT,TV

924 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 924 TRANSACTION CODE: MCBTRX
NAM: MCBTIP RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
*** CHANGED VALTAB ***
PROGRAM NUMBER: 924 TRANSACTION CODE: MCBTRX
NAM: MCBTIP RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940216 1529:21
OFF BTLOADING
OFF STICKING

Example 5-8. Execution of Source Runstream—COBOL MCB TIP

Transaction Program

7831 4077–009 5–43

Application Programming in a TIP Environment

ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940216 1529:21
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940216 1529:22
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/16/94 15:29:22 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 15:29:22 16 FEB 94
TP REGISTER FINISHED 15:29:22 16 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 15:29:22 16 FEB 94
TP RESERVE FINISHED 15:29:22 16 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR

Example 5-8. Execution of Source Runstream—COBOL MCB TIP

Transaction Program

5–44 7831 4077–009

 Application Programming in a TIP Environment

PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-16 1529:23
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY MCBTIP FROM QUAL*UCSTST TO 810
Program MCBTIP copied to TIP file 810 in ZOOM fast-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE

LIST ALL FROM 810

Program Name: MCBTIP TIP Program File: 810

Element Format: ZOOM fast-load Created on: 94-02-16 1529:12
Record Number: 2 Area Size: 217 records
Start Address: 400004001066, Program Mode: 3rd, NA,64-Gran
Program Number: 924
Bank Index: 3,1 2,5 2,6 2,4
Bank Type: EM, D-bank EM, D-bank BM,D-bank EM,I-bank
Lower Limit: 050000 060000 100000 001000
Bank Size: 000672 027531 300000 006467
GAP/SAP: RW/RW RW/RW ERW/ERW ER/ER
Processing completed successfully for LIST
EXIT
SUPUR Processor Terminated. Date-Time: 94-02-16 1529:30
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5-8. Execution of Source Runstream—COBOL MCB TIP

Transaction Program

7831 4077–009 5–45

Application Programming in a TIP Environment

Execution of the Standard TIP Transaction in This Example

The following screens show an execution of the standard TIP transaction described
previously. User input is bolded.

>MCBTRX 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME:

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY: $
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

5–46 7831 4077–009

 Application Programming in a TIP Environment

5.2. TIP Transactions That Access UDS Databases

This subsection augments the basic information covered in 5.1. It describes how to
code, compile, and link standard TIP transaction programs that access UDS databases.
This subsection uses simple UCS COBOL and UCS C examples throughout.

UCS TIP transactions support the interface to the UDS database models in the
following ways:
• UCS COBOL and UCS FORTRAN support the interface to DMS 2200 databases in
TIP.
• UCS COBOL, UCS FORTRAN, and UCS C all provide access to RDMS 2200
databases in TIP. UCS COBOL and UCS C support both the embedded SQL and
the interpreter SQL interfaces. UCS FORTRAN supports both module language
SQL and the interpreter SQL interfaces.
• UCS COBOL, UCS FORTRAN, and UCS C all provide access to SFS 2200 databases
in TIP.

For each database interface, there are requirements that are unique to the standard
TIP environment. The following pages discuss these requirements.

7831 4077–009 5–47

Application Programming in a TIP Environment

Table 5–2 is a summary of the UDS interfaces supported by the UCS host languages in
TIP transactions.

Table 5–2. UDS Interfaces from UCS Languages

in TIP Transactions

UCS COBOL UCS FORTRAN UCS C

DMS 2200 DMS 2200

RDMS 2200 RDMS 2200 RDMS 2200
Interpreter Interpreter SQL Interpreter SQL
SQL Module SQL Embedded SQL
Embedded
SQL
SFS 2200 SFS 2200 SFS 2200
Relative Direct SDF Binary
(Direct SDF) (Direct SDF)
Indexed
(MSAM)

The UCS interfaces to UDS databases are designed to be compatible with older UDS
interfaces. UCS and non-UCS programs can share the same
• UDS software
• Database files

Both UCS and non-UCS programs also support the same functional capabilities. In
other words, UCS programs and non-UCS programs with the same data manipulation
language command syntax can access the same database files using the same UDS
software, simultaneously. As far as compatibility is concerned, very little has changed
for the applications programmer.

5–48 7831 4077–009

 Application Programming in a TIP Environment

To describe how UCS TIP transaction programs access these UDS data models, the
following subsections show three very simple databases, one for each of the data
models:
• DMS 2200
• RDMS 2200
• SFS 2200

The three databases shown are interrelated by the common denominator of an

individual. The universe for this database is the company for which the individual
works. The individual is uniquely identified in each database by his or her employee
number. Also, to make the example simple, the following is assumed:
• The individual's spouse does not work for the same company.
• No individual has more than three children.
• No individual participates in more than three sports.

The databases store the following information about the employee:

• The DMS 2200 database contains information about the individual's current job.
• The RDMS 2200 database contains information about the individual's home and
family.
• The SFS 2200 database contains information about the individual's participation in
company sports.

7831 4077–009 5–49

Application Programming in a TIP Environment

For each database model, a subsection describes each of the following processes:
• Creating the database
• Loading information into the database
• Accessing information from the database

All of the examples use alternate application group 7 (UDS$$SVN).

5.2.1. Using DMS 2200 Databases

UCS TIP transaction programming first supported DMS 2200 software in SB3R1. UCS
COBOL and UCS FORTRAN are the supported host languages.

The following subsections describe the steps involved in creating and accessing a
DMS 2200 database using UCS TIP transaction programs. They discuss
• DMS 2200 schemas

• DMS 2200 subschemas

• DML application TIP transaction programs

5.2.1.1. DMS 2200 Schemas

A DMS 2200 schema describes a DMS 2200 database as it exists on mass storage.
The schema describes
• All record types and the data items within these record types
• The storage areas in which these record types reside
• The set relationships between these record types

The coding of a DMS 2200 schema to be used by UCS TIP transaction programs must
comply with the following conditions:
• The schema cannot contain any Fieldata data items or records.
Fieldata is not supported by any UCS compiler. Schemas that do not contain
Fieldata can be shared by both UCS and non-UCS programs.

5–50 7831 4077–009

 Application Programming in a TIP Environment

Therefore, most existing schemas built for non-UCS programs can be shared with
UCS programs. This means you do not need to recode or reprocess schemas.

• The schema cannot contain any of the following new UCS COBOL USAGE clauses
unless the schema contains the syntax SOURCE IS UCS (DMS level 17R1):
− BINARY-1
− BINARY
These USAGE clauses are currently not supported by the schema processor
(@DDL) unless SOURCE IS UCS appears in the schema (available in DMS level 17R1
and later).

• All area names, record names, data item names, set names, and database data
names must be unique. For example, a schema cannot contain a record and an
area with the same name. Also, these names must be unique within the COBOL
program.

Refer to the DMS DDL Administration, Operations, and Programming Guide for more
information on DMS 2200 schemas.

The schema used in the example for this section uses the following record and set
diagram.

7831 4077–009 5–51

Application Programming in a TIP Environment

The following is a brief description of the record types in this database:

EMPNUMBER
A direct record type that is keyed off the individual's unique employee number.

INDIVIDUAL
An indexed sequential record type that is keyed off the individual's name;
duplicates are allowed.

JOBINFO
A calc record type that is keyed off job titles; no duplicates are allowed.

DEPARTMENT
A calc record type that is keyed off department numbers; no duplicates are
allowed.

5.2.1.2. DMS 2200 Subschemas

A DMS 2200 subschema describes the part of the database that is visible to the
application program. It details the portion of the database that the application program
can reference.

UCS programs require their own subschemas, with a new HOST LANGUAGE value for
both UCS COBOL and UCS FORTRAN. For UCS COBOL, the following clause is
required:
HOST LANGUAGE IS UCS COBOL

For UCS FORTRAN, the following clause is required:

HOST LANGUAGE IS UCS FORTRAN

Remember the following requirements, in addition to the new HOST LANGUAGE

clause settings:
• When coding a UCS subschema, the applications programmer must remember
that no Fieldata characters are allowed. This means that the subschema
REDEFINES clause, if used, cannot contain either of the following:

5–52 7831 4077–009

 Application Programming in a TIP Environment

− USAGE COMP-4
− USAGE DISP-1
If the SDDL processor finds any Fieldata data definitions in the schema or the
subschema when any UCS subschema is processed, it produces no output and
prints a fatal error message.
• The T option is not permitted on the SDDL processor call. This option converts
USAGE clauses to Fieldata or ASCII, depending upon the current values of the
clauses.

When a UCS subschema is processed, the SDDL processor produces three output
elements:

The following describes these output elements:

• Object subschema
This is an absolute element used during compilation by the UCS compilers and
during execution by DMS 2200.
• S$PROC
This is a symbolic element containing information describing records and data
items. It is used by the UCS compilers while they process an INVOKE statement.
The record and data item layouts are copied from S$PROC into the program during
compilation.
• S$WORK
When a subschema contains a HOST LANGUAGE clause for a UCS language,
S$WORK is generated as an object module. You statically link S$WORK to the
transaction program (as described later in this subsection).

7831 4077–009 5–53

Application Programming in a TIP Environment

Note that if the subschema being processed includes the clause HOST LANGUAGE IS
UCS COBOL, the SDDL processor call no longer (as of DMS level 16R1) requires the F
option. The following table shows the equivalent USAGE clauses in ASCII COBOL and
UCS COBOL.

ASCII COBOL UCS COBOL

USAGE COMP USAGE BINARY

PIC 1 USAGE BINARY-1

The following example shows the SDDL processor call for the UCS COBOL example
subschema:
@UDS$$SVN*DMRMT$.SDDL,DN QUAL*UCSTST.PERSONSUBTIP,UDS$$SVN*SCHFILEXEC.PERSONSUBTIP

The HOST LANGUAGE IS UCS FORTRAN clause requires no special SDDL

processor call options. The following example shows the SDDL processor call in
this case:

@UDS$$SVN*DMRMT$.SDDL,DN QUAL*UCSTST.PERSONSUBTIP,UDS$$SVN*SCHFILEXEC.PERSONSUBTIP

Refer to the DMS SDDL Administration, Operations, and Programming Guide for
more information on DMS 2200 subschemas.

5.2.1.3. Using UDS-TIP Files

When you use DMS 2200, the following can be defined under TIP file control:
• Schema file
• Storage area files
• Subschema file

Note: Using TIP file control eliminates much Exec input/output overhead and
eliminates the need for file assignments. Therefore, it is recommended that DMS
2200 databases that will be accessed by TIP transactions be set up using TIP
schema, subschema, and storage area files. This requires setting up a TIP file for
each underlying Exec file.

Schema File
If the schema file is a TIP file, the Data Definition Language (DDL) syntax must identify
the schema as residing in a TIP file. This is accomplished by using the following clause
in the SCHEMA NAME statement:
IN TIP FILE uds-tip-file-code

For more information on coding a DMS 2200 schema that uses TIP areas, refer to the
DMS DDL Administration, Operations, and Programming Guide.

5–54 7831 4077–009

 Application Programming in a TIP Environment

Storage Area Files

If the storage areas are TIP files, you must specify the following clause in each area
definition in the DDL syntax for the schema definition:
AREA MAPS TO TIP FILE

Furthermore, the area code for each area definition in the schema must be the same
as the UDS-TIP file number of the TIP file for that area.

For more information on setting up TIP files that will hold DMS 2200 storage areas,
refer to the Repository for ClearPath OS 2200 Administration Guide.

Subschema File
If the subschema file is a TIP file, the Subschema Data Definition Language (SDDL)
syntax must identify the subschema as residing in a TIP file. This is accomplished by
using the following clause in the SUBSCHEMA NAME statement:
IN TIP FILE uds-tip-file-code

For more information on coding a DMS 2200 subschema that uses TIP areas, refer to
the DMS SDDL Administration, Operations, and Programming Guide.

5.2.1.4. Example of a DMS 2200 Database Definition

The following example shows a sample schema and subschema being set up for UCS
program use. The schema can be used by both UCS and non-UCS programs. The
subschema is for UCS COBOL host language programs. The schema file, storage area
files, and subschema file are all UDS/TIP files.

7831 4077–009 5–55

Application Programming in a TIP Environment

Source Listing of the DMS 2200 Schema

Example 5-9 shows a source listing of the schema PERSONNELTIP. The schema
resides in the element QUAL*UCSTST.PERSONNELTIP and can be used by both UCS
and non-UCS programs.

IDENTIFICATION DIVISION
SCHEMA NAME IS PERSONNELTIP IN TIP FILE 70
DATA DIVISION
DATA NAME SECTION.
01 CALC-AREA-NAME USAGE IS AREA-NAME
01 EMPNO-AREA-NAME USAGE IS AREA-NAME
01 EMPNO-AREA-KEY USAGE IS AREA-KEY
AREA SECTION.
AREA LOOKS INCLUDE QUICK-BEFORE-LOOKS AFTER-LOOKS
AREA NAME IS DEPTAREATIP
AREA CODE IS 71
MODE IS DATA
AREA MAPS TO TIP
ALLOCATE 12 PAGES
PAGES ARE 448 WORDS
CALC USES 1 CHAINS LINKED PRIOR
AREA NAME IS JOBAREATIP
AREA CODE IS 72
MODE IS DATA
AREA MAPS TO TIP
ALLOCATE 10 PAGES 2 OVERFLOW AT END
PAGES ARE 448 WORDS
CALC USES 1 CHAINS LINKED PRIOR
AREA NAME IS EMPNOAREATIP
AREA CODE IS 73
MODE IS DATA
AREA MAPS TO TIP
ALLOCATE 1000 PAGES
PAGES ARE 448 WORDS
AREA NAME IS INDAREATIP
AREA CODE IS 74
MODE IS DATA
AREA MAPS TO TIP
ALLOCATE 1000 PAGES
PAGES ARE 1792 WORDS
AREA NAME IS INDINDEXTIP
AREA CODE IS 75
MODE IS INDEX
AREA MAPS TO TIP
ALLOCATE 10 PAGES
PAGES ARE 112 WORDS

Example 5–9. Source Listing of the Schema (QUAL*UCSTST.PERSONNELTIP)

5–56 7831 4077–009

 Application Programming in a TIP Environment

RECORD SECTION.
RECORD DEPARTMENT
CODE IS 101
LOCATION MODE IS CALC DMSCALC
IN CALC-AREA-NAME
USING DEPT-NO
DUPLICATES ARE NOT ALLOWED
WITHIN DEPTAREA
MODE IS ASCII
05 DEPT-NO PIC X(4)
05 DEPT-NAME PIC X(24)
05 DEPT-DESCRIPTION PIC X(55)
RECORD JOBINFO
CODE IS 102
LOCATION MODE IS CALC DMSCALC
IN CALC-AREA-NAME
USING JOB-TITLE
DUPLICATES ARE NOT ALLOWED
WITHIN JOBAREA
MODE IS ASCII
05 JOB-TITLE PIC X(20)
05 JOB-DESCRIPTION PIC X(50)
05 JOB-SALARY PIC X(5)
RECORD EMPNUMBER
CODE IS 103
LOCATION MODE IS DIRECT EMPNO-AREA-KEY, EMPNO-AREA-NAME
WITHIN EMPNOAREA
MODE IS ASCII
05 EMP-NUMBER PIC X(5)
RECORD INDIVIDUAL
CODE IS 104
LOCATION MODE IS INDEX SEQUENTIAL
USING ASCENDING KEY IND-LAST-NAME, IND-FIRST-NAME
INDEX AREA IS INDINDEX
LINKS ARE NEXT AND PRIOR
DUPLICATES ARE NOT ALLOWED
WITHIN INDAREA
MODE IS ASCII
05 IND-LAST-NAME PIC X(20)
05 IND-FIRST-NAME PIC X(12)
SET SECTION.
SET DEPT-IND
CODE IS 201
MODE IS CHAIN
ORDER IS SORTED
OWNER IS DEPARTMENT
MEMBER IS INDIVIDUAL AUTOMATIC
LINKED TO OWNER

Example 5–9. Source Listing of the Schema (QUAL*UCSTST.PERSONNELTIP)

7831 4077–009 5–57

Application Programming in a TIP Environment

ASCENDING KEY IS IND-LAST-NAME, IND-FIRST-NAME

DUPLICATES ARE LAST
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET
SET JOB-IND
CODE IS 202
MODE IS CHAIN
ORDER IS SORTED
OWNER IS JOBINFO
MEMBER IS INDIVIDUAL AUTOMATIC
LINKED TO OWNER
ASCENDING KEY IS IND-LAST-NAME, IND-FIRST-NAME
DUPLICATES ARE LAST
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET
SET EMPNO-IND
CODE IS 203
MODE IS CHAIN
ORDER IS NEXT
OWNER IS EMPNUMBER
MEMBER IS INDIVIDUAL AUTOMATIC
SET OCCURRENCE SELECTION IS THRU CURRENT OF SET

Example 5–9. Source Listing of the Schema (QUAL*UCSTST.PERSONNELTIP)

5–58 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of the DMS 2200 Subschema

Example 5-10 shows a source listing of the subschema PERSONSUBTIP. The
subschema resides in the element QUAL*UCSTST.PERSONSUBTIP. The subschema is
for UCS COBOL host language programs.

IDENTIFICATION DIVISION
SUBSCHEMA NAME IS PERSONSUBTIP IN TIP FILE 70
OF SCHEMA PERSONNELTIP
HOST LANGUAGE IS UCS COBOL
DATA DIVISION
DATA NAME SECTION.
DATA NAMES ARE ALL
AREA SECTION.
AREAS ARE ALL
RECORD SECTION.
RECORDS ARE ALL
SET SECTION.
SETS ARE ALL

Example 5–10. Source Listing of the Subschema (QUAL*UCSTST.PERSONSUBTIP)

7831 4077–009 5–59

Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–11 shows the source listing of the runstream used to process the schema
PERSONNELTIP and the subschema PERSONSUBTIP. (This runstream could, for
example, be executed using an @START or @ADD statement.) Noteworthy lines are
bolded.

@ . ***
@ . *** ******** START OF THE DMS DATABASE DEFINITION SECTION **********
@ . ***
@ . ***
@ . *** CATALOG: SETS UP AN EXEC FILE TO HOLD THE OUTPUT OF THE DDL
@ . *** PROCESSING OF THE SCHEMA AND THE SDDL PROCESSING OF
@ . *** THE SUBSCHEMA.
@ . ***
@ . *** THE OUTPUT OF THESE PROCESSORS MUST BE PLACED IN AN EXEC
@ . *** FILE. THEY CANNOT WRITE TO A TIP FILE. LATER ANOTHER
@ . *** PORTION OF THIS RUNSTREAM WILL COPY THE DDL AND THE SDDL
@ . *** PROCESSOR OUTPUT THAT WILL BE USED DURING TRANSACTION
@ . *** EXECUTION TO THE APPROPRIATE TIP FILE.
@ . ***
@CAT,P UDS$$SVN*SCHFILEXEC.,F///1000
@ . ***
@ . ***
@ . *** CATALOG: CATALOGS THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA EXEC FILES THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-filename MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P UDS$$SVN*SCHFILETIP.,F/1000//1000
@CAT,P UDS$$SVN*DEPTAREATIP.,F/3//3
@CAT,P UDS$$SVN*JOBAREATIP.,F/3//3
@CAT,P UDS$$SVN*EMPNOAREATIP.,F/250//250
@CAT,P UDS$$SVN*INDAREATIP.,F/1000//1000
@CAT,P UDS$$SVN*INDINDEXTIP.,F/1//1
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA FILES.
@ . ***
@ . *** 2. RESERVE THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA FILES.
@ . ***

Example 5–11. Runstream to Process Schema and Subschema

5–60 7831 4077–009

 Application Programming in a TIP Environment

@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.

@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** UDS$$SVN*SCHFILETIP.
@ . ***
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** Assigned TIP-FILE-NUMBER = 2131
@ . ***
@ . *** 2200 + 1 - 2131
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR UDS$$SVN*SCHFILETIP = 70
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG UDS$$SVN*SCHFILETIP.,FIX
TREG UDS$$SVN*DEPTAREATIP.,FIX
TREG UDS$$SVN*JOBAREATIP.,FIX
TREG UDS$$SVN*EMPNOAREATIP.,FIX
TREG UDS$$SVN*INDAREATIP.,FIX
TREG UDS$$SVN*INDINDEXTIP.,FIX
RES,G 70,64000,28,,SCHFILETIP,,,WW=P,AUDIT=0,NREC
RES,G 71,12,448,,DEPTAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 72,12,448,,JOBAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 73,1000,448,,EMPNOAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 74,1000,1792,,INDAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 75,16,112,,INDINDEXTIP,,,WW=P,AUDIT=0,NREC
LFD,G 70/75
@EOF
@ . ***
@ . ***
@ . *** USE THE DDL PROCESSOR TO PRODUCE ABSOLUTE SCHEMA TABLES AND
@ . *** TO PLACE INFORMATION ABOUT THE SCHEMA IN THE REPOSITORY DATABASE.
@ . *** LATER THE OUTPUT OF THE DDL PROCESSOR WILL BE COPIED TO THE
@ . *** APPROPRIATE TIP FILE.
@ . *** THE DDL PROCESSOR CANNOT WRITE TO A TIP FILE.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
@UDS$$SVN*DMRMT$.DDL,DN QUAL*UCSTST.PERSONNELTIP,SCHFILEXEC.PERSONNELTIP
@ . ***
@ . ***
@ . *** USE THE SDDL PROCESSOR TO PRODUCE SUBSCHEMA TABLES AND TO PLACE

Example 5–11. Runstream to Process Schema and Subschema

7831 4077–009 5–61

Application Programming in a TIP Environment

@ . *** INFORMATION ABOUT THE SUBSCHEMA IN THE REPOSITORY DATABASE

@ . ***
@ . ***
@ . *** THE SDDL PROCESSOR CREATES A PROC THAT CONTAINS THE DATA DIVISION
@ . *** ENTRIES FOR THE DATABASE DATA NAMES AND THE DATABASE RECORDS THAT
@ . *** WILL BE COPIED INTO THE USER PROGRAM BY THE UCS COMPILER. AS
@ . *** PART OF THE SDDL PROCESS THIS PROC IS AUTOMATICALLY PDP'ED.
@ . ***
@ . *** NOTICE THAT THE OUTPUT OF THE SDDL PROCESSOR IS WRITTEN TO AN EXEC
@ . *** FILE. LATER THIS OUTPUT WILL BE COPIED TO THE APPROPRIATE TIP
@ . *** FILE. THE SDDL PROCESSOR CANNOT WRITE TO A TIP FILE.
@ . ***
@UDS$$SVN*DMRMT$.SDDL,DFL QUAL*UCSTST.PERSONSUBTIP,SCHFILEXEC.PERSONSUBTIP
@EOF
@ . ***
@ . ***
@ . *** COPIES THE SCHEMA AND SUBSCHEMA AFTER THE DDL AND SDDL PROCESSORS
@ . *** HAVE CREATED ABSOLUTES FROM THEIR EXEC FILE TO THE TIP FILE WHERE
@ . *** THEY ARE REQUIRED FOR TRANSACTION PROGRAMS.
@ . ***
@ . *** THE 'TPFREE'FREES AN EXEC FILE FROM TIP TO THE OS 2200 SYSTEM.
@ . *** ALL TIP FILE ASSIGNMENTS ARE RETAINED.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TPFREE UDS$$SVN*SCHFILETIP.
@EOF
@ . ***
@ . ***
@ . *** COPIES THE SCHEMA AND SUBSCHEMA ABSOLUTES FROM THE EXEC FILE
@ . *** TO THE TIP FILE.
@ . ***
@PRT,T UDS$$SVN*SCHFILEXEC.
@COPY,A UDS$$SVN*SCHFILEXEC.,UDS$$SVN*SCHFILETIP.
@PACK,P UDS$$SVN*SCHFILETIP.
@PRT,TL UDS$$SVN*SCHFILETIP.
@ . ***
@ . ***
@ . *** THE 'TPASG'ASSIGNS THE EXEC FILE BACK TO TIP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TPASG UDS$$SVN*SCHFILETIP.
LFD,G 70
@EOF
@ . ***

Example 5–11. Runstream to Process Schema and Subschema

5–62 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@ . *** USE THE INFORMATION PLACED IN THE REPOSITORY DATABASE BY THE DDL
@ . *** AND SDDL PROCESSORS TO CREATE SCHEMA AND SUBSCHEMA INFORMATION
@ . *** IN THE REPOSITORY AND PRODUCE THEIR FILE DESCRIPTION TABLES (FDTs)
@ . ***
@UDS$$SVN*UREP$ABS.DD,ES ,,APPSVN
PROCESS SCHEMA PERSONNELTIP INSTALL.
PROCESS SUBSCHEMA PERSONSUBTIP FOR SCHEMA PERSONNELTIP INSTALL.
EXIT.
@ . ***
@ . ***
@ . *** ******** END OF THE DMS DATABASE DEFINITION SECTION ***********

Example 5–11. Runstream to Process Schema and Subschema

7831 4077–009 5–63

Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5–12 shows the execution of the runstream used to process the schema and
subschema. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . ***
@ . *** ******** START OF THE DMS DATABASE DEFINITION SECTION **********
@ . ***
@ . ***
@ . *** CATALOG: SETS UP AN EXEC FILE TO HOLD THE OUTPUT OF THE DDL
@ . *** PROCESSING OF THE SCHEMA AND THE SDDL PROCESSING OF
@ . *** THE SUBSCHEMA.
@ . ***
@ . *** THE OUTPUT OF THESE PROCESSORS MUST BE PLACED IN AN EXEC
@ . *** FILE. THEY CANNOT WRITE TO A TIP FILE. LATER ANOTHER
@ . *** PORTION OF THIS RUNSTREAM WILL COPY THE DDL AND THE SDDL
@ . *** PROCESSOR OUTPUT THAT WILL BE USED DURING TRANSACTION
@ . *** EXECUTION TO THE APPROPRIATE TIP FILE.
@ . ***
@CAT,P UDS$$SVN*SCHFILEXEC.,F///1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** CATALOG: CATALOGS THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA EXEC FILES THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-FILENAME MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P UDS$$SVN*SCHFILETIP.,F/1000//1000
I:002333 CAT complete.
@CAT,P UDS$$SVN*DEPTAREATIP.,F/3//3
I:002333 CAT complete.
@CAT,P UDS$$SVN*JOBAREATIP.,F/3//3
I:002333 CAT complete.
@CAT,P UDS$$SVN*EMPNOAREATIP.,F/250//250
:002333 CAT complete.
@CAT,P UDS$$SVN*INDAREATIP.,F/1000//1000
I:002333 CAT complete.
@CAT,P UDS$$SVN*INDINDEXTIP.,F/1//1
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:

Example 5–12. Execution of Source Runstream—DMS Database Setup

5–64 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@ . *** 1. REGISTER THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA FILES.
@ . ***
@ . *** 2. RESERVE THE SCHEMA, SUBSCHEMA, AND DATABASE STORAGE
@ . *** AREA FILES.
@ . ***
@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.
@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** UDS$$SVN*SCHFILETIP.
@ . ***
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** ASSIGNED TIP-FILE-NUMBER = 2131
@ . ***
@ . *** 2200 + 1 - 2131
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR UDS$$SVN*SCHFILETIP = 70
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:17:07 FS-LEVEL FS 003
TREG UDS$$SVN*SCHFILETIP.,FIX
TP REGISTER STARTED 12:17:07 17 FEB 94
TP REGISTER FINISHED 12:17:08 17 FEB 94
TREG UDS$$SVN*DEPTAREATIP.,FIX
TP REGISTER STARTED 12:17:08 17 FEB 94
TP REGISTER FINISHED 12:17:08 17 FEB 94
TREG UDS$$SVN*JOBAREATIP.,FIX
TP REGISTER STARTED 12:17:08 17 FEB 94
TP REGISTER FINISHED 12:17:08 17 FEB 94
TREG UDS$$SVN*EMPNOAREATIP.,FIX
TP REGISTER STARTED 12:17:08 17 FEB 94
TP REGISTER FINISHED 12:17:08 17 FEB 94
TREG UDS$$SVN*INDAREATIP.,FIX
TP REGISTER STARTED 12:17:08 17 FEB 94
TP REGISTER FINISHED 12:17:09 17 FEB 94
TREG UDS$$SVN*INDINDEXTIP.,FIX
TP REGISTER STARTED 12:17:09 17 FEB 94
TP REGISTER FINISHED 12:17:09 17 FEB 94
RES,G 70,64000,28,,SCHFILETIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94

Example 5–12. Execution of Source Runstream—DMS Database Setup

7831 4077–009 5–65

Application Programming in a TIP Environment

TP RESERVE FINISHED 12:17:09 17 FEB 94

RES,G 71,12,448,,DEPTAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94
TP RESERVE FINISHED 12:17:09 17 FEB 94
RES,G 72,12,448,,JOBAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94
TP RESERVE FINISHED 12:17:09 17 FEB 94
RES,G 73,1000,448,,EMPNOAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94
TP RESERVE FINISHED 12:17:09 17 FEB 94
RES,G 74,1000,1792,,INDAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94
TP RESERVE FINISHED 12:17:09 17 FEB 94
RES,G 75,16,112,,INDINDEXTIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:17:09 17 FEB 94
TP RESERVE FINISHED 12:17:09 17 FEB 94
LFD,G 70/75
DMS AREA 70
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME SCHFILETIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 71
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 12 SIZE: 448 APPLICATION GROUP: 0
FILE NAME DEPTAREATIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 72
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 12 SIZE: 448 APPLICATION GROUP: 0
FILE NAME JOBAREATIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 73
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 1000 SIZE: 448 APPLICATION GROUP: 0
FILE NAME EMPNOAREATIP

Example 5–12. Execution of Source Runstream—DMS Database Setup

5–66 7831 4077–009

 Application Programming in a TIP Environment

PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 74
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 1000 SIZE: 1792 APPLICATION GROUP: 0
FILE NAME INDAREATIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 75
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 16 SIZE: 112 APPLICATION GROUP: 0
FILE NAME INDINDEXTIP
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USE THE DDL PROCESSOR TO PRODUCE ABSOLUTE SCHEMA TABLES AND
@ . *** TO PLACE INFORMATION ABOUT THE SCHEMA IN THE REPOSITORY DATABASE.
@ . *** LATER THE OUTPUT OF THE DDL PROCESSOR WILL BE COPIED TO THE
@ . *** APPROPRIATE TIP FILE.
@ . *** THE DDL PROCESSOR CANNOT WRITE TO A TIP FILE.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
I:002333 ASG complete.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
I:002333 USE complete.
@UDS$$SVN*DMRMT$.DDL,DN QUAL*UCSTST.PERSONNELTIP,SCHFILEXEC.PERSONNELTIP
DDL PROCESSOR LEVEL : 13R3 02-17-94 12:17:10
DMS 1100 BUILD ID 13R3

END DDL 0 WARNING 0 FATAL 0 SYNTAX

TIME: TOTAL: 00:00:05.343 CLOCK TIME: 00:00:04.250

CPU: 00:00:00.511 I/O: 00:00:03.332

CC/ER: 00:00:01.501
@ . ***
@ . ***
@ . *** USE THE SDDL PROCESSOR TO PRODUCE SUBSCHEMA TABLES AND TO PLACE
@ . *** INFORMATION ABOUT THE SUBSCHEMA IN THE REPOSITORY DATABASE
@ . ***

Example 5–12. Execution of Source Runstream—DMS Database Setup

7831 4077–009 5–67

Application Programming in a TIP Environment

@ . ***
@ . *** THE SDDL PROCESSOR CREATES A PROC THAT CONTAINS THE DATA DIVISION
@ . *** ENTRIES FOR THE DATABASE DATA NAMES AND THE DATABASE RECORDS THAT
@ . *** WILL BE COPIED INTO THE USER PROGRAM BY THE UCS COMPILER. AS
@ . *** PART OF THE SDDL PROCESS THIS PROC IS AUTOMATICALLY PDP'ED.
@ . ***
@ . *** NOTICE THAT THE OUTPUT OF THE SDDL PROCESSOR IS WRITTEN TO AN EXEC
@ . *** FILE. LATER THIS OUTPUT WILL BE COPIED TO THE APPROPRIATE TIP
@ . *** FILE. THE SDDL PROCESSOR CANNOT WRITE TO A TIP FILE.
@ . ***
@UDS$$SVN*DMRMT$.SDDL,DL QUAL*UCSTST.PERSONSUBTIP,SCHFILEXEC.PERSONSUBTIP
SDDL PROCESSOR LEVEL :
DMS 1100 BUILD ID

1 IDENTIFICATION DIVISION
2 SUBSCHEMA NAME IS PERSONSUBTIP IN TIP FILE 70
3 OF SCHEMA PERSONNELTIP
4 HOST LANGUAGE IS UCS COBOL
5 DATA DIVISION
6 DATA NAME SECTION.
7 DATA NAMES ARE ALL
8 AREA SECTION.
9 AREAS ARE ALL
10 RECORD SECTION.
11 RECORDS ARE ALL
12 SET SECTION.
13 SETS ARE ALL
END SDDL 0 WARNING 0 FATAL 0 SYNTAX

TIME: TOTAL: 00:00:05.990 CLOCK TIME: 00:00:04.519

CPU: 00:00:00.378 I/O: 00:00:02.766

CC/ER: 00:00:06.441
@PDP,CN DSF$.X$PROC/PERSONSUBTIP,PDP$$$SO$$$.S$PROC/PERSONSUBTIP
PDP 13R1J (931108 0108:39) 1994 Feb 17 Thu 1217:14
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 22 Entry Points: 2 Time: 1.196 Storage: 7070/0/7070/0106210
@FREE,A PDP$$$SO$$$.
I:002333 FREE complete.
@ . ***
@ . ***
@ . *** COPIES THE SCHEMA AND SUBSCHEMA AFTER THE DDL AND SDDL PROCESSORS
@ . *** HAVE CREATED ABSOLUTES FROM THEIR EXEC FILE TO THE TIP FILE WHERE
@ . *** THEY ARE REQUIRED FOR TRANSACTION PROGRAMS.

Example 5–12. Execution of Source Runstream—DMS Database Setup

5–68 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@ . *** THE 'TPFREE'FREES AN EXEC FILE FROM TIP TO THE OS 2200 SYSTEM.
@ . *** ALL TIP FILE ASSIGNMENTS ARE RETAINED.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:17:20 FS-LEVEL FS 003
TPFREE UDS$$SVN*SCHFILETIP.
TP FREE STARTED 12:17:20 17 FEB 94
TP FREE FINISHED 12:17:20 17 FEB 94
END FREIPS
@ . ***
@ . ***
@ . *** COPIES THE SCHEMA AND SUBSCHEMA ABSOLUTES FROM THE EXEC FILE
@ . *** TO THE TIP FILE.
@ . ***
@PRT,T UDS$$SVN*SCHFILEXEC.
FURPUR 30R7 (940125 0849:29) 1994 Feb 17 Thu 1217:21
STD#UDS$$SVN*SCHFILEXEC(1)
ABS PERSONNELTIP
ABS PERSONSUBTIP
OM S$WORK/PERSONSUBTIP
COBP S$PROC/PERSONSUBTIP(0)
@COPY,A UDS$$SVN*SCHFILEXEC.,UDS$$SVN*SCHFILETIP.
3 ABS
@PACK,P UDS$$SVN*SCHFILETIP.
END RELOCATABLE PREP. UDS$$SVN*SCHFILETIP(1) 0 REL 0 ENTRY PT(S) NO DUP(S)
END OBJECT MODULE PREP. UDS$$SVN*SCHFILETIP(1) 1 OM 1 ENTRY PT(S)
END PACK. TEXT=2,TOC=1,ABS=3
@PRT,TL UDS$$SVN*SCHFILETIP.
STD#UDS$$SVN*SCHFILETIP(1) ELEMENT TABLE
D NAME VERSION TYPE DATE TIME
PERSONNELTIP ABSOLUTE 17 FEB 94 12:17:14...
PERSONSUBTIP ABSOLUTE 17 FEB 94 12:17:18...
S$WORK PERSONSUBTIP OBJ-MODULE 17 FEB 94 12:17:18...
NEXT AVAILABLE LOCATION-
ASSEMBLER PROCEDURE TABLE EMPTY
COBOL PROCEDURE TABLE EMPTY
FORTRAN PROCEDURE TABLE EMPTY
RELOCATABLE ENTRY POINT TABLE EMPTY
PREP'D OBJECT MODULE ENTRY POINT TABLE
T NAME SEQ POS TYPE T NAME
S$PERSONSUBTIP 3 1 DATA
NON-PREP'D OBJECT MODULE ENTRY POINTS EMPTY
NO DUPLICATE OM ENTRY POINTS FOUND
@ . ***
@ . ***
@ . *** THE 'TPASG'ASSIGNS THE EXEC FILE BACK TO TIP.

Example 5–12. Execution of Source Runstream—DMS Database Setup

7831 4077–009 5–69

Application Programming in a TIP Environment

@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:17:33 FS-LEVEL FS 003
TPASG UDS$$SVN*SCHFILETIP.
TP ASSIGN STARTED 12:17:33 17 FEB 94
TP ASSIGN FINISHED 12:17:34 17 FEB 94
LFD,G 70

TIP FILE 70
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME SCHFILETIP
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USE THE INFORMATION PLACED IN THE REPOSITORY DATABASE BY THE DDL
@ . *** AND SDDL PROCESSORS TO CREATE SCHEMA AND SUBSCHEMA INFORMATION
@ . *** IN THE REPOSITORY AND PRODUCE THEIR FILE DESCRIPTION TABLES (FDTS)
@ . ***

@UDS$$SVN*UREP$ABS.DD,ES ,,APPSVN
UREP 3R2 (11/04/93 10:17:34) 02/17/94 12:17:34
1 PROCESS SCHEMA PERSONNELTIP INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA SCHEMA VERSION ABS for SCHEMA
PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA DEPTAREATIP VERSION ''for
SCHEMA PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA JOBAREATIP VERSION ''for SCHEMA
PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA EMPNOAREATIP VERSION ''for
SCHEMA PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDAREATIP VERSION ''for SCHEMA
PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDINDEXTIP VERSION ''for
SCHEMA PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4039 The PROCESS SCHEMA PERSONNELTIP is successfully completed.
2 PROCESS SUBSCHEMA PERSONSUBTIP FOR SCHEMA PERSONNELTIP INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA PERSONSUBTIP VERSION ABS for
SCHEMA PERSONNELTIP was SUCCESSFUL.
*REMARK* DSD4039 The PROCESS SUBSCHEMA PERSONSUBTIP is successfully complete
3 EXIT.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 9 )REMARKS .
@ . ***
@ . ***
@ . *** ******** END OF THE DMS DATABASE DEFINITION SECTION ***********

Example 5–12. Execution of Source Runstream—DMS Database Setup

5–70 7831 4077–009

 Application Programming in a TIP Environment

5.2.1.5. Coding UCS DML Transaction Programs

The data manipulation language (DML) provides a set of commands for accessing a
DMS 2200 database.
A UCS DML transaction program must identify a subschema that contains a HOST
LANGUAGE IS UCS clause in the INVOKE statement.

The syntax for DML commands in UCS transaction programs is identical to the syntax
supported for non-UCS transaction programs.

A UCS DML transaction program can use DPS 2200 functions, MCB functions, and TIP
primitives.

The following figure summarizes a simple UCS DML transaction program described in
the following subsections. This sample transaction program uses DPS 2200. The
program
1. Reads an employee number
2. Accesses information about that individual from the DMS 2200 database
3. Displays the data
IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDMS INITIAL.
.
.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE .....
.
.
WORKING-STORAGE SECTION.
01 EMPLOYEE-NUMBER ....
PROCEDURE DIVISION.
CALL 'D$INIT'....
CALL 'D$GETFL'....
CALL 'D$GETFL'....
CALL 'D$OPEN'....
IMPART
OPEN .... RETRIEVAL
FETCHs ....
MOVE DATA TO DPS FORM
DEPART
CALL 'D$SEND'....
CALL 'D$TERM'....
STOP RUN.

Refer to the DMS CDML Operations and Programming Reference Manual for more
information on coding UCS COBOL DML programs. Refer to the DMS FDML
Operations and Programming Reference Manual for more information on coding UCS
FORTRAN DML programs.

7831 4077–009 5–71

Application Programming in a TIP Environment

5.2.1.6. Compiling UCS DML Transaction Programs

UCS compilers directly process DML source statements, converting them into an
executable form. The UCS compilers parse both
• The host language syntax
• The DML syntax

The ASCII COBOL DML (ADML) and FORTRAN DML (FDML) preprocessors required for
non-UCS programs are not needed and no longer exist in UCS.

Since there is no preprocessing, no independent D$WORK element is created.

Instead, D$WORK is an integral part of the object module produced by the UCS
compiler.

As shown in the preceding figure, compilation of a UCS transaction program

containing DML statements involves the following steps:
1. When you compile a UCS DML transaction program, the subschema file
(UDS$$SVN*SCHFILEXEC. in the illustration) must be available to the UCS compiler.
This means that prior to calling the compiler, you must
a. Assign the subschema EXEC file
b. Attach an @USE name to the subschema EXEC file
The @USE name is required if the compilation is taking place under a project-id
different from the qualifier of the subschema file. Since the INVOKE
statement has no syntax to identify the qualifier of the subschema file, the
following occurs:
c. The compiler first looks for a file with the @USE name of the subschema file
name.

5–72 7831 4077–009

 Application Programming in a TIP Environment

d. If it does not find such a file, the compiler tries to assign the subschema file,
using the run's project-id as the subschema file's qualifier.
2. When compiling a UCS COBOL transaction program containing DML statements,
you must specify the COMPAT keyword option on the compiler call (but only if the
subschema includes items with USAGE COMP-1 or COMP-2, as of DMS level 17R1).
The COMPAT keyword option causes the compiler to interpret these as if they
were the correct COBOL 85 format.
No special keyword options are required for compilation of UCS FORTRAN DML
programs.

3. The UCS compilers access the object subschema and the S$PROC symbolic
element from the subschema file while parsing the DML syntax.
4. The output of the compiler is an object module that includes the D$WORK
information.

The following statements show how to compile the UCS COBOL DML transaction
program illustrated in this section.

@ASG,A UDS$$SVN*SCHFILEXEC.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
@UCOB,S QUAL*UCSTST.DPSDMS,QUAL*UCSTST.DPSDMS/COMP,,,;
NO-OPTIONS, NO-REMARK

7831 4077–009 5–73

Application Programming in a TIP Environment

5.2.1.7. Basic Linking Information for UCS DML Transaction

Programs
When statically linking a UCS transaction program containing DML statements, you
must specify use of a special application group library search chain by using an @USE
LINK$PF statement. This library search chain causes the Linking System to resolve
references using the DMS 2200 software for a particular application group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the DMS 2200 interface
during static linking

The following generic format shows how to specify use of the appropriate application
group library search chain:

@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program containing DML statements to the system software
in application group 7, use the following statement:

@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to DMS 2200 software would be resolved using
UDS$$SVN*D$MR.

If the DMS transaction program uses DPS 2200 functions, you can build a user-defined
library search chain that ensures that the file containing the desired version of DPS
2200 is included in the library search chain for the desired application group. How to
build this search chain for application group seven is shown in 4.5.1. If this search
chain is used, the LINK$PF statement is

@USE LINK$PF, SYS$LIB$*APP$7DPS.

For more information on these library search chains, see Section 4.

5–74 7831 4077–009

 Application Programming in a TIP Environment

Ensuring That the Linking System Finds S$WORK

When static linking a UCS transaction program containing DML statements, the Linking
System needs to locate the S$WORK object module.

You can use one of the following ways to ensure that the Linking System can locate
S$WORK:
• Explicitly supply (INCLUDE) the S$WORK object module from the subschema EXEC
file. (This method is used in the static linking example shown in "Statically Linking
a UCS DML Transaction Program," which follows.)
• Specify the file containing S$WORK in the USING clause of the RESOLVE
command.
• Set up a user-defined library search chain that searches both
− The file containing S$WORK
− The files containing the system software for the appropriate application group

Then specify an @USE LINK$PF statement to identify this library search chain.

Statically Linking a UCS DML Transaction Program

You must statically link a UCS transaction program containing DML statements. The
following steps are involved:
1. Specify use of the application group library search chain, using an @USE LINK$PF
statement.
2. Call the LINK Processor (@LINK).
3. Specify static linking commands, including commands that identify
• The program's compiler-produced object module
• The subschema's S$WORK object module

7831 4077–009 5–75

Application Programming in a TIP Environment

The output of this static link must be a zero overhead object module.

Object
Subschema

S$PROC
Symbolic
Element
@USE LINK$PF,SYS$LIB$*APP$7. S$WORK
UDS DML or Object
UCS Object @USE LINK$PF,SYS$LIB$*APP$7DPS. Module
Module @LINK
UDS$$SVN*SCHFILEXEC.

qual*progfile.om/comp
UDS DML
UCS Linked
ZOOM

qual*progfile.zoom

The following example shows how to statically link a UCS transaction program
containing DML statements, producing a zero overhead object module:

(1) @USE LINK$PF,SYS$LIB$*APP$7DPS.

(2) @LINK ,QUAL*UCSTST.DPSDMS
(3) INCLUDE QUAL*UCSTST.DPSDMS/COMP
(4) INCLUDE UDS$$SVN*SCHFILEXEC.S$WORK/PERSONSUBTIP
(5) RESOLVE ALL REFERENCES USING LIBCODENAME
(6) PROCESS FOR EXTENDED FAST LOAD
(7) DELETE ALL DEFINITIONS EXCEPT START$
(8) @EOF

Explanation:
1. This statement ensures that the program is statically linked using the DMS 2200
and DPS 2200 software located in the desired application group. This search chain
was built in 4.5.1 to include DPS 2200. If MCB functions are used in the transaction
program instead of DPS 2200 functions, the Unisys-supplied application group
library search chains can be used (SYS$LIB$*APP$7.). In this example, this
program is to execute in application group 7.
2. This statement calls the Linking System LINK Processor. The zero overhead object
module (ZOOM) to be produced is named QUAL*UCSTST.DPSDMS.
3. This command identifies the compiler-generated object module containing the
UCS DML program.
4. This command identifies the object module generated by SDDL that contains the
subschema's S$WORK element.
5. This command resolves external references, including those to the UCS Runtime
System library.

5–76 7831 4077–009

 Application Programming in a TIP Environment

6. This command merges banks and attempts to produce a fast-load zero overhead
object module, otherwise a standard zero overhead object module is created.
7. This command deletes all definitions except the program's starting address,
START$. This decreases the size of the ZOOM.
8. This statement ends static linking.

5.2.1.8. Example of a UCS Transaction Program Containing DML

Statements
The following subsections show an example of compiling, linking, and executing the
following:
• A batch database load program
The batch load program uses dynamic linking.
(Due to the length of the load program, its source listing is not provided.)
• A database retrieval transaction program
The retrieval program uses DPS 2200 functions. The retrieval transaction program
is statically linked to produce a zero overhead object module.

7831 4077–009 5–77

Application Programming in a TIP Environment

Source Listing of the UCS DML Transaction Program (DPSDMS)

Example 5–13 shows the source listing of the UCS DPS DML transaction program
DPSDMS. This program reads an employee number as input and displays the
information contained in this database about the individual's job using a DPS form. In
this example, the program resides in element QUAL*UCSTST.DPSDMS. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSDMS INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE TIP COBOL DPS DMS PROGRAM - DPSDMS *
* *
* initializes with DPS *
* reads the input data *
* opens the DPS form *
* moves the employee number to the form *
* imparts to the PERSONNELTIP database *
* retrieves the requested information from the DMS database *
* moves the DMS information to the form *
* departs from the PERSONNELTIP database *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUBTIP IN FILE SCHFILEXEC
OF SCHEMA PERSONNELTIP
COPYING RECORDS INTO WORKING
COPYING DATA-NAMES INTO WORKING
RUN-UNIT-ID DPSALL
DMCA IS WORKING
ERROR DMS-GENERAL-ERROR-PARA.
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

5–78 7831 4077–009

 Application Programming in a TIP Environment

VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.

01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
COPY GETFIELD.
COPY SENDERROR.
COPY SCREEN-DSPLYIND-50.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER.
05 EMP-PAGE PIC 9(3).
05 EMP-RECORD PIC 9(2).
*
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL 'D$INIT'USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE TRANSACTION CODE
************************************************************
DPS-FREE-FORMAT-READ1.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-FREE-FORMAT-READ2.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

7831 4077–009 5–79

Application Programming in a TIP Environment

IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.
IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5 OR
GETFIELD-TYPE NOT EQUAL 3
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* EMPLOYEE NUMBER VALIDATION
************************************************************
VALID-EMPLOYEE-NUMBER.
IF EMP-PAGE <= 99 OR EMP-RECORD <= 0
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER
************************************************************
DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

5–80 7831 4077–009

 Application Programming in a TIP Environment

* OPEN ALL DATABASE STORAGE AREAS FOR RETRIEVAL OF

* DATA ONLY, NO DATA UPDATE ID ALLOWED
************************************************************
IMPART-TO-DMS.
IMPART.
OPEN ALL USAGE-MODE IS RETRIEVAL.
************************************************************
* DMS - RETRIEVE THE INDIVIDUAL INFORMATION
* MOVE THE INDIVIDUAL INFORMATION TO THE DPS FORM
************************************************************
DMS-RETRIEVE-INDIVIDUAL-DATA.
MOVE 'EMPNOAREATIP'TO EMPNO-AREA-NAME.
MOVE EMP-PAGE TO PAGE-NUM OF EMPNO-AREA-KEY.
MOVE EMP-RECORD TO RECORD-NUM OF EMPNO-AREA-KEY.
FETCH EMPNUMBER RECORD.
FETCH NEXT RECORD WITHIN EMPNO-IND SET.
FETCH OWNER RECORD WITHIN DEPT-IND SET.
FETCH OWNER RECORD WITHIN JOB-IND SET.
DMS-MOVE-INDIVIDUAL-DATA.
MOVE IND-LAST-NAME TO S50-IND-LAST-NAME.
MOVE IND-FIRST-NAME TO S50-IND-FIRST-NAME.
MOVE DEPT-NAME TO S50-DEPT-NAME.
MOVE DEPT-NO TO S50-DEPT-NO.
MOVE DEPT-DESCRIPTION TO S50-DEPT-DESCRIPTION.
MOVE JOB-TITLE TO S50-JOB-TITLE.
MOVE JOB-DESCRIPTION TO S50-JOB-DESCRIPTION.
MOVE JOB-SALARY TO S50-JOB-SALARY.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************
DMS-DEPART-PARA.
DEPART.
************************************************************
* SENDS THE SCREEN TO THE USER
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* TERMINATION WITH DPS
************************************************************
DPS-TERMINATION.
CALL 'D$TERM'USING DPS-STATUS.
************************************************************

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

7831 4077–009 5–81

Application Programming in a TIP Environment

* PROGRAM TERMINATION
***********************************************************
TERMINATION-PARA.
STOP RUN.
************************************************************
* DMS - CHECK FOR A '0013'ERROR,
* IF THIS ERROR OCCURRED THE
* INVALID-EMPLOYEE-NUMBER MESSAGE IS PRINTED
* ELSE THE ERROR MESSAGE IS RETURNED TO THE PRINTER
* FOR DEBUGGING.
************************************************************
DMS-GENERAL-ERROR-PARA.
IF ERROR-NUM = '0013'
MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
ELSE DISPLAY 'DMS-GENERAL-ERROR-PARA.'UPON PRINTER
DISPLAY 'AREA = 'ERROR-AREA UPON PRINTER
DISPLAY 'RECORD = 'ERROR-RECORD UPON PRINTER
DISPLAY 'SET = ' ERROR-SET UPON PRINTER
DISPLAY 'ROLLBACK = 'RB-ERROR-CODE UPON PRINTER
DISPLAY 'FUNCTION = 'ERROR-FUNCTION UPON PRINTER
DISPLAY 'ERR NUM = ' ERROR-NUM UPON PRINTER
END-IF.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
*
************************************************************
* RETURNS AN ERROR MESSAGE TO THE USER IF THE INPUT
* MESSAGE WAS IN ERROR AND TERMINATES WITH THE
* TRANSACTION PROCESSING SYSTEM
************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR'USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*

*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO
* TO A DPS INTERNAL ERROR.
************************************************************
DPS-GENERAL-ERROR-PARA.

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

5–82 7831 4077–009

 Application Programming in a TIP Environment

CALL 'D$DUMP'.
CALL 'D$ERRMSG'USING DPS-STATUS.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.

Example 5–13. Source Listing of DML Transaction Program

(QUAL*UCSTST.DPSDMS)

7831 4077–009 5–83

Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–14 shows the source listing of a runstream used to compile, link, and set
up the batch database load program LOADDMSDBTP and the database retrieval
transaction program DPSDMS. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE BATCH INITIAL LOAD PROGRAM AND THE TIP TRANSACTION
@ . *** PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADDMSDBTP,QUAL*UCSTST.LOADDMSDBTP/COMP,,, ;
COMPAT, NO-OPTIONS
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS DMS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
@UCOB QUAL*UCSTST.DPSDMS,QUAL*UCSTST.DPSDMS/COMP,,, COMPAT, NO-OPTIONS
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***

Example 5–14. Runstream to Compile, Link, and Execute—COBOL DPS DMS

Transaction Program

5–84 7831 4077–009

 Application Programming in a TIP Environment

@ . *** THE SUBSCHEMA ABSOLUTE IS COPIED TO QUAL*UCSTST. (HOME$)

@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@COPY,A UDS$$SVN*SCHFILEXEC.S$WORK/PERSONSUBTIP,QUAL*UCSTST.
@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*UCSTST.LOADDMSDBTP/COMP
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSDMS'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK ,QUAL*UCSTST.DPSDMS
INCLUDE QUAL*UCSTST.DPSDMS/COMP
INCLUDE UDS$$SVN*SCHFILEXEC.S$WORK/PERSONSUBTIP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
905 NAM,DPSDMS ACT,DPSDMS PRG,3 STF,0 QPR,1 STA,J OPT,TV
905 REC,Z AUD,7 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF

Example 5–14. Runstream to Compile, Link, and Execute—COBOL DPS

DMS Transaction Program

7831 4077–009 5–85

Application Programming in a TIP Environment

@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY DPSDMS FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810
EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–14. Runstream to Compile, Link, and Execute—COBOL DPS

DMS Transaction Program

5–86 7831 4077–009

 Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5–15 shows the execution of the source runstream used to compile, link, and
setup this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE BATCH INITIAL LOAD PROGRAM AND THE TIP TRANSACTION
@ . *** PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
W:120533 filename not unique.
W:120133 file is already assigned.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
I:002333 USE complete.
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADDMSDBTP,QUAL*UCSTST.LOADDMSDBTP/COMP,,, ;
COMPAT, NO-OPTIONS
UCOB- 6R2(940210) LSS- 8R2(940209) 940217 12:27:39
SIZES: CODE(EM6): 1701 DATA: 2089
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13R1J (931108 0108:39) 1994 Feb 17 Thu 1227:50
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 2.885 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS DMS COBOL TRANSACTION PROGRAM

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

7831 4077–009 5–87

Application Programming in a TIP Environment

@ . ***
@USE COB$PF,APP7*DPS.
I:002333 USE complete.
@UCOB QUAL*UCSTST.DPSDMS,QUAL*UCSTST.DPSDMS/COMP,,, COMPAT, NO-OPTIONS
UCOB- 6R2(940210) LSS- 8R2(940209) 940217 12:27:53
SIZES: CODE(EM6): 1321 DATA: 822
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 6 REMARKS(CLARIFICATION)
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE SUBSCHEMA ABSOLUTE IS COPIED TO QUAL*UCSTST. (HOME$)
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@COPY,A UDS$$SVN*SCHFILEXEC.S$WORK/PERSONSUBTIP,QUAL*UCSTST.
FURPUR 30R7 (940125 0849:29) 1994 Feb 17 Thu 1228:03
1 ABS
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@XQT QUAL*UCSTST.LOADDMSDBTP/COMP

IMPARTED

DATABASE AREAS ARE OPEN FOR INITIAL LOAD

DEPARTMENT RECORDS ARE LOADED

JOBINFO RECORDS ARE LOADED

EMPNUMBER RECORDS ARE LOADED

INDIVIDUAL RECORDS ARE LOADED

INITIAL LOAD COMPLETED

*******************

DATABASE VALIDATION

EMPNO FIRST NAME LAST NAME DEPARTMENT NAME JOB TITLE

24101 MARY ANDERSON APPLICATION DEVELOPMENT CONSULTANT

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

5–88 7831 4077–009

 Application Programming in a TIP Environment

26504 JOHN BLAKE APPLICATION SUPPORT PROGRAMMER

26510 GEORGE CARR APPLICATION SUPPORT SYSTEMS ANALYST

10211 STEVEN FIELDING APPLICATION DEVELOPMENT PROGRAMMER

10215 JENNIFER HELLER APPLICATION DEVELOPMENT PROGRAMMER

32009 JAKE KAISER APPLICATION DEVELOPMENT SYSTEMS ANALYST

26503 RALPH MILLER APPLICATION DEVELOPMENT TEAM LEADER

10223 KAREN RALSTON APPLICATION SUPPORT TEAM LEADER

****

**** 0008 INDIVIDUAL RECORDS ARE LOADED

DATABASE LOAD HAS BEEN VALIDATED

@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSDMS'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DPSDMS
LINK 5R2 (940207 1635:57) 1994 Feb 17 Thu 1228:47
*WARNING (link 687)* The Linking System could NOT create a ZOOM that conforms
to the Fast Load format restriction of four banks or less. This is due to
incompatibilities in the attributes (e.g. merge order, mode, locality) of
certain banks, which prevent them from being merged. Such merging is required
to reduce the number of banks that are output. The ZOOM that is created will
be of the standard form.
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 1 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

7831 4077–009 5–89

Application Programming in a TIP Environment

@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.

@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940217 1228:53
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

905 NAM,DPSDMS ACT,DPSDMS PRG,3 STF,0 QPR,1 STA,J OPT,TV

905 REC,Z AUD,7 PRT,PR

*** ORIGINAL VALTAB ***

PROGRAM NUMBER: 905 TRANSACTION CODE: DPSDMS
NAM: DPSDMS RUN: 30 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: O PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
*** CHANGED VALTAB ***
PROGRAM NUMBER: 905 TRANSACTION CODE: DPSDMS
NAM: DPSDMS RUN: 30 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: O PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

5–90 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1228:53
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940217 1228:54
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1228:54
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:28:54 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 12:28:54 17 FEB 94
TP REGISTER FINISHED 12:28:56 17 FEB 94

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

7831 4077–009 5–91

Application Programming in a TIP Environment

RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:28:56 17 FEB 94
TP RESERVE FINISHED 12:28:56 17 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-17 1228:57
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY DPSDMS FROM QUAL*UCSTST TO 810
Program DPSDMS copied to TIP file 810 in ZOOM std-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: DPSDMS TIP Program File: 810

Element Format: ZOOM std-load Created on: 94-02-17 1228:52
Record Number: 2 Area Size: 436 records
Start Address: 400004001005 Program Mode: 3rd,NA,64-Gran
Program Number: 905
Processing completed successfully for LIST
EXIT
SUPUR Processor Terminated. Date-Time: 94-02-17 1229:54
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–15. Execution of Source Runstream—COBOL DPS DMS

Transaction Program

5–92 7831 4077–009

 Application Programming in a TIP Environment

Execution of the DPS DMS 2200 Transaction Program

The following screens show the execution of a DPS DMS 2200 transaction program.
User input is bolded.

>DPSDMS 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: APPLICATION DEVELOPMENT NUMBER: 4124
FUNCTION: DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION CODE

*** JOB INFORMATION ***

TITLE: PROGRAMMER YEARLY SALARY: $40000
FUNCTION: DESIGNS, WRITES, AND TESTS CODE

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

7831 4077–009 5–93

Application Programming in a TIP Environment

5.2.2. Using RDMS 2200 Databases

UCS TIP transaction programming first supported the Relational Data Management
System (RDMS 2200) software in SB3R1. UCS COBOL, UCS FORTRAN, and UCS C
were the supported host languages.

Support for the embedded SQL interface was added to UCS COBOL transaction
programs in SB4 and to UCS C in SB5R2. Also, as of SB5R2 UCS FORTRAN transaction
programs support the module language SQL interface.

The following subsections describe the steps involved in creating and accessing an
RDMS 2200 database using UCS TIP transactions. They discuss
• Table definitions
• SQL application TIP transaction programs

5.2.2.1. RDMS 2200 Tables

Relational databases are composed of two-dimensional tables with rows and columns.

RDMS 2200 tables are kept in storage areas. You define storage areas by using the
Unisys Repository Manager (UREP).

Once you have defined the storage areas for the tables, you can define the tables
themselves using one of the following ways:
• By using the IPF SQL interface
• By coding an SQL program
• By using the MAPPER Relational Interface (MRI)
• Client-based tools using
− ODBC (Open DataBase Connectivity)
− Open Client/Open Server interconnect

When you define a table, UREP makes an entry in the Unisys repository that
symbolically describes the table's characteristics (for example, table names and
column names).

Coding an RDMS 2200 table definition has no special constraints in UCS. Existing table
definitions being used by non-UCS SQL programs can be used without change by UCS
interpreted SQL, UCS module language SQL, and embedded SQL programs.

RDMS 2200 tables can be loaded by using one of the following:

• By the new RDMS 2200 load utility RDMUTL
RDMUTL is a replacement for the RDMSLOAD utility.
• By an SQL program
• By using the MAPPER Relational Interface (MRI)

5–94 7831 4077–009

 Application Programming in a TIP Environment

• Client-based tools using

− ODBC (Open DataBase Connectivity)
− Open Client/Open Server interconnect
Refer to the Relational Database Server Administration Guide for more information
on RDMS 2200 storage areas and tables.

The following figure shows the tables that are used in the RDMS 2200 example for
this section.

The following is a brief description of the table types in this database.

INDIVIDUALR
is a table whose primary key is the individual's employee number (INDR-EMP-
NUMBER). The table also has a secondary index consisting of the individual's
name (indr-last-name, indr-first-name).

SCHOOL
is a table whose primary key is the school's unique number (SCH-NUMBER).

CHILD
is a table whose primary key is the individual's employee number (CHILD-EMP-
NUMBER) and the sequential number of the child in the family (CHILD-NUMBER).
The table also has a secondary index consisting of the child's name (child-last-
name, child-first-name). The child's school number (child-school-number) is a
foreign key to the SCHOOL table. The child's employee number (CHILD-EMP-
NUMBER) is a foreign key to the INDIVIDUALR table.

7831 4077–009 5–95

Application Programming in a TIP Environment

To keep the program simple, this example assumes that no individual will have more
than three children.

5.2.2.2. Using UDS-TIP Files

When you use RDMS 2200, the storage areas can be defined under TIP file control.

Note: Using TIP file control eliminates much Exec input/output overhead.
Therefore, it is recommended that RDMS 2200 databases that will be accessed by
TIP transactions be set up using TIP storage areas. This requires setting up a TIP
file for each underlying Exec file.

When you later define the storage areas using UREP, the UDS-TIP-CODE must match
the UDS-TIP file number.

For more information on setting up TIP files that hold RDMS 2200 storage areas, refer
to the Repository For ClearPath OS 2200 Administration Guide.

5.2.2.3. Example of an RDMS 2200 Database Definition

The following subsections show a sample set of tables being set up for use by UCS
programs:
• The IPF SQL interface is used to define the tables.
• The RDMS 2200 load utility, RDMUTL, is used to load the data into the tables.
• The storage area files are all UDS-TIP files.

5–96 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of the Table Definitions (INDIVIDUALR, SCHOOL, CHILD)

Example 5–16 shows the source listing of the table definitions for the tables
INDIVIDUALR, SCHOOL, and CHILD. This source is used as input to the IPF SQL
interface. In this example, these table definitions reside in element
QUAL*UCSTST.TIPTABLES.

SQL USE DEFAULT QUALIFIER FAMILYTIP

SQL CREATE TABLE INDIVIDUALR IN FAMILYTIP.INDRAREATIP &
COLUMNS ARE INDR_EMP_NUMBER : CHARACTER (5) NOT NULL, &
INDR_LAST_NAME : CHARACTER (20) NOT NULL, &
INDR_FIRST_NAME : CHARACTER (12) NOT NULL, &
INDR_BIRTH_DATE : CHARACTER (6) NOT NULL, &
INDR_SPOUSE_LAST_NAME : CHARACTER (20), &
INDR_SPOUSE_FIRST_NAME : CHARACTER (12) &
PRIMARY KEY PRI_INDR IS INDR_EMP_NUMBER ASCENDING &
INDEX SEC_INDNAME ON INDR_LAST_NAME ASCENDING, &
INDR_FIRST_NAME ASCENDING
SQL CREATE TABLE SCHOOL IN FAMILYTIP.SCHOOLAREATP &
COLUMNS ARE SCH_NUMBER : CHARACTER (4) NOT NULL, &
SCH_NAME : CHARACTER (25) NOT NULL, &
SCH_START_GRADE : CHARACTER (2) NOT NULL, &
SCH_END_GRADE : CHARACTER (2) NOT NULL &
PRIMARY KEY PRI_SCH IS SCH_NUMBER ASCENDING
SQL CREATE TABLE CHILD IN FAMILYTIP.CHILDAREATIP &
COLUMNS ARE CHILD_EMP_NUMBER : CHARACTER (5) NOT NULL, &
CHILD_NUMBER : CHARACTER (3) NOT NULL, &
CHILD_LAST_NAME : CHARACTER (20) NOT NULL, &
CHILD_FIRST_NAME : CHARACTER (12) NOT NULL, &
CHILD_BIRTH_DATE : CHARACTER (6) NOT NULL, &
CHILD_SCHOOL_NUMBER : CHARACTER (4), &
CHILD_GRADE_AVERAGE : NUMERIC (5.3) &
PRIMARY KEY PRI_INDR IS CHILD_EMP_NUMBER ASCENDING, &
CHILD_NUMBER ASCENDING &
FOREIGN KEY FOR_SCH IS CHILD_SCHOOL_NUMBER &
REFERS TO SCH_NUMBER OF SCHOOL &
FOREIGN KEY FOR_EMP IS CHILD_EMP_NUMBER &
REFERS TO INDR_EMP_NUMBER OF INDIVIDUALR &
INDEX SEC_CHDNAME ON CHILD_LAST_NAME ASCENDING, &
CHILD_FIRST_NAME ASCENDING

Example 5–16. Source Listing of the Table Definitions (QUAL*UCSTST.TIPTABLES)

7831 4077–009 5–97

Application Programming in a TIP Environment

Source Listings of the Table Load Data

Example 5–17 is the source listing of the load data for the INDIVIDUALR table. For this
example, the INDIVIDUALR load data resides in the file QUAL*INDLOAD.

>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.

COLUMNS FIELD NAME RDMS FORMAT

======= ========== ===========
1-5 INDR_EMP_NUMBER CHARACTER (5) NOT NULL primary key
7-26 INDR_LAST_NAME CHARACTER (20) NOT NULL
28-39 INDR_FIRST_NAME CHARACTER (12) NOT NULL
41-46 INDR_BIRTH_DATE CHARACTER (6) NOT NULL
48-57 INDR-SPOUSE_LAST_NAME CHARACTER (20) NULLS ALLOWED
59-70 INDR-SPOUSE_FIRST_NAME CHARACTER (12) NULLS ALLOWED

>END DESCRIPTION<
10211 FIELDING STEVEN 480719 FIELDING KATHY
10215 HELLER JENNIFER 590529 * *
10223 RALSTON KAREN 580910 EASTMAN JOHN
24101 ANDERSON MARY 520803 ANDERSON FRED
26503 MILLER RALPH 470317 * *
26504 BLAKE JOHN 650714 * *
26510 CARR GEORGE 561123 CARR SUSAN
32009 KAISER JAKE 531008 WRIGHT ANGEL

Example 5–17. Source Listing of the Load Data for INDIVIDUALR Table
(QUAL*INDLOAD.)

5–98 7831 4077–009

 Application Programming in a TIP Environment

Example 5–18 is the source listing of the load data for the SCHOOL table. For this
example, the SCHOOL load data resides in the file QUAL*SCHLOAD.

>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.

COLUMNS FIELD NAME RDMS FORMAT

======= ========== ===========
1-4 SCH_NUMBER CHARACTER (4) NOT NULL primary key
6-30 SCH_NAME CHARACTER (25) NOT NULL
32-33 SCH_START_GRADE CHARACTER (2) NOT NULL
35-36 SCH_END_GRADE CHARACTER (2) NOT NULL

>END DESCRIPTION<
1349 WOODBURY SENIOR HIGH 09 12
1361 EAGAN MIDDLE SCHOOL 06 08
2188 WESTERLY ELEMENTARY 01 05
3703 GLENVIEW ELEMENTARY 01 05

Example 5–18. Source Listing of the Load Data for SCHOOL Table
(QUAL*SCHLOAD.)

7831 4077–009 5–99

Application Programming in a TIP Environment

Example 5–19 is the source listing of the load data for the CHILD table. For this
example, the CHILD load data resides in the file QUAL*CHILDLOAD.

>DESCRIPTION<
THIS IS AN OPTIONAL DESCRIPTION SECTION, WHICH DESCRIBES
THE FORMAT OF THE DATA IN THIS FILE.

COLUMNS FIELD NAME RDMS FORMAT

======= ========== ===========
1-5 CHILD_EMP_NUMBER CHARACTER (5) NOT NULL primary key
7-8 CHILD_NUMBER CHARACTER (2) NOT NULL primary key
10-29 CHILD_LAST_NAME CHARACTER (20) NOT NULL
31-42 CHILD_FIRST_NAME CHARACTER (12) NOT NULL
44-49 CHILD_BIRTH_DATE CHARACTER (6) NOT NULL
51-54 CHILD_SCHOOL_NUMBER CHARACTER (4) NULLS ALLOWED foreign key
56-60 CHILD_GRADE_AVERAGE NUMERIC (5.3) NULLS ALLOWED

>END DESCRIPTION<
10211 01 FIELDING STEVEN JR 680108 * *
10211 02 FIELDING DANIEL 710708 * *
10211 03 FIELDING JANE 760411 1349 3.500
10215 01 HELLER VANESSA 851002 * *
10223 01 EASTMAN JAMES 880912 * *
24101 01 ANDERSON SEAN 800611 3703 2.850
24101 02 ANDERSON MICHELLE 800611 3703 4.000
32009 01 KAISER JASON 780213 1361 3.500
32009 02 KAISER SHARON 830228 2188 3.250

Example 5–19. Source Listing of the Load Data for CHILD Table
(QUAL*CHILDLOAD.)

5–100 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–20 shows the source listing of the runstream used to define the RDMS
2200 storage areas and tables. The runstream also loads the table data. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE RDMS DATABASE DEFINITION SECTION **********
@ . ***
@ . *** CATALOG: CATALOGS THE DATABASE STORAGE AREA EXEC FILES
@ . *** THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-filename MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P UDS$$SVN*INDRAREATIP.,F/20//20
@CAT,P UDS$$SVN*CHILDAREATIP.,F/20//20
@CAT,P UDS$$SVN*SCHOOLAREATP.,F/5//5
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE DATABASE STORAGE AREA FILES.
@ . ***
@ . *** 2. RESERVE THE DATABASE STORAGE AREAS FILES.
@ . ***
@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.
@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** UDS$$SVN*INDRAREATIP.
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** Assigned TIP-FILE-NUMBER = 2134
@ . ***
@ . *** 2200 + 1 - 2134
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR UDS$$SVN*INDRAREATIP = 67
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG UDS$$SVN*INDRAREATIP.,FIX

Example 5–20. Runstream to Define Storage Areas and Tables and Load Tables

7831 4077–009 5–101

Application Programming in a TIP Environment

TREG UDS$$SVN*CHILDAREATIP.,FIX
TREG UDS$$SVN*SCHOOLAREATP.,FIX
RES,G 67,40,896,,INDRAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 68,40,896,,CHILDAREATIP,,,WW=P,AUDIT=0,NREC
RES,G 69,20,448,,SCHOOLAREATP,,,WW=P,AUDIT=0,NREC
LFD,G 67/69
@EOF
@ . ***
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE RDMS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD,E ,,APPSVN
CREATE SCHEMA FAMILYTIP.
CREATE STORAGE-AREA INDRAREATIP FOR SCHEMA FAMILYTIP
ADD FILE-TYPE IS UDS-TIP.
ADD DATA-FORMAT IS RSM.
ADD FILE-NAME IS INDRAREATIP.
ADD UDS-TIP-CODE IS 67.
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 40.
ADD CHECKSUM IS NO.
CREATE STORAGE-AREA CHILDAREATIP FOR SCHEMA FAMILYTIP.
ADD FILE-TYPE IS UDS-TIP.
ADD DATA-FORMAT IS RSM.
ADD FILE-NAME IS CHILDAREATIP.
ADD UDS-TIP-CODE IS 68.
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 40.
ADD CHECKSUM IS NO.
CREATE STORAGE-AREA SCHOOLAREATP FOR SCHEMA FAMILYTIP.
ADD FILE-TYPE IS UDS-TIP.
ADD DATA-FORMAT IS RSM.
ADD FILE-NAME IS SCHOOLAREATP.
ADD UDS-TIP-CODE IS 69.
ADD DOMAIN IS UDS.
ADD LOCK-STRATEGY IS PAGE.
ADD RECOVERED IS TRUE.

Example 5–20. Runstream to Define Storage Areas and Tables and Load
Tables

5–102 7831 4077–009

 Application Programming in a TIP Environment

ADD AUDITED IS TRUE.

ADD PAGE-SIZE IS 448.
ADD MAXIMUM-PAGES IS 20.
ADD CHECKSUM IS NO.
PROCESS STORAGE-AREA ALL FOR SCHEMA FAMILYTIP INSTALL.
EXIT.
@ . ***
@ . ***
@ . *** USE IPF SQL TO DEFINE THE RDMS TABLES
@ . ***
@IPF
MODE LINE
$DATAMANAGER := RDMS
SQL BEGIN THREAD DEFINETABLES FOR APPSVN UPDATE(COMMANDLOOK)SQL FILE
QUAL*UCSTST.TIPTABLES
SQL END THREAD
LOGOFF
@ . ***
@ . ***
@ . *** LOAD THE RDMS DATABASE
@ . ***
@SYS$LIB$*RDMS.RDMUTL,S APPSVN
LOAD EXTERNAL FILE "QUAL*INDLOAD"
SORTED YES
LOAD FACTOR 50
INTO TABLE FAMILYTIP.INDIVIDUALR
FORMAT INDR_EMP_NUMBER(1:5),
INDR_LAST_NAME(7:26),
INDR_FIRST_NAME(28:39),
INDR_BIRTH_DATE(41:46),
INDR_SPOUSE_LAST_NAME(48:57) NULLIF((48:48) = '*'),
INDR_SPOUSE_FIRST_NAME(59:70) NULLIF((59:59) = '*') ;
LOAD EXTERNAL FILE "QUAL*SCHLOAD"
SORTED YES
LOAD FACTOR 50
INTO TABLE FAMILYTIP.SCHOOL
FORMAT SCH_NUMBER(1:4),
SCH_NAME(6:30),
SCH_START_GRADE(32:33),
SCH_END_GRADE(35:36) ;
LOAD EXTERNAL FILE "QUAL*CHILDLOAD"
SORTED YES
LOAD FACTOR 50
INTO TABLE FAMILYTIP.CHILD
' FORMAT CHILD_EMP_NUMBER(1:5),
CHILD_NUMBER(7:8),

Example 5–20. Runstream to Define Storage Areas and Tables and Load
Tables

7831 4077–009 5–103

Application Programming in a TIP Environment

CHILD_LAST_NAME(10:29),
CHILD_FIRST_NAME(31:42),
CHILD_BIRTH_DATE(44:49),
CHILD_SCHOOL_NUMBER(51:54) NULLIF((51:51) = '*'),
CHILD_GRADE_AVERAGE(56:60) NULLIF((56:56) = '*') ;
@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE RDMS DATABASE DEFINITION SECTION *************
@ . ***

Example 5–20. Runstream to Define Storage Areas and Tables and Load
Tables

5–104 7831 4077–009

 Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5–21 shows the execution of the source runstream used to define the RDMS
2200 storage areas and tables and load the table data. Output has been saved by an
@BRKPT statement. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE RDMS DATABASE DEFINITION SECTION **********
@ . ***
@ . *** CATALOG: CATALOGS THE DATABASE STORAGE AREA EXEC FILES
@ . *** THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-FILENAME MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P UDS$$SVN*INDRAREATIP.,F/20//20
I:002333 CAT complete.
@CAT,P UDS$$SVN*CHILDAREATIP.,F/20//20
I:002333 CAT complete.
@CAT,P UDS$$SVN*SCHOOLAREATP.,F/5//5
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE DATABASE STORAGE AREA FILES.
@ . ***
@ . *** 2. RESERVE THE DATABASE STORAGE AREAS FILES.
@ . ***
@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.
@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** UDS$$SVN*INDRAREATIP.
@ . ***
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** ASSIGNED TIP-FILE-NUMBER = 2134
@ . ***
@ . *** 2200 + 1 - 2134
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR UDS$$SVN*INDRAREATIP = 67
@ . ***

Example 5–21. Execution of Source Runstream—RDMS Database Setup

7831 4077–009 5–105

Application Programming in a TIP Environment

@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:49:49 FS-LEVEL FS 003
TREG UDS$$SVN*INDRAREATIP.,FIX
TP REGISTER STARTED 12:49:49 17 FEB 94
TP REGISTER FINISHED 12:49:49 17 FEB 94
TREG UDS$$SVN*CHILDAREATIP.,FIX
TP REGISTER STARTED 12:49:49 17 FEB 94
TP REGISTER FINISHED 12:49:49 17 FEB 94
TREG UDS$$SVN*SCHOOLAREATP.,FIX
TP REGISTER STARTED 12:49:49 17 FEB 94
TP REGISTER FINISHED 12:49:49 17 FEB 94
RES,G 67,40,896,,INDRAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:49:49 17 FEB 94
TP RESERVE FINISHED 12:49:49 17 FEB 94
RES,G 68,40,896,,CHILDAREATIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:49:49 17 FEB 94
TP RESERVE FINISHED 12:49:49 17 FEB 94
RES,G 69,20,448,,SCHOOLAREATP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:49:49 17 FEB 94
TP RESERVE FINISHED 12:49:49 17 FEB 94
LFD,G 67/69
DMS AREA 67
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 40 SIZE: 896 APPLICATION GROUP: 0
FILE NAME INDRAREATIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 68
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 40 SIZE: 896 APPLICATION GROUP: 0
FILE NAME CHILDAREATIP
PLACEMENT 0
LEG STATUS AVL-UP

DMS AREA 69
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 20 SIZE: 448 APPLICATION GROUP: 0
FILE NAME SCHOOLAREATP
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***

Example 5–21. Execution of Source Runstream—RDMS Database Setup

5–106 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE RDMS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD,E ,,APPSVN
UREP 3R2 (11/04/93 10:17:39) 02/17/94 12:49:50
1 CREATE SCHEMA FAMILYTIP.
2 CREATE STORAGE-AREA INDRAREATIP FOR SCHEMA FAMILYTIP
3 ADD FILE-TYPE IS UDS-TIP.
4 ADD DATA-FORMAT IS RSM.
5 ADD FILE-NAME IS INDRAREATIP.
6 ADD UDS-TIP-CODE IS 67.
7 ADD DOMAIN IS UDS.
8 ADD LOCK-STRATEGY IS PAGE.
9 ADD RECOVERED IS TRUE.
10 ADD AUDITED IS TRUE.
11 ADD PAGE-SIZE IS 896.
12 ADD MAXIMUM-PAGES IS 40.
13 ADD CHECKSUM IS NO.
14 CREATE STORAGE-AREA CHILDAREATIP FOR SCHEMA FAMILYTIP.
15 ADD FILE-TYPE IS UDS-TIP.
16 ADD DATA-FORMAT IS RSM.
17 ADD FILE-NAME IS CHILDAREATIP.
18 ADD UDS-TIP-CODE IS 68.
19 ADD DOMAIN IS UDS.
20 ADD LOCK-STRATEGY IS PAGE.
21 ADD RECOVERED IS TRUE.
22 ADD AUDITED IS TRUE.
23 ADD PAGE-SIZE IS 896.
24 ADD MAXIMUM-PAGES IS 40.
25 ADD CHECKSUM IS NO.
26 CREATE STORAGE-AREA SCHOOLAREATP FOR SCHEMA FAMILYTIP.
27 ADD FILE-TYPE IS UDS-TIP.
28 ADD DATA-FORMAT IS RSM.
29 ADD FILE-NAME IS SCHOOLAREATP.
30 ADD UDS-TIP-CODE IS 69.
31 ADD DOMAIN IS UDS.
32 ADD LOCK-STRATEGY IS PAGE.
33 ADD RECOVERED IS TRUE.
34 ADD AUDITED IS TRUE.
35 ADD PAGE-SIZE IS 448.
36 ADD MAXIMUM-PAGES IS 20.
37 ADD CHECKSUM IS NO.
38 PROCESS STORAGE-AREA ALL FOR SCHEMA FAMILYTIP INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA CHILDAREATIP VERSION ''for
SCHEMA FAMILYTIP was SUCCESSFUL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA INDRAREATIP VERSION ''for
SCHEMA FAMILYTIP was SUCCESSFUL.

Example 5–21. Execution of Source Runstream—RDMS Database Setup

7831 4077–009 5–107

Application Programming in a TIP Environment

*REMARK* DSD4023 The INSTALL for STORAGE-AREA SCHOOLAREATP VERSION ''for

SCHEMA FAMILYTIP was SUCCESSFUL.
*REMARK* DSD4036 Your PROCESS STORAGE-AREA ALL command was successful.
39 EXIT.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 4 )REMARKS .
@ . ***
@ . ***
@ . *** USE IPF SQL TO DEFINE THE RDMS TABLES
@ . ***
@IPF
IPF 1100 6R3 02/17/94 12:50:15
The BEGIN THREAD command completed successfully.
SQL USE DEFAULT QUALIFIER FAMILYTIP
The USE command completed successfully.
SQL CREATE TABLE INDIVIDUALR IN FAMILYTIP.INDRAREATIP &
COLUMNS ARE INDR_EMP_NUMBER : CHARACTER (5) NOT NULL, &
INDR_LAST_NAME : CHARACTER (20) NOT NULL, &
INDR_FIRST_NAME : CHARACTER (12) NOT NULL, &
INDR_BIRTH_DATE : CHARACTER (6) NOT NULL, &
INDR_SPOUSE_LAST_NAME : CHARACTER (20), &
INDR_SPOUSE_FIRST_NAME : CHARACTER (12) &
PRIMARY KEY PRI_INDR IS INDR_EMP_NUMBER ASCENDING &
INDEX SEC_INDNAME ON INDR_LAST_NAME ASCENDING, &
INDR_FIRST_NAME ASCENDING
The CREATE TABLE command completed successfully.
SQL CREATE TABLE SCHOOL IN FAMILYTIP.SCHOOLAREATP &
COLUMNS ARE SCH_NUMBER : CHARACTER (4) NOT NULL, &
SCH_NAME : CHARACTER (25) NOT NULL, &
SCH_START_GRADE : CHARACTER (2) NOT NULL, &
SCH_END_GRADE : CHARACTER (2) NOT NULL &
PRIMARY KEY PRI_SCH IS SCH_NUMBER ASCENDING
The CREATE TABLE command completed successfully.
SQL CREATE TABLE CHILD IN FAMILYTIP.CHILDAREATIP &
COLUMNS ARE CHILD_EMP_NUMBER : CHARACTER (5) NOT NULL, &
CHILD_NUMBER : CHARACTER (3) NOT NULL, &
CHILD_LAST_NAME : CHARACTER (20) NOT NULL, &
CHILD_FIRST_NAME : CHARACTER (12) NOT NULL, &
CHILD_BIRTH_DATE : CHARACTER (6) NOT NULL, &
CHILD_SCHOOL_NUMBER : CHARACTER (4), &
CHILD_GRADE_AVERAGE : NUMERIC (5.3) &
PRIMARY KEY PRI_INDR IS CHILD_EMP_NUMBER ASCENDING, &
CHILD_NUMBER ASCENDING &
FOREIGN KEY FOR_SCH IS CHILD_SCHOOL_NUMBER &
REFERS TO SCH_NUMBER OF SCHOOL &
FOREIGN KEY FOR_EMP IS CHILD_EMP_NUMBER &
REFERS TO INDR_EMP_NUMBER OF INDIVIDUALR &
INDEX SEC_CHDNAME ON CHILD_LAST_NAME ASCENDING, &

Example 5–21. Execution of Source Runstream—RDMS Database Setup

5–108 7831 4077–009

 Application Programming in a TIP Environment

CHILD_FIRST_NAME ASCENDING
The CREATE TABLE command completed successfully.
The END THREAD command completed successfully.
END IPF
@ . ***
@ . ***
@ . *** LOAD THE RDMS DATABASE
@ . ***
@SYS$LIB$*RDMS.RDMUTL,S APPSVN
RDMS 6R3 RELATIONAL UTILITY PROCESSOR 02/17/94 12:50:35
......... Begin thread ........
PLEASE ENTER RELATIONAL UTILITY COMMAND, FOLLOWED BY A SEMICOLON(;)
1 LOAD EXTERNAL FILE "QUAL*INDLOAD"
2 SORTED YES
3 LOAD FACTOR 50
4 INTO TABLE FAMILYTIP.INDIVIDUALR
5 FORMAT INDR_EMP_NUMBER(1:5),
6 INDR_LAST_NAME(7:26),
7 INDR_FIRST_NAME(28:39),
8 INDR_BIRTH_DATE(41:46),
9 INDR_SPOUSE_LAST_NAME(48:57) NULLIF((48:48) = '*'),
10 INDR_SPOUSE_FIRST_NAME(59:70) NULLIF((59:59) = '*');

RDM is processing your request at 02/17/94 12:50:35.

Thread committed after reading line 22 of the input file at time 12:50:37

The loading of file "QUAL*INDLOAD" is completed at 02/17/94 12:50:37.

The total number of lines read is 22
The total number of rows loaded is 8
11 LOAD EXTERNAL FILE "QUAL*SCHLOAD"
12 SORTED YES
13 LOAD FACTOR 50
14 INTO TABLE FAMILYTIP.SCHOOL
15 FORMAT SCH_NUMBER(1:4),
16 SCH_NAME(6:30),
17 SCH_START_GRADE(32:33),
18 SCH_END_GRADE(35:36) ;

RDM is processing your request at 02/17/94 12:50:37.

Thread committed after reading line 16 of the input file at time 12:50:37

The loading of file "QUAL*SCHLOAD" is completed at 02/17/94 12:50:37.

The total number of lines read is 16
The total number of rows loaded is 4
19 LOAD EXTERNAL FILE "QUAL*CHILDLOAD"
20 SORTED YES

Example 5–21. Execution of Source Runstream—RDMS Database Setup

7831 4077–009 5–109

Application Programming in a TIP Environment

21 LOAD FACTOR 50
22 INTO TABLE FAMILYTIP.CHILD
23 FORMAT CHILD_EMP_NUMBER(1:5),
24 CHILD_NUMBER(7:8),
25 CHILD_LAST_NAME(10:29),
26 CHILD_FIRST_NAME(31:42),
27 CHILD_BIRTH_DATE(44:49),
28 CHILD_SCHOOL_NUMBER(51:54) NULLIF((51:51) = '*'),
29 CHILD_GRADE_AVERAGE(56:60) NULLIF((56:56) = '*') ;

RDM is processing your request at 02/17/94 12:50:38.

Thread committed after reading line 24 of the input file at time 12:50:39

The loading of file "QUAL*CHILDLOAD" is completed at 02/17/94 12:50:39.

The total number of lines read is 24
The total number of rows loaded is 9

.......... End thread .........

END RELATIONAL UTILITY PROCESSOR --- 0 ERRORS

@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE RDMS DATABASE DEFINITION SECTION *************
@ . ***

Example 5–21. Execution of Source Runstream—RDMS Database Setup

5–110 7831 4077–009

 Application Programming in a TIP Environment

5.2.2.4. Coding RDMS 2200 TIP Transactions

RDMS 2200 provides three methods for accessing relational databases from UCS
transaction programs:
• Embedded SQL
This interface is supported by UCS COBOL and UCS C.
• Module Language SQL
This Interface is supported by UCS FORTRAN
• The SQL interpreter interface
This interface supports UCS COBOL, UCS FORTRAN, and UCS C for transaction
programming.

When you code an RDMS 2200 TIP transaction program, the following applies:
• When you use UCS COBOL or UCS C, embedded SQL commands improve TIP
performance, since these commands are parsed at compilation time. SQL
commands specified using the interpreter (nonembedded) interface are parsed
during each execution.
• When you use UCS, FORTRAN, module language SQL commands improve TIP
performance, since these commands are parsed at compilation time. SQL
commands specified using the interpreter interface are parsed during each
execution.
• When you use RDMS 2200 in TIP transactions, a call to RSA$INIT must precede
the first RDMS 2200 command in the transaction program. This call allocates and
initializes all of the space required for the RDMS 2200 work area. Optionally, it
also allows the programmer to specify the size of the work area. You should
make only one call to RSA$INIT within the transaction sequence.
The syntax for this call is as follows:
− UCS COBOL
CALL "RSA$INIT" [USING work-area-size].

− UCS FORTRAN
CALL RSA$INIT [(work-area-size)]

− UCS C
rsa_init ([work-area-size]);

UCS C requires #include <rsa.h>.

where work-area-size is a 36-bit binary integer declared in a UCS program as
follows:
− UCS COBOL
PIC 1(36) USAGE BINARY-1

− UCS FORTRAN
INTEGER

7831 4077–009 5–111

Application Programming in a TIP Environment

− UCS C
int

The default work area provides an initial allocation of 2000 words. The system
acquires more space dynamically, as needed. The overhead incurred by obtaining
additional space is expensive. Therefore, for TIP transactions, you should
determine the amount of space required by the transaction program and set
work-area-size accordingly.
For details about how to determine the size of the work area, refer to 3.5.1.
• The following commands are local to the compilation unit; therefore, they must be
coded in each program module that requires their functioning:

− SET STATISTICS

− USE DEFAULT

− WHENEVER

• Cursor declarations (DECLARE CURSOR and ALLOCATE CURSOR) must appear in

the source listing prior to any static embedded SQL reference to the cursor.

For more information on using SQL in TIP transactions, refer to the RDMS SQL
Programming Reference Manual.

For information on coding RDMS 2200 embedded SQL programs, RDMS 2200 module
language SQL programs, or RDMS 2200 interpreter SQL programs, refer to the
following:
• "Coding with the RDMS 2200 Embedded SQL Interface," in 3.2.2
• COBOL Compiler Programming Reference Manual Volume 2
• RDMS SQL Programming Reference Manual

5.2.2.5. Compiling UCS Transaction Programs That Access RDMS

2200 Databases
Compiling UCS transaction programs that access RDMS 2200 databases is
straightforward.

5–112 7831 4077–009

 Application Programming in a TIP Environment

Embedded SQL Transaction Programs

When compiling UCS COBOL or UCS C transaction programs containing embedded
SQL, you must specify the special keyword option APPLICATION/application-name.
This keyword option identifies the application group whose RDMS and related
RDT$FILE file is referenced while the compiler parses the RDMS 2200 commands.
This is the same application group that the program is linked to and executed within.
The default setting of this keyword option is APPLICATION/UDSSRC.

The following statement is a sample UCS COBOL compiler call used to compile an
embedded SQL program that uses application group 7:

@UCOB QUAL*UCSTST.MCBESQ/RDMS,QUAL*UCSTST.MCBESQ/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN

The following figure represents the process used to compile an embedded SQL
transaction program:
1. The embedded SQL commands are passed to RDMS 2200 for parsing.
2. RDMS 2200 accesses the table and view definitions in the RDT$FILE belonging to
the application group specified in the APPLICATION/application-name keyword
option.

7831 4077–009 5–113

Application Programming in a TIP Environment

Transaction Programs Using the Module Language SQL Interface

When you use the module SQL language interface, UCS FORTRAN accesses RDMS
indirectly by calling procedures generated by the SQL Module Language Preprocessor
(SMLP).

An SQL module implementation consists of at least two program units that you must
develop: the module language program, and the UCS FORTRAN host application
program.

The module language defines modules and procedures. Only one module is permitted
per host application program. A set of procedures make up the module. A procedure
consists of a procedure name, a list of parameter declarations, and a single SQL
statement. The SQLSTATE parameter must be included in the parameter list.

To execute an SQL statement, the host application program calls the module
procedure associated with a particular SQL statement in the same way it calls any
other subroutine or subprogram. The name of the subroutine or subprogram is the
module procedure name.

The SMLP interprets the module source language and generates a COBOL
subprogram element that must be compiled using the UCS COBOL compiler. The
COBOL subprogram combines with the host application program to manipulate the
RDMS database.

The following describes the steps involved in setting up an application that uses the
module SQL language to access an RDMS database and how the subprogram and host
program work together.
1. You develop a FORTRAN host application program and module language source as
follows:
• The host application program contains the calls to the module language source
procedures to execute SQL statements.
• The module SQL source defines procedures that contain the SQL statements
that the host program executes.
2. You call the SMLP to convert the module SQL source to a new source element
that consists of COBOL subprograms.
3. Use the UCS COBOL compiler to compile the COBOL subprograms. This step can
be performed either automatically by the SMLP, or manually by the user. The UCS
COBOL compiler processes embedded SQL statements by interfacing with RDMS.
The compilation produces an object module for each COBOL subprogram.
4. You call the UCS FORTRAN compiler to compile the host application program.
5. You statically link and execute the transaction program.

5–114 7831 4077–009

 Application Programming in a TIP Environment

The following figure shows an overview of this process.

Table/View
Definitions

ESQL Syntax RDMS RDT$FILE

Analysis

Module COBOL UCS COBOL

Language Subprograms Subprogram
@SMLP @UCOB
Source Source OMs

@LINK

UCS FORTRAN UCS FORTRAN Executable

Host @UFTN Host UCS FORTRAN
Program Source OM MSQL Program

002324

The SMLP generates a COBOL subprogram element from the module language source
program.

The COBOL subprogram element generated by the SMLP contains a COBOL

subprogram for each procedure in the module. The SQL operation defined in the
original module language has been converted to an embedded SQL statement in the
associated COBOL subprogram. All the COBOL subprograms are contained in the
same output symbolic element as back-to-back programs. The element generated for
the COBOL subprograms is the same as the output element specified on the SMLP
invocation, with a version name of COB attached.

The SMLP automatically compiles the generated COBOL subprogram element by

calling the UCS COBOL compiler. The UCS COBOL compiler call line includes
• The keyword options element, if one was specified on the SMLP call line in the
fourth field. This element should include the APPLICATION/application-name
keyword option to identify the correct application group.
• The MODULE keyword option.

Specifying the C option on the SMLP call line disables the automatic COBOL
compilation. You must then compile the generated COBOL subprogram element
including the APPLICATION/application-name and MODULE keyword options.

7831 4077–009 5–115

Application Programming in a TIP Environment

The following example contains

• A sample SMLP call that inhibits the automatic UCS COBOL compiler call.
• A user-invoked call to the UCS COBOL compiler.
• A call to the UCS FORTRAN compiler to compile the host application program.

Application group seven is being used.

@SMLP,C QUAL*UCSTST.DISPLAYFAM/MSQL-FMOD,QUAL*UCSTST.FMOD

@UCOB,S QUAL*UCSTST.FMOD/COB,QUAL*UCSTST.,,,NO-OPTIONS,NARROW;
APPLICATION/APPSVN,MODULE

@UFTN QUAL*UCSTST.DISPLAYFAM/MSQL-FHOST,QUAL*UCSTST.FHOST,,,NO-OPTIONS

Transaction Programs Using the SQL Interpreter Interface

When you compile a UCS transaction program using the SQL interpreter interface,
only a call to the correct UCS compiler is required. No special options or keyword
options are required by interpretive SQL for any of the host languages (UCS COBOL,
FORTRAN, or C).

The following statement is a sample UCS COBOL compiler call used to compile a
program using the SQL interpreter interface.

@UCOB QUAL*UCSTST.MCBISQ/RDMS,QUAL*UCSTST.MCBISQ/COMP,,, ;
NO-OPTIONS

The following figure represents the process used to compile a transaction program
using the SQL interpreter interface. Notice that only the compiler is used. This is
because all RDMS 2200 command syntax is parsed at execution time.

5–116 7831 4077–009

 Application Programming in a TIP Environment

5.2.2.6. Basic Linking Information for UCS RDMS 2200 Transaction

Programs
When statically linking a UCS transaction program that accesses an RDMS 2200
database, you must specify use of a special application group library search chain by
using an @USE LINK$PF statement. This library search chain causes the Linking
System to resolve references using the RDMS 2200 software for a particular
application group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the RDMS 2200 interface
during static linking
The following generic format shows how to specify use of the appropriate application
group library search chain:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program containing RDMS 2200 statements to the system
software in application group 7, use the following statement:
@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to RDMS 2200 software would be resolved using
UDS$$SVN*RSA. Embedded SQL programs and module SQL programs are compiled
for a specific application group. The default is application UDSSRC or application
group 3 (APP$3). Use of the APPLICATION/appname keyword option on the
compilation can target it for any application group you wish. You also should use the
@USE LINK$PF,SYS$LIB$*APP$n. statement specifying the file for the same
application group when either dynamically linking or static linking these programs. If
you wish to change the application that your compiled ESQL/Module-SQL object
modules will link to, you must follow the static linking procedure in "Portable
Embedded and Module Language SQL Programs" in 3.2.2.10.

If the RDMS transaction program uses DPS 2200 functions, you can build a user-
defined library search chain that ensures that the file containing the desired version of
DPS 2200 is included in the library search chain for the desired application group. See
4.5 for information on how to build such a search chain for application group seven. If
this search chain is used, the LINK$PF statement is as follows:
@USE LINK$PF,SYS$LIB$*APP$7DPS.

For more information on these library search chains, see Section 4.

7831 4077–009 5–117

Application Programming in a TIP Environment

You must statically link a UCS transaction program containing RDMS 2200 statements.
The following steps are involved:
1. Specify use of the appropriate application group library search chain using an
@USE LINK$PF statement.
2. Call the LINK Processor (@LINK).
3. Specify static-linking commands, including a command that identifies the
program's compiler-produced object module.
The output of this static link must be a ZOOM.

The following example shows how to statically link a UCS transaction program
containing RDMS 2200 statements, producing a zero overhead object module:

(1) @USE LINK$PF,SYS$LIB$*APP$7.

(2) @LINK ,QUAL*UCSTST.MCBESQ
(3) INCLUDE QUAL*UCSTST.MCBESQ/COMP
(4) RESOLVE ALL REFERENCES USING LIBCODENAME
(5) PROCESS FOR EXTENDED FAST LOAD
(6) DELETE ALL DEFINITIONS EXCEPT START$
(7) @EOF

Explanation
1. This statement ensures that the program is statically linked using the RDMS 2200
software located in the desired application group. (It ensures that the library
search chain for the correct application group is used.) In this example, this
program is to execute in application group 7. Any embedded SQL or module SQL
programs input to this static link must also have been compiled for this application
group.
2. If DPS 2200 functions are used in the transaction, use the search chain built in
4.5.1.
3. This statement calls the Linking System LINK Processor. The ZOOM to be
produced is named QUAL*UCSTST.MCBESQ.
4. This command identifies the compiler-generated object module containing the
UCS RDMS 2200 program.
5. This command resolves external references, including those to the UCS Runtime
System library.
6. This command merges banks and attempts to produce a fast-load ZOOM;
otherwise a standard ZOOM is created.

5–118 7831 4077–009

 Application Programming in a TIP Environment

7. This command deletes all definitions except the program's starting address,
START$. This decreases the size of the ZOOM.
8. This statement ends static linking.

5.2.2.7. Example of a UCS COBOL Transaction Program Containing

RDMS 2200 Statements
The following pages show an example that compiles, links, and executes a UCS
COBOL embedded SQL program that uses MCB functions.

The MCBESQ program following shows the simple UCS MCB RDMS 2200 transaction
program used in the examples on the following pages. The program
1. Initializes with TIP
2. Reads an employee number
3. Accesses information about that individual from the RDMS 2200 database
4. Displays the data
5. Terminates with TIP

MCBESQ
IDENTIFICATION DIVISION.
PROGRAM-ID. MCBESQ INITIAL.
.
.
DATA DIVISION.
WORKING-STORAGE SECTION.
table definitions
.
.
.
01 EMPLOYEE-NUMBER ....
PROCEDURE DIVISION.
MCB INITIALIZATION
READ EMPLOYEE-NUMBER
BEGIN THREAD
USE DEFAULT QUALIFIER
SINGLETON SELECT
MOVE DATA TO OUTPUT MESSAGE
DECLARE CURSOR
OPEN CURSOR
FETCHs ....
MOVE DATA TO OUTPUT MESSAGE
END THREAD
SEND OUTPUT MESSAGE
MCB TERMINATION
STOP RUN.

7831 4077–009 5–119

Application Programming in a TIP Environment

Source Listing of the Embedded SQL Transaction Program (MCBESQ)

Example 5–22 shows the complete source listing of the MCB embedded SQL COBOL
transaction program MCBESQ. This program reads an employee number as input and
displays the information contained in the database about the individual's family in an
output message.

In this example, the program resides in element QUAL*UCSTST.MCBESQ/RDMS.

Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. MCBESQ INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE TIP COBOL MCB RDMS ESQL PROGRAM - MCBESQ *
* *
* initializes with MCB *
* reads the input employee number *
* moves the employee number to the output message *
* begins thread with UDS *
* retrieves the requested information from the RDMS database *
* moves the RDMS information to the output message *
* ends thread with UDS *
* sends the output message *
* terminates with MCB *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER
SYMBOLIC CHARACTERS EXT IS 4.
DATA DIVISION.
WORKING-STORAGE SECTION.
************************************************************
* WORK AREA BUFFERS
************************************************************
01 IN-TEXT PIC X(60) VALUE SPACES.
01 TRAN-CODE PIC X(6) VALUE SPACES.
************************************************************
* BUFFER TO HOLD EMPLOYEE NUMBER INPUT
************************************************************

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–120 7831 4077–009

 Application Programming in a TIP Environment

01EMPLOYEE-TEXT VALUE SPACES.

02 EMPLOYEE-NUMBER PIC X(5).
02 FILLER PIC X(55).
************************************************************
* UNSTRING COUNTER
************************************************************
01 EMP-COUNT PIC 99 VALUE ZERO.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERROR-MESSAGE PIC X(85) VALUE SPACES.
*
01 ERR-MISSING-INPUT.
* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 24
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
*
01 INVALID-EMPLOYEE-NUMBER.
* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 24
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
02 FILLER PIC X(28) VALUE SPACES.
************************************************************
* MCB PROCEDURE
************************************************************
COPY MCBPKT-UCOB.
************************************************************
* OUTPUT MESSAGE BUFFER
************************************************************
01 OUTPUT-MSG.
* Cursor to home
02 FILLER PIC 1(9) BINARY-1 VALUE 27.

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

7831 4077–009 5–121

Application Programming in a TIP Environment

02 FILLER PIC X(1) VALUE 'e'.

* Erase to end of screen
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC X(1) VALUE 'M'.
* Line 1 Column 1 - Start protection
02 FILLER PIC 1(9) BINARY-1 VALUE 31.
02 FILLER PIC X(2) VALUE SPACES.
02 FILLER PIC X(1) VALUE '<'.
02 FILLER PIC X(1) VALUE '3'.
* Line 1
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(33)
VALUE '******** INDIVIDUAL DATA ********'.
* Line 3
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"!'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(17) VALUE 'EMPLOYEE NUMBER: '.
02 OUT-EMP-NUMBER PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"='.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(6) VALUE 'NAME: '.

02 OUT-IND-FIRST-NAME PIC X(12) VALUE SPACES.

02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '"P'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-IND-LAST-NAME PIC X(20) VALUE SPACES.
* Line 6
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '%$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(30)
VALUE '*** DEPARTMENT INFORMATION ***'.
* Line 7
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '&-'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–122 7831 4077–009

 Application Programming in a TIP Environment

02 FILLER PIC X(6) VALUE 'NAME: '.

02 OUT-DEPT-NAME PIC X(24) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '&O'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(8) VALUE 'NUMBER: '.
02 OUT-DEPT-NO PIC X(4) VALUE SPACES.
* Line 8
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "')".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(10) VALUE 'FUNCTION: '.
02 OUT-DEPT-DESCRIPTION PIC X(56) VALUE SPACES.
* Line 10
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE ")$".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(23)
VALUE '*** JOB INFORMATION ***'.
* Line 11
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "*,".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(7) VALUE 'TITLE: '.
02 OUT-JOB-TITLE PIC X(20) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "*O".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(17) VALUE 'YEARLY SALARY: $ '.
02 OUT-JOB-SALARY PIC X(5) VALUE SPACES.
* Line 12
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE "+)".
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 FILLER PIC X(10) VALUE 'FUNCTION: '.
02 OUT-JOB-DESCRIPTION PIC X(50) VALUE SPACES.
* Line 15
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '.$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

7831 4077–009 5–123

Application Programming in a TIP Environment

02 OUT-SPORTS-ACTION PIC X(71) VALUE SPACES.

* Line 16
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '/3'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME1 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '/>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE1 PIC X(13) VALUE SPACES.
* Line 17
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '03'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME2 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '0>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE2 PIC X(13) VALUE SPACES.
* Line 18
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '13'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-NAME3 PIC X(10) VALUE SPACES.
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '1>'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-SPT-LEAGUE-TYPE3 PIC X(13) VALUE SPACES.
* Line 20
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '3$'.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
02 OUT-CHILDREN PIC X(16) VALUE '*** CHILDREN ***'.
* Line 21-23
02 LINE21-23 OCCURS 3 TIMES.
05 FILLER PIC 1(9) BINARY-1 VALUE 27.
05 FILLER PIC 1(9) BINARY-1 VALUE 11.
05 OUT-FIRST-ROW PIC X(1) VALUE '4'.
05 FILLER PIC X(1) VALUE '3'.
05 FILLER PIC 1(9) BINARY-1 VALUE 15.

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–124 7831 4077–009

 Application Programming in a TIP Environment

05 OUT-CHILD-FIRST-NAME PIC X(12) VALUE SPACES.

05 FILLER PIC 1(9) BINARY-1 VALUE 27.
05 FILLER PIC 1(9) BINARY-1 VALUE 11.]
05 OUT-LAST-ROW PIC X(1) VALUE '4'.
05 FILLER PIC X(1) VALUE '@'.
05 FILLER PIC 1(9) BINARY-1 VALUE 15.
05 OUT-CHILD-LAST-NAME PIC X(20) VALUE SPACES.
* Line 24 Column 1 - Cursor position
02 FILLER PIC 1(9) BINARY-1 VALUE 27.
02 FILLER PIC 1(9) BINARY-1 VALUE 11.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC 1(9) BINARY-1 VALUE 15.
* Line 24 Column 1 - End protection
02 FILLER PIC 1(9) BINARY-1 VALUE 31.
02 FILLER PIC X(2) VALUE '7 '.
02 FILLER PIC X(1) VALUE '<'.
02 FILLER PIC X(1) VALUE '0'.
************************************************************
* RDMS WORK AREA SIZE
************************************************************
01 WORK-AREA-SIZE PIC 1(36) USAGE BINARY-1 VALUE 2000.
************************************************************
* UDS THREAD STATUS FLAG
************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 INDR-LAST-NAME PIC X(20).
01 INDR-FIRST-NAME PIC X(12).
01 CHILD-LAST-NAME PIC X(20).
01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* ESQL STATEMENT STATUS
************************************************************
01 SQLSTATE PIC X(5).
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.

EXEC SQL END DECLARE SECTION END-EXEC.

************************************************************
* GETERROR BUFFERS

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

7831 4077–009 5–125

Application Programming in a TIP Environment

************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************
01 ERR-INDEX PIC 9.
************************************************************
* ALLERROR INDICATOR
************************************************************
01 xx PIC 9 VALUE 0.
88 ALLERR VALUE 1.
************************************************************
* COUNTER FOR CHILDREN
************************************************************
01 CHILD-COUNT PIC 9(1) VALUE 0.
************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
*
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH MCB
* READ OF THE INPUT MESSAGE
************************************************************
MCB-INITIALIZATION.
MOVE SPACES TO P-TRXBUFF.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE 2 TO P-NODE.
MOVE 1 TO P-LVL.
MOVE P-TRINIT TO P-FUNC.
MOVE 1820 TO P-LENGTH.
MOVE 4 TO P-AUX.
CALL 'MCB$ENT'USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
************************************************************
* EXTRACTING THE EMPLOYEE NUMBER FROM THE INPUT MESSAGE
* VALIDATING THE EMPLOYEE NUMBER
************************************************************
MCB-INPUT-MESSAGE-ANALYSIS.
MOVE P-TRXBUFF (P-AUXTXN:60) TO IN-TEXT.
UNSTRING IN-TEXT DELIMITED BY ALL SPACES
INTO TRAN-CODE, EMPLOYEE-TEXT COUNT IN EMP-COUNT.
IF EMPLOYEE-TEXT (1:1) = EXT

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–126 7831 4077–009

 Application Programming in a TIP Environment

MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE

PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE IF EMP-COUNT NOT EQUAL 5 OR
EMPLOYEE-NUMBER IS NOT NUMERIC
MOVE EMPLOYEE-TEXT (1:10) TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE OUTPUT MESSAGE
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO OUT-EMP-NUMBER.
************************************************************
* RDMS - SETS UP RDMS WORK AREA
* SETS UP RDMS GENERAL ERROR HANDLING
************************************************************
RDMS-SETUP.
CALL 'RSA$INIT'USING WORK-AREA-SIZE.
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
* SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
************************************************************
BEGIN-THREAD-TO-UDS.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
MOVE 1 TO THREAD-FLAG.
EXEC SQL
USE DEFAULT QUALIFIER FAMILYTIP
END-EXEC.
************************************************************
* SINGLETON SELECT OF THE INDIVIDUAL'S DATA
************************************************************
SINGLETON-SELECT-INDRDATA.
EXEC SQL
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :INDR-LAST-NAME, :INDR-FIRST-NAME
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :EMPLOYEE-NUMBER
END-EXEC.
IF SQLSTATE = "02000"

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

7831 4077–009 5–127

Application Programming in a TIP Environment

MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO

MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM END-THREAD-TO-UDS
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF.
************************************************************
* MOVE THE INDIVIDUAL INFORMATION TO THE OUTPUT MESSAGE
************************************************************
MOVE-INDIVIDUAL-DATA.
MOVE INDR-LAST-NAME TO OUT-IND-LAST-NAME.
MOVE INDR-FIRST-NAME TO OUT-IND-FIRST-NAME.
************************************************************
* DEFINE THE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN THE CURSOR
* RETRIEVE DATA FROM THE CURSOR
* MOVE THE CHILD INFORMATION TO THE OUTPUT MESSAGE
************************************************************
RDMS-SETUP-CHILDDATA-CURSOR.
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMPLOYEE-NUMBER
END-EXEC.
EXEC SQL
OPEN CHILDDATA
END-EXEC.
RDMS-FETCH-MOVE-CHILD-DATA.
PERFORM WITH TEST AFTER UNTIL SQLSTATE = "02000"
OR CHILD-COUNT = 3
EXEC SQL
FETCH NEXT CHILDDATA INTO
:CHILD-LAST-NAME, :CHILD-FIRST-NAME
END-EXEC
IF SQLSTATE NOT = "02000"
ADD 1 TO CHILD-COUNT
MOVE CHILD-FIRST-NAME
TO OUT-CHILD-FIRST-NAME (CHILD-COUNT)
MOVE CHILD-LAST-NAME
TO OUT-CHILD-LAST-NAME (CHILD-COUNT)
END-IF
END-PERFORM.
IF CHILD-COUNT = 0 MOVE SPACES TO OUT-CHILDREN.
MOVE '4'TO OUT-FIRST-ROW (1), OUT-LAST-ROW (1).
MOVE '5'TO OUT-FIRST-ROW (2), OUT-LAST-ROW (2).

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–128 7831 4077–009

 Application Programming in a TIP Environment

MOVE '6'TO OUT-FIRST-ROW (3), OUT-LAST-ROW

***********************************************************
* TERMINATE WITH THE DATABASE SYSTEMS
************************************************************
END-THREAD-TO-UDS.
END THREAD.
MOVE 0 TO THREAD-FLAG.
************************************************************
* SENDS THE OUTPUT MESSAGE
************************************************************
MCB-SEND-MESSAGE.
MOVE 0 TO P-MCB-STATUS.
MOVE P-SENDD TO P-FUNC.
MOVE 0 TO P-ID.
MOVE 769 TO P-LENGTH.
MOVE 1 TO P-START.
MOVE 63 TO P-AUX.
MOVE 1 TO P-BIT2.
MOVE 1 TO P-BIT0.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, OUTPUT-MSG.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
************************************************************
* TIP TERMINATION WITH MCB
* PROGRAM TERMINATION
************************************************************
TERMINATION-PARA.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
STOP RUN.
*
*
************************************************************
* RDMS - RETURN AN ERROR MESSAGE TO THE PRINTER FILE IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY '***SQLSTATE = 'SQLSTATE UPON PRINTER.
DISPLAY '***RDMCA AUX-INFO = 'AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = 'ERROR-STATUS OF RDMCA
UPON PRINTER.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

7831 4077–009 5–129

Application Programming in a TIP Environment

EXEC SQL
GETERROR INTO :ERR(1),:ERR(2),:ERR(3),:ERR(4),:ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END PERFORM.
PERFORM END-THREAD-TO-UDS.
PERFORM TERMINATION-PARA.
*
************************************************************
* RETURNS AN ERROR MESSAGE IF THE INPUT MESSAGE WAS IN ERROR
************************************************************
************************************************************
INVALID-INPUT-PARA.

MOVE 0 TO P-MCB-STATUS.
MOVE P-SENDD TO P-FUNC.
MOVE 0 TO P-ID.
MOVE 85 TO P-LENGTH.
MOVE 1 TO P-START.
MOVE 4 TO P-AUX.
MOVE 0 TO P-FLAGS.
MOVE 1 TO P-BIT0.
CALL 'MCB$ENT'USING P-MCB-PACKET, P-MCB-STATUS,
ERROR-MESSAGE.
IF P-STATBIT NOT EQUAL ZERO GO TO MCB-ERROR-EXIT.
*
*
************************************************************
* ONLY EXECUTED WHEN A MCB ERROR OCCURS
************************************************************
MCB-ERROR-EXIT.
DISPLAY '********* MCB ERROR *********'UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = 'P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = 'P-ERRCODE UPON PRINTER.
DISPLAY 'ERROR CODE Q3 = 'P-ERRCODEQ3 UPON PRINTER.
DISPLAY 'ERROR CODE Q4 = 'P-ERRCODEQ4 UPON PRINTER.
IF THREAD-FLAG = 1 PERFORM END-THREAD-TO-UDS.
MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 5–22. Source Listing of the Embedded SQL Transaction Program

(QUAL*UCSTST.MCBESQ/RDMS)

5–130 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–23 shows the source listing of a runstream used to compile, link, and set
up the example transaction program MCBESQ. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . ***
@ . *** COMPILE OF THE MCB RDMS ESQL COBOL TRANSACTION PROGRAM
@ . ***
@UCOB QUAL*UCSTST.MCBESQ/RDMS,QUAL*UCSTST.MCBESQ/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'MCBESQ'.
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@LINK ,QUAL*UCSTST.MCBESQ
INCLUDE QUAL*UCSTST.MCBESQ/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL*
VALCHG M
945 NAM,MCBESQ ACT,MCBESQ PRG,3 STF,0 QPR,1 STA,J OPT,TV
945 REC,Z AUD,7 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY

Example 5–23. Runstream to Compile, Link, and Execute—COBOL MCB ESQL

Transaction Program

7831 4077–009 5–131

Application Programming in a TIP Environment

OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY MCBESQ FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810

Example 5–23. Runstream to Compile, Link, and Execute—COBOL MCB

ESQL Transaction Program

5–132 7831 4077–009

 Application Programming in a TIP Environment

EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–23. Runstream to Compile, Link, and Execute—COBOL MCB

ESQL Transaction Program

Execution of the Source Runstream

Example 5–24 shows the execution of the source runstream used to compile, link, and
set up this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . ***
@ . *** COMPILE OF THE MCB RDMS ESQL COBOL TRANSACTION PROGRAM
@ . ***
@UCOB QUAL*UCSTST.MCBESQ/RDMS,QUAL*UCSTST.MCBESQ/COMP,,, ;
NO-OPTIONS,APPLICATION/APPSVN
UCOB- 6R2 (940210) LSS- 8R2 (940209) 940217 12:55:43
SIZES: CODE(EM6): 1554 DATA: 1335
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING (LEVEL)
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'MCBESQ'.
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.MCBESQ
LINK 5R2 (940207 1635:57) 1994 Feb 17 Thu 1255:54
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.

Example 5–24. Execution of Source Runstream—COBOL MCB ESQL Transaction

Program

7831 4077–009 5–133

Application Programming in a TIP Environment

@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940217 1256:00
*VALCHG M

KEYWORDS FOR VALTAB FIELDS

LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

945 NAM,MCBESQ ACT,MCBESQ PRG,3 STF,0 QPR,1 STA,J OPT,TV

945 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 945 TRANSACTION CODE: MCBESQ
NAM: MCBESQ RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
*** CHANGED VALTAB ***
PROGRAM NUMBER: 945 TRANSACTION CODE: MCBESQ
NAM: MCBESQ RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1556:01

Example 5–24. Execution of Source Runstream—COBOL MCB ESQL

Transaction Program

5–134 7831 4077–009

 Application Programming in a TIP Environment

OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940217 1556:01
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1556:01
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 12:56:02 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 12:56:02 17 FEB 94
TP REGISTER FINISHED 12:56:04 17 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:56:04 17 FEB 94
TP RESERVE FINISHED 12:56:04 17 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER

Example 5–24. Execution of Source Runstream—COBOL MCB ESQL

Transaction Program

7831 4077–009 5–135

Application Programming in a TIP Environment

RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0

FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-17 1256:05
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY MCBESQ FROM QUAL*UCSTST TO 810
Program MCBESQ copied to TIP file 810 in ZOOM fast-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: MCBESQ TIP Program File: 810

Element Format: ZOOM fast-load Created on: 94-02-17 1255:59
Record Number: 2 Area Size: 268 records
Start Address: 400004001070 Program Mode: 3rd,NA,64-Gran
Program Number: 945
Bank Index: 3,1 2,5 2,6 2,4
Bank Type: EM, D-bank EM, D-bank BM, D-bank EM,I-bank
Lower Limit: 050000 060000 100000 001000
Bank Size: 002504 027531 300000 007506
GAP/SAP: RW/RW RW/RW ERW/ERW ER/ER

Processing completed successfully for LIST

EXIT
SUPUR Processor Terminated. Date-Time: 94-02-17 1256:08
@ .
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–24. Execution of Source Runstream—COBOL MCB ESQL

Transaction Program

5–136 7831 4077–009

 Application Programming in a TIP Environment

Execution of the MCB ESQL COBOL Transaction Program

The following screens show the execution of an MCB ESQL COBOL transaction
program. User input is bolded.

>MCBESQ 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY:
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

STEVEN JR FIELDING
DANIEL FIELDING
JANE FIELDING

7831 4077–009 5–137

Application Programming in a TIP Environment

Example of a UCS C Transaction Program Containing RDMS 2200 Statements

The following pages show an example that compiles, links, and executes a UCS C
embedded SQL program that uses DPS 2200 functions.

The DPSESQ program following shows the simple UCS DPS RDMS 2200 transaction
program used in the examples on the following pages. The program
• Initializes with DPS
• Reads an employee number
• Accesses information about that individual from RDMS 2200 database
• Displays the data
• Terminates with DPS
DPSESQ
.
.
.
table definitions
.
.
.
char employee_number[5];
.
.
.
int main(void)
{
DPS INITIALIZATION
READ employee_number
BEGIN TRHREAD
USE DEFAULT QUALIFIER
SINGLETON SELECT
strncpy DATA TO DPS FORM
DECLARE CURSOR
OPEN CURSOR
FETCHs ...
strncpy DATA TO DPS FORM
END THREAD
SEND DPS FORM
DPS TERMINATION
return(0);
}

5–138 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of the Embedded SQL Transaction Program (DPSESQ)

Example 5–25 shows the complete source listing of the DPS Embedded SQL C
transaction program DPSESQ.

This program reads an employee number as input and displays the information
contained in the database about the individual's family in an output message.

In this example, the program resides in element QUAL*UCSTST.DPSESQ/RDMS

Noteworthy lines are bolded.

/* ***************************************************************
* *
* SIMPLE TIP C DPS ESQL PROGRAM - DPSESQ *
* *
* initializes with DPS *
* reads the input employee number *
* opens the DPS form *
* moves the employee number to the form *
* begins thread with UDS *
* retrieves the requested information from the database*
* moves the RDMS information to the DPS form *
* ends thread with UDS *
* displays the DPS form *
* terminates with DPS *
* *
*************************************************************** */
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <rsa.h>
#include <dpsfunc-def.h>
#include <dps-stat-def.h>
#include <info-buf-def.h>
#include <get-fld-def.h>
#include <senderr-def.h>
#include "screen-50.h"
/* ************************************************************
* EMPLOYEE NUMBER INPUT ERROR MESSAGE *
************************************************************ */
char err_employee_number[41];
/* ************************************************************
* ESQL STATEMENT STATUS *
************************************************************ */
char SQLSTATE[6];
#define NO_FIND_STATUS "02000"

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

7831 4077–009 5–139

Application Programming in a TIP Environment

/* ************************************************************
* RDMS WORK AREA SIZE *
************************************************************ */
int work_area_size = 2000;
/* ************************************************************
* UDS THREAD STATUS FLAG *
************************************************************ */
int thread_flag = 0;
/* ************************************************************
* RELATIONAL DATABASE INFORMATION *
************************************************************ */
EXEC SQL BEGIN DECLARE SECTION;
char employee_number[6];
char indr_last_name[21];
char indr_first_name[13];
char child_last_name[21];
char child_first_name[13];
EXEC SQL END DECLARE SECTION;

int main(void)
{
int i;
/* ************************************************************
* TIP INITIALIZATION WITH DPS *
************************************************************ */
d_init(&dps_status, &info_buffer);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER *
* RETURNS THE EMPLOYEE NUMBER *
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT *
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH *
* GETFIELD-TYPE = 3 - TESTS FIELD TYPE *
************************************************************ */
d_getfl(&dps_status, &get_field);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_getfl(&dps_status, &get_field);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
strncpy(employee_number, get_field.getfield_text,
sizeof(employee_number));
if(get_field.u_1.s_1.getfield_type == 1)
{ strcpy(error_message.error_text,
"NO EMPLOYEE NUMBER WAS SPECIFIED");
d_senderr(&dps_status, &error_message, &error_coordinates);

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

5–140 7831 4077–009

 Application Programming in a TIP Environment

if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
return(0);
}
else
{ if((get_field.u_1.s_1.getfield_length != 5) ||
(get_field.u_1.s_1.getfield_type != 3))
{ strncpy(err_employee_number,
get_field.getfield_text, sizeof(err_employee_number));
err_employee_number[40] = '\0';
sprintf(error_message.error_text,
"NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER %s",
err_employee_number);
d_senderr(&dps_status, &error_message, &error_coordinates);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();

return(0);
}
}
/* ************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER *
************************************************************ */
d_open(&dps_status, &screen_dsplyind_50);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION *
************************************************************ */
strncpy(screen_dsplyind_50.screen_dsplyind_50_data.s50_emp_number,
get_field.getfield_text,
sizeof(screen_dsplyind_50.screen_dsplyind_50_data.s50_emp_number));
/* ************************************************************
* RSA WORK AREA SIZE
************************************************************ */
rsa_init (&work_area_size);
/* ************************************************************
* GENERAL ERROR PROCESSING FOR A NEGATIVE SQL ERROR

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

7831 4077–009 5–141

Application Programming in a TIP Environment

************************************************************ */
EXEC SQL WHENEVER SQLERROR GO TO: HANDLE_SQL_ERROR;
/* ************************************************************
* INITIALIZE WITH THE DATABASE SYSTEM
* SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
************************************************************ */
EXEC SQL BEGIN THREAD CDSPDATA FOR APPSVN RETRIEVE;
thread_flag = 1;
EXEC SQL USE DEFAULT QUALIFIER FAMILYTIP;
/* ************************************************************
* SINGLETON SELECT OF THE INDIVIDUAL'S DATA
************************************************************ */
EXEC SQL
SELECT INDR_LAST_NAME, INDR_FIRST_NAME
INTO :indr_last_name, :indr_first_name
FROM INDIVIDUALR
WHERE INDIVIDUALR.INDR_EMP_NUMBER = :employee_number;
if (strcmp(SQLSTATE, NO_FIND_STATUS) == 0)
{ sprintf(error_message.error_text,
"NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER: %s",
employee_number);
d_senderr(&dps_status, &error_message, &error_coordinates);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
EXEC SQL END THREAD;
thread_flag = 0;
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
return(0);
}
else {
strncpy
(screen_dsplyind_50.screen_dsplyind_50_data.s50_ind_last_name,
indr_last_name, sizeof(screen_dsplyind_50.
screen_dsplyind_50_data.s50_ind_last_name));
strncpy
(screen_dsplyind_50.screen_dsplyind_50_data.s50_ind_first_name,
indr_first_name, sizeof(screen_dsplyind_50.
screen_dsplyind_50_data.s50_ind_first_name));
}
/* ************************************************************
* DEFINE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN CURSOR
************************************************************ */
EXEC SQL

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

5–142 7831 4077–009

 Application Programming in a TIP Environment

DECLARE CHILDDATA CURSOR

SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :employee_number;
EXEC SQL OPEN CHILDDATA;
/* ************************************************************
* RETRIEVE DATA FROM THE CURSOR
************************************************************ */
i=0;
while(1)
{ EXEC SQL
FETCH NEXT CHILDDATA INTO :child_last_name, :child_first_name;
if (strcmp(SQLSTATE, NO_FIND_STATUS) != 0)
{ strncpy(screen_dsplyind_50.screen_dsplyind_50_data.
s50_child_index_data[i].s50_child_last_name,
child_last_name,
sizeof(screen_dsplyind_50.screen_dsplyind_50_data.
s50_child_index_data[i].s50_child_last_name));
strncpy(screen_dsplyind_50.screen_dsplyind_50_data.
s50_child_index_data[i].s50_child_first_name,
child_first_name,
sizeof(screen_dsplyind_50.screen_dsplyind_50_data.
s50_child_index_data[i].s50_child_first_name));
i++;
}
else break;
}
if (i == 0)
screen_dsplyind_50.screen_dsplyind_50_fca.
screen_dsplyind_50_fca_def.s50_children_on_dyn = 'C';
/* ************************************************************
* TERMINATE WITH THE DATABASE SYSTEM
************************************************************ */
EXEC SQL END THREAD;
thread_flag = 0;
/* ************************************************************
* SENDS THE SCREEN TO THE USER *
************************************************************ */
d_send(&dps_status, &screen_dsplyind_50);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
/* ************************************************************
* TERMINATION OF THE PROGRAM *
************************************************************ */
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

7831 4077–009 5–143

Application Programming in a TIP Environment

return(0);
/* ************************************************************
* RETURN AN ERROR MESSAGE ON THE PRINTER IF A
* DATABASE ERROR OCCURS
************************************************************ */
HANDLE_SQL_ERROR:
handle_sqlerror();
return(0);
}
void handle_sqlerror(void)
{
char msg[133];
EXEC SQL WHENEVER SQLERROR CONTINUE;
printf("***SQLSTATE = %p\n", SQLSTATE);
printf("GETERROR returned the following text for SQLSTATE:\n\n");
do{
EXEC SQL GETERROR INTO :msg;
printf("%s\n",msg);
} while(msg[0] != '\0');
EXEC SQL END THREAD;
thread_flag = 0;
d_term(&dps_status);
if(dps_status.status_word.status_indicator == STATUS_FATAL)
error_exit();
}
/* ************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS *
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF *
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO *
* TO A DPS INTERNAL ERROR. *
************************************************************ */
void error_exit(void)
{
d_dump();
d_errmsg(&dps_status);
if(thread_flag == 1)
{ EXEC SQL END THREAD;
thread_flag = 0;
d_term(&dps_status);
}
exit(1);
}

Example 5–25. Source Listing of the Embedded SQL Transaction Program

(DPSESQ)

5–144 7831 4077–009

 Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–26 shows the source listing of a runstream used to compile, link, and setup
the example transaction program DPSESQ. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** COMPILE OF THE DPS RDMS ESQL C TRANSACTION PROGRAM
@ . ***
@USE C$PF,APP7*DPS.
@UC QUAL*UCSTST.DPSESQ/RDMS,QUAL*UCSTST.DPSESQ/COMP,,,NO-OPTIONS, ;
APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSESQ'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK ,QUAL*UCSTST.DPSESQ
INCLUDE QUAL*UCSTST.DPSESQ/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
948 NAM,DPSESQ ACT,DPSESQ PRG,3 STF,0 QPR,1 STA,J OPT,TV
948 REC,Z AUD,7 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING

7831 4077–009 5–145

Application Programming in a TIP Environment

Example 5–26. Runstream to Set Up Transaction Program DPSESQ

ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY DPSESQ FROM QUAL*UCSTST TO 810
ONLINE 810

Example 5–26. Runstream to Set Up Transaction Program DPSESQ

5–146 7831 4077–009

 Application Programming in a TIP Environment

LIST ALL FROM 810

EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–26. Runstream to Set Up Transaction Program DPSESQ

Execution of the Source Runstream

Example 5–27 shows the execution of the source runstream used to compile, link, and
setup this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** ******** START OF THE EXAMPLE EXECUTION SECTION ******************
@ . ***
@ . *** COMPILE OF THE DPS RDMS ESQL C TRANSACTION PROGRAM
@ . ***
@USE C$PF,APP7*DPS.
I:002333 USE complete.
@UC QUAL*UCSTST.DPSESQ/RDMS,QUAL*UCSTST.DPSESQ/COMP,,,NO-OPTIONS, ;
APPLICATION/APPSVN
UC- 4R2(940208) LSS- 8R2(940209) 940227 22:33:56
SIZES: CODE(EM6): 1075 DATA: 1438
END UC- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING(LEVEL)
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSESQ'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DPSESQ
LINK 5R2 (940207 1635:57) 1994 Feb 27 Sun 2234:48
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP

Example 5–27. Execution of Source Runstream—COBOL DPSESQ Transaction

Program

7831 4077–009 5–147

Application Programming in a TIP Environment

@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940227 2235:18
*VALCHG M

KEYWORDS FOR VALTAB FIELDS

LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

948 NAM,DPSESQ ACT,DPSESQ PRG,3 STF,0 QPR,1 STA,J OPT,TV

948 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 948 TRANSACTION CODE: DPSESQ
NAM: DPSESQ RUN: 60 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET TCA: 0
*** CHANGED VALTAB ***
PROGRAM NUMBER: 948 TRANSACTION CODE: DPSESQ
NAM: DPSESQ RUN: 60 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0

Example 5–27. Execution of Source Runstream—COBOL DPSESQ

Transaction Program

5–148 7831 4077–009

 Application Programming in a TIP Environment

AUD: 7 REC:Z QPR: 1 MAS: NONE SET TCA: 0

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940227 2235:19
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940227 2235:20
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940227 2235:20
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/27/94 22:35:21 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 22:35:21 27 FEB 94
TP REGISTER FINISHED 22:35:22 27 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 22:35:22 27 FEB 94
TP RESERVE FINISHED 22:35:22 27 FEB 94
LFD 810

Example 5–27. Execution of Source Runstream—COBOL DPSESQ

Transaction Program

7831 4077–009 5–149

Application Programming in a TIP Environment

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-27 2235:23
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY DPSESQ FROM QUAL*UCSTST TO 810
Program DPSESQ copied to TIP file 810 in ZOOM fast-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: DPSESQ TIP Program File: 810

Element Format: ZOOM fast-load Created on: 94-02-27 2235:11
Record Number: 2 Area Size: 446 records
Start Address: 400004001005 Program Mode: 3rd, NA, 64-Gran
Program Number: 948
Bank Index: 3,1 2,5 2,6 2,4
Bank Type: EM, D-bank EM, D-bank BM, D-bank EM, I-bank
Lower Limit: 050000 060000 100000 001000
Bank Size: 002642 027663 300000 020763
GAP/SAP: RW/RW RW/RW ERW/ERW ER/ER

Processing completed successfully for LIST

EXIT
SUPUR Processor Terminated. Date-Time: 94-02-27 2235:32
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–27. Execution of Source Runstream—COBOL DPSESQ

Transaction Program

5–150 7831 4077–009

 Application Programming in a TIP Environment

Execution of the DPS ESQL C Transaction Program

The following screens show the execution of a DPS ESQL C transaction program.
User input is bolded.

>DPSESQ 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY:
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

*** CHILDREN ***

STEVEN JR FIELDING
DANIEL FIELDING
JANE FIELDING

7831 4077–009 5–151

Application Programming in a TIP Environment

5.2.3. Using SFS 2200 Databases

The Shared File System (SFS 2200) is a Universal Data System (UDS) software product
that consists of a collection of file access routines. SFS 2200
• Provides shared access to a file by more than one program at a time
• Has all the recovery and locking features provided by the UDS environment

UCS TIP transaction programming first supported SFS for UCS COBOL, UCS FORTRAN,
and UCS C in SB3R1.

UCS TIP transaction programs using SFS 2200 provide access to both of the following
types of UCS COBOL files:
• Relative files
A UCS COBOL relative file is an SFS 2200 direct system data format (DSDF) file.
• Indexed files
A UCS COBOL indexed file is an SFS 2200 multi-indexed sequential access method
(MSAM) file.

UCS TIP transaction programs using SFS 2200 also provide support for direct SDF files
for UCS FORTRAN, and UCS C. In UCS C, direct sequential data files are called binary
files. Table 5-3 shows the SFS 2200 file access methods (file organization methods)
supported for the UCS TIP transaction programs.

Table 5–3. SFS 2200 File Access Methods

Supported for UCS TIP Transaction Programs

UCS COBOL UCS FORTRAN UCS C

Relative Direct Binary

(Direct SDF) (Direct SDF)
Indexed (MSAM)

The SFS 2200 example on the following pages uses an indexed (MSAM) COBOL file
that contains information about an individual's participation in company-organized
sports:
• It is assumed that no individual will participate in more than three sports.
• The SPT-ACTIVE-COUNT field identifies the number of company sports the
individual currently plays.
• The individual's employee number (SPT-EMP-NUMBER) uniquely identifies each
record occurrence.

5–152 7831 4077–009

 Application Programming in a TIP Environment

• A second index exists on the last name of the individual (the last name is stored in
data item SPT-IND-LAST-NAME).

The following is the data definition of the SPORTS record.

FD SPORTSTIP.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).

5.2.3.1. Defining SFS 2200 Files and Storage Areas

In order to set up an SFS 2200 file system, the following steps must occur:
1. Catalog the SFS 2200 files. The following statement catalogs the SPORTS file for
the example in the following subsections.
@CAT,P TIP$SFS*SPORTSTIP.,F/5//5

2. Define the UDS storage areas that map to the SFS 2200 files, using UREP.
• There must be one storage area per SFS 2200 file.
• The DATA-FORMAT attribute for the storage area must have a value of one of
the following:
− DSDF (direct system data format)
− MSAM (multi-indexed sequential access method file)
• The QUALIFIER attribute must be the same as the name of the SCHEMA for
this file.
3. After you define the storage areas, create the file description tables (FDT) required
by UDS by using the PROCESS STORAGE-AREA...INSTALL command.

UCS COBOL and UCS FORTRAN SFS 2200 files require no further processing for
program use. In fact, the same COBOL and FORTRAN SFS 2200 files can be used by
both UCS and non-UCS programs, as long as they do not contain Fieldata characters.

UCS C SFS 2200 (binary) files require one more step in their setup, however. The
additional step is required because C does not have language syntax for specifying an
SFS 2200 file. You must create an external file description for C 2200 files, using the
Define File Processor (DFP), a stand-alone preprocessor. You create this external file
description as a define-file-block omnibus element in a program file. The following
runstream creates this omnibus element in a file called UDS$$SVN*DFP$.

(1) @CAT,P UDS$$SVN*DFP$.

(2) @USE DFP$,UDS$$SVN*DFP$.
(3) @DFP,LE UDS$$SVN*data-file-name.,DFP$.data-file-name

7831 4077–009 5–153

Application Programming in a TIP Environment

(4) SHARE = YES

(5) @EOF

Explanation
1. This statement catalogs a file to hold the define-file-block omnibus element
created by DFP. The file in this example might be used to hold all of the define-
file-block omnibus elements for application group 7.
2. This statement places the @USE name of DFP$ on the file into which DFP is to
place its output. This @USE name is required by the Define File Processor.
3. This statement calls the Define File Processor. The LE options specify that
• A define-file-block omnibus element containing the description of the external
data file is to be built.
• A listing is to be produced.
The first field on the processor call identifies the SFS 2200 data file for which this
block is being built. The second field identifies the file name (which must be DFP$)
and element name (which must be the same as the name of the data file) where
the define-file-block omnibus element is to be placed.
4. This input parameter identifies this file as an SFS 2200 (shared) file.
5. This statement terminates the runstream.

During execution of a UCS C SFS 2200 transaction program, whenever the program
opens an SFS 2200 file, the UCS Runtime System reads the define-file-block. This
means that prior to the fopen command in a UCS C 2200 transaction program, you
must do the following:
1. Assign the program file containing the define-file-block omnibus element to the
run.
2. Give the file an @USE name of DFP$.

This process is necessary so that when an SFS 2200 file is opened, the UCS Runtime
System knows where to locate the define-file-block omnibus element.

The following is an example of the commands required in the UCS C transaction

program prior to the fopen.

system("@ASG,A UDS$$SVN*DFP$.");
system("@USE DFP$,UDS$$SVN*DFP$.");

Remember that a define-file-block is not required by UCS COBOL or UCS FORTRAN

transaction programs.

For more information on SFS 2200 programming, refer to the SFS 2200 Administration
and Support Reference Manual.

For more information on using DFP, refer to the DFP Administration and
Programming Reference Manual.

5–154 7831 4077–009

 Application Programming in a TIP Environment

5.2.3.2. Using UDS/TIP Files

When you use SFS 2200, the storage areas can be defined under TIP file control.

Note: Using TIP file control eliminates much Exec input/output overhead and
eliminates the need for file assignments. Therefore, it is recommended that SFS
2200 databases that will be accessed by TIP transactions be set up using TIP
storage areas. This requires setting up a TIP file for each underlying Exec file.

When you later define the storage areas using UREP, the UDS-TIP-CODE must match
the UDS/TIP file number.

Also, the underlying Exec files must use the qualifier TIP$SFS. If the QUALIFIER
attribute is used in the storage area definition, it must also have the value TIP$SFS.

For more information on setting up TIP files that are to hold SFS 2200 storage areas,
refer to the following documents:
• Repository for ClearPath OS 2200 Administration Guide
• SFS 2200 Administration and Support Reference Manual

5.2.3.3. Example of an SFS 2200 Database Definition

The following pages show an example of an SFS 2200 database definition. For this
example, one indexed (MSAM) file is set up. The file holds information about the
participation of an individual in company-sponsored sports. All employees have a
record occurrence in the file, even if they do not participate in any sport. The storage
area file is a UDS-TIP file.

7831 4077–009 5–155

Application Programming in a TIP Environment

Source Listing of Runstream to Define the SFS 2200 File and Storage Area
Example 5–28 shows the source listing of a runstream used to define the SFS 2200 file
and storage area. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE SFS DATABASE DEFINITION SECTION **********
@ . ***
@ . *** CATALOG: CATALOGS THE DATABASE STORAGE AREA EXEC FILES
@ . *** THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-filename MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P TIP$SFS*SPORTSTIP.,F/5//5

@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE DATABASE STORAGE AREA FILES.
@ . ***
@ . *** 2. RESERVE THE DATABASE STORAGE AREAS FILES.
@ . ***
@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.
@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** TIP$SFS*SPORTSTIP.
@ . ***
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** Assigned TIP-FILE-NUMBER = 2135
@ . ***
@ . *** 2200 + 1 - 2135
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR TIP$SFS*SPORTSTIP = 66
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG TIP$SFS*SPORTSTIP.,FIX
RES,G 66,10,896,,SPORTSTIP,,,WW=P,AUDIT=0,NREC

Example 5–28. Runstream to Define the SFS 2200 File and Storage Area

5–156 7831 4077–009

 Application Programming in a TIP Environment

LFD,G 66
@EOF
@ . ***
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE SFS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD,E ,,APPSVN
CREATE SCHEMA TIP$SFS.
CREATE STORAGE-AREA SPORTSTIP FOR SCHEMA TIP$SFS.
ADD FILE-TYPE IS UDS-TIP.
ADD DATA-FORMAT IS MSAM.
ADD FILE-NAME IS SPORTSTIP.
ADD UDS-TIP-CODE IS 66.
ADD DOMAIN IS UDS.
ADD RECOVERED IS TRUE.
ADD AUDITED IS TRUE.
ADD PAGE-SIZE IS 896.
ADD MAXIMUM-PAGES IS 10.
PROCESS STORAGE-AREA ALL FOR SCHEMA TIP$SFS INSTALL.
EXIT.
@ . ***
@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE SFS DATABASE DEFINITION SECTION *************
@ . ***

Example 5–28. Runstream to Define the SFS 2200 File and Storage Area

7831 4077–009 5–157

Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5–29 shows the execution of the source runstream used to define the SFS
2200 file and storage area for this example. Output has been saved by an @BRKPT
statement. Noteworthy lines are bolded.

@ . ***
@ . *** ******** START OF THE SFS DATABASE DEFINITION SECTION **********
@ . ***
@ . *** CATALOG: CATALOGS THE DATABASE STORAGE AREA EXEC FILES
@ . *** THAT WILL CORRESPOND TO THE TIP FILES.
@ . ***
@ . *** TIP FILES ARE NOT AWARE OF EXEC QUALIFIERS, THEREFORE
@ . *** THE EXEC-FILENAME MUST ESTABLISH UNIQUENESS WITHOUT
@ . *** THE QUALIFIER.
@ . ***
@CAT,P TIP$SFS*SPORTSTIP.,F/5//5
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE DATABASE STORAGE AREA FILES.
@ . ***
@ . *** 2. RESERVE THE DATABASE STORAGE AREAS FILES.
@ . ***
@ . *** 3. LIST THESE TIP FILES IN ORDER TO CONFIRM THEIR SETUP.
@ . ***
@ . *** THE UDS-TIP FILE NUMBERS ARE BACKWARDS FROM THE TIP FILE NUMBERS.
@ . *** THE FOLLOWING EQUATION COORDINATES THE TWO NUMBERS.
@ . ***
@ . ***
@ . *** UDS-TIP-FILE-NUMBER = TPFMAX + 1 - TIP-FILE-NUMBER
@ . ***
@ . *** EXAMPLE: CALCULATING THE UDS-TIP FILE NUMBER FOR
@ . *** TIP$SFS*SPORTSTIP.
@ . ***
@ . *** GIVEN: TPFMAX = 2200 (EXEC CONFIGURATION TAG)
@ . *** ASSIGNED TIP-FILE-NUMBER = 2135
@ . ***
@ . *** 2200 + 1 - 2135
@ . ***
@ . *** UDS-TIP-FILE-NUMBER FOR TIP$SFS*SPORTSTIP = 66
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 13:28:00 FS-LEVEL FS 003

Example 5–29. Execution of Source Runstream—SFS Database Setup

5–158 7831 4077–009

 Application Programming in a TIP Environment

TREG TIP$SFS*SPORTSTIP.,FIX
TP REGISTER STARTED 13:28:00 17 FEB 94
TP REGISTER FINISHED 13:28:01 17 FEB 94
RES,G 66,10,896,,SPORTSTIP,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 13:28:01 17 FEB 94
TP RESERVE FINISHED 13:28:01 17 FEB 94
LFD,G 66
DMS AREA 66
TIP/DMS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 10 SIZE: 896 APPLICATION GROUP: 0
FILE NAME SPORTSTIP
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . ***
@ . *** USE THE UNISYS REPOSITORY TO DEFINE THE SFS STORAGE AREAS
@ . ***
@UDS$$SVN*UREP$ABS.DD,E ,,APPSVN
UREP 3R2 (11/04/93 10:17:39) 02/17/94 13:28:01
1 CREATE SCHEMA TIP$SFS.
2 CREATE STORAGE-AREA SPORTSTIP FOR SCHEMA TIP$SFS.
3 ADD FILE-TYPE IS UDS-TIP.
4 ADD DATA-FORMAT IS MSAM.
5 ADD FILE-NAME IS SPORTSTIP.
6 ADD UDS-TIP-CODE IS 66.
7 ADD DOMAIN IS UDS.
8 ADD RECOVERED IS TRUE.
9 ADD AUDITED IS TRUE.
10 ADD PAGE-SIZE IS 896.
11 ADD MAXIMUM-PAGES IS 10.
12 PROCESS STORAGE-AREA ALL FOR SCHEMA TIP$SFS INSTALL.
*REMARK* DSD4023 The INSTALL for STORAGE-AREA SPORTSTIP VERSION ''for
SCHEMA TIP$SFS was SUCCESSFUL.
*REMARK* DSD4036 Your PROCESS STORAGE-AREA ALL command was successful.
13 EXIT.
END UREP ( 0 )FATALS ( 0 )ERRORS ( 0 )WARNINGS ( 2 )REMARKS .
@ . ***
@ . ***
@ . ***
@ . ***
@ . *** ******** END OF THE SFS DATABASE DEFINITION SECTION *************
@ . ***

Example 5–29. Execution of Source Runstream—SFS Database Setup

7831 4077–009 5–159

Application Programming in a TIP Environment

5.2.3.4. Coding UCS Transaction Programs That Access SFS 2200

Databases
SFS2200 files used by UCS COBOL and UCS FORTRAN require special program syntax
to identify these files as SFS 2200 files.

For UCS C, this is accomplished instead by use of the Define File Processor; refer to
"Defining SFS 2200 Files and Storage Areas" in this subsection. Also, the UCS C
transaction program must assign and place a USE statement on the program file
containing the define-file-block.

UCS COBOL
UCS COBOL identifies SFS 2200 files by using the A-SHARED-FILE syntax in the
SELECT clause. The following SELECT clauses show the syntax for identifying a
relative (DSDF) file and an indexed (MSAM) file for COBOL:

Relative (DSDF) File

SELECT file01 ASSIGN TO A-SHARED-FILE...RELATIVE....

Indexed (MSAM) File

SELECT file02 ASSIGN TO A-SHARED-FILE...INDEXED....

UCS FORTRAN
UCS FORTRAN identifies SFS 2200 files by the RFORM setting in the OPEN statement.
A value of LS, MS, ES, FS, US, or VS identifies the file as an SFS 2200 file. (The "S"
stands for shared.)

The following OPEN statement shows an example of this syntax:

OPEN (UNIT=10,ACCESS='DIRECT',RFORM='ES',RECL=132)

UCS C
In a UCS C transaction program using SFS, the program file containing the
define-file-block must be assigned (@ASG) and given a use name (@USE) of DFP$ prior
to the fopen command. The following is an example:
system ("@ASG,A UDS$$SVN*DFP$.");
system ("@USE DFP$,UDS$$SVN*DFP$.");

5–160 7831 4077–009

 Application Programming in a TIP Environment

5.2.3.5. Explicit Thread Control in UCS SFS 2200 Transaction

Programs
UCS transaction programs that access SFS 2200 databases should use the explicit
thread control commands BEGIN THREAD and END THREAD. The BEGIN THREAD
command must be executed before the SFS file is opened. The END THREAD
command must be executed after the SFS file is closed. If the embedded format of
the BEGIN THREAD and END THREAD commands is used, the
APPLICATION/application-name keyword option should be used on the UCS COBOL or
UCS C compiler call to identify the correct application group software to be used for
parsing these thread control commands.

5.2.3.6. Compiling UCS Transaction Programs That Access SFS 2200

Databases
Compiling a UCS program that accesses an SFS 2200 database is straightforward. You
merely call the appropriate UCS compiler, identify the element containing the source
input, and specify the element to contain the output object module, as usual.

@UCOB . . .
or
@UCOB . . . ,,,APPLICATION/name
UCS SFS or UCS SFS
Source @UCOB . . .,,,COMPAT Object
Program or Module
@UCOB . . . ,,,APPLICATION/name,COMPAT
or
qual*progfile.source @UCOB . . .,,,COMPAT/FULL,NO-OPTIM qual*progfile.om/comp
or
@UCOB . . . ,,,APPLICATION/name,;
COMPAT/FULL,NO-OPTIM
or
@UFTN . . . .
or
@UC . . . .
or
@UC . . . ,,,APPLICATION/ name
002328

7831 4077–009 5–161

Application Programming in a TIP Environment

Only UCS COBOL might require a special keyword option. If the program uses the
ASCII COBOL usage clauses in the file definitions, you must use the COMPAT keyword
option to ensure an error-free compilation.

UCS COBOL and UCS C transaction programs that use the embedded format of the
BEGIN THREAD and END THREAD commands require the correct setting of the
APPLICATION/application-name keyword option.

The following statement shows an example of a compilation:

@UCOB QUAL*UCSTST.DPSSFS,QUAL*UCSTST.DPSSFS/COMP,,,NO-OPTIONS,;
APPLICATION/APPSVN,COMPAT

5.2.3.7. Basic Linking Information for UCS SFS 2200 Transaction

Programs
When statically linking a UCS transaction program that accesses an SFS 2200
database, you must specify use of a special application group library search chain by
using an @USE LINK$PF statement. This library search chain causes the Linking
System to resolve references using the SFS 2200 software for a particular application
group.

The system automatically sets up application group library search chains for each of
the 64 application groups during installation of the Linking System. These library
search chains mean the applications programmer does not have to do either of the
following:
• Build a user-defined library search chain for linking
• Explicitly supply (INCLUDE) the object module containing the SFS 2200 interface
during static linking

The following generic format shows how to specify use of the appropriate application
group library search chain:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the desired application group number.

If you want to link a UCS program that accesses an SFS 2200 database to the system
software in application group 7, use the following statement:
@USE LINK$PF.,SYS$LIB$*APP$7.

In this case, all references to SFS 2200 software would be resolved using
UDS$$SVN*SFS.

5–162 7831 4077–009

 Application Programming in a TIP Environment

If the SFS transaction program uses DPS 2200 functions, you can build a user-defined
library search chain that ensures that the file containing the desired version of DPS
2200 is included in the library search chain for the desired application group. See 4.5.1
for information on how to build a search chain for application group 7. If this search
chain is used, the LINK$PF statement is
@USE LINK$PF,SYS$LIB$*APP$7DPS.

For more information on these library search chains, see Section 4.

You must statically link a UCS transaction program that accesses an SFS 2200
database. The following steps are involved:
1. Specify use of the application group library search chain using an @USE LINK$PF
statement.
2. Call the LINK Processor.
3. Specify static linking commands, including a command that identifies the
program's compiler-produced object module.

The output of the static link must be a ZOOM.

The following example shows how to statically link a UCS transaction program that
accesses an SFS 2200 database, producing a ZOOM:

(1) @USE LINK$PF,SYS$LIB$*APP$7DPS.

(2) @LINK ,QUAL*UCSTST.DPSSFS
(3) INCLUDE QUAL*UCSTST.DPSSFS/COMP
(4) RESOLVE ALL REFERENCES USING LIBCODENAME
(5) PROCESS FOR EXTENDED FAST LOAD
(6) DELETE ALL DEFINITIONS EXCEPT START$
(7) @EOF

7831 4077–009 5–163

Application Programming in a TIP Environment

Explanation
1. This statement ensures that the program is statically linked using the SFS 2200
and DPS 2200 software in the desired application group. This search chain was
built in to include DPS 2200. If MCB functions are used in the transaction instead
of DPS 2200 functions, the application group library search chain, which is supplied
by Unisys, can be used (SYS$LIB$*APP$7). In this example, this program is to
execute in application group 7.
2. This statement calls the Linking System LINK Processor. The ZOOM to be
produced is named QUAL*UCSTST.DPSSFS.
3. This command identifies the compiler-generated object module containing the
UCS program that accesses the SFS 2200 database.
4. This command resolves external references, including those to the UCS Runtime
System library.
5. This command merges banks and attempts to produce a fast load ZOOM,
otherwise a standard ZOOM is created.
6. This command deletes all definitions except the program's starting address,
START$. This decreases the size of the ZOOM.
7. This statement ends static linking.

5.2.3.8. Example of a UCS Transaction Program That Accesses an

SFS 2200 Database
The following subsections show an example of compiling, linking, and executing the
following:
• A batch SFS 2200 database load program
The batch load program uses dynamic linking.
(Due to the length of the load program, its listing is not provided.)
• An SFS 2200 database retrieval transaction program
The retrieval program uses DPS 2200 functions.
The retrieval transaction program is statically linked to produce a zero overhead
object module.

5–164 7831 4077–009

 Application Programming in a TIP Environment

The following figure summarizes the retrieval program used in the example. The
program
1. Initializes with DPS/TIP
2. Reads an employee number as input
3. Accesses information about that individual's sports activities from the SFS 2200
database
4. Displays the data
5. Terminates with DPS/TIP
IDENTIFICATION DIVISION.
PROGRAM-ID. DPSSFS INITIAL.
.
.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file-name
ASSIGN TO A-SHARED-FILE ....
.
.
FILE SECTION.
FD file-name
file definition ....
WORKING-STORAGE SECTION.
01 EMPLOYEE-NUMBER ....
.
.
PROCEDURE DIVISION.
DPS INITIALIZATION
READ EMPLOYEE-NUMBER
BEGIN THREAD
OPEN FILE
READ FILE
MOVE DATA TO OUTPUT FORM
CLOSE FILE
END THREAD
SEND OUTPUT MESSAGE
DPS TERMINATION
STOP RUN.

7831 4077–009 5–165

Application Programming in a TIP Environment

Source Listing of the Transaction Program (DPSSFS)

Example 5–30 shows the complete source listing of the database retrieval transaction
program DPSSFS. This program reads an employee number as input and displays the
information contained in the database about this individual's participation in company
sports in an output message.

In this example, the program resides in element QUAL*UCSTST.DPSSFS. Noteworthy

lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSSFS INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE TIP COBOL DPS SFS PROGRAM - DPSSFS *
* *
* initializes with DPS *
* reads the input data *
* opens the DPS form *
* moves the employee number to the form *
* opens the SPORTSTIP SFS database file *
* retrieves the requested information from the SFS database *
* moves the SFS information to the form *
* closes the SPORTSTIP SFS database file *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SPORTSTIP
ASSIGN TO A-SHARED-FILE SPORTSTIP
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS SPT-EMP-NUMBER
ALTERNATE RECORD KEY IS SPT-IND-LAST-NAME WITH DUPLICATES.
DATA DIVISION.
FILE SECTION.
FD SPORTSTIP.

Example 5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

5–166 7831 4077–009

 Application Programming in a TIP Environment

01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* NO SPORTS MESSAGE
************************************************************
01 NO-SPORTS PIC X(78)
VALUE '*** NO COMPANY-SPONSORED SPORTS PARTICIPATION ***'.
************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
COPY GETFIELD.
COPY SENDERROR.
COPY SCREEN-DSPLYIND-50.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER PIC X(5).
************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
************************************************************
* ESQL STATEMENT STATUS
************************************************************
01 SQLSTATE PIC X(5).
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS

Example 5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

7831 4077–009 5–167

Application Programming in a TIP Environment

************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
************************************************************
* GETERROR BUFFERS
************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************
01 ERR-INDEX PIC 9.
*
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL 'D$INIT'USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE TRANSACTION CODE
************************************************************
DPS-FREE-FORMAT-READ1.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-FREE-FORMAT-READ2.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.

Example 5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

5–168 7831 4077–009

 Application Programming in a TIP Environment

MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.

IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5 OR
GETFIELD-TYPE NOT EQUAL 3
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER
************************************************************
DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* SETS UP GENERAL ERROR HANDLING
************************************************************
ERROR-SETUP.
EXEC SQL
WHENEVER SQLERROR GO TO RDMS-ERROR-PARA
END-EXEC.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEMS
************************************************************
CONNECT-TO-DATABASES.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
OPEN INPUT SPORTSTIP.
************************************************************
* SFS - RETRIEVE THE SPORTS INFORMATION
* MOVE THE SPORTS INFORMATION TO THE DPS FORM
************************************************************

Example 5-30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

7831 4077–009 5–169

Application Programming in a TIP Environment

SFS-RETRIEVE-SPORTS-DATA.
MOVE EMPLOYEE-NUMBER TO SPT-EMP-NUMBER.
READ SPORTSTIP RECORD
KEY IS SPT-EMP-NUMBER
INVALID KEY PERFORM BAD-KEY.
MOVE SPT-IND-FIRST-NAME TO S50-IND-FIRST-NAME.
MOVE SPT-IND-LAST-NAME TO S50-IND-LAST-NAME.
IF SPT-ACTIVE-COUNT = 0
MOVE NO-SPORTS TO S50-SPORTS-ACTION
ELSE PERFORM VARYING I FROM 1 BY 1 UNTIL I > SPT-ACTIVE-COUNT
MOVE SPT-NAME (I) TO S50-SPT-NAME (I)
MOVE SPT-LEAGUE-TYPE (I) TO S50-SPT-LEAGUE-TYPE (I)
END-PERFORM
END-IF.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEMS
************************************************************
SFS-FILE-CLOSE-PARA.
CLOSE SPORTSTIP.
END THREAD.
************************************************************
* SENDS THE SCREEN TO THE USER
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* TERMINATION WITH DPS
************************************************************
DPS-TERMINATION.
CALL 'D$TERM'USING DPS-STATUS.
************************************************************
* PROGRAM TERMINATION
************************************************************
TERMINATION-PARA.
STOP RUN.
*
*
************************************************************
* SFS - DISPLAY OF BAD INPUT KEY
************************************************************
BAD-KEY.
MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO.
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE.

Example 5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

5–170 7831 4077–009

 Application Programming in a TIP Environment

PERFORM INVALID-INPUT-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
*
************************************************************
* RETURNS AN ERROR MESSAGE TO THE USER IF THE INPUT
* MESSAGE WAS IN ERROR AND TERMINATES WITH THE
* TRANSACTION PROCESSING SYSTEM
************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR'USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*
*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO
* TO A DPS INTERNAL ERROR.
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG'USING DPS-STATUS.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
*
************************************************************
* RDMS - RETURN AN ERROR MESSAGE TO THE PRINTER FILE IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY '***SQLSTATE = 'SQLSTATE UPON PRINTER.
DISPLAY '***RDMCA AUX-INFO = 'AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = 'ERROR-STATUS OF RDMCA
UPON PRINTER.
GETERROR INTO :ERR(1), :ERR(2), :ERR(3), :ERR(4), :ERR(5).
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
END-PERFORM.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.

Example 5–30. Source Listing of the Program (QUAL*UCSTST.DPSSFS)

7831 4077–009 5–171

Application Programming in a TIP Environment

Source Listing of Runstream

Example 5–31 shows the source listing of a runstream used to compile, link, and set
up the example program DPSSFS. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE BATCH INITIAL LOAD PROGRAM AND THE TIP TRANSACTION
@ . *** PROGRAM
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADSFSDBTP,QUAL*UCSTST.LOADSFSDBTP/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS SFS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
@UCOB QUAL*UCSTST.DPSSFS,QUAL*UCSTST.DPSSFS/COMP,,,NO-OPTIONS,;
APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
@XQT QUAL*UCSTST.LOADSFSDBTP/COMP

Example 5–31. Runstream to Compile, Link, and Execute—COBOL DPS SFS

Transaction Program

5–172 7831 4077–009

 Application Programming in a TIP Environment

@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSSFS'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK ,QUAL*UCSTST.DPSSFS
INCLUDE QUAL*UCSTST.DPSSFS/COMP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
907 NAM,DPSSFS ACT,DPSSFS PRG,3 STF,0 QPR,1 STA,J OPT,TV
907 REC,Z AUD,7 PRT,LANGPR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE

Example 5–31. Runstream to Compile, Link, and Execute—COBOL DPS

SFS Transaction Program

7831 4077–009 5–173

Application Programming in a TIP Environment

@ . *** SUPUR TIP FILE.

@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY DPSSFS FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810
EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–31. Runstream to Compile, Link, and Execute—COBOL DPS

SFS Transaction Program

5–174 7831 4077–009

 Application Programming in a TIP Environment

Execution of the Source Runstream

Example 5–32 shows the execution of the source runstream used to compile, link, and
set up this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE BATCH INITIAL LOAD PROGRAM AND THE TIP TRANSACTION
@ . *** PROGRAM
@ . ***
@ . ***
@ . *** INITIAL LOAD PROGRAM COMPILE
@ . ***
@UCOB QUAL*UCSTST.LOADSFSDBTP,QUAL*UCSTST.LOADSFSDBTP/COMP,,,NO-OPTIONS
UCOB- 6R2 (940210) LSS- 8R2 (940209) 940217 13:33:35
SIZES: CODE(EM6): 686 DATA: 1026
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13RJ (931109 0108:39) 1994 Feb 17 Thu 1333:50
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 708 Entry Points: 1 Time: 3.958 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS SFS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
I:OO2333 USE complete.
@UCOB QUAL*UCSTST.DPSSFS,QUAL*UCSTST.DPSSFS/COMP,,,COMPAT,NO-OPTIONS,;
APPLICATION/APPSVN
UCOB- 6R2 (940210) LSS- 8R2 (940209) 940217 13:33:57
SIZES: CODE(EM6): 1205 DATA: 380
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING(LEVEL)
@ . ***

Example 5–32. Execution of Source Runstream—COBOL DPS SFS Transaction

Program

7831 4077–009 5–175

Application Programming in a TIP Environment

@ . ***
@ . *** EXECUTION OF THE INITIAL LOAD PROGRAM USING DYNAMIC LINKING
@ . ***
@ . *** THE FOLLOWING STATEMENT SHOULD BE SET UP FOR THE APPROPRIATE
@ . *** APPLICATION GROUP:
@ . *** @USE LINK$PF,SYS$LIB$*APP$n
@ . *** WHERE "n" IS THE APPLICATION GROUP NUMBER
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7.
I:002333 USE complete.
@XQT QUAL*UCSTST.LOADSFSDBTP/COMP

SFS FILE SPORTS OPEN

SPORTS RECORDS ARE LOADED

SFS FILE SPORTS CLOSED

INITIAL LOAD COMPLETED

*******************

DATABASE VALIDATION

*******************

EMPNO FIRST NAME LAST NAME SPORTS PARTICIPATION

----- ------------ -------------------- ---------------------------------

10211 STEVEN FIELDING GOLF VOLLEYBALL

10215 JENNIFER HELLER

10223 KAREN RALSTON GOLF SOFTBALL VOLLEYBALL

24101 MARY ANDERSON TENNIS

26503 RALPH MILLER TENNIS GOLF

26504 JOHN BLAKE TENNIS BOWLING SOFTBALL

26510 GEORGE CARR VOLLEYBALL TENNIS SOFTBALL

32009 JAKE KAISER

****

Example 5–32. Execution of Source Runstream—COBOL DPS SFS

Transaction Program

5–176 7831 4077–009

 Application Programming in a TIP Environment

**** 0008 INDIVIDUAL RECORDS ARE LOADED

DATABASE LOAD HAS BEEN VALIDATED

@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSSFS'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DPSSFS
LINK 5R2 (940207 1635:57) 1994 Feb 17 Mon 1334:36
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940217 1334:40
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH

Example 5-32. Execution of Source Runstream—COBOL DPS SFS

Transaction Program

7831 4077–009 5–177

Application Programming in a TIP Environment

DBKSIZ DBK D-BANK SIZE

AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCABANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

907 NAM,DPSSFS ACT,DPSSFS PRG,3 STF,0 QPR,1 STA,J OPT,TV

907 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 907 TRANSACTION CODE: DPSSFS
NAM: DPSSFS RUN: 30 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: O PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
*** CHANGED VALTAB ***
PROGRAM NUMBER: 907 TRANSACTION CODE: DPSSFS
NAM: DPSSFS RUN: 30 PRI: M PRG: 3 STF: 0 COP: 1 PRT: PR LEV: 0
STA: J OPT: TV IND: O PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1334:47
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940217 1334:47
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1334:47
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***

Example 5–32. Execution of Source Runstream—COBOL DPS SFS

Transaction Program

5–178 7831 4077–009

 Application Programming in a TIP Environment

@ . *** ** USES THE FREIPS UTILITY TO:

@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 13:38:48 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 13:34:48 17 FEB 94
TP REGISTER FINISHED 13:34:48 17 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 13:34:48 17 FEB 94
TP RESERVE FINISHED 13:34:48 17 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-17 1334:49
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY DPSSFS FROM QUAL*UCSTST TO 810
Program DPSSFS copied to TIP file 810 in ZOOM fast-load format.
Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: DPSSFS TIP Program File: 810

Example 5–32. Execution of Source Runstream—COBOL DPS SFS

Transaction Program

7831 4077–009 5–179

Application Programming in a TIP Environment

Element Format: ZOOM std-load Created on: 94-02-17 1334:49

Record Number: 2 Area Size: 282 records
Start Address: 400004001013 Program Mode: 3rd,NA,64-Gran

Program Number: 907

Bank Index: 3,1 2,5 2,6 2,4
Bank Type: EM, D-bank EM, D-bank BM, D-bank EM, I-bank
Lower Limit: 050000 060000 100000 001000
Bank Size: 01112 027531 300000 011702
GAP/SAP: RW/RW RW/RW ERW/ERW ER/ER
Processing completed successfully for LIST
EXIT
SUPUR Processor Terminated. Date-Time: 94-02-17 1334:52

@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–32. Execution of Source Runstream—COBOL DPS SFS

Transaction Program

5–180 7831 4077–009

 Application Programming in a TIP Environment

Execution of DPS SFS COBOL Transaction Program

The following screens show the execution of the previous example. User input is
bolded.

>DPSSFS 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: NUMBER:
FUNCTION:

*** JOB INFORMATION ***

TITLE: YEARLY SALARY:
FUNCTION:

*** COMPANY SPORTS PARTICIPATION ***

GOLF ADVANCED
VOLLEYBALL INTERMEDIATE

*** CHILDREN ***

7831 4077–009 5–181

Application Programming in a TIP Environment

5.2.4. Coding, Compiling, and Linking Multiple Database

Models in TIP Transactions
TIP transactions can access more than one UDS database model from the same
program. UCS supports all combinations of multiple UDS data models usage (for
example, RDMS 2200 and SFS 2200 together, DMS 2200 and RDMS 2200 together, all
three together, and
so forth).

This type of program requires use of BEGIN THREAD and END THREAD commands, no
matter which of the data models are used. The other UDS commands (for example,
the DMS 2200 IMPART and DEPART commands and the SFS 2200 OPEN and CLOSE
commands) must follow the BEGIN THREAD command and precede the END THREAD
command. Specifying the BEGIN THREAD and END THREAD commands is known as
using explicit thread control. Programs that access multiple database models require
explicit thread control.

There are no additional compiling or linking considerations resulting from accessing

multiple database models in the same TIP transaction. However, note that the rules
for each separate database model still apply.

The following pages show an example of a program that uses the three database
models discussed earlier. This is possible because the databases all contain data
about a group of individuals, each is uniquely identified in each database by the same
employee number.

5–182 7831 4077–009

 Application Programming in a TIP Environment

This example is a COBOL transaction program that is a combination of the DMS 2200,
RDMS 2200, and SFS 2200 programs shown previously (see 5.1.1, 5.1.2, and 5.1.3). The
transaction program uses DPS 2200 functions.

The following example, DPSALL, summarizes this program.

DPSALL
IDENTIFICATION DIVISION.
PROGRAM-ID. DPSALL INITIAL.
.
.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file-name
ASSIGN TO A-SHARED-FILE ....
.
.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE .....
.
.
FILE SECTION.
FD file-name
file definition ....
WORKING-STORAGE SECTION.
table definitions ...
form definition
.
.
01 EMPLOYEE-NUMBER ....
.
PROCEDURE DIVISION.
CALL 'D$INIT'...
CALL 'D$GETFL'...
CALL 'D$GETFL'...
MOVE GET-FIELD-TEXT TO EMPLOYEE-NUMBER
CALL 'D$OPEN'...
MOVE EMPLOYEE-NUMBER TO form
BEGIN THREAD
OPEN FILE
IMPART
OPEN DMS areas .... RETRIEVAL
FETCHs ....
MOVE DMS data TO form
READ FILE
MOVE SFS data TO form
USE DEFAULT QUALIFIER
DEFINE CURSOR
OPEN CURSOR
FETCHs ....

7831 4077–009 5–183

Application Programming in a TIP Environment

MOVE RDMS data TO form

DEPART
CLOSE FILE
END THREAD
CALL 'D$SEND'...
CALL 'D$TERM'...
STOP RUN.

5.2.4.1. Source Listing of the Program (DPSALL)

Example 5–33 shows the complete source listing of the program DPSALL. This
program uses DPS 2200 for screen control while accessing a DMS 2200, RDMS 2200,
and SFS 2200 database.

In this example, this program resides in element QUAL*UCSTST.DPSALL. Noteworthy

lines are bolded.

IDENTIFICATION DIVISION.
PROGRAM-ID. DPSALL INITIAL.
******************************************************************
******************************************************************
* *
* SIMPLE TIP COBOL DPS/DMS/SFS/RDMS PROGRAM - DPSALL *
* *
* initializes with DPS *
* reads the input data *
* opens the DPS form *
* moves the employee number to the form *
* begins thread with UDS *
* opens the SPORTSTIP SFS database file *
* imparts to the PERSONNELTIP database *
* retrieves the requested information from the DMS database *
* moves the DMS information to the form *
* retrieves the requested information from the SFS database *
* moves the SFS information to the form *
* retrieves the requested information from the RDMS database *
* moves the RDMS information to the form *
* departs from the PERSONNELTIP database *
* closes the SPORTSTIP SFS database file *
* ends thread with UDS *
* displays the DPS form *
* terminates with DPS *
* *
******************************************************************
******************************************************************
ENVIRONMENT DIVISION.

Example 5–33. Source Listing of the Program (DPSALL)

5–184 7831 4077–009

 Application Programming in a TIP Environment

CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SPORTSTIP
ASSIGN TO A-SHARED-FILE SPORTSTIP
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS SPT-EMP-NUMBER
ALTERNATE RECORD KEY IS SPT-IND-LAST-NAME WITH DUPLICATES.
DATA DIVISION.
SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUBTIP IN FILE SCHFILEXEC
OF SCHEMA PERSONNELTIP
COPYING RECORDS INTO WORKING
COPYING DATA-NAMES INTO WORKING
RUN-UNIT-ID DPSALL
DMCA IS WORKING
ERROR DMS-GENERAL-ERROR-PARA.
FILE SECTION.
FD SPORTSTIP.
01 SPORTS-DATA.
05 SPT-EMP-NUMBER PIC X(5).
05 SPT-IND-LAST-NAME PIC X(20).
05 SPT-IND-FIRST-NAME PIC X(12).
05 SPT-ACTIVE-COUNT PIC 9.
05 SPT-SPORT OCCURS 3 TIMES.
10 SPT-NAME PIC X(10).
10 SPT-LEAGUE-TYPE PIC X(12).
10 SPT-DUES PIC 9(2).
WORKING-STORAGE SECTION.
************************************************************
* USER INPUT ERROR MESSAGE
************************************************************
01 ERR-MISSING-INPUT PIC X(78)
VALUE 'NO EMPLOYEE NUMBER WAS SPECIFIED.'.
01 INVALID-EMPLOYEE-NUMBER.
02 TEXT-1 PIC X(40)
VALUE 'NO EMPLOYEE EXISTS WITH EMPLOYEE NUMBER '.
02 ERR-EMPLOYEE-NO PIC X(10).
************************************************************
* NO SPORTS MESSAGE
************************************************************
01 NO-SPORTS PIC X(78)
VALUE '*** NO COMPANY-SPONSORED SPORTS PARTICIPATION ***'.

Example 5–33. Source Listing of the Program (DPSALL)

7831 4077–009 5–185

Application Programming in a TIP Environment

************************************************************
* DPS PROCEDURES
************************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
COPY GETFIELD.
COPY SENDERROR.
COPY SCREEN-DSPLYIND-50.
************************************************************
* VARIABLE TO HOLD EMPLOYEE NUMBER INPUT
************************************************************
01 EMPLOYEE-NUMBER.
05 EMP-PAGE PIC 9(3).
05 EMP-RECORD PIC 9(2).
************************************************************
* RDMS WORK AREA SIZE
************************************************************
01 WORK-AREA-SIZE PIC 1(36) USAGE BINARY-1 VALUE 2000.
************************************************************
* UDS THREAD STATUS FLAG
************************************************************
01 THREAD-FLAG PIC 9(1) VALUE 0.
************************************************************
* RELATIONAL DATABASE INFORMATION
************************************************************
01 CHILD-LAST-NAME PIC X(20).
01 CHILD-FIRST-NAME PIC X(12).
************************************************************
* ESQL STATEMENT STATUS
************************************************************
01 SQLSTATE PIC X(5).
************************************************************
* RELATIONAL COMMAND ERROR BUFFERS
************************************************************
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 RDMCA.
05 ERROR-STATUS PIC 9(4).
05 AUX-INFO PIC S9(9) USAGE BINARY.
EXEC SQL END DECLARE SECTION END-EXEC.
************************************************************
* GETERROR BUFFERS
************************************************************
01 ERROR-TEXT.
05 ERR PIC X(132) OCCURS 5 TIMES.
************************************************************
* INDEX FOR GETERROR DISPLAYS
************************************************************

Example 5–33. Source Listing of the Program (DPSALL)

5–186 7831 4077–009

 Application Programming in a TIP Environment

01 ERR-INDEX PIC 9.
************************************************************
* ALLERROR INDICATOR
************************************************************
01 XX PIC 9 VALUE 0.
88 ALLERR VALUE 1.
************************************************************
* COUNTER FOR CHILDREN
************************************************************
01 CHILD-COUNT PIC 9(1) VALUE 0.
************************************************************
* INDEX VARIABLE
************************************************************
01 I PIC 9(1).
*
PROCEDURE DIVISION.
************************************************************
* TIP INITIALIZATION WITH DPS
************************************************************
DPS-INITIALIZATION.
CALL 'D$INIT'USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE TRANSACTION CODE
************************************************************
DPS-FREE-FORMAT-READ1.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* FREE FORMAT READ OF THE EMPLOYEE NUMBER
* RETURNS THE EMPLOYEE NUMBER
* GETFIELD-TYPE = 1 - TESTS FOR NO INPUT
* GETFIELD-LENGTH = 5 - TESTS THE FIELD LENGTH
************************************************************
DPS-FREE-FORMAT-READ2.
CALL 'D$GETFL'USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
MOVE GETFIELD-TEXT TO EMPLOYEE-NUMBER.

Example 5-33. Source Listing of the Program (DPSALL)

7831 4077–009 5–187

Application Programming in a TIP Environment

IF GETFIELD-TYPE = 1
MOVE ERR-MISSING-INPUT TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE IF GETFIELD-LENGTH NOT EQUAL 5 OR
GETFIELD-TYPE NOT EQUAL 3
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
ELSE CONTINUE
END-IF
END-IF.
************************************************************
* EMPLOYEE NUMBER VALIDATION
************************************************************
VALID-EMPLOYEE-NUMBER.
IF EMP-PAGE <= 99 OR EMP-RECORD <= 0
MOVE GETFIELD-TEXT TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* OPENS THE SCREEN TO BE SENT TO THE USER
************************************************************
DPS-OPEN-OUTPUT-SCREEN.
CALL 'D$OPEN'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-GENERAL-ERROR-PARA
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA.
************************************************************
* TRANSFERS THE EMPLOYEE NUMBER TO THE FORM DEFINITION
************************************************************
MOVE-EMPLOYEE-NUMBER.
MOVE EMPLOYEE-NUMBER TO S50-EMP-NUMBER.
************************************************************
* RDMS - SETS UP RDMS WORK AREA
* SETS UP RDMS GENERAL ERROR HANDLING
************************************************************
RDMS-SETUP.
CALL 'RSA$INIT'USING WORK-AREA-SIZE.
EXEC SQL

Example 5–33. Source Listing of the Program (DPSALL)

5–188 7831 4077–009

 Application Programming in a TIP Environment

WHENEVER SQLERROR GO TO RDMS-ERROR-PARA

END-EXEC.
************************************************************
* INITIALIZE WITH THE DATABASE SYSTEMS
************************************************************
CONNECT-TO-DATABASES.
BEGIN THREAD DSPDATA FOR APPSVN RETRIEVE.
MOVE 1 TO THREAD-FLAG.
OPEN INPUT SPORTSTIP.
IMPART.
OPEN ALL USAGE-MODE IS RETRIEVAL.
************************************************************
* DMS - RETRIEVE THE INDIVIDUAL INFORMATION
* MOVE THE INDIVIDUAL INFORMATION TO THE DPS FORM
************************************************************
DMS-RETRIEVE-INDIVIDUAL-DATA.
MOVE 'EMPNOAREATIP'TO EMPNO-AREA-NAME.
MOVE EMP-PAGE TO PAGE-NUM OF EMPNO-AREA-KEY.
MOVE EMP-RECORD TO RECORD-NUM OF EMPNO-AREA-KEY.
FETCH EMPNUMBER RECORD.
FETCH NEXT RECORD WITHIN EMPNO-IND SET.
FETCH OWNER RECORD WITHIN DEPT-IND SET.
FETCH OWNER RECORD WITHIN JOB-IND SET.
DMS-MOVE-INDIVIDUAL-DATA.
MOVE IND-LAST-NAME TO S50-IND-LAST-NAME.
MOVE IND-FIRST-NAME TO S50-IND-FIRST-NAME.
MOVE DEPT-NAME TO S50-DEPT-NAME.
MOVE DEPT-NO TO S50-DEPT-NO.
MOVE DEPT-DESCRIPTION TO S50-DEPT-DESCRIPTION.
MOVE JOB-TITLE TO S50-JOB-TITLE.
MOVE JOB-DESCRIPTION TO S50-JOB-DESCRIPTION.
MOVE JOB-SALARY TO S50-JOB-SALARY.
************************************************************
* SFS - RETRIEVE THE SPORTS INFORMATION
* MOVE THE SPORTS INFORMATION TO THE DPS FORM
************************************************************
SFS-RETRIEVE-SPORTS-DATA.
MOVE EMPLOYEE-NUMBER TO SPT-EMP-NUMBER.
READ SPORTSTIP RECORD
KEY IS SPT-EMP-NUMBER
INVALID KEY PERFORM BAD-KEY.
IF SPT-ACTIVE-COUNT = 0
MOVE NO-SPORTS TO S50-SPORTS-ACTION
ELSE PERFORM VARYING I FROM 1 BY 1 UNTIL I > SPT-ACTIVE-COUNT
MOVE SPT-NAME (I) TO S50-SPT-NAME (I)
MOVE SPT-LEAGUE-TYPE (I) TO S50-SPT-LEAGUE-TYPE (I)
END-PERFORM
END-IF.

Example 5–33. Source Listing of the Program (DPSALL)

7831 4077–009 5–189

Application Programming in a TIP Environment

************************************************************
* RDMS - SET DEFAULT QUALIFIER ON ALL TABLES IN THIS THREAD
* DEFINE THE CURSOR TO BE USED FOR DATA RETRIEVAL
* OPEN THE CURSOR
* RETRIEVE DATA FROM THE CURSOR
* MOVE THE CHILD INFORMATION TO THE DPS FORM
************************************************************
RDMS-SET-DEFAULT-QUALIFIER.
EXEC SQL
USE DEFAULT QUALIFIER FAMILYTIP
END-EXEC.
RDMS-SETUP-CHILDDATA-CURSOR.
EXEC SQL
DECLARE CHILDDATA CURSOR
SELECT CHILD_LAST_NAME, CHILD_FIRST_NAME
FROM CHILD
WHERE CHILD.CHILD_EMP_NUMBER = :EMP-NUMBER
END-EXEC.
EXEC SQL
OPEN CHILDDATA
END-EXEC.
RDMS-FETCH-MOVE-CHILD-DATA.
PERFORM WITH TEST AFTER UNTIL SQLSTATE = "02000"
OR CHILD-COUNT = 3
EXEC SQL
FETCH NEXT CHILDDATA INTO
:CHILD-LAST-NAME, :CHILD-FIRST-NAME
END-EXEC
IF SQLSTATE NOT = "02000"
ADD 1 TO CHILD-COUNT
MOVE CHILD-FIRST-NAME
TO S50-CHILD-FIRST-NAME (CHILD-COUNT)
MOVE CHILD-LAST-NAME
TO S50-CHILD-LAST-NAME (CHILD-COUNT)
END-IF
END-PERFORM.
IF CHILD-COUNT = 0 MOVE 'C'TO S50-CHILDREN-ON-DYN.
************************************************************
* TERMINATE WITH THE DATABASE SYSTEMS
************************************************************
DMS-DEPART-PARA.
DEPART.
SFS-FILE-CLOSE-PARA.
CLOSE SPORTSTIP.
UDS-END-THREAD-PARA.
END THREAD.
MOVE 0 TO THREAD-FLAG.

Example 5–33. Source Listing of the Program (DPSALL)

5–190 7831 4077–009

 Application Programming in a TIP Environment

************************************************************
* SENDS THE SCREEN TO THE USER
************************************************************
DPS-SEND-OUTPUT-SCREEN.
CALL 'D$SEND'USING DPS-STATUS, SCREEN-DSPLYIND-50.
IF STATUS-FATAL
PERFORM DPS-TERMINATION
PERFORM TERMINATION-PARA
END-IF.
************************************************************
* TERMINATION WITH DPS
************************************************************
DPS-TERMINATION.
CALL 'D$TERM'USING DPS-STATUS.

************************************************************
* PROGRAM TERMINATION
************************************************************
TERMINATION-PARA.
STOP RUN.
*
*
************************************************************
* DMS - CHECK FOR A '0013'ERROR,
* IF THIS ERROR OCCURRED THE
* INVALID-EMPLOYEE-NUMBER MESSAGE IS PRINTED
* ELSE THE ERROR MESSAGE IS RETURNED TO THE PRINTER
* FOR DEBUGGING.
************************************************************
DMS-GENERAL-ERROR-PARA.
IF ERROR-NUM = '0013'
MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE
PERFORM INVALID-INPUT-PARA
ELSE DISPLAY 'DMS-GENERAL-ERROR-PARA.'UPON PRINTER
DISPLAY 'AREA = 'ERROR-AREA UPON PRINTER
DISPLAY 'RECORD = 'ERROR-RECORD UPON PRINTER
DISPLAY 'SET = ' ERROR-SET UPON PRINTER
DISPLAY 'ROLLBACK = 'RB-ERROR-CODE UPON PRINTER
DISPLAY 'FUNCTION = 'ERROR-FUNCTION UPON PRINTER
DISPLAY 'ERR NUM = ' ERROR-NUM UPON PRINTER
END-IF.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.

Example 5–33. Source Listing of the Program (DPSALL)

7831 4077–009 5–191

Application Programming in a TIP Environment

PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
************************************************************
* SFS - DISPLAY OF BAD INPUT KEY
************************************************************
BAD-KEY.
MOVE EMPLOYEE-NUMBER TO ERR-EMPLOYEE-NO.
MOVE INVALID-EMPLOYEE-NUMBER TO ERROR-MESSAGE.
PERFORM INVALID-INPUT-PARA.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
************************************************************
* RDMS - RETURN AN ERROR MESSAGE TO THE PRINTER FILE IF A
* DATABASE ERROR OCCURS
************************************************************
RDMS-ERROR-PARA.
EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC.
DISPLAY '***SQLSTATE = 'SQLSTATE UPON PRINTER.
DISPLAY '***RDMCA AUX-INFO = 'AUX-INFO UPON PRINTER.
DISPLAY '***ERROR STATUS = 'ERROR-STATUS OF RDMCA
UPON PRINTER.
PERFORM UNTIL ALLERR
INITIALIZE ERROR-TEXT
EXEC SQL
GETERROR INTO :ERR(1),:ERR(2),:ERR(3),;ERR(4),:ERR(5)
END-EXEC
PERFORM VARYING ERR-INDEX FROM 1 BY 1 UNTIL ERR-INDEX = 6
DISPLAY ERR (ERR-INDEX) UPON PRINTER
IF ERR(ERR-INDEX) = SPACE SET ALLERR TO TRUE END-IF
END-PERFORM
END-PERFORM.
PERFORM DMS-DEPART-PARA.
PERFORM SFS-FILE-CLOSE-PARA.
PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.
*
*
************************************************************
* RETURNS AN ERROR MESSAGE TO THE USER IF THE INPUT
* MESSAGE WAS IN ERROR AND TERMINATES WITH THE
* TRANSACTION PROCESSING SYSTEM

Example 5–33. Source Listing of the Program (DPSALL)

5–192 7831 4077–009

 Application Programming in a TIP Environment

************************************************************
INVALID-INPUT-PARA.
CALL 'D$SENDERR'USING DPS-STATUS, ERROR-MESSAGE,
ERROR-COORDINATES.
*
*
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
* THE OUTPUT OF D$DUMP SHOULD BE INCLUDED WITH UCF
* DOCUMENTATION IF THIS PARAGRAPH WAS EXECUTED DUE TO
* TO A DPS INTERNAL ERROR.
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG'USING DPS-STATUS.
IF IMPART-DEPART EQUAL TO 1 PERFORM DMS-DEPART-PARA.
IF THREAD-FLAG = 1 PERFORM UDS-END-THREAD-PARA.
PERFORM DPS-TERMINATION.
PERFORM TERMINATION-PARA.

Example 5–33. Source Listing of the Program (DPSALL)

7831 4077–009 5–193

Application Programming in a TIP Environment

5.2.4.2. Source Listing of the Runstream to Compile and Statically

Link
Example 5–34 shows the source listing of a runstream used to compile and statically
link the example program DPSALL. Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE TIP TRANSACTION PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
@EOF
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS DMS/RDMS ESQL/SFS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
@UCOB QUAL*UCSTST.DPSALL,QUAL*UCSTST.DPSALL/COMP,,, COMPAT, NO-OPTIONS,;
APPLICATION/APPSVN
@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSALL'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***
@USE LINK$PF,SYS$LIB$*APP$7DPS.

Example 5–34. Runstream to Compile and Static Link—COBOL DPS

DMS/ESQL/SFS Transaction Program

5–194 7831 4077–009

 Application Programming in a TIP Environment

@LINK ,QUAL*UCSTST.DPSALL
INCLUDE QUAL*UCSTST.DPSALL/COMP
INCLUDE UDS$$SVN*SCHFILEXEC.S$WORK/PERSONSUBTIP
RESOLVE ALL REFERENCES USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
944 NAM,DPSALL ACT,DPSALL PRG,3 STF,0 QPR,1 STA,J OPT,TV
944 REC,Z AUD,7 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE@ .
@ . *** TRANSACTION ZOOM.

Example 5–34. Runstream to Compile and Static Link—COBOL DPS

DMS/ESQL/SFS Transaction Program

7831 4077–009 5–195

Application Programming in a TIP Environment

@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*TIPSUPUR.,FIX
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
LFD 810
@EOF
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
CREATE 810 MAIN
COPY ONLY DPSALL FROM QUAL*UCSTST TO 810
ONLINE 810
LIST ALL FROM 810
EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–34. Runstream to Compile and Static Link—COBOL DPS

DMS/ESQL/SFS Transaction Program

5–196 7831 4077–009

 Application Programming in a TIP Environment

5.2.4.3. Execution of the Source Runstream to Compile and

Statically Link
Example 5–35 shows the execution of the source runstream used to compile and
statically link this example. Output has been saved by an @BRKPT statement.
Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** COMPILE OF THE TIP TRANSACTION PROGRAM
@ . ***
@ . *** ASSIGN THE FILE CONTAINING SUBSCHEMA PROCESSING OUTPUT AND
@ . *** PUT A USE NAME ON IT.
@ . ***
@ASG,A UDS$$SVN*SCHFILEXEC.
W:120533 filename not unique.
W:120133 file is already assigned.
@USE SCHFILEXEC,UDS$$SVN*SCHFILEXEC.
I:002333 USE complete.
@ . ***
@ . ***
@ . *** RETRIEVAL PROGRAM COMPILE
@ . ***
@ . *** THE PROC FOR THE DPS PREDEFINED FORM RESIDES IN THE USER
@ . *** PROGRAM FILE. THIS PROCEDURE IS PDP'ED WITHIN THE
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . *** THIS PDP ONLY NEEDS TO BE DONE ONCE. THE PROC WILL THEN BE
@ . *** AVAILABLE TO ALL PROGRAMS COMPILED FROM THIS FILE.
@ . ***
@PDP,UC QUAL*UCSTST.SCREEN-50/COBP,.SCREEN-50
PDP 13RJ (931108 0108:39) 1994 Feb 17 Thu 1337:45
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 666 Entry Points: 1 Time: 3.103 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@ . *** COMPILE OF THE DPS DMS/RDMS ESQL/SFS COBOL TRANSACTION PROGRAM
@ . ***
@USE COB$PF,APP7*DPS.
I:0023333 USE complete.
@UCOB QUAL*UCSTST.DPSALL,QUAL*UCSTST.DPSALL/COMP,,, COMPAT, NO-OPTIONS,;
APPLICATION/APPSVN
UCOB- 6R2 (940210) LSS- 8R2 (940209) 940217 13:37:47
SIZES: CODE(EM6): 1917 DATA: 1623
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR) 1 WARNING(LEVEL)
6 REMARKS(CLARIFICATION)

Example 5–35. Execution of Source Runstream to Compile and Static Link—

COBOL DPS DMS/ESQL/SFS Transaction Program

7831 4077–009 5–197

Application Programming in a TIP Environment

@ . ***
@ . ***
@ . *** LINK OF THE STANDARD TIP TRANSACTION PROGRAM 'DPSALL'.
@ . ***
@ . *** PRIOR TO CALLING THE STATIC LINK PROCESSOR, A SPECIAL
@ . *** SEARCH CHAIN FOUND IN SYS$LIB$*APP$7DPS.SSDEF$ IS SPECIFIED
@ . *** USING AN "@USE LINK$PF" COMMAND. THIS SEARCH CHAIN IDENTIFIES
@ . *** THE DPS SYSTEM FILE FOR APPLICATION GROUP 7 AND SETS
@ . *** ACTIVE$APP TO APPLICATION GROUP 7.
@ . ***

@USE LINK$PF,SYS$LIB$*APP$7DPS.
I:002333 USE complete.
@LINK ,QUAL*UCSTST.DPSALL
LINK 5R2 (940207 1635:57) 1994 Feb 17 Thu 1338:12
*WARNING (LINK 687)* The Linking System could NOT create a ZOOM that conforms
to the Fast Load format restriction of four banks or less. This is due to
incompatibilities in the attributes (e.g. merge order, mode, locality) of
certain banks, which prevent them from being merged. Such merging is required
to reduce the number of banks that are output. The ZOOM that is created will
be of the standard form.
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 1 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 44R2#0000001 940217 1338:22
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.

Example 5–35. Execution of Source Runstream to Compile and Static

Link—COBOL DPS DMS/ESQL/SFS Transaction Program

5–198 7831 4077–009

 Application Programming in a TIP Environment

COPIES COP MAXIMUM COPIES

STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

944 NAM,DPSALL ACT,DPSALL PRG,3 STF,0 QPR,1 STA,J OPT,TV

944 REC,Z AUD,7 PRT,PR
*** ORIGINAL VALTAB ***
PROGRAM NUMBER: 944 TRANSACTION CODE: DPSALL
NAM: DPSALL RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET

*** CHANGED VALTAB ***

PROGRAM NUMBER: 944 TRANSACTION CODE: DPSALL
NAM: DPSALL RUN: 60 PRI: M PRG: 3 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV IND: NONE SET PCT: 1 WAITQ: 0
AUD: 7 REC: Z QPR: 1 MAS: NONE SET
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1338:23
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 44R2#0000001 940217 1338:23
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 44R2#0000001 940217 1338:23
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE

Example 5–35. Execution of Source Runstream to Compile and Static

Link—COBOL DPS DMS/ESQL/SFS Transaction Program

7831 4077–009 5–199

Application Programming in a TIP Environment

@ . *** SUPUR TIP FILE.

@ . ***
@CAT,P QUAL*TIPSUPUR.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 44R2 02/17/94 13:38:24 FS-LEVEL FS 003
TREG QUAL*TIPSUPUR.,FIX
TP REGISTER STARTED 13:38:24 17 FEB 94
TP REGISTER FINISHED 13:38:24 17 FEB 94
RES 810,64000,28,,TIPSUPUR,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 13:38:24 17 FEB 94
TP RESERVE FINISHED 13:38:25 17 FEB 94
LFD 810

TIP FILE 810

DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME TIPSUPUR
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** USES THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPYS THE TRANSACTION PROGRAM INTO THE SUPUR PROGRAM FILE,
@ . *** AND PLACES THE SUPUR PROGRAM FILE ONLINE.
@ . ***
@TIP$*TIPRUN$.SUPUR,P
SUPUR Processor Level 44R2#0000001 Date-Time: 94-02-17 1338:25
CREATE 810 MAIN
Processing completed successfully for CREATE
COPY ONLY DPSALL FROM QUAL*UCSTST TO 810

Example 5–35. Execution of Source Runstream to Compile and Static

Link—COBOL DPS DMS/ESQL/SFS Transaction Program

5–200 7831 4077–009

 Application Programming in a TIP Environment

Program DPSALL copied to TIP file 810 in ZOOM std-load format.

Processing completed successfully for COPY
ONLINE 810
Online installed 1 LCP records in VALTAB for programs in file 810.
Processing completed successfully for ONLINE
LIST ALL FROM 810

Program Name: DPSALL TIP Program File: 810

Element Format: ZOOM std-load Created on: 94-02-17 1338:21
Record Number: 2 Area Size: 512 records
Start Address: 400004001062 Program Mode: 3rd, NA, 64-Gran
Program Number: 944
Processing completed successfully for LIST
EXIT
SUPUR Processor Terminated. Date-Time: 94-02-17 1338:28
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 5–35. Execution of Source Runstream to Compile and Static

Link—COBOL DPS DMS/ESQL/SFS Transaction Program

7831 4077–009 5–201

Application Programming in a TIP Environment

5.2.4.4. Execution of the DPS DMS RDMS SFS Transaction Program

The following screens show the execution of a DPS transaction program that
accesses a DMS 2200 database, an RDMS 2200 database, and an SFS 2200 database.
User input is bolded.

>DPSALL 10211

******** INDIVIDUAL DATA *******

EMPLOYEE NUMBER: 10211 NAME: STEVEN FIELDING

*** DEPARTMENT INFORMATION ***

NAME: APPLICATION DEVELOPMENT NUMBER: 4124
FUNCTION: DESIGNS, DEVELOPS, AND IMPLEMENTS NEW APPLICATION CODE

*** JOB INFORMATION ***

TITLE: PROGRAMMER YEARLY SALARY: $40000
FUNCTION: DESIGNS, WRITES, AND TESTS CODE

*** COMPANY SPORTS PARTICIPATION ***

GOLF ADVANCED
VOLLEYBALL INTERMEDIATE

*** CHILDREN ***

STEVEN JR FIELDING
DANIEL FIELDING
JANE FIELDING

5–202 7831 4077–009

 Application Programming in a TIP Environment

5.3. Improving TIP Transaction Execution-Time

Performance
The following subsections provide suggestions for producing standard TIP transaction
programs for optimal execution-time performance. The topics covered are as follows:
• Coding suggestions
• Compiling suggestions
• Linking suggestions

5.3.1. Coding for Standard TIP Execution-Time Performance

To achieve the best execution-time performance for standard TIP transaction
programs, observe the following suggestions during coding:
• Use embedded SQL for UCS COBOL and UCS C transactions.
If you plan to use a static database design, code all UCS COBOL and UCS C
standard TIP transaction programs that access RDMS 2200 databases using
embedded SQL commands, rather than the interpreter SQL interface (non-
embedded SQL commands). Embedded SQL commands are parsed once at
compilation time. Interpreter SQL commands are parsed during each program
execution.
• Use module SQL for UCS FORTRAN transactions
If you plan to use a static database design, code all UCS FORTRAN standard TIP
transaction programs that access RDMS 2200 databases using module SQL
commands rather than the interpreter interface. Module Language SQL
commands are parsed at compilation time; interpreter commands are parsed
during each program execution.
• Set the RDMS work area size.
For standard TIP transaction programs that access RDMS 2200 databases, code a
call to RSA$INIT that includes the optional parameter to specify the initial size for
the RDMS work area. By setting the work area size to the size used by the
transaction program, you eliminate the overhead of dynamic space acquisition.
Refer to the following for information about RSA$INIT and how to determine the
size of the work area:
− “Coding RDMS 2200 TIP Transactions,” 5.2.2.4
− “Coding for Batch and Demand Execution-Time Performance,” 3.5.1
• Combine frequently-called subprograms or subroutines.
Whenever feasible, combine frequently-called subprograms or subroutines into a
single compilation unit with the transaction programs that call them.

7831 4077–009 5–203

Application Programming in a TIP Environment

• Use the “multiple INITAL” method of coding.

The “multiple INITAL” method of coding can provide better performance for
transaction programs that
− Are constantly in use
− Update database files
Refer to the Transaction Processing Programming Reference Manual for a
complete explanation of this method.
• When coding UCS COBOL programs
− Use the inline PERFORM statement for loops
− Use the INITIAL clause on the PROGRAM-ID statement to establish the
program's initial state. CANCEL does not work properly under TIP, and the
INITIAL clause is more efficient. In addition, if your TIP program gets TIP
RESTARTs, use of the INITIAL clause helps your program reinitialize for
handling the next input.
− Define all parameters to be passed as 01 level data items and use the
COMPAT/ARGUMENTS compiler keyword option when compiling these
programs
− Use the SQRT intrinsic function instead of n**.5 to figure square roots.
• When coding UCS C programs
− Use the alternate calling sequence (ACS) instead of the standard calling
sequence (SCS) when C programs call C functions. This can be accomplished
by using the ALT-CALL compiler keyword option for a global effect or by using
the “#pragma alternate function-name” statement for a specific function call.
− Use the “#pragma expand” and the “#pragma inline function-name”
statements to expand function calls inline. This should only be done if
ο The function is small
ο The function executes for a short time
ο The function is called many times
• The URTS “heap” bank URTS$TABLES may be a performance concern. When
executing a TIP transaction program, TIP “sticking” and RESTART are lost if the
URTS$TABLES bank is expanded or if another bank is allocated. If the
URTS$TABLES “heap” bank space is tight, you should consider the following to
help minimize URTS$TABLES space needs:
− Closing PCIOS files when you are finished using them. This releases the space
that they were using.
− Using extended mode SORT (EM SORT). This moves the major portion of
space used by SORT processing to a separate bank so that it is no longer
located in the heap data bank.
− Use the CALL RSA$INIT routine to initially allocate all RDMS space so that it is
allocated as contiguous space.

5–204 7831 4077–009

 Application Programming in a TIP Environment

Note: Sorting can degrade the performance of transaction programs

For more information about how to code UCS programs for performance, refer to the
programming reference manual for the appropriate UCS language (for UCS COBOL,
UCS FORTRAN, and UCS C, this information is in Volume 2).

7831 4077–009 5–205

Application Programming in a TIP Environment

5.3.2. Compiling for Standard TIP Execution-Time Performance

To achieve the best execution-time performance for standard TIP transaction
programs, observe the following suggestions during compilation:
• Use the OPTIM compiler keyword option. (OPTIM is on by default.) This keyword
option increases the optimization performed by the LSS code generator, producing
code that executes more efficiently.
• Use the REORDER compiler keyword option. (REORDER is on by default.) This
keyword option increases the optimization performed by the LSS code generator,
producing code that is more efficient at execution time.
• For UCS COBOL, use the COMPAT/ARGUMENTS keyword option if you can
guarantee that all parameters are 01 levels. This ensures that they are word-
aligned, which permits improved code generation for parameter references.
• Avoid use of the RUNCHECK keyword option on production-oriented compilations.
RUNCHECK performs the following functions:
− Subscript range checking on all array references
− Range checking on COBOL reference modification
− Range checking on FORTRAN substring variables
• Avoid use of the CLEAR keyword option. This keyword option initializes all
uninitialized data to zeros. This function is usually unnecessary, and can be
performed more efficiently by program code.
• When using UCS FORTRAN or UCS C, consider using the compiler keyword option
EXPAND for routines that are small and called frequently. This keyword option
causes subprograms or subroutines to be generated inline (expanded inline at
each of their calls).
For more information on these keyword options and other ways to compile UCS
programs for performance, refer to the programming reference manual for the
appropriate UCS language (for UCS COBOL, FORTRAN, and C, this is Volume 2).

5–206 7831 4077–009

 Application Programming in a TIP Environment

5.3.3. Linking UCS Standard TIP Transactions for Performance

To achieve the best execution-time performance for standard TIP transaction
programs, observe the following suggestions during linking. Note that all TIP
programs must be linked as either regular or FAST LOAD ZOOMs.

5.3.3.1. Basic Static-Linking Suggestions

The following are general suggestions for linking transaction programs:
• Do not include PADS code in production transaction programs. PADS will
dynamically acquire a bank and this inhibits TIP “sticking” and RESTART.
You can prevent inclusion of PADS code by using a static linking RESOLVE
command. The RESOLVE command must list the file SYS$LIB$*EMOMRTS in the
USING clause before it lists LIBCODENAME (LCN). If you specify this file in the
USING clause, C$NPADS is included in the program instead of PADS. C$NPADS is
a PADS stub.
The following is the required RESOLVE command:
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME

Note that PADS interactive debugging cannot be done on a program linked in this
manner. PADS postmortem debugging is still available.
• Use static linking to produce a FAST LOAD ZOOM whose banks have been
merged. You can accomplish this by using the following static linking command:

− PROCESS FOR EXTENDED FAST LOAD

or,
OUTPUT FAST LOAD

If the Linker cannot create a FAST LOAD format ZOOM, it will give you a LINK
687 Warning and produce a standard ZOOM.
Note that a FAST LOAD format ZOOM is only possible with a very small
transaction program. In addition, the processing done for FAST LOAD causes the
Linker to do more aggressive bank-merging, and it will merge the URTS$TABLES
“heap” bank with other data banks. This may result in there not being enough
space available in URTS$TABLES to handle allocation requests and another bank
may then be acquired at runtime. If this is done TIP “sticking” and RESTART will
be lost for the transaction. You might then try and link your transaction into a
standard ZOOM instead of a FAST LOAD ZOOM to see if you can regain the TIP
'sticking' and RESTART capabilities for your transaction:
PROCESS FOR EXTENDED ZOOM

• Use a ZOOM with only the transaction program entry point defined.
Use static linking to produce a ZOOM with only the entry point definition for the
starting address of the transaction program. You can accomplish this by using the
following static linking command:
DELETE ALL DEFINITIONS EXCEPT START$

7831 4077–009 5–207

Application Programming in a TIP Environment

• If your program is doing COBOL call-identifier (CALL progname.), consider using

the more efficient LSI$RES-NAME method. Take a copy of either the LSI$RES-
NAME or LSI$RES-NAMH symbolics from the file SYS$LIB$*LINK. and edit the
source. Put the names of the procedures you may be calling into the source in
DECLARE statements. (The comments in the elements explain how to do it.)
Then MASM the resulting source element, and INCLUDE it in your static link(s).
See Section 7 for more details.

5.3.3.2. URTS$TABLES Operation

There is a URTS object module that is linked into every executable program called
URTS$TABLES. Within this object module is defined a bank whose bank name is also
URTS$TABLES. (Often referred to as the URTS “heap” bank.) URTS$TABLES is a
program-level bank. It defaults to starting at 060000, with an initial size of about
10,000 decimal words, and with a maximum limit of 0777777. It is used to hold key
URTS information on the state of the executing program, including many URTS data
structures and buffers and space for dynamic allocations. It starts at 060000 and does
not extend past 0777777 so that it can be referenced from basic mode code from
products such as PCIOS. Many things can cause space to be allocated in
URTS$TABLES, including
• Opening files
• Using SORT
• Calling RDMS
• Using DPS
• Using C malloc in a TIP transaction (unless the TIPMALLOC keyword option was
used to compile the main program)
• Starting up a new activity (TSKSTART and tskstart calls)

The URTS$TABLES bank will be expanded during execution as more space is needed.
If it runs out of room, other banks will be allocated and linked to the original so that
the capacity is somewhat open-ended. If the URTS$TABLES bank is expanded, or
others allocated, this will inhibit TIP “sticking” and RESTART for TIP transactions. It is
also relatively expensive for non-TIP executions if the execution time is short.
Therefore, it may be desirable when you static-link your executable programs to set
the size of the URTS$TABLES bank to the maximum that your programs need, or could
possibly need.

The new ClearPath 2200 machines have virtual memory and large real memories and it
is no longer productive to attempt to keep the size of your programs small with
memory reserves just barely large enough to keep them running. If your programs
can run with URTS$TABLES at its maximum limit of 0777777, then set its size
accordingly ( 0777777 - 060000 + 1 or 0720000). Put the following into the static link
sources of your executable programs, after all INCLUDE and RESOLVE statements:
SET SIZE = 0720000 FOR URTS$TABLES

5–208 7831 4077–009

 Application Programming in a TIP Environment

Programs that use DPS may not run with this maximum size if it calls the basic mode
MCB. So, for DPS you might want to keep your URTS$TABLES upper limit to 0577777.
This would be a size of 0577777 - 060000 + 1, or 0520000 words. (Check the DPS
documentation to see if this is necessary.) To get your URTS$TABLES at an initial
limit of 0577777, put the following static linker statement in your static link source,
after all INCLUDE statements and RESOLVE statements:
SET SIZE = 0520000 FOR URTS$TABLES

Do not set the size of URTS$TABLES in HVTIP links, as HVTIP memory management is
done differently. Also, if you have created a FAST LOAD ZOOM, the URTS$TABLES
bank will have been merged with other banks, and you may have to set a different size
in order to get it to get to the desired 0777777 or 0577777 limit.

Once the URTS$TABLES bank is expanded to its maximum limit and all space within it
has been allocated, a new bank will be allocated if more space is needed. Note that
there may be several URTS space allocations done for something such as opening a
file. If one or more buffers is obtained for opening a given file, and another buffer
needs to be allocated to finish opening the file resulting in another URTS$TABLES bank
being acquired, an error will occur.

This is because (currently) all the buffers needed for a specific use such as handling of
a given file must be in the same bank. In order to keep this error from happening you
must use a keyword option on the compilation of the main program for your
executable program. The keyword is URTS$TABLES, and you give it a size which is a
reserve for “same-bank” allocations within the URTS$TABLES bank. This reserve is
used when a URTS$TABLES allocation is done and must be in the same bank as
another allocation and the “normal” space in the bank is used up. The initial reserve is
treated as an octal number, so do not use the digits 8 or 9 in the reserve.

Here is a compilation of a COBOL main program with an initial URTS$TABLES

“same-bank” reserve of the recommended 050000 words:
@UCOB COBMAIN2,,,,URTS$TABLES/50000 . Reserve 050000 words

You probably should not use this option if your program is not running out of
URTS$TABLES space since putting in a “same-bank” reserve virtually guarantees that
your program will acquire another URTS$TABLES bank at runtime. You also may not
want to use this mechanism if your program uses a product that requires that
URTS$TABLES not grow past some limit such as 0577777, since the URTS runtime
code will expand URTS$TABLES to 0777777 and use that space before it will acquire
another bank.

If the heap data bank space is tight and you wish to minimize its size, you should
consider doing the following:
• Closing PCIOS files when you are finished using them. This releases the space
that they were using.
• Using extended mode SORT (EM SORT). This moves the major portion of space
used by SORT processing to a separate bank so that it is no longer located in the
Heap Data Bank. The EM SORT is also much faster than the older basic mode
SORT.

7831 4077–009 5–209

Application Programming in a TIP Environment

• Use the "CALL RSA$INIT" routine to initially allocate all RDMS space so that it is
allocated as contiguous space.

5.3.3.3. C malloc Calls Under TIP (TIPMALLOC)

The default space for malloc calls in non-TIP programs is for URTS to dynamically
acquire a bank and allocate space out of it. Under TIP, the malloc space comes from
the URTS$TABLES bank. When the bank runs out of space, another bank will be
acquired, etc., and so malloc under TIP is also quite open-ended. However, use of
URTS$TABLES space can be quite heavy, and if URTS$TABLES is expanded or another
bank acquired, TIP “sticking” and RESTART are lost for the transaction.

For TIP (and also batch or demand) programs, if the main program is compiled with the
keyword option TIPMALLOC, there is a URTS object module that is linked into the
resulting ZOOM that defines space that instead will be used for malloc purposes. The
name of the bank is TIPMALLOC$$$, and it is an activity-level bank with an initial size
of 262144 words and a maximum size of 16 million words. However, you can change
the SIZE of the bank in the static link of your TIP program to be what you want. For
example, assuming that you compiled your main program with the TIPMALLOC
keyword option, put the following statement into the static link source of your
executable ZOOM, after all the INCLUDE and RESOLVE statements:
SET SIZE = 04000000 for TIPMALLOC$$$

This statement in the static link of your ZOOM will give you approximately 262144*4
words of dynamic space available for C malloc calls before the space would run out
and another bank acquired. This means that TIP “sticking” and RESTART will not be
lost until that point was reached if the program is executed under TIP. The
preservation of TIP “sticking” and RESTART can be a major concern in transaction
performance. The maximum size that you can set for TIPMALLOC$$$ would be
0100000000, or approximately 16 million words.

Do not use the TIPMALLOC keyword option on compilations to be linked into HVTIP
ZOOMs. HVTIP has its own memory allocation scheme and is controlled by code in
the URTS HVTIP loader.

5.3.3.4. Static Linking with RDMS 2200

When you use interpreted or embedded SQL to access RDMS databases in a TIP
transaction program, RDMS uses the UCS C malloc function to acquire dynamic
memory allocations. In batch or demand mode the malloc space is acquired by
creating an activity level bank. For TIP the malloc space is acquired from the
URTS$TABLES heap bank. This is a small bank and once the bank is filled, another
URTS$TABLES heap bank is created.

The CREATE$BANK call causes your transaction to lose its TIP sticking and TIP restart.
To prevent this from occurring, the main program must use the keyword option
TIPMALLOC on the compilation of the program. Using TIPMALLOC results in the
TIPMALLOC$$$ bank being included within your link. Inclusion of this bank allows TIP
sticking and restart to function because a dynamic bank creation does not take place.

5–210 7831 4077–009

 Application Programming in a TIP Environment

Allowing TIP sticking and restarting keeps RDMS and any other subsystem that is
called from acquiring the memory heap space from the URTS$TABLES heap bank.
Note that a fast-load zoom cannot be created with the TIPMALLOC option because the
total (collective) size is more than 262K words. (This is not the actual size, but the
potential growth size when the program requires more memory.)

5.3.3.5. Static Linking with DPS 2200

When you use DPS 2200 in a standard TIP transaction program, DPS uses space within
URTS$TABLES for its work area. The addition of one static link command can improve
performance by avoiding expansion of URTS$TABLES for DPS during transaction
execution. During static linking of the transaction program, set the size for
URTS$TABLES to reflect the default size plus the size obtained by calling the DPS 2200
HELPER processor. You can do this most easily by setting the size of URTS$TABLES
to its maximum according to the previous general “URTS$TABLES Operation”
discussion. However, the following older more difficult method is still valid, though
not recommended due to its complexity.

The following example shows the HELPER output for the DPS 2200 software in file
APP7*DPS that was used in examples in this section. Noteworthy lines are bolded.

@APP7*DPS.HELPER
HELPER 5R1A APP7 DPS Helper Utility Processor 1991 Jun 27 Thu 1450:31

RES 2102,478400,28,$$TERMFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE TERMINAL FILE MUST BE 7475 TRACKS

RES 2105,200,112,$$PASSFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PASSWORD FILE MUST BE 13 TRACKS

RES 2103,5001,2016,$$PAGEFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PAGING FILE MUST BE 5627 TRACKS

** IF ONE EXECFILE CONTAINS THE TERMINAL, PASSWORD AND PAGING FILE,

THE SIZE OF THE EXECFILE MUST BE 13115 TRACKS

RES 2108,126000,28,ALT$SCRNFILE,ALT$SCRNFILE,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS

RES 2109,126000,28,FORMS,FORMS,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS

DPS MEMORY USAGE REQUIREMENTS

ACOB, FTN, PL1 -

7831 4077–009 5–211

Application Programming in a TIP Environment

RUNTIME BLOCK SIZE: 9902 DECIMAL WORDS

D$DEF BLOCK SIZE: 9956 DECIMAL WORDS

UCS - RUNTIME BLOCK SIZE: 10048 DECIMAL WORDS

UCS - D$DEF BLOCK SIZE: 9984 DECIMAL WORDS
UCS - PARAM BLOCK SIZE: 5376 DECIMAL WORDS
UCS/INTERFACE data bank size requirements:
DYNAMIC link without D$DEFs 15424 DECIMAL WORDS
DYNAMIC link with D$DEFs 25408 DECIMAL WORDS
STATIC link without D$DEFs 10048 DECIMAL WORDS
STATIC link with D$DEFs 20032 DECIMAL WORDS
.
. (additional lines)
.

Using this output, perform the following steps:

1. In the HELPER output, locate the information with the following title:
UCS/INTERFACE data bank size requirements;

2. Below this are four lines of output. The third and fourth lines apply to static
linking: If D$DEF routines are used in the program, refer to the fourth line.
Otherwise, refer to the third line.
3. Take the size shown on the appropriate line and use it in a static linking SET SIZE
command for the transaction program, as follows:
SET SIZE = SIZE + dps-helper-size FOR URTS$TABLES

where dps-helper-size is the size indicated in the HELPER output.

For this example, assuming that the TIP transaction program does not use D$DEF
routines, the following command would be used in the static link of the transaction
program:
SET SIZE = SIZE + 10048 FOR URTS$TABLES

The SET SIZE command must follow the RESOLVE command.

If your DPS TIP program is still losing its TIP sticking and restart and it uses RDMS
embedded or interpreted SQL, consider adding the TIPMALLOC keyword option to the
compilation of your main program. RDMS SQL space needs are satisfied from C
malloc calls, and that space will be satisfied from the auxiliary TIPMALLOC$$$ bank
instead of URTS$TABLES space when the TIPMALLOC keyword option is used. See
the preceding subsections regarding the TIPMALLOC keyword option and static linking
with RDMS.

Note: The SET SIZE command must follow the RESOLVE command. If both DPS
and RDMS are being used by the transaction program, use only one SET SIZE
command in the static link. Add the space required by DPS and RDMS together, and
use the result of this calculation in the SET SIZE command.

5–212 7831 4077–009

 Application Programming in a TIP Environment

5.3.3.6. Space Optimization

This subsection suggests how to link your standard TIP transaction programs so that
Space for the activity-local stack (ALS) is not dynamically acquired
Space for the URTS “heap” URTS$TABLES, is not dynamically acquired

If your transactions contain different execution paths, you may want to apply these
techniques only to the high-priority execution paths in the transactions. Remember
that your transactions execute successfully without applying either of these
techniques.

To obtain the information to apply the techniques discussed in this subsection, you
must obtain a TIP DIAG$ file, which is then processed by PADS commands.

5.3.3.7. Example Application

An expanded example demonstrates this technique. The expanded UCS COBOL
example uses DPS 2200 and accesses a DMS 2200 database. The same techniques
shown in this example apply regardless of the UCS language or transaction processing
interface used.

The transaction control program is called DPSDMS. One input to this transaction
sequence is the transaction code DPSDMS followed by an employee number (for
example, DPSDMS 10211). The following processing sequence is used for this input:
1. Initializes using DPS
2. Reads the employee number input
3. Validates the employee number
4. Opens a DPS form
5. Imparts to a DMS database
6. Retrieves data from the DMS database using the employee number
7. Moves the DMS data into the DPS form
8. Departs from the DMS database
9. Displays the DPS form on the terminal
10. Terminates using DPS
IDENTIFICATION DIVISION.
.
.
PROCEDURE DIVISION.
.
.
.
CALL 'D$INIT'...
reads input message
validation of input
CALL 'D$OPEN'...

7831 4077–009 5–213

Application Programming in a TIP Environment

IMPART.
retrieval from DMS database
move data to DPS form
DEPART.
CALL 'D$SEND'...
CALL 'D$TERM',,,
STOP RUN.

This transaction has been function-tested. The following performance aids have
already been applied:
• Coding
The INITIAL clause was added to the transaction program DPSDMS.
• Compiling
The OPTIM and REORDER keyword options were used when compiling
transaction program DPSDMS.
• Linking
The PADS interface code inclusion is prevented by the RESOLVE ALL REFERENCES
command.
The size of URTS$TABLES was increased to accommodate the use of DPS. This
was accomplished by adding a SET SIZE FOR URTS$TABLES command to the
static link of the transaction program DPSDMS.
A FAST LOAD ZOOM was requested by the PROCESS command in the static link.
For this example, the linking runstream for the DPSDMS transaction program is as
follows:
@USE LINK$PF,SYS$LIB$*APP$7DPS.
@LINK,S ,QUAL*PROGFILE.DPSDMS
INCLUDE QUAL*PROGFILE.DPSDMS/COMP
INCLUDE UDS$$SVN*SCHEXECFILE.S$WORK/PERSONSUBTIP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR URTS$TABLES
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

To continue the optimization process, you must collect information by executing the
transaction DPSDMS, producing a diagnostic dump in the process. The following
describes how to produce and process this dump.

5–214 7831 4077–009

 Application Programming in a TIP Environment

Step 1: Produce a Diagnostic Dump

Temporarily insert a call command that will create a DIAG dump, just prior to the MCB
or DPS termination command in the transaction execution path. These calls are as
follows:
UCS COBOL
CALL 'FERR'.

UCS FORTRAN
CALL FERR

UCS C
ferr();

In the example, this call would be placed in the transaction program DPSDMS just
before the call to 'D$TERM', as follows:

IDENTIFICATION DIVISION.
.
.
PROCEDURE DIVISION.
.
.
CALL 'D$INIT'....
reads input message
validation of input
CALL 'D$OPEN'....
IMPART.
retrieval from DMS database
move data to DPS form
DEPART.
CALL 'D$SEND'...
CALL 'FERR'.
CALL 'D$TERM'....
STOP RUN.

Step 2: Recompile
Recompile the transaction program.

Step 3: Relink
Relink the transaction program producing a short listing (@LINK,S...)

Step 4: Set Options

To produce the DIAG dump, both of the following must be true:
• The VALTAB for this transaction code must have "T" included in the OPTIONS
parameter, so that a DIAG dump is produced when the abort call is encountered.
• TIPTRACE in the TIP FLAGBOX must be set to "ON."

7831 4077–009 5–215

Application Programming in a TIP Environment

Step 5: SUPUR Load

Use the SUPUR utility to load the new ZOOM.

Step 6: Execute
Depending upon your site setup, refer to the appropriate subsection that follows:
• If you have access to the operator console or a terminal that can be placed in
CONS MODE (@@CONS), refer to "Executing with Console Output."
• If you do not have access to the operator console output, refer to "Executing
Without Console Output."

Executing with Console Output

You must sign on with a user-id that has CONSOLE MODE set to DISPLAY. (This user-
id attribute is set using SIMAN.)

1. Execute the transaction while watching the operator console output. When the
transaction aborts, the following message is displayed:
*nnnnn**TIP DIAG$ FILE CREATED - TIPDIAG$*xxxxxxnnnnn

where
nnnnn
is the generated id for this execution of the transaction.
xxxxxx
is the transaction name that is in error.
TIPDIAG$*xxxxxxnnnnn
is the name of the DIAG file which contains the dump for this execution of the
transaction.
When this example is executed, a message like the following is received:
*7022J**TIP DIAG$ FILE CREATED - TIPDIAG$*DPSDMS7022J

2. Call PADS. Supply the DIAG dump file name on the processor call, as in the
following example:
@pads diag,tipdiag$*dpsdms7022j.

3. Request the first DIAG dump file entry for this transaction execution.
# CMD > select first diag entry

5–216 7831 4077–009

 Application Programming in a TIP Environment

Executing Without Console Output

If you do not have access to the operator console output, execute the transaction
according to the following steps.
1. Execute the transaction checking the wall clock time.
2. When the transaction completes, call PADS (@PADS) using the TIPDIAG keyword,
followed by the application group number on the processor call.
In the following example, application group 7 is specified. (If the application group
number is omitted, application group 1 is assumed.)
@pads tipdiag,7

After successful activation, PADS responds with the current number of entries in
the TIP error history file. There are one or more entries for each transaction
execution that errors and produces a DIAG dump.
The following is an example of this PADS output.
PADS 8R1 1993-07-11 2328:52
# Application 7 TIP Error History File contains 192 entries.

3. Locate the diagnostic information for your specific transaction execution. There
are several PADS commands you can use to accomplish this. The following are
examples:
• The following example command lists the last six entries with the transaction
code DPSDMS. You must enter the transaction code in capital letters.
# CMD >tiplog$code$ 'DPSDMS',6

• The following example command lists the last six entries created on July 11,
1993 (930711) with transaction code DPSDMS. You must enter the transaction
code in capital letters.
# CMD >tlog$search$ " tiplog.error_date (i) = '930711'and " !! %
# CMD > " tiplog.transaction_code (i) = 'DPSDMS'",6

• The following command lists the last six entries created after 11:00 PM
(230000) on July 11, 1993 (930711) with transaction code DPSDMS. You must
enter the transaction code in capital letters.
# CMD >tlog$search$ " tiplog.error_date (i) = '930711'and " !! %
# CMD > " tiplog.error_time (i) > '230000'and " !! %
# CMD > " tiplog.transaction_code (i) = 'DPSDMS'",6

Each of these queries produces a report on six or fewer entries that match the
criteria supplied. Look at the date (ERROR_DATE) and time (ERROR_TIME) on each
entry to select the entry for the time when you executed the transaction.

7831 4077–009 5–217

Application Programming in a TIP Environment

Often, one transaction execution produces multiple consecutive entries within the TIP
error history file. You can identify entries for the same execution by checking for the
same value in the FILENAME=TIPDIAG$*filename field. You want the oldest of these
entries; this is the entry with the highest TIPLOG number. To confirm this, check the
values in the ERROR_TIME field for the entries.

The following is a sample of the output for two entries for the same transaction
execution. The TIPLOG(4) entry is the one you want to interrogate further. The
bolded fields provide the information that is important to you.

# TIPLOG(3)
# PROGRAM_NAME=DPSDMS TRANSACTION_CODE=DPSDMS
# ERROR_INFO
# ERROR_VA=400013101005T CONTINGENCY_TYPE=2T ERROR_TYPE=0T
# ERROR_CODE=14T
# ERROR_AUX_INFO=21T ERROR_ID=34001000322T ERROR_DATE=930711
ERROR_TIME=
# 231014 ERROR_INS=0T
# TIP_INFO
# PID=10T TIP_TYPE=transaction HVTIP_LIB_BANK=OT
# FILENAME=TIPDIAG$*DPSDMS7022J.
# TIPLOG(4)
# PROGRAM_NAME=DPSDMS TRANSACTION_CODE=DPSDMS
# ERROR_INFO
# ERROR_VA=200444006077T CONTINGENCY_TYPE=12T ERROR_TYPE=3T
# ERROR_CODE=0T
# ERROR_AUX_INFO=0T ERROR_ID=34001001757T ERROR_DATE=930711
ERROR_TIME=
# 231012 ERROR_INS=0T
# TIP_INFO
# PID=10T TIP_TYPE=transaction HVTIP_LIB_BANK=OT
# FILENAME=TIPDIAG$*DPSDMS7022J.

4. Now that you know which TIPLOG entry reflects your transaction execution, issue
a TDIAG$ command to PADS, supplying the TIPLOG number. This command is as
follows for the example:
#CMD >tdiag$ 4

Querying the DIAG Dump Using PADS

Now that you have located the correct DIAG dump in a PADS session, you are ready to
query this dump to find information for improving transaction performance.

There are two bank sizes that you are interested in obtaining: the size of the activity-
local stack (ALS), and the size of the heap, URTS$TABLES. To improve the
performance of the transaction execution, you want to set the initial size of these
banks to the maximum size of these banks during transaction execution. This
prevents costly execution-time bank expansion.

5–218 7831 4077–009

 Application Programming in a TIP Environment

Setting the Initial Size of the ALS

During static linking, set the initial size of the activity-local stack (ALS) so that
expansion of the ALS does not occur during program execution. Note, however, that
even if the ALS is expanded at execution time, TIP “sticking” and RESTART are not
lost for the transaction.

The ALS is where all UCS automatic program storage resides. The upper limit of the
ALS is set by the Exec to 0677777. The initial size is currently 010000 by default. Note
that the ALS grows downwards, from high addresses towards lower addresses.
Automatic storage is used internally by the UCS Runtime System and externally by
certain user-defined variables. Only UCS COBOL, UCS FORTRAN, and UCS C let the
programmer define storage as automatic:
• In UCS COBOL, all WORKING-STORAGE is automatic and is placed on the ALS, if
the PROGRAM-ID statement includes the INITIAL clause.
• In UCS C, all storage defined as automatic is always placed on the ALS.
• In UCS FORTRAN, local procedure-level variables are allocated on the ALS if both
the following are true:
- The variable is not declared as STATIC, is not in COMMON, and does not
have a DATA statement on it.
- The MIN-DBANK keyword option is used on the compilation of the
FORTRAN program.
Since there is plenty of memory available on the newer ClearPath machines, it is
recommended that you simply set the initial size of the ALS to a fairly large size and
then not worry about it. An initial size of 0400000 should be sufficient for most
programs. It is not recommended that you set it to the full maximum size of 0700000,
since then its lower limit would overlap that of basic mode code and some programs
may no longer operate. You should not therefore set an initial size of over 0600000.
Put the following statement in the static link of your executable program to set it to
the recommended 0400000:
SET ALS_INIT_SIZE = 0400000

If you do not wish to set the ALS to a simple value such as 0400000 or 0600000
(which should handle most all situations), you may want to determine exactly the size
your ALS bank was expanded to in the execution of your TIP ZOOM. To determine the
size that the ALS reached and to set the initial size of the activity-local stack for your
ZOOM, do the following:
1. Issue an "inq bankinfo b1" command to PADS. Register B1 always points to the
ALS.
2. Use a static linking command similar to the following to set the size of the ALS:
SET ALS_INIT_SIZE = 0xxxx

The default initial size of the ALS is 010000 words. The default maximum size is
0700000 words. (The maximum size is also 0700000 words.) The size you specify
for the ALS should be a multiple of 01000.

7831 4077–009 5–219

Application Programming in a TIP Environment

Example
The following is an example of the process. User input is bolded.

# CMD or ? > inq bankinfo b1

# Bank LLA: TL (5T) =>676000T#0\36864 Limit: 677777T Size: 10000T
# Base B1: TL (5T) =>0T#0\*
# GAP: (Read, Write), SAP: (Read, Write)
# type: (Extended,Data)
# locality: Task Local, Access by: Kernal
# Maximum upper limit: 1000000T Boundary: 0T
# Group ID: 0T
# D-Bank
# Dynamic
# Guard Mode

The "inq bankinfo b1" command requests a display of information about the ALS bank
that is always pointed to by base register B1. The first line of output from the "inq
bankinfo b1" command contains the size of the ALS during transaction execution. In
this case, the size is 10000T (010000 words). PADS uses T to denote octal. This is the
size you use in the static linking SET ALS_INIT_SIZE command for non-XPA systems.

The following static link runstream shows the commands resulting from this process.
Notice that ALS_INIT_SIZE is set to the same value as the SIZE output by the PADS
query.

@USE LINK$PF,SYS$LIB$*APP$7DPS.

@LINK,S ,QUAL*PROGFILE.DPSDMS
INCLUDE QUAL*PROGFILE.DPSDMS/COMP
INCLUDE UDS$$SVN*SCHEXECFILE.S$WORK/PERSONSUBTIP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR URTS$TABLES
SET ALS_INIT_SIZE = 010000
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

The SET command should be placed after the RESOLVE command and before the
PROCESS command in the static link of the transaction program.

5–220 7831 4077–009

 Application Programming in a TIP Environment

5.3.3.8. Setting the Initial Size of the Heap (URTS$TABLES)

During static linking, set the initial size of the heap (URTS$TABLES) so that expansion
of this bank part does not occur during program execution. You can do this most
easily by setting the size of URTS$TABLES to its maximum according to the preceding
general “URTS$TABLES Operation” discussion. However, the following older more
difficult method is still valid, though not recommended due to its complexity.

The heap is where dynamic runtime program storage resides. Dynamic storage is
used internally by the UCS Runtime System, RDMS 2200, DPS 2200, PCIOS files, and
Sort/Merge.

To set the initial size of the heap (URTS$TABLES), do the following:

1. Issue a "dump r15" command to PADS to provide the location of the bank that
contains the heap, URTS$TABLES.
The output will be in the form:
000nnnT 40000n060000T

You are interested in the value of n in the second number. This is the bank
descriptor index (BDI) for the bank that contains the heap. It is used as input to
the next PADS command.

2. Issue a "bankinfo$(PL(n))" where n is the BDI number obtained in #1.

Example
The following is an example of the process defined by #1 and #2. (User input is
bolded.)

# CMD > dump r15

# 000117T 400006060000T
#
# CMD > bankinfo$(PL(6))
# Bank LLA: PL(7T)+>60000T#0\799488 Limit: 133277T Size: 53300T
# Logical bank name (LBN):FL$DATA$BANK_$A
# GAP: (Read,Write), SAP: (Read,Write)
# Type: (Extended,Data)
# locality: Program Local, Access by: Ordinary
# Maximum upper limit: 1000000T Boundary:0T
# Group ID: 0T
# D-Bank
# Dynamic
# Guard Mode

The ”dump r15” command requests the bank descriptor index (BDI) for the bank that
contains the heap, URTS$TABLES. In this example, the first half of the second entry in
the output provides this BDI. The value is 400006, making the input to the next
command the value 6.

7831 4077–009 5–221

Application Programming in a TIP Environment

The “bankinfo$(PL(6))” command requests a display of information about the bank

containing the heap. The size of the entire bank is at the end of the first line of output.
In this case, the size is 53300T (053300 words). PADS uses T to denote octal.

3. Refer to the static link listing to find the size of the portions of the bank that are
not the heap, URTS$TABLES.
@LINK,S ,QUAL*UCSTST.DPSDMS
:
1 BANK GROUP EM$$GROUP_$A. 6 banks
:
5 Name: FL$DATA$BANK_$A. (new bank)
Bank_type = Data; LBN = 04
L,BDI = 0400006; Addr Range: 000060000 - 000133230
7 bank parts:
┌──1 QUAL*UCSTST(1).DPSDMS/COMP 1993 MAR 27 1910:55
│ Name: DPSDMS$3 000060000 - 000060113
│ 2 SYS$LIB$*EMOMRTS(857).URTS$TABLES 1993 Jan 19 1552:38
│ Name: SS$CGY_LIST 000060114 - 000060115
0472 │ 3 SYS$LIBEMOMRTS(857).URTS$TABLES 1993 Jan 19 1552:38
words ───-┤ Name: URST$TABLES$17 000060116 - 000060125
│ 4 SYS$LIB$*EMOMRTS(857).RTS-GCLSINT 1993 Jan 19 1552:38
│ Name: LV$GCLSINT 000060126 - 000060141
│ 5 SYS$LIB$*PADS(98).PADS$EMRTS 1993 Jan 7 1438:18
│ Name: PADS$LV 000060142 - 0000660341
│ 6 SYS$LIB$*LINKOMLIB(228).LS$INTERCEPT 1992 Dec 17 1417:57
└── Name: LS$INTERCEPT$04 000060342 - 000060471

052537 ───> 7 SYS$LIB$*EMOMRTS(857).URTS$TABLES 1993 Jan 19

1552:38
words Name: URTS$TABLES 000060472 -
000133230

4. Subtract the total size of the non-URTS$TABLES bank parts from the bank size
obtained from the PADS "bankinfo$" command.
In this example, the following subtraction produces the size of the heap
URTS$TABLES.

053300
- 000472
052606 is the size of URTS$TABLES

5. Round the result from the subtraction up to the nearest multiple of octal 1000. In
this case 053000. This is the size you use in the static linking SET command for
URTS$TABLES.
The following example static link runstream shows the commands resulting from
this process. If the static link already contains a SET SIZE FOR URTS$TABLES
command, it should be replaced by this new command.
@USE LINK$PF,SYS$LIB$*APP$DPS.
@LINK,S ,QUAL*PROGFILE.DPSDMS.
INCLUDE QUAL*PROGFILE.DPSDMS/COMP

5–222 7831 4077–009

 Application Programming in a TIP Environment

INCLUDE UDS$$SVN*SCHEXECFILE.S$WORK/PERSONSUBTIP
RESOLVE ALL REFERENCES USING SYS$LIB$EMOMRTS.,LIBCODENAME
SET SIZE = 053000 FOR URTS$TABLES
SET ALS_INIT_SIZE = 010000
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

The SET command should be placed after the RESOLVE command and before the
PROCESS command in the static link of the transaction program.

5.3.4. Transaction Processing Techniques for Improving

Performance
The OS 2200 Transaction Processing System provides many performance
improvement options that can affect the efficiency of your application, depending
upon its profile. Refer to the Transaction Processing Administration and Operations
Reference Manual and the Transaction Processing Programming Reference Manual
to learn about the following options:
• Using VALTAB settings
− Program Status Field (STA) setting of "K" to allow block transfer loading. Note
that not all programs may operate correctly under a BT-load since the initial
state of the loaded code is from a collection of banks of an executing version
of the transaction at a random time. In fact, the various bank copies may have
been taken at different times during an execution. So, if your program does
not operate correctly under BT-load, don't turn on BT-loads for your
transaction with the STA,K option.
− PCT Size Field (PCT).
− Program Type Field (PRG).
− Execution Priority Field (PRI).
− Queuing Priority Field (QPR).
− Recovery Option Field (REC).
− Wait Queue Length (WAI).
• Using resident online (RTPS) programs to load frequently used transaction
programs and cause them to be permanently "stuck" in real-time position in main
storage. A multiple-INITAL RTPS transaction is the most efficient.
• Using the program TIP RESTART technique to restart a transaction program at
termination time. This avoids the overhead of allocating and loading the restarted
program's banks. In combination with the STA,I option (“sticking”), great
improvements in performance may result. This method is much preferred over
the Block Transfer loading technique (STA,K) since it has few unexpected side-
effects.

7831 4077–009 5–223

Application Programming in a TIP Environment

5–224 7831 4077–009

Section 6
Application Programming in an HVTIP
Environment

This section discusses topics relating to application programming using HVTIP

transactions.

All examples in Section 6 show UCS COBOL transactions. Unless otherwise indicated,
the same techniques also apply to UCS FORTRAN and UCS C HVTIP transactions.

6.1. Basic Information for HVTIP Transaction

Programming
HVTIP transactions must be statically linked zero overhead object modules (HVTIP
ZOOM and HVTIP-II ZOOM).

Note: An HVTIP program can only use a single heap bank for data loading while an
HVTIP-II program can use multiple heap banks for data loading.

This subsection covers the following topics about creating HVTIP ZOOMs:
• Coding, compiling, and establishing the HVTIP environment for HVTIP initial control
programs (ICP) and subprograms
• Linking for functional testing

The information in 0 is a foundation for understanding later subsections.

One central example is used throughout 0. It is expanded upon as new topics are
discussed. Figure 6–1 illustrates the HVTIP transaction sequence for this example.

Figure 6–1. Example HVTIP Transaction—Generic

7831 4077–009 6–1

Application Programming in an HVTIP Environment

In this example
1. The transaction code xxxHVT schedules the initial control program, called xxxICP.
2. xxxICP calls subprogram xxxSUBX.
3. xxxSUBX calls subprogram xxxSUBY.

In the actual examples, the string xxx is replaced with either “DPS” or “MCB,”
depending upon which function calls are being used in the example. The examples
describe any differences that exist between using DPS 2200 functions or MCB
functions.

Examples in Section 6 show UCS COBOL. Except where noted, everything discussed
regarding these examples also applies to UCS FORTRAN and UCS C.

6.1.1. The HVTIP-II Environment

In SB6, the original UCS HVTIP environment (one program-level 262K data heap bank)
was replaced with a new HVTIP environment called HVTIP-II, which can have more
than one data heap bank.

Note: If the VALTAB for a transaction specifies data heap information with the
DLACTCNT, DLPRGCNT, DASIZL, DPSIZL, DSACTCNT, DSPRGCNT, DSLOWER,
DSUPPER, or DBMAX parameters, the actual transaction ZOOM must be an HVTIP-II
ZOOM if the additional heap banks are to be used.
If the VALTAB for a transaction does not specify data heap information and the
actual transaction is an HVTIP-II ZOOM that references BDIs other than program
level 5, the HVTIP heap manager will attempt to dynamically create the data heap
banks with the BDIs requested.

The HVTIP-II environment is capable of having more than one data heap bank available
for loading the nonshared static data of an HVTIP transaction. It consists of enhanced
Exec VALTAB options for specifying multiple data heap banks, and Linking System
syntax for a new type of ZOOM (an HVTIP-II ZOOM), to take advantage of the
additional data heaps.

The HVTIP-II environment is a scaling and performance improvement when compared

to the original UCS HVTIP environment. For example, an original UCS HVTIP
transaction’s nonsharable static data must fit in one small program-level heap bank
whose lower limit cannot be less than 045000. In order to allow large transactions to
run, the user must do one (or both) of two things:
• Use CANCEL or TRANSFER-WITH-CANCEL to free data space.
• Use the COBOL INITIAL clause to cause data to be allocated on the activity-local
stack (ALS) instead of the static data heap.

This can be expensive and can create very complex HVTIP applications just to manage
one small program-level heap bank effectively. Inevitably there is a limit to how much
ICP and subprogram data can be processed. The HVTIP-II environment is an attempt
to remove this capacity limitation in a performance-effective manner.

6–2 7831 4077–009

 Application Programming in an HVTIP Environment

At the beginning of an HVTIP-II transaction, the Exec will acquire any data heaps
requested through the VALTAB specifications. The pertinent data heap information is
passed to the HVTIP heap manager when the initial control program (ICP) is loaded. To
minimize the relocation path length, the LINK Processor SET LOWADR command
permits the user to indicate the starting virtual address of some or all of the data
segments (DSEG) and common block segments (CBSEG) of an HVTIP-II ZOOM. See
the Transaction Processing Programming Reference Manual and the Linking System
Programming Reference Manual for the exact syntax of the VALTAB specifications
and LINK commands applicable to the HVTIP-II environment.

The original UCS HVTIP environment allows you to specify, through VALTAB and LINK
commands, the following heap bank attributes:
• The initial size of the heap bank, using VALTAB DBK parameter (if it is zero, the
size of the HVTIP$$DBANK in the ICP will be used; you can control it with a SET
SIZE = n for HVTIP$$DBANK link statement).
• The maximum upper limit, using SET MAX_LIMIT = n for HVTIP$$DBANK at LINK
time (default is 0777777).
• The low address, using SET LOWADR = n for HVTIP$$DBANK at LINK time (default
equal to the smallest nonzero LOWADR of the input object module D-banks).

The HVTIP-II environment retains the main heap bank as an implicit small program-
level bank. Beyond the first heap, the VALTAB specification (for program-level and
activity-level heaps separately) indicates how many additional data heap banks are to
be used, the sizes of the large heap banks, and the size and starting offset of the small
heap banks. The LINK Processor SET LOWADR command allows you to specify for
any and all segments (like the original UCS HVTIP) its starting offset and the bank into
which it is to be allocated. Note that you can still use the original form of the SET
LOWADR command for the default heap bank (without BDI specifications); it is also
part of the HVTIP-II environment. You must use the new SET LOWADR syntax,
however, for all additional heaps specified through the VALTAB settings if the default
is not changed.

For the remainder of this section the differences between the original UCS HVTIP and
the new HVTIP-II environments will be noted as appropriate. From an application
development perspective, all of the capabilities of the original UCS HVTIP environment
have been retained in the new HVTIP-II environment. The new capabilities are add-ons
once an HVTIP-II ZOOM is specified through the LINK Processor OUTPUT or PROCESS
FOR EXTENDED commands.

7831 4077–009 6–3

Application Programming in an HVTIP Environment

6.1.2. Coding HVTIP Transactions

UCS programming supports the following host languages for HVTIP transactions:
• COBOL
• FORTRAN
• C

Table 6–1 shows the interfaces supported for these host languages.

Table 6–1. Transaction Processing Interfaces from UCS Languages

UCS COBOL UCS FORTRAN UCS C

DPS 2200 DPS 2200 DPS 2200

MCB MCB MCB
Non-message-handling Non-message-handling Non-message-handling
primitives primitives primitives
DMS 2200 DMS 2200
RDMS 2200 RDMS 2200 RDMS 2200
Interpreter SQL Interpreter SQL Interpreter SQL
Embedded SQL Module SQL Embedded SQL
SFS 2200 SFS 2200 SFS 2200
Relative access (direct Direct access (direct Binary access (direct
SDF) SDF) SDF)
Indexed access
(MSAM)
PCIOS PCIOS PCIOS
FCSS FCSS FCSS

For HVTIP transactions:

• DPS 2200 functions are supported for UCS COBOL, UCS FORTRAN, and UCS C.
• MCB functions are supported for all host languages.
• Most non-message-handling primitives are supported for all host languages.
• The COMPOOL message-buffering primitives are not supported in UCS
programming for any language.
• DMS 2200, the network/hierarchical database model, is supported for
UCS COBOL and UCS FORTRAN only.
• All host languages can access the relational database model, RDMS 2200.
• UCS COBOL and UCS C have added an embedded SQL interface for the relational
database model, RDMS 2200.

6–4 7831 4077–009

 Application Programming in an HVTIP Environment

• As of SB5R2, UCS FORTRAN has added a module SQL interface for the relational
database module, RDMS 2200.
• All host languages can access the conventional shared file model, SFS 2200.
• All host languages support access to PCIOS files.
• All host languages support access to FCSS files.

6.1.2.1. Designating a Transaction ZOOM as an ICP or a Subprogram

An HVTIP transaction consists of one or more HVTIP ZOOMs.

You must identify an HVTIP transaction as one of the following:

• An initial control program (ICP) (one per transaction)
• A subprogram (zero or more per transaction)

The method for specifying whether a transaction ZOOM is for an ICP or a subprogram
differs in each host language:
• UCS COBOL
The default is an ICP or main program. A subprogram is designated if the
PROCEDURE DIVISION statement includes a “USING ......” clause. If this clause is
not present and you want to create a subprogram, use the SUBPROGRAM
keyword option on the UCS COBOL compiler call.
• UCS FORTRAN
The default is an ICP or main program. To create a subprogram, code the
SUBROUTINE statement or the FUNCTION statement in the FORTRAN program.
• UCS C
Any program containing a function named “main” is an ICP. All other programs are
subprograms.

In preparation for SB6 enhancements, when you link each ZOOM, you should specify
one of the following statements:
• SET ICP = TRUE
• SET ICP = FALSE

7831 4077–009 6–5

Application Programming in an HVTIP Environment

6.1.2.2. Defining Storage in HVTIP Transactions

In HVTIP, there are two types of storage used by the ICP and subprograms:
• Shared storage
• Local storage

Shared Storage
Shared storage is storage shared by the ICP and the subprograms it calls. In other
words, this storage is visible to all program units in the transaction sequence. For UCS
HVTIP, this shared storage must be defined as common blocks. There is only one
copy of this storage at execution time. In COBOL, C, and FORTRAN, common storage
is defined by using common blocks. Common blocks are created by using
• The COMMON-STORAGE SECTION or EXTERNAL clause in COBOL
• The COMMON statement in FORTRAN
• The #pragma common statement in C. Note that C storage is activity-level by
default. If you want program-level common blocks, you will also need to bracket
the declarations you want to be at program-level with #pragma shared begin
program and #pragma shared end program statements.

Note: When coding the common storage definition, you must have the identical
definition in the ICP and all subprograms that could be called by the transaction
sequence for that ICP.

The segments for an FLSS subsystem are also loaded into “heap” banks by the HVTIP
loader. You therefore can also share the common blocks in your HVTIP transaction
with any FLSS subsystems you may call if the following statement is used in the
SSDEF of the FLSS subsystem:
SHARE HEAP BANKS WITH OTHER SUBSYSTEMS INCLUDING HVTIP

6–6 7831 4077–009

 Application Programming in an HVTIP Environment

Here is a C example of a program which defines two common blocks

(EMPLOYEE_COUNT and CURRENT_EMPLOYEE_DATA) that could be shared with
FORTRAN and COBOL (and C) code and which would be visible to other HVTIP ZOOMs
(or FLSS object modules) that are called during the transaction:
#pragma shared begin program /* Put our COMMON blocks at
program level */
int EMPLOYEE_COUNT = 0;
struct employee
{ char name[48];
int number;
int salary;
int start_date; } CURRENT_EMPLOYEE_DATA[10000];

#pragma common EMPLOYEE_COUNT

#pragma common CURRENT_EMPLOYEE_DATA
#pragma shared end program
#define BAD_DATA -99

int get_salary(int emp_no)

{
if(emp_no <= EMPLOYEE_COUNT && emp_no >= 0)
return(CURRENT_EMPLOYEE_DATA[emp_no].salary);
else
return(BAD_DATA);
}

Local Storage
Local storage is storage that is visible only to the ICP or subprogram ZOOM that
defines it. All data storage generated internally by the UCS compilers is local storage.
User variables may also be in local storage:
• In COBOL, this storage is defined in the WORKING-STORAGE SECTION, those 01
variables that do not have the EXTERNAL attribute.
• In FORTRAN, this is all variables that are not in common blocks.
• In C, this is all variables other than those placed into common blocks.

Sharing Storage by Passing Parameters

Parameter passing is a method for sharing any type of storage. The parameters are
defined in the calling program. They are made visible to each subprogram to which
they are passed.

This method of sharing storage is available in all three host languages. In COBOL and
FORTRAN, the actual parameters are passed. In C, pointers to the actual parameters
must be passed to achieve the same effect.

When passing many parameters, it is a good idea to define the global data as a
structure and pass only one parameter (the structure) or, in the case of UCS C, pass
only one pointer to the structure.

7831 4077–009 6–7

Application Programming in an HVTIP Environment

Static and Automatic Storage

There are two types of HVTIP calls:
• Call interface (HV$CALL)
• Transfer-with-cancel interface (HV$XFR$CANCL)

For more information on these types of calls, refer to

• "Calling Subprograms by Using an HVTIP Call Interface (HV$CALL)"
• "Calling Subprograms by Using an HVTIP Transfer-with-Cancel Interface
(HV$XFR$CANCL)"

The use of static and automatic storage is important in understanding the two types
of HVTIP calls. There are four possible locations for HVTIP data bank storage:
• The HVTIP heap data bank and the HVTIP-II heap data banks
• Hold static storage
• The activity-local stack (ALS)
• Hold automatic storage

Whether static or automatic storage is used depends on the UCS language in use:
• UCS COBOL
For UCS COBOL, all COMMON-STORAGE is static storage.
Whether WORKING-STORAGE is static or automatic depends on how the program
is coded. If the INITIAL clause appears on the PROGRAM-ID statement,
WORKING-STORAGE is allocated as automatic storage and initialized each time the
ICP or subprogram is called. If there is no INITIAL clause, WORKING-STORAGE is
placed in static storage. For more information on the COBOL INITIAL clause, refer
to “Using the COBOL INITIAL Clause.”
• UCS FORTRAN
For UCS FORTRAN, all COMMON blocks are in static storage.
Local variables (variables declared within a subprogram), can be either in static or
automatic storage. Local variables will be put into automatic storage if the
MIN-DBANK keyword option is supplied to the compilation. An exception is local
variables that have initial values (DATA statements initializing them). Local
variables with initial values are placed into static storage.
• UCS C
UCS C allows the program to specifically define storage as static or automatic.
File-level declarations are static storage. Any declaration with the static attribute
also are given static storage. Variables placed into COMMON storage with the
#pragma common statement are given static storage also. For more information
on how to do this, refer to the C Compiler Programming Reference Manual
Volume 1.

6–8 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.2.3. Coding HVTIP Transactions That Use DPS 2200 Functions

DPS 2200 provides a simple CALL interface to perform its work.

DPS 2200 supports transactions written in UCS COBOL, UCS FORTRAN, and UCS C.

The code used to call DPS 2200 is the same in UCS programming as it was in non-UCS
programming. The same DPS 2200 software and forms files can be used in both
environments simultaneously.

7831 4077–009 6–9

Application Programming in an HVTIP Environment

UCS DPS 2200 HVTIP transactions can use either COMPOOL or MCB message
buffering, depending on
• The VALTAB STATUS (STA) keyword setting
• The availability of the MCB software
• The designation of MCB message buffering in the CMS 1100 configuration

If all of the following are true, DPS 2200 uses MCB message buffering:
• STA, J is specified in the VALTAB entry.
• MCB software is available.
• MCB message buffering is designated in CMS 1100.

If no J is specified on the STA keyword, then DPS 2200 uses COMPOOL message
buffering.

For more information on DPS 2200 coding, refer to the DPS 2200 Run-Time
Programming Reference Manual.

6–10 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.2.4. Coding HVTIP Transactions That Use MCB Functions

The same MCB system software can be used in both UCS and non-UCS programming,
simultaneously.

UCS COBOL, FORTRAN, and C all support calls to MCB functions. MCB functions can
be directly called from all UCS HVTIP transactions.

The generic call syntax for these MCB calls is as follows:

UCS COBOL
CALL 'MCB$ENT' USING mcb-packet, mcb-status
[,msg-buffer [,multi-dest-list]].

UCS FORTRAN
CALL MCB$ENT(mcb_packet, mcb_status [,msg_buffer [,multi_dest_list]])

UCS C
mcb_ent(&mcb_packet.&mcb_status [,&msg_buffer [,&multi_dest_list]])

7831 4077–009 6–11

Application Programming in an HVTIP Environment

Notice that these calls to MCB differ from their non-UCS counterparts. They include
two additional optional parameters:
• msg-buffer/msg_buffer
Identifies the storage area into which messages are read, and from which
messages are sent by the transaction. For UCS COBOL, this parameter eliminates
the need for the ASCII COBOL CLOCTE call (which sets up this buffer’s address).
• Mult-dest-list/multi_dest_list
Provides a simple method for identifying a multiple-destination list of position
identifiers (PID). For UCS COBOL, this parameter eliminates the need for the ASCII
COBOL CLOCTE call (which sets up the buffer’s address).

Transactions that use MCB functions require the following:

• Declarations of the MCB functions
• Allocation of storage space for the MCB packet
• MCB error message handling buffers
• In some cases, a message buffer

To aid the UCS programmer in coding these, the MCB release tape includes precoded
sample UCS COBOL and UCS FORTRAN procedures for these buffers. The two
elements containing these procedures are found in the MCB installation file. They are
also found in the Unisys-supplied system procedure file SYS$LIB$*PROC$. They have
the following names:

Language Procedure Name

UCS COBOL MCBDEF-UCOB

UCS FORTRAN MCBDEF-UFTN

For UCS C, the following #include statement provides the definitions for the MCB
information. This element is found in the C include file.
#include <mcb.h>

For more information on MCB coding, refer to the MCB Programming Reference
Manual.

6–12 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.2.5. Coding HVTIP Transactions That Use the Non-Message-

Handling Primitives
UCS programming supports the following list of non-message-handling primitives for
COBOL, FORTRAN, and C:
• CONECT and DISCON
• COMMIT and ROLLBACK
• ALL FCSS file handling functions
• The TIMER primitives for scheduling transaction execution at a future time:
TIMABS, TIMDEL, TIMREL, TIMUPA, and TIMUPR
• The execution-option-indicator primitives: UOPAND, UOPGET, and UOPTOR

UCS does not support

• The COMPOOL message-handling primitives
• The KONS primitives

Primitive coding has not changed in UCS, except for the function names for the UCS
COBOL version.

Previous Name UCS Name

CCONET CONECT
CDISCN DISCON
CCMMIT COMMIT
CRLBAK ROLLBACK
CFCSS FCSS
CUOPND UOPAND
CUOPGT UOPGET
CUOPTR UOPTOR
CTMABS TIMABS
CTMDEL TIMDEL
CTMREL TIMREL
CTMUPA TIMUPA
CTMUPR TIMUPR

UCS COBOL still supports the previous name of each of these calls in transactions;
however, when you code new UCS transactions or upgrade existing transactions to
UCS, it is recommended that you use the new name.

7831 4077–009 6–13

Application Programming in an HVTIP Environment

New TIP primitive procedures for UCS COBOL and UCS FORTRAN that require no
special keyword options are available as of SB4. They are found in TIP$*TIPLIB$. The
new procedure names are USYSDF and UCMPDF.

For UCS C, the following #include statement provides the definitions for the TIP
primitives. This element is found in the C include file.
#include <tip.h>

For more information on TIP primitives, refer to the Transaction Processing

Programming Guide.

6.1.2.6. UCS Language Coding Considerations

The programming reference manual for each UCS language includes a section on
transaction processing. This section gives specific information about using that
language in the TIP and HVTIP environments. These documents are as follows:
• COBOL Compiler Programming Reference Manual Volume 2
• FORTRAN Compiler Programming Reference Manual Volume 2
• C Compiler Programming Reference Manual Volume 2

6.1.2.7. Setting Up an HVTIP Transaction Sequence

An HVTIP transaction sequence consists of
• An ICP
• All subprograms that the ICP could possibly call

The ICP and subprograms are kept in an HVTIP library. Each ICP and subprogram is
identified by
• An HVTIP library number
• The bank number within that HVTIP library

In HVTIP processing, the end user enters a transaction code at the terminal or work
station. (This transaction code is identified by a precoded entry known as a VALTAB
entry.) Entering the transaction code on a TIP screen causes the transaction to be
scheduled, which in turn causes the ICP to be loaded and execution to begin. The ICP
can call one or more subprograms. These subprograms in turn can call other
subprograms, and so on.

The following subsections discuss the coding and setting up required to define an
HVTIP transaction sequence.

6–14 7831 4077–009

 Application Programming in an HVTIP Environment

Coding ICP VALTABs

Each ICP has at least one VALTAB entry defining its storage location and execution
time options.

Setting up an ICP VALTAB entry is the same in UCS programming as in non-UCS

programming. For a detailed description of the format of a VALTAB entry, refer to the
Transaction Processing Administration and Operations Reference Manual.

The following example shows the VALTAB entry for the example initial control
program DPSICP:
900 NAM,DPSICP ACT,DPSHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV
900 REC,Z AUD,3 PRT,PR

The following example shows the VALTAB entry for the example initial control
program MCBICP:
920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV
920 REC,Z AUD,3 PRT,PR

A brief definition of the VALTAB keywords used in these examples follows:

900 and 920

Identify a unique number for the VALTAB entry. The number is required at the
start of each line for the VALTAB entry.

NAM,xxxxxx
Identifies the program name.

ACT,xxxxxx
Identifies the transaction code.

PRG,5
Identifies the Program Type as HVTIP.

STF,0
Sets the Standard File number to denote the use of HVTIP libraries and the TPUR
utility.

STA,J
Denotes that MCB message buffering will be used if the Communication
Management System (CMS 1100) is configured for MCB message buffering and
the MCB software is available.

QPR,1
Specifies the location in the input queuing tree structure where input requests are
to be queued for this transaction program.

7831 4077–009 6–15

Application Programming in an HVTIP Environment

REC,Z
Denotes that this is a recoverable step.

AUD,3
Identifies the audit trail number (application group number).

PRT,PR
Identifies the transaction printer queue.

OPT,TV
Allows the TIPDIAG$ file to be created for diagnostics upon termination.
(TIPTRACE must also be set to ON in the FLAGBOX to receive a TIPDIAG$ file.)
Also allows MCB to use a reduced output path length (ROPL) for non-recoverable
output messages.

Note: The use of the IND,O VARTAB is no longer recommended. It indicates the
use of TIP memory by the transaction, but this is no longer meaningful on the
current hardware with paging memories. In addition, use of the IND,O option
causes the transaction to error-off if an ER MCORE$ is done to expand a bank, If a
transaction needs to expand a bank, it should be allowed to do it without the
transaction erroring off.

6–16 7831 4077–009

 Application Programming in an HVTIP Environment

HVTIP-II VALTABs
HVTIP provides you with the following optional VALTAB options. The values given
should match those given in the OUTPUT HVTIP2 statement in the static link of the
ICP. These VALTABs basically supply additional D-banks to the transaction to expand
address space. If the VALTABs are not supplied and the transaction requires
additional space that cannot be satisfied by the primary HVTIP heap bank (BDI 5), then
run-time CREATE_BANK calls are done by URTS to acquire the needed space. The
CREATE_BANK calls cause the transaction to lose TIP “sticking” and RESTART, causing
degraded performance. The extra D-banks provide space for loading HVTIP programs,
for UC malloc space, and for loading data for Fast Load Self Contained subsystems
(FLSS).

DSP[RGCNT], <number>
Indicates how many program level small banks (beyond the main heap) are
needed. The default is zero.

DLP[RGNT],<number>
Indicates how many program level large banks are needed. The default is zero.

DPS[IZL],<number>
Indicates how many BDIs each program level large bank should span. Each BDI
indicates 262K words of storage. Large banks start at offset zero, and are an
integral number of 262K blocks (BDIs). The default is 2.

DSA[CTCNT],<number>
Indicates how many activity level small banks are needed. The default is zero.

DLA[CTCNT],<number>
Indicates how many activity level large banks are needed. The default is zero.

DAS[IZL],<number>
Indicates how many BDIs each activity level large bank should span. The default is
2.

DSL[OWER],<number>
Indicates the lower limit of each additional small bank (excluding the primary heap
bank) for both program and activity level banks. The default is zero.

DSU[PPER],<number>
Indicates the upper limit of each additional small bank (excluding the primary heap
bank) for both program and activity level banks. The default (and maximum) value
is 0777777.

Use of the DSL and DSU VALTABs is recommended so that the resulting small
heap banks do not cause address overlap problems when calling basic mode
programs. Typical lower-limit and upper-limit values for programs using UDS are
0130000 and 0577777.

7831 4077–009 6–17

Application Programming in an HVTIP Environment

HVTIP-II VALTABs and Linking

The following shows the relationship between the values given in the OUTPUT HVTIP2
static link statement (used when linking the ICP and HVTIP subprograms), and the ICP
VALTAB values given to VTBUTL. The heap banks marked as pooled are for use by
the UC malloc function and for supplying heap space for FLSS subsystems that may
be called by the transaction. The other D-banks supply heap space for loading the
segment (data) of the HVTIP ICP and subprograms. This example is construed to
show those relationships, and is much more complicated than any actual application is
likely to be:

. Setup an HVTIP heap environment consisting of:

. Program-level banks:
. Small banks: (4, each with limits of 060000 to O577777)
. BDIs: 06
. 07
. 010 (pooled)
. 011 (pooled)
. Large banks: (2, 2 BDIs each)
. BDIs: 012 & 013
. 014 & 015 (pooled)
. Activity-level banks:
. Small banks: (4, each with limits of 060000 to 0577777)
. BDIs: 03
. 04 (pooled)
. 05 (pooled)
. 06 (pooled)
. Large banks: (1, having 3 BDIs)
. BDIs 07, 010, & 011 (pooled)
.
. The standard HVTIP heap bank (Program-level BDI 5) is also
. available for loading HVTIP data.
.
. The above bank allocations correspond to the following
. VALTAB settings:
.
. DSPRGCNT, 4 DLPRGCNT, 2 DPSIZL, 2
. DSACTCNT, 4 DLACTCNT, 1 DASIZL, 3
. DSLOWER, 060000 DSUPPER, 0577777
.
. Here is the OUTPUT HVTIP2 statement to match
. these bank allocations:
.
OUTPUT HVTIP2
WITH
TS_MISMATCH_ACTION = CANCEL
SMALL_BANK_LIMITS = 060000 TO 0577777

USING
4 SMALL_BANKS,
2 POOLED_SMALL_BANKS,
2 LARGE_BANKS,

6–18 7831 4077–009

 Application Programming in an HVTIP Environment

1 POOLED_LARGE_BANKS,
LARGE_BANK_SIZE = 2
FOR PROGRAM_LEVEL_HEAP
USING
4 SMALL_BANKS,
3 POOLED_SMALL-BANKS,
1 LARGE BANKS,
1 POOLED_LARGE_BANKS
LARGE_BANK_SIZE = 3
FOR ACTIVITY_LEVEL_HEAP

Using HVTIP Libraries

All HVTIP ICPs and subprograms ready for execution must be stored in a special TIP
file known as an HVTIP library. The TPUR utility
• Sets up the HVTIP library
• Loads the ICP ZOOM and the subprogram ZOOMs into the HVTIP library

For detailed information on how to set up and handle HVTIP libraries, refer to the
Transaction Processing Administration and Operations Reference Manual.

The following figure shows the HVTIP library and bank numbers for the DPS 2200
example transaction. HVTIP library 22 is used. DPSICP is in bank 1, DPSSUBX in bank
2, and DPSSUBY in bank 3.

The following figure shows the HVTIP library and bank numbers for the MCB example
transaction. HVTIP library 22 is used. MCBICP is in bank 6, MCBSUBX in bank 7, and
MCBSUBY in bank 8.

7831 4077–009 6–19

Application Programming in an HVTIP Environment

Calling an HVTIP Subprogram

Case Sensitivity for Reference Names
In UCS COBOL and UCS FORTRAN, references (calls) to subprogram names are not
case sensitive. The calls are converted to uppercase by these two compilers
automatically. The C programming language, however, is case sensitive. You can
code all UCS C subprogram call names using both uppercase and lowercase
characters. To use lowercase characters in UCS C subprograms, refer to “Creating the
HVCALLS MASM Object Module,” which follows.

Defining the Location of Called Subprograms with an HVCALLS Element

Whenever an HVTIP ICP ZOOM or subprogram ZOOM calls an HVTIP subprogram
ZOOM, a method for locating that called subprogram must be established. Since there
is no VALTAB entry for a subprogram, the location cannot be provided by using a
VALTAB entry. Instead, you must code an extended mode MASM routine that defines
the location.

Note: Unisys supports “extended mode” MASM usage (assembler directive

$EXTEND with or without assembler directive $OBJ) only in software written by
Unisys or in interfaces written by the customer that explicitly require extended
mode assembler-produced elements according to the documentation written by
Unisys. In a “nonextended mode” MASM usage (absence of assembler directive
$EXTEND), Unisys does not support the generation of object modules (use of
assembler directive $OBJ) but will continue to provide full support for the
generation of other provided element types which are not object modules (absence
of both the $EXTEND and $OBJ assembler directives).

This MASM routine is known as an HVCALLS element. An HVCALLS element

generates the definitions needed to call or transfer (with cancel) to the HVTIP
subprogram ZOOM. The generated definitions supply the information required to
• Locate the entry point of the called subprogram
Use ll,bbbb,offset form, where ll,bbbb stands for the HVTIP library and bank
number.
• Define the type of call being made to the subprogram (call or transfer-with-cancel)

HVCALLS elements are created by coding a small MASM element that uses the
PROCs that are defined in SYS$LIB$*LINK.HVTIP$CALLS. (SYS$LIB$*LINK is one of
the installation files for the Linking System.) The MASM procedures (procs) used to
generate the required definitions are found in the HVTIP$CALLS element. Instructions
for using the HV$CALL, HV$XFR, HV$XFRCANCL, and HV$VECTOR PROCs are also in
the HVTIP$CALLS element. Note that in ClearPath OS 2200 Release 7.0, the HVTIP
library number limit was expanded from 63 (077) to 2047 (03777), and the bank number
limit was expanded from 4095 (07777) to 16383 (037777).

After you create the HVCALLS MASM object module containing the definitions, you
statically link it with the calling HVTIP ICP or subprogram ZOOM.

Note: An HVTIP or HVTIP-II ZOOM should not contain an entry point definition
with the same name as an HVCALLS definition. If this happens, the first one
included during static linking is used, and a duplicate definition message occurs.

6–20 7831 4077–009

 Application Programming in an HVTIP Environment

Types of HVTIP Calls

There are two different types of calls that can be made to an HVTIP subprogram:

Type of Call Name Description

Call interface HV$CALL Similar to the non-UCS HVTIP call

interface
Transfer-with- HV$XFR$CANCL Similar to the non-UCS HVTIP transfer
cancel interface interface

You can combine these two types of high-level language calls in any feasible order to
meet the needs of the user application. The subsections that follow define each type
of call and show an example of its use.

The following figure illustrates the calls made in the DPS 2200 example. DPSICP calls
DPSSUBX, using the transfer-with-cancel interface (HV$XFR$CANCL). In turn,
DPSSUBX calls DPSSUBY, using the call interface (HV$CALL).

The following figure illustrates the calls made in the MCB example. MCBICP calls
MCBSUBX by using the transfer-with-cancel interface (HV$XFR$CANCL). In turn,
MCBSUBX calls MCBSUBY by using the call interface (HV$CALL).

7831 4077–009 6–21

Application Programming in an HVTIP Environment

DPS 2200 and MCB use the same method for defining these types of calls. Therefore,
only the DPS 2200 example is shown in the subsections that follow.

Calling Subprograms by Using an HVTIP Call Interface (HV$CALL)

How an HVTIP Call Functions
In the example transaction, shown below, the HVTIP call interface is used when
subprogram DPSSUBX calls subprogram DPSSUBY.

Subprogram DPSSUBX calls subprogram DPSSUBY by using the MASM proc

HV$CALL. This allows a return to subprogram DPSSUBX to take place at a later point
in time. In this example, this return occurs when the exit is reached in subprogram
DPSSUBY.

The call interface has no effect on the calling program’s automatic storage or static
storage. (For information on types of HVTIP storage, refer to “Defining Storage in
HVTIP Transactions.”) Both types of storage are kept intact. Return information is
kept so a return can be made to the calling program. Therefore, in our example, the

6–22 7831 4077–009

 Application Programming in an HVTIP Environment

static storage and automatic storage for DPSSUBX remain intact when the call to
DPSSUBY takes place. Return information for DPSSUBX is saved.

When the return occurs

• All automatic storage (ALS storage) belonging to the subprogram that caused the
return is released.
• No static storage (HVTIP heap data bank) is released.
• The return information used to make the return is eliminated.

Therefore, in our example, when the exit is reached in DPSSUBY

• The return to DPSSUBX takes place.
• The automatic storage (ALS) for DPSSUBY is released.
• The DPSSUBX return information is eliminated.

This processing is similar to the HVTIP call interface in non-UCS programming.

Creating the HVCALLS MASM Object Module

Example 6–1 shows the extended mode MASM source code required to direct the
HVTIP call between DPSSUBX and DPSSUBY. The HVCALLS object module produced
by this routine will be statically linked to the calling program, DPSSUBX.

(1) @USE MASM$PF1,SYS$LIB$*LINK. . Get HVTIP$CALLS from

(1) @ASG,A MASM$PF1 . Linking System product file

(2) @MASM,N ,QUAL*UCSTST.HVCALLSDEF/DPSSUBY

$OBJ
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
(3) HV$CALL 22,3,0 'DPSSUBY'
$END

Example 6–1. Source Code to Create HVCALLS Object Module (HV$CALL)

Explanation
1. These statements obtain the MASM procs that are required to generate the
needed definitions. These procs are located on the Linking System release tape in
the element SYS$LIB$*LINK.HVTIP$CALLS.
2. The output of the assembly is placed into the object module
HVCALLSDEF/DPSSUBY. This is the HVCALLS element. Thus the reference in
subprogram DPSSUBX to subprogram DPSSUBY is resolved by the definition in
HVCALLSDEF/DPSSUBY.
3. This statement generates a code definition for DPSSUBY which, when called,
invokes the Executive system HVTIP call interface (HV$CALL$SUB) to make a call
to the HVTIP subprogram in HVTIP library number 22, bank number 3, at offset 0.

This statement can be specified using one of the following formats:

7831 4077–009 6–23

Application Programming in an HVTIP Environment

Format 1

HV$CALL ll,bbbb,offset 'subprogram-name'

Format 2

subprogram-name HV$CALL ll,bbbb,offset

where

ll
is the HVTIP library number.

bbbb
is the bank number within the designated HVTIP library.

offset
instructs Exec where to begin execution in the subprogram. If this value is zero,
the default starting address of the subprogram ZOOM is used.

’subprogram-name’
is the name of the subprogram being called using Format 1. The subprogram
name can contain any character allowed by the UCS language being used. The
HVCALLS MASM source code requires an $ASCII directive if lowercase characters
are used in the subprogram name. The following is an example.
$OBJ
$ASCII
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
HV$CALL 22,3,0 'DPSSUBY'
$END

subprogram-name
is the name of the subprogram being called using Format 2. Only uppercase
characters and numbers are allowed for subprogram names specified in this field.
If the subprogram name contains other ASCII characters supported by the UCS
languages, Format 1 must be used.

Format 1 is the preferred method for coding HV$CALL statements.

When the COBOL statement “CALL ’DPSSUBY’.” is encountered, the definition created
by the HV$CALL statement is used to determine the HVTIP library and bank number to
be loaded.

If you program in FORTRAN, use a subroutine call in place of the COBOL subprogram
call. If you program in C, use a function call in place of the COBOL subprogram call.

Parameters are allowed on the call interface.

6–24 7831 4077–009

 Application Programming in an HVTIP Environment

The HVCALLS MASM source code can contain a mixture of HV$CALL and
HV$XFR$CANCL statements. However, the entry point name of the ZOOM being
linked should not appear in any of the HV$CALL or HV$XFR$CANCL statements in the
HVCALLS MASM element for that ZOOM or the static linker will produce duplicate
definition warnings and the program may not execute correctly.

To put the entry point name of the ZOOM being linked into the HVCALLS MASM
source code, add a DELETE DEFINITIONS (zoom-entry-point-name) BEFORE
RESOLUTION statement to the static link. For more information, see 6.1.4. The
following is an example of the static link format:

@USE LINK$PF...
@LINK...
OUTPUT HVTIP
INCLUDE HVCALLS ELEMENT
DELETE DEFINITIONS (ZOOM-ENTRY-POINT-NAME) BEFORE RESOLUTION
INCLUDE COMPILER-OM
RESOLVE....
DELETE ALL DEFINITIONS EXCEPT...
@EOF

Calling Subprograms by Using an HVTIP Transfer-with-Cancel Interface

(HV$XFR$CANCL)

How an HVTIP Transfer-with-Cancel Functions

In the example transaction, shown below, the HVTIP transfer-with-cancel interface is
used when initial control program DPSICP calls subprogram DPSSUBX.

Initial control program DPSICP calls subprogram DPSSUBX using the MASM proc
HV$XFR$CANCL. Using this proc eliminates all possibilities of returning to the caller.

A transfer-with-cancel releases all automatic storage (ALS storage) and all static
storage (HVTIP heap data bank) belonging to all previously called subprograms.
Common storage is not released. The ICP static storage is also not released, since it

7831 4077–009 6–25

Application Programming in an HVTIP Environment

contains the UCS Runtime System internal data. (For information on types of HVTIP
storage, refer to “Defining Storage in HVTIP Transactions.”)

All return information accumulated by the HVTIP transaction sequence is canceled. A

point of no return is established. Processing can only go forward.

Therefore, in our example

• DPSICP automatic storage is released.
• The common blocks, the ICP static storage, and any internally allocated storage
are not released and remain in the HVTIP heap data bank.
• All return information accumulated by the HVTIP transaction sequence is canceled.

This processing is similar to the HVTIP transfer interface in non-UCS programming.

Creating the HVCALLS MASM Object Module

Example 6–2 shows the extended mode MASM source code required to direct the
HVTIP transfer-with-cancel between DPSICP and DPSSUBX. The HVCALLS object
module produced by this routine will be statically linked to the calling program,
DPSICP.

(1) @USE MASM$PF1,SYS$LIB$*LINK. . Get HVTIP$CALLS from

(1) @ASG,A MASM$PF1 . Linking System product file

(2) @MASM,N ,QUAL*UCSTST.HVCALLSDEF/DPSSUBX

$OBJ
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
(3) HV$XFR$CANCL 22,2,0 'DPSSUBX'
$END

Example 6–2. Source Code to Create HVCALLS Object Module (HV$XFR$CANCL)

Explanation
1. These statements obtain the MASM procs that are required to generate the
needed definitions. These procs are located on the Linking System release tape in
the element SYS$LIB$*LINK.HVTIP$CALLS.
2. The output of the assembly is placed into the object module
HVCALLSDEF/DPSSUBX. This is the HVCALLS element. Thus, initial control
program DPSICP’s reference to subprogram DPSSUBX is resolved by the definition
in HVCALLSDEF/DPSSUBX.
3. This statement generates a code definition for DPSSUBX which, when called,
invokes the Executive system HVTIP transfer-with-cancel interface
(HV$XFR$CANCL) to transfer to the HVTIP subprogram in HVTIP library number 22,
bank number 2, at offset 0.

This statement can be specified using one of the following formats:

6–26 7831 4077–009

 Application Programming in an HVTIP Environment

Format 1
HV$XFR$CANCL ll,bbbb,offset 'subprogram-name'

Format 2
subprogram-name HV$XFR$CANCL ll,bbbb,offset

where

ll
is the HVTIP library number.

bbbb
is the bank number within the designated HVTIP library.

offset
instructs Exec where to begin execution in the subprogram. If this value is zero,
the default starting address of the subprogram ZOOM is used.

’subprogram-name’
is the name of the subprogram being called using Format 1. The subprogram
name can contain any character allowed by the UCS language being used. The
HVCALLS MASM source code requires an $ASCII directive if lowercase characters
are used in the subprogram name. The following is an example.

$OBJ
$ASCII
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
HV$XFR$CANCL 22,2,0 'DPSSUBX'
$END

subprogram-name
is the name of the subprogram being called using Format 2. Only uppercase
characters and numbers are allowed for subprogram names specified in this field.
If the subprogram name contains other ASCII characters supported by the UCS
languages, Format 1 must be used.

Format 1 is the preferred method for coding HV$XFR$CANCL statements.

When the COBOL statement “CALL ’DPSSUBX’.” is encountered, the definition created
by the HV$XFR$CANCL statement is used to determine the HVTIP library and bank
number to be loaded.

If you program in FORTRAN, use a subroutine call in place of the COBOL subprogram
call. If you program in C, use a function call in place of the COBOL subprogram call.

No parameters are allowed on the transfer-with-cancel interface.

7831 4077–009 6–27

Application Programming in an HVTIP Environment

The HVCALLS MASM source code can contain a mixture of HV$CALL and
HV$XFR$CANCL statements. However, the entry point name of the ZOOM being
linked should not appear in any of the HV$CALL or HV$XFR$CANCL statements in the
HVCALLS MASM element for that ZOOM.

To put the entry point name of the ZOOM being linked into the HVCALLS MASM
source code, add a DELETE DEFINITIONS (ZOOM-ENTRY-POINT-NAME) BEFORE
RESOLUTION statement to the static link. For more information, see 6.1.4. The
following is an example of the static link format:

@USE LINK$PF...
@LINK...
OUTPUT HVTIP
INCLUDE HVCALLS ELEMENT
DELETE DEFINITIONS (ZOOM-ENTRY-POINT-NAME) BEFORE RESOLUTION
INCLUDE COMPILER-OM
RESOLVE....
DELETE ALL DEFINITIONS EXCEPT...
@EOF

Optionally, you can use the HVTIP transfer-with-cancel interface to free all common
blocks in the transaction sequence except those introduced by the initial control
program. In other words, all common blocks introduced by previously called
subprograms are released in addition to the normal transfer-with-cancel function. This
is accomplished by adding a parameter to the CALL statement for the transfer-with-
cancel interface. During execution, when a transfer-with-cancel function is
encountered with a nonzero parameter count, all subprogram data including common
blocks will be freed before control is transferred.

To set up this type of transfer-with-cancel interface:

• Set up a dummy parameter
01 CANCEL-SUB-CB PIC X.

• Place this dummy parameter on the transfer-with-cancel CALL statement

CALL 'XXX' USING CANCEL-SUB-CB.

A transfer-with-cancel CALL statement without a USING clause will be treated as a

normal Transfer with Cancel.

6.1.2.8. Using the COBOL INITIAL Clause

The COBOL INITIAL clause is part of the PROGRAM-ID statement. The following is an
example of the COBOL INITIAL clause:
PROGRAM-ID. xxxSUBX INITIAL.

The COBOL INITIAL clause has two functions in the HVTIP environment:
1. It automatically initializes all data defined with the VALUE clause, every time the
ICP or subprogram containing the INITIAL clause is called.

6–28 7831 4077–009

 Application Programming in an HVTIP Environment

2. It causes all storage defined in the WORKING-STORAGE SECTION to be allocated

as automatic storage. This means the following:
• WORKING-STORAGE is located on the activity-local stack (ALS) instead of in
the HVTIP heap data bank. Therefore, when an EXIT PROGRAM statement
occurs, this storage in the called program is released.
• The HVTIP heap data bank is smaller in size, which is desirable.
• When the program is exited, all local files are closed (if they are open).

6.1.2.9. Using the COBOL CANCEL Statement

The COBOL CANCEL statement ensures that the canceled subprogram will be in its
initial state the next time it is called. The HVTIP UCS implementation of the CANCEL
statement causes the release of the local static storage belonging to the canceled
subprogram. This storage release could be beneficial to an HVTIP transaction that is
memory-tight.

For example, if subprogram SUBD called subprogram SUBE (using HV$CALL), a

CANCEL ‘SUBE’. statement could be executed when control returns to subprogram
SUBD. This CANCEL statement would cause the release of all static storage that
belonged to subprogram SUBE only. This could decrease the size requirements of the
HVTIP heap data bank.

The INITIAL clause (refer to the previous subsection) could be used on the PROGRAM-
ID statement of the subprogram to be canceled. This would make most of the
subprogram’s local storage automatic storage, and thus place it on the activity-local
stack. In this case, the effect of using the CANCEL statement is not as great.
However, the subprogram would still have some local static storage that could be
released by a CANCEL statement.

7831 4077–009 6–29

Application Programming in an HVTIP Environment

By using the INITIAL clause, there is still some local static storage that can be released
by using the CANCEL statement. The amount left to be released can be determined
by looking at the SIZES line displayed just prior to the END UCOB signoff line at the
end of a compilation listing. The number associated with DATA on the SIZES line is the
amount of local storage that will be affected by using the CANCEL statement.

One disadvantage of the CANCEL statement is that it decreases execution-time

performance, so use it only when necessary. Instead, use the INITIAL clause in HVTIP
programs. The INITIAL clause is more efficient; it does, however, generate more code
in the prologue to initialize any data items in working storage that have VALUE clauses
associated with them. Note also that even when the INITIAL clause is used, the
compilation will still have a significant amount of local static D-bank that will not be
released unless a CANCEL is done.

If you use a CANCEL statement, you should use one of the following methods:
• Use a special format of the HV$CALL statement (HV$CALL,1) for the subprogram
being canceled. By using the HV$CALL,1 format in the HVCALLS MASM source
code, two entry point definitions will be generated for the subprogram instead of
one. The first is the standard entry point that is always generated. The second is
the CANCEL entry point having a CN$$ prefix. The example shows HVCALLS
MASM source code using this method of generating the CANCEL entry point:
$OBJ
$ASCII
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
HV$CALL,1 22,9,0 'SUBE'
$END

• Use a static linking CHANGE REFERENCE command for each entry point name that
is canceled. See “COBOL ICPs Performing CANCEL Statements,” and “COBOL
Subprograms Performing CANCEL Statements,” that follow for more information.

6–30 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.3. Compiling HVTIP ICPs and Subprograms

Compiling an HVTIP initial control program or subprogram is no different from
compiling any other UCS program. Predefined form DPS procedures generated for
COBOL have only one 01 level, thus assuring the allocation of contiguous storage
without the use of a special keyword option.

The following remarks apply to compilation of both ICPs and subprograms:

• The DPS 2200 system procs are placed in the system proc file, SYS$LIB$*PROC$.
Therefore, no special @USE ...$PF statement is required when compiling UCS
COBOL or UCS FORTRAN programs using DPS 2200 functions. The compiler
always searches the system procedure file.
• The UCS C procedures are added to the system procedure file, SYS$LIB*PROC$,
when a mode C installation is used for SYS$LIB$DPS.
• MCB procs for UCS COBOL and UCS FORTRAN are found in the Unisys-supplied
system procedure file SYS$LIB$*PROC$.

The following remark applies to HVTIP subprograms only, not ICPs:

The UCS COBOL compiler must know if a COBOL program is a subprogram or a main
program. If a UCS COBOL PROCEDURE DIVISION statement includes a "USING ...."
clause (the subprogram has input parameters), then the UCS COBOL compiler knows
that it is a subprogram and compiles it as such. If the PROCEDURE DIVISION
statement does not include a "USING ...." clause (the subprogram has no parameters),
you must use the keyword option SUBPROGRAM on the @UCOB compiler call to
identify the source as a subprogram. If you do not use the SUBPROGRAM keyword
option when compiling an HVTIP subprogram that has no parameters, another copy of
the very large URTS$TABLES URTS module will be linked in with the subprogram and
your subprogram ZOOM will consume much more D-bank storage than it really needs.
In addition, this extra space is all “dead” wasted space. This is due to the UCOB
compiler not knowing if the subprogram is actually a main program or not, and so it
has to generate it as a main program which has references to the large URTS$TABLES
URTS object module.

The following figure illustrates compilation of a UCS COBOL, C, or FORTRAN ICP using
DPS 2200 functions. (Notice that the output of the ICP compilation is an object module
element called xxxICP/COMP.)

7831 4077–009 6–31

Application Programming in an HVTIP Environment

The following figure illustrates compilation of a UCS COBOL, C, or FORTRAN ICP using
MCB functions. (Notice that the output of the ICP compilation is an object module
element called xxxICP/COMP.)

6–32 7831 4077–009

 Application Programming in an HVTIP Environment

The following figure illustrates compilation of a UCS COBOL, C, or FORTRAN HVTIP

subprogram using DPS 2200 functions. (Notice that the output of the subprogram
compilation is an object module element called xxxSUBX/COMP or xxxSUBY/COMP.)

The following figure illustrates compilation of a UCS COBOL, C, or FORTRAN HVTIP

subprogram using MCB functions. (Notice that the output of the subprogram
compilation is an object module element called xxxSUBX/COMP or xxxSUBY/COMP.)

6.1.4. Basic Static Linking of HVTIP Transactions

The following subsections present basic information on how to statically link HVTIP
initial control programs (ICP) and subprograms. The basic static linking described here
permits function testing of the transaction sequence. Once the functional

7831 4077–009 6–33

Application Programming in an HVTIP Environment

requirements are satisfied, you should relink the ICP and its subprograms for
performance.

All HVTIP transactions must be statically linked HVTIP ZOOMs. You statically link the
ICP and each subprogram separately, creating separate HVTIP ZOOMs. The following
subsections show how.

6.1.4.1. Basic Static Linking for an ICP

The following subsections describe
• A generic static linking runstream for ICPs
• The specific static linking runstreams for the example initial control programs
DPSCIP and MCBICP
Generic Static Linking Runstream for an ICP
Example 6–3 shows a generic static linking runstream for an ICP.

(1) @USE LINK$PF.,SYS$LIB$*APP$n

(2) @LINK ,QUAL*FILE.ICP
(3) OUTPUT HVTIP (or OUTPUT HVTIP2...)
(4) INCLUDE QUAL*FILE.ICP/COMP
(5) INCLUDE QUAL*FILE.HVCALLS
(6) INCLUDE QUAL*DPSFILE.UCS/INTERFACE,.EMCBEP$$DPS
(7) RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
(8) DELETE ALL DEFINITIONS EXCEPT START$
(9) SET ZEROFILL = NONE FOR ALL BANKS
(10) @EOF

Example 6–3. Generic Static Linking Runstream for an HVTIP ICP

Explanation
1. This statement ensures that the ICP is statically linked using the system software
located in the desired application group. (It ensures that the library search chain
for the correct application group is used.)
Replace n in “SYS$LIB$*APP$n” with the desired application group number. As an
example, use the following statement for application group number 7
:@USE LINK$PF.,SYS$LIB$*APP$7

This statement thus identifies the desired MCB interface software and the UDS
interface software; therefore, you do not need to use static linking INCLUDE
commands specifying the specific MCB and UDS product files. The desired files
are indicated by the library search chain. If the program uses embedded or
module SQL, this file must be for the same application group that the program
was compiled for.
For a complete discussion of how these library search chains are created and
used, see Section 4.
2. This statement calls the Linking System LINK Processor. The output HVTIP ZOOM
to be created is named QUAL*FILE.ICP.

6–34 7831 4077–009

 Application Programming in an HVTIP Environment

3. This command specifies that the object module produced by static linking is an
HVTIP ZOOM. Bank merging occurs by default when you specify OUTPUT HVTIP
or OUTPUT HVTIP2.
It is recommended that the OUTPUT command be the first command in an HVTIP
static link. The OUTPUT command should be followed by the INCLUDE commands
and then the RESOLVE command, as in this example.
Note that this command must precede any SET command (for example, SET
LOWADR) for the bank HVTIP$$DBANK. (Such statements are used in
performance linking.)
4. This command supplies the compiler-generated object module for the ICP as input
to static linking.
5. This command supplies the HVCALLS MASM object module that defines the calls
for subprograms that may be called by this ICP. If this ICP never calls a
subprogram located in another HVTIP bank, you can omit this command.
6. This command supplies the appropriate interface object modules for ICPs that use
DPS 2200. (The SYS$LIB$*APP$n application group library search chains supplied
by Unisys do not supply DPS 2200 interface information.)
A site may update the application group library search chains supplied by Unisys
so that they include the DPS 2200 interface information for that application group.
Then this INCLUDE command is not necessary (see 4.5).
7. This command resolves external references, including those to the UCS Runtime
System library.
SYS$LIB$*EMOMRTS is required only if both of the following are true:
• PADS is installed on the system.
• A library search chain that includes a search of the PADS library is being used.
PADS cannot be included in an extended mode HVTIP static link because PADS
currently has basic mode banks; the bank merging that takes place during static
linking is unable to merge basic mode and extended mode banks.
SYS$LIB$*EMOMRTS specifically prevents PADS from being included in the static
link. The object module C$NPADS is used to resolve the PADS references instead.

If PADS is not installed or a library search chain is being used that does not specify
a search of the PADS library, use the following RESOLVE command instead:
RESOLVE ALL REFERENCES USING LIBCODENAME

8. This command deletes all entry point definitions except the starting address of the
ICP.
9. This command results in more efficient program loads since data areas with no
initial values do not have to be cleared to zero. This command only affects the
loads of OUTPUT HVTIP2 ZOOMs. Setting the ZEROFILL status for banks has no
effect on OUTPUT HVTIP ZOOMs, since uninitialized data areas are always cleared
on OUTPUT HVTIP ZOOMs. If you want uninitialized data areas to be cleared to
zeros when they are loaded, use the following statement:
(9) SET ZEROFILL = LOAD FOR ALL COMMON BLOCK BANKS

7831 4077–009 6–35

Application Programming in an HVTIP Environment

10. This statement ends static linking.

COBOL ICPs Performing CANCEL Statements

If you have a UCS COBOL ICP that performs a CANCEL statement, you should either
• Use a special format of the HV$CALL statement for the subprogram being
canceled. See “Using the COBOL CANCEL Statement” earlier in this section for
more information.
• Use a static linking CHANGE REFERENCE command for each entry point name
being canceled. The following is an example.
CHANGE REFERENCE (‘CN$$subprogram-name’) TO subprogram-name

where subprogram-name is the entry point name of the subprogram being

canceled.

This CHANGE REFERENCE command should follow the INCLUDE command that
supplies the object module that contains the CANCEL statement.

For example, assume

• The following statement appears in the ICP:
CANCEL ‘SUBD’.

• The ICP resides in object module QUAL*FILE.ICP/COMP

6–36 7831 4077–009

 Application Programming in an HVTIP Environment

In this case, you must include the following commands in the static link of the ICP:

INCLUDE QUAL*FILE.ICP/COMP
CHANGE REFERENCE ('CN$$SUBD') TO SUBD

Specific ICP Static Linking Examples

The following static linking runstream is used to link DPSICP:
@LINK ,QUAL*UCSTST.DPSICP
OUTPUT HVTIP . (or OUTPUT HVTIP2 ...)
INCLUDE QUAL*UCSTST.DPSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DPSSUBX
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT START$
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

The following static linking runstream is used to link MCBICP:

@USE LINK$PF,SYS$LIB$*APP$3

@LINK ,QUAL*UCSTST.MCBICP
OUTPUT HVTIP . (or OUTPUT HVTIP2 ...)
INCLUDE QUAL*UCSTST.MCBICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBX
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT START$
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

7831 4077–009 6–37

Application Programming in an HVTIP Environment

6.1.4.2. Basic Static Linking for HVTIP Subprograms

The following subsections describe
• A generic static linking runstream for an HVTIP subprogram
• The specific static linking runstreams for the example subprograms DPSSUBX and
MCBSUBX
Generic Static Linking Runstream for Subprograms
Example 6–4 shows a generic static linking runstream for an HVTIP subprogram:
(1) @USE LINK$PF,SYS$LIB$*APP$n
(2) @LINK ,QUAL*FILE.SUB
(3) OUTPUT HVTIP . (or OUTPUT HVTIP2 ...)
(4) INCLUDE QUAL*FILE.SUB/COMP
(5) INCLUDE QUAL*FILE.HVCALLS
(6) INCLUDE QUAL*DPSFILE.UCS/INTERFACE,.EMCBEP$$DPS
(7) RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
(8) DELETE ALL DEFINITIONS EXCEPT SUB
(9) SET ZEROFILL = NONE FOR ALL BANKS
(10) @EOF

Example 6–4. Generic Static Linking Runstream for an HVTIP Subprogram

Explanation
1. This statement ensures that the subprogram is statically linked using the system
software located in the desired application group. (It ensures that the library
search chain for the correct application group is used.)
Replace n in “SYS$LIB$*APP$n” with the desired application group number. As an
example, use the following statement for application group number 7:
@USE LINK$PF,SYS$LIB$*APP$7

This statement thus identifies the desired MCB interface software and the UDS
interface software; therefore, you do not need to use static linking INCLUDE
commands specifying the specific MCB and UDS product files. The desired files
are indicated by the library search chain. If the program uses embedded or
module SQL, this file must be for the same application group that the program
was compiled for.
For a complete discussion of how these library search chains are created and
used, see Section 4.
2. This statement calls the Linking System LINK Processor. The output HVTIP ZOOM
to be created is named QUAL*FILE.SUB.
3. This command specifies that the object module produced by static linking is an
HVTIP ZOOM. Bank merging occurs by default when you specify OUTPUT HVTIP.
It is recommended that the OUTPUT command be the first command in an HVTIP
static link. The OUTPUT command should be followed by the INCLUDE commands
and then the RESOLVE command, as in this example.

6–38 7831 4077–009

 Application Programming in an HVTIP Environment

Note that this command must precede any SET command (for example, SET
LOWADR) for the bank HVTIP$$DBANK. (Such statements are used in
performance linking.)
4. This command supplies the compiler-generated object module for the
subprogram as input to static linking.
5. This command supplies the HVCALLS MASM object module that defines the calls
for subprograms that may be called by this subprogram. If this subprogram never
calls a subprogram located in another HVTIP bank, you can omit this command.
6. This command supplies the appropriate interface object modules for subprograms
that use DPS 2200. (The SYS$LIB$*APP$n application group library search chains
supplied by Unisys do not supply DPS 2200 interface information.)
A site may update the library search chains supplied by Unisys for application
groups so that they include the DPS 2200 interface information for that application
group. Then this INCLUDE command is not necessary (see 4.5).
7. This command resolves external references, including those to the UCS Runtime
System library.
SYS$LIB$*EMOMRTS is required only if both of the following are true:
• PADS is installed on the system.
• A library search chain that includes a search of the PADS library is being used.
PADS cannot be included in an extended mode HVTIP static link because PADS
currently has some basic mode banks; the bank merging that takes place during
static linking is unable to merge basic mode and extended mode banks.
SYS$LIB$*EMOMRTS specifically prevents PADS from being included in the static
link. The object module C$NPADS is used to resolve the PADS references instead.
If PADS is not installed or a library search chain is being used that does not specify
a search of the PADS library, use the following RESOLVE command instead:
RESOLVE ALL REFERENCES USING LIBCODENAME

8. This command deletes all entry point definitions except the one used to call this
subprogram. Replace sub with the actual entry point name.
The Linking System requires that this external reference to the subprogram be
kept. Scheduling of the subprogram uses the HVTIP library number, bank number,
and offset; not this external reference.
9. This command results in more efficient program loads since data areas with no
initial values do not have to be cleared to zero. This command only affects the
loads of OUTPUT HVTIP2 ZOOMs. Setting the ZEROFILL status for banks has no
effect on OUTPUT HVTIP ZOOMs, since unitialized data areas are always cleared
on OUTPUT HVTIP ZOOMs. If you want uninitialized areas to be cleared to zeros
when they are loaded, use the following statement:
(9) SET ZEROFILL = LOAD FOR ALL COMMON_BLOCK BANKS

10. This statement ends static linking.

7831 4077–009 6–39

Application Programming in an HVTIP Environment

COBOL Subprograms Performing CANCEL Statements

If you have a UCS COBOL subprogram that performs a CANCEL statement, you should
either
1. Use a special format of the HV$CALL statement for the subprogram being
cancelled. See "Using the COBOL CANCEL Statement" earlier in this section for
more information.
2. Use a static linking CHANGE REFERENCE command for each entry point name that
is cancelled. The following is an example.
CHANGE REFERENCE (‘CN$$subprogram-name’) TO subprogram-name

where subprogram-name is the entry point name of the subprogram being

cancelled.
This CHANGE REFERENCE command should follow the INCLUDE command that
supplies the object module that contains the CANCEL statement.
For example, assume
• The following statement appears in the subprogram SUBD:
CANCEL ‘SUBE’.

• The subprogram SUBD resides in object module QUAL*FILE.SUB/COMP

In this case, you must include the following commands in the static link of the
subprogram SUBD:

INCLUDE QUAL*FILE.SUB/COMP
CHANGE REFERENCE ('CN$$SUBE') TO SUBE

6–40 7831 4077–009

 Application Programming in an HVTIP Environment

Specific Subprogram Static-Linking Examples

The following static-linking runstream is used to link DPSSUBX:
@LINK ,QUAL*UCSTST.DPSSUBX
OUTPUT HVTIP . (or OUTPUT HVTIP2 ...)
INCLUDE QUAL*UCSTST.DPSSUBX/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DPSSUBY
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS,LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT DPSSUBX
@EOF

The following static-linking runstream is used to link MCBSUBX:

@USE LINK$PF,SYS$LIB$*APP$3

@LINK ,QUAL*UCSTST.MCBSUBX
OUTPUT HVTIP . (or OUTPUT HVTIP2 ...)
INCLUDE QUAL*UCSTST.MCBSUBX/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBY
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS,LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT MCBSUBX
@EOF

6.1.5. Examples of HVTIP Transactions

Two examples are shown in this subsection:
• The first example uses COBOL and DPS 2200 functions.
• The second example uses COBOL and MCB functions.

Each example is composed of the following general components:

1. Source listing of the ICP
2. Partial source listing of the MCBPKT-UCOB routine from the MCB release tape
(MCB example only)
3. Source listing of the ICP HVCALLS element
4. Source listing of the first subprogram
5. Source listing of the HVCALLS element for the first subprogram
6. Source listing of the second subprogram
7. A source listing of a runstream to set up, compile, and link the example
transaction (for example, with an @START or @ADD statement)
8. The execution of the source runstream (output saved by an @BRKPT statement)
9. An example of execution of the transactions

7831 4077–009 6–41

Application Programming in an HVTIP Environment

6.1.5.1. Example Using DPS 2200 Functions

The following figure illustrates the example in this subsection. This example uses
• The HVTIP call and transfer-with-cancel interfaces
• COBOL and DPS 2200 functions

HVTIP Library 22

Transfer
with
Cancel

Bank 1 Bank 2 Bank 3

DPSHVT
Call
DPSICP DPSSUBX DPSSUBY
Return

Terminal
Point of
No Return

Source Listing of the ICP (DPSICP)

Example 6–5 shows the complete source listing of the ICP, DPSICP. In this example,
this program resides in element QUAL*UCSTST.DPSICP. Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF AN INITIAL CONTROL PROGRAM "DPSICP" THAT PERFORMS A *
* TRANSFER WITH CANCEL TO A SUBPROGRAM "DPSSUBX". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. DPSICP INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
PROCEDURE DIVISION.
******************************************************

6–42 7831 4077–009

 Application Programming in an HVTIP Environment

*** TRANSACTION INITIALIZATION ***

******************************************************
START-UP-ICP.
DISPLAY 'THIS IS DPSICP' UPON PRINTER.
CALL 'D$INIT' USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL GO TO ERROR-EXIT.
DISPLAY 'INITIALIZATION COMPLETE' UPON PRINTER.
******************************************************
*** TRANSFER WITH CANCEL TO DPSSUBX ***
******************************************************
TRANSFERCANCEL-SUBX.
DISPLAY 'DPSICP TRANSFERRING WITH CANCEL TO DPSSUBX'
UPON PRINTER.
CALL 'DPSSUBX'.
******************************************************
*** ERROR RETURN ***
******************************************************
ERROR-RETURN.
DISPLAY 'RETURNED TO DPSICP - ERROR' UPON PRINTER.
DISPLAY 'TERMINATING FROM DPSICP -ERROR' UPON PRINTER.
CALL 'D$TERM' USING DPS-STATUS.
IF STATUS-FATAL GO TO ERROR-EXIT.
STOP RUN.

Example 6–5. Source Listing of the ICP (QUAL*UCSTST.DPSICP)

Source Listing of the ICP HVCALLS Element

Example 6–6 shows the source listing of the HVCALLS element for the ICP. In this
example, this routine resides in element QUAL*UCSTST.HVCALLSDEF/DPSSUBX.
Noteworthy lines are bolded.

. HVCALLS DEFINITION
. DPSSUBX is defined as a TRANSFER WITH CANCEL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$XFR$CANCL 22,2,0 'DPSSUBX'
$END

Example 6–6. Source Listing of the ICP HVCALLS Element

(QUAL*UCSTST.HVCALLSDEF/DPSSUBX)

7831 4077–009 6–43

Application Programming in an HVTIP Environment

Source Listing of the First Subprogram (DPSSUBX)

Example 6–7 shows the complete source listing of the first subprogram, DPSSUBX. In
this example, this subprogram resides in element QUAL*UCSTST.DPSSUBX.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "DPSSUBX" THAT WAS CALLED FROM THE ICP *
* "DPSICP" USING TRANSFER WITH CANCEL AND IN TURN CALLS A *
* SUBPROGRAM "DPSSUBY". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. DPSSUBX INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.

Example 6–7. Source Listing of the First Subprogram (QUAL*UCSTST.DPSSUBX)

6–44 7831 4077–009

 Application Programming in an HVTIP Environment

COPY DPSSTATUSCOB.
PROCEDURE DIVISION.
******************************************************
*** DPSSUBX START UP ***
******************************************************
START-UP-SUBX.
DISPLAY ' THIS IS DPSSUBX' UPON PRINTER.
******************************************************
*** CALL TO DPSSUBY ***
******************************************************
CALL-SUBY.
DISPLAY ' DPSSUBX CALLING DPSSUBY' UPON PRINTER.
CALL 'DPSSUBY'.
******************************************************
*** RETURN TO DPSSUBX ***
******************************************************
RETURN-FROM-DPSSUBY.
DISPLAY ' RETURNED TO DPSSUBX ' UPON PRINTER.
******************************************************
*** TRANSACTION TERMINATION ***
******************************************************
END-TRANSACTION.
DISPLAY ' TERMINATING FROM DPSSUBX' UPON PRINTER.
CALL 'D$TERM' USING DPS-STATUS.
IF STATUS-FATAL GO TO ERROR-EXIT.
STOP RUN.
******************************************************
* THIS IS THE FATAL ERROR PARAGRAPH. ALL *
* FATAL DPS ERRORS IN THIS PROGRAM WILL *
* CAUSE AN UNCONDITIONAL JUMP HERE: *
******************************************************
ERROR-EXIT.
DISPLAY ' DPSSUBX ERROR EXIT' UPON PRINTER.
CALL 'D$DUMP'.
CALL 'D$ERRMSG' USING DPS-STATUS.
CALL 'D$TERM' USING DPS-STATUS.
STOP RUN.

Example 6-7. Source Listing of the First Subprogram (QUAL*UCSTST.DPSSUBX)

7831 4077–009 6–45

Application Programming in an HVTIP Environment

Source Listing of the Subprogram HVCALLS Element

Example 6–8 shows the source listing of the HVCALLS element for the first
subprogram, DPSSUBX. In this example, this routine resides in element
QUAL*UCSTST.HVCALLSDEF/DPSSUBY. Noteworthy lines are bolded.

. HVCALLS DEFINITION
. DPSSUBY is defined as a CALL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$CALL 22,3,0 'DPSSUBY '
$END

Example 6–8. Source Listing of the HVCALLS Element for First Subprogram
(QUAL*UCSTST.HVCALLSDEF/DPSSUBY)

6–46 7831 4077–009

 Application Programming in an HVTIP Environment

Source Listing of the Second Subprogram (DPSSUBY)

Example 6–9 shows the complete source listing of the second subprogram, DPSSUBY.
In this example, this subprogram resides in element QUAL*UCSTST.DPSSUBY.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "DPSSUBY" THAT WAS CALLED FROM THE *
* SUBPROGRAM "DPSSUBX" WITH A CALL AND IN TURN IT RETURNS TO *
* SUBPROGRAM "DPSSUBX". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. DPSSUBY INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** DPSSUBY START UP ***
******************************************************
START-UP-SUBY.
DISPLAY ' THIS IS DPSSUBY' UPON PRINTER.
******************************************************
*** RETURN TO DPSSUBX ***
******************************************************
RETURN-SUBX.
DISPLAY ' DPSSUBY RETURNING TO DPSSUBX'
UPON PRINTER.
EXIT PROGRAM.

Example 6–9. Source Listing of the Second Subprogram

(QUAL*UCSTST.DPSSUBY)

7831 4077–009 6–47

Application Programming in an HVTIP Environment

Source Listing of Runstream

Example 6–10 shows the source listing of a runstream used to set up, compile, and
link the HVTIP transactions shown in this example. Noteworthy lines are bolded.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
@ASG,A MASM$PF1.
@ . ***
@ . ***
@ . *** * ICP DPSICP ******
@ . *** COMPILE THE ICP "DPSICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL ELEMENT "HVCALLSDEF/DPSSUBX
@ . ***
@USE COB$PF,APP3*DPS.
@UCOB QUAL*UCSTST.DPSICP,.DPSICP/COMP,,,NO-OPTIONS
@MASM,N QUAL*UCSTST.HVCALLSDEF/DPSSUBX,.HVCALLSDEF/DPSSUBX
@EOF
@ . ***
@ . ***
@ . *** * SUBPROGRAM DPSSUBX ******
@ . *** COMPILE THE FIRST SUBPROGRAM "DPSSUBX" AND ASSEMBLE ITS
@ . *** HVCALLS CALL ELEMENT "HVCALLSDEF/DPSSUBY"
@ . ***
@UCOB QUAL*UCSTST.DPSSUBX,.DPSSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
@MASM,N QUAL*UCSTST.HVCALLSDEF/DPSSUBY,.HVCALLSDEF/DPSSUBY
@EOF
@ . ***
@ . ***
@ . *** * SUBPROGRAM DPSSUBY ******
@ . *** COMPILE THE SECOND SUBPROGRAM "DPSSUBY"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO DPS COMMANDS.
@ . ***
@UCOB QUAL*UCSTST.DPSSUBY,.DPSSUBY/COMP,,, NO-OPTIONS,SUBPROGRAM

Example 6–10. Runstream to Set Up, Compile, and Link—COBOL DPS HVTIP
Transaction Sequence

6–48 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE DPS IS BEING USED IN THIS EXAMPLE THE FOLLOWING
@ . *** STATEMENT MUST BE ADDED TO THE STATIC LINK OF EACH
@ . *** TRANSACTION THAT USES DPS. THE FILENAME IS DEPENDENT ON
@ . *** THE INSTALLATION OF DPS. THE FILENAME 'APP3*DPS' IS USED
@ . *** IN THIS EXAMPLE.
@ . ***
@ . *** INCLUDE APP3*DPS.UCS/INTERFACE, APP3*DPS.EMCBEP$$DPS
@ . ***
@ . ***
@ . *** *** DPSICP LINK ********
@ . *** LINK THE ICP "DPSICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/DPSSUBX"
@ . ***
@LINK ,QUAL*UCSTST.DPSICP
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.DPSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DPSSUBX
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT START$
SET ZEROFILL = NONE FOR ALL BANKS
@EOF
@ . ***
@ . ***
@ . *** *** DPSSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "DPSSUBX" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/DPSSUBY"
@ . ***
@LINK ,QUAL*UCSTST.DPSSUBX
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.DPSSUBX/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DPSSUBY
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT DPSSUBX
SET ZEROFILL = NONE FOR ALL BANKS
@EOF
@ . ***
@ . ***
@ . *** *** DPSSUBY LINK ********
@ . *** LINK THE SUBPROGRAM "DPSSUBY"
@ . ***

Example 6–10. Runstream to Set Up, Compile, and Link—COBOL DPS HVTIP
Transaction Sequence

7831 4077–009 6–49

Application Programming in an HVTIP Environment

@ . THE DPS "UCS/INTERFACE" AND "EMCBEP$$DPS" ELEMENTS ARE NOT

@ . INCLUDED IN THIS LINK BECAUSE THIS SUBPROGRAM CONTAINS NO DPS.
@ . ***
@LINK ,QUAL*UCSTST.DPSSUBY
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.DPSSUBY/COMP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT DPSSUBY
SET ZEROFILL = NONE FOR ALL BANKS
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,5 STF,0 STA,J QPR,0 OPT,TV
@ . *** nnn REC,Z AUD,n PRT,xxxxxx
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
900 NAM,DPSICP ACT,DPSHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV
900 REC,Z AUD,3 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000

Example 6–10. Runstream to Set Up, Compile, and Link—COBOL DPS

HVTIP Transaction Sequence

6–50 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB nn - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP nn - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-file-number - TPLIB = HVTIP-LIBRARY-number
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-file-number = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-number)
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*HVTIPLIB22.,FIX
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
LFD 92
@EOF
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER

Example 6–10. Runstream to Set Up, Compile, and Link—COBOL DPS

HVTIP Transaction Sequence

7831 4077–009 6–51

Application Programming in an HVTIP Environment

ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
CREATE,K 22,30
COPY,IVK 22,1,QUAL*UCSTST.DPSICP
COPY,IK 22,2,QUAL*UCSTST.DPSSUBX
COPY,IK 22,3,QUAL*UCSTST.DPSSUBY
LIST 22
LOAD,K 22
STATUS,K 22
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . EXAMPLE SETUP IS COMPLETE

Example 6–10. Runstream to Set Up, Compile, and Link—COBOL DPS

HVTIP Transaction Sequence

6–52 7831 4077–009

 Application Programming in an HVTIP Environment

Execution of the Source Runstream

Example 6–11 shows the execution of the source runstream used to set up, compile,
and link this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
I:002333 USE complete.
@ASG,A MASM$PF1.
I:002333 ASG complete.
@ . ***
@ . ***
@ . *** * ICP DPSICP ******
@ . *** COMPILE THE ICP "DPSICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL ELEMENT "HVCALLSDEF/DPSSUBX
@ . ***
@USE COB$PF,APP3*DPS
I:002333 USE complete.
@UCOB QUAL*UCSTST.DPSICP,.DPSICP/COMP,,,NO-OPTIONS
UCOB- 8R1 (970210) LSS-10R1 (970209) 970223 12:30:04
SIZES: CODE(EM6): 229 DATA: 232 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.HVCALLSDEF/DPSSUBX,.HVCALLSDEF/DPSSUBX
MASM 6R2A (960423 0008:22) 1997 Feb 23 Sun 1230:08
END MASM - LINES: 134 TIME: 5.438 STORAGE: 29345/7895
@ . ***
@ . ***
@ . *** * SUBPROGRAM DPSSUBX ******
@ . *** COMPILE THE FIRST SUBPROGRAM "DPSSUBX" AND ASSEMBLE ITS
@ . *** HVCALLS CALL ELEMENT "HVCALLSDEF/DPSSUBY"
@ . ***
@UCOB QUAL*UCSTST.DPSSUBX,.DPSSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
UCOB- 8R1 (970210) LSS-10R1 (970209) 970223 12:30:10
SIZES: CODE(EM6): 140 DATA: 203 COMMON: 3

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP Transaction

Sequence

7831 4077–009 6–53

Application Programming in an HVTIP Environment

END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)

@MASM,N QUAL*UCSTST.HVCALLSDEF/DPSSUBY,.HVCALLSDEF/DPSSUBY
MASM 6R2A (960423 0008:22) 1997 Feb 23 Sun 1230:12
END MASM - LINES: 134 TIME: 4.333 STORAGE: 29345/7895
@ . ***
@ . ***
@ . *** * SUBPROGRAM DPSSUBY ******
@ . *** COMPILE THE SECOND SUBPROGRAM "DPSSUBY"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO DPS COMMANDS.
@ . ***
@UCOB QUAL*UCSTST.DPSSUBY,.DPSSUBY/COMP,,, NO-OPTIONS,SUBPROGRAM
UCOB- 8R1 (970210) LSS-10R1 (970209) 970223 12:30:14
SIZES: CODE(EM6): 58 DATA: 118 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE DPS IS BEING USED IN THIS EXAMPLE THE FOLLOWING
@ . *** STATEMENT MUST BE ADDED TO THE STATIC LINK OF EACH
@ . *** TRANSACTION THAT USES DPS. THE FILENAME IS DEPENDENT ON
@ . *** THE INSTALLATION OF DPS. THE FILENAME 'APP3*DPS' IS USED
@ . *** IN THIS EXAMPLE.
@ . ***
@ . *** INCLUDE APP3*DPS.UCS/INTERFACE, APP3*DPS.EMCBEP$$DPS
@ . ***
@ . ***
@ . *** *** DPSICP LINK ********
@ . *** LINK THE ICP "DPSICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/DPSSUBX"
@ . ***
@LINK ,QUAL*UCSTST.DPSICP
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1230:16
END LINK , LINES : 6 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** DPSSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "DPSSUBX" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/DPSSUBY"
@ . ***
@LINK ,QUAL*UCSTST.DPSSUBX
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1230:23
END LINK , LINES : 6 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

6–54 7831 4077–009

 Application Programming in an HVTIP Environment

@ . *** *** DPSSUBY LINK ********

@ . *** LINK THE SUBPROGRAM "DPSSUBY"
@ . ***
@ . THE DPS "UCS/INTERFACE" AND "EMCBEP$$DPS" ELEMENTS ARE NOT
@ . INCLUDED IN THIS LINK BECAUSE THIS SUBPROGRAM CONTAINS NO DPS.
@ . ***
@LINK ,QUAL*UCSTST.DPSSUBY
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1230:27
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** NNN NAM,XXXXXX ACT,XXXXXX PRG,5 STF,0 STA,J QPR,N OPT,TV
@ . *** NNN REC,Z AUD,N PRT,XXXXX
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 45R2#0000001 970223 1230:31
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

7831 4077–009 6–55

Application Programming in an HVTIP Environment

TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

900 NAM,DPSICP ACT,DPSHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV

900 REC,Z AUD,3 PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 900 TRANSACTION CODE: DPSHVT DBK: 0
NAM: DPSICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1230:32
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 45R2#0000001 970223 1230:32
@ . ***

@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1230:32
ON BTLOADING
ON STICKING
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB NN - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP NN - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

6–56 7831 4077–009

 Application Programming in an HVTIP Environment

@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER - TPLIB = HVTIP-LIBRARY-NUMBER

@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-NUMBER)
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 45R2 02/23/97 12:30:32 FS-LEVEL FS 003
TREG QUAL*HVTIPLIB22.,FIX
TP REGISTER STARTED 12:30:32 23 FEB 97
TP REGISTER FINISHED 12:30:35 23 FEB 97
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:30:35 23 FEB 97
TP RESERVE FINISHED 12:30:35 23 FEB 97
LFD 92

TIP FILE 92
DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME HVTIPLIB22
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

7831 4077–009 6–57

Application Programming in an HVTIP Environment

@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1230:35
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
I:002333 ASG complete.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
TPUR 45R2#0000001 970223 1230:36
CREATE,K 22,30
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
NEXT AVAILABLE RECORD: 7 LIBRARY CYCLE: MAIN

COPY,IVK 22,1,QUAL*UCSTST.DPSICP

LLBBBB : 260001 LIB# : 22 BANK# : 1

ELEMENT SPECIFICATION : QUAL*UCSTST.DPSICP
CREATION DATE : 02/23/97 CREATION TIME : 12:30:22
BANK SIZE : 013500 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 7
LOWER LIMIT : 001000

COPY,IK 22,2,QUAL*UCSTST.DPSSUBX

LLBBBB : 260002 LIB# : 22 BANK# : 2

ELEMENT SPECIFICATION : QUAL*UCSTST.DPSSUBX
CREATION DATE : 02/23/97 CREATION TIME : 12:30:26
BANK SIZE : 07100 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 221
LOWER LIMIT : 001000

COPY,IK 22,3,QUAL*UCSTST.DPSSUBY

LLBBBB : 260003 LIB# : 22 BANK# : 3

ELEMENT SPECIFICATION : QUAL*UCSTST.DPSSUBY
CREATION DATE : 02/23/97 CREATION TIME : 12:30:31
BANK SIZE : 04100 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 353
LOWER LIMIT : 001000

LIST 22

LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

NEXT AVAILABLE RECORD: 789 LIBRARY CYCLE: MAIN

LLBBBB : 260001 LIB# : 22 BANK# : 1

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

6–58 7831 4077–009

 Application Programming in an HVTIP Environment

ELEMENT SPECIFICATION : QUAL*UCSTST.DPSICP

CREATION DATE : 02/23/97 CREATION TIME : 12:30:22
BANK SIZE : 013500 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 7
LOWER LIMIT : 001000
LLBBBB : 260002 LIB# : 22 BANK# : 2
ELEMENT SPECIFICATION : QUAL*UCSTST.DPSSUBX
CREATION DATE : 02/23/97 CREATION TIME : 12:30:26
BANK SIZE : 07100 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 221
LOWER LIMIT : 001000

LLBBBB : 260003 LIB# : 22 BANK# : 3

ELEMENT SPECIFICATION : QUAL*UCSTST.DPSSUBY
CREATION DATE : 02/23/97 CREATION TIME : 12:30:31
BANK SIZE : 04100 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 353
LOWER LIMIT : 001000
LOAD,K 22

STATUS,K 22
ONLINE LIBRARY STATUS
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

BANK RTN LOAD STATUS BANK BANK TIP MEM LOWER START RECORD
NUMB COUNT INDICATORS SIZE TYPE GROUP# LIMIT ADDR NUMBER
---- ----- ----------- ------- ------- --- ------ ------ ------
1 0 0013500 Z,DY,EM 2 001000 001001 7
2 0 0007100 Z,DY,EM 2 001000 001001 221
3 0 0004100 Z,DY,EM 1 001000 001001 353

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1230:38
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . EXAMPLE SETUP IS COMPLETE

Example 6–11. Execution of Source Runstream—COBOL DPS HVTIP

Transaction Sequence

7831 4077–009 6–59

Application Programming in an HVTIP Environment

Execution of the HVTIP Transaction in This Example

The following screen shows an execution of the HVTIP transaction described
previously. User input is bolded.

>DPSHVT

This would produce the following printer output:

THIS IS DPSICP

INITIALIZATION COMPLETE

DPSICP TRANSFERRING WITH CANCEL TO DPSSUBX

THIS IS DPSSUBX

DPSSUBX CALLING DPSSUBY

THIS IS DPSSUBY

DPSSUBY RETURNING TO DPSSUBX

RETURNED TO DPSSUBX

TERMINATING FROM DPSSUBX

6–60 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.5.2. Example Using MCB Functions

The following figure illustrates the example in this subsection. This example uses
• The HVTIP call and transfer-with-cancel interfaces
• COBOL and MCB functions

Source Listing of the ICP (MCBICP)

Example 6–12 shows the complete source listing of the ICP, MCBICP. In this example,
this program resides in element QUAL*UCSTST.MCBICP. Noteworthy lines are
bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF AN INITIAL CONTROL PROGRAM "MCBICP" THAT PERFORMS A *
* TRANSFER WITH CANCEL TO A SUBPROGRAM "MCBSUBX". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBICP INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.

Example 6–12. Source Listing of the ICP (QUAL*UCSTST.MCBICP)

7831 4077–009 6–61

Application Programming in an HVTIP Environment

COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY MCBPKT-UCOB.
PROCEDURE DIVISION.
****************************************************
*** TRANSACTION INITIALIZATION ***
****************************************************
START-UP-ICP.
DISPLAY 'THIS IS MCBICP' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 1 TO P-BIT2.
MOVE P-TRINIT TO P-FUNC.
MOVE 80 TO P-LENGTH.
MOVE 63 TO P-AUX.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
DISPLAY 'INITIALIZATION COMPLETE' UPON PRINTER.
****************************************************
*** TRANSFER WITH CANCEL TO MCBSUBX ***
****************************************************
TRANSFERCANCEL-SUBX.
DISPLAY 'MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX'
UPON PRINTER.
CALL 'MCBSUBX'.
****************************************************
*** ERROR RETURN ***
****************************************************
ERROR-RETURN.
DISPLAY 'RETURNED TO MCBICP - ERROR' UPON PRINTER.
DISPLAY 'TERMINATING FROM MCBICP - ERROR' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.
****************************************************
*** MCB ERROR HANDLING ***
****************************************************
ERROR-EXIT.
DISPLAY '********* MCB ERROR *********' UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 6–12. Source Listing of the ICP (QUAL*UCSTST.MCBICP)

6–62 7831 4077–009

 Application Programming in an HVTIP Environment

Partial Source Listing of the MCBPKT-UCOB Routine

Example 6–13 shows a partial source listing of the MCBPKT-UCOB routine. This is a
version of the procs contained in the MCBDEF-UCOB element from the MCB release
tape that has been tailored for this example. (For more information, refer to “Coding
HVTIP Transactions That Use MCB Functions” in 6.1.2.)

In this example, this routine resides in element QUAL*UCSTST.MCBPKT-UCOB.

Noteworthy lines are bolded.

MCBPKT-UCOB PROC
/
*
* Sample MCB procedure for use in UCOB transactions
*
************************************************
** TRANSACTION CODE BUFFER **
************************************************
01 P-TRXCODE PIC X(6).
************************************************
** INPUT BUFFER **
** This buffer will hold a 24 X 80 screen. **
** The maximum size is PIC X(262143). **
************************************************
01 P-INMSG PIC X(1920).
**************************************************
** BUFFER ADDRESS **
**************************************************
01 P-MSG-LENGTH PIC 9(10) BINARY.
01 P-SAVEPID PIC 1(18) BINARY-1.
01 P-TRXBUFF PIC X(1920) VALUE SPACES.
**************************************************
** MCB ERROR STATUS RETURN **
**************************************************
01 P-MCB-STATUS.
02 P-STATBIT PIC S9(5) BINARY.
02 P-ERRCODE PIC 9(5) BINARY.
02 P-ERRCODEQ REDEFINES P-ERRCODE.
04 P-ERRCODEQ3 PIC 1(9) BINARY-1.
04 P-ERRCODEQ4 PIC 1(9) BINARY-1.
*************************************************
** FUNCTION CODES FOR INTERFACES TO THE MCB **
*************************************************
* TRINIT VALUE 2. initialize
* TERM VALUE 10. terminate
* COMMIT VALUE 11. commit
* ROLBAK VALUE 12. rollback

Example 6–13. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

7831 4077–009 6–63

Application Programming in an HVTIP Environment

* RECV VALUE 13. read input

* INPREL VALUE 14. release input
* CANCELL VALUE 15. cancel output
* SENDD VALUE 16. store output
* PASOFF VALUE 17. store passoff
* CHKPT VALUE 18. store checkpoint
* ENQUE VALUE 19. enqueue message
* AUDIT VALUE 20. audit
* DISREC VALUE 21. discrete receive
*****************************************************************
01 P-TRINIT PIC 9(2) BINARY VALUE 2.
01 P-TERM PIC 9(2) BINARY VALUE 10.
01 P-COMMIT PIC 9(2) BINARY VALUE 11.
01 P-ROLBAK PIC 9(2) BINARY VALUE 12.
01 P-RECV PIC 9(2) BINARY VALUE 13.
01 P-INPREL PIC 9(2) BINARY VALUE 14.
01 P-CANCELL PIC 9(2) BINARY VALUE 15.
01 P-SENDD PIC 9(2) BINARY VALUE 16.
01 P-PASOFF PIC 9(2) BINARY VALUE 17.
01 P-CHKPT PIC 9(2) BINARY VALUE 18.
01 P-ENQUE PIC 9(2) BINARY VALUE 19.
01 P-AUDIT PIC 9(2) BINARY VALUE 20.
01 P-DISREC PIC 9(2) BINARY VALUE 21.
/
*************************************************
** PACKET FOR MCB CALL **
*************************************************
01 P-MCB-PACKET.
02 P-WORD00.
* P-FUNC function code
* P-OFF data offset
* P-ID msg identifier
03 P-FUNC PIC 9(2) BINARY.
03 P-OFF PIC 9(2) BINARY.
03 P-ID PIC 9(5) BINARY.
02 P-WORD01.
* P-LENGTH request char count
* P-BUFF data buffer address
03 P-LENGTH PIC 9(5) BINARY.
03 P-BUFF PIC 9(5) BINARY.
02 P-WORD02.
* P-START start char point
* P-RTN return point
03 P-START PIC 9(5) BINARY.
03 P-RTN PIC 9(5) BINARY.
02 P-WORD03.
* P-AUX aux data

Example 6–13. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

6–64 7831 4077–009

 Application Programming in an HVTIP Environment

* P-FAC facilities
* P-VER version
03 P-AUX PIC 1(6) BINARY-1.
03 P-FAC PIC 1(6) BINARY-1.
03 P-VER PIC 1(6) BINARY-1.
****
03 P-FLAGS.
.
. (additional statements)
.

Example 6–13. Partial Source Listing of MCBPKT-UCOB Routine

(QUAL*UCSTST.MCBPKT-UCOB)

Source Listing of the ICP HVCALLS Element

Example 6–14 shows the source listing of the HVCALLS element for the ICP. In this
example, this routine resides in element QUAL*UCSTST.HVCALLSDEF/MCBSUBX.
Noteworthy lines are bolded.

. HVCALLS DEFINITION
. MCBSUBX is defined as a TRANSFER WITH CANCEL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$XFR$CANCL 22,7,0 'MCBSUBX'
$END

Example 6–14. Source Listing of the ICP HVCALLS Element

(QUAL*UCSTST.HVCALLSDEF/MCBSUBX)

7831 4077–009 6–65

Application Programming in an HVTIP Environment

Source Listing of the First Subprogram (MCBSUBX)

Example 6–15 shows the complete source listing of the first subprogram, MCBSUBX.
In this example, this subprogram resides in element QUAL*UCSTST.MCBSUBX.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBX" THAT WAS CALLED FROM THE ICP *
* "MCBICP" USING TRANSFER WITH CANCEL AND IN TURN CALLS A *
* SUBPROGRAM "MCBSUBY". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBSUBX INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY MCBPKT-UCOB.
PROCEDURE DIVISION.
****************************************************
*** MCBSUBX START UP ***
****************************************************
START-UP-SUBX.
DISPLAY ' THIS IS MCBSUBX' UPON PRINTER.
****************************************************
*** CALL TO MCBSUBY ***
****************************************************
CALL-SUBY.
DISPLAY ' MCBSUBX CALLING MCBSUBY' UPON PRINTER.
CALL 'MCBSUBY'.
****************************************************
*** RETURN TO MCBSUBX ***
****************************************************
RETURN-FROM-MCBSUBY.
DISPLAY ' RETURNED TO MCBSUBX ' UPON PRINTER.
****************************************************
*** TRANSACTION TERMINATION ***

Example 6–15. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBX)

6–66 7831 4077–009

 Application Programming in an HVTIP Environment

****************************************************
MCB-TERMINATE.
DISPLAY ' TERMINATING FROM MCBSUBX' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
STOP RUN.
****************************************************
*** MCB ERROR HANDLING ***
****************************************************
ERROR-EXIT.
DISPLAY '********* MCB ERROR *********' UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 6–15. Source Listing of First Subprogram

(QUAL*UCSTST.MCBSUBX)

7831 4077–009 6–67

Application Programming in an HVTIP Environment

Source Listing of the Subprogram HVCALLS Element

Example 6–16 shows the source listing of the HVCALLS element for the first
subprogram. In this example, this routine resides in element
QUAL*UCSTST.HVCALLSDEF/MCBSUBY. Noteworthy lines are bolded.

. HVCALLS DEFINITION
. MCBSUBY is defined as a CALL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$CALL 22,8,0 'MCBSUBY'
$END

Example 6–16. Source Listing of the HVCALLS Element for First Subprogram
(QUAL*UCSTST.HVCALLSDEF/MCBSUBY)

6–68 7831 4077–009

 Application Programming in an HVTIP Environment

Source Listing of the Second Subprogram (MCBSUBY)

Example 6–17 shows the complete source listing of the second subprogram,
MCBSUBY. In this example, this subprogram resides in element
QUAL*UCSTST.MCBSUBY. Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBY" THAT WAS CALLED FROM THE *
* SUBPROGRAM "MCBSUBX" WITH A CALL AND IN TURN IT RETURNS TO *
* SUBPROGRAM "MCBSUBX". *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBSUBY INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** MCBSUBY START UP ***
******************************************************
START-UP-SUBY.
DISPLAY ' THIS IS MCBSUBY' UPON PRINTER.
******************************************************
*** RETURN TO MCBSUBX ***
******************************************************
RETURN-SUBX.
DISPLAY ' MCBSUBY RETURNING TO MCBSUBX'
UPON PRINTER.
EXIT PROGRAM.

Example 6–17. Source Listing of the Second Subprogram

(QUAL*UCSTST.MCBSUBY)

7831 4077–009 6–69

Application Programming in an HVTIP Environment

Source Listing of Runstream

Example 6–18 shows the source listing of the runstream used to set up, compile, and
link the HVTIP transactions shown in this example. Noteworthy lines are bolded.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.
@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
@EOF
@ . ***
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
@ASG,A MASM$PF1.
@ . ***
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL ELEMENT "HVCALLSDEF/MCBSUBX
@ . ***
@UCOB QUAL*UCSTST.MCBICP,.MCBICP/COMP,,,NO-OPTIONS
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBX,.HVCALLSDEF/MCBSUBX
@EOF
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE THE FIRST SUBPROGRAM "MCBSUBX" AND ASSEMBLE ITS
@ . *** HVCALLS CALL ELEMENT "HVCALLSDEF/MCBSUBY"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX,.MCBSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBY,.HVCALLSDEF/MCBSUBY
@EOF
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBY ******

Example 6–18. Runstream to Set Up, Compile, and Link—COBOL MCB HVTIP
Transaction Sequence

6–70 7831 4077–009

 Application Programming in an HVTIP Environment

@ . *** COMPILE THE SECOND SUBPROGRAM "MCBSUBY"

@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBY,.MCBSUBY/COMP,,,NO-OPTIONS,SUBPROGRAM
@ . ***
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$n.
@ . ***
@ . *** WHERE "n" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** ** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@ . ***
@USE LINK$PF,SYS$LIB$*APP$3.
@ . ***
@ . ***
@ . *** **** MCBICP LINK ********
@ . *** LINK THE ICP "MCBICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBICP
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.MCBICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBX
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT START$
SET ZEROFILL = NONE FOR ALL BANKS
@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBY"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.MCBSUBX/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBY
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT MCBSUBX

Example 6–18. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Sequence

7831 4077–009 6–71

Application Programming in an HVTIP Environment

SET ZEROFILL = NONE FOR ALL BANKS

@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBY LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBY"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBY
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.MCBSUBY/COMP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT MCBSUBY
SET ZEROFILL = NONE FOR ALL BANKS
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,5 STF,0 STA,J QPR,1 OPT,TV
@ . *** nnn REC,Z AUD,n PRT,xxxxxx
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV
920 REC,Z AUD,3 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***

Example 6–18. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Sequence

6–72 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@ . *** * HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
@ . ***
@ . ***
@ . *** * HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB nn - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP nn - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-file-number - TPLIB = HVTIP-LIBRARY-number
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-file-number = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-number)
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*HVTIPLIB22.,FIX
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
LFD 92
@EOF
@ . ***
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO

Example 6–18. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Sequence

7831 4077–009 6–73

Application Programming in an HVTIP Environment

@ . *** THE HVTIP LIBRARY.

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
CREATE,K 22,30
COPY,IVK 22,6,QUAL*UCSTST.MCBICP
COPY,IK 22,7,QUAL*UCSTST.MCBSUBX
COPY,IK 22,8,QUAL*UCSTST.MCBSUBY
LIST 22
LOAD,K 22
STATUS,K 22
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . EXAMPLE SETUP IS COMPLETE

Example 6–18. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Sequence

Execution of the Source Runstream

Example 6–19 shows the execution of the source runstream used to set up, compile,
and link this example. Output has been saved by an @BRKPT statement. Noteworthy
lines are bolded.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP Transaction

Sequence

6–74 7831 4077–009

 Application Programming in an HVTIP Environment

@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER

@ . *** AND BANK NUMBER.
@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
PDP 13R2 (960429 0108:39) 1997 Feb 23 Sun 1240:30
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 278 Entry Points: 1 Time: 1.789 Storage: 7070/0/7070/0106210
@ . ***
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
I:002333 USE complete.
@ASG,A MASM$PF1.
I:002333 ASG complete.
@ . ***
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL ELEMENT "HVCALLSDEF/MCBSUBX
@ . ***
@UCOB QUAL*UCSTST.MCBICP,.MCBICP/COMP,,,NO-OPTIONS
UCOB- 8R1 (970210) LSS-10R1 (970209) 970223 12:40:36
SIZES: CODE(EM6): 266 DATA: 352 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBX,.HVCALLSDEF/MCBSUBX
MASM 6R2A (960423 0008:22) 1997 Feb 23 Sun 1240:39
END MASM - LINES: 134 TIME: 4.461 STORAGE: 29345/7895
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE THE FIRST SUBPROGRAM "MCBSUBX" AND ASSEMBLE ITS
@ . *** HVCALLS CALL ELEMENT "HVCALLSDEF/MCBSUBY"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX,.MCBSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
UCOB- 8R1 (970210) LSS- 8R2 (970209) 970223 12:40:36
SIZES: CODE(EM6): 191 DATA: 322 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBY,.HVCALLSDEF/MCBSUBY
MASM 6R2A (960423 0008:22) 1997 Feb 23 Sun 1240:43
END MASM - LINES: 134 TIME: 4.525 STORAGE: 29345/7895
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBY ******
@ . *** COMPILE THE SECOND SUBPROGRAM "MCBSUBY"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBY,.MCBSUBY/COMP,,,NO-OPTIONS,SUBPROGRAM

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

7831 4077–009 6–75

Application Programming in an HVTIP Environment

UCOB- 8R1 (970210) LSS-10R1 (970209) 970223 12:40:45

SIZES: CODE(EM6): 58 DATA: 118 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$N.
@ . ***
@ . *** WHERE "N" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** ** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@ . ***
@USE LINK$PF,SYS$LIB$*APP$3.
I:002333 USE complete.
@ . ***
@ . ***
@ . *** **** MCBICP LINK ********
@ . *** LINK THE ICP "MCBICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBICP
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1240:47
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBY"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1240:55
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBY LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBY"
@ . ***
@LINK,QUAL*UCSTST.MCBSUBY
LINK 7R1 (970207 1635:57) 1997 Feb 23 Sun 1241:02
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

6–76 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** NNN NAM,XXXXXX ACT,XXXXXX PRG,5 STF,0 STA,J QPR,N OPT,TV
@ . *** NNN REC,Z AUD,N PRT,XXXXXX
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 45R2#0000001 970223 1241:05
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,J QPR,1 OPT,TV
920 REC,Z AUD,3 PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 920 TRANSACTION CODE: MCBHVT DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: TV PCT: 1 WAITQ: 0

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

7831 4077–009 6–77

Application Programming in an HVTIP Environment

AUD: 3 REC: Z QPR: 1 MAS: NONE SET

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1241:06
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 45R2#0000001 970223 1241:06
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1241:06
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** * HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** * HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB NN - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP NN - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER - TPLIB = HVTIP-LIBRARY-NUMBER
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-NUMBER)
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

6–78 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 45R2 02/23/97 12:41:06 FS-LEVEL FS 003
TREG QUAL*HVTIPLIB22.,FIX
TP REGISTER STARTED 12:41:06 23 FEB 97
TP REGISTER FINISHED 12:41:09 23 FEB 97
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 12:41:09 23 FEB 97
TP RESERVE FINISHED 12:41:09 23 FEB 97
LFD 92
TIP FILE 92
DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME HVTIPLIB22
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1241:09
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
I:002333 ASG complete.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
TPUR 45R2#0000001 970223 1241:09
CREATE,K 22,30
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
NEXT AVAILABLE RECORD: 7 LIBRARY CYCLE: MAIN

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

7831 4077–009 6–79

Application Programming in an HVTIP Environment

COPY,IVK 22,6,QUAL*UCSTST.MCBICP
LLBBBB : 260006 LIB# : 22 BANK# : 6
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/23/97 CREATION TIME : 12:40:54
BANK SIZE : 011200 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 7
LOWER LIMIT : 001000

COPY,IK 22,7,QUAL*UCSTST.MCBSUBX

LLBBBB : 260007 LIB# : 22 BANK# : 7

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX
CREATION DATE : 02/23/97 CREATION TIME : 12:41:01
BANK SIZE : 04600 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 178
LOWER LIMIT : 001000

COPY,IK 22,8,QUAL*UCSTST.MCBSUBY

LLBBBB : 260010 LIB# : 22 BANK# : 8

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBY
CREATION DATE : 02/23/97 CREATION TIME : 12:41:05
BANK SIZE : 04100 BANK TYPE : Z,DY,EM
START ADDRESS : 001001 START RECORD NUMBER : 266
LOWER LIMIT : 001000
LIST 22

LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

NEXT AVAILABLE RECORD: 704 LIBRARY CYCLE: MAIN
LLBBBB : 260006 LIB# : 22 BANK# : 6
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/23/97 CREATION TIME : 12:40:54
BANK SIZE : 011200 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 7
LOWER LIMIT : 001000

LLBBBB : 260007 LIB# : 22 BANK# : 7

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX
CREATION DATE : 02/23/97 CREATION TIME : 12:41:01
BANK SIZE : 04600 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 178
LOWER LIMIT : 001000

LLBBBB : 260010 LIB# : 22 BANK# : 8

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBY
CREATION DATE : 02/23/97 CREATION TIME : 12:41:05
BANK SIZE : 04100 BANK TYPE : Z,DY,EM

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

6–80 7831 4077–009

 Application Programming in an HVTIP Environment

START ADDRESS : 001001 START RECORD NUMBER : 266

LOWER LIMIT : 001000

LOAD,K 22

STATUS,K 22

ONLINE LIBRARY STATUS

LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

BANK RTN LOAD STATUS BANK BANK TIP MEM LOWER START RECORD
NUMB COUNT INDICATORS SIZE TYPE GROUP# LIMIT ADDR NUMBER
---- ----- ----------- ------- ------- --- ------ ------ ------
6* 0 0011200 Z,DY,EM 2 001000 001011 7
7 0 0004600 Z,DY,EM 1 001000 001011 178
8 0 0004100 Z,DY,EM 1 001000 001001 266

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970223 1241:12
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . **
@ . EXAMPLE SETUP IS COMPLETE

Example 6–19. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence

7831 4077–009 6–81

Application Programming in an HVTIP Environment

Execution of the HVTIP Transactions in This Example

The following screen shows an execution of the HVTIP transaction described
previously. User input is bolded.

>MCBHNT

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX

THIS IS MCBSUBX

MCBSUBX CALLING MCBSUBY

THIS IS MCBSUBY

MCBSUBY RETURNING TO MCBSUBX

RETURNED TO MCBSUBX

TERMINATING FROM MCBSUBX

6–82 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.6. HVTIP Subprograms with Multiple Entry Points

This subsection describes how to code and statically link HVTIP subprograms that
have multiple entry points. HVTIP ZOOMs are allowed to have only one entry point.
Therefore, when you have an HVTIP subprogram with multiple entry points, you must
do the following:
1. Set up a MASM jump vector that defines a single external entry point, while
allowing the multiple entry points to be defined as constant offsets from the
single external entry point. The MASM source for the jump vector code will use
the HV$VECTOR PROC in SYS$LIB$*LINK.HVTIP$CALLS.
2. Include this MASM jump vector in the static link of the subprogram containing the
multiple entry points.
3. Define all entry points in an HVCALLS element.
4. Include the HVCALLS element in the static link of the calling program, as usual.

6.1.6.1. Example Transaction

In the following example, the ICP MCBICP calls one of the following two subprograms:
1. MCBSUBA
• MCBSUBA has three entry points: MCBSUBA, MCBEP2, and MCBEP3.
• MCBICP calls MCBSUBA by using any of these entry points.
• The call from MCBICP to all three entry points of MCBSUBA uses the HVTIP
call interface (HV$CALL).
• MCBSUBA is contained in bank 10 in HVTIP library 22.
• A return is made from MCBSUBA to MCBICP, where the transaction sequence
ends.
2. MCBSUBX
• MCBSUBX has only one entry point: MCBSUBX.
• The call from MCBICP to MCBSUBX is an HVTIP transfer-with-cancel
(HV$XFR$CANCL).
• MCBSUBX is contained in bank 7 in HVTIP library 22.
• MCBSUBX is the last subprogram in the transaction sequence. It does not call
any other subprogram.

Figure 6–2 illustrates this example.

7831 4077–009 6–83

Application Programming in an HVTIP Environment

Figure 6–2. HVTIP Subprogram with Multiple Entry Points

As shown in the following table, the transaction code specified by the end user
determines
• Whether subprogram MCBSUBA or subprogram MCBSUBX is called
• Which entry point in MCBSUBA is used if MCBSUBA is called

Transaction
Code Description

MCBHVT Transfers with cancel to MCBSUBX.

MCBEP1 Calls MCBSUBA (paragraph MCBEP1).
MCBEP2 Calls MCBSUBA (paragraph MCBEP2).
MCBEP3 Calls MCBSUBA (paragraph MCBEP3).

The following figure summarizes the program code for MCBICP, MCBSUBA, and
MCBSUBX. Notice that the PROCEDURE DIVISION statement in MCBSUBA identifies
the extra entry points using the clause WITH ENTRY POINTS MCBEP2, MCBEP3.

6–84 7831 4077–009

 Application Programming in an HVTIP Environment

For the complete program code in this example, see 6.1.7.

7831 4077–009 6–85

Application Programming in an HVTIP Environment

6.1.6.2. Step 1: Coding the MASM Jump Vector Routine

HVTIP ZOOMs are allowed to have only one entry point. Therefore, you must set up a
MASM jump vector routine that defines a single external entry point, while allowing
the multiple entry points to be defined as constant offsets from the single external
entry point. This MASM jump vector routine is then included in the static link of the
subprogram containing the multiple entry points (MCBSUBA in this example).

Example 6–20 is an example of the MASM jump vector routine used to define the
three entry points into MCBSUBA. When MCBICP calls MCBSUBA, this MASM jump
vector routine is entered first and transfers control to the appropriate address within
MCBSUBA: MCBSUBA (MCBEP1), MCBEP2, or MCBEP3.

The following figure illustrates this jump vector routine.

HVTIP Library 22 *jumper

01000 3-Word MCBSUBA Entry
000
0,01
22,1
01003 3-Word MCBEP2 Entry
3
CALL 'MCBSUBA'. 100
,10,0 01006
22 3-Word MCBEP3 Entry
6
00
0,01
,1
22
CALL 'MCBEP2'.

MCBEP1.

CALL 'MCBEP3'.

MCBEP2.

Initial Control Program MCBEP3.

Bank 6

Subprogram MCBSUBA
Bank 10

6–86 7831 4077–009

 Application Programming in an HVTIP Environment

@USE MASM$PF1,SYS$LIB$*LINK. (1)

@ASG,A MASM$PF1 (1)

@MASM,N ,QUAL*UCSTST.JUMPVECTOR/MCBSUBA (2)

. JUMP VECTOR DEFINITION
. THE THREE ENTRY POINTS FOR MCBSUBA ARE DEFINED
. MCBSUBA first entry point (MCBSUBA)1A
. MCBSUBA second entry point (MCBEP2)
. MCBSUBA third entry point (MCBEP3)
.
$OBJ
$EXTEND
$INCLUDE 'MAXR$'
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
OM$USE_LV,0 . Define link vector bank as $(0)
. .
$(1) $BANK HV$CODE_EMB,01000 . Define an extended-mode (3)
. code bank that starts at 01000
. and has the MERGE_ORDER
. bank attribute set to FIRST.
. That causes this bank to always
. be placed at the front of any
. bank into which it is merged.
.
JUMPER* . Start address for HVTIP subprogram (4)
.
HV$VECTOR MCBSUBA . Offset 01000 passes control (5)
. to MCBSUBA (MCBEP1)
.
HV$VECTOR MCBEP2 . Offset 01003 passes control (5)
. to MCBEP2
.
HV$VECTOR MCBEP3 . Offset 01006 passes control (5)
. to MCBEP3
$END

Example 6–20. MASM Jump Vector Routine to Define Multiple Entry Points

Explanation
1. These statements obtain the MASM procs, located on the Linking System product
file, required to generate the jump vector.
2. The name of the MASM jump vector routine is
QUAL*UCSTST.JUMPVECTOR/MCBSUBA.
3. This statement gives bank “jv” (location counter 1) a merge order attribute of
FIRST and causes it to start at offset 01000.
4. This MASM jump vector routine has an externalized definition (entry point) name
of JUMPER. Thus, the HVTIP subprogram ZOOM is supplied with this single entry
point.

7831 4077–009 6–87

Application Programming in an HVTIP Environment

5. Each of the three HV$VECTOR calls generates three extended mode instructions
that, when executed, pass program control to the corresponding entry point in the
bank.
If hyphens or lowercase characters are present in the entry point name, you must
put the entry point name in single quotes on the HV$VECTOR statement. The
following is an example.
HV$VECTOR ‘mcbsuba’

HV$VECTOR ‘mcbep2’

HV$VECTOR ‘mcbep3’

Also, you should place an $ASCII directive after the $OBJ directive in the MASM
jump vector routine.
The HV$VECTOR statements will receive “U” flags at assembly time, indicating
undefined names in the assembly. These names will be resolved by the static
linking process when creating the subprogram ZOOM.

6.1.6.3. Step 2: Statically Linking the Subprogram with Multiple

Entry Points
When statically linking the subprogram with multiple entry points (MCBSUBA) to
create a ZOOM, you must include this MASM jump vector routine in the static link.
The following shows the static link for this example.

@USE LINK$PF,SYS$LIB$*APP$3.

@LINK ,QUAL*UCSTST.MCBSUBA
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.MCBSUBA/COMP
(1) INCLUDE QUAL*UCSTST.JUMPVECTOR/MCBSUBA
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
(2) DELETE ALL DEFINITIONS EXCEPT JUMPER
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

Explanation
1. This command includes the MASM jump vector routine.
2. This command deletes all definitions except JUMPER. This is to make sure that
the external definition JUMPER is the only entry point in the HVTIP subprogram
ZOOM.

6.1.6.4. Step 3: Creating the HVCALLS Element

In order for MCBICP to call either MCBSUBA or MCBSUBX, it must include an
HVCALLS element that defines
• The HVTIP library and bank number of each subprogram entry point
• The type of call that is to take place (call or transfer-with-cancel)

6–88 7831 4077–009

 Application Programming in an HVTIP Environment

Example 6–21 shows how to create the HVCALLS element for this example.

@USE MASM$PF1,SYS$LIB$*LINK.
@ASG,A MASM$PF1

@MASM,N ,QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA
. HVCALLS DEFINITION
. MCBSUBX is defined as a TRANSFER WITH CANCEL
. MCBSUBA first entry point is defined as a CALL
. MCBSUBA second entry point (MCBEP2) is defined as a CALL
. MCBSUBA third entry point (MCBEP3) is defined as a CALL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$XFR$CANCL 22,7,0 'MCBSUBX' (1)
HV$CALL 22,10,01000 'MCBSUBA' (2)
HV$CALL 22,10,01003 'MCBEP2' (2)
HV$CALL 22,10,01006 'MCBEP3' (2)
$END

Example 6–21. Creating the HVCALLS Element for the Calling Program

Explanation
1. MCBSUBX is defined as a transfer-with-cancel to HVTIP library 22 bank number 7.
2. All three of the MCBSUBA entry points are defined using HV$CALL, so that a
return is possible.
The labels on these statements correspond to the three entry points; you must
define them in the same order as designated in the multiple entry point jump
vector MASM routine described in the previous subsection.
Notice that each label has the same HVTIP library (22) and bank number (10),
followed by its jump vector’s relative address in the subprogram, starting at octal
01000. Each entry is three words apart because its corresponding jump vector
entry is three instructions long, resulting in the octal addresses: 01000, 01003, and
01006.

6.1.6.5. Step 4: Statically Linking the Calling Program

You must include the HVCALLS element when statically linking the calling program
(MCBICP in this example). The following shows the static linking commands used for
MCBICP.

@USE LINK$PF,SYS$LIB$*APP$3.

@LINK ,QUAL*UCSTST.MCBICP
OUTPUT HVTIP2
INCLUDE QUAL*UCSTST.MCBICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME

7831 4077–009 6–89

Application Programming in an HVTIP Environment

DELETE ALL DEFINITIONS EXCEPT START$

SET ZEROFILL = NONE FOR ALL BANKS
@EOF

6.1.7. Example of an HVTIP Subprogram with Multiple Entry

Points
This subsection describes the code for all aspects of the multiple-entry-point example
introduced in 6.1.6. Figure 6–3 illustrates this example. This example also introduces
the expanded heap capabilities of HVTIP2.

Figure 6–3. Example Showing HVTIP Subprogram with Multiple Entry Points

COBOL and MCB functions are used in this example. There are no changes in the
techniques shown for handling HVTIP subprograms with multiple entry points if DPS
2200 functions are used instead of MCB functions.

This example is composed of the following general components:

1. Source listing of the ICP
2. Source listing of the ICP HVCALLS element
3. Source listing of the first subprogram
4. Source listing of the MASM jump vector routine for the subprogram with multiple
entry points
5. Source listing of the second subprogram
6. A source listing of the runstream to set up, compile, and link the example
transaction
7. The execution of the source runstream (output saved by an @BRKPT statement)
8. Examples of execution of the transactions

6–90 7831 4077–009

 Application Programming in an HVTIP Environment

Source Listing of the ICP (MCBICP)

Example 6–22 shows the complete source listing of the ICP, MCBICP. In this example,
this program resides in element QUAL*UCSTST.MCBICP/MULTEP.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF AN INITIAL CONTROL PROGRAM "MCBICP" USING MCB THAT *
* PERFORMS A TRANSFER WITH CANCEL TO A SUBPROGRAM "MCBSUBX" OR *
* A CALL TO ONE OF THE SUBPROGRAM "MCBSUBA ENTRY POINTS: *
* MCBSUBA (the first entry point), MCBEP2, MCBEP3. *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBICP INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY MCBPKT-UCOB.
PROCEDURE DIVISION.
****************************************************
*** TRANSACTION INITIALIZATION ***
****************************************************
START-UP-ICP.
DISPLAY 'THIS IS MCBICP' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 1 TO P-BIT2.
MOVE P-TRINIT TO P-FUNC.
MOVE 80 TO P-LENGTH.
MOVE 4 TO P-AUX.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
DISPLAY 'INITIALIZATION COMPLETE' UPON PRINTER.
MOVE FUNCTION UPPER-CASE (P-MCB-TRANS-CODE)
TO COMMON-FIELD-1.
******************************************************
*** TRANSFER WITH CANCEL TO MCBSUBX ***

Example 6–22. Source Listing of the ICP (QUAL*UCSTST.MCBICP/MULTEP)

7831 4077–009 6–91

Application Programming in an HVTIP Environment

*** OR ***
*** CALL TO ONE OF THREE ENTRY POINTS ***
*** OF MCBSUBA ***
*** DEPENDING UPON THE TRANSACTION CODE ***
******************************************************
SETUP-CALL-TO-SUBPROGRAM.
EVALUATE COMMON-FIELD-1
WHEN 'MCBHVT'
DISPLAY 'MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX'
UPON PRINTER
CALL 'MCBSUBX'
WHEN 'MCBEP1'
DISPLAY 'MCBICP CALLING MCBSUBA' UPON PRINTER
CALL 'MCBSUBA'
WHEN 'MCBEP2'
DISPLAY 'MCBICP CALLING MCBEP2' UPON PRINTER
CALL 'MCBEP2'
WHEN OTHER
DISPLAY 'MCBICP CALLING MCBEP3' UPON PRINTER
CALL 'MCBEP3'
END-EVALUATE.
******************************************************
*** RETURN TO MCBICP ***
******************************************************
RETURN-FROM-MCBSUBA.
DISPLAY 'RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA'
UPON PRINTER.
****************************************************
*** TRANSACTION TERMINATION ***
****************************************************
MCB-TERMINATE.
DISPLAY 'TERMINATING FROM MCBICP' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.
****************************************************
*** MCB ERROR HANDLING ***
****************************************************
ERROR-EXIT.
DISPLAY '********* MCB ERROR *********' UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
DISPLAY 'ERROR CODE Q3 = ' P-ERRCODEQ3 UPON PRINTER.
DISPLAY 'ERROR CODE Q4 = ' P-ERRCODEQ4 UPON PRINTER.

Example 6–22. Source Listing of the ICP (QUAL*UCSTST.MCBICP/MULTEP)

6–92 7831 4077–009

 Application Programming in an HVTIP Environment

MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 6–22. Source Listing of the ICP (QUAL*UCSTST.MCBICP/MULTEP)

Source Listing of the ICP HVCALLS Element

Example 6–23 shows the source listing of the HVCALLS element for the ICP. In this
example, this routine resides in element
QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA. Noteworthy lines are bolded.

. HVCALLS DEFINITION
. MCBSUBX is defined as a TRANSFER WITH CANCEL
. MCBSUBA first entry point is defined as a CALL
. MCBSUBA second entry point (MCBEP2) is defined as a CALL
. MCBSUBA third entry point (MCBEP3) is defined as a CALL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
HV$XFR$CANCL 22,7,0 'MCBSUBX'
HV$CALL 22,10,01000 'MCBSUBA'
HV$CALL 22,10,01003 'MCBEP2'
HV$CALL 22,10,01006 'MCBEP3'
$END

Example 6–23. Source Listing of the ICP HVCALLS Element

(QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA)

7831 4077–009 6–93

Application Programming in an HVTIP Environment

Source Listing of the First Subprogram (MCBSUBA)

Example 6–24 shows the complete source listing of the first subprogram, MCBSUBA.
In this example, this program resides in element QUAL*UCSTST.MCBSUBA.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBA" THAT WAS CALLED FROM THE ICP *
* "MCBICP" USING A CALL TO ONE OF THE THREE ENTRY POINTS: *
* MCBSUBA, MCBEP2, MCBEP3. *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBSUBA INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
PROCEDURE DIVISION WITH ENTRY POINTS MCBEP2, MCBEP3.
*
MCBEP1.
DISPLAY ' THIS IS MCBSUBA "MCBEP1" ENTRY POINT'
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.
EXIT PROGRAM.
*
MCBEP2.
DISPLAY ' THIS IS MCBSUBA "MCBEP2" ENTRY POINT '
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.

Example 6–24. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA)

6–94 7831 4077–009

 Application Programming in an HVTIP Environment

EXIT PROGRAM.
*
MCBEP3.
DISPLAY ' THIS IS MCBSUBA "MCBEP3" ENTRY POINT '
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.
EXIT PROGRAM.

Example 6–24. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA)

7831 4077–009 6–95

Application Programming in an HVTIP Environment

Source Listing of the MASM Jump Vector Routine

Example 6–25 shows the complete source listing of the jump vector routine that
defines the three entry points of subprogram MCBSUBA. In this example, this
program resides in element QUAL*UCSTST.JUMPVECTOR/MCBSUBA. This element
will be statically linked with MCBSUBA. Noteworthy lines are bolded.

. JUMP VECTOR DEFINITION

. THE THREE ENTRY POINTS FOR MCBSUBA ARE DEFINED
. MCBSUBA first entry point
. MCBSUBA second entry point (MCBEP2)
. MCBSUBA third entry point (MCBEP3)
.
$OBJ
$EXTEND
$INCLUDE 'MAXR$'
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
.
OM$USE_LV,0 . Define link vector bank as $(0)
.
$(1) $BANK HV$CODE_EMB,01000 . Define an extended-mode code bank
. that starts at 01000 and has the
. MERGE_ORDER bank attribute set to
. FIRST.
. That causes this bank to always
. be placed at the front of any
. bank into which it is merged.
.
JUMPER* . Start address for HVTIP subprogram
.
HV$VECTOR MCBSUBA . Offset 01000 passes control
. to MCBSUBA
.
HV$VECTOR MCBEP2 . Offset 01003 passes control
. to MCBEP2
.
HV$VECTOR MCBEP3 . Offset 01006 passes control
. to MCBEP3
.
$END

Example 6–25. Source Listing of the MASM Jump Vector Routine

(QUAL*UCSTST.JUMPVECTOR/MCBSUBA)

6–96 7831 4077–009

 Application Programming in an HVTIP Environment

Source Listing of the Second Subprogram (MCBSUBX)

Example 6–26 shows the complete source listing of the second subprogram,
MCBSUBX. In this example, this program resides in element
QUAL*UCSTST.MCBSUBX/NOCALLS.

IDENTIFICATION DIVISION.
*******************************************************************************
*********************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBX" THAT WAS CALLED FROM THE ICP *
* "MCBICP" USING TRANSFER WITH CANCEL *
* *
*******************************************************************************
*********************************************************************
PROGRAM-ID. MCBSUBX INITIAL.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY MCBPKT-UCOB
PROCEDURE DIVISION.
****************************************************
*** MCBSUBX START UP ***
****************************************************
START-UP-SUBX.
DISPLAY ' THIS IS MCBSUBX' UPON PRINTER.
****************************************************
*** TRANSACTION TERMINATION ***
****************************************************
MCB-TERMINATE.
DISPLAY ' TERMINATING FROM MCBSUBX' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
STOP RUN.
*****************************************************
*** MCB ERROR HANDLING ***
*****************************************************

Example 6–26. Source Listing of the Second Subprogram

(QUAL*UCSTST.MCBSUBX/NOCALLS)

7831 4077–009 6–97

Application Programming in an HVTIP Environment

ERROR-EXIT.
DISPLAY '********* MCB ERROR ********* UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
DISPLAY 'ERROR CODE Q3 = ' P-ERRCODEQ3 UPON PRINTER.
DISPLAY 'ERROR CODE Q4 = ' P-ERRCODEQ4 UPON PRINTER.
MOVE 0 TO P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 6–26 Source Listing of the Second Subprogram

(QUAL*UCSTST.MCBSUBX/NOCALLS)

Source Listing of Runstream

Example 6–27 shows the source listing of the runstream used to set up, compile, and
link the HVTIP transactions shown in the previous subsections. Noteworthy lines are
bolded.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS:
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.
@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
@EOF
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
@ASG,A MASM$PF1.
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL AND CALL ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"
@ . ***
@UCOB QUAL*UCSTST.MCBICP/MULTEP,.MCBICP/COMP,,,NO-OPTIONS
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA,.HVCALLSDEF/MCBSUBXSUBA

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB HVTIP
Transaction Program Sequence Using Multiple Entry Points

6–98 7831 4077–009

 Application Programming in an HVTIP Environment

@EOF
@ . ***
@ . *** * MULTIPLE ENTRY POINT SUBPROGRAM MCBSUBA ******
@ . *** COMPILE THE MULTIPLE ENTRY POINT SUBPROGRAM "MCBSUBA" AND
@ . *** ASSEMBLE ITS JUMP VECTOR ELEMENT "JUMPVECTOR/MCBSUBA"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBA,.MCBSUBA/COMP,,,NO-OPTIONS,SUBPROGRAM
@MASM,N QUAL*UCSTST.JUMPVECTOR/MCBSUBA,.JUMPVECTOR/MCBSUBA
@EOF
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE SUBPROGRAM "MCBSUBX"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX/NOCALLS,.MCBSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$n.
@ . ***
@ . *** WHERE "n" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@USE LINK$PF,SYS$LIB$*APP$3.
@ . ***
@ . *** CREATE SYMBOLIC ELEMENTS TO HOLD THE "OUTPUT" STATEMENT
@ . *** AND THE "SET LOWADR" STATEMENTS FOR BLANK COMMON THAT EACH
@ . *** OF THE STATIC LINKS WILL NEED:
@ . ***
@ELT,I QUAL*UCSTST.OUTPUTSTMT
. Setup an HVTIP2 heap environment consisting of:
. Program-level banks:
. Small banks: (4, each with limits of 060000 to 0577777)
. BDIs 06
. 07
. 010 (pooled)
. 011 (pooled)
. Large banks: (2, 2 BDIs each)
. BDIs 012 & 013
. 014 & 015 (pooled)
. Activity-level banks:

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

7831 4077–009 6–99

Application Programming in an HVTIP Environment

. Small banks: (4, each with limits of 060000 to 0577777)

. BDIs 03
. 04 (pooled)
. 05 (pooled)
. 06 (pooled)
. Large banks: (1, 3 BDIs each)
. BDIs 07, 010, & 011 (pooled)
.
. The standard HVTIP heap bank (Program-level BDI 5) is also available.
.
. The above bank allocations correspond to the following
. VALTAB settings:
. DSPRGCNT,4 DLPRGCNT,2 DPSIZL,2
. DSACTCNT,4 DLACTCNT,1 DASIZL,3
. DSLOWER,060000 DSUPPER,0577777
.
. Here is the OUTPUT HVTIP2 statement to match these bank allocations:
.
OUTPUT HVTIP2
WITH
TS_MISMATCH_ACTION = CANCEL,
SMALL_BANK_LIMITS = 060000 TO 0577777
USING
4 SMALL_BANKS,
2 POOLED_SMALL_BANKS,
2 LARGE_BANKS,
1 POOLED_LARGE_BANKS,
LARGE_BANK_SIZE = 2
FOR PROGRAM_LEVEL_HEAP
USING
4 SMALL_BANKS,
3 POOLED_SMALL_BANKS,
1 LARGE_BANKS,
1 POOLED_LARGE_BANKS,
LARGE_BANK_SIZE = 3
FOR ACTIVITY_LEVEL_HEAP
@ELT,I QUAL*UCSTST.COMMON
. Place our Cobol Blank Common at 060100 in the Program-level
. small bank with BDI 06:
.
SET LOWADR = 0400006060100 FOR $BLANK$COMMON$
@EOF
@ . ***
@ . ***
@ . *** *** MCBICP LINK ********
@ . *** LINK THE ICP "MCBICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

6–100 7831 4077–009

 Application Programming in an HVTIP Environment

@ . ***
@LINK ,QUAL*UCSTST.MCBICP
ADD QUAL*UCSTST.OUTPUTSTMT
INCLUDE QUAL*UCSTST.MCBICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
ADD QUAL*UCSTST.COMMON
SET ZEROFILL = NONE FOR ALL BANKS
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBA LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBA" INCLUDING THE JUMP VECTOR ELEMENT
@ . *** "JUMPVECTOR/MCBSUBA"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBA
ADD QUAL*UCSTST.OUTPUTSTMT
INCLUDE QUAL*UCSTST.MCBSUBA/COMP
INCLUDE QUAL*UCSTST.JUMPVECTOR/MCBSUBA
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
ADD QUAL*UCSTST.COMMON
SET LOWADR = 0400007060100 FOR HVTIP$$DSEG
SET ZEROFILL = NONE FOR ALL BANKS
DELETE ALL DEFINITIONS EXCEPT JUMPER
@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
ADD QUAL*UCSTST.OUTPUTSTMT
INCLUDE QUAL*UCSTST.MCBSUBX/COMP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
ADD QUAL*UCSTST.COMMON
SET LOWADR = 0400005170000 FOR HVTIP$$DSEG
SET ZEROFILL = NONE FOR ALL BANKS
DELETE ALL DEFINITIONS EXCEPT MCBSUBX
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** VTBUTL IS THE UTILITY FOR MANAGING THE VALTAB ENTRIES

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

7831 4077–009 6–101

Application Programming in an HVTIP Environment

@ . *** AND THE VINDEX.

@ . ***
@ . *** VALCHG ADDS, CHANGES, OR DELETES VALTAB ENTRIES FROM
@ . *** THE EXISTING VALTAB AND VINDEX.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,5 STF,0 STA,IJ QPR,n OPT,TV
@ . *** nnn REC,Z AUD,3 PRT,xxxxxx
@ . *** nnn DSP,n DLP,n DPS,n
@ . *** nnn DSA,n DLA,n DAS,n
@ . *** nnn DSLOWER,0nnnnnn DSUPPER,0nnnnnn
@ . ***
@ . *** THE LAST 3 LINES ABOVE ARE ONLY APPLICABLE WHEN
@ . *** USING HVTIP-II FUNCTIONALITY.
@ . ***
@ . ***
@ . *** IN THIS EXAMPLE:
@ . *** THE TRANSACTION CODE (ACT,xxxxxx) IDENTIFIES WHICH
@ . *** SUBPROGRAM WILL BE CALLED.
@ . *** TRANSACTION CODE 'MCBHVT' EXECUTES SUBPROGRAM 'MCBSUBX'
@ . *** TRANSACTION CODE 'MCBEP1' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** FIRST ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP2' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** SECOND ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP3' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** THIRD ENTRY POINT
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
920 REC,Z AUD,3 PRT,PR
920 DSP,4 DLP,2 DPS,2
920 DSA,4 DLA,1 DAS,3
920 DSLOWER,060000 DSUPPER,0577777
921 NAM,MCBICP ACT,MCBEP1 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
921 REC,Z AUD,3 PRT,PR
921 DSP,4 DLP,2 DPS,2
921 DSA,4 DLA,1 DAS,3
921 DSLOWER,060000 DSUPPER,0577777
922 NAM,MCBICP ACT,MCBEP2 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
922 REC,Z AUD,3 PRT,PR
922 DSP,4 DLP,2 DPS,2
922 DSA,4 DLA,1 DAS,3
922 DSLOWER,060000 DSUPPER,0577777
923 NAM,MCBICP ACT,MCBEP3 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

6–102 7831 4077–009

 Application Programming in an HVTIP Environment

923 REC,Z AUD,3 PRT,PR

923 DSP,4 DLP,2 DPS,2
923 DSA,4 DLA,1 DAS,3
923 DSLOWER,060000 DSUPPER,0577777
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB nn - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP mm - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-file-number minus TPLIB = HVTIP-LIBRARY-number
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-file-number = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-number)
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

7831 4077–009 6–103

Application Programming in an HVTIP Environment

@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*HVTIPLIB22.,FIX
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
LFD 92
@EOF
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
CREATE,K 22,30
COPY,IVK 22,6,QUAL*UCSTST.MCBICP
COPY,IK 22,7,QUAL*UCSTST.MCBSUBX
COPY,IK 22,10,QUAL*UCSTST.MCBSUBA
LIST 22
LOAD,K 22
STATUS,K 22
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF RECOVERY
ON SCHEDULE
@EOF
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 6–27. Runstream to Set Up, Compile, and Link—COBOL MCB

HVTIP Transaction Program Sequence Using Multiple Entry Points

6–104 7831 4077–009

 Application Programming in an HVTIP Environment

Execution of the Source Runstream

Example 6–28 shows the execution of the source runstream used to set up, compile,
and link this example. Output has been saved by an @BRKPT statement.

@ . ***
@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS:
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.
@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
PDP 13R2 (960429 0508:57) 1997 Feb 06 Thu 1354:33
Copyright (c) 1994 Unisys Corporation.
All rights reserved.
UNISYS PROPRIETARY
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 278 Entry Points: 1 Time: 2.134 Storage: 7070/0/7070/0920 73
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
I:002333 USE complete.
@ASG,A MASM$PF1.
W:120333 file is assigned to another run.
W:120133 file is already assigned.
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL AND CALL ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"
@ . ***
@UCOB QUAL*UCSTST.MCBICP/MULTEP,.MCBICP/COMP,,,NO-OPTIONS
UCOB- 8R1(970210) LSS- 10R1(970209) 960206 13:54:33
SIZES: CODE(EM6): 327 DATA: 565 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA,.HVCALLSDEF/MCBSUBXSUBA
MASM 6R2A U2 (970423 1042:19) 1997 Feb 06 Thu 1354:37
COPYRIGHT (c) 1994 Unisys Corporation.
All rights reserved.
UNISYS PROPRIETARY
END MASM - LINES: 497 TIME: 3.929 STORAGE: 29399/8152

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP Transaction

Sequence Using Multiple Entry Points

7831 4077–009 6–105

Application Programming in an HVTIP Environment

@ . ***
@ . *** * MULTIPLE ENTRY POINT SUBPROGRAM MCBSUBA ******
@ . *** COMPILE THE MULTIPLE ENTRY POINT SUBPROGRAM "MCBSUBA" AND
@ . *** ASSEMBLE ITS JUMP VECTOR ELEMENT "JUMPVECTOR/MCBSUBA"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBA,.MCBSUBA/COMP,,,NO-OPTIONS,SUBPROGRAM
UCOB- 8R1(970210) LSS- 10R1(970209) 970206 13:54:38
SIZES: CODE(EM6): 132 DATA: 380 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.JUMPVECTOR/MCBSUBA,.JUMPVECTOR/MCBSUBA
MASM 6R2A U2 (960423 1042:19) 1997 Feb 06 Thu 1354:39
COPYRIGHT (c) 1994 Unisys Corporation.
All rights reserved.
UNISYS PROPRIETARY
ASSEMBLY CONTAINS WARNINGS: - FLAGS: U
END MASM - LINES: 258 TIME: 3.904 STORAGE: 29399/7972 WARNINGS: U(3)
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE SUBPROGRAM "MCBSUBX"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX/NOCALLS,.MCBSUBX/COMP,,,NO-OPTIONS,SUBPROGRAM
UCOB- 8R1(970210) LSS- 10R1(970209) 970206 13:54:39
SIZES: CODE(EM6): 179 DATA: 262 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
@ . *** HVTIP ZOOMS.
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$N.
@ . ***
@ . *** WHERE "N" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@ . ***
@USE LINK$PF,SYS$LIB$*APP$3.
I:002333 USE complete.
@ . ***
@ . *** CREATE SYMBOLIC ELEMENTS TO HOLD THE "OUTPUT" STATEMENT
@ . *** AND THE "SET LOWADR" STATEMENTS FOR BLANK COMMON THAT EACH
@ . *** OF THE STATIC LINKS WILL NEED:
@ . ***

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

6–106 7831 4077–009

 Application Programming in an HVTIP Environment

@ELT,I QUAL*UCSTST.OUTPUTSTMT
ELT 8R3 (960423 1235:55) 1997 Feb 06 Thu 1354:42
END ELT. ERRORS: NONE. TIME: 1.179 SEC. IMAGE COUNT: 48
@ELT,I QUAL*UCSTST.COMMON
ELT 8R3 (960423 1235:55) 1997 Feb 06 Thu 1354:42
END ELT. ERRORS: NONE. TIME: 1.098 SEC. IMAGE COUNT: 4
@ . ***
@ . ***
@ . *** *** MCBICP LINK ********
@ . *** LINK THE ICP "MCBICP" INCLUDING THE HVCALLS ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"
@ . ***
@LINK ,QUAL*UCSTST.MCBICP
LINK 7R1 (970207 1144:41) 1997 Feb 06 Thu 1354:42
END LINK , LINES : 59 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBA LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBA" INCLUDING THE JUMP VECTOR ELEMENT
@ . *** "JUMPVECTOR/MCBSUBA"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBA
LINK 7R1 (970207 1144:41) 1997 Feb 06 Thu 1354:48
END LINK , LINES : 60 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
LINK 7R1 (970207 1144:41) 1997 Feb 06 Thu 1354:50
*INFO (LINK 780)* The Linking System will create a ZOOM that conforms to the
HVTIP2 format. It can only be executed in the HVTIP2 environment.
END LINK , LINES : 59 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** VTBUTL IS THE UTILITY FOR MANAGING THE VALTAB ENTRIES
@ . *** AND THE VINDEX.
@ . ***

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

7831 4077–009 6–107

Application Programming in an HVTIP Environment

@ . *** VALCHG ADDS, CHANGES, OR DELETES VALTAB ENTRIES FROM

@ . *** THE EXISTING VALTAB AND VINDEX.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** NNN NAM,XXXXXX ACT,XXXXXX PRG,5 STF,0 STA,IJ QPR,N OPT,TV
@ . *** NNN REC,Z AUD,3 PRT,XXXXXX
@ . *** NNN DSP,N DLP,N DPS,N
@ . *** NNN DSA,N DLA,N DAS,N
@ . *** NNN DSLOWER,0NNNNNN DSUPPER,0NNNNNN
@ . ***
@ . *** THE LAST 3 LINES ABOVE ARE ONLY APPLICABLE WHEN
@ . *** USING HVTIP-II FUNCTIONALITY.
@ . ***
@ . ***
@ . *** IN THIS EXAMPLE:
@ . *** THE TRANSACTION CODE (ACT,XXXXXX) IDENTIFIES WHICH
@ . *** SUBPROGRAM WILL BE CALLED.
@ . *** TRANSACTION CODE 'MCBHVT' EXECUTES SUBPROGRAM 'MCBSUBX'
@ . *** TRANSACTION CODE 'MCBEP1' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** FIRST ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP2' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** SECOND ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP3' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** THIRD ENTRY POINT
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 45R2#0000001 970206 1354:53
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

6–108 7831 4077–009

 Application Programming in an HVTIP Environment

WAITQ WAI WAIT-Q LENGTH

DBKSIZ DBK D-BANK SIZE
DASIZL DAS LARGE ACT BLOCKS
DBMAX DBM MAIN BANK MAX SIZE
DLACTCNT DLA # LARGE ACT BANKS
DLPRGCNT DLP # LARGE PRG BANKS
DPSIZL DPS LARGE PRG BLOCKS
DSACTCNT DSA # SMALL ACT BANKS
DSPRGCNT DSP # SMALL PRG BANKS
DSLOWER DSL BANK LOWER LIMIT
DSUPPER DSU BANK UPPER LIMIT
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY
TCASIZ TCA TCA BANK SIZE
DATA CARDS FOR NEXT VALTAB CHANGE:
920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
920 REC,Z AUD,3 PRT,PR
920 DSP,4 DLP,2 DPS,2
920 DSA,4 DLA,1 DAS,3
920 DSLOWER,060000 DSUPPER,0577777
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 920 TRANSACTION CODE: MCBHVT DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: LANGPR LEV: 0
STA: IJ OPT: TV PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET TCA: 0
DBM: 0 DAS: 3 DLA: 1 DSA: 4
DPS: 2 DLP: 2 DSP: 4
DSL: 060000 DSU:0577777
DATA CARDS FOR NEXT VALTAB CHANGE:
921 NAM,MCBICP ACT,MCBEP1 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
921 REC,Z AUD,3 PRT,PR
921 DSP,4 DLP,2 DPS,2
921 DSA,4 DLA,1 DAS,3
921 DSLOWER,060000 DSUPPER,0577777
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 921 TRANSACTION CODE: MCBEP1 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: LANGPR LEV: 0
STA: IJ OPT: TV PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET TCA: 0
DBM: 0 DAS: 3 DLA: 1 DSA: 4
DPS: 2 DLP: 2 DSP: 4
DSL: 060000 DSU:0577777
DATA CARDS FOR NEXT VALTAB CHANGE:
922 NAM,MCBICP ACT,MCBEP2 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
922 REC,Z AUD,3 PRT,PR

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

7831 4077–009 6–109

Application Programming in an HVTIP Environment

922 DSP,4 DLP,2 DPS,2

922 DSA,4 DLA,1 DAS,3
922 DSLOWER,060000 DSUPPER,0577777
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 922 TRANSACTION CODE: MCBEP2 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: LANGPR LEV: 0
STA: IJ OPT: TV PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET TCA: 0
DBM: 0 DAS: 3 DLA: 1 DSA: 4
DPS: 2 DLP: 2 DSP: 4
DSL: 060000 DSU:0577777
DATA CARDS FOR NEXT VALTAB CHANGE:
923 NAM,MCBICP ACT,MCBEP3 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
923 REC,Z AUD,3 PRT,PR
923 DSP,4 DLP,2 DPS,2
923 DSA,4 DLA,1 DAS,3
923 DSLOWER,060000 DSUPPER,0577777
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 923 TRANSACTION CODE: MCBEP3 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: LANGPR LEV: 0
STA: IJ OPT: TV PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET TCA: 0
DBM: 0 DAS: 3 DLA: 1 DSA: 4
DPS: 2 DLP: 2 DSP: 4
DSL: 060000 DSU:0577777
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R1#0000001 970206 1354:54
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 45R2#0000001 970206 1354:54
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970206 1354:54
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

6–110 7831 4077–009

 Application Programming in an HVTIP Environment

E:244433 file is already catalogued.

@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB NN - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP MM - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER MINUS TPLIB = HVTIP-LIBRARY-NUMBER
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-NUMBER)
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 45R2 02/06/97 13:54:54 FS-LEVEL FS 003
CURRENT TIP DIRECTORY IS LOCAL
TREG QUAL*HVTIPLIB22.,FIX
TP REGISTER STARTED 13:54:54 6 FEB 97
TP REGISTER FINISHED 13:54:54 6 FEB 97
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 13:54:54 6 FEB 97
TP RESERVE FINISHED 13:54:54 6 FEB 97
LFD 92
TIP FILE 92
DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME HVTIPLIB22

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

7831 4077–009 6–111

Application Programming in an HVTIP Environment

PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970206 1354:54
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
W:120533 filename not unique.
W:120133 file is already assigned.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
TPUR 45R2#0000001 970206 1354:54
CREATE,K 22,30
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
NEXT AVAILABLE RECORD: 7 LIBRARY CYCLE: MAIN
COPY,IVK 22,6,QUAL*UCSTST.MCBICP
LLBBBB : 170006 LIB# : 22 BANK# : 6
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/06/97 CREATION TIME : 13:54:47
BANK SIZE : 011000 BANK TYPE : Z,DY,EM
START ADDRESS : 001013 START RECORD NUMBER : 7
LOWER LIMIT : 001000 STATUS BITS : NONE
COPY,IK 22,7,QUAL*UCSTST.MCBSUBX
LLBBBB : 170007 LIB# : 22 BANK# : 7
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX
CREATION DATE : 02/06/97 CREATION TIME : 13:54:52
BANK SIZE : 04700 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 173
LOWER LIMIT : 001000 STATUS BITS : NONE
COPY,IK 22,10,QUAL*UCSTST.MCBSUBA
LLBBBB : 170012 LIB# : 22 BANK# : 10
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBA
CREATION DATE : 02/06/97 CREATION TIME : 13:54:50
BANK SIZE : 05000 BANK TYPE : Z,DY,EM
START ADDRESS : 001000 START RECORD NUMBER : 264
LOWER LIMIT : 001000 STATUS BITS : NONE

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

6–112 7831 4077–009

 Application Programming in an HVTIP Environment

LIST 22
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
NEXT AVAILABLE RECORD: 357 LIBRARY CYCLE: MAIN
LLBBBB : 170006 LIB# : 22 BANK# : 6
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/06/97 CREATION TIME : 13:54:47
BANK SIZE : 011000 BANK TYPE : Z,DY,EM
START ADDRESS : 001013 START RECORD NUMBER : 7
LOWER LIMIT : 001000 STATUS BITS : NONE
LLBBBB : 170007 LIB# : 22 BANK# : 7
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX
CREATION DATE : 02/06/97 CREATION TIME : 13:54:52
BANK SIZE : 04700 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 173
LOWER LIMIT : 001000 STATUS BITS : NONE
LLBBBB : 170012 LIB# : 22 BANK# : 10
ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBA
CREATION DATE : 02/06/97 CREATION TIME : 13:54:50
BANK SIZE : 05000 BANK TYPE : Z,DY,EM
START ADDRESS : 001000 START RECORD NUMBER : 264
LOWER LIMIT : 001000 STATUS BITS : NONE
LOAD,K 22
STATUS,K 22
ONLINE LIBRARY STATUS
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
BANK RTN LOAD STATUS BANK BANK LOWER START RECORD
NUMB COUNT INDICATORS SIZE TYPE LIMIT ADDR NUMBER
---- ----- ----------- ------- ------- ------ ------ ------
6* 0 0011000 Z,DY,EM 001000 001013 7
7 0 0004700 Z,DY,EM 001000 001011 173
10* 0 0005000 Z,DY,EM 001000 001000 264
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970206 1354:57
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 6–28. Execution of Source Runstream—COBOL MCB HVTIP

Transaction Sequence Using Multiple Entry Points

7831 4077–009 6–113

Application Programming in an HVTIP Environment

Execution of the HVTIP Transactions in This Example

Example 1
The following screen shows an execution of the HVTIP transaction described
previously. User input is bolded.

>MCBHNT

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX

THIS IS MCBSUBX

TERMINATING FROM MCBSUBX

Example 2
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

>MCBEP1

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBSUBA

THIS IS MCBSUBA "MCBEP1" ENTRY POINT

TRANSACTION CODE MCBEP1 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

6–114 7831 4077–009

 Application Programming in an HVTIP Environment

Example 3
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

>MCBEP2

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBEP2

THIS IS MCBSUBA "MCBEP2" ENTRY POINT

TRANSACTION CODE MCBEP2 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

7831 4077–009 6–115

Application Programming in an HVTIP Environment

Example 4
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

>MCBEP3

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBEP3

THIS IS MCBSUBA "MCBEP3" ENTRY POINT

TRANSACTION CODE MCBEP3 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

6–116 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.8. Mixed-Mode HVTIP

Note: Mixed-mode handling is available for non-HVTIP also. See Section 13 in the
Linking System Subsystem Guide for details.

HVTIP programs can switch modes when doing a CALL or TRANSFER to another
HVTIP subprogram. In other words, an extended mode HVTIP ZOOM can access a
basic mode HVTIP absolute and vice-versa. This is allowed for all HVTIP transactions
where:
• The ICP is an extended mode ZOOM
• The VALTAB W indicator is used (IND, W)

A mixed-mode transaction is given two d-banks by default:

• Program Level BDI 5 is for use by basic mode
• Program Level BDI 6 is for use by extended mode (by convention)

More extended mode d-banks can be obtained if the DSP, DLP, DSA, or DLA VALTAB
entries are specified. The extended mode ICP and subprograms must also have an
OUTPUT HVTIP2 statement in their static links that indicates mixed mode:

OUTPUT HVTIP2 WITH ENVIRONMENT = MIXED_MODE

BM_LIMITS = 040000 to 0177777

D-bank limits may also be supplied in the OUTPUT HVTIP2 statement and should
match those in the VALTAB entries.

If the extended mode programs wish to share COMMON with the basic mode
programs, then SET LOWADR statements must be supplied to the extended mode
HVTIP static links. This places the common blocks at the addresses in BDI 5 where
the basic mode code expects them to be. Extended mode HVTIP programs should
NOT put anything into the BDI 5 d-bank other than common blocks, and their
placement (assigned addresses) must match that given them by the basic mode ACOB
ICP

To use the mixed-mode feature, an environment switch must be done and parameter
passing protocols matched when a CALL or TRANSFER is done to code in the opposite
mode. This can be done using intercept routines.

There is an SSG-based runstream in SYS$LIB$*URTS.MIXEDMODESKL that will

generate the relocatable (for basic mode) and object module (for extended mode)
intercepts necessary to support mixed-mode HVTIP executions. It supports ACOB
code on the basic mode side and any UCS language (UCOB, UC, or UFTN) on the
extended mode side. In addition, mixed-mode calls to ACOB AFCBs and extended
mode subsystems are supported in the HVTIP environment. The intercepts must be
included in the collections and static links of the code that is calling to code in another
mode. The inputs to MIXEDMODESKL specify information such as intercept routine
names, entry point names, modes, parameter types, etc. This language is described in
the Linking System Subsystems Guide.

7831 4077–009 6–117

Application Programming in an HVTIP Environment

The basic mode side of a mixed-mode transaction must still have a basic mode (ACOB)
main program to initialize the basic mode run-time environment. The basic mode main
program must be called (or transferred to) from the extended mode side, and it will
never return since it is a main program.

The ACOB MAPHVTIP runstream has been updated to help support mixed-mode.
(MAPHVTIP is in the ACOB TIP library file, SYS$LIB$*ACOB-TIPLIB.) A new USING
clause is defined to indicate that the HVTIP absolutes it creates are to possibly
execute in a mixed- mode environment:
USING MIXEDMODE

This option causes the generated MAP symbolic for the basic mode ICP to include the
BMSTACK intercept first in the ICP’s RSEG and BLANK$COMMON second (if it is
used). This is necessary so that their addresses can be reliably predicted since they
must be given constant values on the extended mode side. (Constant values must be
supplied to MIXEDMODESKL for BMSTACK’s address and to the static links of the
extended mode HVTIP ZOOMs for Blank Common’s address.) The BMSTACK intercept
defines an interface area used by the intercept routines for passing and staging
parameters. Its default size is 512 words.

The extended mode side is assumed to be UCOB, but can actually be any UCS
language as long as you are careful with the data types used for parameters and are
aware of the language differences. Any UC program being called (or calling) from/to
ACOB code (or from/to UCOB or UFTN for that matter) will require a #pragma
interface statement to accept or pass the parameters properly. This pragma results
in the UC generated code changing all pointer parameters for the entry point named in
the pragma to be pass-by-reference parameters. This then matches UFTN, UCOB, or
ACOB parameter-passing. See the UC PRM. The BMSTACK interface area must be
initialized before the first extended mode call to basic mode. The entry point B$INIT
(in intercept object module B$INIT) must be called before the first call to basic mode
code to do this initialization. In addition, if the extended mode side is going to call any
basic mode ACOB-based AFCBs, the entry point R$INIT (in relocatable intercept
R$INIT) must be called from the basic mode HVTIP code before any extended mode
calls to basic mode AFCBs can be done. Note that the appropriate ...SYSDTA
relocatables associated with the basic mode AFCBs must be included in the collection
of the basic mode HVTIP code that calls the R$INIT initialization intercept. This results
in the d-bank for the ACOB AFCBs being collected into the RSEG of the HVTIP absolute
that calls the R$INIT initialization intercept.

The preceding discussion is background for the following three mixed-mode

examples.

The first example is trivial, in that the extended mode ICP simply calls a basic mode
HVTIP main program that calls another basic mode HVTIP subprogram.

The second example has the extended mode ICP call a basic mode HVTIP main
program which then calls an extended mode HVTIP subprogram passing a parameter.
Both modes also share the same common storage.

6–118 7831 4077–009

 Application Programming in an HVTIP Environment

The third example is quite extensive, with an extended mode ICP, a basic mode ICP,
and extended mode and basic mode subprograms. COMMON is shared between
modes and parameters are passed between modes. An ACOB AFCB and an extended
mode subsystem are also accessed from both modes. Finally, VALTAB entries define
five transactions where one is extended mode, one is basic mode, and three are
mixed-mode. The extended mode and mixed-mode transactions share the same
extended mode ICP, and the basic mode transaction’s ICP is called from the mixed-
mode transactions.

The examples are meant to show what is needed to traverse modes and are artificial.
Transaction outputs consist of symbiont prints (COBOL DISPLAY...UPON PRINTER and
FORTRAN PRINT statements). Only the runstreams are shown and the transaction
outputs. The execution of the runstreams is not shown. The runstreams have been
given line numbers for ease of reference.

6.1.8.1. Simple Mixed-Mode Example

An extended mode ICP calls a basic mode HVTIP main program that calls a basic mode
HVTIP subprogram.

1: @ .
2: @ . >>>>>>
3: @ . >>>>>> SIMPLE MIXED-MODE EXAMPLE:
4: @ . >>>>>>
5: @ . >>>>>> Use TIP file 87, HVTIP library # 17 with a
6: @ . >>>>>> filename of QUAL*HVTIPLIB17.
7: @ . >>>>>> The EM ICP will be Bank # 020.
8: @ . >>>>>> The BM ICP will be Bank # 021.
9: @ . >>>>>> BM subprogram BMSUB will be Bank # 022.
10: @ . >>>>>> Use VALTAB 615 for the transaction, and
11: @ . >>>>>> name the transaction MIXED1.
12: @ . >>>>>> Use Application # 9.
13: @ . >>>>>> Have all print queued to print queue HOLDPR.
14: @ . >>>>>>
15: @ .
16: @ucob,i emicp,,,,no-options
17: IDENTIFICATION DIVISION.
18: PROGRAM-ID. EICP.
19: ENVIRONMENT DIVISION.
20: CONFIGURATION SECTION.
21: SOURCE-COMPUTER. UNISYS-2200.
22: OBJECT-COMPUTER. UNISYS-2200.
23: DATA DIVISION.
24: PROCEDURE DIVISION.
25: BEGIN.
26: CALL 'B$INIT'.
27: CALL 'BMICP'.
28: STOP RUN.
29: @acob,i bmicp

Example 6–29. Simple Mixed-Mode Example

7831 4077–009 6–119

Application Programming in an HVTIP Environment

30: IDENTIFICATION DIVISION.

31: PROGRAM-ID. BMICP
32: ENVIRONMENT DIVISION.
33: CONFIGURATION SECTION.
34: SOURCE-COMPUTER. UNIVAC-1100.
35: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
36: SPECIAL-NAMES.
37: PRINTER IS PRINTER.
38: DATA DIVISION.
39: WORKING-STORAGE SECTION.
40: 01 param pic x(5).
41: PROCEDURE DIVISION.
42: begin.
43: move 'PARAM' to param.
44: call 'BMSUB' using param.
45: display 'Back in BMICP from BMSUB call.'
46: upon printer.
47: stop run.
48: @acob,iv bmsub
49: IDENTIFICATION DIVISION.
50: PROGRAM-ID. BMSUB
51: ENVIRONMENT DIVISION.
52: CONFIGURATION SECTION.
53: SOURCE-COMPUTER. UNIVAC-1100.
54: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
55: SPECIAL-NAMES.
56: PRINTER IS PRINTER.
57: DATA DIVISION.
58: LINKAGE SECTION.
59: 01 param pic x(5).
60: PROCEDURE DIVISION using param.
61: begin.
62: display 'In BMSUB, PARAM = ',param
63: upon printer.
64: quit.
65: exit program.
66: @use tiplib,sys$lib$*acob-tiplib
67: @use cb,sys$lib$*acob.
68: @asg,t ctrl.
69: @elt,i ctrl.xfr$mnq
70: @elt,i ctrl.call$mnq
71: dummy$* equ 0 .
72: bmsub* equ 0210022000000 . Lib#=021, Bank#=022
73: C$BBMSUB* equ 0
74: end
75: @eof
76: @add sys$lib$*urts.mixedmodeskl
77: execution environment,mmhvtip ;

Example 6–29. Simple Mixed-Mode Example

6–120 7831 4077–009

 Application Programming in an HVTIP Environment

78: starting_mode,em ;
79: bm_language,acob ;
80: bm_initialbasing,BDR1,C$DML
81: .
82: . Ensure that the offset given BMSTACK below matches the
83: . Dbank address in the Collection of the Basic Mode ICP.
84: .
85: bmstack is lbdi,0400005 offset,040000 length,01000
86: intercept_elt emint contains entrypoint,BMICP ;
87: needing translation,ucob2acob
88: entrypoint BMICP needs calltype,hvtipcall ;
89: hvtarget_lb,021,021 . *** Lib#=021,Bank#=021 ***
90: @eof
91: @eof
92: @add sys$lib$*acob-tiplib.maphvtip
93: hvtip icp,bmicp
94: hvtip subprogram,bmsub
95: control ctrl
96: nocommon
97: cobol lib,cb tipversion,tiplib ;
98: common banked ;
99: cbep$,sys$lib$*acob-dml ;
100: utility,ascii
101: using mixedmode
102: @eof
103: @eof
104: @elt,i tpf$.output-stmt
105: output hvtip2 with env=mixed_mode
106: bm_limits=040000 to 0177777
107: @link,is linkemicp,emicp
108: add tpf$.output-stmt
109: include tpf$.emicp,.b$init,.emint
110: resolve all references using
111: local_defs,sys$lib$*emomrts.,lcn
112: set icp=true
113: delete all definitions except start$
114: @eof
115: @ .
116: @ . >>>>>>
117: @ . >>>>>> Completely release, deregister and delete the
118: @ . >>>>>> HVTIP library before recreating it.
119: @ . >>>>>> Also delete the VALTAB entry we are going to use.
120: @ . >>>>>> Note that this runstream is tailored for a
121: @ . >>>>>> system using shared files.
122: @ . >>>>>>
123: @qual,d shared#
124: @prt,fc qual*hvtiplib17.

Example 6–29. Simple Mixed-Mode Example

7831 4077–009 6–121

Application Programming in an HVTIP Environment

125: @use tip$,std#tip$*tiprun$.

126: @xqt,icx tip$.tpur
127: status,k 17
128: unload,k 17
129: @eof
130: @
131: @xqt,iux tip$.freips
132: rel 87
133: dreg qual*hvtiplib17.
134: @eof
135: @ .
136: @delete,c qual*hvtiplib17.
137: @ . Delete possible old VALTAB entries from previous testing.
138: @ . Since this is a test runstream and re-uses old VALTABs,
139: @ . we must delete all variations that we know about.
140: @ .
141: @xqt,ixmuz tip$.vtbutl
142: *valchg m
143: 615 ACT,JMHHVT DELETE
144: 616 ACT,JMHEP1 DELETE
145: 617 ACT,JMHEP2 DELETE
146: 618 ACT,JMHEP3 DELETE
147: 619 ACT,BMICP DELETE
148: @eof
149: @ . More possible old VALTAB entries from previous testing:
150: @xqt,ixmuz tip$.vtbutl
151: *valchg m
152: 615 ACT,MIXED1 DELETE
153: 616 ACT,MIXED2 DELETE
154: @eof
155: @ .
156: @ . >>>>>> Now install HVTIP library 17
157: @ .
158: @xqt,ixmuz tip$.vtbutl
159: *VALCHG M
160: 615 NAM,EMICP ACT,MIXED1 PRG,5 STF,0 STA,IJ QPR,1 OPT,TVZM
161: 615 REC,Z AUD,9 IND,W PRT,HOLDPR
162: 615 DSLOWER,060000 DSUPPER,0577777
163: 615 BMLOWER,040000 BMUPPER,0177777
164: @eof
165: @xqt,p tip$.boxer
166: off btloading
167: off sticking
168: on recovery
169: off schedule
170: @eof
171: @ . Ensure the VINDEX is updated in main storage.

Example 6–29. Simple Mixed-Mode Example

6–122 7831 4077–009

 Application Programming in an HVTIP Environment

172: @xqt tip$.tpinit

173: @xqt,p tip$.boxer
174: on btloading
175: on sticking
176: @cat,p shared#qual*hvtiplib17.,f/1000//1000
177: @cat,p shared#tipdiag$pf*hvtip21.,f/1000//1000
178: @xqt,iux tip$.freips
179: treg qual*hvtiplib17.,fix
180: res 87,64000,28,,hvtiplib17,ww=p,audit=0,nrec
181: lfd 87
182: @eof
183: @ . >>>>>> Copy the transactions into the HVTIP library.
184: @xqt,p tip$.boxer
185: on recovery
186: off schedule
187: @xqt,imux tip$.tpur
188: create,k 17,30
189: copy,ivk 17,020,tpf$.emicp
190: copy,ik 17,021,tpf$.bmicp
191: copy,ik 17,022,tpf$.bmsub
192: list 17
193: load,k 17
194: status,k 17
195: @eof
196: @xqt,p tip$.boxer
197: fb
198: off recovery
199: on schedule
200: on tiptrace
201: on sticking
202: fb
203: @eof
204: @prt,f qual*hvtiplib17.
205: @qual,r
206: @ . >>>>>> The transaction MIXED1 is ready to use.

Example 6–29. Simple Mixed-Mode Example

7831 4077–009 6–123

Application Programming in an HVTIP Environment

The following screen shows an execution of the MIXED1 HVTIP transaction. User
input is bolded.

>MIXED1

This would produce the following output on print queue HOLDPR:

In BMSUB, PARAM = PARAM

Back in BMICP from BMSUB call.

6.1.8.2. Mixed-Mode Example 2

An extended mode ICP calls a basic mode HVTIP main program that calls an extended
mode HVTIP subprogram, passing a parameter. Both modes also use Common
storage.

1: @ .
2: @ . >>>>>>
3: @ . >>>>>> MIXED-MODE EXAMPLE 2:
4: @ . >>>>>>
5: @ . >>>>>> Use TIP file 87, HVTIP library # 17 with a
6: @ . >>>>>> filename of QUAL*HVTIPLIB17.
7: @ . >>>>>> The EM ICP will be Bank # 020.
8: @ . >>>>>> The BM ICP will be Bank # 021.
9: @ . >>>>>> EM subprogram ESUB will be Bank # 023.
10: @ . >>>>>> Use VALTAB 616 for the transaction, and
11: @ . >>>>>> name the transaction MIXED2.
12: @ . >>>>>> Use Application # 9.
13: @ . >>>>>> Have all print queued to print queue HOLDPR.
14: @ . >>>>>>
15: @ .
16: @asg,t source.
17: @asg,t rel.
18: @ucob,i source.eicp,rel.,,,no-options
19: IDENTIFICATION DIVISION.
20: PROGRAM-ID. EICP.

Example 6–30. Mixed-Mode Example 2

6–124 7831 4077–009

 Application Programming in an HVTIP Environment

21: ENVIRONMENT DIVISION.

22: CONFIGURATION SECTION.
23: SOURCE-COMPUTER. UNISYS-2200.
24: OBJECT-COMPUTER. UNISYS-2200.
25: DATA DIVISION.
26: COMMON-STORAGE SECTION.
27: 01 COMM PIC 9(4).
28: PROCEDURE DIVISION.
29: BEGIN.
30: CALL 'B$INIT'.
31: CALL 'BICP'.
32: STOP RUN.
33: @acob,i source.bicp,rel.
34: IDENTIFICATION DIVISION.
35: PROGRAM-ID. BICP
36: ENVIRONMENT DIVISION.
37: CONFIGURATION SECTION.
38: SOURCE-COMPUTER. UNIVAC-1100.
39: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
40: SPECIAL-NAMES.
41: PRINTER IS PRINTER.
42: DATA DIVISION.
43: WORKING-STORAGE SECTION.
44: 01 param pic x(30).
45: COMMON-STORAGE SECTION.
46: 01 COMM PIC 9(4).
47: PROCEDURE DIVISION.
48: begin.
49: move 'OLD VALUE' to param.
50: move 1234 to comm.
51: call 'ESUB' using param.
52: display 'PARAM=',param,' COMM=',COMM
53: upon printer.
54: stop run.
55: @ucob,i source.esub,rel.,,,subprogram,compat,no-options
56: IDENTIFICATION DIVISION.
57: PROGRAM-ID. ESUB.
58: ENVIRONMENT DIVISION.
59: CONFIGURATION SECTION.
60: SOURCE-COMPUTER. UNIVAC-1100.
61: OBJECT-COMPUTER. UNIVAC-1100.
62: DATA DIVISION.
63: COMMON-STORAGE SECTION.
64: 01 COMM PIC 9(4).
65: LINKAGE SECTION.
66: 01 param pic x(30).
67: PROCEDURE DIVISION using param.

Example 6-30. Mixed-Mode Example 2

7831 4077–009 6–125

Application Programming in an HVTIP Environment

68: begin.
69: move 'NEW VALUE' to param.
70: add 1 to comm.
71: quit.
72: exit program.
73: @use tiplib,sys$lib$*acob-tiplib
74: @use cb,sys$lib$*acob.
75: @asg,t ctrl.
76: @elt,i ctrl.xfr$mnq
77: @elt,i ctrl.call$mnq
78: dummy$* equ 0 .
79: end
80: @eof
81: @use masm$pf,sys$lib$*link
82: @asg,a masm$pf
83: @masm,i source.hvcalls,rel.
84: $obj
85: $INCLUDE 'OM$DEF'
86: $INCLUDE 'HVTIP$CALLS'
87: $INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL'
88: hv$call 021,021,0 'BMICP' . Lib#=021, Bank#=021
89: $end
90: @eof
91: @add sys$lib$*urts.mixedmodeskl
92: files are source,source rel,rel
93: execution environment,mmhvtip ;
94: starting_mode,em ;
95: bm_language,acob ;
96: bm_initialbasing,BDR1,C$DML
97: .
98: . Ensure that the offset given BMSTACK below matches the
99: . Dbank address in the Collection of the Basic Mode ICP.
100: .
101: bmstack is lbdi,0400005 offset,040000 length,01000
102: intercept_elt eint contains entrypoint,BICP ;
103: needing translation,ucob2acob
104: entrypoint BICP needs calltype,hvtipcall ;
105: target_name,BMICP . Access via HVCALLS mechanism
106: intercept_elt bint contains entrypoint,ESUB ;
107: needing translation,acob2ucob
108: . We are not using the TARGET_NAME option for our basic mode to
109: . extended mode HVTIP CALLL. If we did use that option, we would have
110: . to link the EMSHELL/ESUB intercept OM (generated by MIXEDMODESKL)
111: . with the ESUB extended mode subprogram in order to preserve register
112: . X11. (The ACOB runtime code to the ER CALL$ requires that X11 be
113: . preserved across the CALL$ ER.) We would also have to define an

Example 6-30. Mixed-Mode Example 2

6–126 7831 4077–009

 Application Programming in an HVTIP Environment

114: . ESUB alias in the CALL$MNQ element to reference from TARGET_NAME.

115: entrypoint ESUB needs calltype,hvtipcall ;
116: hvtarget_lb,021,023
117:
118: @eof
119: @eof
120: @add sys$lib$*acob-tiplib.maphvtip
121: rel rel
122: abs rel
123: hvtip icp,bicp
124: local to,bicp masm,bint
125: control ctrl
126: cobol lib,cb tipversion,tiplib ;
127: common banked ;
128: cbep$,sys$lib$*acob-dml ;
129: utility,ascii
130: using mixedmode
131: @eof
132: @eof
133: @elt,i source.output-stmt
134: output hvtip2 with env=mixed_mode
135: bm_limits=040000 to 0177777
136: conceal messages 613 . Inhibit 'SIZE' warnings
137:
138: @elt,i source.common-stmt
139: . Ensure EM alignment and size match BM for Blank Common:
140:
141: SET ALIGNMENT = 0 FOR $BLANK$COMMON$
142: SET SIZE = SIZE - 1 FOR $BLANK$COMMON$
143:
144: . Offset for next statement is obtained by examining the
145: . MAP listing of the collection of BICP. The offset should
146: . be set to the BICP DBANK starting offset plus the offset
147: . of Blank Common (BLANK$COMMON in Basic Mode) in its RSEG:
148:
149: SET LOWADR=0400005041000 FOR $BLANK$COMMON$
150:
151: @link,i source.linkeicp,rel.eicp
152: add source.output-stmt
153: include rel.eicp,.b$init,.eint,.hvcalls
154: resolve all references using
155: local_defs,sys$lib$*emomrts.,lcn
156: set icp=true
157: add source.common-stmt
158: delete all definitions except start$
159: @eof
160: @link,i source.linkesub,rel.esub
161: add source.output-stmt

Example 6-30. Mixed-Mode Example 2

7831 4077–009 6–127

Application Programming in an HVTIP Environment

162: include rel.esub

163: resolve all references using
164: local_defs,sys$lib$*emomrts.,lcn
165: add source.common-stmt
166: delete all definitions except esub
167: @eof
168: @ .
169: @ . >>>>>>
170: @ . >>>>>> Completely release, deregister and delete the
171: @ . >>>>>> HVTIP library before recreating it.
172: @ . >>>>>> Also delete the VALTAB entry we are going to use.
173: @ . >>>>>> Note that this runstream is tailored for a system
174: @ . >>>>>> using shared files.
175: @ . >>>>>>
176: @ . TPUR can't seem to find the HVTIP ZOOMs/absolutes
177: @ . in temp file REL after the @QUAL,D below, so put
178: @ . them in tpf$.:
179: @copy,a rel.eicp
180: @copy,a rel.bicp
181: @copy,a rel.esub
182: @qual,d shared#
183: @prt,fc qual*hvtiplib17.
184: @use tip$,std#tip$*tiprun$.
185: @xqt,icx tip$.tpur
186: status,k 17
187: unload,k 17
188: @eof
189: @ .
190: @xqt,iux tip$.freips
191: rel 87
192: dreg qual*hvtiplib17.
193: @eof
194: @ .
195: @delete,c qual*hvtiplib17.
196: @ . Delete possible old VALTAB entries from previous testing.
197: @ . Since this is a test runstream and re-uses old VALTABs,
198: @ . we must delete all variations that we know about.
199: @ .
200: @xqt,ixmuz tip$.vtbutl
201: *valchg m
202: 615 ACT,JMHHVT DELETE
203: 616 ACT,JMHEP1 DELETE
204: 617 ACT,JMHEP2 DELETE
205: 618 ACT,JMHEP3 DELETE
206: 619 ACT,BMICP DELETE
207: @eof
208: @ . More possible old VALTAB entries from previous testing:

Example 6-30. Mixed-Mode Example 2

6–128 7831 4077–009

 Application Programming in an HVTIP Environment

209: @xqt,ixmuz tip$.vtbutl

210: *valchg m
211: 615 ACT,MIXED1 DELETE
212: 616 ACT,MIXED2 DELETE
213: @eof
214: @ .
215: @ . >>>>>> Now install HVTIP library 17
216: @ .
217: @xqt,ixmuz tip$.vtbutl
218: *VALCHG M
219: 616 NAM,EICP ACT,MIXED2 PRG,5 STF,0 STA,IJ QPR,1 OPT,TVZM
220: 616 REC,Z AUD,9 IND,W PRT,HOLDPR
221: 616 DSLOWER,060000 DSUPPER,0577777
222: 616 BMLOWER,040000 BMUPPER,0177777
223: @eof
224: @xqt,p tip$.boxer
225: off btloading
226: off sticking
227: on recovery
228: off schedule
229: @eof
230: @ . Ensure the VINDEX is updated in main storage.
231: @xqt tip$.tpinit
232: @xqt,p tip$.boxer
233: on btloading
234: on sticking
235: @cat,p shared#qual*hvtiplib17.,f/1000//1000
236: @cat,p shared#tipdiag$pf*hvtip21.,f/1000//1000
237: @xqt,iux tip$.freips
238: treg qual*hvtiplib17.,fix
239: res 87,64000,28,,hvtiplib17,ww=p,audit=0,nrec
240: lfd 87
241: @eof
242: @ . >>>>>> Copy the transactions into the HVTIP library.
243: @xqt,p tip$.boxer
244: on recovery
245: off schedule
246: @xqt,imux tip$.tpur
247: create,k 17,30
248: copy,ivk 17,020,tpf$.eicp
249: copy,ik 17,021,tpf$.bicp
250: copy,ik 17,023,tpf$.esub
251: list 17
252: load,k 17
253: status,k 17
254: @eof
255: @xqt,p tip$.boxer

Example 6-30. Mixed-Mode Example 2

7831 4077–009 6–129

Application Programming in an HVTIP Environment

256: fb
257: off recovery
258: on schedule
259: on tiptrace
260: on sticking
261: fb
262: @eof
263: @prt,f qual*hvtiplib17.
264: @qual,r
265: @ . >>>>>> The transaction MIXED2 is ready to use.

Example 6-30. Mixed Mode Example 2

The following screen shows an execution of the MIXED2 HVTIP transaction. User
input is bolded.

>MIXED2

This produces the following output on print queue HOLDPR:

PARAM=NEW VALUE COMM=1235

6.1.8.3. Mixed-Mode Example 3

This is an extensive example with many mode switches. Parameters are passed
between modes and Common is shared between modes. An ACOB-based AFCB is
called from both modes and an FLSS extended mode fixed-gate subsystem is called
from both modes. (An FLSS subsystem has local data that is loaded into heaps for
each execution thread by the same loader that loads local data for extended mode
HVTIP ZOOMs.) In addition, the extended mode subsystem calls the basic mode AFCB
and the basic mode AFCB calls the extended mode subsystem. Each procedure called
prints out its name and an entry count to help follow the flow.
Five separate transactions are defined that all use the same HVTIP ZOOMs and
absolutes:
• BMICP : Basic Mode only.
• JMHHVT: Extended Mode only.
• JMHEP1: Mixed-Mode. This one does HVTIP Transfers as well as CALLs.
• JMHEP2: Mixed-Mode. This one experiences a TIP RESTART on every other
execution. It also exits from the basic mode ICP without detaching from MCB, so
MCB does an ERR$ at the end.
• JMHEP3: Mixed-Mode.

The same extended mode ICP is used for the last four transactions. The basic mode
ICP for the first transaction is also called (or Transferred-to) from the mixed-mode
transactions. This shows that there is some flexibility available when you are laying-
out the functionality and flow of your transactions.

6–130 7831 4077–009

 Application Programming in an HVTIP Environment

There are four separate runstreams for this example, roughly divided by function.

The first runstream (Example 6–31)

• Shows the SOLAR$SGS input to install a product that defines the AFCB and
subsystem. The SOLAR INSTALL is not shown.
• Does the MIXEDMODESKL intercept-generation.
• Processes the subsystem’s SSDEF with SSDP, generating an SSDEF absolute and
FLSS intercepts for the subsystem.
• Does the compilations, links, and collections of the code for the basic mode AFCB
and the extended mode subsystem.

The second runstream (Example 6–32) compiles the ACOB programs needed for the
ACOB HVTIP absolutes and creates the ACOB HVTIP absolutes using the MAPHVTIP
runstream in the ACOB TIP library file, SYS$LIB$*ACOB-TIPLIB.

The third runstream (Example 6–33) compiles and links the UCOB HVTIP ZOOMs.
Several D-banks beyond the standard BDIs 5 and 6 are defined in the OUTPUT HVTIP2
link statements to show the greatly increased data capabilities of HVTIP-II. The source
for the PROC element MCBPKT/UCOB is not shown. It is a copy of the MCB COBOL
PROC element in SYS$LIB$*PROC$.MCBDEF-UCOB.

The fourth runstream (Example 6–34) installs the new HVTIP ZOOMs and absolutes in
the appropriate HVTIP library file. The HVTIP library is first completely released,
deregistered, and deleted in case it had been in use for something else (other tests).
The VALTAB entries supply bank limits for the mixed-mode and extended mode
transactions, and all print is queued to the HOLDPR print queue for all five
transactions.

7831 4077–009 6–131

Application Programming in an HVTIP Environment

1: @ .
2: @ . >>>>>> The SOLAR SGSs used to install product MTEST, which defines
3: @ . >>>>>> an Extended Mode fixed-gate subsystem and one Basic Mode
4: @ . >>>>>> AFCB. This product was installed earlier using SOLAR and
5: @ . >>>>>> this SOLAR$SGS element. Note that this runstream had to
6: @ . >>>>>> be executed first since it sets up the files needed by
7: @ . >>>>>> these SGSs.
8: @ .
9: @ELT,I SOLAR$SGS
10: . ******************************************************************
11: . * *
12: . * PRODUCT : MTEST Element Name : SOLAR$SGS *
13: . * *
14: . * FUNCTION : Provide product descriptor SGS's for SOLAR load. *
15: . * *
16: . * USED BY : SOLAR PRODLD *
17: . * *
18: . ******************************************************************
19: .
20: PRODUCT ;
21: NAME,MTEST ;
22: LEVEL,1R1 ;
23: MODE,A
24: .
25: DEFAULT_MODE A
26: .
27: FILE ;
28: MODE,A ;
29: SOURCE,JMH*AFCB2 ;
30: DEST,JMH*AFCB2 ;
31: ATTRIBUTES,PACK,PREP,FIXED_NAME
32: .
33: FILE ;
34: MODE,A ;
35: SOURCE,JMH*FGSS ;
36: DEST,JMH*FGSS ;
37: ATTRIBUTES,PACK,PREP,FIXED_NAME
38: .
39: .
40: SHARED_SUBSYSTEM ;
41: MODE,A ;
42: FILE,JMH*FGSS ;
43: FIXED_GATE,SSDEF$,0203370 . An FGSS SSDEF
44: .
45: AFCB ;
46: MODE,A ;

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

6–132 7831 4077–009

 Application Programming in an HVTIP Environment

47: FILE,JMH*AFCB2 ;
48: BANK,0403372,AFCB2,AFCB2,D,W . An ACOB BM AFCB
49: @eof
50: @ .
51: @ . >>>>>> Create intercepts for mixed-mode operation using MIXEDMODESKL.
52: @ .
53: @ . >>>>>> - EMINT is an Extended Mode object module, and is used to
54: @ . >>>>>> interface from Extended Mode HVTIP ZOOMs to Basic Mode
55: @ . >>>>>> HVTIP ZOOMs and a Basic Mode AFCB.
56: @ . >>>>>> - EMINT2 is an Extended Mode object module used to access one
57: @ . >>>>>> entry point of an Extended Mode FGSS. Could have used an
58: @ . >>>>>> intercept generated by SSDP, but do it this way to
59: @ . >>>>>> show that it can be done this way for gated entry points.
60: @ . >>>>>> - BMINT is a Basic Mode relocatable, and interfaces
61: @ . >>>>>> from Basic Mode HVTIP ZOOMs to Extended Mode HVTIP ZOOMs
62: @ . >>>>>> and to an Extended Mode fixed-gate subsystem.
63: @ .
64: @add sys$lib$*urts.mixedmodeskl
65: execution environment,MMHVTIP ;
66: starting_mode,em ;
67: bm_language,acob ;
68: bm_initialbasing,utilityi,c$dml . Get C$DML on UI BDR
69: .
70: . Ensure that the offset given BMSTACK below matches the
71: . Dbank address in the Collection of the Basic Mode ICP.
72: .
73: bmstack is lbdi,0400005 offset,040000 length,01000
74:
75: intercept_elt EMINT contains ;
76: entrypoint,BMICP,BMSUB,BMSUB2,BMSUB2XFR,;
77: AFCB1,AFCB22,AFCB3 ;
78: needing translation,ucob2acob
79: entrypoint BMICP needs calltype,hvtipxfr ; . Note: HVTIPXFR
80: hvtarget_lb,021,013
81: entrypoint BMSUB needs calltype,hvtipcall ;
82: hvtarget_lb,021,014
83:
84: . BMSUB2 can be entered either by an HVTIP CALL or TRANSFER:
85:
86: entrypoint BMSUB2 needs calltype,hvtipcall ;
87: hvtarget_lb,021,015
88: entrypoint BMSUB2XFR needs calltype,hvtipxfr ;
89: hvtarget_lb,021,015
90: entrypoint AFCB1 needs calltype,normal ;
91: target_va,0203372001000 ;
92: dbank,acob
93: entrypoint AFCB22 needs calltype,normal ;

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

7831 4077–009 6–133

Application Programming in an HVTIP Environment

94: target_va,0203372001001 ;
95: dbank,acob
96: entrypoint AFCB3 needs calltype,normal ;
97: target_va,0203372001002 ;
98: dbank,acob
99: intercept_elt EMINT2 contains entrypoint,SSEP2_CALLER ;
100: needing translation,em2em . Q&D CBEP!
101: entrypoint SSEP2_CALLER needs calltype,normal ;
102: target_va,0203370001140 . Needs EM form!
103:
104: intercept_elt BMINT contains ;
105: entrypoint,SSEP1,SSEP2,MCBSUBA,MCBSUBX, ;
106: MCBSUBB,SSEP3,MCBSUBXCL ;
107: needing translation,acob2ucob
108: entrypoint SSEP1 needs calltype,normal ;
109: target_va,0403370001100 . BM form of SSEP1_CALLER
110: entrypoint SSEP2 needs calltype,normal ;
111: target_va,0403370001140 ; . BM form of SSEP2_CALLER
112:
113: parmcount,2 ;
114: param,1,TYPE,char,BYTESIZE,80 ;
115: param,2,TYPE,char,BYTESIZE,40
116: entrypoint SSEP3 needs calltype,normal ;
117: target_va,0403370001200 . BM form of SSEP3_CALLER
118:
119: entrypoint MCBSUBA needs calltype,hvtipcall ;
120: hvtarget_lb,021,012
121: entrypoint MCBSUBB needs calltype,hvtipcall ;
122: hvtarget_lb,021,016
123:
124: . Subprogram MCBSUBX also can be entered either by an
125: . HVTIP CALL or TRANSFER:
126:
127: entrypoint MCBSUBX needs calltype,hvtipxfr ;
128: hvtarget_lb,021,07 . Terminates MCB & TRANSFERs to BMSUB2
129: entrypoint MCBSUBXCL needs calltype,hvtipcall ;
130: hvtarget_lb,021,07 . Terminates MCB & does a STOP RUN
131:
132: @eof
133: @copy,rs bmint,jmh*acobtests2. . for MAP
134: @copy,rs bmstack,jmh*acobtests2. . for MAP
135: @copy,rs r$init,jmh*acobtests2. . for MAP
136: @copy,as emint,jmh*ucstst2. . for LINK
137: @copy,as emint2,jmh*ucstst2. . for LINK
138: @copy,as b$init,jmh*ucstst2. . for LINK
139: @pack,p jmh*ucstst2.
140: @ .

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

6–134 7831 4077–009

 Application Programming in an HVTIP Environment

141: @ .
142: @ . >>>>>>> Now create the ACOB AFCB. There are 3 subprograms, a
143: @ . >>>>>>> MASM jump vector, and we use the BMINT intercept from
144: @ . >>>>>>> MIXEDMODESKL to access an Extended Mode Fixed Gate
145: @ . >>>>>>> subsystem.
146: @ .
147: @hdg make acob afcb with 3 subprograms: AFCB1, AFCB22, AFCB3
148: @acob,iv jmh*acobtests2.AFCB1
149: IDENTIFICATION DIVISION.
150: PROGRAM-ID. AFCB1
151: ENVIRONMENT DIVISION.
152: CONFIGURATION SECTION.
153: SOURCE-COMPUTER. UNIVAC-1100.
154: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
155: SPECIAL-NAMES.
156: PRINTER IS PRINTER.
157: DATA DIVISION.
158: working-storage section.
159: 01 oparm40 pic x(40).
160: 01 oparm80 pic x(80).
161: 01 p4 pic x(4).
162: 01 mydepth pic 9999 value zero.
163: LINKAGE SECTION.
164: 01 parm80 pic x(80).
165: PROCEDURE DIVISION using parm80.
166: begin.
167: compute mydepth = mydepth + 1.
168: display ' BM AFCB1 Entry # ' mydepth upon printer.
169:
170: * Call EM AFCB SSEP2 if EM called us.
171: * ('SSEP' will be at beginning of our parameter.)
172:
173: move parm80 to p4.
174: if p4 is not equal to 'SSEP' go to skip-em-call.
175: move 'AFCB1 calling you, Mr. EM AFCB!!' to oparm80.
176: move 'Arg#2 ' to oparm40.
177: call 'SSEP2' using oparm80 oparm40.
178: skip-em-call.
179: move 'AFCB1 got your message!!!!!' to parm80.
180: quit.
181: exit program.
182: @eof
183: @acob,iv jmh*acobtests2.AFCB22
184: IDENTIFICATION DIVISION.
185: PROGRAM-ID. AFCB22
186: ENVIRONMENT DIVISION.
187: CONFIGURATION SECTION.

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

7831 4077–009 6–135

Application Programming in an HVTIP Environment

188: SOURCE-COMPUTER. UNIVAC-1100.

189: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
190: SPECIAL-NAMES.
191: PRINTER IS PRINTER.
192: DATA DIVISION.
193: working-storage section.
194: 01 parm40 pic x(40).
195: 01 mydepth pic 9999 value zero.
196: LINKAGE SECTION.
197: 01 parm80 pic x(80).
198: PROCEDURE DIVISION using parm80.
199: begin.
200: compute mydepth = mydepth + 1.
201: display ' BM AFCB22 Entry # ' mydepth upon printer.
202:
203: move 'AFCB22 ate your message...' to parm80.
204: exit program.
205: @eof
206: @acob,iv jmh*acobtests2.AFCB3
207: IDENTIFICATION DIVISION.
208: PROGRAM-ID. AFCB3
209: ENVIRONMENT DIVISION.
210: CONFIGURATION SECTION.
211: SOURCE-COMPUTER. UNIVAC-1100.
212: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
213: SPECIAL-NAMES.
214: PRINTER IS PRINTER.
215: DATA DIVISION.
216: working-storage section.
217: 01 parm40 pic x(40).
218: 01 mydepth pic 9999 value zero.
219: LINKAGE SECTION.
220: 01 pflag pic s1(36) usage binary-1.
221: 01 who2 pic x(2).
222: PROCEDURE DIVISION using pflag who2.
223: begin.
224: compute mydepth = mydepth + 1.
225: if pflag is equal to 0 go to no-prints.
226: display 'In BM AFCB3: Entry # ' mydepth ' PARAM = '
227: who2 upon printer.
228: no-prints.
229:
230: exit program.
231: @eof
232: @ .
233: @ . We need a MASM jump-vector at the head of our AFCB so that
234: @ . we can easily define their common-bank CBEP values in the

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

6–136 7831 4077–009

 Application Programming in an HVTIP Environment

235: @ . AFCB-CBEP MASM element.

236: @ .
237: @masm,i jmh*acobtests2.afcb2-jv
238: AXR$
239: $(1) . BM AFCB jump vector
240: afcb2jv* j afcb1 . EP AFCB1 01000
241: afcb2jv2* j afcb22 . EP AFCB22 01001
242: afcb3jv* j afcb3 . EP AFCB3 01002
243: nop 0
244: nop 0
245: nop 0
246: $END
247: @eof
248: @masm,i jmh*acobtests2.afcb-cbep
249: .
250: . A CBEP Relocatable to access the AFCB from Basic Mode HVTIP programs.
251: .
252: afcb1* $EQU 0403372001000
253: afcb22* $EQU 0403372001001
254: afcb3* $EQU 0403372001002
255: $END
256: @eof
257: @pack,p jmh*acobtests2.
258: @map,fis jmh*acobtests2.afcb2
259: not tpf$.
260: ibank,dm afcb2,01000
261: frstin jmh*acobtests2.afcb2-jv . Jump Vector
262: in jmh*acobtests2.AFCB1,.AFCB22,.AFCB3
263: in jmh*acobtests2.bmint . To access EM FGSS EPs SSEP1/..2/..3
264: ent afcb2jv
265: @eof
266: @ . Put the AFCB absolute into the system installation file.
267: @chg,z jmh*afcb2.
268: @copy,a jmh*acobtests2.afcb2,jmh*afcb2.
269: @pack jmh*afcb2.
270: @prt,tb jmh*acobtests2.
271: @PRIV
272: @SYS$LIB$*COMUS.RELOAD 0403372
273: @PRIV OFF
274: @ .
275: @ . >>>>>> Now create the Fixed Gate Subsystem OMs. This is a
276: @ . >>>>>> fast-load self-contained subsystem (FLSS). It has
277: @ . >>>>>> local (program and/or activity-level) data. One OM
278: @ . >>>>>> is used as a Basic Mode access to the code. It has
279: @ . >>>>>> all its banks at application level, and has gated
280: @ . >>>>>> entry points. It uses the /NODB SSDP intercepts to
281: @ . >>>>>> access the code in the other FLSS OM. The subsystem

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

7831 4077–009 6–137

Application Programming in an HVTIP Environment

282: @ . >>>>>> code is Fortran, and is compiled with the MIN-DBANK

283: @ . >>>>>> keyword option to put most local data on the ALS.
284: @ . >>>>>> Extended Mode callers can call entry points in either
285: @ . >>>>>> FLSS OM.
286: @ . >>>>>>
287: @uftn,i jmh*ucstst2.om1,,,,min-dbank,no-options
288: subroutine ssep1
289: integer ents/0/ @ A #entries count (the initial value
290: @ also forces ENTS to be in static storage)
291:
292: ents = ents + 1
293: print *,'EM SSEP1 Entry # ',ents
294: end
295:
296: subroutine ssep2(c80,c40)
297: character*80 c80,c40*(*),p80*80
298: integer ents/0/ @ A #entries count (the initial value
299: @ also forces ENTS to be static)
300:
301: ents = ents + 1
302: print *,'EM SSEP2 Entry # ',ents
303:
304: if (c80(1:2) .eq. 'BM') then
305: p80 = 'SSEP2 calling!!!!'
306: c Note: AFCB1 may call us recursively!
307: call AFCB1(p80)
308: endif
309:
310: c80 = 'Hello from SSEP2!'
311: c40 = 'xxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXXXXXXXXXX'
312: end
313:
314: subroutine ssep3(pflag,who)
315: logical pflag
316: character*2 who
317: integer ents/0/ @ A #entries count (the initial value
318: @ also forces ENTS to be static)
319:
320: ents = ents + 1
321: if(pflag) then
322: print *,'In SSEP3 EM FGSS subroutine. Entry # ', ents,
323: 1 ' WHO arg is: ',who
324: endif
325:
326: if (who.eq.'BM') then
327: elseif(who.eq.'EM') then
328: else

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

6–138 7831 4077–009

 Application Programming in an HVTIP Environment

329: print *,'SSEP3: unknown WHO parameter: ',who

330: endif
331:
332: end
333: @uftn,i jmh*ucstst2.om2,,,,min-dbank,no-options
334:
335: * We have gated EPs into our FLSS. We access the ungated
336: * EPs via ../NODB intercepts, thereby allowing our callers
337: * to be BM code that does NOT have access to RB-form FLSS
338: * intercepts.
339: * You ..MUST.. compile this Fortran with the MIN-DBANK option,
340: * so that we do not store into local static data when
341: * passing-on our parameters.
342: *
343: * CHARACTER*(*) args are a bit suspect as the size default
344: * is 4 characters. However, PARAM,TYPE,CHAR,80 (and 40)
345: * clauses were used for the SSEP2_CALLER entry point in
346: * MIXEDMODESKEL so that the correct sizes will be passed to
347: * this code from the intercepts at runtime.
348:
349: subroutine ssep1_caller
350: print *,'Calling EM SSEP1 from EM SSEP1_CALLER:'
351: call ssep1
352: end
353:
354: subroutine ssep2_caller(c80,c40)
355: character*80 c80,c40*(*)
356: print *,'Calling EM SSEP2 from EM SSEP2_CALLER:'
357: call ssep2(c80,c40)
358: end
359:
360: subroutine ssep3_caller(pflag,who)
361: logical pflag
362: character*2 who
363: if(pflag) print *,'Calling EM SSEP3 from EM SSEP3_CALLER:'
364:
365: call ssep3(pflag,who)
366: end
367: @ssdp,ie jmh*ucstst2.ssdef$,jmh*ucstst2.ssdef$,;
368: jmh*ucstst2.,jmh*ucstst2.,jmh*ucstst2.
369: fixed bdi is 03370
370: subsystem type is chameleon fast_load self_contained
371: define lsc $LOCAL
372: search JMH*FGSS.
373: .
374: debug level is full
375: .

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

7831 4077–009 6–139

Application Programming in an HVTIP Environment

376: share heap banks with other subsystems including hvtip

377: .
378: . The first FLSS OM has local data, and 3 externally-visible
379: . entry points:
380: .
381: intercept routine using gate_offset 01000 is ssint1
382: external entry points are SSEP1,SSEP2,SSEP3
383: .
384: . The second FLSS OM is really an access to SSEP1,SSEP2, and SSEP3.
385: . The entry points here are all at application level and are
386: . directly gated and so are easily called from Basic Mode code:
387: .
388: intercept routine using gate_offset 01040 is ssint2
389: external entry points are ssep1_caller=01100,ssep2_caller=01140,
390: ssep3_caller=01200
391:
392: @eof
393: @ .
394: @ . >>>>>> Now static link the FLSS OMs, DEACT the subsystem, and
395: @ . >>>>>> copy the new subsystem OMs to the installation file.
396: @ .
397: @link,ie jmh*ucstst2.ssom1
398: include jmh*ucstst2.om1
399: include jmh*ucstst2.ssint1/ssom
400: include jmh*ucstst2.emint . AFCB1 and AFCB22 ACOB AFCB EP Defns
401:
402: OUTPUT FAST_LOAD SELF_CONTAINED
403: resolve all references using local_defs,lcn
404: set lowadr = 0400007060100 for FLSS$$DSEG . keep away from BDI 5!!
405: . If we 'share' heaps with hvtip, DO NOT let our DSEGS get into
406: . BDI 5!! It won't work on Mixed-Mode transactions, since BDI 5
407: . is reserved for blank common and Basic Mode RSEGs.
408: delete all definitions in sys$lib$*emomrts.cbep$nperts
409: @ .
410: @link,ie jmh*ucstst2.ssom2
411: include jmh*ucstst2.om2
412: include jmh*ucstst2.ssint2/ssom,.ssint1/nodb . Need access to OM1
413: OUTPUT FAST_LOAD SELF_CONTAINED
414: resolve all references using local_defs,lcn
415:
416: set locality=program for all banks
417: set locality=application for all banks in jmh*ucstst2.om2
418: set lowadr=0400007071000 for FLSS$$DSEG
419: . Don't use BDI 5 for our segments if we can be called by
420: . Mixed-Mode transactions and share heaps with HVTIP.
421: delete all definitions in sys$lib$*emomrts.cbep$nperts
422: @pack,p jmh*ucstst2.

Example 6–31. MIXEDMODESKL, and Creating the AFCB and FGSS

6–140 7831 4077–009

 Application Programming in an HVTIP Environment

423: @prt,tb jmh*ucstst2.

424: @chg,z jmh*fgss.
425: @sys$lib$*solar.deact jmh*fgss.ssdef$
426: @copy,a jmh*ucstst2.ssdef$,jmh*fgss.
427: @copy,a jmh*ucstst2.ssom1,jmh*fgss.ssom1
428: @copy,a jmh*ucstst2.ssom2,jmh*fgss.ssom2
429: @pack,p jmh*fgss.

Example 6-31. MIXEDMODESKL, and Creating the AFCB and FGSS

1: @ .
2: @ . >>>>>> Now we compile the ACOB programs that make-up the ACOB
3: @ . >>>>>> HVTIP basic mode absolutes for our transactions.
4: @ . >>>>>> We also setup the XFR$MNQ and CALL$MNQ MASM elements
5: @ . >>>>>> that supply the HVTIP library # and bank # for the
6: @ . >>>>>> various entry points.
7: @ . >>>>>> Finally, we collect the HVTIP absolutes using the ACOB
8: @ . >>>>>> MAPHVTIP @add stream.
9: @ .
10: @ . Our ACOB HVTIP absolutes need the MIXEDMODESKL intercepts, and
11: @ . the ACOB AFCB subprogram dbanks for Mapping.....
12: @ .
13: @use tiplib,sys$lib$*acob-tiplib
14: @use cb,sys$lib$*acob. . Common-banked library
15: @asg,t ctrl,///9999
16: @elt,il ctrl.xfr$mnq
17: d$dummy2* EQU 0 .
18: bmsub2xfr* equ 0210015000000 . bank 015, TRANSFER (with CANCEL) EP
19: c$bbmsub2xfr* equ 0 .
20: END
21: @eof
22: @elt,il ctrl.call$mnq
23: d$dummy* EQU 0 .
24: .
25: BMSUB* EQU 0210014000000 . Lib# 021 (17), Bank# 014
26: C$BBMSUB* EQU 0 .
27: .
28: bmsub2* equ 0210015000000 . bank 015, CALL ep to use
29: c$bbmsub2* equ 0 .
30: END .
31: @eof
32: @acob,i jmh*acobtests2.bmicp
33: IDENTIFICATION DIVISION.
34: PROGRAM-ID. BMICP
35: ENVIRONMENT DIVISION.

Example 6–32. Creating the ACOB HVTIP Absolutes

7831 4077–009 6–141

Application Programming in an HVTIP Environment

37: SOURCE-COMPUTER. UNIVAC-1100.

38: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
39: SPECIAL-NAMES.
40: PRINTER IS PRINTER.
41: DATA DIVISION.
42: * If we statically initialize COMMON at all, it wipes-out
43: * anything that EM put there!!!!
44: COMMON-STORAGE SECTION.
45: 01 common-field-1 pic x(6).
46: 01 com80 pic x(80).
47: 01 comwho pic x(8).
48: 01 bmflag pic 9.
49: 01 restart pic x(7).
50: 01 stopit pic x(6).
51: 01 active-flag pic x(6).
52: 01 terminate-mcb pic 9.
53:
54: WORKING-STORAGE SECTION.
55: 01 parm80 pic x(80).
56: 01 parm40 pic x(40).
57: 01 tran3 pic x(3).
58: 01 mydepth pic 9999 value zero.
59: 01 zeroz pic s9(12) comp value 0.
60: 01 onez pic s9(12) comp value 1.
61: PROCEDURE DIVISION.
62: begin.
63:
64: * COMMON-FIELD-1 got the transaction code (if called from EM).
65: * All our EM transaction codes start with JMH:
66:
67: move 0 to bmflag.
68: move common-field-1 to tran3.
69: if common-field-1 is not equal to 'JMHEP2' or restart is
70: equal to 'RESTART' go to skip-restart-attempt.
71:
72: * EM transaction JMHEP2, and it is NOT a TIP RESTART.
73: * Attempt to cause a RESTART by doing no prints, setting
74: * the STOPIT code in COMMON to 'STOPIT', and calling an EM
75: * subprogram to do the STOP. Do a FEW extra things to show
76: * that RESTART is not easily inhibited.
77:
78: call 'R$INIT'.
79:
80: * Call an EM subsystem subprogram to show we can do it
81: * (if mixed-mode).
82: * Arg #1 is a print flag
83: * Arg #2 (Character*2) is a 'who called' indicator.

Example 6–32. Creating the ACOB HVTIP Absolutes

6–142 7831 4077–009

 Application Programming in an HVTIP Environment

84:
85: if tran3 is equal to 'JMH'
86: call 'SSEP3' using 0 'BM'.
87:
88: * Call a BM AFCB subprogram to show we can do it (if mixed-mode).
89: * Arg #1 is a print flag
90: * Arg #2 (Character*2) is a 'who called' indicator.
91:
92: if tran3 is equal to 'JMH'
93: call 'AFCB3' using 0 'BM'.
94:
95: move 'BMICP' to comwho.
96: move 'STOPIT' to stopit.
97: move 1 to terminate-mcb.
98:
99: call 'MCBSUBX'.
100: display '?!?!? EM subprog Returned to us ?!?!?'
101: upon printer.
102: STOP RUN.
103:
104: skip-restart-attempt.
105: display '*********!!NOW IN THE BASIC MODE ICP!!************'
106: upon printer.
107: display ' COMMON-FIELD-1 is: ' common-field-1
108: upon printer.
109: display ' COM80 is: ' com80 upon printer.
110: display ' COMWHO is: ' comwho upon printer.
111:
112: move zeroz to bmflag.
113: if tran3 is equal to 'JMH'
114: go to em-tag.
115: display 'This is a BM-only transaction' upon printer.
116:
117: move onez to bmflag.
118: go to bm-tag.
119:
120: em-tag.
121: display 'Calling R$INIT from BMICP:' upon printer.
122: call 'R$INIT'.
123: call 'SSEP3' using 1 'BM'.
124:
125: bm-tag.
126: call 'AFCB3' using 1 'BM'.
127:
128: move 'Calling from BMICP' to parm80.
129: call 'AFCB1' using parm80.
130:

Example 6–32. Creating the ACOB HVTIP Absolutes

7831 4077–009 6–143

Application Programming in an HVTIP Environment

131: move 'BMCIP data!!' to com80.

132: move 'BMICP' to comwho.
133: move 'CALL1' to parm80..
134: display 'Calling BMSUB' upon printer.
135: call 'BMSUB' using parm80.
136: move 'Calling from BMICP' to parm80.
137: call 'AFCB22' using parm80.
138:
139: if bmflag is equal to 0
140: go to mixed-mode.
141: display ' ' upon printer.
142: display '***********************' upon printer.
143: display '**BMICP signing-off!!**' upon printer.
144: display '***********************' upon printer.
145: STOP RUN.
146: mixed-mode.
147: move 'BMICP' to comwho.
148: call 'SSEP1'.
149: display 'BMICP now calling EM transaction MCBSUBA'
150: upon printer.
151: call 'MCBSUBA'.
152: move 'BMICP' to comwho.
153: * Transaction code JMHEP1 signals to do TRANSFERS to BMSUB2
154: * from EM, and so BMSUB2 then does STOP RUN. So, don't CALL
155: * BMSUB2 on a tran code of JMHEP1. (It is also CALLable..)
156: if common-field-1 is equal to 'JMHEP1'
157: go to skip-call.
158: call 'BMSUB2'.
159: skip-call.
160:
161: if common-field-1 is not equal to 'JMHEP1'
162: go to skip-transfer.
163: display 'BMICP now TRANSFERing to EM MCBSUBX, bye....'
164: upon printer.
165: call 'MCBSUBX'.
166: skip-transfer.
167: * JMHEP3: We get a chain of calls going, and STOP RUN
168: * at the end.
169:
170: if common-field-1 is equal to 'JMHEP3'
171: display 'BMICP now starting-off a chain of calls'
172: upon printer
173: move 'CALLxM' to stopit
174: call 'MCBSUBA'
175: display '!!Oh-Oh, BMICP was Return-ed to!!'
176: upon printer.
177:

Example 6–32. Creating the ACOB HVTIP Absolutes

6–144 7831 4077–009

 Application Programming in an HVTIP Environment

178: display '**********************************' upon printer.

179: display '**BMICP doing a STOP RUN now....**' upon printer.
180: display '**********************************' upon printer.
181: stop run.
182: @acob,iv jmh*acobtests2.bmsub . BMSUB can be called
183: IDENTIFICATION DIVISION.
184: PROGRAM-ID. BMSUB
185: ENVIRONMENT DIVISION.
186: CONFIGURATION SECTION.
187: SOURCE-COMPUTER. UNIVAC-1100.
188: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
189: SPECIAL-NAMES.
190: PRINTER IS PRINTER.
191: DATA DIVISION.
192: COMMON-STORAGE SECTION.
193: 01 common-field-1 pic x(6).
194: 01 com80 pic x(80).
195: 01 comwho pic x(8).
196: 01 bmflag pic 9.
197:
198: 01 restart pic x(7).
199: 01 stopit pic x(6).
200: 01 active-flag pic x(6).
201: 01 terminate-mcb pic 9.
202:
203: working-storage section.
204: 01 parm40 pic x(40).
205: 01 mydepth pic 9999 value zero.
206: LINKAGE SECTION.
207: 01 parm80 pic x(80).
208: PROCEDURE DIVISION using parm80.
209: begin.
210: compute mydepth = mydepth + 1.
211: display 'In BMSUB: Entry # ' mydepth ' PARAM = '
212: parm80 upon printer.
213:
214: if comwho is equal to 'BMICP'
215: go to skip0.
216: display 'I was called from Extended Mode! '
217: upon printer.
218: skip0.
219: if bmflag is equal to 1
220: go to quit.
221: * Mixed-Mode transaction. We can call EM if we wish.
222:
223: if parm80 is not equal to 'SSEP1'
224: go to skip-call.

Example 6–32. Creating the ACOB HVTIP Absolutes

7831 4077–009 6–145

Application Programming in an HVTIP Environment

225: call 'SSEP1'.

226: skip-call.
227:
228: if parm80 is not equal to 'SSEP2'
229: go to skip-call2.
230: move 'This is BMSUB calling, are you there???!!!!!...'
231: to parm80.
232: move 'Second parm from BMSUB' to parm40.
233: call 'SSEP2' using parm80 parm40.
234: skip-call2.
235:
236: move 'BMSUB calling...' to parm80.
237: move '(BMSUB) Are You there??!!!!!!!!!' to parm40.
238: call 'MCBSUBB' using parm80 parm40.
239: * (May not return to me...)
240:
241: move 'BMSUB got your message!!!!' to parm80.
242:
243: quit.
244: display 'Returning from BMSUB' upon printer.
245: exit program.
246: @eof
247: @ . BMSUB2 can be either called or transferred-to
248: @acob,iv jmh*acobtests2.bmsub2
249: IDENTIFICATION DIVISION.
250: PROGRAM-ID. BMSUB2
251: ENVIRONMENT DIVISION.
252: CONFIGURATION SECTION.
253: SOURCE-COMPUTER. UNIVAC-1100.
254: OBJECT-COMPUTER. UNIVAC-1100 memory 3 modules.
255: SPECIAL-NAMES.
256: PRINTER IS PRINTER.
257: DATA DIVISION.
258: COMMON-STORAGE SECTION.
259: 01 common-field-1 pic x(6).
260: 01 com80 pic x(80).
261: 01 comwho pic x(8).
262: 01 bmflag pic 9.
263:
264: 01 restart pic x(7).
265: 01 stopit pic x(6).
266: 01 active-flag pic x(6).
267: 01 terminate-mcb pic 9.
268:
269: working-storage section.
270: 01 parm80 pic x(80).
271: 01 parm40 pic x(40).

Example 6–32. Creating the ACOB HVTIP Absolutes

6–146 7831 4077–009

 Application Programming in an HVTIP Environment

272: 01 mydepth pic 9999 value zero.

273: PROCEDURE DIVISION.
274: begin.
275: compute mydepth = mydepth + 1.
276: display 'In BMSUB2, entry # ' mydepth ' upon printer.
277:
278:
279: if comwho is equal to 'BMICP'
280: go to skip0.
281: display 'I was called from Extended Mode! '
282: upon printer.
283: skip0.
284: if common-field-1 is not equal to 'JMHEP1'
285: go to skip-stop.
286: display ' **********' upon printer.
287: display 'BMSUB2 was *TRANSFER*ed-to!!' upon printer.
288: display ' **********' upon printer.
289:
290: move 'BMSUB2 calling!!!!!!!!!' to parm80.
291: call 'BMSUB' using parm80.
292: call 'MCBSUBA'.
293:
294: move 'BMSUB2 is calling you!!!!!! ' to parm80.
295: move 'Arg#2 ' to parm40.
296: call 'SSEP2' using parm80 parm40.
297:
298: display '*********************************' upon printer.
299: display '**BMSUB2 will now do a STOP RUN**' upon printer.
300: display '*********************************' upon printer.
301: STOP RUN.
302: skip-stop.
303: * Call MCBSUBX (via CALL EP) if we are to get a
304: * long chain going:
305:
306: if stopit is equal to 'CALLxM'
307: display 'BMSUB2 calling MCBSUBXCL' upon printer
308: call 'MCBSUBXCL'.
309: * MCBSUBX will NOT return here....
310:
311: display ' BMSUB2 is now returning to its caller'
312: upon printer.
313: exit program.
314: @eof
315: @ .
316: @ . >>>>>> Now we collect our HVTIP ACOB-based absolutes.
317: @ . >>>>>> We use the ACOB MAPHVTIP skeleton to generate the
318: @ . >>>>>> collections.

Example 6–32. Creating the ACOB HVTIP Absolutes

7831 4077–009 6–147

Application Programming in an HVTIP Environment

319: @ . >>>>>> The ICP requires the following special modules:

320: @ . >>>>>> - The ...SYSDTA relocatables which supply the
321: @ . >>>>>> dbank for the AFCB code it calls.
322: @ . >>>>>> - The AFCB-CBEP relocatable which is a CBEP
323: @ . >>>>>> defining the entry points in the AFCB it calls.
324: @ . >>>>>> - The R$INIT intercept from MIXEDMODESKL which
325: @ . >>>>>> initializes the pointers to the dbank space for
326: @ . >>>>>> the BM AFCB code which Extended Mode also calls.
327: @ . >>>>>> - The BMINT MIXEDMODESKL intercept which gives
328: @ . >>>>>> access to both the Extended Mode HVTIP ZOOMs and
329: @ . >>>>>> EM subsystem code to the Basic Mode ICP code.
330: @ .
331: @add sys$lib$*acob-tiplib.maphvtip
332: rel jmh*acobtests2.
333: abs jmh*acobtests2.
334: .
335: hvtip icp,bmicp . Bank 013
336: local to,bmicp masm,bmint masm,r$init masm,afcb-cbep ;
337: masm,afcb22sysdta masm,afcb1$sysdta ;
338: masm,afcb3$sysdta
339: hvtip subprogram,bmsub . Bank 014
340: local to,bmsub masm,bmint
341: hvtip subprogram,bmsub2 . Bank 015
342: local to,bmsub2 masm,bmint
343: control ctrl
344:
345: cobol lib,cb tipversion,tiplib common banked ;
346: cbep$,sys$lib$*acob-dml utility,ascii
347: list normal
348: using mixedmode
349: @eof
350: @eof
351: @pack,p jmh*acobtests2.
352: @prt,tb jmh*acobtests2.

Example 6–32. Creating the ACOB HVTIP Absolutes

1: @ .
2: @ . >>>>>>>>> This runstream creates the Extended Mode HVTIP
3: @ . >>>>>>>>> transactions. It does the compilations and the
4: @ . >>>>>>>>> static links.
5: @ .
6: @ . Transaction BMICP is a BM-only transaction. It does some calls
7: @ . to BM HVTIP absolutes and to BM AFCBs.
8: @ . Transaction JMHHVT is an EM-only transaction. It does a TRANSFER
9: @ . to an EM HVTIP ZOOM and some calls to EM Subsystems.

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–148 7831 4077–009

 Application Programming in an HVTIP Environment

10: @ . Transaction JMHEP1 is Mixed-Mode. It does lots of EM-BM calls,

11: @ . including HVTIP and AFCB/Subsystem types. It stops by doing a
12: @ . Transfer from BM to EM, which Transfers to BM, which does a
13: @ . STOP RUN.
14: @ . Transaction JMHEP2 is Mixed-Mode. It tries to get a TIP RESTART.
15: @ . If successful, it does prints and a series of EM/BM calls etc.
16: @ . on the second entry. It also does minimal EM<->BM calls to
17: @ . ZOOMS/ABS/AFCBS/SS on the first execution to prove that these
18: @ . things do NOT inhibit RESTART.
19: @ . Transaction JMHEP3 is Mixed-Mode. It does lots of EM-BM calls,
20: @ . including HVTIP and AFCB/SS types.
21: @ . ***
22: @ . *** *** START OF THE EXAMPLE SETUP SECTION *********************
23: @ . ***
24: @ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS:
25: @ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINES.
26: @ . ***
27: @ . *** A LOCAL COPY OF THE MCB PACKET PROCEDURE IS PDP'ED
28: @ . *** INTO THE COMPILATION FILE SO THE PROCEDURE CAN BE
29: @ . *** LOCATED BY THE COMPILER.
30: @ . ***
31: @ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
32: @ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
33: @ . *** AND BANK NUMBER.
34: @ . ***
35: @PDP,UC JMH*UCSTST2.MCBPKT/UCOB,.MCBPKT-UCOB
36: @EOF
37: @ . ***
38: @USE MASM$PF1.,SYS$LIB$*LINK.
39: @ASG,A MASM$PF1.
40: @ . ***
41: @ . *** * ICP MCBICP ******
42: @ . *** COMPILE THE ICP "MCBICP AND ASSEMBLE ITS HVCALLS
43: @ . *** TRANSFER WITH CANCEL AND CALL ELEMENT
44: @ . *** "HVCALLSDEF/callbm "
45: @ . ***
46: @UCOB,I JMH*UCSTST2.MCBICP/CALLBM,.MCBICP/CALLBM,,,COMPAT,NO-OPTIONS
47: IDENTIFICATION DIVISION.
48: ******************************************************************
49: ******************************************************************
50: * *
51: * EXAMPLE OF AN EXTENDED MODE INITIAL CONTROL PROGRAM 'MCBICP'. *
52: * DEPENDING ON THE TRANSACTION CODE, THIS MAIN PROGRAM CAN DO *
53: * CALLS OR TRANSFERS TO OTHER SUBPROGRAMS, AND WILL EVEN CALL *
54: * A BASIC MODE ICP IN A MIXED-MODE ENVIRONMENT. *
55: * *
56: ******************************************************************

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–149

Application Programming in an HVTIP Environment

57: ******************************************************************
58: PROGRAM-ID. MCBICP INITIAL.
59: ENVIRONMENT DIVISION.
60: CONFIGURATION SECTION.
61: SOURCE-COMPUTER. UNISYS-2200.
62: SPECIAL-NAMES.
63: PRINTER IS PRINTER.
64: DATA DIVISION.
65: COMMON-STORAGE SECTION.
66: 01 COMMON-FIELD-1 PIC X(6).
67: 01 com80 pic x(80).
68: 01 comwho pic x(8).
69: 01 bmflag pic 9.
70: 01 restart pic x(7).
71: 01 stopit pic x(6).
72: 01 active-flag pic x(6).
73: 01 terminate-mcb pic 9.
74:
75: WORKING-STORAGE SECTION.
76: 01 no-prints pic 9.
77: COPY MCBPKT-UCOB.
78: PROCEDURE DIVISION.
79: ****************************************************
80: *** TRANSACTION INITIALIZATION ***
81: ****************************************************
82: START-UP-ICP.
83: *
84: * -Do not put any initial values on Blank Common so that we have
85: * a way of detecting a TIP RESTART. (Initial values on one small
86: * var in common may cause zeros to be put in the rest of common.)
87: * -If STOPIT was not 'STOPIT', we check the ACTIVE variable for
88: * having the value 'ACTIVE'. If it does, this is presumeably a
89: * TIP RESTART, and we set the RESTART value to 'RESTART'.
90: * -We open MCB, setup some more Common vars.
91: * -At this point, if it was NOT a RESTART, we try to ensure that
92: * a RESTART will occur next time by NOT printing anything and by
93: * doing very little. We at least call or transfer to the BM ICP,
94: * and it also will do very little before calling/transfering back
95: * to here after setting STOPIT to 'STOPIT'.
96: *
97: move 1 to no-prints.
98: display 'ACTIVE-FLAG: ' active-flag .
99: if active-flag is equal to 'ACTIVE'
100: move 'RESTART' to restart
101: move 0 to no-prints.
102:
103: move 'ACTIVE' to active-flag.

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–150 7831 4077–009

 Application Programming in an HVTIP Environment

104: move 0 to terminate-mcb.

105:
106: if restart is not equal to 'RESTART' go to no-disp1.
107: DISPLAY 'THIS IS MCBICP' UPON PRINTER.
108: display 'This was also a TIP RESTART!!!!!!' upon printer.
109: no-disp1.
110: MOVE LOW-VALUES TO P-MCB-PACKET.
111: MOVE 0 TO P-MCB-STATUS.
112: MOVE 1 TO P-BIT2.
113: MOVE P-TRINIT TO P-FUNC.
114: MOVE 80 TO P-LENGTH.
115: MOVE 4 TO P-AUX.
116: CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
117: IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
118: move 'MCBICP' to comwho.
119: move 'A message from the EM ICP!' to com80.
120: MOVE FUNCTION UPPER-CASE (P-MCB-TRANS-CODE)
121: TO COMMON-FIELD-1.
122:
123: ******************************************************
124: *** Do various CALLS/TRANSFERS ***
125: *** DEPENDING UPON THE TRANSACTION CODE ***
126: ******************************************************
127: SETUP-CALL-TO-SUBPROGRAM.
128:
129: * If JMHEP2 and a a first-time entry (no RESTART), go right to
130: * the BMICP for an expedited execution so that RESTART
131: * occurs on the NEXT execution.
132:
133: if no-prints is equal to 0 or common-field-1 is not equal
134: to 'JMHEP2' go to not-first-time.
135: * Short and sweet with NO PRINTs to ensure RESTART.
136:
137: call 'B$INIT'.
138: call 'BMICP'.
139: display '!???BMICP returned to EMICP???!' upon printer.
140: STOP RUN.
141:
142: not-first-time.
143: display 'EMICP, MCB initialized.' upon printer.
144: display ' Transaction code was ' common-field-1
145: upon printer.
146: call 'SSEP1'.
147:
148: EVALUATE COMMON-FIELD-1
149: WHEN 'JMHHVT'
150: DISPLAY 'MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX'

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–151

Application Programming in an HVTIP Environment

151: UPON PRINTER

152: CALL 'MCBSUBX'
153: WHEN 'JMHEP1'
154: CALL 'MCBSUBA'
155: DISPLAY 'MCBICP calling B$INIT ' upon printer
156: CALL 'B$INIT'
157: display 'MCBICP now calling BMICP' upon printer
158: call 'BMICP'
159: display 'Back in EM MCBICP routine!??!' upon printer
160: STOP RUN
161: WHEN 'JMHEP2'
162: CALL 'MCBEP2'
163: DISPLAY 'MCBICP calling B$INIT ' upon printer
164: CALL 'B$INIT'
165: display 'MCBICP now calling BMICP' upon printer
166: call 'BMICP'
167: display 'Back in EM MCBICP routine!??!' upon printer
168: STOP RUN
169: WHEN OTHER
170: DISPLAY 'MCBICP calling B$INIT ' upon printer
171: CALL 'B$INIT'
172: CALL 'MCBEP3'
173: display 'MCBICP now calling BMICP' upon printer
174: call 'BMICP'
175: display 'Back in EM MCBICP routine!??!' upon printer
176: STOP RUN
177: END-EVALUATE.
178: STOP RUN.
179: ****************************************************
180: *** MCB ERROR HANDLING ***
181: ****************************************************
182: ERROR-EXIT.
183: DISPLAY '********* MCB ERROR *********' UPON PRINTER.
184: DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
185: DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
186: DISPLAY 'ERROR CODE Q3 = ' P-ERRCODEQ3 UPON PRINTER.
187: DISPLAY 'ERROR CODE Q4 = ' P-ERRCODEQ4 UPON PRINTER.
188: MOVE 0 to P-ID.
189: MOVE P-TERM TO P-FUNC.
190: CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
191: STOP RUN.
192: @MASM,NI JMH*UCSTST2.HVCALLSDEF/callbm
193: . HVCALLS DEFINITION
194: . MCBSUBX is defined as a TRANSFER WITH CANCEL
195: . MCBSUBA first entry point is defined as a CALL
196: . MCBSUBA second entry point (MCBEP2) is defined as a CALL
197: . MCBSUBA third entry point (MCBEP3) is defined as a CALL

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–152 7831 4077–009

 Application Programming in an HVTIP Environment

198: . MCBSUBB entry point is a CALL

199: . BMICP is defined as a CALL here, but the EMINT intercept
200: . generated by MIXEDMODESKL will define that EP.
201: $OBJ
202: $INCLUDE 'OM$DEF'
203: $INCLUDE 'HVTIP$CALLS'
204: $INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
205: HV$XFR$CANCL 17,7,0 'MCBSUBX'
206: HV$CALL 17,012,01000 'MCBSUBA'
207: HV$CALL 17,012,01003 'MCBEP2'
208: HV$CALL 17,012,01006 'MCBEP3'
209: HV$CALL 17,016,01000 'MCBSUBB'
210: . HV$CALL 17,013,01000 'BMICP' .
211: $end
212: @EOF
213: @ . ***
214: @ . *** * MULTIPLE ENTRY POINT SUBPROGRAM MCBSUBA ******
215: @ . *** COMPILE THE MULTIPLE ENTRY POINT SUBPROGRAM "MCBSUBA" AND
216: @ . *** ASSEMBLE ITS JUMP VECTOR ELEMENT "JUMPVECTOR/MCBSUBA"
217: @ . ***
218: @ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
219: @ . ***
220: @UCOB,I JMH*UCSTST2.MCBSUBA/callbm,.MCBSUBA/COMP,,,COMPAT,;
221: NO-OPTIONS,SUBPROGRAM
222: IDENTIFICATION DIVISION.
223: ******************************************************************
224: ******************************************************************
225: * *
226: * Example of a subprogram "MCBSUBA" that has 3 entry points. *
227: * MCBSUBA, MCBEP2, MCBEP3. *
228: * *
229: ******************************************************************
230: ******************************************************************
231: PROGRAM-ID. MCBSUBA initial.
232: ENVIRONMENT DIVISION.
233: CONFIGURATION SECTION.
234: SOURCE-COMPUTER. UNISYS-2200.
235: SPECIAL-NAMES.
236: PRINTER IS PRINTER.
237: DATA DIVISION.
238: COMMON-STORAGE SECTION.
239: 01 COMMON-FIELD-1 PIC X(6).
240: 01 com80 pic x(80).
241: 01 comwho pic x(8).
242: 01 bmflag pic 9.
243:
244: 01 restart pic x(7).

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–153

Application Programming in an HVTIP Environment

245: 01 stopit pic x(6).

246: 01 active-flag pic x(6).
247: 01 terminate-mcb pic 9.
248:
249: * 'INITIAL' option makes STOPIT-SAVE variable stacked on the ALS.
250:
251: WORKING-STORAGE SECTION.
252: 01 parm40 pic x(40).
253: 01 parm80 pic x(80).
254: 01 ents1 pic 999 value zero.
255: 01 ents2 pic 999 value zero.
256: 01 ents3 pic 999 value zero.
257: 01 stopit-save pic x(6).
258:
259: PROCEDURE DIVISION WITH ENTRY POINTS MCBEP2, MCBEP3.
260: *
261: MCBEP1.
262: add 1 to ents1 giving ents1.
263: DISPLAY 'EM MCBSUBA Entry Point MCBEP1: Entry # ' ents1
264: UPON PRINTER.
265: if comwho is equal to 'MCBICP' then
266: go to skip-bm-calls.
267: * We were called from a basic mode HVTIP absolute!
268: *
269: * If STOPIT is = 'CALLxM' we are supposed to get a long call
270: * chain going. Our job is to call BMSUB. Do that at the end,
271: * after vigorously exercising things:
272:
273: move stopit to stopit-save.
274: move ' ' to stopit.
275:
276: display 'I was called from Basic Mode!!' upon printer.
277: move 'MCBSUBA calling ' to parm80.
278: call 'AFCB22' using parm80.
279: move 'SSEP1:MCBSUBA calling U ' to parm80.
280: call 'AFCB1' using parm80.
281:
282: move stopit-save to stopit.
283: move 'EMCALLER ' TO parm80.
284: call 'BMSUB' using parm80.
285:
286: skip-bm-calls.
287: move 'MCBSUBA is calling...' to parm80.
288: move 'Second MCBSUBA parm to SSEP2!' to parm40.
289: call 'SSEP2_CALLER' using parm80 parm40.
290:
291: DISPLAY ' RETURNING From MCBSUBA:MCBEP1' UPON PRINTER.

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–154 7831 4077–009

 Application Programming in an HVTIP Environment

292: EXIT PROGRAM.

293: *
294: MCBEP2.
295: add 1 to ents2 giving ents2.
296: DISPLAY 'EM MCBSUBA Entry Point MCBEP2: Entry # ' ents2
297: UPON PRINTER.
298: call 'SSEP1'.
299: DISPLAY ' RETURNING from MCBSUBA, MCBEP2' UPON PRINTER.
300: EXIT PROGRAM.
301: *
302: MCBEP3.
303: add 1 to ents3 giving ents3.
304: DISPLAY 'EM MCBSUBA Entry Point MCBEP3: Entry # ' ents3
305: UPON PRINTER.
306: DISPLAY ' RETURNING from MCBSUBA, MCBEP3' UPON PRINTER.
307: EXIT PROGRAM.
308: @MASM,I JMH*UCSTST2.JUMPVECTOR/MCBSUBA,.JUMPVECTOR/MCBSUBA
309: . JUMPVECTOR DEFINITION
310: . THE THREE ENTRY POINTS FOR MCBSUBA ARE DEFINED
311: . MCBSUBA first entry point (MCBSUBA)
312: . MCBSUBA second entry point (MCBEP2)
313: . MCBSUBA third entry point (MCBEP3)
314: .
315: $OBJ
316: $EXTEND
317: $INCLUDE 'MAXR$'
318: $INCLUDE 'OM$DEF'
319: $INCLUDE 'HVTIP$CALLS'
320: . .
321: OM$USE_LV,0 . Define link vector bank as $(0)
322: . .
323: $(1) $BANK HV$CODE_EMB,01000 . Define an ext. mode code bank
324: . . that starts at 01000 and has the
325: . . MERGE_ORDER bank attribute set
326: . . to FIRST.
327: . . That causes this bank to always
328: . . be at the front of any bank
329: . . into which it is merged.
330: . .
331: JUMPER* . Start addr for HVTIP subprogram
332: . .
333: HV$VECTOR MCBSUBA . Offset 01000 will pass control
334: . . to MCBSUBA (MCBEP1)
335: . .
336: HV$VECTOR MCBEP2 . Offset 01003 will pass control
337: . . to MCBEP2
338: . .

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–155

Application Programming in an HVTIP Environment

339: HV$VECTOR MCBEP3 . Offset 01006 will pass control

340: . . to MCBEP3
341: . .
342: $END
343: @EOF
344: @ . *** MCBSUBB - has 2 parms
345: @ . ***
346: @ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
347: @ . ***
348: @UCOB,I JMH*UCSTST2.MCBSUBB/callbm,.MCBSUBB/COMP,,,COMPAT,;
349: NO-OPTIONS,SUBPROGRAM
350: IDENTIFICATION DIVISION.
351: ******************************************************************
352: ******************************************************************
353: * *
354: * This subprogram has 2 input parameters. *
355: * *
356: ******************************************************************
357: ******************************************************************
358: PROGRAM-ID. MCBSUBB.
359: ENVIRONMENT DIVISION.
360: CONFIGURATION SECTION.
361: SOURCE-COMPUTER. UNISYS-2200.
362: SPECIAL-NAMES.
363: PRINTER IS PRINTER.
364: DATA DIVISION.
365: COMMON-STORAGE SECTION.
366: 01 COMMON-FIELD-1 PIC X(6).
367: 01 com80 pic x(80).
368: 01 comwho pic x(8).
369: 01 bmflag pic 9.
370:
371: 01 restart pic x(7).
372: 01 stopit pic x(6).
373: 01 active-flag pic x(6).
374: 01 terminate-mcb pic 9.
375:
376: WORKING-STORAGE SECTION.
377: 01 v1 pic x(40).
378: 01 v2 pic x(80).
379: 01 mydepth pic 9999 value zero.
380: 01 callxm pic x(6).
381:
382: linkage section.
383: 01 parm80 pic x(80).
384: 01 parm40 pic x(40).
385: PROCEDURE DIVISION using parm80 parm40.

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–156 7831 4077–009

 Application Programming in an HVTIP Environment

386: *
387: BEGIN.
388: compute mydepth = mydepth + 1.
389: DISPLAY 'EM MCBSUBB Entry # ' mydepth
390: UPON PRINTER.
391:
392:
393: if comwho is equal to 'MCBICP'
394: go to skipbm.
395: call 'AFCB22' using parm80.
396: move 'SSEP :MCBSUBB calling YOU!' to parm80.
397: call 'AFCB1' using parm80.
398: move 'ANTIDISESTABLISHMENTARIANISM' to parm80.
399:
400: skipbm.
401:
402: * If STOPIT is 'CALLxM', we are to get a chain of calls going.
403: * Our job is to call BMSUB2 (and it will NOT return.....)...
404:
405: move 'CALLxM' to callxm.
406: if stopit is not equal to 'CALLxM' go to retnow.
407: call 'BMSUB2'.
408: display 'BMSUB2 ..returned.. to MCBSUBB!!!' upon printer.
409: retnow.
410: move '''Message-Received''' to parm40.
411: display 'Returning from MCBSUBB now....' upon printer.
412:
413: EXIT PROGRAM.
414: @ . ***
415: @ . *** * SUBPROGRAM MCBSUBX ******
416: @ . *** COMPILE SUBPROGRAM "MCBSUBX"
417: @ . ***
418: @UCOB,I JMH*UCSTST2.MCBSUBX/callbm,.MCBSUBX/COMP,,,COMPAT,;
419: NO-OPTIONS,SUBPROGRAM
420: IDENTIFICATION DIVISION.
421: ******************************************************************
422: ******************************************************************
423: * *
424: * EXAMPLE OF A SUBPROGRAM "MCBSUBX" THAT WAS CALLED FROM THE ICP *
425: * "MCBICP" USING TRANSFER WITH CANCEL
426: * *
427: ******************************************************************
428: ******************************************************************
429: PROGRAM-ID. MCBSUBX.
430: ENVIRONMENT DIVISION.
431: CONFIGURATION SECTION.
432: SOURCE-COMPUTER. UNISYS-2200.

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–157

Application Programming in an HVTIP Environment

433: SPECIAL-NAMES.
434: PRINTER IS PRINTER.
435: DATA DIVISION.
436: COMMON-STORAGE SECTION.
437: 01 COMMON-FIELD-1 PIC X(6).
438: 01 com80 pic x(80).
439: 01 comwho pic x(8).
440: 01 bmflag pic 9.
441:
442: 01 restart pic x(7).
443: 01 stopit pic x(6).
444: 01 active-flag pic x(6).
445: 01 terminate-mcb pic 9.
446:
447: WORKING-STORAGE SECTION.
448: 01 parm80 pic x(80).
449: 01 parm40 pic x(40).
450: 01 mydepth pic 9999 value zero.
451: COPY MCBPKT-UCOB.
452: PROCEDURE DIVISION.
453: ****************************************************
454: *** MCBSUBX START UP ***
455: ****************************************************
456: START-UP-SUBX.
457: *
458: * BM may have called us to do a clean EM exit in order to
459: * preserve TIP RESTART. If so DON'T PRINT ANYTHING, or TIP
460: * RESTART is inhibited.
461: *
462: if stopit is equal to 'STOPIT' go to mcb-terminate.
463:
464: * If stopit is 'CALLxM', we are to get a long chain of calls
465: * goint, and MCBSUBX was entered by a CALL as vs. a TRANSFER.
466: *
467:
468: compute mydepth = mydepth + 1.
469: display ' MCBSUBX Entry # ' mydepth upon printer.
470: if stopit is equal to 'CALLxM'
471: go to skip-transferprint.
472:
473: display ' ****************' upon printer.
474: display 'MCBSUBX, was TRANSFERred-to from: ' comwho
475: upon printer.
476: display ' ****************' upon printer.
477: skip-transferprint.
478:
479: * Can't call BM AFCB if BMICP was never entered:

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–158 7831 4077–009

 Application Programming in an HVTIP Environment

480: if comwho is not equal to 'BMICP'

481: go to skipbm.
482:
483: move 'MCBSUBX calling..' to parm80.
484: call 'AFCB1' using parm80.
485:
486: move 'MCBSUBX calling.U' to parm80.
487: call 'AFCB22' using parm80.
488: call 'AFCB3' using 1 'EM'.
489:
490: skipbm.
491:
492: call 'SSEP1'.
493: call 'SSEP3' using 1 'EM'.
494: DISPLAY ' TERMINATING MCB FROM MCBSUBX' UPON PRINTER.
495: move 1 to terminate-mcb.
496:
497: MCB-TERMINATE.
498:
499: if terminate-mcb is equal to 0
500: go to skip-mcb-termination.
501: MOVE LOW-VALUES TO P-MCB-PACKET.
502: MOVE 0 TO P-MCB-STATUS.
503: MOVE 0 TO P-FLAGS.
504: MOVE P-TERM TO P-FUNC.
505: CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
506: IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
507:
508: skip-mcb-termination.
509:
510: if stopit is equal to 'CALLxM'
511: display 'Doing a STOP RUN in MCBSUBX now..' upon printer
512: STOP RUN.
513:
514: * Clear STOPIT flag to not mess-up a tip restart.
515: if stopit is not equal to 'STOPIT' go to skip-stopit.
516: move ' ' to stopit.
517:
518: * Ensure sticking happens even if we call an EM SS ep and a BM
519: * ACOB AFCB EP. (No prints pleez....!)
520:
521: call 'SSEP3' using 0 'EM'.
522: if comwho is equal to 'BMICP'
523: call 'AFCB3' using 0 'EM'.
524:
525: STOP RUN.
526:

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–159

Application Programming in an HVTIP Environment

527: skip-stopit.
528: * No Mixed-Mode if Tran code is JMHHVT:
529: if common-field-1 is equal to 'JMHHVT'
530: go to skip-bm-call.
531: display 'Now doing a *TRANSFER* (with CANCEL) to BMSUB2:'
532: upon printer.
533: call 'BMSUB2XFR'.
534: skip-bm-call.
535: display 'MCBSUBX doing a STOP RUN now....' upon printer.
536: STOP RUN.
537: ****************************************************
538: *** MCB ERROR HANDLING ***
539: ****************************************************
540: ERROR-EXIT.
541: DISPLAY '********* MCB ERROR *********' UPON PRINTER.
542: DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
543: DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
544: DISPLAY 'ERROR CODE Q3 = ' P-ERRCODEQ3 UPON PRINTER.
545: DISPLAY 'ERROR CODE Q4 = ' P-ERRCODEQ4 UPON PRINTER.
546: MOVE 0 to P-ID.
547: MOVE P-TERM TO P-FUNC.
548: CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
549: STOP RUN.
550: @ . ***
551: @ . *** THE ICP AND SUBPROGRAMS ARE LINKED SEPARATELY CREATING
552: @ . *** HVTIP ZOOMS.
553: @ . ***
554: @ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
555: @ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
556: @ . *** LOCATE THAT APPLICATION GROUP'S MCB.
557: @ . ***
558: @ . *** @USE LINK$PF.,SYS$LIB$*APP$n.
559: @ . ***
560: @ . *** WHERE "n" IS REPLACED WITH THE APPLICATION GROUP NUMBER
561: @ . ***
562: @ . *** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
563: @ . ***
564: @USE LINK$PF,SYS$LIB$*APP$9.
565: @ . ***
566: @ . *** CREATE SYMBOLIC ELEMENTS TO HOLD THE "OUTPUT" STATEMENT
567: @ . *** AND THE "SET LOWADR" STATEMENTS FOR BLANK COMMON THAT EACH
568: @ . *** OF THE STATIC LINKS WILL NEED:
569: @ . ***
570: @ELT,I JMH*UCSTST2.OUTPUTSTMT
571: . Setup an HVTIP2 heap environment consisting of:
572: . Program-level banks:
573: . Basic Mode heap, BDI 05

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–160 7831 4077–009

 Application Programming in an HVTIP Environment

574: . Small banks: (4, each with limits of 060000 to 0577777)

575: . BDIs 06
576: . 07
577: . 010 (pooled)
578: . 011 (pooled)
579: . Large banks: (2, 2 BDIs each)
580: . BDIs 012 & 013
581: . 014 & 015 (pooled)
582: . Activity-level banks:
583: . Small banks: (4, each with limits of 060000 to 0577777)
584: . BDIs 03
585: . 04 (pooled)
586: . 05 (pooled)
587: . 06 (pooled)
588: . Large banks: (1, 3 BDIs each)
589: . BDIs 07, 010, & 011 (pooled)
590: .
591: . The standard HVTIP heap bank (Program-level BDI 5) is also available.
592: .
593: . The above bank allocations correspond to the following
594: . VALTAB settings:
595: . DSPRGCNT,4 DLPRGCNT,2 DPSIZL,2
596: . DSACTCNT,4 DLACTCNT,1 DASIZL,3
597: . DSLOWER,060000 DSUPPER,0577777
598: . BMLOWER,040000 BMUPPER,0177777
599: .
600: . Here is the OUTPUT HVTIP2 statement to match these bank allocations:
601: .
602: OUTPUT HVTIP2
603: WITH
604: TS_MISMATCH_ACTION = CANCEL,
605: ENVIRONMENT = MIXED_MODE BM_LIMITS=040000 TO 0177777,
606: SMALL_BANK_LIMITS = 060000 TO 0577777
607: USING
608: 4 SMALL_BANKS,
609: 2 POOLED_SMALL_BANKS,
610: 2 LARGE_BANKS,
611: 1 POOLED_LARGE_BANKS,
612: LARGE_BANK_SIZE = 2
613: FOR PROGRAM_LEVEL_HEAP
614: USING
615: 4 SMALL_BANKS,
616: 3 POOLED_SMALL_BANKS,
617: 1 LARGE_BANKS,
618: 1 POOLED_LARGE_BANKS,
619: LARGE_BANK_SIZE = 3
620: FOR ACTIVITY_LEVEL_HEAP

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–161

Application Programming in an HVTIP Environment

621: .
622: . Have the HVTIP$$DBANK limits match the small bank limits too:
623: .
624: set lowadr = 060000 for HVTIP$$DBANK
625: set size = 0520000 for HVTIP$$DBANK
626:
627: @ELT,I JMH*UCSTST2.COMMON
628: . Ensure EM alignment and size match BM for Blank Common:
629:
630: CONCEAL MESSAGES 613
631: SET ALIGNMENT = 0 FOR $BLANK$COMMON$
632: SET SIZE = SIZE - 1 FOR $BLANK$COMMON$
633:
634: . Offset for next statement is obtained by examining the
635: . MAP listing of the collection of BICP. The offset should
636: . be set to the BICP DBANK starting offset plus the offset
637: . of Blank Common (BLANK$COMMON in Basic Mode) in its RSEG:
638:
639: SET LOWADR=0400005041000 FOR $BLANK$COMMON$
640:
641: @EOF
642: @ . ***
643: @ . ***
644: @ . *** *** MCBICP LINK ********
645: @ . *** LINK THE ICP "MCBICP" INCLUDING THE HVCALLS ELEMENT
646: @ . *** "HVCALLSDEF/MCBSUBXSUBA"
647: @ . ***
648: @link,ie JMH*UCSTST2.JMHICP
649: ADD JMH*UCSTST2.OUTPUTSTMT
650: INCLUDE JMH*UCSTST2.MCBICP/callbm
651: INCLUDE JMH*UCSTST2.HVCALLSDEF/callbm
652: INCLUDE tpf$.emint,.b$init . Intercepts to get to BM
653: INCLUDE jmh*ucstst2.ssint1/nodb . To get to EM subsystem
654: RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
655: ADD JMH*UCSTST2.COMMON
656: SET ZEROFILL = NONE FOR ALL BANKS
657: DELETE ALL DEFINITIONS EXCEPT START$
658: @EOF
659: @ . ***
660: @ . *** *** MCBSUBA LINK ********
661: @ . *** LINK THE SUBPROGRAM "MCBSUBA" INCLUDING THE JUMP VECTOR ELT
662: @ . *** "JUMPVECTOR/MCBSUBA"
663: @ . ***
664: @link,ie JMH*UCSTST2.MCBSUBA/link,.mcbsuba
665: ADD JMH*UCSTST2.OUTPUTSTMT
666: INCLUDE JMH*UCSTST2.MCBSUBA/COMP
667: INCLUDE JMH*UCSTST2.JUMPVECTOR/MCBSUBA

Example 6–33. Creating the UCOB HVTIP ZOOMs

6–162 7831 4077–009

 Application Programming in an HVTIP Environment

668: .
669: . EMINT is an intercept to get to BM HVTIP absolute BMSUB.
670: . SSINT1/DB is an FLSS intercept to get to EM subsystem
671: . entry points SSEP1, SSEP2, SSEP3.
672: . EMINT2 is an intercept to get to the EM subsystem gated
673: . entry points of SSEP1_CALLER and SSEP2_CALLER.
674: .
675: INCLUDE tpf$.emint
676: include jmh*ucstst2.ssint1/db
677: include tpf$.emint2
678: RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
679: ADD JMH*UCSTST2.COMMON
680: SET LOWADR = 0400007115000 FOR HVTIP$$DSEG
681: SET ZEROFILL = NONE FOR ALL BANKS
682: DELETE ALL DEFINITIONS EXCEPT JUMPER
683: @EOF
684: @ . ***
685: @ . *** *** MCBSUBB LINK ********
686: @ . *** LINK THE SUBPROGRAM "MCBSUBB"
687: @ . ***
688: @link,ie JMH*UCSTST2.MCBSUBB/link,.mcbsubb
689: ADD JMH*UCSTST2.OUTPUTSTMT
690: INCLUDE JMH*UCSTST2.MCBSUBB/COMP
691: INCLUDE tpf$.emint
692: include jmh*ucstst2.ssint1/db
693: include tpf$.emint2
694: RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
695: ADD JMH*UCSTST2.COMMON
696: SET LOWADR = 0400007120000 FOR HVTIP$$DSEG
697: SET ZEROFILL = NONE FOR ALL BANKS
698: DELETE ALL DEFINITIONS EXCEPT MCBSUBB
699: @EOF
700: @ . ***
701: @ . ***
702: @ . *** *** MCBSUBX LINK ********
703: @ . *** LINK THE SUBPROGRAM "MCBSUBX"
704: @ . ***
705: @link,ie JMH*UCSTST2.MCBSUBX/link,.mcbsubx
706: ADD JMH*UCSTST2.OUTPUTSTMT
707: INCLUDE JMH*UCSTST2.MCBSUBX/COMP
708: include tpf$.emint . FOR BMSUB2XFR
709: include jmh*ucstst2.ssint1/nodb
710: RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
711: ADD JMH*UCSTST2.COMMON
712: SET LOWADR = 0400006170000 FOR HVTIP$$DSEG
713: SET ZEROFILL = NONE FOR ALL BANKS
714: DELETE ALL DEFINITIONS EXCEPT MCBSUBX

Example 6–33. Creating the UCOB HVTIP ZOOMs

7831 4077–009 6–163

Application Programming in an HVTIP Environment

715: @EOF
716: @ .
717: @ . *** EXAMPLE SETUP IS COMPLETE

Example 6–33. Creating the UCOB HVTIP ZOOMs

1: @ .
2: @ . >>>>>> First, completely release, deregister, and delete the
3: @ . >>>>>> HVTIP library before recreating it, since it is used
4: @ . >>>>>> for testing other transactions.
5: @ . >>>>>> Also delete the VALTAB entries we are going to use
6: @ . >>>>>> before recreating them with new contents.
7: @ . >>>>>> Note that this runstream is tailored for a system
8: @ . >>>>>> using shared files.
9: @ .
10: @qual,d shared#
11: @prt,fc qual*HVTIPLIB17.
12: @use tip$,std#tip$*tiprun$.
13: @xqt,icx TIP$.tpur
14: STATUS,K 17
15: UNLOAD,K 17
16: @EOF
17: @ .
18: @xqt,iux tip$.freips
19: rel 87
20: dreg qual*hvtiplib17.
21: @eof
22: @ .
23: @EOF
24: @ . RELEASE TIP FILE 87 (HVTIP LIB # 17)
25: @ .
26: @delete,c qual*HVTIPLIB17.
27: @ .
28: @ . Delete possible old VALTAB entries from previous testing.
29: @ . Since this is a test runstream and re-uses old VALTABs,
30: @ . we must delete all variations that we know about.
31: @ .
32: @xqt,ixmuz tip$.vtbutl
33: *valchg m
34: 615 ACT,JMHHVT DELETE
35: 616 ACT,JMHEP1 DELETE
36: 617 ACT,JMHEP2 DELETE
37: 618 ACT,JMHEP3 DELETE
38: 619 ACT,BMICP DELETE
39: @eof

Example 6–34. Installing the HVTIP ZOOMs and Absolutes

6–164 7831 4077–009

 Application Programming in an HVTIP Environment

40: @ . More possible old VALTAB entries from previous testing:

41: @xqt,ixmuz tip$.vtbutl
42: *valchg m
43: 615 ACT,MIXED1 DELETE
44: 616 ACT,MIXED2 DELETE
45: @eof
46: @ .
47: @ . Now install HVTIP library 17.
48: @ .
49: @ . First setup the VALTAB entries for our 5 transactions.
50: @ . (Ensure that the VINDEX is updated in main storage
51: @ . using TPINIT.)
52: @ . Then create the HVTIP library file using FREIPS.
53: @ . Then copy the new HVTIP ZOOMS/Absolutes in using TPUR.
54: @ .
55: @ . ***
56: @ . ***
57: @ . *** ** VALTAB SETUP
58: @ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
59: @ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
60: @ . ***
61: @ . *** VTBUTL IS THE UTILITY FOR MANAGING THE VALTAB ENTRIES
62: @ . *** AND THE VINDEX.
63: @ . ***
64: @ . *** VALCHG ADDS, CHANGES, OR DELETES VALTAB ENTRIES FROM
65: @ . *** THE EXISTING VALTAB AND VINDEX.
66: @ . ***
67: @ . *** INPUT:
68: @ . *** *VALCHG M
69: @ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,5 STF,0 STA,IJ
70: @ . *** nnn REC,Z AUD,9
71: @ . *** nnn OPT,TV PRT,xxxxxx QPR,n
72: @ . *** nnn DSP,n DLP,n DPS,n
73: @ . *** nnn DSA,n DLA,n DAS,n
74: @ . *** nnn DSL,0nnnnnn DSU,0nnnnnn
75: @ . ***
76: @ . *** THE LAST 3 LINES ABOVE ARE ONLY APPLICABLE WHEN
77: @ . *** USING HVTIP-II FUNCTIONALITY.
78: @ . ***
79: @ . ***
80: @ . *** IN THIS EXAMPLE:
81: @ . *** THE TRANSACTION CODE (ACT,xxxxxx) IDENTIFIES WHICH
82: @ . *** SUBPROGRAMS WILL BE CALLED.
83: @ . *** TRANSACTION CODE 'MCBHVT' IS EXTENDED MODE.
84: @ . *** TRANSACTION CODE 'MCBEP1' IS MIXED MODE.
85: @ . *** TRANSACTION CODE 'MCBEP2' IS MIXED MODE.
86: @ . *** TRANSACTION CODE 'MCBEP3' IS MIXED MODE.

Example 6–34. Installing the HVTIP ZOOMs and Absolutes

7831 4077–009 6–165

Application Programming in an HVTIP Environment

87: @ . *** TRANSACTION CODE 'BMICP' IS BASIC MODE.

88: @ . ***
89: @ . *** Note that the same ICP (JMHICP) is used for the
90: @ . *** Extended mode and Mixed Mode transactions.
91: @XQT,XIMUZ tip$.VTBUTL
92: *VALCHG M
93: 615 NAM,JMHICP ACT,JMHHVT PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
94: 615 REC,Z AUD,9 PRT,HOLDPR
95: 615 DSP,4 DLP,2 DPS,2
96: 615 DSA,4 DLA,1 DAS,3
97: 615 DSLOWER,060000 DSUPPER,0577777
98: 616 NAM,JMHICP ACT,JMHEP1 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
99: 616 REC,Z AUD,9 IND,W PRT,HOLDPR
100: 616 DSP,4 DLP,2 DPS,2
101: 616 DSA,4 DLA,1 DAS,3
102: 616 DSLOWER,060000 DSUPPER,0577777
103: 616 BMLOWER,040000 BMUPPER,0177777
104: 617 NAM,JMHICP ACT,JMHEP2 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
105: 617 REC,Z AUD,9 IND,W PRT,HOLDPR
106: 617 DSP,4 DLP,2 DPS,2
107: 617 DSA,4 DLA,1 DAS,3
108: 617 DSLOWER,060000 DSUPPER,0577777
109: 617 BMLOWER,040000 BMUPPER,0177777
110: 618 NAM,JMHICP ACT,JMHEP3 PRG,5 STF,0 STA,IJ QPR,1 OPT,TV
111: 618 REC,Z AUD,9 IND,W PRT,HOLDPR
112: 618 DSP,4 DLP,2 DPS,2
113: 618 DSA,4 DLA,1 DAS,3
114: 618 DSLOWER,060000 DSUPPER,0577777
115: 618 BMLOWER,040000 BMUPPER,0177777
116: 619 NAM,BMICP ACT,BMICP PRG,5 STF,0 STA,I QPR,1 OPT,TVZM
117: 619 REC,Z AUD,9 PRT,HOLDPR
118: @EOF
119: @ . ***
120: @XQT,P tip$.BOXER
121: OFF BTLOADING
122: OFF STICKING
123: ON RECOVERY
124: OFF SCHEDULE
125: @EOF
126: @ . *** Ensure the VINDEX is updated in main storage
127: @XQT tip$.TPINIT
128: @ . ***
129: @XQT,P tip$.BOXER
130: ON BTLOADING
131: ON STICKING
132: @EOF
133: @ . ***
134: @ . ***

Example 6–34. Installing the HVTIP ZOOMs and Absolutes

6–166 7831 4077–009

 Application Programming in an HVTIP Environment

135: @ . *** ** HVTIP LIBRARY SETUP

136: @ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
137: @ . *** HVTIP LIBRARY TIP FILE.
138: @ . ***
139: @CAT,P SHARED#QUAL*HVTIPLIB17.,F/1000//1000
140: @CAT,P SHARED#TIPDIAG$PF*HVTIP21.,/1000//1000
141: @ . ***
142: @ . ***
143: @ . *** HVTIP LIBRARY INFORMATION
144: @ . ***
145: @ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP
146: @ . *** LIBRARIES ARE DEFINED BY THE EXEC GENERATION.
147: @ . ***
148: @ . *** TPLIB nn - DEFINES THE STARTING TIP FILE NUMBER
149: @ . *** FOR HVTIP LIBRARIES
150: @ . *** HVTIP mm - DEFINES THE NUMBER OF HVTIP LIBRARIES
151: @ . *** FOR THIS SYSTEM
152: @ . ***
153: @ . *** HVTIP_LIBRARY-TIP_file_number minus TPLIB =
154: @ . *** HVTIP_LIBRARY_number
155: @ . ***
156: @ . *** FOR EXAMPLE: TPLIB = 70
157: @ . *** HVTIP = 64
158: @ . *** HVTIP_LIBRARY - TIP_file_number = 87
159: @ . *** THEREFORE:
160: @ . *** 87 - 70 = 17 (HVTIP_LIBRARY_number)
161: @ . ***
162: @ . *** ** USES THE FREIPS UTILITY TO:
163: @ . ***
164: @ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
165: @ . *** TRANSACTION ZOOM.
166: @ . ***
167: @ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
168: @ . *** TRANSACTION ZOOM.
169: @ . ***
170: @ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
171: @ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
172: @ . ***
173: @prt,fc qual*hvtiplib17.
174: @xqt,iux tip$.FREIPS
175: TREG QUAL*HVTIPLIB17.,FIX
176: RES 87,64000,28,,HVTIPLIB17,WW=P,AUDIT=0,NREC
177: LFD 87
178: @EOF
179: @ . *** * HVTIP LIBRARY LOAD ******
180: @ . ***
181: @ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
182: @ . *** THE HVTIP LIBRARY.

Example 6–34. Installing the HVTIP ZOOMs and Absolutes

7831 4077–009 6–167

Application Programming in an HVTIP Environment

183: @ . ***
184: @ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
185: @ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
186: @ . *** EXECUTED FROM THIS HVTIP LIBRARY.
187: @ . ***
188: @prt,fc qual*hvtiplib17.
189: @XQT,P tip$.BOXER
190: ON RECOVERY
191: OFF SCHEDULE
192: @use tst,std#jmh*ucstst2.
193: @asg,a tst
194: @use acob,std#jmh*acobtests2.
195: @asg,a acob
196: @ . ***
197: @XQT,IMUX tip$.TPUR
198: CREATE,K 17,30
199: COPY,IVK 17,6,TST.JMHICP
200: COPY,IK 17,7,TST.MCBSUBX
201: COPY,IK 17,012,TST.MCBSUBA
202: COPY,IK 17,016,TST.MCBSUBB
203: COPY,IVK 17,013,acob.bmicp
204: COPY,IK 17,014,acob.bmsub
205: COPY,IK 17,015,acob.bmsub2
206: LIST 17
207: LOAD,K 17
208: STATUS,K 17
209: @EOF
210: @ . ***
211: @XQT,P tip$.BOXER
212: FB
213: OFF RECOVERY
214: ON SCHEDULE
215: ON TIPTRACE
216: ON STICKING
217: FB
218: @EOF
219: @prt,fc qual*hvtiplib17.
220: @free qual*hvtiplib17.
221: @qual,r
222: @ . ***
223: @ . ***

Example 6–34. Installing the HVTIP ZOOMs and Absolutes

6–168 7831 4077–009

 Application Programming in an HVTIP Environment

The following screen shows an execution of the basic mode BMICP transaction. User
input is bolded.

>BMICP

This produces the following output on the HOLDPR print queue. Note that the lines
have been numbered here for ease of reference:

1: *********!!NOW IN THE BASIC MODE ICP!!************

2: COMMON-FIELD-1 IS:
3: COM80 IS:
4: COMWHO IS:
5: THIS IS A BM-ONLY TRANSACTION
6: IN BM AFCB3: ENTRY # 0001 PARAM = BM
7: BM AFCB1 ENTRY # 0001
8: CALLING BMSUB
9: IN BMSUB: ENTRY # 0001 PARAM = CALL1
10: RETURNING FROM BMSUB
11: BM AFCB22 ENTRY # 0001
12:
13: ***********************
14: **BMICP SIGNING-OFF!!**
15: ***********************

Example 6–35. BMICP Output

The following screen shows an execution of the extended mode JMHHVT transaction.
User input is bolded.

>JMHHVT

7831 4077–009 6–169

Application Programming in an HVTIP Environment

This produces the following output on the HOLDPR print queue. Note that the lines
have been numbered here for ease of reference, and blank lines have been removed:

1: EMICP, MCB initialized.

2: Transaction code was JMHHVT
3: EM SSEP1 Entry # 1
4: MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX
5: MCBSUBX Entry # 0001
6: ****************
7: MCBSUBX, was TRANSFERred-to from: MCBICP
8: ****************
9: EM SSEP1 Entry # 1
10: In SSEP3 EM FGSS subroutine. Entry # 1 WHO arg is: EM
11: TERMINATING MCB FROM MCBSUBX
12: MCBSUBX doing a STOP RUN now....

Example 6–36. JMHHVT Output

6–170 7831 4077–009

 Application Programming in an HVTIP Environment

The following screen shows an execution of the mixed-mode JMHEP1 transaction.

User input is bolded.

>JMHEP1

This produces the following output on the HOLDPR print queue. Note that the lines
have been numbered here for ease of reference, and that blank lines have been
removed:

1: EMICP, MCB initialized.

2: Transaction code was JMHEP1
3: EM SSEP1 Entry # 1
4: EM MCBSUBA Entry Point MCBEP1: Entry # 001
5: Calling EM SSEP2 from EM SSEP2_CALLER:
6: EM SSEP2 Entry # 1
7: RETURNING From MCBSUBA:MCBEP1
8: MCBICP calling B$INIT
9: MCBICP now calling BMICP
10: *********!!NOW IN THE BASIC MODE ICP!!************
11: COMMON-FIELD-1 is: JMHEP1
12: COM80 is: A message from the EM ICP!
13: COMWHO is: MCBICP
14: Calling R$INIT from BMICP:
15: Calling EM SSEP3 from EM SSEP3_CALLER:
16: In SSEP3 EM FGSS subroutine. Entry # 1 WHO arg is: BM
17: In BM AFCB3: Entry # 0001 PARAM = BM
18: BM AFCB1 Entry # 0001
19: Calling BMSUB
20: In BMSUB: Entry # 0001 PARAM = CALL1
21: EM MCBSUBB Entry # 0001
22: BM AFCB22 Entry # 0001
23: BM AFCB1 Entry # 0002
24: Calling EM SSEP2 from EM SSEP2_CALLER:
25: EM SSEP2 Entry # 1
26: Returning from MCBSUBB now....
27: Returning from BMSUB
28: BM AFCB22 Entry # 0002

Example 6–37. JMHEP1 Output

7831 4077–009 6–171

Application Programming in an HVTIP Environment

29: Calling EM SSEP1 from EM SSEP1_CALLER:

30: EM SSEP1 Entry # 1
31: BMICP now calling EM transaction MCBSUBA
32: EM MCBSUBA Entry Point MCBEP1: Entry # 001
33: I was called from Basic Mode!!
34: BM AFCB22 Entry # 0003
35: BM AFCB1 Entry # 0003
36: Calling EM SSEP2 from EM SSEP2_CALLER:
37: EM SSEP2 Entry # 2
38: In BMSUB: Entry # 0002 PARAM = EMCALLER
39: EM MCBSUBB Entry # 0002
40: BM AFCB22 Entry # 0004
41: BM AFCB1 Entry # 0004
42: Calling EM SSEP2 from EM SSEP2_CALLER:
43: EM SSEP2 Entry # 3
44: Returning from MCBSUBB now....
45: Returning from BMSUB
46: Calling EM SSEP2 from EM SSEP2_CALLER:
47: EM SSEP2 Entry # 4
48: RETURNING From MCBSUBA:MCBEP1
49: EM MCBSUBA Entry Point MCBEP2: Entry # 001
50: EM SSEP1 Entry # 2
51: RETURNING from MCBSUBA, MCBEP2
52: EM MCBSUBA Entry Point MCBEP3: Entry # 001
53: RETURNING from MCBSUBA, MCBEP3
54: BMICP now TRANSFERing to EM MCBSUBX, bye....
55: MCBSUBX Entry # 0001
56: ****************
57: MCBSUBX, was TRANSFERred-to from: BMICP
58: ****************
59: BM AFCB1 Entry # 0005
60: BM AFCB22 Entry # 0005
61: In BM AFCB3: Entry # 0002 PARAM = EM
62: EM SSEP1 Entry # 1
63: In SSEP3 EM FGSS subroutine. Entry # 1 WHO arg is: EM
64: TERMINATING MCB FROM MCBSUBX
65: Now doing a *TRANSFER* (with CANCEL) to BMSUB2:
66: **********
67: BMSUB2 was *TRANSFER*ed-to!!
68: **********
69: In BMSUB: Entry # 0001 PARAM = BMSUB2 calling!!!!!!!!!
70: EM MCBSUBB Entry # 0001
71: BM AFCB22 Entry # 0006
72: BM AFCB1 Entry # 0006
73: Calling EM SSEP2 from EM SSEP2_CALLER:
74: EM SSEP2 Entry # 1
75: Returning from MCBSUBB now....

Example 6–37. JMHEP1 Output

6–172 7831 4077–009

 Application Programming in an HVTIP Environment

76: Returning from BMSUB

77: EM MCBSUBA Entry Point MCBEP1: Entry # 001
78: I was called from Basic Mode!!
79: BM AFCB22 Entry # 0007
80: BM AFCB1 Entry # 0007
81: Calling EM SSEP2 from EM SSEP2_CALLER:
82: EM SSEP2 Entry # 2
83: In BMSUB: Entry # 0002 PARAM = EMCALLER
84: EM MCBSUBB Entry # 0002
85: BM AFCB22 Entry # 0008
86: BM AFCB1 Entry # 0008
87: Calling EM SSEP2 from EM SSEP2_CALLER:
88: EM SSEP2 Entry # 3
89: Returning from MCBSUBB now....
90: Returning from BMSUB
91: Calling EM SSEP2 from EM SSEP2_CALLER:
92: EM SSEP2 Entry # 4
93: RETURNING From MCBSUBA:MCBEP1
94: EM MCBSUBA Entry Point MCBEP2: Entry # 001
95: EM SSEP1 Entry # 1
96: RETURNING from MCBSUBA, MCBEP2
97: EM MCBSUBA Entry Point MCBEP3: Entry # 001
98: RETURNING from MCBSUBA, MCBEP3
99: Calling EM SSEP2 from EM SSEP2_CALLER:
100: EM SSEP2 Entry # 5
101: BM AFCB1 Entry # 0009
102: Calling EM SSEP2 from EM SSEP2_CALLER:
103: EM SSEP2 Entry # 6
104: *********************************
105: **BMSUB2 will now do a STOP RUN**
106: *********************************

Example 6–37. JMHEP1 Output

7831 4077–009 6–173

Application Programming in an HVTIP Environment

The following screen shows an execution of the mixed-mode JMHEP2 transaction.

This transaction only puts output into the print queue if it detected that a TIP RESTART
had occurred. Therefore it will emit output only on every-other execution, so we
execute it twice. User input is bolded.

>JMHEP2
>JMHEP2

This produces the following output on the HOLDPR print queue. Note that the lines
have been numbered here for ease of reference, and that blank lines have been
removed:

1: THIS IS MCBICP
2: This was also a TIP RESTART!!!!!!
3: EMICP, MCB initialized.
4: Transaction code was JMHEP2
5: EM SSEP1 Entry # 1
6: EM MCBSUBA Entry Point MCBEP2: Entry # 001
7: EM SSEP1 Entry # 2
8: RETURNING from MCBSUBA, MCBEP2
9: MCBICP calling B$INIT
10: MCBICP now calling BMICP
11: *********!!NOW IN THE BASIC MODE ICP!!************
12: COMMON-FIELD-1 is: JMHEP2
13: COM80 is: A message from the EM ICP!
14: COMWHO is: MCBICP
15: Calling R$INIT from BMICP:
16: Calling EM SSEP3 from EM SSEP3_CALLER:
17: In SSEP3 EM FGSS subroutine. Entry # 1 WHO arg is: BM
18: In BM AFCB3: Entry # 0001 PARAM = BM
19: BM AFCB1 Entry # 0001
20: Calling BMSUB
21: In BMSUB: Entry # 0001 PARAM = CALL1
22: EM MCBSUBB Entry # 0001
23: BM AFCB22 Entry # 0001
24: BM AFCB1 Entry # 0002
25: Calling EM SSEP2 from EM SSEP2_CALLER:
26: EM SSEP2 Entry # 1
27: Returning from MCBSUBB now....

Example 6–38. JMHEP2 Output

6–174 7831 4077–009

 Application Programming in an HVTIP Environment

28: Returning from BMSUB

29: BM AFCB22 Entry # 0002
30: Calling EM SSEP1 from EM SSEP1_CALLER:
31: EM SSEP1 Entry # 1
32: BMICP now calling EM transaction MCBSUBA
33: EM MCBSUBA Entry Point MCBEP1: Entry # 001
34: I was called from Basic Mode!!
35: BM AFCB22 Entry # 0003
36: BM AFCB1 Entry # 0003
37: Calling EM SSEP2 from EM SSEP2_CALLER:
38: EM SSEP2 Entry # 2
39: In BMSUB: Entry # 0002 PARAM = EMCALLER
40: EM MCBSUBB Entry # 0002
41: BM AFCB22 Entry # 0004
42: BM AFCB1 Entry # 0004
43: Calling EM SSEP2 from EM SSEP2_CALLER:
44: EM SSEP2 Entry # 3
45: Returning from MCBSUBB now....
46: Returning from BMSUB
47: Calling EM SSEP2 from EM SSEP2_CALLER:
48: EM SSEP2 Entry # 4
49: RETURNING From MCBSUBA:MCBEP1
50: EM MCBSUBA Entry Point MCBEP2: Entry # 001
51: EM SSEP1 Entry # 2
52: RETURNING from MCBSUBA, MCBEP2
53: EM MCBSUBA Entry Point MCBEP3: Entry # 001
54: RETURNING from MCBSUBA, MCBEP3
55: BMSUB2 is now returning to its caller
56: **********************************
57: **BMICP doing a STOP RUN now....**
58: **********************************
59: * WARNING * TERMINATION WITHOUT DETACHING FROM MCB
60: ERR$ TYPE 03 CODE 00 CONT 12 REENT ADR: 014250
61: BDI: 400601 L,BDI: 200601
62: SYSTEM-UNIQUE ID: 030000000000000000000225
63: TRANSACTION CODE: JMHEP2 PROGRAM FILE:
64: USER EXECUTED ER ERR$.

Example 6–38. JMHEP2 Output

7831 4077–009 6–175

Application Programming in an HVTIP Environment

The following screen shows an execution of the mixed-mode JMHEP3 transaction.

User input is bolded.

>JMHEP3

This produces the following output on the HOLDPR print queue. Note that the lines
have been numbered here for ease of reference, and that blank lines have been
removed:

1: EMICP, MCB initialized.

2: Transaction code was JMHEP3
3: EM SSEP1 Entry # 1
4: MCBICP calling B$INIT
5: EM MCBSUBA Entry Point MCBEP3: Entry # 001
6: RETURNING from MCBSUBA, MCBEP3
7: MCBICP now calling BMICP
8: *********!!NOW IN THE BASIC MODE ICP!!************
9: COMMON-FIELD-1 is: JMHEP3
10: COM80 is: A message from the EM ICP!
11: COMWHO is: MCBICP
12: Calling R$INIT from BMICP:
13: Calling EM SSEP3 from EM SSEP3_CALLER:
14: In SSEP3 EM FGSS subroutine. Entry # 1 WHO arg is: BM
15: In BM AFCB3: Entry # 0001 PARAM = BM
16: BM AFCB1 Entry # 0001
17: Calling BMSUB
18: In BMSUB: Entry # 0001 PARAM = CALL1
19: EM MCBSUBB Entry # 0001
20: BM AFCB22 Entry # 0001
21: BM AFCB1 Entry # 0002
22: Calling EM SSEP2 from EM SSEP2_CALLER:
23: EM SSEP2 Entry # 1
24: Returning from MCBSUBB now....
25: Returning from BMSUB
26: BM AFCB22 Entry # 0002
27: Calling EM SSEP1 from EM SSEP1_CALLER:
28: EM SSEP1 Entry # 1
29: BMICP now calling EM transaction MCBSUBA

Example 6–39. JMHEP3 Output

6–176 7831 4077–009

 Application Programming in an HVTIP Environment

30: EM MCBSUBA Entry Point MCBEP1: Entry # 001

31: I was called from Basic Mode!!
32: BM AFCB22 Entry # 0003
33: BM AFCB1 Entry # 0003
34: Calling EM SSEP2 from EM SSEP2_CALLER:
35: EM SSEP2 Entry # 2
36: In BMSUB: Entry # 0002 PARAM = EMCALLER
37: EM MCBSUBB Entry # 0002
38: BM AFCB22 Entry # 0004
39: BM AFCB1 Entry # 0004
40: Calling EM SSEP2 from EM SSEP2_CALLER:
41: EM SSEP2 Entry # 3
42: Returning from MCBSUBB now....
43: Returning from BMSUB
44: Calling EM SSEP2 from EM SSEP2_CALLER:
45: EM SSEP2 Entry # 4
46: RETURNING From MCBSUBA:MCBEP1
47: EM MCBSUBA Entry Point MCBEP2: Entry # 001
48: EM SSEP1 Entry # 2
49: RETURNING from MCBSUBA, MCBEP2
50: EM MCBSUBA Entry Point MCBEP3: Entry # 001
51: RETURNING from MCBSUBA, MCBEP3
52: BMSUB2 is now returning to its caller
53: BMICP now starting-off a chain of calls
54: EM MCBSUBA Entry Point MCBEP1: Entry # 001
55: I was called from Basic Mode!!
56: BM AFCB22 Entry # 0005
57: BM AFCB1 Entry # 0005
58: Calling EM SSEP2 from EM SSEP2_CALLER:
59: EM SSEP2 Entry # 5
60: In BMSUB: Entry # 0003 PARAM = EMCALLER
61: EM MCBSUBB Entry # 0003
62: BM AFCB22 Entry # 0006
63: BM AFCB1 Entry # 0006
64: Calling EM SSEP2 from EM SSEP2_CALLER:
65: EM SSEP2 Entry # 6
66: BMSUB2 calling MCBSUBXCL
67: MCBSUBX Entry # 0001
68: BM AFCB1 Entry # 0007
69: BM AFCB22 Entry # 0007
70: In BM AFCB3: Entry # 0002 PARAM = EM
71: EM SSEP1 Entry # 3
72: In SSEP3 EM FGSS subroutine. Entry # 2 WHO arg is: EM
73: TERMINATING MCB FROM MCBSUBX
74: Doing a STOP RUN in MCBSUBX now..

Example 6-39. JMHEP3 Output

7831 4077–009 6–177

Application Programming in an HVTIP Environment

6.1.9. Releasing Subprogram Storage

You can use a transfer-with-cancel statement to release all accumulated subprogram
static storage (HVTIP heap data bank) and automatic storage (ALS storage). Using a
transfer-with-cancel statement frees all the subprogram data storage but retains all
common block storage. The ICP program storage always remains intact.

You may want to use a transfer-with-cancel statement when the ICP is using the
multiple INITAL feature.

The following is an example that shows how to use a transfer-with-cancel statement.

In the example, the multiple INITAL feature is being used in ICP. The ICP has two entry
points: START$ and CANCELALL. A further explanation of this example follows.

Initial Control Program (ICP) Code

PROCEDURE DIVISION WITH ENTRY POINTS CANCELALL.
BEGIN.
TIP Initialization (1)
IMPART.
DMS open
GO TO MESSAGE-PROCESS.
INIT-LOOP.
TIP Initialization
IF no input GO TO END-PROGRAM
MESSAGE-PROCESS
Verify message input
CALL 'SUB'. (2)
FREE WITH MESSAGE TERMINATE.
CALL 'MYCANCELLER'. (3)
CANCELALL.
GO TO INIT-LOOP.
END-PROGRAM.
CLOSE ALL.
DEPART.
TIP termination
STOP RUN.

Explanation
1. The first time the ICP is called, it initializes with TIP, which opens a step. Next, an
IMPART to a DMS 2200 database occurs followed by the first input message being
processed. This processing may include calls to several subprograms.
2. A call to subprogram SUB. During this processing the DMS 2200 database is
accessed and possibly updated. After processing, the database updates are
committed and the active step is closed. This is done with the FREE WITH
MESSAGE TERMINATE command in this example.
3. The ICP calls the subprogram MYCANCELLER, which calls the alternate entry point
in the ICP using an HVTIP transfer-with-cancel function. This alternate entry point
is named CANCELALL. The code at CANCELALL directs the execution flow to the

6–178 7831 4077–009

 Application Programming in an HVTIP Environment

top of the multiple INITAL loop. Then, if any messages are waiting, a new step is
opened and the next message is read and processed.

HVCALLSDEF Element That Is Statically Linked into the ICP

$OBJ
$ASCII
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$RLIB$.CBEP$$EMCALL'
HV$CALL ll,bb,0 'SUB'
. ll=HVTIP library number, bb= bank number
HV$CALL ll,bb,0 'MYCANCELLER'
$END

JUMPVECTOR Element That Is Statically Linked into the ICP

This code identifies the two ICP entry points.

$OBJ
$ASCII
$EXTEND
$INCLUDE 'MAXR$'
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
OM$USE_LV,0
$(1) $BANK HV$CODE_EMB,01000
JUMPER*
HV$VECTOR START$
HV$VECTOR CANCELALL
$END

Static Link for ICP

@USE LINK$PF,SYS$LIB$*APP$n.
(where 'n' is the application group number)
@LINK
OUTPUT HVTIP2
INCLUDE MASM OM of JUMPVECTOR for ICP
INCLUDE compiler OM of ICP
INCLUDE MASM OM of HVCALLSDEF for ICP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
DELETE ALL DEFINITIONS EXCEPT JUMPER
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

Subprogram SUB Code

PROCEDURE DIVISION.
BEGIN.
Perform DMS database updates
EXIT PROGRAM.

7831 4077–009 6–179

Application Programming in an HVTIP Environment

Static Link for SUB

@USE LINK$PF,SYS$LIB$*APP$n.
(where 'n' is the application group number)
@LINK
OUTPUT HVTIP2
INCLUDE compiler OM of SUB
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
DELETE ALL DEFINITIONS EXCEPT SUB
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

Subprogram MYCANCELLER Code

PROCEDURE DIVISION.
BEGIN.
CALL 'CANCELALL'.
STOP RUN.

HVCALLSDEF Element That Is Statically Linked into MYCANCELLER

$OBJ
$ASCII
$INCLUDE 'OM$DEF'
$INCLUDE 'HVTIP$CALLS'
$INCLUDE 'SYS$RLIB$.CBEP$$EMCALL'
HV$XFR$CANCL ll,bb,01003 'CANCELALL'
. ll=HVTIP library number, bb= bank number
$END

Static Link for MYCANCELLER

@USE LINK$PF,SYS$LIB$*APP$n.
(where 'n' is the application group number)
@LINK
OUTPUT HVTIP2
INCLUDE compiler OM of MYCANCELLER
INCLUDE MASM OM of HVCALLSDEF for MYCANCELLER
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
DELETE ALL DEFINITIONS EXCEPT MYCANCELLER
SET ZEROFILL = NONE FOR ALL BANKS
@EOF

6–180 7831 4077–009

 Application Programming in an HVTIP Environment

6.1.10. Creating HVTIP Transaction Programs Greater Than 65K

UCS allows you to create HVTIP transaction programs that have code banks up to
262K in size. Before UCS, HVTIP transaction programs could not be larger than 65K.

An HVTIP ZOOM has by definition only one code bank. All code that is brought into
the static link of the ZOOM, whether by INCLUDE statements or from RESOLVE
statements, is merged together into one extended mode code bank. Also in this code
bank is the template information to initialize the local data and COMMON blocks for
the ZOOM, which are defined as segments in the ZOOM. (HVTIP$$DSEG is the
segment name used for the merged-up bank holding all local data.)

The default generated code from UCS compilations can be merged up to the 262K
architectural limit for code banks. (However, if you use the older EXTENDED/0,
EXTENDED/2, or EXTENDED/4 keyword options, then the code cannot be merged past
65K unless you also use the SEGCODE option.) Code brought into your static links
from the URTS run-time library can generally be loaded at greater than 65K addresses
also. There might be MASM object modules from other products that cannot be
merged at greater than 65K addresses. The static linker will normally automatically
merge banks that cannot be loaded at greater than 65K addresses at less than 65K
addresses so that truncation errors do not occur. You can also control the order of
bank merging to some extent by use of the MERGE_ORDER attributes of HI and LO.
See the discussion on Merging Banks (MERGE) in the Linking System Programming
Reference Manual.

7831 4077–009 6–181

Application Programming in an HVTIP Environment

6.2. Coding, Compiling, and Linking HVTIP

Transactions That Access UDS Databases
UCS HVTIP transactions fully support the interfaces to the UDS database models:
• UCS COBOL and UCS FORTRAN support the interface to DMS 2200 databases in
HVTIP.
• UCS COBOL, UCS FORTRAN, and UCS C all provide access to RDMS 2200
databases in HVTIP. (UCS COBOL and UCS C support both the embedded SQL and
the interpreter SQL interfaces. UCS FORTRAN supports both the module language
SQL and the interpreter SQL interfaces.)
• UCS COBOL, UCS FORTRAN, and UCS C all provide access to SFS 2200 databases
in HVTIP.

For each database interface, there are requirements that are unique to the HVTIP
environment. The following subsections discuss these requirements.

6.2.1. Using DMS 2200 in HVTIP Transactions

The following subsections describe the special requirements that are unique to using
DMS 2200 in the UCS HVTIP environment.

6.2.1.1. Using UDS/TIP Files

When you use DMS 2200, the following can be defined under TIP file control:
• Schema file
• File storage areas
• Subschema file

Note: Using TIP file control eliminates much Exec input/output overhead and
eliminates the need for file assignments. Therefore, it is recommended that DMS
2200 databases that will be accessed by HVTIP transactions be set up using TIP
schema, subschema, and storage area files. This requires setting up a TIP file for
each underlying Exec file.

Schema File
If the schema file is a TIP file, the Data Definition Language (DDL) syntax must identify
the schema as residing in a TIP file. This is accomplished by using the following clause
in the SCHEMA NAME statement:
IN TIP FILE uds-tip-file-code

For more information on coding a DMS 2200 schema that uses TIP areas, refer to the
DMS DDL Administration, Operations, and Programming Guide.

Storage Area Files

If the storage areas are TIP files, you must specify the following clause in each area
definition in the DDL syntax for the schema definition:

6–182 7831 4077–009

 Application Programming in an HVTIP Environment

AREA MAPS TO TIP FILE

Furthermore, the area code for each area definition in the schema must be the same
as the UDS-TIP file number of the TIP file for that area.

For more information on setting up TIP files that will hold DMS 2200 storage areas,
refer to the Repository for ClearPath OS 2200 Administration Guide.

Subschema File
If the subschema file is a TIP file, the Subschema Data Definition Language (SDDL)
syntax must identify the subschema as residing in a TIP file. This is accomplished by
using the following clause in the SUBSCHEMA NAME statement:
IN TIP FILE uds-tip-file-code

For more information on coding a DMS 2200 subschema that uses TIP areas, refer to
the DMS SDDL Administration, Operations, and Programming Guide.

6.2.1.2. Processing Subschemas Used by HVTIP Transactions

Subschemas that are to be used by HVTIP transactions may optionally include the C
option on the Subschema Data Definition processor call (@SDDL). This option
generates S$WORK as a definer common block object module.

When the schema or subschema is to be accessed by more than one subprogram, this
option should be used to facilitate placing S$WORK in common storage. The
programs can be HVTIP, although this is not required. HVTIP programs that will not
use multiple subprograms to access a schema or subschema are not required to use
the C option.

For example, the following statement generates the UCS COBOL subschema
PERSONSUB so that it can be used by HVTIP transactions:
@UDS$$SVN*DMRMT$.SDDL,CDN
QUAL*UCSTST.PERSONSUB,UDS$$SVN*SCHFILE.PERSONSUB

For more information on processing subschemas used by HVTIP transactions, refer to

the DMS SDDL Administration, Operations, and Programming Guide.

6.2.1.3. Coding DMS 2200 HVTIP Transactions

When you code a DMS 2200 HVTIP transaction, the following rules apply:
1. The INVOKE clause may optionally include the following clauses for UCS COBOL:
ENVIRONMENT IS HVTIP

2. The INVOKE clause may optionally include the following clause for UCS FORTRAN:
ENVIRONMENT = HVTIP

The purpose of the ENVIRONMENT clause is to facilitate the placement of the

DMS information into Common-Storage. Placing the DMS information into

7831 4077–009 6–183

Application Programming in an HVTIP Environment

Common-Storage allows the use of subprograms operating in conjunction with

each other to access the same database. The ENVIRONMENT clause is not
required for HVTIP programs if subprograms are not necessary and Working-
Storage is sufficient. The ENVIRONMENT clause can be specified for non-HVTIP
programs to help place the DMS information placed into Common-Storage.
3. When you use the HVTIP ENVIRONMENT clause in the INVOKE clause all storage
must be identified as COMMON. Attempting to copy the DMCA, the record
delivery area, the record descriptions, the data-names, or the generalized names
into anything but COMMON storage results in an error.
4. The INVOKE clause cannot specify the ROLLBACK clause. Depending on the
program specification, errors are handled in one of the following ways:
• By the general error paragraph
• By the syntax ON ERROR GO TO or ERROR =
• Inline
5. Each program module in an HVTIP transaction sequence that references any
COMMON storage requires an identical INVOKE clause, whether or not it contains
any DMS 2200 commands. In addition, all program modules that reference any
COMMON storage must have identical definitions of any user variables in common
storage. This ensures correct COMMON storage referencing.
A sample UCS COBOL INVOKE clause for an HVTIP transaction is as follows:
SUBSCHEMA SECTION.
INVOKE SUBSCHEMA PERSONSUB IN FILE SCHFILE
OF SCHEMA PERSONNEL
ENVIRONMENT IS HVTIP
COPYING RECORDS INTO COMMON
COPYING DATA-NAMES INTO COMMON
RUN-UNIT-ID DSPIND
DMCA IS COMMON
ERROR DMS-GENERAL-ERROR-PARA.

There is one exception: The general error paragraph specification (described in

the following bullet) need not be identical on the INVOKE clauses.
6. If you define a general error paragraph in the INVOKE clause, the program module
must contain the general error paragraph. If the program module contains no
DMS 2200 commands, the general error paragraph need not be specified in the
INVOKE clause.

For more information about using the DMS 2200 data manipulation language in HVTIP
transactions, refer to one of the following, depending on whether you are using UCS
COBOL or UCS FORTRAN:
• DMS CDML Operations and Programming Reference Manual
• DMS FDML Operations and Programming Reference Manual

6–184 7831 4077–009

 Application Programming in an HVTIP Environment

6.2.1.4. Compiling DMS 2200 HVTIP Transactions

If you use any form of the COMPAT compiler keyword option when you compile DMS
2200 COBOL HVTIP transactions, you must use the same form in the initial control
program and in all subprograms that can be called in the transaction sequence.

6.2.1.5. Linking DMS 2200 HVTIP Transactions

When statically linking an HVTIP transaction, if you use the INDEX COMMON BANKS
command, you must specify the name of the subschema common block bank in the
list of common block bank names specified in the command.

For example, in the following command, S$PERSONSUB_$A is the common block bank
name for the definer common block created by the SDDL processor because of the C
option on the @SDDL processor call:
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUB_$A

You can find the name of the subschema common block bank by looking for this bank
in an @LINK,S listing.

When static linking a UDS DMS HVTIP transaction program where the subschema was
produced as a common block bank (the “C” option was used on the SDDL processor
call), the following warning will occur:
*WARNING (LINK 647)* Sizes vary for common block S$subschema-name

This warning can be ignored. It occurs because the UCS compilers are not aware of
the size of the subschema common block bank; therefore, they create a one-word
bank. During static linking, the Linking System detects that the size assigned by the
UCS compilers does not match the actual size of the common block bank. The Linking
Systems then issues the warning message.

7831 4077–009 6–185

Application Programming in an HVTIP Environment

6.2.2. Using RDMS 2200 in HVTIP Transactions

The following subsections describe the special requirements that are unique to using
RDMS 2200 in the UCS HVTIP environment.

6.2.2.1. Using UDS/TIP Files

When you use RDMS 2200, the storage areas can be defined under TIP file control.

Note: Using TIP file control eliminates much Exec input/output overhead.
Therefore, it is recommended that RDMS 2200 databases that will be accessed by
HVTIP transactions be set up using TIP storage areas. This requires setting up a
TIP file for each underlying Exec file.

When you later define the storage areas using UREP, the UDS-TIP-CODE must match
the UDS/TIP file number.

For more information on setting up TIP files that will hold RDMS 2200 storage areas,
refer to the Repository for ClearPath OS 2200 Administration Guide.

6.2.2.2. Coding RDMS 2200 HVTIP Transactions

When you code an RDMS 2200 HVTIP transaction, the following rules apply:
• The RDMS 2200 tables and views must be defined as common storage if they are
to be used across program modules in the transaction sequence. Their definitions
must appear in the initial control program and all subprograms that can be called in
the transaction sequence. These definitions must be identical.
• When you use UCS COBOL or UCS C, embedded SQL commands improve HVTIP
performance, since these commands are parsed at compilation time. SQL
commands specified using the interpreter (nonembedded) interface are parsed
during each execution.
• When you use UCS FORTRAN, module SQL commands improve HVTIP
performance, since these commands are parsed at compilation time. SQL
commands specified using the interpreter interface are parsed during each
execution.
• When you use RDMS 2200 in HVTIP transactions, a call to RSA$INIT must precede
the first RDMS 2200 command in the transaction sequence or execution thread.
This call allocates and initializes all of the space required for the RDMS 2200 work
area. Optionally, it also allows the programmer to specify the size of the work
area. You should make only one call to RSA$INIT within the transaction sequence.
The syntax for this call is as follows:
− UCS COBOL
CALL “RSA$INIT” [USING work-area-size].

− UCS FORTRAN
CALL RSA$INIT [(work-area-size)]

6–186 7831 4077–009

 Application Programming in an HVTIP Environment

− UCS C
rsa_init [(work-area-size)]

(requires #include <rsa.h>)

where work-area-size is a 36-bit binary integer declared in a UCS program as
follows:
− UCS COBOL
PIC 1(36) USAGE BINARY-1

− UCS FORTRAN
INTEGER

− UCS C
int

The default work area provides an initial allocation of 14,000 words. The system
acquires more space dynamically, as needed. The overhead incurred by obtaining
additional space is expensive. Therefore, for HVTIP transactions, you should
determine the amount of space required by the transaction sequence and set
work-area-size accordingly.
For details about how to determine the size of the work area, refer to 3.5.1.
• The following commands are local to the compilation unit; therefore, they must be
coded in each program module that requires their functioning:
− SET STATISTICS
− USE DEFAULT
− WHENEVER
− Cursor declarations (DECLARE CURSOR and ALLOCATE CURSOR) must appear
in the source listing prior to any static embedded SQL reference to the cursor.
• The following commands may produce unpredictable results if they span
compilation units; this is because they require carry-over information in the RDMS
2200 data bank area between calls. The listed precautions will help avoid
problems:
− GETERROR
The GETERROR command must be in all program modules that meet both of
the following conditions:
ο Contain RDMS 2200 commands that can receive errors
ο Must use the GETERROR command for handling error messages

− GET DESCRIPTION
The GET DESCRIPTION command and its corresponding DECLARE CURSOR
command must be in the same program module.

7831 4077–009 6–187

Application Programming in an HVTIP Environment

− FETCH NEXT
The performance shortcut used by the FETCH NEXT command occurs only
when the FETCH command to which it refers is in the same program module.
If the FETCH command to which it refers is not in the same program module,
the FETCH NEXT command still works, but does not take the shortcut.
− DEBUG
The DEBUG command must be in the program module in which debugging is
to occur.

For more information on using SQL in HVTIP transactions, refer to the RDMS SQL
Programming Reference Manual.

6.2.2.3. Compiling RDMS 2200 HVTIP Transactions

If you use any form of the COMPAT compiler keyword option with UCS COBOL, you
must use the same form in the initial control program and in all subprograms that can
be called in the transaction sequence.

6.2.2.4. Linking RDMS 2200 HVTIP Transactions

There are no linking considerations unique to RDMS 2200 HVTIP transactions.

6–188 7831 4077–009

 Application Programming in an HVTIP Environment

6.2.3. Using SFS 2200 in HVTIP Transactions

The following subsections describe the special requirements that are unique to using
SFS 2200 in the UCS HVTIP environment.

6.2.3.1. Using UDS/TIP Files

When you use SFS 2200, the storage areas can be defined under TIP file control.

Note: Using TIP file control eliminates much Exec input/output overhead and
eliminates the need for file assignments. Therefore, it is recommended that SFS
2200 databases that will be accessed by HVTIP transactions be set up using TIP
storage areas. This requires setting up a TIP file for each underlying Exec file.

When you later define the storage areas using UREP, the UDS-TIP-CODE must match
the UDS/TIP file number.

Also, the underlying Exec files must use the qualifier TIP$SFS. If the QUALIFIER
attribute is used in the storage area definition, it must also have the value TIP$SFS.

For more information on setting up TIP files that are to hold SFS 2200 storage areas,
refer to the following documents:
• Repository for ClearPath OS 2200 Administration Guide
• SFS Administration and Support Reference Manual.

6.2.3.2. Coding SFS 2200 HVTIP Transactions

There are no coding considerations unique to SFS 2200 HVTIP transactions.

6.2.3.3. Compiling SFS 2200 HVTIP Transactions

If you use any form of the COMPAT compiler keyword option with UCS COBOL, you
must use the same form in the initial control program and in all subprograms that can
be called in the transaction sequence.

6.2.3.4. Linking SFS 2200 HVTIP Transactions

There are no linking considerations unique to SFS 2200 HVTIP transactions.

7831 4077–009 6–189

Application Programming in an HVTIP Environment

6.2.4. Coding, Compiling, and Linking Multiple Database

Models in HVTIP Transactions
HVTIP transactions can access more than one UDS database model from the same
program. UCS supports all combinations of multiple UDS data models usage (for
example, RDMS 2200 and SFS 2200 together, DMS 2200 and RDMS 2200 together, all
three together, and so forth).

This type of program requires use of BEGIN THREAD and END THREAD commands, no
matter which of the data models are used. The other UDS commands (for example,
the DMS 2200 IMPART and DEPART commands and the SFS 2200 OPEN and CLOSE
commands) must follow the BEGIN THREAD command and precede the END THREAD
command. Specifying the BEGIN THREAD and END THREAD commands is known as
using explicit thread control. Programs that access multiple database models require
explicit thread control.

There are no additional compiling or linking considerations resulting from accessing

multiple database models in the same HVTIP transaction. However, note that the
rules for each separate database model still apply.

6–190 7831 4077–009

 Application Programming in an HVTIP Environment

6.3. Improving HVTIP Transaction Execution-Time

Performance
The following pages offer suggestions for producing HVTIP transaction programs that
provide optimal execution-time performance and efficient memory usage. The topics
covered are as follows:
• Coding suggestions
• Compiling suggestions
• Linking suggestions

6.3.1. Coding for HVTIP Execution-Time Performance

To achieve the best execution-time performance for HVTIP transaction programs,
observe the following suggestions during coding:
• Use embedded SQL for UCS COBOL or UCS C transactions.
If you are using a static database design, code all UCS COBOL and UCS C HVTIP
transaction programs that access RDMS 2200 databases using embedded SQL
commands, rather than the interpreter SQL interface. Embedded SQL commands
are parsed once at compilation time. Interpreter SQL commands are parsed
during each program execution.
• Use module SQL for UCS FORTRAN transactions.
If you plan to use a static database design, code all UCS FORTRAN HVTIP
transaction programs that access RDMS 2200 databases using module language
SQL rather than the interpreter interface. Module Language SQL commands are
parsed at compilation time; interpreter SQL commands are parsed during program
execution.
• Set the RDMS work area size.
For HVTIP transaction sequences that access RDMS 2200 databases, code a call to
RSA$INIT that includes the optional parameter to specify the initial size for the
RDMS work area. By setting the work area size to the size used by the
transaction sequence, you eliminate the overhead of dynamic space acquisition.
Refer to the following for information about RSA$INIT and how to determine the
size of the work area:
− “Coding RDMS 2200 HVTIP Transactions,”
− “Coding for Batch and Demand Execution-Time Performance,”
• Combine frequently called subprograms or subroutines.
Whenever feasible, combine small frequently-called subprograms or subroutines
into a single compilation unit with the initial control program or subprograms that
call them.
• Use the following statement at or near the end of the static links of your HVTIP-II
ZOOMs (linking sources that contain OUTPUT HVTIP2 statements)
SET ZEROFILL = NONE FOR ALL BANKS

7831 4077–009 6–191

Application Programming in an HVTIP Environment

This command results in the uninitialized data areas of your program not being
cleared to zeros when they are loaded, which helps run-time efficiency
considerably. This is especially true for the ICP and for programs that have large
arrays or COMMON blocks.
The default ZEROFILL status for object modules produced by UCS compilations is
− LOAD for local data under $0. The HVTIP$$DSEG segment is always given a
default ZEROFILL status of LOAD, which means that uninitialized local data
areas for HVTIP-II programs are cleared to zeros as a default.
− NONE for COMMON blocks. COMMON block segments always have a default
ZEROFILL status of NONE, which means that uninitialized areas of COMMON
blocks in HVTIP-II programs default to not being cleared to zeros.
Uninitialized user data areas in HVTIP-II programs that are not cleared to zeros are
subject to unknown initial contents in the following situations:
− When a data area released by COBOL CANCEL OR TRANSFER-WITH-CANCEL
is reused by the URTS loader when loading data for an HVTIP-II ZOOM.
− When a TIP RESTART occurs on an HVTIP execution, the contents of the
HVTIP heap banks cannot be assumed to be zeros.
If you wish uninitialized data areas of your programs to be cleared to zeros when
they are loaded, use the following statement in your HVTIP-II static links:
SET ZEROFILL = LOAD FOR ALL COMMON_BLOCK BANKS

You generally do not want to do this:

SET ZEROFILL = LOAD FOR ALL BANKS

This results in the ZEROFILL status for the HVTIP$DBANK “heap” bank of the
HVTIP ICP also having a value of LOAD, which can hurt performance. On a TIP
RESTART, this means that the HVTIP$$DBANK ’heap’ bank and all other heap
banks that are dynamically acquired by the URTS loader will be cleared to zeros by
the loader. This could cost over a hundred thousand CPU cycles per heap bank. It
is usually faster to clear uninitialized areas on a segment basis as needed instead
of clearing whole heap banks up front when they are acquired.

For more information about how to code UCS programs for performance, refer to the
programming reference manual for the appropriate UCS language (for UCS COBOL,
UCS FORTRAN, and UCS C, this information is in Volume 2).

6.3.2. Coding for Efficient Memory Usage

The following discussion is intended primarily for the OUTPUT HVTIP ZOOMs, since
only one small program-level data heap bank is allowed for data processing. This
means that data space is at a premium and must be managed very efficiently. The
suggestions and techniques that follow also apply to the OUTPUT HVTIP2 type ZOOM,
and may be used to conserve data heap space.

Note: Since the HVTIP-II ZOOM also has the potential to operate in a multiple data
heap environment under user control, conserving data heap space in the HVTIP-II
environment is not as critical as in the original UCS HVTIP environment.

6–192 7831 4077–009

 Application Programming in an HVTIP Environment

For HVTIP transaction sequences that use memory efficiently, follow these
suggestions during coding:
• Use the COBOL INITIAL clause
Code all UCS COBOL HVTIP transaction programs using the INITIAL clause. The
INITIAL clause causes all storage defined in the Working-Storage Section to be
allocated as automatic storage. This storage is located on the activity-local stack
(ALS). When the EXIT PROGRAM statement is executed, this storage is released.
Because this storage is allocated on the ALS and not in the HVTIP heap data bank,
the size of the HVTIP heap data bank is decreased.
Refer to “Using the COBOL INITIAL Clause” for more information about using the
INITIAL clause.
• Use the UCS COBOL CANCEL statement
Whenever possible, cancel a UCS COBOL subprogram after it returns to its calling
program. The CANCEL statement causes the release of all local storage belonging
to the canceled subprogram. Release of this storage can be critical to a memory-
tight HVTIP transaction sequence. Consider using HVTIP-II (OUTPUT HVTIP2),
which greatly increases the amount of local storage that is available.
• When coding UCS COBOL programs
− Use the inline PERFORM statement for loops.
− Define all parameters to be passed as 01 level data items and use the
COMPAT/ARGUMENTS compiler keyword option when compiling these
programs.
− Use the SQRT intrinsic function instead of n**.5 to figure square roots.
• When coding UCS C programs
− Use the alternate calling sequence (ACS) instead of the standard calling
sequence (SCS) when C programs call C functions. This can be done by using
the ALT-CALL compiler keyword option for a global effect or by using the
“#pragma alternate function-name” statement for a specific function call.
− Use the “#pragma expand” and the #pragma inline function-name” statements
to expand function calls inline. This will have the greatest effect if:
ο The function is small.
ο The function executes for a short period of time.
ο The function call is in a loop.
• When executing a HVTIP transaction program, an error will occur if the program
exceeds the maximum size of the heap data bank (HVTIP$$DBANK). This bank has
a maximum size of octal 720K words (decimal 237K words) because of its starting
address of 060000. Exceeding this bank’s limits can be avoided by managing the
space used within it. A default size of 010000 words is allotted to this bank for
use by the UCS Runtime System, PCIOS file handling, basic mode SORT
processing, DPS 2200, and RDMS 2200.
If the heap data bank space is tight, you should consider
− Closing PCIOS files when you are finished using them. This releases the space
that they were using.

7831 4077–009 6–193

Application Programming in an HVTIP Environment

− Use the "CALL RSA$INIT” routine to initially allocate all RDMS space so that it
is allocated as contiguous space.
− Use the HVTIP-II feature. HVTIP-II allows you to define as many heap banks as
you may need for your program’s data storage. This also means that you may
be able to remove CANCEL statements that you may currently be using to
help conserve storage. HVTIP-II programs are HVTIP programs that are linked
using an OUTPUT HVTIP2 statement and where special HVTIP-II VALTAB
entries are used for the ICP.

6.3.3. Compiling for HVTIP Execution-Time Performance

To achieve the best execution-time performance for HVTIP transaction programs,
observe the following suggestions during compilation:

• Use the OPTIM compiler keyword option.

The OPTIM keyword option increases the optimization performed by the LSS code
generator, producing code that executes more efficiently. (OPTIM is on by default;
the NO-OPTIM keyword option turns it off.)
• Use the REORDER compiler keyword option.
The REORDER keyword option increases the optimization performed by the LSS
code generator, producing code that is more efficient at execution time.
(REORDER is on by default.)
• Use the COMPAT/ARGUMENTS keyword option.
For UCS COBOL, use the COMPAT/ARGUMENTS keyword option, if you can
guarantee that all parameters are 01 levels. This insures that they are word-
aligned, which permits improved code generation for parameter references.
• Avoid use of the RUNCHECK keyword option.
Avoid use of the RUNCHECK keyword option on production-oriented compilations.
RUNCHECK performs the following functions:
− Subscript range checking on all array references
− Range checking on COBOL reference modification
− Range checking on FORTRAN substring variables
• Avoid use of the CLEAR keyword option
The CLEAR keyword option initializes all uninitialized data to zeros. This function
can be performed more efficiently by program code.
• Use the EXPAND keyword option.
For UCS FORTRAN or UCS C programs, consider using the compiler keyword
option EXPAND for routines that are small and called frequently. This keyword
option causes subprograms or subroutines to be generated inline (that is, inline
expanded at each of their calls).

For more information about these keyword options and other ways to compile UCS
programs for performance, refer to the programming reference manual for the
appropriate UCS language.

6–194 7831 4077–009

 Application Programming in an HVTIP Environment

6.3.4. Linking UCS HVTIP Transactions for Performance

To achieve the best execution-time performance for HVTIP transaction programs,
observe the following suggestions during linking.

The SET SIZE + 0nnnnn FOR URTS$TABLES statement is not valid for HVTIP or HVTIP2
links. In a non-HVTIP FAST LOAD static link, the URTS$TABLES bank segment is
merged last and the URTS heap area is defined by the size of the URTS$TABLES bank
segment. The URTS heap area can then be expanded dynamically to the end of the
bank if more space is needed. Increasing the size of URTS$TABLES during the link will
then increase the size of the static URTS heap area and reduce or eliminate the need
for dynamic bank expansion. In the non-HVTIP case, URTS can redefine the end of the
URTS heap area by determining the upper limit of the bank.

In the HVTIP or HVTIP2 link, the Linking System does not honor the request to merge
the URTS$TABLES bank last, because the HVTIP data heap area is much different than
the standard URTS heap area. Since the URTS$TABLES bank segment is not merged
last, URTS has no dynamic mechanism available to determine the end of the
URTS$TABLES data segment. The URTS heap area is defined by the size of the
URTS$TABLES data segment at assembly time. When that space is not sufficient, the
URTS heap manager must call the HVTIP heap manager to acquire additional space.
The HVTIP heap manager will then dynamically expand the heap bank as needed. In
the HVTIP or HVTIP2 case, you must adjust the size of the HVTIP heap bank
(HVTIP$$DBANK) to prevent dynamic bank expansions. You do not adjust the size of
the URTS$TABLES bank-part.

It is no longer necessary to attempt to conserve D-bank space by setting the size of

HVTIP$$DBANK to the minimum size needed by your code. The 2200 ClearPath
hardware now has virtual memory and paging, and you do not get actual pages for
memory unless your program actually uses it by referencing it. Therefore, it is
recommended that you now set the size of HVTIP$$DBANK to the maximum in the
static link of your ICP. This means that the bank will not have to be expanded at run-
time. (A run-time expansion would inhibit TIP “sticking” and RESTART.) However,
some products might still require that the HVTIP$$DBANK bank not grow past some
limit, in order to honor nonoverlap requirements of basic mode code they have or
make calls to. If you are using one of these products you will have to ensure that
HVTIP$$DBANK does not exceed their limit when you set its size.

7831 4077–009 6–195

Application Programming in an HVTIP Environment

6.3.4.1. Static-Linking with RDMS 2200

When you use interpreted or embedded SQL in your program, RDMS requests work
space using the c malloc function. If there is not enough space available, the run-time
system might perform a MODIFY$BANK to expand a bank, or a CREATE$BANK to
create a new bank to allocate space from. These system calls cause the transaction
to lose its TIP sticking and restart, which affects performance.

Space for the malloc function comes from the main BDI 5 program-level D-bank
HVTIP$$DBANK in an HVTIP transaction where the ICP uses the OUTPUT HVTIP
statement. The space comes from activity-level "pooled" banks in a transaction where
the ICP uses the OUTPUT HVTIP2 statement. So, if your SQL HVTIP program is losing
its TIP sticking and restart, you must address these two cases differently.

Considering the large memories current machines have, you should always set the
size of your HVTIP$$DBANK bank to its maximum possible size in your static link. The
default size given to the HVTIP$$DBANK bank in the static link of the ICP is only large
enough to handle the data segments (HVTIP$$DSEG and COMMON blocks) defined by
the ICP. This size is generally not sufficient to handle other HVTIP segments or run-
time space allocation needs. (If it is not sufficient, the run-time system expands the
size of HVTIP$$DBANK by a MODIFY$BANK call, and TIP sticking and restart are lost
for the transaction.)

The maximum HVTIP$$DBANK size is determined by the starting offset it has (look in
a test static link listing to find this) and the last offset it can have. This last offset is
either 0777777 (the maximum offset a small bank can have) or might be dictated by
the requirements of some basic mode products your program uses, such as DPS or
MCB. You subtract the last desired offset from the starting offset, add 1, and then
supply this size to a SET SIZE statement in your HVTIP link, as shown below. (Put this
statement after your OUTPUT HVTIP or OUTPUT HVTIP2 statement.)

SET SIZE = 0720000 for HVTIP$$DBANK

This statement should be sufficient to regain your TIP sticking and restart for HVTIP
programs where OUTPUT HVTIP is used in the static link of the ICP.

Note: Do not confuse the HVTIP$$DBANK bank in the static link listing with the
URTS$TABLES bank part or the HVTIP$$DSEG segment in the listing. In an HVTIP
ICP static link, URTS$TABLES is only a subportion of the HVTIP$$DSEG segment
that is dynamically loaded at execution time into an HVTIP heap bank. The
HVTIP$$DBANK D-bank is the main heap bank for an HVTIP program.

For OUTPUT HVTIP2 programs, you need to supply one or more activity-level "pooled"
banks to the transaction since malloc space comes from those banks on HVTIP2
programs. You must supply the "pooled" clauses in your OUTPUT HVTIP2 statement
and also must ensure that the banks are there at execution time with DSACTCNT or
DLACTCNT VALTAB clauses supplied to the VTBUTL processor. See 6.5, "HVTIP-II
Environment Details" for details on OUTPUT HVTIP2. Note that for OUTPUT HVTIP2
programs, you should also maximize the size of your BDI 5 HVTIP$$DBANK bank since
that bank is used extensively for other allocations and can be expanded if it isn't big
enough.

6–196 7831 4077–009

 Application Programming in an HVTIP Environment

6.3.4.2. Static Linking with DPS 2200

When you use DPS in an HVTIP transaction sequence, DPS uses space within
HVTIP$$DBANK for its work area. Adding one static link command can improve
performance, by avoiding expansion of HVTIP$$DBANK for DPS during transaction
execution. It is actually easiest just to set HVTIP$$DBANK to its maximum size in the
static link. However, if DPS is still using the basic mode MCB interfaces, then the old
MCB basic mode restrictions would apply. (Check your DPS documentation.) This
may mean that your HVTIP$$DBANK should not grow beyond 0577777. So, to set
HVTIP$$DBANK to this maximum value and to keep it from expanding past that value,
do this in the static link of your ICP:
SET MAX_LIMIT = 0577777 for HVTIP$$DBANK
SET SIZE = 0520000 for HVTIP$$DBANK

However, you can get a more exact size to set for HVTIP$$DBANK if you want to go
to the trouble to do it. During static linking of the initial control program, you should
set the size for HVTIP$$DBANK to reflect the default size, plus the size obtained by
calling the DPS 2200 HELPER processor.

Example 6–40 shows the HELPER output for the DPS 2200 software in file APP3*DPS,
used in examples in this section. Noteworthy lines are bolded.

@APP3*DPS.HELPER
HELPER R1A APP3-DPS DPS Helper Utility Processor 1997 Jun 26 Thu 1450:31

RES 2102,478400,28,$$TERMFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE TERMINAL FILE MUST BE 7475 TRACKS

RES 2105,200,112,$$PASSFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PASSWORD FILE MUST BE 13 TRACKS

RES 2103,5001,2016,$$PAGEFILE$$,EXECFILE,NREC,AUDIT=0
THE SIZE OF THE PAGING FILE MUST BE 5627 TRACKS

** IF ONE EXECFILE CONTAINS THE TERMINAL, PASSWORD AND PAGING FILE,

THE SIZE OF THE EXECFILE MUST BE 13115 TRACKS

RES 2108,126000,28,ALT$SCRNFILE,ALT$SCRNFILE,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS

Example 6–40. Output of DPS HELPER Processor

7831 4077–009 6–197

Application Programming in an HVTIP Environment

RES 2109,126000,28,FORMS,FORMS,NREC,AUDIT=0
THE SIZE OF THIS FORM LIBRARY MUST BE 1969 TRACKS
DPS MEMORY USAGE REQUIREMENTS

ACOB, FTN, PL1 -

RUNTIME BLOCK SIZE: 9902 DECIMAL WORDS
D$DEF BLOCK SIZE: 9956 DECIMAL WORDS

UCS - RUNTIME BLOCK SIZE: 10048 DECIMAL WORDS

UCS - D$DEF BLOCK SIZE: 9984 DECIMAL WORDS
UCS - PARAM BLOCK SIZE: 5376 DECIMAL WORDS
UCS/INTERFACE data bank size requirements:

DYNAMIC link without D$DEFs 15424 DECIMAL WORDS

DYNAMIC link with D$DEFs 25408 DECIMAL WORDS
STATIC link without D$DEFs 10048 DECIMAL WORDS
STATIC link with D$DEFs 20032 DECIMAL WORDS
.
. (additional lines).

Example 6–40. Output of DPS HELPER Processor

Using this output, perform the following steps:

1. In the DPS HELPER output, locate the information with the following title:
UCS/INTERFACE data bank size requirements:

2. Below this are four lines of output. The third and fourth lines apply to static
linking:
• If D$DEF routines are used in the program, refer to the fourth line.
• Otherwise, refer to the third line.
3. Take the size shown on the appropriate line and use it in a static linking SET SIZE
command for the initial control program, as follows:
SET SIZE = SIZE + dps-helper-size FOR HVTIP$$DBANK

4. where dps-helper-size is the size indicated in the HELPER output.

For this example, assuming that the HVTIP transaction sequence does not use D$DEF
routines, use the following command in the static link of the initial control program:
SET SIZE = SIZE + 10048 FOR HVTIP$$DBANK

Note: The SET SIZE command must follow the RESOLVE command. If your DPS
HVTIP program fails due to insufficient memory, consider using OUTPUT HVTIP2 in
the ICP static file. The HVTIP-II environment allows for more than one D-bank to
get space from. See 6.5, "The HVTIP-II Environment Details", for more information.

6–198 7831 4077–009

 Application Programming in an HVTIP Environment

6.3.4.3. HVTIP ZOOM Structure

The following discussion is intended primarily for the OUTPUT HVTIP or PROCESS FOR
EXTENDED HVTIP ZOOMs since only one small program level data heap bank is
allowed for data processing. The HVTIP-II environment retains the small program-level
heap bank but also allows additional heap banks to be used with an HVTIP-II ZOOM.
This section does not discuss any data heap banks beyond the first (main) program-
level heap bank.

Further discussion of performance linking of an HVTIP transaction sequence requires

some background information.

An HVTIP transaction sequence consists of both

• The initial control program
• All of the subprograms that can be called directly or indirectly from this initial
control program

Depending on functional requirements, any execution of an HVTIP transaction using

this initial control program can include either
• The entire transaction sequence
• Just a part of the sequence, with only certain subprograms being called

In a very simple case, the transaction sequence can consist of an initial control
program and one subprogram, as follows:
• When the HVTIP transaction code is entered, followed by good data, the initial
control program is executed.
• The initial control program, in turn, calls the subprogram.
• The subprogram completes its processing and returns to the initial control
program.
• The initial control program sends output back to the terminal.
• Processing terminates.

This first transaction execution uses the entire transaction sequence, and is illustrated
by the following figure.

7831 4077–009 6–199

Application Programming in an HVTIP Environment

A second execution, in which bad data is input, uses only the initial control program.
The subprogram is not called. The initial control program
• Detects the incorrect data
• Sends an error message to the terminal
• Terminates the transaction

This is an example of using a subset of the transaction sequence, as illustrated by the

following figure.

The preceding example of a transaction sequence includes two zero overhead object
modules (ZOOMs):
• The initial control program, ICP
• The subprogram, SUBPROG

Each of these HVTIP ZOOMs consists of two bank groups:

• All the code and data resides in a bank group called HVTIP$$GROUP.
• The second bank group, HVTIP$$SEGS, is for documentation purposes only.

HVTIP$$GROUP
This bank group contains all of the actual text of an HVTIP ZOOM. It contains two
banks, HVTIP$$CODE and HVTIP$$DBANK:
• HVTIP$$CODE is a single code bank containing the text of all of the code, data, and
common block banks of the object modules supplied to the static linking process.

When the LINK Processor produces an HVTIP ZOOM, it

• Merges all code banks in the input object modules into a single code bank
• Merges all data banks into a single data segment
• Creates a common block segment for each common block in creating
HVTIP$$CODE
• The LINK Processor assigns BDI 4 to HVTIP$$CODE. This is required by HVTIP
execution.

6–200 7831 4077–009

 Application Programming in an HVTIP Environment

The following diagram represents two object modules being linked together to
form the HVTIP$$CODE portion of the HVTIP ZOOM for the initial control program
ICP:
− The code banks for the two object modules become the code bank portion of
HVTIP$$CODE.
− The two data banks become the data segment in HVTIP$$CODE.
− Each unique common block bank becomes a common block bank segment in
HVTIP$$CODE.
This same process also occurs when you statically link subprograms.

• HVTIP$$DBANK is an uninitialized data bank that represents the main storage

HVTIP heap data bank. The LINK processor assigns BDI 5 to this bank as required
by HVTIP execution. This bank is created by the OS 2200 operating system at load
time; it is where the URTS HVTIP loader loads the data segments for your HVTIP
ZOOMs during HVTIP program execution. The HVTIP$$DBANK that is in the ICP
ZOOM is the one whose attributes are used by the Exec when the transaction is
started.
The static linker currently gives this bank a default starting address of 01000 less
than the HVTIP$$DSEG address in the ICP. Unless your ICP static link has SET
LOWADR statements that force other starting addresses, this means that
HVTIP$$DBANK usually starts at 057000. Its size will be just a little larger than
the size required to handle the segments (HVTIP$$DSEG and common blocks) of
the ICP. If you want it to be larger so that it can also accommodate the storage
needs of your HVTIP subprograms, you should do a SET SIZE = xxxxxx FOR
HVTIP$$DBANK statement in the static link of your ICP.

7831 4077–009 6–201

Application Programming in an HVTIP Environment

You may also set the LOWADR of HVTIP$$DBANK if you wish. It defaults to
01000 less than the HVTIP$$DSEG LOWADR, so it usually is at 057000. However,
it could be set down to as low as 045000 to gain a little more space if you wish.
Just remember that the lower you set it the more likely it will be to overlap some
basic mode code space and have things stop working.

HVTIP$$SEGS
This bank group is for documentation purposes only (It is also very useful when
debugging to see where things were allocated.) In a long listing from a static link of an
HVTIP ZOOM, HVTIP$$SEGS includes descriptions of the segments whose text
resides within HVTIP$$CODE, as if those segments were still separate banks.
HVTIP$$SEGS describes
• The data segment holding all noncommon data for the ZOOM (called
HVTIP$$DSEG)
• All common block segments

This description includes the address range of each segment (bank); this information is
critical for debugging.

6.3.4.4. HVTIP Transaction Execution

Considering this structure of an HVTIP ZOOM, the following defines HVTIP$$CODE for
the example initial control program ICP and subprogram SUBPROG.

HVTIP$$CODE for the initial control program ICP consists of

• Text for the code to be executed, including the HVTIP subprogram and any run-
time routines that were linked in with it
• Text to initialize the HVTIP$$DSEG local data for the ICP
• Text to initialize the two common block banks (COMMON BLOCK BANK 1 and
COMMON BLOCK BANK 2)

6–202 7831 4077–009

 Application Programming in an HVTIP Environment

HVTIP$$CODE for the subprogram SUBPROG consists of

• Text for the code to be executed, including the HVTIP subprogram and any run-
time routines that were linked in with it
• Text to initialize the HVTIP$$DSEG local data for the subprogram
• Text to initialize the two common block banks (COMMON BLOCK BANK 1 and
COMMON BLOCK BANK 2)

Note that common blocks are only initialized when they are initially allocated by the
URTS HVTIP loader. When a subprogram is loaded that also defines an existing
common block, the common block is not reinitialized, the subprogram is simply linked
to the existing copy. Therefore, all initial values for COMMON blocks should be given
in the ICP.

An S-option static link listing will show that the extent of the HVTIP$$CODE bank is
well beyond the limits of the last code bank-part that is linked in. This area at the end
holds the loading and initialization information for the segments defined in the HVTIP
ZOOM.

This example can demonstrate what happens when an HVTIP transaction is executed.
The following diagrams illustrate the execution of the example transaction sequence.

When the HVTIP transaction code is entered, the initial control program ICP is loaded
as follows:
• HVTIP$$CODE for the initial control program is loaded into the bank designated by
program local BDI 4.
• The uninitialized bank HVTIP$$DBANK is made available at program local BDI 5.
• The ICP data segment is copied from HVTIP$$CODE (BDI 4) to HVTIP$$DBANK
(BDI 5).
• The ICP common block bank 1 segment is copied from HVTIP$$CODE (BDI 4) to
HVTIP$$DBANK (BDI 5).
• The ICP common block bank 2 segment is copied from HVTIP$$CODE (BDI 4) to
HVTIP$$DBANK (BDI 5).

7831 4077–009 6–203

Application Programming in an HVTIP Environment

If any other common block banks were part of the initial control program, they would
also be copied from HVTIP$$CODE (BDI 4) to HVTIP$$DBANK (BDI 5).

If the subprogram SUBPROG is called by the initial control program, the following
occurs:
• HVTIP$$CODE for the subprogram is loaded into the BDI 4 bank, replacing
HVTIP$$CODE for the initial control program.
• The subprogram data segment is copied from HVTIP$$CODE (BDI 4) to
HVTIP$$DBANK (BDI 5).
• If the subprogram contains any common block bank segments that have not been
previously encountered, each is copied from HVTIP$$CODE (BDI 4) to
HVTIP$$DBANK (BDI 5).
In this example, all common blocks have already been loaded by the initial control
program. Because of this, no common block bank segments are loaded when the
subprogram is called.

When the OS 2200 operating system creates the HVTIP$$DBANK bank and the UCS
Runtime System loads each of the segments within HVTIP$$DBANK, the starting
address of the HVTIP$$DBANK bank and each segment within this bank is referred to
as its LOWADR.

In the HVTIP links up to this point, LOWADR values have been automatically set by the
static linking process. This discussion provides background so that you can adjust
these LOWADR settings for more efficient use of space.

6–204 7831 4077–009

 Application Programming in an HVTIP Environment

As segments are loaded into the HVTIP$$DBANK “heap” bank, the UCS Runtime
System loads the segments at the address specified by the LOWADRs they received
in the static link of the HVTIP ZOOMs, if possible. In the following cases, this is not
possible:
• If segments have overlapping addresses (for example, two segments both have
LOWADRs of 070000).
• If the LOWADR of HVTIP$$DBANK has been adjusted through special LINK
commands; this can override the LOWADRs of the segments that are loaded into
HVTIP$$DBANK.
• If segments have so much empty space between them that loading at the
specified LOWADRs would waste a significant amount of space.

In these cases, the LOWADR is ignored. Instead, the segments are loaded at the next
available locations. This is known as relocation. Relocation is not desirable from a
performance standpoint. However, to eliminate all run-time relocation of your DATA
and COMMON block segments can be a significant amount of work, and may have to
be completely redone if even minor changes occur in segment sizes in the application.
In addition, complex execution paths through your subprograms may make it almost
impossible to come up with a segment address layout that will fit all situations. It may
not be worthwhile to take the effort to attempt to eliminate the run-time relocation.

6.3.4.5. Space Optimization

Using the information just presented, this subsection suggests how to link your HVTIP
transaction program sequences so that
• Common blocks are referenced in the most efficient manner.
• Overlapping addresses are avoided so relocation does not occur.
• Space is not wasted.

It is assumed that you have already applied the techniques described previously in this
section for performance coding and linking.

Your application can contain many different HVTIP transaction execution paths. After
reading this subsection, you may want to apply some of these techniques to each ICP
and all of its subprograms. You may want to apply some techniques only to the high-
priority execution paths in the transaction sequences. Remember that your
transactions will execute successfully without applying any of these techniques.

The basic principle is that the segments (HVTIP$$DSEGs and common blocks) from
each of the HVTIP static links must not have overlapping addresses. Since the static
linker does not know what segment addresses (LOWADRs) have been assigned in
other static links, the segment addresses will definitely overlap unless something is
done about it. The ICP is the only static link where the segment addresses will not
overlap. This is because it is loaded first and gets preference. The segments defined
in the ICP will be loaded at their statically-linked addresses unless the HVTIP$$DBANK
bank supplied at run-time does not have the same address range as the one in the ICP
static link. (It can be overridden with VALTAB settings.)

7831 4077–009 6–205

Application Programming in an HVTIP Environment

Simple Method
If all the common blocks are defined in the ICP link, you can get their starting
addresses from an S-option output of the static link of the ICP. Then you can supply
SET LOWADR statements for them in an ADD element, giving those offsets. It may
be preferable to “pad” these a bit, so that minor changes in sizes of the ICP DSEG or in
the common block sizes do not result in a new set of LOWADRs being needed. You
should also probably put the following statement in the ADD element to ensure that all
of the SET LOWADRs are honored by the HVTIP loader:
SET RELOAD_SKIP_SIZE=0777000

Use this ADD element in an ADD statement in all of your HVTIP links, including the ICP.
As far as the HVTIP$$DSEG (and other common block) addresses for your HVTIP
subprograms, just do a SET LOWADR statement in each HVTIP link to set the segment
addresses to an open spot, again leaving some “pad” for growth on each. Look at the
output of an initial static link for each HVTIP ZOOM to see what the extent of the
HVTIP$$DSEG segment is so you can leave enough room. (Do the same for any
additional common blocks they may define that the ICP did not have.) Just remember
that if you do it wrong and some segments overlap, it will all work fine anyway, you
will just incur some relocation costs at run-time. It is also best to set the SIZE of the
HVTIP$$DBANK “heap” bank in the ICP static link to the maximum that it can be for
your transaction so that a run-time expansion will not be needed. This generally
brings it out to a MAX_LIMIT of 0777777, though you might want to clamp it at
0577777 for DPS programs.

Complex Method
However, if you want to set up your segment addresses the hard way, just perform
the following process. To obtain the information to apply the techniques discussed in
this subsection, you must obtain a DIAG dump, which is then processed by a PADS
procedure supplied by Unisys. This procedure is discussed later.

6–206 7831 4077–009

 Application Programming in an HVTIP Environment

6.3.4.6. Example Application

An expanded example demonstrates this technique. The expanded UCS COBOL
example uses DPS 2200 and accesses a DMS 2200 database. The same techniques
shown in this example apply regardless of the UCS language or transaction processing
interface used.

The initial control program is called DMSICP. The subprogram is called DMSSUB. One
input to this transaction sequence is the transaction code DMSHVT followed by an
employee number (for example, DMSHVT 10211). The processing sequence for this
input is as follows:

Step Program Actions

1 DMSICP Initializes using DPS

Reads the employee number input
Validates the employee number
Imparts to a DMS database
Calls the subprogram DMSSUB
2 DMSSUB Retrieves data from the DMS database
using the employee number
Opens a DPS form
Moves the DMS data into the DPS form
Displays the DPS form on the terminal
Returns to the initial control program
DMSICP
3 DMSICP Departs from the DMS database
Terminates using DPS

7831 4077–009 6–207

Application Programming in an HVTIP Environment

This transaction sequence has been function tested. The following performance aids
have already been applied:
• Coding
The INITIAL clause was added to both the initial control program DMSICP and the
subprogram DMSSUB.
• Compiling
The OPTIM and REORDER keyword options were used when compiling both the
initial control program DMSICP and the subprogram DMSSUB.
• Linking
The size of HVTIP$$DBANK was increased to accommodate the use of DPS. This
was accomplished by adding a SET SIZE FOR HVTIP$$DBANK command to the
static link of the initial control program DMSICP.

6–208 7831 4077–009

 Application Programming in an HVTIP Environment

For this example, the linking runstream for the initial control program is as follows:
@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR HVTIP$$DBANK
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

The linking runstream for the subprogram is as follows:

@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSSUB
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSSUB/COMP
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT DMSSUB
@EOF

To continue the optimization process, you must collect information by executing the
transaction DMSHVT, producing a diagnostic dump in the process. The following
describes how to produce and process this dump.

7831 4077–009 6–209

Application Programming in an HVTIP Environment

Step 1: Produce a Diagnostic Dump

Temporarily insert a call command that will create a DIAG dump, just prior to the MCB
or DPS termination command in the transaction execution path. These calls are as
follows:

UCS COBOL
CALL 'FERR'.

UCS FORTRAN
CALL FERR

UCS C
ferr();

Note: If this dump occurs after a UCS COBOL CANCEL statement or an HVTIP
transfer-with-cancel function, information about the canceled HVTIP$$DSEG
segments is lost.

In the example, this call would be placed in the initial control program DMSICP just
before the call to ’D$TERM’, as follows:

IDENTIFICATION DIVISION.
.
.
PROCEDURE DIVISION.
.
.
CALL 'D$INIT'....
.
reads input message
validation of input
.
IMPART.
CALL 'DMSSUB'.
DEPART.
CALL 'FERR'.
CALL 'D$TERM'....
STOP RUN.

6–210 7831 4077–009

 Application Programming in an HVTIP Environment

Step 2: Recompile
Recompile the portion of the transaction sequence to which you added this call.

Step 3: Relink
Relink the part of the transaction sequence that contains this call.

Step 4: Set Options

To produce the DIAG dump, both of the following must be true:
• The VALTAB for this transaction code must have “T” included in the OPTIONS
parameter, so that a DIAG dump is produced when the abort call is encountered.
• TIPTRACE in the TIP FLAGBOX must be set to ON.
Step 5: Execute
Depending upon your site setup, refer to the appropriate subsection that follows:
• If you have access to the operator console or a terminal that can be placed in
CONS MODE (@@CONS), refer to “Executing with Console Output.”

• If you do not have access to the operator console output, refer to “Executing
without Console Output.”

Executing with Console Output

You must sign on with a user-id that has CONSOLE MODE set to DISPLAY. (This user-
id attribute is set using SIMAN.)

In the following steps, user input is bolded.

1. Execute the transaction while watching the operator console output. When the
transaction aborts, the following message is displayed:
*TIP DIAG$ FILE CREATED - TIPDIAG$*xxxxxxnnnnn

where
nnnnn
is the generated id for this execution of the transaction.
xxxxxx
is the transaction name that errored.
TIPDIAG$*xxxxxxnnnnn
is the name of the DIAG file which contains the dump for this execution of the
transaction.
When this example is executed, a message like the following is received:
*30JVL**TIP DIAG$ FILE CREATED - TIPDIAG$*DMSICP30JVL

7831 4077–009 6–211

Application Programming in an HVTIP Environment

2. Call PADS. Supply the DIAG dump file name on the processor call, as in the
following example:
@pads diag,tipdiag$*dmsicp30jvl.

3. Request the first DIAG dump file entry for this transaction execution.
# CMD > select first diag entry

4. Add (@ADD) the PADS procedure HVTIP$INFO, found in the file SYS$LIB$*URTS:
# CMD >@add sys$lib$*urts.hvtip$info
# CMD >HVTIP$INFO pl(5)

This procedure
• Provides the size of the ALS
• Detects run-time relocation
• Produces a report on the addresses for the data banks and the common block
banks

6–212 7831 4077–009

 Application Programming in an HVTIP Environment

The following is a sample of this process using the example transaction. User input is
bolded.

@pads diag,tipdiag$*dmsicp30jvl.
PADS 8R2 1997-02-21 1252:35
.
. (system output)
.
# CMD >select first diag entry
# CMD >@add sys$lib$*urts.hvtip$info
# CMD >HVTIP$INFO pl(5)
# *********************************************************************
# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
#
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#
# The Currently Allocated Heap Data Segments:
# Seg LLBBBB EM Start End
# Numb BDI Address Address
# 0000 020001 0400005 => 0047005 - 0122510
# 0001 020002 0400005 => 0153246 - 0154111
#
# Common Blocks:
# Common Blocks are Named (Indexed would be more optimal).
# Seg LLBBBB EM Start End Common Block
# Numb BDI Address Address Name
# 0000 020001 0400005 => 0122511 - 0124007 $BLANK$COMMON$
# 0000 020001 0400005 => 0124010 - 0124743 S$PERSONSUBTIP_$A
#
# These HVTIP ZOOMs have been referenced
# (and have not been CANCELed):
# Seg # LLBBBB Received Control as
# 0000 020001 ICP (Main prog)
# 0001 020002 HVTIP Subroutine
# *********************************************************************
# CMD >exit pads

You can use the output from this procedure to

• Adjust the addressing of the data segments in HVTIP$$DBANK
• Set the size of HVTIP$$DBANK
• Index the common blocks

7831 4077–009 6–213

Application Programming in an HVTIP Environment

Executing Without Console Output

If you do not have access to the operator console output, execute the transaction
according to the following steps. In these steps, user input is bolded.
1. Execute the transaction.
2. When the transaction completes, call PADS (@PADS) using the TIPDIAG keyword,
followed by the application group number on the processor call.
In the following example, application group 3 is specified. (If the application group
number is omitted, application group 1 is assumed.)
@pads tipdiag,3

After successful activation, PADS responds with the current number of entries in
the TIP error history file. There are one or more entries for each transaction
execution that errors and produces a DIAG dump.
The following is an example of this PADS output.
PADS 10R1 1997-02-21 1222:10
# Application 3 TIP Error History File contains 566 entries.

3. Locate the diagnostic information for your specific transaction execution. There
are several PADS commands you can use to accomplish this. The following are
examples:
• The following example command lists the last six entries with the transaction
code DMSHVT. You must enter the transaction code in capital letters.
# CMD >tiplog$code$ 'DMSHVT',6

• The following example command lists the last six entries created on February
21, 1997 (970221) with transaction code DMSHVT. You must enter the
transaction code in capital letters.
# CMD >tlog$search$ " tiplog.error_date (i) = '970221' and " !! %
#CMD > " tiplog.transaction_code (i) = 'DMSHVT' ",6

• The following command lists the last six entries created after 10:00 AM
(100000) on February 21, 1997 (970221) with transaction code DMSHVT. You
must enter the transaction code in capital letters.
# CMD >tlog$search$ " tiplog.error_date (i) = '970221' and " !! %
# CMD > " tiplog.error_time (i) > '100000' and " !! %
# CMD > " tiplog.transaction_code (i) = 'DMSHVT' ",6

Each of these queries produces a report on six or fewer entries that match the
criteria supplied. Look at the date (ERROR_DATE) and time (ERROR_TIME) on each
entry to select the entry for the time when you executed the transaction.

Often, one transaction execution produces multiple consecutive entries within the
TIP error history file. You can identify entries for the same execution by checking
for the same value in the FILENAME=TIPDIAG$*filename field. You want the
oldest of these entries; this is the entry with the highest TIPLOG number. To
confirm this, check the values in the ERROR_TIME field for the entries.

6–214 7831 4077–009

 Application Programming in an HVTIP Environment

The following is a sample of the output for two entries for the same transaction
execution. The TIPLOG(4) entry is the one you want to interrogate further. The
shaded fields provide the information that is important to you.
# TIPLOG(3)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=0T CONTINGENCY_TYPE=2T ERROR_TYPE=0T ERROR_CODE=14T
# ERROR_AUX_INFO=21T ERROR_ID=34001000311T ERROR_DATE=970221
ERROR_TIME=
# 122100 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVL.
# TIPLOG(4)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=202172004606 CONTINGENCY_TYPE=12T ERROR_TYPE=3T
ERROR_CODE=0T
# ERROR_AUX_INFO=0T ERROR_ID=34001001757T ERROR_DATE=970221
ERROR_TIME=
# 122059 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVL.

4. Now that you know which TIPLOG entry reflects your transaction execution, issue
a TDIAG$ command to PADS, supplying the TIPLOG number. This command is as
follows for the example:
# CMD >tdiag$ 4

5. Add (@ADD) the PADS procedure HVTIP$INFO, found in the file SYS$LIB$*URTS.
# CMD >@add sys$lib$*urts.hvtip$info
# CMD >HVTIP$INFO pl(5)

This procedure
• Provides the size of the ALS
• Detects run-time relocation
• Produces a report on the addresses for the data banks and the common block
banks

7831 4077–009 6–215

Application Programming in an HVTIP Environment

The following is a sample of this process using the example. User input is bolded.
@pads tipdiag,3
PADS 10R1 1997-02-21 1222:10
# Application 3 TIP Error History File contains 566 entries.
# CMD >tlog$search$ " tiplog.error_date(i) = '970221' and " !! %
# CMD > " tiplog.error_time(i) > '100000' and " !! %
# CMD > " tiplog.transaction_code(i) = 'DMSHVT' ",4
# TIPLOG(3)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=0T CONTINGENCY_TYPE=2T ERROR_TYPE=0T ERROR_CODE=14T
# ERROR_AUX_INFO=21T ERROR_ID=34001000311T ERROR_DATE=970221 ERROR_TIME=
# 122100 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVL.
# TIPLOG(4)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=202172004606T CONTINGENCY_TYPE=12T ERROR_TYPE=3T
# ERROR_CODE=0T
# ERROR_AUX_INFO=0T ERROR_ID=34001001711T ERROR_DATE=970221 ERROR_TIME=
# 122059 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVL.continued
# TIPLOG(10)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=0T CONTINGENCY_TYPE=2T ERROR_TYPE=0T ERROR_CODE=14T
# ERROR_AUX_INFO=21T ERROR_ID=34001000311T ERROR_DATE=970221 ERROR_TIME=
# 095201 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVK.
# TIPLOG(11)
# PROGRAM_NAME=DMSICP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=202172004606T CONTINGENCY_TYPE=12T ERROR_TYPE=3T
# ERROR_CODE=0T
# ERROR_AUX_INFO=0T ERROR_ID=34001001757T ERROR_DATE=970221 ERROR_TIME=
# 095200 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=20001T
# FILENAME=TIPDIAG$*DMSICP30JVK.
# CMD >tdiag$ 4
# PROGRAM_NAME=DMSCIP TRANSACTION_CODE=DMSHVT
# ERROR_INFO
# ERROR_VA=202172004606T CONTINGENCY_TYPE=12T ERROR_TYPE=3T
# ERROR_CODE=0T
# ERROR_AUX_INFO=0T ERROR_ID=34001001757T ERROR_DATE=970221 ERROR_TIME=
# 122059 ERROR_INS=0T
# TIP_INFO
# PID=734T TIP_TYPE=transaction HVTIP_LIB_BANK=200001T
# FILENAME=TIPDIAG$*DMSICP30JVL.
# Diagnostic file from runid: *30JVL
.
. (the remainder of output from tlog$search$ command) .
# CMD >@add sys$lib$*urts.hvtip$info
# CMD >HVTIP$INFO pl(5)
# *********************************************************************

6–216 7831 4077–009

 Application Programming in an HVTIP Environment

# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#
# The Currently Allocated Heap Data Segments:
# Seg LLBBBB EM Start End
# Numb BDI Address Address
# 0000 020001 0400005 => 0047005 - 0122510
# 0001 020002 0400005 => 0153246 - 0154111
#
# Common Blocks:
# Common Blocks are Named (Indexed would be more optimal).
# Seg LLBBBB EM Start End Common Block
# Numb BDI Address Address Name
# 0000 020001 0400005 => 0122511 - 0124007 $BLANK$COMMON$
# 0000 020001 0400005 => 0124010 - 0124743 S$PERSONSUBTIP_$A
#
# These HVTIP ZOOMs have been referenced
# (and have not been CANCELed):
# Seg # LLBBBB Received Control as
# 0000 020001 ICP (Main prog)
# 0001 020002 HVTIP Subroutine
# *********************************************************************
# CMD >exit pads

You can use the output from this procedure to

• Adjust the addressing of the data segments in HVTIP$$DBANK
• Set the size of HVTIP$$DBANK.
• Index the common blocks

For more information about how to use PADS commands, refer to the PADS
Programming Guide.

6. Remove the abort call from the transaction sequence after receiving the required
information.

6.3.4.7. Setting the Initial Size of the Activity-Local Stack (ALS)

The ALS is where all automatic program storage resides. Automatic storage is used
internally by the UCS Runtime System and externally by certain user-defined variables.
UCS COBOL, UCS FORTRAN, and UCS C provide methods for the programmer to
define storage as automatic:
• In UCS COBOL, you define working storage as automatic by including the INITIAL
clause in the PROGRAM-ID statement. All working storage is automatic and is
placed on the ALS.
• In UCS FORTRAN, local variables without initial values are placed on the ALS if the
MIN-DBANK keyword option is used on the compilation.
• In UCS C, all storage defined as automatic is always placed on the ALS.

7831 4077–009 6–217

Application Programming in an HVTIP Environment

The UCS compilers also use the ALS for temporary storage. When you enter a
routine, ALS storage for temporary use and for user variables is bought. When you
exit a routine (RETURN), the storage is released. The ALS is a stack and it is a push-
pop operation. Note that the ALS grows from high addresses to low address,
backwards.

The maximum size of the ALS defaults to 0700000. You can change this with a static
linker SET ALS_MAX_SIZE command, but this is not recommended. You cannot
increase it to greater than 0700000, and it serves no purpose to lower it. If you lower
the ALS max size too much, some software may no longer work. The ALS is used by
virtually all extended mode code. The default initial size of the ALS is 010000 words.
You may wish to increase this initial size so that a run-time expansion is not
necessary. It might be wise to not increase it past a size of 0600000 (resulting in a
lower limit of 0100000) so that it does not overlap basic mode code address space. A
recommended value would be 0400000. :
SET ALS_INIT_SIZE = 0400000

6.3.4.8. Indexing Common Block Banks

The static linking INDEX command gives a common block bank an internal index
number. This number allows the UCS Runtime System to identify and load (or link to)
a common block bank more efficiently than if it uses the name of the common block
bank. As a result, performance is improved.

If the INDEX command is used, every possible program in the transaction sequence
(the initial control program and all its subprograms) must contain the identical INDEX
command. All programs must list every common block bank in the transaction
sequence in the exact same order, whether the program contains that common block
bank or not.

An INDEX command can contain up to 200 common block bank names; however,
multiple INDEX commands may be used.

Note: There is a limit of 4095 common block banks that can be indexed.

The format for the INDEX command is as follows:

INDEX COMMON BANKS com_blk_bank1, com_blk_bank2

You should place this INDEX command after the RESOLVE command and before the
DELETE ALL DEFINITIONS command in each static link.

By looking at the PADS procedure output, you can tell if the common block banks are
indexed. If not, the PADS procedure prints the names.

6–218 7831 4077–009

 Application Programming in an HVTIP Environment

The following is sample output from the PADS procedure.

# *********************************************************************
# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
#
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#
# The Currently Allocated Heap Data Segments:
# Seg LLBBBB EM Start End
# Numb BDI Address Address
# 0000 020001 0400005 => 0047005 - 0122510
# 0001 020002 0400005 => 0153246 - 0154111
#
# Common Blocks:
# Common Blocks are Named (Indexed would be more optimal).
# Seg LLBBBB EM Start End Common Block
# Numb BDI Address Address Name
# 0000 020001 0400005 => 0122511 - 0124007 $BLANK$COMMON$
# 0000 020001 0400005 => 0124010 - 0124743 S$PERSONSUBTIP_$A
#
# These HVTIP ZOOMs have been referenced
# (and have not been CANCELed):
# Seg # LLBBBB Received Control as
# 0000 020001 ICP (Main prog)
# 0001 020002 HVTIP Subroutine
# *********************************************************************

The line “Common Blocks are Named (Indexed would be more optimal)” tells you that
the current static links do not use the INDEX command. If the INDEX command were
being used, this line would read “Common Blocks are Indexed.”

The two common block banks in the example are

• $BLANK$COMMON$
• S$PERSONSUBTIP_$A

These names should appear in the INDEX command in the static link of each ZOOM in
the HVTIP transaction sequence. If any common block banks for this transaction
sequence are not reflected in this execution, they must also be listed in each INDEX
command.

The INDEX command for the example is as follows:

INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A

7831 4077–009 6–219

Application Programming in an HVTIP Environment

The updated link source for the initial control program is as follows:
@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR HVTIP$$DBANK
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

The updated link source for the subprogram is as follows:

@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSSUB
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSSUB/COMP
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT DMSSUB
@EOF

6–220 7831 4077–009

 Application Programming in an HVTIP Environment

6.3.4.9. Setting LOWADR for HVTIP$$DSEG of the Initial Control

Program
The next step is to set LOWADR for HVTIP$$DSEG of the initial control program; this
is its local data segment. Setting LOWADR avoids address overlap, and makes sure
that no address adjustment (which would degrade performance) is necessary.

This data segment resides in HVTIP$$DBANK. It is loaded when transaction execution

begins.

The format for the LOWADR command is as follows:

SET LOWADR = 0nnnnnn FOR HVTIP$$DSEG

The leading zero denotes an octal number.

You should place this SET command after the RESOLVE command and before the
DELETE ALL DEFINITIONS command in the static link of the initial control program.

The output from the PADS procedure provides the address that you should use for
HVTIP$$DSEG of the initial control program. You can determine this address by
looking at the “Currently Allocated Heap Data Segments” section; one line has the
HVTIP library and bank number (LLBBBB) for the initial control program.

In this case, DMSICP has an HVTIP library number of 2 and a bank number of 1. The
address range for the data segment for DMSICP is at the end of the same line.

7831 4077–009 6–221

Application Programming in an HVTIP Environment

The following is sample output from the PADS procedure.

# *********************************************************************
# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
#
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#
# The Currently Allocated Heap Data Segments:
# Seg LLBBBB EM Start End
# Numb BDI Address Address
# 0000 020001 0400005 => 0047005 - 0122510
# 0001 020002 0400005 => 0153246 - 0154111
#
# Common Blocks:
# Common Blocks are Named (Indexed would be more optimal).
# Seg LLBBBB EM Start End Common Block
# Numb BDI Address Address Name
# 0000 020001 0400005 => 0122511 - 0124007 $BLANK$COMMON$
# 0000 020001 0400005 => 0124010 - 0124743 S$PERSONSUBTIP_$A
#
# These HVTIP ZOOMs have been referenced
# (and have not been CANCELed):
# Seg # LLBBBB Received Control as
# 0000 020001 ICP (Main prog)
# 0001 020002 HVTIP Subroutine
# *********************************************************************

In the example, the data segment for the initial control program (library 2 bank 1 -
020001) is at address range 047005-122510.

If the low address in this range is not a multiple of four, you should round it up to a
multiple of four. (This would be an octal number that ends in either zero or four.)

In the example, 047005 is rounded up to 047010. This means the high address for this
segment becomes 0122513. The new address range is 047010-0122513.

The following SET LOWADR command is added to the static link of DMSICP:
SET LOWADR = 047010 FOR HVTIP$$DSEG

6–222 7831 4077–009

 Application Programming in an HVTIP Environment

This command results in the following HVTIP heap data bank layout. You can find the
start and end addresses for HVTIP$$DBANK by looking at the line in the PADS
procedure output labeled “Current HVTIP Program Heap Address Range.”

The updated link source for the initial control program is as follows:

@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR HVTIP$$DBANK
SET LOWADR = 047010 FOR HVTIP$$DSEG
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

7831 4077–009 6–223

Application Programming in an HVTIP Environment

6.3.4.10. Setting LOWADR for Common Block Banks

The next step is setting LOWADR for each common block bank to the LOWADR
specified in the first program in the transaction sequence that references that
common block bank.

You must place the LOWADR command for a common block bank only in the static
links of ZOOMs that actually reference that common block bank. The format for this
command is as follows:
SET LOWADR = 0nnnnnn FOR common_block_bank_1

The leading zero denotes an octal number.

You should place this command after the RESOLVE command and before the DELETE
ALL DEFINITIONS command in the static link of each ZOOM that references that
common block bank.

Duplicate common blocks are not loaded. By setting LOWADRs as described here,
you make sure the common block banks are referenced using the same addresses
throughout the transaction sequence. Thus, no address adjustment is necessary, and
performance is not degraded. If any common block banks do not appear in the
execution, give them an address that is greater than the end address of the last
common block bank in HVTIP$$DBANK. Make sure they do not overlap with any data
segment or other common block banks.

Using the PADS procedure output, you can see the list of common blocks.

6–224 7831 4077–009

 Application Programming in an HVTIP Environment

The following is sample output from the PADS procedure.

# *********************************************************************
# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
#
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#
# The Currently Allocated Heap Data Segments:
# Seg LLBBBB EM Start End
# Numb BDI Address Address
# 0000 020001 0400005 => 0047005 - 0122510
# 0001 020002 0400005 => 0153246 - 0154111
#
# Common Blocks:
# Common Blocks are Named (Indexed would be more optimal).
# Seg LLBBBB EM Start End Common Block
# Numb BDI Address Address Name
# 0000 020001 0400005 => 0122511 - 0124007 $BLANK$COMMON$
# 0000 020001 0400005 => 0124010 - 0124743 S$PERSONSUBTIP_$A
#
.
. (the remainder of the PADS procedure output)
.

In the example, there are two common blocks. The output shows that
• $BLANK$COMMON$ starts at octal address 122511.
• S$PERSONSUBTIP_$A starts at octal address 124010.

If the low address in this range is not a multiple of four, it should be rounded up to a
multiple of four. (This would be an octal number that ends in either zero or four.)

Also, you must check that there is no address overlap with the HVTIP$$DSEG address
range established by setting the LOWADR for HVTIP$$DSEG for the initial control
program.

Currently, $BLANK$COMMON$ starts at 0122511. Rounding up to 0122514 also

eliminates the HVTIP$$DSEG overlap. The $BLANK$COMMON$ address range
becomes
0122514 - 0124012.

S$PERSONSUBTIP_$A starts at 0124010. No rounding is required, but overlap still

occurs with the new address for $BLANK$COMMON$. Therefore, the start address
must be increased to 0124014. The new address range for S$PERSONSUBTIP_$A
becomes 0124014-0124747.

7831 4077–009 6–225

Application Programming in an HVTIP Environment

These addresses represent the addresses that should be used in the SET LOWADR
commands in the initial control program and subprograms that contain these common
blocks.

The static link commands for our example are as follows:

SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A

These commands result in the following HVTIP heap data bank layout. You can find
the start and end addresses for HVTIP$$DBANK by looking at the line in the PADS
procedure output labeled “Current HVTIP Program Heap Address Range”.

The updated linking runstream for the initial control program looks as follows:
@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = SIZE + 10048 FOR HVTIP$$DBANK
SET LOWADR = 047010 FOR HVTIP$$DSEG
SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

6–226 7831 4077–009

 Application Programming in an HVTIP Environment

The updated link source for the subprogram is as follows:

@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSSUB
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSSUB/COMP
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT DMSSUB
@EOF

6.3.4.11. Setting the Size of HVTIP$$DBANK

By default, the initial size of HVTIP$$DBANK (the main HVTIP heap data bank) equals
one of the following, in the priority order indicated:
1. The value set in the VALTAB entry keyword DBKSIZE for the initial control
program. This value is used at execution time only. Static linking is unaware of
this value. For information on the VALTAB entry, refer to the Transaction
Processing Administration and Operations Reference Manual.
2. In the absence of a user-specified value for the keyword DBKSIZE in the VALTAB
entry, the size used for HVTIP$$DBANK is the size specified by the user in the
static link of the initial control program (ICP), as follows:
SET SIZE = n FOR HVTIP$$DBANK

3. In the absence of either of the preceding, the default equals the sum of the size of
the data segment for the ICP, plus all common block segments, plus control
information.
If HVTIP$$DBANK is not big enough to contain all of the data and common block
segments for the transaction execution, one of the following occurs:
• If EXPANSION_SIZE equals 0, a run-time error message is received and the
transaction aborts.
• If the EXPANSION_SIZE does not equal 0, the UCS Runtime System expands
the size of HVTIP$$DBANK by at least the size specified by EXPANSION_SIZE,
using an Executive request to MCORE$.
EXPANSION_SIZE has a default size of 010000. This causes expansion to occur
in increments no smaller than 4,096 (010000) words.

HVTIP$$DBANK should initially be set to the maximum size required by the most
commonly-used execution paths for the transaction sequence. Doing so avoids the
overhead of dynamically acquiring space. For rarely-used execution paths that require
a larger HVTIP$$DBANK, expansion should be allowed to occur. Note, however, that if
HVTIP$$DBANK is expanded by the URTS run-time system, TIP “sticking” and
RESTART are lost for that transaction.

7831 4077–009 6–227

Application Programming in an HVTIP Environment

You set the initial size of HVTIP$$DBANK by using the following command in the static
link of the initial control program (ICP):
SET SIZE = 0nnnnn FOR HVTIP$$DBANK

The leading zero denotes an octal number. You should place this command after the
RESOLVE command and before the DELETE ALL DEFINITIONS command in the static
link of the initial control program.

By looking at the output of the PADS procedure, you can find the address range from
this execution of the transaction. From this address range you can calculate the size
of HVTIP$$DBANK.

The following is a portion of the PADS procedure output for the example transaction.
The shaded line contains the octal address range of HVTIP$$DBANK.

# *********************************************************************
# ** HVTIP$INFO ** (07/01/97)
# (Numbers are octal. LLBBBB refers to HVTIP Library and bank number.)
#
# Current ALS Size is 004000 words.
#
# Runtime relocation was performed on one or more data segments.
#
# Current HVTIP Program Heap Address Range: 0400005 => 0047000 - 0402777
#

By subtracting 047000 from 0402777, you determine that the size of HVTIP$$DBANK
is 0334000. If this size is not a multiple of 01000, you should round it up to a multiple
of 01000. (This would be an octal number that ends in 000.)

Also, you must check to be sure that there is no address range specified as a result of
the SET LOWADR commands (added to the static link of the initial control program)
that fall outside the new address range of HVTIP$$DBANK.

In the static link of the initial control program, add the following command:
SET SIZE = 0334000 FOR HVTIP$$DBANK

6–228 7831 4077–009

 Application Programming in an HVTIP Environment

This command results in the HVTIP heap data bank layout as shown in the following
diagram.

The updated link source for the initial control program is as follows:
@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET SIZE = 0334000 FOR HVTIP$$DBANK
SET LOWADR = 047010 FOR HVTIP$$DSEG
SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

It is easiest to simply set the size of HVTIP$$DBANK to the maximum, so that it

extends to its MAX_LIMIT. The default MAX_LIMIT is 0777777. You may wish to set
MAX_LIMIT for HVTIP$$DBANK to 0577777 if your transaction uses DPS.

You may also set the LOWADR of HVTIP$$DBANK if you wish. It defaults to 01000
less than the HVTIP$$DSEG LOWADR, so it usually is at 057000. However, it could be
set down to as low as 045000 to gain a little more space if you need it. Just
remember that the lower you set it, the more likely it will be to overlap some basic
mode code space and have things stop working. Many things would stop working if
you dropped it below 045000.

7831 4077–009 6–229

Application Programming in an HVTIP Environment

6.3.4.12. Setting EXPANSION_SIZE for HVTIP$$DBANK

EXPANSION_SIZE represents the minimum size by which HVTIP$$DBANK can be
expanded using MCORE$, if expansion is necessary to load a new segment. Possible
values are

0
No expansion is allowed. The transaction results in an error if expansion is
required.

n
HVTIP$$DBANK is expanded in increments no smaller than n words. The value of
n should be a multiple of 01000 words.

You should set the initial size for HVTIP$$DBANK to reflect the size required by the
commonly-used execution paths in the transaction sequence. For these cases, no
expansion of HVTIP$$DBANK should occur. For rarely-used execution paths in the
transaction sequence that require a larger HVTIP$$DBANK, expansion will occur.

You use the following static-linking command to change the expansion size for a
subprogram:
SET EXPANSION_SIZE = 0nnnnn

The leading zero denotes an octal number. You should place this command after the
RESOLVE command and before the DELETE ALL DEFINITIONS command in the static
link.

For the example, the expansion size is allowed to default to a value of 010000. No
changes are made to the static link of DMSSUB.

EXPANSION_SIZE only affects the main heap bank.

6.3.4.13. Setting RELOAD_SKIP_SIZE

In most cases, the UCS Runtime System attempts to load a segment at the address
specified by LOWADR. In some cases, however, this may be wasteful of storage
space. For example, consider the following two segments:

Segment 1 LOWADR = 01000

Size = 01000

Segment 2 LOWADR = 010000

Size = n

In this example, there are 06000 words of empty space between Segment 1 and
Segment 2 when they are loaded in HVTIP$$DBANK. Depending on the user
application, this may or may not be wasteful of storage space.

6–230 7831 4077–009

 Application Programming in an HVTIP Environment

For example, one subprogram might call another subprogram only conditionally.
Assume the conditionally-called subprogram is Segment 3, as follows:

Segment 3 LOWADR = 02500

Size = 05000

In this case, Segment 3, if called, occupies the space between Segments 1 and 2.
Thus, the space is not wasted. In other applications, however, this amount of space
might be wasted.

RELOAD_SKIP_SIZE is a field name that applies to an HVTIP ZOOM subprogram. It

tells the UCS Runtime System not to relocate segments if the space between
segments is less than n words, where n is the value of RELOAD_SKIP_SIZE. By
default, RELOAD_SKIP_SIZE is set at 01000 words (512 words decimal).

RELOAD_SKIP_SIZE allows you to set an upper limit on the amount of space between
segments. When a segment is loaded, one of two conditions exists:

• Space < RELOAD_SKIP_SIZE

In this case, the space is left empty. The segment is loaded at the LOWADR
specified. Thus, relocation is avoided, provided LOWADRs have been properly
set. As a result, performance is not degraded; however, this may increase storage
requirements.
• Space >= RELOAD_SKIP_SIZE
In this case, the space is not left empty. The segment is loaded contiguously at
the next available address, rather than at its LOWADR. This decreases storage
requirements. Relocation is probably necessary, however, and performance is
thus degraded on the initial call to this subprogram.

You can change the default setting of RELOAD_SKIP_SIZE by using the following
command:

SET RELOAD_SKIP_SIZE = 0nnnnn

The leading zero denotes an octal number. You should place this command after the
RESOLVE command and before the DELETE ALL DEFINITIONS command in the static
link of each ZOOM for which you want to reset the RELOAD_SKIP_SIZE. It cannot be
placed before the OUTPUT statement.

For the example, the RELOAD_SKIP_SIZE is allowed to default to a value of 01000

words. No changes are made to the static link of DMSSUB.

RELOAD_SKIP_SIZE affects all heap banks. In HVTIP-II (OUTPUT HVTIP2), the SET
RELOAD_SKIP_SIZE = 0777777 feature no longer terminates the transaction if any
relocation occurs in the specified zoom. If the SET RELOAD_SKIP_SIZE = 0777777
statement is present in the transaction’s ICP link source code; it is treated as if the
statement SET FAST_LOAD_MONITOR = 5 is present and it causes a message to be
sent to the transaction’s print file for each relocation or CREATE$BANK Exec call. The
SET RELOAD_SKIP_SIZE = 0777777 statement has no effect in the links of HVTIP-II
subprograms, only the ICP.

7831 4077–009 6–231

Application Programming in an HVTIP Environment

If you have carefully done SET LOWADR statements in all of your HVTIP static links so
that no segments overlap and so no relocation occurs, you may wish to put the
following statement into the links to ensure that the URTS HVTIP Loader honors your
LOWADRs and does not attempt to “save” space by packing your segments together
and causing relocation to occur:
SET RELOAD_SKIP_SIZE = 0777000

6.3.4.14. Initial Control Program Static Link Runstream and Listing

The following static link runstream shows the results of the performance link for the
initial control program DMSICP.

@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN
SET SIZE = 0334000 FOR HVTIP$$DBANK
SET LOWADR = 047010 FOR HVTIP$$DSEG
SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT START$
@EOF

6–232 7831 4077–009

 Application Programming in an HVTIP Environment

This performance link runstream produces the following output. Notable lines are
marked with numbers in parentheses; explanations follow.

@USE LINK$PF,SYS$LIB$*APP$3. (1)

I:002333 USE complete.
@LINK,S ,QUAL*UCSTST.DMSICP
LINK 7R1 (970207 1635:57) 1997 Feb 21 Mon 1646:13 (2)
1 OUTPUT HVTIP (3)
2 INCLUDE QUAL*UCSTST.DMSICP/COMP (3)
3 INCLUDE QUAL*UCSTST.HVCALLSDEF/DMSSUB (3)
4 INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP (3)
5 INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS (3)
6 RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN (3)
7 SET SIZE = 0334000 FOR HVTIP$$DBANK (3)
1 Bank(s) had SIZE set to 0334000 .
8 SET LOWADR = 047010 FOR HVTIP$$DSEG (3)
1 Bank(s) had LOWADR set to 047010 .
9 SET LOWADR = 0122514 FOR $BLANK$COMMON$ (3)
1 Bank(s) had LOWADR set to 0122514 .
10 SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A (3)
1 Bank(s) had LOWADR set to 0124014 .
11 INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A (3)
12 DELETE ALL DEFINITIONS EXCEPT START$ (3)
10 Banks were merged resulting in bank HVTIP$$CODE . (4)
11 Banks were merged resulting in bank HVTIP$$DSEG . (4)
*WARNING (LINK 647)* Sizes vary for common block S$PERSONSUBTIP . (5)
1343 Definitions deleted after resolution . (6)

1 BANK GROUP HVTIP$$SEGS. 4 banks. (7)

1 QUAL*UCSTST(1).DMSICP/COMP 1997 Feb 21 1218:01 (8)

Name: $BLANK$COMMON$
Bank_type = Common; LBN = 02
L,BDI = 0400005; Addr Range (in HVTIP heap): 000122514 - 000124012(9)

2 UDS$$SRC*SCHEXECFILE(1).S$WORK/PERSONSUBTIP 1997 Feb 21 1114:09 (10)

Name: S$PERSONSUBTIP_$A (Old name = S$PERSONSUBTIP)
Bank_type = Common; LBN = 03
L,BDI = 0400005; Addr Range (in HVTIP heap): 000124014 - 000124747(9)

3 Name: HVTIP$$DSEG (new bank) (11)

Bank_type = Data; LBN = 04
L,BDI = 0400005; Addr Range (in HVTIP heap): 000047010 - 000076414(9)

11 bank parts: (12)

1 QUAL*UCSTST(1).DMSICP/COMP 1997 Feb 21 1218:01
Name: DMSICP$0 000047010 - 000047551
2 SYS$LIB$*EMOMRTS(19).URTS$TABLES 1997 Mar 26 1552:38
Name: URTS$TABLES 000047552 - 000076213

7831 4077–009 6–233

Application Programming in an HVTIP Environment

3 SYS$LIB$*EMOMRTS(19).URTS$TABLES 1997 Mar 26 1552:38

Name: SS$CGY_LIST 000076214 - 000076215
4 SYS$LIB$*EMOMRTS(19).RTS-GCLSINT 1997 Mar 26 1552:28
Name: LV$GCLSINT 000 76216 - 000076221
5 APP3*DPS(13).UCS/INTERFACE 1995 May 17 0044:47
Name: DPS$LINKBK 00007622 - 000076233
6 SYS$LIB$*EMOMRTS(19).URTS$TABLES 1997 Mar 26 1552:38
Name: URTS$TABLES$17 000076234 - 000076243
7 SYS$LIB$*EMSRVC(19).SRVC-ERTRAN1 1996 Aug 22 1101:12
Name:ERTRAN1LVB 000076244 - 000076247
8 SYS$LIB$*EMOMRTS(19).C$NPADS 1997 Mar 26 1551:57
Name: C$NPADS_LV Void

9 SYS$LIB$*RSA(22).RSAC-UCSEMOM 1996 Sep 13 2240:37

Name:RSAC-UCSEMOM$17 000076250 - 000076260
10 SYS$LIB$*EMOMRTS(19).RTS-PADSINT 1997 Mar 26 1535:40
Name:LV$PADSINT 000076262 - 000076271
11 SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT 1996 Dec 17 1417:57
Name: LS$INTERCEPT$04 000122364 - 000122513

4 QUAL*UCSTST(1).DMSICP/COMP 1997 Feb 21 1218:01 (13)

Name: DMSICP$3
Bank_type = SDD; LBN = 05
Addr Range: 000000000 - 000000112

2 BANK GROUP HVTIP$$GROUP. 2 banks. (14)

1 Name: HVTIP$$CODE (new bank) (15)

Bank_type = Code; LBN = 0
L,BDI = 0400004; Addr Range: 000001000 - 000026177 (16)

10 bank parts: (17)

1 QUAL*UCSTST(1).DMSICP/COMP 1997 Feb 21 1218:01
Name: DMSICP$1 000001000 - 000001753
2 APP3*DPS(13).UCS/INTERFACE 1995 May 17 1434:58
Name: DPS$CODEBK 000001754 - 000004732
3 SYS$LIB$*EMOMRTS(19).RTS-GCLSINT 1997 Mar 26 1535:38
Name: RTS-GCLSINT 000004733 - 000005625
4 SYS$LIB$*EMSRVC(19).SRVC-ERTRAN1 1996 Aug 22 1201:36
Name: SRVC_ERTRAN1 000005626 - 000013452
5 SYS$LIB$*EMOMRTS(19).C$NPADS 1997 Mar 19 1535:17
Name: C$NPADS 0000013453 - 000014560
6 SYS$LIB$*RSA(29).RSAC-UCSEMOM 1996 Sep 13 1317:09
Name: I_BANK 0000014561 - 000014616
7 SYS$LIB$*EMOMRTS(19).RTS-PADSINT 1997 Mar 26 1535:40
Name: RTS-PADSINT 000014617 - 000014717
8 SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT 1996 May 6 1506:03
Name: LS$INTERCEPT$01 000014720 - 000016346
9 SYS$LIB$*EMSRVC(19).UC-CONDITION 1996 Apr 29 1546:47
Name: UC_CONDITION 000016347 - 000016706

6–234 7831 4077–009

 Application Programming in an HVTIP Environment

10 SYS$LIB$*EMSRVC(19).SRVC-CHRTBL 1996 Apr 29 1541:35

Name: SRVC-CHRTBL 000016707 - 000017106 (18)

2 Name: HVTIP$$DBANK (new bank) (19)

Bank_type = Data; LBN = 01
L,BDI = 0400005; Addr Range: 000047000 - 000402777 (20)

END LINK , LINES : 12 , ERRORS : 0 , WARNINGS : 1 , XREFS : 0. (21)

Explanations
1. This @USE LINK$PF statement identifies the application-group-dependent search
chain to be used by this static link. In this case, the search chain for application
group three is specified.

2. This is the LINK Processor call line. It identifies

• The level of the Linking System software
• In parentheses, the date and time this Linking System software was generated
• The date and time that this static link took place (not in parentheses)

3. These are echoes of the static linking commands input from the source runstream.
Some are followed with comments verifying that the action requested was taken.

4. As a result of the OUTPUT HVTIP command, banks were merged to produce

HVTIP$$CODE and HVTIP$$DSEG.

5. The Subschema Data Definition Language (SDDL) processor creates a common

block bank that is one word shorter than expected by the UCS environment. This
warning can be ignored.

6. This line provides the number of entry points that were deleted as a result of the
DELETE ALL DEFINITIONS command. The DELETE command decreases the size of
a ZOOM produced by the static link.

7. HVTIP$$SEGS is the first bank group. It defines the data segments of the ZOOM.
It exists for documentation purposes only. The initialization text of the banks
contained in HVTIP$$SEGS actually exists in bank HVTIP$$CODE. These segments
are loaded at run time by the HVTIP heap manager. They might or might not be
loaded at the addresses shown here.
In this case, the banks contained in HVTIP$$SEGS are the following:
• $BLANK$COMMON$
• S$PERSONSUBTIP_$A
• HVTIP$$DSEG
• DMSICP$3

8. The first bank within HVTIP$$SEGS has a bank_type of “common.” This bank is
named $BLANK$COMMON$. It comes from the object module
QUAL*UCSTST.DMSICP/COMP.

7831 4077–009 6–235

Application Programming in an HVTIP Environment

QUAL*UCSTST(1).DMSICP/COMP
Name: $BLANK$COMMON$
Bank_type = Common; LBN = 02

9. The address ranges shown are for documentation purposes since the segments
may actually be loaded at different addresses at run time. If the transaction ends
in an error, this information can help with debugging. The initialization text actually
exists in part of the address range of HVTIP$$CODE.

10. The second bank, S$PERSONSUBTIP_$A, was produced by the Subschema Data
Definition Language (SDDL) processor because the “C” option was used. It has a
bank_type of “common.”
UDS$$SRC*SCHEXECFILE(1).S$WORK/PERSONSUBTIP
Name: S$PERSONSUBTIP_$A (Old name = S$PERSONSUBTIP)
Bank_type = Common; LBN = 03
11. The bank HVTIP$$DSEG, created by static linking, describes the data segment
whose initialization text actually exists in HVTIP$$CODE. It contains the input
banks now listed as bank parts.
Name: HVTIP$$DSEG (new bank)
Bank_type = Data; LBN = 04

12. This describes the input banks to HVTIP$$DSEG. The address ranges shown are
for documentation. If the program ends in an error, this information can help with
debugging.
Bank names are preceded by the name of the object module that originally
contained the bank. In this example, HVTIP$$DSEG contains the bank parts as
follows:
• The following lines are for the data bank for the initial control program
DMSICP.
QUAL*UCSTST(1).DMSICP/COMP
Name: DMSICP$0

• The following lines are for a UCS Runtime System data bank. It contains the
UCS Runtime System tables, I/O buffers and packets, entry point definitions,
and the storage management reserve.
SYS$LIB$*EMOMRTS(19).URTS$TABLES
Name: URTS$TABLES

• The following lines are for a UCS Runtime System data bank. It is a dummy
bank used to satisfy SS_CGY_REF in URTS$TABLES, when the user does not
supply a contingency routine for a chameleon subsystem to access its
unshared data. If chameleon subsystems are not being used, this bank is not
used.
SYS$LIB$*EMOMRTS(19).URTS$TABLES
Name: SS$CGY_LIST

• The following lines are for the link vector bank for the UCS Runtime System
contingency processing routine.

6–236 7831 4077–009

 Application Programming in an HVTIP Environment

SYS$LIB$*EMOMRTS(19).RTS-GCLSINT
Name: LV$GCLSINT

• The following lines are for the link vector bank DPS uses to access its work
area in URTS$TABLES.
APP3*DPS(13).UCS/INTERFACE
Name: DPS$LINKBK

• The following lines are for the link vector bank for the UCS Runtime System.
SYS$LIB$*EMOMRTS(19).URTS$TABLES
Name: URTS$TABLES$17

• This bank contains the link vector for the Executive requests (ERs).
SYS$LIB$*EMSRVC(19).SRVC-ERTRAN1
Name: ERTRAN1LVB

• The following lines are for the link vector bank for the intercept routine used
to resolve PADS references.
SYS$LIB$*EMOMRTS(19).C$NPADS
Name: C$NPADS_LV

• This bank contains the link vector for RDMS.

SYS$LIB$*RSA(9).RSAC-UCSEMOM
Name: RSAC-UCSEMOM$17

• The following lines are for the link vector bank for the intercept routines used
to call PADS from the UCS Runtime System Common Bank.
SYS$LIB$*EMOMTS(19).RTS-PADSINT
Name: LS$PADSINT

• The following lines are for the link vector bank for the Linking System.
SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT
Name: LS$INTERCEPT$04

13. This is a special bank group used during postmortem debugging with PADS. It is a
symbolic debugging dictionary. It provides information that allows PADS to
reference data and code statements in the user program using symbolic names.
QUAL*UCSTST(1).DMSICP/COMP
Name: DMSICP$3
Bank_type = SDD; LBN = 05

14. This bank group contains banks HVTIP$$CODE and HVTIP$$DBANK. This is the
bank group that is loaded into BDI 4 when the initial control program is loaded.

15. HVTIP$$CODE contains all of the actual text of the input banks, plus control
information. Code banks, data banks, and common blocks banks (if present) exist
as segments in this bank.

7831 4077–009 6–237

Application Programming in an HVTIP Environment

Name: HVTIP$$CODE (new bank)

Bank_type = Code; LBN = 0

16. This address range is where all input code banks and the initialization information
for all data banks and common block banks actually resides.

17. Only the code banks are listed here (as bank parts), although all of the initialization
text for HVTIP$$DSEG and the common block segments also reside in
HVTIP$$CODE. The code banks are as follows:
• The following lines are for the code bank of the initial control program
DMSICP.
QUAL*UCSTST(1).DMSICP/COMP
Name: DMSICP$1

• The following lines are for the code bank that contains the UCS interface for
DPS.
APP3*DPS(13).UCS/INTERFACE
Name: DPS$CODEBK

• The following lines are for a UCS Runtime System code bank used as the
interface to the Linking system from the generated code and the UCS Runtime
System.
SYS$LIB$*EMOMRTS(19).RTS-GCLSINT
Name: RTS-GCLSINT

• The following lines are for a UCS Runtime System code bank. It provides the
interface to the Executive requests (ERs).
SYS$LIB$*EMSRVC(19).SRVC-ERTRAN1
Name: SRVC-ERTRAN1

• The following lines are for an intercept routine used to resolve PADS
references.
SYS$LIB$*EMOMRTS(19).C$NPADS
Name: C$NPADS

• This is the entry point virtual address into the RDMS application group defined
by ACTIVE$APP in the library search chains.
SYS$LIB$*RSA(29).RSAC-UCSEMOM
Name: I_BANK

• The following lines are for an intercept routine used to call PADS from the UCS
Runtime System Common Bank.
SYS$LIB$*EMOMRTS(19).RTS-PADSINT
Name: RTS-PADSINT

• The following lines are for a Linking System code bank. It provides the entry
points for the program-callable interfaces in the Linking system used by PADS
and FLIT.

6–238 7831 4077–009

 Application Programming in an HVTIP Environment

SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT
Name: LS$INTERCEPT$01

• This bank is used by the Executive request interface.

SYS$LIB$*EMSRVC(19).UC-CONDITION
Name: UC_CONDITION

• This bank is used by the Executive request interface.

SYS$LIB$*EMSRVC(19).SRVC-CHRTBL
Name: SRVC-CHRTBL

18. HVTIP$$SEGS text and control information occupies the address range from
000017107 to 000026177 (line 16).

19. HVTIP$$DBANK is a void bank representing the HVTIP heap data bank.
Name: HVTIP$$DBANK (new bank)
Bank_type = Data; LBN = 01

20. This address range is established by the LOWADR and SIZE settings for
HVTIP$$DBANK. This information has no meaning for HVTIP subprograms.
The ICP static link defines the HVTIP$$DBANK that is used as the “heap” bank
by the transaction.

21. This is the sign-off line for the LINK Processor. It identifies
• The number of lines of @LINK commands entered by the user (LINES : 12)
• The number of errors that occurred in this @LINK session (ERRORS : 0)
• The number of warnings that were issued in this @LINK session
(WARNINGS : 1)
• The number of external references not resolved during the @LINK session
(XREFS : 0)
External references not resolved by static linking must be resolved by the dynamic
linker during execution. In the case of an HVTIP ZOOM, the number of external
references must always be zero.

7831 4077–009 6–239

Application Programming in an HVTIP Environment

6.3.4.15. Subprogram Static Link Runstream and Listing

The following static link runstream shows the results of the performance link for the
subprogram DMSSUB.
@USE LINK$PF,SYS$LIB$*APP$3.
@LINK,S ,QUAL*UCSTST.DMSSUB
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.DMSSUB/COMP
INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
SET LOWADR = 0122514 FOR $BLANK$COMMON$
SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
DELETE ALL DEFINITIONS EXCEPT DMSSUB
@EOF

This performance link runstream produces the following output.

@USE LINK$PF,SYS$LIB$*APP$3.
I:002333 USE complete.
@LINK,S ,QUAL*UCSTST.DMSSUB
LINK 7R1 (970207 1635:57) 1997 Feb 24 Mon 1646:20
1 OUTPUT HVTIP
2 INCLUDE QUAL*UCSTST.DMSSUB/COMP
3 INCLUDE UDS$$SRC*SCHEXECFILE.S$WORK/PERSONSUBTIP
4 INCLUDE APP3*DPS.UCS/INTERFACE,.EMCBEP$$DPS
5 RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LIBCODENAME
6 SET LOWADR = 0122514 FOR $BLANK$COMMON$
1 Bank(s) had LOWADR set to 0122514 .
7 SET LOWADR = 0124014 FOR S$PERSONSUBTIP_$A
1 Bank(s) had LOWADR set to 0124014 .
8 INDEX COMMON BANKS $BLANK$COMMON$, S$PERSONSUBTIP_$A
9 DELETE ALL DEFINITIONS EXCEPT DMSSUB
4 Banks were merged resulting in bank HVTIP$$CODE .
4 Banks were merged resulting in bank HVTIP$$DSEG .
*WARNING (LINK 647)* Sizes vary for common block S$PERSONSUBTIP .
1205 Definitions deleted after resolution .

1 BANK GROUP HVTIP$$SEGS. 4 banks.

1 QUAL*UCSTST(1).DMSSUB/COMP 1997 Feb 24 1218:12

Name: $BLANK$COMMON$
Bank_type = Common; LBN = 02
L,BDI = 0400005; Addr Range (in HVTIP heap): 000122514 - 000124012

2 UDS$$SRC*SCHEXECFILE(1).S$WORK/PERSONSUBTIP 1997 Feb 24 1141:09

Name: S$PERSONSUBTIP_$A (Old name = S$PERSONSUBTIP)
Bank_type = Common; LBN = 03
L,BDI = 0400005; Addr Range (in HVTIP heap): 000124014 - 000124747

6–240 7831 4077–009

 Application Programming in an HVTIP Environment

3 Name: HVTIP$$DSEG (new bank)

Bank_type = Data; LBN = 04
L,BDI = 0400005; Addr Range (in HVTIP heap): 000000010 - 000000642

4 bank parts:
1 QUAL*UCSTST(1).DMSSUB/COMP 1997 Feb 24 1218:12
Name: DMSSUB$0 000000010 - 000000501
2 SYS$LIB$*EMOMRTS(19).RTS-GCLSINT 1997 Mar 27 1535:38
Name: RTS-GCLSINT$17 000000502 - 000000505
3 APP3*DPS(13).UCS/INTERFACE 1996 May 17 1434:58
Name: DPS$LINKBK 000000506 - 000000517
4 SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT 1996 May 6 1506:03
Name: LS$INTERCEPT$04 000125464 - 000125613

4 QUAL*UCSTST(1).DMSSUB/COMP 1997 Feb 24 1218:12

Name: DMSSUB$3
Bank_type = SDD; LBN = 05
Addr Range: 000000000 - 000000101

2 BANK GROUP HVTIP$$GROUP. 2 banks.

1 Name: HVTIP$$CODE (new bank)

Bank_type = Code; LBN = 0
L,BDI = 0400004; Addr Range: 000001000 - 000012777

6 bank parts:
1 QUAL*UCSTST(1).DMSSUB/COMP 1997 Feb 24 1218:12
Name: DMSSUB$1 000001000 - 000001565
2 APP3*DPS(13).UCS/INTERFACE 1995 May 17 1434:58
Name: DPS$CODEBK 000001566 - 000004544
3 SYS$LIB$*EMOMRTS(19).RTS-GCLSINT 1997 Mar 26 1535:38
Name: RTS-GCLSINT 000004545 - 000005437
4 SYS$LIB$*LINKOMLIB(252).LS$INTERCEPT 1996 May 6 1506:03
Name: LS$INTERCEPT$01 000005440 - 000007066

2 Name: HVTIP$$DBANK (new bank)

Bank_type = Data; LBN = 01
L,BDI = 0400005; Addr Range: 000000000 - 000125265

END LINK , LINES : 9 , ERRORS : 0 , WARNINGS : 1 , XREFS : 0.

7831 4077–009 6–241

Application Programming in an HVTIP Environment

6.4. HVTIP and FLSS Error Messages

The HVTIP heap manager is the component of the UCS Runtime System responsible
for managing the HVTIP heap data bank during the execution of an HVTIP transaction.
A component of the heap manager loads local data for Fast-Load Self-Contained
Subsystem (FLSS) data segments. An FLSS segment load may occur in any execution
environment, including TIP, HVTIP, demand, and batch. HVTIP segment loads occur
only in an HVTIP transaction.

For error message descriptions, see subsection “UCS Runtime System Messages
(URTS)” in Appendix B of the appropriate UCS language manual, either:

• OS 2200 COBOL Compiler Programming Reference Manual Volume 2,

Compiler and System Interface (7831 0455)

• Application Development Solutions C Compiler Programming Reference

Manual Volume 2, Compiler and System Interface
(7831 0430)

• OS 2200 FORTRAN Compiler Programming Reference Manual Volume 2,

Compiler and System Interface (7830 7477)

6–242 7831 4077–009

 Application Programming in an HVTIP Environment

6.5. The HVTIP-II Environment Details

Beginning with SB6, a new type of HVTIP ZOOM, the HVTIP-II ZOOM, is available. The
HVTIP-II ZOOM has the capability of using many heap banks in addition to the implicit
program-level heap (the first heap bank in the HVTIP-II environment and the only heap
bank in the original UCS HVTIP environment). The additional heaps are specified using
an expanded TIPUTL VALTAB specification. In order to reduce or eliminate data
segment relocation within the additional heap banks, an expanded form of the SET
LOWADR command is also available. The following paragraphs show snapshot HVTIP-
II VALTAB/LINK constructs.

When you use interpreted or embedded SQL in a program, RDMS uses the UCS C
malloc function to acquire dynamic memory allocations. Under HVTIP, C malloc space
is acquired from the HVTIP D-bank, program level BDI 5. When heap space runs out,
the malloc calls fail, returning NULL, and the program execution fails. However, if the
HVTIP ICP static link has an OUTPUT HVTIP2 statement instead of an OUTPUT HVTIP
statement, C malloc space then is taken from separate activity-level banks called
"pooled" banks. If your static link and VTBUTL VALTAB settings also supply activity-
level pooled banks, those banks are used for malloc space. If you do not supply any
pooled banks, CREATE$BANK calls are done to dynamically acquire activity-level banks
which are used for C malloc space. Those system calls result in your transaction losing
its TIP sticking and restart. See the OS 2200 Transaction Processing Administration
and Operations Reference Manual (7830 7881) for more details on how to supply
extra banks to the transaction. See the Linking System Programmer Reference
Manual for a description of the OUTPUT HVTIP2 statement.

6.5.1. HVTIP-II VALTAB

HVTIP-II has the following additional VALTAB keywords: DLACTCNT, DLPRGCNT,
DASIZL, DPSIZL, DSACTCNT, and DSPRGCNT, DSLOWER, and DSUPPER.

Example
DSACTCNT, 2 DLACTCNT, 3 DASIZL, 3 DSPRGCNT, 2 DLPRGCNT, 3
DPSIZL, 3
DSLOWER, 0100000 DSUPPER, 0577777

where

DSACTCNT, 2 DLACTCNT, 3 DASIZL, 3

indicates 2 small activity-level heaps, 3 large activity-level heaps with three 262K (3
BDIs) word blocks each.

DSPRGCNT, 2 DLPRGCNT, 3 DPSIZL, 3 DSLOWER,0100000 DSUPPER,0577777

indicates 2 small program-level heaps, and 3 large program-level heaps with three
262K word blocks each. Each VALTAB-specified small bank has an address range
of 0100000 to 0577777.

7831 4077–009 6–243

Application Programming in an HVTIP Environment

6.5.2. HVTIP-II BDI Allocation

The default BDI allocation for HVTIP-II programs is as follows:

Program-level
BDI 4 is the code bank, BDI 5 is the implicit (main) data heap bank, and extra
program-level heap banks start at BDI 6. The small banks will be allocated first,
followed by the large banks.

Activity-level
BDI 1 is reserved for code. BDI 2 is reserved for template data. Extra activity-level
heap banks start at BDI 3. The small banks are allocated first, followed by the
large banks.

Note: The extra program-level and activity-level heap banks are those specified
using the new VALTAB parameters. However, if no extra heap banks are specified
using new VALTAB parameters, and the LINK for the HVTIP-II ZOOM references
extra BDIs, the HVTIP heap manager will attempt to dynamically acquire those
specific BDIs.
Program-level BDI 4 and BDI 5 have the same meaning and purpose as in the original
UCS HVTIP environment. All other BDIs allocated represent bank containers with a
lower-limit of 0 and an upper-limit ending with 777777 (262,144 word blocks) unless
the DSLOWER or DSUPPER VALTAB keywords are used.

6.5.3. HVTIP-II Linking System Commands

There are a number of new commands and existing command extensions that are
designed primarily for the HVTIP-II environment. Some of these have been discussed
or referenced already. Basically, the set of HVTIP-II specific LINK commands includes
OUTPUT HVTIP2 and PROCESS FOR EXTENDED HVTIP2
SET ICP
SET LOWADR
SET BOOKKEEPING_SIZE
SET FAST_LOAD_MONITOR
SET DEFAULT_LBDI
SET MIXED_COMMON

The exact syntax of these commands is described in the Linking System

Programming Reference Manual. The rest of this section shows an example of their
use in the context of static linking HVTIP2 ZOOMs.

Example
HVTIP-II ICP LINK
@LINK
:
OUTPUT HVTIP2 WITH ALLOW_CREATE_BANK = FALSE,
TS_MISMATCH_ACTION = CANCEL
USING 4 SMALL_BANKS,

6–244 7831 4077–009

 Application Programming in an HVTIP Environment

2 POOLED_SMALL_BANKS,
1 LARGE_BANKS,
LARGE_BANK_SIZE=2 FOR PROGRAM_LEVEL_HEAP
1 LARGE_BANKS,
LARGE_BANK_SIZE = 3
FOR ACTIVITY_LEVEL_HEAP
SET ICP=TRUE
SET BOOKKEEPING_SIZE=1
SET FAST_LOAD_MONITOR=1
SET LOWADR = 0600003002000 FOR HVTIP$$DSEG

In this example, the OUTPUT HVTIP2 command corresponds to a VALTAB

specification similar to the following:
DSPRGCNT,4 DLPRGCNT,1 DPSIZL,2 DSACTCNT,0 DLACTCNT,1 DASIZL,3

where

DSPRGCNT,4 DLPRGCNT,1 DPSIZL,2

indicates 4 small program-level banks (2 nonpooled and 2 pooled), 1 large
program-level bank (2*262K words).

DSACTCNT,0 DLACTCNT,1 DASIZL,3

indicates 0 small activity-level banks and 1 large activity-level bank (3*262K words).

The bank numbers of pooled banks (program or activity level) are always allocated at
the end of the corresponding (small or large) bank set. Large banks (program or
activity) always follow all small banks in the bank numbering scheme. (Pooled banks
are HVTIP-II heap banks that are reserved for data other than HVTIP segments. The
current uses for pooled banks include FLSS subsystem heap space and UCS malloc
space.) Note that malloc space is currently allocated only out of activity-level banks.

Also be aware that RDMS does C malloc calls to acquire workspace. If your HVTIP2
application uses RDMS and you do not supply any activity-level pooled banks, URTS
does a CREATE$BANK call and your transaction loses TIP sticking and restart.

7831 4077–009 6–245

Application Programming in an HVTIP Environment

Following the default BDI allocation mapping at program and activity level, the Linking
System creates an HVTIP-II ZOOM with this heap bank information since this ZOOM is
also an ICP:

In this example, small pooled banks are allocated at LBDI=0400010 and 0400011. Data
segments cannot be allocated to these banks. It is advisable to use the SET ICP
command to indicate whether or not the ZOOM being created is an ICP. Without the
SET ICP command, the Linking System has to determine whether or not the ZOOM
being created is an ICP, which is not possible to determine accurately in all situations.

When multiple heaps are being used, you should use the appropriate WITH and USING
clauses of the OUTPUT or PROCESS command to ensure that the pooled banks and
segments in large banks are handled as intended. Pooled bank count information is
only processed by the HVTIP heap manager if the ZOOM is truly being loaded as an
ICP, since that is the only time when heaps are initialized for the transaction. VALTAB
information overrides ZOOM information if they conflict.

The ALLOW_CREATE_BANK WITH clause controls whether FLSS (Fast-Load

Self-Contained) Subsystem and UC malloc functions are allowed to perform
CREATE$BANK Exec calls. The default is TRUE. TIP transaction sticking and RESTART
are inhibited if any CREATE$BANK calls are made.

The TS_MISMATCH_ACTION WITH clause is used to inform the HVTIP heap manager
what action to take when it finds that a subprogram ZOOM has been changed during
the execution of the transaction and its timestamp no longer matches the value it had
the last time the HVTIP heap manager loaded it.

TS_MISMATCH_ACTION=CANCEL will cancel the original subprogram, load the new

version of the subprogram, and continue the transaction. The other distinct option is
to error terminate the transaction. The default action is a combination of cancel and
error termination as described in the Linking System Programming Reference
Manual.

6–246 7831 4077–009

 Application Programming in an HVTIP Environment

The SET BOOKKEEPING_SIZE command allows for tailoring of various internal tables
used by the HVTIP heap manager. The most common reason for using this command
is when the following message is issued during transaction execution:
"Nested CALL limit exceeded, reLINK ICP"

In this case, the ICP should be relinked with a larger PSEUDOSTACK size. The SET
BOOKKEEPING_SIZE=1 command in the example sets the PSEUDOSTACK size to
accommodate 16 entries (the default is 8). Tailoring of the other tables and areas is
described in the Linking System Programming Reference Manual.

The SET FAST_LOAD_MONITOR command is used to set certain debugging flags for
processing by the HVTIP heap manager.

As noted earlier, the SET LOWADR command has been expanded for HVTIP-II. In the
example, a segment named HVTIP$$DSEG is to be located in the activity-level heap
specified by BDI 3 (LBDI 0600003) with a lower offset of 02000. The 0600003002000
is known as an extended mode virtual address (VA). The purpose of SET LOWADR is
the same in the HVTIP-II environment as in the original UCS HVTIP environment: to
eliminate or minimize data segment relocation within data heap banks, since relocation
is a costly operation. Given the expanded heap space available in HVTIP-II, it should be
much easier to allocate data segments to specific heap banks to avoid relocation
when loading.

Another purpose of the LOWADR command in the HVTIP-II environment is to identify

the segment’s target container heap when it is not the default heap. If the requested
address is unavailable, the HVTIP heap manager attempts to select another location
within the same heap bank. If space is not available in the selected heap bank, the
heap manager will look for space in other heap banks.

The SET DEFAULT_LBDI command selects the LBDI for data banks and segments that
have no SET LOWADR LBDI specified. During an HVTIP-II or FLSS static link, the linker
remembers the latest program-level BDI and the latest activity-level BDI. The initial
default program-level BDI is 5, and the initial default activity-level BDI is 3. When the
statement SET LOWADR = 0100000 for x is encountered, the linker attaches the
current default BDI for bank x’s locality to bank x. If no SET LOWADR statement
exists for bank x, the last default is used.

The SET MIXED_COMMON command controls whether a mixture of indexed and

nonindexed common banks are allowed in the transaction. The default is FALSE,
which is compatible with the original HVTIP.

Appendix E, "FLSS Heap Banks, Segment Addresses, and TIP Restarts" in the Linking
System Subsystems Programming Guide (7830 7451) gives good information on
details concerning linking and segment addresses for both FLSS subsystems and
HVTIP-II. There is a lot of similarity in the structure and run-time handling of FLSS
subsystems and HVTIP-II ZOOMs.

7831 4077–009 6–247

Application Programming in an HVTIP Environment

6–248 7831 4077–009

Section 7
Using the COBOL CALL identifier
Statement

This section discusses topics relating to the use of the COBOL CALL identifier feature
in application programs.

7.1. The COBOL CALL identifier Statement

The COBOL CALL identifier statement calls a user-supplied data name that represents
a subprogram name. During execution, the program assigns the data name identifier
one or more subprogram names; these subprograms are then called. When the CALL
identifier statement executes, the Linking System is invoked to resolve the reference
to identifier. This process is sometimes referred to as explicit resolution.

Figure 7–1 shows the use of the CALL identifier statement. SUBPRGA and SUBPRGB
represent subprogram names. During execution, PROGRAM1 supplies either the value
SUBPRGA or the value SUBPRGB to identifier-1, depending upon the value of the
variable data-1. SUBPRGA or SUBPRGB is then called.

7831 4077–009 7–1

Using the COBOL CALL identifier Statement

Figure 7–1. COBOL CALL identifier

7.2. Using CALL identifier with Standard Object

Modules
With the CALL identifier statement, the actual subprogram name is supplied during
execution. This means the operating system must invoke the Linking System to
dynamically resolve the reference. Standard object modules can use the linking
method described in this subsection, whether they are in a Home Subsystem
executable or in a fixed gate subsystem. This method is as follows.

CALL identifier is a reference to a user program; therefore, the COBOL compiler has
attached the library code name UCS$EMUSER to the reference. (For information on
this process, see the Linking System Programming Reference Manual.) Thus, the
Linking System searches the files represented by UCS$EMUSER for the definition of
identifier.

By default, UCS$EMUSER includes a search of the library code name $LOCAL. To

ensure that the Linking System can locate the desired subprogram during execution,
do one of the following:
• Place the desired subprogram in the same file as the main program.

7–2 7831 4077–009

 Using the COBOL CALL identifier Statement

• Define the library code name $LOCAL to include a search of the file containing the
desired subprogram. (For information on this process, see the Linking System
Programming Reference Manual.)

Note that when you use CALL identifier for ASCII identifiers, COBOL automatically
converts all letters in the reference name to uppercase before passing the name to
the Linking System.

When using the COBOL CALL identifier in object modules, the code that is targeted
does not need to be static linked into your application. The linker can find and load the
code if the entry point called does not exist in the currently executing code. If you
have a very large application where most of the code will usually never be called, this
can help minimize the size of the code that is loaded during execution. If a module isn't
called it will not be loaded. You can also do this with standard calls (CALL subprog-
name). You can leave the targets of the calls “dangling” (unresolved) by not linking
them into your application. If called at execution time, a link-fault will occur and the
code will be loaded by the linker.

Note: This strategy does not work with ZOOMs. ZOOMs cannot link-fault.

For standard object modules, the default method of handling the COBOL CALL
identifier results in a call to the linker. This involves a lookup and possibly an object
module load if the code has not been loaded yet. The linker is single-thread on these
calls. Transactions that call into a subsystem that heavily uses COBOL CALL identifier
can end up queuing behind the linker's Test & Set cell due to the heavy traffic. This is
especially true if the subsystem is a Self Contained Subsystem (SCSS) that often also
needs the linker to load the local SCSS dbank when called from a new transaction
copy. A load takes much longer than a simple name-resolution call. So, object modules
(and especially SCSSs) would benefit greatly from using the expedited LSI$RES-NAME
method to handle CALL identifier calls that was originally implemented for ZOOMs
and is described in the following sections. Object modules can also use the LSI$RES-
NAME method in a way that blends and optimizes the two approaches to handling
CALL identifier. That is described in section 7.4

Note: Due to the following restrictions, it is recommended that standard ZOOMs

using CALL identifier use the resolution method described in 7.3. This method also
reduces the overhead of the CALL statement, since the Linking System is not
invoked at execution time.
Standard ZOOMs executing in batch or demand can also use this process. However,
the following two conditions must be met:
1. The target of the CALL cannot be in a ZOOM. The entry points that are called
must be in standard object modules and cannot be in ZOOMs or bound object
modules.
2. The object module that contains the target of the CALL must be a fully resolved
object module. That is, all references must be resolved either at static link time
or when the object module is loaded. A link fault cannot occur if the program
execution began in a ZOOM. This restriction does not apply if the program
began execution in a bound object module.

7831 4077–009 7–3

Using the COBOL CALL identifier Statement

7.3. Using CALL identifier with TIP and HVTIP

ZOOMs
TIP and HVTIP COBOL ZOOMs cannot invoke the Linking System to dynamically
resolve CALL identifier statements. TIP and HVTIP ZOOMs must use the static linking
method for resolution described in this subsection. Standard ZOOMs executing in
batch or demand mode can also use this method, thereby improving program
performance. This method is as follows.

From the release tape, you copy a source program that explicitly resolves the CALL
identifier statement. (This interface is named LS$RES_NAME.) You edit this program
as necessary, so that it includes all definitions potentially needed for resolving CALL
identifier statements in your program You assemble this program. Finally, you include
this program in the static link when you create your TIP or HVTIP ZOOM.

The following steps describe the process in more detail:

1. Copy the symbolic element SYS$LIB$*LINK.LSI$RES-NAME into a user file. This

element contains a template that you must edit to create a symbolic element that
includes the code necessary to resolve all CALL identifier statements in the
calling program. For example
@COPY,S SYS$LIB$*LINK.LSI$RES-NAME,Q*USER-FILE.LSI$RES-NAME

A listing of this element is found in 7.3.1.

Alternatively, you can use the following statement:
@COPY,S SYS$LIB$*LINK.LSI$RES-NAMH,Q*USER-FILE.LSI$RES-NAME

The LSI$RES-NAMH version uses a hash table to speed up its operation.

2. At the designated place in this element, write a DECLARE directive for each
possible CALL identifier value. DECLARE directives create the required entry
point definitions. Make sure that the value of identifier is in uppercase. For
example
DECLARE 'IDENTIFIER-1',*0,*0,*0

DECLARE directives are discussed in 7.3.2.

3. Assemble (@MASM) the symbolic element, producing an object module that

contains the set of definitions for the CALL identifier statements. For example
@MASM,S Q*USER-FILE.LSI$RES-NAME,Q*USER-FILE.LSI$RESNAME/OM

7–4 7831 4077–009

 Using the COBOL CALL identifier Statement

Note: Unisys supports extended mode MASM usage (assembler directive

$EXTEND with or without assembler directive $OBJ) only in software written
by Unisys or in interfaces written by the customer that explicitly require
extended mode assembler-produced elements according to the documentation
written by Unisys. In a “nonextended mode” MASM usage (absence of
assembler directive $EXTEND), Unisys does not support the generation of
object modules (use of assembler directive $OBJ) but will continue to provide
full support for the generation of other provided element types that are not
object modules (absence of both the $EXTEND and $OBJ assembler directives).

4. Include the object module produced in step 3 in the static link when creating the
calling program’s COBOL ZOOM. This incorporates the set of CALL identifier
definitions into the ZOOM.
For example
INCLUDE Q*USER-FILE.LSI$RES-NAME/OM
RESOLVE ALL REFERENCES EXCEPT LS$RES_NAME USING LCN

or
RESOLVE ALL REFERENCES USING Q*USER-FILE.,LCN

or
INCLUDE Q*USER-FILE.LSI$RES-NAME/OM
RESOLVE ALL REFERENCES USING LOCAL_DEFS, LCN

When the system loads the COBOL ZOOM, the code included within the ZOOM in
step 4 resolves each CALL identifier reference using the definitions provided by the
DECLARE directives described in step 2. Each definition represents a subprogram
entry point; when the CALL identifier statement calls such an entry point, the called
subprogram is loaded and executed.

See 7.3.1 for the listing of the LSI$RES-NAME element described in step 1. See 7.3.2
for a description of the DECLARE directive mentioned in step 2.

7831 4077–009 7–5

Using the COBOL CALL identifier Statement

7.3.1. Listing of SYS$LIB$*LINK.LSI$RES-NAME

Example 7–1 is a listing of the symbolic element SYS$LIB$*LINK.LSI$RES-NAME. This
is the element copied in step 1, edited in step 2, assembled in step 3, and included in
the static link in step 4 of the procedure described in 7.3.

$include 'maxr$' . 02067

$include 'om$def' . 02067
$include 'eru$' . 02067
$ascii . 02067
$obj . 02067
$extend . 02067
om$use_lv ,x2,b2 . 02067
. 02067
LS$STRONG_LVE $EQU +(OM$REF_FORM OM$CODE,OM$STRONG,; . 02273
OM$LVE,OM$MSU,OM$NONE) . 02273
. 02273
dbl_wrd FORM 36,36 . 02273
. 02273
. * * * * * * * * * * * * 02273
. SET 'String',value * 02273
. * * * * * * * * * * * * 02273
itsz equ 4 . 02273
p1 PROC *1 . 02273
set* name . 02273
n equ p1(1,1) . 02273
r equ $SL(n)///4 . 02273
r equ r>0->1!0 . 02273
+ $SL(n)/4+r,$SL(n) . 02273
j do 1,$SL(n),itsz , + $SS(n,j,itsz)LS . 02273
dbl_wrd p1(1,2),0 . 02273
end . 02273
. 02273
. 02273
. * * * * * * * * * * * * * * * * * * * * 02273
. DECLARE 'String',reference,LCN,Type * 02273
. * 03151
. Note: Specify *0 to get the default * 03151
. for that field. * 03151
. * * * * * * * * * * * * * * * * * * * * 02273
p2 PROC *1 . 02273
declare* name . 02273
IF p2(1,*4) . 02273
ANDF p2(1,*2) . 02273
ANDF p2(1,*3) . 02273
DISPLAY 1 . ,p2(1,1),'IMPORT','ls$strong_lve' . 02273

Example 7–1. Listing of SYS$LIB$*LINK.LSI-RES-NAME

7–6 7831 4077–009

 Using the COBOL CALL identifier Statement

x $IMPORT ls$strong_lve p2(1,1) . 03211

ENDF . 02273
IF p2(1,*4) . 02273
ANDF p2(1,*2)=0 . 02273
ANDF p2(1,*3) . 02273
DISPLAY 2 . ,p2(1,1),'IMPORT','ls$strong_lve',p2(1,2) . 02273
x $IMPORT ls$strong_lve p2(1,2) . 03211
ENDF . 02273
IF p2(1,*4) . 02273
ANDF p2(1,*2) . 02273
ANDF p2(1,*3)=0 . 02273
DISPLAY 3 . ,p2(1,1),'IMPORT','ls$strong_lve',p2(1,3) . 02273
x $IMPORT ls$strong_lve,p2(1,3) p2(1,1) . 03211
ENDF . 02273
IF p2(1,*4) . 02273
ANDF p2(1,*2)=0 . 02273
ANDF p2(1,*3)=0 . 02273
DISPLAY 4 . ,p2(1,1),'IMPORT','ls$strong_lve',p2(1,3),p2(1,2) .02273
x $IMPORT ls$strong_lve,p2(1,3) p2(1,2) . 03211
ENDF . 02273
IF p2(1,*4)=0 . 02273
ANDF p2(1,*2) . 02273
ANDF p2(1,*3) . 02273
DISPLAY 5 . ,p2(1,1),'IMPORT',p2(1,4) . 02273
x $IMPORT p2(1,4) p2(1,1) . 03211
ENDF . 02273
IF p2(1,*4)=0 . 02273
ANDF p2(1,*2)=0 . 02273
ANDF p2(1,*3) . 02273
DISPLAY 6 . ,p2(1,1),'IMPORT',p2(1,4),p2(1,2) . 02273
x $IMPORT p2(1,4) p2(1,2) . 03211
ENDF . 02273
IF p2(1,*4)=0 . 02273
ANDF p2(1,*2) . 02273
ANDF p2(1,*3)=0 . 02273
DISPLAY 7 . ,p2(1,1),'IMPORT',p2(1,4),p2(1,3) . 02273
x $IMPORT p2(1,4),p2(1,3) p2(1,1) . 03211
ENDF . 02273
IF p2(1,*4)=0 . 02273
ANDF p2(1,*2)=0 . 02273
ANDF p2(1,*3)=0 . 02273
DISPLAY 8 . ,p2(1,1),'IMPORT',p2(1,4),p2(1,3),p2(1,2) . 02273
x $IMPORT p2(1,4),p2(1,3) p2(1,2) . 03211
ENDF . 02273
n equ p2(1,1) . 02273
r equ $SL(n)///4 . 02273
r equ r>0->1!0 . 02273
+ $SL(n)/4+r,$SL(n) . 02273

Example 7-1. Listing of SYS$LIB$*LINK.LSI-RES-NAME

7831 4077–009 7–7

Using the COBOL CALL identifier Statement

j do 1,$SL(n),itsz , + $SS(n,j,itsz)LS . 02273

+ (x)d . 03211
end . 02273
. 02273
. 02273
. 02273
$(0) $bank om$data_emb 'ls$db1' . 02273
ls$resnm_dat* . 02273
. *************** E X A M P L E S **************************** 02273
. ************************************************************** 02273
. ** SET 'string',0400016001000 ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 02273
. ** DECLARE 'name1',LCN ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 03151
. ** COBOL CALL identifier-1 EXAMPLEs: ** 05512
. ** If an entry point can be CANCEL'd, put in its ** 05512
. ** CN$$... name also. ** 05512
. ** ** 03151
. ** DECLARE 'SUBPRGA',*0,*0,*0 ** (1) 03151
. ** DECLARE 'DATABASE-UPDATE',*0,*0,*0 ** (1) 05512
. ** DECLARE 'CN$$DATABASE-UPDATE',*0,*0,*0 ** (1) 05512
. ** ** 03151
. ************************************************************** 03151
. 03151
. Put your SET or DECLARE directives here. (They are case-sensitive) 05512
. There is no minimum or maximum number (within reason) (2) 05512
. 02273
. 05512
. 02273
. End of user-inserted SET or DECLARE directives 05512
. 02273
. ************************************************************** 02273
. 02273
. 02273
. If you wish to define a list 'RES' area for names to be dynamically 05512
. found and added to the list at runtime, put the desired reserve value 05512
. in the tag DESIRED_RES below. 05512
. 05512
DESIRED_RES $EQU 0 . <<< Change this value to define a 'RES' area<<<<<<<
. 05512
$DO DESIRED_RES , +0 . <<< Do NOT edit this line, zeros are required<<<<<
. 05512
. ********************************************************************* 05512

Example 7–1. Listing of SYS$LIB$*LINK.LSI-RES-NAME

7–8 7831 4077–009

 Using the COBOL CALL identifier Statement

. 02273
ls$resnm_stp* $equ $-ls$resnm_dat . 05512
'*RES' . tag the end 05512
'END*' . tag the end 05512
+0 . # Dynamic calls done to linker 05515
. 02273
$(1) $bank om$code_emb . 02273
. 02273
ls$res_name* . 02273
. 02273
lx,u x2,0 . Void the LV register 02408
lbu b2,r0 . Base the LVE bank 02273
. 02273
$IF DESIRED_RES=0 . 05512
om$call ls$fastresnm . Call the actual LS$RES_NAME code(3)02273
$ELSE . 05512
l,u a2,DESIRED_RES . 05512
om$call ls$fastres2 . This one will dynamically-resolve 05512
. any EPs not in the list,and add them
. to the 'RES' area of the list. 05512
$ENDF . 05512
rtn . Return to the caller 02273
. 02273
$end . 02273

Example 7-1. Listing of SYS$LIB$*LINK.LSI-RES-NAME

Explanations
1. These are examples of DECLARE directives (see 7.3.2) for programs called by
COBOL CALL identifier statements.
2. Specify your DECLARE directives immediately following the comment “Put the
SET or DECLARE directives here.”
3. During assembly (@MASM), the “om$call ls$fastresnm” statement receives a “U”
flag, indicating an undefined name in the assembly. You can ignore this “U” flag:
The name will be resolved by the static-link process when you statically link the
ZOOM.

7.3.2. Specifying DECLARE Directives in LSI$RES-NAME

The DECLARE directive creates a two-word entry point definition. You specify
DECLARE directives in the element illustrated in Example 7-1.

(The two-word definition is in link-vector-entry format: One word contains the virtual
address of the entry point, one word contains the virtual address of the called
subprogram’s link vector bank. See the Linking System Programming Reference
Manual for details.)

Generic Format
DECLARE[,1] 'string-name', exref-name, libcodename, type

7831 4077–009 7–9

Using the COBOL CALL identifier Statement

COBOL CALL identifier format

DECLARE[,1] 'subprog-name',*0,*0,*0

,1
is an optional flag indicating that the CANCEL CN$$... version of the entry point
should be generated also. This only works on the LSI$RES-NAMH version.

where

'subprog-name'

is the subprogram name whose entry point definition is required. (This is the actual
subprogram name, not the variable data name specified in the CALL identifier
statement itself.)
Enclose the value within apostrophes. Make sure the value you supply for
subprog-name is in uppercase.

exref-name
is typically the same as ’subprog-name’. The default, denoted by *0, is
’subprog-name’.

libcodename
is the library code name representing the file or files containing the definition of
’subprog-name’. The default, denoted by *0, is $DEFAULT. Always specify *0.

type
identifies the kind of resolution needed so that the correct type of definition is
returned for ’subprog-name’ The default, denoted by *0, is LS$STRONG_LVE.

Examples
Assume that a COBOL program contained the following statement:

CALL name.

where name is an alphanumeric variable that contains one of the following ASCII
strings: “SUBPRGA” or “SUBPRGB”. The following DECLARE directives would be
used for subprograms SUBPRGA and SUBPRGB.

DECLARE 'SUBPRGA',*0,*0,*0

DECLARE 'SUBPRGB',*0,*0,*0

If you are in an HVTIP environment, you must use an HVCALLS element to identify the
location of the HVTIP library and bank number for the desired subprogram. In this
case, the subprogram name specified in the HV$CALL or HV$XFR$CANCL statement
must exactly match the subprogram name in the DECLARE directive.

As an example, the following statements used in an HVCALLS element would

correspond to the DECLARE directives for SUBPRGA and SUBPRGB shown previously.

7–10 7831 4077–009

 Using the COBOL CALL identifier Statement

(These examples assume SUBPRGA resides in library number 4, bank number 15, and
SUBPRGB in library number 4, bank number 16.)

SUBPRGA HV$CALL 4,15,0

SUBPRGB HV$XFR$CANCL 4,16,0

For more information, refer to the following topics found in 6.1.2.7:

• “Calling an HVTIP Subprogram”
• “Calling Subprograms by Using an HVTIP Call Interface (HV$CALL)”
• “Calling Subprograms by Using an HVTIP Transfer-with-Cancel Interface
(HV$XFR$CANCL)”

7831 4077–009 7–11

Using the COBOL CALL identifier Statement

7.3.3. Specifying CANCEL identifier Names

Every COBOL subprogram has a CANCEL entry point which is its regular entry point
name preceded by CN$$. A COBOL subprogram with entry point SUBPRGA therefore
has a CANCEL entry point of CN$$SUBPRGA. A COBOL program which does a
CANCEL identifier statement can also use the LSI$RES-NAME/LSI$RES-NAMH
mechanism in order to speed up execution. (This method must be used for TIP and
HVTIP ZOOMs.) The CN$$... version of the entry point can be coded in a DECLARE
directive, just like the regular entry point is. If you are using the LSI$RES-NAMH
version, the CN$$... entry point can be obtained also by putting a ,1 on the DECLARE
directive for the main entry point.

Examples
As an example, a COBOL subprogram both calls and CANCELs an identifier whose
value could be ’SUBPRGA’ or ’SUBPRGB’. Here is a portion of the COBOL program,
and the DECLARE directives necessary for the LSI$RES-NAME and LSI$RES-NAMH
elements.
.
.
LINKAGE SECTION.
01 PROGNAME PIC X(12).
01 PARM1 PIC X(12).
PROCEDURE DIVISION USING PROGNAME PARM1.
BEGIN.
CALL PROGNAME USING PARM1.
CANCEL PROGNAME.
EXIT PROGRAM.

LSI$RES-NAME or LSI$RES-NAMH DECLAREs:

DECLARE 'SUBPRGA',*0,*0,*0
DECLARE 'CN$$SUBPRGA',*0,*0,*0
DECLARE 'SUBPRGB',*0,*0,*0
DECLARE 'CN$$SUBPRGB',*0,*0,*0

LSI$RES-NAMH DECLAREs could also be coded this way:

DECLARE,1 'SUBPRGA'
DECLARE,1 'SUBPRGB'

You should also see Appendix D in the Linking System Subsystems Programming
Guide (7830 7451–004) concerning the COBOL CANCEL statement. It gives more
details on COBOL CANCEL, including CANCELs of code in fixed-gate subsystems.

7–12 7831 4077–009

 Using the COBOL CALL identifier Statement

7.4. Using the LSI$RES-NAME Method with Object

Modules
The method described in 7.3 consists of editing a copy of the Linker symbolic
SYS$LIB$*LINK.LSI$RES-NAME and inserting DECLARE directives into it for all of the
entry points in your program that might be the target of CALL identifier statements.
You can also use this method for standard object modules, whether they are in a
Home Subsystem executable or in a fixed gate subsystem. If all of the entry points are
in the LSI$RES-NAME copy, their code will be loaded when the subsystem is loaded,
and the linker will not be involved later during normal execution.

However, that may result in a lot more code and data being loaded than is actually
needed if many of those entry points will never be called. This is true both for Home
Subsystem executables and fixed gate subsystems. For Self Contained Subsystems
(SCSS) this can be especially important since every execution thread using an SCSS
requires the linker to load its local data. Loading “extra” data for code that will never
be called can result in a significant amount of wasted memory.

For object modules (but not for ZOOMs), you can use the LSI$RES-NAME method in a
way that blends the quite-dynamic method of calling the linker and the quite-static
method of linking-in all of the code into your application at static link time. In the
LSI$RES-NAME source, there is a place where it tells you to put your DECLARE
directives. Right after it is a place where you can define a reserve area that can be
used to dynamically place entry points that are called by CALL identifier and that are
not in the original DECLARE list. If you define a reserve area and a CALL identifier
name is not in the list, the linker will be called to resolve the name (and load it if it
hasn't been loaded yet) and it will be placed into the list in the reserve area. It is then
immediately accessible the next time it is needed with no linker call. The reserve area
is empty in the supplied LSI$RES-NAME copy in the linker file. This is the statement
that defines it:

DESIRED_RES $EQU 0 . <<< Change this value to define a 'RES' area<<<<<<

You can even take it to the extreme and not place any DECLARE directives in the
LSI$RES-NAME element, and define only a reserve area if you wish. All names called
by CALL identifier will then be dynamically resolved by the linker and placed into the
list. Once most of the names that are being called have been placed into the list, you
are no longer calling the linker and potentially queuing-up behind its Test & Set. If the
list is not large enough for all of the entry points that are called by CALL identifier, new
ones will still be resolved by dynamic calls to the linker but will not be tabled in the list.
Each call will go to the linker to be “resolved”, which is the same thing that happens
on normal CALL identifer calls with object modules.

When you define a reserve area in LSI$RES-NAME, you must estimate the space that
is needed. Each entry point needs space for the entry point name in ASCII and for 3
words of control information. The entry point "DB-SUBPROG" would need 6 words.
When you estimate the reserve area size, don't make it too small. If the list fills-up
then the CALL identifier calls executed on entry points not in the list will end-up
always going to the linker, impairing efficiency.

7831 4077–009 7–13

Using the COBOL CALL identifier Statement

Here is an example. Assume you wish to set up an LSI$RES-NAME for your application
where you want to initially only put the names "ICP-DRIVER" and "VALIDATE-PARMS"
into the DECLARE list. You have also determined that you would need about 300
words for the dynamic reserve area to handle the other names that will come-in
dynamically. This is what the LSI$RES-NAME code would look like. (Some of the
comments that tell you how to use this method have been removed from the source
below.)
. 02273
. ************************************************************** 03151
. ** COBOL CALL identifier-1 EXAMPLEs: ** 05512
. ** If an entry point can be CANCEL'd, put in its ** 05512
. ** CN$$... name also. ** 05512
. ** ** 03151
. ** DECLARE 'SUBPRGA',*0,*0,*0 ** 03151
. ** DECLARE 'DATABASE-UPDATE',*0,*0,*0 ** 05512
. ** DECLARE 'CN$$DATABASE-UPDATE',*0,*0,*0 ** 05512
. ** ** 03151
. ************************************************************** 03151
. 03151
. Put your SET or DECLARE directives here. (They are case-sensitive) 05512
. There is no minimum or maximum number (within reason) 05512
. 02273
DECLARE 'ICP-DRIVER',*0,*0,*0,*0
DECLARE 'VALIDATE-PARMS',*0,*0,*0
. 02273
. End of user-inserted SET or DECLARE directives 05512
. 02273
. ************************************************************** 02273
. 02273
. 02273
. If you wish to define a list 'RES' area for names to be dynamically 05512
. found and added to the list at runtime, put the desired reserve value 05512
. in the tag DESIRED_RES below. 05512
. 05512
. 05512
DESIRED_RES $EQU 300 . <<< Change this value to define a 'RES' area<<<<<<<
. 05512
$DO DESIRED_RES , +0 . <<< Do NOT edit this line, zeros are required<<<<<<
. 05512
. ******************************************************************** 05512
. 02273
ls$resnm_stp* $equ $-ls$resnm_dat . 05512

7–14 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5. Examples of Using CALL identifier with

ZOOMs
This subsection gives an example of use of the CALL identifier statement in the
following situations:
• Standard ZOOM (batch or demand mode) calling either of two subprograms
• TIP ZOOM main program calling either of two subprograms
• HVTIP ZOOM ICP calling either of two subprograms

Each example is composed of the following general components:

1. A source listing of the main program or ICP
2. A partial source listing of the copied and edited LSI$RES-NAME element
3. Source listings of the called subprograms
4. A source listing of a runstream to set up, compile, and link (and, for batch and
demand, execute) the example program
5. The execution of the runstream (output saved by an @BRKPT statement)
6. For TIP and HVTIP, examples of executions of transactions

The HVTIP example also includes the following:

• A source listing of an MCB packet
• A source listing of the ICP HVCALLS element
• A source listing of the jump vector required for subprograms with multiple entry
points

7831 4077–009 7–15

Using the COBOL CALL identifier Statement

7.5.1. Standard (Batch/Demand) ZOOM Calling Two

Subprograms
This subsection describes the use of the COBOL CALL identifier statement in a
standard ZOOM. The method shown provides the best performance for a batch and
demand environment.

The following figure summarizes the COBOL main program and subprograms used in
the example. In this example, PROGRAM1 is a main program that calls either
subprogram SUBPRGA or subprogram SUBPRGB, depending on the value of the
variable data-1. Either ’SUBPRGA’ or ’SUBPRGB’ is substituted for identifier-1 in the
CALL identifier statement.

7–16 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.1.1. Source Listing of the Main Program (PROGRAM1)

Example 7–2 shows the complete source listing of the main program, PROGRAM1. In
this example, this program is found in element QUAL*UCSTST.PROGRAM1.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A MAIN PROGRAM "PROGRAM1" THAT USES THE *
* CALL identifier-1 STATEMENT TO CALL EITHER *
* SUBPROGRAM "SUBPRGA" OR SUBPROGRAM "SUBPRGB" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. PROGRAM1.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DATA-1 PIC X(3).
01 IDENTIFIER-1 PIC X(7).
PROCEDURE DIVISION.
******************************************************
*** PROGRAM1 START UP ***
******************************************************
BEGIN.
DISPLAY 'THIS IS PROGRAM1' UPON PRINTER.
******************************************************
*** READ INPUT DATA ***
******************************************************
READ-DATA-INPUT.
ACCEPT DATA-1.
******************************************************
*** CALL TO SUBPRGA OR SUBPRGB ***
*** DEPENDING ON INPUT DATA ***
******************************************************
CALL-ID.
DISPLAY ' PROGRAM1: DATA-1 = ' DATA-1 UPON PRINTER.
IF DATA-1 = 'ABC'
THEN

Example 7–2. Source Listing of Main Program (QUAL*UCSTST.PROGRAM1)

7831 4077–009 7–17

Using the COBOL CALL identifier Statement

MOVE 'SUBPRGA' TO IDENTIFIER-1

ELSE
MOVE 'SUBPRGB' TO IDENTIFIER-1
END-IF.00 00
DISPLAY ' PROGRAM1: CALL IDENTIFIER-1 ' UPON PRINTER.
CALL IDENTIFIER-1.
******************************************************
*** PROGRAM TERMINATION ***
******************************************************
TERMINATION.
DISPLAY 'TERMINATION FROM PROGRAM1' UPON PRINTER.
STOP RUN.

Example 7-2. Source Listing of Main Program (QUAL*UCSTST.PROGRAM1)

7.5.1.2. Partial Source Listing of Edited LSI$RES-NAME Element

Example 7–3 shows a partial source listing of the element that was copied from
SYS$LIB$*LINK.LSI$RES-NAME and then edited, as described in 7.3. See 7.3.1 for the
complete listing of the release tape element SYS$LIB$*LINK.LSI$RES-NAME.

7–18 7831 4077–009

 Using the COBOL CALL identifier Statement

In this example, this routine is found in element QUAL*UCSTST.LSI$RES-NAME/STANDARD.

Noteworthy lines are bolded.

$include 'maxr$' . 02067

$include 'om$def' . 02067
$include 'eru$' . 02067
$ascii . 02067
$obj . 02067
$extend . 02067
om$use_lv ,x2,b2 . 02067
.
. (additional source statements)
.
$(0) $bank om$data_emb 'ls$db1' . 02273
ls$resnm_dat* . 02273
. *************** E X A M P L E S **************************** 02273
. ************************************************************** 02273
. ** SET 'string',0400016001000 ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 02273
. ** DECLARE 'name1',LCN ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 03151
. ** COBOL CALL identifier-1 EXAMPLES ** 03151
. ** ** 03151
. ** DECLARE 'SUBPRGA',*0,*0,*0 ** 03151
. ** DECLARE 'SUBPRGB',*0,*0,*0 ** 03151
. ** ** 03151
. ************************************************************** 03151
. 03151
. Put the SET or DECLARE directives here ** 02408
. 02273
. ************************************************************** 02273
. 02273
DECLARE 'SUBPRGA',*0,*0,*0
DECLARE 'SUBPRGB',*0,*0,*0
. 02273
. End of user-inserted SET or DECLARE directives 05512
. 02273
. ************************************************************** 02273
. 02273
. 02273
. If you wish to define a list 'RES' area for names to be dynamically 05512
. found and added to the list at runtime, put the desired reserve value 05512
. in the tag DESIRED_RES below. 05512
. 05512

Example 7–3. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/STANDARD)

7831 4077–009 7–19

Using the COBOL CALL identifier Statement

DESIRED_RES $EQU 0 . <<< Change this value to define a 'RES' area<<<<<<<

05512
$DO DESIRED_RES , +0 . <<< Do NOT edit this line, zeros are required<<<<<
. 05512
. ********************************************************************* 05512
. 02273
ls$resnm_stp* $equ $-ls$resnm_dat . 05512

Example 7–3. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/STANDARD)

7–20 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.1.3. Source Listing of Subprograms

Example 7–4 shows the complete source listing of subprogram SUBPRGA. In this
example, this program is found in element QUAL*UCSTST.SUBPRGA. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "SUBPRGA" THAT IS CALLED USING *
* CALL identifier-1 FROM THE MAIN PROGRAM "PROGRAM1" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. SUBPRGA.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** SUBPRGA START UP ***
******************************************************
BEGIN.
DISPLAY ' THIS IS SUBPROGRAM SUBPRGA' UPON PRINTER.
DISPLAY ' SUBPRGA: CALL IDENTIFIER-1. WORKED'
UPON PRINTER.
******************************************************
*** SUBPROGRAM RETURN ***
******************************************************
RETURN-TO-PROGRAM1.
DISPLAY ' RETURN FROM SUBPROGRAM SUBPRGA'
UPON PRINTER.
EXIT PROGRAM.

Example 7–4. Source Listing of First Subprogram (QUAL*UCSTST.SUBPRGA)

7831 4077–009 7–21

Using the COBOL CALL identifier Statement

Example 7–5 shows the complete source listing of subprogram SUBPRGB. In this
example, this program is found in element QUAL*UCSTST.SUBPRGB.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "SUBPRGB" THAT IS CALLED USING *
* CALL identifier-1 FROM THE MAIN PROGRAM "PROGRAM1" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. SUBPRGB.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** SUBPRGB START UP ***
******************************************************
BEGIN.
DISPLAY ' THIS IS SUBPROGRAM SUBPRGB' UPON PRINTER.
DISPLAY ' SUBPRGB: CALL IDENTIFIER-1. WORKED'
UPON PRINTER.
******************************************************
*** SUBPROGRAM RETURN ***
******************************************************
RETURN-TO-PROGRAM1.
DISPLAY ' RETURN FROM SUBPROGRAM SUBPRGB'
UPON PRINTER.
EXIT PROGRAM.

Example 7–5. Source Listing of Second Subprogram (QUAL*UCSTST.SUBPRGB)

7–22 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.1.4. Source Listing of Runstream

Example 7–6 shows a listing of the runstream used to set up, compile, link, and
execute the example program PROGRAM1. Note that this example assumes that the
LSI$RES-NAME element has already been copied and edited, as described previously.
Noteworthy lines are bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** ****** CALL 'identifier' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,
@ . *** QUAL*UCSTST.LSI$RES-NAME/STANDARD
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/STANDARD IS THEN EDITED TO
@ . *** INCLUDE THE TWO DECLARE STATEMENTS FOR THE TWO SUBPROGRAMS.
@ . ***
@ . *** DECLARE 'SUBPRGA',*0,*0,*0
@ . *** DECLARE 'SUBPRGB',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/STANDARD IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/STANDARD,QUAL*UCSTST.
@EOF
@ . ***
@ . ***
@ . *** COMPILE OF MAIN PROGRAM 'PROGRAM1'
@ . ***
@UCOB QUAL*UCSTST.PROGRAM1,.PROGRAM1/COMP,,,NO-OPTIONS
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGA'
@ . ***
@UCOB QUAL*UCSTST.SUBPRGA,.SUBPRGA/COMP,,,SUBPROGRAM,NO-OPTIONS
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGB'

Example 7–6. Runstream to Set Up, Compile, Link and Execute—COBOL Standard
ZOOM

7831 4077–009 7–23

Using the COBOL CALL identifier Statement

@ . ***
@UCOB QUAL*UCSTST.SUBPRGB,.SUBPRGB/COMP,,,SUBPROGRAM,NO-OPTIONS
@ . ***
@ . ***
@ . *** LINK OF THE MAIN PROGRAM 'PROGRAM1',
@ . *** SUBPROGRAM 'SUBPRGA', AND
@ . *** SUBPROGRAM 'SUBPRGB'.
@ . *** THIS INCLUDES THE USER ELEMENT LSI$RES-NAME/STANDARD.
@ . ***
@LINK ,QUAL*UCSTST.PROGRAM1
INCLUDE QUAL*UCSTST.PROGRAM1/COMP
INCLUDE QUAL*UCSTST.LSI$RES-NAME/STANDARD
INCLUDE QUAL*UCSTST.SUBPRGA/COMP
INCLUDE QUAL*UCSTST.SUBPRGB/COMP
RESOLVE ALL REFERENCES EXCEPT LS$RES_NAME USING LIBCODENAME
PROCESS FOR EXTENDED ZOOM
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ******* FIRST EXECUTION *******
@ . ***
@ . *** THE FIRST EXECUTION OF MAIN PROGRAM 'PROGRAM1'
@ . *** WILL PROVIDE INPUT 'ABC' THEREFORE SUBPROGRAM 'SUBPRGA'
@ . *** WILL BE CALLED
@ . ***
@XQT QUAL*UCSTST.PROGRAM1
ABC
@ . ***
@ . ***
@ . *** ******* SECOND EXECUTION *******
@ . ***
@ . *** THE SECOND EXECUTION OF MAIN PROGRAM 'PROGRAM1'
@ . *** WILL PROVIDE INPUT 'XYZ' THEREFORE SUBPROGRAM 'SUBPRGB'
@ . *** WILL BE CALLED
@ . ***
@XQT QUAL*UCSTST.PROGRAM1
XYZ 0000
@ . ***
@ . ***
@ . *** TESTING IS COMPLETE

Example 7–6. Runstream to Set Up, Compile, Link and Execute—COBOL Standard
ZOOM

7–24 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.1.5. Execution of the Source Runstream

Example 7–7 shows the execution of the source runstream described in the previous
subsection. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . ***
@ . ******** START OF THE EXAMPLE SETUP SECTION **********************
@ . ***
@ . ***
@ . *** ****** CALL 'IDENTIFIER' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,
@ . *** QUAL*UCSTST.LSI$RES-NAME/STANDARD
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/STANDARD IS THEN EDITED TO
@ . *** INCLUDE THE TWO DECLARE STATEMENTS FOR THE TWO SUBPROGRAMS.
@ . ***
@ . *** DECLARE 'SUBPRGA',*0,*0,*0
@ . *** DECLARE 'SUBPRGB',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/STANDARD IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/STANDARD,QUAL*UCSTST.
MASM 6R2A (960423 0008:22) 1997 Feb 20 Thu 1527:31
ASSEMBLY CONTAINS WARNINGS: - FLAGS: U
END MASM - LINES: 592 TIME: 4.651 STORAGE: 29345/10294 WARNINGS: U(1)
@ . ***
@ . ***
@ . *** COMPILE OF MAIN PROGRAM 'PROGRAM1'
@ . ***
@UCOB QUAL*UCSTST.PROGRAM1,.PROGRAM1/COMP,,,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:27:34
SIZES: CODE(EM6): 143 DATA: 394
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGA'
@ . ***
@UCOB QUAL*UCSTST.SUBPRGA,.SUBPRGA/COMP,,,SUBPROGRAM,NO-OPTIONS

Example 7–7. Execution of Source Runstream—COBOL Standard ZOOM

7831 4077–009 7–25

Using the COBOL CALL identifier Statement

UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:27:39

SIZES: CODE(EM6): 58 DATA: 153
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGB'
@ . ***
@UCOB QUAL*UCSTST.SUBPRGB,.SUBPRGB/COMP,,,SUBPROGRAM,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:27:44
SIZES: CODE(EM6): 58 DATA: 153
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** LINK OF THE MAIN PROGRAM 'PROGRAM1',
@ . *** SUBPROGRAM 'SUBPRGA', AND
@ . *** SUBPROGRAM 'SUBPRGB'.
@ . *** THIS INCLUDES THE USER ELEMENT LSI$RES-NAME/STANDARD.
@ . ***
@LINK ,QUAL*UCSTST.PROGRAM1
LINK 7R1 (970207 1635:57) 1997 Feb 20 Thu 1527:48
END LINK , LINES : 7 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ******* FIRST EXECUTION *******
@ . ***
@ . *** THE FIRST EXECUTION OF MAIN PROGRAM 'PROGRAM1'
@ . *** WILL PROVIDE INPUT 'ABC' THEREFORE SUBPROGRAM 'SUBPRGA'
@ . *** WILL BE CALLED
@ . ***
@XQT QUAL*UCSTST.PROGRAM1

THIS IS PROGRAM1

PROGRAM1: DATA-1 = ABC

PROGRAM1: CALL IDENTIFIER-1

THIS IS SUBPROGRAM SUBPRGA

SUBPRGA: CALL IDENTIFIER-1. WORKED

RETURN FROM SUBPROGRAM SUBPRGA

TERMINATION FROM PROGRAM1

@ . ***
@ . ***

Example 7–7. Execution of Source Runstream—COBOL Standard ZOOM

7–26 7831 4077–009

 Using the COBOL CALL identifier Statement

@ . *** ******* SECOND EXECUTION *******

@ . ***
@ . *** THE SECOND EXECUTION OF MAIN PROGRAM 'PROGRAM1'
@ . *** WILL PROVIDE INPUT 'XYZ' THEREFORE SUBPROGRAM 'SUBPRGB'
@ . *** WILL BE CALLED
@ . ***
@XQT QUAL*UCSTST.PROGRAM1

THIS IS PROGRAM1

PROGRAM1: DATA-1 = XYZ

PROGRAM1: CALL IDENTIFIER-1

THIS IS SUBPROGRAM SUBPRGB

SUBPRGB: CALL IDENTIFIER-1. WORKED

RETURN FROM SUBPROGRAM SUBPRGB

TERMINATION FROM PROGRAM1

@ . ***
@ . ***
@ . *** TESTING IS COMPLETE

Example 7–7. Execution of Source Runstream—COBOL Standard ZOOM

7831 4077–009 7–27

Using the COBOL CALL identifier Statement

7.5.2. TIP ZOOM Calling Two Subprograms

This subsection describes use of the CALL identifier statement in a TIP COBOL main
program. The method shown here is the only way that this statement can be resolved
for TIP and HVTIP ZOOMS.

The following figure summarizes the COBOL main program and subprograms used in
the example. In this example, PRGRM1 is a TIP main program that calls either TIP
subprogram SUBPRGC or TIP subprogram SUBPRGD, depending on the value of the
variable data-1. Either “SUBPRGC” or “SUBPRGD” is substituted for identifier-1 in the
CALL identifier statement.

Note the following about this example:

• This example uses DPS 2200 functions. However, you set up and use CALL
identifier in the same method for MCB functions.
• This example uses application group 3 (UDSSRC).

7–28 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.2.1. Source Listing of the Main Program (PRGRM1)

Example 7–8 shows the complete source listing of the main program, PRGRM1. In this
example, this program is found in element QUAL*UCSTST.PRGRM1. Noteworthy lines
are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A TIP MAIN PROGRAM "PRGRM1" THAT USES THE *
* CALL identifier-1 STATEMENT TO CALL EITHER *
* SUBPROGRAM "SUBPRGC" OR SUBPROGRAM "SUBPRGD" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. PRGRM1.
ENVIRONMEN DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DATA-1 PIC X(3).
01 IDENTIFIER-1 PIC X(7).
******************************************************
*** DPS PROCEDURES ***
******************************************************
COPY DPSSTATUSCOB.
COPY INFO-BUFFER.
COPY GETFIELD.
PROCEDURE DIVISION.
******************************************************
*** TRANSACTION INITIALIZATION ***
******************************************************
BEGIN.
CALL 'D$INIT' USING DPS-STATUS, INFO-BUFFER.
IF STATUS-FATAL GO TO DPS-GENERAL-ERROR-PARA.
DISPLAY 'THIS IS PRGRM1' UPON PRINTER.
******************************************************
*** READ INPUT DATA ***
******************************************************
READ-DATA-INPUT.
CALL 'D$GETFL' USING DPS-STATUS, GET-FIELD.
IF STATUS-FATAL GO TO DPS-GENERAL-ERROR-PARA.

Example 7–8. Source Listing of Main Program (QUAL*UCSTST.PRGRM1)

7831 4077–009 7–29

Using the COBOL CALL identifier Statement

CALL 'D$GETFL' USING DPS-STATUS, GET-FIELD.

IF STATUS-FATAL GO TO DPS-GENERAL-ERROR-PARA.
MOVE GETFIELD-TEXT TO DATA-1.
******************************************************
*** CALL TO SUBPRGC OR SUBPRGD ***
*** DEPENDING ON INPUT DATA ***
******************************************************
CALL-ID.
DISPLAY ' PRGRM1: DATA-1 = ' DATA-1 UPON PRINTER.
IF DATA-1 = 'ABC'
THEN
MOVE 'SUBPRGC' TO IDENTIFIER-1
ELSE
MOVE 'SUBPRGD' TO IDENTIFIER-1
END-IF.
DISPLAY ' PRGRM1: CALL IDENTIFIER-1 ' UPON PRINTER.
CALL IDENTIFIER-1.
******************************************************
*** TRANSACTION TERMINATION ***
******************************************************
TERMINATION.
DISPLAY 'TERMINATION FROM PRGRM1' UPON PRINTER.
CALL 'D$TERM' USING DPS-STATUS.
IF STATUS-FATAL GO TO DPS-GENERAL-ERROR-PARA.
STOP RUN.
************************************************************
* ONLY EXECUTED WHEN A DPS ERROR OCCURS
************************************************************
DPS-GENERAL-ERROR-PARA.
CALL 'D$DUMP'.
CALL 'D$ERRMSG' USING DPS-STATUS.
CALL 'D$TERM' USING DPS-STATUS.
STOP RUN.

Example 7–8. Source Listing of Main Program (QUAL*UCSTST.PRGRM1)

7.5.2.2. Partial Source Listing of Edited LSI$RES–NAME Element

Example 7–9 shows a partial source listing of the element that was copied from
SYS$LIB$*LINK.LSI$RES-NAME and then edited, as described in 7.3. See 7.3.1 for the
complete listing of the release tape element SYS$LIB$*LINK.LSI$RES-NAME.

7–30 7831 4077–009

 Using the COBOL CALL identifier Statement

In this example, this routine is found in element QUAL*UCSTST.LSI$RES-NAME/TIP.

Noteworthy lines are bolded.

$include 'maxr$' . 02067

$include 'om$def' . 02067
$include 'eru$' . 02067
$ascii . 02067
$obj . 02067
$extend . 02067
om$use_lv ,x2,b2 . 02067
.
. (additional source statements)
.
$(0) $bank om$data_emb 'ls$db1' . 02273
ls$resnm_dat* . 02273
. *************** E X A M P L E S **************************** 02273
. ************************************************************** 02273
. ** SET 'string',0400016001000 ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 02273
. ** DECLARE 'name1',LCN ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 03151
. ** COBOL CALL identifier-1 EXAMPLES ** 03151
. ** ** 03151
. ** DECLARE 'SUBPRGA',*0,*0,*0 ** 03151
. ** DECLARE 'SUBPRGB',*0,*0,*0 ** 03151
. ** ** 03151
. ************************************************************** 03151
. 03151
. Put the SET or DECLARE directives here ** 02408
. 02273
. ************************************************************** 02273
. 02273
DECLARE 'SUBPRGC',*0,*0,*0
DECLARE 'SUBPRGD',*0,*0,*0
. 02273
. End of user-inserted SET or DECLARE directives 05512
. 02273
. ************************************************************** 02273
. 02273
. 02273
. If you wish to define a list 'RES' area for names to be dynamically 05512
. found and added to the list at runtime, put the desired reserve value 05512
. in the tag DESIRED_RES below. 05512
. 05512

Example 7–9. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/TIP)

7831 4077–009 7–31

Using the COBOL CALL identifier Statement

DESIRED_RES $EQU 0 . <<< Change this value to define a 'RES' area<<<<<<<

05512
$DO DESIRED_RES , +0 . <<< Do NOT edit this line, zeros are required<<<<<
. 05512
. ********************************************************************* 05512
. 02273
ls$resnm_stp* $equ $-ls$resnm_dat . 05512

Example 7–9. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/TIP)

7–32 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.2.3. Source Listing of Subprograms

Example 7–10 shows the complete source listing of subprogram SUBPRGC. In this
example, this program is found in element QUAL*UCSTST.SUBPRGC. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "SUBPRGC" THAT IS CALLED USING *
* CALL identifier-1 FROM THE TIP MAIN PROGRAM "PRGRM1" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. SUBPRGC.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** SUBPRGC START UP ***
******************************************************
BEGIN.
DISPLAY ' THIS IS SUBPROGRAM SUBPRGC' UPON PRINTER.
DISPLAY ' SUBPRGC: CALL IDENTIFIER-1. WORKED'
UPON PRINTER.
******************************************************
*** SUBPROGRAM RETURN ***
******************************************************
RETURN-TO-PRGRM1.
DISPLAY ' RETURN FROM SUBPROGRAM SUBPRGC'
UPON PRINTER.
EXIT PROGRAM.

Example 7–10. Source Listing of First Subprogram (QUAL*UCSTST.SUBPRGC)

7831 4077–009 7–33

Using the COBOL CALL identifier Statement

Example 7–11 shows the complete source listing of subprogram SUBPRGD. In this
example, this program is found in element QUAL*UCSTST.SUBPRGD.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "SUBPRGD" THAT IS CALLED USING *
* CALL identifier-1 FROM THE TIP MAIN PROGRAM "PRGRM1" *
* *
******************************************************************
******************************************************************
PROGRAM-ID. SUBPRGD.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
******************************************************
*** SUBPRGD START UP ***
******************************************************
BEGIN.
DISPLAY ' THIS IS SUBPROGRAM SUBPRGD' UPON PRINTER.
DISPLAY ' SUBPRGD: CALL IDENTIFIER-1. WORKED'
UPON PRINTER.
******************************************************
*** SUBPROGRAM RETURN ***
******************************************************
RETURN-TO-PRGRM1.
DISPLAY ' RETURN FROM SUBPROGRAM SUBPRGD'
UPON PRINTER.
EXIT PROGRAM.

Example 7–11. Source Listing of Second Subprogram (QUAL*UCSTST.SUBPRGD)

7–34 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.2.4. Source Listing of Runstream

Example 7–12 shows a listing of the runstream used to set up, compile, and link the
TIP transaction shown in this example. Note that this example assumes that the
LSI$RES-NAME element has already been copied and edited, as described previously.
Noteworthy lines are bolded.

@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************

@ . ***
@ . ***
@ . *** ****** CALL 'identifier' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,QUAL*UCSTST.LSI$RES-NAME/TIP00
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/TIP IS THEN EDITED TO
@ . *** INCLUDE THE TWO DECLARE STATEMENTS FOR THE TWO SUBPROGRAMS.
@ . ***
@ . *** DECLARE 'SUBPRGC',*0,*0,*0
@ . *** DECLARE 'SUBPRGD',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/TIP IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/TIP,QUAL*UCSTST.
@EOF
@ . ***
@ . ***
@ . *** COMPILE OF THE TIP MAIN PROGRAM 'PRGRM1',
@ . *** SUBPROGRAM 'SUBPRGC', AND
@ . *** SUBPROGRAM 'SUBPRGD'.
@ . ***
@ . *** WHEN USING DPS, THE "COMPAT" KEYWORD OPTION IS REQUIRED ON
@ . *** THE COBOL COMPILER CALL.
@ . ***
@ . ***
@ . ***
@ . *** COMPILE OF TIP MAIN PROGRAM 'PRGRM1'
@ . ***
@USE COB$PF,APP3*DPS
@UCOB QUAL*UCSTST.PRGRM1,.PRGRM1/COMP,,,NO-OPTIONS
@ . ***
@ . ***

Example 7–12. Runstream to Set Up, Compile, and Link—COBOL TIP ZOOM

7831 4077–009 7–35

Using the COBOL CALL identifier Statement

@ . *** COMPILE OF SUBPROGRAM 'SUBPRGC'

@ . ***
@UCOB QUAL*UCSTST.SUBPRGC,.SUBPRGC/COMP,,,SUBPROGRAM,NO-OPTIONS00
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGD'
@ . ***
@UCOB QUAL*UCSTST.SUBPRGD,.SUBPRGD/COMP,,,SUBPROGRAM,NO-OPTIONS00
@ . ***
@ . ***
@ . *** LINK OF THE TIP MAIN PROGRAM 'PRGRM1',
@ . *** SUBPROGRAM 'SUBPRGC', AND
@ . *** SUBPROGRAM 'SUBPRGD'.
@ . *** THIS INCLUDES THE USER ELEMENT LSI$RES-NAME/TIP.
@ . ***
@ . *** SINCE DPS IS BEING USED IN THIS EXAMPLE THE FOLLOWING
@ . *** STATEMENT MUST BE ADDED TO THE STATIC LINK OF EACH
@ . *** TRANSACTION THAT USES DPS. THE FILENAME IS DEPENDENT ON
@ . *** THE INSTALLATION OF DPS. THE FILENAME 'APP3*DPS' IS USED
@ . *** IN THIS EXAMPLE.
@ . ***
@ . *** INCLUDE APP3*DPS..UCS/INTERFACE, APP3*DPS..EMCBEP$$DPS
@ . ***
@ . ***
@LINK ,QUAL*UCSTST.PRGRM1
INCLUDE QUAL*UCSTST.PRGRM1/COMP
INCLUDE QUAL*UCSTST.LSI$RES-NAME/TIP
INCLUDE QUAL*UCSTST.SUBPRGC/COMP 00
INCLUDE QUAL*UCSTST.SUBPRGD/COMP 00
INCLUDE APP3*DPS.UCS/INTERFACE, APP3*DPS.EMCBEP$$DPS
RESOLVE ALL REFERENCES EXCEPT LS$RES_NAME USING LIBCODENAME
PROCESS FOR EXTENDED FAST LOAD
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . ***
@ . *** SETS UP THE VALTAB FOR THIS EXAMPLE'S TRANSACTION.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,3 STF,0 QPR,n STA,J
@ . *** nnn REC,Z AUD,n PRT,xxxxx
@ . ***
@ . ***

Example 7–12. Runstream to Set Up, Compile, and Link—COBOL TIP ZOOM

7–36 7831 4077–009

 Using the COBOL CALL identifier Statement

@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
970 NAM,PRGRM1 ACT,PRGRM1 PRG,3 STF,0 QPR,1 STA,J
970 REC,Z AUD,3 PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF@ . ***
@ . ***
@ . *** ** SUPUR FILE SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** SUPUR TIP FILE.
@ . ***
@CAT,P UDS$$SRC*SUPURFILE.,F/1000//1000
@ . ***
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE TIP SUPUR FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE SUPUR TIP FILE THIS TEST USES FOR THE
@ . *** TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG UDS$$SRC*SUPURFILE.,FIX
RES 997,64000,28,,SUPURFILE,,,WW=P,AUDIT=0,NREC
LFD 997
@EOF
@ . ***
@ . *** USE THE SUPUR UTILITY TO CREATE A SUPUR PROGRAM FILE,
@ . *** COPY TRANSACTION PROGRAMS INTO THE SUPUR PROGRAM FILE, AND
@ . *** PLACE THE SUPUR PROGRAM FILE ONLINE.
@ . ***

Example 7–12. Runstream to Set Up, Compile, and Link—COBOL TIP ZOOM

7831 4077–009 7–37

Using the COBOL CALL identifier Statement

@TIP$*TIPRUN$.SUPUR,P
CREATE 997 MAIN
COPY ONLY PRGRM1 FROM QUAL*UCSTST TO 997
ONLINE 997
LIST ALL FROM 997
EXIT
@ . ***
@ . ***
@ . *** EXAMPLE SETUP IS COMPLETE

Example 7–12. Runstream to Set Up, Compile, and Link—COBOL TIP ZOOM

7.5.2.5. Execution of the Source Runstream

Example 7–13 shows the execution of the source runstream described in the previous
subsection. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************

@ . ***
@ . ***
@ . *** ****** CALL 'IDENTIFIER' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,QUAL*UCSTST.LSI$RES-NAME/TIP
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/TIP IS THEN EDITED TO
@ . *** INCLUDE THE TWO DECLARE STATEMENTS FOR THE TWO SUBPROGRAMS.
@ . ***
@ . *** DECLARE 'SUBPRGC',*0,*0,*0
@ . *** DECLARE 'SUBPRGD',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/TIP IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/TIP,QUAL*UCSTST.
MASM 6R2A (960423 00008:22) 1997 Feb 20 Thu 1533:18
ASSEMBLY CONTAINS WARNINGS: - FLAGS: U
END MASM - LINES: 592 TIME: 4.778 STORAGE: 29345/10294 WARNINGS: U(1)
@ . ***
@ . ***

Example 7–13. Execution of Source Runstream—COBOL TIP ZOOM

7–38 7831 4077–009

 Using the COBOL CALL identifier Statement

@ . *** COMPILE OF THE TIP MAIN PROGRAM 'PRGRM1',

@ . *** SUBPROGRAM 'SUBPRGC', AND
@ . *** SUBPROGRAM 'SUBPRGD'.
@ . ***
@ . *** WHEN USING DPS, THE "COMPAT" KEYWORD OPTION IS REQUIRED ON
@ . *** THE COBOL COMPILER CALL.
@ . ***
@ . *** COMPILE OF TIP MAIN PROGRAM 'PRGRM1'
@ . ***
@USE COB$PF,APP3*DPS.
I:002333 USE complete.
@UCOB QUAL*UCSTST.PRGRM1,.PRGRM1/COMP,,,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:33:22
SIZES: CODE(EM6): 179 DATA: 422
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@ . ***
@ . ***
@ . *** COMPILE OF SUBPROGRAM 'SUBPRGC'
@ . ***
@UCOB QUAL*UCSTST.SUBPRGC,.SUBPRGC/COMP,,,SUBPROGRAM,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:33:29
SIZES: CODE(EM6): 58 DATA: 153
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)

Example 7–13. Execution of Source Runstream—COBOL TIP ZOOM

7831 4077–009 7–39

Using the COBOL CALL identifier Statement

7.5.2.6. Execution of the TIP Transactions in This Example

Example 1
The following screen shows an execution of the TIP transaction described previously.
User input is bolded.

PRGRM1 ABC

This would produce the following printer output:

THIS IS PRGRM1

PRGRM1: DATA-1 = ABC

PRGRM1: CALL IDENTIFIER-1

THIS IS SUBPROGRAM SUBPRGC

SUBPRGC: CALL IDENTIFIER-1. WORKED

RETURN FROM SUBPROGRAM SUBPRGC

TERMINATION FROM PRGRM1

Example 2
The following screen shows another execution of the TIP transaction described
previously. User input is bolded.

PRGRM1XYZ

This would produce the following printer output:

THIS IS PRGRM1

PRGRM1: DATA-1 = XYZ

PRGRM1: CALL IDENTIFIER-1

THIS IS SUBPROGRAM SUBPRGD

SUBPRGD: CALL IDENTIFIER-1. WORKED

RETURN FROM SUBPROGRAM SUBPRGD

TERMINATION FROM PRGRM1

7–40 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3. HVTIP ZOOM ICP Calling Two Subprograms

This subsection describes use of the CALL identifier statement in an HVTIP COBOL
ICP. The method shown here is the only way that this statement can be resolved for
TIP and HVTIP ZOOMS.

The following figure summarizes the COBOL ICP and subprograms used in the
example. In this example, MCBICP is an HVTIP ICP that calls one of the following,
depending upon the input transaction code:
• One of three entry points in subprogram MCBSUBA
• The main (and only) entry point in subprogram MCBSUBX

Any of the following is substituted for identifier-1 in the CALL identifier statement:
• MCBSUBA (the first entry point of subprogram MCBSUBA)
• MCBEP2 (the second entry point of subprogram MCBSUBA)
• MCBEP3 (the third entry point of subprogram MCBSUBA)
• MCBSUBX (the main entry point of MCBSUBA)

7831 4077–009 7–41

Using the COBOL CALL identifier Statement

MCBICP

IDENTIFICATION DIVISION.
PROGRAM-ID. MCBICP. MCBSUBA
IDENTIFICATION DIVISION.
DATA DIVISION. PROGRAM-ID. MCBSUBA.

01 identifier-1 PIC X(7). PROCEDURE DIVISION.

COPY MCBPKT-UCOB. WITH ENTRY POINTS
MCBEP2, MCBEP3,
MCBEP1.
PROCEDURE DIVISION.

EXIT PROGRAM.
EVALUATE P-MCB-TRANS-CODE MCBEP2.
WHEN 'MCBHVT'
MOVE 'MCBSUBX' TO identifier-1
EXIT PROGRAM.
WHEN 'MCBEP1'
MOVE 'MCBSUBA' TO identifier-1 MCBEP3.
WHEN 'MCBEP2'
MOVE 'MCBEP2' TO identifier-1 EXIT PROGRAM.
WHEN OTHER
MOVE 'MCBEP3' TO identifier-1
END-EVALUATE.
CALL identifier-1.

MCBSUBX

STOP RUN. IDENTIFICATION DIVISION.

PROGRAM-ID. MCBSUBX.

STOP RUN

Note the following about this example:

• This example uses MCB functions. However, you set up and use CALL identifier
in the same manner for DPS 2200 functions.
• This example uses application group 3 (UDSSRC).
• This example uses
− An HVTIP call interface for all three entry points of subprogram MCBSUBA
− An HVTIP transfer-with-cancel interface for the entry point of subprogram
MCBSUBX

7–42 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3.1. Source Listing of the ICP (MCBICP)

Example 7–14 shows the complete source listing of the ICP, MCBICP. In this example,
this program is found in element QUAL*UCSTST.MCBICP/CALLID. Noteworthy lines
are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF AN INITIAL CONTROL PROGRAM "MCBICP" USING MCB THAT *
* PERFORMS A TRANSFER WITH CANCEL TO A SUBPROGRAM "MCBSUBX" OR *
* A CALL TO ONE OF THE SUBPROGRAM "MCBSUBA ENTRY POINTS: *
* MCBSUBA (the first entry point), MCBEP2, MCBEP3. *
* CALL identifier-1 IS USED. *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBICP.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
01 IDENTIFIER-1 PIC X(7).
COPY MCBPKT-UCOB.
PROCEDURE DIVISION.
******************************************************
*** TRANSACTION INITIALIZATION ***
******************************************************
START-UP-ICP.
DISPLAY 'THIS IS MCBICP' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 1 TO P-BIT2.
MOVE P-TRINIT TO P-FUNC.
MOVE 80 TO P-LENGTH.
MOVE 63 TO P-AUX.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS, P-TRXBUFF.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
DISPLAY 'INITIALIZATION COMPLETE' UPON PRINTER.
MOVE P-MCB-TRANS-CODE TO COMMON-FIELD-1.

Example 7–14. Source Listing of ICP (QUAL*UCSTST.MCBICP/CALLID)

7831 4077–009 7–43

Using the COBOL CALL identifier Statement

******************************************************
*** TRANSFER WITH CANCEL TO MCBSUBX ***
*** OR ***
*** CALL TO ONE OF THREE ENTRY POINTS ***
*** OF MCBSUBA ***
*** DEPENDING ON THE TRANSACTION CODE ***
*** USING CALL identifier-1 ***
******************************************************
SETUP-CALL-TO-SUBPROGRAM.
EVALUATE P-MCB-TRANS-CODE
WHEN 'MCBHVT'
DISPLAY 'MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX'
UPON PRINTER
MOVE 'MCBSUBX' TO identifier-1
WHEN 'MCBEP1'
DISPLAY 'MCBICP CALLING MCBSUBA' UPON PRINTER
MOVE 'MCBSUBA' TO identifier-1
WHEN 'MCBEP2'
DISPLAY 'MCBICP CALLING MCBEP2' UPON PRINTER
MOVE 'MCBEP2' TO identifier-1
WHEN OTHER
DISPLAY 'MCBICP CALLING MCBEP3' UPON PRINTER
MOVE 'MCBEP3' TO identifier-1
END-EVALUATE.
CALL IDENTIFIER-1.
******************************************************
*** RETURN TO MCBICP ***
******************************************************
RETURN-FROM-MCBSUBA.
DISPLAY 'RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA'
UPON PRINTER.
****************************************************
*** TRANSACTION TERMINATION ***
****************************************************
MCB-TERMINATE.
DISPLAY 'TERMINATING FROM MCBICP ' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
STOP RUN.
****************************************************
*** MCB ERROR HANDLING ***
****************************************************
ERROR-EXIT.
DISPLAY '********* MCB ERROR *********' UPON PRINTER.

Example 7–14. Source Listing of ICP (QUAL*UCSTST.MCBICP/CALLID)

7–44 7831 4077–009

 Using the COBOL CALL identifier Statement

DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.

DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
MOVE 0 to P-ID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 7–14. Source Listing of ICP (QUAL*UCSTST.MCBICP/CALLID)

7.5.3.2. Partial Source Listing of MCBPKT-UCOB

Example 7–15 shows a partial source listing of the MCBPKT-UCOB routine. This is a
version of the procs contained in the MCBDEF-UCOB element from the MCB release
tape that has been tailored for this example. (For more information, refer to 6.1.2.4
“Coding HVTIP Transactions That Use MCB Functions.”) In this example, this routine is
found in element QUAL*UCSTST.MCBPKT-UCOB. Noteworthy lines are bolded.

MCBPKT-UCOB PROC
/
*
* Sample MCB procedure for use in UCOB transactions
*
************************************************
** TRANSACTION CODE BUFFER **
************************************************
01 P-TRXCODE PIC X(6).
************************************************
** INPUT BUFFER **
** This buffer will hold a 24 X 80 screen. **
** The maximum size is PIC X(262143). **
************************************************
01 P-INMSG PIC X(1920).
**************************************************
** BUFFER ADDRESS **
**************************************************
01 P-MSG-LENGTH PIC 9(10) BINARY.
01 P-SAVEPID PIC 1(18) BINARY-1.
01 P-TRXBUFF PIC X(1920) VALUE SPACES.
**************************************************
** MCB ERROR STATUS RETURN **
**************************************************
01 P-MCB-STATUS.
02 P-STATBIT PIC S9(5) BINARY.
02 P-ERRCODE PIC 9(5) BINARY-1.
02 P-ERRCODE REDEFINES P-ERRCODE.
04 P-ERRCODEQ3 PIC 1(9) BINARY-1.

Example 7–15. Partial Source Listing of MCBPKT-UCOB

7831 4077–009 7–45

Using the COBOL CALL identifier Statement

04 P-ERRCODEQ4 PIC 1(9) BINARY-1.

/
*************************************************
** FUNCTION CODES FOR INTERFACES TO THE MCB **
*************************************************
* TRINIT VALUE 2. initialize
* TERM VALUE 10. terminate
* COMMIT VALUE 11. commit
* ROLBAK VALUE 12. rollback
* RECV VALUE 13. read input
* INPREL VALUE 14. release input
* CANCELL VALUE 15. cancel output
* SENDD VALUE 16. store output
* PASOFF VALUE 17. store passoff
* CHKPT VALUE 18. store checkpoint
* ENQUE VALUE 19. enqueue message
* AUDIT VALUE 20. audit
* DISREC VALUE 21. discrete receive
*****************************************************************
01 P-TRINIT PIC 9(2) BINARY VALUE 2.
01 P-TERM PIC 9(2) BINARY VALUE 10.
01 P-COMMIT PIC 9(2) BINARY VALUE 11.
01 P-ROLBAK PIC 9(2) BINARY VALUE 12.
01 P-RECV PIC 9(2) BINARY VALUE 13.
01 P-INPREL PIC 9(2) BINARY VALUE 14.
01 P-CANCELL PIC 9(2) BINARY VALUE 15.
01 P-SENDD PIC 9(2) BINARY VALUE 16.
01 P-PASOFF PIC 9(2) BINARY VALUE 17.
01 P-CHKPT PIC 9(2) BINARY VALUE 18.
01 P-ENQUE PIC 9(2) BINARY VALUE 19.
01 P-AUDIT PIC 9(2) BINARY VALUE 20.
01 P-DISREC PIC 9(2) BINARY VALUE 21.
/
*************************************************
** PACKET FOR MCB CALL **
*************************************************
01 P-MCB-PACKET.
02 P-WORD.
* P-FUNC function code
* P-OFF data offset
* P-ID msg identifier
03 P-FUNC PIC 9(2) BINARY.
03 P-OFF PIC 9(2) BINARY.
03 P-ID PIC 9(5) BINARY.
02 P-WORD01.
* P-LENGTH request char count
* P-BUFF data buffer address

Example 7–15. Partial Source Listing of MCBPKT-UCOB

7–46 7831 4077–009

 Using the COBOL CALL identifier Statement

03 P-LENGTH PIC 9(5) BINARY.

03 P-BUFF PIC 9(5) BINARY.
02 P-WORD02.
* P-START start char point
* P-RTN return point
03 P-START PIC 9(5) BINARY.
03 P-RTN PIC 9(5) BINARY.
02 P-WORD03.
* P-AUX aux data
* P-FAC facilities
* P-VER version
03 P-AUX PIC 1(6) BINARY-1.
03 P-FAC PIC 1(6) BINARY-1.
03 P-VER PIC 1(6) BINARY-1.
****
03 P-FLAGS.
* *** P-BIT17 recoverable msg ind ***
04 P-BIT17 PIC 1 BINARY-1.
04 P-BIT16 PIC 1 BINARY-1.
04 P-BIT15 PIC 1 BINARY-1.
04 P-BIT14 PIC 1 BINARY-1.
* *** P-BIT13 conversational link ***
04 P-BIT13 PIC 1 BINARY-1.
04 P-BIT12 PIC 1 BINARY-1.
04 P-BIT11 PIC 1 BINARY-1.
04 P-BIT10 PIC 1 BINARY-1.
04 P-BIT9 PIC 1 BINARY-1.
04 P-BIT8 PIC 1 BINARY-1.
04 P-BIT7 PIC 1 BINARY-1.
04 P-BIT6 PIC 1 BINARY-1.
04 P-BIT5 PIC 1 BINARY-1.
04 P-BIT4 PIC 1 BINARY-1.
04 P-BIT3 PIC 1 BINARY-1.
04 P-BIT2 PIC 1 BINARY-1.
04 P-BIT1 PIC 1 BINARY-1.
* *** P-BIT0 last block indicator ***
04 P-BIT0 PIC 1 BINARY-1.
02 P-WORD04.
* P-PID terminal identifier
* P-MN message number
03 P-PID PIC 9(5) BINARY.
03 P-MN PIC 9(5) BINARY.
02 P-WORD05-06.
03 P-MCB-TRANS-CODE.
* P-TC1 transaction code
* P-TC2 transaction code
04 P-TC1 PIC X(4).
04 P-TC2 PIC X(2).

Example 7–15. Partial Source Listing of MCBPKT-UCOB

7831 4077–009 7–47

Using the COBOL CALL identifier Statement

* P-ML message length

03 P-ML PIC 9(5) BINARY.
02 P-WORD07.
* P-STEP1 step-id word 1
03 P-STEP1 PIC 9(10) BINARY.
02 P-WORD08.
* P-STEP2 step-id word 2
03 P-STEP2 PIC 9(10) BINARY.
02 P-WORD09.
* P-PROG program number
* P-NODE queue node
03 P-PROG PIC 9(5) BINARY.
03 P-NODE PIC 9(5) BINARY.
.
. (additional source statements)
.

Example 7–15. Partial Source Listing of MCBPKT-UCOB

7–48 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3.3. Source Listing of the ICP HVCALLS Element

Example 7–16 shows a source listing of the HVCALLS element used in this example.
For information on HVCALLS elements, see the following in 6.1.2:
• “Calling an HVTIP Subprogram”
• “Calling Subprograms by Using an HVTIP Call Interface (HV$CALL)”
• “Calling Subprograms by Using an HVTIP Transfer-with-Cancel Interface
(HV$XFR$CANCL)”

In this example, this routine is found in element QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA.

Noteworthy lines are bolded.

. HVCALLS DEFINITION
. MCBSUBX is defined as a TRANSFER WITH CANCEL
. MCBSUBA first entry point is defined as a CALL
. MCBSUBA second entry point (MCBEP2) is defined as a CALL
. MCBSUBA third entry point (MCBEP3) is defined as a CALL
.
$OBJ .
$INCLUDE 'OM$DEF' .
$INCLUDE 'HVTIP$CALLS' .
$INCLUDE 'SYS$*RLIB$.CBEP$$EMCALL' .
MCBSUBX HV$XFR$CANCL 22,7,0 . transfer with cancel to MCBSUBX code
MCBSUBA HV$CALL 22,10,01000 . call MCBSUBA definition
MCBEP2 HV$CALL 22,10,01003 . call MCBEP2 definition
MCBEP3 HV$CALL 22,10,01006 . call MCBEP3 definition
$END

Example 7–16. Source Listing of ICP HVCALLS Element

(QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA)

7.5.3.4. Partial Source Listing of Edited LSI$RES-NAME Element

Example 7–17 shows a partial source listing of the element that was copied from
SYS$LIB$*LINK.LSI$RES-NAME and then edited, as described in 7.3. See 7.3.1 for the
complete listing of the release tape element SYS$LIB$*LINK.LSI$RES-NAME.

7831 4077–009 7–49

Using the COBOL CALL identifier Statement

In this example, this routine is found in element QUAL*UCSTST.LSI$RES-

NAME/MCBHVTIP. Noteworthy lines are bolded.

$include 'maxr$' . 02067

$include 'om$def' . 02067
$include 'eru$' . 02067
$ascii . 02067
$obj . 02067
$extend . 02067
om$use_lv ,x2,b2 . 02067
.
. (additional source statements)
.
$(0) $bank om$data_emb 'ls$db1' . 02273
ls$resnm_dat* . 02273
. *************** E X A M P L E S **************************** 02273
. ************************************************************** 02273
. ** SET 'string',0400016001000 ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 02273
. ** DECLARE 'name1',LCN ** 02273
. ************************************************************** 02273
. 02273
. ************************************************************** 03151
. ** COBOL CALL identifier-1 EXAMPLES ** 03151
. ** ** 03151
. ** DECLARE 'SUBPRGA',*0,*0,*0 ** 03151
. ** DECLARE 'SUBPRGB',*0,*0,*0 ** 03151
. ** ** 03151
. ************************************************************** 03151
. 03151
. Put the SET or DECLARE directives here ** 02408
. 02273
. ************************************************************** 02273
. 02273
DECLARE 'MCBSUBX',*0,*0,*0
DECLARE 'MCBSUBA',*0,*0,*0
DECLARE 'MCBEP2',*0,*0,*0
DECLARE 'MCBEP3',*0,*0,*0
. 02273
. End of user-inserted SET or DECLARE directives 05512
. 02273
. ************************************************************** 02273
. 02273
. 02273

Example 7–17. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP)

7–50 7831 4077–009

 Using the COBOL CALL identifier Statement

. If you wish to define a list 'RES' area for names to be dynamically 05512
. found and added to the list at runtime, put the desired reserve value 05512
. in the tag DESIRED_RES below. 05512
. 05512
DESIRED_RES $EQU 0 . <<< Change this value to define a 'RES' area<<<<<<<
05512
$DO DESIRED_RES , +0 . <<< Do NOT edit this line, zeros are required<<<<<
. 05512
. ********************************************************************* 05512
. 02273
ls$resnm_stp* $equ $-ls$resnm_dat . 05512

Example 7–17. Partial Source Listing of Edited LSI$RES-NAME Element

(QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP)

7831 4077–009 7–51

Using the COBOL CALL identifier Statement

7.5.3.5. Source Listing of First Subprogram

Example 7–18 shows the complete source listing of subprogram MCBSUBA. In this
example, this program is found in element QUAL*UCSTST.MCBSUBA. Noteworthy
lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBA" THAT WAS CALLED FROM THE ICP *
* "MCBICP" USING A CALL TO ONE OF THE THREE ENTRY POINTS: *
* MCBSUBA, MCBEP2, MCBEP3. *
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBSUBA.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
PROCEDURE DIVISION WITH ENTRY POINTS MCBEP2, MCBEP3.
MCBEP1.
DISPLAY ' THIS IS MCBSUBA "MCBEP1" ENTRY POINT'
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.
EXIT PROGRAM.
*
MCBEP2.
DISPLAY ' THIS IS MCBSUBA "MCBEP2" ENTRY POINT '
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.
EXIT PROGRAM.

Example 7–18. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA)

7–52 7831 4077–009

 Using the COBOL CALL identifier Statement

*
MCBEP3.
DISPLAY ' THIS IS MCBSUBA "MCBEP3" ENTRY POINT '
UPON PRINTER.
DISPLAY ' TRANSACTION CODE ' COMMON-FIELD-1 ' WAS'
UPON PRINTER.
DISPLAY ' USED TO ENTER MCBSUBA AT THIS ENTRY POINT'
UPON PRINTER.
DISPLAY ' RETURNING TO MCBICP ' UPON PRINTER.
EXIT PROGRAM.

Example 7–18. Source Listing of First Subprogram (QUAL*UCSTST.MCBSUBA)

7831 4077–009 7–53

Using the COBOL CALL identifier Statement

7.5.3.6. Source Listing of Jump Vector Element for Subprogram

MCBSUBA
Example 7–19 shows the source listing of the jump vector element to define the three
entry points of subprogram MCBSUBA. (For information on such jump vector
elements, see 6.1.6.)

In this example, this routine is found in element QUAL*UCSTST.JUMPVECTOR/MCBSUBA.

Noteworthy lines are bolded.

. JUMPVECTOR DEFINITION
. THE THREE ENTRY POINTS FOR MCBSUBA ARE DEFINED
. MCBSUBA first entry point (MCBEP1)
. MCBSUBA second entry point (MCBEP2)
. MCBSUBA third entry point (MCBEP3)
.
$OBJ
$EXTEND
$INCLUDE 'MAXR$'
$INCLUDE 'OM$DEF'
$INCLUDE 'SYS$LIB$*LINK.HVTIP$CALLS'
. .
OM$USE_LV,0 . Define link vector bank as $(0)
. .
$(1) $BANK HV$CODE_EMB,01000 . Define an extended mode code bank
. . that starts at 01000 and has the
. . MERGE_ORDER bank attribute set to
. . FIRST.
. . That causes this bank to always
. . be at the front of any bank
. . into which it is merged.
. .
JUMPER* . Start address for HVTIP subprogram
. .
HV$VECTOR MCBSUBA . Offset 01000 will pass control
. . to MCBSUBA (MCBEP1)
. .
HV$VECTOR MCBEP2 . Offset 01003 will pass control
. . to MCBEP2
. .
HV$VECTOR MCBEP3 . Offset 01006 will pass control
. . to MCBEP3
. .
$END

Example 7–19. Source Listing of Jump Vector Element for Subprogram MCBSUBA
(QUAL*UCSTST.JUMPVECTOR/MCBSUBA)

7–54 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3.7. Source Listing of Second Subprogram

Example 7–20 shows the complete source listing of subprogram MCBSUBX. In this
example, this program is found in element QUAL*UCSTST.MCBSUBX/NOCALLS.
Noteworthy lines are bolded.

IDENTIFICATION DIVISION.
******************************************************************
******************************************************************
* *
* EXAMPLE OF A SUBPROGRAM "MCBSUBX" THAT WAS CALLED FROM THE ICP *
* "MCBICP" USING TRANSFER WITH CANCEL
* *
******************************************************************
******************************************************************
PROGRAM-ID. MCBSUBX.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UNISYS-2200.
SPECIAL-NAMES.
PRINTER IS PRINTER.
DATA DIVISION.
COMMON-STORAGE SECTION.
01 COMMON-FIELD-1 PIC X(6).
WORKING-STORAGE SECTION.
COPY MCBPKT-UCOB.
PROCEDURE DIVISION.
******************************************************
*** MCBSUBX START UP ***
******************************************************
START-UP-SUBX.
DISPLAY ' THIS IS MCBSUBX' UPON PRINTER.
****************************************************
*** TRANSACTION TERMINATION ***
****************************************************
MCB-TERMINATE.
DISPLAY ' TERMINATING FROM MCBSUBX' UPON PRINTER.
MOVE LOW-VALUES TO P-MCB-PACKET.
MOVE 0 TO P-MCB-STATUS.
MOVE 0 TO P-FLAGS.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
IF P-STATBIT NOT EQUAL ZERO GO TO ERROR-EXIT.
STOP RUN.
****************************************************

Example 7–20. Source Listing of Second Subprogram

(QUAL*UCSTST.MCBSUBX/NOCALLS)

7831 4077–009 7–55

Using the COBOL CALL identifier Statement

*** MCB ERROR HANDLING ****

***********************************************
ERROR-EXIT.
DISPLAY '********* MCB ERROR *********' UPON PRINTER.
DISPLAY 'ERROR STATUS BIT = ' P-STATBIT UPON PRINTER.
DISPLAY 'ERROR CODE = ' P-ERRCODE UPON PRINTER.
MOVE 0 to P-PID.
MOVE P-TERM TO P-FUNC.
CALL 'MCB$ENT' USING P-MCB-PACKET, P-MCB-STATUS.
STOP RUN.

Example 7–20. Source Listing of Second Subprogram

(QUAL*UCSTST.MCBSUBX/NOCALLS)

7–56 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3.8. Source Listing of Runstream

Example 7–21 shows a listing of the runstream used to set up, compile, and link the
HVTIP transactions shown in this example. Note that this example assumes that the
LSI$RES-NAME element has already been copied and edited, as described previously.
Noteworthy lines are bolded.

@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************

@ . ***
@ . ***
@ . *** ****** CALL 'identifier' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,
@ . *** QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/MCBHVTIP IS THEN EDITED TO
@ . *** INCLUDE ONE DECLARE STATEMENT FOR SUBPROGRAM 'MCBSUBX'
@ . *** AND THE THREE DECLARE STATEMENTS FOR THE THREE ENTRY
@ . *** POINTS IN SUBPROGRAM 'MCBSUBA'
@ . ***
@ . *** DECLARE 'MCBSUBX',*0,*0,*0
@ . *** DECLARE 'MCBSUBA',*0,*0,*0
@ . *** DECLARE 'MCBEP2',*0,*0,*0
@ . *** DECLARE 'MCBEP3',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/MCBHVTIP IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP,QUAL*UCSTST.
@EOF
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINE.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7831 4077–009 7–57

Using the COBOL CALL identifier Statement

@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
@EOF
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
@ASG,A MASM$PF1.
@ . ***
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL AND CALL ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"
@ . ***
@UCOB QUAL*UCSTST.MCBICP/CALLID,.MCBICP/COMP,,,NO-OPTIONS
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA,.HVCALLSDEF/MCBSUBXSUBA
@EOF
@ . ***
@ . ***
@ . *** * MULTIPLE ENTRY POINT SUBPROGRAM MCBSUBA ******
@ . *** COMPILE THE MULTIPLE ENTRY POINT SUBPROGRAM "MCBSUBX" AND
@ . *** ASSEMBLE ITS JUMP VECTOR ELEMENT "JUMPVECTOR/MCBSUBA"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBA,.MCBSUBA/COMP,,, SUBPROGRAM,NO-OPTIONS
@MASM,N QUAL*UCSTST.JUMPVECTOR/MCBSUBA,.JUMPVECTOR/MCBSUBA
@EOF
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE SUBPROGRAM "MCBSUBX"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX/NOCALLS,.MCBSUBX/COMP,,, SUBPROGRAM,NO-OPTIONS
@ . ***
@ . ***
@ . *** LINK OF THE HVTIP ICP AND SUBPROGRAMS
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$n.
@ . ***
@ . *** WHERE "n" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@ . ***

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7–58 7831 4077–009

 Using the COBOL CALL identifier Statement

@USE LINK$PF.,SYS$LIB$*APP$3.
@ . ***
@ . *** *** MCBICP LINK ********
@ . *** LINK OF THE HVTIP INITIAL CONTROL PROGRAM 'MCBICP'
@ . *** THIS INCLUDES THE USER ELEMENT HVCALLSDEF/MCBSUBXSUBA.
@ . *** THIS INCLUDES THE USER ELEMENT LSI$RES-NAME/MCBHVTIP.
@ . ***
@LINK ,QUAL*UCSTST.MCBICP
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.MCBICP/COMP
INCLUDE QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA
INCLUDE QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP
RESOLVE ALL REFERENCES EXCEPT LS$RES_NAME USING SYS$LIB$*EMOMRTS, LCN
DELETE ALL DEFINITIONS EXCEPT START$
@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBA LINK ********
@ . *** LINK OF THE HVTIP SUBPROGRAM 'MCBSUBA'
@ . *** THIS INCLUDES THE USER ELEMENT JUMPVECTOR/MCBSUBA.
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBA
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.MCBSUBA/COMP
INCLUDE QUAL*UCSTST.JUMPVECTOR/MCBSUBA
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT JUMPER
@EOF
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
OUTPUT HVTIP
INCLUDE QUAL*UCSTST.MCBSUBX/COMP
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS, LIBCODENAME
DELETE ALL DEFINITIONS EXCEPT MCBSUBX
@EOF
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTABS FOR THIS EXAMPLE'S TRANSACTIONS.
@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.
@ . ***
@ . *** INPUT:
@ . *** *VALCHG M

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7831 4077–009 7–59

Using the COBOL CALL identifier Statement

@ . *** nnn NAM,xxxxxx ACT,xxxxxx PRG,5 STF,0 STA,J QPR,n

@ . *** nnn REC,Z AUD,n IND,O PRT,xxxxx
@ . ***
@ . ***
@ . *** IN THIS EXAMPLE:
@ . *** THE TRANSACTION CODE (ACT,xxxxxx) IDENTIFIES WHICH
@ . *** SUBPROGRAM WILL BE CALLED.
@ . *** TRANSACTION CODE 'MCBHVT' EXECUTES SUBPROGRAM 'MCBSUBX'
@ . *** TRANSACTION CODE 'MCBEP1' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** FIRST ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP2' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** SECOND ENTRY POINT 'MCBEP2'
@ . *** TRANSACTION CODE 'MCBEP3' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** THIRD ENTRY POINT 'MCBEP3'
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
*VALCHG M
920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,J QPR,1 OPT,T
920 REC,Z AUD,3 IND,O PRT,PR
921 NAM,MCBICP ACT,MCBEP1 PRG,5 STF,0 STA,J QPR,1 OPT,T
921 REC,Z AUD,3 IND,O PRT,PR
922 NAM,MCBICP ACT,MCBEP2 PRG,5 STF,0 STA,J QPR,1 OPT,T
922 REC,Z AUD,3 IND,O PRT,PR
923 NAM,MCBICP ACT,MCBEP3 PRG,5 STF,0 STA,J QPR,1 OPT,T
923 REC,Z AUD,3 IND,O PRT,PR
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@EOF
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
ON BTLOADING
ON STICKING
@EOF
@ . ***
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7–60 7831 4077–009

 Using the COBOL CALL identifier Statement

@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB nn - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP nn - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-file-number - TPLIB = HVTIP-LIBRARY-number
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-file-number = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-number)
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
TREG QUAL*HVTIPLIB22.,FIX
RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
LFD 92
@EOF
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.
@ . ***

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7831 4077–009 7–61

Using the COBOL CALL identifier Statement

@XQT,P TIP$*TIPRUN$.BOXER
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
CREATE,K 22,30
COPY,IVK 22,6,QUAL*UCSTST.MCBICP
COPY,IK 22,7,QUAL*UCSTST.MCBSUBX
COPY,IK 22,10,QUAL*UCSTST.MCBSUBA
LIST 22
LOAD,K 22
STATUS,K 22
@EOF
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . EXAMPLE SETUP IS COMPLETE

Example 7–21. Runstream to Set Up, Compile, and Link—COBOL HVTIP ZOOM

7–62 7831 4077–009

 Using the COBOL CALL identifier Statement

7.5.3.9. Execution of the Source Runstream

Example 7–22 shows the execution of the source runstream described in the previous
subsection. Output has been saved by an @BRKPT statement. Noteworthy lines are
bolded.

@ . *** *** START OF THE EXAMPLE SETUP SECTION *************************

@ . ***
@ . ***
@ . *** ****** CALL 'IDENTIFIER' LSI$RES-NAME ROUTINE*****
@ . ***
@ . ***
@ . *** THE LINKING SYSTEM ELEMENT SYS$LIB$*LINK.LSI$RES-NAME
@ . *** IS COPIED TO THE USER FILE USING THE FOLLOWING STATEMENT.
@ . ***
@ . *** @COPY,S SYS$LIB$*LINK.LSI$RES-NAME,
@ . *** QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/MCBHVTIP IS THEN EDITED TO
@ . *** INCLUDE ONE DECLARE STATEMENT FOR SUBPROGRAM 'MCBSUBX'
@ . *** AND THE THREE DECLARE STATEMENTS FOR THE THREE ENTRY
@ . *** POINTS IN SUBPROGRAM 'MCBSUBA'
@ . ***
@ . *** DECLARE 'MCBSUBX',*0,*0,*0
@ . *** DECLARE 'MCBSUBA',*0,*0,*0
@ . *** DECLARE 'MCBEP2',*0,*0,*0
@ . *** DECLARE 'MCBEP3',*0,*0,*0
@ . ***
@ . ***
@ . *** THE USER ELEMENT LSI$RES-NAME/MCBHVTIP IS THEN ASSEMBLED.
@ . ***
@MASM,N QUAL*UCSTST.LSI$RES-NAME/MCBHVTIP,QUAL*UCSTST.
MASM 6R2A (960423 00008:22) 1997 Feb 20 Thu 1541:56
ASSEMBLY CONTAINS WARNINGS: - FLAGS: U
END MASM - LINES: 824 TIME: 4.902 STORAGE: 29345/10294 WARNINGS: U(1)
@ . ***
@ . ***
@ . *** COBOL COMPILE OF THE ICP AND SUBPROGRAMS;
@ . *** MASM ASSEMBLY OF THE HVCALLS ROUTINE.
@ . ***
@ . *** THE MCB PACKET PROCEDURE IS PDP'ED WITHIN THE USER
@ . *** FILE SO THE PROCEDURE CAN BE LOCATED BY THE COMPILER.
@ . ***
@ . *** THE USER-WRITTEN MASM ROUTINES "HVCALLS" DIRECTS EACH
@ . *** CALL TO A SUBPROGRAM TO THE CORRECT HVTIP LIBRARY NUMBER
@ . *** AND BANK NUMBER.

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7831 4077–009 7–63

Using the COBOL CALL identifier Statement

@ . ***
@PDP,UC QUAL*UCSTST.MCBPKT/UCOB,.MCBPKT-UCOB
PDP 13R2 (960423 0108:39) 1997 Feb 20 Thu 1541:59
END PDP. Errors: 0 Fatal 0 Syntax 0 Warning
Lines: 278 Entry Points: 1 Time: 1.949 Storage: 7070/0/7070/0106210
@ . ***
@USE MASM$PF1.,SYS$LIB$*LINK.
I:002333 USE complete.
@ASG,A MASM$PF1.
I:002333 ASG complete.
@ . ***
@ . ***
@ . *** * ICP MCBICP ******
@ . *** COMPILE THE ICP "MCBICP" AND ASSEMBLE ITS HVCALLS
@ . *** TRANSFER WITH CANCEL AND CALL ELEMENT
@ . *** "HVCALLSDEF/MCBSUBXSUBA"
@ . ***
@UCOB QUAL*UCSTST.MCBICP/CALLID,.MCBICP/COMP,,,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:42:00
SIZES: CODE(EM6): 347 DATA: 582 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.HVCALLSDEF/MCBSUBXSUBA,.HVCALLSDEF/MCBSUBXSUBA
MASM 6R2A (960423 0008:22) 1997 Feb 20 Thu 1542:08
END MASM - LINES: 347 TIME: 4.726 STORAGE: 29345/7931
@ . ***
@ . ***
@ . *** * MULTIPLE ENTRY POINT SUBPROGRAM MCBSUBA ******
@ . *** COMPILE THE MULTIPLE ENTRY POINT SUBPROGRAM "MCBSUBX" AND
@ . *** ASSEMBLE ITS JUMP VECTOR ELEMENT "JUMPVECTOR/MCBSUBA"
@ . ***
@ . *** THIS SUBPROGRAM CONTAINS NO MCB FUNCTIONS.
@ . ***
@UCOB QUAL*UCSTST.MCBSUBA,.MCBSUBA/COMP,,, SUBPROGRAM,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:42:10
SIZES: CODE(EM6): 131 DATA: 384 COMMON: 3
END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)
@MASM,N QUAL*UCSTST.JUMPVECTOR/MCBSUBA,.JUMPVECTOR/MCBSUBA
MASM 6R2A (960423 0008:22) 1997 Feb 20 Thu 1542:14
ASSEMBLY CONTAINS WARNINGS: - FLAGS: U
END MASM - LINES: 258 TIME: 4.482 STORAGE: 29345/7924 WARNINGS: U(3)
@ . ***
@ . ***
@ . *** * SUBPROGRAM MCBSUBX ******
@ . *** COMPILE SUBPROGRAM "MCBSUBX"
@ . ***
@UCOB QUAL*UCSTST.MCBSUBX/NOCALLS,.MCBSUBX/COMP,,, SUBPROGRAM,NO-OPTIONS
UCOB- 8R1 (970210) LSS- 10R1 (970209) 970220 15:42:18
SIZES: CODE(EM6): 177 DATA: 267 COMMON: 3

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7–64 7831 4077–009

 Using the COBOL CALL identifier Statement

END UCOB- 0 ERRORS(MAJOR) 0 ERRORS(MINOR)

@ . ***
@ . ***
@ . *** LINK OF THE HVTIP ICP AND SUBPROGRAMS
@ . ***
@ . *** SINCE MCB IS BEING USED IN THIS EXAMPLE, IDENTIFYING
@ . *** THE CORRECT APPLICATION GROUP SEARCH CHAIN WILL
@ . *** LOCATE THAT APPLICATION GROUP'S MCB.
@ . ***
@ . *** @USE LINK$PF.,SYS$LIB$*APP$n.
@ . ***
@ . *** WHERE "n" IS REPLACED WITH THE APPLICATION GROUP NUMBER
@ . ***
@ . *** IDENTIFY THE APPLICATION GROUP SEARCH CHAIN
@ . ***
@USE LINK$PF.,SYS$LIB$*APP$3.
I:002333 USE complete.
@ . ***
@ . *** *** MCBICP LINK ********
@ . *** LINK OF THE HVTIP INITIAL CONTROL PROGRAM 'MCBICP'
@ . *** THIS INCLUDES THE USER ELEMENT HVCALLSDEF/MCBSUBXSUBA.
@ . *** THIS INCLUDES THE USER ELEMENT LSI$RES-NAME/MCBHVTIP.
@ . ***
@LINK ,QUAL*UCSTST.MCBICP
LINK 7R1 (970207 1635:57) 1997 Feb 20 Thu 1542:26
END LINK , LINES : 6 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBA LINK ********
@ . *** LINK OF THE HVTIP SUBPROGRAM 'MCBSUBA'
@ . *** THIS INCLUDES THE USER ELEMENT JUMPVECTOR/MCBSUBA.
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBA
LINK 7R1 (970207 1635:57) 1997 Feb 20 Thu 1542:40
END LINK , LINES : 5 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** *** MCBSUBX LINK ********
@ . *** LINK THE SUBPROGRAM "MCBSUBX"
@ . ***
@LINK ,QUAL*UCSTST.MCBSUBX
LINK 7R1 (970207 1635:57) 1997 Feb 20 Thu 1542:47
END LINK , LINES : 4 , ERRORS : 0 , WARNINGS : 0 , XREFS : 0.
@ . ***
@ . ***
@ . *** ** VALTAB SETUP
@ . *** SETS UP THE VALTABS FOR THIS EXAMPLE'S TRANSACTIONS.

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7831 4077–009 7–65

Using the COBOL CALL identifier Statement

@ . *** THE NEW VINDEX IS THEN LOADED INTO MEMORY.

@ . ***
@ . *** INPUT:
@ . *** *VALCHG M
@ . *** NNN NAM,XXXXXX ACT,XXXXXX PRG,5 STF,0 STA,J QPR,N
@ . *** NNN REC,Z AUD,N IND,O PRT,XXXXX
@ . ***
@ . ***
@ . *** IN THIS EXAMPLE:
@ . *** THE TRANSACTION CODE (ACT,XXXXXX) IDENTIFIES WHICH
@ . *** SUBPROGRAM WILL BE CALLED.
@ . *** TRANSACTION CODE 'MCBHVT' EXECUTES SUBPROGRAM 'MCBSUBX'
@ . *** TRANSACTION CODE 'MCBEP1' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** FIRST ENTRY POINT
@ . *** TRANSACTION CODE 'MCBEP2' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** SECOND ENTRY POINT 'MCBEP2'
@ . *** TRANSACTION CODE 'MCBEP3' EXECUTES SUBPROGRAM 'MCBSUBA'
@ . *** THIRD ENTRY POINT 'MCBEP3'
@ . ***
@ . ***
@XQT,XIMUZ TIP$*TIPRUN$.VTBUTL
VTBUTL 45R2#0000001 970220 1543:00
*VALCHG M
KEYWORDS FOR VALTAB FIELDS
LONG FORM SHORT FORM FIELD DESCRIPTION
--------- ---------- -----------------
(FIRST FIELD ON EACH CARD) PROGRAM NUMBER
NAME NAM PROGRAM NAME
ACTION ACT TRANSACTION CODE
RUNTIME RUN MAXIMUM RUN TIME
PRIORITY PRI PROGRAM PRIORITY
INDICATORS IND VALTAB INDICATORS
PRGTYPE PRG PROGRAM TYPE
OPTIONS OPT PROGRAM OPTIONS
STFILE STF STANDARD FILE NO.
COPIES COP MAXIMUM COPIES
STATUS STA PROGRAM STATUS
PRTDEVICE PRT PRINT QUEUE DEVICE
LEVEL LEV SWITCHING LEVEL
PCTBLOCKS PCT NUMBER PCT BLOCKS
WAITQ WAI WAIT-Q LENGTH
DBKSIZ DBK D-BANK SIZE
AUDIT AUD AUDIT TRAIL NUMBER
RECOVERY REC RECOVERY OPTIONS
MASK MAS ACCESS MASK
QPRIORITY QPR QUEUING PRIORITY

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7–66 7831 4077–009

 Using the COBOL CALL identifier Statement

TCASIZ TCA TCA Bank SIZE

DATA CARDS FOR NEXT VALTAB CHANGE:

920 NAM,MCBICP ACT,MCBHVT PRG,5 STF,0 STA,J QPR,1 OPT,T

920 REC,Z AUD,3 IND,O PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 920 TRANSACTION CODE: MCBHVT DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: T IND: O PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET
DATA CARDS FOR NEXT VALTAB CHANGE:

921 NAM,MCBICP ACT,MCBEP1 PRG,5 STF,0 STA,J QPR,1 OPT,T

921 REC,Z AUD,3 IND,O PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 921 TRANSACTION CODE: MCBEP1 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: T IND: O PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET
DATA CARDS FOR NEXT VALTAB CHANGE:

922 NAM,MCBICP ACT,MCBEP2 PRG,5 STF,0 STA,J QPR,1 OPT,T

922 REC,Z AUD,3 IND,O PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 922 TRANSACTION CODE: MCBEP2 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: T IND: O PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET
DATA CARDS FOR NEXT VALTAB CHANGE:
923 NAM,MCBICP ACT,MCBEP3 PRG,5 STF,0 STA,J QPR,1 OPT,T
923 REC,Z AUD,3 IND,O PRT,PR
*** NEW ADDED VALTAB ***
PROGRAM NUMBER: 923 TRANSACTION CODE: MCBEP3 DBK: 0
NAM: MCBICP RUN: 60 PRI: M PRG: 5 STF: 0 COP: 5 PRT: PR LEV: 0
STA: J OPT: T IND: O PCT: 1 WAITQ: 0
AUD: 3 REC: Z QPR: 1 MAS: NONE SET
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970220 1543:01
OFF BTLOADING
OFF STICKING
ON RECOVERY
OFF SCHEDULE
@ . ***
@XQT TIP$*TIPRUN$.TPINIT
TPINIT 45R2#0000001 970220 1543:01
@ . ***

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7831 4077–009 7–67

Using the COBOL CALL identifier Statement

@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970220 1543:02
ON BTLOADING
ON STICKING
@ . ***
@ . ***
@ . *** ** HVTIP LIBRARY SETUP
@ . *** CATALOGS THE EXEC FILE THAT WILL HOLD THE
@ . *** HVTIP LIBRARY TIP FILE.
@ . ***
@CAT,P QUAL*HVTIPLIB22.,F/1000//1000
I:002333 CAT complete.
@ . ***
@ . ***
@ . *** HVTIP LIBRARY INFORMATION
@ . ***
@ . *** THE TIP FILE NUMBERS THAT CAN BE USED AS HVTIP LIBRARIES
@ . *** ARE DEFINED BY THE EXEC GENERATION.
@ . ***
@ . *** TPLIB NN - DEFINES THE STARTING TIP FILE NUMBER FOR
@ . *** HVTIP LIBRARIES
@ . *** HVTIP NN - DEFINES THE NUMBER OF HVTIP LIBRARIES FOR
@ . *** THIS SYSTEM
@ . ***
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER - TPLIB = HVTIP-LIBRARY-NUMBER
@ . ***
@ . *** FOR EXAMPLE: TPLIB = 70
@ . *** HVTIP = 64
@ . *** HVTIP-LIBRARY-TIP-FILE-NUMBER = 92
@ . *** THEREFORE:
@ . *** 92 - 70 = 22 (HVTIP-LIBRARY-NUMBER)
@ . ***
@ . *** ** USES THE FREIPS UTILITY TO:
@ . ***
@ . *** 1. REGISTER THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 2. RESERVE THE HVTIP LIBRARY TIP FILE USED FOR THE
@ . *** TRANSACTION ZOOM.
@ . ***
@ . *** 3. LIST THE HVTIP LIBRARY TIP FILE THIS TEST USES FOR
@ . *** THE TRANSACTION ZOOM IN ORDER TO CONFIRM THE SETUP.
@ . ***
@TIP$*TIPRUN$.FREIPS,U
FREIPS 45R2 02/20/97 15:43:02 FS-LEVEL FS 003
TREG QUAL*HVTIPLIB22.,FIX
TP REGISTER STARTED 15:43:02 20 FEB 97
TP REGISTER FINISHED 15:43:04 20 FEB 97

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7–68 7831 4077–009

 Using the COBOL CALL identifier Statement

RES 92,64000,28,,HVTIPLIB22,,,WW=P,AUDIT=0,NREC
TP RESERVE STARTED 15:43:04 20 FEB 97
TP RESERVE FINISHED 15:43:04 20 FEB 97
LFD 92
TIP FILE 92
DIR-ACCESS,LOCAL SIMPLX
NO AFTERLOOKS, NON-RECOVERABLE, WW, NO AUTO-ANSWER
RECORDS: 64000 SIZE: 28 APPLICATION GROUP: 0
FILE NAME HVTIPLIB22
PLACEMENT 0
LEG STATUS AVL-UP
END FREIPS
@ . ***
@ . *** * HVTIP LIBRARY LOAD ******
@ . ***
@ . *** USE THE TPUR UTILITY TO COPY TRANSACTION PROGRAMS INTO
@ . *** THE HVTIP LIBRARY.
@ . ***
@ . *** BRING AN HVTIP LIBRARY THAT IS INITIALIZED AND CONTAINS
@ . *** AT LEAST ONE PROGRAM BANK ONLINE SO TRANSACTIONS CAN BE
@ . *** EXECUTED FROM THIS HVTIP LIBRARY.
@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970220 1543:04
ON RECOVERY
OFF SCHEDULE
@ . ***
@ASG,A QUAL*UCSTST.
W:122133 file is already assigned.
@ . ***
@XQT,MUX TIP$*TIPRUN$.TPUR
TPUR 45R2#0000001 970220 1543:04
CREATE,K 22,30
LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30
NEXT AVAILABLE RECORD: 7 LIBRARY CYCLE: MAIN

COPY,IVK 22,6,QUAL*UCSTST.MCBICP

LLBBBB : 260006 LIB# : 22 BANK# : 6

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/20/97 CREATION TIME : 15:42:37
BANK SIZE : 012100 BANK TYPE : Z,DY,EM
START ADDRESS : 001013 START RECORD NUMBER : 7
LOWER LIMIT : 001000

COPY,IK 22,7,QUAL*UCSTST.MCBSUBX

LLBBBB : 260007 LIB# : 22 BANK# : 7

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7831 4077–009 7–69

Using the COBOL CALL identifier Statement

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX

CREATION DATE : 02/20/97 CREATION TIME : 15:42:58
BANK SIZE : 04500 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 194
LOWER LIMIT : 001000

COPY,IK 22,10,QUAL*UCSTST.MCBSUBA

LLBBBB : 260012 LIB# : 22 BANK# : 10

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBA
CREATION DATE : 02/20/97 CREATION TIME : 15:42:45
BANK SIZE : 04700 BANK TYPE : Z,DY,EM
START ADDRESS : 001000 START RECORD NUMBER : 280
LOWER LIMIT : 001000
LIST 22

LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

NEXT AVAILABLE RECORD: 733 LIBRARY CYCLE: MAIN

LLBBBB : 260006 LIB# : 22 BANK# : 6

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBICP
CREATION DATE : 02/20/97 CREATION TIME : 15:42:37
BANK SIZE : 012100 BANK TYPE : Z,DY,EM
START ADDRESS : 001013 START RECORD NUMBER : 7
LOWER LIMIT : 001000

LLBBBB : 260007 LIB# : 22 BANK# : 7

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBX
CREATION DATE : 02/20/97 CREATION TIME : 15:42:58
BANK SIZE : 04500 BANK TYPE : Z,DY,EM
START ADDRESS : 001011 START RECORD NUMBER : 194
LOWER LIMIT : 001000

LLBBBB : 260012 LIB# : 22 BANK# : 10

ELEMENT SPECIFICATION : QUAL*UCSTST.MCBSUBA
CREATION DATE : 02/20/97 CREATION TIME : 15:42:45
BANK SIZE : 04700 BANK TYPE : Z,DY,EM
START ADDRESS : 001000 START RECORD NUMBER : 280
LOWER LIMIT : 001000
LOAD,K 22
STATUS,K 22

ONLINE LIBRARY STATUS

LIBRARY NUMBER: 22 NUMBER OF BANKS ALLOWED: 30

BANK RTN LOAD STATUS BANK BANK TIP MEM LOWER START RECORD
NUMB COUNT INDICATORS SIZE TYPE GROUP# LIMIT ADDR NUMBER

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7–70 7831 4077–009

 Using the COBOL CALL identifier Statement

---- ----- ----------- ------- ------- --- ------ ------ ------

6* 0 0012100 Z,DY,EM 2 001000 001013 7

7 0 0004500 Z,DY,EM 1 001000 001011 194
10* 0 0004700 Z,DY,EM 1 001000 001000 280

@ . ***
@XQT,P TIP$*TIPRUN$.BOXER
BOXER 45R2#0000001 970220 1543:12
OFF RECOVERY
ON SCHEDULE
@ . ***
@ . ***
@ . EXAMPLE SETUP IS COMPLETE

Example 7–22. Execution of Source Runstream—COBOL HVTIP ZOOM

7831 4077–009 7–71

Using the COBOL CALL identifier Statement

7.5.3.10. Execution of the HVTIP Transactions in This Example

Example 1
The following screen shows an execution of the HVTIP transaction described
previously. User input is bolded.

MCBHVT

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP TRANSFERRING WITH CANCEL TO MCBSUBX

THIS IS MCBSUBX

TERMINATING FROM MCBSUBX

Example 2
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

MCBEP1

This would produce the following printer output.

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBSUBA

THIS IS MCBSUBA "MCBEP1" ENTRY POINT

TRANSACTION CODE MCBEP1 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

7–72 7831 4077–009

 Using the COBOL CALL identifier Statement

Example 3
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

MCBEP2

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBEP2

THIS IS MCBSUBA "MCBEP2" ENTRY POINT

TRANSACTION CODE MCBEP2 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

Example 4
The following screen shows another execution of the HVTIP transaction described
previously. User input is bolded.

MCBEP3

This would produce the following printer output:

THIS IS MCBICP

INITIALIZATION COMPLETE

MCBICP CALLING MCBEP3

THIS IS MCBSUBA "MCBEP3" ENTRY POINT

TRANSACTION CODE MCBEP3 WAS

USED TO ENTER MCBSUBA AT THIS ENTRY POINT

RETURNING TO MCBICP

7831 4077–009 7–73

Using the COBOL CALL identifier Statement

RETURNED TO MCBICP FROM SUBPROGRAM MCBSUBA

TERMINATING FROM MCBICP

7–74 7831 4077–009

Section 8
Planning for Use of UCS in New and
Existing Applications

Extended mode hardware and UCS software provide the most powerful solution-
oriented working environment available today on OS 2200 systems. They are the hub
of all new software developed for these and future systems. All new user-developed
applications should be implemented using UCS. Existing basic mode applications
written in ACOB or FTN should slowly be upgraded to UCS.

This new environment does not prohibit use of existing non-UCS applications.
Programs using non-UCS programming can coexist harmoniously with programs using
UCS. The two environments can share both software and files. In fact, a single
application can consist of UCS and non-UCS programs. (Any one particular program,
however, must be all UCS or all non-UCS.)

7831 4077–009 8–1

Planning for Use of UCS in New and Existing Applications

8.1. Implementing New User-Developed

Applications
All new user-developed applications should be developed using UCS:
• UCS provides an advanced set of programming tools that can be used to improve
programmer productivity and enhance performance of existing and future
applications. It provides an efficient application development environment that has
matured to better meet the needs of its users.
• The use of UCS will continue to grow. All new products and high-level language
feature enhancements provided by Unisys will be implemented through UCS
software.
• The follow-on architecture will emphasize extended mode performance.

Therefore, in order to take advantage of the ever increasing capacity, performance,

and capabilities of the new and future technology, all new user-developed applications
should be implemented using UCS.

To aid sites, this guide provides examples demonstrating how easy it is to implement
user-developed application programs in UCS (see Sections 3, 5, and 6). Each Unisys
software product also supplies its own programming reference manual or guide to
supply more detailed information on use of the product. A complete list of these
documents can be found in “About This Guide.”

8.2. Coexistence of UCS and Non-UCS Programs in

an Existing Application
Extended mode hardware and UCS software do not prohibit the use of existing non-
UCS applications. UCS and non-UCS programs coexist harmoniously on the same
system.

An application can be any of the following:

• A UCS application
• A non-UCS application
• A mixed-mode application, consisting of both UCS and non-UCS programs
A mixed mode application is possible because the two environments share both
the same software and the same files. (See 1.4.)
Mixed-mode HVTIP executions are possible starting with SB7.

8–2 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

A single program, however, must be all UCS or all non-UCS at the linking/collection
level: Any one particular user-written program cannot consist of some non-UCS
relocatable elements and some UCS object modules (for example, ACOB relocatable
elements and UCS COBOL object modules).

Since UCS and non-UCS programs can coexist so harmoniously, and even be part of
the same application, it is a good idea to upgrade to UCS when maintaining existing
applications, such as in the following circumstances:
• When new programs are added to an existing application
• When existing programs in an application require maintenance

The following subsections describe how resources, software, and files are shared by
the two programming environments.

8.2.1. Software and File Sharing by UCS and Non-UCS

Programs
At the system software level, the OS 2200 operating system and its related utilities
support both the UCS and non-UCS environments. The same holds true for the
communications software available on the 1100/90 and 2200 hardware.

The UCS high-level languages support a broad base of interfaces that are also
supported by the non-UCS programming languages. These include the following:
• UDS software and its database files
• PCIOS files
• Transaction processing support for TIP and HVTIP, using either MCB, DPS MCB, or
DPS COMPOOL
• Most non-message handling TIP primitives, including FCSS file handling

7831 4077–009 8–3

Planning for Use of UCS in New and Existing Applications

• Sort/Merge support

Table 8–1 provides a summary of the supported interfaces.

Table 8–1. Interfaces Supported in the UCS and Non-UCS

Environments

UCS Programming Interfaces Non-UCS Programming Interfaces

DMS 2200 DMS 2200

RDMS 2200 RDMS 2200
Interpreter SQL Interpreter SQL
Embedded SQL
Module SQL
SFS 2200 SFS 2200
UREP INVOKE
PCIOS files PCIOS files
TIP/HVTIP TIP/HVTIP
MCB commands MCB commands
DPS 2200 commands using MCB DPS 2200 commands using MCB
message buffering message buffering
DPS 2200 commands using COMPOOL DPS 2200 commands using COMPOOL
message buffering message buffering
DPS 2200 commands in a demand DPS 2200 commands in a demand
program program
TIP primitives TIP primitives
Most non-message-handling All non-message-handling COMPOOL
message-handling
FCSS files FCSS files
Sort/Merge Sort/Merge
PCFP
Executive request interface
Contingency Handling
SLIB functions SYSLIB functions
2200 POSIX.1

In most cases, UCS and non-UCS programs can share the interface software. The data
files can also be shared, as long as they contain no Fieldata. UCS software does not
support Fieldata.

8–4 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Appendix A describes how to generate and install this software so that both
environments can make use of it.

8.2.1.1. UDS Database and Software Sharing

The same UDS database files can be accessed by both a UCS program and a non-UCS
program simultaneously. Therefore, a site can code UCS programs or applications that
use existing databases, with no change to the database files. The UCS programs do
not interfere with the non-UCS programs that are already accessing those files.

The only restriction is that no Fieldata characters can exist in the data contained in
these files. UCS software does not support Fieldata.

Not only can UCS and non-UCS programs share the same UDS database files; they can
also share the same UDS software itself. Only one copy of the UDS software is
required on an 1100/90 or 2200 system for both environments. The capabilities of the
UDS software are equal for both environments.

In summary, UCS programs and non-UCS programs can simultaneously access the
same UDS database files, using the same UDS software.

8.2.1.2. PCIOS File Sharing

UCS programs and non-UCS programs can both access the same Processor Common
Input/Output System (PCIOS) files, regardless of the environment (UCS or non-UCS) in
which they were created. Again, the only restriction is that no Fieldata characters can
exist in the data contained in these files. UCS software does not support Fieldata.

UCS and non-UCS programs can access a PCIOS file directly or through SFS 2200
Table 8–2 specifies the supported PCIOS and SFS file access methods and
corresponding file organization for each UCS language.

7831 4077–009 8–5

Planning for Use of UCS in New and Existing Applications

Table 8–2. PCIOS File Access Methods and Organization

Language File Access Method File Organization

UCS COBOL PCIOS PCIOS

Sequential Sequential SDF
Relative Direct SDF
Indexed MSAM
ANSI Tape ANSI Tape
ANSI Interchange ANSI Interchange
Tape Tape
EBCDIC Tape IBM
SFS 2200 SFS 2200
Relative Direct SDF
Indexed MSAM
UCS FORTRAN PCIOS PCIOS
Sequential Sequential SDF
Direct Direct SDF
ANSI Tape ANSI Tape
SFS 2200 SFS 2200
Direct Direct SDF
UCS C PCIOS PCIOS
Text Sequential SDF
Binary Direct SDF
SFS 2200 SFS 2200
Binary Direct SDF

For information on acceptable PCIOS formats, see the programming reference manual
for the UCS language in which the program is coded.

8–6 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.2.1.3. TIPUTILs for UCS and Non-UCS

TIPUTILs are the transaction processing utilities that you use to set up and manage
transaction processing files. They include the TIP primitives that can be incorporated
into an application program. TIPUTILs are installed from the product release tape,
using SOLAR. Refer to the following documents for information on TIPUTILs:
• Transaction Processing Planning and Configuration Guide
This document gives an overview of installing and generating TIPUTILs.

• Transaction Processing Administration and Operations Reference Manual

This document describes how to use the TIP utilities.

TIPUTILs are built to reflect the environment they will be supporting; each TIPUTIL
represents a particular environment. Therefore, a site may or may not have multiple
TIPUTILs, depending upon their transaction processing needs.

The TIPUTIL installed by SOLAR must be the one built for UCS transaction usage. This
TIPUTIL provides TIP utilities that can handle UCS transaction ZOOMs.

Other TIPUTILs can be built and manually copied from tape into the appropriate files
(that is, not installed by SOLAR). These would include the following:
• Non-UCS MCB TIPUTILs
• Non-UCS COMPOOL TIPUTILs
• Other UCS MCB TIPUTILs

7831 4077–009 8–7

Planning for Use of UCS in New and Existing Applications

8.2.1.4. MCB Software Sharing

The Message Control Bank (MCB) is the message control component of the OS 2200
Integrated Recovery system. MCB is a replacement for COMPOOL and provides
additional functional capabilities, particularly in message recovery. MCB is used
primarily in a transaction processing environment.
For detailed information on MCB, refer to the following documents:
• MCB Programming Reference Manual
• MCB Operations Reference Manual

MCB has been designed so that the same copy of the software can be simultaneously
accessed by both UCS and non-UCS transactions. The MCB capabilities are equivalent
in the two environments.

But a change has been made in the coding of MCB commands. The UCS version of
the MCB commands uses a simpler format that optionally identifies the message
buffer and multiple destination list as part of the MCB call The MCB entry points have
also been renamed.

In conjunction with these new command formats, UCS versions of the MCB packet
definition are provided for UCS COBOL, UCS FORTRAN, and UCS C. Refer to Section 5
for details.

8–8 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.2.1.5. DPS Form and Software Sharing

The Display Processing System (DPS 2200) lets you define forms (screens) and
incorporate them into your application program. For information on DPS 2200, refer to
the following documents:
• DPS 2200 Form Design Programming Guide
• DPS 2200 Run-Time Programming Reference Manual
• DPS 2200 Administration Guide

Both UCS and non-UCS programs can simultaneously use the same copy of DPS 2200.
DPS 2200 provides the same programming interface for both UCS and non-UCS
programs. UCS and non-UCS programs that call DPS 2200 are coded exactly the same.

When using DPS 2200 for transaction processing, the site still has the choice of using
MCB or COMPOOL message buffering. Both are available in the UCS environment.

7831 4077–009 8–9

Planning for Use of UCS in New and Existing Applications

Not only can UCS programs and non-UCS programs share the same DPS 2200
software; they can also share the same form files and the same forms within those
files.

8.2.1.6. TIP FCSS File Sharing

Transaction Processing (TIP) File Control Super Structure (FCSS) files are files specially
structured for transaction processing file control. Refer to the Transaction Processing
Programming Guide for information on TIP FCSS files.

Both UCS and non-UCS transactions can share TIP FCSS files. UCS does not require
changes to the definition or access of these TIP files. Again, the only restriction is that
FCSS files accessed by UCS transactions cannot contain any Fieldata characters. UCS
software does not support Fieldata.

8–10 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.2.2. Coexistence of UCS and Non-UCS Programs in Different

Environments
In addition to sharing software and data files, UCS programs also coexist with non-
UCS programs in the different environments potentially present on an extended mode
system. The following subsections describe how UCS and non-UCS programs coexist
in each of the following environments:
• Batch and demand
• TIP and HVTIP
• SX 1100

8.2.2.1. Coexistence in Batch and Demand Environments

Batch and demand programs execute under a OS 2200 operating system that fully
supports UCS. Non-UCS programs continue to execute normally and coexist with UCS
programs.

A user-developed application can consist of both UCS and non-UCS programs. The
only rule for user-written programs is that at the linking/collection level, any one
particular program must be all UCS or all non-UCS: Any one particular user-written
program cannot consist of some non-UCS relocatables and some UCS object modules.

8.2.2.2. Coexistence in TIP and HVTIP Environments

TIP and HVTIP programs execute under a 2200 operating system that fully supports
UCS. As with most existing programs, non-UCS transactions continue to execute
normally and coexist with UCS transactions.

A single application can even consist of some UCS transactions and some non-UCS
transactions. These applications are possible because transactions can
conversationally link or pass off across the UCS and non-UCS environments. This
means that a UCS transaction can conversationally link to a non-UCS transaction,
which can in turn conversationally link to a UCS transaction. The conversation can flow
in either direction between UCS and non-UCS transactions.

7831 4077–009 8–11

Planning for Use of UCS in New and Existing Applications

Pass-off messages can also span UCS and non-UCS environments. A UCS transaction
can pass off to a non-UCS transaction, which can pass off to a UCS transaction.

UCS Pass-off Non-UCS Pass-off UCS

Transaction Message Transaction Message Transaction

For both conversational links and pass-off messages, the message handling must use
all COMPOOL or all MCB in the same application group. This makes coexistence easy
in the TIP/HVTIP environment.

The only rule for user-written transactions is that any one particular transaction must
be all UCS or all non-UCS. In the HVTIP environment, this restriction is relaxed: An
extended mode transaction can have both extended mode subprograms (ZOOMs) and
basic mode subprograms (absolutes) (see 6.1.8).

8–12 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

One method that can be used to run a mixed-mode HVTIP application involves using
two initial control programs (an absolute and a ZOOM) with matching subprograms.

Subprogram
Absolutes

002378

Using this method, a transaction code (trancd) with associated data is entered, and the
following occurs:
• The ICP absolute is loaded.
• This ICP accesses a table that identifies whether each transaction code has been
implemented using ZOOMs or is still using absolutes.
• If not upgraded to ZOOMs, absolutes are used. The ICP absolute calls the correct
subprogram absolutes. All processing for the transaction takes place using
absolutes.
• If ZOOMs are implemented, the ICP absolute performs a PASSOFF to the ICP
ZOOM. The passoff message should reflect the trancd and all data, as though this
message was entered from a terminal. The ICP ZOOM calls the correct
subprogram ZOOMs. All processing for the transaction takes place using ZOOMs.
Note: This setup requires that message buffering be all COMPOOL or all MCB.
ZOOMs support either MCB message buffering using MCB functions or DPS 2200
functions, or COMPOOL message buffering through DPS.

Once all code is upgraded to ZOOMs, the absolute ICP, absolute subprograms, and the
lookup table can be discarded.

7831 4077–009 8–13

Planning for Use of UCS in New and Existing Applications

8.2.2.3. Coexistence in the SX 1100 Environment

SX 1100 C is an additional implementation of the C programming language supported
on OS 2200 systems. SX 1100 C was implemented before the development of UCS and
UCS C.

The SX 1100 operating environment can coexist with the OS 2200 operating
environment. In the same fashion, UCS C programs can coexist with SX 1100 C
programs; a site can continue to run SX 1100 C applications as before.

However, UCS C programs cannot communicate with SX 1100 C programs. If

necessary, you can upgrade these programs to UCS C (see 8.3.3).

8–14 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.3. Upgrading Existing Programs to UCS

UCS provides tools that simplify code development and increase programmer
productivity. Upgrading programs to UCS allows applications to benefit from improved
program development, execution, debugging, and maintenance. See Section 1 for a
description of the increased capabilities of UCS.

Once an organization installs UCS software, it can begin to upgrade non-UCS programs
and transactions to UCS, if beneficial. For example, in the following circumstances, it is
a good idea to convert an existing program to UCS:
• If maintenance is required on an existing program and it must be recoded and
recompiled anyway
• If the new features available in UCS and the extended mode architecture would
increase the performance or capability of an existing program

A site can gradually upgrade programs to UCS because UCS is designed to coexist
with the older, non-UCS environment. A site can upgrade some programs in an
application to UCS while others remain non-UCS programs. (See 1.4.)

Table 8–3 outlines the process of upgrading existing programs to UCS:

Table 8–3. Steps to Upgrade an Existing Program to UCS

Step Description

1 Determine which existing programs need the added capabilities of UCS

software and extended mode hardware.
2 Assess the site’s resources and allocate time, people, and resources to
the upgrading process.
UCS C, UCS COBOL, and UCS FORTRAN programs automatically use the
expanded addressing space available in the extended mode
architecture. Using both expanded addressing and the UCS code
optimizer, often increases program performance.
When upgrading applications from ASCII COBOL or ASCII FORTRAN to
the UCS languages to take advantage of these performance
improvements, it is recommended that 3 to 4 megawords of additional
memory be available. This additional memory prevents memory
thrashing, which could cause performance degradation.
3 Upgrade source programs to the requirements of each UCS language or
environment (described later in this section).
4 Recompile with the appropriate UCS compiler and link the program with
the Linking System.
5 Test the UCS programs and compare the results with those of their non-
UCS counterparts.

7831 4077–009 8–15

Planning for Use of UCS in New and Existing Applications

Upgrading the language syntax of a program may be simple or complex, depending on

• Whether the program is coded in a language available in UCS
• How closely the program conforms to the applicable language standards

If programs are coded in one of the four languages that UCS supports and closely
conform to the standards, tools are available to simplify the upgrade of the source
code, thus reducing or eliminating any manual conversion.

Note: Most of the tools provided are in the form of keyword options on the UCS
compiler calls. The compilers have compatibility keyword options that resolve
differences between non-UCS and UCS versions of COBOL, FORTRAN, and C UCS
FORTRAN also has a compiler keyword option that actually converts older source
code into a format acceptable to UCS FORTRAN.

The following subsections describe

• The changes that are necessary to upgrade a program to UCS
• The UCS tools that aid this effort
• Upgrading for interface products

8–16 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.3.1. Upgrading COBOL Programs

To upgrade COBOL programs that are compatible with the 1985 American National
Standard with the 1989 Intrinsic Function Addendum to UCS, you need to merely
recompile them with UCS COBOL. Most programs that are compatible with the 1974
American National Standard will compile error-free with UCS COBOL.

To ease the transition from ASCII COBOL (ACOB), UCS COBOL provides several
keyword options that perform conversion tasks as part of the compilation process.

The recommended method for an easy upgrade is as follows:

1. Compile the existing program with one of these compatibility keyword options.
2. Check the compiler output for areas that require manual conversion.

Using these keyword options reduces the amount of coding changes, if any, required
to upgrade the program.

Table 8–4 describes the relevant keyword options. Based on the descriptions, use the
keyword option that best matches your site’s use of ASCII COBOL.

7831 4077–009 8–17

Planning for Use of UCS in New and Existing Applications

Table 8–4. Keyword Options for Upgrading COBOL Programs

Keyword Option Description

COMPAT The COMPAT keyword option makes the following features

compatible with ASCII COBOL:
COMP data items are allocated as BINARY.
COMP-3 data items are allocated as PACKED-DECIMAL.
Exact binary items can be described without change. For
example, PIC-1 without a USAGE BINARY-1 clause defines an
exact binary item.
The SYNCHRONIZED clause allocates compatible data.
Word alignment for COMP-1 and COMP-2 data items is
compatible.
PROGRAM-ID can be an integer.
HIGH-VALUE is octal 0177 (all bits set for a 7-bit machine).
COMPAT/FULL The COMPAT/FULL keyword option provides the same
compatibility as the COMPAT keyword option; it also allocates all
static variables, whether or not they are ever referenced. Also, all
static variables are placed in one bank. These two additional
features are the same as the ACOB implementation.
Code compiled using the COMPAT/FULL keyword option is not as
performance efficient as code compiled using the COMPAT
keyword option.
COMPAT/HV377 The COMPAT/HV377 keyword option provides the same
compatibility as the COMPAT keyword option, except that items
with the HIGH-VALUES attribute are set to octal 0377 (all bits set
for an 8-bit machine).
COMPAT/HV177 COMPAT/HV177 sets HIGH-VALUES to octal 0177. It has no other
effect.
COMP-BIN The COMP-BIN compiler keyword option causes an item declared
as USAGE COMP to be treated as though it were declared USAGE
BINARY. The COMPAT keyword option also sets this option. If
both the COMPAT and NO-COMP-BIN keyword options are
specified, COMPAT overrides NO-COMP-BIN.
COMPAT/ARGUMENTS COMPAT/ARGUMENTS restrict parameters of a CALL statement
which are passed BY REFERENCE to 01 and 77 level items.

Several products that interface with UCS COBOL programs require use of the
compatibility keyword options to compile and execute properly:
• UDS DML
UDS DML programs require the COMPAT (but only if the subschema includes
items with USAGE COMP-1 or COMP-2) keyword option to resolve the use of the
ASCII COBOL USAGE clauses that occur in the record descriptions.

8–18 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

• DPS 2200
DPS 2200 programs and transactions that use predefined ASCII-COBOL-format
forms whose procedures were generated using SB3 software require the
COMPAT/FULL and NO-OPTIM keyword options to
− Resolve the ASCII COBOL USAGE clauses
− Provide proper data alignment
When using UDS DML with DPS 2200 in this situation, use the COMPAT/FULL and
NO-OPTIM keyword options to satisfy both products’ requirements.
DPS 2200 programs and transactions that use predefined ASCII-COBOL-format
forms whose procedures were generated using SB4 or later software require the
COMPAT keyword option to resolve the ASCII COBOL USAGE clauses.
• COBOL
Any COBOL programs that contain the ASCII COBOL USAGE clauses require, at a
minimum, the COMPAT keyword option.

Even with use of the compatibility keyword options, certain language features are
implemented differently in UCS COBOL than in ASCII COBOL. These changes can
potentially change the execution of a program upgraded from previous COBOL
standards. To find information on these differences, see the COBOL Compiler
Programming Reference Manual Volume 2. It includes information about the
following:
• Differences that occur because UCS COBOL is a new implementation of COBOL
• Features of ASCII COBOL that are not carried forward to UCS COBOL
• Changes in the 1985 American National Standard COBOL and substantive changes
made by the standards committee
• Language elements that are obsolete

Carefully read this material to determine how best to upgrade 1974 American National
Standard COBOL (ASCII COBOL) programs to UCS COBOL.

8.3.2. Upgrading FORTRAN Programs

To upgrade ASCII FORTRAN programs that adhere to the 1978 American National
Standard and have extensions that are carried forward to UCS FORTRAN, simply
recompile them with the UCS FORTRAN compiler. UCS FORTRAN supports most
nonstandard ASCII FORTRAN extensions. New, improved UCS FORTRAN
replacements are available for most of the ASCII FORTRAN features that are no longer
supported.

The UCS FORTRAN compiler has several tools that ease the upgrade of programs that
do not adhere to the 1978 American National Standard. Table 8–5 describes keyword
options that

• Resolve many of the differences that exist between the two implementations of
FORTRAN

7831 4077–009 8–19

Planning for Use of UCS in New and Existing Applications

• Actually convert archaic source code so that it conforms to the 1978 American
National Standard

Table 8–5. Keyword Options for Upgrading FORTRAN Programs

Keyword Option Description

CONVERT The CONVERT keyword option converts ASCII FORTRAN source code
that contains archaic syntax to a new version of the source code that
conforms to the current standard.
The UCS FORTRAN compiler accepts the nonstandard syntax and
flags the following items as archaic:
Syntax that the future Unisys FORTRAN 90 compiler might not
support. This includes ambiguous coding due to 31-character names
and poor coding techniques.
Syntax that the current standard defines differently.

When the CONVERT keyword option is in effect, the UCS FORTRAN

compiler automatically converts most of these archaic features to
standard code. The compiler flags the nonstandard syntax features
that cannot be handled by the compiler. These cases require manual
conversion.
CONVERT/PROC The CONVERT/PROC keyword option functions the same as the
CONVERT keyword option, but additionally converts all INCLUDE
procedures.
COMPAT The COMPAT keyword option causes
Resolution of ambiguities due to 31-character names, nonstandard
coding, and insignificant blanks
Resolution of conflicts due to nonstandard character assignment
statements
Programs compiled with this keyword option might sustain degraded
performance in the area of character assignment statements. In
general, use COMPAT only for programs that contain nonstandard
coding.

8–20 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

There is a COMPILER statement option (STD=66) that causes the UCS FORTRAN
compiler to handle the following items using ASCII FORTRAN techniques:
• DO loops always execute once.
• The compiler allocates all character data, including array elements and members of
common blocks, on word boundaries.

The compiler determines

• The type of a statement function by its use
• The type of a parameter variable by the type of the value it defines

Use the STD=66 option to resolve compatibility problems that occur during the
upgrade of older ASCII FORTRAN programs.

See the FORTRAN Compiler Programming Reference Manual Volume 2 for a detailed
description of these compiler keyword options and COMPILER statement options and
for information about how to use them. This manual also contains a summary of the
differences between ASCII FORTRAN and UCS FORTRAN, including the following
topics:

• UCS FORTRAN extensions that are not in ASCII FORTRAN

• UCS FORTRAN changes to ASCII FORTRAN extensions
• ASCII FORTRAN extensions that are fully supported in UCS FORTRAN
• Unsupported ASCII FORTRAN extensions
• ASCII FORTRAN extensions that cause ambiguity problems and how they are
resolved with the COMPAT keyword option
• ASCII FORTRAN extensions that are archaic and must be converted
• Execution differences between ASCII FORTRAN and UCS FORTRAN

This manual also describes other miscellaneous differences between the two versions
of FORTRAN. Read this information carefully to help determine the resources needed
to upgrade programs to UCS FORTRAN.

8.3.3. Upgrading C Programs

SX 1100 C is an additional implementation of the C language supported on OS 2200
systems. SX 1100 C was implemented before UCS C. The UCS C compiler can help
upgrade C programs in the SX 1100 operating environment to the OS 2200 operating
environment.

When moving from SX 1100, some change in the way C programs access data and
interface with system facilities is necessary because the program’s execution no
longer involves the SX 1100 operating environment. C programs running in an SX 1100
environment are not dependent on the UNIXR operating system. Use the C
compatibility keyword option COMPAT when moving C programs from the SX 1100
environment to the OS 2200 environment. For information on COMPAT, see the C
Compiler Programming Reference Manual Volume 2.

7831 4077–009 8–21

Planning for Use of UCS in New and Existing Applications

UCS C manipulates ordinary OS 2200 system data format (SDF) files. These files are
compatible with SX 1100 only to the extent that SX 1100 can read and write SDF files.
No facility is provided for reading and writing files uniquely formatted for SX 1100.
Also, SX 1100 binary data files are not compatible with UCS C.

8.3.4. Upgrading Other Languages

Programs written in the following languages have no equivalents in UCS:
• Report Program Generator II (RPG II)
• PL/I
• APL

However, these programs continue to run in the non-UCS environment and coexist
with UCS programs.

You can upgrade these programs by rewriting them in one of the UCS languages: UCS
COBOL, UCS FORTRAN, or UCS C. Also, if these programs use PCIOS data files, a UCS
program or application can share their data.

8.3.5. Upgrading MASM Programs

Note: Unisys supports “extended mode” MASM usage (assembler directive
$EXTEND with or without assembler directive $OBJ) only in software written by
Unisys or in interfaces written by the customer that explicitly require extended
mode assembler-produced elements, according to documentation supplied by
Unisys. In a “nonextended mode” (basic mode) MASM usage (absence of
assembler directive $EXTEND), Unisys does not support the generation of object
modules (use of assembler directive $OBJ). Unisys will continue to provide full
support for the generation of other provided element types which are not object
modules (absence of both the $EXTEND and $OBJ assembler directives).

If a MASM program is called from a UCS-compiled program or requires a large

extended mode addressing environment, it must be upgraded to UCS. Consider the
following points when upgrading MASM code to UCS high-level languages:
• Many MASM components of complex systems exist only as an interface to a
system service that is accessible through an Executive request (ER). If a MASM
program only issues ERs, replace the program by calling the appropriate UCS
library routine from the UCS program. All UCS languages support access to basic
mode ERs through UCS Runtime System interface routines.

8–22 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Common ERs, such as EABT$, also have unique entry points that are directly
callable from UCS programs. For more information about the interface routines for
ERs, see the programming reference manual for the appropriate language. (For
UCS COBOL, UCS FORTRAN, and UCS C , this is Volume 2.)
• Consider the purpose and structure of the MASM program and determine if it is
more cost effective to rewrite the program in a high-level UCS language. High-
level languages such as C and FORTRAN now perform functions similar to MASM
subprograms.
• Upgrade assembly language programs to extended mode MASM if Unisys
documentation explicitly requires it. In these cases, complete examples of sample
MASM code are provided and explained, so the programmer need not have
MASM background.

Replacing assembly language with high-level languages is a desirable practice. A long

range strategy of reducing reliance on MASM should be considered in order to
distance applications from the architectural characteristics of a particular system.

8.3.6. Upgrading User-Written Libraries

User subroutines or functions that programs use frequently can be grouped and
stored together as a user library. To upgrade your user library subroutines and
functions to a UCS language, follow the same process as upgrading a program. If a
subroutine or function is written in a language that is not available in UCS, rewrite it in
the UCS language that works best for the tasks involved.

You should consider several points before upgrading user libraries to the UCS
languages:
• UCS applications will execute only with subroutines and functions compiled with a
UCS compiler. If a subroutine or function is called by both UCS and non-UCS
programs, two versions of the routine must exist (an object module version and a
relocatable binary version).
• A separate non-UCS calling interface may need to be written for each non-UCS
language that calls a subroutine or function. However, only one entry point is
needed for those routines called by a UCS program. Before upgrading to the UCS
languages, determine if the calling sequence for each subroutine or function is
valid or needs to be adapted to the UCS standard calling sequence.

7831 4077–009 8–23

Planning for Use of UCS in New and Existing Applications

For user-written libraries, the definition of each language continues to govern

interlanguage calls. This includes
• Data-type compatibilities
• Parameter-passing modes (for example, pass by reference in COBOL or
FORTRAN, and pass by value in C)

For information on interlanguage calls, see the programming reference manual for the
appropriate language. (For UCS COBOL, UCS FORTRAN, and UCS C, this is volume 2.)

Table 8–6 includes a list of basic mode ERs and the extended mode services that they
provide. The table also identifies the SB release level and UCS language supported for
each ER.

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

ABORT$ FABORT SB3R1 C COBOL FORTRAN

ABORT$ FABORT SB4R4
ACSF$ FACSF, FACSF2, IACSF, SB3R1 C COBOL FORTRAN
IACSF2
ACSF$ ACSF SB4R4
ACT$ RTS Multitasking SB3R1 FORTRAN
ACT$ RTS Multitasking SB4R2 C
APNCHA$ FSYMB SB3R1 C COBOL FORTRAN
APRINT$ FSYMB SB3R1 C COBOL FORTRAN
APRNTA$ FSYMB SB3R1 C COBOL FORTRAN
APRTCA$ FSYMB SB3R1 C COBOL FORTRAN
APRTCN$ FSYMB SB3R1 C COBOL FORTRAN
APUNCH$ FSYMB SB3R1 C COBOL FORTRAN
AREAD$ FSYMB SB3R1 C COBOL FORTRAN
AREADA$ FSYMB SB3R1 C COBOL FORTRAN
ATREAD$ FSYMB SB3R1 C COBOL FORTRAN
BANK$ UCSBANK$ SB3R1 FORTRAN
BANK$ SLIB: Storage SB4R1 C
Management
CLIST$ UCSCLIST$ SB3R1 C COBOL FORTRAN
CO$MIT TIP Primitive: COMMIT SB3R1 C COBOL FORTRAN

8–24 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

CO$MIT TIP Primitive: COMMIT SB4R4

COM$ UCSGENERAL$ Note 1 C COBOL FORTRAN
COND$ FCOND SB3R1 C COBOL FORTRAN
COND$ COND SB4R4
CONFIG$ UCSGENERAL$ Note 1 C COBOL FORTRAN
CSF$ FACSF, FACSF2, IACSF, SB3R1 C COBOL FORTRAN
IACSF2
CSI$ UCSGENERAL$ Note 1 C COBOL FORTRAN
CTS$ RTS Test and Set SB4R2 C
Queuing
CTSA$ RTS Test and Set SB4R2 C
Queuing
CTSQ$ RTS Test and Set SB4R2 C
Queuing
DACT$ RTS Multitasking SB3R1 FORTRAN
DACT$ RTS Multitasking SB4R2 C
DATE$ ADATE SB3R1 C COBOL FORTRAN
DATE$ ADATE SB4R4
DM$IOW SLIB: E_DMIOW SB4R4 C
EABT$ FEABT SB3R1 C COBOL FORTRAN
EABT$ FEABT SB4R4
EDJS$ UCSGENERAL$ Note 1 C COBOL FORTRAN
ERR$ FERR SB3R1 C COBOL FORTRAN
ERR$ FERR SB4R4
ERRPR$ UCSGENERAL$ Note 1 C COBOL FORTRAN
EXIT$ FEXIT SB3R1 C COBOL FORTRAN
EXIT$ FEXIT SB4R4
FACIL$ UCSGENERAL$ Note 1 C COBOL FORTRAN
FC$SSN- TIP Primitive: FCSS SB3R1 C COBOL FORTRAN
AD
FC$SSN- TIP Primitive: FCSS SB4R4
AD

7831 4077–009 8–25

Planning for Use of UCS in New and Existing Applications

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

FC$SSN-IO TIP Primitive: FCSS SB3R1 C COBOL FORTRAN

FC$SSN-IO TIP Primitive: FCSS SB4R4
FITEM$ UCSFITEM$ SB3R1 C COBOL FORTRAN
FITEM$ FITEM SB4R4
FL$BOX UCSGENERAL$ Note 1 C COBOL
FORK$ RTS Multitasking Note 2 C FORTRAN
HMDBIT$ UCSGENERAL$ Note 1
INFO$ UCSINFO$ SB3R1 C COBOL FORTRAN
INFO$ One for each function SB4R4
code
IO$ FIO SB3R1 C FORTRAN
IO$ FIO Note 3 COBOL
IO$ FIO SB4R4
IOW$ FIOW SB3R1 C FORTRAN
IOW$ FIOW Note 3 COBOL
IOW$ SLIB: E_IOW SB4R4 C
IOW$ FIOW SB4R4
LCORE$ UCSBANK$ SB3R1 C COBOL FORTRAN
LEVEL$ UCSGENERAL$ Note 1 C COBOL FORTRAN
LOAD$ Applies to Collector N/A
MCORE$ UCSBANK$ SB3R1 C COBOL FORTRAN
MCT$ UCSGENERAL$ Note 1
MODPS$ UCSGENERAL$ Note 1
MSCON$ UCSGENERAL$ Note 1
OPT$ UCSOPT$ SB3R1 C COBOL FORTRAN
OPT$ OPT SB4R4
PB$CON TIP Primitive: CONECT SB3R1 C COBOL FORTRAN
PB$CON TIP Primitive: CONECT SB4R4
PB$DIS TIP Primitive: DISCON SB3R1 C COBOL FORTRAN
PB$DIS TIP Primitive: DISCON SB4R4

8–26 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

PCT$ UCSPCT$ SB3R1 C COBOL FORTRAN

PCT$ PCT SB4R4
PFD$ UCSPFT$ SB3R1 C COBOL FORTRAN
PFD$ PFD SB4R4
PFI$ UCSPFI$ SB3R1 C COBOL FORTRAN
PFI$ PFI SB4R4
PFS$ UCSPFS$ SB3R1 C COBOL FORTRAN
PFS$ PFS SB4R4
PFUWL$ UCSPFUWL$ SB3R1 C COBOL FORTRAN
PFUWL$ PFUWL SB4R4
PFWL$ UCSPFWL$ SB3R1 C COBOL FORTRAN
PFWL$ PFWL SB4R4
PRINT$ FSYMB SB3R1 C COBOL FORTRAN
PRNTA$ FSYMB SB3R1 C COBOL FORTRAN
PRTCA$ FSYMB SB3R1 C COBOL FORTRAN
PRTCN$ FSYMB SB3R1 C COBOL FORTRAN
PSR$ UCSGENERAL$ Note 1 C COBOL FORTRAN
READ$ FSYMB SB3R1 C COBOL FORTRAN
RL$BAK TIP Primitive: ROLLBAK SB3R1 C COBOL FORTRAN
RL$BAK TIP Primitive: ROLLBAK SB4R4
RSI$ UCSGENERAL$ Note 1
RT$ UCSGENERAL$ Note 1
RT$INT TIP ER - UCSGENERAL$ Note 1
RT$PID TIP ER - UCSGENERAL$ Note 1
SETBP$ UCSGENERAL$ Note 1
SETC$ FSETC SB3R1 C COBOL FORTRAN
SETC$ SETC SB4R4
SMOQUE$ UCSGENERAL$ Note 1
SNAP$ UCSGENERAL$ Note 1
SPRNT$ UCSGENERAL$ Note 1

7831 4077–009 8–27

Planning for Use of UCS in New and Existing Applications

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

SUMOD$ UCSGENERAL$ Note 1

SUVAL$ UCSGENERAL$ Note 1
SYMB$ FSYMB SB3R1 C COBOL FORTRAN
SYMB$ Several SB4R4
SYMINFO$ UCSGENERAL$ Note 1 C COBOL FORTRAN
SYSLOG$ UCSGENERAL$ Note 1
TDATE$ UCSTDATE$ SB3R1 C COBOL FORTRAN
TDATE$ TDATE SB4R4
TIME$ UCSTIME$ SB3R1 C COBOL FORTRAN
TINTL$ UCSTINTL$ SB3R1 C COBOL FORTRAN
TINTL$ TINTL SB4R4
TLBL$ UCSTLBL$ SB3R1 C COBOL FORTRAN
TLBL$ TLBL SB4R4
TREAD$ FSYMB SB3R1 C COBOL FORTRAN
TSWAP$ FTSWAP, UCSTSWAP$ SB3R1 C COBOL FORTRAN
TSWAP$ NEW_REEL_, SB4R4
NEXT_REEL
TWAIT$ UCSGENERAL$ Note 1 C COBOL FORTRAN
UNLCK$ FUNLCK SB3R1 C COBOL FORTRAN
UNLCK$ FUNLCK SB4R4
UO$AND TIP Primitive: UOPAND SB3R1 C COBOL FORTRAN
UO$AND TIP Primitive: UOPAND SB4R4
UO$GET TIP Primitive: UOPGET SB3R1 C COBOL FORTRAN
UO$GET TIP Primitive: UOPGET SB4R4
UO$OR TIP Primitive: UOPTOR SB3R1 C COBOL FORTRAN
UO$OR TIP Primitive: UOPTOR SB4R4
UT$DEL TIP Primitive: TIMDEL SB3R1 C COBOL FORTRAN
UT$DEL TIP Primitive: TIMDEL SB4R4
UT$EAQ TIP Primitive: TIMABS SB3R1 C COBOL FORTRAN
UT$EAQ TIP Primitive: TIMABS SB4R4

8–28 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Table 8–6. Basic Mode ERs and Extended Mode Services for UCS
Languages

Basic
Mode Exec Extended Mode Initial
Request Service Release UCS Languages Supported

UT$ERQ TIP Primitive: TIMREL SB3R1 C COBOL FORTRAN

UT$ERQ TIP Primitive: TIMREL SB4R4
UT$UPA TIP Primitive: TIMUPA SB3R1 C COBOL FORTRAN
UT$UPA TIP Primitive: TIMUPA SB4R4
UT$UPR TIP Primitive: TIMUPR SB3R1 C COBOL FORTRAN
UT$UPR TIP Primitive: TIMUPR SB4R4
WAIT$ FWST SB3R1 C COBOL FORTRAN
WAIT$ FWST SB4R4
WALL$ UCSGENERAL$ Note 1 C COBOL FORTRAN
WANY$ FWANY SB3R1 C COBOL FORTRAN
WANY$ FWANY SB4R4

Notes:
1. There are several cautions, restrictions and concerns regarding the usage of the
UCSGENERAL$ versions of the basic mode ERs. Consult the appropriate
language programming reference manual for details on UCSGENERAL$
implementation and usage.
2. The RTS Multitasking implementation in this basic mode ER does not provide
the total capability of the Executive Request.
3. The implementation of the UCS COBOL LOC$ function in SB4R2 has made these
ERs available.

7831 4077–009 8–29

Planning for Use of UCS in New and Existing Applications

8.3.7. High-Level Language Interfaces

The Service Library services are designed for use by programs written in high-
level UCS languages. With continuing software release levels of the Service
Library, additional services are provided; services are also made available to more
UCS languages.

The following list shows services made available to UCS languages by the Service
Library (product SLIB). See the Service Library Programming Reference Manual
for details.
• Character Conversion
• Condition Word
• Element Type
• Internal Format
• Level ID
• Processor Setup
• SDF Input
• Storage Management
• Symbolic Read
• Symbolic Write
• Time and Date

8–30 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.3.8. Common Bank Considerations

Non-UCS applications can use common banks to share code and data across many
callers of a system. The following types of common banks exist:
• Alternate file common banks (AFCB)
• Configured common banks
• Nonconfigured common banks

UCS code and data banks cannot be packaged as common banks; instead, they must
be packaged as extended mode software subsystems in order to achieve sharing
capabilities similar to non-UCS common banked applications. Software subsystems
can be constructed only with UCS compiler-produced object modules.

In general, UCS programs do not have the ability to call common banks directly.

If shared banks are a necessary part of a non-UCS application being upgraded to UCS,
it will be necessary to replace common banks with software subsystems.

If shared banks are not required when moving to UCS, then nonshared object modules
are an option.

Software subsystems provide additional capabilities not provided by common banks.

They can be used to create protection and sharing environments and replace the
following capabilities associated with common banks:
• System-wide code bank sharing
• System-wide data bank sharing
• Code entry-point protection

For detailed information about creating and installing software subsystems, refer to
the Linking System Subsystems Programming Guide.

7831 4077–009 8–31

Planning for Use of UCS in New and Existing Applications

8.3.9. Upgrading UDS Applications

Upgrading UDS programs is very simple. The UCS and non-UCS environments have
equivalent capabilities. In most cases, UCS and non-UCS programs use the same
syntax and file structures.

The following subsections outline the changes needed to upgrade DMS 2200, RDMS
2200, and SFS 2200 programs to UCS.

For complete examples of UCS programs that access UDS databases, see 3.2.

8.3.9.1. Upgrading Existing DMS 2200 Applications to UCS

The following are considerations when upgrading non-UCS data manipulation language
(DML) programs to UCS DML programs. For complete information on DML programs,
refer to the following documents:
DMS CDML Operations and Programming Reference Manual
DMS FDML Operations and Programming Reference Manual
Schema
UCS and non-UCS programs can share the same schema, as long as it contains no
Fieldata characters. If the schema contains Fieldata, you must update both the schema
and the database.

The schema cannot use any of the new UCS COBOL USAGE clauses (BINARY-1,
BINARY, DISPLAY-2). Note that the new schemas written with the COBOL 85 syntax
and containing the SOURCE IS UCS clause, can use the new USAGE types.

All area names, record names, data item names, set names, and database data names
must be unique. For example, a schema cannot contain a record and an area with the
same name. Also, these names must be unique within the COBOL program.

The database procedures for a schema can be upgraded to UCS COBOL once all
application programs for that schema have been upgraded to UCS.

ASCII COBOL, ASCII FORTRAN, UCS COBOL, and UCS FORTRAN application programs
can use database procedures that are coded using ASCII COBOL or basic mode
MASM. Additionally, ASCII COBOL, UCS COBOL, DMU, and QLP application programs
can access UCS COBOL database procedures.

8–32 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Subschema
Separate subschemas are required for UCS programs. These subschemas require one
of the following new host language clauses:
• HOST LANGUAGE IS UCS COBOL.
• HOST LANGUAGE IS UCS FORTRAN. These clauses generate the S$WORK
element as an object module.

UCS subschemas cannot contain any Fieldata characters. This requires that the
subschemas contain no COBOL REDEFINES clauses with USAGE COMP-4 or USAGE
DISP-1.

You cannot use the T option when processing UCS subschemas. This option converts
COBOL USAGE clauses from ASCII to Fieldata, and Fieldata to ASCII. Note that the
Subschema Data Definition Language (SDDL) processor produces no output and
issues a fatal error message if it discovers Fieldata data definitions while processing a
UCS subschema.

Note that the F option is no longer required on the SDDL processor call. SDDL
converts the record and data names descriptions to COBOL 85 compliant code. When
you create a UCS subschema that will be used by HVTIP transactions, the SDDL
processor call must use the C option if the subschema storage is COMMON.

Preprocessing
No preprocessing is required for UCS DML programs. DML commands are parsed by
the UCS COBOL and UCS FORTRAN compilers themselves.

Coding
You must recode the INVOKE statement to reflect the use of the UCS subschema.

For HVTIP transactions, the INVOKE statement must include the ENVIRONMENT IS
HVTIP clause if the subschema storage is COMMON.

Compiling
If the subschema file has a qualifier that is different from the project-id of the
compilation, you must identify the subschema file to the UCS compiler, before calling
the UCS compiler.

Do this by doing the following, before calling the UCS compiler:

1. Assign (@ASG) the subschema file.
2. Give the subschema file an internal name (@USE) of the subschema filename,
without the qualifier.

UCS COBOL DML programs do not require the COMPAT keyword option unless
COMP-1 or COMP-2 items are included in the subschema. When used, the COMPAT
keyword option converts these clauses to the correct UCS formats.

You can use the COMPAT/FULL keyword option instead, if it is required by other
interface products used in the program.

7831 4077–009 8–33

Planning for Use of UCS in New and Existing Applications

UCS FORTRAN DML programs do not require any special compiler keyword options.

The UCS compilers parse both the host language syntax and the DML syntax. They
produce an object module that contains the D$WORK element.

Linking
Before dynamically or statically linking a UCS DML program, you must identify the
DMS software belonging to the correct application group. Do this by using an @USE
statement with the following format:

@USE LINK$PF,SYS$LIB$*APP$n

where n represents the application group number. See Section 4 for information on
this process.

When dynamically linking a UCS DML program, you must copy the subschema object
module S$WORK to the @XQT file (HOME$) before execution, so the dynamic linker
can locate this object module.

When statically linking a UCS DML program, you must use an INCLUDE command that
specifies the subschema S$WORK object module.

In HVTIP, if you use the INDEX command in the static link, it must include the
subschema common block. See 6.2.1 for details and examples of the INDEX command.

8.3.9.2. Upgrading Existing RDMS 2200 Applications to UCS

The following are considerations when upgrading non-UCS RDMS 2200 programs to
UCS RDMS 2200 programs. For complete information on RDMS 2200, refer to the
following documents:
• Relational Database Server Administration Guide
• RDMS SQL Programming Reference Manual
• RDMS and IPF SQL Interface End Use Guide
Table and View Definitions
No changes are required in the definition of existing tables or views.

Coding
No changes are required in the coding of Relational Data Manipulation Language
(RDML) programs.

If desired, you can convert ASCII COBOL programs that access RDMS 2200 databases
to the new embedded SQL interface available with UCS COBOL. You can also convert
ASCII FORTRAN programs that access RDMS 2200 databases to the new Module
Language SQL interface available with UCS FORTRAN. Also, for UCS programs that
use SQL (interpreted or embedded), you may want to specify the RDMS work area
size on the UCS version of the RSA$INIT routine.

8–34 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Compiling
No special compiler keyword options are required for compilation.

Linking
Before dynamically or statically linking a UCS RDMS 2200 program, you must identify
the RDMS 2200 software belonging to the correct application group. Do this by using
an @USE statement with the following format:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the application group number.

See Section 4 for information on this process.

8.3.9.3. Upgrading Existing SFS 2200 Applications to UCS

The following are considerations when upgrading non-UCS SFS 2200 programs to UCS
SFS 2200 programs. For complete information on SFS 2200, refer to the SFS
Administration and Support Reference Manual.

File Definitions
No changes are required in the definition of SFS files for UCS COBOL and UCS
FORTRAN.

The Define File Processor (DFP) is required to define SFS files for UCS C.

Coding
No changes are required in the coding of SFS programs.

Compiling
UCS FORTRAN and UCS C require no special compiler keyword options for
compilations.

UCS COBOL requires the COMPAT keyword option, if the ASCII COBOL USAGE
clauses are used in the file definitions. You can use the COMPAT/FULL keyword option
instead, if it is required by other interface products used in the program.

Linking
Before dynamically or statically linking a UCS SFS 2200 program, you must identify the
SFS 2200 software belonging to the correct application group. Do this by using an
@USE statement with the following format:
@USE LINK$PF,SYS$LIB$*APP$n

where n represents the application group number.

See Section 4 for more information on this process.

7831 4077–009 8–35

Planning for Use of UCS in New and Existing Applications

8.3.10. Upgrading Existing Programs That Access PCIOS Files

PCIOS file handling is supported for both UCS and non-UCS programs. UCS programs
can use existing PCIOS files as long as the PCIOS files contain no Fieldata characters.

No recoding is required when upgrading a non-UCS program that accesses PCIOS files
to UCS. When compiling UCS COBOL programs, you must use the COMPAT keyword
option if the ASCII COBOL USAGE clauses are used in the file definitions. You can use
the COMPAT/FULL keyword option instead, if it is required by other interface products
used in the program.

8.3.11. Converting Old Data Files

Newly developed or upgraded UCS programs may need to access data files that were
created in the non-UCS environment.

UCS programs cannot access files that contain Fieldata characters. You must convert
such files to a data format accepted by UCS; for example, ASCII.

UCS also does not support the following older formats of file types:
• PCIOS ISAM
• LION
• CFH
• FORMxx
• FORTRAN V
• ANSI-68 COBOL

If these older formats or Fieldata characters do exist, a site has two choices:
• Continue to maintain the existing programs and data as they are (that is, non-UCS)
• Upgrade programs and data to UCS, using the following method:
− Convert files by coding a non-UCS program that reads the data in from the old
file and writes it to a new file whose type is compatible with UCS.

Determine whether or not to upgrade to UCS by weighing the benefits of upgrading

the programs and data to UCS against the amount of effort upgrading will take. Keep
in mind that non-UCS programs can still use the existing data files as they always
have. Also, these non-UCS programs can coexist with UCS programs. Therefore,
continue to use non-UCS programs and make long term plans to upgrade these
programs and data to UCS, as it becomes advantageous or necessary.

8–36 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.3.12. Upgrading Applications That Use DPS 2200

UCS programs can use the Display Processing System (DPS 2200) in either demand or
transaction processing environments. For complete information on DPS 2200, refer to
the following documents:
• DPS 2200 Run-time Programming Reference Manual
• DPS 2200 Form Design Programming Guide
• DPS 2200 Administration Guide

The following are considerations when upgrading non-UCS DPS 2200 programs to UCS
DPS 2200 programs.

8.3.12.1.Forms
Predefined forms defined for non-UCS programs can be used by UCS programs
without change.

UCS COBOL provides the additional facility of storing the predefined forms procs in
the Unisys Repository Manager (UREP).

8.3.12.2. Coding
No changes are required in the coding of DPS 2200 programs.

8.3.12.3. Compiling
Programs being upgraded to UCS FORTRAN require no special compiler keyword
options for compilation.

Programs being upgraded to UCS COBOL require the COMPAT/FULL and the NO-
OPTIM keyword options if both of the following are true:
• Predefined forms are being used.
• Procs for the predefined forms were generated using SB3 or older software.

Programs being upgraded to UCS COBOL require the COMPAT keyword option if both
of the following are true:
• Predefined ASCII-COBOL-format forms are being used.
• Procs for the predefined forms were generated using SB4 software. You can use
the COMPAT/FULL keyword option instead if it is required by other interface
products used in the program.

Programs being upgraded to UCS COBOL require no special compiler keyword options
for compilation if both of the following are true:
• Predefined UCS-COBOL-format forms are being used (SB5R2 software or later).
• DPS procs for UCS COBOL are being used.

7831 4077–009 8–37

Planning for Use of UCS in New and Existing Applications

8.3.12.4. Linking
If a UCS program that accesses DPS 2200 is using dynamic linking or static linking and
the system default DPS 2200 software, nothing special is required before execution of
this program.

However, if alternate DPS 2200 software is being used, you must identify the DPS
2200 software belonging to the correct application group, before dynamically or
statically linking the UCS program. To do so, you must
1. Build a special library search chain.
2. Identify the library search chain by means of an @USE statement, before the
dynamic linking or static linking.

See 4.5 for information on this process.

When statically linking, you can use the following INCLUDE command instead of using
a special library search chain to identify the alternate DPS 2200 software:
INCLUDE qual*dpsfile.UCS/INTERFACE,.EMCBEP$$DPS

8.3.13. Upgrading TIP and HVTIP Transactions

TIP and HVTIP transactions execute under an 2200 operating system that fully
supports UCS. As with most existing non-UCS programs, non-UCS transactions
coexist with UCS transactions and continue to execute normally.

This subsection describes differences between coding, compiling, linking, and setting
up the following:
• UCS TIP and HVTIP transactions
• Non-UCS TIP and HVTIP transactions

For a detailed description with numerous examples, see Sections 5 and 6.

For complete information on Transaction Processing, refer to the following

documents:
• Transaction Processing Planning and Configuration Guide
• Transaction Processing Administration and Operations Reference Manual
• Transaction Processing Programming Guide

8.3.13.1. Coding
DPS 2200
DPS 2200 is fully supported for UCS transactions. UCS COBOL, UCS C, and UCS
FORTRAN interfaces to DPS 2200 are available. All upgrading considerations described
in 8.3.12 apply to upgrading non-UCS DPS 2200 transactions to UCS DPS 2200.

UCS DPS 2200 transactions can perform their message buffering by using either
COMPOOL or MCB.

8–38 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

If all of the following are true, DPS 2200 uses MCB message buffering:
• STATUS is set to J in the VALTAB entry.
• The MCB software is available.
• The MCB interface is configured in CMS 1100 for the $$OPEN being used.

In all other cases, DPS 2200 uses COMPOOL message buffering, provided that the
COMPOOL interface is configured in CMS 1100 for the $$OPEN being used.

MCB
The full set of MCB function calls is supported for UCS transactions. These functions
are available from programs written in UCS COBOL, UCS FORTRAN, and UCS C.

There has been a change in the MCB function calls for UCS COBOL and UCS
FORTRAN. Two optional parameters have been added:
• The message buffer
• The multiple destination list

This means the call to CLOCTE is no longer required; therefore, the call to the CLOCTE
entry point is not supported in UCS COBOL programs.

The MCB entry point names have changed. The old entry points are not supported by
UCS. Therefore, to upgrade existing non-UCS transactions using MCB functions to
UCS, you must perform some simple recoding of the MCB function calls.

For information on the new entry point names, see the MCB Programming Reference
Manual.

The MCB function definitions and packet definitions for UCS COBOL and UCS
FORTRAN are provided on the MCB release tape and in SYS$LIB*PROC$ in the
elements MCBDEF-UCOB and MCBDEF-UFTN. These definitions are found on the UCS
C release tape in the include file, and can be used by using the following statement:
#include <mcb.h>

COMPOOL Message-Handling Primitives

The COMPOOL message-handling primitives are not supported by UCS. If you are
upgrading an existing transaction that uses these primitives to UCS, you must recode
it, using one of the following:
• MCB functions
• DPS 2200 functions

KONS
KONS is not available to UCS transactions. No replacement is provided by Unisys.

7831 4077–009 8–39

Planning for Use of UCS in New and Existing Applications

Non-Message-Handling Primitives
UCS supports the following non-message-handling primitives:
• CONECT
• DISCON
• COMMIT
• ROLLBACK
• TIMABS
• TIMDEL
• TIMREL
• TIMUPA
• TIMUPR
• UOPAND
• UOPGET
• UOPTOR
• FCSS

The coding of these primitives has not changed. New names have been provided for
the UCS COBOL primitives in order to match the FORTRAN names. The older COBOL
names are still supported by UCS COBOL.

UDS Interfaces
The guidelines discussed in 8.3.9 describe the steps needed to upgrade the UDS
interfaces in UCS transactions.

Coding HVTIP ICPs and Subprograms

Designate UCS COBOL HVTIP subprograms in either of the following ways:
• By using the USING clause in the PROCEDURE DIVISION statement
• By using the compilation keyword option SUBPROGRAM

Designate UCS FORTRAN subprograms by coding the SUBROUTINE or FUNCTION

statement in the transaction.

8–40 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Locating HVTIP Subprograms with MASM Routines

Both UCS and non-UCS HVTIP transactions require MASM routines in order to locate
subprograms. This is one of the uses of extended mode MASM by the user that is
documented and supported by Unisys.

If you choose to upgrade to UCS using an existing MASM routine, you must recode it
to match the UCS format and the use of extended mode MASM.

However, complete examples of the required routines are provided in Section 6 to

guide you in their creation.

HVTIP Restrictions Lifted by UCS Software

See 8.4 for information regarding coding restrictions for HVTIP transactions that are
removed by UCS.

8.3.13.2. Compiling
For information on the compiling requirements for DPS 2200 programs, see 8.3.12. For
information on the compiling requirements for programs accessing UDS databases,
see 8.3.9. These same guidelines apply to UCS transactions.

When compiling UCS FORTRAN or UCS C transactions coded with MCB functions, no
special keyword options are required.

UCS COBOL transactions require the COMPAT keyword option if the ASCII COBOL
USAGE clauses are used in the transactions. You can use the COMPAT/FULL keyword
option instead if it is required by other interface products used in the program.

UCS COBOL HVTIP subprograms that do not employ the USING clause in the
PROCEDURE DIVISION require the SUBPROGRAM keyword option on the @UCOB
statement.

8.3.13.3. Linking
UCS transactions must be completely resolved, statically linked ZOOMs. You cannot
use dynamic linking or partial static linking to link a UCS transaction. For details on
functional and performance linking, see Sections 5 and 6.

8.3.13.4. Setup
TIP transactions require the use of SUPUR files. TIP online files cannot be used by UCS
transactions. To indicate the use of SUPUR files, you must set the STF parameter in
the VALTAB entry to zero (STF,0).

HVTIP transaction VALTAB entries remain the same. HVTIP libraries and the TPUR
utility are still used.

7831 4077–009 8–41

Planning for Use of UCS in New and Existing Applications

8.3.14. Handling TIP Files

UCS transactions can access files conforming to all three UDS database models, just
as UCS programs can access the following files:
• DMS 2200 hierarchical and network database files
• RDMS 2200 relational database files
• SFS 2200 conventional database files

See 8.3.9 for details on accessing these files. UCS transactions can also access PCIOS
files, as long as security level requirements are met and the files contain no Fieldata
characters.

UCS also continues to support TIP FCSS files. The functions available to access these
files are the same as in non-UCS programming.

UCS transactions can access FCSS files defined in the non-UCS environment, as long
as they contain no Fieldata characters.

8–42 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.4. HVTIP Restrictions Lifted by UCS

UCS software has lifted several restrictions that existed for HVTIP programming. This
subsection describes the new capabilities that are available.

8.4.1. UCS FORTRAN and HVTIP

Users of ASCII FORTRAN and HVTIP will encounter fewer restrictions on the use of
the FORTRAN language when upgrading programs to UCS FORTRAN and HVTIP. ASCII
FORTRAN HVTIP cannot use any language feature that involves a library routine that
contains statically initialized data. These ASCII FORTRAN restrictions do not apply to
use of UCS FORTRAN with HVTIP.

8.4.2. DPS 2200, HVTIP, and UCS

In non-UCS HVTIP programming, ICPs and subprograms coded using DPS 2200 are not
allowed to use the HVTIP transfer interface to transfer to other subprograms. This
restriction is lifted when using UCS.

(In UCS, the HVTIP transfer interface has been renamed transfer-with-cancel.)

7831 4077–009 8–43

Planning for Use of UCS in New and Existing Applications

8.5. Preparation for Sites Without UCS Applications

The following changes can be made to upgrade existing programs and transactions
while still in a non-UCS environment:
• Remove archaic syntax to bring source programs into conformance with the latest
language standards. This is syntax that the non-UCS compilers support but that is
not being carried forward to UCS. This syntax is usually one of the following:
− Syntax that the language standard no longer supports
− Syntax that is a language extension that is not being carried forward into UCS
Note that until your programs are actually upgraded to UCS, they cannot take
advantage of the new features of the current language standards.
The necessary changes are documented in the programming reference manuals
for ASCII COBOL, UCS COBOL, ASCII FORTRAN, and UCS FORTRAN. Also, you can
use the ASCII COBOL flagging compiler as a tool to identify the code that must
change to conform to the COBOL ’85 standard.
• Remove Fieldata characters from data and program files.
• Convert older data and program files to formats accepted by UCS.
• Upgrade interface software to levels that support both UCS and non-UCS
programs. For example:
− Move DMS level 8 database applications to DMS.
− Consider moving transactions to DPS 2200 and MCB to decrease future
conversion efforts.
• Investigate ways to eliminate MASM code from programs that are scheduled to
be upgraded to UCS.

Table 8–7 describes non-UCS programming tools that aid the upgrade of code, files,
and data to formats acceptable to UCS.

8–44 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Table 8–7. Tools to Aid Upgrading

Tool Description

ASCII COBOL Flagging The ASCII COBOL Flagging Compiler flags all syntax that
Compiler is not in the COBOL 1974 standard. It also flags all new
COBOL 1985 reserved words that need changing in the
program before upgrading. Compiling a COBOL
program with the flagging compiler indicates the extent
of conversion that is necessary. See the ASCII COBOL
Programming Reference Manual.

To prepare for UCS, make such changes when

• Installing new levels of software
• Conducting routine program maintenance on non-UCS programs

These preparations ensure that an organization will have the easiest transition to UCS.

7831 4077–009 8–45

Planning for Use of UCS in New and Existing Applications

8.6. Checklists for Upgrading Existing ASCII

COBOL Applications to UCS
Use the checklists in this section as a guide when upgrading:
• ASCII COBOL DMS applications to UCS COBOL DMS
• ASCII COBOL DPS transaction programs to UCS COBOL (non-HVTIP)
• ASCII COBOL MCB transaction programs to UCS COBOL (non-HVTIP)

8.6.1. Upgrading ASCII COBOL DMS Applications to UCS

COBOL DMS
This subsection discusses tasks you will need to perform when upgrading ASCII
COBOL DMS applications to UCS COBOL DMS. These tasks include
• Review related documentation
• Set up software
• Verify schema code
• Define subschema
• Update DML program code
• Compile DML program
• Use UCS repository
• Link DML program
• Create transaction program VALTAB
• Perform UCS DMS database procedure

Check off the required tasks in this subsection.

8.6.1.1. Review Related Documentation

The following is a list of the related documentation that you should review:
• UCS Evaluation Overview
• Application Development Solutions Application Development Programming
Guide
• COBOL Compiler Programming Reference Manual, Volume 2
• DMS CDML Operations and Programming Reference Manual

8–46 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.6.1.2. Set Up Software

The following is a list of things you should do to set up the software:
• Ensure that all installed OS 2200 software is from the same System Base (SB)
release.
• Verify the following OS 2200 generation parameters:
− Set EXPRGENVIRON to TRUE.
− Set up REPROG statements for the DIAGDUMP facility.
• Install the following UCS products:
− Operating System Group (OSG) software, including UCS Runtime System,
Linking System, SLIB, and ELMS
− Language Support System (LSS) software (UCS Support System)
− UCS COBOL
− PADS (optional)

If using the standard UDS and DMS release tapes:

• Verify that the Operating System Group (OSG) software is installed.
• Install UDS and DMS release tapes.

If building DMS for specific application groups:

• Verify that the Operating System Group (OSG) software is installed.
• Check that the Linking System processor is set to SYS$LIB$*LINK in the DMS
generation.
• Identify the BDI for UDS$DMRSHELL in CHG documents for the CBEP$$DMS and
DMSSHELL-BDI/OM elements. (These CHG documents should be used in the UDS
DMS generation.)

If using MCB, build and install MCB so that it supports UCS:

• Verify that the Operating System Group (OSG) software is installed.
• Set EXTENDEDMODE to YES.
• Set EMMCBBDI to the BDI of the EMMCB common bank.
If using DPS from the standard release tape:
• Verify that the Operating System Group (OSG) software is installed.
• Install the DPS release tape using mode C if SB5R2 or later in order to install the
UCS-COBOL-format DPS system procs.
If building DPS so that it supports UCS:
• Verify that the Operating System Group (OSG) software is installed.
• Place the WITH OBJECT clause on the CO$MASMPROCESSOR statement.

7831 4077–009 8–47

Planning for Use of UCS in New and Existing Applications

If using TIPUTIL, build and install TIPUTIL that supports UCS as follows:
• Verify that the Operating System Group (OSG) software is installed.
• Perform a full generation:
• Answer MCB to communication interface question.
• Answer YES to UCS Programming Environment question.
• For additional SGSs, supply BDI number for the MCBBNK bank.
• Using SOLAR, install TIPUTIL that supports UCS.

8.6.1.3. Verify Schema Code

The following is a list of things you should do to verify schema code:
• Check that the schema has no Fieldata data items.
• Check that the schema does not use the following COBOL ’85 USAGE clauses
(unless the syntax SOURCE IS UCS is included in the schema):
− BINARY
− BINARY-1
• Check that all area names, record names, data item names, set names, and
database data names in the schema are unique. Also, these names must be unique
within the COBOL program.

8.6.1.4. Define Subschema

The following is a list of things you should do to define the subschema:
• Code new subschemas for UCS COBOL programs. The subschema requirements
are:
− New subschema name
− HOST LANGUAGE IS UCS COBOL
− No Fieldata—USAGE COMP-4, USAGE DISPLAY-1
• Process the new subschema for UCS COBOL programs. Check the following
options:
− The T option is not allowed on the SDDL processor call.
− The C option is required if subschema is to be used by an HVTIP transaction
program and subschema storage is COMMON.
• Check the SDDL processor output to ensure that S$WORK is an object module.

8.6.1.5. Update DML Program Code

The following is a list of things you should do to update DML program code:
• Change the subschema name in the INVOKE statement of each program to match
the name given to the new UCS COBOL subschemas.
• Review the code for differences between ASCII COBOL and UCS COBOL.

8–48 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

− Use COMPAT compiler keyword option if COMP-1 or COMP-2 items are

included in the subschema.
− Make changes by hand.
• Check that all schema area names, record names, data item names, set names,
and database data names are unique within the COBOL programs.
• If using HVTIP transaction programs and the subschema storage is COMMON
check that the INVOKE statement includes the ENVIRONMENT IS HVTIP clause.

8.6.1.6. Compile DML Program

The following is a list of things you should do to compile a DML program:
• Check that no preprocessing step is performed. (No separate D$WORK element
will exist.)
• Compile the programs using the UCS COBOL processor call:
− Assign subschema file prior to calling the UCS COBOL compiler.
− Place an @USE of the subschema file name on the subschema file prior to
calling the UCS COBOL compiler.
− Use the COMPAT compiler keyword option if COMP-1 or COMP-2 items are
included in the subschema.

If using DPS forms whose WORKING-STORAGE was generated by a level of DPS

earlier than SB4R1, use the following UCS COBOL compiler keyword options:
• COMPAT/FULL (instead of COMPAT)
• NO-OPTIM

If using DPS forms that are invoked from the repository, use the
APPLICATION/application-name UCS COBOL compiler keyword option.

If using TIP primitive procedures:

• Identify files containing procedures.
• Check to see if the COMPAT compiler keyword option is required for any TIP
primitive procedures used.

8.6.1.7. Use UCS Repository

If using the repository cross-reference storage
• Use the following UCS COBOL compiler keyword options:
− APPLICATION/application-name
− UREP-XREP
• Verify that the attribute DMS-LEVEL has the correct value (NONE, PARTIAL, or
COMPLETE).

8.6.1.8. Link DML Program

Use the following lists if you use static linking.

7831 4077–009 8–49

Planning for Use of UCS in New and Existing Applications

• Note: These tasks apply when coding the static linking runstream for batch,
demand, and standard TIP transaction programs. Refer to Section 6 of this
guide (the Application Development Solutions Application Development
Programming Guide) for information on static linking HVTIP transaction
programs.
• Identify one of the following application group search chains:
@USE LINK$PF, SYS$LIB$*APP$n.

where n is the application group number.

Unisys supplied application group search chain:

DPS user-defined search chain that identifies the DPS file and the Unisys
supplied application group search chain:
@USE LINK$PF,SYS$LIB$*APP$nDPS.

where n is the application group number.

• Call the @LINK processor.
• INCLUDE the compiler-produced object modules.
• INCLUDE the SDDL-produced S$WORK object module.
• If using DPS and the search chain does not identify the correct DPS file, INCLUDE
the DPS elements UCS/INTERFACE and EMCBEP$$DPS.
• If executing a performance-oriented static link, exclude PADS using the following
RESOLVE command:
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN

• If executing a debugging-oriented static link, exclude PADs using the following

RESOLVE command:
RESOLVE ALL REFERENCES USING LCN

• Increase the size of URTS$TABLES as follows:

If using RDMS and DPS, increase the size of URTS$TABLES by the total heap
size displayed by the (RDMS) DEBUG DUMP SIZES command and by the size
displayed by DPS HELPER using the following formula:
SET SIZE = SIZE + rdms/dps-helper-size FOR URTS$TABLES

If using RDMS and not using DPS, increase the size of URTS$TABLES by the
total heap size displayed by the (RDMS) DEBUG DUMP SIZES using the
following formula:
SET SIZE = SIZE + rdms-size FOR URTS$TABLES

If using DPS and not using RDMS, increase the size of URTS$TABLES by the
size displayed by DPS HELPER using the following formula:
SET SIZE = SIZE + dps-helper-size FOR URTS$TABLES

• Merge banks and create a ZOOM using the following PROCESS command.

8–50 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

For batch programs:

PROCESS FOR EXTENDED ZOOM

For standard TIP transaction programs:

PROCESS FOR EXTENDED FAST LOAD

• Eliminate definitions that will not be used as entry points using the following
command:
DELETE ALL DEFINITIONS EXCEPT ....

The following list shows you what to do if you are using dynamic linking.

These tasks apply to batch and demand programs only.

• @COPY,A S$WORK to the file from which the program will be executed.
• Identify one of the following application group search chains:

Unisys-supplied application group search chain:
@USE LINK$PF, SYS$LIB$*APP$n.

where n is the application group number

DPS user-defined search chain that identifies the DPS file and the Unisys
supplied application group search chain:
@USE LINK$PF,SYS$LIB$*APP$nDPS.

where n is the application group number.

• Execute the program.

8.6.1.9. Create Transaction Program VALTAB

To create transaction program VALTAB, specify the use of SUPUR files in the VALTAB
entry (STF,0).

8.6.1.10. Convert UCS DMS Database Procedures

To convert UCS DMS database procedures, convert the database procedures to UCS
COBOL after all programs are converted to UCS. ASCII COBOL programs cannot
access a UCS database procedure.

8.6.2. Upgrading ASCII COBOL DPS Transaction Programs to

UCS COBOL (Non-HVTIP)
This subsection discusses tasks you will need to perform when upgrading ASCII
COBOL DPS transaction programs to UCS COBOL (non-HVTIP). These tasks include
• Review related documentation
• Set up software
• Verify schema code (if using DMS)

7831 4077–009 8–51

Planning for Use of UCS in New and Existing Applications

• Define subschema (if using DMS)

• Define form
• Update DPS transaction program code
• Compile DPS transaction program
• Link DPS transaction program
• Create DPS transaction program VALTAB

8.6.2.1. Review Related Documentation

The following is a list of the documents that contain information on upgrading ASCII
COBOL DPS programs to UCS COBOL (Non-HVTIP):
• Application Development Solutions Application Development Programming
Guide
• COBOL Compiler Programming Reference Manual Volume 2
• DPS 2200 Run-Time Programming Reference Manual
• Transaction Processing Programming Reference Manual
• Transaction Processing Administration and Operations Reference Manual

8.6.2.2. Set Up Software

The following list shows how to set up the software:
• Ensure that all installed OS 2200 software is from the same System Base (SB)
release.
• Verify the following OS 2200 generation parameters:

Set EXPRGENVIRON to TRUE.

Set EXPRGENVIRON to TRUE.

Set up REPROG statements for the DIAGDUMP facility.
• Install the following UCS products:

Operating System Group (OSG) software, including UCS Runtime System,
Linking System, SLIB, and ELMS

Language Support System (LSS) software (UCS Support System)

UCS COBOL

PADS (optional)
• Build and install MCB so that it supports UCS as follows:

Verify that the Operating System Group (OSG) is installed.

Set EXTENDEDMODE to YES.

Set EMMCBBDI to the BDI of the EMMCB common bank.
• Build and install TIP DPS so that it supports UCS as follows:

Verify that the Operating System Group (OSG) is installed.

8–52 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Place the WITH OBJECT clause on the CO$MASMPROCESSOR statement.

If DPS is level SB5R2 or later, install with mode C to install the
UCS-COBOL-format DPS system procs.
• Build and install TIPUTIL so that it supports UCS as follows:

Verify that the Operating System Group (OSG) is installed.

Perform a full generation:
o Answer YES to communication interface question.
o Answer YES to UCS Programming Environment question.
o For additional SGSs, supply BDI number for the MCBBNK bank.

Using SOLAR, install TIPUTIL that supports UCS.

If using UDS and DMS from the standard UDS and DMS release tapes
• Verify that the Operating System Group (OSG) software is installed.
• Install UDS and DMS release tapes.

If building DMS specific application groups:

• Verify that the Operating System Group (OSG) software is installed.
• Check that the Linking System processor is set to SYS$LIB$*LINK in the DMS
generation.
• Identify the BDI for UDS$DMRSHELL in CHG documents for the CBEP$$DMS and
DMSSHELL-BDI/OM elements. These CHG documents should be used in the DMS
generation.

8.6.2.3. Verify Schema Code (if using DMS)

The following list shows what to do to verify the scheme code:
• Check that the schema has no Fieldata data items.
• Check that the schema does not use the following COBOL ’85 USAGE clauses.
These are not allowed in the schema definitions unless the schema contains the
syntax SOURCE IS UCS:

BINARY

BINARY-1
• Check that all area names, record names, data item names, set names, and
database data names in the schema are unique. Also, these names must be unique
within the COBOL program.

8.6.2.4. Define Subschema (if using DMS)

The following list shows what to do to define the subschema:
• Code new subschemas for UCS COBOL programs. The subschema requirements
are

New subschema name

7831 4077–009 8–53

Planning for Use of UCS in New and Existing Applications

HOST LANGUAGE IS UCS COBOL

No Fieldata—USAGE COMP-4, USAGE DISPLAY-1
• Process the new subschema for UCS COBOL programs. Check the following
options:

The F option is no longer required on the SDDL processor call

The T option is not allowed on the SDDL processor call
• Check the SDDL processor output to ensure that S$WORK is an object module.

8.6.2.5. Define Form

Generate the form WORKING-STORAGE using DPS (SB4 level).

8.6.2.6. Update DPS Transaction Program Code

The following list shows what to do to update the DPS transaction program code:
• Review the code for differences between ASCII COBOL and UCS COBOL:

Use COMPAT compiler keyword option.

Make changes by hand.
• If using DMS

Change the subschema name in the INVOKE statement of each program to
match the name given to the new UCS COBOL subschemas.

Check that all schema area names, record names, data item names, set
names, and database data names are unique within the COBOL programs.

8.6.2.7. Compile DPS Transaction Program

The following list shows what to do to compile DPS transaction programs:
• If using UCS-COBOL-format forms and UCS-COBOL-format DPS system procs
(DPS SB5R2 or later software) no special compilation keyword options are
required.
• If using ASCII-COBOL-format forms whose WORKING-STORAGE was generated
using an SB4R1 or later level of DPS or using ASCII-COBOL-format DPS system
procs, use the UCS COBOL compiler COMPAT keyword option.
• If using forms whose WORKING-STORAGE was generated using a level of DPS
prior to SB4R1, use the following UCS COBOL compiler keyword options:

COMPAT/FULL

NO-OPTIM
• If using DPS forms that are invoked from the repository, use the UCS COBOL
compiler APPLICATION/application-name keyword option.
• If using TIP primitive procedures

Identify file(s) containing procedures.

8–54 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

Check to see if the COMPAT compiler keyword option is required for any TIP
primitive procedures used.
• If using DMS

Check that no preprocessing step is performed. (No separate D$WORK
element may exist.)

Compile the programs using the UCS COBOL processor call:
o Assign subschema file prior to calling the UCS COBOL compiler.
o Place an @USE of the subschema file name on the subschema file prior to
calling the UCS COBOL compiler.
o Use COMPAT compiler keyword option (if using COMP-1 or COMP-2
items).
• If using DMS and the repository cross-reference storage

Use the following UCS COBOL compiler keyword options:
o APPLICATION/application-name
o UREP-XREP

Verify that the attribute DMS-LEVEL has the correct value (NONE, PARTIAL, or
COMPLETE.)

8.6.2.8. Link DPS Transaction Program

To link DPS transaction programs, identify one of the following application group
search chains:
• For a user-defined search chain that identifies the DPS file and the application
group search chain supplied by Unisys, use the following:
@USE LINK$PF,SYS$LIB$*APP$nDPS.

where n is the application group number

• For an application group search chain supplied by Unisys, enter:
@USE LINK$PF, SYS$LIB$*APP$n.

where n is the application group number.

• Call the @LINK processor.
• INCLUDE the compiler-produced object modules.
• If the search chain does not identify the correct DPS file, INCLUDE the following
DPS elements:

UCS/INTERFACE

EMCBEP$$DPS

If using DMS
• INCLUDE the SDDL-produced S$WORK object module.

7831 4077–009 8–55

Planning for Use of UCS in New and Existing Applications

• Resolve the library references using the following RESOLVE command (for a
performance-oriented static link), which also excludes PADS:
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN

Increase the size of URTS$TABLES as follows:

• If using RDMS, increase the size of URTS$TABLES by the total heap size displayed
by the (RDMS) DEBUG DUMP SIZES command and by the size displayed by DPS
HELPER using the following formula:
SET SIZE = SIZE + rdms/dps-helper-size FOR URTS$TABLES

• If not using RDMS

Increase the size of URTS$TABLES by the size displayed by DPS HELPER using
the following formula:
SET SIZE = SIZE + dps-helper-size FOR URTS$TABLES

Merge banks and create a FAST LOAD ZOOM using the following PROCESS
command:
PROCESS FOR EXTENDED FAST LOAD

Eliminate definitions that will not be used as entry points using the following
command:
DELETE ALL DEFINITIONS EXCEPT ....

8.6.2.9. Create DPS Transaction Program VALTAB

To create DPS transaction program VALTAB, specify the use of SUPUR files in the
VALTAB entry (STF,0).

8.6.3. Upgrading ASCII COBOL MCB Transaction Programs to

UCS COBOL (Non-HVTIP)
This subsection discusses tasks you will need to perform when upgrading ASCII
COBOL MCB transaction programs to UCS COBOL (non-HVTIP). These tasks include
• Review related documentation
• Set up software
• Verify schema code (if using DMS)
• Define subschema (if using DMS)
• Define form
• Update MCB transaction program code
• Compile MCB transaction program
• Link MCB transaction program
• Create MCB transaction program VALTAB

8–56 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

8.6.3.1. Review Related Documentation

The following list shows the related documentation for upgrading ASCII COBOL MCB
transaction programs to UCS COBOL:
• Application Development Solutions Application Development Programming
Guide
• COBOL Compiler Programming Reference Manual Volume 2
• Message Control Bank (MCB) Programming Reference Manual
• Transaction Processing Programming Reference Manual
• Transaction Processing Administration and Operations Reference Manual

8.6.3.2. Set Up Software

The following list shows you the procedures for setting up the software:
• Ensure that all installed OS 2200 software is from the same System Base (SB)
release.
• Verify the following OS 2200 generation parameters:

Set EXPRGENVIRON set to TRUE.

Set up REPROG statements for the DIAGDUMP facility.
• Install the following UCS Products:

Operating System Group (OSG) software, including UCS Runtime System,
Linking System, SLIB, and ELMS

Language Support System (LSS) software (UCS Support System)

UCS COBOL

PADS (optional)
• Build and install MCB so that it supports UCS as follows:

Set EXTENDEDMODE to YES.

Set EMMCBBDI to the BDI of the EMMCB common bank.
• Build and install TIPUTIL so that it supports UCS as follows:

Verify that the Operating System Group (OSG) software is installed.

Perform a full generation:
o Answer MCB to communication interface question.
o Answer YES to UCS Programming Environment question.
o For additional SGSs, supply BDI number for the MCBBNK bank.
• Using SOLAR, install TIPUTIL that supports UCS.

7831 4077–009 8–57

Planning for Use of UCS in New and Existing Applications

If using UDS and DMS

• If using the standard UDS and DMS release tapes

Verify that the Operating System Group (OSG) software is installed.

Install UDS and DMS release tapes.
• If building DMS for specific application groups

Verify that the Operating System Group (OSG) software is installed.

Check that the Linking System processor is set to SYS$LIB$*LINK in the DMS
generation.

Identify the BDI for UDS$DMRSHELL in CHG documents for the CBEP$$DMS
and DMSSHELL-BDI/OM elements. (These CHG documents should be used in
the DMS generation.)

8.6.3.3. Verify Schema Code (If Using DMS)

The following list shows how to verify schema code:
• Check that the schema has no Fieldata data items.
• Check that the schema does not use the following COBOL ’85 USAGE clauses.
Note that these USAGEs are allowed (for DMS level 17R1 and later) if the SOURCE
IS UCS syntax is included in the schema:

BINARY

BINARY-1
• Check that all area names, record names, data item names, set names, and
database data names in the schema are unique. Also, these names must be unique
within the COBOL program.

8.6.3.4. Define Subschema (If Using DMS)

The following list shows how to define the subschema:
• Code new subschemas for UCS COBOL programs. The subschema requirements
are

New subschema name

HOST LANGUAGE IS UCS COBOL

No Fieldata—USAGE COMP-4, USAGE DISPLAY-1
• Process the new subschema for UCS COBOL programs. Check the following
options:

The F option is no longer required on the SDDL processor call.

The T option is not allowed on the SDDL processor call.
• Check the SDDL processor output to ensure that S$WORK is an object module.

8.6.3.5. Update MCB Transaction Program Code

The following list shows how to update MCB transaction program code:

8–58 7831 4077–009

 Planning for Use of UCS in New and Existing Applications

• Change the MCB function call entry point name from CMCB to MCB$ENT.
• Eliminate all calls to CLOCTE.
• Add the message buffer and/or multidestination list parameter to the appropriate
MCB function calls.
• Review the code for differences between ASCII COBOL and UCS COBOL.

Use COMPAT compiler keyword option.

Make changes by hand.

If using DMS
• Change the subschema name in the INVOKE statement of each program to match
the name given to the new UCS COBOL subschemas.
• Check that all schema area names, record names, data item names, set names,
and database data names are unique within the COBOL programs.

8.6.3.6. Compile MCB Transaction Program

The following list shows how to compile MCB transaction programs:
• Identify the location of the MCB packet procedure.
• If using TIP primitive procedures

Identify files containing procedures.

Check to see if the COMPAT compiler keyword option is required for any TIP
primitive procedures used.
• If using DMS

Check that no preprocessing step is performed. No separate D$WORK
element will exist.

Compile the programs using the UCS COBOL processor call:
o Assign subschema file prior to calling the UCS COBOL compiler.
o Place an @USE of the subschema file name on the subschema file prior to
calling the UCS COBOL compiler.
o Use COMPAT compiler keyword option.
• If using DMS and the repository cross-reference storage

Use the following UCS COBOL compiler keyword options:
o APPLICATION/application-name
o UREP-XREP

Verify that the attribute DMS-LEVEL has the correct value (NONE, PARTIAL, or
COMPLETE).

8.6.3.7. Link MCB Transaction Program

The following list shows how to link MCB transaction programs:
• Identify the application group search chain supplied by Unisys by entering

7831 4077–009 8–59

Planning for Use of UCS in New and Existing Applications

@USE LINK$PF,SYS$LIB$*APP$n.

where n is the application group number

• Call the @LINK processor.
• INCLUDE the compiler-produced object modules.
• If using DMS, INCLUDE the SDDL-produced S$WORK object module.
• Resolve the library references using one of the following RESOLVE commands:

For a performance-oriented static link, PADS should be excluded using the
following command:
RESOLVE ALL REFERENCES USING SYS$LIB$*EMOMRTS.,LCN

For a debugging-oriented static link, PADS should be included using the

following command:
RESOLVE ALL REFERENCES USING LCN

• If using RDMS

Increase the size of URTS$TABLES to include the total heap size displayed by
the (RDMS) DEBUG DUMP SIZES command using the following formula:
SET SIZE = SIZE + rdms-size FOR URTS$TABLES

Merge banks and create a FAST LOAD ZOOM using the following PROCESS
command:
PROCESS FOR EXTENDED FAST LOAD

Eliminate definitions that will not be used as entry points using the following
command:
DELETE ALL DEFINITIONS EXCEPT ...

8.6.3.8. Create MCB Transaction Program VALTAB

To create MCB transaction program VALTAB, specify the use of SUPUR files in the
VALTAB entry (STF,0).

8–60 7831 4077–009

Section 9
Shared Subsystems in a Transaction
Environment

Shared subsystems allow access to code that exists outside of the TIP/HVTIP
transaction environment. (See the Linking System Subsystem Programming Guide
for detailed information on shared subsystems.) Code and selected data in a
subsystem can be application-level, meaning that it can be used concurrently by other
runs on the system. Access to code in the shared subsystem is supplied by gate
definitions and intercept routines supplied in a library that is installed with the
subsystem.

Shared subsystems can have local (unshared) data. If they have no local data, all code
and data are at application level and access is through fixed gates. (Calls to entry
points in the subsystem are resolved to fixed-gate constant definitions, much in the
same way that CBEP-type EQUs are used to resolve access to common banks in basic
mode.) These subsystems may be either chameleon or protected, and access to the
subsystem is simple and efficient.

There are three subsystem types that can have local unshared static data:
• Object module split chameleon fixed-gate subsystems
The subsystem creator must split the local data from the code using Y option
static links and make the local data object modules available to users in a library
file.

• Self-contained subsystems
These can be either chameleon or protected subsystems. Code and data may
exist in any combination of application, program, and activity levels. Access to
code in the subsystem is through intercept routines generated by SSDP when it
processes the SSDEF for the subsystem.

• Fast-load self-contained subsystems (FLSS)

These are chameleon subsystems with all code at application level. Data may
exist in any combination of application, program, and activity levels. Access to
code in the subsystem is through intercept routines generated by SSDP when it
processes the SSDEF for the subsystem.

7831 4077–009 9–1

Shared Subsystems in a Transaction Environment

9.1. Object Module Split Fixed-Gate Subsystems

The advantage of the object module split fixed-gate subsystem is speed. The local
data is linked with the caller and loaded when the caller’s data is loaded. The
disadvantage is flexibility. If the subsystem code is changed, all callers of the
subsystem must relink with the new data object modules from the object module split
link. If they do not relink, there might be a code and data mismatch and program
failure might occur.

9.2. Self-Contained Subsystems

The advantage of the self-contained subsystem is flexibility. You can tailor the code
and data in the subsystem in almost any way you want. If the subsystem changes,
users do not have to relink. The disadvantage is speed. When the Linking System is
invoked to load the local data in the subsystem
• Link-mode linker execution is single-thread. When the linker is loading local
subsystem data for one execution thread, all other execution threads are locked
out from loading their local data for that subsystem until the load is complete.
• The linker performs IO to do the load to system files, subsystem files, and its own
scratch files.
• The linker must perform TERMREG processing when the activity terminates to
clean up its tables kept in application-level storage.
• CREATE_BANK calls are done to acquire storage for the local data. This destroys
the TIP sticking and RESTART when called from a transaction.

Self-contained subsystems should not be used by high-volume transaction programs

(either TIP or HVTIP) unless they
• Are multiple INITAL type transactions (RTPS-type multiple INITAL transactions are
most optimal)
• Only call the subsystem code from infrequently used paths

9–2 7831 4077–009

 Shared Subsystems in a Transaction Environment

9.3. Fast-Load Self-Contained Subsystems

Fast-load self-contained subsystems (FLSS) overcome the efficiency problems of
self-contained subsystems while retaining many of the benefits. The Linking System
is not invoked to load the local unshared data for the subsystem. The URTS
subsystem loader is used to load the local data. (It also loads the local data for HVTIP
ZOOMs.) This means that the load
• Has no IO
• Has no single-thread operation
• Has no linker TERMREG processing at activity termination to do cleanup
• Has no CREATE_BANK calls to get data space if the transaction supplies heap
banks either through VALTAB entries (HVTIP) or from the transaction ZOOM (TIP).

The load is therefore much faster and transaction sticking and RESTART are generally
not inhibited. Subsection 6.1.8 on mixed-mode HVTIP shows and HVTIP program using
an FLSS subsystem. The last portion of Example 6–31 sets up an FLSS subsystem.

FLSS subsystems are really transaction-oriented subsystems, though they can be

called from any execution environment including demand and batch. An object
module in an FLSS subsystem is linked in a similar way to the link of an HVTIP ZOOM.
(A file containing FLSS object modules is the subsystem version of an HVTIP library
containing HVTIP ZOOMs.) The resulting object module structure is also very similar
to an HVTIP ZOOM, with a template in a code bank supplying instructions to the URTS
subsystem loader on how to load the local data. All nonapplication-level noncommon
data is merged into a single segment named FLSS$$DSEG, exactly like the
HVTIP$$DSEG in HVTIP. All nonapplication-level common blocks are left unmerged
and treated as individual segments, just like in HVTIP. The URTS loader dynamically
loads the segments into heap banks, just like it loads the segments from HVTIP
ZOOMs. You can use SET LOWADR statements when linking the FLSS object
modules to get faster nonrelocated loads just like with HVTIP ZOOMs.

If you do not want CREATE_BANK calls to be used to acquire heap banks into which to
load the FLSS segments, then your transaction will have to supply the heap banks. For
TIP transactions, the CREATE_BANK statements in the link of your transaction ZOOM
are all that is needed. For HVTIP transactions, the ICP VALTAB entries must be made
to supply extra banks to the transaction. The static link of the ICP must also designate
some of those banks as pooled banks, opening them up for use as heap banks for
FLSS subsystems. (The OUTPUT HVTIP2 statement must be used in the static link of
the ICP.)

The FLSS subsystem may also choose to use the HVTIP heap banks by having the
following statement in its SSDEF:
SHARE HEAP BANKS WITH OTHER SUBSYSTEMS INCLUDING HVTIP

Table 9–1 describes the differences between an FLSS object module and an HVTIP
ZOOM.

7831 4077–009 9–3

Shared Subsystems in a Transaction Environment

Table 9–1. FLSS Object Module and HVTIP ZOOM Comparison

Topic FLSS Object Module HVTIP ZOOM

Code All application level; can have One code bank (BDI 4)
multiple banks per object loaded by the Exec;
module; can have basic mode contains the user code
code; all loaded by the and the template used in
dynamic linker on the first loading user local data.
reference to the subsystem;
one of the code banks
contains the template used in
loading user local data.
Data Local data is merged into a Local data is merged into
DSEG and multiple common a DSEG and multiple
segments; all data loaded into common segments; all
a heap by the HVTIP loader. data loaded into a heap by
the HVTIP loader.
Can have multiple application There is no application
level extended mode and level data available in an
basic mode banks, which are HVTIP ZOOM.
loaded by the dynamic linker
during the initial load of the
subsystem.
Heaps Uses the HVTIP heaps when Uses the HVTIP heaps as
called from HVTIP. Uses the supplied by the VALTAB
home subsystem heap(s) if entries. CREATE_BANK
they are supplied; otherwise, calls are performed if the
CREATE_BANK calls are VALTAB entries do not
performed. supply the required heap
BDIs.
The HVTIP loader loads The HVTIP loader loads
segments into a different segments into a different
heap bank than they were heap bank than they were
linked for if the desired heap linked for if the desired
is not available. heap is not available.
Intraobject Local common segments are Local common segment
module and shared between all object are shared between all
ZOOM crosstalk modules in a given subsystem HVTIP ZOOMs in an
for a given activity (task). Each execution thread. One
activity gets its own copy of activity is assumed.
common blocks.
Local common may also be
shared with other FLSS
subsystems if desired, and
even with the HVTIP
transaction when called from
HVTIP code. (Default is to not
share local common.)

9–4 7831 4077–009

 Shared Subsystems in a Transaction Environment

Table 9–1. FLSS Object Module and HVTIP ZOOM Comparison

Topic FLSS Object Module HVTIP ZOOM

Other local data for a Other local data for an

subsystem object module is HVTIP ZOOM is
accessible only to that object accessible only to that
module and to the one activity ZOOM and to the one
(task). execution thread.
Application-level data is
accessible to all subsystem
object modules and all
activities/executions.
Code in another object Code in another HVTIP
module in the subsystem is ZOOM is only accessible
generally only accessible through the HV$CALL
through the @SSDP PROC intercepts.
intercepts. (Code that has
application-level latent
parameters can be accessed
directly.)
Callers Can be called from Can only be called from
• Demand or batch an HVTIP ZOOM or an
programs HVTIP absolute (mixed-
mode).
• TIP programs
• HVTIP ZOOMs
• Other subsystems called
from any of the above
An FLSS can be called from
anywhere as long as a UCS
execution environment exists
at the time of the call.
The callers must link with The callers must link with
intercepts generated by the an intercept generated
@SSDP call of the subsystem from an HV$CALL PROC.
definition (SSDEF). Both D-
bank and no-D-bank versions
are available.

7831 4077–009 9–5

Shared Subsystems in a Transaction Environment

Table 9–1. FLSS Object Module and HVTIP ZOOM Comparison

Topic FLSS Object Module HVTIP ZOOM

Entry points Each object module can have One externally visible
as many externally-visible entry point per HVTIP
entry points as desired. No ZOOM is the default. If
jump vector needs to be you want more than one
created. entry, you must
• Create a jump-vector
object module using
the HV$VECTOR
MASM PROC and link
it to the HVTIP ZOOM
• Give each entry point
the correct offset in
the HV$CALL PROC
intercept used to
access the HVTIP
ZOOM.
Relinking Programs calling an FLSS do Programs calling an HVTIP
not have to relink with new ZOOM do not have to
intercepts unless the relink with new intercepts
subsystem owner has (from HV$CALL) unless
changed the gate BDI or the the HVTIP library owner
offsets of any intercepts used has moved any entry
by the program. points the program was
using from one HVTIP
library to another (or has
changed their bank
number).

The preceding table shows that FLSS object modules are much more flexible than
HVTIP ZOOMs, while retaining most of the performance benefits. (You can even have
PADS linked into the subsystem.) This is especially true if you have code bank size
problems with your HVTIP ZOOMs. You may want to move some of your code to
FLSS object modules because of this.

The one disadvantage of FLSS subsystems is replacement capabilities. The HVTIP

ZOOM replacement mechanism is much faster and cleaner than the subsystem
update capabilities. You have to set up your own transaction-hold mechanism to be
able to safely do a live update of an in-use FLSS subsystem (or any subsystem type).

9–6 7831 4077–009

Appendix A
Data Definitions

Table A–1 provides a summary of where data definitions supplied or produced by

Unisys reside for each of the UCS interface products.

Table A–1. Data Definitions Supplied or Produced by Unisys for UCS Interface
Products

UCS UCS COBOL UCS FORTRAN Includes

Interface Procedures UCS C #includes

DMS Subschema file Subschema file

INVOKE
RDMS table Unisys Repository Unisys Repository Unisys Repository
and view
INVOKE
SFS file Unisys Repository Unisys Repository Unisys Repository
INVOKE
PCIOS file Unisys Repository Unisys Repository Unisys Repository
INVOKE
MCB SYS$LIB$*PROC$., SYS$LIB$*PROC$., MCB #include <mcb.h>
MCB utility file in the utility file in the element
element MCBDEF– MCBDEF–UFTN
UCOB
TIP TIP$*TIPLIB$.USYSDF, TIP$*TIPLIB$.USYSDF, #include <tip.h>
Primitives TIP$*TIPLIB$.UCMPDF TIP$*TIPLIB$.UCMPDF
DPS system SYS$LIB$*PROC$., DPS SYS$LIB$*PROC$., DPS #include
procs installation file installation file <dps–proc–def.h>
dps_proc is the
appropriate DPS proc
name

7831 4077–009 A–1

Data Definitions

A–2 7831 4077–009

Index

sizes line, 2-7

A batch/demand programming
CALL identifier example, 7-16
A SHARED FILE, 3-162 coding, 3-4
ACTIVE$APP, library search chain, 4-9 coding DMS 2200, 3-66, 5-72
activity local stack, initial size, 5-221 coexistence of UCS and non UCS, 8-11
APP$n, library search chain, 4-8 compilation, 3-6
application groups compiling DMS 2200 programs, 3-67, 5-73
ACTIVE$APP library search chain, 4-9 DMS 2200
APP$n library search chain, 4-8 database procedures, 3-53
description of, 4-1 introduction to, 3-50, 5-51
dynamically linking to, 4-5 schemas, 3-51, 5-51
files into which they are installed, 4-8 subschemas, 3-54, 5-53
for DPS 2200, 3-213, 8-38 DPS 2200
library search chains in coding, 3-210
SYS$LIB$*APP$n.SSDEF$, 4-11 compiling, 3-211
linking overview, 4-2 dynamic linking, 3-214
specifying use of library search chains example of execution of
for, 4-12 program, 3-222, 3-225, 3-232
statically linking to, 4-6 execution of compilation runstream
system defined library search chains example, 3-221
for, 4-8 form definition example, 3-193
APPLICATION keyword option, 3-113, introduction to, 3-191
5-114 introduction to example, 3-216
applications, definition of, 1-32 linking, 3-213
ASCII COBOL source program example, 3-217
CLOCTE call, 5-7, 6-12 static linking, 3-214
flagging compiler for conversion, 8-44 support history, 3-192
upgrading existing applications to working storage definition
UCS, 8-46 example, 3-199
upgrading to UCS, 8-17, 8-19 DPS 2200 with UDS
ASCII FORTRAN example of execution of
differences with UCS FORTRAN, 8-21 program, 5-203
upgrading to UCS, 8-19 runstream for, 5-195
A-SHARED-FILE, 5-161 source program example, 5-185
automatic program storage, for ALS, 3-258 examples
embedded SQL program, 5-121
execution of runstream for DMS
B 2200, 5-94
execution of runstream for interpreted
SQL program, 3-155
banks
introduction to, 3-26, 3-33, 3-57, 3-74,
described in @LINK output, 3-23
3-86, 3-169, 5-56, 5-78, 5-97,
groups, 3-23
5-165
parts, 3-23

7831 4077–009 Index–1

Index

introduction to defining SFS files and HVTIP ZOOM example

storage areas, 3-160, 5-156 execution of runstream for, 7-63
introduction to RDMS 2200, 3-120 execution of transactions, 7-72
runstream for SFS, 5-173 HVCALLS element, 7-49
schema, 3-57, 5-57 ICP listing, 7-43
introduction to, 3-1 jump vector element, 7-54
linking MCBPKT UCOB listing, 7-45
development dynamic linking, 3-9 runstream for, 7-57
development static linking, 3-15 subprogram listing, 7-52, 7-55
introduction to, 3-9 standard ZOOM example
mixed dynamic and static, 3-12 execution of runstream for, 7-25
linking DMS 2200 programs runstream for, 7-23
dynamic, 3-71 subprogram listing, 7-21
finding S$WORK, 3-70 steps in process, 7-4
introduction to, 3-69, 5-75 TIP ZOOM example
static, 3-72, 5-76 execution of runstream for, 7-38
multiple database models execution of transactions, 7-40
execution of runstream for, 3-188 main program listing, 7-29
introduction to begin, 3-178 runstream for, 7-35
RDMS 2200 subprogram listings, 7-33
batch/demand programming, with standard object modules, 7-2
introduction to, 3-83 with ZOOMs, 7-4
coding, 3-94, 5-112 call interface (HV$CALL), 6-21, 6-22
columns vs. program variables, 3-111 CALL MCB$ENT, 5-6, 6-11
dynamic linking, 3-116 CALL RSA$INIT, 6-186
linking introduction, 3-115, 5-118 calling programs in other languages, 1-6
RDMS 2200 tables, 3-84, 5-95 CANCEL statement, COBOL, 6-29, 6-36, 6-40
static linking, 3-117 checklist, for upgrading ASCII COBOL DMS
SFS 2200 applications to UCS, 8-46
coding, 3-162, 5-161 CLEAR keyword option, HVTIP execution
compiling, 3-163, 5-162 time performance, 6-194
defining files and storage areas, 3-157, CLOCTE, 5-7, 6-12
5-154 COBOL, batch/demand performance, 3-253
executing programs, 3-167 coding
introduction to, 3-156, 5-153 batch/demand
linking, 3-163, 5-163 DMS 2200, 3-66, 5-72
bound object modules, 1-21, 3-14 programs, 3-4
DMS 2200
HVTIP, 6-183
C requirements, 8-33
DPS 2200, 3-210, 8-37
C storage, 6-6 HVTIP, 6-4
Call identifier RDMS 2200
definition of, 7-1 columns vs program variables, 3-111
HVTIP ZOOM example embedded SQL, 3-94, 5-112
introduction to, 7-41 HVTIP, 6-186
standard ZOOM example interpreted SQL, 3-109
introduction to, 7-16 requirements, 8-34
TIP ZOOM example SFS 2200, 3-162, 5-161, 8-35
introduction to, 7-28 TIP, 5-2
CALL identifier TIP and HVTIP, 8-38
DECLARE directives for, 7-9 with UCS, overview, 1-5
coexistence of UCS and non UCS

Index–2 7831 4077–009

 Index

batch and demand mode, 8-11 CONVERT keyword option, 8-21

introduction to, 8-2 CONVERT/PROC keyword option, 8-21
software and file sharing COPY statements, 3-6
DPS 2200, 8-9
FCSS files, 8-10
introduction to, 8-3 D
MCB, 8-8
PCIOS, 8-5 D$DEF routines, 3-191
TIPUTILs, 8-7 D$WORK, 3-67, 3-68, 5-73, 5-74
UDS, 8-5 Data Management System (DMS 2200)
SX 1100, 8-14 batch/demand programming
TIP and HVTIP, 8-11 database procedures, 3-53
coexistence of UCS and non<>UCS introduction to, 3-50, 5-51
overview of, 1-31 schemas, 3-51, 5-51
columns, RDMS 2200 data types, 3-111 subschemas, 3-54, 5-53
common block banks, indexing, 6-218 coding batch/demand, 3-66, 5-72
COMPAT keyword option coding requirements, 8-33
for batch/demand DML, 3-68, 5-74 coding, compiling, linking requirements
for DMS 2200, 8-33 for HVTIP, 6-182
for DPS 2200, 8-37 compiling in batch/demand, 3-67, 5-73
for SFS 2200, 3-163, 5-163, 8-35 compiling requirements, 8-33
for UCS FORTRAN, 8-21 description of, 3-46
compilation examples
batch/demand execution of runstream for
description of, 3-6 batch/demand, 5-94
DMS 2200, 3-67, 5-73 introduction to, 3-57, 3-74, 5-56, 5-78
compiler call format, 2-1 schema, 3-57, 5-57
compiler calls, 1-7 linking in batch/demand
DMS 2200 requirements, 8-33 dynamic, 3-71
DPS 2200 finding S$WORK, 3-70
batch/demand, 3-211 introduction to, 3-69, 5-75
requirements, 8-37 requirements, 8-34
HVTIP, 6-31 static, 3-72, 5-76
listings schemas, 8-32
bank sizes line, 2-7 subschemas, 8-33
Option Listing, 2-6 UCS interface, 5-2, 6-4
overview, 2-5 upgrading applications to UCS, 8-32
sign off line, 2-8 data manipulation language (DML)
sign on line, 2-6 coding batch/demand, 3-66, 5-72
LSS, 1-9 COMPAT keyword option, 8-18
object modules, 1-11 database model program, 3-233
of UCS programs, 2-1 debugging
OMOR, 1-14 dynamic linking, 1-16
options, 2-2 PADS, 1-27
overview of, 1-7 DECLARE directives, for CALL identifier, 7-4,
precedence of options, 2-2 7-9
RDMS 2200 Declare Section, of a COBOL program, 3-96
interpreted SQL, 3-115 define file block, for SFS 2200, 3-158, 3-168,
interpreter SQL, 5-117 5-154
SFS 2200 batch/demand, 3-163, 5-162 Define File Processor (DFP), 3-158, 5-154
TIP, 5-12 DEFINE LSC, 4-2
COMPOOL, 5-8, 8-4, 8-9, 8-12, 8-39 definitions, duplicate, 3-10
conversational links, 8-11

7831 4077–009 Index–3

Index

demand programming transaction processing coding

DPS 2200 with UDS requirements, 8-38
example of execution of UCS
program, 3-246 and non UCS interfaces, 8-4
source program example, 3-235 interface, 5-2, 6-4
performance, improving support for, 3-5
coding, 3-249 upgrading to UCS, 8-37
linking, 3-253 working storage definition example, 3-199
Display Processing System (DPS 2200) DMS 2200, UCS and non UCS interfaces, 8-4
ASCII COBOL transaction programs, DMSICP, description, 6-207
upgrading to UCS (non DOMAIN attribute, for SFS 2200, 3-167
HVTIP), 8-51 DPS 2200 (See also Display Processing
batch/demand example System), 6-4
execution of compilation runstream DPS 2200, transaction processing, 5-3
for, 3-221 DPS HELPER processor, example
execution of program, 3-222, 3-225, output, 6-197
3-232 DPSDMS, description, 5-214
introduction to, 3-216 duplicate definitions, 3-10
source program, 3-217 dynamic ESQL commands
batch/demand example for UDS definition, 3-103
execution of program, 3-246, 5-203 EXECUTE command, 3-103
runstream for, 3-244, 5-195 EXECUTE IMMEDIATE command, 3-104
source program, 5-185 PREPARE command, 3-103
coding types of, 3-103
for HVTIP, 6-9 Dynamic Linker
for TIP, 5-3 description of, 1-15
function calls, 3-210 with bound object modules, 1-21
COMPAT keyword option, 8-19 with standard object modules, 1-20
compilation, 3-211 with ZOOMs, 1-23
compiling requirements, 8-37 dynamic linking
creating library search chains for, 4-6 batch/demand development, 3-9
D$DEF routines, 3-191 DMS 2200 batch/demand, 3-71
dynamic linking, 3-214 DPS 2200 batch/demand, 3-214
form definition example, 3-193 duplicate definitions, 3-10
Form Language Definition for CALL identifier, 7-2
Processor, 3-191 link faults, 1-17
FORMGEN processor, 3-191 link vectors, 3-25
ICP compilation mixed dynamic and static, 3-12
for HVTIP, 6-31 overview of, 1-15
for TIP, 5-12 RDMS 2200 batch/demand, 3-116
introduction to, 3-191 search order for resolving
linking references, 3-17
introduction, 3-213 SFS 2200 batch/demand, 3-164
requirements, 8-38 to application groups, 4-5
to application groups, 3-213 using library search chains, 3-16
PER processor, 3-256
restrictions lifted by UCS, 8-43
software and file sharing, 8-9 E
static linking, 6-197
static linking batch/demand, 3-214 EM$$CODE, 3-23
subprogram compilation for HVTIP, 6-33 EM$$DATA, 3-24
support history, 3-192 EM$$GROUP, 3-23

Index–4 7831 4077–009

 Index

EM$$LINK_VECTOR, 3-25 subprogram listing, 6-66, 6-69

embedded SQL,improving HVTIP execution HVTIP multiple entry points
time performance, 6-191 execution of runstream for, 6-105
error messages, HVTIP, 6-242 execution of transaction, 6-114
examples HVCALLS element, 6-93
batch/demand ICP listing, 6-91
introduction to, 3-26, 3-33, 3-57, 5-56 introduction to, 6-90
schema, 3-57, 5-57 jump vector for, 6-96
batch/demand DMS 2200 runstream for, 6-98
execution of runstream for, 5-94 subprogram listing, 6-94, 6-97
introduction to, 3-74, 5-78 multiple database models
batch/demand DPS 2200 execution of runstream for, 3-188
execution of compilation runstream introduction to begin, 3-178
for, 3-221 three database models, 3-48, 5-50
execution of program, 3-222, 3-225, TIP DPS 2200
3-232 execution of runstream for, 5-24
introduction to, 3-216 ICP listing, 5-18
source program, 3-217 introduction to, 5-17
batch/demand DPS 2200 with UDS runstream for, 5-21
execution of program, 5-203 TIP MCB
runstream for, 5-195 execution of runstream for, 5-43
source program, 5-185 ICP listing, 5-30
batch/demand RDMS 2200 introduction to, 5-29
embedded SQL program, 5-121 MCBPKT UCOB listing, 5-38
execution of runstream for interpreted runstream for, 5-41
SQL program, 3-155 EXECUTE IMMEDIATE, ESQL command
introduction to, 3-86, 3-120, 5-97 definition, 3-104
batch/demand SFS 2200 EXECUTE, ESQL command definition, 3-103
introduction to, 3-160, 3-169, 5-156, executing
5-165 SFS 2200 programs, 3-167
runstream for, 5-173 with console output, 5-218, 6-211
CALL identifier without console output, 5-219, 6-214
HVTIP ZOOM, 7-41 Executive requests (ER), 8-22
introduction to, 7-15 extended mode
standard (batch/demand) ZOOM, 7-16 hardware, 1-34
TIP ZOOM, 7-28 interfaces to other Unisys products, 1-34
DPS 2200 form definition, 3-193 software subsystems, 1-34
HVTIP DPS 2200
execution of runstream for, 6-53
execution of transaction, 6-60 F
HVCALLS element, 6-43, 6-46
ICP listing, 6-42 Fieldata, 3-51, 5-51, 8-4
introduction to, 6-42 File Control Super Structure (FCSS)
runstream for, 6-48 files
subprogram listing, 6-44, 6-47 UCS interface, 5-2, 6-4
HVTIP MCB UCS support, 8-42
execution of runstream for, 6-74 UCS and non UCS interfaces, 8-4
execution of transaction, 6-82 files
HVCALLS element, 6-65, 6-68 access method and organization, 8-5
ICP listing, 6-61 defining SFS 2200, 3-157, 5-154
introduction to, 6-61 in static linking RESOLVE...USING
MCBPKT UCOB listing, 6-63 clause, 3-18
runstream for, 6-70

7831 4077–009 Index–5

Index

upgrading old data formats to UCS, 8-36, MCB, 6-61

8-44 multiple entry points, 6-90
Form Language Definition Processor handling TIP files in UCS, 8-42
(FLDP), 3-191 heap manager, 6-242
FORMGEN processor, 3-191, 3-193 improving execution time
front end processors, 3-6 performance, 6-191
INDEX static linking command, 8-34
introduction to, 6-1
H linking requirements for upgrading to
UCS, 8-41
heap bank, URTS, 3-253, 5-209 multiple entry points
heap manager, HVTIP, 6-242 coding jump vector, 6-86
High Volume Transaction Processing (HVTIP) HVCALLS element for, 6-88
CALL identifier example, 7-41 introduction to, 6-83
coding statically linking, 6-88, 6-89
call interface (HV$CALL), 6-21, 6-22 program units all UCS or all non UCS, 8-12
calling subprograms, 6-20 RDMS 2200
CANCEL statement, 6-29 coding, 6-186
defining storage, 6-6 compiling, 6-188
designating as ICP or subprogram, 6-5 using UDS/TIP files, 6-186
DPS 2200, 6-9 restrictions lifted by UCS, 8-43
HVTIP libraries, 6-19 set up requirements for upgrading to
INITIAL clause, 6-28 UCS, 8-41
ll,bbbb,offset, 6-20 SFS 2200 requirements, 6-189
MCB, 6-11 static linking
MCBDEF UCOB, 6-12 CANCEL, 6-36, 6-40
MCBDEF UFTN, 6-12 for ICP, 6-34
non message handling primitives, 6-13 for subprograms, 6-38
setting up transaction sequence, 6-14 introduction to, 6-33
storage, 6-8 subprogram static link runstream and
transaction codes, 6-14 listing, 6-240
transfer with cancel interface transaction execution, 6-202
(HV$XFR$CANCL), 6-21, 6-25 transfer with cancel interface
VALTAB, 6-14, 6-15 (HV$XFR$CANCL), 8-43
coding for, 6-191 UCS and non UCS interfaces, 8-4
coding requirements for upgrading to upgrading to UCS, 8-38
UCS, 8-38 ZOOM structure, 6-199
coexistence of UCS and non UCS, 8-11 HOME$, 3-17, 3-19
compilation, 6-31 HOST LANGUAGE IS UCS ..., 3-54, 3-66,
compiling requirements for upgrading to 5-53, 5-72, 8-33
UCS, 8-41 HVCALLS elements
creating subschemas with C option, 8-33 definition of, 6-20
DMS 2200 example of, 6-93
coding, 6-183 example of, 6-43, 6-46, 6-65, 6-68, 6-88
compiling, 6-185 for CALL identifier, 7-49
linking, 6-185 runstream to create, 6-23, 6-26
subschemas, 6-183 HVTIP II environment, 6-243
using UDS/TIP files, 6-182 HVTIP Zoom, 6-181
error messages, 6-242 HVTIP$$CODE, description, 6-200
examples HVTIP$$DBANK, setting the size of, 6-227
DPS 2200, 6-42 HVTIP$$ESG, description, 6-202
introduction to, 6-41 HVTIP$$GROUP, 6-200

Index–6 7831 4077–009

 Index

HVTIP$CALLS elements,with CALL L

identifier, 7-10
Language Support System (LSS)
for batch/demand, 3-6
I function of, 1-9
languages, programming, calling programs in
INCLUDE statements, for procs, 3-6 other UCS languages, 1-34
INDEX command, indexing common block letter options, 2-2
banks, 6-218 LIBCODENAME, 3-18
INDEX, static linking command, 6-185, 8-34 libraries
indexing common block banks, 6-218 HVTIP, 6-19
INITIAL clause, COBOL, 5-9, 6-28 TIP, 5-12
initial control programs (ICP) upgrading to UCS, 8-23
compiling, 5-12, 6-31 library search chains
designating, 6-5 $LOCAL, 4-10
performing CANCEL, 6-36 ACTIVE$APP, 4-9
statically linking, 5-14, 6-34 APP$n, 4-8
initial size, of activity local stack, 5-221 created with SSDP, 1-25
interfaces, supported by UCS DEFINE LSC command, 4-2
overview of, 1-6 definition of, 3-16, 4-2
transaction processing, 5-2, 6-4 for application group files, 4-8
interlanguage calls, standard calling for batch/demand DMS 2200, 3-69, 5-75
sequence, 1-5, 1-34 for DPS 2200, 3-213, 3-214, 4-6
INVOKE, 6-184, 8-33 for RDMS 2200, 3-115, 5-118
for SFS 2200, 3-163, 5-163
in static linking RESOLVE commands, 3-18
J in SYS$*DATA$.SSDEF$, 3-16, 4-8
in SYS$LIB$*APP$n.SSDEF$, 4-2, 4-11
jump vector elements overview for application groups, 4-2
CALL identifier, 7-54 resolving references using, 3-16
coding, 6-86 SEARCH command, 4-2
example of, 6-96 specifying use of with @USE
LINK$PF, 4-12
SSDEF$ element name, 3-16
K SSDP, 4-2
system created for application
keyword options groups, 4-8
APPLICATION, 3-113, 5-114 UCS$EMUSER, 4-9, 7-2
CHECK, 3-252 user defined, 3-16
COMPAT, 3-68, 3-163, 5-74, 5-163, 8-21 link faults, 1-17
CONVERT, 8-21 LINK Processor
CONVERT/PROC, 8-21 bound object modules, 1-21
element, 2-4 introduction to, 1-18
for upgrading to UCS COBOL, 8-17 standard object modules, 1-19
introduction to, 2-3 ZOOMs, 1-23
NO OPTIM, 8-19 link vectors, 3-25
NO OPTIONS, 3-7 linking
STD=66, 8-21 batch/demand DMS 2200
TIPMALLOC, 5-211 dynamic, 3-71
KONS, 5-8, 8-39 finding S$WORK, 3-70
introduction to, 3-69, 5-75
static, 3-72, 5-76

7831 4077–009 Index–7

Index

batch/demand performance, 3-253 all COMPOOL or all MCB, 8-12

batch/demand, during development, 3-9 ASCII COBOL transaction programs,
cannot link UCS and non UCS, 8-3 upgrading to UCS (non
compared to collection, 1-15 HVTIP), 8-56
DMS 2200 requirements, 8-34 coding HVTIP programs, 6-11
DPS 2200, 3-213 coding TIP programs, 5-5
dynamic, 1-15 ICP compilation for HVTIP, 6-32
link faults, 1-17 ICP compilation for TIP, 5-13
link vectors, 3-25 MCBDEF UCOB, 5-7, 6-12, 8-39
mixed dynamic and static, 3-12 MCBDEF UFTN, 5-7, 6-12, 8-39
overview of, 1-12 MCBPKT UCOB routine, 7-45
RDMS 2200 software sharing, 8-8
dynamic, 3-116 subprogram compilation for HVTIP, 6-33
introduction to, 5-118 transaction processing coding
static, 3-117 requirements, 8-39
requirements for DPS 2200, 8-38 UCS and non UCS interfaces, 8-4
resolving references using LSCs, 3-16 UCS interface, 5-2, 6-4
search order for resolving UCS support for, 3-5
references, 3-17 with DPS 2200, 8-9
setting size of activity local stack, 3-258 with DPS 2200 HVTIP, 6-10
SFS 2200 with DPS 2200 TIP, 5-5
dynamic, 3-164 messages, 8-11
introduction to, 3-163, 5-163 Meta Assembler (MASM)
static, 3-165, 5-164 eliminating MASM code, 8-44
static linking output, 3-20 for HVCALLS, 6-20
Linking System for locating HVTIP subprograms, 8-41
Dynamic Linker, 1-15 for LSI$RES NAME, 7-4
LINK Processor, 1-18 HVTIP jump vectors, 6-86
OMOR, 1-14 upgrading to UCS, 8-22
overview of, 1-12 mixed dynamic and static linking, 3-12
SSDP, 1-25 mixed mode applications, 8-11
ll,bbbb,offset, 6-20 multibanking, automatic, with UCS, 1-34
LOCAL_DEFS, 3-18 multiple database models, 5-183, 6-190
LOWADR, setting for common block multiple database models begin, 3-178
banks, 6-224
LSI$RES NAME, for CALL identifier, 7-4
N
M NO OPTIM, 8-19
NO OPTIONS, 3-7
main programs
bound object modules, 3-14
designating, 3-8 O
START$, 3-14
malloc space, 5-211 Object Module Output Routines
mcb_ent, 5-6, 6-11, 6-12 (OMOR), 1-14, 3-6
MCBDEF UCOB, 5-7, 6-12, 8-39 object modules
MCBDEF UFTN, 5-7, 6-12, 8-39 as UCS output, 1-11
MCBPKT UCOB, 5-38, 6-63, 7-45 bound, 1-21, 3-14
memory usage, coding for efficiency with standard, 1-19, 7-2
HVTIP, 6-193 supplied by LOCAL_DEFS, 3-18
Message Control Bank (MCB) ZOOMs, 1-23

Index–8 7831 4077–009

 Index

optimizing, restrictions using EXECUTE interpreted SQL, 3-109

command, 3-103 compilation
Options Listing, 2-6 interpreted SQL, 3-115, 5-117
creating work area for, 3-249
description of, 3-46
P HVTIP
coding requirements, 6-186
PADS$EMRTS, 3-24 compiling requirements, 6-188
pass off messages, 8-12 linking requirements, 6-188
per Structure (FCSS) files, file sharing, 8-10 improving HVTIP performance
performance, improving, execution, 6-191
batch/demand, 3-249 introduction to batch/demand, 3-83
precedence of compiler options, 2-2 linking
PREPARE, ESQL command definition, 3-103 dynamic, 3-116
primitives, transaction processing, 5-8, 6-13, introduction to, 3-115, 5-118
8-40 static, 3-117
Processor Common Input/Output System performance suggestion, 3-249
(PCIOS) RDMSLOAD, 5-95
file access methods, 8-5 RDMUTL, 3-84, 5-95
software and file sharing, 8-5 setting work area for, 6-186
UCS and non UCS interfaces, 8-4 storage areas, 3-84, 5-95
UCS interface, 5-2, 6-4 tables, 3-84, 5-95
UCS support for, 3-5 UCS and non UCS interfaces, 8-4
upgrading to UCS, 8-36 UCS interface, 5-2, 6-4
procs, used for compilation, 3-6, 5-12, 6-31 upgrading applications to UCS, 8-34
Program Callable FURPUR, UCS support work area size for, 3-250
for, 3-6 releasing subprogram storage, 6-178
Programmers Advanced Debugging System RESOLVE command, static linking, 3-18
(PADS) resolving references using LSCs, 3-16
banks shown in @LINK output, 3-23 RFORM, 3-162, 5-161
batch/demand performance, 3-253 RSA$INIT,improving HVTIP execution time
overview of, 1-27 performance, 6-191
programming, batch/demand, 3-253 rsa_init, 3-249, 6-187

R S

RDMS 2200, static linking, 5-211 S$PROC, 3-55, 3-68, 5-54, 5-74
RDMSLOAD, 5-95 S$WORK, 3-55, 3-70, 3-71, 3-72, 5-54, 5-76
RDMUTL, 3-84, 5-95 schemas
RDT$FILE, 3-113, 5-114 batch/demand, 3-51, 5-51
references, resolving using LSCs, 3-16 example, 3-57, 5-57
Relational Data Management System (RDMS HVTIP, 6-182
2200) sharing by UCS and non UCS, 8-32
batch/demand examples, 3-120 TIP, 5-55
embedded SQL program, 5-121 SDD$$GROUP, 3-23
execution of runstream for interpreted SEARCH, 4-2
SQL program, 3-155 search order for resolving references, 3-17
introduction to, 3-86, 3-120 setting the size of HVTIP$$DBANK, 6-227
coding Shared File System (SFS 2200)
columns vs. program variables, 3-111 batch/demand examples, 3-169, 5-156,
embedded SQL, 3-94, 5-112 5-165

7831 4077–009 Index–9

Index

introduction to, 3-160, 3-169, 5-156, RESOLVE command USING clause, 3-18
5-165 search order for resolving
runstream for, 5-173 references, 3-18
coding batch/demand, 3-162, 5-161 SFS 2200 batch/demand, 3-165, 5-164
compiling batch/demand, 3-163, 5-162 TIP, 5-14
defining files and storage areas, 3-157, to application groups, 4-6
5-154 using library search chains, 3-16
description of, 3-46 with DPS 2200, 6-197
executing batch/demand programs, 3-167 with RDMS, improving HVTIP execution
file access methods, 8-5 time, 6-196
HVTIP coding, compiling, linking static linking, with RDMS 2200, 5-211
requirements, 6-189 STD=66 keyword option, 8-21
introduction to batch/demand, 3-156, storage areas
5-153 DMS 2200 HVTIP, 6-182
linking DMS 2200 TIP, 5-56
dynamic, 3-164 RDMS 2200, 3-84, 5-95
introduction to, 3-163, 5-163 SFS 2200, 3-157, 5-154
static, 3-165, 5-164 storage, HVTIP, 6-8
supported file access methods, 3-156, local, 6-7
5-153 passing parameters, 6-7
UCS and non UCS interfaces, 8-4 shared, 6-6
UCS interface, 5-2, 6-4 static and automatic, 6-8
UCS support for, 3-5 SUBPROGRAM keyword option, 3-8
upgrading applications to UCS, 8-35 subprogram storage, releasing, 6-178
sign off line, 2-8 subprograms
sign on line, 2-6 calling HVTIP, 6-20
Sort/Merge compiling, 5-12, 6-31
UCS and non UCS interfaces, 8-4 designating in HVTIP, 6-5
UCS support for, 3-5 HVTIP static linking, 6-38
space optimization, HVTIP, 6-205 performing CANCEL, 6-40
SQL, embedded, UCS interface only, 8-4 SUBPROGRAM keyword option, 3-8
SQL, interpreted, UCS and non UCS subschemas
interfaces, 8-4 batch/demand, 3-54, 5-53
SSDEF$, 3-16 during compilation, 3-67, 5-73
standard calling sequence, 1-5, 1-6, 1-34 HVTIP, 6-183
standard object modules, 1-19, 7-2 sharing by UCS and non UCS, 8-33
standards supported by UCS languages, 1-5 Subsystem Definition Processor
START$, 3-14 creating library search chains, 3-16, 4-2
static data base design, improving HVTIP DEFINE LSC command, 4-2
performance, 6-191 description of, 1-25
static linking SEARCH command, 4-2
batch/demand development, 3-15 subsystems
compared to dynamic linking, 1-16 extended mode, providing system
DMS 2200 batch/demand, 3-72, 5-76 security, 1-34
DPS 2200 batch/demand, 3-214 produced by SSDP, 1-25
HVTIP, 6-33 upgrading common banks, 8-31
HVTIP multiple entry points, 6-88, 6-89 SX 1100, 8-14, 8-21
LINK Processor, 1-18 syntax converter, for COBOL, 8-44
link vectors, 3-25 syntax parsing, restrictions using EXECUTE
mixed dynamic and static, 3-12 command, 3-103
object module types, 1-19 SYS$*DATA$.SSDEF$, 1-25, 3-16, 3-17, 4-3,
output, 3-20 4-8
RDMS 2200 batch/demand, 3-117 SYS$LIB$*APP$n.SSDEF$, 4-2, 4-11

Index–10 7831 4077–009

 Index

T introduction, 5-1
static linking
for ICP, 5-14
tables, RDMS 2200, 3-84, 5-95
introduction to, 5-14
THREAD commands, multiple database
Transaction Processing (TIP)
models, 3-178, 5-183, 6-190
FCSS files, available to UCS and non
TIP
UCS, 8-4
(See also Transaction processing), 5-1
primitives available to UCS and non UCS
malloc space, 5-211
programs, 8-4
TIPMALLOC, 5-211
UCS and non UCS interfaces, 8-4
TIPUTILs, 8-7
transaction sequences, 5-10, 6-14
transaction codes, 6-14
transfer with cancel
transaction processing
example, 6-178
CALL identifier example, 7-28
releasing subprogram storage, 6-178
coding requirements for upgrading to
transfer with cancel interface
UCS, 8-38
(HV$XFR$CANCL), 6-21, 6-25
coexistence of UCS and non UCS, 8-11
restrictions lifted, 8-43
compiling requirements for upgrading to
UCS, 8-41
FCSS files, 8-10
handling TIP files in UCS, 8-42 U
KONS, 8-39
linking requirements for upgrading to UCS C
UCS, 8-41 coexistence with SX 1100, 8-14
must be ZOOMs, 1-23 designating main or subprograms, 3-8,
non message handling primitives 6-5
supported, 8-40 equivalent RDMS 2200 data types, 3-111
set up requirements for upgrading to file access method and organization, 8-5
UCS, 8-41 interfaces supported, 1-6
TIPUTILs, 8-7 interpreted SQL, 3-109
upgrading to UCS, 8-38 supported standard, 1-6
Transaction processing syntax for MCB call, 5-6, 6-12
basic information, 5-1 upgrading to, 8-21
coding using DFP to define SFS 2200 files, 3-158,
#include mcb.h, 5-7 5-154
DPS 2200, 5-3 UCS COBOL
INITIAL clause, 5-9 CALL identifier, 7-1
MCB, 5-5 CANCEL statement, HVTIP, 6-29, 6-36,
MCBDEF UCOB, 5-7 6-40
MCBDEF UFTN, 5-7 designating main or subprograms, 3-8,
non message handling primitives, 5-8 6-5
setting up transaction sequence, 5-10 embedded SQL, 3-94, 5-112
TIP libraries, 5-12 equivalent RDMS 2200 data types, 3-111
VALTAB, 5-10 file access method and organization, 8-5
compilation, 5-12 INITIAL clause, HVTIP, 6-28
DPS 2200, 5-3 INITIAL clause, TIP, 5-9
examples interfaces supported, 1-6
DPS 2200, 5-17 interpreted SQL, 3-109
introduction to, 5-17 MCBPKT UCOB routine, 7-45
MCB, 5-29 syntax for MCB call, 5-6, 6-11
general rules, 5-3 syntax for SFS 2200, 3-162, 5-161
generic example, 5-2 unsupported USAGE clauses, 3-51, 5-52
interface languages, (table), 5-2 upgrading to, 8-17

7831 4077–009 Index–11

Index

UCS FORTRAN ASCII COBOL applications, 8-46

COMPAT keyword option, 8-21 circumstances for, 8-3, 8-15
CONVERT keyword option, 8-21 common banks, 8-31
CONVERT/PROC keyword option, 8-21 DMS 2200, 8-32
designating main or subprograms, 3-8, DPS 2200, 8-37
6-5 handling TIP files, 8-42
equivalent RDMS 2200 data types, 3-111 introduction to, 8-15
file access method and organization, 8-5 MASM, 8-22
HVTIP restrictions lifted, 8-43 non UCS languages, 8-22
interfaces supported, 1-6 old data file formats, 8-36
interpreted SQL, 3-109 overview of, 1-31
STD=66 keyword option, 8-21 PCIOS, 8-36
supported standard, 1-6 RDMS 2200, 8-34
syntax for MCB call, 6-11 SFS 2200, 8-35
syntax for SFS 2200, 3-162, 5-161 steps of, 8-15
upgrading to, 8-19 TIP and HVTIP, 8-38
UCS$EMUSER, 4-9, 7-2 UCS C, 8-21
Unisys Repository Manager (UREP) UCS COBOL, 8-17
for RDMS 2200, 3-84, 3-95, 5-95 UCS FORTRAN, 8-19
for SFS 2200, 3-157, 5-154 user libraries, 8-23
UCS interface only, 8-4 URTS
UCS support for, 3-5 object module, 5-209
Universal Compiling System URTS :, 3-253
applications, 1-32 URTS$TABLES
calling programs in other languages, 1-6 operation, 3-253, 5-209
cannot link UCS and non UCS, 8-3 USAGE clauses, 3-51, 3-55, 5-52, 5-55
coexistence of UCS and non UCS, 8-2 user defined library search chains, 3-16
compilation overview, 1-7 USING clause, RESOLVE command, 3-18
developing user applications, 1-31
DPS 2200 with, 3-191
HVTIP restrictions lifted by UCS, 8-43 V
implementing new applications, 8-2
interfaces supported, 1-6 VALTAB, 6-10, 6-14
linking overview, 1-12 variables, compared to RDMS 2200 data
object modules, 1-11 types, 3-111
PADS, 1-27
preparing for, 8-44
standard calling sequence, 1-5, 1-34 W
summary of, 1-29
UDS interfaces, 3-46, 5-49
working storage, DPS 2200 example, 3-199
upgrading software to (See upgrading
software to UCS), 8-15
Universal Data System (UDS)
coding, compiling, linking
Z
batch/demand, 3-46, 5-48
interfaces supported by UDS, 3-46, 5-49 zero overhead object modules (ZOOM)
multiple database models, 5-183, 6-190 batch/demand performance, 3-253
multiple database models begin, 3-178 description of, 1-23
software and file sharing, 8-5 for CALL identifier
three database examples, 3-48, 5-50 DECLARE directives for, 7-9
upgrading applications to UCS, 8-32 HVTIP ZOOM example, 7-41
with HVTIP, 6-182 introduction to, 7-4
upgrading software to UCS LSI$RES NAME element for, 7-6

Index–12 7831 4077–009

 Index

standard ZOOM example, 7-16 @LINK, 1-18, 3-20

TIP ZOOM example, 7-28 @UC, 1-7
recommended for production @UCOB, 1-7
programs, 3-15 @UFTN, 1-7
transaction processing, 1-23 @USE LINK$PF
zoom, HVTIP, 6-181 for application groups, 4-12
for batch/demand DMS 2200, 3-69, 5-75
for DMS 2200 programs, 8-34
Special Characters for DPS 2200, 3-214
for ordinary object modules, 3-16
for RDMS 2200, 3-115, 5-118
$LOCAL, library search chain, 4-10
for SFS 2200, 3-163, 5-163
search order, 3-17

7831 4077–009 Index–13

Index

Index–14 7831 4077–009

.
© 2013 Unisys Corporation.
All rights reserved.

*78314077-009*
7831 4077–009