ILE Concepts

AS/400e
ILE Concepts
V ersion 4
SC41-5606-03
AS/400e
ILE Concepts
V ersion 4
SC41-5606-03
Note Before using this information and the product it supports, be sure to read the information in Appendix D. Notices.
Fourth Edition (May 1999) This edition applies to version 4, release 4, modication 0 of the Licensed program IBM Operating System/400 (Program 5769-SS1) and to all subsequent releases and modications until otherwise indicated in new editions. This edition applies only to reduced instruction set computer (RISC) systems. This edition replaces SC41-5606-02. Copyright International Business Machines Corporation 1997, 1999. All rights reserved. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
About ILE Concepts (SC41-5606) . Who should read this book . . . . AS/400 Operations Navigator . . . Installing Operations Navigator. . Prerequisite and related information . How to send your comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix ix ix x x xi
Chapter 1. Integrated Language Environment Introduction What Is ILE? . . . . . . . . . . . . . . . . . . What Are the Benets of ILE? . . . . . . . . . . . . Binding . . . . . . . . . . . . . . . . . . . Modularity . . . . . . . . . . . . . . . . . . Reusable Components. . . . . . . . . . . . . . Common Run-Time Services . . . . . . . . . . . Coexistence with Existing Applications . . . . . . . . Source Debugger . . . . . . . . . . . . . . . Better Control over Resources . . . . . . . . . . . Better Control over Language Interactions . . . . . . Better Code Optimization . . . . . . . . . . . . . Better Environment for C . . . . . . . . . . . . . Foundation for the Future . . . . . . . . . . . . What Is the History of ILE? . . . . . . . . . . . . . Original Program Model Description . . . . . . . . . Extended Program Model Description . . . . . . . . Integrated Language Environment Description . . . . . Chapter 2. ILE Basic Concepts . Structure of an ILE Program . . Procedure . . . . . . . . . Module Object . . . . . . . . ILE Program . . . . . . . . Service Program . . . . . . . Binding Directory . . . . . . . Binder Functions . . . . . . . Calls to Programs and Procedures Dynamic Program Calls . . . Static Procedure Calls . . . . Activation . . . . . . . . . Error Handling . . . . . . . . Optimizing Translator . . . . . Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1 . 1 . 1 . 1 . 1 . 2 . 2 . 3 . 3 . 3 . 4 . 6 . 6 . 6 . 6 . 7 . 8 . 10 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 12 13 16 18 19 21 21 22 23 24 25 26 27 27 28 29 30 31 32 34 36 36 37
Chapter 3. ILE Advanced Concepts . . . . . . Program Activation . . . . . . . . . . . . . Program Activation Creation. . . . . . . . . Activation Group . . . . . . . . . . . . . . Activation Group Creation . . . . . . . . . Default Activation Groups. . . . . . . . . . ILE Activation Group Deletion . . . . . . . . Service Program Activation . . . . . . . . . . Control Boundaries . . . . . . . . . . . . . Control Boundaries for ILE Activation Groups . . Control Boundaries for the OPM Default Activation
Copyright IBM Corp. 1997, 1999
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Group .
iii
Control Boundary Use . . . . . . . . . Error Handling . . . . . . . . . . . . . Job Message Queues . . . . . . . . . Exception Messages and How They Are Sent How Exception Messages Are Handled . . Exception Recovery. . . . . . . . . . Default Actions for Unhandled Exceptions. . Types of Exception Handlers . . . . . . ILE Conditions. . . . . . . . . . . . Data Management Scoping Rules . . . . . Call-Level Scoping . . . . . . . . . . Activation-Group-Level Scoping . . . . . Job-Level Scoping . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38 39 39 40 40 41 41 43 45 46 46 47 48 51 51 52 53 53 53 54 54 55 60 60 61 63 64 65 66 67 68 77 79 79 79 80 80 80 83 83 84 86 86 86 86 89 89 89 90 91 91 91 93
Chapter 4. Program Creation Concepts. . . . . . . . . Create Program and Create Service Program Commands. . . Use Adopted Authority (QUSEADPAUT) . . . . . . . . Symbol Resolution . . . . . . . . . . . . . . . . . Resolved and Unresolved Imports . . . . . . . . . . Binding by Copy . . . . . . . . . . . . . . . . . Binding by Reference . . . . . . . . . . . . . . . Binding Large Numbers of Modules . . . . . . . . . . Importance of the Order of Exports . . . . . . . . . . Program Access . . . . . . . . . . . . . . . . . . Program Entry Procedure Module Parameter on the CRTPGM Export Parameter on the CRTSRVPGM Command . . . . Import and Export Concepts. . . . . . . . . . . . . . Binder Language . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . . . . . Start Program Export and End Program Export Commands . Export Symbol Command . . . . . . . . . . . . . Binder Language Examples . . . . . . . . . . . . . Program Updates . . . . . . . . . . . . . . . . . Parameters on the UPDPGM and UPDSRVPGM Commands Module Replaced by a Module with Fewer Imports . . . . Module Replaced by a Module with More Imports . . . . . Module Replaced by a Module with Fewer Exports . . . . Module Replaced by a Module with More Exports. . . . . Tips for Creating Modules, Programs, and Service Programs . Chapter 5. Activation Group Management. . . . Multiple Applications Running in the Same Job . . . Reclaim Resources Command . . . . . . . . . Reclaim Resources Command for OPM Programs Reclaim Resources Command for ILE Programs . Reclaim Activation Group Command . . . . . Service Programs and Activation Groups . . . . . Chapter 6. Calls to Procedures and Programs Call Stack . . . . . . . . . . . . . . Call Stack Example . . . . . . . . . . Calls to Programs and Calls to Procedures . . Static Procedure Calls . . . . . . . . . Procedure Pointer Calls . . . . . . . . Passing Arguments to ILE Procedures . . . Dynamic Program Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
AS/400 ILE Concepts V4R4
Passing Arguments on a Dynamic Program Call . . . . . . Interlanguage Data Compatibility . . . . . . . . . . . . . Syntax for Passing Arguments in Mixed-Language Applications . Operational Descriptors . . . . . . . . . . . . . . . Support for OPM and ILE APIs . . . . . . . . . . . . . Chapter 7. Storage Management . Dynamic Storage. . . . . . . . Heap . . . . . . . . . . . Teraspace . . . . . . . . . Storage Management Bindable APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94 94 94 94 96 99 99 99 102 103 105 105 106 107 107 108 108 109 109 110 111 112 112 115 115 115 115 116 116 116 117 117 118 118 118 118 118 121 121 122 123 124 124
Chapter 8. Exception and Condition Management . . . Handle Cursors and Resume Cursors . . . . . . . . . Exception Handler Actions . . . . . . . . . . . . . How to Resume Processing . . . . . . . . . . . . How to Percolate a Message . . . . . . . . . . . How to Promote a Message. . . . . . . . . . . . Default Actions for Unhandled Exceptions. . . . . . . . Nested Exceptions . . . . . . . . . . . . . . . . Condition Handling . . . . . . . . . . . . . . . . How Conditions Are Represented. . . . . . . . . . Condition Token Testing . . . . . . . . . . . . . Relationship of ILE Conditions to OS/400 Messages. . . OS/400 Messages and the Bindable API Feedback Code . Chapter 9. Debugging Considerations . . . . . Debug Mode . . . . . . . . . . . . . . . Debug Environment . . . . . . . . . . . . Addition of Programs to Debug Mode . . . . . How Observability and Optimization Affect Debugging Observability . . . . . . . . . . . . . . Optimization Levels . . . . . . . . . . . . Debug Data Creation and Removal . . . . . . Module Views . . . . . . . . . . . . . . Debugging across Jobs . . . . . . . . . . OPM and ILE Debugger Support . . . . . . . Watch Support . . . . . . . . . . . . . Unmonitored Exceptions . . . . . . . . . . . National Language Support Restriction for Debugging Chapter 10. Data Management Scoping . . . . Common Data Management Resources . . . . . Commitment Control Scoping . . . . . . . . . Commitment Denitions and Activation Groups . . Ending Commitment Control . . . . . . . . Commitment Control during Activation Group End. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 11. ILE Bindable Application Programming Interfaces . . . . . 127 ILE Bindable APIs Available . . . . . . . . . . . . . . . . . . . . 127 Dynamic Screen Manager Bindable APIs . . . . . . . . . . . . . . . 130 Chapter 12. Advanced Optimization Technique. Types of Proling. . . . . . . . . . . . . How to Prole a Program. . . . . . . . . . Enabling the program to collect proling data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 131 132 132
Contents
Collect Proling Data . . . . . . . . . . . . . . . . . . Applying the Collected Proling Data . . . . . . . . . . . . Managing Programs Enabled to Collect Proling Data . . . . . . . Managing Programs with Proling Data Applied to Them . . . . . . How to Tell if a Program or Module is Proled or Enabled for Collection Chapter 13. Shared Storage Synchronization . Shared Storage . . . . . . . . . . . . . Shared Storage Pitfalls . . . . . . . . . . Shared Storage Access Ordering . . . . . . . Example Problem 1: One Writer, Many Readers Storage Synchronizing Actions . . . . . . . . Example 1 Solution . . . . . . . . . . . Example Problem 2: Two Contending Writers or . . . . . . . . . . . . . . . . . . . . . Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
133 134 135 136 136 139 139 139 140 140 141 142 142
Appendix A. Output Listing from CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM Command . . . . . . . . . . . . . . . . . Binder Listing . . . . . . . . . . . . . . . . . . . . . . . Basic Listing . . . . . . . . . . . . . . . . . . . . . . Extended Listing . . . . . . . . . . . . . . . . . . . . . Full Listing . . . . . . . . . . . . . . . . . . . . . . . Listing for Example Service Program . . . . . . . . . . . . . Binder Language Errors . . . . . . . . . . . . . . . . . . . Signature Padded . . . . . . . . . . . . . . . . . . . . Signature Truncated . . . . . . . . . . . . . . . . . . . Current Export Block Limits Interface . . . . . . . . . . . . . Duplicate Export Block. . . . . . . . . . . . . . . . . . . Duplicate Symbol on Previous Export . . . . . . . . . . . . . Level Checking Cannot Be Disabled More than Once, Ignored . . . . Multiple Current Export Blocks Not Allowed, Previous Assumed. . . . Current Export Block Is Empty . . . . . . . . . . . . . . . . Export Block Not Completed, End-of-File Found before ENDPGMEXP . Export Block Not Started, STRPGMEXP Required . . . . . . . . Export Blocks Cannot Be Nested, ENDPGMEXP Missing . . . . . . Exports Must Exist inside Export Blocks . . . . . . . . . . . . Identical Signatures for Dissimilar Export Blocks, Must Change Exports Multiple Wildcard Matches . . . . . . . . . . . . . . . . . No Current Export Block . . . . . . . . . . . . . . . . . . No Wildcard Matches . . . . . . . . . . . . . . . . . . . Previous Export Block Is Empty . . . . . . . . . . . . . . . Signature Contains Variant Characters . . . . . . . . . . . . . SIGNATURE(*GEN) Required with LVLCHK(*NO). . . . . . . . . Signature Syntax Not Valid . . . . . . . . . . . . . . . . . Symbol Name Required . . . . . . . . . . . . . . . . . . Symbol Not Allowed as Service Program Export . . . . . . . . . Symbol Not Dened. . . . . . . . . . . . . . . . . . . . Syntax Not Valid . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
145 145 145 147 149 151 152 153 153 154 155 155 156 157 157 158 159 159 160 161 161 162 162 163 164 164 165 165 166 167 167
Appendix B. Exceptions in Optimized Programs . . . . . . . . . . . 169 Appendix C. CL Commands Used with ILE Objects CL Commands Used with Modules . . . . . . . CL Commands Used with Program Objects . . . . CL Commands Used with Service Programs. . . . CL Commands Used with Binding Directories . . . CL Command Used with Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 171 171 172 172 172
vi
CL Commands Used with Source Debugger . . . . . . . . . . . . . . 173 CL Commands Used to Edit the Binder Language Source File . . . . . . . 173 Appendix D. Notices . . . . . . . . . . . . . . . . . . . . . . 175 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 179 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Readers Comments Wed Like to Hear from You. . . . . . . . . . 195
Contents
vii
viii
About ILE Concepts (SC41-5606)

This book describes concepts and terminology pertaining to the Integrated Language Environment (ILE) architecture of the OS/400 licensed program. Topics covered include module creation, binding, the running and debugging of programs, and exception handling. The concepts described in this book pertain to all ILE languages. Each ILE language may implement the ILE architecture somewhat differently. To determine exactly how each language enables the concepts described here, refer to the programmers guide for that specic ILE language. This book also describes OS/400 functions that directly pertain to all ILE languages. In particular, common information on binding, message handling, and debugging are explained. This book does not describe migration from an existing AS/400 language to an ILE language. That information is contained in each ILE high-level language (HLL) programmers guide.
Who should read this book

You should read this book if: v You are a software vendor developing applications or software tools v You are experienced in developing mixed-language applications on the AS/400 system v You are not familiar with the AS/400 system but have application programming experience on other systems v Your programs share common procedures, and when you update or enhance those procedures, you have to re-create the programs that use them If you are an AS/400 application programmer who writes primarily in one language, you should read the rst four chapters of this book for a general understanding of ILE and its benets. The programmers guide for that ILE language can then be sufficient for application development.
AS/400 Operations Navigator

AS/400 Operations Navigator is a powerful graphical interface for Windows clients. With AS/400 Operations Navigator, you can manage and administer your AS/400 systems from your Windows desktop. You can use Operations Navigator to manage communications, printing, database, security, and other system operations. Operations Navigator includes Management Central for managing multiple AS/400 systems centrally. Figure 1 on page x shows an example of the Operations Navigator display:
ix
Figure 1. AS/400 Operations Navigator Display
This new interface has been designed to make you more productive and is the only user interface to new, advanced features of OS/400. Therefore, IBM recommends that you use AS/400 Operations Navigator, which has online help to guide you. While this interface is being developed, you may still need to use a traditional emulator such as PC5250 to do some of your tasks.
Installing Operations Navigator

To use AS/400 Operations Navigator, you must have Client Access installed on your Windows PC. For help in connecting your Windows PC to your AS/400 system, consult Client Access Express for Windows - Setup, SC41-5507-00. AS/400 Operations Navigator is a separately installable component of Client Access that contains many subcomponents. If you are installing for the rst time and you use the Typical installation option, the following options are installed by default: v Operations Navigator base support v Basic operations (messages, printer output, and printers) To select the subcomponents that you want to install, select the Custom installation option. (After Operations Navigator has been installed, you can add subcomponents by using Client Access Selective Setup.) 1. Display the list of currently installed subcomponents in the Component Selection window of Custom installation or Selective Setup. 2. Select AS/400 Operations Navigator. 3. Select any additional subcomponents that you want to install and continue with Custom installation or Selective Setup. After you install Client Access, double-click the AS400 Operations Navigator icon on your desktop to access Operations Navigator and create an AS/400 connection.
Prerequisite and related information

Use the AS/400 Information Center as your starting point for looking up AS/400 technical information. You can access the Information Center from the AS/400e Information Center CD-ROM (English version: SK3T-2027) or from one of these Web sites:
http://www.as400.ibm.com/infocenter http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm
The AS/400 Information Center contains important topics such as logical partitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also contains Internet links to Web sites such as the AS/400 Online Library and the AS/400 Technical Studio. Included in the Information Center is a link that describes at a high level the differences in information between the Information Center and the Online Library. For a list of related publications, see the Bibliography.
How to send your comments

Your feedback is important in helping to provide the most accurate and high-quality information. If you have any comments about this book or any other AS/400 documentation, ll out the readers comment form at the back of this book. v If you prefer to send comments by mail, use the readers comment form with the address that is printed on the back. If you are mailing a readers comment form from a country other than the United States, you can give the form to the local IBM branch office or IBM representative for postage-paid mailing. v If v If you prefer to send comments by FAX, use either of the following numbers: United States and Canada: 1-800-937-3430 Other countries: 1-507-253-5192 you prefer to send comments electronically, use one of these e-mail addresses: Comments on books: RCHCLERK@us.ibm.com IBMMAIL, to IBMMAIL(USIB56RZ) Comments on the AS/400 Information Center: RCHINFOC@us.ibm.com Be sure to include the following: v The name of the book. v The publication number of the book. v The page number or topic to which your comment applies.
About ILE Concepts (SC41-5606)
xi
xii
Chapter 1. Integrated Language Environment Introduction

This chapter denes the Integrated Language Environment* (ILE*) model, describes the benets of ILE, and explains how ILE evolved from previous program models. Wherever possible, information is presented from the perspective of an RPG or COBOL programmer and is described in terms of existing AS/400* features.
What Is ILE?
ILE is a new set of tools and associated system support designed to enhance program development on the AS/400 system. The capabilities of this new model can be exploited only by programs produced by the new ILE family of compilers. That family includes ILE RPG/400*, ILE COBOL/400*, ILE C/400*, and ILE CL.
What Are the Benets of ILE?

ILE offers numerous benets over previous program models. Those benets include binding, modularity, reusable components, common run-time services, coexistence, and a source debugger. They also include better control over resources, better control over language interactions, better code optimization, a better environment for C, and a foundation for the future.
Binding
The benet of binding is that it helps reduce the overhead associated with calling programs. Binding the modules together speeds up the call. The previous call mechanism is still available, but there is also a faster alternative. To differentiate between the two types of calls, the previous method is referred to as a dynamic or external program call, and the ILE method is referred to as a static or bound procedure call. The binding capability, together with the resulting improvement in call performance, makes it far more practical to develop applications in a highly modular fashion. An ILE compiler does not produce a program that can be run. Rather, it produces a module object (*MODULE) that can be combined (bound) with other modules to form a single runnable unit; that is, a program object (*PGM). Just as you can call an RPG program from a COBOL program, ILE allows you to bind modules written in different languages. Therefore, it is possible to create a single runnable program that consists of modules written separately in RPG, COBOL, C, and CL.
Modularity
The benets from using a modular approach to application programming include the following: v Faster compile time The smaller the piece of code we compile, the faster the compiler can process it. This benet is particularly important during maintenance, because often only a
line or two needs to be changed. When we change two lines, we may have to recompile 2000 lines. That is hardly an efficient use of resources. If we modularize the code and take advantage of the binding capabilities of ILE, we may need to recompile only 100 or 200 lines. Even with the binding step included, this process is considerably faster. v Simplied maintenance When updating a very large program, it is very difficult to understand exactly what is going on. This is particularly true if the original programmer wrote in a different style from your own. A smaller piece of code tends to represent a single function, and it is far easier to grasp its inner workings. Therefore, the logical ow becomes more obvious, and when you make changes, you are far less likely to introduce unwanted side effects. v Simplied testing Smaller compilation units encourage you to test functions in isolation. This isolation helps to ensure that test coverage is complete; that is, that all possible inputs and logic paths are tested. v Better use of programming resources Modularity lends itself to greater division of labor. When you write large programs, it is difficult (if not impossible) to subdivide the work. Coding all parts of a program may stretch the talents of a junior programmer or waste the skills of a senior programmer. v Easier migrating of code from other platforms Programs written on other platforms, such as UNIX**, are often modular. Those modules can be migrated to the AS/400 system and incorporated into an ILE program.
Reusable Components
ILE allows you to select packages of routines that can be blended into your own programs. Routines written in any ILE language can be used by all AS/400 ILE compiler users. The fact that programmers can write in the language of their choice ensures you the widest possible selection of routines. The same mechanisms that IBM and other vendors use to deliver these packages to you are available for you to use in your own applications. Your installation can develop its own set of standard routines, and do so in any language it chooses. Not only can you use off-the-shelf routines in your own applications. You can also develop routines in the ILE language of your choice and market them to users of any ILE language.
Common Run-Time Services

A selection of off-the-shelf components (bindable APIs) is supplied as part of ILE, ready to be incorporated into your applications. These APIs provide services such as: Date and time manipulation Message handling Math routines Greater control over screen handling Dynamic storage allocation
Over time, additional routines will be added to this set and others will be available from third-party vendors. For further details of the APIs supplied with ILE, see theSystem API Reference .
Coexistence with Existing Applications

ILE programs can coexist with existing OPM programs. ILE programs can call OPM programs and other ILE programs. Similarly, OPM programs can call ILE programs and other OPM programs. Therefore, with careful planning, it is possible to make a gradual transition to ILE.
Source Debugger
The source debugger allows you to debug ILE programs and service programs. For information about the source debugger, see Chapter 9. Debugging Considerations.
Better Control over Resources

Before the introduction of ILE, resources (for example, open les) used by a program could be scoped to (that is, owned by) only: The program that allocated the resources The job In many cases, this restriction forces the application designer to make tradeoffs. ILE offers a third alternative. A portion of the job can own the resource. This alternative is achieved through the use of an ILE construct, the activation group. Under ILE, a resource can be scoped to any of the following: A program An activation group The job
Shared Open Data PathScenario

Shared open data paths (ODPs) are an example of resources you can better control with ILEs new level of scoping. To improve the performance of an application on the AS/400, a programmer decided to use a shared ODP for the customer master le. That le is used by both the Order Entry and the Billing applications. Because a shared ODP is scoped to the job, it is quite possible for one of the applications to inadvertently cause problems for the other. In fact, avoiding such problems requires careful coordination among the developers of the applications. If the applications were purchased from different suppliers, avoiding problems may not even be possible. What kind of problems can arise? Consider the following scenario: 1. The customer master le is keyed on account number and contains records for account numbers A1, A2, B1, C1, C2, D1, D2, and so on.
2. An operator is reviewing the master le records, updating each as required, before requesting the next record. The record currently displayed is for account B1. 3. The telephone rings. Customer D1 wants to place an order. 4. The operator presses the Go to Order Entry function key, processes the order for customer D1, and returns to the master le display. 5. The program still correctly displays the record for B1, but when the operator requests the next record, which record is displayed? If you said D2, you are correct. When the Order Entry application read record D1, the current le position changed because the shared ODP was scoped to the job. Therefore, the request for the next record means the next record after D1. Under ILE, this problem could be prevented by running the master le maintenance in an activation group dedicated to Billing. Likewise, the Order Entry application would run in its own activation group. Each application would still gain the benets of a shared ODP, but each would have its own shared ODP, owned by the relevant activation group. This level of scoping prevents the kind of interference described in this example. Scoping resources to an activation group allows programmers the freedom to develop an application that runs independently from any other applications running in the job. It also reduces the coordination effort required and enhances the ability to write drop-in extensions to existing application packages.
Commitment ControlScenario
The ability to scope a shared open data path (ODP) to the application is useful in the area of commitment control. Assume that you want to use a le under commitment control but that you also need it to use a shared ODP. Without ILE, if one program opens the le under commitment control, all programs in the job have to do so. This is true even if the commitment capability is needed for only one or two programs. One potential problem with this situation is that, if any program in the job issues a commit operation, all updates are committed. The updates are committed even if logically they are not part of the application in question. These problems can be avoided by running each part of the application that requires commitment control in a separate activation group.
Better Control over Language Interactions

Without ILE, the way a program runs on the AS/400 depends on a combination of the following: The language standard (for example, the ANSI standards for COBOL and C) The developer of the compiler This combination can cause problems when you mix languages.
Mixed LanguagesScenario
Without activation groups, which are introduced by ILE, interactions among OPM languages are difficult to predict. ILE activation groups can solve that difficulty.
For example, consider the problems caused by mixing COBOL with other languages. The COBOL language standard includes a concept known as a run unit. A run unit groups programs together so that under certain circumstances they behave as a single entity. This can be a very useful feature. Assume that three ILE COBOL/400 programs (PRGA, PRGB, and PRGC) form a small application in which PRGA calls PRGB, which in turn calls PRGC (see Figure 2). Under the rules of ILE COBOL/400, these three programs are in the same run unit. As a result, if any of them ends, all three programs should be ended and control should return to the caller of PRGA.
ILE COBOL/400 Run Unit PRGA PRGB PRGC
RV3W027-1
Figure 2. Three ILE COBOL/400 Programs in a Run Unit
Suppose that we now introduce an RPG program (RPG1) into the application and that RPG1 is also called by the COBOL program PRGB (see Figure 3). An RPG program expects that its variables, les, and other resources remain intact until the program returns with the last-record (LR) indicator on.
ILE COBOL/400 Run Unit PRGA PRGB PRGC
RPG1
RV3W028-1
Figure 3. Three ILE COBOL/400 Programs and One ILE RPG/400 Program in a Run Unit
However, the fact that program RPG1 is written in RPG does not guarantee that all RPG semantics apply when RPG1 is run as part of the COBOL run unit. If the run unit ends, RPG1 disappears regardless of its LR indicator setting. In many cases, this situation may be exactly what you want. However, if RPG1 is a utility program, perhaps controlling the issue of invoice numbers, this situation is unacceptable. We can prevent this situation by running the RPG program in a separate activation group from the COBOL run unit (see Figure 4 on page 6). An ILE COBOL/400 run unit itself is an activation group.
ILE COBOL/400 Run Unit Activation Group PRGA PRGB PRGC RPG1
RV3W029-1
Figure 4. ILE RPG/400 Program in a Separate Activation Group
For information about the differences between an OPM run unit and an ILE run unit, see the ILE COBOL for AS/400 Programmers Guide.
Better Code Optimization

The ILE translator does many more types of optimization than the original program model (OPM) translator does. Although each compiler does some optimization, the majority of the optimization on the AS/400 is done by the translator. An ILE-enabled compiler does not directly produce a module. First it produces an intermediate form of the module, and then it calls the ILE translator to translate the intermediate code into instructions that can be run.
Better Environment for C

C is a popular language for tool builders. Because of this, a better C language means that more and more of the latest application development tools are migrated to the AS/400. For you, this means a greater choice of: CASE tools Fourth-generation languages (4GLs) Additional programming languages Editors Debuggers
Foundation for the Future

The benets and functions that ILE provides will be even more important in the future. Future ILE compilers will offer signicant enhancements. As we move into object-oriented programming languages and visual programming tools, the need for ILE becomes even more apparent. Increasingly, programming methods rely on a highly modularized approach. Applications are built by combining thousands of small reusable components to form the completed application. If these components cannot transfer control among themselves quickly, the resulting application cannot work.
What Is the History of ILE?

ILE is a stage in the evolution of OS/400* program models. Each stage evolved to meet the changing needs of application programmers.
The programming environment provided when the AS/400 system was rst introduced is called the original program model (OPM). In Version 1 Release 2, the Extended Program Model (EPM) was introduced.
Original Program Model Description

Application developers on the AS/400 enter source code into a source le and compile that source. If the compilation is a success, a program object is created. The set of functions, processes, and rules provided by the OS/400 to create and run a program is known as the original program model (OPM). As an OPM compiler generates the program object, it generates additional code. The additional code initializes program variables and provides any necessary code for special processing that is needed by the particular language. The special processing could include processing any input parameters expected by this program. When a program is to start running, the additional compiler-generated code becomes the starting point (entry point) for the program. A program is typically activated when the OS/400 encounters a call request. At run time, the call to another program is a dynamic program call. The resources needed for a dynamic program call can be signicant. Application developers often design an application to consist of a few large programs that minimize the number of dynamic program calls. Figure 5 illustrates the relationship between OPM and the operating system. As you can see, RPG, COBOL, CL, BASIC, and PL/I all operate in this model. The broken line forming the OPM boundary indicates that OPM is an integral part of OS/400. This integration means that many functions normally provided by the compiler writer are built into the operating system. The resulting standardization of calling conventions allows programs written in one language to freely call those written in another. For example, an application written in RPG typically includes a number of CL programs to issue le overrides, to perform string manipulations, or to send messages.
OS/400 Original Program Model (OPM)
RPG
BASIC
CL
PL/I
COBOL
RV2W976-2
Figure 5. Relationship of OPM to OS/400

Principal Characteristics of OPM

The following list identies the principal characteristics of OPM: v Good for traditional RPG and COBOL programs OPM is ideal for supporting traditional RPG and COBOL programs, that is, relatively large, multifunction programs. v Dynamic binding When program A wants to call program B, it just does so. This dynamic program call is a simple and powerful capability. At run time, the operating system locates program B and ensures that the user has the right to use it. An OPM program has only a single entry point, whereas, each procedure in an ILE program can be an entry point. v Limited data sharing In OPM, an internal procedure has to share variables with the entire program, whereas, in ILE, each procedure can have its own locally scoped variables.
Extended Program Model Description

OPM continues to serve a useful purpose. However, OPM does not provide direct support for procedures as dened in languages like C. A procedure is a set of self-contained high-level language (HLL) statements that performs a particular task and then returns to the caller. Individual languages vary in the way that a procedure is dened. In C, a procedure is called a function. To allow languages that dene procedure calls between compilation units or that dene procedures with local variables to run on an AS/400, OPM was enhanced. These enhancements are called the Extended Program Model (EPM). As shown in Figure 6 on page 9, EPM was created to support languages like Pascal. Along with the base OPM support, EPM provides the ability to call procedures located in other programs. Because EPM uses the functions of OPM, some procedure calls in EPM turn into dynamic calls to the program containing the procedure. Conceptually, the entry point of the called EPM program provides the following functions: Initializes the program variables Calls the identied procedure The system support to help resolve the procedure calls to the appropriate programs is provided by the Set Program Information (SETPGMINF) command. Although EPM is a different programming model from OPM, it is closely tied to OPM. EPM is built as an additional layer above the AS/400 high-level machine interface. Most of the functions associated with OPM also apply to EPM. In the following chapters of this manual, the term OPM means both OPM and EPM. Functions that apply only to EPM are specically qualied with the term EPM.
OS/400 Original Program Model (OPM) Extended Program Model (EPM)
RPG
BASIC
Pascal
CL
PL/I
FORTRAN
COBOL
RV3W103-0
Figure 6. Relationship of OPM and EPM to OS/400
The shaded area around the EPM block indicates that, unlike OPM, EPM is not incorporated into OS/400. Rather, it is a layer on top of the operating system. It provides the additional support required for procedure-based languages.
Principal Characteristics of Procedure-Based Languages

Procedure-based languages have the following characteristics: v Locally scoped variables Locally scoped variables are known only within the procedure that denes them. The equivalent of locally scoped variables is the ability to dene two variables with the same name that refer to two separate pieces of data. For example, the variable COUNT might have a length of 4 digits in subroutine CALCYR and a length of 6 digits in subroutine CALCDAY. Locally scoped variables provide considerable benet when you write subroutines that are intended to be copied into several different programs. Without locally scoped variables, the programmers must use a scheme such as naming variables based on the name of the subroutine. v Automatic variables Automatic variables are created whenever a procedure is entered. Automatic variables are destroyed when the procedure is exited. v External variables External data is one way of sharing data between programs. If program A declares a data item as external, program A is said to export that data item to other programs that want to share that data. Program D can then import the item without programs B and C being involved at all. For more information about imports and exports, see Module Object on page 12. v Multiple entry points COBOL and RPG programs have only a single entry point. In a COBOL program, it is the start of the PROCEDURE DIVISION. In an RPG program, it is the rst-page (1P) output. This is the model that OPM supports.
Procedure-based languages, on the other hand, may have multiple entry points. For example, a C program may consist entirely of subroutines to be used by other programs. These procedures can be exported, along with relevant data if required, for other programs to import. In ILE, programs of this type are known as service programs. They can include modules from any of the ILE languages. Service programs are similar in concept to dynamic link libraries (DLLs) in Windows** or OS/2*. Service programs are discussed in greater detail in Service Program on page 16. v Frequent calls Procedure-based languages are by nature very call intensive. Although EPM provides some functions to minimize the overhead of calls, procedure calls between separately compiled units still have a relatively high overhead. ILE improves this type of call signicantly.
Integrated Language Environment Description

As Figure 7 shows, ILE is tightly integrated into OS/400, just as OPM is. It provides the same type of support for procedure-based languages that EPM does, but it does so far more thoroughly and consistently. Its design provides for the more traditional languages, such as RPG and COBOL, and for future language developments.
OS/400 Original Program Model (OPM)
Extended Program Model (EPM)
Integrated Language Environment (ILE) RPG
RPG
BASIC
Pascal C
CL
PL/I FORTRAN COBOL CL COBOL
RV3W026-1
Figure 7. Relationship of OPM, EPM, and ILE to OS/400
10
Chapter 2. ILE Basic Concepts

Table 1 compares and contrasts the original program model (OPM) and the Integrated Language Environment (ILE) model. This chapter briey explains the similarities and differences listed in the table.
Table 1. Similarities and Differences between OPM and ILE OPM ILE Program Program Service program Compilation results in a runnable program Compilation results in a nonrunnable module object Compile, run Compile, bind, run Run units simulated for each language Activation groups Dynamic program call Dynamic program call Static procedure call Single-language focus Mixed-language focus Language-specic error handling Common error handling Language-specic error handling OPM debuggers Source-level debugger
Structure of an ILE Program

An ILE program contains one or more modules. A module, in turn, contains one or more procedures (see Figure 8).
Program A Module M1
RPG
Module M2
Procedure P1
Procedure P2
RV2W1003-2
Figure 8. Structure of an ILE Program
Procedure
A procedure is a set of self-contained high-level language statements that performs a particular task and then returns to the caller. For example, an ILE C/400 function is an ILE procedure.
11
Module Object
A module object is a nonrunnable object that is the output of an ILE compiler. A module object is represented to the system by the symbol *MODULE. A module object is the basic building block for creating runnable ILE objects. This is a signicant difference between ILE and OPM. The output of an OPM compiler is a runnable program. A module object can consist of one or more procedures and data item specications. It is possible to directly access the procedures or data items in one module from another ILE object. See the ILE HLL programmers guides for details on coding the procedures and data items that can be directly accessed by other ILE objects. ILE RPG/400, ILE COBOL/400, and ILE C/400 all have the following common concepts: v Exports An export is the name of a procedure or data item, coded in a module object, that is available for use by other ILE objects. The export is identied by its name and its associated type, either procedure or data. An export can also be called a denition. v Imports An import is the use of or reference to the name of a procedure or data item not dened in the current module object. The import is identied by its name and its associated type, either procedure or data. An import can also be called a reference. A module object is the basic building block of an ILE runnable object. Therefore, when a module object is created, the following may also be generated: v Debug data Debug data is the data necessary for debugging a running ILE object. This data is optional. v Program entry procedure (PEP) A program entry procedure is the compiler-generated code that is the entry point for an ILE program on a dynamic program call. It is similar to the code provided for the entry point in an OPM program. v User entry procedure (UEP) A user entry procedure, written by a programmer, is the target of the dynamic program call. It is the procedure that gets control from the PEP. The main() function of a C program becomes the UEP of that program in ILE. Figure 9 on page 13 shows a conceptual view of a module object. In this example, module object M1 exports two procedures (Draw_Line and Draw_Arc) and a data item (rtn_code). Module object M1 imports a procedure called Draw_Plot. This particular module object has a PEP, a corresponding UEP (the procedure Draw_Arc), and debug data.
12
Module M1 Program Entry Procedure (PEP) User Entry Procedure (UEP): Draw_Arc
Procedure Draw_Line; Dcl rtn_code EXTRN; CallPrc Draw_Plot;
End Draw_Line;
Procedure Draw_Arc; End Draw_Arc;
Export: Draw_Line (Procedure) Draw_Arc (Procedure) rtn_code (Data) Import: Draw_Plot (Procedure) Debug Data for Module M1
RV3W104-0
Figure 9. Conceptual View of a Module
Characteristics of a *MODULE object: v A *MODULE object is the output from an ILE compiler. v It is the basic building block for ILE runnable objects. v v v v v It It If It It is not a runnable object. may have a PEP dened. a PEP is dened, a UEP is also dened. can export procedure and data item names. can import procedure and data item names.
v It can have debug data dened.
ILE Program
An ILE program shares the following characteristics with an OPM program: v The program gets control through a dynamic program call. v There is only one entry point to the program. v The program is identied to the system by the symbol *PGM. An ILE program has the following characteristics that an OPM program does not have: v An ILE program is created from one or more copied module objects. v One or more of the copied modules can contain a PEP. v You have control over which modules PEP is used as the PEP for the ILE program object.
13
When the Create Program (CRTPGM) command is specied, the ENTMOD parameter allows you to select which module containing a PEP is the programs entry point. A PEP that is associated with a module that is not selected as the entry point for the program is ignored. All other procedures and data items of the module are used as specied. Only the PEP is ignored. When a dynamic program call is made to an ILE program, the modules PEP that was selected at program-creation time is given control. The PEP calls the associated UEP. When an ILE program object is created, only those procedures associated with the copied modules containing debug data can be debugged by the ILE debugger. The debug data does not affect the performance of a running ILE program. Figure 10 on page 15 shows a conceptual view of an ILE program object. When the program PGMEXAMP is called, the PEP of the program, which was dened in the copied module object M3, is given control. The copied module M2 also has a PEP dened, but it is ignored and never used by the program. In this program example, only two modules, M1 and M3, have the necessary data for the new ILE debugger. Procedures from modules M2 and M4 cannot be debugged by using the new ILE debugger. The imported procedures print and SIN are resolved to exported procedures from service programs PRINTS and MATHFUNC, respectively.
14
*PGM (PGMEXAMP) Program Entry Procedure (Use PEP in module M3) User Entry Procedure: (Use P3 in module M3) Module M1 Procedure P1; DCL D EXTRN; CallPrc print; End P1; Debug Data Module M3 PEP UEP: P3
Procedure P3; CallPrc P2; End P3;
Module M2 PEP UEP: P2 Procedure P2; CallPrc P1; CallPrc P4; End P2; Module M4 Procedure P4; DCL X REAL; D=SIN(X); End P4;
Debug Data Internally resolved imports: P1, P2, P4, D Used PEP: Defined in module M3 UEP: Procedure P3 in module M3 Externally resolved imports: print in *LIBL/PRINTS SIN in MATHLIB/MATHFUNC
RV2W980-5
Figure 10. Conceptual View of an ILE Program
Characteristics of an ILE *PGM object: v One or more modules from any ILE language are copied to make the *PGM object. v The person who creates the program has control over which modules PEP becomes the only PEP for the program. v On a dynamic program call, the modules PEP that was selected as the PEP for the program gets control to run. v The UEP associated with the selected PEP is the users entry point for the program. v Procedures and data item names cannot be exported from the program. v Procedures or data item names can be imported from modules and service programs but not from program objects. For information on service programs, see Service Program on page 16. v Modules can have debug data. v A program is a runnable object.
15
Service Program
A service program is a collection of runnable procedures and available data items easily and directly accessible by other ILE programs or service programs. In many respects, a service program is similar to a subroutine library or procedure library. Service programs provide common services that other ILE objects may need; hence the name service program. An example of a set of service programs provided by OS/400 are the run-time procedures for a language. These run-time procedures often include such items as mathematical procedures and common input/output procedures. The public interface of a service program consists of the names of the exported procedures and data items accessible by other ILE objects. Only those items that are exported from the module objects making up a service program are eligible to be exported from a service program. The programmer can specify which procedures or data items can be known to other ILE objects. Therefore, a service program can have hidden or private procedures and data that are not available to any other ILE object. It is possible to update a service program without having to re-create the other ILE programs or service programs that use the updated service program. The programmer making the changes to the service program controls whether the change is compatible with the existing support. The way that ILE provides for you to control compatible changes is by using the binder language. The binder language allows you to dene the list of procedure names and data item names that can be exported. A signature is generated from the names of procedures and data items and from the order in which they are specied in the binder language. To make compatible changes to a service program, new procedure or data item names should be added to the end of the export list. For more information on signatures, the binder language, and protecting your customers investment in your service programs, see Binder Language on page 64. Figure 11 on page 17 shows a conceptual view of a service program. Notice that the modules that make up that service program are the same set of modules that make up ILE program object PGMEXAMP in Figure 10 on page 15. The previous signature, Sigyy, for service program SPGMEXAMP contains the names of procedures P3 and P4. After an upward-compatible change is made to the service program, the current signature, Sigxx, contains not only the names of procedures P3 and P4; it also contains the name of data item D. Other ILE programs or service programs that use procedures P3 or P4 do not have to be re-created. Although the modules in a service program may have PEPs, these PEPs are ignored. The service program itself does not have a PEP. Therefore, unlike a program object, a service program cannot be called dynamically.
16
Public Interface
*SRVPGM (SPGMEXAMP)
P3 P4 D
Module M1 Procedure P1; DCL D EXTRN; CallPrc print; End P1; Debug Data Module M3 PEP UEP: A3
Module M2 PEP UEP: A2 Procedure P2; CallPrc P1; CallPrc P4; End P2; Module M4 Procedure P4; DCL X REAL; D=SIN(X); End P4;
Procedure P3; CallPrc P2; End P3;

Debug Data
Internally resolved imports: P1, P2, P4, D Current Signature = Sigxx Previous Signature = Sigyy Externally resolved imports: print in *LIBL/PRINTS SIN in MATHLIB/MATHFUNC
RV2W981-8
Figure 11. Conceptual View of an ILE Service Program
Characteristics of an ILE *SRVPGM object: v One or more modules from any ILE language are copied to make the *SRVPGM object. v No PEP is associated with the service program. Because there is no PEP, a dynamic program call to a service program is not valid. A modules PEP is ignored. v Other ILE programs or service programs can use the exports of this service program identied by the public interface. v Signatures are generated from the procedure and data item names that are exported from the service program.
17
v Service programs can be replaced without affecting the ILE programs or service programs that use them, as long as previous signatures are still supported. v Modules can have debug data. v A service program is a collection of runnable procedures and data items. v Weak data can be exported only to an activation group. It cannot be made part of the public interface that is exported from the service program. For information about weak data, see Export in Import and Export Concepts on page 63.
Binding Directory
A binding directory contains the names of modules and service programs that you may need when creating an ILE program or service program. Modules or service programs listed in a binding directory are used only if they provide an export that can satisfy any currently unresolved import requests. A binding directory is a system object that is identied to the system by the symbol *BNDDIR. Binding directories are optional. The reasons for using binding directories are convenience and program size. v They offer a convenient method of packaging the modules or service programs that you may need when creating your own ILE program or service program. For example, one binding directory may contain all the modules and service programs that provide math functions. If you want to use some of those functions, you specify only the one binding directory, not each module or service program you use. Note: The more modules or service programs a binding directory contains, the longer it may take to bind the programs. Therefore, you should include only the necessary modules or service programs in your binding directory. v Binding directories can reduce program size because you do not specify modules or service programs that do not get used. Very few restrictions are placed on the entries in a binding directory. The name of a module or service program can be added to a binding directory even if that object does not yet exist. For a list of CL commands used with binding directories, see Appendix C. CL Commands Used with ILE Objects. Figure 12 on page 19 shows a conceptual view of a binding directory.
18
Binding Directory (ABD) Object Name Object Type QALLOC QMATH QFREE QHFREE *SRVPGM *SRVPGM *MODULE *SRVPGM Object Library *LIBL QSYS *LIBL ABC
. . .
. . .
. . .
RV2W982-0
Figure 12. Conceptual View of a Binding Directory
Characteristics of a *BNDDIR object: v Convenient method of grouping the names of service programs and modules that may be needed to create an ILE program or service program. v Because binding directory entries are just names, the objects listed do not have to exist yet on the system. v The only valid library names are *LIBL or a specic library. v The objects in the list are optional. The named objects are used only if any unresolved imports exist and if the named object provides an export to satisfy the unresolved import request.
Binder Functions
The function of the binder is similar to, but somewhat different from, the function provided by a linkage editor. The binder processes import requests for procedure names and data item names from specied modules. The binder then tries to nd matching exports in the specied modules, service programs, and binding directories. In creating an ILE program or service program, the binder performs the following types of binding: v Bind by copy To create the ILE program or service program, the following are copied: The modules specied on the module parameter Any modules selected from the binding directory that provide an export for an unresolved import Physical addresses of the needed procedures and data items used within the copied modules are established when the ILE program or service program is created. For example, in Figure 11 on page 17, procedure P3 in module M3 calls procedure P2 in module M2. The physical address of procedure P2 in module M2 is made known to procedure M3 so that address can be directly accessed. v Bind by reference Symbolic links to the service programs that provide exports for unresolved import requests are saved in the created program or service program. The symbolic
19
links refer to the service programs providing the exports. The links are converted to physical addresses when the program object to which the service program is bound is activated. Figure 11 on page 17 shows an example of a symbolic link to SIN in service program *MATHLIB/MATHFUNC. The symbolic link to SIN is converted to a physical address when the program object to which service program SPGMEXAMP is bound is activated. At run time, with physical links established to the procedures and data items being used, there is little performance difference between the following: v Accessing a local procedure or data item v Accessing a procedure or data item in a different module or service program bound to the same program Figure 13 and Figure 14 on page 21 show conceptual views of how the ILE program PGMEXAMP and service program SPGMEXAMP were created. The binder uses modules M1, M2, M3, and M4 and service programs PRINTS and MATHFUNC to create ILE program PGMEXAMP and service program SPGMEXAMP.
Service Programs Module M1 Module M2 Module M3 Module M4 PRINTS MATHFUNC
CRTPGM PGM(PGMEXAMP) MODULE (M1, M2, M3, M4) ENTMOD(*LIBL/M3) + BNDSRVPGM(*LIBL/PRINTS MATHLIB/MATHFUNC)
Binder
Program PGMEXAMP
RV2W983-3
Figure 13. Creation of an ILE Program. The broken line indicates that the service programs are bound by reference instead of being bound by copy.
20
Service Programs Module M1 Module M2 Module M3 Module M4 PRINTS MATHFUNC
CRTSRVPGM SRVPGM(SPGMEXAMP) MODULE (M1, M2, M3, M4) EXPORT(*SRCFILE) + SRCFILE(*LIBL/QSRVSRC) SRCMBR(*SRVPGM) BNDSRVPGM(*LIBL/PRINTS MATHLIB/MATHFUNC)
Binder
Service Program SPGMEXAMP

RV3W030-1
Figure 14. Creation of a Service Program. The broken line indicates that the service programs are bound by reference instead of being bound by copy.
For additional information on creating an ILE program or service program, see Chapter 4. Program Creation Concepts on page 51.
Calls to Programs and Procedures

In ILE you can call either a program or a procedure. ILE requires that the caller identify whether the target of the call statement is a program or a procedure. ILE languages communicate this requirement by having separate call statements for programs and for procedures. Therefore, when you write your ILE program, you must know whether you are calling a program or a procedure. Each ILE language has unique syntax that allows you to distinguish between a dynamic program call and a static procedure call. The standard call statement in each ILE language defaults to either a dynamic program call or a static procedure call. For RPG and COBOL the default is a dynamic program call, and for C the default is a static procedure call. Thus, the standard language call performs the same type of function in either OPM or ILE. This convention makes migrating from an OPM language to an ILE language relatively easy. The binder can handle a procedure name that is up to 256 characters long. To determine how long your procedure names can be, see your ILE HLL programmers guide.
Dynamic Program Calls

A dynamic program call transfers control to either an ILE program object or an OPM program object. Dynamic program calls include the following: v An OPM program can call another OPM program or an ILE program, but it cannot call a service program.
21
v An ILE program can call an OPM program or another ILE program, but it cannot call a service program. v A service program can call an OPM program or an ILE program, but it cannot call another service program.
Static Procedure Calls

A static procedure call transfers control to an ILE procedure. Static procedure calls can be coded only in ILE languages. A static procedure call can be used to call any of the following: v A procedure within the same module v A procedure in a separate module within the same ILE program or service program v A procedure in a separate ILE service program Figure 15 on page 23 shows examples of static procedure calls. The gure shows that: v A procedure in an ILE program can call an exported procedure in the same program or in a service program. Procedure P1 in program A calls procedure P2 in another copied module. Procedure P3 in program C calls procedure P4 in service program D. v A procedure in a service program can call an exported procedure in the same service program or in another service program. Procedure P6 in service program B calls procedure P7 in another copied module. Procedure P5 in service program E calls procedure P4 in service program F.
22
Program A Module Proc: P1 CallPrc P2 End P1 Module Proc: P2 End P2 Static Procedure Call
Service Program B Module Proc: P6 CallPrc P7 End P6 Module Proc: P7 End P7
Static Procedure Call
Program C Module Proc: P3 CallPrc P4 End P3 Static Procedure Call
Service Program D Module Proc: P4 End P4
Service Program E Module Proc: P5 CallPrc P4 End P5 Static Procedure Call
Service Program F Module Proc: P4 End P4
RV2W993-2
Figure 15. Static Procedure Calls
Activation
After successfully creating an ILE program, you will want to run your code. The process of getting a program or service program ready to run is called activation. You do not have to issue a command to activate a program. Activation is done by the system when a program is called. Because service programs are not called, they are activated during the call to a program that directly or indirectly requires their services. Activation performs the following functions: v Uniquely allocates the static data needed by the program or service program v Changes the symbolic links to service programs providing the exports into links to physical addresses No matter how many jobs are running a program or service program, only one copy of that objects instructions resides in storage. However, each program activation has its own static storage. So even when one program object is used concurrently by many jobs, the static variables are separate for each activation. A program can
23
also be activated in more than one activation group, even within the same job, but activation is local to a particular activation group. If either of the following is true: v Activation cannot nd the needed service program v The service program no longer supports the procedures or data items represented by the signature an error occurs and you cannot run your application. For more details on program activation, refer to Program Activation Creation on page 28. When activation allocates the storage necessary for the static variables used by a program, the space is allocated from an activation group. At the time the program or service program is created, you can specify the activation group that should be used at run time. For more information on activation groups, refer to Activation Group on page 29.
Error Handling
Figure 16 on page 25 shows the complete error-handling structure for both OPM and ILE programs. This gure is used throughout this manual to describe advanced error-handling capabilities. This topic gives a brief overview of the standard language error-handling capabilities. For additional information on error handling, refer to Error Handling on page 39. The gure shows a fundamental layer called exception-message architecture. An exception message may be generated by the system whenever an OPM program or an ILE program encounters an error. Exception messages are also used to communicate status information that may not be considered a program error. For example, a condition that a database record is not found is communicated by sending a status exception message. Each high-level language denes language-specic error-handling capabilities. Although these capabilities vary by language, in general it is possible for each HLL user to declare the intent to handle specic error situations. The declaration of this intent includes identication of an error-handling routine. When an exception occurs, the system locates the error-handling routine and passes control to user-written instructions. You can take various actions, including ending the program or recovering from the error and continuing. Figure 16 on page 25 shows that ILE uses the same exception-message architecture that is used by OPM programs. Exception messages generated by the system initiate language-specic error handling within an ILE program just as they do within an OPM program. The lowest layer in the gure includes the capability for you to send and receive exception messages. This can be done with message handler APIs or commands. Exception messages can be sent and received between ILE and OPM programs.
24
Original Program Model (OPM) CL RPG
Integrated Language Environment (ILE) C CL RPG
COBOL
HLL - Specific Handlers
Direct Monitors
ILE Conditions
Unhandled Exception Default Actions
Exception Message Architecture

RV3W101-0
Figure 16. Error Handling for OPM and ILE
Language-specic error handling works similarly for ILE programs as for OPM programs, but there are basic differences: v When the system sends an exception message to an ILE program, the procedure and module name are used to qualify the exception message. If you send an exception message, these same qualications can be specied. When an exception message appears in the job log for an ILE program, the system normally supplies the program name, module name, and procedure name. v Extensive optimization for ILE programs can result in multiple HLL statement numbers associated with the same generated instructions. As the result of optimization, exception messages that appear in the job log may contain multiple HLL statement numbers. Additional error-handling capabilities are described in Error Handling on page 39.
Optimizing Translator
On the AS/400, optimization means maximizing the run-time performance of the object. All ILE languages have access to the optimization techniques provided by the ILE optimizing translator. Generally, the higher the optimizing request, the longer it takes to create the object. At run time, highly optimized programs or service programs should run faster than corresponding programs or service programs created with a lower level of optimization. Although optimization can be specied for a module, program object, and service program, the optimization techniques apply to individual modules. The levels of optimization are: 10 or *NONE 20 or *BASIC 30 or *FULL 40 (more optimization than level 30)
25
For performance reasons, you probably want a high level of optimization when you use a module in production. Test your code at the optimization level at which you expect to use it. Verify that everything works as expected, then make the code available to your users. Because optimization at level 30 (*FULL) or level 40 can signicantly affect your program instructions, you may need to be aware of certain debugging limitations and different addressing exception detection. Refer to Chapter 9. Debugging Considerations for debug considerations. Refer to Appendix B. Exception in Optimized Programs for addressing error considerations.
Debugger
ILE provides a debugger that allows source-level debugging. The debugger can work with a listing le and allow you to set breakpoints, display variables, and step into or over an instruction. You can do these without ever having to enter a command from the command line. A command line is also available while working with the debugger. The source-level debugger uses system-provided APIs to allow you to debug your program or service program. These APIs are available to everyone and allow you to write your own debugger. The debuggers for OPM programs continue to exist on the AS/400 system but can be used to debug only OPM programs. When you debug an optimized module, some confusion may result. When you use the ILE debugger to view or change a variable being used by a running program or procedure, the following happens. The debugger retrieves or updates the data in the storage location for this variable. At level 20 (*BASIC), 30 (*FULL), or 40 optimization, the current value of a data variable may be in a hardware register, where the debugger cannot access it. (Whether a data variable is in a hardware register depends on several factors. Those factors include how the variable is used, its size, and where in the code you stopped to examine or change the data variable.) Thus, the value displayed for a variable may not be the current value. For this reason, you should use an optimization level of 10 (*NONE) during development. Then, for best performance, you should change the optimization level to 30 (*FULL) or 40 during production. For more information on the ILE debugger, see Chapter 9. Debugging Considerations.
26
Chapter 3. ILE Advanced Concepts

This chapter describes advanced concepts for the ILE model. Before reading this chapter, you should be familiar with the concepts described in Chapter 2. ILE Basic Concepts on page 11.
Program Activation
Activation is the process used to prepare a program to run. Both ILE programs and ILE service programs must be activated by the system before they can be run. Program activation includes two major steps: 1. Allocate and initialize static storage for the program. 2. Complete the binding of programs to service programs. This topic concentrates on step 1. Step 2 is explained in Service Program Activation on page 34. Figure 17 on page 28 shows two ILE program objects stored in permanent disk storage. As with all OS/400 objects, these program objects may be shared by multiple concurrent users running in different OS/400 jobs. Only one copy of the programs code exists. When one of these ILE programs is called, however, some variables declared within the program must be allocated and initialized for each program activation. As shown in Figure 17, each program activation supports at least one unique copy of these variables. Multiple copies of variables with the same name can exist within one program activation. This occurs if your HLL allows you to declare static variables that are scoped to individual procedures.
27
Program A Program Instructions One copy of program instructions
Job Activation Group Program A Variable X = 10
Job Activation Group Program A Variable X = 20
One copy of static variables for each program activation
RV2W986-3
Figure 17. One Copy of Static Variables for Each Program Activation
Program Activation Creation

ILE manages the process of program activation by keeping track of program activations within an activation group. Refer to Activation Group on page 29 for a denition of an activation group. Only one activation for a particular program object is in an activation group. Programs of the same name residing in different AS/400 libraries are considered different program objects when applying this rule. When you use a dynamic program call statement in your HLL program, ILE uses the activation group that was specied when the program was created. This attribute is specied by using the activation group (ACTGRP) parameter on either the Create Program (CRTPGM) command or the Create Service Program (CRTSRVPGM) command. If a program activation already exists within the activation group indicated with this parameter, it is used. If the program has never been activated within this activation group, it is activated rst and then run. If there is a named activation group, the name can be changed with the ACTGRP parameter on the UPDPGM and UPDSRVPGM commands Once a program is activated, it remains activated until the activation group is deleted. As a result of this rule, it is possible to have active programs that are not on the call stack within the activation group. Figure 18 on page 29 shows an example of three active programs within an activation group, but only two of the three programs have procedures on the call stack. In this example, program A calls program B, causing program B to be activated. Program B then returns to program A. Program A then calls program C. The resulting call stack contains procedures for
28
programs A and C but not for program B. For a discussion of the call stack, see Call Stack on page 89.
Job Activation Group Active Programs Program A Activation Call Stack Procedures called in Program A
Program B Activation
. . .
Procedures called in Program C
Program C Activation
RV2W987-3
Figure 18. Program May Be Active But Not on the Call Stack
Activation Group
All ILE programs and service programs are activated within a substructure of a job called an activation group. This substructure contains the resources necessary to run the programs. These resources fall into the following general categories: Static and automatic program variables Dynamic storage Temporary data management resources Certain types of exception handlers and ending procedures The static and automatic program variables and dynamic storage are assigned separate address spaces for each activation group. This provides some degree of program isolation and protection from accidental access. The temporary data management resources include the following: Open les (open data path or ODP) Commitment denitions Local SQL cursors Remote SQL cursors Hierarchical le system (HFS) User interface manager Query management instances Open communications links Common Programming Interface (CPI) communications
29
The separation of these resources among activation groups supports a fundamental concept. That is, the concept that all programs activated within one activation group are developed as one cooperative application. Software vendors may select different activation groups to isolate their programs from other vendor applications running in the same job. This vendor isolation is shown in Figure 19. In this gure, a complete customer solution is provided by integrating software packages from four different vendors. Activation groups increase the ease of integration by isolating the resources associated with each vendor package.
Job Activation Group RPG Order Entry Application from Vendor 1 Activation Group RPG Accounts Payable Application from Vendor 2
Activation Group COBOL Inventory Control Application from Vendor 3
Activation Group C Decision Support Application from Vendor 4
RV2W988-1
Figure 19. Activation Groups Isolate Each Vendors Application
There is a signicant consequence of assigning the above resources to an activation group. The consequence is that when an activation group is deleted, all of the above resources are returned to the system. The temporary data management resources left open at the time the activation group is deleted are closed by the system. The storage for static and automatic program variables and dynamic storage that has not been deallocated is returned to the system.
Activation Group Creation

You can control the run-time creation of an ILE activation group by specifying an activation group attribute when you create your program or service program. The attribute is specied by using the ACTGRP parameter on the CRTPGM command or CRTSRVPGM command. There is no Create Activation Group command.
30
All ILE programs have one of the following activation group attributes: v A user-named activation group Specied with the ACTGRP(name) parameter. This attribute allows you to manage a collection of ILE programs and ILE service programs as one application. The activation group is created when it is rst needed. It is then used by all programs and service programs that specify the same activation group name. v A system-named activation group Specied with the ACTGRP(*NEW) parameter on the CRTPGM command. This attribute allows you to create a new activation group whenever the program is called. ILE selects a name for this activation group. The name assigned by ILE is unique within your job. The name assigned to a system-named activation group does not match any name you choose for a user-named activation group. ILE service programs do not support this attribute. v An attribute to use the activation group of the calling program Specied with the ACTGRP(*CALLER) parameter. This attribute allows you to create an ILE program or ILE service program that will be activated within the activation group of the calling program. With this attribute, a new activation group is never created when the program or service program is activated. All activation groups within a job have a name. Once an activation group exists within a job, it is used by ILE to activate programs and service programs that specify that name. As a result of this design, duplicate activation group names cannot exist within one job. You can, however, use the ACTGRP parameter on the UPDPGM and UPDSRVPGM to change the name of the activation group.
Default Activation Groups

When an OS/400 job is started, the system creates two activation groups to be used by OPM programs. One activation group is reserved for OS/400 system code. The other activation group is used for all other OPM programs. You cannot delete the OPM default activation groups. They are deleted by the system when your job ends. ILE programs and ILE service programs can be activated in the OPM default activation groups if two conditions are satised: v The ILE programs or ILE service programs were created with the activation group *CALLER option. v The call to the ILE programs or ILE service programs originates in the OPM default activation groups. Because the default activation groups cannot be deleted, your ILE HLL end verbs cannot provide complete end processing. Open les cannot be closed by the system until the job ends. The static and heap storages used by your ILE programs cannot be returned to the system until the job ends. Figure 20 on page 32 shows a typical OS/400 job with an ILE activation group and the OPM default activation groups. The two OPM default activation groups are combined because the special value *DFTACTGRP is used to represent both groups. The boxes within each activation group represent program activations.
31
Job Default Activation Group OPM Program A Activation OPM Program B Activation OS/400 System Code Program Activations
Activation Group ILE Program C Activation ILE Program D Activation
RV2W989-3
Figure 20. Default Activation Groups and ILE Activation Group
ILE Activation Group Deletion

Activation groups require resources to be created within a job. Processing time may be saved if an activation group can be reused by an application. ILE provides several options to allow you to return from the activation group without ending or deleting the activation group. Whether the activation group is deleted depends on the type of activation group and the method in which the application ended. An application may leave an activation group and return to a call stack entry (see Call Stack on page 89) that is running in another activation group in the following ways: v HLL end verbs For example, STOP RUN in COBOL or exit() in C. v Unhandled exceptions Unhandled exceptions can be moved by the system to a call stack entry in another activation group. v Language-specic HLL return statements For example, a return statement in C, an EXIT PROGRAM statement in COBOL, or a RETURN statement in RPG. v Skip operations For example, sending an exception message or branching to a call stack entry that is not in your activation group.
32
You can delete an activation group from your application by using HLL end verbs. An unhandled exception can also cause your activation group to be deleted. These operations will always delete your activation group, provided the nearest control boundary is the oldest call stack entry in the activation group (sometimes called a hard control boundary). If the nearest control boundary is not the oldest call stack entry (sometimes called a soft control boundary), control passes to the call stack entry prior to the control boundary. However, the activation group is not deleted. A control boundary is a call stack entry that represents a boundary to your application. ILE denes control boundaries whenever you call between activation groups. Refer to Control Boundaries on page 36 for a denition of a control boundary. A user-named activation group may be left in the job for later use. For this type of activation group, any normal return or skip operation past a hard control boundary does not delete the activation group. The same operations used within a system-named activation group deletes the activation group. System-named activation groups are always deleted because you cannot reuse them by specifying the system-generated name. For language-dependent rules about a normal return from the oldest call stack entry of an activation group, refer to the ILE HLL programmers guides. Figure 21 shows examples of how to leave an activation group. In the gure, procedure P1 is the oldest call stack entry. For the system-named activation group (created with the ACTGRP(*NEW) option), a normal return from P1 deletes the activation group. For the user-named activation group (created with the ACTGRP(name) option), a normal return from P1 does not delete the activation group.
System-Named Activation Group ILE Normal Return Procedure P1 User-Named Activation Group ILE Procedure P1 Normal Return
Always Delete
Never Delete
. . .
ILE Skip Procedure Pn
. . .
ILE Procedure Pn Skip
ACTGRP(*NEW)
ACTGRP(NAME)
RV2W1036-2
Figure 21. Leaving User-Named and System-Named Activation Groups
If a user-named activation group is left in the job, you can delete it by using the Reclaim Activation Group (RCLACTGRP) command. This command allows you to delete named activation groups after your application has returned. Only activation groups that are not in use can be deleted with this command. Figure 22 on page 34 shows an OS/400 job with one activation group that is not in use and one activation group that is currently in use. An activation group is considered in use if there are call stack entries for the ILE procedures activated within that activation group. Using the RCLACTGRP command in program A or program B deletes the activation group for program C and program D.
33
Job Activation Group in Use Active Programs Program A Call Stack Procedures called in Program A
Program B
Procedures called in Program B
Activation Group Not in Use Active Programs Program C Activation
Program D Activation
RV2W990-4
Figure 22. Activation Groups In Use Have Entries on the Call Stack
When an activation group is deleted by ILE, certain end-operation processing occurs. This processing includes calling user-registered exit procedures, data management cleanup, and language cleanup (such as closing les). Refer to Data Management Scoping Rules on page 46 for details on the data management processing that occurs when an activation group is deleted.
Service Program Activation

This topic discusses the unique steps the system uses to activate a service program. The common steps used for programs and service programs are described in Program Activation on page 27. The following activation activities are unique for service programs: v Service program activation starts indirectly as part of a dynamic program call to an ILE program. v Service program activation includes completion of interprogram binding linkages by mapping the symbolic links into physical links. v Service program activation includes signature check processing. An ILE program activated for the rst time within an activation group, is checked for binding to any ILE service programs. If service programs have been bound to the program being activated, they are also activated as part of the same dynamic call processing. This process is repeated until all necessary service programs are activated.
34
Figure 23 shows ILE program A bound to ILE service programs B, C, and D. ILE service programs B and C are also bound to ILE service program E. The activation group attribute for each program and service program is shown.
ILE Program A ACTGRP(X)
ILE Service Program B ACTGRP(X)
ILE Service Program C ACTGRP(X)
ILE Service Program D ACTGRP(Y)
ILE Service Program E ACTGRP(*CALLER)

RV2W991-1
Figure 23. Service Program Activation
When ILE program A is activated, the following takes place: v The service programs are located by using an explicit library name or by using the current library list. This option is controlled by you at the time the programs and service programs are created. v Just like programs, a service program activation occurs only once within an activation group. In Figure 23, service program E is activated only one time, even though it is used by service programs B and C. v A second activation group (Y) is created for service program D. v Signature checking occurs among all of the programs and service programs. Conceptually this process may be viewed as the completion of the binding process started when the programs and service programs were created. The CRTPGM command and CRTSRVPGM command saved the name and library of each referenced service program. An index into a table of exported procedures and data items was also saved in the client program or service program at program creation time. The process of service program activation completes the binding step by changing these symbolic references into addresses that can be used at run time. Once a service program is activated static procedure calls and static data item references to a module within a different service program are processed. The amount of processing is the same as would be required if the modules had been bound by copy into the same program. However, modules bound by copy require less activation time processing than service programs. The activation of programs and service programs requires execute authority to the ILE program and all ILE service program objects. In Figure 23, the current authority of the caller of program A is used to check authority to program A and all of the service programs. The authority of program A is also used to check authority to all
35
of the service programs. Note that the authority of service program B, C, or D is not used to check authority to service program E.
Control Boundaries
ILE takes the following action when an unhandled function check occurs, or an HLL end verb is used. ILE transfers control to the caller of the call stack entry that represents a boundary for your application. This call stack entry is known as a control boundary. There are two denitions for a control boundary. Control Boundaries for ILE Activation Groups and Control Boundaries for the OPM Default Activation Group on page 37 illustrate the following denitions. A control boundary can be either of the following: v Any ILE call stack entry for which the immediately preceding call stack entry is in a different nondefault activation group. v Any ILE call stack entry for which the immediately preceding call stack entry is an OPM program.
Control Boundaries for ILE Activation Groups

This example shows how control boundaries are dened between ILE activation groups. Figure 24 on page 37 shows two ILE activation groups and the control boundaries established by the various calls. Procedures P2, P3, and P6 are potential control boundaries. For example, when you are running in procedure P7, procedure P6 is the control boundary. When you are running in procedures P4 or P5, procedure P3 becomes the control boundary.
36
Call Stack
ILE Procedure P1
Activation Group A1 ILE Procedure P2
Activation Group A2 ILE Procedure P3
ILE Procedure P4
ILE Procedure P6 ILE Procedure P7
ILE Procedure P5
RV2W992-3
Figure 24. Control Boundaries. The shaded procedures are control boundaries.
Control Boundaries for the OPM Default Activation Group

This example shows how control boundaries are dened when an ILE program is running in the OPM default activation group. Figure 25 on page 38 shows three ILE procedures (P1, P2, and P3) running in the OPM default activation group. This example could have been created by using the CRTPGM command or CRTSRVPGM command with the ACTGRP(*CALLER) parameter value. Procedures P1 and P3 are potential control boundaries because the preceding call stack entries are OPM programs A and B.
37
Default Activation Group OPM Program A
ILE Procedure P1
ILE Procedure P2
OPM
Program B
ILE Procedure P3
*DFTACTGRP
RV2W1040-1
Figure 25. Control Boundaries in the Default Activation Group. The shaded procedures are control boundaries.
Control Boundary Use

When you use an ILE HLL end verb, ILE uses the most recent control boundary on the call stack to determine where to transfer control. The call stack entry just prior to the control boundary receives control after ILE completes all end processing. The control boundary is used when an unhandled function check occurs within an ILE procedure. The control boundary denes the point on the call stack at which the unhandled function check is promoted to the generic ILE failure condition. For additional information, refer to Error Handling on page 39. When the nearest control boundary is the oldest call stack entry in an ILE activation group, any HLL end verb or unhandled function check causes the activation group to be deleted. When the nearest control boundary is not the oldest call stack entry in an ILE activation group, control returns to the call stack entry just prior to the control boundary. The activation group is not deleted because earlier call stack entries exist within the same activation group. Figure 24 on page 37 shows procedure P2 and procedure P3 as the oldest call stack entries in their activation groups. Using an HLL end verb in procedure P2, P3, P4, or P5 (but not P6 or P7) would cause activation group A2 to be deleted.
38
Error Handling
This topic explains advanced error handling capabilities for OPM and ILE programs. To understand how these capabilities t into the exception message architecture, refer to Figure 26. Specic reference information and additional concepts are found in Chapter 8. Exception and Condition Management. Figure 26 shows an overview of error handling. This topic starts with the bottom layer of this gure and continues to the top layer. The top layer represents the functions you may use to handle errors in an OPM or ILE program.
Original Program Model (OPM) CL RPG Integrated Language Environment (ILE) C CL RPG
COBOL
Direct Monitors
ILE Conditions
Exception Message Architecture

RV3W101-0
Figure 26. ILE and OPM Error Handling
Job Message Queues

A message queue exists for every call stack entry within each OS/400 job. This message queue facilitates the sending and receiving of informational messages and exception messages between the programs and procedures running on the call stack. The message queue is referred to as the call message queue. The call message queue is identied by the name of the OPM program or ILE procedure that is on the call stack. The procedure name or program name can be used to specify the target call stack entry for the message that you send. Because ILE procedure names are not unique, the ILE module name and ILE program or service program name can optionally be specied. When the same program or procedure has multiple call stack entries, the nearest call message queue is used. In addition to the call message queues, each OS/400 job contains one external message queue. All programs and procedures running within the job can send and receive messages between an interactive job and the workstation user by using this queue. For more information on how to send and receive exception messages, refer to the message handling APIs in the System API Reference.
39
Exception Messages and How They Are Sent

This topic describes the different exception message types and the ways in which an exception message may be sent. Error handling for ILE and OPM is based on exception message types. Unless otherwise qualied, the term exception message indicates any of these message types: Escape (*ESCAPE) Indicates an error causing a program to end abnormally, without completing its work. You will not receive control after sending an escape exception message. Status (*STATUS) Describes the status of work being done by a program. You may receive control after sending this message type. Whether you receive control depends on the way the receiving program handles the status message. Notify (*NOTIFY) Describes a condition requiring corrective action or a reply from the calling program. You may receive control after sending this message type. Whether you receive control depends on the way the receiving program handles the notify message. Function Check Describes an ending condition that has not been expected by the program. An ILE function check, CEE9901, is a special message type that is sent only by the system. An OPM function check is an escape message type with a message ID of CPF9999. For information on these message types and other OS/400 message types, refer to the System API Reference. An exception message is sent in the following ways: v Generated by the system OS/400 (including your HLL) generates an exception message to indicate a programming error or status information. v Message handler API The Send Program Message (QMHSNDPM) API can be used to send an exception message to a specic call message queue. v ILE API The Signal a Condition (CEESGL) bindable API can be used to raise an ILE condition. This condition results in an escape exception message or status exception message. v Language-specic verbs For ILE C/400, the raise() function generates a C signal. Neither ILE RPG/400 nor ILE COBOL/400 has a similar function.
How Exception Messages Are Handled

When you or the system send an exception message, exception processing begins. This processing continues until the exception is handled, which is when the exception message is modied to indicate that it has been handled.
40
The system modies the exception message to indicate that it has been handled when it calls an exception handler for an OPM call message queue. Your ILE HLL modies the exception message before your exception handler is called for an ILE call message queue. As a result, HLL-specic error handling considers the exception message handled when your handler is called. If you do not use HLL-specic error handling, your ILE HLL can either handle the exception message or allow exception processing to continue. Refer to your ILE HLL reference manual to determine your HLL default actions for unhandled exception messages. To allow you to bypass language-specic error handling, additional capabilities are dened for ILE. These capabilities include direct monitor handlers and ILE condition handlers. When you use these capabilities, you are responsible for modifying the exception message to indicate that the exception is handled. If you do not modify the exception message, the system continues exception processing by attempting to locate another exception handler. The topic Types of Exception Handlers on page 43 contains details on direct monitor handlers and ILE condition handlers. To modify an exception message, refer to the Change Exception Message (QMHCHGEM) API in the System API Reference.
Exception Recovery
You may want to continue processing after an exception has been sent. Recovering from an error can be a useful application tool that allows you to deliver applications that tolerate errors. For ILE and OPM programs, the system has dened the concept of a resume point. The resume point is initially set to an instruction immediately following the occurrence of the exception. After handling an exception, you may continue processing at a resume point. For more information on how to use and modify a resume point, refer to Chapter 8. Exception and Condition Management.
Default Actions for Unhandled Exceptions

If you do not handle an exception message in your HLL, the system takes a default action for the unhandled exception. Figure 26 on page 39 shows the default actions for unhandled exceptions based on whether the exception was sent to an OPM or ILE program. Different default actions for OPM and ILE create a fundamental difference in error handling capabilities. For OPM, an unhandled exception generates a special escape message known as a function check message. This message is given the special message ID of CPF9999. It is sent to the call message queue of the call stack entry that incurred the original exception message. If the function check message is not handled, the system removes that call stack entry. The system then sends the function check message to the previous call stack entry. This process continues until the function check message is handled. If the function check message is never handled, the job ends. For ILE, an unhandled exception message is percolated to the previous call stack entry message queue. Percolation occurs when the exception message is moved to the previous call message queue. This creates the effect of sending the same exception message to the previous call message queue. When this happens, exception processing continues at the previous call stack entry.
41
Figure 27 shows unhandled exception messages within ILE. In this example, procedure P1 is a control boundary. Procedure P1 is also the oldest call stack entry in the activation group. Procedure P4 incurred an exception message that was unhandled. Percolation of an unhandled exception continues until either a control boundary is reached or the exception message is handled. An unhandled exception is converted to a function check when it is percolated to the control boundary. If the exception is an escape, the function check is generated. If it is a notify exception, the default reply is sent, the exception is handled, and the sender of the notify is allowed to continue. If it is a status exception, the exception is handled, and the sender of the status is allowed to continue. The resume point (shown in procedure P3) is used to dene the call stack entry at which exception processing of the function check should continue. For ILE, the next processing step is to send the special function check exception message to this call stack entry. This is procedure P3 in this example. The function check exception message can now be handled or percolated to the control boundary. If it is handled, normal processing continues and exception processing ends. If the function check message is percolated to the control boundary, ILE considers the application to have ended with an unexpected error. A generic failure exception message is dened by ILE for all languages. This message is CEE9901 and is sent by ILE to the caller of the control boundary. The default action for unhandled exception messages dened in ILE allows you to recover from error conditions that occur within a mixed-language application. For unexpected errors, ILE enforces a consistent failure message for all languages. This improves the ability to integrate applications from different sources.
Call Stack
OPM Program A Send Terminating Exception CEE9901
Activation Group ILE Procedure P1 ILE Procedure P2 ILE Procedure P3

Resume Point
Percolate Function Check
Percolate Unhandled Exception
ILE Procedure P4
RV2W1043-1
Figure 27. Unhandled Exception Default Action
42
Types of Exception Handlers

This topic provides an overview of the exception handler types provided for both OPM and ILE programs. As shown in Figure 26 on page 39, this is the top layer of the exception message architecture. ILE provides additional exception-handling capabilities when compared to OPM. For OPM programs, HLL-specic error handling provides one or more handling routines for each call stack entry. The appropriate routine is called by the system when an exception is sent to an OPM program. HLL-specic error handling in ILE provides the same capabilities. ILE, however, has additional types of exception handlers. These types of handlers give you direct control of the exception message architecture and allow you to bypass HLL-specic error handling. The additional types of handlers for ILE are: Direct monitor handler ILE condition handler To determine if these types of handlers are supported by your HLL, refer to your ILE HLL programmers guide. Direct monitor handlers allow you to directly declare an exception monitor around limited HLL source statements. For ILE C/400, this capability is enabled through a #pragma directive. ILE COBOL/400 does not directly declare an exception monitor around limited HLL source statements in the same sense that ILE C/400 does. An ILE COBOL/400 program cannot directly code the enablement and disablement of handlers around arbitrary source code. However, a statement such as
ADD a TO b ON SIZE ERROR imperative
is internally mapped to use the same mechanism. Thus, in terms of the priority of which handler gets control rst, such a statement-scoped conditional imperative gets control before the ILE condition handler (registered via CEEHDLR). Control then proceeds to the USE declaratives in COBOL. ILE condition handlers allow you to register an exception handler at run time. ILE condition handlers are registered for a particular call stack entry. To register an ILE condition handler, use the Register a User-Written Condition Handler (CEEHDLR) bindable API. This API allows you to identify a procedure at run time that should be given control when an exception occurs. The CEEHDLR API requires the ability to declare and set a procedure pointer within your language. CEEHDLR is implemented as a built-in function. Therefore, its address cannot be specied and it cannot be called through a procedure pointer. ILE condition handlers may be unregistered by calling the Unregister a User-Written Condition Handler (CEEHDLU) bindable API. OPM and ILE support HLL-specic handlers. HLL-specic handlers are the language features dened for handling errors. For example, the ILE C/400 signal function can be used to handle exception messages. HLL-specic error handling in RPG includes the ability to code *PSSR and INFSR subroutines. HLL-specic error handling in COBOL includes USE declarative for I/O error handling and imperatives in statement-scoped condition phrases such as ON SIZE ERROR and AT INVALID KEY. Exception handler priority becomes important if you use both HLL-specic error handling and additional ILE exception handler types.
43
Figure 28 on page 45 shows a call stack entry for procedure P2. In this example, all three types of handlers have been dened for a single call stack entry. Though this may not be a typical example, it is possible to have all three types dened. Because all three types are dened, an exception handler priority is dened. The gure shows this priority. When an exception message is sent, the exception handlers are called in the following order: 1. Direct monitor handlers First the invocation is chosen, then the relative order of handlers in that invocation. Within an invocation, all direct monitor handlers and COBOL statement-scoped conditional imperatives get control before the ILE condition handlers. Similarly, the ILE condition handlers get control before other HLL-specic handlers. If direct monitor handlers have been declared around the statements that incurred the exception, these handlers are called before HLL-specic handlers. For example, if procedure P2 in Figure 28 on page 45 has a HLL-specic handler and procedure P1 has a direct monitor handler, P2s handler is considered before P1s direct monitor handler. Direct monitors can be lexically nested. The handler specied in the most deeply nested direct monitor is chosen rst within the multiply nested monitors that specify the same priority number. 2. ILE condition handler If an ILE condition handler has been registered for the call stack entry, this handler is called second. Multiple ILE condition handlers may be registered. In the example, procedure P5 and procedure P6 are ILE condition handlers. When multiple ILE condition handlers are registered for the same call stack entry, the system calls these handlers in last-in-rst-out (LIFO) order. If we categorize COBOL statement-scoped conditional imperatives as HLL-specic handlers, those imperatives take priority over the ILE condition handler. 3. HLL-specic handler HLL-specic handlers are called last. The system ends exception processing when an exception message is modied to show that it has been handled. If you are using direct monitor handlers or ILE condition handlers, modifying the exception message is your responsibility. Several control actions are available. For example, you can specify handle as a control action. As long as the exception message remains unhandled, the system continues to search for an exception handler using the priorities previously dened. If the exception is not handled within the current call stack entry, percolation to the previous call stack entry occurs. If you do not use HLL-specic error handling, your ILE HLL can choose to allow exception handling to continue at the previous call stack entry.
44
Call Stack
Exception Handler Priority ILE Direct Monitor Handler Procedure P4
ILE Procedure P1
ILE Procedure P2 Exception Occurs
ILE ILE Condition Handler Procedure P5
ILE Procedure P3
ILE ILE Condition Handler Procedure P6 ILE HLL - Specific Handler Procedure P7
. . .
Last in First out
Standard Language Default

RV2W1041-3
Figure 28. Exception Handler Priority
ILE Conditions
To allow greater cross-system consistency, ILE has dened a feature that allows you to work with error conditions. An ILE condition is a system-independent representation of an error condition within an HLL. For the OS/400 operating system, each ILE condition has a corresponding exception message. An ILE condition is represented by a condition token. A condition token is a 12-byte data structure that is consistent across multiple SAA participating systems. This data structure contains information that allows you to associate the condition with the underlying exception message. ILE condition handlers and the percolation model described previously conform to an SAA architecture. To write programs that are consistent across systems, you need to use ILE condition handlers and ILE condition tokens. For more information on ILE conditions refer to Chapter 8. Exception and Condition Management.
45
Data Management Scoping Rules

Data management scoping rules control the use of data management resources. These resources are temporary objects that allow a program to work with data management. For example, when a program opens a le, an object called an open data path (ODP) is created to connect the program to the le. When a program creates an override to change how a le should be processed, the system creates an override object. Data management scoping rules determine when a resource can be shared by multiple programs or procedures running on the call stack. For example, open les created with the SHARE(*YES) parameter value or commitment denition objects can be used by many programs at the same time. The ability to share a data management resource depends on the level of scoping for the data management resource. Data management scoping rules also determine the existence of the resource. The system automatically deletes unused resources within the job, depending on the scoping rules. As a result of this automatic cleanup operation, the job uses less storage and job performance improves. ILE formalizes the data management scoping rules for both OPM and ILE programs into the following scoping levels: Call Activation group Job Depending on the data management resource you are using, one or more of the scoping levels may be explicitly specied. If you do not select a scoping level, the system selects one of the levels as a default. Refer to Chapter 10. Data Management Scoping for information on how each data management resource supports the scoping levels. For additional details, refer to the Data Management book.
Call-Level Scoping
Call-level scoping occurs when the data management resource is connected to the call stack entry that created the resource. Figure 29 on page 47 shows an example. Call-level scoping is usually the default scoping level for programs that run in the default activation group. In this gure, OPM program A, OPM program B, or ILE procedure P2 may choose to return without closing their respective les F1, F2, or F3. Data management associates the ODP for each le with the call-level number that opened the le. The RCLRSC command may be used to close the les based on a particular call-level number passed to that command.
46
Default Activation Group OPM Program A ODP F1
OPM Override R1 Program B ILE PEP P1 ILE

UEP P2
ODP F2
ODP F3
RV2W1037-1
Figure 29. Call-Level Scoping. ODPs and overrides may be scoped to the call level.
Overrides that are scoped to a particular call level are deleted when the corresponding call stack entry returns. Overrides may be shared by any call stack entry that is below the call level that created the override.
Activation-Group-Level Scoping
Activation-group-level scoping occurs when the data management resource is connected to the activation group of the ILE program or ILE service program that created the resource. When the activation group is deleted, data management closes all resources associated with the activation group that have been left open by programs running in the activation group. Figure 30 on page 48 shows an example of activation-group-level scoping. Activation-group-level scoping is the default scoping level for most types of data management resources used by ILE procedures not running in the default activation group. For example, the gure shows ODPs for les F1, F2, and F3 and override R1 scoped to the activation group.
47
ILE Activation Group ILE PEP P1 ODP F1 ILE

UEP P2
Data Management Resources
Override R1
ODP F2
ILE Procedure P3
ODP F3
. . .
RV3W102-0
Figure 30. Activation Group Level Scoping. ODPs and overrides may be scoped to an activation group.
The ability to share a data management resource scoped to an activation group is limited to programs running in that activation group. This provides application isolation and protection. For example, assume that le F1 in the gure was opened with the SHARE(*YES) parameter value. File F1 could be used by any ILE procedure running in the same activation group. Another open operation for le F1 in a different activation group results in the creation of a second ODP for that le.
Job-Level Scoping
Job-level scoping occurs when the data management resource is connected to the job. Job-level scoping is available to both OPM and ILE programs. Job-level scoping allows for sharing data management resources between programs running in different activation groups. As described in the previous topic, scoping resources to an activation group limits the sharing of that resource to programs running in that activation group. Job-level scoping allows the sharing of data management resources between all ILE and OPM programs running in the job. Figure 31 on page 49 shows an example of job-level scoping. Program A may have opened le F1, specifying job-level scoping. The ODP for this le is connected to the job. The le is not closed by the system unless the job ends. If the ODP has been created with the SHARE(YES) parameter value, any OPM program or ILE procedure could potentially share the le.
48
Job Default Activation Group OPM Program A ODP F1 OPM

Program B
Data Management Resources
Override R1
ILE Activation Group ILE PEP P1
Commitment Definition *JOB
. . .
ILE UEP P2
RV2W1039-2
Figure 31. Job Level Scoping. ODPs, overrides, and commitment denitions may be scoped to the job level.
Overrides scoped to the job level inuence all open le operations in the job. In this example, override R1 could have been created by procedure P2. A job-level override remains active until it is either explicitly deleted or the job ends. The job-level override is the highest priority override when merging occurs. This is because call-level overrides are merged together when multiple overrides exist on the call stack. Data management scoping levels may be explicitly specied by the use of scoping parameters on override commands, commitment control commands, and through various APIs. The complete list of data management resources that use the scoping rules are in Chapter 10. Data Management Scoping.
49
50
Chapter 4. Program Creation Concepts

The process for creating ILE programs or service programs gives you greater exibility and control in designing and maintaining applications. The process includes two steps: 1. Compiling source code into modules. 2. Binding modules into an ILE program or service program. Binding occurs when the Create Program (CRTPGM) or Create Service Program (CRTSRVPGM) command is run. This chapter explains concepts associated with the binder and with the process of creating ILE programs or service programs. Before reading this chapter, you should be familiar with the binding concepts described in Chapter 2. ILE Basic Concepts on page 11.
Create Program and Create Service Program Commands

The Create Program (CRTPGM) and Create Service Program (CRTSRVPGM) commands look similar and share many of the same parameters. Comparing the parameters used in the two commands helps to clarify how each command can be used. Table 2 shows the commands and their parameters with the default values supplied.
Table 2. Parameters for CRTPGM and CRTSRVPGM Commands Parameter Group CRTPGM Command CRTSRVPGM Command Identication PGM(*CURLIB/WORK) SRVPGM(*CURLIB/UTILITY) MODULE(*PGM) MODULE(*SRVPGM) Program access ENTMOD(*FIRST) EXPORT(*SRCFILE) SRCFILE(*LIBL/QSRVSRC) SRCMBR(*SRVPGM) Binding BNDSRVPGM(*NONE) BNDSRVPGM(*NONE) BNDDIR(*NONE) BNDDIR(*NONE) Run time ACTGRP(*NEW) ACTGRP(*CALLER) Miscellaneous OPTION(*GEN OPTION(*GEN *NODUPPROC *NODUPVAR *NODUPPROC *NODUPVAR *WARN *RSLVREF) *WARN *RSLVREF) DETAIL(*NONE) DETAIL(*NONE) ALWUPD(*YES) ALWUPD(*YES) ALWRINZ(*NO) ALWRINZ(*NO) REPLACE(*YES) REPLACE(*YES) AUT(*LIBCRTAUT) AUT(*LIBCRTAUT) TEXT(*ENTMODTXT) TEXT(*ENTMODTXT) TGTRLS(*CURRENT) TGTRLS(*CURRENT) USRPRF(*USER) USRPRF(*USER)
The identication parameters for both commands name the object to be created and the modules copied. The only difference in the two parameters is in the default module name to use when creating the object. For CRTPGM, use the same name for the module as is specied on the program (*PGM) parameter. For CRTSRVPGM, use the same name for the module as is specied on the service program (*SRVPGM) parameter. Otherwise, these parameters look and act the same.
51
The most signicant similarity in the two commands is how the binder resolves symbols between the imports and exports. In both cases, the binder processes the input from the module (MODULE), bound service program (BNDSRVPGM), and binding directory (BNDDIR) parameters. The most signicant difference in the commands is with the program-access parameters (see Program Access on page 60). For the CRTPGM command, all that needs to be identied to the binder is which module has the program entry procedure. Once the program is created and a dynamic program call is made to this program, processing starts with the module containing the program entry procedure. The CRTSRVPGM command needs more program-access information because it can supply an interface of several access points for other programs or service programs.
Use Adopted Authority (QUSEADPAUT)

The QUSEADPAUT system value denes which users can create programs with the use adopted authority (USEADPAUT(*YES)) attribute. All users authorized by the QUSEADPAUT system value can create or change programs and service programs to use adopted authority if the user has the necessary authorities. See the Security - Reference to nd out what authorities are required. The system value can contain the name of an authorization list. The users authority is checked against this list. If the user has at least *USE authority to the named authorization list, the user can create, change, or update programs or service programs with the USEADPAUT(*YES) attribute. The authority to the authorization list cannot come from adopted authority. If an authorization list is named in the system value and the authorization list is missing, the function being attempted will not complete. A message is sent indicating this. However, if the program is created with the QPRCRTPG API, and the *NOADPAUT value is specied in the option template, the program will create successfully even if the authorization list does not exist. If more than one function is requested on the command or API, and the authorization list is missing, the function is not performed. If the command being attempted when the authorization list cannot be found is Create Pascal Program (CRTPASPGM) or Create Basic Program (CRTBASPGM), the result is a function check.
Table 3. Possible Values for QUSEADPAUT
Values Description A diagnostic message is signaled to indicate that the program is created with USEADPAUT(*NO) if all of the following are true: v An authorization list is specied for the QUSEADPAUT system value. v The user does not have authority to the authorization list mentioned above. v There are no other errors when the program or service program is created. If the user has authority to the authorization list, the program or service program is created with USEADPAUT(*YES). *NONE All users authorized by the QUSEADPAUT system value can create or change programs and service programs to use adopted authority if the users have the necessary authorities. See the Security - Reference to nd out what authorities are required.
authorizationlist name
For more information about the QUSEADPAUT system value, see the Security Reference .
52
Symbol Resolution
Symbol resolution is the process the binder goes through to match the following: v The import requests from the set of modules to be bound by copy v The set of exports provided by the specied modules and service programs The set of exports to be used during symbol resolution can be thought of as an ordered (sequentially numbered) list. The order of the exports is determined by the following: v The order in which the objects are specied on the MODULE, BNDSRVPGM, and BNDDIR parameters of the CRTPGM or CRTSRVPGM command v The exports from the language run-time routines of the specied modules
Resolved and Unresolved Imports

An import and export each consist of a procedure or data type and a name. An unresolved import is one whose type and name do not yet match the type and name of an export. A resolved import is one whose type and name exactly match the type and name of an export. Only the imports from the modules that are bound by copy go into the unresolved import list. During symbol resolution, the next unresolved import is used to search the ordered list of exports for a match. If an unresolved import exists after checking the set of ordered exports, the program object or service program is normally not created. However, if *UNRSLVREF is specied on the option parameter, a program object or service program with unresolved imports can be created. If such a program object or service program tries to use an unresolved import at run time, the following occurs: v If the program object or service program was created or updated for a Version 2 Release 3 system, error message MCH3203 is issued. That message says, Function error in machine instruction. v If the program object or service program was created or updated for a Version 3 Release 1 system, error message MCH4439 is issued. That message says, Attempt to use an import that was not resolved.
Binding by Copy
The modules specied on the MODULE parameter are always bound by copy. Modules named in a binding directory specied by the BNDDIR parameter are bound by copy if they are needed. A module named in a binding directory is needed in either of the following cases: v The module provides an export for an unresolved import v The module provides an export named in the current export block of the binder language source le being used to create a service program If an export found in the binder language comes from a module object, that module is always bound by copy, regardless of whether it was explicitly provided on the command line or comes from a binding directory. For example,
Module Module Module Binder M1: imports P2 M2: exports P2 M3: exports P3 language S1: STRPGMEXP PGMLVL(*CURRENT) EXPORT P3 ENDPGMEXP
53
Binding directory BNDDIR1:
M2 M3 CRTSRVPGM SRVPGM(MYLIB/SRV1) MODULE(MYLIB/M1) SRCFILE(MYLIB/S1) SRCMBR(S1) BNDDIR(MYLIB/BNDDIR1)
Service program SRV1 will have three modules: M1, M2, and M3. M3 is copied because P3 is in the current export block.
Binding by Reference
Service programs specied on the BNDSRVPGM parameter are bound by reference. If a service program named in a binding directory provides an export for an unresolved import, that service program is bound by reference. A service program bound in this way does not add new imports. Note: To better control what gets bound to your program, specify the generic service program name or specic libraries. The value *LIBL should only be specied in a user-controlled environment when you know exactly what is getting bound to your program. Do not specify BNDSRVPGM(*LIBL/*ALL) with OPTION(*DUPPROC *DUPVAR). Specifying *LIBL with *ALL may give you unpredictable results at program run time.
Binding Large Numbers of Modules

For the module (MODULE) parameter on the CRTPGM and CRTSRVPGM commands, there is a limit on the number of modules you can specify. If the number of modules you want to bind exceed the limit, you can use one the following methods: 1. Use binding directories to bind large number of modules that provide exports that are needed by other modules. 2. Use a module naming convention that allows generic module names to be specied on the MODULE parameter on the CRTPGM and CRTSRVPGM commands. For example, CRTPGM PGM(mylib/payroll) MODULE(mylib/pay*). All modules with names started with pay are unconditionally included in the program mylib/payroll. Therefore, pick your naming convention carefully so that the generic names specied on the CRTPGM or CRTSRVPGM commands do not bind unwanted modules. 3. Group the modules into separate libraries so that the value *ALL can be used with specic library names on the MODULE parameter. For example, CRTPGM PGM(mylib/payroll) MODULE(payroll/*ALL). Every module in the library payroll is unconditionally included in the program mylib/payroll. 4. Use a combination of generic names and specic libraries that are described in method 2 and 3. 5. For service programs, use the binding source language. An export specied in the binding source language causes a module to be bound if it satises the export. The RTVBNDSRC command can help you create your binding source language. Although the MODULE parameter on the RTVBNDSRC command limits the number of modules that can be explicitly specied on the MODULE parameter, you can use generic module names and the value *ALL with specic libraries names. You can use the RTVBNDSRC command multiple times with output directed to the same source le. However, you may need to edit the binding source language in this case.
54
Importance of the Order of Exports

With only a slight change to the command, you can create a different, but potentially equally valid, program. The order in which objects are specied on the MODULE, BNDSRVPGM, and BNDDIR parameters is usually important only if both of the following are true: v Multiple modules or service programs are exporting duplicate symbol names v Another module needs to import the symbol name Most applications do not have duplicate symbols, and programmers seldom need to worry about the order in which the objects are specied. For those applications that have duplicate symbols exported that are also imported, consider the order in which objects are listed on CRTPGM or CRTSRVPGM commands. The following examples show how symbol resolution works. The modules, service programs, and binding directories in Figure 32 on page 56 are used for the CRTPGM requests in Figure 33 on page 57 and Figure 34 on page 59. Assume that all the identied exports and imports are procedures. The examples also show the role of binding directories in the program-creation process. Assume that library MYLIB is in the library list for the CRTPGM and CRTSRVPGM commands. The following command creates binding directory L in library MYLIB:
CRTBNDDIR BNDDIR(MYLIB/L)
The following command adds the names of modules M1 and M2 and of service programs S and T to binding directory L:
ADDBNDDIRE BNDDIR(MYLIB/L) OBJ((M1 *MODULE) (M2 *MODULE) (S) (T))
55
Module M1
Import List
Module M2
Export List P20
P20 P21 Prints
. . .
Import List P30
. . .
. . .
Service Program S Export List P1 P20 P30
Service Program T Export List P30 P40 P21
. . .
Binding Directory L
. . .
Service Program QLEPRINTS Export List
M1 M2 S T
*MODULE *MODULE *SRVPGM *SRVPGM
*LIBL *LIBL *LIBL *LIBL
Prints
. . .
RV2W1054-3
Figure 32. Modules, Service Programs, and Binding Directory
Program Creation Example 1

Assume that the following command is used to create program A in Figure 33 on page 57:
CRTPGM PGM(TEST/A) MODULE(*LIBL/M1) BNDSRVPGM(*LIBL/S) BNDDIR(*LIBL/L) OPTION(*DUPPROC)
56
Program A
Module M1
Import List P20 P21 Prints
Module M2 Export List

P20
. . .
Import List P30
. . .
. . .
. . .
Binding Directory L
. . .
M1 M2 S T
Prints
. . .
RV2W1049-4
Figure 33. Symbol Resolution and Program Creation: Example 1
To create program A, the binder processes objects specied on the CRTPGM command parameters in the order specied: 1. The value specied on the rst parameter (PGM) is A, which is the name of the program to be created. 2. The value specied on the second parameter (module) is M1. The binder starts there. Module M1 contains three imports that need to be resolved: P20, P21, and Prints. 3. The value specied on the third parameter (BNDSRVPGM) is S. The binder scans the export list of service program S for any procedures that resolve any unresolved import requests. Because the export list contains procedure P20, that import request is resolved. 4. The value specied on the fourth parameter (BNDDIR) is L. The binder next scans binding directory L.
57
a. The rst object specied in the binding directory is module M1. Module M1 is currently known because it was specied on the module parameter, but it does not provide any exports. b. The second object specied in the binding directory is module M2. Module M2 provides exports, but none of them match any currently unresolved import requests (P21 and Prints). c. The third object specied in the binding directory is service program S. Service program S was already processed in step 3 on page 57 and does not provide any additional exports. d. The fourth object specied in the binding directory is service program T. The binder scans the export list of service program T. Procedure P21 is found, which resolves that import request. 5. The nal import that needs to be resolved (Prints) is not specied on any parameter. Nevertheless, the binder nds the Prints procedure in the export list of service program QLEPRINTS, which is a common run-time routine provided by the compiler in this example. When compiling a module, the compiler species as the default the binding directory containing its own run-time service programs and the ILE run-time service programs. That is how the binder knows that it should look for any remaining unresolved references in the run-time service programs provided by the compiler. If, after the binder looks in the run-time service programs, there are references that cannot be resolved, the bind normally fails. However, if you specify OPTION(*UNRSLVREF) on the create command, the program is created.
Program Creation Example 2

Figure 34 on page 59 shows the result of a similar CRTPGM request, except that the service program on the BNDSRVPGM parameter has been removed:
CRTPGM PGM(TEST/A) MODULE(*LIBL/M1) BNDDIR(*LIBL/L) OPTION(*DUPPROC)
58
Program A
Module M1
Import List P20 P21 Prints
Module M2
Export List P20
. . .
Import List P30
. . .
. . .
. . .
Binding Directory L
. . .
M1 M2 S T
Prints
. . .
RV2W1050-3
Figure 34. Symbol Resolution and Program Creation: Example 2
The change in ordering of the objects to be processed changes the ordering of the exports. It also results in the creation of a program that is different from the program created in example 1. Because service program S is not specied on the BNDSRVPGM parameter of the CRTPGM command, the binding directory is processed. Module M2 exports procedure P20 and is specied in the binding directory ahead of service program S. Therefore, module M2 gets copied to the resulting program object in this example. When you compare Figure 33 on page 57 with Figure 34 you see the following: v Program A in example 1 contains only module M1 and uses procedures from service programs S, T, and QLEPRINTS. v In program A of example 2, two modules called M1 and M2 use service programs T and QLEPRINTS. The program in example 2 is created as follows:
59
1. The rst parameter (PGM) species the name of the program to be created. 2. The value specied on the second parameter (MODULE) is M1, so the binder again starts there. Module M1 contains the same three imports that need to be resolved: P20, P21, and Prints. 3. This time, the third parameter specied is not BNDSRVPGM. It is BNDDIR. Therefore, the binder rst scans the binding directory specied (L). a. The rst entry specied in the binding directory is module M1. Module M1 from this library was already processed by the module parameter. b. The second entry specied in the binding directory is for module M2. The binder scans the export list of module M2. Because that export list contains P20, that import request is resolved. Module M2 is bound by copy and its imports must be added to the list of unresolved import requests for processing. The unresolved import requests are now P21, Prints, and P30. c. Processing continues to the next object that is specied in the binding directory service program S. Here, the service program S provides the P30 export for currently unresolved import requests. Processing continues to the next object that is listed in the binding directory, service program T. 4. Service program T provides export P21 for the unresolved import. 5. As in example 1, import request Prints is not specied. However, the procedure is found in the run-time routines provided by the language in which module M1 was written. Symbol resolution is also affected by the strength of the exports. For information about strong and weak exports, see Export in Import and Export Concepts on page 63.
| | | | |
Program Access
When you create an ILE program object or service program object, you need to specify how other programs can access that program. On the CRTPGM command, you do so with the entry module (ENTMOD) parameter. On the CRTSRVPGM command, you do so with the export (EXPORT) parameter (see Table 2 on page 51).
Program Entry Procedure Module Parameter on the CRTPGM Command

The program entry procedure module (ENTMOD) parameter tells the binder the name of the module in which the following are located: Program entry procedure (PEP) User entry procedure (UEP) This information identies which module contains the PEP that gets control when making a dynamic call to the program that is created. The default value for the ENTMOD parameter is *FIRST. This value species that the binder uses as the entry module the rst module it nds in the list of modules specied on the module parameter that contains a PEP. If the following conditions exist: *FIRST is specied on the ENTMOD parameter
60
A second module with a PEP is encountered the binder copies this second module into the program object and continues the binding process. The binder ignores the additional PEP. If *ONLY is specied on the ENTMOD parameter, only one module in the program can contain a PEP. If *ONLY is specied and a second module with a PEP is encountered, the object is not created. For explicit control, you can specify the name of the module that contains the PEP. Any other PEPs are ignored. If the module explicitly specied does not contain a PEP, the CRTPGM request fails. To see whether a module has a program entry procedure, you use the display module (DSPMOD) command. The information appears in the Program entry procedure name eld of the Display Module Information display. If *NONE is specied in the eld, this module does not have a PEP. If a name is specied in the eld, this module has a PEP.
Export Parameter on the CRTSRVPGM Command

The export (EXPORT), source le (SRCFILE), and source member (SRCMBR) parameters identify the public interface to the service program being created. The parameters specify the exports (procedures and data) that a service program makes available for use by other ILE programs or service programs. The default value for the export parameter is *SRCFILE. That value directs the binder to the SRCFILE parameter for a reference to information about exports of the service program. This additional information is a source le with binder language source in it (see Binder Language on page 64). The binder locates the binder language source and, from the specied names to be exported, generates one or more signatures. The binder language also allows you to specify a signature of your choice instead of having the binder generate one. The Retrieve Binder Source (RTVBNDSRC) command can be used to create a source le that contains binder language source based on exports from a module or from a set of modules. The le created by the RTVBNDSRC command contains all symbols eligible to be exported from the modules, specied in the binder language syntax. You can edit this le to include only the symbols you want to export, then specify this le on the SRCFILE parameter of the CRTSRVPGM command. The other possible value for the export parameter is *ALL. When EXPORT(*ALL) is specied, all of the symbols exported from the copied modules are exported from the service program. The signature that gets generated is determined by the following: v The number of exported symbols v Alphabetical order of exported symbols If EXPORT(*ALL) is specied, no binder language is needed to dene the exports from a service program. This value is the easiest one to use because you do not have to generate the binder language source. However, a service program with EXPORT(*ALL) specied can be difficult to update or correct once the exports are used by other programs. If the service program is changed, the order or number of exports could change. Therefore, the signature of that service program could
61
change. If the signature changes, all programs or service programs that use the changed service program have to be re-created. EXPORT(*ALL) indicates that all symbols exported from the modules used in the service program are exported from the service program. ILE C/400 can dene exports as global or static. Only external variables declared in ILE C/400 as global are available with EXPORT(*ALL). In ILE RPG/400, the following are available with EXPORT(*ALL): v The RPG program name (not to be confused with *PGM object) v Variables dened with the keyword EXPORT In ILE COBOL/400, the following language elements are module exports: v The name in the PROGRAM-ID paragraph in the lexically outermost COBOL program (not to be confused with *PGM object) of a compilation unit. This maps to a strong procedure export. v The COBOL compiler-generated name derived from the name in the PROGRAM-ID paragraph in the preceding bullet if that program does not have the INITIAL attribute. This maps to a strong procedure export. For information about strong and weak exports, see Export in Import and Export Concepts on page 63. v Any data item or le item declared as EXTERNAL. This maps to a weak export.
Export Parameter Used with Source File and Source Member Parameters
The default value on the export parameter is *SRCFILE. If *SRCFILE is specied on the export parameter, the binder must also use the SRCFILE and SRCMBR parameters to locate the binder language source. The following example command binds a service program named UTILITY by using the defaults to locate the binder language source:
CRTSRVPGM SRVPGM(*CURLIB/UTILITY) MODULE(*SRVPGM) EXPORT(*SRCFILE) SRCFILE(*LIBL/QSRVSRC) SRCMBR(*SRVPGM)
For this command to create the service program, a member named UTILITY must be in the source le QSRVSRC. This member must then contain the binder language source that the binder translates into a signature and set of export identiers. The default is to get the binder language source from a member with the same name as the name of the service program, UTILITY. If a le, member, or binder language source with the values supplied on these parameters is not located, the service program is not created.
Maximum width of a le for the SRCFILE parameter

In V3R7 or later releases, the maximum width of a le for the Source File (SRCFILE) parameter on the CRTSRVPGM or UPDSRVPGM command is 240 characters. If the le is larger than the maximum width, message CPF5D07 appears. For V3R2, the maximum width is 80 characters. For V3R6, V3R1 and V2R3, there is no limit on the maximum width.
62
Import and Export Concepts

ILE languages support the following types of exports and imports: v Weak data exports v Weak data imports v Strong data exports v v v v Strong data imports Strong procedure exports Weak procedure exports Procedure imports
An ILE module object can export procedures or data items to other modules. And an ILE module object can import (reference) procedures or data items from other modules. When using a module object on CRTSRVPGM command to create a service program, its exports optionally export from the service program. (SeeExport Parameter on the CRTSRVPGM Command on page 61.) The strength (strong or weak) of an export depends on the programming language. The strength determines when enough is known about an export to set its characteristics, such as the size of a data item. A strong exports characteristics are set at bind time. The strength of the exports affects symbol resolution. v The binder uses the characteristics of the strong export, if one or more weak exports have the same name. v If a weak export does not have the same name as a strong export, you cannot set its characteristics until activation time. At activation time, if multiple weak exports with the same name exist, the program uses the largest one. This is true, unless an already activated weak export with the same name has already set its characteristics. v At bind time, if a binding directory is used, and weak exports are found to match weak imports, they will be bound. However, the binding directory only as long as there are unresolved imports to be resolved. Once all imports are resolved, the search through the binding directory entries stops. Duplicate weak exports are not agged as duplicate variables or procedures. The order of items in the binding directory is very important. You can export weak exports outside a program object or service program for resolution at activation time. This is opposed to strong exports that you export only outside a service program and only at bind time. You cannot, however, export strong exports outside a program object. You can export strong procedure exports outside a service program to satisfy either of the following at bind time: v Imports in a program that binds the service program by reference. v Imports in other service programs that are bound by reference to that program. Service programs dene their public interface through binding source language. You can make weak procedure exports part of the public interface for a service program through the binding source language. However, exporting a weak procedure export from the service program through the binding source language no longer marks it as weak. It is handled as a strong procedure export.
63
You can only export weak data to an activation group. You cannot make it part of the public interface that is exported from the service program through the use of binder source language. Specifying a weak data in the binder source language causes the bind to fail. Table 4 summarizes the types of imports and exports that are supported by some of the ILE languages:
Table 4. Imports and Exports Supported by ILE Languages
ILE Weak Languages Data Exports RPG IV COBOL CL C C++ Note: 1. COBOL and CL allow only one procedure to be exported from the module. 2. COBOL uses the weak data model. Data items that are declared as external become both weak exports and weak imports for that module. 3. COBOL requires the nomonocase option. Without this option, the lowercase letters are automatically converted to uppercase.
2
Weak Data Imports No

3
Strong Data Exports Yes No No Yes Yes
Strong Data Imports Yes No No Yes Yes
Strong Weak Procedure Procedure Procedure Imports Exports Exports Yes Yes
1 1
No Yes No No No
3
No No No No Yes
Yes Yes Yes Yes Yes
Yes No No No
Yes Yes Yes
For information on which declarations become imports and exports for a particular language, see one of the following books: v Licensed Information Document: ILE RPG for AS/400, GI10-4931 v Licensed Information Document: ILE COBOL for AS/400, GI10-4932 v CL Reference (Abridged) v Licensed Information Document: ILE C for AS/400, GI10-4933
Binder Language
The binder language is a small set of nonrunnable commands that denes the exports for a service program. The binder language enables the source entry utility (SEU) syntax checker to prompt and validate the input when a BND source type is specied. Note: You cannot use the SEU syntax checking type BND for a binder source le that contains wildcarding. You also cannot use it for a binder source le that contains names longer than 254 characters. The binder language consists of a list of the following commands: 1. Start Program Export (STRPGMEXP) command, which identies the beginning of a list of exports from a service program 2. Export Symbol (EXPORT) commands, each of which identies a symbol name available to be exported from a service program 3. End Program Export (ENDPGMEXP) command, which identies the end of a list of exports from a service program
64
Figure 35 is a sample of the binder language in a source le:

STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES) . . EXPORT SYMBOL(p1) EXPORT SYMBOL('p2') EXPORT SYMBOL('P3') . . ENDPGMEXP . . . STRPGMEXP PGMLVL(*PRV) . . EXPORT SYMBOL(p1) EXPORT SYMBOL('p2') . . ENDPGMEXP
Figure 35. Example of Binder Language in a Source File
The Retrieve Binder Source (RTVBNDSRC) command can be used to help generate the binder language source based on exports from one or more modules.
Signature
The symbols identied between a STRPGMEXP PGMLVL(*CURRENT) and ENDPGMEXP pair dene the public interface to a service program. That public interface is represented by a signature. A signature is a value that identies the interface supported by a service program. If you choose not to specify an explicit signature, the binder generates a signature from the list of procedure and data item names to be exported and from the order in which they are specied. Therefore, a signature provides an easy and convenient way to validate the public interface to a service program. A signature does not validate the interface to a particular procedure within a service program. Note: To avoid making incompatible changes to a service program, existing procedure and data item names must not be removed or rearranged in the binder language source. Additional export blocks must contain the same symbols in the same order as existing export blocks. Additional symbols must be added only to the end of the list. There is no way to remove a service program export in a way compatible with existing programs and service programs because that export may be needed by programs or service programs bound to that service program. If an incompatible change is made to a service program, exiting programs that remain bound to it may no longer work correctly. An incompatible change to a service program can be made only if it can be guaranteed that all programs and service programs bound to it are re-created with CRTPGM or CRTSRVPGM after the incompatible change is made.
65
Start Program Export and End Program Export Commands

The Start Program Export (STRPGMEXP) command identies the beginning of a list of exports from a service program. The End Program Export (ENDPGMEXP) command identies the end of a list of exports from a service program. Multiple STRPGMEXP and ENDPGMEXP pairs specied within a source le cause multiple signatures to be created. The order in which the STRPGMEXP and ENDPGMEXP pairs occur is not signicant.
Program Level Parameter on the STRPGMEXP Command

Only one STRPGMEXP command can specify PGMLVL(*CURRENT), but it does not have to be the rst STRPGMEXP command. All other STRPGMEXP commands within a source le must specify PGMLVL(*PRV). The current signature represents whichever STRPGMEXP command has PGMLVL(*CURRENT) specied. If more than one of the STRPGMEXP commands is marked *CURRENT, the rst one is assumed to be the current one. That command is represented by the current signature.
Level Check Parameter on the STRPGMEXP Command

The level check (LVLCHK) parameter on the STRPGMEXP command species whether the binder should automatically check the public interface to a service program. Specifying LVLCHK(*YES), or letting the value default to LVLCHK(*YES), causes the binder to examine the signature parameter. The signature parameter determines whether the binder uses an explicit signature value or generates a nonzero signature value. If the binder generates a signature value, the system veries that the value matches the value known to the service programs clients. If the values match, clients of the service program can use the public interface without being recompiled. Specifying LVLCHK(*NO) disables the automatic signature checking. You may decide to use this feature if the following conditions exist: v You know that certain changes to the interface of a service program do not constitute incompatibilities. v You want to avoid updating the binder language source le or recompiling clients. Use the LVLCHK(*NO) value with caution because it means that you are responsible for manually verifying that the public interface is compatible with previous levels. Specify LVLCHK(*NO) only if you can control which procedures of the service program are called and which variables are used by its clients. If you cannot control the public interface, run-time or activation errors may occur. See Binder Language Errors of Appendix A for an explanation of the common errors that could occur from using the binder language.
Signature Parameter on the STRPGMEXP Command

The signature (SIGNATURE) parameter allows you to explicitly specify a signature for a service program. The explicit signature can be a hexadecimal string or a character string. You may want to consider explicitly specifying a signature for either of the following reasons: v The binder could generate a compatible signature that you do not want. A signature is based on the names of the specied exports and on their order. Therefore, if two export blocks have the same exports in the same order, they have the same signature. As the service program provider, you may know that
66
the two interfaces are not compatible (because, for example, their parameter lists are different). In this case, you can explicitly specify a new signature instead of having the binder generate the compatible signature. If you do so, you create an incompatibility in your service program, forcing some or all clients to recompile. v The binder could generate an incompatible signature that you do not want. If two export blocks have different exports or a different order, they have different signatures. If, as the service program provider, you know that the two interfaces are really compatible (because, for example, a function name has changed but it is still the same function), you can explicitly specify the same signature as previously generated by the binder instead of having the binder generate an incompatible signature. If you specify the same signature, you maintain a compatibility in your service program, allowing your clients to use your service program without rebinding. The default value for the signature parameter, *GEN, causes the binder to generate a signature from exported symbols. You can determine the signature value for a service program by using the Display Service Program (DSPSRVPGM) command and specifying DETAIL(*SIGNATURE).
Export Symbol Command

The Export Symbol (EXPORT) command identies a symbol name available to be exported from a service program. If the exported symbols contain lowercase letters, the symbol name should be enclosed within apostrophes as in Figure 35 on page 65. If apostrophes are not used, the symbol name is converted to all uppercase letters. In the example, the binder searches for an export named P1, not p1. Symbol names can also be exported through the use of wildcard characters (<<< or >>>). If a symbol name exists and matches the wildcard specied, the symbol name is exported. If any of the following conditions exists, an error is signaled and the service program is not created: v No symbol name matches the wildcard specied v More than one symbol name matches the wildcard specied v A symbol name matches the wildcard specied but is not available for export Substrings in the wildcard specication must be enclosed within quotation marks. Signatures are determined by the characters in wildcard specications. Changing the wildcard specication changes the signature even if the changed wildcard specication matches the same export. For example, the two wildcard specications r>>> and ra>>> both export the symbol rate but they create two different signatures. Therefore, it is strongly recommended that you use a wildcard specication that is as similar to the export symbol as possible. Note: You cannot use the SEU syntax checking type BND for a binder source le that contains wildcarding.
Wildcard Export Symbol Examples

For the following examples, assume that the symbol list of possible exports consists of:
67
interest_rate international prime_rate The following examples show which export is chosen or why an error occurs: EXPORT SYMBOL (interest>>>) Exports the symbol interest_rate because it is the only symbol that begins with interest. EXPORT SYMBOL (i>>>rate>>>) Exports the symbol interest_rate because it is the only symbol that begins with i and subsequently contains rate. EXPORT SYMBOL (<<<i>>>rate) Results in a Multiple matches for wildcard specication error. Both prime_rate and interest_rate contain an i and subsequently end in rate. EXPORT SYMBOL (inter>>>prime) Results in a No matches for wildcard specication error. No symbol begins with inter and subsequently ends in prime. EXPORT SYMBOL (<<<) Results in a Multiple matches for wildcard specication error. This symbol matches all three symbols and therefore is not valid. An export statement can result in only one exported symbol.
Binder Language Examples

As an example of using the binder language, assume that you are developing a simple nancial application with the following procedures: v Rate procedure Calculates an Interest_Rate, given the values of Loan_Amount, Term_of_Payment, and Payment_Amount. v Amount procedure Calculates the Loan_Amount, given the values of Interest_Rate, Term_of_Payment, and Payment_Amount. v Payment procedure Calculates the Payment_Amount, given the values of Interest_Rate, Term_of_Payment, and Loan_Amount. v Term procedure Calculates the Term_of_Payment, given the values of Interest_Rate, Loan_Amount, and Payment_Amount. Some of the output listings for this application are shown in Appendix A. Output Listing from CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM. In the binder language examples, each module contains more than one procedure. This structure is more typical of ILE C/400 than of ILE RPG/400, but the examples apply even to modules that contain only one procedure.
Binder Language Example 1

The binder language for the Rate, Amount, Payment, and Term procedures looks like the following:
68
FILE: MYLIB/QSRVSRC
MEMBER: FINANCIAL
STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') ENDPGMEXP
Some initial design decisions have been made, and three modules (MONEY, RATES, and CALCS) provide the necessary procedures. To create the service program pictured in Figure 36, the binder language is specied on the following CRTSRVPGM command:
CRTSRVPGM SRVPGM(MYLIB/FINANCIAL) MODULE(MYLIB/MONEY MYLIB/RATES MYLIB/CALCS) EXPORT(*SRCFILE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(*SRVPGM)
Note that source le QSRVSRC in library MYLIB, specied in the SRCFILE parameter, is the le that contains the binder language source. Also note that no binding directory is needed because all the modules needed to create the service program are specied on the MODULE parameter.
Service Program MYLIB/FINANCIAL Public Interface Term Rate Amount Payment
Module MONEY
Procedure Amount Procedure Payment
Module RATES Procedure Term Procedure Rate Module CALCS Procedure CALC1 Procedure CALC2
Current Signature = Sig 123
RV2W1051-3
Figure 36. Creating a Service Program by Using the Binder Language
69

As progress is made in developing the application, a program called BANKER is written. BANKER needs to use the procedure called Payment in the service program called FINANCIAL. The resulting application with the BANKER program is shown in Figure 37.
Public Interface
Program BANKER
Service Program MYLIB/FINANCIAL Term Rate
Module M1
CallPrc Payment
Amount Payment
Module MONEY
Procedure Amount Procedure Payment Module RATES

MYLIB/FINANCIAL Payment = 4th slot Signature = Sig 123
Procedure Term Procedure Rate Module CALCS Procedure CALC1 Procedure CALC2
Current Signature = Sig 123
RV2W1053-4
Figure 37. Using the Service Program FINANCIAL
When the BANKER program was created, the MYLIB/FINANCIAL service program was provided on the BNDSRVPGM parameter. The symbol Payment was found to be exported from the fourth slot of the public interface of the FINANCIAL service program. The current signature of MYLIB/FINANCIAL along with the slot associated with the Payment interface is saved with the BANKER program. During the process of getting BANKER ready to run, activation veries the following: v Service program FINANCIAL in library MYLIB can be found. v The service program still supports the signature (SIG 123) saved in BANKER. This signature checking veries that the public interface used by BANKER when it was created is still valid at run time.
70
As shown in Figure 37 on page 70, at the time BANKER gets called, MYLIB/FINANCIAL still supports the public interface used by BANKER. If activation cannot nd either a matching signature in MYLIB/FINANCIAL or the service program MYLIB/FINANCIAL, the following occurs: BANKER fails to get activated. An error message is issued.

As the application continues to grow, two new procedures are needed to complete our nancial package. The two new procedures, OpenAccount and CloseAccount, open and close the accounts, respectively. The following steps need to be performed to update MYLIB/FINANCIAL such that the program BANKER does not need to be re-created: 1. Write the procedures OpenAccount and CloseAccount. 2. Update the binder language to specify the new procedures. The updated binder language supports the new procedures. It also allows the existing ILE programs or service programs that use the FINANCIAL service program to remain unchanged. The binder language looks like this:
FILE: MYLIB/QSRVSRC MEMBER: FINANCIAL STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') EXPORT SYMBOL('OpenAccount') EXPORT SYMBOL('CloseAccount') ENDPGMEXP STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') ENDPGMEXP
When an update operation to a service program is needed to do both of the following: v Support new procedures or data items v Allow the existing programs and service programs that use the changed service program to remain unchanged one of two alternatives must be chosen. The rst alternative is to perform the following steps: 1. Duplicate the STRPGMEXP, ENDPGMEXP block that contains PGMLVL(*CURRENT). 2. Change the duplicated PGMLVL(*CURRENT) value to PGMLVL(*PRV). 3. In the STRPGMEXP command that contains PGMLVL(*CURRENT), add to the end of the list the new procedures or data items to be exported. 4. Save the changes to the source le. 5. Create or re-create the new or changed modules. 6. Create the service program from the new or changed modules by using the updated binder language.
71
The second alternative is to take advantage of the signature parameter on the STRPGMEXP command and to add new symbols at the end of the export block:
STRPGMEXP PGMVAL(*CURRENT) SIGNATURE('123') EXPORT SYMBOL('Term') . . . EXPORT SYMBOL('OpenAccount') EXPORT SYMBOL('CloseAccount') ENDPGMEXP
To create the enhanced service program shown in Figure 38, the updated binder language specied on page 71 is used on the following CRTSRVPGM command:
CRTSRVPGM SRVPGM(MYLIB/FINANCIAL) MODULE(MYLIB/MONEY MYLIB/RATES MYLIB/CALCS MYLIB/ACCOUNTS)) EXPORT(*SRCFILE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(*SRVPGM)
Public Interface
Program BANKER
Service Program MYLIB/FINANCIAL Term Rate
Module M1
CallPrc Payment
Amount Payment OpenAccount CloseAccount
MYLIB/FINANCIAL Payment = 4th slot Signature = Sig 123
Module Money Procedure Amount Procedure Payment Module RATES Procedure Term Procedure Rate
Module CALCS Procedure CALC1 Procedure CALC2

Module ACCOUNTS
Procedure OpenAccount Procedure CloseAccount
Current Signature = Sig 456 Previous Signature = Sig 123

RV2W1052-4
Figure 38. Updating a Service Program by Using the Binder Language
72
The BANKER program does not have to change because the previous signature is still supported. (See the previous signature in the service program MYLIB/FINANCIAL and the signature saved in BANKER.) If BANKER were re-created by the CRTPGM command, the signature that is saved with BANKER would be the current signature of service program FINANCIAL. The only reason to re-create the program BANKER is if the program used one of the new procedures provided by the service program FINANCIAL. The binder language allows you to enhance the service program without changing the programs or service programs that use the changed service program.

After shipping the updated FINANCIAL service program, you receive a request to create an interest rate based on the following: The current parameters of the Rate procedure The credit history of the applicant A fth parameter, called Credit_History, must be added on the call to the Rate procedure. Credit_History updates the Interest_Rate parameter that gets returned from the Rate procedure. Another requirement is that existing ILE programs or service programs that use the FINANCIAL service program must not have to be changed. If the language does not support passing a variable number of parameters, it seems difficult to do both of the following: v Update the service program v Avoid re-creating all the other objects that use the FINANCIAL service program Fortunately, however, there is a way to do this. The following binder language supports the updated Rate procedure. It still allows existing ILE programs or service programs that use the FINANCIAL service program to remain unchanged.
FILE: MYLIB/QSRVSRC MEMBER: FINANCIAL STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL('Term') EXPORT SYMBOL('Old_Rate') /* Original Rate procedure with four parameters */ EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') EXPORT SYMBOL('OpenAccount') EXPORT SYMBOL('CloseAccount') EXPORT SYMBOL('Rate') /* New Rate procedure that supports + a fifth parameter, Credit_History */ ENDPGMEXP STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') EXPORT SYMBOL('OpenAccount') EXPORT SYMBOL('CloseAccount') ENDPGMEXP STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') ENDPGMEXP
The original symbol Rate was renamed Old_Rate but remains in the same relative position of symbols to be exported. This is important to remember.
73
A comment is associated with the Old_Rate symbol. A comment is everything between /* and */. The binder ignores comments in the binder language source when creating a service program. The new procedure Rate, which supports the additional parameter of Credit_History, must also be exported. This updated procedure is added to the end of the list of exports. The following two ways can deal with the original Rate procedure: v Rename the original Rate procedure that supports four parameters as Old_Rate. Duplicate the Old_Rate procedure (calling it Rate). Update the code to support the fth parameter of Credit_History. v Update the original Rate procedure to support the fth parameter of Credit_History. Create a new procedure called Old_Rate. Old_Rate supports the original four parameters of Rate. It also calls the new updated Rate procedure with a dummy fth parameter. This is the preferred method because maintenance is simpler and the size of the object is smaller. Using the updated binder language and a new RATES module that supports the procedures Rate, Term, and Old_Rate, you create the following FINANCIAL service program:
74
Public Interface
Service Program MYLIB/FINANCIAL
Term Old_Rate Amount Payment OpenAccount CloseAccount Rate
Module MONEY Procedure Amount Procedure Payment

Module ACCOUNTS
Module RATES Procedure Term Procedure Old_Rate Procedure Rate
Current Signature = Sig 789 Previous Signatures = Sig 456, Sig 123
RV2W1055-2
Figure 39. Updating a Service Program by Using the Binder Language
The ILE programs and service programs that use the original Rate procedure of the FINANCIAL service program go to slot 2. This directs the call to the Old_Rate procedure, which is advantageous because Old_Rate handles the original four parameters. If any of the ILE programs or service programs that used the original Rate procedure need to be re-created, do one of the following: v To continue to use the original four-parameter Rate procedure, call the Old_Rate procedure instead of the Rate procedure. v To use the new Rate procedure, add the fth parameter, Credit_History, to each call to the Rate procedure. When an update to a service program must meet the following requirements: v Support a procedure that changed the number of parameters it can process v Allow existing programs and service programs that use the changed service program to remain unchanged the following steps need to be performed:
75
1. Duplicate the STRPGMEXP, ENDPGMEXP block that contains PGMLVL(*CURRENT). 2. Change the duplicated PGMLVL(*CURRENT) value to PGMLVL(*PRV). 3. In the STRPGMEXP command that contains PGMLVL(*CURRENT), rename the original procedure name, but leave it in the same relative position. In this example, Rate was changed to Old_Rate but left in the same relative position in the list of symbols to be exported. 4. In the STRPGMEXP command that has PGMLVL(*CURRENT), place the original procedure name at the end of the list that supports a different number of parameters. In this example, Rate is added to the end of the list of exported symbols, but this Rate procedure supports the additional parameter Credit_History. 5. Save the changes to the binder language source le. 6. In the le containing the source code, enhance the original procedure to support the new parameter. In the example, this means changing the existing Rate procedure to support the fth parameter of Credit_History. 7. A new procedure is created that handles the original parameters as input and calls the new procedure with a dummy extra parameter. In the example, this means adding the Old_Rate procedure that handles the original parameters and calling the new Rate procedure with a dummy fth parameter. 8. Save the binder language source code changes. 9. Create the module objects with the new and changed procedures. 10. Create the service program from the new and changed modules using the updated binder language.
Changing Programs: The Change Program (CHGPGM) command changes the attributes of a program without requiring recompiling. Some of the changable attributes follow: v The optimization attribute. v The user prole attribute.
v v v v Use adopted authority attribute. The performance collection attribute. The proling data attribute. The program text.
The user can also force re-creation of a program even if the specied attributes are the same as the current attributes. Do this by specifying the force program re-creation (FRCCRT) parameter. | | | | | | | | | Re-creating a program with CHGPGM or CHGSRVPGM while one or more jobs is using it causes an Object Destroyed exception to occur. With the new value, *NOCRT, you can prevent this from inadvertently happening. With this new value you can do a CHGCMDDFT to default FRCCRT to *NOCRT. If any parameters are changed on CHGPGM or CHGSRVPGM that may cause a re-create, specify *NOCRT. A DEP statement in the command denition of CHGPGM and CHGSRVPGM will detect the condition, and no programs changes will occur. At this point you can change the FRCCRT parameter value to either *YES or *NO to get the same results. If you remove any observability, or change the text description,
76
| | |
you will not need to re-create the program object. If that is the case, FRCCRT(*NOCRT) will work as FRCCRT(*NO). For compatability, IBM does not ship *NOCRT as the default. Other jobs running the program may fail by changing any of the parameters that are listed below: v v v v v The The The The The Optimize program prompt (OPTIMIZE parameter). Use adopted authority prompt (USEADPAUT parameter). Enable performance collection prompt (ENBPFRCOL parameter). Proling data prompt (PRFDTA parameter). User prole prompt (USRPRF parameter).
Additionally, forcing a program re-creation by specifying FRCCRT(*YES) may cause other jobs running the program that is being changed to fail.
Program Updates
After an ILE program object or service program is created, you may have to correct an error in it or add an enhancement to it. However, after you service the object, it may be so large that shipping the entire object to your customers is difficult or expensive. You can reduce the shipment size by using the Update Program (UPDPGM) or Update Service Program (UPDSRVPGM) command. These commands replace only the specied modules, and only the changed or added modules have to be shipped to your customers. If you use the PTF process, an exit program containing one or more calls to the UPDPGM or UPDSRVPGM commands can be used to do the update functions. Binding the same module to multiple program objects or service programs requires running the UPDPGM or UPDSRVPGM command against each *PGM and *SRVPGM object. For example, Figure 40 on page 78
77
Public Interface
Service Program MYLIB/FINANCIAL
Term Old_Rate Amount Payment OpenAccount CloseAccount Rate Module MONEY Procedure Amount Module MONEY Procedure Payment Procedure Amount Procedure Payment

Module ACCOUNTS
Module RATES Procedure Term Procedure Old_Rate Procedure Rate
Current Signature = Sig 789 Previous Signatures = Sig 456, Sig 123
RV3W105-0
Figure 40. Replacing a Module in a Service Program
Be careful not to update a program or service program while the program remains activated in another job. Otherwise, updates to that job remain inactive until the reclaimed by activation or signoff. The allow update (ALWUPD) and allow *SRVPGM library update (ALWLIBUPD) parameters on the CRTPGM or CRTSRVPGM command determine whether a program object or service program can be updated. By specifying ALWUPD(*NO), the modules in a program object or service program cannot be replaced by the UPDPGM or UPDSRVPGM command. By specifying ALWUPD(*YES) and ALWLIBUPD(*YES), you can update your program to use a service program from a library that was not previously specied. By specifying ALWUPD(*YES) and ALWLIBUPD(*NO), you can update the modules, but not the bound service program library. You can not specify ALWUPD(*NO) and ALWLIBUPD(*YES) at the same time.
78
Parameters on the UPDPGM and UPDSRVPGM Commands

Each module specied on the module parameter replaces a module with the same name that is bound into a program object or service program. If more than one module bound into a program object or service program has the same name, the replacement library (RPLLIB) parameter is used. This parameter species which method is used to select the module to be replaced. If no module with the same name is already bound into a program object or service program, the program object or service program is not updated. The bound service program (BNDSRVPGM) parameter species additional service programs beyond those that the program object or service program is already bound to. If a replacing module contains more imports or fewer exports than the module it replaces, these service programs may be needed to resolve those imports. With the service program library (SRVPGMLIB) parameter, you can specify the library that stores the bound service program. Each time you run the UPDPGM or UPDSRVPGM commands, the updated bound service program from the specied library is used. You can also change the library name when activating the program. The UPDPGM or UPDSRVPGM command allows you to change library if ALWLIBUPD(*YES) is used. The binding directory (BNDDIR) parameter species binding directories that contain modules or service programs that also may be required to resolve extra imports. The activation group (ACTGRP) parameter species the activation group name to be used when you transfer an ILE application to AS/400. This parameter also allows you to change the activation group name when you activate a program or service program. The change is ony allowed for a named activation group.
Module Replaced by a Module with Fewer Imports

If a module is replaced by another module with fewer imports, the new program object or service program is always created. However, the updated program object or service program contains an isolated module if the following conditions exist: v Because of the now missing imports, one of the modules bound into a program object or service program no longer resolves any imports v That module originally came from a binding directory used on the CRTPGM or CRTSRVPGM command Programs with isolated modules may grow signicantly over time. To remove modules that no longer resolve any imports and that originally came from a binding directory, you can specify OPTION(*TRIM) when updating the objects. However, if you use this option, the exports that the modules contain are not available for future program updates.
Module Replaced by a Module with More Imports

If a module is replaced by a module with more imports, the program object or service program can be updated if those extra imports are resolved, given the following: v The existing set of modules bound into the object. v Service programs bound to the object.
79
v Binding directories specied on the command. If a module in one of these binding directories contains a required export, the module is added to the program or service program. If a service program in one of these binding directories contains a required export, the service program is bound by reference to the program or service program. v Implicit binding directories. An implicit binding directory is a binding directory that contains exports that may be needed to create a program that contains the module. Every ILE compiler builds a list of implicit binding directories into each module it creates. If those extra imports cannot be resolved, the update operation fails unless OPTION(*UNRSLVREF) is specied on the update command.
Module Replaced by a Module with Fewer Exports

If a module is replaced by another module with fewer exports, the update occurs if the following conditions exist: v The missing exports are not needed for binding. v The missing exports are not exported out of the service program in the case of UPDSRVPGM. The service program export is different if EXPORT(*ALL) is specied. The update does not occur if the following conditions exist: v Some imports cannot be resolved because of the missing exports. v Those missing exports cannot be found from the extra service programs and binding directories specied on the command. v The binder language indicates to export a symbol, but the export is missing.
Module Replaced by a Module with More Exports

If a module is replaced by another module with more exports, the update operation occurs if all the extra exports are uniquely named. The service program export is different if EXPORT(*ALL) is specied. However, if one or more of the extra exports are not uniquely named, the duplicate names may cause a problem: v If OPTION(*NODUPPROC) or OPTION(*NODUPVAR) is specied on the update command, the program object or service program is not updated. v If OPTION(*DUPPROC) or OPTION(*DUPVAR) is specied, the update occurs, but the export with the duplicate name selected for binding may be different. If the module being replaced was specied on the CRTPGM or CRTSRVPGM command before the object that contains the selected export, the selected export is selected. (If the data item is weak, it still may not be selected.)
Tips for Creating Modules, Programs, and Service Programs

To create and maintain modules, ILE programs, and service programs conveniently, consider the following: v Follow a naming convention for the modules that will get copied to create a program or service program. A naming strategy with a common prex makes it easier to specify modules generically on the module parameter.
80
v For ease of maintenance, include each module in only one program or service program. If more than one program needs to use a module, put the module in a service program. That way, if you have to redesign a module, you only have to redesign it in one place. v To ensure your signature, use the binder language whenever you create a service program. The binder language allows the service program to be easily updated without having to re-create the using programs and service programs. The Retrieve Binder Source (RTVBNDSRC) command can be used to help generate the binder language source based on exports from one or more modules. If either of the following conditions exists: A service program will never change Users of the service program do not mind changing their programs when a signature changes you do not need to use the binder language. Because this situation is not likely for most applications, consider using the binder language for all service programs. v If other people will use a program object or service program that you create, specify OPTION(*RSLVREF) when you create it. When you are developing an application, you may want to create a program object or service program with unresolved imports. However, when in production, all the imports should be resolved. If OPTION(*WARN) is specied, unresolved references are listed in the job log that contains the CRTPGM or CRTSRVPGM request. If you specify a listing on the DETAIL parameter, they are also included on the program listing. You should keep the job log or listing. v When designing new applications, determine if common procedures that should go into one or more service programs can be identied. It is probably easiest to identify and design common procedures for new applications. If you are converting an existing application to use ILE, it may be more difficult to determine common procedures for a service program. Nevertheless, try to identify common procedures needed by the application and try to create service programs containing the common procedures. v When converting an existing application to ILE, consider creating a few large programs. With a few, usually minor changes, you can easily convert an existing application to take advantage of the ILE capabilities. After you create the modules, combining them into a few large programs may be the easiest and least expensive way to convert to ILE. Using a few large programs rather than many small programs has the additional advantage of using less storage. v Try to limit the number of service programs your application uses. This may require a service program to be created from more than one module. The advantages are a faster activation time and a faster binding process. There are very few right answers for the number of service programs an application should use. If a program uses hundreds of service programs, it is probably using too many. On the other hand, one service program may not be practical either. As an example, approximately 10 service programs are provided for the language-specic and common run-time routines provided by the OS/400. Over
81
70 modules went into creating these 10 service programs. This ratio seems to be a good balance for performance, understandability, and maintainability.
82
Chapter 5. Activation Group Management

This chapter contains examples of how to structure an application using activation groups. Topics include: v Supporting multiple applications v Using the Reclaim Resources (RCLRSC) command with OPM and ILE programs v Deleting activation groups with the Reclaim Activation Group (RCLACTGRP) command v Service programs and activation groups
Multiple Applications Running in the Same Job

User-named activation groups allow you to leave an activation group in a job for later use. A normal return operation or a skip operation (such as longjmp() in ILE C/400) past the control boundary does not delete your activation group. This allows you to leave your application in its last-used state. Static variables and open les remain unchanged between calls into your application. This can save processing time and may be necessary to implement the function you are trying to provide. You should be prepared, however, to accept requests from multiple independent clients running in the same job. The system does not limit the number of ILE programs that can be bound to your ILE service program. As a result, you may need to support multiple clients. Figure 41 on page 84 shows a technique that you may use to share common service functions while keeping the performance advantages of a user-named activation group.
83
Activation Group A1 ILE User One Program A CALLPRC P1 ID=ONE Activation Group A3 ILE Service Program X Procedure P1
. . .
Procedure P10 Static Storage Activation Group A2 ILE User Two Program B CALLPRC P1 ID=TWO ID=ONE U1, U2,... ID=TWO U1, U2,... Variables
RV2W1042-0
Figure 41. Multiple Applications Running in the Same Job
Each call to a procedure in service program X requires a user handle. The eld ID represents a user handle in this example. Each user is responsible for providing this handle. An initialization routine to return a unique handle for each user is implemented by you. When a call is made to your service program, the user handle is used to locate the storage variables that relate to this user. While saving activation-group creation time, you can support multiple clients at the same time.
Reclaim Resources Command

The Reclaim Resources (RCLRSC) command depends on a system concept known as a level number. A level number is a unique value assigned by the system to certain resources you use within a job. Three level numbers are dened as follows: Call level number Each call stack entry is given a unique level number Program-activation level number Each OPM and ILE program activation is given a unique level number Activation-group level number Each activation group is given a unique level number As your job runs, the system continues to assign unique level numbers for each new occurrence of the resources just described. The level numbers are assigned in increasing value. Resources with higher level numbers are created after resources with lower level numbers. Figure 42 on page 85 shows an example of using the RCLRSC command on OPM and ILE programs. Call-level scoping has been used for the open les shown in this
84
example. When call-level scoping is used, each data management resource is given the same level numbers as the call stack entry that created that resource.
Default Activation Group Call Stack OPM Program A Number 102 OPM Program B RCLRSC LVL(*) Number 104 OPM Program C Number 106 ILE Program D Number 108 Shared ODP F1 Number 108 ODP F3 Number 106 ODP F2 Number 104 ODP F1 Number 102
OPM Program A Activation Number 101 OPM Program B Activation Number 103 OPM Program C Activation Number 105 ILE Program D Activation Number 107 *DFTACTGRP Activation Group A1 ILE Program A Activation Number 199
ILE PEP P1 Number 200 ILE UEP P2 Number 201

RV3W100-0
Figure 42. Reclaim Resources
In this example, the calling sequence is programs A, B, C, and D. Programs D and C return to program B. Program B is about to use the RCLRSC command with an option of LVL(*). The RCLRSC command uses the level (LVL) parameter to clean up resources. All resources with a call-level number greater than the call-level number of the current call stack entry are cleaned up. In this example, call-level number 104 is used as the starting point. All resources greater than call-level number 104 are deleted. Note that resouces in call level 200 and 201 are unaffected by RCLRSC because they are in an ILE activation group. RCLRSC works only in the default activation group.
85
In addition, the storage from programs C and D and the open data path (ODP) for le F3 is closed. File F1 is shared with the ODP opened in program A. The shared ODP is closed, but le F1 remains open.
Reclaim Resources Command for OPM Programs

The Reclaim Resources (RCLRSC) command may be used to close open les and free static storage for OPM programs that have returned without ending. Some OPM languages, such as RPG, allow you to return without ending the program. If you later want to close the programs les and free its storage, you may use the RCLRSC command.
Reclaim Resources Command for ILE Programs

For ILE programs that are created by the CRTBNDxxx command with DFTACTGRP(*YES) specied, the RCLRSC command frees static storage just as it does for OPM programs. For ILE programs that are not created by the CRTBNDxxx command with DFTACTGRP(*YES) specied, the RCLRSC command reinitializes any activations that have been created in the default activation group but does not free static storage. ILE programs that use large amounts of static storage should be activated in an ILE activation group. Deleting the activation group returns this storage to the system. The RCLRSC command closes les opened by service programs or ILE programs running in the default activation group. The RCLRSC command does not reinitialize static storage of service programs and does not affect nondefault activation groups. To use the RCLRSC command directly from ILE, you can use either the QCAPCMD API or an ILE CL procedure. The QCAPCMD API allows you to directly call system commands without the use of a CL program. In Figure 42 on page 85, directly calling system commands is important because you may want to use the call-level number of a particular ILE procedure. Certain languages, such as ILE C/400, also provide a system function that allows direct running of OS/400 commands.
Reclaim Activation Group Command

The Reclaim Activation Group (RCLACTGRP) command can be used to delete a nondefault activation group that is not in use. This command allows options to either delete all eligible activation groups or to delete an activation group by name.
Service Programs and Activation Groups

When you create an ILE service program, decide whether to specify an option of *CALLER or a name for the ACTGRP parameter. This option determines whether your service program will be activated into the callers activation group or into a separately named activation group. Either choice has advantages and disadvantages. This topic discusses what each option provides. For the ACTGRP(*CALLER) option, the service program functions as follows: v Static procedure calls are fast Static procedure calls into the service program are optimized when running in the same activation group. v Shared external data
86
Service programs may export data to be used by other programs and service programs in the same activation group. v Shared data management resources Open les and other data management resources may be shared between the service program and other programs in the activation group. The service program may issue a commit operation or a rollback operation that affects the other programs in the activation group. v No control boundary Unhandled exceptions within the service program percolate to the client programs. HLL end verbs used within the service program can delete the activation group of the client programs. For the ACTGRP(name) option, the service program functions as follows: v Separate address space for variables The client program cannot manipulate pointers to address your working storage. This may be important if your service program is running with adopted authority. v Separate data management resources You have your own open les and commitment denitions. The accidental sharing of open les is prevented. v State information controlled You control when the application storage is deleted. By using HLL end verbs or normal language return statements, you can decide when to delete the application. You must, however, manage the state information for multiple clients.
87
88
Chapter 6. Calls to Procedures and Programs

The ILE call stack and argument-passing methods facilitate interlanguage communication, making it easier for you to write mixed-language applications. This chapter discusses different examples of dynamic program calls and static procedure calls, which were introduced in Calls to Programs and Procedures on page 21. A third type of call, the procedure pointer call, is introduced. In addition, this chapter discusses original program model (OPM) support for OPM and ILE application programming interfaces (APIs).
Call Stack
The call stack is a last-in-rst-out (LIFO) list of call stack entries, one entry for each called procedure or program. Each call stack entry has information about the automatic variables for the procedure or program and about other resources scoped to the call stack entry, such as condition handlers and cancel handlers. There is one call stack per job. A call adds a new entry on the call stack for the called procedure or program and passes control to the called object. A return removes the stack entry and passes control back to the calling procedure or program in the previous stack entry.
Call Stack Example

Figure 43 on page 90 contains a segment of a call stack with two programs: an OPM program (Program A) and an ILE program (Program B). Program B contains three procedures: its program entry procedure, its user entry procedure, and another procedure (P1). The concepts of program entry procedure (PEP) and user entry procedure (UEP) are dened in Module Object on page 12. The call ow includes the following steps: 1. A dynamic program call to Program A. 2. Program A calls Program B, passing control to its PEP. This call to Program B is a dynamic program call. 3. The PEP calls the UEP. This is a static procedure call. 4. The UEP calls procedure P1. This is a static procedure call.
89
Call Stack OPM Program A OPM
ILE Program B Module M1 Program Entry Procedure ILE
Dynamic Program Call Program Entry Procedure Static Procedure Call ILE
User Entry Procedure
User Entry Procedure Static Procedure Call
Module M2 Procedure P1 Procedure P1
RV2W1034-1
Figure 43. Dynamic Program Calls and Static Procedure Calls on the Call Stack
Figure 43 illustrates the call stack for this example. The most recently called entry on the stack is depicted at the bottom of the stack. It is the entry that is currently processing. The current call stack entry may do either of the following: v Call another procedure or program, which adds another entry to the bottom of the stack. v Return control to its caller after it is done processing, which removes itself from the stack. Assume that, after procedure P1 is done, no more processing is needed from Program B. Procedure P1 returns control to the UEP, and P1 is removed from the stack. Then the UEP returns control to the PEP, and the UEP is removed from the stack. Finally, the PEP returns control to Program A, and the PEP is removed from the stack. Only Program A is left on this segment of the call stack. Program A continues processing from the point where it made the dynamic program call to Program B.
Calls to Programs and Calls to Procedures

Three types of calls can be made during ILE run time: dynamic program calls, static procedure calls, and procedure pointer calls. When an ILE program is activated, all of its procedures except its PEP become available for static procedure calls and procedure pointer calls. Program activation occurs when the program is called by a dynamic program call and the activation does not already exist. When a program is activated, all the service programs that
90
are bound to this program are also activated. The procedures in an ILE service program can be accessed only by static procedure calls or by procedure pointer calls (not by dynamic program calls).
Static Procedure Calls

A call to an ILE procedure adds a new call stack entry to the bottom of the stack and passes control to a specied procedure. Examples include any of the following: 1. A call to a procedure in the same module 2. A call to a procedure in a different module in the same ILE program or service program 3. A call to a procedure that has been exported from an ILE service program in the same activation group 4. A call to a procedure that has been exported from an ILE service program in a different activation group In examples 1, 2, and 3, the static procedure call does not cross an activation group boundary. The call path length, which affects performance, is identical. This call path is much shorter than the path for a dynamic program call to an ILE or OPM program. In example 4, the call crosses an activation group boundary, and additional processing is done to switch activation group resources. The call path length is longer than the path length of a static procedure call within an activation group, but still shorter than for a dynamic program call. For a static procedure call, the called procedure must be bound to the calling procedure during binding. The call always accesses the same procedure. This contrasts with a call to a procedure through a pointer, where the target of the call can vary with each call.
Procedure Pointer Calls

Procedure pointer calls provide a way to call a procedure dynamically. For example, by manipulating arrays, or tables, of procedure names or addresses, you can dynamically route a procedure call to different procedures. Procedure pointer calls add entries to the call stack in exactly the same manner as static procedure calls. Any procedure that can be called using a static procedure call can also be called through a procedure pointer. If the called procedure is in the same activation group, the cost of a procedure pointer call is almost identical to the cost of a static procedure call. Procedure pointer calls can additionally access procedures in any ILE program that has been activated.
Passing Arguments to ILE Procedures

In an ILE procedure call, an argument is an expression that represents a value that the calling procedure passes to the procedure specied in the call. ILE languages use three methods for passing arguments: by value, directly The value of the data object is placed directly into the argument list. by value, indirectly The value of the data object is copied to a temporary location. The address of the copy (a pointer) is placed into the argument list.
91
by reference A pointer to the data object is placed into the argument list. Changes made by the called procedure to the argument are reected in the calling procedure. Figure 44 illustrates these argument passing styles. Not all ILE languages support passing by value, directly. The available passing styles are described in the ILE HLL programmers guides.
By value, directly a copy of argument
By value, indirectly pointer a copy of argument
By reference pointer the actual argument

RV2W1027-1
Figure 44. Methods for Passing Arguments to ILE Procedures
HLL semantics usually determine when data is passed by value and when it is passed by reference. For example, ILE C/400 passes and accepts arguments by value, directly, while for ILE COBOL/400 and ILE RPG/400, arguments are usually passed by reference. You must ensure that the calling program or procedure passes arguments in the manner expected by the called procedure. The ILE HLL programmers guides contain more information on passing arguments to different languages. A maximum of 400 arguments are allowed on a static procedure call. Each ILE language may further restrict the maximum number of arguments. The ILE languages support the following argument-passing styles: v ILE C/400 passes and accepts arguments by value directly, widening integers and oating-point values. Arguments can also be passed by value indirectly by specifying the #pragma argument directive for a called function. v ILE COBOL/400 passes arguments by reference or by value indirectly. ILE COBOL/400 accepts parameters only indirectly. v ILE RPG/400 passes and accepts arguments by reference. v ILE CL passes and accepts arguments by reference.
Function Results
To support HLLs that allow the denition of functions (procedures that return a result argument), the model assumes that a special function result argument may be present, as shown in Figure 45 on page 93. As described in the ILE HLL
92
programmers guides, ILE languages that support function results use a common mechanism for returning function results.
Calling Procedure
Call
Calling procedure passes arguments
Called procedure may return a function result
Return
Called Procedure
RV2W1028-1
Figure 45. Program Call Argument Terminology
Omitted Arguments
All ILE languages can simulate omitted arguments, which allows the use of the feedback code mechanism for ILE condition handlers and other run-time procedures. For example, if an ILE C/400 procedure or an ILE bindable API is expecting an argument passed by reference, you can sometimes omit the argument by passing a null pointer in its place. For information about how to specify an omitted argument in a specic ILE language, refer to the programmers guide for that language. The System API Reference species which arguments can be omitted for each API. For ILE languages that do not provide an intrinsic way for a called procedure to test if an argument has been omitted, the Test for Omitted Argument (CEETSTA) bindable API is available.
Dynamic Program Calls

A dynamic program call is a call made to a program object. For example, when you use the CL command CALL, you are making a dynamic program call. OPM programs are called by using dynamic program calls. OPM programs are additionally limited to making only dynamic program calls. EPM programs can make program calls and procedure calls. EPM programs can also be called by other programs and procedures. ILE programs are also called by dynamic program calls. The procedures within an activated ILE program can be accessed by using static procedure calls or procedure pointer calls. ILE programs that have not been activated yet must be called by a dynamic program call.
93
In contrast to static procedure calls, which are bound at compile time, symbols for dynamic program calls are resolved to addresses when the call is performed. As a result, a dynamic program call uses more system resources than a static procedure call. Examples of a dynamic program call include: v A call to an ILE program, an EPM program, or an OPM program v A call to a non-bindable API A dynamic program call to an ILE program passes control to the PEP of the identied program, which then passes control to the UEP of the program. After the called program is done processing, control is passed back to the instruction following the call program instruction.
Passing Arguments on a Dynamic Program Call

Calls to ILE or OPM programs (in contrast to calls to ILE procedures) usually pass arguments by reference, meaning that the called program receives the address of the arguments. EPM programs can receive arguments passed by reference, by value directly, or by value indirectly. When using a dynamic program call, you need to know the method of argument passing that is expected by the called program and how to simulate it if necessary. A maximum of 255 arguments are allowed on a dynamic program call. Each ILE language may further restrict the maximum number of arguments. Information on how to use the different passing methods is contained in the ILE HLL programmers guides, and, for passing methods in EPM, in the Pascal Users Guide, SC09-1844.
Interlanguage Data Compatibility

ILE calls allow arguments to be passed between procedures that are written in different HLLs. To facilitate data sharing between the HLLs, some ILE languages have added data types. For example, ILE COBOL/400 added USAGE PROCEDURE-POINTER as a new data type. To pass arguments between HLLs, you need to know the format each HLL expects of arguments it is receiving. The calling procedure is required to make sure the arguments are the size and type expected by the called procedure. For example, an ILE C/400 function may expect a 4-byte integer, even if a short integer (2 bytes) is declared in the parameter list. Information on how to match data type requirements for passing arguments is contained in the ILE HLL programmers guides.
Syntax for Passing Arguments in Mixed-Language Applications

Some ILE languages provide syntax for passing arguments to procedures in other ILE languages. For example, ILE C/400 provides a #pragma argument to pass value arguments to other ILE procedures by value indirectly.
Operational Descriptors
Operational descriptors may be useful to you if you are writing a procedure or API that can receive arguments from procedures written in different HLLs. Operational descriptors provide descriptive information to the called procedure in cases where the called procedure cannot precisely anticipate the form of the argument (for example, different types of strings). The additional information allows the procedure to properly interpret the arguments.
94
The argument supplies the value; the operational descriptor supplies information about the arguments size and type. For example, this information may include the length of a character string and the type of string. With operational descriptors, services such as bindable APIs are not required to have a variety of different bindings for each HLL, and HLLs do not have to imitate incompatible data types. A few ILE bindable APIs use operational descriptors to accommodate the lack of common string data types between HLLs. The presence of the operational descriptor is transparent to the API user. Operational descriptors support HLL semantics while being invisible to procedures that do not use or expect them. Each ILE language can use data types that are appropriate to the language. Each ILE language compiler provides at least one method for generating operational descriptors. For more information on HLL semantics for operational descriptors, refer to the ILE HLL reference manual. Operational descriptors are distinct from other data descriptors with which you may be familiar. For instance, they are unrelated to the descriptors associated with distributed data or les.
Requirements of Operational Descriptors

You should use operational descriptors when they are expected by a called procedure written in a different ILE language and when they are expected by an ILE bindable API. Generally, bindable APIs require descriptors for most string arguments. Information on bindable APIs in the System API Reference species whether a given bindable API requires operational descriptors.
Absence of a Required Descriptor

The omission of a required descriptor is an error. If a procedure requires a descriptor for a specic parameter, this requirement forms part of the interface for that procedure. If a required descriptor is not provided, it will fail during run time.
Presence of an Unnecessary Descriptor

The presence of a descriptor that is not required does not interfere with the called procedures access to arguments. If an operational descriptor is not needed or expected, the called procedure simply ignores it. Note: Descriptors can be an impediment to interlanguage communication when they are generated regardless of need. Descriptors increase the length of the call path, which can diminish performance.
Bindable APIs for Operational Descriptor Access

Descriptors are normally accessed directly by a called procedure according to the semantics of the HLL in which the procedure is written. Once a procedure is programmed to expect operational descriptors, no further handling is usually required by the programmer. However, sometimes a called procedure needs to determine whether the descriptors that it requires are present before accessing them. For this purpose the following bindable APIs are provided: v Retrieve Operational Descriptor Information (CEEDOD) bindable API v Get String Information (CEESGI) bindable API
95
Support for OPM and ILE APIs

When you develop new functions in ILE or convert an existing application to ILE, you may want to continue to support call-level APIs from OPM. This topic explains one technique that may be used to accomplish this dual support while maintaining your application in ILE. ILE service programs provide a way for you to develop and deliver bindable APIs that may be accessed from all ILE languages. To provide the same functions to OPM programs, you need to consider the fact that an ILE service program cannot be called directly from an OPM program. The technique to use is to develop ILE program stubs for each bindable API that you plan to support. You may want to name the bindable APIs the same as the ILE program stubs, or you may choose different names. Each ILE program stub contains a static procedure call to the actual bindable API. An example of this technique is shown in Figure 46.
Default Activation Group OPM Program A CALLPGM B Activation Group Vendor1 ILE Program B CALLPRC P1 STUB
ILE Program D CALLPRC P4 STUB Activation Group A1 ILE Program H CALLPRC P1 ILE Service Program X Procedure P1
. . .
. . .
Procedure P4
RV2W1047-1
Figure 46. Supporting OPM and ILE APIs
Programs B through D are the ILE program stubs. Service program X contains the actual implementation of each bindable API. Each program stub and the service program are given the same activation group name. In this example, the activation group name VENDOR1 is chosen. Activation group VENDOR1 is created by the system when necessary. The dynamic program call from OPM program A creates the activation group on the rst call from an OPM program. The static procedure call from ILE program H creates the activation group when ILE program H is activated. Once the activation group exists, it may be used from either program A or program H.
96
You should write the implementation of your API in an ILE procedure (procedure P1 in this example). This procedure may be called either directly through a procedure call or indirectly through a dynamic program call. You should not implement any functions such as sending exception messages that depend on a specic call stack structure. A normal return from either the program stub or the implementing procedure leaves the activation group in the job for later use. You can implement your API procedure with the knowledge that a control boundary is established for either the program stub or the implementing procedure on each call. HLL end verbs delete the activation group whether the call originated from an OPM program or an ILE program.
97
98
Chapter 7. Storage Management

The operating system provides storage support for the ILE high-level languages. This storage support removes the need for unique storage managers for the run-time environment of each language. It avoids incompatibilities between different storage managers and mechanisms in high-level languages. The operating system provides the automatic, static, and dynamic storage used by programs and procedures at run time. Automatic and static storage are managed by the operating system. That is, the need for automatic and static storage is known at compilation time from program variable declarations. Dynamic storage is managed by the program or procedure. The need for dynamic storage is known only at run time. When program activation occurs, static storage for program variables is allocated and initialized. When a program or procedure begins to run, automatic storage is allocated. The automatic storage stack is extended for variables as the program or procedure is added to the call stack. As a program or procedure runs, dynamic storage is allocated under program control. This storage is extended as additional storage is required. You have the ability to control dynamic storage. The remainder of this chapter concentrates on dynamic storage and the ways in which it can be controlled.
| | | | | | | | | | | | | | | | | | | | | |
Dynamic Storage
There are two types of dynamic storage: Heap and teraspace.
Heap
The operating system allows the use of multiple heaps that are dynamically created and discarded. A heap is an area of storage that is used for allocations of dynamic storage. The amount of dynamic storage that is required by an application depends on the data being processed by the programs and procedures that use the heap.
Heap Characteristics
Each heap has the following characteristics: v The system assigns a unique heap identier to each heap within the activation group. The heap identier for the default heap is always zero. A storage management-bindable API, called by a program or procedure, uses the heap identier to identify the heap on which it is to act. The bindable API must run within the activation group that owns the heap. v The activation group that creates a heap also owns it. Because activation groups own heaps, the lifetime of a heap is no longer than that of the owning activation group. The heap identier is meaningful and unique only within the activation group that owns it. v You can dynamically extend the size of a heap to satisfy allocation requests.
99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
The maximum size of the heap is 4 gigabytes minus 512K bytes. This is the maximum heap size if the total number of allocations (at any one time) does not exceed 128 000. v The maximum size of any single allocation from a heap is limited to 16 megabytes minus 64K bytes.
Default Heap
The rst request for dynamic storage from the default heap within an activation group results in the creation of a default heap from which the storage allocation takes place. If there is insufficient storage in the heap to satisfy any subsequent requests for dynamic storage, the system extends the heap and allocates additional storage. Allocated dynamic storage remains allocated until explicitly freed or until the system discards the heap. The default heap is discarded only when the owning activation group ends. Programs in the same activation group automatically share dynamic storage provided the default heap allocated the storage. However, you can isolate the dynamic storage that is used by some programs and procedures within an activation group. You do this by creating one or more heaps.
User-Created Heaps
You can explicitly create and discard one or more heaps by using ILE bindable APIs. This gives you the capability of managing the heaps and the dynamic storage that is allocated from those heaps. For example, dynamic storage allocated in user-created heaps for programs within an activation group may or may not be shared. The sharing of dynamic storage depends on which heap identier is referred to by the programs. You can use more than one heap to avoid automatic sharing of dynamic storage. In this way you can isolate logical groups of data. Following are some additional reasons for using one or more user-created heaps: v You can group certain storage objects together to meet a one-time requirement. Once you meet that requirement, you can free the dynamic storage that was allocated by a single call to the Discard Heap (CEEDSHP) bindable API. This operation frees the dynamic storage and discards the heap. In this way, dynamic storage is available to meet other requests. v You can free multiple dynamic storage that is allocated at once by using the Mark Heap (CEEMKHP) and Release Heap (CEERLHP) bindable APIs. The CEEMKHP bindable API allows you to mark a heap. When you are ready to free the group of allocations that were made since the heap was marked, use the CEERLHP bindable API. Using the mark and release functions leaves the heap intact, but frees the dynamic storage that is allocated from it. In this way, you can avoid the system overhead that is associated with heap creation by re-using existing heaps to meet dynamic storage requirements. v Your storage requirements may not match the storage attributes that dene the default heap. For example, the initial size of the default heap is 4K bytes. However, you require a number of dynamic storage allocations that together exceed 4K bytes. You can create a heap with a larger initial size than 4K bytes. This reduces the system overhead which would otherwise occur both when implicitly extending the heap and subsequently accessing the heap extensions.
100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Similarly, you can have heap extensions larger than 4K bytes. For information about dening heap sizes, see Heap Allocation Strategy and the discussion of heap attributes. You may have other reasons for using multiple heaps rather than the default heap. The storage management-bindable APIs give you the capability to manage both the heaps that you create and the dynamic storage that is allocated in those heaps. See the System API Reference for an explanation of the storage management-bindable APIs.
Single-Heap Support
Languages that do not have intrinsic multiple-heap storage support, such as ILE C/400, use the default heap. You cannot use the Discard Heap (CEEDSHP), the Mark Heap (CEEMKHP), or the Release Heap (CEERLHP) bindable APIs with the default heap. You can free dynamic storage that is allocated by the default heap by using explicit free operations, or by ending the activation group that owns it. These restrictions on the use of the default heap help prevent inadvertent release of allocated dynamic storage in mixed-language applications. Remember to consider release heap and discard heap operations as insecure for large applications that re-use existing code with potentially different storage support. Remember not to use release heap operations that are valid for the default heap. This causes multiple parts of an application that uses the mark function correctly when used separately to possibly fail when used together.
ILE C/400 Heap Support

ILE C/400 provides optional heap support to what is already provided by the system. If you choose to use this optional support, the following rules apply: v Dynamic storage allocated through the C functions malloc(), calloc(), and realloc(), cannot be freed or reallocated with the CEEFRST and the CEECZST bindable APIs. v Dynamic storage allocated by the CEEGTST bindable API can be freed with the free() function. v Dynamic storage initially allocated with the CEEGTST bindable API can be reallocated with the realloc() function. If you do not choose this optional support, you can use both the storage management bindable APIs and the malloc(), calloc(), realloc(), and free() functions. Other languages, such as COBOL, have no heap storage model. These languages can access the ILE dynamic storage model through the bindable APIs for dynamic storage.
Heap Allocation Strategy

The attributes associated with the default heap are dened by the system through a default allocation strategy. This allocation strategy denes attributes such as a heap creation size of 4K bytes and an extension size of 4K bytes. You cannot change this default allocation strategy. However, you can control heaps that you explicitly create through the Create a Heap (CEECRHP) bindable API. You also can dene an allocation strategy for
Chapter 7. Storage Management
101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
explicitly created heaps through the Dene Heap Allocation Strategy (CEE4DAS) bindable API. Then, when you explicitly create a heap, the heap attributes are provided by the allocation strategy that you dened. In this way you can dene separate allocation strategies for one or more explicitly created heaps. You can use the CEECRHP bindable API without dening an allocation strategy. In this case, the heap is dened by the attributes of the _CEE4ALC allocation strategy type. The _CEE4ALC allocation strategy type species a heap creation size of 4K bytes and an extension size of 4K bytes. The _CEE4ALC allocation strategy type contains the following attributes:
Max_Sngl_Alloc Min_Bdy Crt_Size Ext_Size Alloc_Strat No_Mark Blk_Xfer PAG Alloc_Init Init_Value = = = = = = = = = = 16MB - 64K /* maximum size of a single allocation */ 16 /* minimum boundary alignment of any allocation */ 4K /* initial creation size of the heap */ 4K /* the extension size of the heap */ 0 /* a choice for allocation strategy */ 1 /* a group deallocation choice */ 0 /* a choice for block transfer of a heap */ 0 /* a choice for heap creation in a PAG */ 0 /* a choice for allocation initialization */ 0x00 /* initialization value */
The attributes are shown here to illustrate the structure of the _CEE4ALC allocation strategy type. For a full explanation of the attributes, see the description of the _CEE4ALC allocation strategy type in the System API Reference.
Teraspace
A teraspace is temporary, dynamic storage that programs and procedures can use at run time. It provides a 1-terabyte address space to a process. A teraspace is not a space object. This means it is not a system object and that you cannot refer to it by using a system pointer. However, teraspace storage is addressable with space pointers. Teraspace storage allocations are controlled with a set of APIs.
Teraspace Characteristics
Teraspace adds capabilities beyond heap. Teraspace has the following characteristics: v The machine provides at most one teraspace per process, when a running program requests teraspace storage. Teraspace can exist no longer than the time between process initiation and process completion. v Unless you explicitly request shared access, you can only address a teraspace from one process. The system does not support other attempts to address it from other processes. Such an action has undened behavior. v Teraspace has much larger capacity than heap. You can dynamically increase the size of a teraspace to satisfy allocation requests. The maximum size of a teraspace is 1 terabyte (1024 gigabytes). v The maximum size of any single allocation from a teraspace is limited to 2147483408 bytes if ILE C runtime interfaces malloc(), calloc() or realloc() is used. If the Portable Operating System Interface for Computer Environments (POSIX) Shared Memory APIs are used, then the maximum size of a single allocation is 4,294,967,295 bytes (4 GB - 1). v A teraspace may consist of many individually allocated and deallocated separate areas. Addressability holes may exist between these areas.
102
| | | | | | | | | | | | | | | | | | |
Bindable APIs for Teraspace

IBM provides bindable APIs for allocating and discarding teraspace.1 v _C_TS_malloc() allocates storage within a teraspace. v _C_TS_free() frees one previous allocation of teraspace. v _C_TS_realloc() changes the size of a previous teraspace allocation. v _C_TS_calloc() allocates storage within a teraspace and sets it to 0. The POSIX shared memory interfaces were also enabled to support Teraspace. See the Interprocess Communication APIs section and the shmget() interface in the UNIX-type APIs manual for more information.
Compiler Options
ILE C and C++ compilers provide teraspace options to: v Request that generated code is enabled to work with teraspace storage. This includes teraspace storage that is allocated by the generated code and parameters that are passed from other teraspace-enabled programs and service programs. v Use teraspace versions of storage interfaces without source code changes. For example, malloc() is mapped to _C_TS_malloc(). See ILE C for AS/400 Programmers Guide, LPS: VisualAge for C++ for AS/400, or VisualAge C++ for OS/400 Read Me First! for details on these compiler options.
Storage Management Bindable APIs

Bindable APIs are provided for all heap operations. Applications can be written using either the bindable APIs, language-intrinsic functions, or both. The bindable APIs fall into the following categories: v Basic heap operations. These operations can be used on the default heap and on user-created heaps. The Free Storage (CEEFRST) bindable API frees one previous allocation of heap storage. The Get Heap Storage (CEEGTST) bindable API allocates storage within a heap. The Reallocate Storage (CEECZST) bindable API changes the size of previously allocated storage. v Extended heap operations. These operations can be used only on user-created heaps. The Create Heap (CEECRHP) bindable API creates a new heap. The Discard Heap (CEEDSHP) bindable API discards an existing heap. The Mark Heap (CEEMKHP) bindable API returns a token that can be used to identify heap storage to be freed by the CEERLHP bindable API. The Release Heap (CEERLHP) bindable API frees all storage allocated in the heap since the mark was specied. v Heap allocation strategies
1. Teraspace compiler options are available from ILE C and C++ compilers to automatically map malloc(), free(), calloc() and realloc() to their teraspace versions. Chapter 7. Storage Management
103
The Dene Heap Allocation Strategy (CEE4DAS) bindable API denes an allocation strategy that determines the attributes for a heap created with the CEECRHP bindable API. See the System API Reference for specic information about the storage management bindable APIs.
104
Chapter 8. Exception and Condition Management

This chapter provides additional details on exception handling and condition handling. Before you read this chapter, read the advanced concepts described in Error Handling on page 39. The exception message architecture of the OS/400 is used to implement both exception handling and condition handling. There are cases in which exception handling and condition handling interact. For example, an ILE condition handler registered with the Register a User-Written Condition Handler (CEEHDLR) bindable API is used to handle an exception message sent with the Send Program Message (QMHSNDPM) API. These interactions are explained in this chapter. The term exception handler is used in this chapter to mean either an OS/400 exception handler or an ILE condition handler.
Handle Cursors and Resume Cursors

To process exceptions, the system uses two pointers called the handle cursor and resume cursor. These pointers keep track of the progress of exception handling. You need to understand the use of the handle cursor and resume cursor under certain advanced error-handling scenarios. These concepts are used to explain additional error-handling features in later topics. The handle cursor is a pointer that keeps track of the current exception handler. As the system searches for an available exception handler, it moves the handle cursor to the next handler in the exception handler list dened by each call stack entry. This list can contain: v Direct monitor handlers v ILE condition handlers v HLL-specic handlers The handle cursor moves down the exception handler list to lower priority handlers until the exception is handled. If the exception is not handled by any of the exception handlers that have been dened for a call stack entry, the handle cursor moves to the rst (highest priority) handler for the previous call stack entry. The resume cursor is a pointer that keeps track of the current location at which your exception handler can resume processing after handling the exception. Normally the system sets the resume cursor to the next instruction following the occurrence of an exception. For call stack entries above the procedure that incurred the exception, the resume point is directly after the procedure or program call that currently suspended the procedure or program. To move the resume cursor to an earlier resume point, use the Move Resume Cursor (CEEMRCR) bindable API. Figure 47 on page 106 shows an example of the handle cursor and resume cursor.
105
Call Stack
ILE Procedure P1 CALLPRC P2

Resume Point
ILE Procedure P2 CALLPRC P3

Resume Point
Exception Handler List Handle Cursor
ILE Procedure P3 Exception Occurred

Resume Point
. . .
Resume Cursor
Exception Handler Procedure P10

RV2W1044-0
Figure 47. Handle Cursor and Resume Cursor Example
The handle cursor is currently at the second exception handler dened in the exception handler priority list for procedure P2. The handler procedure P10 is currently called by the system. If procedure P10 handles the exception and returns, control goes to the current resume cursor location dened in procedure P3. This example assumes that procedure P3 percolated the exception to procedure P2. The exception handler procedure P10 can modify the resume cursor with the Move Resume Cursor (CEEMRCR) bindable API. Two options are provided with this API. An exception handler can modify the resume cursor to either of the following: v The call stack entry containing the handle cursor v The call stack entry prior to the handle cursor In Figure 47, you could modify the resume cursor to either procedure P2 or P1. After the resume cursor is modied and the exception is marked as handled, a normal return from your exception handler returns control to the new resume point.
Exception Handler Actions

When your exception handler is called by the system, you can take several actions to handle the exception. For example, ILE C/400 extensions support control actions, branch point handlers, and monitoring by message ID. The possible actions described here pertain to any of the following types of handlers: v Direct monitor handler v ILE condition handler v HLL-specic handler
106
How to Resume Processing

If you determine that processing can continue, you can resume at the current resume cursor location. Before you can resume processing, the exception message must be changed to indicate that it has been handled. Certain types of handlers require you to explicitly change the exception message to indicate that the message has been handled. For other handler types, the system can change the exception message before your handler is called. For a direct monitor handler, you may specify an action to be taken for the exception message. That action may be to call the handler, to handle the exception before calling the handler, or to handle the exception and resume the program. If the action is just to call the handler, you can still handle the exception by using the Change Exception Message (QMHCHGEM) API or the bindable API CEE4HC (Handle Condition). You can change the resume point within a direct monitor handler by using the Move Resume Cursor (CEEMRCR) bindable API. After making these changes, you continue processing by returning from your exception handler. For an ILE condition handler, you continue processing by setting a return code value and returning to the system. For the actual return code values, please refer to the Register a User-Written Condition Handler (CEEHDLR) bindable API described in the System API Reference For an HLL-specic handler, the exception message is changed to indicate that it has been handled before your handler is called. To determine whether you can modify the resume cursor from an HLL-specic handler, refer to your ILE HLL programmers guide.
How to Percolate a Message

If you determine that an exception message is not recognized by your handler, you can percolate the exception message to the next available handler. For percolation to occur, the exception message must not be considered as a handled message. Other exception handlers in the same or previous call stack entries are given a chance to handle the exception message. The technique for percolating an exception message varies depending on the type of exception handler. For a direct monitor handler, do not change the exception message to indicate that it has been handled. A normal return from your exception handler causes the system to percolate the message. The message is percolated to the next exception handler in the exception handler list for your call stack entry. If your handler is at the end of the exception handler list, the message is percolated to the rst exception handler in the previous call stack entry. For an ILE condition handler, you communicate a percolate action by setting a return code value and returning to the system. For the actual return code values, please refer to the bindable API CEEHDLR described in the System API Reference For an HLL-specic handler, it may not be possible to percolate an exception message. Whether you can percolate a message depends on whether your HLL marks the message as handled before your handler is called. If you do not declare an HLL-specic handler, your HLL can percolate the unhandled exception message. Please refer to your ILE HLL reference manual to determine the exception messages your HLL-specic handler can handle.
107
How to Promote a Message

Under certain limited situations, you can choose to modify the exception message to a different message. This action marks the original exception message as handled and restarts exception processing with a new exception message. This action is allowed only from direct monitor handlers and ILE condition handlers. For direct monitor handlers, use the Promote Message (QMHPRMM) API to promote a message. Only status and escape message types can be promoted. With this API you have some control over where the handle cursor is placed to continue exception processing. Refer to the System API Reference for information on this API. For an ILE condition handler, you communicate the promote action by setting a return code value and returning to the system. For the actual return code values, refer to the Register a User-Written Condition Handler (CEEHDLR) bindable API described in the System API Reference
Default Actions for Unhandled Exceptions

If an exception message is percolated to the control boundary, the system takes a default action. If the exception is a notify message, the system sends the default reply, handles the exception, and allows the sender of the notify message to continue processing. If the exception is a status message, the system handles the exception and allows the sender of the status message to continue processing. If the exception is an escape message, the system handles the escape message and sends a function check message back to where the resume cursor is currently positioned. If the unhandled exception is a function check, all entries on the stack up to the control boundary are cancelled and the CEE9901 escape message is sent to the next prior stack entry. Table 5 contains default responses that the system takes when an exception is unhandled at a control boundary.
Table 5. Default Responses to Unhandled Exceptions Message Type Severity of Condition
Condition Raised by the Signal a Condition (CEESGL) Bindable API Return the unhandled condition. Return the unhandled condition. Not applicable. Not applicable. Return the unhandled condition. Exception Originated from Any Other Source Resume without logging the message. Resume without logging the message. Log the notify message and send the default reply. Log the notify message and send the default reply. Log the escape message and send a function check message to the call stack entry of the current resume point. Log the escape message and send a function check message to the call stack entry of the current resume point.
Status Status Notify Notify Escape
0 (Informative message) 1 (Warning) 0 (Informative message) 1 (Warning) 2 (Error)
Escape
3 (Severe error)
Return the unhandled condition.
108
Table 5. Default Responses to Unhandled Exceptions (continued) Message Type Severity of Condition Condition Raised by the Signal a Condition (CEESGL) Bindable API Escape 4 (Critical ILE error) Log the escape message and send a function check message to the call stack entry of the current resume point. Function check 4 (Critical ILE error) Not applicable
Exception Originated from Any Other Source Log the escape message and send a function check message to the call stack entry of the current resume point. End the application, and send the CEE9901 message to the caller of the control boundary.
Note: When the application is ended by an unhandled function check, the activation group is deleted if the control boundary is the oldest call stack entry in the activation group.
Nested Exceptions
A nested exception is an exception that occurs while another exception is being handled. When this happens, processing of the rst exception is temporarily suspended. The system saves all of the associated information such as the locations of the handle cursor and resume cursor. Exception handling begins again with the most recently generated exception. New locations for the handle cursor and resume cursor are set by the system. Once the new exception has been properly handled, handling activities for the original exception normally resume. When a nested exception occurs, both of the following are still on the call stack: v The call stack entry associated with the original exception v The call stack entry associated with the original exception handler To reduce the possibility of exception handling loops, the system stops the percolation of a nested exception at the original exception handler call stack entry. Then the system promotes the nested exception to a function check message and percolates the function check message to the same call stack entry. If you do not handle the nested exception or the function check message, the system ends the application by calling the Abnormal End (CEE4ABN) bindable API. In this case, message CEE9901 is sent to the caller of the control boundary. If you move the resume cursor while processing the nested exception, you can implicitly modify the original exception. To cause this to occur, do the following: 1. Move the resume cursor to a call stack entry earlier than the call stack entry that incurred the original exception 2. Resume processing by returning from your handler
Condition Handling
ILE conditions are OS/400 exception messages represented in a manner independent of the system. An ILE condition token is used to represent an ILE condition. Condition handling refers to the ILE functions that allow you to handle errors separately from language-specic error handling. Other SAA systems have
109
implemented these functions. You can use condition handling to increase the portability of your applications between systems that have implemented condition handling. ILE condition handling includes the following functions: v Ability to dynamically register an ILE condition handler v Ability to signal an ILE condition v Condition token architecture v Optional condition token feedback codes for bindable ILE APIs These functions are described in the topics that follow.
How Conditions Are Represented

The ILE condition token is a 12-byte compound data type that contains structured elds to convey aspects of a condition. Such aspects can be its severity, its associated message number, and information that is specic to the given instance of the condition. The condition token is used to communicate this information about a condition to the system, to message services, to bindable APIs, and to procedures. The information returned in the optional fc parameter of all ILE bindable APIs, for example, is communicated using a condition token. If an exception is detected by the operating system or by the hardware, a corresponding condition token is automatically built by the system. You can also create a condition token using the Construct a Condition Token (CEENCOD) bindable API. Then you can signal a condition to the system by returning the token through the Signal a Condition (CEESGL) bindable API.
Layout of a Condition Token

Figure 48 displays a map of the condition token. The starting bit position is shown for each eld.
Case Severity Control Condition_ID
0 32 34 37 40
Facility_ID
I_S_Info
64
The ILE condition ID always has case 1 format: MsgSev

0
Msg_No
16 RV2W1032-2
Figure 48. ILE Condition Token Layout
Every condition token contains the components indicated in Figure 48: Condition_ID A 4-byte identier that, with the Facility_ID, describes the condition that the token communicates. ILE bindable APIs and most applications produce case 1 conditions.
110
Case
A 2-bit eld that denes the format of the Condition_ID portion of the token. ILE conditions are always case 1.
Severity A 3-bit binary integer that indicates the severity of the condition. The Severity and MsgSev elds contain the same information. See Table 5 on page 108 for a list of ILE condition severities. See Table 7 on page 112 and Table 8 on page 112 for the corresponding OS/400 message severities. Control A 3-bit eld containing ags that describe or control various aspects of condition handling. The third bit species whether the Facility_ID has been assigned by IBM. Facility_ID A 3-character alphanumeric string that identies the facility that generated the condition. The Facility_ID indicates whether the message was generated by the system or an HLL run time. Table 6 lists the facility IDs used in ILE. I_S_Info A 4-byte eld that identies the instance specic information associated with a given instance of the condition. This eld contains the reference key to the instance of the message associated with the condition token. If the message reference key is zero, there is no associated message. MsgSev A 2-byte binary integer that indicates the severity of the condition. MsgSev and Severity contain the same information. See Table 5 on page 108 for a list of ILE condition severities. See Table 7 on page 112 and Table 8 on page 112 for the corresponding OS/400 message severities. Msg_No A 2-byte binary number that identies the message associated with the condition. The combination of Facility_ID and Msg_No uniquely identies a condition. Table 6 contains the facility IDs used in ILE condition tokens and in the prex of OS/400 messages.
Table 6. Facility IDs Used in Messages and ILE Condition Tokens Facility ID Facility CEE ILE common library CPF OS/400 XPF message MCH OS/400 machine exception message
Condition Token Testing

You can test a condition token that is returned from a bindable API for the following: Success To test for success, determine if the rst 4 bytes are zero. If the rst 4 bytes are zero, the remainder of the condition token is zero, indicating a successful call was made to the bindable API. Equivalent Tokens To determine whether two condition tokens are equivalent (that is, the same type of condition token, but not the same instance of the condition token), compare the rst 8 bytes of each condition token with one another. These bytes are the same for all instances of a given condition.
111
Equal Tokens To determine whether two condition tokens are equal, (that is, they represent the same instance of a condition), compare all 12 bytes of each condition token with one another. The last 4 bytes can change from instance to instance of a condition.
Relationship of ILE Conditions to OS/400 Messages

A message is associated with every condition that is raised in ILE. The condition token contains a unique ID that ILE uses to write a message associated with the condition to the message le. The format of every run-time message is FFFxxxx: FFF The facility ID, a 3-character ID that is used by all messages generated under ILE and ILE languages. Refer to Table 6 on page 111 for a list of IDs and corresponding facilities. The error message number. This is a hexadecimal number that identies the error message associated with the condition.
xxxx
Table 7 and Table 8 show how ILE condition severity maps to OS/400 message severity.
Table 7. Mapping AS/400 *ESCAPE Message Severities to ILE Condition Severities From AS/400 Message To ILE Condition Severity To AS/400 Message Severity Severity 0-29 2 20 30-39 3 30 40-99 4 40 Table 8. Mapping AS/400 *STATUS and *NOTIFY Message Severities to ILE Condition Severities From AS/400 Message To ILE Condition Severity To AS/400 Message Severity Severity 0 0 0 1-99 1 10
OS/400 Messages and the Bindable API Feedback Code

As input to a bindable API, you have the option of coding a feedback code, and using the feedback code as a return (or feedback) code check in a procedure. The feedback code is a condition token value that is provided for exibility in checking returns from calls to other procedures. You can then use the feedback code as input to a condition token. If the feedback code is omitted on the call to a bindable API and a condition occurs, an exception message is sent to the caller of the bindable API. If you code the feedback code parameter in your application to receive feedback information from a bindable API, the following sequence of events occurs when a condition is raised: 1. An informational message is sent to the caller of the API, communicating the message associated with the condition. 2. The bindable API in which the condition occurred builds a condition token for the condition. The bindable API places information into the instance specic
112
information area. The instance specic information of the condition token is the message reference key of the informational message. This is used by the system to react to the condition. 3. If a detected condition is critical (severity is 4), the system sends an exception message to the caller of the bindable API. 4. If a detected condition is not critical (severity less than 4), the condition token is returned to the routine that called the bindable API. 5. When the condition token is returned to your application, you have the following options: v Ignore it and continue processing. v Signal the condition using the Signal a Condition (CEESGL) bindable API. v Get, format, and dispatch the message for display using the Get, Format, and Dispatch a Message (CEEMSG) bindable API. v Store the message in a storage area using the Get a Message (CEEMGET) bindable API. v Use the Dispatch a Message (CEEMOUT) bindable API to dispatch a user-dened message to a destination that you specify. v When the caller of the API regains control, the informational message is removed and does not appear in the job log. If you omit the feedback code parameter when you are calling a bindable API, the bindable API sends an exception message to the caller of the bindable API.
113
114
Chapter 9. Debugging Considerations

The source debugger is used to debug OPM, ILE and service programs. CL commands can still be used to debug original program model (OPM) programs. This chapter presents several considerations about the source debugger. Information on how to use the source debugger can be found in the online information and in the programmers guide for the ILE high-level language (HLL) you are using. Information on the commands to use for a specic task (for example, creating a module) can be found in your ILE HLL programmers guide.
Debug Mode
To use the source debugger, your session must be in debug mode. Debug mode is a special environment in which program debug functions can be used in addition to normal system functions. Your session is put into debug mode when you run the Start Debug (STRDBG) command.
Debug Environment
A program can be debugged in either of the two environments: v The OPM debug environment. All OPM programs are debugged in this environment unless the OPM programs are explicitly added to the ILE debug environment. v The ILE debug environment. All ILE programs are debugged in this environment. In addition, an OPM program is debugged in this environment if all of the following criteria are met: It is a CL, COBOL or RPG program. It is complied with OPM source debug data. By setting the OPMSRC parameter of the STRDBG command to indicate *YES. The ILE debug environment provides source level debug support. The debug capability comes directly from statement, source, or list views of the code. Once an OPM program is in the ILE debug environment, the system will provide seamless debugging of both the ILE and OPM programs through the same user interface. For information on how to use the source debugger for OPM programs in the ILE debug environment, see online help or the programmers guide for the equivalent ILE high-level language (HLL) you are using for the OPM language: CL, COBOL, or RPG. For example, you can refer to the ILE RPG for AS/400 Programmers Guide for information on debugging OPM RPG programs in the ILE debug environment.
Addition of Programs to Debug Mode

A program must be added to debug mode before it can be debugged. OPM programs, ILE programs, and ILE service programs can be in debug mode at the same time. As many as 20 OPM programs can be in debug mode at one time in the OPM debug environment. The number of ILE programs, service programs and
115
OPM programs in the ILE debug environment that can be in debug mode at one time is not limited. However, the maximum amount of debug data that is supported at one time is 16MB per module. You must have *CHANGE authority to a program or service program to add it to debug mode. A program or service program can be added to debug mode when it is stopped on the call stack. ILE programs and service programs are accessed by the source debugger one module at a time. When you are debugging an ILE program or service program, you may need to debug a module in another program or service program. That second program or service program must be added to debug mode before the module in the second program can be debugged. When debug mode ends, all programs are removed from debug mode.
How Observability and Optimization Affect Debugging

Whether a module is observable and whether it is fully optimized affect the ability to debug it. Module observability refers to data that can be stored with a module that allows it to be changed without being compiled again. Optimization is a process where the system looks for processing shortcuts that reduce the amount of system resources necessary to produce the same output.
Observability
Module observability consists of two types of data: Debug Data Represented by the *DBGDTA value. This data is necessary to allow a module to be debugged. Creation Data Represented by the *CRTDTA value. This data is necessary to translate the code to machine instructions. The module must have this data for you to change the module optimization level. Once a module is compiled, you can only remove this data. Using the Change Module (CHGMOD) command, you can remove either type of data from the module, or remove both types. Removing all observability reduces the module to its minimum size (with compression). Once this data is removed, you cannot change the module in any way unless you compile the module again and replace the data. To compile it again, you must have authority to the source code.
Optimization Levels
Generally, if a module has creation data, you can change the level at which the source code is optimized to run on the system. Processing shortcuts are translated into machine code, allowing the procedures in the module to run more efficiently. The higher the optimization level, the more efficiently the procedures in the module run. However, with more optimization you cannot change variables and may not be able to view the actual value of a variable during debugging. When you are debugging,
116
set the optimization level to 10 (*NONE). This provides the lowest level of performance for the procedures in the module but allows you to accurately display and change variables. After you have completed your debugging, set the optimization level to 30 (*FULL) or 40. This provides the highest level of performance for the procedures in the module.
Debug Data Creation and Removal

Debug data is stored with each module and is generated when a module is created. To debug a procedure in a module that has been created without debug data, you must re-create the module with debug data, and then rebind the module to the ILE program or service program. You do not have to recompile all the other modules in the program or service program that already have debug data. To remove debug data from a module, re-create the module without debug data or use the Change Module (CHGMOD) command.
Module Views
The levels of debug data available may vary for each module in an ILE program or service program. The modules are compiled separately and could be produced with different compilers and options. These debug data levels determine which views are produced by the compiler and which views are displayed by the source debugger. Possible values are: *NONE No debug views are produced. *STMT No source is displayed by the debugger, but breakpoints can be added using procedure names and statement numbers found on the compiler listing. The amount of debug data stored with this view is the minimum amount of data necessary for debugging. *SOURCE The source debugger displays source if the source les used to compile the module are still present on the system. *LIST The list view is produced and stored with the module. This allows the source debugger to display source even if the source les used to create the module are not present on the system. This view can be useful as a backup copy if the program will be changed. However, the amount of debug data may be quite large, especially if other les are expanded into the listing. The compiler options used when the modules were created determine whether the includes are expanded. Files that can be expanded include DDS les and include les (such as ILE C/400 includes, ILE RPG/400 /COPY les, and ILE COBOL/400 COPY les). All debug views are produced. As for the list view, the amount of debug data may be very large.
*ALL
ILE RPG/400 also has a debug option *COPY that produces both a source view and a copy view. The copy view is a debug view that has all the /COPY source members included.
117
Debugging across Jobs

You may want to use a separate job to debug programs running in your job or a batch job. This is very useful when you want to observe the function of a program without the interference of debugger panels. For example, the panels or windows that an application displays may overlay or be overlaid by the debugger panels during stepping or at breakpoints. You can avoid this problem by starting a service job and starting the debugger in a different job from the one that is being debugged. For information on this, see the appendix on testing in the CL Programming book.
OPM and ILE Debugger Support

The OPM and ILE debugger support enables source level debugging of the OPM programs through the ILE Debugger APIs. For information on ILE Debugger APIs, see the System API Reference. The OPM and ILE debugger support provides seamless debugging of both the ILE and OPM programs through the same user interface. To use this support, an OPM program must be compiled with the AS/400 RPG, COBOL, or CL compiler. The OPTION parameter must be set to *SRCDBG or *LSTDBG for the compilation. System/36 compilers and EPM compilers are not supported.
Watch Support
The Watch support provides the ability to stop program execution when the content of a specied storage location is changed. The storage location is specied by the name of a program variable. The program variable is resolved to a storage location and the content at this location is monitored for changes. If the content at the storage location is changed, execution stops. The interrupted program source is displayed at the point of interruption, and the source line that is highlighted will be run after the statement that changed the storage location.
Unmonitored Exceptions
When an unmonitored exception occurs, the program that is running issues a function check and sends a message to the job log. If you are in debug mode and the modules of the program were created with debug data, the source debugger shows the Display Module Source display. The program is added to debug mode if necessary. The appropriate module is shown on the display with the affected line highlighted. You can then debug the program.
National Language Support Restriction for Debugging

If either of the following conditions exist: v The coded character set identier (CCSID) of the debug job is 290, 930, or 5026 (Japan Katakana) v The code page of the device description used for debugging is 290, 930, or 5026 (Japan Katakana) debug commands, functions, and hexadecimal literals should be entered in uppercase. For example:
BREAK 16 WHEN var=X'A1B2' EVAL var:X
118
The above restriction for Japan Katakana code pages does not apply when using identier names in debug commands (for example, EVAL). However, when debugging ILE RPG/400, ILE COBOL/400, or ILE CL modules, identier names in debug commands are converted to uppercase by the source debugger and therefore may be redisplayed differently.
119
120
Chapter 10. Data Management Scoping

This chapter contains information on the data management resources that may be used by an ILE program or service program. Before reading this chapter, you should understand the data management scoping concepts described in Data Management Scoping Rules on page 46. Details for each resource type are left to each ILE HLL programmers guide.
Common Data Management Resources

This topic identies all the data management resources that follow data management scoping rules. Following each resource is a brief description of how to specify the scoping. Additional details for each resource can be found in the publications referred to. v Open le operations Open le operations result in the creation of a temporary resource called an open data path (ODP). The open function can be started by using HLL open verbs, the Open Query File (OPNQRYF) command, or the Open Data Base File (OPNDBF) command. The ODP is scoped to the activation group of the program that opened the le. For OPM or ILE programs that run in the default activation group, the ODP is scoped to the call-level number. To change the scoping of HLL open verbs, an override may be used. You can specify scoping by using the open scope (OPNSCOPE) parameter on all override commands, the OPNDBF command, and the OPNQRYF command. For more information about open le operations, see the Data Management book. v Overrides Overrides are scoped to the call level, the activation group level, or the job level. To specify override scoping, use the override scope (OVRSCOPE) parameter on any override command. If explicit scoping is not specied, the scope of the override depends on where the override is issued. If the override is issued from the default activation group, it is scoped to the call level. If the override is issued from any other activation group, it is scoped to the activation group level. For more information about overrides, see the Data Management book. v Commitment denitions Commitment denitions support scoping to the activation group level and scoping to the job level. The scoping level is specied with the control scope (CTLSCOPE) parameter on the Start Commitment Control (STRCMTCTL) command. For more information about commitment denitions, see Backup and Recovery. v Local SQL cursors SQL programs may be created for ILE compiler products. The SQL cursors used by an ILE program may be scoped to either the module or activation group. You may specify the SQL cursor scoping through the end SQL (ENDSQL) parameter on the Create SQL Program commands. For more information about local SQL cursors, see the DB2 UDB for AS/400 SQL Programming book. v Remote SQL connections Remote connections used with SQL cursors are scoped to an activation group implicitly as part of normal SQL processing. This allows multiple conversations to
121
exist among one source job and multiple target jobs or systems. For more information about remote SQL connections, see the DB2 UDB for AS/400 SQL Programming book. User interface manager The Open Print Application (QUIOPNPA) and Open Display Application APIs support an application scope parameter. These APIs can be used to scope the user interface manager (UIM) application to either an activation group or the job. For more information about the user interface manager, see the System API Reference Open data links (open le management) The Enable Link (QOLELINK) API enables a data link. If this API is used from within an ILE activation group, the data link is scoped to that activation group. If this API is used from within the default activation group, the data link is scoped to the call level. For more information about open data links, see the System API Reference Common Programming Interface (CPI) Communications conversations The activation group that starts a conversation owns that conversation. The activation group that enables a link through the Enable Link (QOLELINK) API owns the link. For more information about Common Programming Interface (CPI) Communications conversations, see the System API Reference . Hierarchical le system The Open Stream File (OHFOPNSF) API manages hierarchical le system (HFS) les. The open information (OPENINFO) parameter on this API may be used to control scoping to either the activation group or the job level. For more information about the hierarchical le system, see the System API Reference .
Commitment Control Scoping

ILE introduces two changes for commitment control: v Multiple, independent commitment denitions per job. Transactions can be committed and rolled back independently of each other. Before ILE, only a single commitment denition was allowed per job. v If changes are pending when an activation group ends normally, the system implicitly commits the changes. Before ILE, the system did not commit the changes. Commitment control allows you to dene and process changes to resources, such as database les or tables, as a single transaction. A transaction is a group of individual changes to objects on the system that should appear to the user as a single atomic change. Commitment control ensures that one of the following occurs on the system: v The entire group of individual changes occurs (a commit operation) v None of the individual changes occur (a rollback operation) Various resources can be changed under commitment control using both OPM programs and ILE programs. The Start Commitment Control (STRCMTCTL) command makes it possible for programs that run within a job to make changes under commitment control. When commitment control is started by using the STRCMTCTL command, the system creates a commitment denition. Each commitment denition is known only to the job that issued the STRCMTCTL command. The commitment denition contains information pertaining to the resources being changed under commitment control
122
within that job. The commitment control information in the commitment denition is maintained by the system as the commitment resources change. The commitment denition is ended by using the End Commitment Control (ENDCMTCTL) command. For more information about commitment control, see Backup and Recovery
Commitment Denitions and Activation Groups

Multiple commitment denitions can be started and used by programs running within a job. Each commitment denition for a job identies a separate transaction that has resources associated with it. These resources can be committed or rolled back independently of all other commitment denitions started for the job. Note: Only ILE programs can start commitment control for activation groups other than the default activation group. Therefore, a job can use multiple commitment denitions only if the job is running one or more ILE programs. Original program model (OPM) programs run in the default activation group. By default, OPM programs use the *DFTACTGRP commitment denition. For OPM programs, you can use the *JOB commitment denition by specifying CMTSCOPE(*JOB) on the STRCMTCTL command. When you use the Start Commitment Control (STRCMTCTL) command, you specify the scope for a commitment denition on the commitment scope (CMTSCOPE) parameter. The scope for a commitment denition indicates which programs that run within the job use that commitment denition. The default scope for a commitment denition is to the activation group of the program issuing the STRCMTCTL command. Only programs that run within that activation group will use that commitment denition. Commitment denitions that are scoped to an activation group are referred to as commitment denitions at the activation-group level. The commitment denition started at the activation-group level for the OPM default activation group is known as the default activation-group (*DFTACTGRP) commitment denition. Commitment denitions for many activation-group levels can be started and used by programs that run within various activation groups for a job. A commitment denition can also be scoped to the job. A commitment denition with this scope value is referred to as the job-level or *JOB commitment denition. Any program running in an activation group that does not have a commitment denition started at the activation-group level uses the job-level commitment denition. This occurs if the job-level commitment denition has already been started by another program for the job. Only a single job-level commitment denition can be started for a job. For a given activation group, only a single commitment denition can be used by the programs that run within that activation group. Programs that run within an activation group can use the commitment denition at either the job level or the activation-group level. However, they cannot use both commitment denitions at the same time. When a program performs a commitment control operation, the program does not directly indicate which commitment denition to use for the request. Instead, the system determines which commitment denition to use based on which activation group the requesting program is running in. This is possible because, at any point in time, the programs that run within an activation group can use only a single commitment denition.
123
Ending Commitment Control

Commitment control may be ended for either the job-level or activation-group-level commitment denition by using the End Commitment Control (ENDCMTCTL) command. The ENDCMTCTL command indicates to the system that the commitment denition for the activation group of the program making the request is to be ended. The ENDCMTCTL command ends one commitment denition for the job. All other commitment denitions for the job remain unchanged. If the commitment denition at the activation-group level is ended, programs running within that activation group can no longer make changes under commitment control. If the job-level commitment denition is started or already exists, any new le open operations specifying commitment control use the job-level commitment denition. If the job-level commitment denition is ended, any program running within the job that was using the job-level commitment denition can no longer make changes under commitment control. If commitment control is started again with the STRCMTCTL command, changes can be made.
Commitment Control during Activation Group End

When the following conditions exist at the same time: v An activation group ends v The job is not ending the system automatically ends a commitment denition at an activation-group level. If both of the following conditions exist: v Uncommitted changes exist for a commitment denition at an activation-group level v The activation group is ending normally the system performs an implicit commit operation for the commitment denition before it ends the commitment denition. Otherwise, if either of the following conditions exist: v The activation group is ending abnormally v The system encountered errors when closing any les opened under commitment control scoped to the activation group an implicit rollback operation is performed for the commitment denition at the activation-group level before being ended. Because the activation group ends abnormally, the system updates the notify object with the last successful commit operation. Commit and rollback are based on pending changes. If there are no pending changes, there is no rollback, but the notify object is still updated. If the activation group ends abnormally with pending changes, the system implicitly rolls back the changes. If the activation group ends normally with pending changes, the system implicitly commits the changes. An implicit commit operation or rollback operation is never performed during activation group end processing for the *JOB or *DFTACTGRP commitment denitions. This is because the *JOB and *DFTACTGRP commitment denitions are never ended because of an activation group ending. Instead, these commitment denitions are either explicitly ended by an ENDCMTCTL command or ended by the system when the job ends.
124
The system automatically closes any les scoped to the activation group when the activation group ends. This includes any database les scoped to the activation group opened under commitment control. The close operation for any such le occurs before any implicit commit operation that is performed for the commitment denition at the activation-group level. Therefore, any records that reside in an I/O buffer are rst forced to the database before any implicit commit operation is performed. As part of the implicit commit operation or rollback operation, the system calls the API commit and rollback exit program for each API commitment resource. Each API commitment resource must be associated with the commitment denition at the activation-group level. After the API commit and rollback exit program is called, the system automatically removes the API commitment resource. If the following conditions exist: v An implicit rollback operation is performed for a commitment denition that is being ended because an activation group is being ended v A notify object is dened for the commitment denition the notify object is updated.
125
126
Chapter 11. ILE Bindable Application Programming Interfaces

ILE bindable application programming interfaces (bindable APIs) are an important part of ILE. In some cases they provide additional function beyond that provided by a specic high-level language. For example, not all HLLs offer intrinsic means to manipulate dynamic storage. In those cases, you can supplement an HLL function by using particular bindable APIs. If your HLL provides the same function as a particular bindable API, use the HLL-specic one. Bindable APIs are HLL independent. This can be useful for mixed-language applications. For example, if you use only condition management bindable APIs with a mixed-language application, you will have uniform condition handling semantics for that application. This makes condition management more consistent than when using multiple HLL-specic condition handlers. The bindable APIs provide a wide range of function including: Activation group and control ow management Condition management Date and time manipulation Dynamic screen management Math functions Message handling Program or procedure call management and operational descriptor access Source debugger Storage management For reference information on the ILE bindable APIs, see the System API Reference .
ILE Bindable APIs Available

Most bindable APIs are available to any HLL that ILE supports. Naming conventions of the bindable APIs are as follows: v Bindable APIs with names beginning with CEE are based on the SAA Language Environment* specications. These APIs are intended to be consistent across the IBM SAA systems. For more information about the SAA Language Environment, see the SAA CPI Language Environment Reference. v Bindable APIs with names beginning with CEE4 or CEES4 are specic to the AS/400 system. ILE provides the following bindable APIs: Activation Group and Control Flow Bindable APIs Abnormal End (CEE4ABN) Find a Control Boundary (CEE4FCB) Register Activation Group Exit Procedure (CEE4RAGE) Register Call Stack Entry Termination User Exit Procedure (CEERTX) Signal the Termination-Imminent Condition (CEETREC) Unregister Call Stack Entry Termination User Exit Procedure (CEEUTX) Condition Management Bindable APIs
127
Construct a Condition Token (CEENCOD) Decompose a Condition Token (CEEDCOD) Handle a Condition (CEE4HC) Move the Resume Cursor to a Return Point (CEEMRCR) Register a User-Written Condition Handler (CEEHDLR) Retrieve ILE Version and Platform ID (CEEGPID) Return the Relative Invocation Number (CEE4RIN) Signal a Condition (CEESGL) Unregister a User Condition Handler (CEEHDLU) Date and Time Bindable APIs Calculate Day-of-Week from Lilian Date (CEEDYWK) Convert Date to Lilian Format (CEEDAYS) Convert Integers to Seconds (CEEISEC) Convert Lilian Date to Character Format (CEEDATE) Convert Seconds to Character Timestamp (CEEDATM) Convert Seconds to Integers (CEESECI) Convert Timestamp to Number of Seconds (CEESECS) Get Current Greenwich Mean Time (CEEGMT) Get Current Local Time (CEELOCT) Get Offset from Universal Time Coordinated to Local Time (CEEUTCO) Get Universal Time Coordinated (CEEUTC) Query Century (CEEQCEN) Return Default Date and Time Strings for Country (CEEFMDT) Return Default Date String for Country (CEEFMDA) Return Default Time String for Country (CEEFMTM) Set Century (CEESCEN) Math Bindable APIs The x in the name of each math bindable API refers to one of the following data types: I S D T E 32-bit binary integer 32-bit single oating-point number 64-bit double oating-point number 32-bit single oating-complex number (both real and imaginary parts are 32 bits long) 64-bit double oating-complex number (both real and imaginary parts are 64 bits long) Absolute Function (CEESxABS) Arccosine (CEESxACS) Arcsine (CEESxASN) Arctangent (CEESxATN) Arctangent2 (CEESxAT2) Conjugate of Complex (CEESxCJG) Cosine (CEESxCOS) Cotangent (CEESxCTN)
128
Error Function and Its Complement (CEESxERx) Exponential Base e (CEESxEXP) Exponentiation (CEESxXPx) Factorial (CEE4SIFAC) Floating Complex Divide (CEESxDVD) Floating Complex Multiply (CEESxMLT) Gamma Function (CEESxGMA) Hyperbolic Arctangent (CEESxATH) Hyperbolic Cosine (CEESxCSH) Hyperbolic Sine (CEESxSNH) Hyperbolic Tangent (CEESxTNH) Imaginary Part of Complex (CEESxIMG) Log Gamma Function (CEESxLGM) Logarithm Base 10 (CEESxLG1) Logarithm Base 2 (CEESxLG2) Logarithm Base e (CEESxLOG) Modular Arithmetic (CEESxMOD) Nearest Integer (CEESxNIN) Nearest Whole Number (CEESxNWN) Positive Difference (CEESxDIM) Sine (CEESxSIN) Square Root (CEESxSQT) Tangent (CEESxTAN) Transfer of Sign (CEESxSGN) Truncation (CEESxINT) Additional math bindable API: Basic Random Number Generation (CEERAN0) Message Handling Bindable APIs Dispatch a Message (CEEMOUT) Get a Message (CEEMGET) Get, Format, and Dispatch a Message (CEEMSG) Program or Procedure Call Bindable APIs Get String Information (CEEGSI) Retrieve Operational Descriptor Information (CEEDOD) Test for Omitted Argument (CEETSTA) Source Debugger Bindable APIs Allow a Program to Issue Debug Statements (QteSubmitDebugCommand) Enable a Session to Use the Source Debugger (QteStartSourceDebug) Map Positions from One View to Another (QteMapViewPosition) Register a View of a Module (QteRegisterDebugView) Remove a View of a Module (QteRemoveDebugView) Retrieve the Attributes of the Source Debug Session (QteRetrieveDebugAttribute)
Chapter 11. ILE Bindable Application Programming Interfaces
129
Retrieve the List of Modules and Views for a Program (QteRetrieveModuleViews) Retrieve the Position Where the Program Stopped (QteRetrieveStoppedPosition) Retrieve Source Text from the Specied View (QteRetrieveViewText) Set the Attributes of the Source Debug Session (QteSetDebugAttribute) Take a Job Out of Debug Mode (QteEndSourceDebug) Storage Management Bindable APIs Create Heap (CEECRHP) Dene Heap Allocation Strategy (CEE4DAS) Discard Heap (CEEDSHP) Free Storage (CEEFRST) Get Heap Storage (CEEGTST) Mark Heap (CEEMKHP) Reallocate Storage (CEECZST) Release Heap (CEERLHP)
Dynamic Screen Manager Bindable APIs

The dynamic screen manager (DSM) bindable APIs are a set of screen I/O interfaces that provide a dynamic way to create and manage display screens for the ILE high-level languages. The DSM APIs fall into the following functional groups: v Low-level services The low-level services APIs provide a direct interface to the 5250 data stream commands. The APIs are used to query and manipulate the state of the display screen; to create, query, and manipulate input and command buffers that interact with the display screen; and to dene elds and write data to the display screen. v Window services The window services APIs are used to create, delete, move, and resize windows; and to manage multiple windows concurrently during a session. v Session services The session services APIs provide a general paging interface that can be used to create, query, and manipulate sessions; and to perform input and output operations to sessions. For more information about the DSM bindable APIs, see the System API Reference
130
Chapter 12. Advanced Optimization Technique

Program proling is an advanced optimization technique to reorder procedures, or code within procedures, in ILE programs and service programs based on statistical data gathered while running the program. This reordering can improve instruction cache utilization and reduce paging required by the program, thereby improving performance. The semantic behavior of the program is not affected by program proling. The performance improvement realized by program proling depends on the type of application. Generally speaking, you can expect more improvement from programs that spend the majority of time in the application code itself, rather than spending time in the run time or doing input/output processing. Additionally, different AS/400 models have different instruction cache capabilities. A model with limited caching capabilities may not see as much improvement as a model with extensive caching capabilities. Therefore, you may want to consider your customer set to determine the model to prole. Program proling is only available for ILE programs and service programs that meet the following conditions: v The programs were created specically for V4R2M0 or later releases. v The programs target release is the same as the current system release level. v The programs that are compiled by using an optimization level of *FULL (30) or above. Note: Because of the optimization requirements, you should fully debug your programs before using program proling.
Types of Proling
| | | | You can prole your programs in the following two ways: v Block order v Procedure order and block order Block order proling records the number of times each side of a conditional branch is taken. It reorders code within the bound module so that the more frequently used condition does not branch. This improves the instruction cache utilization by increasing the likelihood that the next instruction is in the instruction cache, reducing the need to fetch it from main memory. Procedure order proling records the number of times each procedure calls another procedure within the program. It reorders the procedures within the program so that the most frequently called procedures are packaged together. This reduces the paging by increasing the likelihood that the called procedure is brought into main memory at the same time the calling procedure was brought in. | | | Even though you can choose to apply only block order proling to your program, it is recommended that you apply both types. This provides the best performance gains.
131
How to Prole a Program

Proling a program is a ve step process: 1. Enable the program to collect proling data. 2. Start the program proling collection on the system with the Start Program Proling (STRPGMPRF) command. 3. Collect proling data by running the program through its high-use code paths. Because program proling uses statistical data gathered while running the program to perform these optimizations, it is critical that this data be collected over typical uses of your application. 4. End the program proling collection on the system with the End Program Proling (ENDPGMPRF) command. 5. Apply the collected proling data to the program by requesting that code be reordered for optimal performance based on the collected proling data. Program proling is sensitive to the level of the optimizing translator that is used. IBM recommends performing the steps on the same machine. (Otherwise the collected data may not be usable.) v Do not apply optimizing translator PTFs between the time programs are enabled for proling data collection and the next time it is applied. v Do not apply system release levels between the time programs are enabled for proling data collection and the time it is applied.
Enabling the program to collect proling data

A program is enabled to collect proling data if at least one of the modules bound into the program is enabled to collect proling data. Enabling a program to collect proling data can be done either by changing one or more *MODULE objects to collect proling data and then creating or updating the program with these modules, or by changing the program after it is created to collect proling data. Both techniques result in a program with bound modules enabled to collect proling data. Depending on the ILE language you are using, there may be an option on the compiler command to create the module as enabled to collect proling data. The change module (CHGMOD) command can also be used by specifying *COL on the proling data (PRFDTA) parameter to change any ILE module to collect proling data, as long as the ILE language supports an optimization level of at least *FULL (30). | | | | | | | | | | | | To collect proling data after creation through either the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) commands an observable program must do the following: v Specify *COL on the proling data (PRFDTA) parameter that will affect all modules bound in the program that: Must have a target release that matches the current system release which is V4R2M0 or later. Have an optimization level of 30 or above Note: You can only enable proling data for programs and service programs that are created for the same release level as the system they are on. The modules in the programs and service programs must also have their created for release at the same level as the system.
132
Enabling a module or program to collect proling data requires that the object be retranslated. Therefore, the time required to enable a module or program to collect proling data is comparable to the time it takes to force recreate the object (FRCCRT parameter). Additionally, the size of the object will be larger due to the extra machine instructions generated by the optimizing translator. Once you enable a program or module to collect proling data, creation data observability cannot be removed until one of the following occurs: v The collected proling data is applied to the program. v The program or module changes so that it cannot collect proling data. Use the Display Module (DSPMOD), Display Program (DSPPGM) or Display Service Program (DSPSRVPGM) commands, specifying DETAIL(*BASIC), to determine if a module or program is enabled to collect proling data. For programs or service programs use option 5 (display description) from the DETAIL(*MODULE) to determine which of the bound module(s) are enabled to collect proling data. See topic How to tell if program or module is proled or enabled for collection for more details. Note: If a program already has proling data collected (the statistical data gathered while the program is running), this data is cleared when a program is re-enabled to collect proling data. See Managing programs enabled to collect proling data for details.
| | | | |
Collect Proling Data

Program proling must be started on the machine that a program enabled to collect proling data is to be run on in order for that program to update proling data counts. This enables large, long-running applications to be started and allowed to reach a steady state before gathering proling data. This gives you control over when data collection occurs. | | | | | Use the Start Program Proling (STRPGMPRF) command to start program proling on a machine. To end program proling on a machine, use the End Program Proling (ENDPGMPRF) command. IBM ships both commands with the public authority of *EXCLUDE. Program proling is ended implicitly when a machine is IPLed. Once program proling is started, any program or service program that is run that is also enabled to collect proling data will update its proling data counts. This will happen regardless of whether or not the program was activated before the STRPGMPRF command was issued. If the program you are collecting proling data on can be called by multiple jobs on the machine, the proling data counts will be updated by all of these jobs. If this is not desirable, a duplicate copy of the program should be made in a separate library and that copy should be used instead. Notes: 1. When program proling is started on a machine, proling data counts are incremented while a program that is enabled to collect proling data is running. Therefore it is possible that stale proling data counts are being added to if this program was previously run without subsequently clearing these counts. You can force the proling data counts to be cleared in several ways. See Managing programs enabled to collect proling data for details.
133
2. Proling data counts are not written to DASD each time they are incremented as doing so would cause too great a degradation to the programs runtime. Proling data counts are only written to DASD when the program is naturally paged out. To ensure proling data counts are written to DASD, use the Clear Pool (CLRPOOL) command to clear the storage pool which the program is running in.
Applying the Collected Proling Data

| | | | | | | | | | | | Applying collected proling data does the following: 1. Instructs the machine to use the collected proling data to reorder procedures (procedure order proling data) in the program for optimal performance. 2. Additionally it instructs the machine to use the code within procedures (basic block proling data) in the program for optimal performance. 3. It removes the machine instructions from the program that were previously added when the program was enabled to collect proling data. This means that the program cannot collect prole data. 4. The collected proling data is stored in the program as observable data: v *BLKORD (basic block proling observability) v *PRCORD (procedure order proling observability) Once the collected data has been applied to the program, it cannot be applied again. To apply proling data again requires you to go through the steps outlined in How to prole a program. Any previously applied proling data is discarded when a program is enabled to collect proling data. If you want to apply the data you already collected again, make a copy of the program before applying proling data. This may be desirable if you are experimenting with the benets derived from each type of proling (either block order or block and procedure ordered ). To apply proling data, use the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) command. For the proling data (PRFDTA) parameter specify to apply: v Block order proling data (*APYBLKORD) v Procedure proling data (*APYPRCORD) v Or both types of proling data (*APYALL) or (*APYPRCORD) IBM recommends using *APYALL. Applying proling data to the program creates and saves two new forms of observability with the program. You can remove these new observabilities by using the Change Program (CHGPGM) and Change Service Program (CHGSRVPGM) commands. v *BLKORD observability is implicitly added when block order proling data is applied to the program. This allows the machine to preserve the applied block order proling data for the program in cases where the program is retranslated. v Applying procedure order proling data to the program implicitly adds *PRCORD and *BLKORD observability. This allows the machine to preserve the applied procedure order proling data for the program in cases where the program is either retranslated or updated.
| | | | | | | | | | | | | | |
| | | |
134
For example, you apply block order proling data to your program and then subsequently remove *BLKORD observability. The program is still block order proled. However, any change that causes your program to be retranslated will also cause it to no longer be block order proled. Note: Removing *CRTDTA observability will also cause *BLKORD observability to be removed implicitly. This is because *BLKORD observability is only needed when the program is retranslated. Since the program cannot be retranslated if *CRTDTA observability is removed, *BLKORD is no longer needed and is also removed. However *PRCORD observability is not removed. In addition it is not recommend to retranslate the program with *BLKORD observability with a different version of the optimizing translator from the one used to enable the program and apply the proling data. Optimizing translator PTFs and new releases of the operating system may invalidate some of the basic block proling data.
Managing Programs Enabled to Collect Proling Data

Changing a program that is enabled to collect proling data by using the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) commands will implicitly cause proling data counts to be zeroed if the change requires the program be retranslated. For example, if you change a program that is enabled to collect proling data from optimization level *FULL to optimization level 40, any collected proling data will be implicitly cleared. This is also true if a program that is enabled to collect proling data is restored, and FRCOBJCVN(*YES *ALL) is specied on the Restore Object (RSTOBJ) command. Likewise, updating a program that is enabled to collect proling data by using the Update Program (UPDPGM) or Update Service Program (UPDSRVPGM) commands will implicitly cause proling data counts to be cleared if the resulting program is still enabled to collect proling data. For example, program P1 contains modules M1 and M2. Module M1 bound in P1 is enabled to collect proling data but module M2 is not. So long as one of the modules is enabled, updating program P1 with module M1 or M2 will result in a program that is still enabled to collect proling data. All proling data counts will be cleared. However, if module M1 is changed to no longer be enabled to collect proling data by specifying *NOCOL on the proling data (PRFDTA) parameter of the Change Module (CHGMOD) command, updating program P1 with M1 will result in program P1 no longer being enabled to collect proling data. You can explicitly clear proling counts from the program by specifying the *CLR option on the proling data (PRFDTA) parameter of the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) commands. Note the program must not be activated to use the *CLR option. | | | | | | If you no longer want the program to collect proling data, you must do one of the following steps to accomplish this. v Specify *NOCOL on the proling data (PRFDTA) parameter of the Change Program (CHGPGM) v Specify *NOCOL on the proling data (PRFDTA) parameter of the Change Service Program (CHGSRVPGM) commands.
135
| | |
This will change the program back to the state before it collected proling data. You can change the PRFDTA value of the modules to *NOCOL with the CHGMOD command or by recompiling the modules, and rebind the modules into the program.
Managing Programs with Proling Data Applied to Them

If a program that has proling data applied is changed by using the Change Program (CHGPGM) or Change Service Program (CHGSRVPGM) commands, you will lose applied proling data if both of these conditions are true: v The change requires the program to be retranslated. Note: The optimization level of a program that has proling data applied cannot be changed. This is because the proling data is optimization level dependent. v The required proling observability has been removed. Also all applied proling data will be lost if the change request is to enable the program to collect proling data, regardless of whether proling observability has been removed or not. Such a request will result in a program that is enabled to collect proling data. Here are some examples: v Program A has procedure order and block order proling data applied. *BLKORD observability has been removed from the program but *PRCORD observability has not. A CHGPGM command is run to change the performance collection attribute of program A, which also requires the program to be retranslated. This change request will cause program A to no longer be block order proled. However, the procedure order proling data will still be applied. v Program A has procedure order and block order proling data applied. *BLKORD and *PRCORD observability have been removed from the program. A CHGPGM command is run to change the user prole attribute of program A, which also requires the program to be retranslated. This change request will cause program A to no longer be block order or procedure order proled. Program A will go back to the state before the proling data was applied. v Program A has block order proling data applied. *BLKORD observability has been removed from the program. A CHGPGM command is run to change the text of the program, which does not require the program to be translated again. This change request will cause program A to still be block order proled. v Program A has procedure order and block proling data applied. This does not remove *PRCORD and *BLKORD observability from the program. Run a CHGPGM command to enable the program to collect proling data (this retranslates the program). This will cause program A to no longer be block order or procedure order proled. This leaves the program in a state as if proling data was never applied. This enables the program to collect proling data with all proling data counts cleared.
| | | | | | |
How to Tell if a Program or Module is Proled or Enabled for Collection

Use the Display Program (DSPPGM) or Display Service Program (DSPSRVPGM) commands, specifying DETAIL(*BASIC), to determine the program proling data attribute of a program. The value of Proling data will be one of the following values:
136
v *NOCOL - The program is not enabled to collect proling data. v *COL - One or more modules in the program are enabled to collect proling data. This value does not indicate if proling data was actually collected. v *APYALL - Block order and procedure order proling data are applied to this program. The collection of proling data is no longer enabled. v *APYBLKORD - Block order proling data is applied to the procedures of one or more bound modules in this program. This applies to only the bound modules that were previously enabled to collect proling data. The collection of proling data is no longer enabled. v *APYPRCORD- Procedure order program proling data is applied to this program. The collection of proling data is no longer enabled. | | | | | | To have only procedure order proling applied to it, a program is: v First proled specifying *APYALL or *APYPRCORD (which is the same as *APYALL). v Then the *PRCORD observability needs to be removed and the program retranslated. To display the program proling data attribute of a module bound within the program use DSPPGM or DSPSRVPGM DETAIL(*MODULE), specify option 5 on the modules bound into the program, to see the value of this parameter at the module level. The value of Proling data will be one of the following values: v *NOCOL - This bound module is not enabled to collect proling data. v *COL - This bound module is enabled to collect proling data. This value does not indicate if proling data was actually collected. v *APYBLKORD - Block order proling data is applied to one or more procedures of this bound modules. The collection of proling data is no longer enabled. In addition DETAIL(*MODULE) displays the following elds to give an indication of the number of procedures affected by the program proling data attribute. | | v Number of procedures - Total number of procedures in the module. v Number of procedures block reordered - The number of procedures in this module that are basic block reordered. v Number of procedures block order measured - Number of procedures in this bound module that had block order proling data collected when block order proling data was applied. When the benchmark was run, it could be the case that no data was collected for a specic procedure because the procedure was not executed in the benchmark. Thus this count reects the actual number of procedures that were executed with the benchmark. Use DSPMOD command to determine the proling attribute of a module. The value of Proling data will be one of the following. It will never show *APYBLKORD because basic block data can be applied only to modules bound into a program, never to stand-alone modules. v *NOCOL - module is not enabled to collect prole data. v *COL - module is enabled to collect prole data.
137
138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Chapter 13. Shared Storage Synchronization

Shared storage provides an efficient means for communication between two or more concurrently running threads. This chapter discusses a number of issues that are related to shared storage. The primary focus is on data synchronization problems that can arise when accessing shared storage, and how to overcome them. Although not unique to ILE, the programming problems associated with shared storage are more likely to occur in ILE languages than in original MI languages. This is due to the broader support for multiprogramming Application Programming Interfaces in ILE.
Shared Storage
The term shared storage, as it pertains to this discussion, refers to any space data that is accessed from two or more threads. This denition includes any storage directly accessible down to its individual bytes, and can include the following classes of storage: v MI space objects v Primary associated spaces of other MI objects v POSIX shared memory segments v Implicit process spaces: Automatic storage, static storage, and activation-based heap storage v Teraspace The system considers these spaces, regardless of the longevity of their existence, as shared storage when accessed by multiple threads capable of concurrent processing.
Shared Storage Pitfalls

When creating applications which take advantage of shared storage, developers need to avoid two types of problems that can result in unpredictable data values: race conditions and storage access ordering problems. A race condition exists when different program results are possible due solely to the relative timing of two or more cooperating threads. Storage access ordering problems are also known as storage synchronization or memory consistency problems. Two or more cooperating threads relying on a specic ordering of updates to shared storage without serializing the storage accesses cause these problems. There could be a storage access ordering problem if the following condition exists: One thread stores values to two shared variables, and another thread has an implicit dependency on observing those updates in a certain order. You can avoid race conditions by synchronizing the processing of the competing threads so that they interact in a predictable, well-behaved manner. Although the focus of this document is on storage synchronization, the techniques for synchronizing thread execution and synchronizing storage overlap to a great extent. Because of this, the example problems discussed later in this chapter briey touch on race conditions.
139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Shared storage access ordering problems can be avoided by ensuring that storage synchronization actions are performed by both the threads reading from and writing to shared storage. In practice you can solved both types of problems simultaneously using a variety of thread synchronization mechanisms available on the AS/400.
Shared Storage Access Ordering

When threads share storage no guarantee exists that shared storage accesses (reads and writes) performed by one thread will be observed in that particular order by other threads. You can prevent this by having some form of explicit storage synchronization performed by the threads that are reading or writing to the shared storage. Only the following conditions require storage synchronization: Two or more threads are attempting concurrent access to shared storage, and the semantics of the threads logic requires some ordering on the shared storage accesses. When the order in which shared storage updates are observed is not important, no storage synchronization is necessary. A given thread will always observe its own storage updates (to shared or non-shared storage) in order. All threads accessing overlapping shared storage locations will observe those accesses in the same order. Consider the following simple example, which illustrates how both race conditions and storage access ordering problems can lead to unpredictable results.
Thread A -------------Y = 1; X = 1; volatile int X = 0; volatile int Y = 0; Thread B ------------print(X); print(Y);
The table below summarizes the possible results that are printed by B.
X 0 0 Y 0 1 Type of Problem Race Condition Race Condition Explanation Thread B read the variables before the modications of Thread A. Thread B observed the update to Y but printed X before observing Thread As update. Thread B read both variables after the updates of Thread A. Thread B observed the update to X but had yet to see Thread As update to Y. With no explicit data synchronizing actions, this type of out-of-sequence storage access can occur.
1 1
1 0
Race Condition Storage Access Ordering
Example Problem 1: One Writer, Many Readers

Usually, the potential for out-of-order shared storage accesses does not affect the correctness of multi-threaded program logic. However, in some cases, the order threads see that other threads storage updates are vital to the correctness of the program. Let us consider a typical scenario which requires some form of explicit data synchronization. This is when the state of one shared storage location is used
140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | || | | | | | | | | | | |
(by convention in a programs logic) to control access to a second (non-overlapping) shared storage location. For example, assume that one thread initializes some shared data (DATA). Furthermore, assume that the thread then sets a shared ag (FLAG) to indicate to all other threads that the shared data is initialized.
Initializing Thread ------------------DATA = 10 FLAG = 1 All Other Threads --------------------------loop until FLAG has value 1 use DATA
In this case, the sharing threads must enforce an order on the shared storage accesses. Otherwise, other threads might view the initializing threads shared storage updates out of order. This could allow some or all of the other threads to read an uninitialized value from DATA.
Storage Synchronizing Actions

When an ordering of shared storage accesses is required, you must meet the following condition: All threads which require enforcement of an ordering must take explicit action to synchronize the shared storage accesses. These actions are called storage synchronizing actions. A synchronizing action taken by a thread ensures that shared storage accesses appearing prior to the synchronizing action in the threads logical ow complete before those accesses appearing in the logical ow of the code after the synchronizing action. This is from the viewpoint of other threads at their synchronizing actions. In other words, if a thread performs two writes to two shared locations and a synchronizing action separates those writes, the system accomplishes the following: The rst write is guaranteed to be available to other threads at or before their next synchronizing actions, and no later than the second write becomes available. When two reads from two shared locations are separated by a storage synchronizing action, the second read reads a value no less current than the rst read. This is only true when other threads enforce an ordering when writing to the shared storage. The following thread synchronization actions constitute storage synchronizing actions:
Mechanism Object Locks Space Location Locks Mutex Semaphores Pthread Conditions Data Queues Message Queues Compare-and-Swap Synchronizing Action Lock, Unlock Lock, Unlock Lock, Unlock Post, Wait Wait, Signal, Broadcast Enqueue, Dequeue Enqueue, Dequeue Successful store to target All All V3R1M0 V3R2M0 V4R2M0 All V3R2M0 V3R1M0 First Available in VRM
Remember, to completely enforce shared storage access ordering between two or more threads, it is necessary that all threads dependent on the access ordering use appropriate synchronizing actions. This is true for both readers and writers of the
141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
shared data. This agreement between two modem between readers and writers ensures that the order of accesses will remain unchanged by any optimizations that are employed by the underlying machine.
Example 1 Solution
A preferred method for solving the problem in the example above is to avoid the dependency between the data and ag values altogether. You can do this by using a more robust thread synchronization scheme. Although you could employ many of the thread synchronization techniques, one that lends itself well to this problem is a semaphore. (Support for semaphores has been available since AS/400 Version 3, Release 2.) In order for the following logic to be appropriate, you must assume the following: v The program created the semaphore before starting the cooperating threads. v The program initialized the semaphore to a count of 1.
Initializing Thread ------------------DATA = 10 Decrement semaphore All Other Threads --------------------------Wait for semaphore count to reach 0 use DATA
Example Problem 2: Two Contending Writers or Readers

Another common problem requiring additional synchronization is one in which two or more threads attempt to enforce an informal locking protocol, as in the example below. In this example, two threads manipulate data in shared storage. Both threads repeatedly attempt to read and write two shared data items, using a shared ag in an attempt to serialize accesses.
Thread A -------------------------------------/* Do some work on the shared data */ for (int i=0; i<10; ++i) { /* Wait until the locked flag is clear */ while (locked == 1) { sleep(1); } locked = 1; /* Set the lock */ Thread B -------------------------------------/* Do some work on the shared data */ for (int i=0; i<10; ++i) { /* Wait until the locked flag is clear */ while (locked == 1) { sleep(1); } locked = 1; /* Set the lock */
/* Update the shared data */ data1 += 5; data2 += 10; } locked = 0; /* Clear the lock */ }
/* Update the shared data */ data1 += 4; data2 += 6; locked = 0; /* Clear the lock */
This example illustrates both of our shared memory pitfalls. Race Conditions The locking protocol used here has not circumvented the data race conditions. Both jobs could simultaneously see that the locked ag is clear, and thus both fall into the logic which updates the data. At that point, there is no guarantee of which data values will be read, incremented, and written allowing many possible outcomes. Storage Access Ordering Concerns Ignore, for a moment, the race condition mentioned above. Notice that the logic used by both jobs to update the lock and the shared data contains assumptions about the implicit ordering of the eld updates. Specically, there is an assumption on the part of each thread that the other thread will observe that the locked ag has been set to 1 prior to observing changes to the data. Additionally, it is assumed that each thread will observe the changing of the data prior to observing the locked ag value of zero. As noted earlier in this discussion, these assumptions are not valid.
142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Example 2 Solution
To avoid the race condition, and to enforce storage ordering, you should serialize accesses to the shared data by one of the synchronization mechanisms that is enumerated above. This example, where multiple threads are competing for a shared resource, lends itself well to some form of lock. A solution employing a space location lock will be discussed, followed by an alternative solution employing the compare-and-swap mechanism.
THREAD A -------------------------------------for (i=0; i<10; ++i) { /* Get an exclusive lock on the shared data. We go into a wait state until the lock is granted. */ locksl( LOCK_LOC, _LENR_LOCK ); /* Update the shared data */ data1 += 5; data2 += 10; /* Unlock the shared data */ unlocksl( LOCK_LOC, _LENR_LOCK ); THREAD B -----------------------------------for (i=0; i<10; ++i) { /* Get an exclusive lock on the shared data. We go into a wait state until the lock is granted. */ locksl( LOCK_LOC, _LENR_LOCK ); /* Update the shared data */ data1 += 4; data2 += 6; /* Unlock the shared data */ unlocksl( LOCK_LOC, _LENR_LOCK );
Restricting access to the shared data with a lock guarantees that only one thread will be able to access the data at a time. This solves the race condition. This solution also solves the storage access ordering concerns, since there is no longer an ordering dependency between two shared storage locations.
Alternate Solution Using Compare-and-Swap

Space location locks, like those used in the rst solution, are full of features that are not required in this simple example. For instance, space location locks support a time-out value which would allow processing to resume if unable to acquire the lock within some period of time. Space location locks also support several combinations of shared locks. These are important features, but come at the price of some performance overhead. An alternative is to use Compare-and-Swap. This is a lower-level mechanism that can to provide a very simple and fast locking protocol if there is little contention for the lock. In this solution, the system will use Compare-and-Swap to attempt to set the lock. If that attempt fails (because the system found the lock already set), the thread will wait for a while and then try again until acquiring the lock. After updating the shared data, the system will use Compare-and-Swap again to release the lock. In this example, assume that, in addition to the shared data items, the threads also share the address of a location LOCK. Furthermore, assume that the lock was initialized to zero (either through static initialization or some prior synchronized initialization).
THREAD A ---------------------------------------/* Do some work on the shared data */ for (i=0; i<10; ++i) { /* Set the expected value for the lock */ unlck_val = 0; /* Attempt to set the lock using Compare-and-Swap */ while (_CMPSWP(&LOCK, &unlck_val, 1) == 0) { sleep(1); unlck_val = 0; } /* Update the shared data */ data1 += 5; data2 += 10; /* Unlock the shared data... must use CMPSWP again to ensure other jobs/threads see update to shared data prior to clearing of the lock. */ _CMPSWP(&LOCK, &locked_val, 0); THREAD B ---------------------------------------/* Do some work on the shared data */ for (i=0; i<10; ++i) { /* Set the expected value for the lock */ unlck_val = 0; /* Attempt to set the lock using Compare-and-Swap */ while (_CMPSWP(&LOCK, &unlck_val, 1) == 0) { sleep(1); unlck_val = 0; } /* Update the shared data */ data1 += 4; data2 += 6; /* Unlock the shared data... must use CMPSWP again to ensure other jobs/threads see update to shared data prior to clearing of the lock. */ _CMPSWP(&LOCK, &locked_val, 0);
Here, the threads use Compare-and-Swap to perform a race-free test and update of the lock variable. This solves the race condition experienced in the original problem
143
| | | | | |
fragments. It also addresses the storage access ordering problem. As noted earlier, Compare-and-Swap is a synchronizing action. Using Compare-and-Swap to set the lock prior to reading the shared data, ensures that the threads will read the most recently updated data. Using Compare-and-Swap to clear the lock after updating the shared data ensures that the updates are available for subsequent reads by any thread.
144
Appendix A. Output Listing from CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM Command

This appendix shows examples of binder listings and explains errors that could occur as a result of using the binder language.
Binder Listing
The binder listings for the Create Program (CRTPGM), Create Service Program (CRTSRVPGM), Update Program (UPDPGM), and Update Service Program (UPDSRVPGM) commands are almost identical. This topic presents a binder listing from the CRTSRVPGM command used to create the FINANCIAL service program in Binder Language Examples on page 68. Three types of listings can be specied on the detail (DETAIL) parameter of the CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM commands: *BASIC *EXTENDED *FULL
Basic Listing
If you specify DETAIL(*BASIC) on the CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM command, the listing consists of the following: v The values specied on the CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM command v A brief summary table v Data showing the length of time some pieces of the binding process took to complete Figure 49, Figure 50, and Figure 51 on page 147 show this information.
145
Create Service Program Service program . . . . . . . . . . . . . . . . . Library . . . . . . . . . . . . . . . . . . . . Export . . . . . . . . . . . . . . . . . . . . . . Export source file . . . . . . . . . . . . . . . . Library . . . . . . . . . . . . . . . . . . . . Export source member . . . . . . . . . . . . . . . Activation group . . . . . . . . . . . . . . . . . Allow update . . . . . . . . . . . . . . . . . . Allow bound *SRVPGM library name update . . . . . Creation options . . . . . . . . . . . . . . . . . Listing detail . . . . . . . . . . . . . . . . . . User profile . . . . . . . . . . . . . . . . . . . Replace existing service program . . . . . . . . . Target release . . . . . . . . . . . . . . . . . . Allow reinitialization . . . . . . . . . . . . . . Authority . . . . . . . . . . . . . . . . . . . . Text . . . . . . . . . . . . . . . . . . . . . . . Module MONEY RATES Service Program *NONE Binding Directory *NONE Library Binding Directory Library Binding Directory Library Binding Directory Library MYLIB MYLIB Library Module CALCS ACCTS Service Program Library MYLIB MYLIB Library Service Program Library Service Program : : : : : : : : : : : : : : : : : FINANCIAL MYLIB *SRCFILE QSRVSRC MYLIB *SRVPGM *CALLER *YES *NO *GEN *NODUPPROC *FULL *USER *YES *CURRENT *NO *LIBCRTAUT Module Library
Page
*NODUPVAR
*DUPWARN
Module
Library
Library
Library
Figure 49. Values Specied on CRTSRVPGM Command
Create Service Program Brief Summary Table Program entry procedures . . . . . . . . . . . : Multiple strong definitions . . . . . . . . . : Unresolved references . . . . . . . . . . . . : 0 0 0
Page
* * * * *
E N D
O F
B R I E F
S U M M A R Y
T A B L E
* * * * *
Figure 50. Brief Summary Table
146
Create Service Program Binding Statistics Symbol collection CPU time . . . . . . . . Symbol resolution CPU time . . . . . . . . Binding directory resolution CPU time . . Binder language compilation CPU time . . . Listing creation CPU time . . . . . . . . Program/service program creation CPU time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : .018 .006 .403 .040 1.622 .178 2.761 11.522 S T A T I S T I C S
Page
23
Total CPU time . . . . . . . . . . . . . . . . . . . . . . . : Total elapsed time . . . . . . . . . . . . . . . . . . . . . : * * * * * E N D O F B I N D I N G
* * * * *
*CPC5D0B - Service program FINANCIAL created in library MYLIB. * * * * * E N D O F C R E A T E S E R V I C E P R O G R A M L I S T I N G * * * * *
Figure 51. Binding Statistics
Extended Listing
If you specify DETAIL(*EXTENDED) on the CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM command, the listing includes all the information provided by DETAIL(*BASIC) plus an extended summary table. The extended summary table shows the number of imports (references) that were resolved and the number of exports (denitions) processed. For the CRTSRVPGM or UPDSRVPGM command, the listing also shows the binder language used, the signatures generated, and which imports (references) matched which exports (denitions). Figure 52, Figure 53 on page 148, and Figure 54 on page 149 show examples of the additional data.
Create Service Program Extended Summary Table Valid definitions . . . Strong . . . . . . . . Weak . . . . . . . . . Resolved references . . To strong definitions To weak definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : O F 418 418 0 21 21 0 E X T E N D E D S U M M A R Y T A B L E * * * * * Page 2
* * * * *
E N D
Figure 52. Extended Summary Listing
147
Create Service Program Module . . . . . . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000009 Symbol Def Def Def Ref Ref Ref Ref Ref Ref Ref MONEY MYLIB *YES Identifier main Amount Payment Q LE AG_prod_rc Q LE AG_user_rc _C_main Q LE leDefaultEh Q LE mhConversionEh _C_exception_router Binder Information Listing
Page
Type Proc Proc Proc Data Data Proc Proc Proc Proc
Scope Module SrvPgm SrvPgm
Export Strong Strong Strong
Key
0000017F 0000017E 000000AC 00000180 00000181 00000125
Module . . . . . . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 0000000A 0000000B 0000000C 0000000D 0000000E 0000000F 00000010 Symbol Def Def Ref Ref Ref Ref Ref Ref
RATES MYLIB *YES Identifier Term Rate Q LE AG_prod_rc Q LE AG_user_rc Q LE leDefaultEh Q LE mhConversionEh _C_exception_router Type Proc Proc Data Data Proc Proc Proc Scope SrvPgm SrvPgm Export Strong Strong Key
0000017F 0000017E 00000180 00000181 00000125
Module . . . . . . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 00000011 00000012 00000013 00000014 00000015 00000016 00000017 Symbol Def Def Ref Ref Ref Ref Ref Ref
CALCS MYLIB *YES Identifier Calc1 Calc2 Q LE AG_prod_rc Q LE AG_user_rc Q LE leDefaultEh Q LE mhConversionEh _C_exception_router Type Proc Proc Data Data Proc Proc Proc Scope Module Module Export Strong Strong Key
0000017F 0000017E 00000180 00000181 00000125
Module . . . . . . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 00000018 00000019 0000001A 0000001B 0000001C 0000001D 0000001E Symbol Def Def Ref Ref Ref Ref Ref Ref
ACCTS MYLIB *YES Identifier OpenAccount CloseAccount Q LE AG_prod_rc Q LE AG_user_rc Q LE leDefaultEh Q LE mhConversionEh _C_exception_router Type Proc Proc Data Data Proc Proc Proc Scope SrvPgm SrvPgm Export Strong Strong Key
0000017F 0000017E 00000180 00000181 00000125
Figure 53. Binder Information Listing (Part 1 of 2)
148
Service program . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 0000001F Symbol Def Ref
QC2SYS *LIBL *NO Identifier system QLEAWI *LIBL *YES Identifier Q Q Q Q LE LE LE LE AG_user_rc AG_prod_rc leDefaultEh mhConversionEh Type Data Data Proc Proc Scope Export Strong Strong Strong Strong Key Type Proc Scope Export Strong Key
Service program . . . . . . : Library . . . . . . . . . : Bound . . . . . . . . . . : Number 0000017E 0000017F 00000180 00000181 Symbol Def Def Def Def Ref
Figure 53. Binder Information Listing (Part 2 of 2)
Create Service Program Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') EXPORT SYMBOL('OpenAccount') EXPORT SYMBOL('CloseAccount') ENDPGMEXP ******** Export signature: 00000000ADCEFEE088738A98DBA6E723. STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL('Term') EXPORT SYMBOL('Rate') EXPORT SYMBOL('Amount') EXPORT SYMBOL('Payment') ENDPGMEXP ******** Export signature: 000000000000000000ADC89D09E0C6E7. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G
Page
14
* * * * *
Figure 54. Binder Language Listing
Full Listing
If you specify DETAIL(*FULL) on the CRTPGM, CRTSRVPGM, UPDPGM, or UPDSRVPGM command, the listing includes all the detail provided for DETAIL(*EXTENDED) plus a cross-reference listing. Figure 55 on page 150 shows a partial example of the additional data provided.
149
Create Service Program Cross-Reference Listing Identifier . . . xlatewt yn y0 y1 Amount Calc1 Calc2 CloseAccount CEECRHP CEECZST CEEDATE CEEDATM CEEDAYS CEEDCOD CEEDSHP CEEDYWK CEEFMDA CEEFMDT CEEFMTM CEEFRST CEEGMT CEEGPID CEEGTST CEEISEC CEELOCT CEEMGET CEEMKHP CEEMOUT CEEMRCR CEEMSG CEENCOD CEEQCEN CEERLHP CEESCEN CEESECI CEESECS CEESGL CEETREC CEEUTC CEEUTCO CEE4ABN CEE4CpyDvfb CEE4CpyIofb CEE4CpyOfb CEE4DAS CEE4FCB CEE4HC CEE4RAGE CEE4RIN OpenAccount Payment Q LE leBdyCh Q LE leBdyEpilog Q LE leDefaultEh Q LE mhConversionEh Q LE AG_prod_rc Q LE AG_user_rc Q LE HdlrRouterEh Q LE RtxRouterCh Rate Term Defs . . . 000000DD 00000140 0000013E 0000013F 00000002 00000011 00000012 00000019 000001A0 0000019F 000001A9 000001B1 000001A8 00000187 000001A1 000001B3 000001AD 000001AF 000001AE 0000019E 000001B6 00000195 0000019D 000001B0 000001B4 00000183 000001A2 00000184 00000182 00000185 00000186 000001AC 000001A3 000001AB 000001B2 000001AA 00000190 00000191 000001B5 000001B7 00000192 0000019A 00000199 00000198 000001A4 0000018A 00000197 0000018B 00000196 00000018 00000003 00000188 00000189 00000180 00000015 00000181 00000016 0000017F 00000013 0000017E 0000018F 0000018E 0000000B 0000000A --------Refs-------Ref Ref Type . . . *SRVPGM *SRVPGM *SRVPGM *SRVPGM *MODULE *MODULE *MODULE *MODULE *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *MODULE *MODULE *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *SRVPGM *MODULE *MODULE Library . . . *LIBL *LIBL *LIBL *LIBL MYLIB MYLIB MYLIB MYLIB *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL MYLIB MYLIB *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL *LIBL MYLIB MYLIB
Page
15
00000007 00000008 00000004 0000001A 00000005 00000014
0000000E 0000001C 0000000F 0000001D 0000000C 0000000D 0000001B
Object . . . QC2UTIL1 QC2UTIL2 QC2UTIL2 QC2UTIL2 MONEY CALCS CALCS ACCTS QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI ACCTS MONEY QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI QLEAWI RATES RATES
Figure 55. Cross-Reference Listing
150
Listing for Example Service Program

Figure 51 on page 147, Figure 53 on page 148, and Figure 55 on page 150 show some of the listing data generated when DETAIL(*FULL) was specied to create the FINANCIAL service program in Figure 38 on page 72. The gures show the binding statistics, the binder information listing, and the cross-reference listing.
Binder Information Listing for Example Service Program

The binder information listing ( Figure 53 on page 148) includes the following data and column headings: v The library and name of the module or service program that was processed. If the Bound eld shows a value of *YES for a module object, the module is marked to be bound by copy. If the Bound eld shows a value of *YES for a service program, the service program is bound by reference. If the Bound eld shows a value of *NO for either a module object or service program, that object is not included in the bind. The reason is that the object did not provide an export that satised an unresolved import. v Number For each module or service program that was processed, a unique identier (ID) is associated with each export (denition) or import (reference). v Symbol This column identies the symbol name as an export (Def) or an import (Ref). v Ref A number specied in this column (Ref) is the unique ID of the export (Def) that satises the import request. For example, in Figure 53 on page 148 the unique ID for the import 00000005 matches the unique ID for the export 0000017E. v Identier This is the name of the symbol that is exported or imported. The symbol name imported for the unique ID 00000005 is Q LE AG_user_rc. The symbol name exported for the unique ID 0000017E is also Q LE AG_user_rc. v Type If the symbol name is a procedure, it is identied as Proc. If the symbol name is a data item, it is identied as Data. v Scope For modules, this column identies whether an exported symbol name is accessed at the module level or at the public interface to a service program. If a program is being created, the exported symbol names can be accessed only at the module level. If a service program is being created, the exported symbol names can be accessed at the module level or the service program (SrvPgm) level. If an exported symbol is a part of the public interface, the value in the Scope column must be SrvPgm. v Export This column identies the strength of a data item that is exported from a module or service program. v Key This column contains additional information about any weak exports. Typically this column is blank.
151
Cross-Reference Listing for Example Service Program

The cross-reference listing in Figure 55 on page 150 is another way of looking at the data presented in the binder information. The cross-reference listing includes the following column headings: v Identier The name of the export that was processed during symbol resolution. v Defs The unique ID associated with each export. v Refs A number in this column indicates the unique ID of the import (Ref) that was resolved to this export (Def). v Type Identies whether the export came from a *MODULE or a *SRVPGM object. v Library The library name as it was specied on the command or in the binding directory. v Object The name of the object that provided the export (Def).
Binding Statistics for Example Service Program

Figure 51 on page 147 shows a set of statistics for creating the service program FINANCIAL. The statistics identify where the binder spent time when it was processing the create request. You have only indirect control over the data presented in this section. Some amount of processing overhead cannot be measured. Therefore, the value listed in the Total CPU time eld is larger than the sum of the times listed in the preceding elds.
Binder Language Errors

While the system is processing the binder language during the creation of a service program, an error might occur. If DETAIL(*EXTENDED) or DETAIL(*FULL) is specied on the Create Service Program (CRTSRVPGM) command, you can see the errors in the spooled le. The following information messages could occur: v Signature padded v Signature truncated The following warning errors could occur: v Current export block limits interface v v v v Duplicate export block Duplicate symbol on previous export Level checking cannot be disabled more than once, ignored Multiple current export blocks not allowed, previous assumed
The following serious errors could occur: v Current export block is empty v Export block not completed, end-of-le found before ENDPGMEXP
152
v v v v v v v v v v v v
Export block not started, STRPGMEXP required Export blocks cannot be nested, ENDPGMEXP missing Exports must exist inside export blocks Identical signatures for dissimilar export blocks, must change exports Multiple wildcard matches No current export block No wildcard match Previous export block is empty Signature contains variant characters SIGNATURE(*GEN) required with LVLCHK(*NO) Signature syntax not valid Symbol name required
v Symbol not allowed as service program export v Symbol not dened v Syntax not valid
Signature Padded
Figure 56 shows a binder language listing that contains this message.
Binder Language Listing STRPGMEXP SIGNATURE('Short signature') ******** Signature padded EXPORT SYMBOL('Proc_2') ENDPGMEXP ******** Export signature: E2889699A340A289879581A3A4998540. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 56. The Signature Provided Was Shorter than 16 Bytes, So It Is Padded
This is an information message.
Suggested Changes
No changes are required. If you wish to avoid the message, make sure that the signature being provided is exactly 16 bytes long.
Signature Truncated
Figure 57 on page 154 shows a binder language listing that contains this message.
153
Binder Language Listing STRPGMEXP SIGNATURE('This signature is very long') ******** Signature truncated EXPORT SYMBOL('Proc_2') ENDPGMEXP ******** Export signature: E38889A240A289879581A3A499854089. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 57. Only the First 16 Bytes of Data Provided Are Used for the Signature
This is an information message.
Suggested Changes
No changes are required. If you wish to avoid the message, make sure that the signature being provided is exactly 16 bytes long.
Current Export Block Limits Interface

Figure 58 shows a binder language listing that contains this error.
Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL(A) EXPORT SYMBOL(B) EXPORT SYMBOL(C) ENDPGMEXP ******** Export signature: 0000000000000000000000000000CDE3. ******** Current export block limits interface. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 58. A PGMLVL(*PRV) Exported More Symbols than the PGMLVL(*CURRENT)
This is a warning error. A PGMLVL(*PRV) export block has specied more symbols than the PGMLVL(*CURRENT) export block. If no other errors occurred, the service program is created. If both of the following are true: v PGMLVL(*PRV) had supported a procedure named C v Under the new service program, procedure C is no longer supported any ILE program or service program that called procedure C in this service program gets an error at run time.
154
Suggested Changes
1. Make sure that the PGMLVL(*CURRENT) export block has more symbols to be exported than a PGMLVL(*PRV) export block. 2. Run the CRTSRVPGM command again. In this example, the EXPORT SYMBOL(C) was incorrectly added to the STRPGMEXP PGMLVL(*PRV) block instead of to the PGMLVL(*CURRENT) block.
Duplicate Export Block

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. ******** Duplicate export block. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 59. Duplicate STRPGMEXP/ENDPGMEXP Blocks
This is a warning error. More than one STRPGMEXP and ENDPGMEXP block exported all the same symbols in the exact same order. If no other errors occurred, the service program is created. The duplicated signature is included only once in the created service program.
Suggested Changes
1. Make one of the following changes: v Make sure that the PGMLVL(*CURRENT) export block is correct. Update it as appropriate. v Remove the duplicate export block. 2. Run the CRTSRVPGM command again. In this example, the STRPGMEXP command with PGMLVL(*CURRENT) specied needs to have the following source line added after EXPORT SYMBOL(B):
EXPORT SYMBOL(C)
Duplicate Symbol on Previous Export

Figure 60 on page 156 shows a binder language listing that contains a duplicate symbol error.
155
Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) EXPORT SYMBOL(A) ******** Duplicate symbol on previous export EXPORT SYMBOL(C) ENDPGMEXP ******** Export signature: 000000000000000000000000000CDED3. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 60. Duplicate Exported Symbols
This is a warning error. A symbol to be exported from the service program was specied more than once in a STRPGMEXP and ENDPGMEXP block. If no other errors occurred, the service program is created. Only the rst duplicate symbol is exported from the service program. All duplicate symbols affect the signature that is generated.
Suggested Changes
1. Remove one of the duplicate source lines from the binder language source le. 2. Run the CRTSRVPGM command again. In this example, remove the second EXPORT SYMBOL(A).
Level Checking Cannot Be Disabled More than Once, Ignored

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*NO) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000000. STRPGMEXP PGMLVL(*PRV) LVLCHK(*NO) ******** Level checking cannot be disabled more than once, ignored EXPORT SYMBOL(A) ENDPGMEXP ******** Export signature: 000000000000000000000000000000C1. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 61. Multiple STRPGMEXP Commands Have LVLCHK(*NO) Specied
This is a warning error. More than one STRPGMEXP blocks specied LVLCHK(*NO). If no other errors occurred, the service program is created. The second and subsequent LVLCHK(*NO) are assumed to be LVLCHK(*YES).
156
Suggested Changes
1. Make sure that only one STRPGMEXP block has LVLCHK(*NO) specied. 2. Run the CRTSRVPGM command again. In this example, the PGMLVL(*PRV) export block is the only export block that has LVLCHK(*NO) specied. The LVLCHK(*NO) value is removed from the PGMLVL(*CURRENT) export block.
Multiple Current Export Blocks Not Allowed, Previous Assumed

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) EXPORT SYMBOL(C) ENDPGMEXP ******** Export signature: 0000000000000000000000000000CDE3. STRPGMEXP EXPORT SYMBOL(A) ******** Multiple 'current' export blocks not allowed, 'previous' assumed. EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 62. More than One PGMLVL(*CURRENT) Value Specied
This is a warning error. A value of PGMLVL(*CURRENT) was specied or was allowed to default to PGMLVL(*CURRENT) on more than one STRPGMEXP command. The second and subsequent export blocks with a value of PGMLVL(*CURRENT) are assumed to be PGMLVL(*PRV). If no other errors occurred, the service program is created.
Suggested Changes
1. Change the appropriate source text to STRPGMEXP PGMLVL(*PRV). 2. Run the CRTSRVPGM command again. In this example, the second STRPGMEXP is the one to change.
Current Export Block Is Empty

Figure 63 on page 158 shows a binder language listing that contains this error.
157
Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) ENDPGMEXP ******** Export signature: 00000000000000000000000000000000. ***ERROR Current export block is empty. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 63. No Symbols to Be Exported from the STRPGMEXP PGMLVL(*CURRENT) Block
This is a serious error. No symbols are identied to be exported from the *CURRENT export block. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add the symbol names to be exported. v Remove the empty STRPGMEXP-ENDPGMEXP block, and make another STRPGMEXP-ENDPGMEXP block as PGMLVL(*CURRENT). 2. Run the CRTSRVPGM command. In this example, the following source line is added to the binder language source le between the STRPGMEXP and ENDPGMEXP commands:
EXPORT SYMBOL(A)
Export Block Not Completed, End-of-File Found before ENDPGMEXP

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) ***ERROR Syntax not valid. ***ERROR Export block not completed, end-of-file found before ENDPGMEXP. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 64. No ENDPGMEXP Command Found, but the End of the Source File Was Found
This is a serious error. No ENDPGMEXP was found before the end of the le was reached. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add the ENDPGMEXP command in the appropriate place. v Remove any STRPGMEXP command that does not have a matching ENDPGMEXP command, and remove any symbol names to be exported.
158
2. Run the CRTSRVPGM command. In this example, the following lines are added after the STRPGMEXP command:
EXPORT SYMBOL(A) ENDPGMEXP
Export Block Not Started, STRPGMEXP Required

Binder Language Listing ENDPGMEXP ***ERROR Export block not started, STRPGMEXP required. ***ERROR No 'current' export block * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 65. STRPGMEXP Command Is Missing
This is a serious error. No STRPGMEXP command was found prior to nding an ENDPGMEXP command. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add the STRPGMEXP command. v Remove any exported symbols and the ENDPGMEXP command. 2. Run the CRTSRVPGM command. In this example, the following two source lines are added to the binder language source le before the ENDPGMEXP command.
STRPGMEXP EXPORT SYMBOL(A)
Export Blocks Cannot Be Nested, ENDPGMEXP Missing

159
Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) STRPGMEXP PGMLVL(*PRV) ***ERROR Export blocks cannot be nested, ENDPGMEXP missing. EXPORT SYMBOL(A) ENDPGMEXP ******** Export signature: 000000000000000000000000000000C1. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 66. ENDPGMEXP Command Is Missing
This is a serious error. No ENDPGMEXP command was found prior to nding another STRPGMEXP command. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add the ENDPGMEXP command prior to the next STRPGMEXP command. v Remove the STRPGMEXP command and any symbol names to be exported. 2. Run the CRTSRVPGM command. In this example, an ENDPGMEXP command is added to the binder source le prior to the second STRPGMEXP command.
Exports Must Exist inside Export Blocks

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. EXPORT SYMBOL(A) ***ERROR Exports must exist inside export blocks. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 67. Symbol Name to Be Exported Is outside the STRPGMEXP-ENDPGMEXP Block
This is a serious error. A symbol to be exported is not dened within a STRPGMEXP-ENDPGMEXP block. The service program is not created.
160
Suggested Changes
1. Make one of the following changes: v Move the symbol to be exported. Put it within a STRPGMEXP-ENDPGMEXP block. v Remove the symbol. 2. Run the CRTSRVPGM command. In this example, the source line in error is removed from the binder language source le.
Identical Signatures for Dissimilar Export Blocks, Must Change Exports

This is a serious error. Identical signatures have been generated from STRPGMEXP-ENDPGMEXP blocks that exported different symbols. This error condition is highly unlikely to occur. For any set of nontrivial symbols to be exported, this error should occur only once every 3.4E28 tries. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add an additional symbol to be exported from the PGMLVL(*CURRENT) block. The preferred method is to specify a symbol that is already exported. This would cause a warning error of duplicate symbols but would help ensure that a signature is unique. An alternative method is to add another symbol to be exported that has not been exported. v Change the name of a symbol to be exported from a module, and make the corresponding change to the binder language source le. v Specify a signature by using the SIGNATURE parameter on the Start Program Export (STRPGMEXP) command. 2. Run the CRTSRVPGM command.
Multiple Wildcard Matches

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT ("A"<<<) ***ERROR Multiple matches of wildcard specification EXPORT ("B"<<<) ENDPGMEXP ******** Export signature: 0000000000000000000000000000FFC2. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G
Figure 68. Multiple Matches of Wildcard Specication
161
This is a serious error. A wildcard specied for export matched more than one symbol available for export. The service program is not created.
Suggested Changes
1. Specify a wildcard with more detail so that the desired matching export is the only matching export. 2. Run the CRTSRVPGM command.
No Current Export Block

Binder Language Listing STRPGMEXP PGMLVL(*PRV) EXPORT SYMBOL(A) ENDPGMEXP ******** Export signature: 000000000000000000000000000000C1. ***ERROR No 'current' export block * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 69. No PGMLVL(*CURRENT) Export Block
This is a serious error. No STRPGMEXP PGMLVL(*CURRENT) is found in the binder language source le. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Change a PGMLVL(*PRV) to PGMLVL(*CURRENT). v Add a STRPGMEXP-ENDPGMEXP block that is the correct *CURRENT export block. 2. Run the CRTSRVPGM command. In this example, the PGMLVL(*PRV) is changed to PGMLVL(*CURRENT).
No Wildcard Matches
162
Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT ("Z"<<<) ***ERROR No matches of wildcard specification EXPORT ("B"<<<) ENDPGMEXP ******** Export signature: 0000000000000000000000000000FFC2. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G
Figure 70. No Matches of Wildcard Specication
This is a serious error. A wildcard specied for export did not match any symbols available for export. The service program is not created.
Suggested Changes
1. Specify a wildcard that matches the symbol desired for export. 2. Run the CRTSRVPGM command.
Previous Export Block Is Empty

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(B) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD2. STRPGMEXP PGMLVL(*PRV) ENDPGMEXP ******** Export signature: 00000000000000000000000000000000. ***ERROR Previous export block is empty. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 71. No PGMLVL(*CURRENT) Export Block
This is a serious error. A STRPGMEXP PGMLVL(*PRV) was found, and no symbols were specied. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Add symbols to the STRPGMEXP-ENDPGMEXP block that is empty. v Remove the STRPGMEXP-ENDPGMEXP block that is empty. 2. Run the CRTSRVPGM command.
163
In this example, the empty STRPGMEXP-ENDPGMEXP block is removed from the binder language source le.
Signature Contains Variant Characters

Binder Language Listing STRPGMEXP SIGNATURE('\!cdefghijklmnop') ***ERROR Signature contains variant characters EXPORT SYMBOL('Proc_2') ENDPGMEXP ******** Export signature: E05A8384858687888991929394959697. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 72. Signature Contains Variant Characters
This is a serious error. The signature contains characters that are not in all coded character set identiers (CCSIDs). The service program is not created.
Suggested Changes
1. Remove the variant characters. 2. Run the CRTSRVPGM command. In this specic case, it is the \! that needs to be removed.
SIGNATURE(*GEN) Required with LVLCHK(*NO)

Binder Language Listing STRPGMEXP SIGNATURE('ABCDEFGHIJKLMNOP') EXPORT SYMBOL('Proc_2') ***ERROR SIGNATURE(*GEN) required with LVLCHK(*NO) ENDPGMEXP LVLCHK(*NO)
******** Export signature: C1C2C3C4C5C6C7C8C9D1D2D3D4D5D6D7. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 73. If LVLCHK(*NO) Is Specied, an Explicit Signature Is Not Valid
This is a serious error. If LVLCHK(*NO) is specied, SIGNATURE(*GEN) is required. The service program is not created.
164
Suggested Changes
1. Make one of the following changes: v Specify SIGNATURE(*GEN) v Specify LVLCHK(*YES) 2. Run the CRTSRVPGM command.
Signature Syntax Not Valid

Binder Language Listing ***ERROR ***ERROR ***ERROR ***ERROR STRPGMEXP SIGNATURE('"abcdefghijkl "') Signature syntax not valid Signature syntax not valid Syntax not valid. Syntax not valid. EXPORT SYMBOL('Proc_2') ENDPGMEXP * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 74. What Is Specied for the Signature Value Is Not Valid
This is a serious error. The signature contains invalid characters. The service program is not created.
Suggested Changes
1. Remove invalid characters from the signature value. 2. Run the CRTSRVPGM command. In this case, remove the characters from the signature eld.
Symbol Name Required

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(') ***ERROR Symbol name required. ENDPGMEXP ******** Export signature: 000000000000000000000000000000C1. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 75. No Symbol to Be Exported
This is a serious error.
165
No symbol name was found to export from the service program. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Remove the line in error from the binder language source le. v Add a symbol name to be exported from the service program. 2. Run the CRTSRVPGM command. In this example, the source line EXPORT SYMBOL("") is removed from the binder language source le.
Symbol Not Allowed as Service Program Export

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) ***ERROR Symbol not allowed as service program export. EXPORT SYMBOL(D) ENDPGMEXP ******** Export signature: 00000000000000000000000000000CD4. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 76. Symbol Name Not Valid to Export from Service Program
This is a serious error. The symbol to be exported from the service program was not exported from one of the modules to be bound by copy. Typically the symbol specied to be exported from the service program is actually a symbol that needs to be imported by the service program. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Remove the symbol in error from the binder language source le. v On the MODULE parameter of the CRTSRVPGM command, specify the module that has the desired symbol to be exported. v Add the symbol to one of the modules that will be bound by copy, and re-create the module object. 2. Run the CRTSRVPGM command. In this example, the source line of EXPORT SYMBOL(A) is removed from the binder language source le.
166
Symbol Not Dened

Binder Language Listing STRPGMEXP PGMLVL(*CURRENT) EXPORT SYMBOL(A) EXPORT SYMBOL(Q) ***ERROR Symbol not defined. ENDPGMEXP ******** Export signature: 00000000000000000000000000000CE8. * * * * * E N D O F B I N D E R L A N G U A G E L I S T I N G * * * * *
Figure 77. Symbol Not Found in the Modules That Are to Be Bound by Copy
This is a serious error. The symbol to be exported from the service program could not be found in the modules that are to be bound by copy. The service program is not created.
Suggested Changes
1. Make one of the following changes: v Remove the symbol that is not dened from the binder language source le. v On the MODULE parameter of the CRTSRVPGM command, specify the module that has the desired symbol to be exported. v Add the symbol to one of the modules that will be bound by copy, and re-create the module object. 2. Run the CRTSRVPGM command. In this example, the source line of EXPORT SYMBOL(Q) is removed from the binder language source le.
Syntax Not Valid

This is a serious error. The statements in the source member are not valid binder language statements. The service program is not created.
Suggested Changes
1. Correct the source member so it contains valid binder language statements. 2. Run the CRTSRVPGM command.
167
168
Appendix B. Exceptions in Optimized Programs

In rare circumstances, an MCH3601 exception message may occur in programs compiled with optimization level 30 (*FULL) or 40. This appendix explains one example in which this message occurs. The same program does not receive an MCH3601 exception message when compiled with optimization level 10 (*NONE) or 20 (*BASIC). Whether the message in this example occurs depends on how your ILE HLL compiler allocates storage for arrays. This example might never occur for your language. When you ask for optimization level 30 (*FULL) or 40, ILE attempts to improve performance by calculating array index references outside of loops. When you refer to an array in a loop, you are often accessing every element in order. Performance can be improved by saving the last array element address from the previous loop iteration. To accomplish this performance improvement, ILE calculates the rst array element address outside the loop and saves the value for use inside the loop. Take the following example:
DCL ARR[1000] INTEGER; DCL I INTEGER; I = init_expression; /* More statements */ WHILE ( I < limit_expression ) I = I + 1; /* Some statements in the while loop */ ARR[I] = some_expression; /* Other statements in the while loop */ END; /* Assume that init_expression evaluates to -1 which is then assigned to I */
If a reference to ARR[init_expression] would have produced an incorrect array index, this example can cause an MCH3601 exception. This is caused by ILE attempting to calculate the rst array element address prior to entering the WHILE loop. If you receive MCH3601 exceptions at optimization level 30 (*FULL) or 40, look for the following situation: 1. You have a loop that increments a variable before it uses the variable as an array element index. 2. The initial value of the index variable on entrance to the loop is negative. 3. A reference to the array using the initial value of the variable is not valid. When these conditions exist, it may be possible to do the following so that optimization level 30 (*FULL) or 40 can still be used: 1. Move the part of the program that increments the variable to the bottom of the loop. 2. Change the references to the variables as needed. The previous example would be changed as follows:
169
I = init_expression + 1; WHILE ( I < limit_expression + 1 ) ARR[I] = some_expression; I = I + 1; END;
If this change is not possible, reduce the optimization level from 30 (*FULL) or 40 to 20 (*BASIC) or 10 (*NONE).
170
Appendix C. CL Commands Used with ILE Objects

The following lists indicate which CL commands can be used with each ILE object.
CL Commands Used with Modules

CHGMOD Change Module CRTCMOD Create C Module CRTCBLMOD Create COBOL Module CRTCLMOD Create CL Module CRTRPGMOD Create RPG Module DLTMOD Delete Module DSPMOD Display Module RTVBNDSRC Retrieve Binder Source WRKMOD Work with Module
CL Commands Used with Program Objects

CHGPGM Change Program CRTBNDC Create Bound C Program CRTBNDCBL Create Bound COBOL Program CRTBNDCL Create Bound CL Program CRTBNDRPG Create Bound RPG Program CRTPGM Create Program DLTPGM Delete Program DSPPGM Display Program DSPPGMREF Display Program References
171
UPDPGM Update Program WRKPGM Work with Program
CL Commands Used with Service Programs

CHGSRVPGM Change Service Program CRTSRVPGM Create Service Program DLTSRVPGM Delete Service Program DSPSRVPGM Display Service Program UPDSRVPGM Update Service Program WRKSRVPGM Work with Service Program
CL Commands Used with Binding Directories

ADDBNDDIRE Add Binding Directory Entry CRTBNDDIR Create Binding Directory DLTBNDDIR Delete Binding Directory DSPBNDDIR Display Binding Directory RMVBNDDIRE Remove Binding Directory Entry WRKBNDDIR Work with Binding Directory WRKBNDDIRE Work with Binding Directory Entry
CL Command Used with Structured Query Language

CRTSQLCI Create Structured Query Language ILE C/400 Object CRTSQLCBLI Create Structured Query Language ILE COBOL/400 Object CRTSQLRPGI Create Structured Query Language ILE RPG/400 Object
172
CL Commands Used with Source Debugger

DSPMODSRC Display Module Source ENDDBG End Debug STRDBG Start Debug
CL Commands Used to Edit the Binder Language Source File

STRPDM Start Programming Development Manager STRSEU Start Source Entry Utility The following nonrunnable commands can be entered into the binder language source le: ENDPGMEXP End Program Export EXPORT Export STRPGMEXP Start Program Export
Appendix C. CL Commands Used with ILE Objects
173
174
Appendix D. Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs
175
and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation Software Interoperability Coordinator 3605 Highway 52 N Rochester, MN 55901-7829 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot conrm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBMs future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are ctitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBMs application programming interfaces. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Trademarks
The following terms are trademarks of International Business Machines Corporation in the United States, or other countries, or both:
176
Application System/400 AS/400 C/400 COBOL/400 DB2 DB2/400 IBM ILE Integrated Language Environment Language Environment Operating System/400 OS/2 OS/400 RPG/400 RPG IV SAA System 36 Systems Application Architecture 400 Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and/or other countries licensed exclusively through X/Open Company Limited. Other company, product, and service names may be trademarks or service marks of others.
Appendix D. Notices
177
178
Bibliography
For additional information about topics related to the ILE environment on the AS/400 system, refer to the following IBM AS/400 publications: v Backup and Recovery, SC41-5304-03, provides information about planning a backup and recovery strategy, the different types of media available to save and restore system data, as well as a description of how to record changes made to database les using journaling and how that information can be used for system recovery. This manual describes how to plan for and set up user auxiliary storage pools (ASPs), mirrored protection, and checksums along with other availability recovery topics. It also describes how to install the system again from backup. v CL Programming, SC41-5721-02, provides a wide-ranging discussion of AS/400 programming topics, including a general discussion of objects and libraries, CL programming, controlling ow and communicating between programs, working with objects in CL programs, and creating CL programs. Other topics include predened and impromptu messages and message handling, dening and creating user-dened commands and menus, application testing, including debug mode, breakpoints, traces, and display functions. v CL Reference (Abridged), SC41-5722-03, provides a description of the AS/400 control language (CL) and its OS/400 commands. (Non-OS/400 commands are described in the respective licensed program publications.) It also provides an overview of all the CL commands for the AS/400 system, and it describes the syntax rules needed to code them. v Communications Management, SC41-5406-02, provides information about work management in a communications environment, communications status, tracing and diagnosing communications problems, error handling and recovery, performance, and specic line speed and subsystem storage information. v Data Management, SC41-5710-00, provides information about using les in application programs. This manual includes information on the following topics: Fundamental structure and concepts of data management support on the system.
Overrides and le redirection (temporarily making changes to les when an application program is run). Copying les by using system commands to copy data from one place to another. Tailoring a system using double-byte data. v DB2 UDB for AS/400 Database Programming, SC41-5701-02, provides a detailed discussion of the AS/400 database organization, including information on how to create, describe, and update database les on the system. This manual also describes how to dene les to the system using OS/400 data description specications (DDS) keywords. v Distributed Data Management, SC41-5307-00, provides information about remote le processing. It describes how to dene a remote le to OS/400 distributed data management (DDM), how to create a DDM le, what le utilities are supported through DDM, and the requirements of OS/400 DDM as related to other systems. v ICF Programming, SC41-5442-00, provides information needed to write application programs that use AS/400 communications and the OS/400 intersystem communications function (OS/400-ICF). This guide also contains information on data description specications (DDS) keywords, system-supplied formats, return codes, le transfer support, and program examples. v ILE C for AS/400 Programmers Guide, SC09-2712-01, provides information on how to develop applications using the ILE C/400 language. It includes information about creating, running, and debugging programs. It also includes programming considerations for interlanguage program and procedure calls, locales, exception handling, database les, externally described les, and device les. Some performance tips are also described. An appendix includes information on migrating source code from EPM C/400 or System C/400 to ILE C/400. v ILE C for AS/400 Language Reference, SC09-2711-01, provides information about how to write programs that adhere to the Systems Application Architecture C Level 2 denition and use ILE C/400 specic functions such as record I/O. It also provides information on ILE C/400 machine interface library functions.
179
v ILE C for AS/400 Run-Time Library Reference, SC09-2715-00, provides quick reference information about ILE C/400 command syntax, elements of C, SAA C library functions, ILE C/400 library extensions to SAA C, and ILE C/400 machine interface library extensions. v ILE COBOL for AS/400 Programmers Guide, SC09-2540-01, describes how to write, compile, bind, run, debug, and maintain ILE COBOL/400 programs on the AS/400 system. It provides programming information on how to call other ILE COBOL/400 and non-ILE COBOL/400 programs, share data with other programs, use pointers, and handle exceptions. It also describes how to perform input/output operations on externally attached devices, database les, display les, and ICF les. v ILE COBOL for AS/400 Reference, SC09-2539-01, describes the ILE COBOL/400 programming language. It provides information on the structure of the ILE COBOL/400 programming language and on the structure of an ILE COBOL/400 source program. It also describes all Identication Division paragraphs, Environment Division clauses, Data Division paragraphs, Procedure Division statements, and Compiler-Directing statements. v ILE RPG for AS/400 Programmers Guide, SC09-2507-02, is a guide for using the RPG IV programming language, which is an implementation of ILE RPG/400 in the Integrated Language Environment (ILE) on the AS/400 system. It includes information on creating and running programs, with considerations for procedure calls and interlanguage programming. The guide also covers debugging and exception handling and explains how to use AS/400 les and devices in RPG programs. Appendixes include information on migration to RPG IV and sample compiler listings. It is intended for people with a basic understanding of data processing concepts and of the RPG language. v ILE RPG for AS/400 Reference, SC09-2508-02, provides information needed to write programs for the AS/400 system using the RPG IV programming language. This manual describes, position by position and keyword by keyword, the valid entries for all RPG specications, and provides a detailed description of all the operation codes and built-in functions. This manual also contains information on the RPG logic cycle, arrays and tables, editing functions, and indicators.
v Intrasystem Communications Programming, SC41-5447-00, provides information about interactive communications between two application programs on the same AS/400 system. This guide describes the communications operations that can be coded into a program that uses intrasystem communications support to communicate with another program. It also provides information on developing intrasystem communications application programs that use the OS/400 intersystem communications function (OS/400-ICF). v Security - Basic, SC41-5301-00, explains why security is necessary, denes major concepts, and provides information on planning, implementing, and monitoring basic security on the AS/400 system. v Security - Reference, SC41-5302-03, tells how system security support can be used to protect the system and the data from being used by people who do not have the proper authorization, protect the data from intentional or unintentional damage or destruction, keep security information up-to-date, and set up security on the system. v System API Reference, SC41-5801-03, provides information for the experienced programmer on how to use the application programming interfaces (APIs) to such OS/400 functions as: Conguration Database les Dynamic Screen Manager Message handling Network management Security Source debugging Spooled les User interface User object User-dened communications
Work management Working with software products This book includes both original program model (OPM) and Integrated Language Environment (ILE) APIs. Some of the APIs provide an alternative to the CL commands. v Work Management, SC41-5306-03, provides information about how to create and change a work management environment. Other topics
180
include a description of tuning the system, collecting performance data including information on record formats and contents of the data being collected, working with system values to control or change the overall operation of the system, and a description of how to gather data to determine who is using the system and what resources are being used.
Bibliography
181
182
Index Special Characters

_C_TS_calloc() 103 _C_TS_free( 103 _C_TS_malloc() 103 _C_TS_realloc() 103 _CEE4ALC allocation strategy type activation group (continued) user-named (continued) description 33, 83 advanced concepts 27 ALWLIBUPD parameter on CRTPGM command 78 on CRTSRVPGM command 78 ALWUPD parameter on CRTPGM command 78 on CRTSRVPGM command 78 API (application programming interface) Abnormal End (CEE4ABN) 109 activation group 127 CEE4ABN (Abnormal End) 109 CEEDOD (Retrieve Operational Descriptor Information) 95 CEEHDLR (Register User-Written Condition Handler) 43, 105 CEEHDLU (Unregister User-Written Condition Handler) 43 CEEMGET (Get Message) 113 CEEMOUT (Dispatch Message) 113 CEEMRCR (Move Resume Cursor) 107 CEEMSG (Get, Format and Dispatch Message) 113 CEENCOD (Construct Condition Token) 110 CEESGI (Get String Information) 95 CEESGL (Signal Condition) condition token 110, 113 description 40 CEETSTA (Test for Omitted Argument) 93 Change Exception Message (QMHCHGEM) 107 condition management 128, 129 Construct Condition Token (CEENCOD) 110 control ow 127 date 128 debugger 129 Dispatch Message (CEEMOUT) 113 dynamic screen manager (DSM) 130 error handling 129 exception management 128, 129 Get, Format and Dispatch Message (CEEMSG) 113 Get Message (CEEMGET) 113 Get String Information (CEESGI) 95 HLL independence 127 list of 127, 130 math 128 message handling 129 Move Resume Cursor (CEEMRCR) 107 naming conventions 127 original program model (OPM) and ILE 96 procedure call 129 program call 129 Promote Message (QMHPRMM) 108 QCAPCMD 86 QMHCHGEM (Change Exception Message) 107 QMHPRMM (Promote Message) 108 QMHSNDPM (Send Program Message) 40, 105
102
A
Abnormal End (CEE4ABN) bindable API 109 access ordering shared storage 140 ACTGRP 79 ACTGRP (activation group) parameter 31 *CALLER value 86 activation group creation 31 program activation 28, 31 actions storage synchronizing 141 activation description 23 dynamic program call 93 program 27 program activation 34 service program 34, 90 activation group ACTGRP (activation group) parameter *CALLER value 86 activation group creation 28 program activation 28, 31 benets of resource scoping 3 bindable APIs (application programming interfaces) 127 call stack example 28 commitment control example 4 scoping 123 control boundary activation group deletion 33 example 36 creation 30 data management scoping 47, 123 default 31 deletion 32 management 83 mixing COBOL with other languages 4 multiple applications running in same job 83 original program model (OPM) 31 reclaim resources 84, 86 resource isolation 29 resources 29 reuse 32 scoping 47, 123 service program 86 shared open data path (ODP) example 3 system-named 31, 33 user-named deletion 33
183
API (application programming interface) (continued) Register User-Written Condition Handler (CEEHDLR) 109, 105 Retrieve Operational Descriptor Information (CEEDOD) 95 Send Program Message (QMHSNDPM) 40, 105 services 2 Signal Condition (CEESGL) condition token 110, 113 description 40 source debugger 129 storage management 130 supplementing HLL-specic run-time library 127 Test for Omitted Argument (CEETSTA) 93 time 128 Unregister User-Written Condition Handler (CEEHDLU) 43 application multiple running in same job 83 application development tools 6 application programming interface (API) Abnormal End (CEE4ABN) 109 activation group 127 CEE4ABN (Abnormal End) 109 CEEDOD (Retrieve Operational Descriptor Information) 95 CEEHDLR (Register User-Written Condition Handler) 43, 105 CEEHDLU (Unregister User-Written Condition Handler) 43 CEEMGET (Get Message) 113 CEEMOUT (Dispatch Message) 113 CEEMRCR (Move Resume Cursor) 107 CEEMSG (Get, Format and Dispatch Message) 113 CEENCOD (Construct Condition Token) 110 CEESGI (Get String Information) 95 CEESGL (Signal Condition) condition token 110, 113 description 40 CEETSTA (Test for Omitted Argument) 93 Change Exception Message (QMHCHGEM) 107 condition management 128, 129 Construct Condition Token (CEENCOD) 110 control ow 127 date 128 debugger 129 Dispatch Message (CEEMOUT) 113 dynamic screen manager (DSM) 130 error handling 129 exception management 128, 129 Get, Format and Dispatch Message (CEEMSG) 113 Get Message (CEEMGET) 113 Get String Information (CEESGI) 95 HLL independence 127 list of 127, 130 math 128 message handling 129 Move Resume Cursor (CEEMRCR) 107 naming conventions 127 original program model (OPM) and ILE 96
application programming interface (API) (continued) procedure call 109 program call 129 Promote Message (QMHPRMM) 108 QCAPCMD 86 QMHCHGEM (Change Exception Message) 107 QMHPRMM (Promote Message) 108 QMHSNDPM (Send Program Message) 40, 105 Register User-Written Condition Handler (CEEHDLR) 43, 105 Retrieve Operational Descriptor Information (CEEDOD) 95 Send Program Message (QMHSNDPM) 40, 105 services 2 Signal Condition (CEESGL) condition token 110, 113 description 40 source debugger 129 storage management 130 supplementing HLL-specic run-time library 127 Test for Omitted Argument (CEETSTA) 93 time 128 Unregister User-Written Condition Handler (CEEHDLU) 43 argument passing in mixed-language applications 94 argument passing between languages 94 by reference 92 by value directly 91 by value indirectly 91 omitted arguments 93 to procedures 91 to programs 94 automatic storage 99
B
basic listing 145 benet of ILE binding 1 C environment 6 code optimization 6 coexistence with existing applications 3 common run-time services 2 future foundation 6 language interaction control 4 modularity 1 resource control 3 reusable components 2 source debugger 3 Bibliography 179 bind by copy 19, 53 by reference 19, 54 bindable API services 2 bindable API (application programming interface) Abnormal End (CEE4ABN) 109 activation group 127 CEE4ABN (Abnormal End) 109
184
bindable API (application programming interface) (continued) CEEDOD (Retrieve Operational Descriptor Information) 109 CEEHDLR (Register User-Written Condition Handler) 43, 105 CEEHDLU (Unregister User-Written Condition Handler) 43 CEEMGET (Get Message) 113 CEEMOUT (Dispatch Message) 113 CEEMRCR (Move Resume Cursor) 107 CEEMSG (Get, Format and Dispatch Message) 113 CEENCOD (Construct Condition Token) 110 CEESGI (Get String Information) 95 CEESGL (Signal Condition) condition token 110, 113 description 40 CEETSTA (Test for Omitted Argument) 93 condition management 128, 129 Construct Condition Token (CEENCOD) 110 control ow 127 date 128 debugger 129 Dispatch Message (CEEMOUT) 113 dynamic screen manager (DSM) 130 error handling 129 exception management 128, 129 Get, Format and Dispatch Message (CEEMSG) 113 Get Message (CEEMGET) 113 Get String Information (CEESGI) 95 HLL independence 127 list of 127, 130 math 128 message handling 129 Move Resume Cursor (CEEMRCR) 107 naming conventions 127 original program model (OPM) and ILE 96 procedure call 129 program call 129 Register User-Written Condition Handler (CEEHDLR) 43, 105 Retrieve Operational Descriptor Information (CEEDOD) 95 Signal Condition (CEESGL) condition token 110, 113 description 40 source debugger 129 storage management 130 supplementing HLL-specic run-time library 127 Test for Omitted Argument (CEETSTA) 93 time 128 Unregister User-Written Condition Handler (CEEHDLU) 43 binder 19 binder information listing service program example 151 binder language denition 64 ENDPGMEXP (End Program Export) 64 ENDPGMEXP (End Program Export) command 66 error 152
binder language (continued) examples 64, 76 EXPORT 67 EXPORT (Export Symbol) 64 STRPGMEXP (Start Program Export) 64 LVLCHK parameter 66 PGMLVL parameter 66 SIGNATURE parameter 66 STRPGMEXP (Start Program Export) command 66 binder listing basic 145 extended 147 full 149 service program example 151 binding benet of ILE 1 large number of modules 54 original program model (OPM) 8 binding directory CL (control language) commands 172 denition 18 binding statistics service program example 152 BNDDIR parameter on UPDPGM command 79 BNDDIR parameter on UPDSRVPGM command 79 BNDSRVPGM parameter on UPDPGM command 79 BNDSRVPGM parameter on UPDSRVPGM command 79 by reference, passing arguments 92 by value directly, passing arguments 91 by value indirectly, passing arguments 91
C
C environment 6 C signal ILE C/400 40 call procedure 21, 89 procedure pointer 89 program 21, 89 call-level scoping 46 call message queue 39 call stack activation group example 28 denition 89 example dynamic program calls 89 static procedure calls 89 callable service 127 Case component of condition token 111 CEE4DAS (Dene Heap Allocation Strategy) bindable API 103 CEE9901 (generic failure) exception message 42 CEE9901 function check 40 CEECRHP (Create Heap) bindable API 101, 103 CEECRHP bindable API 102 CEECZST (Reallocate Storage) bindable API 103 CEEDOD (Retrieve Operational Descriptor Information) bindable API 95 CEEDSHP (Discard Heap) bindable API 100, 103 CEEFRST (Free Storage) bindable API 103
Index
185
CEEGTST (Get Heap Storage) bindable API 103 CEEHDLR (Register User-Written Condition Handler) bindable API 43 CEEHDLU (Unregister User-Written Condition Handler) bindable API 43 CEEMKHP (Mark Heap) bindable API 100, 103 CEERLHP (Release Heap) bindable API 101, 103 CEESGI (Get String Information) bindable API 95 CEESGL (Signal Condition) bindable API condition token 110, 113 description 40 Change Exception Message (QMHCHGEM) API 107 Change Module (CHGMOD) command 116, 117 CHGMOD (Change Module) command 116, 117 CL (control language) command CHGMOD (Change Module) 117 RCLACTGRP (Reclaim Activation Group) 86 RCLRSC (Reclaim Resources) for ILE programs 86 for OPM programs 86 code optimization errors 169 levels 116 performance compared to original program model (OPM) 6 levels 25 module observability 116 coexistence with existing applications 3 command, CL CALL (dynamic program call) 93 CHGMOD (Change Module) 116 CRTPGM (Create Program) 51 CRTSRVPGM (Create Service Program) 51 ENDCMTCTL (End Commitment Control) 122 OPNDBF (Open Data Base File) 121 OPNQRYF (Open Query File) 121 RCLACTGRP (Reclaim Activation Group) 33 RCLRSC (Reclaim Resources) 84 STRCMTCTL (Start Commitment Control) 121, 122 STRDBG (Start Debug) 115 Update Program (UPDPGM) 77 Update Service Program (UPDSRVPGM) 77 command, CL (control language) CHGMOD (Change Module) 117 RCLACTGRP (Reclaim Activation Group) 86 RCLRSC (Reclaim Resources) for ILE programs 86 for OPM programs 86 commitment control activation group 123 commit operation 122 commitment denition 122, 123 ending 124 example 4 rollback operation 122 scope 122, 123 transaction 122 commitment denition 121, 122, 123 Common Programming Interface (CPI) Communication, data management 122 Compare-and-Swap 143
component reusable benet of ILE 2 condition denition 45 management 105 bindable APIs (application programming interfaces) 128, 129 relationship to OS/400 message 112 Condition ID component of condition token 110 condition token 110 Case component 111 Condition ID component 110 Control component 111 denition 45, 110 Facility ID component 111 feedback code on call to bindable API 112 Message Number component 111 Message Severity component 111 Msg_No component 111 MsgSev component 111 relationship to OS/400 message 112 Severity component 111 testing 111 Construct Condition Token (CEENCOD) bindable API 110 control boundary activation group example 36 default activation group example 37 denition 36 function check at 108 unhandled exception at 108 use 38 Control component of condition token 111 control ow bindable APIs (application programming interfaces) 127 CPF9999 (function check) exception message 41 CPF9999 function check 40 Create Heap (CEECRHP) bindable API 101, 103 Create Program (CRTPGM) command ACTGRP (activation group) parameter activation group creation 31 program activation 28, 31 ALWLIBUPD (Allow Library Update) 78 ALWUPD (Allow Update) parameter 77, 78 BNDDIR parameter 53 compared to CRTSRVPGM (Create Service Program) command 51 DETAIL parameter *BASIC value 145 *EXTENDED value 147 *FULL value 149 ENTMOD (entry module) parameter 60 MODULE parameter 53 output listing 145 program creation 13 service program activation 35
186
Create Service Program (CRTSRVPGM) command ACTGRP (activation group) parameter *CALLER value 86 program activation 28, 31 ALWLIBUPD (Allow Library Update) parameter ALWUPD (Allow Update) parameter 78 BNDDIR parameter 53 compared to CRTPGM (Create Program) command 51 DETAIL parameter *BASIC value 145 *EXTENDED value 147 *FULL value 149 EXPORT parameter 61, 62 MODULE parameter 53 output listing 145 service program activation 35 SRCFILE (source le) parameter 62 SRCMBR (source member) parameter 62 creation of debug data 117 module 80 program 51, 80 program activation 28 service program 80 cross-reference listing service program example CRTPGM BNDSRVPGM parameter 54 CRTPGM (Create Program) command compared to CRTSRVPGM (Create Service Program) command 51 DETAIL parameter *BASIC value 145 *EXTENDED value 147 *FULL value 149 ENTMOD (entry module) parameter 60 output listing 145 program creation 13 CRTSRVPGM BNDSRVPGM parameter 54 CRTSRVPGM (Create Service Program) command ACTGRP (activation group) parameter *CALLER value 86 compared to CRTPGM (Create Program) command 51 DETAIL parameter *BASIC value 145 *EXTENDED value 147 *FULL value 149 EXPORT parameter 61, 62 output listing 145 SRCFILE (source le) parameter 62 SRCMBR (source member) parameter 62 cursor handle 105 resume 105 152
D
78 data compatibility 94 data links 122 data management scoping activation group level 47 activation-group level 123 call level 46, 84 commitment denition 121 Common Programming Interface (CPI) Communication 122 hierarchical le system 122 job-level 48, 123 local SQL (Structured Query Language) cursor 121 open data link 122 open le management 122 open le operation 121 override 121 remote SQL (Structured Query Language) connection 121 resource 121 rules 46 SQL (Structured Query Language) cursors 121 user interface manager (UIM) 122 data sharing original program model (OPM) 8 date bindable APIs (application programming interfaces) 128 debug data creation 117 denition 12 removal 117 debug environment ILE 115 OPM 115 debug mode addition of programs 115 denition 115 debug support ILE 118 OPM 118 debugger bindable APIs (application programming interfaces) 129 CL (control language) commands 173 considerations 115 description 26 debugging across jobs 118 bindable APIs (application programming interfaces) 129 CCSID 290 118 CCSID 65535 and device CHRID 290 118 CL (control language) commands 173 error handling 118 ILE program 14 module view 117 national language support restriction 118 observability 116 optimization 116
Index
187
debugging (continued) unmonitored exception 118 default activation group control boundary example 37 original program model (OPM) and ILE programs 31 default exception handling compared to original program model (OPM) 41 default heap 100 Dene Heap Allocation Strategy (CEE4DAS) bindable API 103 deletion activation group 32 direct monitor exception handler type 43, 105 Discard Heap (CEEDSHP) bindable API 100, 103 Dispatch Message (CEEMOUT) bindable API 113 DSM (dynamic screen manager) bindable APIs (application programming interfaces) 130 dynamic binding original program model (OPM) 8 dynamic program call activation 93 CALL CL (control language) command 93 call stack 89 denition 21 examples 21 Extended Program Model (EPM) 93 original program model (OPM) 7, 93 program activation 28 service program activation 34 dynamic screen manager (DSM) bindable APIs (application programming interfaces) 130 dynamic storage 99
E
Enabling program collecting proling data 132 End Commitment Control (ENDCMTCTL) command 122 End Program Export (ENDPGMEXP), binder language 64 End Program Export (ENDPGMEXP) command 66 ENDCMTCTL (End Commitment Control) command 122 ENTMOD (entry module) parameter 60 entry point compared to ILE program entry procedure (PEP) 12 Extended Program Model (EPM) 8 original program model (OPM) 7 error binder language 152 during optimization 169 error handling architecture 24, 39 bindable APIs (application programming interfaces) 128, 129 debug mode 118 default action 41, 108
error handling (continued) language specic 24 nested exception 109 priority example 43 recovery 41 resume point 41 error message MCH3203 53 MCH4439 53 escape (*ESCAPE) exception message type 40 exception handler priority example 43 types 43 exception handling architecture 24, 39 bindable APIs (application programming interfaces) 128, 129 debug mode 118 default action 41, 108 language specic 40 nested exception 109 priority example 43 recovery 41 resume point 41 exception management 105 exception message C signal 40 CEE9901 (generic failure) 42 CPF9999 (function check) 41 debug mode 118 function check (CPF9999) 41 generic failure (CEE9901) 42 handling 40 ILE C/400 raise() function 40 OS/400 40 percolation 41 relationship of ILE conditions to 112 sending 40 types 40 unmonitored 118 exception message architecture error handling 39 export denition 12 order 55 strong 63, 151 weak 63, 151 EXPORT (Export Symbol) 67 EXPORT parameter service program signature 61 used with SRCFILE (source le) and SRCMBR (source member) parameters 62 export symbol wildcard character 67 Export Symbol (EXPORT), binder language 64 exports strong 60, 63 weak 60, 63 extended listing 147 Extended Program Model (EPM) 8 external message queue 39
188
F
Facility ID component of condition token 111 feedback code option call to bindable API 112 le system, data management 122 Free Storage (CEEFRST) bindable API 103 full listing 149 function check (CPF9999) exception message 41 control boundary 108 exception message type 40
J
job multiple applications running in same job-level scoping 48 job message queue 39 83
L
language procedure-based characteristics 9 language interaction consistent error handling 42 control 4 data compatibility 94 language specic error handling 40 exception handler 43, 105 exception handling 40 level check parameter on STRPGMEXP command level number 84 listing, binder basic 145 extended 147 full 149 service program example 151
G
generic failure (CEE9901) exception message 42 Get, Format and Dispatch Message (CEEMSG) bindable API 113 Get Heap Storage (CEEGTST) bindable API 103 Get Message (CEEMGET) bindable API 113 Get String Information (CEESGI) bindable API 95
66
H
handle cursor denition 105 heap allocation strategy 101 characteristics 99 default 100 denition 99 user-created 100 heap allocation strategy 101 history of ILE 6 HLL specic error handling 40 exception handler 43, 105 exception handling 40
M
Mark Heap (CEEMKHP) bindable API 100, 103 math bindable APIs (application programming interfaces) 128 maximum width le for SRCFILE (source le) parameter 62 MCH3203 error message 53 MCH4439 error message 53 message bindable API feedback code 112 exception types 40 queue 39 relationship of ILE conditions to 112 message handling bindable APIs (application programming interfaces) 129 Message Number (Msg_No) component of condition token 111 message queue job 39 Message Severity (MsgSev) component of condition token 111 modularity benet of ILE 1 module object CL (control language) commands 171 creation tips 80 description 12 MODULE parameter on UPDPGM command 79 MODULE parameter on UPDSRVPGM command 79 module replaced by module fewer exports 80
Index
I
ILE basic concepts 11 compared to Extended Program Model (EPM) 10 original program model (OPM) 10, 11 denition 1 history 6 introduction 1 program structure 11 ILE C/400 heap support 101 ILE condition handler exception handler type 43, 105 import denition 12 procedure 14 resolved and unresolved 53 strong 63 weak 63 interlanguage data compatibility 94
189
module replaced by module (continued) fewer imports 80 more exports 80 more imports 79 module replacement 77 module view debugging 117 Move Resume Cursor (CEEMRCR) bindable API multiple applications running in same job 83
107
N
national language support restriction for debugging 118 nested exception 109 notify (*NOTIFY) exception message type 40
original program model (OPM) (continued) default exception handling 31 description 7 dynamic binding 8 dynamic program call 7, 93 entry point 7 exception handler types 43 program entry point 7 OS/400 exception message 40, 112 output listing Create Program (CRTPGM) command 145 Create Service Program (CRTSRVPGM) command 145 Update Program (UPDPGM) command 145 Update Service Program (UPDSRVPGM) command 145 override, data management 121
O
observability 116 ODP (open data path) scoping 46 omitted argument 93 Open Data Base File (OPNDBF) command 121 open data path (ODP) scoping 46 open le operations 121 Open Query File (OPNQRYF) command 121 operational descriptor 94, 96 OPM (original program model) activation group 31 binding 8 characteristics 8 compared to ILE 11, 13 data sharing 8 default exception handling 41 description 7 dynamic binding 8 dynamic program call 93 entry point 7 exception handler types 43 program entry point 7 OPNDBF (Open Data Base File) command 121 OPNQRYF (Open Query File) command 121 optimization benet of ILE 6 code levels 25 module observability 116 errors 169 levels 116 optimization technique proling program 131 optimizing translator 6, 25 ordering concerns storage access 142 original program model (OPM) activation group 31 binding 8 characteristics 8 compared to ILE 11, 13 data sharing 8
P
parameters on UPDPGM and UPDSRVPGM commands 79 passing arguments between languages 94 by reference 92 by value directly 91 by value indirectly 91 in mixed-language applications 94 omitted arguments 93 to procedures 91 to programs 94 PEP (program entry procedure) call stack example 89 denition 12 specifying with CRTPGM (Create Program) command 60 percolation exception message 41 performance optimization benet of ILE 6 errors 169 levels 25, 116 module observability 116 pitfalls shared storage 139 priority exception handler example 43 procedure denition 8, 11 passing arguments to 91 procedure-based language characteristics 9 procedure call bindable APIs (application programming interfaces) 129 compared to program call 21, 89 Extended Program Model (EPM) 93 static call stack 89 denition 22 examples 22
190
procedure pointer call 89, 91 proling program 132 proling types 131 program access 60 activation 27 CL (control language) commands 171 comparison of ILE and original program model (OPM) 13 creation examples 56, 58 process 51 tips 80 passing arguments to 94 program activation activation 28 creation 28 dynamic program call 28 program call bindable APIs (application programming interfaces) 129 call stack 89 compared to procedure call 89 denition 21 examples 21 program entry point compared to ILE program entry procedure (PEP) Extended Program Model (EPM) 8 original program model (OPM) 7 program entry procedure (PEP) call stack example 89 denition 12 specifying with CRTPGM (Create Program) command 60 program isolation in activation groups 29 program level parameter on STRPGMEXP command 66 program structure 11 program update 77 module replaced by module fewer exports 80 fewer imports 79 more exports 80 more imports 79 Promote Message (QMHPRMM) API 108
12
Reclaim Activation Group (RCLACTGRP) command 33, 86 Reclaim Resources (RCLRSC) command 84 for ILE programs 86 for OPM programs 86 recovery exception handling 41 register exception handler 43 Register User-Written Condition Handler (CEEHDLR) bindable API 43, 105 Release Heap (CEERLHP) bindable API 101, 103 removal of debug data 117 resolved import 53 resolving symbol description 53 examples 56, 58 resource, data management 121 resource control 3 resource isolation in activation groups 29 restriction debugging national language support 118 resume cursor denition 105 exception recovery 41 resume point exception handling 41 Retrieve Binder Source (RTVBNDSRC) command 61 Retrieve Operational Descriptor Information (CEEDOD) bindable API 95 reuse activation group 32 components 2 rollback operation commitment control 122 RPLLIB parameter on UPDPGM command 79 RPLLIB parameter on UPDSRVPGM command 79 run-time services 2
S
scope commitment control 123 scoping, data management activation group level 47 activation-group level 123 call level 46, 84 commitment denition 121 Common Programming Interface (CPI) Communication 122 hierarchical le system 122 job level 48 job-level 123 local SQL (Structured Query Language) cursor open data link 122 open le management 122 open le operation 121 override 121 remote SQL (Structured Query Language) connection 121 resource 121 rules 46
Index
Q
QCAPCMD API 86 QMHSNDPM (Send Program Message) API 40 QUSEADPAUT (use adopted authority) system value description 52 risk of changing 52
121
R
race conditions 142 RCLACTGRP (Reclaim Activation Group) command RCLRSC (Reclaim Resources) command 84 for ILE programs 86 for OPM programs 86 Reallocate Storage (CEECZST) bindable API 103 86
191
scoping, data management (continued) SQL (Structured Query Language) cursors 47 user interface manager (UIM) 122 Send Program Message (QMHSNDPM) API 40, 105 sending exception message 40 service program activation 34, 90 binder listing example 151 CL (control language) commands 172 creation tips 80 denition 16 description 10 signature 61, 65 static procedure call 90 Severity component of condition token 111 shared open data path (ODP) example 3 shared storage 139 pitfalls 139 shared storage access ordering 140 shared storage synchronization 139 Signal Condition (CEESGL) bindable API condition token 110, 113 description 40 signature 65 EXPORT parameter 61 signature parameter on STRPGMEXP command 66 single-heap support 101 source debugger 3 bindable APIs (application programming interfaces) 129 CL (control language) commands 173 considerations 115 description 26 SQL (Structured Query Language) CL (control language) commands 172 connections, data management 121 SRCFILE (source le) parameter 62 le maximum width 62 SRCMBR (source member) parameter 62 SRVPGMLIB on UPDSRVPGM command 79 stack, call 89 Start Commitment Control (STRCMTCTL) command 121, 122 Start Debug (STRDBG) command 115 Start Program Export (STRPGMEXP), binder language 64 Start Program Export (STRPGMEXP) command 66 static procedure call call stack 89 denition 22 examples 22, 91 service program 90 service program activation 35 static storage 99 static variable 27, 83 status (*STATUS) exception message type 40 storage shared 139
storage access ordering concerns 142 storage access ordering concerns 142 storage management 99 automatic storage 99 bindable APIs (application programming interfaces) 130 dynamic storage 99 heap 99 static storage 84, 99 storage synchronization, shared 139 storage synchronizing actions 141 storage synchronizing actions 141 STRCMTCTL (Start Commitment Control) command 121, 122 STRDBG (Start Debug) command 115 strong export 63, 151 strong exports 60 structure of ILE program 11 Structured Query Language (SQL) CL (control language) commands 172 connections, data management 121 support for original program model (OPM) and ILE APIs 96 symbol name wildcard character 67 symbol resolution denition 53 examples 56, 58 system-named activation group 31, 33 system value QUSEADPAUT (use adopted authority) description 52 risk of changing 52 use adopted authority (QUSEADPAUT) description 52 risk of changing 52
T
teraspace 102 bindable APIs 103 characteristics 102 compiler options 103 Test for Omitted Argument (CEETSTA) bindable API 93 testing condition token 111 time bindable APIs (application programming interfaces) 128 tip module, program and service program creation transaction commitment control 122 translator code optimization 6, 25
80
192
U
UEP (user entry procedure) call stack example denition 12 unhandled exception default action 41 118 unmonitored exception 89
Unregister User-Written Condition Handler (CEEHDLU) bindable API 43 unresolved import 53 77 77 Update Program (UPDPGM) command UPDPGM command BNDDIR parameter 79 BNDSRVPGM parameter MODULE parameter 79 RPLLIB parameter 79 UPDSRVPGM command BNDDIR parameter 79 BNDSRVPGM parameter MODULE parameter 79 RPLLIB parameter 79 description 52 risk of changing 79 79
Update Service Program (UPDSRVPGM) command
use adopted authority (QUSEADPAUT) system value 52 89 122
user entry procedure (UEP) call stack example denition 12
user interface manager (UIM), data management user-named activation group deletion 33 description 30, 83
V
variable static 27, 83
W
watch support weak export weak exports 118 151 60, 63 67
wildcard character for export symbol
Index
193
194
Readers Comments Wed Like to Hear from You
AS/400e ILE Concepts Version 4 Publication No. SC41-5606-03 Overall, how satised are you with the information in this book? Very Satised h Satised h Neutral h Dissatised h Very Dissatised h
Overall satisfaction
How satised are you that the information in this book is: Very Satised h h h h h h Satised h h h h h h Neutral h h h h h h Dissatised h h h h h h Very Dissatised h h h h h h
Accurate Complete Easy to nd Easy to understand Well organized Applicable to your tasks
Please tell us how we can improve this book:
Thank you for your responses. May we contact you?
h Yes
h No
When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in any way it believes appropriate without incurring any obligation to you.
Name Company or Organization Phone No.
Address
___________________________________________________________________________________________________
Readers Comments Wed Like to Hear from You

SC41-5606-03
Cut or Fold Along Line
Please _ _ _ _ staple Fold and _ _ _ _ _ _ _ _ _ _Fold and_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ do not_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Tape _ _ _ _ _ _ _ _ Tape NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES
BUSINESS REPLY MAIL

FIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK POSTAGE WILL BE PAID BY ADDRESSEE
IBM CORPORATION ATTN DEPT 542 IDCLERK 3605 HWY 52 N ROCHESTER MN 55901-7829
________________________________________________________________________________________ Fold and Tape Please do not staple Fold and Tape
SC41-5606-03
Cut or Fold Along Line
Printed in the United States of America on recycled paper containing 10% recovered post-consumer ber.
SC41-5606-03
Spine information:
AS/400e
Version 4

ILE Concepts

Uploaded by

Copyright:

Available Formats

ILE Concepts

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ILE Concepts

Uploaded by

Copyright:

Available Formats

AS/400e

AS/400 ILE Concepts V4R4

AS/400 ILE Concepts V4R4

AS/400 ILE Concepts V4R4

About ILE Concepts (SC41-5606)

Who should read this book

AS/400 Operations Navigator

Copyright IBM Corp. 1997, 1999

Figure 1. AS/400 Operations Navigator Display

Installing Operations Navigator

Prerequisite and related information

AS/400 ILE Concepts V4R4

How to send your comments

About ILE Concepts (SC41-5606)

AS/400 ILE Concepts V4R4

Chapter 1. Integrated Language Environment Introduction

What Are the Benets of ILE?

Common Run-Time Services

AS/400 ILE Concepts V4R4

Coexistence with Existing Applications

Better Control over Resources

Shared Open Data PathScenario

Chapter 1. Integrated Language Environment Introduction

Better Control over Language Interactions

AS/400 ILE Concepts V4R4

Figure 2. Three ILE COBOL/400 Programs in a Run Unit

Chapter 1. Integrated Language Environment Introduction

Figure 4. ILE RPG/400 Program in a Separate Activation Group

Better Code Optimization

Better Environment for C

Foundation for the Future

What Is the History of ILE?

AS/400 ILE Concepts V4R4

Original Program Model Description

Figure 5. Relationship of OPM to OS/400

Principal Characteristics of OPM

Extended Program Model Description

AS/400 ILE Concepts V4R4

OS/400 Original Program Model (OPM) Extended Program Model (EPM)

Figure 6. Relationship of OPM and EPM to OS/400

Principal Characteristics of Procedure-Based Languages

Chapter 1. Integrated Language Environment Introduction

Integrated Language Environment Description

Extended Program Model (EPM)

Integrated Language Environment (ILE) RPG

PL/I FORTRAN COBOL CL COBOL

Figure 7. Relationship of OPM, EPM, and ILE to OS/400

AS/400 ILE Concepts V4R4

Chapter 2. ILE Basic Concepts

Structure of an ILE Program

Figure 8. Structure of an ILE Program

Copyright IBM Corp. 1997, 1999

AS/400 ILE Concepts V4R4

Procedure Draw_Line; Dcl rtn_code EXTRN; CallPrc Draw_Plot;

Procedure Draw_Arc; End Draw_Arc;

Figure 9. Conceptual View of a Module

v It can have debug data dened.

Chapter 2. ILE Basic Concepts

AS/400 ILE Concepts V4R4

Figure 10. Conceptual View of an ILE Program