Copyright HawkBridge Pty Ltd

AS/400 So ftware P ro ducts and Servi ces

An Independent Review of COOL:2E Release 7.0
September 2000
HawkBridge Pty Ltd
3 Highett Road
Hampton, VIC 3188
Australia
+61 3 9598 5829
http://www.HawkBridge.com
[email protected]
An Independent Review
of
COOL:2E Release 7.0
An Independent Review of COOL:2E Release 7.0
ii Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
About HawkBridge Pty Ltd
HawkBridge Pty Ltd is an Australian company which was set up in 1992 by a husband and wife team, Darryl Millington and
Rachel Palmer, both Analyst/Programmers specialising in COOL:2E (formerly Synon/2), RPG/400 and COBOL/400
development in the AS/400 field. The company is based in Melbourne where the office is run from their family home in a
separate office space allowing for support seven days a week.
The company has predominantly provided contract services for AS/400 sites, in the main for software development projects using
COOL:2E. Since 1997, the emphasis has changed from providing on site resources to servicing clients remotely. This
arrangement enables the company to offer a very flexible service ranging from full time development and support to once off
consulting work.
About the Author
Darryl Millington is a software engineer and consultant specialising in the AS/400. He has been providing COOL:2E (formerly
Synon/2), RPG/400 and COBOL/400 systems development and support for over 11 years. His extensive technical experience
includes all aspects of COOL:2E programming, data modelling and environment support. He has 13 years experience in
Information Technology in general with strong Analysis and Design skills, thorough Testing regime.
After successfully completing a CDI computing course, Darryl started his career in computing in 1987 working for Taubert
Systems in Sydney.
He has worked for many major companies using COOL:2E throughout Australia including, CSA, IBM, ANZ Bank, Armstrong
Jones, APPM, MGICA, South Pacific Tyres and AWH. He has worked in New Zealand, America and England on various
COOL:2E projects, thereby gaining a wide variety of experience and understanding of different types of environments.
Darryl has been an active member of the online COOL:2E user community since 1995. Through this involvement, he has become
well known and is regularly in touch with COOL:2E Development about new product concepts. Darryl is also involved in the
alpha and beta testing of COOL:2E.
A regular speaker at COOL:2E conferences in Europe and America, Darryl has also spoken at a number of Australian
conferences in the past.
Darryl has been providing education to COOL:2E users since the late 1980s as part of his contractual engagements. More
recently, he has been running COOL:2E development courses in Melbourne and Perth for Sterling Education and Computer
Associates.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd iii
AS/400 So ftware P ro ducts and Servi ces
Table of Contents
An Independent Review of COOL:2E Release 7.0........................................................................ i
About HawkBridge Pty Ltd............................................................................................................................................. ii
About the Author ............................................................................................................................................................ ii
Table of Contents...........................................................................................................................................................iii
Introduction .................................................................................................................................... 1
Release 7.0 Enhancements ............................................................................................................. 3
RPG IV ILE Generator.................................................................................................................................................... 4
Duplicate Parameter Contexts....................................................................................................................................... 18
Componentisation and Logic Extraction ....................................................................................................................... 21
Batch Processing Enhancements................................................................................................................................... 22
New JOB Context Fields............................................................................................................................................... 23
Enhanced Object Locking............................................................................................................................................. 28
Softcopy Manuals ......................................................................................................................................................... 29
Release 7.0 Significant Fixes ........................................................................................................ 31
Submit Job Override Option ......................................................................................................................................... 31
SELRCD Partial Key Parameters.................................................................................................................................. 31
Long Condition Values ................................................................................................................................................. 32
Backward Compatibility Test...................................................................................................... 33
Test Objective............................................................................................................................................................... 33
Test Data Models .......................................................................................................................................................... 33
Test Plan ....................................................................................................................................................................... 34
Test Results................................................................................................................................................................... 35
Conclusion.................................................................................................................................................................... 37
Future Direction............................................................................................................................ 39
E-Business Direction..................................................................................................................................................... 40
ILE Generator Direction ............................................................................................................................................... 41
New Sales Opportunity................................................................................................................................................. 41
Conclusion..................................................................................................................................... 43
Appendix A: First RPG Data Model ........................................................................................... 45
Appendix B: Second RPG Data Model ....................................................................................... 53
Appendix C: COBOL Data Model .............................................................................................. 61
An Independent Review of COOL:2E Release 7.0
iv Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Not to be excerpted, copied, or republished without the express written consent of HawkBridge Pty Ltd.
All trademarks are the property of their respective owners.
The information in this report is based on sources we believe to be reliable, but its accuracy, completeness, and
interpretation are not guaranteed. This report should not be relied on as a sole source of information or opinion on
the computing industry. HawkBridge Pty Ltd does not assume responsibility for typographical errors, and the
opinions expressed in this report are subject to change without advance notice.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 1
AS/400 So ftware P ro ducts and Servi ces
Introduction
COOL:2E (formerly Synon/2e) has been through
some very turbulent times in recent years with the
product changing hands of ownership twice in just as
many years. In 1998 Synon, a privately held
company, was bought by Sterling Software, a
publicly held company in what was referred to by
Sterling Software and Synon as a merger. The re-
badge of the product from Synon/2e, a well known
and respected product name in the AS/400
community, to COOL:2E provided little re-assurance
of Sterling Softwares commitment to the product.
Just as Sterling Software were coming to grips with
COOL:2E, demonstrating a clear and positive
direction in the development of the product, they
were bought by Computer Associates, yet another
publicly held company, earlier this year. How long
will it be before we see Computer Associates
demonstrate a clear and positive direction in
developing the product?
Publicly held companies differ from privately held
ones in the way in which they market their products
and services. Under Synon management, the
marketing documents released under the guise of
statements of direction painted the picture clearly for
users of the tool of the technical enhancements.
Whereas, under Sterling Software and Computer
Associates the statements of direction and product
roadmaps released by the respective marketing
departments offer very little, if any idea of future
technical developments in the product.
Sterling Softwares statement of direction only
mentioned the move to e-business enable all of their
products. Release 7.0 of COOL:2E is the result of
that statement of direction and the amount of
development effort applied to enable e-business is no
where near that applied to other enhancements, such
as the RPG IV ILE generator.
Computer Associates recently released its product
roadmaps and the most over used words in the
document are e-business and Jasmine
ii
. The next
release after Release 7.0 - as yet undesignated - is
now under way and one has to wonder whether e-
business and Jasmine
ii
will be the major
enhancements or not.
At a recent IBM user conference in Australia,
Malcolm Haines, from IBM marketing, announced a
change in marketing policy for the AS/400. They
where no longer going to market the technical
community as they have in the past, but shift to focus
their attention on winning the hearts and minds of the
financial community. Publicly held companies see
winning over the financial community as the way to
increase market awareness and popularity for their
products along with reassuring the shareholders of
the companies viability as a profitable investment.
Marketing documents from publicly held companies
would no longer have any meaning in the true
technical direction that product development takes
and we can only determine that direction once the
product is released and we get to use it. Independent
reviews, such as this one, become ever so more
important when the product is owned by a publicly
held company.
Release 5.0 of COOL:2E introduced model object
lists and the new work with user interface. How
many COOL:2E users still use what are considered
the traditional user interfaces to the tool? Release 7.0
has several enhancements that, unless you are aware
of them and understand how best to use them, will
remain under utilised by many COOL:2E users.
Many organisations are too busy to spend the time
and money to send experienced developers on
courses to update their knowledge on new release
An Independent Review of COOL:2E Release 7.0
2 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
enhancements. These developers are expected to
learn about the new features by reading release
highlights and fix notes, and then use trial and error
to determine how best to utilise the enhancements. In
most cases, the trial and error is at the expense of
quality application design.
We have been involved with the development of
Release 7.0 for more than 12 months and have been
using it for more than six months. Gaining
knowledge and experience in application uses of the
new features that can help shortcut your
implementation of Release 7.0.
The major enhancement for Release 7.0 is the RPG
IV ILE generator. This language has tremendous
flexibility, which adds an extra dimension to the
complexity of application development. Used in the
wrong manner, it can wreak havoc on the
performance and integrity of your applications. Not
to mention the decrease in programmer productivity
that can result from incorrect application design. Will
you be prepared for Release 7.0 when it arrives at
your site?
What will be the major enhancements for the next
release? E-business is the strategic direction for all of
the COOL products. Should Computer Associates
devote all of its time and resources to e-business? For
the businesses we have worked for, e-business
represents a small proportion of the total application.
Shouldnt the level of enhancements be in proportion
to the proportion of the total application that they
relate?
In this report, we analyse all of the new features of
COOL:2E delivered with Release 7.0 in a critical
manner from a users perspective. We look at ways in
which they can be used to add value to your
application development. We provide the level of
assurance required by most users to move to the next
release without the need to worry about backward
compatibility issues. We document the method and
approach used to conduct the backward compatibility
checks. We discuss the future direction of COOL:2E
under the current owner, Computer Associates.
Armed with this information, you will be able to
decide whether to upgrade to Release 7.0 and more
importantly whether there is a future in COOL:2E
that fits your particular development environment. As
a technical user of COOL:2E, you will be able to
decide how to utilise the new enhancements to enrich
your applications. You will be able to repeat the
backward compatibility test process in your own
development environment for a greater level of
assurance.
This document is best read in conjunction with the
COOL:2E Release Summary 7.0 provided by
Computer Associates on the COOL:2E
Documentation 7.0 GA CD-ROM.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 3
AS/400 So ftware P ro ducts and Servi ces
Release 7.0 Enhancements
The Statement of Direction
1
that preceded Release 7.0
development highlighted Sterling Softwares
commitment to web-enable all of its products and that
e-business was the focus for all of its Application
Development business. Considering how much
emphasis was placed on e-business and web
enablement there is very little offered in the way of e-
business and web enablement with Release 7.0.
The majority of development effort for Release 7.0 has
been devoted to programmer enhancements and
generator improvements. The only web enablement
enhancements, if you can call them that, come from
third party add-on products. Newlook, from Look
Software Pty Ltd
2
, provides the ability to graphically
enable AS/400 applications and Domino Connectors,
from Triangle Software Products Ltd
3
, provides easy
access to the functionality of Lotus Domino from
applications developed using COOL:2E.
For COOL:2E developers there is a new RPG IV ILE
generator, componentisation of action diagram logic for
re-use, support for duplicate parameters, physical file
processing and object locking enhancements. In
addition, several minor enhancements were made to
facilitate the major enhancements.
When Sterling Software bought Synon, there was a lot
of concern about whether they would continue to
support and develop COOL:2E. In the initial months,
after Sterling Software absorbed Synon it looked like
COOL:2E was destined for the shelf. This was fuelled
to an extend by Sterling Software mistaking COOL:2E
as the previous version of COOL:Plex (formerly
Obsydian) thinking that all COOL:2E users could and
would easily move to the newer tool, COOL:Plex.

1
Sterling Software, September 1999. Statement of Direction:
COOL:Plex and COOL:2E.
2
Look Software Pty Ltd, http://www.looksoftware.com/.
3
Triangle Software Products Ltd, http://www.domcon.com/.
Never really renaming the product, like COOL:Plex
being renamed from Obsydian, also fueled the notion
that the product had no future under Sterling Software.
It wasnt until after the Sterling Software Enterprise
Strategies conference in 1999 that things changed. It
was during this conference that it was highlighted
COOL:Plex was not the natural progressive step for
COOL:2E users and that there was a place for both
development tools. It was also at this conference that
the concept of co-existence of COOL:2E and
COOL:Plex emerged. Whereby a strategy would be
developed to enable better bi-directional interfacing
between the tools. We also heard at the conference
about how Sterling Software senior management was
surprised at the quarterly returns that COOL:2E was
making in comparison to the rest of the COOL
products.
Many users of COOL:2E remained concerned about the
future of the product. The real future of the tool under
Sterling Software management would have to be judged
by what it delivered in the next release. Release 7.0 is
the first release of COOL:2E that was completely
managed by Sterling Software during the concept and
development phase. What is delivered, as enhancements
in Release 7.0 would be a clear indication of Sterling
Softwares commitment to the future of COOL:2E.
Release 7.0 was a considerable investment in
development and was similar to previous major releases
of COOL:2E under Synon management. It
demonstrates that Sterling Software was committed to
the product and that it had a future under Sterling
Software management. However, Computer Associates
now owns the COOL products and they have only been
involved in Release 7.0 during the RC1 phase. If the
next release is anything like Release 7.0, then
COOL:2E users will have no cause for concern about
the future of the product under Computer Associates.
An Independent Review of COOL:2E Release 7.0
4 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Later in this report, we look at the future of COOL:2E
under the management of Computer Associates.
In this section, we analyse all of the new features of
COOL:2E delivered in Release 7.0 in a critical manner
from a users perspective. We look at ways in which
they can be used to add value to your application
development. As a technical user, you will be able to
decide how to utilise the new enhancements to enrich
your applications with the least amount of effort.
RPG IV ILE Generator
RPG IV ILE is the major enhancement for Release 7.0.
Some would argue that it has been a long time coming,
but there are reasons for it not appearing in an earlier
release. When RPG IV was released by IBM, it was
heralded for its developer improvements in
productivity. Nearly all of the enhancements over RPG
III were provided to make it easier to write, build and
maintain applications from source code. RPG IV did
not provide any significant advantage to write, build
and maintain applications from a COOL:2E data model
where generated source code should be irrelevant.
Another reason for not moving to RPG IV ILE sooner
was that the language had not really been adopted by
mainstream application development. There were
concerns with run-time performance and the emergence
of Java and e-business shifted everyones attention. In
recent months IBM has changed its focus on the RPG
IV language and is placing more emphasis in
developing it as the mainstream language.
In recent years, it has become apparent to COOL:2E
users that the RPG III limitations are very restrictive.
The only solution is to convert generated RPG III
source code to RPG IV, and compile using the
CRTBNDRPG command. These limitations were the
primary incentive for Sterling Software to provide the
RPG IV generator. Early discussions with Sterling
Software marketing and lab steered clear of trying to
implement an RPG IV ILE generator capable of
exploiting all of the ILE features. This was due to the
perceived complexity of the language concepts, how
they could be implemented in COOL:2E and whether or
not they could deliver any improvement in the
development process for COOL:2E users.
Writing a generator from the ground up would consume
most of the development effort for the new release. So
it was decided to only provide RPG IV generation
without support for any ILE features. Thankfully, a
method was devised by the lab to build the generator in
a shorter period so that more development time could
be spent on implementing RPG IV ILE features into the
new release.
Release 7.0 is the first step of a multi-phase
implementation of RPG IV and ILE within COOL:2E.
The first step taken in building the generator involved
re-using some of the RPG III generation programs.
These programs produce RPG III code, which is then
converted to RPG IV source code using a conversion
routine built by the lab. Over time, the reliance upon the
RPG III generator programs will be slowly removed
until there is a pure RPG IV generator.
As long as any RPG III generator programs are used by
the RPG IV generator, the data model objects cannot be
modified to take advantage of certain RPG IV
enhancements. One particular restriction is on the
length of field names. RPG IV can allow longer field
names up to 4096 characters, but the RPG III generator
programs cannot use them. This leaves us with field
names of six characters in generated RPG IV source
code. Another restriction with the RPG IV generator is
not being able to use the new RPG IV data types as
primitive data types in a COOL:2E data model, such as
basing pointers and Java classes. It is possible to work
around these and other restrictions using RPG IV
EXCUSRSRC functions, as the generator program for
RPG IV has been re-written for this particular function
type.
Program Creation Strategies
RPG IV ILE enhancements give RPG developers much
more flexibility in designing and developing
applications from source code. With the added increase
in flexibility, developers will be able to produce
applications that add an extra dimension to the
complexity of the application solution. For instance,
using activation groups requires careful consideration
before use, as it is possible to call a program running in
a different activation group. Mixing activation groups is
not an advisable strategy, as we shall see later.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 5
AS/400 So ftware P ro ducts and Servi ces
IBM offers three program creation strategies
4
for
implementing RPG IV and ILE into a development
environment. Adopting the correct strategy for your
development environment is crucial for the success of
RPG IV and ILE development.
Release 7.0 delivers the ability to support program
creation strategies one and two with some restrictions.
The only aspect of program creation strategy three
provided with Release 7.0 is the ability to define and
compile external functions as modules for use with
strategy two.
As a developer, you control which program creation
strategy is used to generate and compile RPG IV
programs and modules by changing the target HLL,
compilation type and creation command for an external
function.
The target HLL now supports a value of RP4, which is
used to specify a target HLL of RPG IV.
Compilation type is a new concept for COOL:2E
developers to understand. Up until Release 7.0, the
compilation type for an external function has always
been of type PGM or program. With the introduction of
ILE features in Release 7.0 a new compilation type has
been provided, this is MOD or module. A function,
which is specified as a module, will not produce an
independently executable object when generated and
compiled. A module is bound to a calling program
during the compilation of that calling program.

4
IBM, 1998. AS/400 Advanced Series ILE RPG for AS/400
Programmers Guide, Version 4, Edition 2. Document number SC09-
2507-01. Chapter 3, Program Creation Strategies.
Two shipped data model messages are provided to
control RPG IV program and module compilation at the
data model level, *CRTBNDRPG and *CRTRPGMOD
respectively. The compilation command may be
overridden at the function level by using the program
compilation override option. Note that any function that
has been overridden will not be affected with any
subsequent changes to the shipped creation messages.
COOL:2E developers are used to this concept, as there
are messages to compile all objects in the data model,
which can be overridden at the object level.
Strategy 1: Using Default Activation Group
The first program creation strategy delivers an OPM
compatible application using the Create Bound RPG
Program (CRTBNDRPG) command to compile a
program to run in the default activation group. This
strategy results in an RPG IV program that interacts
well with OPM programs, such as RPG III. There is no
need to understand activation groups, modules and
procedures, or resource management under ILE. Using
this strategy, you can take full advantage of the
language enhancements in RPG IV without the need to
move into ILE development.
To implement program creation strategy one, use the
following compilation command either at the data
model or function override level:
CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)
DFTACTGRP(*YES) DBGVIEW(*SOURCE)
OPTIMIZE(*BASIC) CVTOPT(*DATETIME)
Current RPG III application designs fit well into the
first strategy without modification. The only down side
of this strategy is that an RPG IV program runs less
Figure 1: Strategy 1 Using Default Activation Group
Default Activation Group
ILE
PGM
OPM
PGM
OPM
PGM
ILE
MOD
An Independent Review of COOL:2E Release 7.0
6 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
efficiently than RPG III programs. Heres a tip dont
convert existing RPG III source code into RPG IV
source code, unless there is a valid reason that involves
using an RPG IV enhancement.
Using program creation strategy one has one major
drawback; you cannot use static calls to modules of any
language from an RPG IV program. This is because
compiling with the default activation group does not
allow the use of static binding.
Strategy 2a: Using Named Activation Group
The second program creation strategy delivers an ILE
application using the CRTBNDRPG command to
compile a program to run in a named activation group.
This strategy results in an RPG IV program that can use
ILE static binding of modules and procedures along
with the ability to separate resource management into
distinct and separate sub-applications running in a
named activation group.
When using ILE static binding to other modules, a
binding directory can be used during the binding phase
of RPG IV program compilation to simplify the
process. The modules need to be created using the
CRTRPGMOD command before they can be bound to a
program using the CRTBNDRPG command.
To implement program creation strategy two using a
named activation group, use the following compilation
command either at the data model or function override
level:
CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)
DFTACTGRP(*NO) DBGVIEW(*SOURCE)
ACTGRP(MYACTGRP) OPTIMIZE(*BASIC)
CVTOPT(*DATETIME) BNDDIR(&YBNDDIR)
If you are using this program creation strategy in an
application that also has programs running in the
default activation group, then there is the possibility of
mixing ILE and OPM behavior. This adds another level
of complexity to application design with the scope of
overrides and open data paths
5
, which can be at job or
activation level. As IBM has highlighted, it is not
advisable to mix ILE and OPM behavior.
One characteristic of the CRTBNDRPG command
needs to be highlighted. During the compilation
process, the RPG IV source member is compiled into a
temporary module. This module is then bound into a
program object and then the module is deleted. The
module cannot be re-used by other programs or
modules in static calls using this approach unless it is
also compiled using the CRTRPGMOD command. This
then enables the RPG IV source to be called statically
or dynamically depending upon the needs of the
application. This technique is not the ideal solution in
an ILE application and is better served by adopting the
third strategy described below.
Special activation groups, *NEW and *CALLER, are
allowed to be used in place of a named activation
group. Specifying *NEW will cause a new activation
group to be started for the program to run in. When the
program completes, the activation group is ended and
all resources reclaimed. Specifying *CALLER will
allow the program to use the activation group of the
calling program, including the default activation group.

5
IBM, 1998. AS/400 Advanced Series ILE RPG for AS/400
Programmers Guide, Version 4, Edition 2. Document number SC09-
2507-01. Chapter 3, Program Creation Strategies. Section 1.3.4, A
Strategy to Avoid.
Figure 2: Strategy 2a Using Named Activation Group
MY Activation Group
Default Activation
Group
Default Activation
Group
ILE
PGM
OPM
PGM
ILE
MOD
OPM
PGM
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 7
AS/400 So ftware P ro ducts and Servi ces
Strategy 2b: Using Callers Activation Group
To implement program creation strategy two using the
calling programs activation group, use the following
compilation command either at the data model or
function override level:
CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)
DFTACTGRP(*NO) DBGVIEW(*SOURCE)
ACTGRP(*CALLER) OPTIMIZE(*BASIC)
CVTOPT(*DATETIME) BNDDIR(&YBNDDIR)
This is the default value for the shipped model creation
message *CRTBNDRPG.
When a program running in the default activation group
calls a program compiled with this form of strategy
two, the called program will run in the default
activation group. This approach gets around the
limitation of strategy one, that prevents static calls to
modules of any language. An ILE program running in
the default activation group may have resource
management issues. The use of the RCLRSC command
will not free static storage allocated by the ILE
program
6
.
When a program running in a named activation group
calls a program compiled with this form of strategy
two, the called program will run in the same named
activation group.
Strategy 2c: Using New Activation Group
To implement program creation strategy two using a
new activation group, use the following compilation
command either at the data model or function override
level:
CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)
DFTACTGRP(*NO) DBGVIEW(*SOURCE)
ACTGRP(*NEW) OPTIMIZE(*BASIC)
CVTOPT(*DATETIME) BNDDIR(&YBNDDIR)

6
IBM, 1998. AS/400e Series ILE Concepts, Version 4, Edition 3.
Document number SC41-5606-02. Chapter 5, Activation Group
Management. Section 5.2.2, Reclaim Resources Command for ILE
Programs.
Figure 3: Strategy 2b Using Callers Activation Group
Default Activation Group
OPM
PGM
OPM
PGM
ILE
MOD
ILE
PGM
Figure 4: Strategy 2c Using New Activation Group
*NEW Activation
Group
Default Activation
Group
Default Activation
Group
ILE
PGM
OPM
PGM
ILE
MOD
OPM
PGM
An Independent Review of COOL:2E Release 7.0
8 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
It is not advisable to implement this at the data model
level by changing the shipped creation message
*CRTBNDRPG, as it means that by default all RPG IV
programs will run in their own activation groups. There
will be noticeable performance degradation with so
many activation groups being started and ended with
every program call and return. Use this option at the
function level for specific functions that you require to
run in a unique activation group only.
Strategy 3: Using All ILE Features
The third and final program creation strategy delivers
an ILE application using the CRTRPGMOD and
CRTPGM or CRTSRVPGM commands to compile a
program or service program to run in a named
activation group. This strategy involves a two step
compilation approach. The first step being to compile
the RPG IV source code into a module using the
CRTRPGMOD command. The module is then bound
into a program object using the CRTPGM command.
This strategy is typically used to bind more than one
module into the program object. The major difference
between this strategy and strategy two is that the
module is permanent and can be used to bind to other
programs and modules. Using this strategy, you have
the greatest flexibility allowing you to utilise all of the
ILE concepts.
The only part of this program creation strategy that is
supported in Release 7.0 is the ability to generate and
compile RPG IV ILE modules. These functions can
then be used by functions using program creation
strategy two, which support static binding of modules.
This program creation strategy is not yet fully
supported by COOL:2E. The future capability of
COOL:2E supporting this program creation strategy is
dependent upon the successful uptake of the RPG IV
ILE generator by the COOL:2E users and the feedback
that is provided. It is strongly recommended that if you
wish this support in a future release of COOL:2E, then
you should provide both positive and negative feedback
back to the development lab. From this feedback, they
can then determine the future direction that the RPG IV
ILE generator will take.
Function Naming Guidelines
The program creation strategy used for a function is
something that every programmer will need to easily
identify. This will enable the correct functions to be
bound to one another without mixing OPM and ILE
behavior, or incorrectly using activation groups for an
application. All of the issues with resource management
and scope of overrides and open data paths become
problematic when mixing OPM and ILE programs, or
an inconsistent use of activation groups.
To determine the correct function to use, a programmer
will need to identify the target HLL, compilation type
and activation group of the function. None of these
characteristics of a function can be easily identified
when editing an action diagram. They can only be
determined from the Edit Function Details screen.
However, there is a loss of programmer productivity in
determining these characteristics of a function, which
leaves room for significant productivity improvements
with simple function naming guidelines.
Object names within COOL:2E should provide a
summary of those characteristics that are necessary to
use the object, which would otherwise be too difficult
to view. If the target HLL, compilation type and
activation group of a function were included in the
name of the function, then considerable time and effort
could be saved in building and maintaining
applications.
Target HLL and Compilation Type
By default the compilation type is set to PGM for all
external functions and can be switched to MOD and
back again using the new T=ILE Compilation Type
option. This is only available if the target HLL
language of the function is ILE compatible, such as
RPG IV.
Both the target HLL and compilation type are viewed
from the Edit Function Details screen. Including a
target HLL and compilation type abbreviation in the
function name as a prefix or suffix will greatly reduce
the time and effort required building RPG IV ILE
applications. As a guideline, you could use the
following target HLL and compilation type
abbreviations:
RPG for an RPG III OPM Program,
RP4 for an RPG IV ILE Program, and
R4M for an RPG IV ILE Module.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 9
AS/400 So ftware P ro ducts and Servi ces
The decision to either use the target HLL and
compilation type abbreviation as a prefix or suffix on
the function name depends on how you wish to group
functions. Using a prefix will group related types,
whereas using a suffix will group related functions.
You will have to decide which is more important for
your particular organisation.
Activation Group
The activation group of a function is determined from
the function compilation override. Including an
activation group abbreviation in the function name as
either a prefix or suffix will greatly reduce the time and
effort required building RPG IV ILE applications. As a
guideline, you could use the following activation group
abbreviations:
(*C) = Runs in the Callers Activation Group,
(*D) = Runs in the Default Activation Group,
(*N) = Runs in a New Activation Group, and
(MY) = Runs in Activation Group MY.
The decision to either use the activation group
abbreviation as a prefix or suffix on the function name
depends on how you wish to group functions. Using a
prefix will group related activation groups, whereas
using a suffix will group related functions. You will
have to decide which is more important for your
particular organisation.
Modularity for Maximum Reusability
As with most new features, there is a right way and a
wrong of using them. Rarely do you see a developer
pick-up a new feature and use it correctly first attempt.
It normally takes months or years of experience to learn
all of the intricacies through trial and error. Looking
back at some of your earlier work can sometimes make
you cringe at the thought of using the same techniques
today.
ILE is an overly complex concept to developers with
little or no knowledge of languages and development
practices outside of RPG III and COBOL procedural
programming on the IBM mid-range. Used in the
wrong manner ILE can complicate the maintenance
process considerably.
For instance, consider a developer confronted with the
RPG III suite of functions in Figure 5 and having to
provide an interface to the Work with Clients function
from an RPG IV ILE function running in a named
activation group. The developer cannot change the
target HLL, compilation type or activation group of the
current function because it is used in numerous other
functions. To further complicate the issue, the Work
with Clients function needs to run as an RPG IV ILE
program in the same activation group as the calling
function.
It is important that you dont mix OPM and ILE
programs in the same application. This is because there
are issues with resource allocation, and file override
and open data path scopes. For this reason, the
developer has decided to copy the Work with Clients
function to a new DSPFIL function. This enables the
developer to change the target HLL to RP4, set the
compilation type to PGM and make sure that the
activation group is set to *CALLER. The developer
now has the Work with Clients function defined
correctly for use by the new calling RPG IV ILE
function. The Work with Clients function will become
Figure 5: RPG III Work with Clients functions
Default Activation Group
Edt Client
:RPG
(EDTRCD)
Wrk Clients
:RPG
(DSPFIL)
Figure 6: RPG IV ILE Work with Clients functions
*CALLER Activation Group
Edt Client
:RP4(*C)
(EDTRCD)
Wrk Clients
:RP4(*C)
(DSPFIL)
An Independent Review of COOL:2E Release 7.0
10 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
an RPG IV ILE program that will run in the same
activation group as the calling function.
The developer cannot stop there, as the RPG IV version
of Work with Clients is still calling the RPG III version
of Edit Client. The developer needs to copy and change
the Edit Client function in the same manner as the
Work with Clients function was copied and changed,
resulting in the suite of functions shown in figure 6.
There is just one major problem with this solution. The
developer has just doubled the amount of effort
required to maintain the Work with Clients function.
Any change made to the RPG III functions will need to
be duplicated in the RPG IV functions. What makes it
worse is that there are twice as many screens as before,
which are the most time consuming objects for
COOL:2E developers.
The problem becomes even more of an issue when
other developers perform the same process as the first
developer to make the Work with Clients functionality
available for different ILE scenarios. Such as running in
a specific named activation group or an RPG IV ILE
module version.
However, a solution exists that enables all of the
program creation strategies to be employed without
duplicating the application logic. More importantly, it
only requires two device designs. This solution uses the
object-based concept of development to reduce
duplicate action diagram code. Figure 7 displays the
new modular Work with Clients suite of functions
resulting from the use of this approach.
In this solution, all device functions or functions
containing application logic as opposed to control flow
logic are coded as RPG IV ILE modules. This enables
them to be bound to a number of other functions at
Figure 8: EXCEXTFUN wrapper function action diagram
.--
| * Ignore initialisation errors.
| PGM.*Return code = CND.*Normal
| <<INSERT WRAPPED FUNCTION HERE>>
| > Check return code. On error, send message.
| .-CASE
| |-PGM.*Return code is *Error on call to...
| | * Error message already sent.
| |
| |-NOT PGM.*Return code is *Normal
| | Send error message Return code invalid
| | I *Return code PGM.*Return code
| -ENDCASE
| * Exit with return code for calling function to process.
| Exit program - return code PGM.*Return code
--
Figure 7: Modular Work with Clients functions
Edt Client
:R4M
(EDTRCD)
Wrk Clients
:RP4(*D)
(EXCEXTFUN)
Wrk Clients
:RP4(MY)
(EXCEXTFUN)
Wrk Clients
:RP4(*C)
(EXCEXTFUN)
Wrk Clients
:R4M
(DSPFIL)
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 11
AS/400 So ftware P ro ducts and Servi ces
compilation time to perform specific ILE behavior. In
the example, the DSPFIL and EDTRCD functions are
converted to RPG IV ILE modules.
We have added three new EXCEXTFUN functions to
act as wrapper type functions. The action diagram logic
for these functions is almost identical apart from the
function that they wrapper and the program creation
strategy employed. Figure 8 contains the action diagram
skeleton for a wrapper function. As you can see, it
contains only the logic to call and responds to the return
from the wrapped function.
With this function structure, it is possible to use any of
the ILE program creation strategies. This represents a
significant reduction in effort required to maintain the
Work with Clients function while at the same time
providing the greatest flexibility in function re-use.
Using COOL:2E function templates you further reduce
development effort by pre-defining reusable function
structures. This modular Work with type structure can
be easily converted to a function template.
The issues with the ILE program creation structure
discussed above are still possible, but good design will
help in reducing that risk.
Encapsulation of Database Functions
Modules can help reduce the impact of database
changes, although it requires significant changes in
function design and use. When a module has been
changed, you only need to re-compile the module and
then use the UPDPGM command to re-bind the new
module to any programs that use it. Isolating all
database file accesses into modules and only using
these modules to access your data reduces the impact of
a file change.
Consider the Edit Client function decomposition in
figure 9. The database update user points no longer call
the standard CRTOBJ, CHGOBJ and DLTOBJ.
Instead, they have been replaced with EXCEXTFUN
wrapper functions, which perform the same role as in
the figure 7. Again, function templates can be used to
simplify the development process for creating this
function structure.
Record Changed Since Displayed
There is an issue with this function structure, in that the
record changed since displayed processing will no
longer be generated for CHGOBJ and DLTOBJ
functions. This is because that processing is only
generated when the database update user points call
Figure 9: Edit Client function decomposition
Change Client
(CHGOBJ)
Wrk Clients
:R4M
(DSPFIL)
Chg Client
:R4M
(EXCEXTFUN)
Crt Client
:R4M
(EXCEXTFUN)
Dlt Client
:R4M
(EXCEXTFUN)
Create Client
(CRTOBJ)
Delete Client
(DLTOBJ)
An Independent Review of COOL:2E Release 7.0
12 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
their respective CRTOBJ, CHGOBJ and DLTOBJ
function types.
A solution is possible, but not with Release 7.0 as it
requires the COOL:2E development lab to change the
tool. The development lab needs to provide access to
the saved record image, change duplicate parameter
usage, and add a new user point in DLTOBJ function
types.
In EDTxxx function types a copy of the record read
from the database is saved as hidden fields on the
device. This is used to check for record changed since
displayed and is not available for use by the action
diagram. During post confirm processing the saved
image can be re-instated into DB1 context for use by
the action diagram and passed into the database update
functions along with the relevant device context fields.
Duplicate parameters will be discussed later in this
document. They are only allowed in EXCEXTFUN and
EXCINTFUN function types. If we could use them
with the database function types, then we could pass the
saved image and new image of the record as
parameters. This would then enable the current image
after it has been read from the database to be compared
to the saved image. If they dont match, then the record
has changed since it was displayed.
The final change required is to provide a new user point
in DLTOBJ function types to allow validation before
the record is deleted. This would then provide similar
functionality and behavior as the CHGOBJ function
type.
Using UPDPGM with Modules
Having implemented all database access as calls to ILE
modules, impacts from any file changes can be
restricted to those modules. When the file does change
it is only a matter of re-generating and compiling the
modules then use the UPDPGM command to re-bind
the updated modules to any programs that use them.
However, there is a change management issue that
cannot be resolved using COOL:2E. There is no easy
method of determining the programs using a specific
module from within COOL:2E. The YDSPMDLUSG
command to determine the impact of the change to the
modules does not have a scope option to treat modules
differently than programs. When you set the scope to
*GENFUN it stops at the ILE module functions
because it is an external function.
A solution is possible, but not with Release 7.0 as it
requires the COOL:2E development lab to change the
tool. The solution requires a new scope option on the
YDSPMDLUSG command similar to *GENFUN,
except that ILE modules are treated as internal
functions. When the usage is being exploded with this
new scope option and it comes across an external
function with a compilation type of MOD, it is to treat
it an internal function. The filter option will also need
to have a similar option to eliminate external functions
that have a compilation type of MOD.
Mixed Source Data Models
Up until Release 7.0, very few COOL:2E sites would
be generating both COBOL and RPG III in the same
data model. However, with the Release 7.0 we will see
a lot more sites using a mix of RPG III, COBOL and
RPG IV ILE functions. There are some issues with
mixing generated programs from the different target
HLL.
EXCUSRSRC Function Types
If you are going to start using more than one target
HLL in the same data model, then you will have to
consider how to deal with EXCUSRSRC function
types. Most COOL:2E developers would probably
create duplicate functions for each of the target HLL.
This adds a level of complexity to the data model that is
unnecessary. Reducing the number of functions in the
data model greatly improves developer productivity.
All of the target HLL generators have been adjusted to
deal with EXCUSRSRC function types in a consistent
manner. When an EXCUSRSRC function type is
encountered, they dont look at the declared target HLL
of the EXCUSRSRC function to determine which
source file to look for the source member to include in
the generated source. Instead, they know the target HLL
being generated and will look for a member, of the
same name as the EXCUSRSRC function, in the
associated target HLL source file.
This minor enhancement reduces the complexity of the
data model and removes the need for COOL:2E
developers to be aware of the target HLL being
generated.
When upgrading to Release 7.0 all RPG III
EXCUSRSRC functions can be converted by building a
model object list of them all, or subsetting the
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 13
AS/400 So ftware P ro ducts and Servi ces
*ALLOBJ list, and executing the following command
against them all:
CVTRPGSRC FROMFILE(QRPGSRC) FROMMBR(@YI)
You can use the merge with command option, /,
against the first function in the model object list and use
function F13 to repeat that option to the bottom of the
model object list. Then place the above command on
the command line and press the Enter key.
If you are using a change management tool that
manages the COOL:2E objects, then you may have
problems with EXCUSRSRC function types that use
this approach. They only manage the source code
member of the declared target HLL and ignore the
implicit target HLL source code members.
There is a solution to this problem, but it requires the
COOL:2E development lab and change management
software vendor to make changes to their software. The
COOL:2E development lab needs to enable multiple
PGM compilation types on an EXCUSRSRC function
type with different target HLL. The change
management software vendor needs to cater for
multiple PGM compilation types on EXCUSRSRC
function types.
Inter-Language Function Calls
When function parameters are passed as RCD or KEY,
the target HLL generators dont declare the same data
structure for receiving them into the program. Consider
figure 10 that shows the parameter details for an
EXCEXTFUN function, which are passed as KEY. The
first parameter has been intentionally dropped to
demonstrate how each of the target HLL generators
treats it.
Figure 10: Parameter details for passed as KEY
Op: DARRYL QPADEV0002 29/08/00 6:22:20
EDIT FUNCTION PARAMETER DETAILS Release 7.0 Test Model
Function name. . : Test PARs Passed as KEY Type : Execute external function
Received by file : Order Product Acpth: Update index
Parameter (file) : Order Product Passed as: KEY
? Field Usage Role Flag error
_ Order Number
_ Product Code I
SEL: Usage: I-Input, O-Output, B-Both, N-Neither, D-Drop.
Role: R-Restrict, M-Map, V-Vary length, P-Position. Error: E-Flag Error.
F3=Exit
Figure 11: RPG III Parameter Declaration
FMT * ..... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
0003.80 * Parameter declarations
0003.90 IP1PARM DS 12
0004.00 * KEY: Order Product Update index
0004.10 * I : Product Code
0004.20 I 7 12 P1AUCD
Figure 12: RPG IV ILE Parameter Declaration
FMT * *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+.
0005.10 * Parameter declarations
0005.20 D P1PARM DS 12
0005.30 * KEY: Order Product Update index
0005.40 * I : Product Code
0005.50 D P1AUCD 7 12
An Independent Review of COOL:2E Release 7.0
14 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Both the RPG III and RPG IV ILE generators declare a
data structure for the parameter as the size of the
combined key fields. The space for the dropped
parameter is still catered for in the data structure, but no
separate data structure sub-field is declared. The
resultant section of the generated RPG III and RPG IV
ILE source code can be seen in Figures 11 and 12.
On the other hand, the COBOL generator does not
declare the size of the data structure and the space for
the dropped fields is not included. Only those
parameters with a usage specified will be included in
the data structure. The resultant section of the generated
COBOL source code can be seen in Figure 13.
This difference in the target HLL generators makes it
difficult for developers to remain target HLL ignorant
when building applications in a mixed source data
model.
There is a work around for this feature to ensure that
parameter mismatches dont occur when calling RPG
III or RPG IV ILE programs and modules from a
COBOL program, or vice versa. When declaring
parameters for COBOL external functions which are
passed as KEY or RCD, make sure that all fields have a
usage defined. If you dont want to actually pass a
value or field for the parameter, declare it as a neither
usage. The resultant section of the generated COBOL
source code when Order Number is declared as neither
usage can be seen in Figure 14.
There is another option, and that is to never pass
parameters as KEY or RCD for COBOL external
functions. However, this produces less efficient runtime
objects because of the number of separate parameters
being passed.
COBOL, CL, and C ILE Modules
Release 7.0 does not have any support for the other ILE
capable languages. However, you can still use them
within RPG IV ILE functions in the data model with a
simple work around. The only problem is that you have
to use PDM or some other 3GL technique to enter the
source code, compile the modules and add them to the
binding directory used by the data model.
Once you have compiled the module and updated the
binding directory, declare an EXCEXTFUN function
with a target HLL of RPG IV ILE, compilation type of
MOD and source member name of your ILE module.
This function will act as the interface in the data model
to the ILE module. Other RPG IV ILE functions can
call this EXCEXTFUN function and it will actually call
the ILE module created external of the data model.
When writing the ILE module source code, make sure
to include the implicit return code parameter.
Otherwise, you will cause an exception error at run
time. This is because we are using an EXCEXTFUN
function that would normally have its source code
generated from the data model and all generated
functions have an implicit return code parameter. It
might pay to place a permanent lock on the
EXCEXTFUN function so as not to accidentally
generate and compile it. If it were to be compiled, it
would replace your original ILE module in the
generation library.
The CL ILE module support was being worked on
during Release 7.0 Alpha and RC1 phase of testing.
The data model shipped message has been defined for
compiling CL ILE modules, which is *CRTCLMOD
and CLL seems to be the three-character abbreviation
for the target HLL. We expect to see support for CL
ILE modules in the next release after Release 7.0.
Figure 13: COBOL Parameter Declaration
FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
0011.70 01 P1PARM.
0011.80 * Product Code
0011.90 03 P1AUCD PIC X(6).
Figure 14: COBOL Parameter Declaration with Neither Usage
FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
0011.70 01 P1PARM.
0011.80 * Order Number
0011.90 03 P1ATCD PIC X(6).
0012.00 * Product Code
0012.10 03 P1AUCD PIC X(6).
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 15
AS/400 So ftware P ro ducts and Servi ces
The COBOL ILE generator has been mentioned at
conferences in the US and Europe earlier this year and
may reach GA by early next year. Although, CA did
say that no promises were being made at the time. The
COBOL ILE generator does not require a complete
generator overhaul as happened with the RPG IV ILE
generator. This is because the syntax and format of
COBOL and COBOL ILE source code are not that
much different
7
.
Pure COBOL Data Models
A pure COBOL data model is one that uses naming
conventions that are only compatible with COBOL
generated source code. The naming convention is
defined in the YHLLVNM model value and
YHLLVNMRFA dataarea. Some COBOL data models
may have a COBOL naming convention, but the objects
defined in the data model may all conform to RPG and
COBOL naming conventions. This particular type of
COBOL data model is not a pure COBOL data model
as it is possible to generate RPG III and RPG IV ILE
source code from it.
The RPG IV language can support the longer names
used by pure COBOL data model. However, the
Release 7.0 RPG IV ILE generator does not fully
support them. The reason has already been discussed
and it has to do with the RPG IV ILE generator re-using
some of the RPG III generator programs. We see the
provision of a full RPG IV ILE generator as the path for
these pure COBOL data models to convert to the RPG
IV language. However, until a full RPG IV ILE
generator is provided, these users are trapped into using
COBOL only.

7
IBM, 1998. AS/400 Advanced Series ILE COBOL for AS/400
Programmers Guide, Version 4, Edition 1. Document number SC09-
2540-00. Chapter 1, Introduction. Section 1.1.2, ILE COBOL for
AS/400.
Conditional Compilation Directives
The RPG IV language allows you to conditionally
include or exclude sections of source code from the
compile
8
. With Release 7.0, you can now take
advantage of these new directives in EXCUSRSRC
functions to control the compilation of RPG IV
generated programs and modules.
The conditional directives were provided for supporting
modular ILE development. Whereby procedure
prototypes, data structures and variables would only be
defined once in a program or module. Figure 15
demonstrates how to include a section of source code in
a program on its first occurrence only. The condition
name must be unique within the compiled program or
module for this to work properly. This technique has
been widely used by C and C++ developers for many
years.
One interesting scenario for its use is to have different
subfile options and command keys available for testing
and production. To achieve this you would have to
define three EXCUSRSRC functions. The first
EXCUSRSRC function would contain the /IF
DEFINED(TEST) directive, the second /ELSE, and the
third /ENDIF. For ease of use and readability in an
action diagram, the function names should include the
compilation directive they contain. These could then be
included into an action diagram around the code that
should be conditionally compiled, as depicted in Figure
16. This example will run the report interactively
during testing and submit it in production.
Using these conditional compilation directives requires
the program to be compiled for testing and then re-
compiled for production. When compiling for testing,
you will need to add the DEFINE(TEST) parameter to
the program or module creation command. When
compiling for production, the DEFINE parameter is not
used.
The benefit for developers in using conditional
compilation in this manner is that all testing and
debugging aids can be left in the action diagram for
future use.

8
IBM, 1998. AS/400 Advanced Series - ILE RPG for AS/400
Reference, Version 4, Edition 2. Document number SC09-2508-01.
Chapter 2, Compiler Directives. Section 1.2.5, Conditional
Compilation Directives.
Figure 15: Example Conditional Directive
/IF NOT DEFINED(MYCOPYMBR)
/DEFINE MYCOPYMBR
... Source to be included once only
/ENDIF
An Independent Review of COOL:2E Release 7.0
16 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
To simplify the use of conditional compilation, the
development lab could add the conditional directives as
new built-in functions. Better still, the development lab
could change the CASE statement or implement a new
block statement similar to CASE for the conditional
directives. This would then enable you to work with the
/IF, /ELSEIF, /ELSE and /ENDIF in the same manner
you work with CASE statements.
Binding Directories
A binding directory is a list of ILE modules and service
programs that may be required to compile an ILE
program or service program. For program creation
strategies that employ the CRTBNDRPG command to
compile the ILE program, a binding directory is
essential to bind to ILE modules. Whereas using the
CRTPGM command to compile the ILE program, a
binding directory is optional as the specific ILE
modules can be explicitly specified on the command.
Release 7.0 provides the capability of defining one
binding directory, specified in the data model by using
the YBNDDIR model value. A few limitations in only
having a single binding directory per data model exist
and one minor issue will need to be rectified by the
development lab.
Having just one binding directory can produce some
problems with compilation in larger data models. The
more modules that exist in the binding directory, the
longer the binding process may take
9
. Only the binding
process time is increased. The resultant ILE program
will be the same irrespective of the size of the binding

9
IBM, 1998. AS/400e Series ILE Concepts, Version4, Edition 3.
Document number SC41-5606-02. Chapter 2, ILE Basic Concepts.
Section 2.6, Binding Directories.
directory. This is because only those ILE modules
actually used by the ILE program will be included in
the ILE program. Therefore, no run-time performance
issues will arise because of large binding directories.
The YBNDDIR data model value will only accept the
binding directory name, which must exist in the
generation library. The ILE program creation
commands allow the binding directory to be specified
with a library name. Some organisations may have
multiple data models that will share the same binding
directory or an existing ILE application that they wish
to interface to that exists in another library. The
YBNDDIR data model value will have to be changed to
accommodate a named library, *LIBL, *CURLIB,
*USRLIBL or *GENLIB to locate the binding
directory. The binding directory must already exist
when using *LIBL, *CURLIB or *USRLIBL. Release
7.0 will create the binding directory in the generation
library if it does not already exist there.
To try to reduce compilation times in larger data
models, it will be necessary to provide the ability to
specify binding directories on data model file and
function options. The data model file binding directory
option would accept all the values allowed for the data
model value as well as *MDLVAL, which means that
the data model value is to be used. The function binding
directory option would accept all the values allowed for
the data model file option as well as *FILVAL, which
means that the data model file option is to be used.
When an ILE module is generated from the data model,
a pre-compiler line is inserted to add the ILE module to
the binding directory associated with the data model as
shown in figure 17. The ILE module does not have to
exist before being added to the binding directory. The
binding directory should be resolved from the function
binding directory option, when it is made available.
Figure 16: Example use of Conditional Compilation Directives in Action Diagram
| > 2=Edit.
| .-CASE
| |-RCD.*SFLSEL is Edit
| | /IF DEFINED(TEST) Common Routines * EXCUSRSRC
| | Print Detailed Report Order Product * PRTFIL
| | /ELSE Common Routines * EXCUSRSRC
| | SBMJOB: Print Detail Report Order Product * PRTFIL
| | /ENDIF Common Routines * EXCUSRSRC
| -ENDCASE
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 17
AS/400 So ftware P ro ducts and Servi ces
When an ILE program or module is being generated,
the generator will need to construct the BNDDIR
parameter of the CRTBNDRPG command by adding
the binding directories of all the referenced functions.
The BNDDIR parameter allows an almost unlimited
number of binding directories to be used. This should
help in reducing the number of modules in binding
directories and increase the performance of binding and
compilation of ILE programs and modules.
With Release 7.0 the binding directory option allows
*NONE to be used. This is a good method of
prohibiting the use of static binding in data models.
Without a binding directory, the compiler cannot find
the definitions to bind to any called ILE modules and
the ILE program will not be created.
The minor issue with Release 7.0 that will need to be
rectified by the development lab is in the management
of binding directory entries. When an ILE module is
deleted from the data model, the binding directory entry
is not removed. This will have to change in order to try
to reduce the size of the binding directory. Having
redundant entries in the binding directory only further
complicates the issue with binding directory size.
COOL:2E should manage the binding directories
completely to reduce the complexity of developing ILE
applications.
Control (H) Specification
Two new model values have been supplied with
Release 7.0 for the RPG IV control (H) specification,
YRP4HSP for RPG IV ILE programs and YRP4HS2
for RPG IV ILE modules. These are limited to one
source line each, which can cause problems when the
keywords require more than one line.
There are several work-arounds for this issue, the first
requires an EXCUSRSRC function containing only H
specifications to be added to all external functions. Any
work-around that requires nearly every function in the
data model to be changed is unworkable.
The second work-around uses a dataarea named
RPGLEHSPEC to contain the keywords
10
. This will
only allow one set of keywords for both RPG IV ILE
programs and modules, which will cause problems
when they are required to be different. The dataarea
will only be used if no H specifications exist in the
program or module being compiled, which means
clearing the model values for the H specifications.
Using the dataarea is not a model based solution and is
something that should be avoided. Other developers
may not understand that the dataarea is being used in
this manner and will have difficulty in finding the
source of the H specifications.
These work-arounds are not cost effective enough as
they will decrease developer productivity. The
development lab will need to increase the number of
lines that can be entered for the new data model values.
Source Code Generation Options
A new data model value, YRP4SGN, has been provided
to change the case and color of the generated source.
The RPG IV language allows the use of mixed case for
symbolic names. During compilation, all lowercase
characters are translated to uppercase. Almost any good
book on programming style will highlight that using
mixed case makes source code easier to read and
understand. For instance, AddBndDirE is easier to read
than ADDBNDDIRE as the words are delimited by
uppercase letters.

10
IBM, 1998. AS/400 Advanced Series - ILE RPG for AS/400
Reference. Chapter 13, Control Specifications. Section 3.2.1, Using a
Data Area as a Control Specification.
Figure 17: Generated RPG IV ILE Module header
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+..
0000.10 H/TITLE RPG IV ILE Module Execute external functio
0000.20 Y* ADDBNDDIRE BNDDIR(YBNDDIR) OBJ((RPGIVILE *MODULE))
0000.30 *
0000.40 Z* CRTRPGMOD
0000.50 Z* DBGVIEW(*SOURCE) CVTOPT(*DATETIME)
0000.60 H* SYNOPSIS :
An Independent Review of COOL:2E Release 7.0
18 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Lots more can be done to further improve readability of
generated source code with mixed case. Release 7.0
allows all uppercase, all lowercase or first character
uppercase options. A style, known as the Hungarian
method, has been used in C and C++ development for
some time, which uses a data type prefix in lowercase
followed by first word in uppercase format, such as
pMyData. This style has been adopted by some
organisations using RPG IV ILE.
COOL:2E could generate similar names to the
Hungarian method by making the field context
lowercase and then using the field DDS name entered
in the data model. Along with this, the development lab
should allow field DDS names to be entered in mixed
case. There is a problem with this though. The other
HLL generators would then have to convert the field
name to all uppercase in order to use them.
Alternatively, we could have pure RPG IV data models
much like pure COBOL data models can exist.
The color of the generated comment lines can be
changed to green, white, red, pink or blue. The
technique of coloring source lines has been around for
many years and is nothing new for RPG IV. The sixth
character is changed to an attribute byte using the
respective hex code. When visually scanning generated
source code, this will make it easier to differentiate
between executable lines and comment lines.
Duplicate Parameter Contexts
Release 7.0 provides the capability of specifying a field
up to nine times as a function parameter for
EXCEXTFUN and EXCINTFUN function types. This
is enabled by using the duplicate parameters function
option. When enabled the PAR context is no longer
available in the function and is replaced by up to nine
new contexts for each parameter entry, PR1 to PR9.
Prior to release 7.0, you could have a single field
defined twice on a function. However, one instance
would be as input and the other as output. Release 7.0
enables the same field to be defined as input, output,
both, and/or neither up to nine times. All fields in an
action diagram must be unique within context and
duplicate parameters are no exception as all fields,
prefixed with their associated parameter entry context,
are unique.
Duplicate parameters were originally designed to
enable co-existence of COOL:2E and COOL:Plex. But,
there are significant advantages in using duplicate
parameter contexts for non-COOL:Plex co-existence
developers.
Figure 18: EXCINTFUN with Duplicate Parameters
Options:
Execution location . . . . : W ( W-Where_found, S-Server )
Generate as subroutine . . : Y ( Y-Yes, N-No )
Share subroutine . . . . . : Y ( M-MDLVAL, Y-Yes, N-No )
Duplicate parameters . . . : Y ( N-No, Y-Yes )
Parameters:
Fmt Field name Usg Role File name
RCD Order Number I MAP Order Product Retrieval index
Product Code I MAP
RCD Order Number I MAP Order Product Retrieval index
Product Code I MAP
...........................................................................
> EXCINTFUN w/Dup Parms
.--
>> . * >>>
>> . .-CASE
>> . -PR1.*ALLPARMS EQ PR2.*ALLPARMS
>> . * >>>
>> . '-ENDCASE
>> . * >>>

An Independent Review of COOL:2E Release 7.0

Copyright HawkBridge Pty Ltd 19
AS/400 So ftware P ro ducts and Servi ces
From our experiences, many USR fields are defined in
data models just so that the same field could be passed
twice into a function. Especially when fields have been
placed on more than one file and you wish to pass the
record data from two or more of these files to a
function. Database trigger programs are a prime
example of the need for duplicate parameters so that the
before and after images of the record can be passed to a
function.
This minor enhancement provided with Release 7.0 will
have significant productivity benefits in not having to
define a new field to the data model. Reducing the
number of fields defined in the data model will
decrease the complexity of the data model, which will
also provide productivity benefits.
It is unfortunate that duplicate parameter contexts are
only available on EXCEXTFUN and EXCINTFUN
function types. Our investigations during Alpha testing
revealed that it could be easily enabled for all function
types and will most probably be available in the next
release. This will help alleviate some issues with
encapsulating database functions into RPG IV ILE
modules discussed earlier.
A new pseudo-field, *ALLPARMS, for duplicate
parameter contexts on CASE and REPEAT WHILE
blocks in action diagrams allows entire parameter
formats to be compared. The pseudo-fields will only
work for EXCEXTFUN function types as it makes use
of the PnPARM data structure created for each
parameter sequence declared to the function.
EXCINTFUN function types dont generate data
structures for each parameter sequence, although the
COBOL and RPG IV generators could easily be
adapted by the development lab to generate them. The
EXCINFUN function types would have to be
implemented with the share sub-routine function option
enabled, which would produce the local parameter
declarations. Consider the EXCINTFUN function
defined in figure 18 with duplicate parameters defined.
It would produce the local parameters as in figures 19,
20 and 21 for COBOL, RPG III and RPG IV
respectively.
Figure 21: EXCINTFUN RPG IV Local Parameter Declarations
FMT D .....DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++
0009.20 D Wl0001 S 6
0009.30 D Wl0002 S 6
0009.40 D Wl0003 S 6
0009.50 D Wl0004 S 6
Figure 20: EXCINTFUN RPG III Local Parameter Declarations
FMT C .....CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEq
0052.80 * Define local variables for subroutine SAINFN.
0052.90 C MOVEL*BLANK WL0001 6
0053.00 C MOVEL*BLANK WL0002 6
0053.10 C MOVEL*BLANK WL0003 6
0053.20 C MOVEL*BLANK WL0004 6
Figure 19: EXCINTFUN COBOL Local Parameter Declarations
FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++
0019.20 01 SBRLCL-CONTEXT.
0019.30 * Define local variables for subroutine SA1INFN.
0019.40 03 WL0001 PIC X(6).
0019.50 03 WL0002 PIC X(6).
0019.60 03 WL0003 PIC X(6).
0019.70 03 WL0004 PIC X(6).
An Independent Review of COOL:2E Release 7.0
20 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
The generator would have to treat a single occurrence
of the EXCINTFUN function as if it were being used
more than once so that the local variables would be
generated. A data structure for the local variables would
then be required, much the same as parameters defined
on EXCEXTFUN function types are declared, resulting
in parameter declarations as in figures 22, 23 and 24.
PRn is not very user friendly for the duplicate
parameter contexts. You need to refer back to the Edit
Function Parameters screen to determine what the
context intended use is, known as the program context.
Although, there are some screens in the action diagram
that do show the program context and parameter
context, such as the Edit Action Condition screen, and
command key F22 will display the duplicate
parameters. It would have been more developer friendly
if you could have used the program context within the
action diagram instead of PRn.
Imagine if you could define PR1 as program context
LOC and use LOC instead of PR1 inside the function.
This would provide you with an explicitly declared
local parameter instead of using the supplied LCL
context, which is implicitly declared to the function.
The implicit nature of LCL context created a great deal
of debate when it appeared as it inherited several flaws
Figure 22: New EXCINTFUN COBOL Local Parameter Declarations
FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++
0019.20 01 SBRLCL-CONTEXT.
0019.30 * Define local variables for subroutine SA1INFN.
0019.31 03 WLSAP1
0019.40 05 WL0001 PIC X(6).
0019.50 05 WL0002 PIC X(6).
0019.31 03 WLSAP2
0019.60 05 WL0003 PIC X(6).
0019.70 05 WL0004 PIC X(6).
Figure 23: New EXCINTFUN RPG III Local Parameter Declarations
FMT DS .....IDsname....NODsExt-file++.............OccrLen+...............
0003.90 IWLSAP1 DS 12
0004.00 * RCD: Order Product Retrieval index
0004.10 * I : MAP Order Number
0004.20 I 1 6 WL0001
0004.30 * I : MAP Product Code
0004.40 I 7 12 WL0002
0004.50 IWLSAP2 DS 12
0004.60 * RCD: Order Product Retrieval index
0004.70 * I : MAP Order Number
0004.80 I 1 6 WL0003
0004.90 * I : MAP Product Code
0005.00 I 7 12 WL0004
Figure 24: New EXCINTFUN RPG IV Local Parameter Declarations
FMT D .....DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++
0009.19 D Wlsap1 DS 12
0009.20 D Wl0001 1 6
0009.30 D Wl0002 7 12
0009.31 D Wlsap2 DS 12
0009.40 D Wl0003 1 6
0009.50 D Wl0004 7 12
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 21
AS/400 So ftware P ro ducts and Servi ces
from WRK context and has the possibility of
introducing errors into your applications
11
.
There is a new file in the data model to support the
duplicate parameter contexts. The file name is
YPARCTXRFP and contains details about the mapping
of the function local parameter surrogate and program
context. It is an extension of the file YMSGPARRFP.
It should be noted that comparing duplicate parameter
contexts using *ALLPARMS may not work for
COBOL generated programs. The PnPARM data
structure only contains the fields with a declared usage.
For it to work in COBOL the same fields should be
declared with a usage in both of the duplicate parameter
entries.
Componentisation and Logic
Extraction
Componentisation and logic extraction is the process of
taking a single large function and dividing it into
smaller, more manageable functions that fit the concept
of modular design. Release 7.0 provides a new feature
that automates this whole process, known as wrapping.
It was originally designed to enable co-existence of
COOL:2E and COOL:Plex so that COOL:Plex
developers could interface with COOL:2E existing
applications via the Application Intergrator/2E product.
The intention here was to enable a COOL:Plex e-
business application to interact with an existing
COOL:2E application. The extracted logic could be
used by any other third party e-business development
tool. This is not only an e-business enablement feature
as there are significant advantages in using
componentisation and logic extraction for COOL:2E
developers.
During Alpha testing of Release 7.0, a client using an
earlier version of COOL:2E wanted a function to be
converted from an EDTRCD to an EDTFIL function
type. The original developer of the EDTRCD function
had not used modular development and the action
diagram, when printed, was dozens of pages long. The
EDTRCD function would still be used in the

11
HawkBridge, 1999. An Independent Review of COOL:2E Release
6.2. Release 6.1 Enhancements - Local Context, p3.
application, so duplication of action diagram logic had
to be reduced for improved productivity in maintaining
the functions.
The conversion process was to extract the logic from
the EDTRCD function into re-usable EXCINTFUN
functions so that it could be used in the EDTRCD and
EDTFIL functions without duplicating any action
diagram code. This proved to be a very time consuming
process, taking almost a week for one developer to
complete. The difficulty lies with trying to identify and
define the parameters for the EXCINTFUN functions
used to wrapper the action diagram code. Without
duplicate parameter contexts the process was very
tedious especially as there where possibly four different
contexts per field, DB1, KEY, DTL, and PAR context.
Had we been using Release 7.0 to perform the
conversion of the EDTRCD to an EDTFIL function
type, it would have taken minutes to perform instead of
days. On top of that the manual process is very prone to
user error and requires substantial testing to ensure it
was accurate. If one conversion can save almost a week
for one developer, then we will save months of work
per year in re-using business logic just by using this
feature alone in Release 7.0. Not to mention the time
and resources saved with the reduction of duplicate
action diagram code.
Wrapping makes use of duplicate parameter contexts in
order to replace device specific contexts not found in
EXCEXTFUN and EXCINTFUN function types. When
a field is found in the original section of action diagram
code that is to be converted to a duplicate parameter
context, a new data model array is created for the
wrapping function. An array is used to get around the
limitation of nine parameter entries per function - for
further details about using arrays for parameters see the
COOL:2E manuals
12
.
The name of the wrapping function array is set to the
name of the wrapping function and a suffix of PAR.
Where data model arrays have been used for function
parameters, it is necessary to separate them from the
normal arrays so they can be easily identified. A prefix
would have been better than a suffix as it would group
all parameter arrays together and make it easier to
search for one. However, most organisations would
prefer to make the decision themselves. For this reason,
it would have been better to have two new model

12
Sterling Software, 1999. Building Applications. Chapter 5,
Modifying Function Parameters. Using Arrays as Parameters, p5-21.
An Independent Review of COOL:2E Release 7.0
22 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
values. One model value would be used for the actual
text to be used, such as PAR by default. The other
model value would be used to determine whether to
apply the text as a prefix or suffix, which would be
suffix by default.
If a data model array already exists by the name
generated by the wrapper process, it will allocate a
unique name similar to other object names. That is it
will append the surrogate of the object being created to
the end of the object name. As the wrapper process can
only be performed interactively, it would be nice if the
developer was presented with a screen to define the
array name to use.
For those people using the wrapper process as part of a
co-existence strategy for COOL:2E and COOL:Plex,
extracting to an EXCEXTFUN function type is the
method proposed by Computer Associates. This is not
the best method for developing modular applications.
Consider extracting to an EXCINTFUN function type
so that the business logic is not embedded inside an
executable object.
Some uses of the business logic may be in other
COOL:2E functions which, for performance reasons,
may want inline source code instead of the overhead of
a dynamic or static call. After the wrapper
EXCINTFUN function has been created, copy it and
change the function type to an EXCEXTFUN function.
This will duplicate the parameter structure for you
easily. Next delete all of the action diagram code in the
EXCEXTFUN function and replace with code similar
to figure 8 and call the EXCINTFUN function. You
now have more flexibility in using the extracted
business logic, whether you are interfacing to
COOL:Plex or not.
Batch Processing Enhancements
Functions based on PHY access paths has been in
considerable demand for many years. EDI applications
make extensive use of multi-format physical files,
where the first couple of characters of each record
determine the record format to be used to un-format the
record.
Processing physical files with COOL:2E in relative
record number sequence has meant that a temporary
logical file needed to be created. This is necessary to
allow functions to process the data in the physical file
via the logical file. When creating records in EDI
physical files another logical file is required to enable
CRTOBJ functions to be defined. These extra logical
files add a level of unnecessary complexity to the
application that could be removed with physical file
processing.
Release 7.0 allows the PHY access path to be used as
the based on access path for RTVOBJ, CHGOBJ,
DLTOBJ and CRTOBJ functions.
RTVOBJ based on PHY Access Path
Using a RTVOBJ function based over a PHY access
path, allows a physical file to be processed by relative
record number. By default the field *Relative record
number will be added as a positioner to new RTVOBJ
functions that are based on a PHY access path.
The RTVOBJ function based on a PHY access path is
implemented in generated source code similar to the
way in which standard RTVOBJ function types are
implemented. However, some differences to normal
behavior should be highlighted.
The RTVOBJ function parameter *Relative record
number is treated as the key to the physical file. Much
like keys to standard RTVOBJ functions, you can use a
role of either RST or POS for input, both or neither
usage to affect the records processed by the function.
Specifying the parameter *Relative record number as
an output or both parameter causes the RTVOBJ
function to return the last read relative record number.
This is different from standard RTVOBJ functions, as
they never return values implicitly, apart from the
return code.
Deleting the parameter *Relative record number will
cause the RTVOBJ function based on the PHY access
path to read the first record only. However, if there is
action diagram code specified in the user point USER:
Process Data record it will process all records in the
file. This is exactly how standard RTVOBJ functions
behave.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 23
AS/400 So ftware P ro ducts and Servi ces
CHGOBJ based on PHY Access Path
The default action diagram for a CHGOBJ function
based on a PHY access path is the same as a standard
CHGOBJ function. For the CHGOBJ function based on
a PHY access path the generator ignores several user
points, namely those performing pre-update file
processing. This can cause confusion with developers,
as they now need to know the based on access path type
before making changes to a CHGOBJ functions.
The reason for such behavior in CHGOBJ functions
based on PHY access paths is due to the complexity in
conditioning the default action diagram. Although, it
has been done in the past for other function types such
as PRTFIL, PRTOBJ, EDTRCD, EDTFIL, EDTTRN
and any function using the post confirm option. Time
was running short for the development lab when this
was being considered and we are glad that they decided
to keep it in Release 7.0, even with its misgivings.
We would like to see this abnormal behavior removed
in a future release of COOL:2E as it further complicates
the development process and may lead to database
inconsistencies. Developers could place action diagram
code in an ignored user point thinking it will be
executed. In fact, it will not be executed which is where
the database inconsistency can arise.
A CHGOBJ function based on a PHY access path can
only be directly attached to a RTVOBJ function based
on the same PHY access path. This is enforced by the
action diagram editor, but not checked by the
generators. This can present problems where a modular
approach to development is practiced, or the new
wrapper function feature is used to extract the action
diagram logic.
It may be necessary to move the statements in the user
point USER: Process database record of a RTVOBJ
function based on a PHY access path into an
EXCINTFUN function. This will enable it to be shared
amongst other functions. If those statements contain a
call to a CHGOBJ function based on a PHY access
path, then any attempt to edit it within the
EXCINTFUN will cause an error. Although, using the
wrapper function option will re-map the DB1 context to
a duplicate parameter context and the generator will
generate the correct source code without an error being
signaled.
There is a work-around for this error, which involves
opening the CHGOBJ function, based on a PHY access
path and the associated RTVOBJ function based on the
same PHY access path. You can then use the notepad to
copy the CHGOBJ function back to the RTVOBJ
function to perform any changes required to passed
parameters. Once the changes have been entered, you
can use the notepad to copy the CHGOBJ function back
and replace the original action diagram statement.
The message in the action diagram editor should be
changed from an error message to a warning message,
much like domain mismatch warning messages. This
would enable you to build your own modular functions
that make use of CHGOBJ functions based on PHY
access paths.
DLTOBJ based on PHY Access Path
The discussion on CHGOBJ functions based on PHY
access paths equally applies to DLTOBJ functions
based on PHY access paths.
CRTOBJ based on PHY Access Path
The discussion on CHGOBJ functions based on PHY
access paths applies in most parts to CRTOBJ functions
based on PHY access paths. The exception to this is the
discussion about calling a CHGOBJ function based on a
PHY access path from an associated RTVOBJ function
based on the same PHY access path.
A CRTOBJ function based on a PHY access path
cannot be included in the same generated HLL program
as a RTVOBJ, CHGOBJ or DLTOBJ function based on
the same PHY access path. This is because the file
definition for creating a record cannot have relative
record number processing as specified for RTVOBJ,
CHGOBJ and DLTOBJ functions based on PHY access
paths.
New JOB Context Fields
The shipped *Job data data model file has been
updated to include the following new fields along with
the internal DDS name associated with them:
An Independent Review of COOL:2E Release 7.0
24 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
*Pgm *STATUS STS
*Pgm Previous *STATUS PST
*Pgm *ROUTINE RVN
*Pgm *PARMS PRM
*Pgm Exception msgid MSI
*Pgm Program library PLB
*Pgm Exception data MSD
*Pgm File in error EFL
*Pgm Last file status EFS
These fields have always been available in the format
physical files Y2PGDSP and Y2PGDSPK for
compiling RPG and COBOL generated programs
respectively. They just have never been included as
entries in the shipped *Job data data model file.
To fall in line with the naming standards for shipped
data model objects, all of these fields have had their
internal DDS names changed from four-character to
three-character names. This will present problems to
COOL:2E developers that have modified the *Job
data file in prior releases of COOL:2E to achieve what
is now provided by default in Release 7.0. For the
limited number of COOL:2E developers that have done
this, the fields they have defined will no longer be
declared in their programs and those programs will fail
compilation. The development lab have mentioned that
they dont advocate any COOL:2E users changing
shipped data model objects in this manner.
There are still some fields on the format physical files
Y2PGDSP and Y2PGDSPK that have not been
included as entries on the shipped *Job data data
model file. You can still define them as your own fields
and add them as database relations to the shipped *Job
data data model file. If you have already defined them
to your data models in a prior release, there is no
requirement to remove them before upgrading to
Release 7.0.
For COBOL generated programs these new fields on
the *Job data data model file will not have any
purpose. This is because they relate to the Program
Status Data Structure in RPG. COBOL generated
programs use the shipped program Y2RTJCR to
retrieve the JOB context fields at run time, as there is
no equivalent Program Status Data Structure in
COBOL.
It has been the objective of the development lab for
many years to only include enhancements that could be
utilised in all target HLL generators, otherwise it would
not be included. The exception was made here as these
new fields can be utilised by RPG IV generated
programs and modules to reduce impact of data model
changes and monitor for specific program exceptions.
Upgrading From Prior Releases
If you have modified the shipped *Job data data
model file to include the fields listed above, then you
need to perform the following actions before upgrading
the data model to Release 7.0:
perform some preliminary impact analysis to
determine if the *Job data data model file is used
for passing parameters to functions and messages,
remove the fields from the shipped *Job data
data model file by deleting the database file
relationship,
try and delete the fields from the data model, and
rename those fields you could not delete so they
dont clash with the new shipped fields.
You will need to assess the impact where the shipped
*Job data data model file has been used to define
parameters on functions and messages. The following
SQL command will identify all parameter usage for the
shipped *Job data data model file:
SELECT @@MSG FROM *MDLLIB/YMSGPARRFP WHERE
@@FIL = 2
Replace *MDLLIB in the above command with the
library name of your data model to be analysed.
You can then use the following command to edit the
parameters of the function to check if the fields are
being used or not:
YPRCSFLSEL OBJSGT(@@MSG) SFLSEL(13)
Replace @@MSG in the above command with the
values returned from the prior SQL SELECT command.
If the parameters are being passed as RCD, then you
will need to recompile that function and all calling
functions to pick up the new record structure. If the
fields you will be attempting to delete are passed
to/from the function, then these functions will need to
be documented and changed to use the new fields as
part of the upgrade process. Make sure you note the
usage of the old fields, as they will disappear from the
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 25
AS/400 So ftware P ro ducts and Servi ces
parameter list after the next step of removing the fields
from the file.
There may be an impact on EXCUSRSRC and
EXCUSRPGM function types that use either of the
format physical files. Scan these functions for usage of
the new shipped fields old DDS names and correct
where necessary.
Removing the fields from the shipped *Job data data
model file will ensure that no other developers will
inadvertently use them in JOB context. This step should
only be started after the impact analysis results have
been resolved. Deleting the entry on the file will also
remove the field usage as a parameter on functions and
you will not know if it is actually passed.
If you are able to delete the old fields from the data
model, then they where not being used in the data
model. This will save you having to convert them to the
new fields.
Make sure that the names are not going to clash with
the new fields, as this will cause problems in upgrading
the data model.
After upgrading your data model to Release 7.0 you can
then convert the usage of your fields to the new shipped
fields. You have one of two options here depending on
your requirements for auditing. Highly structured
development environments with strictly adhered to
development and change control procedures will
probably want to fix the fields as part of the upgrade
process. However, this is not necessary for the majority
of sites where time and resource will not allow this
luxury.
There is no danger of data model or function corruption
in leaving the usage of the fields until a later date. You
will know if you encounter them during normal
development, as the programs will no longer compile
due to an undefined field. The benefit of this approach
is that you are not changing obsolete functions and you
can spread the fix over a longer period.
Figure 25: Chg Client:R4M EXCEXTFUN wrapper RPG IV ILE Module
Parameters:
Fmt Field name Usg Role File name
KEY Client Code I RST Client Update index
FLD Client Name I Client Update index
Client Address Line 1 I
Client Address Line 2 I
Client Address Line 3 I
FLD Client Postal Line 1 I Client Update index
Client Postal Line 2 I
Client Postal Line 3 I
...........................................................................
.--
| * Ignore initialisation errors.
| PGM.*Return code = CND.*Normal
| Change Client - Client * CHGOBJ
| I Client Code = PAR.Client Code
| I Client Name = PAR.Client Name
| I Client Address Line 1 = PAR.Client Address Line 1
| I Client Address Line 2 = PAR.Client Address Line 2
| I Client Address Line 3 = PAR.Client Address Line 3
| I Client Postal Line 1 = PAR.Client Postal Line 1
| I Client Postal Line 2 = PAR.Client Postal Line 2
| I Client Postal Line 3 = PAR.Client Postal Line 3
| I *Pgm *PARMS = JOB.*Pgm *PARMS
| * All error messages are sent by CHGOBJ function.
| * Exit with return code for calling function to process.
| Exit program - return code PGM.*Return code
--
An Independent Review of COOL:2E Release 7.0
26 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Optional Parameters
While investigating possible uses of the new RPG IV
ILE enhancements late in 1999, it became apparent that
a simple change to the data model could allow optional
parameters to be implemented on RPG IV generated
programs and modules. We have already discussed how
to use RPG IV modules to encapsulate your database
accesses and updates to reduce impact of file changes.
What we have not discussed is how to reduce the
impact of database change when the parameters to the
EXEXTFUN wrapper function change as well.
A change to a database file will mean that the
parameters on the CRTOBJ, CHGOBJ and possibly the
DLTOBJ functions based on that file will change. In
our example in figure 9 we would also need to change
the parameters to the EXCEXTFUN wrapper functions.
This would normally require the calling DSPFIL
function to be re-generated and compiled as well.
However, using optional parameters can eliminate the
need to re-generate and compile the calling DSPFIL
function.
If the EXCEXTFUN wrapper functions in figure 9 were
enabled for optional parameters, then we would only
need to re-generate and compile the wrapper functions.
The DSPFIL function that calls the wrapper functions
would only need to be updated with the command
UPDPGM in order to work. This is assuming that the
additional parameters are not required in order for the
DSPFIL function to function properly.
Consider the Chg Client:R4M EXCEXTFUN
function that acts a wrapper for the Change Client
CHGOBJ function in figure 9. Extra fields are being
added to the Client file for the postal address details.
Figure 25 shows the function details required to support
the new fields with optional parameters. Changes made
for the new fields are in bold italic typeface. There is
very little difference from any normal EXCEXTFUN
wrapper function.
The parameters have been declared to the wrapper
function so that any database change will have the least
amount of impact. There are three parameter entries
with the same file and access path. The first is passed as
KEY and sends all of the key fields to the wrapper
Figure 26: Change Client CHGOBJ function
Parameters:
Fmt Field name Usg Role File name
KEY Client Code I RST Client Update index
RCD Client Name I Client Update index
Client Address Line 1 I
Client Address Line 2 I
Client Address Line 3 I
Client Postal Line 1 I
Client Postal Line 2 I
Client Postal Line 3 I
FLD *Pgm *PARAMS I *FIELD
...........................................................................
> USER: Processing before Data update
.--
| * Load original fields to DB1 context.
| DB1.Client Name = PAR.Client Name
| DB1.Client Address Line 1 = PAR.Client Address Line 1
| DB1.Client Address Line 2 = PAR.Client Address Line 2
| DB1.Client Address Line 3 = PAR.Client Address Line 3
| > Load optional fields to DB1 context.
| .-CASE
| |-PAR.*Pgm *PARMS is > 6
| | DB1.Client Postal Line 1 = PAR.Client Postal Line 1
| | DB1.Client Postal Line 2 = PAR.Client Postal Line 2
| | DB1.Client Postal Line 3 = PAR.Client Postal Line 3
| -ENDCASE
--
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 27
AS/400 So ftware P ro ducts and Servi ces
function as RST role. The RST role has no affect on
generated HLL source code, it is only used here for
documenting the restrictive nature of the function in
that it will only process a single record.
The second parameter entry is passed as FLD and sends
the original attribute fields to the wrapper function
without a role specified.
The third parameter entry is passed as FLD and sends
the new attribute fields to the wrapper function without
a role specified. The reason for having a separate
parameter entry for the additional fields is that they
may have been entered at a sequence mixed in with the
original attribute fields. These new attribute fields will
become the optional parameters and all optional
parameters must be declared below all other
parameters.
All of the parameters are passed to the Change Client
CHGOBJ function along with the JOB context of the
*Pgm *PARMS field to inform the CHGOBJ how
many parameters are being passed. The Change
Client CHGOBJ function will use the value passed in
the *Pgm *PARMS parameter to determine which
fields to update on the database as shown in figure 26.
Parameter *Pgm *PARMS will have a value of six
when the EXCEXTFUN function is called from and
original calling function that is not re-generated. When
called from a function that is re-generated it will have a
value of nine. You might be wondering why it is six
and nine instead of five and eight. Dont forget that an
external function has an implicit return code parameter
as the first parameter and this is included in the count of
the number of parameters in JOB context field of
*Pgm *PARMS.
The parameters of the CHGOBJ function have been
declared so that the PAR context fields will not be
mapped implicitly to the associated DB1 context fields.
The first parameter entry only declares the KEY fields
and a CHGOBJ function will only use those fields
declared on the first parameter entry for implicit
mapping. The second parameter entry contains all of
the attribute fields, both the original and optional fields.
The reason for not allowing the implicit mapping of
PAR context to DB1 context is that we only want the
optional fields to be mapped when the number of
parameters is greater than six.
Assume that another file change is applied to the
Client file. We simply add the new fields to the end
of the parameters for the EXCEXTFUN wrapper and
CHGOBJ functions. Then check for the number of
parameters greater than nine in the CHGOBJ function
before updating the next group of DB1 context fields.
This technique seems almost too good to be true. It
provides developers with greater flexibility in
implementing file changes by reducing the impact of a
file change. There is just one flaw in the technique that
will require a fix to the RPG IV generator from the
development lab.
The definition of the *ENTRY and associated PARM
statements needs to be reformatted to remove optional
parameter usage. Figure 27 shows the current RPG IV
generated source code for the *ENTRY and associated
PARM statements. The parameters are received into the
WPnnn fields and mapped into the Pnxxxx fields
by the PARM operation code. Optional parameters
cannot be addressed by the program, otherwise a
runtime error will occur. Figure 28 shows the change
required to enable optional parameters to work.
Figure 27: Current RPG IV *ENTRY Parameters
FMT C .....CL0N01Factor1+++++++Opcode&ExtFactor2+++++++Result++++++++Len
0007.10 * Entry parameters
0007.20 C *ENTRY Plist
0007.30 C Parm P0rtn
0007.40 C P1aacd Parm Wp0001
0007.50 C P2aatx Parm Wp0002
0007.60 C P2abtx Parm Wp0003
0007.70 C P2actx Parm Wp0004
0007.80 C P2adtx Parm Wp0002
0007.90 C P2aetx Parm Wp0003
0008.00 C P2aftx Parm Wp0004
0008.10 C P2agtx Parm Wp0004
An Independent Review of COOL:2E Release 7.0
28 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
The reformatting of the *ENTRY and associated
PARM statements could be implemented as a new
function option for optional parameters, which would
be set to no optional parameters by default. If set to no,
the source code in figure 27 would be generated.
Otherwise, the source code in figure 28 would be
generated.
Without this change to the RPG IV generator, we will
not be able to implement optional parameters. One of
the most dreaded tasks in any AS/400 development,
whether it be traditional 3GL or COOL:2E based, is
performing a file change on a widely used file. Any
technique, which empowers the developer with the
capability of reducing the impact of a file change, adds
benefit to development process.
This technique of optional parameters is not limited to
the RPG IV generator as it can be equally applicable to
the RPG III generator. Unfortunately, COBOL does not
allow optional parameters, as the calling program must
match the linkage section exactly. Otherwise, a runtime
error will occur.
The optional parameter solution still needs some
additional consideration for parameters specified as
output or both usage. In or example we have only
considered parameters that are input usage, which are
the easiest to deal with as optional parameters.
Enhanced Object Locking
Objects in the data model can be explicitly locked from
accidental update or, as Computer Associates would
have us believe, for security reasons. An explicit lock is
also known as a permanent lock. Release 7.0 provides
new features to the permanent lock. A 50-character
description field has been added and the lock status
differentiates between designer and programmer
locking.
Object locking in the data model is a superficial
security measure. All locks, both implicit and explicit,
are maintained by the COOL:2E tool in a file called
YOBJLCKRFP. There are two data members in this
file, PRMLCK for explicit locks and YOBJLCKRFP
for implicit locks. Any person with authority to use the
data model can edit the contents of these data members
using YWRKF, SQL or any other database file utility.
Explicit object locking should not be viewed as a
security measure because its defence is so weak. It is
only an aid to prevent accidental changes to objects by
inexperienced or over-enthusiastic developers.
Adding the 50-character text field with an explicit lock
allows a developer to explain why the object is being
locked. Being confronted with an explicit object lock in
Figure 28: New RPG IV *ENTRY Parameters
FMT C .....CL0N01Factor1+++++++Opcode&ExtFactor2+++++++Result++++++++Len
0007.10 * Entry parameters
0007.20 C *ENTRY Plist
0007.30 C Parm P0rtn
0007.40 C Parm Wp0001
0007.50 C Parm Wp0002
0007.60 C Parm Wp0003
0007.70 C Parm Wp0004
0007.80 C Parm Wp0005
0007.90 C Parm Wp0006
0008.00 C Parm Wp0007
0008.10 C Parm Wp0008
0008.20 * Check for optional parameters
0008.30 C Clear P1parm
0008.40 C If ##prm > 1
0008.50 C Movel Wp0001 P1aacd
0008.60 C End
...
0010.60 C If ##prm > 8
0010.70 C Movel Wp0008 P3agtx
0010.80 C End
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 29
AS/400 So ftware P ro ducts and Servi ces
the past was more of an annoyance than an aid. Most
developers would simply remove the lock so that they
could perform the changes they required. Having a 50-
character text field associated with the explicit lock aids
in communicating why the lock was applied in the first
place. Maybe the object should not be changed due to a
pending file change or it is damaged in some way and it
should not be edited.
Explicit object locks in Release 7.0 also store the user
class that applied the lock. If you are editing a data
model as a designer, then any explicit locks applied will
be designer level locks. If you are editing a data model
as a programmer, then they will be programmer level
locks. Designers can remove other designer and
programmer level locks. Whilst programmers can only
remove programmer level locks.
The designer level locks will become the new
annoyance of object locking in Release 7.0. This is
because programmers will be confronted with them
when there are no designers around to remove them.
Programmers will resort to using YWRKF to manually
remove the record from the YOBJLCKRFP file in order
to do the work assigned to them. The only way to stop
this is to re-design the explicit locking facility to use
OS/400 object level authority. If the designer
permanent lock records where kept in a separate file,
then that file could be secured using OS/400 database
file data authority rights. This would provide very
secure object locking capabilities.
Explicit object locks can only be placed on the
following object types:
Access Path,
Array,
Function, and
Message.
The following data model object types cannot be
explicitly locked:
Application Area,
Condition,
File, and
Field.
Once an explicit lock is applied to an object, the details
of that object cannot be edited or displayed by any user.
There is a display object option from most of the list
type screens, such as Edit Model Object List and
Display Model Usage. This option will not work for
explicitly locked objects.
This is where the frustration begins. Imagine that all the
access paths on a file have been locked by a designer so
that programmers cannot change the details of the
access paths. Programmers will not be able to identify
which access path is the correct one for their task
because they cannot view the key sequence or select
omit criteria being used. What are they to do? They
cannot continually bother designers to remove and add
explicit locks as this would lead to very poor
productivity.
The display option needs to be able to view explicitly
locked objects without having to remove the lock. If the
lock is removed, in most cases it will never be reapplied
and the benefit of the object lock is removed.
It would be nice to be able to explicitly lock fields and
conditions. Fields are divided into two different
categories of usage, database and function. Database
fields are typically created by designers and in most
cases should only be maintained by designers. For this
reason, it would be nice to be able to place explicit
designer level locks on fields. This will prevent
programmers from changing them. If a function field is
based on a database field, then the conditions associated
with the database field should be available to
programmers to edit from the function field.
Softcopy Manuals
You will notice a change to the COOL:2E
Documentation CD-ROM provided with Release 7.0.
There is a Computer Associates splash screen, but the
underlying documents remain mostly unchanged from
Release 6.2.
The function structure charts have found their way back
into the Building Applications manual after their
accidental removal on the Release 6.2 Documentation
CD-ROM.
None of the Release 7.0 enhancements have been added
to the manuals, apart from the Release 7.0 Summary
document. Even more reason for this review.
An Independent Review of COOL:2E Release 7.0
30 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 31
AS/400 So ftware P ro ducts and Servi ces
Release 7.0 Significant Fixes
With most major releases of COOL:2E, the emphasis of
development has been on providing major
enhancements to the tool. Whereas with point releases,
such as Release 6.2, the emphasis has been on reducing
the ever growing list of issues identified by users of
COOL:2E or providing minor enhancements. Release
7.0 is no exception to this general rule of thumb.
The number of fixes that have been identified with
Release 7.0 is very small. Most of them have been
applied as a result of the extensive RC1 testing that was
conducted by dedicated COOL:2E users.
The COOL:2E Release Summary 7.0 provided by
Computer Associates on the COOL:2E Documentation
7.0 GA CD-ROM contains a list of fixes applied to
Release 7.0 and the various PTFs for Release 6.2.
Several of the fixes under the Release 7.0 fix list were
actually fixed in a prior PTF for Release 6.2.
Of the fixes that were applied in Release 7.0 we have
identified three that deserve a mention because they
will affect the manner in which you use COOL:2E.
Submit Job Override Option
Prior to Release 7.0, the submit job override option for
a call to an EXCEXTFUN, EXCUSRPGM or PRTFIL
function would default to * for model value override.
This meant that developers tended to use the model
value by mistake, which caused other functions to
submit jobs with the new default values when re-
generated. Release 7.0 now defaults the submit job
override option to L for local override.
While we are discussing the submit job options,
Release 7.0 enables an RPG IV ILE module to be
submitted. This is an error as ILE modules cannot be
called directly and the submitted job will fail with
program not found.
SELRCD Partial Key Parameters
When a SELRCD function is defined with partial key
parameters as in figure 29, the parameters generated in
the target HLL included all of the key fields. This was
fixed to only generate the declared parameters. The fix
was available with Release 6.2 PTF 62030.
This fix was identified as part of the backward
compatibility test and there are upgrade issues to be
addressed. See a full description of this issue and
techniques for identifying the issues and resolving them
in the Backward Compatibility Test section.
Figure 29: SELRCD Function Partial Key Parameters
Parameters:
Fmt Field name Usg Role File name
KEY Order Number I RST Order Product Retrieval index
Product Code
An Independent Review of COOL:2E Release 7.0
32 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
Long Condition Values
When condition values exceed 21 characters, the
operator is changed to ++. This caused generation
problems and attempts to correct the problem by
reducing the condition value failed to remove the ++.
The work-around required the developer to use the
command YWRKF to remove the ++ from the
YCNDDTARFP file in the data model. This has now
been resolved in Release 7.0 so that when you edit the
condition the ++ will be removed when the field
condition value is reduced in length below 21
characters.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 33
AS/400 So ftware P ro ducts and Servi ces
Backward Compatibility Test
Moving to a new release of COOL:2E is not as straight
forward as the installation manual
13
would have you
believe. You cannot just install the new Release,
upgrade your data models and expect that your
applications will generate and function as they did in
the earlier releases.
With each release there are changes to target HLL
generators, which could impact on the way your
applications function. For instance, one of the earlier
releases of Synon/2 in the late 1980s changed the way
in which the return code was set in RTVOBJ functions.
They used to return the message identifier for data
model message *Record does not exist when a record
was not found. The change that occurred was to return
the message identifier of the record not found message
associated with the file that the RTVOBJ function was
based on. Applications that used to test for the explicit
return code value of *Record does not exist no longer
functioned correctly.
In this section, we document the method and approach
used to conduct the backward compatibility checks.
You will be able to repeat the backward compatibility
test process in your own development environment for
a greater level of assurance. This will provide the level
of assurance required by most users to move to Release
7.0 without the need to worry about backward
compatibility issues.
The backward compatibility test compares the results of
generation at Release 7.0 with the results of generation
at Release 6.2 PTF 62010. If you are not coming from
Release 6.2 PTF 62010 or later, then it is advisable for
you to read An Independent Review of COOL:2E
Release 6.2
14
. This will cover moving from earlier
releases to Release 6.2 PTF 62010.

13
Computer Associates, 2000. Installing COOL:2E Products 7.0.
14
HawkBridge, 1999. An Independent Review of COOL:2E Release
6.2.
Test Objective
The objective of the backward compatibility test is to
ensure that data models migrating from an earlier
release will be capable of generating the same or
similar source code. A data model should be capable of
being migrated to Release 7.0 without any changes
having to be performed to functions, device designs or
access paths.
Test Data Models
For the backward compatibility test, we used copies of
our clients largest data models. We used two RPG and
one pure COBOL data model, which enabled us to
check both of the current target HLL generators.
It should be noted that the following features were not
used largely in any of the data models and as such were
not within the scope of the compatibility test:
Device Windows,
Menu Bars,
SQL,
QRY Access Paths,
SPN Access Paths,
EDTTRN Functions,
Device User Source,
CNT Fields,
MIN Fields,
MAX Fields,
User Defined Data Types, and
Date and Time Built-in Functions.
An Independent Review of COOL:2E Release 7.0
34 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
If you rely upon any of these features extensively, then
it is advisable for you to conduct your own backward
compatibility test.
First RPG Data Model
Our first client is currently at Release 6.0 and
generating RPG. The data model is 10 years old. The
following details were captured using COOL:PE:
394 entities,
1489 access paths,
5015 fields,
2617 internal functions, and
1613 external functions.
Detailed statistical reports are contained in Appendix A.
Second RPG Data Model
Our second client is currently at Release 5.2.1 and
generating RPG. The data model is almost 10 years old.
The following details were captured using COOL:PE:
236 entities,
794 access paths,
2418 fields,
1466 internal functions, and
615 external functions.
Detailed statistical reports are contained in Appendix B.
COBOL Data Model
Our third client is currently at Release 6.0 and
generating COBOL. They have also applied several
PTFs to rectify certain COBOL issues. The data model
is around 7 years old and has under-gone several major
enhancements. The following details were captured
using COOL:PE:
505 entities,
1898 access paths,
7255 fields,
5261 internal functions, and
2474 external functions.
Detailed statistical reports are contained in Appendix C.
Test Plan
The test plan for the backward compatibility test
involved the following sequence of events:
Convert data models to Release 6.2 PTF 62010,
Create a snapshot using COOL:PE,
Mass re-generate data models,
Convert data models to Release 7.0 RC1,
Create new generation libraries,
Mass re-generate data models,
Compare source members for differences, and
Analyze difference reports.
The data models where all converted to Release 6.2
PTF 62010 as the starting point of the backward
compatibility test. This release was the target of our last
backward compatibility test and so there was no need to
test the move from any prior release.
We used COOL:PE, the performance expert tool from
Computer Associates, to create a snapshot of the data
models. This was used to allow us to produce the
statistical analysis reports of the data models to give the
backward compatibility test some form of quantitative
meaning.
Mass re-generation is never easy. There are issues with
storage allocation in PLI programs that prevents a large
data model from re-generating in one pass. It required
several attempts to mass re-generate the data models.
The development lab has advised us that this issue
cannot be resolved as it is a limitation with the PLI
compiler and is not within their control.
We used the CRTJOBD(*NONE) parameter on the
YSBMMDLCRT command to stop the compilation of
the generated objects. Our interest is in obtaining the
generated source and not wasting testing time and
resource to compiling objects.
A new generation library was created for each of the
test data models. The library was created using the
CRTLIB command and then the following command
was executed to create the necessary objects for
generation:
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 35
AS/400 So ftware P ro ducts and Servi ces
YCRTGENOBJ OBJLIB(*NEWGEN)
Replace *NEWGEN in the above command with the
new generation library name. The current library list
must contain the data model and generation libraries of
the data model that the will be associated with new
generation library.
Using the YCRTGENOBJ command to create a new
generation library produces more objects in the new
generation library than exist in the from generation
library. If we where to just copy the objects from the
old generation library it would have taken longer to
copy all of the generated source file members. Also, we
did not want the results of the previous mass re-
generation to exist in the new generation library. This
would have made it difficult to identify failed object
generations during source file member comparison.
The data model value YGENLIB, job description
library lists, and data model library list was updated by
replacing the old generation library with the new one.
Source file members for all EXCUSRSRC functions
where copied from the old generation library to the new
generation library. You can achieve this by building a
model object list of them all, or subsetting the
*ALLOBJ model object list, and executing the
following command against the entries:
CPYF FROMFILE(*OLDGEN/*SRCF)
TOFILE(*NEWGEN/*SRCF) FROMMBR(&YI)
TOMBR(*FROMMBR) MBROPT(*REPLACE)
Replace *OLDGEN in the above command with the
old generation library name; *SRCF with the source
file name, such as QRPGSRC or QLBLSRC; and
*NEWGEN with the new generation library name.
You can use the merge with command option, /,
against the first function in the model object list and use
function F13 to repeat that option to the bottom of the
model object list. Then place the above command on
the command line and press the Enter key.
The second mass re-generation generated the source
into the new generation library, thus preserving the
results of the first mass re-generation. We used the
same options as used for the first mass re-generation.
We compared the source file members in QDDSSRC,
QLBLSRC and QRPGSRC from the new generation
library to the same source file member in the old
generation. The following command was used to
compare source file members:
CMPPFM NEWFILE(*NEWGEN/*SRCF) NEWMBR(*ALL)
OLDFILE(*OLDGEN/*SRCF) OLDMBR(*NEWMBR)
RPTTYPE(*DIFF) OUTPUT(*PRINT)
OPTION(*OMTxxxCMT)
Replace *OLDGEN in the above command with the
old generation library name; *SRCF with the source
file name, such as QRPGSRC, QLBLSRC or
QDDSSRC; and *NEWGEN with the new generation
library name.
The value specified for the OPTION parameter should
be replaced with either *OMTRPGCMT,
*OMTCBLCMT or *OMTDDSCMT depending
upon the source file being compared. This option
removes comment lines from the comparison.
Comments have no impact on the compiled object and
are not within the scope of the backward compatibility
test.
The most time consuming task of the backward
compatibility test is the physical check of the difference
reports produced by the CMPPFM command above.
Our largest report was 830 pages long followed by 608
pages and then 241 pages for the COBOL QLBLSRC,
first RPG QRPGSRC and second RPG QRPGSRC files
respectively. This step is prone to errors of omission, as
it requires human involvement to visually scan the
reports for incompatible differences. It is quite possible
for some errors to be missed, particularly when they
occur infrequently throughout the difference report.
Testing is not an absolute method of removing errors,
whether it is backward compatibility testing, system
testing or any other type of test. Testing is a method of
providing quality assurance and not a process whereby
all errors are identified and removed from the process
or application being tested. For this reason, we do not
offer any guarantees with the results and
recommendations of the backward compatibility test.
Test Results
The backward compatibility test identified very few
changes in the RPG III and COBOL generators. Those
that we did find were connected with fixes or
An Independent Review of COOL:2E Release 7.0
36 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
preparations for the implementation of the RPG IV
generator.
YAPYSYSMDL Audit Report
Make sure you read the audit report produced during
the conversion of your data model to Release 7.0. We
found that it produced a warning for an issue with the
new JOB context fields that prevents one of our clients
from upgrading to Release 7.0.
The new JOB context fields added for Release 7.0 are
added to the data model during the upgrade process.
Should a field already exist using the DDS name of the
new JOB context fields, then the DDS name of that
field will be cleared. If that field appears on database
files, as it does for our client, then you have to re-
generate that file and all impacted files and functions
after setting the DDS name to a valid value. This is not
an option when it impacts most of the data model and
testing of all generated functions is a necessity.
The problem is not with the re-generation, but the
amount of time and effort in testing the re-generation.
We have inherited an issue in change control practice
with the particular client whereby previous developers
had not kept the generated source of objects moved to
production. The data model is old enough to have gone
through several upgrades and data model changes and
the generated source produced today does not function
as it did when the function was originally generated. If
they had kept the original generated source file
members, then testing would only have been a matter of
comparing them to identify differences.
There is another issue with the audit report in that it
does not include all of the fields that where added to the
data model. The only fields reported are *Pgm
*STATUS and *Pgm *PARMS. The remainder of
the new JOB context fields do not appear on the report
although they were added in the upgrade process.
SELRCD Partial Key Parameters
When a SELRCD function uses partial key parameters,
previous releases generated all of the key parameters.
This was fixed for Release 7.0 and has an impact when
the SELRCD function or any calling function is re-
generated. The calling function will have a runtime
error with parameter mismatches unless all impacted
functions are re-generated and compiled.
Use the following two SQL SELECT statements to
identify SELRCD functions with partial key parameters
defined:
SELECT DISTINCT MSG.@@MSG, MSG.SRCMBR FROM
((YMSGDTARFP MSG JOIN YACPDTARFP ACP ON
MSG.@@ACP = ACP.@@ACP) JOIN YACPENTRFP
APE ON MSG.@@ACP = APE.@@ACP) LEFT OUTER
JOIN YMSGPDTRFP PDT ON MSG.@@MSG =
PDT.@@MSG AND APE.@@FLD = PDT.@@FLD
WHERE APE.KEYNBR <> 0 AND ACP.OBJATR <>
'RTV' AND MSG.@@MSG_P = 9000500 AND
(PDT.PARUSG = ' ' OR PDT.PARUSG IS NULL)
SELECT DISTINCT MSG.@@MSG, MSG.SRCMBR FROM
((YMSGDTARFP MSG JOIN YACPDTARFP ACP ON
MSG.@@ACP = ACP.@@ACP) JOIN YENTDTARFP
ENT ON MSG.@@FIL = ENT.@@FIL) LEFT OUTER
JOIN YMSGPDTRFP PDT ON MSG.@@MSG =
PDT.@@MSG AND ENT.@@FLD = PDT.@@FLD
WHERE ENT.ENTTYP = 'K' AND ENT.ENTSEQ <>
0 AND ACP.OBJATR = 'RTV' AND MSG.@@MSG_P
= 9000500 AND (PDT.PARUSG = ' ' OR
PDT.PARUSG IS NULL)
The reason for two separate SQL SELECT statements
is that RTV access path types store their key fields
differently than RSQ or QRY access path types.
You can then use the following command to edit the
function parameters:
YPRCSFLSEL OBJSGT(@@MSG) SFLSEL(13)
Replace @@MSG in the above command with the
values returned from the prior SQL SELECT
statements.
To determine which functions use the SELRCD
function you may have to use 3GL cross-reference
techniques. This is because the implicit select record
processing for display functions cannot be identified
using the YDSPMDLUSG command. A simple
technique is to use the command DSPPGMREF to
document all of the programs in your application to an
output file. Then use either SQL or Queries to find
referencing programs.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 37
AS/400 So ftware P ro ducts and Servi ces
RPG III MOVEL with P Operation Extender
The use of the P operation extender on the MOVEL
operation code
15
has been used extensively in RPG III
generated source code. This will pad the result of the
MOVEL operation from the right with blanks, zeros or
0 depending upon the data type of the result field.
Prior to Release 7.0 some result fields where being
initialised to blanks or zeros prior to the MOVEL
operation. This unnecessary operation has been
removed.
There are no backward compatibility issues regarding
this change. Although, very minute changes in runtime
might be achieved due to the reduction in the number of
MOVEL operation codes being used.
RPG III Result Field Declaration
The use of field length and decimal positions on
calculation specifications has been minimised. In
particular the declaration of the ZAMSDA, @1FFL,
@1FLB and @1FMB fields has been removed from
calculation specifications.
We suspect that this change was linked with the
changes made for the RPG IV generator. As mentioned
earlier, this release of the RPG IV generator makes use
of some of the RPG III generator programs. Having the
declarations in the calculation specification may have
reduced the capability of converting them to the new
definition specification.
There are no backward compatibility issues regarding
this change.
RPG III DSPFIL Initialise #1SEL Field
Sub-routine MBFL#1 initialises the #1SEL field twice.
This seems to have been introduced in a Release 6.2
PTF as it can be reproduced at PTF 62050.
There are no backward compatibility issues regarding
this change. It is just an unnecessary piece of source
code.

15
IBM, 1994. IBM Application System/400 - RPG/400 Reference,
Edition 1. Document Number SC09-1817-00. Chapter 11, Operation
Codes. Section 11.14 Move Operations.
COBOL RTVOBJ and Qualified by Relation
The COBOL source code generated for a RTVOBJ
function based on an access path that uses a key field
resolved from a Qualified by relation has changed.
The resultant source code is around 50 or so lines less
in Release 7.0. This is because they are no longer using
the START GREATER THAN and READ PRIOR
statements. Instead, they are using the dynamic file
processing associated with the READ statement.
The use of indicator 91 has also been removed from the
generated source code. This indicator was redundant as
it was always set off after it was set on for an input-
output error with the START statement.
There is an outstanding question with development
regarding a possible source code generation error. The
full externally described key list is loaded with low
values, but is never moved into the corresponding fields
of the record format of the file being accessed. This
seems to only occur when fully restricted key
parameters are declared to the RTVOBJ function. If
they have intentionally dropped the MOVE
CORRESPONDING statement, then the full externally
described key list is a redundant data structure.
However, if it has not been intentionally dropped it
could result in the wrong record being read from the file
depending on the circumstances that produce this
behavior.
Conclusion
The two RPG data models used for the backward
compatibility test can migrate to Release 7.0 from
Release 6.2 PTF 62010 without any changes. Other
RPG data models may have issues with conflicting field
DDS names on the YAPYMDLCHG audit report.
The COBOL data model cannot migrate to Release 7.0
due to the problems with conflicting field DDS names
on the YAPYMDLCHG audit report and the possible
issue with RTVOBJ functions using key fields resolved
from a Qualified by relation.
An Independent Review of COOL:2E Release 7.0
38 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 39
AS/400 So ftware P ro ducts and Servi ces
Future Direction
February 14 is a day that most people will remember as
Saint Valentines Day. This year, for Sterling Software
employees and clients, it marks the day that Computer
Associates announced its intention to buy Sterling
Software. It took seven weeks for the purchase to be
approved by various regulatory bodies and on April 3
this year, it was formally announced by Computer
Associates.
During E-Strategies at CA-World 2000 in New Orleans
on April 10 this year, we heard about the future
directions of COOL:Plex and COOL:2E from Wasim
Ahmad. It was hard for Wasim to discuss the future of
the products, considering that Computer Associates had
not publicly announced its intentions. The presentation
covered the next releases of both products, which at the
time were almost ready for delivery into RC1 testing.
On April 11 this year, Computer Associates issued the
roadmaps that would outline the future direction of the
Sterling Software products. This amounted to a very
broad statement about continuing to support and
extend the Sterling COOL family of application
development and modeling products.
Later that same day, Wasim re-gave his presentation
from the previous day. This time he was able to
disclose more detail about the direction that the
products would move under the ownership of Computer
Associates. Although, he could not provide any dates
for delivery. For COOL:2E it was announced that they
would provide better support for applications to
increase e-business interoperability.
Amongst the offerings were an XML interface, HTML
generation, and possible integration with Jasmine
ii
.
Interesting to note that the future direction of all the
COOL products is e-business centered and in particular
they were to integrate through Jasmine
ii
.
In September of last year, Sterling Software issued
similar statements of direction for COOL:Plex and
COOL:2E. Release 7.0 of COOL:2E is the result of that
statement of direction and there is very little in the way
of e-business enablement in the new features and
enhancements. Although, we are pleased with what has
been delivered in Release 7.0 as it extends the life of
our applications by allowing us to move to RPG IV and
ILE.
At ISSUG 2000 in Paris on June 13 to 16 this year, the
presentations by Computer Associates were almost
identical to those given at CA-World in New Orleans
earlier this year. There was no new information about
product directions under Computer Associates or dates
for delivering them.
Computer Associates issued the detailed roadmaps for
the COOL products in July of this year. Again it
mentioned the move to e-business enable COOL:2E
and for the first time we see statements about future
enhancements that are not related to e-business. The
COBOL ILE generator will be provided along with
better support for ILE development allowing more
control over the ways applications are created and
helping them to perform faster.
Development of the next release of COOL:2E beyond
Release 7.0 is already underway in the lab. So far, we
have not been involved in that release and there has
been no public statement by Computer Associates about
the progress and content of the next release. Let alone
any mention of delivery dates. Like many other
COOL:2E users, we will have to wait and see. Just as
Release 7.0 was the release to determine the future of
COOL:2E under the management of Sterling Software,
this next release will provide us with an indication of
Computer Associates future intentions with COOL:2E.
An Independent Review of COOL:2E Release 7.0
40 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
E-Business Direction
The strategic direction for COOL:2E under the
management of Computer Associates is e-business.
They believe that e-business covers everything from
electronic business to wireless e-business and anyone
not looking at this will go bust or cease to be
significant.
We disagree with the amount of emphasis being placed
on e-business. E-business is not the only aspect of an
application, yet with the amount of press it receives one
would think it was the only part of business. The only
parts of COOL:2E applications that need to be e-
business enabled are the delivery and presentation of
data. You dont need any special e-business features to
prepare that data for e-business and it would be very
similar to the way that EDI applications have
functioned in the past.
It was revealed at ISSUG 2000 in Paris, during the
COOL:Plex and COOL:2E Technical Panel Discussion,
that there are three stages for e-business enablement in
the plan for COOL:2E. The first stage is delivered with
Release 7.0, which was to provide dynamic web
enablement through NewLook, from Look Software Pty
Ltd
16
. The second stage in the e-business plan for
COOL:2E is to extend COOL:2E to the web via
Jasmine
ii
. The third and final stage is to generate
HTML for Jasmine
ii
.
Dynamic Web Enablement with NewLook
The first stage in e-business enablement of COOL:2E
required no change what so ever to the base COOL:2E
tool. NewLook interfaces with the 5250 data-stream in
order to provide a dynamic graphical user interface.
Although, Look Software do have plans to provide an
AS/400 based server program to provide more
information to NewLook at run-time about the
application. This server program may be capable of
reading and processing information stored in the
COOL:2E data model. However, for now there is no
interfacing of NewLook with the underlying data model
that generated the screens that it interprets. This means
that any prior release of COOL:2E will be capable of
generating applications that will run under NewLook,
not just Release 7.0.

16
Look Software Pty Ltd, http://www.looksoftware.com/.
NewLook is not just a dynamic web enablement tool. It
can also function as a replacement for your 5250
emulator on the corporate LAN or WAN. It allows you
to quickly convert standard green screen applications to
point and click applications with dynamic integration
with desktop applications. Its rules based interpreter
makes GUI conversion projects almost obsolete.
Jasmine
ii
Bridge to AS/400
Jasmine
ii
will allow you to create e-business
applications, re-use investments on other platforms, and
leverage a rich integration environment
17
. It has not
been disclosed what will be provided to Jasmine
ii
for
this stage and when it will be delivered. It looks as if it
will only benefit those COOL:2E customers that
purchase Jasmine
ii
as it will only be accessible via
Jasmine
ii
providers.
Jasmine
ii
does not currently have a bridge to the
AS/400, but it has been mentioned in the Roadmap as a
future enhancement. The bridge will enable COM and
EJB applications on other platforms to access
COOL:2E applications. The wording in the Roadmap
tends to suggest that it may be possible to interface with
non-COOL:2E generated applications. This would
allow Computer Associates to sell their Jasmine
ii
product to a larger AS/400 customer base.
We dont believe that Computer Associates understand
how loyal AS/400 users are to IBM mid-range. If they
did, then they would realise that most COOL:2E users
have no interest in Jasmine
ii
or any other product that
does not reside on the AS/400. Most sites, which we
know of, have a single development team that only
produce AS/400 applications. Why should they have a
need for an application integration tool like Jasmine
ii
when their applications are already integrated on the
AS/400. The AS/400 can also now function as the
complete e-business hardware solution, so there is no
need to have separate NT, UNIX or other web servers.
Jasmine
ii
was designed for UNIX, NT and Windows
environments where there is a plethora of disparate
applications in dire need of integration. Providing
enhancements to COOL:2E that benefit only Jasmine
ii
users will further alienate Computer Associates from
their existing COOL:2E customer base.

17
Computer Associates, July 2000. Roadmap for COOL Products.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 41
AS/400 So ftware P ro ducts and Servi ces
HTML Generation for Jasmine
ii
We suspect this also incorporates the generation of
XML from COOL:2E data models, although it was not
specifically mentioned in Paris. The generated HTML
and XML may not be specific to Jasmine
ii
. Which
means you could possibly use this feature to build web
applications for other third party products.
ILE Generator Direction
More than half of those attending the COOL:2E
Developer Round Table during E-Strategies at CA-
World 2000 believe that ILE is more important than
any other enhancement in COOL:2E. The continued
enhancement of COOL:2E in this area will be the most
appreciated and will maintain customer loyalty in
COOL:2E.
IBM is placing more emphasis on RPG IV ILE in the
hope of making it a mainstream development language.
Recent announcements have indicated that it will even
support new data types for Java classes and methods.
This will allow RPG IV ILE programs and modules to
interact with Java applications. The reverse is also
available whereby a Java application can interact with
an ILE application. This feature and others are set to
encourage a lot more applications to be developed on
the AS/400. Should you be using IBMs web serving
tools on the AS/400 then seamless integration of e-
business applications with traditional AS/400
applications will be possible.
COBOL ILE Generator
The COBOL ILE generator has been identified as a
future enhancement for COOL:2E. This provides us
with some comfort that they might understand their
customers by providing an incentive to some COOL:2E
users that are not e-business focused.
The amount of time and effort required to convert the
existing COBOL generator into a COBOL ILE
generator is considerably less than that required for the
RPG IV ILE generator. This is mainly due to the
similarity in the syntax of the OPM and ILE versions of
COBOL. For this reason, we expect the COBOL ILE
generator to be delivered as a point release of Release
7.0. Although, no details and dates have been provided
by Computer Associates.
Further ILE Support
Release 7.0 is the first step in a multi-phase
implementation of ILE within COOL:2E. It has
provided the very basic ILE features so organisations
can commence to convert their applications to ILE. In
order to fully support ILE within COOL:2E there will
be a need to include the following features, some of
which have already been discussed in this document:
all ILE primitive data types,
procedures,
mixed language development,
ILE and service programs,
ILE module traceability and update,
optional parameters, and
multiple binding directories.
The detailed roadmaps for COOL products did not go
into specific ILE enhancements that would be provided.
However, we can read a lot more into what is provided,
based on our experiences with Release 7.0 and ILE
development. In allowing more control over ways
applications are created, we suspect they mean to
provide support for CRTPGM and CRTSRVPGM
commands. To help them to perform faster, we
suspect they intend providing support for procedures
much like modules are provided in Release 7.0.
New Sales Opportunity
The single largest enhancement in Release 7.0 is the
RPG IV ILE generator. This single enhancement will
be of more value to COOL:2E users than any e-
business enablement enhancement. It offers the
opportunity to use new language features on the AS/400
and better integration into other ILE applications. If
Computer Associates are true to their word in further
enhancing COOL:2E to fully support ILE development,
then COOL:2E could once again be in a position to
expand its user base.
An Independent Review of COOL:2E Release 7.0
42 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
At E-Strategies at CA-World 2000 in New Orleans,
during the COOL:2E Developers Round Table, it was
raised that the tool should be enhanced to enable
existing AS/400 3GL development sites a better
migration path. Wasim Ahmad quoted that only 20% of
the 500,000 AS/400s sold are used for development and
that only 20% of them use CASE tools. This means that
there are 80,000 development AS/400s using 3GL
development techniques and would be potential
COOL:2E customers.
IBM is enhancing the capabilities of RPG IV ILE in the
hope that it will provide enough reason for RPG III
customers to migrate. Since its debut in the early 1990s,
RPG IV ILE has never really taken off as a mainstream
development language. This is mainly due to the
complexity of the ILE development environment
compared to traditional OPM development and the
significant changes in the syntax and semantics of the
new language. COOL:2E could become a tool that
simplifies ILE development making it a necessity for
every AS/400 ILE development site.
Release 7.0 of COOL:2E provides the basic enablement
of RPG ILE application generation in the first step of a
multi-phased implementation of a fully ILE compatible
generator. Before COOL:2E could be sold to traditional
3GL development sites as an ILE management tool,
there would need to be full support for all of the ILE
features. When everyone sees how easy it is for
COOL:2E developers to implement and maintain ILE
applications, they will be convinced of its power as an
ILE development tool.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 43
AS/400 So ftware P ro ducts and Servi ces
Conclusion
Release 7.0 is a significant enhancement of
COOL:2E that will benefit the majority of COOL:2E
users. Had COOL:2E remained with Sterling
Software, I would have said that it demonstrated
Sterling Software were committed to the product.
However, Computer Associates now own COOL:2E
and we will have to wait until the next release before
such a statement can be made about Computer
Associates commitment to the product.
The introduction of an RPG IV ILE generator will
greatly increase the life and viability of our
applications and the proposed COBOL ILE generator
will enable all COOL:2E users to benefit.
Many organisations are looking at modernisation
projects now that the Y2K projects have ceased to
impact the IT budget. The enhancements to extract
business logic into re-usable routines enables
modernisation projects to save considerable time and
effort over manually converting functions.
EDI applications stand to benefit the most from the
batch processing enhancements. Developers will no
longer be required to create and maintain data model
objects just to process a physical file in the data
model.
The future releases for COOL:2E under the
management of Computer Associates have yet to be
scheduled. Further extensions to the ILE generators
will probably be the most appreciated enhancement
after users get a taste of ILE in Release 7.0.
From where we stand, COOL:2E will have a bright
future under the management of Computer
Associates as long as they continue to deliver
significant enhancements that are relevant to the
majority of the users.
An Independent Review of COOL:2E Release 7.0
44 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 45
AS/400 So ftware P ro ducts and Servi ces
Appendix A: First RPG Data Model
The following reports have been produced for the
first RPG data model used for backward
compatibility testing using COOL:PE:
File Statistics Report,
Access Path Statistics Report,
Field Statistics Report,
Function Statistics Report, and
Action Diagram Instruction Type Statistics
Report.
The headers and client specific data have been
removed to protect client confidentiality.
Consult the COOL:PE manual supplied on the
documentation CD-ROM for details about how to
interpret these reports.
An Independent Review of COOL:2E Release 7.0
46 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

A
-
1
:

F
i
l
e


S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
l
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
i
l
e
F
i
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
C
o
u
n
t
C
P
T
D
B
F
C
a
p
t
u
r
e
f
i
l
e
1
0
3
R
C
D
R
e
c
o
r
d
f
o
r
m
a
t
0
R
E
F
D
B
F
R
e
f
e
r
e
n
c
e
f
i
l
e
2
5
2
S
T
R
S
t
r
u
c
t
u
r
e
3
9
T
o
t
a
l
3
9
4
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
c
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 47
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

A
-
2
:

A
c
c
e
s
s

P
a
t
h

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
A
c
c
e
s
s
P
a
t
h
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
A
c
c
e
s
s
A
c
c
e
s
s
H
a
v
e
I
n
d
e
x
I
n
d
e
x
I
n
d
e
x
S
t
a
t
i
c
D
y
n
a
m
i
c
A
L
T
C
O
L
p
a
t
h
p
a
t
h
u
n
i
q
u
e
m
a
i
n
t
m
a
i
n
t
m
a
i
n
t
s
e
l
e
c
t
s
e
l
e
c
t
t
a
b
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
k
e
y
s
i
m
m
e
d
r
e
b
u
i
l
d
d
e
l
a
y
/
o
m
i
t
/
o
m
i
t
c
o
u
n
t
P
H
Y
P
h
y
s
i
c
a
l
3
8
3
0
0
0
0
0
0
0
U
P
D
U
p
d
a
t
e
3
8
6
3
8
6
3
8
6
0
0
0
0
0
R
T
V
R
e
t
r
i
e
v
a
l
4
1
2
4
1
2
4
1
2
0
0
1
6
2
0
R
S
Q
R
e
s
e
q
u
e
n
c
e
2
9
4
3
1
2
8
1
0
1
3
3
4
9
0
S
P
N
S
p
a
n
1
4
0
1
1
0
3
8
1
0
Q
R
Y
Q
u
e
r
y
0
0
0
0
0
0
0
0
G
r
a
n
d
t
o
t
a
l
s
1
,
4
8
9
8
2
9
1
,
0
9
0
0
1
6
5
8
1
2
0
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
48 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

A
-
3
:

F
i
e
l
d

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
e
l
d
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
u
n
c
.
B
a
s
e
F
i
e
l
d
F
i
e
l
d
F
i
e
l
d
%
o
f
f
i
e
l
d
d
o
m
a
i
n
r
e
f
e
r
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
m
o
d
e
l
c
o
u
n
t
c
o
u
n
t
r
a
t
i
o
B
V
L
B
u
d
g
e
t
V
a
l
u
e
1
9
2
3
.
8
5
6
1
1
9
2
.
0
0
C
D
E
A
l
p
h
a
m
e
r
i
c
c
o
d
e
v
a
l
u
e
6
4
0
1
2
.
7
2
3
7
0
1
.
7
2
D
T
#
D
a
t
e
i
n
*
I
S
O
f
o
r
m
a
t
(
Y
Y
Y
Y
-
M
M
-
D
D
i
n
t
e
r
n
a
l
l
y
)
3
0
.
5
0
2
8
1
.
0
7
D
T
E
D
a
t
e
i
n
s
y
s
t
e
m
d
a
t
e
f
o
r
m
a
t
-
(
Y
Y
M
M
D
D
i
n
t
e
r
n
a
l
l
y
)
1
3
3
2
.
6
0
8
5
1
.
5
6
N
A
R
N
a
r
r
a
t
i
v
e
t
e
x
t
9
8
1
.
9
2
6
9
8
1
.
0
0
N
B
R
P
u
r
e
n
u
m
e
r
i
c
v
a
l
u
e
(
e
g
l
i
n
e
n
u
m
b
e
r
)
.
8
1
3
1
6
.
2
1
3
9
7
2
.
0
4
P
C
T
P
e
r
c
e
n
t
a
g
e
o
r
m
a
r
k
e
t
i
n
d
e
x
.
1
4
0
2
.
7
0
1
0
4
1
.
3
4
P
R
C
P
r
i
c
e
o
r
t
a
r
r
i
f
1
2
.
2
1
9
1
.
3
3
Q
T
Y
Q
u
a
n
t
i
t
y
4
9
.
9
0
2
8
1
.
7
5
S
T
S
S
t
a
t
u
s
.
1
,
0
8
9
2
1
.
7
1
2
8
8
1
9
1
.
3
2
T
M
#
T
i
m
e
i
n
*
I
S
O
f
o
r
m
a
t
(
H
H
.
M
M
.
S
S
i
n
t
e
r
n
a
l
l
y
)
3
.
0
0
3
1
.
0
0
T
M
E
T
i
m
e
i
n
H
H
M
M
S
S
f
o
r
m
a
t
.
1
9
.
3
1
1
3
1
.
4
6
T
X
T
O
b
j
e
c
t
t
e
x
t
.
1
,
0
1
0
2
0
.
1
1
2
7
6
2
1
1
.
6
2
V
A
L
M
o
n
e
t
a
r
y
v
a
l
u
e
7
5
9
1
5
.
1
3
8
3
4
0
2
.
2
3
V
N
M
V
a
l
i
d
S
y
s
t
e
m
n
a
m
e
2
8
.
5
7
1
1
2
.
5
4
T
o
t
a
l
s
5
,
0
1
5
3
8
7
2
,
9
2
7
1
.
7
1
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 49
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

A
-
4
:

F
u
n
c
t
i
o
n

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
u
n
c
t
i
o
n
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
F
u
n
c
t
i
o
n
t
y
p
e
C
o
u
n
t
f
u
n
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
6
9
1
.
6
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
2
2
2
.
8
E
d
i
t
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
2
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
1
.
0
E
d
i
t
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
1
5
.
3
D
i
s
p
l
a
y
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
1
3
.
3
E
d
i
t
f
i
l
e
1
8
6
4
.
3
D
i
s
p
l
a
y
f
i
l
e
2
4
8
5
.
8
E
d
i
t
t
r
a
n
s
a
c
t
i
o
n
4
.
0
D
i
s
p
l
a
y
t
r
a
n
s
a
c
t
i
o
n
1
.
0
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
9
5
2
.
2
S
e
l
e
c
t
r
e
c
o
r
d
1
4
6
3
.
4
P
r
i
n
t
f
i
l
e
1
6
4
3
.
8
P
r
i
n
t
o
b
j
e
c
t
1
0
6
2
.
5
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
2
5
4
6
.
0
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
1
7
9
4
.
2
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
2
9
3
6
.
9
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
1
0
0
2
.
3
C
r
e
a
t
e
o
b
j
e
c
t
3
5
0
8
.
2
C
h
a
n
g
e
o
b
j
e
c
t
4
4
1
1
0
.
4
D
e
l
e
t
e
o
b
j
e
c
t
3
3
9
8
.
0
R
e
t
r
i
e
v
e
o
b
j
e
c
t
1
,
0
8
7
2
5
.
6
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
4
.
0
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
1
1
.
2
G
r
a
n
d
t
o
t
a
l
4
,
2
3
0
T
o
t
a
l
i
n
t
e
r
n
a
l
(
s
u
b
r
o
u
t
i
n
e
)
f
u
n
c
t
i
o
n
s
.
:
2
,
6
1
7
T
o
t
a
l
e
x
t
e
r
n
a
l
(
p
r
o
g
r
a
m
)
f
u
n
c
t
i
o
n
s
.
.
:
1
,
6
1
3
T
o
t
a
l
s
c
r
e
e
n
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
9
0
2
T
o
t
a
l
r
e
p
o
r
t
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
1
6
4
T
o
t
a
l
b
a
t
c
h
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
.
:
2
5
4
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
50 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

A
-
5
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

1

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
4
1
.
2
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
6
7
.
3
E
d
i
t
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
3
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
6
.
0
E
d
i
t
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
3
6
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
3
8
.
0
E
d
i
t
f
i
l
e
1
7
9
.
3
D
i
s
p
l
a
y
f
i
l
e
5
6
6
1
.
1
E
d
i
t
t
r
a
n
s
a
c
t
i
o
n
8
.
0
D
i
s
p
l
a
y
t
r
a
n
s
a
c
t
i
o
n
2
.
0
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
5
3
.
1
S
e
l
e
c
t
r
e
c
o
r
d
4
3
7
.
9
P
r
i
n
t
f
i
l
e
5
3
.
1
P
r
i
n
t
o
b
j
e
c
t
1
5
4
.
3
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
8
1
8
1
.
6
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
9
3
3
1
.
9
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
8
5
5
1
.
7
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
3
6
5
.
7
C
r
e
a
t
e
o
b
j
e
c
t
6
4
4
1
.
3
C
h
a
n
g
e
o
b
j
e
c
t
7
0
4
1
.
4
D
e
l
e
t
e
o
b
j
e
c
t
4
6
2
.
9
R
e
t
r
i
e
v
e
o
b
j
e
c
t
4
,
9
2
3
1
0
.
1
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
5
.
0
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
3
7
.
0
R
e
t
r
i
e
v
e
m
e
s
s
a
g
e
1
1
9
.
2
E
x
e
c
u
t
e
m
e
s
s
a
g
e
9
6
.
1
S
e
n
d
i
n
f
o
r
m
a
t
i
o
n
m
e
s
s
a
g
e
6
5
1
1
.
3
S
e
n
d
e
r
r
o
r
m
e
s
s
a
g
e
2
,
2
1
4
4
.
5
S
e
n
d
c
o
m
p
l
e
t
i
o
n
m
e
s
s
a
g
e
1
8
6
.
3
S
e
n
d
s
t
a
t
u
s
m
e
s
s
a
g
e
9
1
.
1
A
d
d
2
,
4
6
7
5
.
0
S
u
b
t
r
a
c
t
6
6
8
1
.
3
M
u
l
t
i
p
l
y
1
,
0
7
6
2
.
2
D
i
v
i
d
e
5
8
2
1
.
2
D
i
v
i
d
e
w
i
t
h
r
e
m
a
i
n
d
e
r
3
9
.
0
C
o
m
p
u
t
e
e
x
p
r
e
s
s
i
o
n
5
0
.
1
M
o
v
e
2
3
,
0
0
0
4
7
.
5
M
o
v
e
a
l
l
8
4
4
1
.
7
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 51
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

A
-
6
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

2

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
C
o
n
v
e
r
t
v
a
r
i
a
b
l
e
5
1
0
1
.
0
C
o
n
c
a
t
e
n
a
t
e
9
1
1
1
.
8
S
u
b
s
t
r
i
n
g
1
5
0
.
3
Q
u
i
t
8
1
7
1
.
6
E
x
i
t
p
r
o
g
r
a
m
1
,
8
0
0
3
.
7
S
e
t
c
u
r
s
o
r
p
o
s
i
t
i
o
n
8
8
.
1
R
e
t
r
i
e
v
e
c
o
n
d
i
t
i
o
n
n
a
m
e
4
5
3
.
9
T
o
t
a
l
4
8
,
4
0
1
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
52 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 53
AS/400 So ftware P ro ducts and Servi ces
Appendix B: Second RPG Data Model
The following reports have been produced for the
second RPG data model used for backward
compatibility testing using COOL:PE:
File Statistics Report,
Access Path Statistics Report,
Field Statistics Report,
Function Statistics Report, and
Action Diagram Instruction Type Statistics
Report.
The headers and client specific data have been
removed to protect client confidentiality.
Consult the COOL:PE manual supplied on the
documentation CD-ROM for details about how to
interpret these reports.
An Independent Review of COOL:2E Release 7.0
54 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

B
-
1
:

F
i
l
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
l
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
i
l
e
F
i
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
C
o
u
n
t
C
P
T
D
B
F
C
a
p
t
u
r
e
f
i
l
e
9
R
C
D
R
e
c
o
r
d
f
o
r
m
a
t
2
R
E
F
D
B
F
R
e
f
e
r
e
n
c
e
f
i
l
e
2
1
7
S
T
R
S
t
r
u
c
t
u
r
e
8
T
o
t
a
l
2
3
6
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
c
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 55
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

B
-
2
:

A
c
c
e
s
s

P
a
t
h

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
A
c
c
e
s
s
P
a
t
h
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
A
c
c
e
s
s
A
c
c
e
s
s
H
a
v
e
I
n
d
e
x
I
n
d
e
x
I
n
d
e
x
S
t
a
t
i
c
D
y
n
a
m
i
c
A
L
T
C
O
L
p
a
t
h
p
a
t
h
u
n
i
q
u
e
m
a
i
n
t
m
a
i
n
t
m
a
i
n
t
s
e
l
e
c
t
s
e
l
e
c
t
t
a
b
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
k
e
y
s
i
m
m
e
d
r
e
b
u
i
l
d
d
e
l
a
y
/
o
m
i
t
/
o
m
i
t
c
o
u
n
t
P
H
Y
P
h
y
s
i
c
a
l
2
2
7
0
0
0
0
0
0
0
U
P
D
U
p
d
a
t
e
2
2
6
2
2
6
2
2
6
0
0
0
0
0
R
T
V
R
e
t
r
i
e
v
a
l
2
2
6
2
2
6
2
2
6
0
0
0
0
0
R
S
Q
R
e
s
e
q
u
e
n
c
e
1
0
8
2
1
0
7
0
1
5
3
0
S
P
N
S
p
a
n
0
0
0
0
0
0
0
0
Q
R
Y
Q
u
e
r
y
7
0
0
0
0
0
0
0
G
r
a
n
d
t
o
t
a
l
s
7
9
4
4
5
4
5
5
9
0
1
5
3
0
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
56 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

B
-
3
:

F
i
e
l
d

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
e
l
d
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
u
n
c
.
B
a
s
e
F
i
e
l
d
F
i
e
l
d
F
i
e
l
d
%
o
f
f
i
e
l
d
d
o
m
a
i
n
r
e
f
e
r
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
m
o
d
e
l
c
o
u
n
t
c
o
u
n
t
r
a
t
i
o
C
D
E
A
l
p
h
a
m
e
r
i
c
c
o
d
e
v
a
l
u
e
4
9
9
2
0
.
6
0
3
2
0
1
.
5
5
D
T
X
E
x
t
e
n
d
e
d
D
a
t
e
F
i
e
l
d
-
(
C
C
Y
Y
M
M
D
D
i
n
t
e
r
n
a
l
l
y
)
6
8
2
.
8
4
3
2
2
.
6
6
N
A
R
N
a
r
r
a
t
i
v
e
t
e
x
t
1
.
0
1
1
1
.
0
0
N
B
R
P
u
r
e
n
u
m
e
r
i
c
v
a
l
u
e
(
e
g
l
i
n
e
n
u
m
b
e
r
)
.
4
1
7
1
7
.
2
0
1
0
8
3
.
8
6
P
C
T
P
e
r
c
e
n
t
a
g
e
o
r
m
a
r
k
e
t
i
n
d
e
x
.
1
0
.
4
0
6
1
.
6
6
Q
T
Y
Q
u
a
n
t
i
t
y
1
9
8
8
.
1
1
8
2
4
.
7
5
S
T
S
S
t
a
t
u
s
.
2
7
0
1
1
.
1
2
4
8
8
3
.
0
6
T
M
E
T
i
m
e
i
n
H
H
M
M
S
S
f
o
r
m
a
t
.
7
.
2
0
2
3
.
5
0
T
X
T
O
b
j
e
c
t
t
e
x
t
.
4
6
6
1
9
.
2
4
5
7
2
6
.
4
7
V
A
L
M
o
n
e
t
a
r
y
v
a
l
u
e
4
7
0
1
9
.
4
2
0
5
6
8
.
3
9
V
N
M
V
a
l
i
d
S
y
s
t
e
m
n
a
m
e
1
2
.
4
2
3
4
.
0
0
T
o
t
a
l
s
2
,
4
1
8
9
7
6
6
7
3
.
6
2
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 57
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

B
-
4
:

F
u
n
c
t
i
o
n

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
u
n
c
t
i
o
n
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
F
u
n
c
t
i
o
n
t
y
p
e
C
o
u
n
t
f
u
n
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
6
.
7
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
6
.
2
E
d
i
t
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
1
.
0
E
d
i
t
f
i
l
e
1
3
0
6
.
2
D
i
s
p
l
a
y
f
i
l
e
9
2
4
.
4
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
7
4
3
.
5
S
e
l
e
c
t
r
e
c
o
r
d
1
5
1
7
.
2
P
r
i
n
t
f
i
l
e
6
9
3
.
3
P
r
i
n
t
o
b
j
e
c
t
1
3
.
6
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
4
6
2
.
2
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
1
1
6
5
.
5
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
3
0
1
.
4
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
6
7
3
.
2
C
r
e
a
t
e
o
b
j
e
c
t
1
7
4
8
.
3
C
h
a
n
g
e
o
b
j
e
c
t
1
8
8
9
.
0
D
e
l
e
t
e
o
b
j
e
c
t
1
6
1
7
.
7
R
e
t
r
i
e
v
e
o
b
j
e
c
t
3
4
7
1
6
.
6
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
2
3
1
1
1
.
1
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
1
6
9
8
.
1
G
r
a
n
d
t
o
t
a
l
2
,
0
8
1
T
o
t
a
l
i
n
t
e
r
n
a
l
(
s
u
b
r
o
u
t
i
n
e
)
f
u
n
c
t
i
o
n
s
.
:
1
,
4
6
6
T
o
t
a
l
e
x
t
e
r
n
a
l
(
p
r
o
g
r
a
m
)
f
u
n
c
t
i
o
n
s
.
.
:
6
1
5
T
o
t
a
l
s
c
r
e
e
n
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
4
7
0
T
o
t
a
l
r
e
p
o
r
t
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
6
9
T
o
t
a
l
b
a
t
c
h
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
.
:
4
6
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
58 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

B
-
5
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

1

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
3
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
1
.
0
E
d
i
t
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
2
.
0
E
d
i
t
f
i
l
e
3
1
.
1
D
i
s
p
l
a
y
f
i
l
e
9
3
.
5
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
1
5
.
0
S
e
l
e
c
t
r
e
c
o
r
d
2
9
.
1
P
r
i
n
t
f
i
l
e
5
.
0
P
r
i
n
t
o
b
j
e
c
t
1
7
.
1
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
4
8
.
2
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
1
,
3
0
9
7
.
8
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
2
9
9
1
.
7
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
9
0
0
5
.
4
C
r
e
a
t
e
o
b
j
e
c
t
2
5
8
1
.
5
C
h
a
n
g
e
o
b
j
e
c
t
2
6
1
1
.
5
D
e
l
e
t
e
o
b
j
e
c
t
1
6
8
1
.
0
R
e
t
r
i
e
v
e
o
b
j
e
c
t
9
2
5
5
.
5
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
1
,
5
1
8
9
.
1
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
1
,
5
8
2
9
.
4
R
e
t
r
i
e
v
e
m
e
s
s
a
g
e
3
5
3
2
.
1
E
x
e
c
u
t
e
m
e
s
s
a
g
e
1
5
1
.
9
S
e
n
d
i
n
f
o
r
m
a
t
i
o
n
m
e
s
s
a
g
e
1
0
1
.
6
S
e
n
d
e
r
r
o
r
m
e
s
s
a
g
e
3
9
8
2
.
3
S
e
n
d
c
o
m
p
l
e
t
i
o
n
m
e
s
s
a
g
e
9
.
0
S
e
n
d
s
t
a
t
u
s
m
e
s
s
a
g
e
2
.
0
A
d
d
4
3
7
2
.
6
S
u
b
t
r
a
c
t
8
1
.
4
M
u
l
t
i
p
l
y
3
1
9
1
.
9
D
i
v
i
d
e
2
8
.
1
C
o
m
p
u
t
e
e
x
p
r
e
s
s
i
o
n
2
1
.
1
M
o
v
e
6
,
5
5
8
3
9
.
3
M
o
v
e
a
l
l
2
6
6
1
.
5
C
o
n
v
e
r
t
v
a
r
i
a
b
l
e
4
2
.
2
C
o
n
c
a
t
e
n
a
t
e
1
0
.
0
S
u
b
s
t
r
i
n
g
1
.
0
Q
u
i
t
1
6
1
.
9
E
x
i
t
p
r
o
g
r
a
m
2
5
0
1
.
5
R
e
t
r
i
e
v
e
c
o
n
d
i
t
i
o
n
n
a
m
e
1
.
0
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 59
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

B
-
6
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

2

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
T
o
t
a
l
1
6
,
6
6
3
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
60 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 61
AS/400 So ftware P ro ducts and Servi ces
Appendix C: COBOL Data Model
The following reports have been produced for the
COBOL data model used for backward compatibility
testing using COOL:PE:
File Statistics Report,
Access Path Statistics Report,
Field Statistics Report,
Function Statistics Report, and
Action Diagram Instruction Type Statistics
Report.
The headers and client specific data have been
removed to protect client confidentiality.
Consult the COOL:PE manual supplied on the
documentation CD-ROM for details about how to
interpret these reports.
An Independent Review of COOL:2E Release 7.0
62 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

C
-
1
:

F
i
l
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
l
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
i
l
e
F
i
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
C
o
u
n
t
C
P
T
D
B
F
C
a
p
t
u
r
e
f
i
l
e
3
1
4
R
C
D
R
e
c
o
r
d
f
o
r
m
a
t
0
R
E
F
D
B
F
R
e
f
e
r
e
n
c
e
f
i
l
e
1
1
0
S
T
R
S
t
r
u
c
t
u
r
e
8
1
T
o
t
a
l
5
0
5
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
c
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 63
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

C
-
2
:

A
c
c
e
s
s

P
a
t
h

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
A
c
c
e
s
s
P
a
t
h
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
A
c
c
e
s
s
A
c
c
e
s
s
H
a
v
e
I
n
d
e
x
I
n
d
e
x
I
n
d
e
x
S
t
a
t
i
c
D
y
n
a
m
i
c
A
L
T
C
O
L
p
a
t
h
p
a
t
h
u
n
i
q
u
e
m
a
i
n
t
m
a
i
n
t
m
a
i
n
t
s
e
l
e
c
t
s
e
l
e
c
t
t
a
b
l
e
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
k
e
y
s
i
m
m
e
d
r
e
b
u
i
l
d
d
e
l
a
y
/
o
m
i
t
/
o
m
i
t
c
o
u
n
t
P
H
Y
P
h
y
s
i
c
a
l
4
7
9
0
0
0
0
0
0
0
U
P
D
U
p
d
a
t
e
4
7
7
4
7
7
4
7
7
0
0
0
0
0
R
T
V
R
e
t
r
i
e
v
a
l
4
8
2
4
8
2
4
8
2
0
0
0
1
0
R
S
Q
R
e
s
e
q
u
e
n
c
e
4
5
2
8
0
4
4
9
1
2
5
2
6
0
S
P
N
S
p
a
n
4
0
4
0
0
0
0
0
Q
R
Y
Q
u
e
r
y
4
0
2
0
0
0
0
0
G
r
a
n
d
t
o
t
a
l
s
1
,
8
9
8
1
,
0
3
9
1
,
4
1
4
1
2
5
2
7
0
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
64 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

C
-
3
:

F
i
e
l
d

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
i
e
l
d
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
F
u
n
c
.
B
a
s
e
F
i
e
l
d
F
i
e
l
d
F
i
e
l
d
%
o
f
f
i
e
l
d
d
o
m
a
i
n
r
e
f
e
r
t
y
p
e
D
e
s
c
r
i
p
t
i
o
n
c
o
u
n
t
m
o
d
e
l
c
o
u
n
t
c
o
u
n
t
r
a
t
i
o
C
D
E
A
l
p
h
a
m
e
r
i
c
c
o
d
e
v
a
l
u
e
1
,
3
3
7
1
8
.
4
1
4
4
6
2
.
9
9
D
T
E
D
a
t
e
i
n
s
y
s
t
e
m
d
a
t
e
f
o
r
m
a
t
-
(
Y
Y
M
M
D
D
i
n
t
e
r
n
a
l
l
y
)
1
7
6
2
.
4
1
1
4
3
1
.
2
3
N
A
R
N
a
r
r
a
t
i
v
e
t
e
x
t
6
7
.
9
0
4
6
1
.
4
5
N
B
R
P
u
r
e
n
u
m
e
r
i
c
v
a
l
u
e
(
e
g
l
i
n
e
n
u
m
b
e
r
)
.
1
,
8
4
9
2
5
.
4
1
0
7
6
5
2
.
4
1
P
C
T
P
e
r
c
e
n
t
a
g
e
o
r
m
a
r
k
e
t
i
n
d
e
x
.
6
.
0
3
6
1
.
0
0
P
R
C
P
r
i
c
e
o
r
t
a
r
r
i
f
1
7
5
2
.
4
1
1
8
0
2
.
1
8
Q
T
Y
Q
u
a
n
t
i
t
y
1
,
0
3
8
1
4
.
3
1
0
5
2
8
8
3
.
6
0
S
T
S
S
t
a
t
u
s
.
1
,
2
1
4
1
6
.
7
3
9
2
8
0
0
1
.
5
1
T
M
E
T
i
m
e
i
n
H
H
M
M
S
S
f
o
r
m
a
t
.
3
1
.
4
3
2
8
1
.
1
0
T
X
T
O
b
j
e
c
t
t
e
x
t
.
1
,
0
2
7
1
4
.
1
3
7
8
6
0
0
1
.
7
1
V
A
L
M
o
n
e
t
a
r
y
v
a
l
u
e
2
9
4
4
.
0
1
1
0
1
7
7
1
.
6
6
V
N
M
V
a
l
i
d
S
y
s
t
e
m
n
a
m
e
4
1
.
5
6
1
3
3
.
1
5
T
o
t
a
l
s
7
,
2
5
5
1
,
0
2
0
3
,
3
9
2
2
.
1
3
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 65
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

C
-
4
:

F
u
n
c
t
i
o
n

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t
F
u
n
c
t
i
o
n
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
F
u
n
c
t
i
o
n
t
y
p
e
C
o
u
n
t
f
u
n
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
6
8
.
8
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
3
0
.
3
D
i
s
p
l
a
y
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
6
.
0
E
d
i
t
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
2
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
2
.
0
E
d
i
t
f
i
l
e
6
3
.
8
D
i
s
p
l
a
y
f
i
l
e
5
8
4
7
.
5
E
d
i
t
t
r
a
n
s
a
c
t
i
o
n
3
.
0
D
i
s
p
l
a
y
t
r
a
n
s
a
c
t
i
o
n
2
.
0
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
6
5
2
8
.
4
S
e
l
e
c
t
r
e
c
o
r
d
8
7
1
.
1
P
r
i
n
t
f
i
l
e
2
6
7
3
.
4
P
r
i
n
t
o
b
j
e
c
t
1
6
7
2
.
1
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
3
9
9
5
.
1
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
2
0
6
2
.
6
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
3
0
9
3
.
9
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
5
9
5
7
.
6
C
r
e
a
t
e
o
b
j
e
c
t
4
6
5
6
.
0
C
h
a
n
g
e
o
b
j
e
c
t
5
4
0
6
.
9
D
e
l
e
t
e
o
b
j
e
c
t
4
1
0
5
.
3
R
e
t
r
i
e
v
e
o
b
j
e
c
t
2
,
8
2
5
3
6
.
5
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
2
.
0
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
5
0
.
6
C
o
u
n
t
f
u
n
c
t
i
o
n
f
i
e
l
d
1
.
0
G
r
a
n
d
t
o
t
a
l
7
,
7
3
5
T
o
t
a
l
i
n
t
e
r
n
a
l
(
s
u
b
r
o
u
t
i
n
e
)
f
u
n
c
t
i
o
n
s
.
:
5
,
2
6
1
T
o
t
a
l
e
x
t
e
r
n
a
l
(
p
r
o
g
r
a
m
)
f
u
n
c
t
i
o
n
s
.
.
:
2
,
4
7
4
T
o
t
a
l
s
c
r
e
e
n
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
1
,
4
9
9
T
o
t
a
l
r
e
p
o
r
t
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
:
2
6
7
T
o
t
a
l
b
a
t
c
h
p
r
o
g
r
a
m
f
u
n
c
t
i
o
n
s
.
.
.
:
3
9
9
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
66 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
F
i
g
u
r
e

C
-
5
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

1

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
E
d
i
t
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
9
3
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
1
s
c
r
e
e
n
)
4
4
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
2
s
c
r
e
e
n
s
)
2
1
.
0
E
d
i
t
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
1
.
0
D
i
s
p
l
a
y
r
e
c
o
r
d
(
3
s
c
r
e
e
n
s
)
6
.
0
E
d
i
t
f
i
l
e
4
0
.
0
D
i
s
p
l
a
y
f
i
l
e
8
4
5
.
6
E
d
i
t
t
r
a
n
s
a
c
t
i
o
n
3
.
0
D
i
s
p
l
a
y
t
r
a
n
s
a
c
t
i
o
n
4
.
0
P
r
o
m
p
t
&
V
a
l
i
d
a
t
e
8
1
6
.
6
S
e
l
e
c
t
r
e
c
o
r
d
2
7
6
.
2
P
r
i
n
t
f
i
l
e
7
9
.
0
P
r
i
n
t
o
b
j
e
c
t
2
5
6
.
2
E
x
e
c
u
t
e
e
x
t
e
r
n
a
l
f
u
n
c
t
i
o
n
8
2
0
.
6
E
x
e
c
u
t
e
i
n
t
e
r
n
a
l
f
u
n
c
t
i
o
n
3
,
8
8
8
3
.
1
E
x
e
c
u
t
e
u
s
e
r
p
r
o
g
r
a
m
5
2
6
.
4
E
x
e
c
u
t
e
u
s
e
r
s
o
u
r
c
e
5
,
5
9
6
4
.
5
C
r
e
a
t
e
o
b
j
e
c
t
2
,
2
1
3
1
.
8
C
h
a
n
g
e
o
b
j
e
c
t
1
,
8
4
9
1
.
5
D
e
l
e
t
e
o
b
j
e
c
t
1
,
2
0
5
.
9
R
e
t
r
i
e
v
e
o
b
j
e
c
t
9
,
7
5
9
7
.
9
D
e
r
i
v
e
d
f
u
n
c
t
i
o
n
f
i
e
l
d
4
.
0
S
u
m
f
u
n
c
t
i
o
n
f
i
e
l
d
2
2
7
.
1
C
o
u
n
t
f
u
n
c
t
i
o
n
f
i
e
l
d
1
.
0
R
e
t
r
i
e
v
e
m
e
s
s
a
g
e
1
,
0
0
9
.
8
E
x
e
c
u
t
e
m
e
s
s
a
g
e
7
8
.
0
S
e
n
d
i
n
f
o
r
m
a
t
i
o
n
m
e
s
s
a
g
e
6
4
0
.
5
S
e
n
d
e
r
r
o
r
m
e
s
s
a
g
e
7
,
2
3
5
5
.
9
S
e
n
d
c
o
m
p
l
e
t
i
o
n
m
e
s
s
a
g
e
7
4
.
0
S
e
n
d
s
t
a
t
u
s
m
e
s
s
a
g
e
3
3
5
.
2
A
d
d
6
,
5
2
3
5
.
3
S
u
b
t
r
a
c
t
8
7
2
.
7
M
u
l
t
i
p
l
y
7
9
2
.
6
D
i
v
i
d
e
6
8
0
.
5
D
i
v
i
d
e
w
i
t
h
r
e
m
a
i
n
d
e
r
1
5
.
0
C
o
m
p
u
t
e
e
x
p
r
e
s
s
i
o
n
4
9
6
.
4
M
o
v
e
5
4
,
1
9
5
4
4
.
2
M
o
v
e
a
l
l
1
,
2
6
1
1
.
0
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd 67
AS/400 So ftware P ro ducts and Servi ces
F
i
g
u
r
e

C
-
6
:

A
c
t
i
o
n

D
i
a
g
r
a
m

I
n
s
t
r
u
c
t
i
o
n

T
y
p
e

S
t
a
t
i
s
t
i
c
s

R
e
p
o
r
t

(
P
a
g
e

2

o
f

2
)
A
c
t
i
o
n
D
i
a
g
r
a
m
I
n
s
t
r
u
c
t
i
o
n
T
y
p
e
S
t
a
t
i
s
t
i
c
s
R
e
p
o
r
t
%
o
f
I
n
s
t
r
u
c
t
i
o
n
t
y
p
e
C
o
u
n
t
a
c
t
i
o
n
s
C
o
n
v
e
r
t
v
a
r
i
a
b
l
e
2
,
9
9
8
2
.
4
C
o
n
c
a
t
e
n
a
t
e
1
,
4
7
8
1
.
2
S
u
b
s
t
r
i
n
g
4
8
4
.
3
Q
u
i
t
8
,
0
6
2
6
.
5
E
x
i
t
p
r
o
g
r
a
m
3
,
7
0
9
3
.
0
S
e
t
c
u
r
s
o
r
p
o
s
i
t
i
o
n
2
9
.
0
R
e
t
r
i
e
v
e
c
o
n
d
i
t
i
o
n
n
a
m
e
1
,
8
9
1
1
.
5
C
o
m
m
i
t
5
2
5
.
4
R
o
l
l
b
a
c
k
5
8
6
.
4
T
o
t
a
l
1
2
2
,
5
3
9
*
*
*
E
N
D
O
F
R
E
P
O
R
T
*
*
*
(
C
)
1
9
9
8
S
t
e
r
l
i
n
g
S
o
f
t
w
a
r
e
.
An Independent Review of COOL:2E Release 7.0
68 Copyright HawkBridge Pty Ltd
AS/400 Sof twa re P ro ducts and Se rvi ces
An Independent Review of COOL:2E Release 7.0
Copyright HawkBridge Pty Ltd
AS/400 So ftware P ro ducts and Servi ces
HawkBridge Pty Ltd
3 Highett Road
Hampton, VIC 3188
Australia
+61 3 9598 5829
http://www.HawkBridge.com
[email protected]