An Independent Review of COOL2E Release 7.0 Letter 2

A S / 40 0 S o ftw a re P ro d u cts a n d S e rvi ce s
An Independent Review of An Independent Review of COOL:2E Release 7.0 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 Darryl_Millington@HawkBridge.com
Copyright HawkBridge Pty Ltd
An Independent Review of COOL:2E Release 7.0

A S / 40 0 S o ftw a re P ro d u cts a n d S e rvice s
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.
ii

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
iii

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.
iv

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 rebadge 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 Jasmineii. The next release after Release 7.0 - as yet undesignated - is now under way and one has to wonder whether ebusiness and Jasmineii 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

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.

Release 7.0 Enhancements
The Statement of Direction1 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 ebusiness 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 Ltd2, provides the ability to graphically enable AS/400 applications and Domino Connectors, from Triangle Software Products Ltd3, 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
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.
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/.

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.
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.
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.

Default Activation Group
OPM PGM
ILE PGM
OPM PGM
ILE MOD
Figure 1: Strategy 1 Using Default Activation Group
IBM offers three program creation strategies4 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
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)
IBM, 1998. AS/400 Advanced Series ILE RPG for AS/400 Programmers Guide, Version 4, Edition 2. Document number SC092507-01. Chapter 3, Program Creation Strategies.
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


OPM PGM
MY Activation Group
Default Activation Group OPM PGM
ILE PGM
ILE MOD
Figure 2: Strategy 2a Using Named Activation Group 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 paths5, 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.
IBM, 1998. AS/400 Advanced Series ILE RPG for AS/400 Programmers Guide, Version 4, Edition 2. Document number SC092507-01. Chapter 3, Program Creation Strategies. Section 1.3.4, A Strategy to Avoid.

OPM PGM
ILE PGM
OPM PGM
ILE MOD
Figure 3: Strategy 2b Using Callers Activation Group Default Activation Group

OPM PGM
*NEW Activation Group

ILE PGM
Default Activation Group OPM PGM
ILE MOD
Figure 4: Strategy 2c Using New Activation Group 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)
will not free static storage allocated by the ILE program6. 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
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
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.

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.

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.
Default Activation Group Wrk Clients :RPG (DSPFIL)
Edt Client :RPG (EDTRCD)
Figure 5: RPG III Work with Clients functions
*CALLER Activation Group Wrk Clients :RP4(*C) (DSPFIL)
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
Edt Client :RP4(*C) (EDTRCD)
Figure 6: RPG IV ILE Work with Clients functions 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

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.
Wrk Clients :RP4(*D) (EXCEXTFUN)
Wrk Clients :RP4(*C) (EXCEXTFUN)
Wrk Clients :RP4(MY) (EXCEXTFUN)
Wrk Clients :R4M (DSPFIL)
Edt Client :R4M (EDTRCD)
Figure 7: Modular Work with Clients functions
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
.-| * 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 8: EXCEXTFUN wrapper function action diagram
10

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
Wrk Clients :R4M (DSPFIL)
Crt Client :R4M (EXCEXTFUN)
Chg Client :R4M (EXCEXTFUN)
Dlt Client :R4M (EXCEXTFUN)
Create Client (CRTOBJ)
Change Client (CHGOBJ)
Delete Client (DLTOBJ)
Figure 9: Edit Client function decomposition
11

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
12

*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.
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 Order Number Product Code Usage I Role Flag error
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 10: Parameter details for passed as KEY
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 11: RPG III 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
Figure 12: RPG IV ILE Parameter Declaration
13

FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 0011.70 01 P1PARM. 0011.80 * Product Code 0011.90 03 P1AUCD PIC X(6).
Figure 13: COBOL Parameter Declaration

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).
Figure 14: COBOL Parameter Declaration with Neither Usage 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.
14

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 different7. 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.
Conditional Compilation Directives The RPG IV language allows you to conditionally include or exclude sections of source code from the compile8. 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 recompiled 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.
/IF NOT DEFINED(MYCOPYMBR) /DEFINE MYCOPYMBR ... Source to be included once only /ENDIF
Figure 15: Example Conditional Directive
IBM, 1998. AS/400 Advanced Series ILE COBOL for AS/400 Programmers Guide, Version 4, Edition 1. Document number SC092540-00. Chapter 1, Introduction. Section 1.1.2, ILE COBOL for AS/400.
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.
15

| | | | | | | | |
> 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
Figure 16: Example use of Conditional Compilation Directives in Action Diagram
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 take9. Only the binding process time is increased. The resultant ILE program will be the same irrespective of the size of the binding
9
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.
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.
16

FMT ** 0000.10 0000.20 0000.30 0000.40 0000.50 0000.60
...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. H/TITLE RPG IV ILE Module Execute external functio Y* ADDBNDDIRE BNDDIR(YBNDDIR) OBJ((RPGIVILE *MODULE)) * Z* CRTRPGMOD Z* DBGVIEW(*SOURCE) CVTOPT(*DATETIME) H* SYNOPSIS :
Figure 17: Generated RPG IV ILE Module header 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 keywords10. 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.
17

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.
Options: Execution location . . Generate as subroutine Share subroutine . . . Duplicate parameters .
. . . .
. . . .
: : : :
W Y Y Y
( ( ( (
W-Where_found, S-Server ) Y-Yes, N-No ) M-MDLVAL, Y-Yes, N-No ) 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 >> . * >>>
Figure 18: EXCINTFUN with Duplicate Parameters
18

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).
Figure 19: EXCINTFUN COBOL 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 20: EXCINTFUN RPG III 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 21: EXCINTFUN RPG IV Local Parameter Declarations 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.
19

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 22: New EXCINTFUN COBOL 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 23: New EXCINTFUN RPG III 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
Figure 24: New EXCINTFUN RPG IV Local Parameter Declarations 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
20

from WRK context and has the possibility of introducing errors into your applications11. 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.
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 manuals12. 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.
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 ebusiness 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.
21

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.
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.
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
22

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:
23

*Pgm *STATUS *Pgm Previous *STATUS *Pgm *ROUTINE *Pgm *PARMS *Pgm Exception msgid *Pgm Program library *Pgm Exception data *Pgm File in error *Pgm Last file status
STS PST RVN PRM MSI PLB MSD EFL EFS
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.
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
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
24

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.
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 --
Figure 25: Chg Client:R4M EXCEXTFUN wrapper RPG IV ILE Module
25

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
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 --
Figure 26: Change Client CHGOBJ function
26

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.
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
Figure 27: Current RPG IV *ENTRY Parameters
27

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
Figure 28: New RPG IV *ENTRY Parameters 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
28

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 50character 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.
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.
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
29

30

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.
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 regenerated. 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.
Submit Job Override Option

Prior to Release 7.0, the submit job override option for a call to an EXCEXTFUN, EXCUSRPGM or PRTFIL
Parameters: Fmt Field name KEY Order Number Product Code
Usg Role File name I RST Order Product
Retrieval index
Figure 29: SELRCD Function Partial Key Parameters
31

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.
32

Backward Compatibility Test
Moving to a new release of COOL:2E is not as straight forward as the installation manual13 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.214. This will cover moving from earlier releases to Release 6.2 PTF 62010.
Computer Associates, 2000. Installing COOL:2E Products 7.0. HawkBridge, 1999. An Independent Review of COOL:2E Release 6.2.
14 13
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.
33

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 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.
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.
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:
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.
34

YCRTGENOBJ OBJLIB(*NEWGEN)
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 *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 regeneration 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, 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.
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
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
35

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 regenerate 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 regenerated. 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.
36

RPG III MOVEL with P Operation Extender The use of the P operation extender on the MOVEL operation code15 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 inputoutput 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.
37

38

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 Jasmineii. Interesting to note that the future direction of all the COOL products is e-business centered and in particular they were to integrate through Jasmineii.
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.
39

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 ebusiness 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 Ltd16. The second stage in the e-business plan for COOL:2E is to extend COOL:2E to the web via Jasmineii. The third and final stage is to generate HTML for Jasmineii. 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
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. Jasmineii Bridge to AS/400 Jasmineii will allow you to create e-business applications, re-use investments on other platforms, and leverage a rich integration environment17. It has not been disclosed what will be provided to Jasmineii for this stage and when it will be delivered. It looks as if it will only benefit those COOL:2E customers that purchase Jasmineii as it will only be accessible via Jasmineii providers. Jasmineii 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 Jasmineii 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 Jasmineii 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 Jasmineii 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. Jasmineii 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 Jasmineii users will further alienate Computer Associates from their existing COOL:2E customer base.
Look Software Pty Ltd, http://www.looksoftware.com/.
17
Computer Associates, July 2000. Roadmap for COOL Products.
40

HTML Generation for Jasmineii 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 Jasmineii. Which means you could possibly use this feature to build web applications for other third party products.
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.
ILE Generator Direction

More than half of those attending the COOL:2E Developer Round Table during E-Strategies at CAWorld 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 ebusiness 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
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 ebusiness 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.
41

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.
42

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.
43

44

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.
45
46
File Statistics Report File Count 103 0 252 39 Total 394 (c) 1998 Sterling Software.
File type CPT RCD REF STR
Description DBF Capture file Record format DBF Reference file Structure
*** END OF REPORT ***
Figure A-1: File Statistics Report
Access Path Statistics Report
Access path type PHY UPD RTV RSQ SPN QRY Grand totals 1,489 829 1,090 0 16 58 12 0

Access path count 383 386 412 294 14 0 Have unique keys 0 386 412 31 0 0 Index maint immed 0 386 412 281 11 0 Index maint rebuild 0 0 0 0 0 0 Index maint delay 0 0 0 13 3 0 Static select /omit 0 0 16 34 8 0 Dynamic select /omit 0 0 2 9 1 0 ALTCOL table count 0 0 0 0 0 0 (C) 1998 Sterling Software.
Description Physical Update Retrieval Resequence Span Query
Figure A-2: Access Path Statistics Report
47
48
Field Statistics Report Field % of count model 192 3.8 640 12.7 30 .5 133 2.6 98 1.9 813 16.2 140 2.7 12 .2 49 .9 1,089 21.7 3 .0 19 .3 1,010 20.1 759 15.1 28 .5 5,015 387 2,927 1.71 field domain refer count count ratio 56 1 192.00 2 370 1.72 0 28 1.07 0 85 1.56 26 98 1.00 1 397 2.04 0 104 1.34 1 9 1.33 0 28 1.75 128 819 1.32 0 3 1.00 1 13 1.46 127 621 1.62 38 340 2.23 7 11 2.54 Totals (C) 1998 Sterling Software.
Func. Field type BVL CDE DT# DTE NAR NBR PCT PRC QTY STS TM# TME TXT VAL VNM
Base
Field
Description Budget Value Alphameric code value Date in *ISO format (YYYY-MM-DD internally) Date in system date format - (YYMMDD internally) Narrative text Pure numeric value (eg line number). Percentage or market index. Price or tarrif Quantity Status. Time in *ISO format (HH.MM.SS internally) Time in HHMMSS format. Object text. Monetary value Valid System name
Figure A-3: Field Statistics Report

Function Statistics Report Count 69 122 2 1 15 13 186 248 4 1 95 146 164 106 254 179 293 100 350 441 339 1,087 4 11 4,230 . . . . . : : : : : 2,617 1,613 902 164 254 % of functions 1.6 2.8 .0 .0 .3 .3 4.3 5.8 .0 .0 2.2 3.4 3.8 2.5 6.0 4.2 6.9 2.3 8.2 10.4 8.0 25.6 .0 .2 (C) 1998 Sterling Software.
Function type Edit record(1 screen) Display record(1 screen) Edit record(2 screens) Display record(2 screens) Edit record(3 screens) Display record(3 screens) Edit file Display file Edit transaction Display transaction Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field
Grand total
Total internal (subroutine) functions Total external (program) functions . Total screen program functions . Total report program functions . Total batch program functions . .
Figure A-4: Function Statistics Report
49
50
Action Diagram Instruction Type Statistics Report Count 141 167 3 6 36 38 179 566 8 2 53 437 53 154 818 933 855 365 644 704 462 4,923 5 37 119 96 651 2,214 186 91 2,467 668 1,076 582 39 50 23,000 844 % of actions .2 .3 .0 .0 .0 .0 .3 1.1 .0 .0 .1 .9 .1 .3 1.6 1.9 1.7 .7 1.3 1.4 .9 10.1 .0 .0 .2 .1 1.3 4.5 .3 .1 5.0 1.3 2.2 1.2 .0 .1 47.5 1.7
Instruction type Edit record(1 screen) Display record(1 screen) Edit record(2 screens) Display record(2 screens) Edit record(3 screens) Display record(3 screens) Edit file Display file Edit transaction Display transaction Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field Retrieve message Execute message Send information message Send error message Send completion message Send status message Add Subtract Multiply Divide Divide with remainder Compute expression Move Move all
Figure A-5: Action Diagram Instruction Type Statistics Report (Page 1 of 2)
Action Diagram Instruction Type Statistics Report
Instruction type Convert variable Concatenate Substring Quit Exit program Set cursor position Retrieve condition name Total 48,401

Count 510 911 150 817 1,800 88 453 % of actions 1.0 1.8 .3 1.6 3.7 .1 .9 (C) 1998 Sterling Software.
Figure A-6: Action Diagram Instruction Type Statistics Report (Page 2 of 2)
51

52

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.
53
54
Figure B-1: File Statistics Report
Access path type PHY UPD RTV RSQ SPN QRY Grand totals 794 454 559 0 1 5 3 0

Figure B-2: Access Path Statistics Report
55
56
Field Statistics Report Field % of count model 499 20.6 68 2.8 1 .0 417 17.2 10 .4 198 8.1 270 11.1 7 .2 466 19.2 470 19.4 12 .4 Totals 2,418 97 667 3.62 Func. Base field domain count count 0 320 4 3 1 1 0 108 0 6 1 8 24 88 0 2 45 72 20 56 2 3 Field refer ratio 1.55 22.66 1.00 3.86 1.66 24.75 3.06 3.50 6.47 8.39 4.00 (C) 1998 Sterling Software.
Field type CDE DTX NAR NBR PCT QTY STS TME TXT VAL VNM
Description Alphameric code value Extended Date Field - (CCYYMMDD internally) Narrative text Pure numeric value (eg line number). Percentage or market index. Quantity Status. Time in HHMMSS format. Object text. Monetary value Valid System name
Figure B-3: Field Statistics Report

Function Statistics Report Count 16 6 1 130 92 74 151 69 13 46 116 30 67 174 188 161 347 231 169 2,081 . . . . . : : : : : 1,466 615 470 69 46 % of functions .7 .2 .0 6.2 4.4 3.5 7.2 3.3 .6 2.2 5.5 1.4 3.2 8.3 9.0 7.7 16.6 11.1 8.1 (C) 1998 Sterling Software.
Function type Edit record(1 screen) Display record(1 screen) Edit record(2 screens) Edit file Display file Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field
Grand total
Figure B-4: Function Statistics Report
57
58
Count 13 1 2 31 93 15 29 5 17 48 1,309 299 900 258 261 168 925 1,518 1,582 353 151 101 398 9 2 437 81 319 28 21 6,558 266 42 10 1 161 250 1 % of actions .0 .0 .0 .1 .5 .0 .1 .0 .1 .2 7.8 1.7 5.4 1.5 1.5 1.0 5.5 9.1 9.4 2.1 .9 .6 2.3 .0 .0 2.6 .4 1.9 .1 .1 39.3 1.5 .2 .0 .0 .9 1.5 .0
Instruction type Edit record(1 screen) Display record(1 screen) Edit record(2 screens) Edit file Display file Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field Retrieve message Execute message Send information message Send error message Send completion message Send status message Add Subtract Multiply Divide Compute expression Move Move all Convert variable Concatenate Substring Quit Exit program Retrieve condition name
Figure B-5: Action Diagram Instruction Type Statistics Report (Page 1 of 2)
Instruction type Total 16,663
Count
% of actions
*** END OF REPORT *** (C) 1998 Sterling Software.
Figure B-6: Action Diagram Instruction Type Statistics Report (Page 2 of 2)
59

60

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.
61
62
Figure C-1: File Statistics Report
Access path type PHY UPD RTV RSQ SPN QRY Grand totals 1,898 1,039 1,414 1 2 52 7 0

Figure C-2: Access Path Statistics Report
63
64
Field Statistics Report Field % of count model 1,337 18.4 176 2.4 67 .9 1,849 25.4 6 .0 175 2.4 1,038 14.3 1,214 16.7 31 .4 1,027 14.1 294 4.0 41 .5 7,255 1,020 3,392 2.13 Func. Base field domain count count 1 446 1 143 0 46 10 765 3 6 11 80 105 288 392 800 3 28 378 600 110 177 6 13 Field refer ratio 2.99 1.23 1.45 2.41 1.00 2.18 3.60 1.51 1.10 1.71 1.66 3.15 Totals (C) 1998 Sterling Software.
Field type CDE DTE NAR NBR PCT PRC QTY STS TME TXT VAL VNM
Description Alphameric code value Date in system date format - (YYMMDD internally) Narrative text Pure numeric value (eg line number). Percentage or market index. Price or tarrif Quantity Status. Time in HHMMSS format. Object text. Monetary value Valid System name
Figure C-3: Field Statistics Report

Function Statistics Report Count 68 30 6 2 2 63 584 3 2 652 87 267 167 399 206 309 595 465 540 410 2,825 2 50 1 7,735 . . . . . : : : : : 5,261 2,474 1,499 267 399 % of functions .8 .3 .0 .0 .0 .8 7.5 .0 .0 8.4 1.1 3.4 2.1 5.1 2.6 3.9 7.6 6.0 6.9 5.3 36.5 .0 .6 .0 (C) 1998 Sterling Software.
Function type Edit record(1 screen) Display record(1 screen) Display record(2 screens) Edit record(3 screens) Display record(3 screens) Edit file Display file Edit transaction Display transaction Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field Count function field
Grand total
Figure C-4: Function Statistics Report
65
66
Count 93 44 21 1 6 40 845 3 4 816 276 79 256 820 3,888 526 5,596 2,213 1,849 1,205 9,759 4 227 1 1,009 78 640 7,235 74 335 6,523 872 792 680 15 496 54,195 1,261 % of actions .0 .0 .0 .0 .0 .0 .6 .0 .0 .6 .2 .0 .2 .6 3.1 .4 4.5 1.8 1.5 .9 7.9 .0 .1 .0 .8 .0 .5 5.9 .0 .2 5.3 .7 .6 .5 .0 .4 44.2 1.0
Instruction type Edit record(1 screen) Display record(1 screen) Display record(2 screens) Edit record(3 screens) Display record(3 screens) Edit file Display file Edit transaction Display transaction Prompt & Validate Select record Print file Print object Execute external function Execute internal function Execute user program Execute user source Create object Change object Delete object Retrieve object Derived function field Sum function field Count function field Retrieve message Execute message Send information message Send error message Send completion message Send status message Add Subtract Multiply Divide Divide with remainder Compute expression Move Move all
Figure C-5: Action Diagram Instruction Type Statistics Report (Page 1 of 2)

Count 2,998 1,478 484 8,062 3,709 29 1,891 525 586 122,539 % of actions 2.4 1.2 .3 6.5 3.0 .0 1.5 .4 .4 Total (C) 1998 Sterling Software.
Instruction type Convert variable Concatenate Substring Quit Exit program Set cursor position Retrieve condition name Commit Rollback
Figure C-6: Action Diagram Instruction Type Statistics Report (Page 2 of 2)
67

68

HawkBridge Pty Ltd 3 Highett Road Hampton, VIC 3188 Australia +61 3 9598 5829 http://www.HawkBridge.com Darryl_Millington@HawkBridge.com

An Independent Review of COOL2E Release 7.0 Letter 2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Independent Review of COOL2E Release 7.0 Letter 2

Uploaded by

Copyright:

Available Formats

A S / 40 0 S o ftw a re P ro d u cts a n d S e rvi ce s

Copyright HawkBridge Pty Ltd