Why a New RPG

 Ready for future enhancements and growth

 Expand or eliminate language limits

 Fulfill RPG programmer’s requirements

­ Longer field names

­ Free form expressions
­ Date/time support

 Modernize through evolution

 Why ILE

 Improve Modularity

 Productivity

 Mixed language support

 Better runtime control (activation groups)

 Foundation for the future

 ILE
Concepts

 New set of tools and associated system support

designed to enhance program development on the
AS/400 system.
 Benefits
– Binding
– Modularity
– Reusable component
– Common run time services
– Co- existence
– Better control over resources
– Better control over language interactions
– Better code optimization
 ILE
Concepts

 Benefits (contd...)
– Better environment for ‘C’
– Foundation for the future
 ILE
Binding

 Bind different modules to form a program

 Modules can be of different languages
 ILE
Integrated Language Environment

Introduction :
 IBM AS/400 Language Compilers
– OPM (Original Program Model)
– EPM (Extended Program Model)
– ILE (Integrated Language Environment)
 ILE
OPM (Original Program Model)
 Earliest language compilers on S/38 & AS/400
generated the MI instructions in a fairly direct manner
 MI instructions were the intermediate form
 The form of the program below MI is called the OPM
 Supported design for RPG & COBOL
 Offered limited support for Block Structured
Languages
 Only CALL supported by MI is called external (or
dynamic) call
 Supports only one language source per program
 ILE
OPM

RPG Source statements

RPG/400 Compiler

Intermediate rep. of pgm

Program resolution monitor

Program template

MI Instructions
MI Boundary

Translator Program object

OPM (IMPI instructions)
 ILE
EPM (Extended Program Model)

 Extensions added to implement C/400 & PASCAL

 Did not replace OPM, but above OPM
 Support for Block Structure Languages
– Block Structured Language are designed to enable
modular style of programming
– Series of small program blocks are linked together by
CALL instructions
 EPM build without any changes to MI to support lot of
CALLs
 Performance penalty when user started or called EPM
programs
 ILE
EPM

C/400 Source statements

Compiler
UCODE

UCODE Optimizer
UCODE

IRP Code generator

Intermediate rep. of pgm

C/400 COMPILER
 ILE
ILE (Integrated Language Environment)

 Introduced in 1993 for V2R3

 An architectural enhancement to the MI & objects below
MI
 Output of ILE translator is non-executable (Modules)
 ILE binder packages these modules into executable
program
 New type of CALL was introduced called STATIC CALLS
 ILE
CALL Types
 Dynamic CALL
– All references are resolved at execution time by name
– This approach is called LATE BINDING
– Flexible
– Low performance
– Slow
 Static CALL
– All references are resolved at compilation time
– This approach is called EARLY BINDING
– Non-Flexible
– High performance
– Faster
 ILE
Jargons
 Procedure
– Sequence of source statements which can be called at
any entry point with optional parameters
 Module
– Object that contains code produced by output of ILE
Compiler
– Non-Executable
– Can contain one or more procedures
– Can be from different languages (RPG/ CL/C /COBOL)
– To produce programs & service programs
 ILE
Jargons
 Program
– Executable code made up of one or more modules
– Can be made up of modules of different languages
– Has a single entry point
– Called by Dynamic CALL
– One of the procedures is designated as Program Entry
Point (PEP)
– Programs can be called with a static call within the
same program
 ILE
Jargons

 Service Program
– Executable code made up of one or more modules
– Activated as a unit
– Treated as a collection of procedure (kind of subroutine
library)
– Procedure is called with a Static CALL
– Can have Multiple Entry Point, one for each procedure
– Can’t be executed with dynamic call
 ILE
Jargons

 Activation Group
– Working storage within a Job
– Allocated to run one or more programs
 Types of Static Call
– Bound by Copy
– Bound by Reference
 ILE
Types of Static CALLS
 Bound by Copy
– Multiple modules to be copied into a single program
– All procedure names are resolved to address at compile
time
– Much faster
– Memory utilization is more
– Better CALL performance
 Bound by Reference
– Uses a service program to store the modules
– Stores program symbolic links to the module in the
service program
– Only single copy of service program
– Activated when links are resolved
 ILE
Types of Static CALLS

 Bound by Reference (Contd...)

– Authority resolutions done at runtime
– An additional overhead
– During execution, performance is about the
same as that of bound by Copy
 ILE
Process Management

 What is a Process ?
– Single Unit of work
– Also called as TASKS
 Handling by OPM
– Non modular program
– Process - Implemented at the MI
– Two parts of the object
 System object
 Process object
– Has control information
– Object contains storage areas
 ILE
Process Management

Types of storage area :

 PSSA
– Program Static Storage Area
– Single copy of static storage area existed for the entire
process
 PASA
– Program Automatic storage area
– This area in the process object contained the call and
return task
– IWA - Invocation work area
 Heap Storage
– Not supported by OPM
– To be managed outside the module separated by each
language compiler
 ILE
Process Management

 Activation Group
– Replace both PSSA & PASA
– Each has its own control information
– Has different protection states, file usage &
commitment control
– Gives great deal of flexibility for jobs above MI
 ILE
Concepts

 New set of tools and associated system support

designed to enhance program development on the
AS/400 system.
 Benefits
– Binding
– Modularity
– Reusable component
– Common run time services
– Co- existence
– Better control over resources
– Better control over language interactions
– Better code optimization
 ILE
Concepts

 Benefits (contd...)
– Better environment for ‘C’
– Foundation for the future
 RPG IV and ILE

 RPG IV - a better RPG

 ILE - a better runtime environment

 Can use RPG IV WITHOUT ILE

 Scoop Of Class

 RPG IV features and functions

 Basic ILE features that enhance use of RPG IV

 Readability Enhancements
 MIXed case translated to upper case by compiler

FieldA = FIELDA = fielda

 10 character names
Full DDS name OK
Often 14 columns to allow for array indexing
AFieldName
AnArray(indx)

 Under_score allowed except as first character

 Completely blank lines allowed - can split code logically

 New Limits !

Description RPG III RPG IV

Field/array name 6 10
Data structure name 6 10
Format name 8 10
File name 8 10
Number of files 50 No limit
Character field 256 32,767
Constant 256 1,024
Named data structure 9,999 32,767
Unnamed data structure 9,999 9,999,999
Numberof decimal places 9 30
Array elements 9,999 32,767
Number of arrays 200 No limit
Number od subroutines 256 No limit
Size of program Varies No limit
 Other Changes
 Keyword orientation on specs
- Similar to DDS coding
- Used on H, F, D specs
- Enhances readability for seldom used features
- Allows for flexibility for future growth

 Comments in col. 81 - 100

 New source member type

- RPGLE
- PDM/SEU support
- SEU “windows” to column 6
 Other Changes
 More flexible format
- Keywords not column oriented

- Keyword areas can be continued

- C spec extended factor 2

 Use of : and ( ) as separators

 RPG IV Conversion Aid

 CVTRPGSRC takes RPG/400 to RPG IV format

 No re-engineering

 Source member larger by 25 %

 Manual intervention may be required

 Report and Log
Report
 Problems
 Flags where manual intervention needed
 Flags/COPY and CALLS for consideration
 Pre-analysis

Log
 Audit trail

 Project progress
 Conversion Report Example
From file………………………….: RPGOLD
Library ……………………..: RJS
From member……………………..: RPGEX

SEQNBR *…1….+….2….+….3….+….4….+….5….+….6…

Conversion Listing

0000046 C CALL ‘DUMMY’

* RNM0511 CALL operation code found

0000047 C* DEBUG
* RNM0517 DEBUG operation code not supported in RPG IV

0000048 C FREE ‘DUMMY’

* RNM0506 FREE operation code is not supported in RPG IV.

0000052 C/COPY RPGOLD,PAYTAX

* RNM0508 /COPY compiler directive found
 Converting Copy Books
 May need to move source from one spec to another (I to D)
 Copy books may be invalid “as-is”
 Can convert Copy Books separately - EXPCPY(*NO)
 Can include into source - EXPCPY(*YES)
Conversion Command
 ILE
Binding

 Bind different modules to form a program

 Modules can be of different languages
 Specifications
Main Source Section Specifications
H - Control(Header) Specification
F - File Description Specification
D - Definition Specification
I - Input Specification
C - Calculation Specification
O - Output Specification

Subprocedure Specifications
P - Procedure Specification
D - Definition Specification
C - Calculation Specification
 H -Spec Changes
RPG/400
H........1..CDYI....S..............1.F...............................Pgm-id
H 1 $M/ S F MYPGM

RPG IV
HKeywords+++++++++++++++++++++++++++++++++++++++++++++++++++++
HALTSEQ(*EXT) CURSYM('$') DATEDIT(*MDY/) DATFMT(*MDY/)
HDEBUG DECEDIT('.') DFTNAME(MyPgm) TIMFMT(*ISO)

• Free Format
• Keyword driven
 H-Spec Keywords

RPG III Position Meaning RPG IV Keyword

15 Dump Statements executed DEBUG
18 Currency symbol CURSYM
19 UDATE Format DATEDIT
20 UDATE Edit DATEDIT
21 Decimal notation DECEDIT
26 Alt. Collating Seq. Table ALTSEQ
41 Forms Alignment FORMSALIGN
43 File translation FTRANS
57 Transparency check (graphics) Not required
75-80 Prog. Or module ID DFTNAME
New Default Date data type format DATFMT
New Default Time data type format TIMFMT
 F-Specs

 File Description + File Continuation + Line Counter

 File name of 10 characters
 Record length of 5 digits
 Relaxed FD checks!
- File can be defined I/O but used as input-only
 Keyword based continuation area similar to DDS
 F-Specs
RPG III

RPG IV
 F-Spec Example

 F-Spec continuation not required

 F-Spec Keywords

Keyword{(value)} Explanation
COMMIT Commitment Control fromF-Spec continuation
DEVID(fieldname) Programdev name replaces ID fromF cont.
EXTIND(*INU1-*INU8) External indicators replaces U1-U8 col 71-72
USROPN User controlled open-relaces UC cols 71-72
FORMLEN(number) Forms length for printer file fromL spec
OFLIND(*Inxx) Overflow indicator fromF_spec pos 33-34
FORMOFL(number) Overflow line printer file fromL spec
IGNORE(fmt_nm{:fmt_nm..}) Replaces IGNORE file continuation option
INFDS(Dsname) Replaces INFDS exception DS fromF cont.
INFSR(SUBRname) File exception subroutine fromF cont.
KEYLOC(number) Key location fromPos 35-38
MAXDEV(*ONLY/*FILE) *FILE replaces NUM on F continuation
 F-Spec Keywords
Keyword{(value)} Explanation
PASS(*ONIND) User controlled indicator area fromF cont.
PLIST(Plist name) Parmlist for SPECIAL file fromF continuation
PGMNAME(program_name) Programto get control for SPECIAL file
PRTCTL(DSnm{:*COMPAT)}) Dynamic printer control fromF cont.
RECNO(fieldname) FromF continuation
RENAME(Ext.fmt:Int.fmt) FromF continuation (new format)
SAVEDS(Dsname) Replaces SAVDS fromF continuation
SAVEIND(number) Replaces INDfromF continuation
SFILE(recfmt_name:field) FromF continuation
SLN(number) FromF continuation
RAFDATA(filename) Replaces RAF file (fromE-spec)
 New F-Spec Keywords

Keyword{(va lu e )} E xp la inatio n
COMM IT{(rp g _n a me ) C on dition alco m mitmentcontro l-o ptiona
lpa
rame
ter
INC
LU DE (fm t_n am e{:fm t_ nam e
… }) O pp o siteo fIG NOR E
PREFIX(p re fix
_n a me {:nb r_ chr_
repl})Atta tch esp refixton amesofa llfie
lds
ina llre co rdsofafile
DATFM T(fo rm a t{sep e rato r}) D efa u ltD atefo rma t+separa to r(opt.)
TIM
FM T(fo rm at{se para to r}) D efa u ltTim efo rma t+separa to r(opt.)
Current RPG/400
New RPG IV
 I-Spec Changes

10 Character File and Record names

14 Character space for field names

2 Character space for field names

Data Structures and named constants on D-spec

 New D Specification

 Includes Data Structures from I-Spec, Arrays from E-Spec

 Additional facilities
- Standalone fields
- Arrays within structures
- Arrays & data structures based on pointers
 Can indent field name to show structure
 More readable and consistent
 Easier to add function
 New D-Spec for Data Definition

 Name - Name of data item (field, constant, datastructure, DS subfield)

 E - Indicates external DS
 T - Type of DS: (S - Program Status, U - Data area
 Ds - Type of field or DS indication
- DS - Data structure
- C - Constant
- S - Defines standalone field or array
- Blank - DS subfield
 From - From position
 To/L - To position or length
 I - Internal data type
 Dc - Decimal positions
 Keywords - Functions using keywords (similar to DDS)
 Keywords-cont - If pos. 7-43 blank, continued from
previous D-Spec
D-Spec : Example
 D-Spec : Data Structures

Keywo rd Descrip tio n

IN
Z(con stant) Initializetovalueofconstant
OCC UR S (nu mber) #occu ran cesinm ultipleoccu ran
ceD S
OVER LA Y (n
am e:{pos}) Red efinessub field
sinaD S
EXTNA M E (n
am e{:fmt_nam
e}) Filen am eforextern allyd escribedD S
EXTFLD (fldname) Externam fieldnam eb eingren amed
PREFIX (prefix_nam e) Prefixsu bfieldsfrom externallydefinedDS
Data Structure : Example
 Absolute vs. Length Notation

Can also be written :

 Defining Standalone Fields
 Rather than C-Spec
 Use S in Ds column
 Length only (no absolute)
 Can be an array
 Defining Named Constants
 Use C in the Ds column
 No length
 Value specified in Keywords area
 Terminates any previous DS
 D-Spec Keywords for Arrays
Keyword Description
DIM(number) Number of elements in array
ASCEND/DESCEND Order of elements in array
PERRCD(number) # elements for compile time table/array
FROMFILE/TOFILE From/To file for prerun time array/table
EXFMT External data type for compile and pre-run time array
ALT(array_name) Compile/preruntime array alternating format
CTDATA Indicates
Defining Arrays in Data Structures
 LIKE
 Rather than DEFINE Opcode (DEFN)
 LIKE - length, decimal positions and data type copied
 Adjust length via + or -
 Use with fields, subfields, arrays
Defining Date, Time and Timestamp Fields
 Define on D or I
 Can externally define in DDS or SQL

 Data types of D, T, Z
 No length required
 Format separator may be defined (default ISO format
 Literal values are D’date value’, T’time value’,
Z’timestamp value’
 Defining Date and Time Formats

 H-Spec
- Specify default internal format
- Defaults to *ISO
 D-Spec
- Overrides H-Spec
- With INZ or CONST, H-Spec rules
 C-Spec
- Factor 1 format for TEST, MOVE, MOVEL
- Moving data to/from date/time fields
Defining Date/Time/Timestamp Fields
 Date Formats

Name Description Format SepLength Example

*MDY Month/Day/Year mm/dd/yy /-*,& 8 01/15/99
*DMY Day/Month/Year dd/mm/yy /-*,& 8 15/01/99
*YMD Year/Month/Day yy/mm/dd /-*,& 8 99/01/15
*CYMDCenturyYear/Month/Day cyy/mm/dd /-*,& 9 199/01/15
*JUL Julian yy/ddd /-*,& 6 99/015
*ISO Intl. Stds. Org yyyy-mm-dd - 10 1999-01-15
*USA IBMUSAStd. mm/dd/yyyy / 10 01/15/1999
*EUR IBMEuropeanStd. dd.mm.yyyy * 10 15.01.1999
*JIS JapaneseInd. Std. yyyy-mm-dd - 10 1999-01-15
 Time Formats

NameDescription Format SepLength Example

*HMSHours:Minutes:Secondshh:mm:ss :.,& 8 13:00:00
*ISOIntl.Stds.Org. hh.mm.ss . 8 13.00.00
*USAIBMUSAStd. hh:mmAM : 8 01:00PM
*EURIBMEuropeanStd. hh.mm.ss . 8 13.00.00
*JIS JapaneseInd.Std. hh:mm:ss : 8 13:00:00
 Date & Time Formats : Example

DateFld = 04/15/99
TimeFld = 13:00:00
 C-Spec Changes

14 Factor 1, Factor 1, Result field characters

5 digits for field length
2 digits for decimal places
10 character opcode space - ‘stretched’ Opcodes
- Optional extenders

Only ONE conditioning indicator

 Renamed Opcodes
O ld N e w
B IT O F B IT O F F
C H E K R C H E C K R
C O M IT C O M M IT
D E F N D E F IN E
D E L E T D E L E T E
E X C P T E X C E P T
L O K U P L O O U P
O C U R O C C U R
R E D P E R E A D P E
R E T R N R E T U R N
S E L E C S E L E C T
S E T O F S E T O F F
U P D A T U P D A T E
U N L C K U N L O C K
W H xx W H E N xx
 C-Spec : Other Op Codes
New
ADDDUR add duration
EXTRCT extract date/time
SUBDUR subtract duration
TEST test valid date/time
EVAL evaluate expression
CALLB call a bound procedure
DOW do while
DOU do until
WHEN when true then select
IF conditional if
 C-Spec : Other Op Codes

Changed
CLEAR clear structure/variable/format
RESET reset structure/variable/format

Discontinued
DEBUG log debug information
FREE free subprogram storage
 Extended Factor 2
 Free-form Factor 2 (can be continued)
 New Opcodes (DOW, DOU, IF, WHEN, EVAL)
 New Operators
+ - * / = **
> < ( ) NOT OR AND
 Using Expressions
 Free- form used with Opcodes:
DOU, DOW, IF WHEN and EVAL
 New operators
+ - * / = **
> < ( ) NOT OR AND
 Use expanded Factor 2
 No Factor 1
 Opcode extender (H) on EVAL for numeric results
 Different types of expressions
 Using Expressions
Conditional

C DOU (Counter>maximum) OR (*IN98=‘1’)

Arithmetic
C EVAL Counter= Counter+1

String

C EVAL Phone=‘(‘+AreaCode+‘)’+Exchange+‘-’+ PhoneNo

 Why Use Expressions - RPG/400
RPG/400 Weekly Style Payroll:

 Not easily read

 Must use temporary fields
 Half adjustment
 Why Use Expressions - RPG IV
RPG IV Weekly Style Payroll:

 Easier to read, understand and maintain

 No Temporary result fields
 Half adjust final result only (better accuracy)
 Precedence Rules
1. ( )
2. Built in Functions
3. Negation (-, NOT)
4. ** Exponentiation
5. * ,/ Multiplication and division
6. +, - Addition and subtraction
7. =, > =, >, < =, <, < > Comparison
8. AND
9. OR

EVAL Result = A + B * C ** (X * Y)
 Using Parentheses
Since ( ) are highest in precedence, use them to :
- Break up complex expressions
- Ensure accurate results
Exponentiation
 Operation Code Extenders

(H) Half adjust

(N) Record read without lock
(P) Pad result field with blanks
(D) Date field identification
(T) Time field identification
(Z) Timestamp field identification

Place to right of Opcode in parenthesis

EVAL(H) is the same as EVAL (H)
C-Spec : CLEAR and RESET
 O-Spec Changes

10 Character File O format names

10 Character EXCEPT label
14 Character space for output field name

Room for indexes

3 Positions for space before/after

3 Positions for skip before/after
 What can be done?

 Define on D_spec as D(date), T(Time), Z (timestamp)

 Specify format (*MDY, *YMD, *JUL)
 Calculate durations (e.g. days between dates)
 Extract components (e.g. year from date)
 Move data (e.g. move numeric field to date)
 Compare values (e.g. Date1 > Date2)
 Test values (does Field1 contain valid MDY format?)
 Date and Time Durations
*YEARS *Y
*MONTHS *M
*DAYS *D
*HOURS *H
*MINUTES *MN
*SECONDS *S
*MSECONDS OR *MS

 Specify as subfactor in factor 2 or result field

 Used with ADDSUR or SUBDUR
 ADDDUR
 Add days, months, or years to a date field
 Add hours, minutes, seconds to a time field
 Add all of the above and microseconds to timestamp field
 SUBDUR
 Subtract duration from date, time or timestamp
 Calculate duration between:
- two dates, time or timestamps
- date and timestamp
- time and timestamp
 Extracting Date and Time
EXTRCT operation code extracts portions of fields

• Year, month, day part of date or timestamp fields

• Hours, minutes, seconds part of time or timestamp
• Microseconds part of timestamp
 Moving Data

 MOVE and MOVEL

 Like to like with format conversion

- Data to Date, Time to Time, Timestamp to Time stamp

- Date or Time to Time stamp
- Timestamp to Date or Time

 Date or Time to Character or Numeric

- Separators removed on move to numeric
 Character or numeric to Date, Time or Timestamp
- Valid separators required for character fields
Moving to/from Date and Time Fields
Using Date Constants
 Comparing Dates and Times
 Greater than means later than
 Less than means before
Testing for Valid Dates
 Advanced Functions in RPG IV

 Built-in Functions
- Trim spaces from character fields
- Refer to a substring of a field
- Return the size of a field
- Return the number of elements in an array
or multi-occurrence data structure
- Place the address of an item in a pointer variable
- Place the address of a procedure in a pointer variable
 Pointers to base storage inside or outside your program

 Sharing data items between bound modules

 % TRIM Built-in Function

%TRIM(string) %TRIML(string) %TRIMR(string)

- %TRIM strips leading and trailing blanks from character
or graphic fields
- %TRIML strips leading blanks only
- %TRIMR strips trailing blanks only
 %SUBST Built-in Function
%SUBST(string:start{length})
 %SIZE Built-in Function
%SIZE(name{:*ALL})
Returns storage size (in bytes) occupied by the named item
 %ELEM Built-in Function
%ELEM(name)
Returns number of elements in an array, table
or multi-occurrence data structure
 Using Built-ins, LIKE, OVERLAY, code
can be made to be more “self maintaining”

If CustName is externally described, what

happens when length changes?
 Modular Programming
• Developing modular code means

- Better chance for proven code reuse

- More options for workload distribution
- Faster compile times for smaller code modules
- Ability to purchase commercially available routines
• With AS/400’s dynamic program call, it sometimes means:
- Relatively slow performance
- Performance “hot spots” for frequently called routines
• Integrated Language Environment brings static binding
- Reduces call performance overhead for frequently called routines
- Enables more modular application design
 Creating RPG IV Programs

ILE programs may contain 1 or more modules

For single module programs : CRTBNDRPG

*MODULE X *PGM X
RPG CRTBNDRPG
Source Procedure Procedure
Mbr X X X
 Creating RPG IV Programs
ILE program may contain 1 or more modules
For multiple module programs: CRTRPGMOD + CRTPGM
*MODULE A

RPG CRTRPGMOD Proc. A

Src
Mbr A *PGM A
*MODULE B

RPG CRTRPGMOD Proc. B CRTPGM…

Src MOD( A B C)
Proc A Proc B Proc C

Mbr B
*MODULE C

RPG CRTRPGMOD Proc. C

Src
Mbr C
 ILE RPG/400 Module
* MODULE
Main Procedure
H
F
D
I
C
O

Program Data
 ILE RPG/400 Module with Subprocedures
* MODULE
Main Procedure
Main H
Source F
D
Section I
C
O
Global
Subprocedure 1
P
D Local
C
P

Subprocedure 2
P
D
Part C
Local
of P
Main
Program Data
Source
Section
ILE RPG/400 Module NOMAIN
* MODULE

H NOMAIN
Subprocedure 1
P
D
C
P Local

Subprocedure 2
P
D
C
P Local

Subprocedure 3
P
D
C
P
Local
 CALL Program vs. CALLB Procedure
CALL must target a *PGM object
- Invoke a dynamic bind at run time
- May be ILE or Original Program Model

CALLB must target a bound procedure

- Takes advantage of static binding prior to run time
- Procedure is code included in a *MODULE
- *Module with called procedure must have
been found during CRTPGM step

CALLB is faster than CALL

 CALL Program vs. CALLB Procedure

*PGM A
*PGM X *PGM Y
Procedure Procedure Procedure
CALL Y CALL A A B C
CALLB ‘B’ CALLB ‘C’
 Using Multiple ILE Languages
CL, COBOL and C will have ILE compilers
Modules from any ILE language can be bound to RPG IV programs
*MODULE A

RPG CRTRPGMOD Proc. A

Src
Mbr A *PGM A
*MODULE B

CBL CRTRPGMOD Proc. B CRTPGM…

Src MOD( A B C)
Proc A Proc B Proc C

Mbr B
*MODULE C

CL CRTRPGMOD Proc. C
Src
Mbr C
 Service Programs
 Problems with Bind by Copy
Multiple copies of frequently used routines

More complicated to update for maintenance

 Solution : Service Programs

Similar to a subroutine library

Single copy of frequently -used routines

Call performance similar to bind by copy

 Creating Service Programs

*MODULE X

RPG CRTRPGMOD Proc. X

Src
Mbr A *SRVPGM J
*MODULE Y

RPG CRTRPGMOD Proc. Y CRTSRVPGM J…

Src MOD( X Y C)
Proc X Proc Y Proc C

Mbr B
*MODULE C

RPG CRTRPGMOD Proc. C

Src
Mbr C
 Using Service Programs
Bind by Copy and Bind by Reference can be used in same program
Completion of bind between Program A and Service Program J
occurs at Call time of Program A

*SRVPGM J
*PGM A *PGM D
Procedure X
Procedure A Procedure B Procedure D
Procedure Y
CALL B CALL C CALL C
Procedure C

Bind
Bind
by Copy
by Reference
 Bind by Copy and Reference

 Both use faster CALLB operation code

 Bind by Copy
- Better suited for modules not likely to be reused
in other programs
- Slightly better run time performance since no startup for
*SRVPGM

 Bind by Reference
- Better suited for modules to be reused in many programs

- Convenient packaging for buying or selling routines

 Coding for Performance

Good performance coding techniques still apply, e.g.:

- Shared open data paths for commonly used files

- Leave LR off in commonly called procedures

Even more important in more modular applications

Only CALL time performance is improved with static binding

- Not opening/closing of database files

- Not storage initialization

 Prototyping

- Parameters

- Type of Call

- Written by developer of subprocedure

- /COPY by Caller of subprocedure

 Components of Subprocedure

· P-Spec
- MAIN or NOMAIN
- EXPORT
· D-Spec

- Local Scope Variables

· C-Spec

- Logic
- Return information to CALLER
 Prototyped CALL

· MUST be used to Call Subprocedures

Includes
- Type of call (bound / dynamic)

- Name of procedure

- Parameter information

- Return value
Simple Call Prototype
CALLP via EVAL
CALLP Using RETURN
 Recursive Calls
• Powerful Capability

- Each CALLP adds to stack

- New storage for all data items

- Data unique for each invocation

CRTPGM Command
CRTPGM Command….contd....
 Source View Debugger
New OS/400 debugger for ILE programs

View source on screen in debug mode

- Set breakpoints by cursor position

- Step through source statements

- Display / change values of programs
 Maintaining ILE Programs

• Make source changes

• CRTRPGMOD to recreate the module

• Either :
- Rebind with CRTPGM specifying all
modules/service programs needed
- UPDPGM to replace the affected module

• Repeat previous step for any other programs

containing the changed module
 Sharing Data in ILE Programs

 Modules bound together may share data items

- One module defines and exports data

- One or more modules bound to the “exporter” may import the data

 An alternative to other methods of sharing data

- More convenient than passing parameters

- Safer than using LDA
 IMPORT/EXPORT Keywords
 Shared data defined on the D spec with keywords
- EXPORT: Allows data to be used by another module
- IMPORT: This data is stored in the “exporter” module
 Allowed for data structures and standalone fields/arrays
 Exported data initialized ONLY when
*PGM containing module is called
- Not re-initialized after LR in the exporting module
 Multiple modules may IMPORT a specific data item
 Only one module may EXPORT a specific data item
 IMPORT/EXPORT Example
Module A

D ShardArray S 5 DIM(10) EXPORT

Module D

D ShardArray S 5 DIM(10) IMPORT

 Procedure A issues CALLB to Procedure B

 Procedure B issues CALLB to Procedure C

 Procedure C issues CALLB to Procedure D

Procedure D now “sees” and can update data in ShardArray
 Activation Groups
 ILE programs can run in default or specific
ILE Activation Group

 Activation groups isolate applications

 ILE AGs have benefits versus default:

- Protect shared resources

- Control of scoping of file overrides
- Control of scoping of commitment control
- Easy cleanup
 Activation Group Example
JOB

Default Activation Group Activation Group: ORDENTRY

PGM 1 PGM 3
PGM A
A

PGM B
Activation Group: QILE

PGMX PGMY
Programs 1,2 and 3 make up parts of the order
entry application. They have been designed to run
in the ORDENTRY activation group. They share
the open data path foe file A. Programs running in
any other Activation Group cannot get to data via
the specific ODP for file A in the ORDENTRY
Activation Group. It is “protected” by the
boundaries of the Activation Group.
Programs A and B are most likely
OPM (original program model), or
non-ILE programs because they are
running the in the default AG.
However, programs X and Y may each open
file A as separate non-shared ODP, or
programs X and Y could choose to share their
own copy of an open data path for file A in
their own Activation Group.
This protects the cursor position, open
attributes, etc, for the files specific to use for a
particular application from other programs in
the job that need access to the same file.
 One copy of
Program A
program
Program Instructions instructions

JOB JOB

Activation Group Activation Group

Program A Program A

Variable X = 10 Variable X = 20

One copy of static variables for each program activation

 ILE
OPM (Original Program Model)
 Earliest language compilers on S/38 & AS/400
generated the MI instructions in a fairly direct manner
 MI instructions were the intermediate form
 The form of the program below MI is called the OPM
 Supported design for RPG & COBOL
 Offered limited support for Block Structured
Languages
 Only CALL supported by MI is called external (or
dynamic) call
 Supports only one language source per program
 Activation Group Usage : Example
JOB

Activation Group Activation Group

RPG Order Entry RPG Accounts Payable
Application from Vendor Application from Vendor
1 2

Activation Group Activation Group

COBOL Inventory C Decision Support
Control Application Application from Vendor
from Vendor 3 4
 Activation Groups and Conversion

 Run time behaviors different depending on whether ILE

or default AG used
 Run complete application in one or other

- Do not mix
- RPG IV can compile for default AG
- CRTBNDRPG ……….DEFACTGRP(*YES)
- CRTPGM has no option to direct to default AG
 Recommendations

Complete Applications
Optimize use of ILE
Design run-time using AGs

Individual Programs
Compile for default AG
Be aware of limits
When done, look at full ILE
 ILE
OPM

RPG Source statements

RPG/400 Compiler

Intermediate rep. of pgm

Program resolution monitor

Program template

MI Instructions
MI Boundary

Translator Program object

OPM (IMPI instructions)
 ILE
EPM (Extended Program Model)

 Extensions added to implement C/400 & PASCAL

 Did not replace OPM, but above OPM
 Support for Block Structure Languages
– Block Structured Language are designed to enable
modular style of programming
– Series of small program blocks are linked together by
CALL instructions
 EPM build without any changes to MI to support lot of
CALLs
 Performance penalty when user started or called EPM
programs
 ILE
EPM

C/400 Source statements

Compiler
UCODE

UCODE Optimizer
UCODE

IRP Code generator

Intermediate rep. of pgm

C/400 COMPILER
 ILE
ILE (Integrated Language Environment)

 Introduced in 1993 for V2R3

 An architectural enhancement to the MI & objects below
MI
 Output of ILE translator is non-executable (Modules)
 ILE binder packages these modules into executable
program
 New type of CALL was introduced called STATIC CALLS
 ILE
CALL Types
 Dynamic CALL
– All references are resolved at execution time by name
– This approach is called LATE BINDING
– Flexible
– Low performance
– Slow
 Static CALL
– All references are resolved at compilation time
– This approach is called EARLY BINDING
– Non-Flexible
– High performance
– Faster
 ILE
Jargons
 Procedure
– Sequence of source statements which can be called at
any entry point with optional parameters
 Module
– Object that contains code produced by output of ILE
Compiler
– Non-Executable
– Can contain one or more procedures
– Can be from different languages (RPG/ CL/C /COBOL)
– To produce programs & service programs
 ILE
Jargons
 Program
– Executable code made up of one or more modules
– Can be made up of modules of different languages
– Has a single entry point
– Called by Dynamic CALL
– One of the procedures is designated as Program Entry
Point (PEP)
– Programs can be called with a static call within the
same program
 ILE
Jargons

 Service Program
– Executable code made up of one or more modules
– Activated as a unit
– Treated as a collection of procedure (kind of subroutine
library)
– Procedure is called with a Static CALL
– Can have Multiple Entry Point, one for each procedure
– Can’t be executed with dynamic call
 ILE
Jargons

 Activation Group
– Working storage within a Job
– Allocated to run one or more programs
 Types of Static Call
– Bound by Copy
– Bound by Reference
 ILE
Types of Static CALLS
 Bound by Copy
– Multiple modules to be copied into a single program
– All procedure names are resolved to address at compile
time
– Much faster
– Memory utilization is more
– Better CALL performance
 Bound by Reference
– Uses a service program to store the modules
– Stores program symbolic links to the module in the
service program
– Only single copy of service program
– Activated when links are resolved
 ILE
Types of Static CALLS

 Bound by Reference (Contd...)

– Authority resolutions done at runtime
– An additional overhead
– During execution, performance is about the
same as that of bound by Copy
 ILE
Process Management

 What is a Process ?
– Single Unit of work
– Also called as TASKS
 Handling by OPM
– Non modular program
– Process - Implemented at the MI
– Two parts of the object
 System object
 Process object
– Has control information
– Object contains storage areas
 ILE
Process Management

Types of storage area :

 PSSA
– Program Static Storage Area
– Single copy of static storage area existed for the entire
process
 PASA
– Program Automatic storage area
– This area in the process object contained the call and
return task
– IWA - Invocation work area
 Heap Storage
– Not supported by OPM
– To be managed outside the module separated by each
language compiler
 ILE
Process Management

 Activation Group
– Replace both PSSA & PASA
– Each has its own control information
– Has different protection states, file usage &
commitment control
– Gives great deal of flexibility for jobs above MI
 ILE
Concepts

 New set of tools and associated system support

designed to enhance program development on the
AS/400 system.
 Benefits
– Binding
– Modularity
– Reusable component
– Common run time services
– Co- existence
– Better control over resources
– Better control over language interactions
– Better code optimization
 ILE
Concepts

 Benefits (contd...)
– Better environment for ‘C’
– Foundation for the future
 ILE
Binding

 Bind different modules to form a program

 Modules can be of different languages