The As/400 Programmer's Handbook: More Toolbox Examples for Every As/400 Programmer (2) (AS/400 Programmer's Handbooks, Band 2) - Softcover

McCall, Mark

Softcover

ISBN 10: 1583470123 ISBN 13: 9781583470121

Verlag: MC Press, LLC, 2000

Inhaltsangabe

A collection of 70 prototypical techniques and coding examples that can be adapted for applications. Each example begins with a quick synopsis that is followed by the supporting source code. The examples encompass modular RPG coding techniques, built-in functions available in RPG, exit programs, application programming interfaces (APIs), database constraints, database triggers, and working with SQL. The CD-ROM contains all source code. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Über diesen Titel

Über die Autorin bzw. den Autor

Mark McCall is the vice president, manager of programming, and PC support for Murphey Favre Securities Services. He is a frequent speaker on the topic of AS/400 client/server strategy. He lives in Spokane, Washington.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

The AS/400 Programmer's Handbook, Volume II

More Toolbox Examples for Every AS/400 Programmer

By Mark McCall

Midrange Computing

Copyright © 2000 Midrange Computing
All rights reserved.

ISBN: 978-1-58347-012-1

Contents

INTRODUCTION, 
Part 1: RPG Programming Examples, 
Chapter 1: Modular Coding Techniques, 
Chapter 2: Built-In Functions, 
Chapter 3: Exit Programs, 
Chapter 4: Application Programming Interfaces, 
Part 2: Database Examples, 
Chapter 5: Database Constraints, 
Chapter 6: Database Triggers, 
Chapter 7: Using SQL, 
Appendix: Software Loading Instructions, 

CHAPTER 1

Modular Coding Techniques

In programming, much of what is done is redundant, a fact that seasoned programmers who have been in the trenches for many years are well aware of. By the time a programmer has been on the job for more than a couple of years, he or she probably does more copying and adapting of code that already exists than writing new code from scratch. It is simply more efficient to leverage work that has already been done than to start from scratch every time. This technique of reusing and reapplying work that has already been done can lead to tremendous gains in productivity.

Another major benefit of reusing software components is reliability. Modular components are easier to test more thoroughly than full applications. Once tested and verified to work correctly, a component can be reused without being fully retested.

When thinking about designing code that can be used and reused throughout an application, one must maintain a balance between achieving modularity and maintaining acceptable performance levels.

Common Modular RPG Coding Techniques

The introduction of the Integrated Language Environment (ILE) for RPG empowered the language with the tools necessary for building reusable component-based software. ILE allows you to call on services from external providers without suffering from the poor performance that plagues dynamic program calls. Prior to ILE, the ability to build component-based software relied strictly on dynamic program calls or methods of sharing source code.

This chapter presents examples based on a variety of modular or component-based design techniques. The following is a list of today's most commonly used techniques to reuse software in RPG on the AS/400:

* /Copy compiler directives

* Internal subroutines

* External subprograms

* ILE subprocedures

* ILE service programs

* * *

Example

Using the /COPY Compiler Directive

This example employs the /COPY compiler directive to copy source code from a central repository, often called a copybook, into a desired program. This technique of reusing source code is one of the oldest available to AS/400 programmers. While this technique has become outdated for many applications, copybooks remain an effective tool for storing ILE Procedure Interface definitions. The example takes a common generic programming task, determining the day of week for a given date, and deposits the code into a copybook, where it can be used by multiple programmers in multiple programs.

What the Example Does

The example consists of three source members. Members MOD002R and MOD003R contain copybook source that determines the day of week for a given date. Member MOD001R employs the copybooks using the /COPY directive. The mainline program logic in MOD001R accepts a date as an input parameter, then uses the copied source to determine the date's day of week. The resulting day is displayed for viewing. Listing 1.1 shows the mainline program MOD001R, while Listings 1.2 and 1.3 show the copybook source members.

How the Example Works

RPG provides a number of directives that perform specific functions when the program source compiles. As its name implies, the /COPY compiler directive allows you to instruct the RPG compiler to copy in source member records from a different member before compilation.

When creating source copybooks, you can isolate a generic segment of code into a source member. Because the member is usually just a snippet of code, or a specific generic function, copybook source is never compiled. It is simply a repository for common routines that are copied and included in the compilation of other source members.

Source statements copied by the /COPY directive are placed into the target member at the point the /COPY appears. Because of this, it may be necessary to divide a single function into multiple copybooks. For instance, the example code that determines the day of week for a given date consists of two parts: definition specs for the used fields and the calculation specs that do the actual work. These two portions of the code are divided into two individual source members. The code is divided because the definition specs need to be copied into the definition specs of the target source, while the calculations may be copied one or more times into various locations within the target member. It is important to remember that source copied into one member from another must still conform to the basic structure and sequencing requirements of RPG in order to compile.

The syntax of the /COPY directive can be explicit or implied. That is, you can provide a fully qualified library, source file and member name, a source file name and member name, or simply a member name. If a library is not specified, the library list of the compiling job is used. If a source file name is not specified, the system assumes the file to be QRPGLESRC. A member name must be specified.

Source members MOD002R and MOD003R are never compiled as standalone modules. When either the Create RPG Module (CRTPRGMOD) or Create Bound RPG Program (CRTBNDRPG) commands are used to compile the member MOD001R, the copybook members are integrated into the source prior to the actual compile.

The example employs two system APIs to derive the day of week. For detailed information about the use of these APIs, please refer to chapter 4.

* * *

Example

Using Internal Subroutines

This example employs an internal subroutine to share code within a single module. Subroutines are grouped segments of code, usually performing a very specific function that can be executed from multiple points in a module. As a general rule, subroutines deliver the best performance of all modular-coding techniques. The primary weakness of the subroutine is its inability to export its services across modules or procedures. The example takes a common generic programming task, determining the day of week for a given date, and deposits the code into a subroutine where it can be executed multiple times within the same module.

What the Example Does

The example presents member MOD004R that uses an internal subroutine coding technique to determine the day of week for a given date. MOD004R accepts a date as an input parameter, then uses the subroutine to determine the date's day of week. The resulting day is displayed for viewing. Listing 1.4 shows the source member MOD004R.

How the Example Works

RPG subroutines are routines that can be executed from any point within a procedure's calculation specifications. Subroutines are coded after the main body of code in the calculation's specs. They are defined using a unique subroutine name coded with the Begin Subroutine (BEGSR) op code. The end of the subroutine is identified using an End...

Details zur Ausgabe

• Verlag: MC Press, LLC
• Erscheinungsdatum: 2000
• Sprache: Englisch
• ISBN 10: 1583470123
• ISBN 13: 9781583470121
• Einband: Taschenbuch
• Anzahl der Seiten: 416
• Kontakt zum Hersteller: Nicht verfügbar
• Verantwortliche Person: Nicht verfügbar