An Independent Review of COOL2E Release 7.0 Letter 2

Copyright � HawkBridge Pty Ltd

A S / 4 0 0 S o ftw a re P ro d u c ts a n d S e rvi c e s

An Independent Revi

Se

Haw3 H

Ham

+61

http://ww

Darryl_Millin

An Indepe

COOL:2E

ndent Reviewof

ew of COOL:2E Release 7.0

ptember 2000

kBridge Pty Ltdighett Road

pton, VIC 3188Australia

3 9598 5829

w.HawkBridge.com

[email protected]

Release 7.0

http://www.hawkbridge.com/

mailto:[email protected]

Copyright (C) HawkBridge Pty Ltd

This document is copyright protected. If you are not the person or organisation that downloaded this document, then you are breaching the copyright of this document. You can request an authorised version from the following URL http:\\www.HawkBridge.com.

Darryl Millington

This document was designed to be distributed electronically and then printed on a laser printer on an as-needed basis. For this reason, the fonts and layout of this document have been chosen for optimal printing rather than for optimal viewing on-screen. To review this document on-screen, however, simply increase the magnification using the magnification box at the bottom of the window. For the best results when viewing dialog boxes on-screen, increase the magnification to 200%.

An Independent Review of COOL:2E Release 7.0

ii Copyright � HawkBridge Pty Ltd

A S / 4 0 0 S o f tw a re P ro d u c ts a n d S e rvic e 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 andRachel Palmer, both Analyst/Programmers specialising in COOL:2E (formerly Synon/2), RPG/400 and COBOL/400development in the AS/400 field. The company is based in Melbourne where the office is run from their family home in aseparate 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 usingCOOL:2E. Since 1997, the emphasis has changed from providing on site resources to servicing clients remotely. Thisarrangement enables the company to offer a very flexible service ranging from full time development and support to once offconsulting work.

About the Author

Darryl Millington is a software engineer and consultant specialising in the AS/400. He has been providing COOL:2E (formerlySynon/2), RPG/400 and COBOL/400 systems development and support for over 11 years. His extensive technical experienceincludes all aspects of COOL:2E programming, data modelling and environment support. He has 13 years experience inInformation 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 TaubertSystems in Sydney.

He has worked for many major companies using COOL:2E throughout Australia including, CSA, IBM, ANZ Bank, ArmstrongJones, APPM, MGICA, South Pacific Tyres and AWH. He has worked in New Zealand, America and England on variousCOOL: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 becomewell known and is regularly in touch with COOL:2E Development about new product concepts. Darryl is also involved in thealpha 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 Australianconferences in the past.

Darryl has been providing education to COOL:2E users since the late 1980s as part of his contractual engagements. Morerecently, he has been running COOL:2E development courses in Melbourne and Perth for Sterling Education and ComputerAssociates.


Copyright � HawkBridge Pty Ltd iii


Table of Contents

An Independent Review of COOL:2E Release 7.0........................................................................ iAbout HawkBridge Pty Ltd............................................................................................................................................. iiAbout the Author ............................................................................................................................................................ iiTable of Contents...........................................................................................................................................................iii

Introduction .................................................................................................................................... 1

Release 7.0 Enhancements ............................................................................................................. 3RPG IV ILE Generator.................................................................................................................................................... 4Duplicate Parameter Contexts ....................................................................................................................................... 18Componentisation and Logic Extraction ....................................................................................................................... 21Batch Processing Enhancements ................................................................................................................................... 22New JOB Context Fields............................................................................................................................................... 23Enhanced Object Locking ............................................................................................................................................. 28Softcopy Manuals ......................................................................................................................................................... 29

Release 7.0 Significant Fixes ........................................................................................................ 31Submit Job Override Option ......................................................................................................................................... 31SELRCD Partial Key Parameters.................................................................................................................................. 31Long Condition Values ................................................................................................................................................. 32

Backward Compatibility Test...................................................................................................... 33Test Objective ............................................................................................................................................................... 33Test Data Models .......................................................................................................................................................... 33Test Plan ....................................................................................................................................................................... 34Test Results................................................................................................................................................................... 35Conclusion .................................................................................................................................................................... 37

Future Direction............................................................................................................................ 39E-Business Direction..................................................................................................................................................... 40ILE Generator Direction ............................................................................................................................................... 41New 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


iv Copyright � HawkBridge Pty Ltd


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, andinterpretation are not guaranteed. This report should not be relied on as a sole source of information or opinion onthe computing industry. HawkBridge Pty Ltd does not assume responsibility for typographical errors, and theopinions expressed in this report are subject to change without advance notice.


Copyright � HawkBridge Pty Ltd 1


Introduction

COOL:2E (formerly Synon/2e) has been throughsome very turbulent times in recent years with theproduct changing hands of ownership twice in just asmany years. In 1998 Synon, a privately heldcompany, was bought by Sterling Software, apublicly held company in what was referred to bySterling Software and Synon as a merger. The re-badge of the product from Synon/2e, a well knownand respected product name in the AS/400community, to COOL:2E provided little re-assuranceof Sterling Softwares commitment to the product.

Just as Sterling Software were coming to grips withCOOL:2E, demonstrating a clear and positivedirection in the development of the product, theywere bought by Computer Associates, yet anotherpublicly held company, earlier this year. How longwill it be before we see Computer Associatesdemonstrate a clear and positive direction indeveloping the product?

Publicly held companies differ from privately heldones in the way in which they market their productsand services. Under Synon management, themarketing documents released under the guise ofstatements of direction painted the picture clearly forusers of the tool of the technical enhancements.Whereas, under Sterling Software and ComputerAssociates the statements of direction and productroadmaps released by the respective marketingdepartments offer very little, if any idea of futuretechnical developments in the product.

Sterling Softwares statement of direction onlymentioned the move to e-business enable all of theirproducts. Release 7.0 of COOL:2E is the result ofthat statement of direction and the amount ofdevelopment effort applied to enable e-business is nowhere near that applied to other enhancements, suchas the RPG IV ILE generator.

Computer Associates recently released its productroadmaps and the most over used words in thedocument are e-business and Jasmineii. The nextrelease after Release 7.0 - as yet undesignated - isnow under way and one has to wonder whether e-business and Jasmineii will be the majorenhancements or not.

At a recent IBM user conference in Australia,Malcolm Haines, from IBM marketing, announced achange in marketing policy for the AS/400. Theywhere no longer going to market the technicalcommunity as they have in the past, but shift to focustheir attention on winning the hearts and minds of thefinancial community. Publicly held companies seewinning over the financial community as the way toincrease market awareness and popularity for theirproducts along with reassuring the shareholders ofthe companies viability as a profitable investment.

Marketing documents from publicly held companieswould no longer have any meaning in the truetechnical direction that product development takesand we can only determine that direction once theproduct is released and we get to use it. Independentreviews, such as this one, become ever so moreimportant when the product is owned by a publiclyheld company.

Release 5.0 of COOL:2E introduced model objectlists and the new “work with” user interface. Howmany COOL:2E users still use what are consideredthe traditional user interfaces to the tool? Release 7.0has several enhancements that, unless you are awareof them and understand how best to use them, willremain under utilised by many COOL:2E users.

Many organisations are too busy to spend the timeand money to send experienced developers oncourses to update their knowledge on new release


2 Copyright � HawkBridge Pty Ltd


enhancements. These developers are expected tolearn about the new features by reading releasehighlights and fix notes, and then use trial and errorto determine how best to utilise the enhancements. Inmost cases, the trial and error is at the expense ofquality application design.

We have been involved with the development ofRelease 7.0 for more than 12 months and have beenusing it for more than six months. Gainingknowledge and experience in application uses of thenew features that can help shortcut yourimplementation of Release 7.0.

The major enhancement for Release 7.0 is the RPGIV ILE generator. This language has tremendousflexibility, which adds an extra dimension to thecomplexity of application development. Used in thewrong manner, it can wreak havoc on theperformance and integrity of your applications. Notto mention the decrease in programmer productivitythat can result from incorrect application design. Willyou be prepared for Release 7.0 when it arrives atyour site?

What will be the major enhancements for the nextrelease? E-business is the strategic direction for all ofthe COOL products. Should Computer Associatesdevote all of its time and resources to e-business? Forthe businesses we have worked for, e-businessrepresents a small proportion of the total application.Shouldn’t the level of enhancements be in proportionto the proportion of the total application that theyrelate?

In this report, we analyse all of the new features ofCOOL:2E delivered with Release 7.0 in a criticalmanner from a users perspective. We look at ways inwhich they can be used to add value to yourapplication development. We provide the level ofassurance required by most users to move to the nextrelease without the need to worry about backwardcompatibility issues. We document the method andapproach used to conduct the backward compatibilitychecks. We discuss the future direction of COOL:2Eunder the current owner, Computer Associates.

Armed with this information, you will be able todecide whether to upgrade to Release 7.0 and moreimportantly whether there is a future in COOL:2Ethat fits your particular development environment. Asa technical user of COOL:2E, you will be able todecide how to utilise the new enhancements to enrich

your applications. You will be able to repeat thebackward compatibility test process in your owndevelopment environment for a greater level ofassurance.

This document is best read in conjunction with theCOOL:2E Release Summary 7.0 provided byComputer Associates on the COOL:2EDocumentation 7.0 GA CD-ROM. ♦




Release 7.0 Enhancements

The Statement of Direction1 that preceded Release 7.0development highlighted Sterling Software’scommitment to web-enable all of its products and thate-business was the focus for all of it’s ApplicationDevelopment business. Considering how muchemphasis was placed on e-business and webenablement there is very little offered in the way of e-business and web enablement with Release 7.0.

The majority of development effort for Release 7.0 hasbeen devoted to programmer enhancements andgenerator improvements. The only web enablementenhancements, if you can call them that, come fromthird party add-on products. Newlook, from LookSoftware Pty Ltd2, provides the ability to graphicallyenable AS/400 applications and Domino Connectors,from Triangle Software Products Ltd3, provides easyaccess to the functionality of Lotus Domino fromapplications developed using COOL:2E.

For COOL:2E developers there is a new RPG IV ILEgenerator, componentisation of action diagram logic forre-use, support for duplicate parameters, physical fileprocessing and object locking enhancements. Inaddition, several minor enhancements were made tofacilitate the major enhancements.

When Sterling Software bought Synon, there was a lotof concern about whether they would continue tosupport and develop COOL:2E. In the initial months,after Sterling Software absorbed Synon it looked likeCOOL:2E was destined for the shelf. This was fuelledto an extend by Sterling Software mistaking COOL:2Eas the previous version of COOL:Plex (formerlyObsydian) thinking that all COOL:2E users could andwould easily move to the newer tool, COOL:Plex. 1 Sterling Software, September 1999. Statement of Direction:COOL:Plex and COOL:2E.2 Look Software Pty Ltd, http://www.looksoftware.com/.3 Triangle Software Products Ltd, http://www.domcon.com/.

Never really renaming the product, like COOL:Plexbeing renamed from Obsydian, also fueled the notionthat the product had no future under Sterling Software.

It wasn’t until after the Sterling Software EnterpriseStrategies conference in 1999 that things changed. Itwas during this conference that it was highlightedCOOL:Plex was not the natural progressive step forCOOL:2E users and that there was a place for bothdevelopment tools. It was also at this conference thatthe concept of co-existence of COOL:2E andCOOL:Plex emerged. Whereby a strategy would bedeveloped to enable better bi-directional interfacingbetween the tools. We also heard at the conferenceabout how Sterling Software senior management wassurprised at the quarterly returns that COOL:2E wasmaking in comparison to the rest of the COOLproducts.

Many users of COOL:2E remained concerned about thefuture of the product. The real future of the tool underSterling Software management would have to be judgedby what it delivered in the next release. Release 7.0 isthe first release of COOL:2E that was completelymanaged by Sterling Software during the concept anddevelopment phase. What is delivered, as enhancementsin Release 7.0 would be a clear indication of SterlingSoftware’s commitment to the future of COOL:2E.

Release 7.0 was a considerable investment indevelopment and was similar to previous major releasesof COOL:2E under Synon management. Itdemonstrates that Sterling Software was committed tothe product and that it had a future under SterlingSoftware management. However, Computer Associatesnow owns the COOL products and they have only beeninvolved in Release 7.0 during the RC1 phase. If thenext release is anything like Release 7.0, thenCOOL:2E users will have no cause for concern aboutthe future of the product under Computer Associates.




Later in this report, we look at the future of COOL:2Eunder the management of Computer Associates.

In this section, we analyse all of the new features ofCOOL:2E delivered in Release 7.0 in a critical mannerfrom a users perspective. We look at ways in whichthey can be used to add value to your applicationdevelopment. As a technical user, you will be able todecide how to utilise the new enhancements to enrichyour applications with the least amount of effort.

RPG IV ILE Generator

RPG IV ILE is the major enhancement for Release 7.0.Some would argue that it has been a long time coming,but there are reasons for it not appearing in an earlierrelease. When RPG IV was released by IBM, it washeralded for its developer improvements inproductivity. Nearly all of the enhancements over RPGIII were provided to make it easier to write, build andmaintain applications from source code. RPG IV didnot provide any significant advantage to write, buildand maintain applications from a COOL:2E data modelwhere generated source code should be irrelevant.

Another reason for not moving to RPG IV ILE soonerwas that the language had not really been adopted bymainstream application development. There wereconcerns with run-time performance and the emergenceof Java and e-business shifted everyone’s attention. Inrecent months IBM has changed its focus on the RPGIV language and is placing more emphasis indeveloping it as the mainstream language.

In recent years, it has become apparent to COOL:2Eusers that the RPG III limitations are very restrictive.The only solution is to convert generated RPG IIIsource code to RPG IV, and compile using theCRTBNDRPG command. These limitations were theprimary incentive for Sterling Software to provide theRPG IV generator. Early discussions with SterlingSoftware marketing and lab steered clear of trying toimplement an RPG IV ILE generator capable ofexploiting all of the ILE features. This was due to theperceived complexity of the language concepts, howthey could be implemented in COOL:2E and whether ornot they could deliver any improvement in thedevelopment process for COOL:2E users.

Writing a generator from the ground up would consumemost of the development effort for the new release. Soit was decided to only provide RPG IV generationwithout support for any ILE features. Thankfully, amethod was devised by the lab to build the generator ina shorter period so that more development time couldbe spent on implementing RPG IV ILE features into thenew release.

Release 7.0 is the first step of a multi-phaseimplementation of RPG IV and ILE within COOL:2E.The first step taken in building the generator involvedre-using some of the RPG III generation programs.These programs produce RPG III code, which is thenconverted to RPG IV source code using a conversionroutine built by the lab. Over time, the reliance upon theRPG III generator programs will be slowly removeduntil there is a pure RPG IV generator.

As long as any RPG III generator programs are used bythe RPG IV generator, the data model objects cannot bemodified to take advantage of certain RPG IVenhancements. One particular restriction is on thelength of field names. RPG IV can allow longer fieldnames up to 4096 characters, but the RPG III generatorprograms cannot use them. This leaves us with fieldnames of six characters in generated RPG IV sourcecode. Another restriction with the RPG IV generator isnot being able to use the new RPG IV data types asprimitive data types in a COOL:2E data model, such asbasing pointers and Java classes. It is possible to workaround these and other restrictions using RPG IVEXCUSRSRC functions, as the generator program forRPG IV has been re-written for this particular functiontype.

Program Creation Strategies

RPG IV ILE enhancements give RPG developers muchmore flexibility in designing and developingapplications from source code. With the added increasein flexibility, developers will be able to produceapplications that add an extra dimension to thecomplexity of the application solution. For instance,using activation groups requires careful considerationbefore use, as it is possible to call a program running ina different activation group. Mixing activation groups isnot an advisable strategy, as we shall see later.




IBM offers three program creation strategies4 forimplementing RPG IV and ILE into a developmentenvironment. Adopting the correct strategy for yourdevelopment environment is crucial for the success ofRPG IV and ILE development.

Release 7.0 delivers the ability to support programcreation strategies one and two with some restrictions.The only aspect of program creation strategy threeprovided with Release 7.0 is the ability to define andcompile external functions as modules for use withstrategy two.

As a developer, you control which program creationstrategy is used to generate and compile RPG IVprograms and modules by changing the target HLL,compilation type and creation command for an externalfunction.

The target HLL now supports a value of RP4, which isused to specify a target HLL of RPG IV.

Compilation type is a new concept for COOL:2Edevelopers to understand. Up until Release 7.0, thecompilation type for an external function has alwaysbeen of type PGM or program. With the introduction ofILE features in Release 7.0 a new compilation type hasbeen provided, this is MOD or module. A function,which is specified as a module, will not produce anindependently executable object when generated andcompiled. A module is bound to a calling programduring the compilation of that calling program.

4 IBM, 1998. AS/400 Advanced Series – ILE RPG for AS/400Programmer’s Guide, Version 4, Edition 2. Document number SC09-2507-01. Chapter 3, Program Creation Strategies.

Two shipped data model messages are provided tocontrol RPG IV program and module compilation at thedata model level, *CRTBNDRPG and *CRTRPGMODrespectively. The compilation command may beoverridden at the function level by using the programcompilation override option. Note that any function thathas been overridden will not be affected with anysubsequent changes to the shipped creation messages.COOL:2E developers are used to this concept, as thereare messages to compile all objects in the data model,which can be overridden at the object level.

Strategy 1: Using Default Activation GroupThe first program creation strategy delivers an OPMcompatible application using the Create Bound RPGProgram (CRTBNDRPG) command to compile aprogram to run in the default activation group. Thisstrategy results in an RPG IV program that interactswell with OPM programs, such as RPG III. There is noneed to understand activation groups, modules andprocedures, or resource management under ILE. Usingthis strategy, you can take full advantage of thelanguage enhancements in RPG IV without the need tomove into ILE development.

To implement program creation strategy one, use thefollowing compilation command either at the datamodel or function override level:

CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)DFTACTGRP(*YES) DBGVIEW(*SOURCE)OPTIMIZE(*BASIC) CVTOPT(*DATETIME)

Current RPG III application designs fit well into thefirst strategy without modification. The only down sideof this strategy is that an RPG IV program runs less

Figure 1: Strategy 1 Using Default Activation Group

Default Activation Group

ILEPGM

OPMPGM

OPMPGM

ILEMOD




efficiently than RPG III programs. Here’s a tip – don’tconvert existing RPG III source code into RPG IVsource code, unless there is a valid reason that involvesusing an RPG IV enhancement.

Using program creation strategy one has one majordrawback; you cannot use static calls to modules of anylanguage from an RPG IV program. This is becausecompiling with the default activation group does notallow the use of static binding.

Strategy 2a: Using Named Activation GroupThe second program creation strategy delivers an ILEapplication using the CRTBNDRPG command tocompile a program to run in a named activation group.This strategy results in an RPG IV program that can useILE static binding of modules and procedures alongwith the ability to separate resource management intodistinct and separate sub-applications running in anamed activation group.

When using ILE static binding to other modules, abinding directory can be used during the binding phaseof RPG IV program compilation to simplify theprocess. The modules need to be created using theCRTRPGMOD command before they can be bound to aprogram using the CRTBNDRPG command.

To implement program creation strategy two using anamed activation group, use the following compilationcommand either at the data model or function overridelevel:

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 anapplication that also has programs running in thedefault activation group, then there is the possibility ofmixing ILE and OPM behavior. This adds another levelof complexity to application design with the scope ofoverrides and open data paths5, which can be at job oractivation level. As IBM has highlighted, it is notadvisable to mix ILE and OPM behavior.

One characteristic of the CRTBNDRPG commandneeds to be highlighted. During the compilationprocess, the RPG IV source member is compiled into atemporary module. This module is then bound into aprogram object and then the module is deleted. Themodule cannot be re-used by other programs ormodules in static calls using this approach unless it isalso compiled using the CRTRPGMOD command. Thisthen enables the RPG IV source to be called staticallyor dynamically depending upon the needs of theapplication. This technique is not the ideal solution inan ILE application and is better served by adopting thethird strategy described below.

Special activation groups, *NEW and *CALLER, areallowed to be used in place of a named activationgroup. Specifying *NEW will cause a new activationgroup to be started for the program to run in. When theprogram completes, the activation group is ended andall resources reclaimed. Specifying *CALLER willallow the program to use the activation group of thecalling program, including the default activation group.

5 IBM, 1998. AS/400 Advanced Series – ILE RPG for AS/400Programmer’s Guide, Version 4, Edition 2. Document number SC09-2507-01. Chapter 3, Program Creation Strategies. Section 1.3.4, AStrategy to Avoid.

Figure 2: Strategy 2a Using Named Activation Group

MY Activation Group Default ActivationGroup

Default ActivationGroup

ILEPGM

OPMPGM

ILEMOD

OPMPGM




Strategy 2b: Using Callers Activation GroupTo implement program creation strategy two using thecalling programs activation group, use the followingcompilation command either at the data model orfunction override level:

CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)DFTACTGRP(*NO) DBGVIEW(*SOURCE)ACTGRP(*CALLER) OPTIMIZE(*BASIC)CVTOPT(*DATETIME) BNDDIR(&YBNDDIR)

This is the default value for the shipped model creationmessage *CRTBNDRPG.

When a program running in the default activation groupcalls a program compiled with this form of strategytwo, the called program will run in the defaultactivation group. This approach gets around thelimitation of strategy one, that prevents static calls tomodules of any language. An ILE program running inthe default activation group may have resourcemanagement issues. The use of the RCLRSC command

will not free static storage allocated by the ILEprogram6.

When a program running in a named activation groupcalls a program compiled with this form of strategytwo, the called program will run in the same namedactivation group.

Strategy 2c: Using New Activation GroupTo implement program creation strategy two using anew activation group, use the following compilationcommand either at the data model or function overridelevel:

CRTBNDRPG PGM(&2/&1) SRCFILE(&3/QRPGLESRC)DFTACTGRP(*NO) DBGVIEW(*SOURCE)ACTGRP(*NEW) OPTIMIZE(*BASIC)CVTOPT(*DATETIME) BNDDIR(&YBNDDIR)

6 IBM, 1998. AS/400e Series – ILE Concepts, Version 4, Edition 3.Document number SC41-5606-02. Chapter 5, Activation GroupManagement. Section 5.2.2, Reclaim Resources Command for ILEPrograms.

Figure 3: Strategy 2b Using Callers Activation Group


OPMPGM

OPMPGM

ILEMOD

ILEPGM

Figure 4: Strategy 2c Using New Activation Group

*NEW ActivationGroup



ILEPGM

OPMPGM

ILEMOD

OPMPGM




It is not advisable to implement this at the data modellevel by changing the shipped creation message*CRTBNDRPG, as it means that by default all RPG IVprograms will run in their own activation groups. Therewill be noticeable performance degradation with somany activation groups being started and ended withevery program call and return. Use this option at thefunction level for specific functions that you require torun in a unique activation group only.

Strategy 3: Using All ILE FeaturesThe third and final program creation strategy deliversan ILE application using the CRTRPGMOD andCRTPGM or CRTSRVPGM commands to compile aprogram or service program to run in a namedactivation group. This strategy involves a two stepcompilation approach. The first step being to compilethe RPG IV source code into a module using theCRTRPGMOD command. The module is then boundinto a program object using the CRTPGM command.

This strategy is typically used to bind more than onemodule into the program object. The major differencebetween this strategy and strategy two is that themodule is permanent and can be used to bind to otherprograms and modules. Using this strategy, you havethe greatest flexibility allowing you to utilise all of theILE concepts.

The only part of this program creation strategy that issupported in Release 7.0 is the ability to generate andcompile RPG IV ILE modules. These functions canthen be used by functions using program creationstrategy two, which support static binding of modules.

This program creation strategy is not yet fullysupported by COOL:2E. The future capability ofCOOL:2E supporting this program creation strategy isdependent upon the successful uptake of the RPG IVILE generator by the COOL:2E users and the feedbackthat is provided. It is strongly recommended that if youwish this support in a future release of COOL:2E, thenyou should provide both positive and negative feedbackback to the development lab. From this feedback, theycan then determine the future direction that the RPG IVILE generator will take.

Function Naming Guidelines

The program creation strategy used for a function issomething that every programmer will need to easily

identify. This will enable the correct functions to bebound to one another without mixing OPM and ILEbehavior, or incorrectly using activation groups for anapplication. All of the issues with resource managementand scope of overrides and open data paths becomeproblematic when mixing OPM and ILE programs, oran inconsistent use of activation groups.

To determine the correct function to use, a programmerwill need to identify the target HLL, compilation typeand activation group of the function. None of thesecharacteristics of a function can be easily identifiedwhen editing an action diagram. They can only bedetermined from the Edit Function Details screen.However, there is a loss of programmer productivity indetermining these characteristics of a function, whichleaves room for significant productivity improvementswith simple function naming guidelines.

Object names within COOL:2E should provide asummary of those characteristics that are necessary touse the object, which would otherwise be too difficultto view. If the target HLL, compilation type andactivation group of a function were included in thename of the function, then considerable time and effortcould be saved in building and maintainingapplications.

Target HLL and Compilation TypeBy default the compilation type is set to PGM for allexternal functions and can be switched to MOD andback again using the new T=ILE Compilation Typeoption. This is only available if the target HLLlanguage of the function is ILE compatible, such asRPG IV.

Both the target HLL and compilation type are viewedfrom the Edit Function Details screen. Including atarget HLL and compilation type abbreviation in thefunction name as a prefix or suffix will greatly reducethe time and effort required building RPG IV ILEapplications. As a guideline, you could use thefollowing target HLL and compilation typeabbreviations:

• “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 andcompilation type abbreviation as a prefix or suffix onthe function name depends on how you wish to groupfunctions. Using a prefix will group related types,whereas using a suffix will group related functions.You will have to decide which is more important foryour particular organisation.

Activation GroupThe activation group of a function is determined fromthe function compilation override. Including anactivation group abbreviation in the function name aseither a prefix or suffix will greatly reduce the time andeffort required building RPG IV ILE applications. As aguideline, you could use the following activation groupabbreviations:

• “(*C)” = Runs in the Callers Activation Group,• “(*D)” = Runs in the Default Activation Group,• “(*N)” = Runs in a New Activation Group, and• “(MY)” = Runs in Activation Group MY.

The decision to either use the activation groupabbreviation as a prefix or suffix on the function namedepends on how you wish to group functions. Using aprefix will group related activation groups, whereasusing a suffix will group related functions. You willhave to decide which is more important for yourparticular organisation.

Modularity for Maximum Reusability

As with most new features, there is a right way and awrong of using them. Rarely do you see a developerpick-up a new feature and use it correctly first attempt.It normally takes months or years of experience to learnall of the intricacies through trial and error. Lookingback at some of your earlier work can sometimes makeyou cringe at the thought of using the same techniquestoday.

ILE is an overly complex concept to developers withlittle or no knowledge of languages and developmentpractices outside of RPG III and COBOL proceduralprogramming on the IBM mid-range. Used in thewrong manner ILE can complicate the maintenanceprocess considerably.

For instance, consider a developer confronted with theRPG III suite of functions in Figure 5 and having toprovide an interface to the Work with Clients function

from an RPG IV ILE function running in a namedactivation group. The developer cannot change thetarget HLL, compilation type or activation group of thecurrent function because it is used in numerous otherfunctions. To further complicate the issue, the Workwith Clients function needs to run as an RPG IV ILEprogram in the same activation group as the callingfunction.

It is important that you don’t mix OPM and ILEprograms in the same application. This is because thereare issues with resource allocation, and file overrideand open data path scopes. For this reason, thedeveloper has decided to copy the Work with Clientsfunction to a new DSPFIL function. This enables thedeveloper to change the target HLL to RP4, set thecompilation type to PGM and make sure that theactivation group is set to *CALLER. The developernow has the Work with Clients function definedcorrectly for use by the new calling RPG IV ILEfunction. The Work with Clients function will become

Figure 5: RPG III Work with Clients functions


Edt Client:RPG

(EDTRCD)

Wrk Clients:RPG

(DSPFIL)

Figure 6: RPG IV ILE Work with Clients functions

*CALLER Activation Group

Edt Client:RP4(*C)

(EDTRCD)

Wrk Clients:RP4(*C)(DSPFIL)




an RPG IV ILE program that will run in the sameactivation group as the calling function.

The developer cannot stop there, as the RPG IV versionof Work with Clients is still calling the RPG III versionof Edit Client. The developer needs to copy and changethe Edit Client function in the same manner as theWork 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. Thedeveloper has just doubled the amount of effortrequired to maintain the Work with Clients function.Any change made to the RPG III functions will need tobe duplicated in the RPG IV functions. What makes itworse is that there are twice as many screens as before,which are the most time consuming objects forCOOL:2E developers.

The problem becomes even more of an issue whenother developers perform the same process as the firstdeveloper to make the Work with Clients functionalityavailable for different ILE scenarios. Such as running ina specific named activation group or an RPG IV ILEmodule version.

However, a solution exists that enables all of theprogram creation strategies to be employed withoutduplicating the application logic. More importantly, itonly requires two device designs. This solution uses theobject-based concept of development to reduceduplicate action diagram code. Figure 7 displays thenew modular Work with Clients suite of functionsresulting from the use of this approach.

In this solution, all device functions or functionscontaining application logic as opposed to control flowlogic are coded as RPG IV ILE modules. This enablesthem to be bound to a number of other functions at

Figure 8: EXCEXTFUN wrapper function action diagram

.--| * Ignore initialisation errors.| PGM.*Return code = CND.*Normal| <<INSERT WRAPPED FUNCTION HERE>>| > Check return code. On error, send message.| .-CASE| |-PGM.*Return code is *Error on call to...| | * Error message already sent.| || |-NOT PGM.*Return code is *Normal| | Send error message ‘ Return code invalid’| | I *Return code PGM.*Return code| ‘-ENDCASE| * Exit with return code for calling function to process.| Exit program - return code PGM.*Return code‘--

Figure 7: Modular Work with Clients functions

Edt Client:R4M

(EDTRCD)

Wrk Clients:RP4(*D)

(EXCEXTFUN)

Wrk Clients:RP4(MY)

(EXCEXTFUN)

Wrk Clients:RP4(*C)

(EXCEXTFUN)

Wrk Clients:R4M

(DSPFIL)




compilation time to perform specific ILE behavior. Inthe example, the DSPFIL and EDTRCD functions areconverted to RPG IV ILE modules.

We have added three new EXCEXTFUN functions toact as wrapper type functions. The action diagram logicfor these functions is almost identical apart from thefunction that they wrapper and the program creationstrategy employed. Figure 8 contains the action diagramskeleton for a wrapper function. As you can see, itcontains only the logic to call and responds to the returnfrom the wrapped function.

With this function structure, it is possible to use any ofthe ILE program creation strategies. This represents asignificant reduction in effort required to maintain theWork with Clients function while at the same timeproviding the greatest flexibility in function re-use.

Using COOL:2E function templates you further reducedevelopment effort by pre-defining reusable functionstructures. This modular Work with type structure canbe easily converted to a function template.

The issues with the ILE program creation structurediscussed above are still possible, but good design willhelp in reducing that risk.

Encapsulation of Database Functions

Modules can help reduce the impact of databasechanges, although it requires significant changes infunction design and use. When a module has beenchanged, you only need to re-compile the module andthen use the UPDPGM command to re-bind the newmodule to any programs that use it. Isolating alldatabase file accesses into modules and only usingthese modules to access your data reduces the impact ofa file change.

Consider the Edit Client function decomposition infigure 9. The database update user points no longer callthe standard CRTOBJ, CHGOBJ and DLTOBJ.Instead, they have been replaced with EXCEXTFUNwrapper functions, which perform the same role as inthe figure 7. Again, function templates can be used tosimplify the development process for creating thisfunction structure.

Record Changed Since DisplayedThere is an issue with this function structure, in that therecord changed since displayed processing will nolonger be generated for CHGOBJ and DLTOBJfunctions. This is because that processing is onlygenerated when the database update user points call

Figure 9: Edit Client function decomposition

Change Client

(CHGOBJ)

Wrk Clients:R4M

(DSPFIL)

Chg Client:R4M

(EXCEXTFUN)

Crt Client:R4M

(EXCEXTFUN)

Dlt Client:R4M

(EXCEXTFUN)

Create Client

(CRTOBJ)

Delete Client

(DLTOBJ)




their respective CRTOBJ, CHGOBJ and DLTOBJfunction types.

A solution is possible, but not with Release 7.0 as itrequires the COOL:2E development lab to change thetool. The development lab needs to provide access tothe saved record image, change duplicate parameterusage, and add a new user point in DLTOBJ functiontypes.

In EDTxxx function types a copy of the record readfrom the database is saved as hidden fields on thedevice. This is used to check for record changed sincedisplayed and is not available for use by the actiondiagram. During post confirm processing the savedimage can be re-instated into DB1 context for use bythe action diagram and passed into the database updatefunctions along with the relevant device context fields.

Duplicate parameters will be discussed later in thisdocument. They are only allowed in EXCEXTFUN andEXCINTFUN function types. If we could use themwith the database function types, then we could pass thesaved image and new image of the record asparameters. This would then enable the current imageafter it has been read from the database to be comparedto the saved image. If they don’t match, then the recordhas changed since it was displayed.

The final change required is to provide a new user pointin DLTOBJ function types to allow validation beforethe record is deleted. This would then provide similarfunctionality and behavior as the CHGOBJ functiontype.

Using UPDPGM with ModulesHaving implemented all database access as calls to ILEmodules, impacts from any file changes can berestricted to those modules. When the file does changeit is only a matter of re-generating and compiling themodules then use the UPDPGM command to re-bindthe updated modules to any programs that use them.

However, there is a change management issue thatcannot be resolved using COOL:2E. There is no easymethod of determining the programs using a specificmodule from within COOL:2E. The YDSPMDLUSGcommand to determine the impact of the change to themodules does not have a scope option to treat modulesdifferently than programs. When you set the scope to*GENFUN it stops at the ILE module functionsbecause it is an external function.

A solution is possible, but not with Release 7.0 as itrequires the COOL:2E development lab to change thetool. The solution requires a new scope option on theYDSPMDLUSG command similar to *GENFUN,except that ILE modules are treated as internalfunctions. When the usage is being exploded with thisnew scope option and it comes across an externalfunction with a compilation type of MOD, it is to treatit an internal function. The filter option will also needto have a similar option to eliminate external functionsthat have a compilation type of MOD.

Mixed Source Data Models

Up until Release 7.0, very few COOL:2E sites wouldbe generating both COBOL and RPG III in the samedata model. However, with the Release 7.0 we will seea lot more sites using a mix of RPG III, COBOL andRPG IV ILE functions. There are some issues withmixing generated programs from the different targetHLL.

EXCUSRSRC Function TypesIf you are going to start using more than one targetHLL in the same data model, then you will have toconsider how to deal with EXCUSRSRC functiontypes. Most COOL:2E developers would probablycreate duplicate functions for each of the target HLL.This adds a level of complexity to the data model that isunnecessary. Reducing the number of functions in thedata model greatly improves developer productivity.

All of the target HLL generators have been adjusted todeal with EXCUSRSRC function types in a consistentmanner. When an EXCUSRSRC function type isencountered, they don’t look at the declared target HLLof the EXCUSRSRC function to determine whichsource file to look for the source member to include inthe generated source. Instead, they know the target HLLbeing generated and will look for a member, of thesame name as the EXCUSRSRC function, in theassociated target HLL source file.

This minor enhancement reduces the complexity of thedata model and removes the need for COOL:2Edevelopers to be aware of the target HLL beinggenerated.

When upgrading to Release 7.0 all RPG IIIEXCUSRSRC functions can be converted by building amodel object list of them all, or subsetting the




*ALLOBJ list, and executing the following commandagainst 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 usefunction F13 to repeat that option to the bottom of themodel object list. Then place the above command onthe command line and press the Enter key.

If you are using a change management tool thatmanages the COOL:2E objects, then you may haveproblems with EXCUSRSRC function types that usethis approach. They only manage the source codemember of the declared target HLL and ignore theimplicit target HLL source code members.

There is a solution to this problem, but it requires theCOOL:2E development lab and change managementsoftware vendor to make changes to their software. TheCOOL:2E development lab needs to enable multiplePGM compilation types on an EXCUSRSRC functiontype with different target HLL. The changemanagement software vendor needs to cater formultiple PGM compilation types on EXCUSRSRCfunction types.

Inter-Language Function CallsWhen function parameters are passed as RCD or KEY,the target HLL generators don’t declare the same datastructure for receiving them into the program. Considerfigure 10 that shows the parameter details for anEXCEXTFUN function, which are passed as KEY. Thefirst parameter has been intentionally dropped todemonstrate how each of the target HLL generatorstreats it.

Figure 10: Parameter details for passed as KEY

Op: DARRYL QPADEV0002 29/08/00 6:22:20EDIT FUNCTION PARAMETER DETAILS Release 7.0 Test ModelFunction name. . : Test PARs Passed as KEY Type : Execute external functionReceived by file : Order Product Acpth: Update indexParameter (file) : Order Product Passed as: KEY

? Field Usage Role Flag error_ Order Number_ Product Code I

SEL: Usage: I-Input, O-Output, B-Both, N-Neither, D-Drop.Role: R-Restrict, M-Map, V-Vary length, P-Position. Error: E-Flag Error.

F3=Exit

Figure 11: RPG III Parameter Declaration

FMT * ..... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 70003.80 * Parameter declarations0003.90 IP1PARM DS 120004.00 * KEY: Order Product Update index0004.10 * I : Product Code0004.20 I 7 12 P1AUCD

Figure 12: RPG IV ILE Parameter Declaration

FMT * *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+.0005.10 * Parameter declarations0005.20 D P1PARM DS 120005.30 * KEY: Order Product Update index0005.40 * I : Product Code0005.50 D P1AUCD 7 12




Both the RPG III and RPG IV ILE generators declare adata structure for the parameter as the size of thecombined key fields. The space for the droppedparameter is still catered for in the data structure, but noseparate data structure sub-field is declared. Theresultant section of the generated RPG III and RPG IVILE source code can be seen in Figures 11 and 12.

On the other hand, the COBOL generator does notdeclare the size of the data structure and the space forthe dropped fields is not included. Only thoseparameters with a usage specified will be included inthe data structure. The resultant section of the generatedCOBOL source code can be seen in Figure 13.

This difference in the target HLL generators makes itdifficult for developers to remain target HLL ignorantwhen building applications in a mixed source datamodel.

There is a work around for this feature to ensure thatparameter mismatches don’t occur when calling RPGIII or RPG IV ILE programs and modules from aCOBOL program, or vice versa. When declaringparameters for COBOL external functions which arepassed as KEY or RCD, make sure that all fields have ausage defined. If you don’t want to actually pass avalue or field for the parameter, declare it as a neitherusage. The resultant section of the generated COBOLsource code when Order Number is declared as neitherusage can be seen in Figure 14.

There is another option, and that is to never passparameters as KEY or RCD for COBOL externalfunctions. However, this produces less efficient runtimeobjects because of the number of separate parametersbeing passed.

COBOL, CL, and C ILE ModulesRelease 7.0 does not have any support for the other ILEcapable languages. However, you can still use themwithin RPG IV ILE functions in the data model with asimple work around. The only problem is that you haveto use PDM or some other 3GL technique to enter thesource code, compile the modules and add them to thebinding directory used by the data model.

Once you have compiled the module and updated thebinding directory, declare an EXCEXTFUN functionwith a target HLL of RPG IV ILE, compilation type ofMOD and source member name of your ILE module.This function will act as the interface in the data modelto the ILE module. Other RPG IV ILE functions cancall this EXCEXTFUN function and it will actually callthe ILE module created external of the data model.

When writing the ILE module source code, make sureto include the implicit return code parameter.Otherwise, you will cause an exception error at runtime. This is because we are using an EXCEXTFUNfunction that would normally have its source codegenerated from the data model and all generatedfunctions have an implicit return code parameter. Itmight pay to place a permanent lock on theEXCEXTFUN function so as not to accidentallygenerate and compile it. If it were to be compiled, itwould replace your original ILE module in thegeneration library.

The CL ILE module support was being worked onduring Release 7.0 Alpha and RC1 phase of testing.The data model shipped message has been defined forcompiling CL ILE modules, which is *CRTCLMODand CLL seems to be the three-character abbreviationfor the target HLL. We expect to see support for CLILE modules in the next release after Release 7.0.

Figure 13: COBOL Parameter Declaration

FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++0011.70 01 P1PARM.0011.80 * Product Code0011.90 03 P1AUCD PIC X(6).

Figure 14: COBOL Parameter Declaration with Neither Usage

FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++0011.70 01 P1PARM.0011.80 * Order Number0011.90 03 P1ATCD PIC X(6).0012.00 * Product Code0012.10 03 P1AUCD PIC X(6).




The COBOL ILE generator has been mentioned atconferences in the US and Europe earlier this year andmay reach GA by early next year. Although, CA didsay that no promises were being made at the time. TheCOBOL ILE generator does not require a completegenerator overhaul as happened with the RPG IV ILEgenerator. This is because the syntax and format ofCOBOL and COBOL ILE source code are not thatmuch different7.

Pure COBOL Data Models

A pure COBOL data model is one that uses namingconventions that are only compatible with COBOLgenerated source code. The naming convention isdefined in the YHLLVNM model value andYHLLVNMRFA dataarea. Some COBOL data modelsmay have a COBOL naming convention, but the objectsdefined in the data model may all conform to RPG andCOBOL naming conventions. This particular type ofCOBOL data model is not a pure COBOL data modelas it is possible to generate RPG III and RPG IV ILEsource code from it.

The RPG IV language can support the longer namesused by pure COBOL data model. However, theRelease 7.0 RPG IV ILE generator does not fullysupport them. The reason has already been discussedand it has to do with the RPG IV ILE generator re-usingsome of the RPG III generator programs. We see theprovision of a full RPG IV ILE generator as the path forthese pure COBOL data models to convert to the RPGIV language. However, until a full RPG IV ILEgenerator is provided, these users are trapped into usingCOBOL only.

7 IBM, 1998. AS/400 Advanced Series – ILE COBOL for AS/400Programmer’s Guide, Version 4, Edition 1. Document number SC09-2540-00. Chapter 1, Introduction. Section 1.1.2, ILE COBOL forAS/400.

Conditional Compilation Directives

The RPG IV language allows you to conditionallyinclude or exclude sections of source code from thecompile8. With Release 7.0, you can now takeadvantage of these new directives in EXCUSRSRCfunctions to control the compilation of RPG IVgenerated programs and modules.

The conditional directives were provided for supportingmodular ILE development. Whereby procedureprototypes, data structures and variables would only bedefined once in a program or module. Figure 15demonstrates how to include a section of source code ina program on its first occurrence only. The conditionname must be unique within the compiled program ormodule for this to work properly. This technique hasbeen widely used by C and C++ developers for manyyears.

One interesting scenario for its use is to have differentsubfile options and command keys available for testingand production. To achieve this you would have todefine three EXCUSRSRC functions. The firstEXCUSRSRC function would contain the /IFDEFINED(TEST) directive, the second /ELSE, and thethird /ENDIF. For ease of use and readability in anaction diagram, the function names should include thecompilation directive they contain. These could then beincluded into an action diagram around the code thatshould be conditionally compiled, as depicted in Figure16. This example will run the report interactivelyduring testing and submit it in production.

Using these conditional compilation directives requiresthe program to be compiled for testing and then re-compiled for production. When compiling for testing,you will need to add the DEFINE(TEST) parameter tothe program or module creation command. Whencompiling for production, the DEFINE parameter is notused.

The benefit for developers in using conditionalcompilation in this manner is that all testing anddebugging aids can be left in the action diagram forfuture use.

8 IBM, 1998. AS/400 Advanced Series - ILE RPG for AS/400Reference, Version 4, Edition 2. Document number SC09-2508-01.Chapter 2, Compiler Directives. Section 1.2.5, ConditionalCompilation Directives.

Figure 15: Example Conditional Directive

/IF NOT DEFINED(MYCOPYMBR)/DEFINE MYCOPYMBR

... Source to be included once only

/ENDIF




To simplify the use of conditional compilation, thedevelopment lab could add the conditional directives asnew built-in functions. Better still, the development labcould change the CASE statement or implement a newblock statement similar to CASE for the conditionaldirectives. This would then enable you to work with the/IF, /ELSEIF, /ELSE and /ENDIF in the same manneryou work with CASE statements.

Binding Directories

A binding directory is a list of ILE modules and serviceprograms that may be required to compile an ILEprogram or service program. For program creationstrategies that employ the CRTBNDRPG command tocompile the ILE program, a binding directory isessential to bind to ILE modules. Whereas using theCRTPGM command to compile the ILE program, abinding directory is optional as the specific ILEmodules can be explicitly specified on the command.

Release 7.0 provides the capability of defining onebinding directory, specified in the data model by usingthe YBNDDIR model value. A few limitations in onlyhaving a single binding directory per data model existand one minor issue will need to be rectified by thedevelopment lab.

Having just one binding directory can produce someproblems with compilation in larger data models. Themore modules that exist in the binding directory, thelonger the binding process may take9. Only the bindingprocess time is increased. The resultant ILE programwill be the same irrespective of the size of the binding

9 IBM, 1998. AS/400e Series – ILE Concepts, Version4, Edition 3.Document number SC41-5606-02. Chapter 2, ILE Basic Concepts.Section 2.6, Binding Directories.

directory. This is because only those ILE modulesactually used by the ILE program will be included inthe ILE program. Therefore, no run-time performanceissues will arise because of large binding directories.

The YBNDDIR data model value will only accept thebinding directory name, which must exist in thegeneration library. The ILE program creationcommands allow the binding directory to be specifiedwith a library name. Some organisations may havemultiple data models that will share the same bindingdirectory or an existing ILE application that they wishto interface to that exists in another library. TheYBNDDIR data model value will have to be changed toaccommodate a named library, *LIBL, *CURLIB,*USRLIBL or *GENLIB to locate the bindingdirectory. The binding directory must already existwhen using *LIBL, *CURLIB or *USRLIBL. Release7.0 will create the binding directory in the generationlibrary if it does not already exist there.

To try to reduce compilation times in larger datamodels, it will be necessary to provide the ability tospecify binding directories on data model file andfunction options. The data model file binding directoryoption would accept all the values allowed for the datamodel value as well as *MDLVAL, which means thatthe data model value is to be used. The function bindingdirectory option would accept all the values allowed forthe data model file option as well as *FILVAL, whichmeans 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 tothe binding directory associated with the data model asshown in figure 17. The ILE module does not have toexist before being added to the binding directory. Thebinding directory should be resolved from the functionbinding directory option, when it is made available.

Figure 16: Example use of Conditional Compilation Directives in Action Diagram

| > 2=Edit.| .-CASE| |-RCD.*SFLSEL is Edit| | /IF DEFINED(TEST) – Common Routines * EXCUSRSRC| | Print Detailed Report – Order Product * PRTFIL| | /ELSE – Common Routines * EXCUSRSRC| | SBMJOB: Print Detail Report – Order Product * PRTFIL| | /ENDIF – Common Routines * EXCUSRSRC| ‘-ENDCASE




When an ILE program or module is being generated,the generator will need to construct the BNDDIRparameter of the CRTBNDRPG command by addingthe binding directories of all the referenced functions.The BNDDIR parameter allows an almost unlimitednumber of binding directories to be used. This shouldhelp in reducing the number of modules in bindingdirectories and increase the performance of binding andcompilation of ILE programs and modules.

With Release 7.0 the binding directory option allows*NONE to be used. This is a good method ofprohibiting the use of static binding in data models.Without a binding directory, the compiler cannot findthe definitions to bind to any called ILE modules andthe ILE program will not be created.

The minor issue with Release 7.0 that will need to berectified by the development lab is in the managementof binding directory entries. When an ILE module isdeleted from the data model, the binding directory entryis not removed. This will have to change in order to tryto reduce the size of the binding directory. Havingredundant entries in the binding directory only furthercomplicates the issue with binding directory size.COOL:2E should manage the binding directoriescompletely to reduce the complexity of developing ILEapplications.

Control (H) Specification

Two new model values have been supplied withRelease 7.0 for the RPG IV control (H) specification,YRP4HSP for RPG IV ILE programs and YRP4HS2for RPG IV ILE modules. These are limited to onesource line each, which can cause problems when thekeywords require more than one line.

There are several work-arounds for this issue, the firstrequires an EXCUSRSRC function containing only Hspecifications to be added to all external functions. Anywork-around that requires nearly every function in thedata model to be changed is unworkable.

The second work-around uses a dataarea namedRPGLEHSPEC to contain the keywords10. This willonly allow one set of keywords for both RPG IV ILEprograms and modules, which will cause problemswhen they are required to be different. The dataareawill only be used if no H specifications exist in theprogram or module being compiled, which meansclearing the model values for the H specifications.Using the dataarea is not a model based solution and issomething that should be avoided. Other developersmay not understand that the dataarea is being used inthis manner and will have difficulty in finding thesource of the H specifications.

These work-arounds are not cost effective enough asthey will decrease developer productivity. Thedevelopment lab will need to increase the number oflines that can be entered for the new data model values.

Source Code Generation Options

A new data model value, YRP4SGN, has been providedto change the case and color of the generated source.The RPG IV language allows the use of mixed case forsymbolic names. During compilation, all lowercasecharacters are translated to uppercase. Almost any goodbook on programming style will highlight that usingmixed case makes source code easier to read andunderstand. For instance, AddBndDirE is easier to readthan ADDBNDDIRE as the words are delimited byuppercase letters. 10 IBM, 1998. AS/400 Advanced Series - ILE RPG for AS/400Reference. Chapter 13, Control Specifications. Section 3.2.1, Using aData Area as a Control Specification.

Figure 17: Generated RPG IV ILE Module header

FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+..0000.10 H/TITLE RPG IV ILE Module Execute external functio0000.20 Y* ADDBNDDIRE BNDDIR(YBNDDIR) OBJ((RPGIVILE *MODULE))0000.30 *0000.40 Z* CRTRPGMOD0000.50 Z* DBGVIEW(*SOURCE) CVTOPT(*DATETIME)0000.60 H* SYNOPSIS :




Lots more can be done to further improve readability ofgenerated source code with mixed case. Release 7.0allows all uppercase, all lowercase or first characteruppercase options. A style, known as the Hungarianmethod, has been used in C and C++ development forsome time, which uses a data type prefix in lowercasefollowed by first word in uppercase format, such aspMyData. This style has been adopted by someorganisations using RPG IV ILE.

COOL:2E could generate similar names to theHungarian method by making the field contextlowercase and then using the field DDS name enteredin the data model. Along with this, the development labshould allow field DDS names to be entered in mixedcase. There is a problem with this though. The otherHLL generators would then have to convert the fieldname to all uppercase in order to use them.Alternatively, we could have pure RPG IV data modelsmuch like pure COBOL data models can exist.

The color of the generated comment lines can bechanged to green, white, red, pink or blue. Thetechnique of coloring source lines has been around formany years and is nothing new for RPG IV. The sixthcharacter is changed to an attribute byte using therespective hex code. When visually scanning generatedsource code, this will make it easier to differentiatebetween executable lines and comment lines.

Duplicate Parameter Contexts

Release 7.0 provides the capability of specifying a fieldup to nine times as a function parameter forEXCEXTFUN and EXCINTFUN function types. Thisis enabled by using the duplicate parameters functionoption. When enabled the PAR context is no longeravailable in the function and is replaced by up to ninenew contexts for each parameter entry, PR1 to PR9.

Prior to release 7.0, you could have a single fielddefined twice on a function. However, one instancewould be as input and the other as output. Release 7.0enables the same field to be defined as input, output,both, and/or neither up to nine times. All fields in anaction diagram must be unique within context andduplicate parameters are no exception as all fields,prefixed with their associated parameter entry context,are unique.

Duplicate parameters were originally designed toenable co-existence of COOL:2E and COOL:Plex. But,there are significant advantages in using duplicateparameter contexts for non-COOL:Plex co-existencedevelopers.

Figure 18: EXCINTFUN with Duplicate Parameters

Options:Execution location . . . . : W ( W-Where_found, S-Server )Generate as subroutine . . : Y ( Y-Yes, N-No )Share subroutine . . . . . : Y ( M-MDLVAL, Y-Yes, N-No )Duplicate parameters . . . : Y ( N-No, Y-Yes )

Parameters:Fmt Field name Usg Role File nameRCD Order Number I MAP Order Product Retrieval index

Product Code I MAPRCD Order Number I MAP Order Product Retrieval index

Product Code I MAP...........................................................................

> EXCINTFUN w/Dup Parms.--

>> . * >>>>> . .-CASE>> . ¦-PR1.*ALLPARMS EQ PR2.*ALLPARMS>> . ¦ * >>>>> . '-ENDCASE>> . * >>>

‘




From our experiences, many USR fields are defined indata models just so that the same field could be passedtwice into a function. Especially when fields have beenplaced on more than one file and you wish to pass therecord data from two or more of these files to afunction. Database trigger programs are a primeexample of the need for duplicate parameters so that thebefore and after images of the record can be passed to afunction.

This minor enhancement provided with Release 7.0 willhave significant productivity benefits in not having todefine a new field to the data model. Reducing thenumber of fields defined in the data model willdecrease the complexity of the data model, which willalso provide productivity benefits.It is unfortunate that duplicate parameter contexts areonly available on EXCEXTFUN and EXCINTFUNfunction types. Our investigations during Alpha testingrevealed that it could be easily enabled for all functiontypes and will most probably be available in the nextrelease. This will help alleviate some issues with

encapsulating database functions into RPG IV ILEmodules discussed earlier.

A new pseudo-field, *ALLPARMS, for duplicateparameter contexts on CASE and REPEAT WHILEblocks in action diagrams allows entire parameterformats to be compared. The pseudo-fields will onlywork for EXCEXTFUN function types as it makes useof the PnPARM data structure created for eachparameter sequence declared to the function.

EXCINTFUN function types don’t generate datastructures for each parameter sequence, although theCOBOL and RPG IV generators could easily beadapted by the development lab to generate them. TheEXCINFUN function types would have to beimplemented with the share sub-routine function optionenabled, which would produce the local parameterdeclarations. Consider the EXCINTFUN functiondefined 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 IVrespectively.

Figure 21: EXCINTFUN RPG IV Local Parameter Declarations

FMT D .....DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++0009.20 D Wl0001 S 60009.30 D Wl0002 S 60009.40 D Wl0003 S 60009.50 D Wl0004 S 6

Figure 20: EXCINTFUN RPG III Local Parameter Declarations

FMT C .....CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEq0052.80 * Define local variables for subroutine SAINFN.0052.90 C MOVEL*BLANK WL0001 60053.00 C MOVEL*BLANK WL0002 60053.10 C MOVEL*BLANK WL0003 60053.20 C MOVEL*BLANK WL0004 6

Figure 19: EXCINTFUN COBOL Local Parameter Declarations

FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++0019.20 01 SBRLCL-CONTEXT.0019.30 * Define local variables for subroutine SA1INFN.0019.40 03 WL0001 PIC X(6).0019.50 03 WL0002 PIC X(6).0019.60 03 WL0003 PIC X(6).0019.70 03 WL0004 PIC X(6).




The generator would have to treat a single occurrenceof the EXCINTFUN function as if it were being usedmore than once so that the local variables would begenerated. A data structure for the local variables wouldthen be required, much the same as parameters definedon EXCEXTFUN function types are declared, resultingin parameter declarations as in figures 22, 23 and 24.

PRn is not very user friendly for the duplicateparameter contexts. You need to refer back to the EditFunction Parameters screen to determine what thecontext intended use is, known as the program context.Although, there are some screens in the action diagramthat do show the program context and parameter

context, such as the Edit Action Condition screen, andcommand key F22 will display the duplicateparameters. It would have been more developer friendlyif you could have used the program context within theaction diagram instead of PRn.

Imagine if you could define PR1 as program contextLOC and use LOC instead of PR1 inside the function.This would provide you with an explicitly declaredlocal parameter instead of using the supplied LCLcontext, which is implicitly declared to the function.The implicit nature of LCL context created a great dealof debate when it appeared as it inherited several flaws

Figure 22: New EXCINTFUN COBOL Local Parameter Declarations

FMT CB ......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++0019.20 01 SBRLCL-CONTEXT.0019.30 * Define local variables for subroutine SA1INFN.0019.31 03 WLSAP10019.40 05 WL0001 PIC X(6).0019.50 05 WL0002 PIC X(6).0019.31 03 WLSAP20019.60 05 WL0003 PIC X(6).0019.70 05 WL0004 PIC X(6).

Figure 23: New EXCINTFUN RPG III Local Parameter Declarations

FMT DS .....IDsname....NODsExt-file++.............OccrLen+...............0003.90 IWLSAP1 DS 120004.00 * RCD: Order Product Retrieval index0004.10 * I : MAP Order Number0004.20 I 1 6 WL00010004.30 * I : MAP Product Code0004.40 I 7 12 WL00020004.50 IWLSAP2 DS 120004.60 * RCD: Order Product Retrieval index0004.70 * I : MAP Order Number0004.80 I 1 6 WL00030004.90 * I : MAP Product Code0005.00 I 7 12 WL0004

Figure 24: New EXCINTFUN RPG IV Local Parameter Declarations

FMT D .....DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++0009.19 D Wlsap1 DS 120009.20 D Wl0001 1 60009.30 D Wl0002 7 120009.31 D Wlsap2 DS 120009.40 D Wl0003 1 60009.50 D Wl0004 7 12




from WRK context and has the possibility ofintroducing errors into your applications11.

There is a new file in the data model to support theduplicate parameter contexts. The file name isYPARCTXRFP and contains details about the mappingof the function local parameter surrogate and programcontext. It is an extension of the file YMSGPARRFP.

It should be noted that comparing duplicate parametercontexts using *ALLPARMS may not work forCOBOL generated programs. The PnPARM datastructure only contains the fields with a declared usage.For it to work in COBOL the same fields should bedeclared with a usage in both of the duplicate parameterentries.

Componentisation and LogicExtraction

Componentisation and logic extraction is the process oftaking a single large function and dividing it intosmaller, more manageable functions that fit the conceptof modular design. Release 7.0 provides a new featurethat automates this whole process, known as wrapping.

It was originally designed to enable co-existence ofCOOL:2E and COOL:Plex so that COOL:Plexdevelopers could interface with COOL:2E existingapplications via the Application Intergrator/2E product.The intention here was to enable a COOL:Plex e-business application to interact with an existingCOOL:2E application. The extracted logic could beused by any other third party e-business developmenttool. This is not only an e-business enablement featureas there are significant advantages in usingcomponentisation and logic extraction for COOL:2Edevelopers.

During Alpha testing of Release 7.0, a client using anearlier version of COOL:2E wanted a function to beconverted from an EDTRCD to an EDTFIL functiontype. The original developer of the EDTRCD functionhad not used modular development and the actiondiagram, when printed, was dozens of pages long. TheEDTRCD function would still be used in the

11 HawkBridge, 1999. An Independent Review of COOL:2E Release6.2. Release 6.1 Enhancements - Local Context, p3.

application, so duplication of action diagram logic hadto be reduced for improved productivity in maintainingthe functions.

The conversion process was to extract the logic fromthe EDTRCD function into re-usable EXCINTFUNfunctions so that it could be used in the EDTRCD andEDTFIL functions without duplicating any actiondiagram code. This proved to be a very time consumingprocess, taking almost a week for one developer tocomplete. The difficulty lies with trying to identify anddefine the parameters for the EXCINTFUN functionsused to wrapper the action diagram code. Withoutduplicate parameter contexts the process was verytedious especially as there where possibly four differentcontexts per field, DB1, KEY, DTL, and PAR context.

Had we been using Release 7.0 to perform theconversion of the EDTRCD to an EDTFIL functiontype, it would have taken minutes to perform instead ofdays. On top of that the manual process is very prone touser error and requires substantial testing to ensure itwas accurate. If one conversion can save almost a weekfor one developer, then we will save months of workper year in re-using business logic just by using thisfeature alone in Release 7.0. Not to mention the timeand resources saved with the reduction of duplicateaction diagram code.

Wrapping makes use of duplicate parameter contexts inorder to replace device specific contexts not found inEXCEXTFUN and EXCINTFUN function types. Whena field is found in the original section of action diagramcode that is to be converted to a duplicate parametercontext, a new data model array is created for thewrapping function. An array is used to get around thelimitation of nine parameter entries per function - forfurther details about using arrays for parameters see theCOOL:2E manuals12.

The name of the wrapping function array is set to thename of the wrapping function and a suffix of “PAR”.Where data model arrays have been used for functionparameters, it is necessary to separate them from thenormal arrays so they can be easily identified. A prefixwould have been better than a suffix as it would groupall parameter arrays together and make it easier tosearch for one. However, most organisations wouldprefer 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.




values. One model value would be used for the actualtext to be used, such as “PAR” by default. The othermodel value would be used to determine whether toapply the text as a prefix or suffix, which would besuffix by default.

If a data model array already exists by the namegenerated by the wrapper process, it will allocate aunique name similar to other object names. That is itwill append the surrogate of the object being created tothe end of the object name. As the wrapper process canonly be performed interactively, it would be nice if thedeveloper was presented with a screen to define thearray name to use.

For those people using the wrapper process as part of aco-existence strategy for COOL:2E and COOL:Plex,extracting to an EXCEXTFUN function type is themethod proposed by Computer Associates. This is notthe best method for developing modular applications.Consider extracting to an EXCINTFUN function typeso that the business logic is not embedded inside anexecutable object.

Some uses of the business logic may be in otherCOOL:2E functions which, for performance reasons,may want inline source code instead of the overhead ofa dynamic or static call. After the wrapperEXCINTFUN function has been created, copy it andchange the function type to an EXCEXTFUN function.This will duplicate the parameter structure for youeasily. Next delete all of the action diagram code in theEXCEXTFUN function and replace with code similarto figure 8 and call the EXCINTFUN function. Younow have more flexibility in using the extractedbusiness logic, whether you are interfacing toCOOL:Plex or not.

Batch Processing Enhancements

Functions based on PHY access paths has been inconsiderable demand for many years. EDI applicationsmake extensive use of multi-format physical files,where the first couple of characters of each recorddetermine the record format to be used to un-format therecord.

Processing physical files with COOL:2E in relativerecord number sequence has meant that a temporary

logical file needed to be created. This is necessary toallow functions to process the data in the physical filevia the logical file. When creating records in EDIphysical files another logical file is required to enableCRTOBJ functions to be defined. These extra logicalfiles add a level of unnecessary complexity to theapplication that could be removed with physical fileprocessing.

Release 7.0 allows the PHY access path to be used asthe 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 accesspath, allows a physical file to be processed by relativerecord number. By default the field “*Relative recordnumber” will be added as a positioner to new RTVOBJfunctions that are based on a PHY access path.

The RTVOBJ function based on a PHY access path isimplemented in generated source code similar to theway in which standard RTVOBJ function types areimplemented. However, some differences to normalbehavior should be highlighted.

The RTVOBJ function parameter “*Relative recordnumber” is treated as the key to the physical file. Muchlike keys to standard RTVOBJ functions, you can use arole of either RST or POS for input, both or neitherusage to affect the records processed by the function.

Specifying the parameter “*Relative record number” asan output or both parameter causes the RTVOBJfunction to return the last read relative record number.This is different from standard RTVOBJ functions, asthey never return values implicitly, apart from thereturn code.

Deleting the parameter “*Relative record number” willcause the RTVOBJ function based on the PHY accesspath to read the first record only. However, if there isaction diagram code specified in the user point “USER:Process Data record” it will process all records in thefile. This is exactly how standard RTVOBJ functionsbehave.




CHGOBJ based on PHY Access Path

The default action diagram for a CHGOBJ functionbased on a PHY access path is the same as a standardCHGOBJ function. For the CHGOBJ function based ona PHY access path the generator ignores several userpoints, namely those performing pre-update fileprocessing. This can cause confusion with developers,as they now need to know the based on access path typebefore making changes to a CHGOBJ functions.

The reason for such behavior in CHGOBJ functionsbased on PHY access paths is due to the complexity inconditioning the default action diagram. Although, ithas been done in the past for other function types suchas PRTFIL, PRTOBJ, EDTRCD, EDTFIL, EDTTRNand any function using the post confirm option. Timewas running short for the development lab when thiswas being considered and we are glad that they decidedto keep it in Release 7.0, even with its misgivings.

We would like to see this abnormal behavior removedin a future release of COOL:2E as it further complicatesthe development process and may lead to databaseinconsistencies. Developers could place action diagramcode in an ignored user point thinking it will beexecuted. In fact, it will not be executed which is wherethe database inconsistency can arise.

A CHGOBJ function based on a PHY access path canonly be directly attached to a RTVOBJ function basedon the same PHY access path. This is enforced by theaction diagram editor, but not checked by thegenerators. This can present problems where a modularapproach to development is practiced, or the newwrapper function feature is used to extract the actiondiagram logic.

It may be necessary to move the statements in the userpoint “USER: Process database record” of a RTVOBJfunction based on a PHY access path into anEXCINTFUN function. This will enable it to be sharedamongst other functions. If those statements contain acall to a CHGOBJ function based on a PHY accesspath, then any attempt to edit it within theEXCINTFUN will cause an error. Although, using thewrapper function option will re-map the DB1 context toa duplicate parameter context and the generator willgenerate the correct source code without an error beingsignaled.

There is a work-around for this error, which involvesopening the CHGOBJ function, based on a PHY accesspath and the associated RTVOBJ function based on thesame PHY access path. You can then use the notepad tocopy the CHGOBJ function back to the RTVOBJfunction to perform any changes required to passedparameters. Once the changes have been entered, youcan use the notepad to copy the CHGOBJ function backand replace the original action diagram statement.

The message in the action diagram editor should bechanged from an error message to a warning message,much like domain mismatch warning messages. Thiswould enable you to build your own modular functionsthat make use of CHGOBJ functions based on PHYaccess paths.

DLTOBJ based on PHY Access Path

The discussion on CHGOBJ functions based on PHYaccess paths equally applies to DLTOBJ functionsbased on PHY access paths.

CRTOBJ based on PHY Access Path

The discussion on CHGOBJ functions based on PHYaccess paths applies in most parts to CRTOBJ functionsbased on PHY access paths. The exception to this is thediscussion about calling a CHGOBJ function based on aPHY access path from an associated RTVOBJ functionbased on the same PHY access path.

A CRTOBJ function based on a PHY access pathcannot be included in the same generated HLL programas a RTVOBJ, CHGOBJ or DLTOBJ function based onthe same PHY access path. This is because the filedefinition for creating a record cannot have relativerecord number processing as specified for RTVOBJ,CHGOBJ and DLTOBJ functions based on PHY accesspaths.

New JOB Context Fields

The shipped “*Job data” data model file has beenupdated to include the following new fields along withthe internal DDS name associated with them:




• *Pgm *STATUS STS• *Pgm Previous *STATUS PST• *Pgm *ROUTINE RVN• *Pgm *PARMS PRM• *Pgm Exception msgid MSI• *Pgm Program library PLB• *Pgm Exception data MSD• *Pgm File in error EFL• *Pgm Last file status EFS

These fields have always been available in the formatphysical files Y2PGDSP and Y2PGDSPK forcompiling RPG and COBOL generated programsrespectively. They just have never been included asentries in the shipped “*Job data” data model file.

To fall in line with the naming standards for shippeddata model objects, all of these fields have had theirinternal DDS names changed from four-character tothree-character names. This will present problems toCOOL:2E developers that have modified the “*Jobdata” file in prior releases of COOL:2E to achieve whatis now provided by default in Release 7.0. For thelimited number of COOL:2E developers that have donethis, the fields they have defined will no longer bedeclared in their programs and those programs will failcompilation. The development lab have mentioned thatthey don’t advocate any COOL:2E users changingshipped data model objects in this manner.

There are still some fields on the format physical filesY2PGDSP and Y2PGDSPK that have not beenincluded as entries on the shipped “*Job data” datamodel file. You can still define them as your own fieldsand add them as database relations to the shipped “*Jobdata” data model file. If you have already defined themto your data models in a prior release, there is norequirement to remove them before upgrading toRelease 7.0.

For COBOL generated programs these new fields onthe “*Job data” data model file will not have anypurpose. This is because they relate to the ProgramStatus Data Structure in RPG. COBOL generatedprograms use the shipped program Y2RTJCR toretrieve the JOB context fields at run time, as there isno equivalent Program Status Data Structure inCOBOL.

It has been the objective of the development lab formany years to only include enhancements that could beutilised in all target HLL generators, otherwise it would

not be included. The exception was made here as thesenew fields can be utilised by RPG IV generatedprograms and modules to reduce impact of data modelchanges and monitor for specific program exceptions.

Upgrading From Prior Releases

If you have modified the shipped “*Job data” datamodel file to include the fields listed above, then youneed to perform the following actions before upgradingthe data model to Release 7.0:

• perform some preliminary impact analysis todetermine if the “*Job data” data model file is usedfor passing parameters to functions and messages,

• remove the fields from the shipped “*Job data”data model file by deleting the database filerelationship,

• try and delete the fields from the data model, and• rename those fields you could not delete so they

don’t clash with the new shipped fields.

You will need to assess the impact where the shipped“*Job data” data model file has been used to defineparameters on functions and messages. The followingSQL command will identify all parameter usage for theshipped “*Job data” data model file:

SELECT @@MSG FROM *MDLLIB/YMSGPARRFP WHERE@@FIL = 2

Replace “*MDLLIB” in the above command with thelibrary name of your data model to be analysed.

You can then use the following command to edit theparameters of the function to check if the fields arebeing used or not:

YPRCSFLSEL OBJSGT(@@MSG) SFLSEL(13)

Replace “@@MSG” in the above command with thevalues returned from the prior SQL SELECT command.

If the parameters are being passed as RCD, then youwill need to recompile that function and all callingfunctions to pick up the new record structure. If thefields you will be attempting to delete are passedto/from the function, then these functions will need tobe documented and changed to use the new fields aspart of the upgrade process. Make sure you note theusage of the old fields, as they will disappear from the




parameter list after the next step of removing the fieldsfrom the file.

There may be an impact on EXCUSRSRC andEXCUSRPGM function types that use either of theformat physical files. Scan these functions for usage ofthe new shipped fields old DDS names and correctwhere necessary.

Removing the fields from the shipped “*Job data” datamodel file will ensure that no other developers willinadvertently use them in JOB context. This step shouldonly be started after the impact analysis results havebeen resolved. Deleting the entry on the file will alsoremove the field usage as a parameter on functions andyou will not know if it is actually passed.

If you are able to delete the old fields from the datamodel, then they where not being used in the datamodel. This will save you having to convert them to thenew fields.

Make sure that the names are not going to clash withthe new fields, as this will cause problems in upgrading

the data model.

After upgrading your data model to Release 7.0 you canthen convert the usage of your fields to the new shippedfields. You have one of two options here depending onyour requirements for auditing. Highly structureddevelopment environments with strictly adhered todevelopment and change control procedures willprobably want to fix the fields as part of the upgradeprocess. However, this is not necessary for the majorityof sites where time and resource will not allow thisluxury.

There is no danger of data model or function corruptionin leaving the usage of the fields until a later date. Youwill know if you encounter them during normaldevelopment, as the programs will no longer compiledue to an undefined field. The benefit of this approachis that you are not changing obsolete functions and youcan spread the fix over a longer period.

Figure 25: “Chg Client:R4M” EXCEXTFUN wrapper RPG IV ILE Module

Parameters:Fmt Field name Usg Role File nameKEY Client Code I RST Client Update indexFLD Client Name I Client Update index

Client Address Line 1 IClient Address Line 2 IClient Address Line 3 I

FLD Client Postal Line 1 I Client Update indexClient Postal Line 2 IClient 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‘--




Optional Parameters

While investigating possible uses of the new RPG IVILE enhancements late in 1999, it became apparent thata simple change to the data model could allow optionalparameters to be implemented on RPG IV generatedprograms and modules. We have already discussed howto use RPG IV modules to encapsulate your databaseaccesses and updates to reduce impact of file changes.What we have not discussed is how to reduce theimpact of database change when the parameters to theEXEXTFUN wrapper function change as well.

A change to a database file will mean that theparameters on the CRTOBJ, CHGOBJ and possibly theDLTOBJ functions based on that file will change. Inour example in figure 9 we would also need to changethe parameters to the EXCEXTFUN wrapper functions.This would normally require the calling DSPFILfunction to be re-generated and compiled as well.However, using optional parameters can eliminate theneed to re-generate and compile the calling DSPFILfunction.

If the EXCEXTFUN wrapper functions in figure 9 wereenabled for optional parameters, then we would onlyneed to re-generate and compile the wrapper functions.The DSPFIL function that calls the wrapper functionswould only need to be updated with the commandUPDPGM in order to work. This is assuming that theadditional parameters are not required in order for theDSPFIL function to function properly.

Consider the “Chg Client:R4M” EXCEXTFUNfunction that acts a wrapper for the “Change Client”CHGOBJ function in figure 9. Extra fields are beingadded to the “Client” file for the postal address details.Figure 25 shows the function details required to supportthe new fields with optional parameters. Changes madefor the new fields are in bold italic typeface. There isvery little difference from any normal EXCEXTFUNwrapper function.

The parameters have been declared to the wrapperfunction so that any database change will have the leastamount of impact. There are three parameter entrieswith the same file and access path. The first is passed asKEY and sends all of the key fields to the wrapper

Figure 26: “Change Client” CHGOBJ function

Parameters:Fmt Field name Usg Role File nameKEY Client Code I RST Client Update indexRCD Client Name I Client Update index

Client Address Line 1 IClient Address Line 2 IClient Address Line 3 IClient Postal Line 1 IClient Postal Line 2 IClient 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‘--




function as RST role. The RST role has no affect ongenerated HLL source code, it is only used here fordocumenting the restrictive nature of the function inthat it will only process a single record.

The second parameter entry is passed as FLD and sendsthe original attribute fields to the wrapper functionwithout a role specified.

The third parameter entry is passed as FLD and sendsthe new attribute fields to the wrapper function withouta role specified. The reason for having a separateparameter entry for the additional fields is that theymay have been entered at a sequence mixed in with theoriginal attribute fields. These new attribute fields willbecome the optional parameters and all optionalparameters must be declared below all otherparameters.

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 howmany parameters are being passed. The “ChangeClient” CHGOBJ function will use the value passed inthe “*Pgm *PARMS” parameter to determine whichfields to update on the database as shown in figure 26.

Parameter “*Pgm *PARMS” will have a value of sixwhen the EXCEXTFUN function is called from andoriginal calling function that is not re-generated. Whencalled from a function that is re-generated it will have avalue of nine. You might be wondering why it is sixand nine instead of five and eight. Don’t forget that anexternal function has an implicit return code parameteras the first parameter and this is included in the count ofthe number of parameters in JOB context field of“*Pgm *PARMS”.

The parameters of the CHGOBJ function have beendeclared so that the PAR context fields will not bemapped implicitly to the associated DB1 context fields.The first parameter entry only declares the KEY fieldsand a CHGOBJ function will only use those fieldsdeclared on the first parameter entry for implicitmapping. The second parameter entry contains all ofthe attribute fields, both the original and optional fields.

The reason for not allowing the implicit mapping ofPAR context to DB1 context is that we only want theoptional fields to be mapped when the number ofparameters is greater than six.

Assume that another file change is applied to the“Client” file. We simply add the new fields to the endof the parameters for the EXCEXTFUN wrapper andCHGOBJ functions. Then check for the number ofparameters greater than nine in the CHGOBJ functionbefore updating the next group of DB1 context fields.

This technique seems almost too good to be true. Itprovides developers with greater flexibility inimplementing file changes by reducing the impact of afile change. There is just one flaw in the technique thatwill require a fix to the RPG IV generator from thedevelopment lab.

The definition of the *ENTRY and associated PARMstatements needs to be reformatted to remove optionalparameter usage. Figure 27 shows the current RPG IVgenerated source code for the *ENTRY and associatedPARM statements. The parameters are received into the“WPnnn” fields and mapped into the “Pnxxxx” fieldsby the PARM operation code. Optional parameterscannot be addressed by the program, otherwise aruntime error will occur. Figure 28 shows the changerequired to enable optional parameters to work.

Figure 27: Current RPG IV *ENTRY Parameters

FMT C .....CL0N01Factor1+++++++Opcode&ExtFactor2+++++++Result++++++++Len0007.10 * Entry parameters0007.20 C *ENTRY Plist0007.30 C Parm P0rtn0007.40 C P1aacd Parm Wp00010007.50 C P2aatx Parm Wp00020007.60 C P2abtx Parm Wp00030007.70 C P2actx Parm Wp00040007.80 C P2adtx Parm Wp00020007.90 C P2aetx Parm Wp00030008.00 C P2aftx Parm Wp00040008.10 C P2agtx Parm Wp0004




The reformatting of the *ENTRY and associatedPARM statements could be implemented as a newfunction option for optional parameters, which wouldbe 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 begenerated.

Without this change to the RPG IV generator, we willnot be able to implement optional parameters. One ofthe most dreaded tasks in any AS/400 development,whether it be traditional 3GL or COOL:2E based, isperforming a file change on a widely used file. Anytechnique, which empowers the developer with thecapability of reducing the impact of a file change, addsbenefit to development process.

This technique of optional parameters is not limited tothe RPG IV generator as it can be equally applicable tothe RPG III generator. Unfortunately, COBOL does notallow optional parameters, as the calling program mustmatch the linkage section exactly. Otherwise, a runtimeerror will occur.The optional parameter solution still needs someadditional consideration for parameters specified asoutput or both usage. In or example we have onlyconsidered parameters that are input usage, which arethe easiest to deal with as optional parameters.

Enhanced Object Locking

Objects in the data model can be explicitly locked fromaccidental update or, as Computer Associates wouldhave us believe, for security reasons. An explicit lock isalso known as a permanent lock. Release 7.0 providesnew features to the permanent lock. A 50-characterdescription field has been added and the lock statusdifferentiates between designer and programmerlocking.

Object locking in the data model is a superficialsecurity measure. All locks, both implicit and explicit,are maintained by the COOL:2E tool in a file calledYOBJLCKRFP. There are two data members in thisfile, PRMLCK for explicit locks and YOBJLCKRFPfor implicit locks. Any person with authority to use thedata model can edit the contents of these data membersusing YWRKF, SQL or any other database file utility.

Explicit object locking should not be viewed as asecurity measure because its defence is so weak. It isonly an aid to prevent accidental changes to objects byinexperienced or over-enthusiastic developers.

Adding the 50-character text field with an explicit lockallows a developer to explain why the object is beinglocked. Being confronted with an explicit object lock in

Figure 28: New RPG IV *ENTRY Parameters

FMT C .....CL0N01Factor1+++++++Opcode&ExtFactor2+++++++Result++++++++Len0007.10 * Entry parameters0007.20 C *ENTRY Plist0007.30 C Parm P0rtn0007.40 C Parm Wp00010007.50 C Parm Wp00020007.60 C Parm Wp00030007.70 C Parm Wp00040007.80 C Parm Wp00050007.90 C Parm Wp00060008.00 C Parm Wp00070008.10 C Parm Wp00080008.20 * Check for optional parameters0008.30 C Clear P1parm0008.40 C If ##prm > 10008.50 C Movel Wp0001 P1aacd0008.60 C End...0010.60 C If ##prm > 80010.70 C Movel Wp0008 P3agtx0010.80 C End




the past was more of an annoyance than an aid. Mostdevelopers would simply remove the lock so that theycould perform the changes they required. Having a 50-character text field associated with the explicit lock aidsin communicating why the lock was applied in the firstplace. Maybe the object should not be changed due to apending file change or it is damaged in some way and itshould not be edited.

Explicit object locks in Release 7.0 also store the userclass that applied the lock. If you are editing a datamodel as a designer, then any explicit locks applied willbe designer level locks. If you are editing a data modelas a programmer, then they will be programmer levellocks. Designers can remove other designer andprogrammer level locks. Whilst programmers can onlyremove programmer level locks.

The designer level locks will become the newannoyance of object locking in Release 7.0. This isbecause programmers will be confronted with themwhen there are no designers around to remove them.Programmers will resort to using YWRKF to manuallyremove the record from the YOBJLCKRFP file in orderto do the work assigned to them. The only way to stopthis is to re-design the explicit locking facility to useOS/400 object level authority. If the designerpermanent lock records where kept in a separate file,then that file could be secured using OS/400 databasefile data authority rights. This would provide verysecure object locking capabilities.

Explicit object locks can only be placed on thefollowing object types:

• Access Path,• Array,• Function, and• Message.

The following data model object types cannot beexplicitly locked:

• Application Area,• Condition,• File, and• Field.

Once an explicit lock is applied to an object, the detailsof that object cannot be edited or displayed by any user.There is a display object option from most of the listtype screens, such as Edit Model Object List and

Display Model Usage. This option will not work forexplicitly locked objects.

This is where the frustration begins. Imagine that all theaccess paths on a file have been locked by a designer sothat programmers cannot change the details of theaccess paths. Programmers will not be able to identifywhich access path is the correct one for their taskbecause they cannot view the key sequence or selectomit criteria being used. What are they to do? Theycannot continually bother designers to remove and addexplicit locks as this would lead to very poorproductivity.

The display option needs to be able to view explicitlylocked objects without having to remove the lock. If thelock is removed, in most cases it will never be reappliedand the benefit of the object lock is removed.

It would be nice to be able to explicitly lock fields andconditions. Fields are divided into two differentcategories of usage, database and function. Databasefields are typically created by designers and in mostcases should only be maintained by designers. For thisreason, it would be nice to be able to place explicitdesigner level locks on fields. This will preventprogrammers from changing them. If a function field isbased on a database field, then the conditions associatedwith the database field should be available toprogrammers to edit from the function field.

Softcopy Manuals

You will notice a change to the COOL:2EDocumentation CD-ROM provided with Release 7.0.There is a Computer Associates splash screen, but theunderlying documents remain mostly unchanged fromRelease 6.2.

The function structure charts have found their way backinto the Building Applications manual after theiraccidental removal on the Release 6.2 DocumentationCD-ROM.

None of the Release 7.0 enhancements have been addedto the manuals, apart from the Release 7.0 Summarydocument. Even more reason for this review. ♦







Release 7.0 Significant Fixes

With most major releases of COOL:2E, the emphasis ofdevelopment has been on providing majorenhancements to the tool. Whereas with point releases,such as Release 6.2, the emphasis has been on reducingthe ever growing list of issues identified by users ofCOOL:2E or providing minor enhancements. Release7.0 is no exception to this general rule of thumb.

The number of fixes that have been identified withRelease 7.0 is very small. Most of them have beenapplied as a result of the extensive RC1 testing that wasconducted by dedicated COOL:2E users.

The COOL:2E Release Summary 7.0 provided byComputer Associates on the COOL:2E Documentation7.0 GA CD-ROM contains a list of fixes applied toRelease 7.0 and the various PTF’s for Release 6.2.Several of the fixes under the Release 7.0 fix list wereactually fixed in a prior PTF for Release 6.2.

Of the fixes that were applied in Release 7.0 we haveidentified three that deserve a mention because theywill affect the manner in which you use COOL:2E.

Submit Job Override Option

Prior to Release 7.0, the submit job override option fora call to an EXCEXTFUN, EXCUSRPGM or PRTFIL

function would default to “*” for model value override.This meant that developers tended to use the modelvalue by mistake, which caused other functions tosubmit jobs with the new default values when re-generated. Release 7.0 now defaults the submit joboverride option to “L” for local override.

While we are discussing the submit job options,Release 7.0 enables an RPG IV ILE module to besubmitted. This is an error as ILE modules cannot becalled directly and the submitted job will fail withprogram not found.

SELRCD Partial Key Parameters

When a SELRCD function is defined with partial keyparameters as in figure 29, the parameters generated inthe target HLL included all of the key fields. This wasfixed to only generate the declared parameters. The fixwas available with Release 6.2 PTF 62030.

This fix was identified as part of the backwardcompatibility test and there are upgrade issues to beaddressed. See a full description of this issue andtechniques for identifying the issues and resolving themin the Backward Compatibility Test section.

Figure 29: SELRCD Function Partial Key Parameters

Parameters:Fmt Field name Usg Role File nameKEY Order Number I RST Order Product Retrieval index

Product Code




Long Condition Values

When condition values exceed 21 characters, theoperator is changed to “++”. This caused generationproblems and attempts to correct the problem byreducing the condition value failed to remove the “++”.The work-around required the developer to use thecommand YWRKF to remove the “++” from theYCNDDTARFP file in the data model. This has nowbeen resolved in Release 7.0 so that when you edit thecondition the “++” will be removed when the fieldcondition value is reduced in length below 21characters. ♦




Backward Compatibility Test

Moving to a new release of COOL:2E is not as straightforward as the installation manual13 would have youbelieve. You cannot just install the new Release,upgrade your data models and expect that yourapplications will generate and function as they did inthe earlier releases.

With each release there are changes to target HLLgenerators, which could impact on the way yourapplications function. For instance, one of the earlierreleases of Synon/2 in the late 1980’s changed the wayin which the return code was set in RTVOBJ functions.They used to return the message identifier for datamodel message “*Record does not exist” when a recordwas not found. The change that occurred was to returnthe message identifier of the record not found messageassociated with the file that the RTVOBJ function wasbased on. Applications that used to test for the explicitreturn code value of “*Record does not exist” no longerfunctioned correctly.

In this section, we document the method and approachused to conduct the backward compatibility checks.You will be able to repeat the backward compatibilitytest process in your own development environment fora greater level of assurance. This will provide the levelof assurance required by most users to move to Release7.0 without the need to worry about backwardcompatibility issues.

The backward compatibility test compares the results ofgeneration at Release 7.0 with the results of generationat Release 6.2 PTF 62010. If you are not coming fromRelease 6.2 PTF 62010 or later, then it is advisable foryou to read An Independent Review of COOL:2ERelease 6.214. This will cover moving from earlierreleases to Release 6.2 PTF 62010. 13 Computer Associates, 2000. Installing COOL:2E Products 7.0.14 HawkBridge, 1999. An Independent Review of COOL:2E Release6.2.

Test Objective

The objective of the backward compatibility test is toensure that data models migrating from an earlierrelease will be capable of generating the same orsimilar source code. A data model should be capable ofbeing migrated to Release 7.0 without any changeshaving to be performed to functions, device designs oraccess paths.

Test Data Models

For the backward compatibility test, we used copies ofour clients largest data models. We used two RPG andone pure COBOL data model, which enabled us tocheck both of the current target HLL generators.

It should be noted that the following features were notused largely in any of the data models and as such werenot 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.




If you rely upon any of these features extensively, thenit is advisable for you to conduct your own backwardcompatibility test.

First RPG Data Model

Our first client is currently at Release 6.0 andgenerating RPG. The data model is 10 years old. Thefollowing details were captured using COOL:PE:

• 394 entities,• 1489 access paths,• 5015 fields,• 2617 internal functions, and• 1613 external functions.

Detailed statistical reports are contained in Appendix A.

Second RPG Data Model

Our second client is currently at Release 5.2.1 andgenerating RPG. The data model is almost 10 years old.The following details were captured using COOL:PE:


Detailed statistical reports are contained in Appendix B.

COBOL Data Model

Our third client is currently at Release 6.0 andgenerating COBOL. They have also applied severalPTF’s to rectify certain COBOL issues. The data modelis around 7 years old and has under-gone several majorenhancements. The following details were capturedusing COOL:PE:


Detailed statistical reports are contained in Appendix C.

Test Plan

The test plan for the backward compatibility testinvolved the following sequence of events:

• Convert data models to Release 6.2 PTF 62010,• Create a snapshot using COOL:PE,• Mass re-generate data models,• Convert data models to Release 7.0 RC1,• Create new generation libraries,• Mass re-generate data models,• Compare source members for differences, and• Analyze difference reports.

The data models where all converted to Release 6.2PTF 62010 as the starting point of the backwardcompatibility test. This release was the target of our lastbackward compatibility test and so there was no need totest the move from any prior release.

We used COOL:PE, the performance expert tool fromComputer Associates, to create a snapshot of the datamodels. This was used to allow us to produce thestatistical analysis reports of the data models to give thebackward compatibility test some form of quantitativemeaning.

Mass re-generation is never easy. There are issues withstorage allocation in PLI programs that prevents a largedata model from re-generating in one pass. It requiredseveral attempts to mass re-generate the data models.The development lab has advised us that this issuecannot be resolved as it is a limitation with the PLIcompiler and is not within their control.

We used the CRTJOBD(*NONE) parameter on theYSBMMDLCRT command to stop the compilation ofthe generated objects. Our interest is in obtaining thegenerated source and not wasting testing time andresource to compiling objects.

A new generation library was created for each of thetest data models. The library was created using theCRTLIB command and then the following commandwas executed to create the necessary objects forgeneration:




YCRTGENOBJ OBJLIB(*NEWGEN)

Replace “*NEWGEN” in the above command with thenew generation library name. The current library listmust contain the data model and generation libraries ofthe data model that the will be associated with newgeneration library.

Using the YCRTGENOBJ command to create a newgeneration library produces more objects in the newgeneration library than exist in the from generationlibrary. If we where to just copy the objects from theold generation library it would have taken longer tocopy all of the generated source file members. Also, wedid not want the results of the previous mass re-generation to exist in the new generation library. Thiswould have made it difficult to identify failed objectgenerations during source file member comparison.

The data model value YGENLIB, job descriptionlibrary lists, and data model library list was updated byreplacing the old generation library with the new one.

Source file members for all EXCUSRSRC functionswhere copied from the old generation library to the newgeneration library. You can achieve this by building amodel object list of them all, or subsetting the*ALLOBJ model object list, and executing thefollowing command against the entries:

CPYF FROMFILE(*OLDGEN/*SRCF)TOFILE(*NEWGEN/*SRCF) FROMMBR(&YI)TOMBR(*FROMMBR) MBROPT(*REPLACE)

Replace “*OLDGEN” in the above command with theold generation library name; “*SRCF” with the sourcefile 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 usefunction F13 to repeat that option to the bottom of themodel object list. Then place the above command onthe command line and press the Enter key.

The second mass re-generation generated the sourceinto the new generation library, thus preserving theresults of the first mass re-generation. We used thesame options as used for the first mass re-generation.

We compared the source file members in QDDSSRC,QLBLSRC and QRPGSRC from the new generationlibrary to the same source file member in the old

generation. The following command was used tocompare source file members:

CMPPFM NEWFILE(*NEWGEN/*SRCF) NEWMBR(*ALL)OLDFILE(*OLDGEN/*SRCF) OLDMBR(*NEWMBR)RPTTYPE(*DIFF) OUTPUT(*PRINT)OPTION(*OMTxxxCMT)

Replace “*OLDGEN” in the above command with theold generation library name; “*SRCF” with the sourcefile name, such as QRPGSRC, QLBLSRC orQDDSSRC; and “*NEWGEN” with the new generationlibrary name.

The value specified for the OPTION parameter shouldbe replaced with either “*OMTRPGCMT”,“*OMTCBLCMT” or “*OMTDDSCMT” dependingupon the source file being compared. This optionremoves comment lines from the comparison.Comments have no impact on the compiled object andare not within the scope of the backward compatibilitytest.

The most time consuming task of the backwardcompatibility test is the physical check of the differencereports produced by the CMPPFM command above.Our largest report was 830 pages long followed by 608pages and then 241 pages for the COBOL QLBLSRC,first RPG QRPGSRC and second RPG QRPGSRC filesrespectively. This step is prone to errors of omission, asit requires human involvement to visually scan thereports for incompatible differences. It is quite possiblefor some errors to be missed, particularly when theyoccur infrequently throughout the difference report.

Testing is not an absolute method of removing errors,whether it is backward compatibility testing, systemtesting or any other type of test. Testing is a method ofproviding quality assurance and not a process wherebyall errors are identified and removed from the processor application being tested. For this reason, we do notoffer any guarantees with the results andrecommendations of the backward compatibility test.

Test Results

The backward compatibility test identified very fewchanges in the RPG III and COBOL generators. Thosethat we did find were connected with fixes or




preparations for the implementation of the RPG IVgenerator.

YAPYSYSMDL Audit Report

Make sure you read the audit report produced duringthe conversion of your data model to Release 7.0. Wefound that it produced a warning for an issue with thenew JOB context fields that prevents one of our clientsfrom upgrading to Release 7.0.

The new JOB context fields added for Release 7.0 areadded to the data model during the upgrade process.Should a field already exist using the DDS name of thenew JOB context fields, then the DDS name of thatfield will be cleared. If that field appears on databasefiles, as it does for our client, then you have to re-generate that file and all impacted files and functionsafter setting the DDS name to a valid value. This is notan option when it impacts most of the data model andtesting of all generated functions is a necessity.

The problem is not with the re-generation, but theamount of time and effort in testing the re-generation.We have inherited an issue in change control practicewith the particular client whereby previous developershad not kept the generated source of objects moved toproduction. The data model is old enough to have gonethrough several upgrades and data model changes andthe generated source produced today does not functionas it did when the function was originally generated. Ifthey had kept the original generated source filemembers, then testing would only have been a matter ofcomparing them to identify differences.

There is another issue with the audit report in that itdoes not include all of the fields that where added to thedata model. The only fields reported are “*Pgm*STATUS” and “*Pgm *PARMS”. The remainder ofthe new JOB context fields do not appear on the reportalthough 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 whenthe SELRCD function or any calling function is re-generated. The calling function will have a runtime

error with parameter mismatches unless all impactedfunctions are re-generated and compiled.

Use the following two SQL SELECT statements toidentify SELRCD functions with partial key parametersdefined:

SELECT DISTINCT MSG.@@MSG, MSG.SRCMBR FROM((YMSGDTARFP MSG JOIN YACPDTARFP ACP ONMSG.@@ACP = ACP.@@ACP) JOIN YACPENTRFPAPE ON MSG.@@ACP = APE.@@ACP) LEFT OUTERJOIN YMSGPDTRFP PDT ON MSG.@@MSG =PDT.@@MSG AND APE.@@FLD = PDT.@@FLDWHERE 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 ONMSG.@@ACP = ACP.@@ACP) JOIN YENTDTARFPENT ON MSG.@@FIL = ENT.@@FIL) LEFT OUTERJOIN YMSGPDTRFP PDT ON MSG.@@MSG =PDT.@@MSG AND ENT.@@FLD = PDT.@@FLDWHERE ENT.ENTTYP = 'K' AND ENT.ENTSEQ <>0 AND ACP.OBJATR = 'RTV' AND MSG.@@MSG_P= 9000500 AND (PDT.PARUSG = ' ' ORPDT.PARUSG IS NULL)

The reason for two separate SQL SELECT statementsis that RTV access path types store their key fieldsdifferently than RSQ or QRY access path types.

You can then use the following command to edit thefunction parameters:

YPRCSFLSEL OBJSGT(@@MSG) SFLSEL(13)

Replace “@@MSG” in the above command with thevalues returned from the prior SQL SELECTstatements.

To determine which functions use the SELRCDfunction you may have to use 3GL cross-referencetechniques. This is because the implicit select recordprocessing for display functions cannot be identifiedusing the YDSPMDLUSG command. A simpletechnique is to use the command DSPPGMREF todocument all of the programs in your application to anoutput file. Then use either SQL or Queries to findreferencing programs.




RPG III MOVEL with P Operation Extender

The use of the P operation extender on the MOVELoperation code15 has been used extensively in RPG IIIgenerated source code. This will pad the result of theMOVEL 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 beinginitialised to blanks or zeros prior to the MOVELoperation. This unnecessary operation has beenremoved.

There are no backward compatibility issues regardingthis change. Although, very minute changes in runtimemight be achieved due to the reduction in the number ofMOVEL operation codes being used.

RPG III Result Field Declaration

The use of field length and decimal positions oncalculation specifications has been minimised. Inparticular the declaration of the ZAMSDA, @1FFL,@1FLB and @1FMB fields has been removed fromcalculation specifications.

We suspect that this change was linked with thechanges made for the RPG IV generator. As mentionedearlier, this release of the RPG IV generator makes useof some of the RPG III generator programs. Having thedeclarations in the calculation specification may havereduced the capability of converting them to the newdefinition specification.

There are no backward compatibility issues regardingthis 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.2PTF as it can be reproduced at PTF 62050.

There are no backward compatibility issues regardingthis change. It is just an unnecessary piece of sourcecode.

15 IBM, 1994. IBM Application System/400 - RPG/400 Reference,Edition 1. Document Number SC09-1817-00. Chapter 11, OperationCodes. Section 11.14 Move Operations.

COBOL RTVOBJ and Qualified by Relation

The COBOL source code generated for a RTVOBJfunction based on an access path that uses a key fieldresolved from a “Qualified by” relation has changed.The resultant source code is around 50 or so lines lessin Release 7.0. This is because they are no longer usingthe START GREATER THAN and READ PRIORstatements. Instead, they are using the dynamic fileprocessing associated with the READ statement.

The use of indicator 91 has also been removed from thegenerated source code. This indicator was redundant asit was always set off after it was set on for an input-output error with the START statement.

There is an outstanding question with developmentregarding a possible source code generation error. Thefull externally described key list is loaded with lowvalues, but is never moved into the corresponding fieldsof the record format of the file being accessed. Thisseems to only occur when fully restricted keyparameters are declared to the RTVOBJ function. Ifthey have intentionally dropped the MOVECORRESPONDING statement, then the full externallydescribed key list is a redundant data structure.However, if it has not been intentionally dropped itcould result in the wrong record being read from the filedepending on the circumstances that produce thisbehavior.

Conclusion

The two RPG data models used for the backwardcompatibility test can migrate to Release 7.0 fromRelease 6.2 PTF 62010 without any changes. OtherRPG data models may have issues with conflicting fieldDDS names on the YAPYMDLCHG audit report.

The COBOL data model cannot migrate to Release 7.0due to the problems with conflicting field DDS nameson the YAPYMDLCHG audit report and the possibleissue with RTVOBJ functions using key fields resolvedfrom a “Qualified by” relation. ♦







Future Direction

February 14 is a day that most people will remember asSaint Valentines Day. This year, for Sterling Softwareemployees and clients, it marks the day that ComputerAssociates announced its intention to buy SterlingSoftware. It took seven weeks for the purchase to beapproved by various regulatory bodies and on April 3this year, it was formally announced by ComputerAssociates.

During E-Strategies at CA-World 2000 in New Orleanson April 10 this year, we heard about the futuredirections of COOL:Plex and COOL:2E from WasimAhmad. It was hard for Wasim to discuss the future ofthe products, considering that Computer Associates hadnot publicly announced its intentions. The presentationcovered the next releases of both products, which at thetime were almost ready for delivery into RC1 testing.

On April 11 this year, Computer Associates issued theroadmaps that would outline the future direction of theSterling Software products. This amounted to a verybroad statement about “continuing to support andextend the Sterling COOL family of applicationdevelopment and modeling products”.

Later that same day, Wasim re-gave his presentationfrom the previous day. This time he was able todisclose more detail about the direction that theproducts would move under the ownership of ComputerAssociates. Although, he could not provide any datesfor delivery. For COOL:2E it was announced that theywould provide better support for applications toincrease e-business interoperability.

Amongst the offerings were an XML interface, HTMLgeneration, and possible integration with Jasmineii.Interesting to note that the future direction of all theCOOL products is e-business centered and in particularthey were to integrate through Jasmineii.

In September of last year, Sterling Software issuedsimilar statements of direction for COOL:Plex andCOOL:2E. Release 7.0 of COOL:2E is the result of thatstatement of direction and there is very little in the wayof e-business enablement in the new features andenhancements. Although, we are pleased with what hasbeen delivered in Release 7.0 as it extends the life ofour applications by allowing us to move to RPG IV andILE.

At ISSUG 2000 in Paris on June 13 to 16 this year, thepresentations by Computer Associates were almostidentical to those given at CA-World in New Orleansearlier this year. There was no new information aboutproduct directions under Computer Associates or datesfor delivering them.

Computer Associates issued the detailed roadmaps forthe COOL products in July of this year. Again itmentioned the move to e-business enable COOL:2Eand for the first time we see statements about futureenhancements that are not related to e-business. TheCOBOL ILE generator will be provided along withbetter support for ILE development “allowing morecontrol over the ways applications are created andhelping them to perform faster”.

Development of the next release of COOL:2E beyondRelease 7.0 is already underway in the lab. So far, wehave not been involved in that release and there hasbeen no public statement by Computer Associates aboutthe progress and content of the next release. Let aloneany mention of delivery dates. Like many otherCOOL:2E users, we will have to wait and see. Just asRelease 7.0 was the release to determine the future ofCOOL:2E under the management of Sterling Software,this next release will provide us with an indication ofComputer Associates future intentions with COOL:2E.




E-Business Direction

The strategic direction for COOL:2E under themanagement of Computer Associates is e-business.They believe that e-business covers everything fromelectronic business to wireless e-business and anyonenot looking at this will go bust or cease to besignificant.

We disagree with the amount of emphasis being placedon e-business. E-business is not the only aspect of anapplication, yet with the amount of press it receives onewould think it was the only part of business. The onlyparts of COOL:2E applications that need to be e-business enabled are the delivery and presentation ofdata. You don’t need any special e-business features toprepare that data for e-business and it would be verysimilar to the way that EDI applications havefunctioned in the past.

It was revealed at ISSUG 2000 in Paris, during theCOOL:Plex and COOL:2E Technical Panel Discussion,that there are three stages for e-business enablement inthe plan for COOL:2E. The first stage is delivered withRelease 7.0, which was to provide dynamic webenablement through NewLook, from Look Software PtyLtd16. The second stage in the e-business plan forCOOL:2E is to extend COOL:2E to the web viaJasmineii. The third and final stage is to generateHTML for Jasmineii.

Dynamic Web Enablement with NewLook

The first stage in e-business enablement of COOL:2Erequired no change what so ever to the base COOL:2Etool. NewLook interfaces with the 5250 data-stream inorder to provide a dynamic graphical user interface.Although, Look Software do have plans to provide anAS/400 based server program to provide moreinformation to NewLook at run-time about theapplication. This server program may be capable ofreading and processing information stored in theCOOL:2E data model. However, for now there is nointerfacing of NewLook with the underlying data modelthat generated the screens that it interprets. This meansthat any prior release of COOL:2E will be capable ofgenerating applications that will run under NewLook,not just Release 7.0. 16 Look Software Pty Ltd, http://www.looksoftware.com/.

NewLook is not just a dynamic web enablement tool. Itcan also function as a replacement for your 5250emulator on the corporate LAN or WAN. It allows youto quickly convert standard green screen applications topoint and click applications with dynamic integrationwith desktop applications. Its rules based interpretermakes GUI conversion projects almost obsolete.

Jasmineii Bridge to AS/400

Jasmineii will allow you to “create e-businessapplications, re-use investments on other platforms, andleverage a rich integration environment”17. It has notbeen disclosed what will be provided to Jasmineii forthis stage and when it will be delivered. It looks as if itwill only benefit those COOL:2E customers thatpurchase Jasmineii as it will only be “accessible viaJasmineii providers”.

Jasmineii does not currently have a bridge to theAS/400, but it has been mentioned in the Roadmap as afuture enhancement. The bridge will enable COM andEJB applications on other platforms to accessCOOL:2E applications. The wording in the Roadmaptends to suggest that it may be possible to interface withnon-COOL:2E generated applications. This wouldallow Computer Associates to sell their Jasmineiiproduct to a larger AS/400 customer base.

We don’t believe that Computer Associates understandhow loyal AS/400 users are to IBM mid-range. If theydid, then they would realise that most COOL:2E usershave no interest in Jasmineii or any other product thatdoes not reside on the AS/400. Most sites, which weknow of, have a single development team that onlyproduce AS/400 applications. Why should they have aneed for an application integration tool like Jasmineiiwhen their applications are already integrated on theAS/400. The AS/400 can also now function as thecomplete e-business hardware solution, so there is noneed to have separate NT, UNIX or other web servers.

Jasmineii was designed for UNIX, NT and Windowsenvironments where there is a plethora of disparateapplications in dire need of integration. Providingenhancements to COOL:2E that benefit only Jasmineiiusers will further alienate Computer Associates fromtheir existing COOL:2E customer base.

17 Computer Associates, July 2000. Roadmap for COOL Products.




HTML Generation for Jasmineii

We suspect this also incorporates the generation ofXML from COOL:2E data models, although it was notspecifically mentioned in Paris. The generated HTMLand XML may not be specific to Jasmineii. Whichmeans you could possibly use this feature to build webapplications for other third party products.

ILE Generator Direction

More than half of those attending the COOL:2EDeveloper Round Table during E-Strategies at CA-World 2000 believe that ILE is more important thanany other enhancement in COOL:2E. The continuedenhancement of COOL:2E in this area will be the mostappreciated and will maintain customer loyalty inCOOL:2E.

IBM is placing more emphasis on RPG IV ILE in thehope of making it a mainstream development language.Recent announcements have indicated that it will evensupport new data types for Java classes and methods.This will allow RPG IV ILE programs and modules tointeract with Java applications. The reverse is alsoavailable whereby a Java application can interact withan ILE application. This feature and others are set toencourage a lot more applications to be developed onthe AS/400. Should you be using IBMs web servingtools on the AS/400 then seamless integration of e-business applications with traditional AS/400applications will be possible.

COBOL ILE Generator

The COBOL ILE generator has been identified as afuture enhancement for COOL:2E. This provides uswith some comfort that they might understand theircustomers by providing an incentive to some COOL:2Eusers that are not e-business focused.

The amount of time and effort required to convert theexisting COBOL generator into a COBOL ILEgenerator is considerably less than that required for theRPG IV ILE generator. This is mainly due to thesimilarity in the syntax of the OPM and ILE versions ofCOBOL. For this reason, we expect the COBOL ILE

generator to be delivered as a point release of Release7.0. Although, no details and dates have been providedby Computer Associates.

Further ILE Support

Release 7.0 is the first step in a multi-phaseimplementation of ILE within COOL:2E. It hasprovided the very basic ILE features so organisationscan commence to convert their applications to ILE. Inorder to fully support ILE within COOL:2E there willbe a need to include the following features, some ofwhich have already been discussed in this document:

• all ILE primitive data types,• procedures,• mixed language development,• ILE and service programs,• ILE module traceability and update,• optional parameters, and• multiple binding directories.

The detailed roadmaps for COOL products did not gointo 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 ILEdevelopment. In “allowing more control over waysapplications are created”, we suspect they mean toprovide support for CRTPGM and CRTSRVPGMcommands. To “help them to perform faster”, wesuspect they intend providing support for proceduresmuch like modules are provided in Release 7.0.

New Sales Opportunity

The single largest enhancement in Release 7.0 is theRPG IV ILE generator. This single enhancement willbe of more value to COOL:2E users than any e-business enablement enhancement. It offers theopportunity to use new language features on the AS/400and better integration into other ILE applications. IfComputer Associates are true to their word in furtherenhancing COOL:2E to fully support ILE development,then COOL:2E could once again be in a position toexpand its user base.




At E-Strategies at CA-World 2000 in New Orleans,during the COOL:2E Developers Round Table, it wasraised that the tool should be enhanced to enableexisting AS/400 3GL development sites a bettermigration path. Wasim Ahmad quoted that only 20% ofthe 500,000 AS/400s sold are used for development andthat only 20% of them use CASE tools. This means thatthere are 80,000 development AS/400s using 3GLdevelopment techniques and would be potentialCOOL:2E customers.

IBM is enhancing the capabilities of RPG IV ILE in thehope that it will provide enough reason for RPG IIIcustomers to migrate. Since its debut in the early 1990s,RPG IV ILE has never really taken off as a mainstreamdevelopment language. This is mainly due to thecomplexity of the ILE development environmentcompared to traditional OPM development and thesignificant changes in the syntax and semantics of thenew language. COOL:2E could become a tool thatsimplifies ILE development making it a necessity forevery AS/400 ILE development site.

Release 7.0 of COOL:2E provides the basic enablementof RPG ILE application generation in the first step of amulti-phased implementation of a fully ILE compatiblegenerator. Before COOL:2E could be sold to traditional3GL development sites as an ILE management tool,there would need to be full support for all of the ILEfeatures. When everyone sees how easy it is forCOOL:2E developers to implement and maintain ILEapplications, they will be convinced of its power as anILE development tool. ♦




Conclusion

Release 7.0 is a significant enhancement ofCOOL:2E that will benefit the majority of COOL:2Eusers. Had COOL:2E remained with SterlingSoftware, I would have said that it demonstratedSterling Software were committed to the product.However, Computer Associates now own COOL:2Eand we will have to wait until the next release beforesuch a statement can be made about ComputerAssociates commitment to the product.

The introduction of an RPG IV ILE generator willgreatly increase the life and viability of ourapplications and the proposed COBOL ILE generatorwill enable all COOL:2E users to benefit.

Many organisations are looking at modernisationprojects now that the Y2K projects have ceased toimpact the IT budget. The enhancements to extractbusiness logic into re-usable routines enablesmodernisation projects to save considerable time andeffort over manually converting functions.

EDI applications stand to benefit the most from thebatch processing enhancements. Developers will nolonger be required to create and maintain data modelobjects just to process a physical file in the datamodel.

The future releases for COOL:2E under themanagement of Computer Associates have yet to bescheduled. Further extensions to the ILE generatorswill probably be the most appreciated enhancementafter users get a taste of ILE in Release 7.0.

From where we stand, COOL:2E will have a brightfuture under the management of ComputerAssociates as long as they continue to deliversignificant enhancements that are relevant to themajority of the users. ♦







Appendix A: First RPG Data Model

The following reports have been produced for thefirst RPG data model used for backwardcompatibility 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 beenremoved to protect client confidentiality.

Consult the COOL:PE manual supplied on thedocumentation CD-ROM for details about how tointerpret these reports.




Figu

re A

-1: F

ile S

tatis

tics R

epor

t

FileStatisticsReport

File

File

type

Description

Count

CPT

DBFCapturefile

103

RCD

Recordformat

0REF

DBFReferencefile

252

STR

Structure

39

Total

394

***ENDOFREPORT***

(c)1998SterlingSoftware.




Figu

re A

-2: A

cces

s Pat

h St

atis

tics R

epor

t

AccessPathStatisticsReport

Access

Access

Have

Index

Index

Index

Static

Dynamic

ALTCOL

path

path

unique

maint

maint

maint

select

select

table

type

Description

count

keys

immed

rebuild

delay

/omit

/omit

count

PHY

Physical

383

00

00

00

0UPD

Update

386

386

386

00

00

0RTV

Retrieval

412

412

412

00

16

20

RSQ

Resequence

294

31

281

013

34

90

SPN

Span

14

011

03

81

0QRY

Query

00

00

00

00

Grandtotals

1,489

829

1,090

016

58

12

0

***ENDOFREPORT***

(C)1998SterlingSoftware.




Figu

re A

-3: F

ield

Sta

tistic

s Rep

ort

FieldStatisticsReport

Func.Base

Field

Field

Field%

of

fielddomain

refer

type

Description

countmodel

countcount

ratio

BVL

BudgetValue

192

3.8

56

1192.00

CDE

Alphamericcodevalue

640

12.7

2370

1.72

DT#

Datein*ISOformat(YYYY-MM-DDinternally)

30

.5

028

1.07

DTE

Dateinsystemdateformat-(YYMMDDinternally)

133

2.6

085

1.56

NAR

Narrativetext

98

1.9

26

98

1.00

NBR

Purenumericvalue(eglinenumber).

813

16.2

1397

2.04

PCT

Percentageormarketindex.

140

2.7

0104

1.34

PRC

Priceortarrif

12

.2

19

1.33

QTY

Quantity

49

.9

028

1.75

STS

Status.

1,089

21.7

128

819

1.32

TM#

Timein*ISOformat(HH.MM.SSinternally)

3.0

03

1.00

TME

TimeinHHMMSSformat.

19

.3

113

1.46

TXT

Objecttext.

1,010

20.1

127

621

1.62

VAL

Monetaryvalue

759

15.1

38

340

2.23

VNM

ValidSystemname

28

.5

711

2.54

Totals

5,015

387

2,927

1.71

***ENDOFREPORT***





Figu

re A

-4: F

unct

ion

Stat

istic

s Rep

ort

FunctionStatisticsReport

%of

Functiontype

Count

functions

Editrecord(1screen)

69

1.6

Displayrecord(1screen)

122

2.8

Editrecord(2screens)

2.0

Displayrecord(2screens)

1.0


15

.3


13

.3

Editfile

186

4.3

Displayfile

248

5.8

Edittransaction

4.0

Displaytransaction

1.0

Prompt&Validate

95

2.2

Selectrecord

146

3.4

Printfile

164

3.8

Printobject

106

2.5

Executeexternalfunction

254

6.0

Executeinternalfunction

179

4.2

Executeuserprogram

293

6.9

Executeusersource

100

2.3

Createobject

350

8.2

Changeobject

441

10.4

Deleteobject

339

8.0

Retrieveobject

1,087

25.6

Derivedfunctionfield

4.0

Sumfunctionfield

11

.2

Grandtotal

4,230

Totalinternal(subroutine)functions.:

2,617

Totalexternal(program)functions

..:

1,613

Totalscreenprogramfunctions

..:

902

Totalreportprogramfunctions

..:

164

Totalbatchprogramfunctions...:

254

***ENDOFREPORT***





Figu

re A

-5: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 1

of 2

)

ActionDiagramInstructionTypeStatisticsReport

%of

Instructiontype

Count

actions

Editrecord(1screen)

141

.2


167

.3


3.0


6.0


36

.0


38

.0

Editfile

179

.3

Displayfile

566

1.1

Edittransaction

8.0

Displaytransaction

2.0

Prompt&Validate

53

.1

Selectrecord

437

.9

Printfile

53

.1

Printobject

154

.3


818

1.6


933

1.9

Executeuserprogram

855

1.7

Executeusersource

365

.7

Createobject

644

1.3

Changeobject

704

1.4

Deleteobject

462

.9

Retrieveobject

4,923

10.1


5.0

Sumfunctionfield

37

.0

Retrievemessage

119

.2

Executemessage

96

.1

Sendinformationmessage

651

1.3

Senderrormessage

2,214

4.5

Sendcompletionmessage

186

.3

Sendstatusmessage

91

.1

Add

2,467

5.0

Subtract

668

1.3

Multiply

1,076

2.2

Divide

582

1.2

Dividewithremainder

39

.0

Computeexpression

50

.1

Move

23,000

47.5

Moveall

844

1.7




Figu

re A

-6: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 2

of 2

)


%of

Instructiontype

Count

actions

Convertvariable

510

1.0

Concatenate

911

1.8

Substring

150

.3

Quit

817

1.6

Exitprogram

1,800

3.7

Setcursorposition

88

.1

Retrieveconditionname

453

.9

Total

48,401

***ENDOFREPORT***








Appendix B: Second RPG Data Model

The following reports have been produced for thesecond RPG data model used for backwardcompatibility testing using COOL:PE:


Report.






Figu

re B

-1: F

ile S

tatis

tics R

epor

t


File

File

type

Description

Count

CPT

DBFCapturefile

9RCD

Recordformat

2REF

DBFReferencefile

217

STR

Structure

8

Total

236

***ENDOFREPORT***





Figu

re B

-2: A

cces

s Pat

h St

atis

tics R

epor

t


Access

Access

Have

Index

Index

Index

Static

Dynamic

ALTCOL

path

path

unique

maint

maint

maint

select

select

table

type

Description

count

keys

immed

rebuild

delay

/omit

/omit

count

PHY

Physical

227

00

00

00

0UPD

Update

226

226

226

00

00

0RTV

Retrieval

226

226

226

00

00

0RSQ

Resequence

108

2107

01

53

0SPN

Span

00

00

00

00

QRY

Query

70

00

00

00

Grandtotals

794

454

559

01

53

0

***ENDOFREPORT***





Figu

re B

-3: F

ield

Sta

tistic

s Rep

ort


Func.Base

Field

Field

Field%

of

fielddomain

refer

type

Description

countmodel

countcount

ratio

CDE

Alphamericcodevalue

499

20.6

0320

1.55

DTX

ExtendedDateField-(CCYYMMDDinternally)

68

2.8

43

22.66

NAR

Narrativetext

1.0

11

1.00

NBR


417

17.2

0108

3.86

PCT


10

.4

06

1.66

QTY

Quantity

198

8.1

18

24.75

STS

Status.

270

11.1

24

88

3.06

TME

TimeinHHMMSSformat.

7.2

02

3.50

TXT

Objecttext.

466

19.2

45

72

6.47

VAL

Monetaryvalue

470

19.4

20

56

8.39

VNM

ValidSystemname

12

.4

23

4.00

Totals

2,418

97

667

3.62

***ENDOFREPORT***





Figu

re B

-4: F

unct

ion

Stat

istic

s Rep

ort


%of

Functiontype

Count

functions

Editrecord(1screen)

16

.7


6.2


1.0

Editfile

130

6.2

Displayfile

92

4.4

Prompt&Validate

74

3.5

Selectrecord

151

7.2

Printfile

69

3.3

Printobject

13

.6


46

2.2


116

5.5

Executeuserprogram

30

1.4

Executeusersource

67

3.2

Createobject

174

8.3

Changeobject

188

9.0

Deleteobject

161

7.7

Retrieveobject

347

16.6


231

11.1

Sumfunctionfield

169

8.1

Grandtotal

2,081


1,466


..:

615


..:

470


..:

69


46

***ENDOFREPORT***





Figu

re B

-5: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 1

of 2

)


%of

Instructiontype

Count

actions

Editrecord(1screen)

13

.0


1.0


2.0

Editfile

31

.1

Displayfile

93

.5

Prompt&Validate

15

.0

Selectrecord

29

.1

Printfile

5.0

Printobject

17

.1


48

.2


1,309

7.8

Executeuserprogram

299

1.7

Executeusersource

900

5.4

Createobject

258

1.5

Changeobject

261

1.5

Deleteobject

168

1.0

Retrieveobject

925

5.5


1,518

9.1

Sumfunctionfield

1,582

9.4

Retrievemessage

353

2.1

Executemessage

151

.9


101

.6

Senderrormessage

398

2.3


9.0

Sendstatusmessage

2.0

Add

437

2.6

Subtract

81

.4

Multiply

319

1.9

Divide

28

.1

Computeexpression

21

.1

Move

6,558

39.3

Moveall

266

1.5

Convertvariable

42

.2

Concatenate

10

.0

Substring

1.0

Quit

161

.9

Exitprogram

250

1.5


1.0




Figu

re B

-6: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 2

of 2

)


%of

Instructiontype

Count

actions

Total

16,663

***ENDOFREPORT***








Appendix C: COBOL Data Model

The following reports have been produced for theCOBOL data model used for backward compatibilitytesting using COOL:PE:


Report.






Figu

re C

-1: F

ile S

tatis

tics R

epor

t


File

File

type

Description

Count

CPT

DBFCapturefile

314

RCD

Recordformat

0REF

DBFReferencefile

110

STR

Structure

81

Total

505

***ENDOFREPORT***





Figu

re C

-2: A

cces

s Pat

h St

atis

tics R

epor

t


Access

Access

Have

Index

Index

Index

Static

Dynamic

ALTCOL

path

path

unique

maint

maint

maint

select

select

table

type

Description

count

keys

immed

rebuild

delay

/omit

/omit

count

PHY

Physical

479

00

00

00

0UPD

Update

477

477

477

00

00

0RTV

Retrieval

482

482

482

00

01

0RSQ

Resequence

452

80

449

12

52

60

SPN

Span

40

40

00

00

QRY

Query

40

20

00

00

Grandtotals

1,898

1,039

1,414

12

52

70

***ENDOFREPORT***





Figu

re C

-3: F

ield

Sta

tistic

s Rep

ort


Func.Base

Field

Field

Field%

of

fielddomain

refer

type

Description

countmodel

countcount

ratio

CDE

Alphamericcodevalue

1,337

18.4

1446

2.99

DTE

Dateinsystemdateformat-(YYMMDDinternally)

176

2.4

1143

1.23

NAR

Narrativetext

67

.9

046

1.45

NBR


1,849

25.4

10

765

2.41

PCT


6.0

36

1.00

PRC

Priceortarrif

175

2.4

11

80

2.18

QTY

Quantity

1,038

14.3

105

288

3.60

STS

Status.

1,214

16.7

392

800

1.51

TME

TimeinHHMMSSformat.

31

.4

328

1.10

TXT

Objecttext.

1,027

14.1

378

600

1.71

VAL

Monetaryvalue

294

4.0

110

177

1.66

VNM

ValidSystemname

41

.5

613

3.15

Totals

7,255

1,020

3,392

2.13

***ENDOFREPORT***





Figu

re C

-4: F

unct

ion

Stat

istic

s Rep

ort


%of

Functiontype

Count

functions

Editrecord(1screen)

68

.8


30

.3


6.0


2.0


2.0

Editfile

63

.8

Displayfile

584

7.5

Edittransaction

3.0

Displaytransaction

2.0

Prompt&Validate

652

8.4

Selectrecord

87

1.1

Printfile

267

3.4

Printobject

167

2.1


399

5.1


206

2.6

Executeuserprogram

309

3.9

Executeusersource

595

7.6

Createobject

465

6.0

Changeobject

540

6.9

Deleteobject

410

5.3

Retrieveobject

2,825

36.5


2.0

Sumfunctionfield

50

.6

Countfunctionfield

1.0

Grandtotal

7,735


5,261


..:

2,474


..:

1,499


..:

267


399

***ENDOFREPORT***





Figu

re C

-5: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 1

of 2

)


%of

Instructiontype

Count

actions

Editrecord(1screen)

93

.0


44

.0


21

.0


1.0


6.0

Editfile

40

.0

Displayfile

845

.6

Edittransaction

3.0

Displaytransaction

4.0

Prompt&Validate

816

.6

Selectrecord

276

.2

Printfile

79

.0

Printobject

256

.2


820

.6


3,888

3.1

Executeuserprogram

526

.4

Executeusersource

5,596

4.5

Createobject

2,213

1.8

Changeobject

1,849

1.5

Deleteobject

1,205

.9

Retrieveobject

9,759

7.9


4.0

Sumfunctionfield

227

.1

Countfunctionfield

1.0

Retrievemessage

1,009

.8

Executemessage

78

.0


640

.5

Senderrormessage

7,235

5.9


74

.0

Sendstatusmessage

335

.2

Add

6,523

5.3

Subtract

872

.7

Multiply

792

.6

Divide

680

.5

Dividewithremainder

15

.0

Computeexpression

496

.4

Move

54,195

44.2

Moveall

1,261

1.0




Figu

re C

-6: A

ctio

n D

iagr

am In

stru

ctio

n Ty

pe S

tatis

tics R

epor

t (Pa

ge 2

of 2

)


%of

Instructiontype

Count

actions

Convertvariable

2,998

2.4

Concatenate

1,478

1.2

Substring

484

.3

Quit

8,062

6.5

Exitprogram

3,709

3.0

Setcursorposition

29

.0


1,891

1.5

Commit

525

.4

Rollback

586

.4

Total

122,539

***ENDOFREPORT***






Copyright � HawkBridge Pty Ltd


HawkBridge Pty Ltd3 Highett Road

Hampton, VIC 3188Australia

+61 3 9598 5829

http://www.HawkBridge.com

[email protected]

http://www.hawkbridge.com/

mailto:[email protected]

Documents

An Independent Review of COOL2E Release 7.0 Letter 2