App Builder Creating Reports

BluePhoenix AppBuilder 2.1.
Creating Reports Guide
BluePhoenix AppBuilder 2.1.0 Creating Reports Guide April, 2003
Corporate Headquarters BluePhoenix Solutions Vlierwerf 7B 4704 SB Roosendaal The Netherlands +31 (0) 165 399 401 +31 (0) 165 396 308 fax USA Headquarters BluePhoenix Solutions USA, Inc. 8000 Regency Parkway Cary, NC 27511 United States +1 919.380.5100 +1 919.380.5111 fax www.bluephoenixsolutions.com
1992-2003 BluePhoenix Solutions All rights reserved. BluePhoenix is a trademark of BluePhoenix Solutions. All other product and company names mentioned herein are for identification purposes only and are the property of, and may be trademarks of, their respective owners. Portions of this product may be covered by U.S. Patent Numbers 5,495,222 and 5,495,610 and various other non-U.S. patents. The software supplied with this document is the property of BluePhoenix Solutions, and is furnished under a license agreement. Neither the software nor this document may be copied or transferred by any means, electronic or mechanical, except as provided in the licensing agreement. BluePhoenix Solutions has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. BluePhoenix Solutions assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by BluePhoenix Solutions or its representatives.
TABLE OF CONTENTS
Table of Contents
AppBuilder 2.1.0 Creating Reports Guide
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Report Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Report-Related Entity Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Configuration Settings for Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Report Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Multiple Regular Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Break Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 Derived Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 Finished Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Using Report Painter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Starting Report Painter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Creating a Report Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Editing a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Selecting a Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Setting Page Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Setting Section Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Setting Section Line Font. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 Adding and Modifying Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 Displaying Additional Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Adding Visual Elements to a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9 Inserting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9 Adding and Modifying Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Adding and Modifying Date or Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Adding and Modifying Page Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13 Adding and Modifying a Grid Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13 Adding or Modifying a Grid Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Developing Report Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Report Contains Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Report and Section Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Report Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 Report Relationship Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Sections as Units of Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Types of Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Header and Subheader Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Regular Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Break Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Footer Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Consistency Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Kinds of Data in a Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Section Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Setting Page Placement Options
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Page Eject Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Page Placement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Creating Subheaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Extending Header Section with Subheaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Specifying Subheader Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Printing Subheaders in a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 Changing Subheader Hierarchies at Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Handling Gaps in Subheader Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Printing Subheader in Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Inheriting Data in Subheader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Subheader Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Creating Break Sections
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Specifying a Break Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Specifying Break Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Avoiding Ambiguous Break Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Handling Issues of a Single Break . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 Handling Other Aspects of Break Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 Ending a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Using Derived Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Overview of Report Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Break Sections without Derived Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Functional Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
ii
Table of Contents
Derived Data in Regular and Break Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Derived Data Classified by Function Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 Mathematical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 Formatting Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 Copy Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 Miscellaneous Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Formatting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Picture Clause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Edit Picture Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Dynamic Edit Pictures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4 Other Formatting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Defining Driver Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Printing a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Feeding Data to a Regular Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2 Starting a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Ending a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Reassigning a Section Subheader Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Getting Data from a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
10 Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Generating a Report in C or COBOL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Preparing a Report on the Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Printing a Report on the Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 Handling Report Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Generating a Report in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13 Understanding Differences in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13 Preparing a Report in Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15 Printing a Report in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Supported Page Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1 Index
Table of Contents
iii
iv
Table of Contents
CHAPTER
INTRODUCTION
Report Writer, in conjunction with Report Painter, lets you design reports on the workstation and then print either on the mainframe, in a batch or CICS environment, or on the workstation in Java mode. At runtime, the Report Writer, a mainframe or Java application, couples the report format defined in Report Painter with a driver rule coded in Rule Painter. The driver rule reads the data and controls the reports logic to produce the report. Report Painter lets you control report layout and content. You need not provide any code in the rule or anywhere else to implement features, such as page ejects and break processing. Report Generator is a code-generation tool that creates a COBOL or Java program from the information Report Painter and other data, such as views and fields, provide. (Rules communicate data to be printed in sections through section views, just as window views serve the analogous purpose when conversing a window.) This introduction includes discussion of: Report Terms Report-Related Entity Types Configuration Settings for Reports Report Processing Multiple Regular Sections Break Sections Derived Data Finished Example Refer to the Development Tools Reference Guide for information on toolbars and Workbench Options. Refer to the Rules Language Reference Guide for information on creating driver rules. In this description of the Report Writer, there are at least three meanings to the word report: An entity in the AppBuilder information model The printed document the AppBuilder environment produces A program that is invoked to produce the document This documentation refers to any of the three simply as report, unless the meaning is ambiguous. Report entity, printed report, and report program are the terms used for these respectively when more precise language is needed. Before discussing reports further, you should be familiar with some Report Terms. Refer to the Messages Reference Guide for a descriptions of error or information messages that are displayed as a result of running the Report Writer.
1-1
Report Terms
Report Terms
This brief summary of terms used with reports should be helpful in reading topics on reports. An object is an instance of either an entity or relationship type, with properties and parts. An object property is an element of an object that helps define and identify that object. An entity type is a generic category of entities, such as a rule or a report. An entity is an instance of an entity type. A relationship type is a kind of relationship, such as the has-access-to or has-root-entity relationship. A relationship is an instance of a relationship type, with properties and parts. A report is a document containing regular and derived data that is produced by the AppBuilder environment. Regular data is data loaded from the database. Derived data is the result of some function applied to data loaded from the database. A driver rule converses a report, and communicates what data is to be included. A regular section displays information extracted from the application database. A break section separates the reports regular sections and may involves a calculation of data from a regular section. A subheader section is a flexible extension of the header section. It can be viewed as a header for a particular regular section, as opposed to the header section which is the header for the whole report. A header section is printed once at the top of each page of a report. It typically contains information such as the company name and the field headings. A footer section is printed at the bottom of each page of a report. It typically displays summary information and the page number. A section view defines what data is to be included in the report. The AppBuilder information model describes a universe of entity and relationship types that serve a particular purpose, such as software development or repository administration.
1-2
Introduction
Report-Related Entity Types
Report-Related Entity Types

The AppBuilder information model defines relationships between the rule, report, section, view, and field entities, as shown in Figure 1-1.
Figure 1-1 Entity types used by Report Writer
The report entity type defines, in conjunction with the section entity type, the paper-based output an application (usually a batch application) produces for the end user. A report can have the following relationships: Is-conversed-by Rule Contains Section A section entity type defines the content of the report. Each section includes definition information about a particular part of the report (for example, a header section, a footer section, and so forth). A section can have the following relationships: Is-contained-in Drawing Is-contained-in Report Owns View A view entity type defines data structures in the AppBuilder environment. For example, a view owned by a section defines the fields that appear in that section. A view can have the following relationships with regard to reports: Is-owned-by Section Includes View Is-included-by View Includes Field
AppBuilder 2.1.0 Creating Reports Guide 1-3
Configuration Settings for Reports
A field entity type is where you store the definition for each of the fields your report uses. The properties of the field entity type let you specify particular qualities for the data that can populate that field (for example, integer, character, decimal, and so forth). A field can have the following relationships with regard to reports: Is-included-in View Refer to the Information Model Reference Guide for detailed information regarding entity and relationship properties.
Configuration Settings for Reports

Java Support The settings in the ReportWriter section of the appbuilder.ini file control the configuration of reports. These are summarized in Table 1-1.
Table 1-1 Setting MEDIA_TYPE Settings in appbuilder.inih Description Specifies Media type that is used to output reports. Possible values are PRINTER, HTML, TEXT. Default is PRINTER. Currently only PRINTER media is supported. Specifies whether you want page/printer or other setup dialog displayed (TRUE) or not (FALSE). This dialog allows to specify printer name and settings, paper size, etc. If set to FALSE, default values are used for all required settings. Default is TRUE. Specifies particular media: printer name for PRINTER media type. Default is \\server\printer. This setting is required if DISPLAY_SETUP_DIALOG=FALSE and report is started without PRINTER clause. Specifies default page size. If page setup dialog is not displayed (DISPLAY_SETUP_DIALOG=FALSE) Report Writer uses this setting as default page size. Refer to Page Formats in Appendix A, Supported Page Formats. Default is ISO_A4. Specifies "average" character size (width, height) in the same units as PRINT_POINT_SIZE setting of a particular font in fonts.ini and is used when Report Writer cannot determine it by the other means. This happens when 3800 printer is specified in Report properties and thus all sizes are measured in INCHES/10 instead of characters. In this case Report Writer cannot calculate size of a single character and it will use the value specified here. This value is used to calculate section left margin in printer-native units. Default is 20, 40
DISPLAY_SETUP_DIALOG
MEDIA
DEFAULT_PAGE_SIZE
AVERAGE_CHAR_SIZE
1-4
Introduction
Report Processing
Report Processing
Mainframe Report Writer To obtain a printed report from the mainframe, perform these workstation and mainframe steps. On the workstation: 1. 2. 3. 4. 5. 6. Create the report hierarchy, using Hierarchy window in the Construction Workbench. Format the report, using Report Painter in the Construction Workbench. Write the conversing rule using Rule Painter in the Construction Workbench. Commit your changes in the Construction Workbench. Use Report Painter (Verify Syntax) to make sure the syntax of the report is correct. Upload to the enterprise repository using the Freeway Explorer.
And these steps on the mainframe: 7. 8. 9. Log on to the Host Workbench and select Reports from the Entity Menu. Apply the Prepare action to the report entity and the conversing rule. Write the JCL to run the report.
10. Run the report.
Note
Steps 9 and 10 are required for a batch report.
Java Report Writer To obtain a printed report on the workstation in Java mode, perform these steps. On the workstation: 1. 2. 3. 4. 5. 6. Create the report hierarchy in the Hierarchy window of the Construction Workbench. Format the report, using Report Painter in the Construction Workbench. Write the conversing rule using Rule Painter in the Construction Workbench. Commit your changes in the Construction Workbench. Prepare the rule owning the report. Run the report.
These steps are discussed in more detail throughout this documentation.
1-5
Report Processing
Example Report As an example, we can create sections and rules for a report to print a report listing employees and the hours each worked in different weeks. We can call the report EMPHRS. First, we need to be able to print a columnar table. We can use the rule below to call a regular section to print the hours, without dividing them by employee. This rule calls a component to access a file on the mainframe to retrieve a record of employee time data. The rule then copies that components output view to the section view of a regular section, called EMPTIME, laid out to print a line of text containing: The name of the month A number (1, 2, 3, 4, 5) indicating a week in that month The number of hours the employee worked on each day in that week Some statistics derived from the employees time data for the week (Refer to Finished Example for a complete copy of the EMPHRS sample report.) Then, by mapping data into this sections view and issuing the following command, the rule prints a line of data. CONVERSE REPORT report_name SECTION regular_sect_name By looping through the series of actions, the rule prints the table of employee hours. CONVERSE REPORT EMPHRS START <get the first time data record> DO WHILE NOT <test for the end of the data file> MAP <the time data> TO EMPTIMEI CONVERSE REPORT EMPHRS SECTION EMPTIME <get the next time data record> ENDDO CONVERSE REPORT EMPHRS END
1-6
Introduction
Multiple Regular Sections

A report can have any number of regular sections, differentiated by name. Simple regular sections, like the one in the example, are often used to print tables of data, a row at a time. More complex ones can be used to print information between tables in a report or to print column headers for tables. To add to our example, another section of the report, called EMPNAME, could be formatted to print information about an employee and a column header for that employees hours. The rule segment can explicitly print such a section before each employees hours. And finally, another section, LEMPDEPT, prints information about the department in which the employee is working. The structure of the report is shown below. 1st LEMPDEPT 1st EMPNAME of 1st LEMPDEPT 1st EMPTIME of 1st EMPNAME of 1st LEMPDEPT 2nd EMPTIME of 1st EMPNAME of 1st LEMPDEPT -- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this employee 2nd EMPNAME of 1st LEMPDEPT 1st EMPTIME of 2nd EMPNAME of 1st LEMPDEPT 2nd EMPTIME of 2nd EMPNAME of 1st LEMPDEPT -- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this employee -- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this department 2nd LEMPDEPT 1st EMPNAME of 2nd LEMPDEPT 1st EMPTIME of 1st EMPNAME of 2nd LEMPDEPT 2nd EMPTIME of 1st EMPNAME of 2nd LEMPDEPT -- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this employee 2nd EMPNAME of 2nd LEMPDEPT 1st EMPTIME of 2nd EMPNAME of 2nd LEMPDEPT 2nd EMPTIME of 2nd EMPNAME of 2nd LEMPDEPT -- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this employee -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -Total hours worked for this employee Total hours worked for this department -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -Total -- -- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- -- -- -- -- -AppBuilder 2.1.0 Creating Reports Guide 1-7
-- -Total -- --- --- --
-- -hours -- --- --- --
-- -- -- -- -- -- -- -worked for this employee -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- --
The rules logic to print this kind of report is shown below: CONVERSE REPORT EMPHRS START <get the first time data record> <get the employee data record for the first time data record> <get the corresponding department data record> *> prints information on first department <* MAP <the department data> TO LEMPDEPTI CONVERSE REPORT EMPHRS SECTION LEMPDEPT *> prints information on first employee of first department <* MAP <the employee data> TO EMPNAMEI CONVERSE REPORT EMPHRS SECTION EMPNAME DO WHILE NOT <test for the end of the data file> *> prints hours worked information of current employee <* MAP <the time data> TO EMPTIMEI CONVERSE REPORT EMPHRS SECTION EMPTIME <get next time data record> IF <the new time record refers to a different department> *> switch to next department <* <get department data record for the new department> *>prints information on this next department <* MAP <the department data> TO LEMPDEPTI CONVERSE REPORT EMPHRS SECTION LEMPDEPT ENDIF IF <the new time record refers to a different department> OR <the new time record refers to a different employee> <get the employee data record for the new employee> *> prints information on next employee <* MAP <the employee data> TO EMPNAMEI CONVERSE REPORT EMPHRS SECTION EMPNAME ENDIF ENDDO CONVERSE REPORT EMPHRS END Chapter 9, Defining Driver Rules explains the interplay between rules and reports. Now that you have seen that a rule takes care of feeding data to the report and how it controls the order of sections to be printed, we can discuss some of the non-procedural features that Report Writer provides.
1-8
Introduction
Page Placement Property

One property of the Section entity is called Page Placement. If you set the Page Placement property of a Section to Next Page, whenever that section is triggered, a new page is started before it prints (see Chapter 4, Setting Page Placement Options). Note that regular sections also can have Page Placement set. Our EMPNAME section has this property set to Next Page; that is why each employee in the printed report is on a separate page (see the sample report, EMPHRS, in Finished Example). Headers and footers print automatically at the top and bottom of each page. Notice the total hours worked summaries on both the department and the employee level. How do you get those to print? The rules logic certainly has no code to keep track of employee and department ID and summing logic for the hours. Instead, we rely on two major features of Report Writer: break sections and derived data.
1-9
Break Sections
Break Sections
A break section prints automatically before any regular section that changes the value of a certain field. You associate the break section with this fieldwhich can be in the view structure of the section view of any regular section in the same reportby specifying a break condition that must match this field. If a regular section whose section view includes that field is invoked, and the value of that field has changed since the last time that section was printed, the break section is printed before it. In addition to the totals of departmental and employee hours worked, you can also print subtotals per employee per month. In other words, we want the following summary data hierarchy: Monthly work hours for an employee Total work hours for an employee Total work hours for an entire department This hierarchy is indented in top-down order because the low-level summary per month, per employee, per department, should be printed beforeand in addition tothe per employee, per department, summary data. Whenever you switch from one employee to the next, you want to see the summary data for the last month of the previous employee followed by the totals for the previous employee. Only then do you want to see the regular section that was conversed for the new employee. Further below is more information about implementing these break hierarchies. For now we can concentrate on the problem of breaking on the monthly summary for an employee. You can implement the above break hierarchy by adding three break sections, MONTHHRS, TOTALHRS, and LTOTEMP, to our report as follows: 03 02 01 MONTHHRS: MONTH field in the EMPTIME section TOTALHRS: EMPLOYEE field in the EMPNAME section LTOTEMP: DEPARTMENT ID in the LEMPDEPT section
The numbers (03, 02, 01) to the left of the break sections indicate the break hierarchythat is, the smaller the number, the higher the data level. 03 levels summarize into 02 levels, which summarize into 01 levels. The fields to the right of the break section name specify the break condition. MONTHHRS has as its break field the MONTH field in the EMPTIME section. Immediately before a new months weekly hours are printed, this break section can print a summary of the employees hours for the previous month. TOTALHRS, a higher-level break section triggered by changes in the EMPLOYEE field in the regular section EMPNAME, can print for each employee the total hours across all the months printed. LTOTEMP ranks higher than either MONTHHRS or TOTALHRS. Its break condition is the DEPARTMENT ID in the regular section LEMPDEPT. At the end of a report, all the break sections are printed, as if the lowest-level break sections break field had changed. So you can see that there is a lot happening during break processing. The nice thing about Report Writer is that all you have to do is paint the three sections, specify that they are break sections, and associate break levels and break conditions with them.
1-10
Introduction
Derived Data
Derived Data
Because you do not invoke break sections directly, they do not have fields that your rules load with data. Instead, they have derived data, which show the result of some function applied to all the values some field has taken in the sections printed since the last time the break section was triggered. As an example, we can examine the fields of our MONTHHRS break section. The weekday total hours field is a sum field, and has as its operand field the weekday total of daily hours field from EMPTIME. The average weekend daily hours field has average as its function, and the weekend average of daily hours fields as its operand field. Where the break section prints Summary for <month name>, the month name is a copy field and has the month name field from EMPTIME as its operand field. (See Chapter 7, Using Derived Data for details.)
Figure 1-2 Sample section of the EMPHRS Report
Staff List Employee: 10145 Department: Phone: (212) 555-1111 Month Jan Jan Jan Jan Jan Week 1 2 3 4 5
Header Regular section EMPNAME
Adams, Andrea Sales Hired: 09/22/86 Mon 8 8 8 8 8 Tue 11 11 11 11 11 Hours: 225 45 11 11 11 11 11 9 9 9 9 9 Hours: 184 22 476
Regular section EMPTIME
Break section MONTHRS
Summary for Jan: Weekday Weekend Feb Feb Feb Feb Feb 1 2 3 4 5
Break section MONTHRS Break section TOTALHRS Footer
Summary for Feb: Weekday Weekend Total hours for emp #10145 PAGE 1
Start: September 28, 1990 01:57:09 Current: September 28, 1990 01:57:21
1-11
Finished Example
Finished Example
The first four pages of the finished EMPHRS report are shown on the next several pages. The EMPNAME section comprises the lines from Employee: through Month Week Mon Tue. It repeats on top of each page because it was made a subheader, a feature explained in Chapter 5, Creating Subheaders This is the first EMPNAME section of the report. Directly following the EMPNAME section are repeated occurrences of the EMPTIME section. The data below the Month heading are mostly blank because they were given the SKIP property. (See Other Formatting Features in Chapter 8, Formatting Fields.) Following is the first MONTHHRS section that appears in print. Note that it refers both to the previous month of January and the new month of February. This exemplifies the difference between COPY and COPYCURR. (See Chapter 7, Using Derived Data for details.) Finally, look at the footer that appears on page four of the report. Note the difference between Start Date/Time and Current Date/Time. (See Chapter 7, Using Derived Data for details.)
1-12
Introduction
Finished Example
Figure 1-3
Example Report EMPHRS, page 1 of 4
STAFF LIST Department: Employee: Phone: 10145 324 10145 0.45 Sales Adams, Andrea Hired: 02/01/1996
X CORPORATION
(212) 555-1111
Month Jan
Week 1 2 3 4 5
--------------------- Hours Worked --------------------Mon Tue Wed Thu Fri Sat Sun Weekday Weekend Total 8 11 10 9 7 2 5 +45.0 +07.0 +52.0 8 11 10 9 7 3 5 +45.0 +08.0 +53.0 8 11 10 9 7 4 5 +45.0 +09.0 +54.0 8 11 10 9 7 5 5 +45.0 +10.0 +55.0 8 11 10 9 7 6 5 +45.0 +11.0 +56.0 Hours 225 45 Feb 7 7 7 7 Maximum 11 6 4 4 4 4 8 8 8 8 12 12 12 12 13 12 11 10 Minimum 7 2 9 9 9 9 Minimum 4 9 1 2 3 4 5 5 5 5 5 5 Minimum 7 1 2 2 2 2 2 0 0 0 0 0 Average 9 4 +42.0 +42.0 +42.0 +42.0 +22.0 +21.0 +20.0 +19.0 +64.0 +63.0 +62.0 +61.0
Maximum +11.0 +11.0 +11.0 +11.0 +11.0
Minimum +07.0 +07.0 +07.0 +07.0 +07.0
Average +09.0 +09.0 +09.0 +09.0 +09.0
Summary for Jan: Weekday Weekend Next month will be: Feb 1 11 2 11 3 11 4 11 Summary for Feb: Weekday Weekend Next month will be: Mar 1 8 2 8 3 8 4 8 5 8 Summary for Mar: Weekday Weekend Next month will be: Apr 1 8 2 8 3 8 4 8 5 8 Page: 1
+12.0 +12.0 +12.0 +12.0
+04.0 +04.0 +04.0 +04.0
+08.0 +08.0 +08.0 +08.0
Hours 168 82 Mar 11 10 11 10 11 10 11 10 11 10 Hours 225 40 Apr 11 10 11 10 11 10 11 10 11 10
Maximum 12 13 9 9 9 9 9 7 7 7 7 7
Average 8 10 +45.0 +45.0 +45.0 +45.0 +45.0 +06.0 +07.0 +08.0 +09.0 +10.0 +51.0 +52.0 +53.0 +54.0 +55.0 +11.0 +11.0 +11.0 +11.0 +11.0 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 5 9 9 9 9 9 7 7 7 7 7
Average 9 4 +45.0 +45.0 +45.0 +45.0 +45.0 +02.0 +02.0 +02.0 +02.0 +02.0 +47.0 +47.0 +47.0 +47.0 +47.0 +11.0 +11.0 +11.0 +11.0 +11.0 01:57:09 01:57:21 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Start: Current:
September 28, 2002 September 28, 2002
1-13
Finished Example
Figure 1-4
STAFF LIST Department: Employee: Phone: 10145 324 10145
Report EMPHRS, page 2 of 4

X CORPORATION Sales 0.45 Adams, Andrea Hired: 02/01/1996
(212) 555-1111
Month
Week
--------------------- Hours Worked --------------------Mon Tue Wed Thu Fri Sat Sun Weekday Weekend Total Hours 225 10 May 11 10 11 10 11 10 11 10 11 10 Hours 225 20 Jun 11 10 11 10 11 10 11 10 11 10 Hours 225 65 Jul 11 10 11 10 11 10 11 10 11 10 Hours 225 25 Aug 12 8 12 8 Maximum 11 2 9 9 9 9 9 7 7 7 7 7 4 4 4 4 4 Minimum 7 0 0 0 0 0 0 Minimum 7 0 7 7 7 7 7 6 6 6 6 6 Minimum 7 6 3 3 3 3 3 2 2 2 2 2 Minimum 7 2 2 2 3 3 Average 9 1 +45.0 +45.0 +45.0 +45.0 +45.0 +04.0 +04.0 +04.0 +04.0 +04.0 +49.0 +49.0 +49.0 +49.0 +49.0
Maximum
Minimum
Average
Summary for Apr: Weekday Weekend Next month will be: May 1 8 2 8 3 8 4 8 5 8 Summary for May: Weekday Weekend Next month will be: Jun 1 8 2 8 3 8 4 8 5 8 Summary for Jun: Weekday Weekend Next month will be: Jul 1 8 2 8 3 8 4 8 5 8 Summary for Jul: Weekday Weekend Next month will be: Aug 1 5 2 5 Page: 2
+11.0 +11.0 +11.0 +11.0 +11.0
+07.0 +07.0 +07.0 +07.0 +07.0
+09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 4 9 9 9 9 9 7 7 7 7 7
Average 9 2 +45.0 +45.0 +45.0 +45.0 +45.0 +13.0 +13.0 +13.0 +13.0 +13.0 +58.0 +58.0 +58.0 +58.0 +58.0 +11.0 +11.0 +11.0 +11.0 +11.0 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 7 9 9 9 9 9 7 7 7 7 7
Average 9 6 +45.0 +45.0 +45.0 +45.0 +45.0 +05.0 +05.0 +05.0 +05.0 +05.0 +50.0 +50.0 +50.0 +50.0 +50.0 +11.0 +11.0 +11.0 +11.0 +11.0 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 3 9 9 10 10
Average 9 2 +44.0 +44.0 +05.0 +05.0 +49.0 +49.0 +12.0 +12.0 01:57:09 01:57:21 +05.0 +05.0 +08.0 +08.0
Start: Current:
1-14
Introduction
Finished Example
Figure 1-5
STAFF LIST Department: Employee: Phone: 10145 324 10145 0.45 Sales Adams, Andrea Hired: 02/01/1996
X CORPORATION
(212) 555-1111
Month
Week 3 4 5
--------------------- Hours Worked --------------------Mon Tue Wed Thu Fri Sat Sun Weekday Weekend Total 5 12 8 9 10 2 3 +44.0 +05.0 +49.0 5 12 8 9 10 2 3 +44.0 +05.0 +49.0 5 12 8 9 10 2 3 +44.0 +05.0 +49.0 Hours 220 25 Sep 11 10 11 10 11 10 11 10 11 10 Hours 225 35 Oct 11 10 11 10 11 10 11 10 11 10 Hours 225 25 Nov 11 10 11 10 11 10 11 10 11 10 Maximum 12 3 9 9 9 9 9 7 7 7 7 7 2 2 2 2 2 Minimum 5 2 5 5 5 5 5 Minimum 7 2 3 3 3 3 3 2 2 2 2 2 Minimum 7 2 4 4 4 4 4 2 2 2 2 2 Average 8 2 +45.0 +45.0 +45.0 +45.0 +45.0 +07.0 +07.0 +07.0 +07.0 +07.0 +52.0 +52.0 +52.0 +52.0 +52.0
Maximum +12.0 +12.0 +12.0
Minimum +05.0 +05.0 +05.0
Average +08.0 +08.0 +08.0
Summary for Aug: Weekday Weekend Next month will be: Sep 1 8 2 8 3 8 4 8 5 8 Summary for Sep: Weekday Weekend Next month will be: Oct 1 8 2 8 3 8 4 8 5 8 Summary for Oct: Weekday Weekend Next month will be: Nov 1 8 2 8 3 8 4 8 5 8
+11.0 +11.0 +11.0 +11.0 +11.0
+07.0 +07.0 +07.0 +07.0 +07.0
+09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 5 9 9 9 9 9 7 7 7 7 7
Average 9 3 +45.0 +45.0 +45.0 +45.0 +45.0 +05.0 +05.0 +05.0 +05.0 +05.0 +50.0 +50.0 +50.0 +50.0 +50.0 +11.0 +11.0 +11.0 +11.0 +11.0 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Maximum 11 3 9 9 9 9 9 7 7 7 7 7
Average 9 2 +45.0 +45.0 +45.0 +45.0 +45.0 +06.0 +06.0 +06.0 +06.0 +06.0 +51.0 +51.0 +51.0 +51.0 +51.0 +11.0 +11.0 +11.0 +11.0 +11.0 +07.0 +07.0 +07.0 +07.0 +07.0 +09.0 +09.0 +09.0 +09.0 +09.0
Page:
Start: Current:
01:57:09 01:57:43
1-15
Finished Example
Figure 1-6
STAFF LIST Department: Employee: Phone: 10145 324 10145 Sales 0.45 Adams, Andrea Hired: 02/01/1996
X CORPORATION
(212) 555-1111
Month
Week
Mon
--------------------- Hours Worked ---------------------~~ Tue Wed Thu Fri Sat Sun Weekday Weekend Total Maximum Hours 225 30 Dec 11 10 11 10 11 10 11 10 11 10 Maximum 11 4 9 9 9 9 9 7 7 7 7 7 4 4 4 4 4 Minimum 7 2 9 9 9 9 9 +45.0 +45.0 +45.0 +45.0 +45.0 Average 9 3 +13.0 +13.0 +13.0 +13.0 +13.0 Average 9 6 +58.0 +58.0 +58.0 +58.0 +58.0 +11.0 +11.0 +11.0 +11.0 +11.0
Minimum
Average
Summary for Nov: Weekday Weekend Next month will be: Dec 1 8 2 8 3 8 4 8 5 8
+07.0 +07.0 +07.0 +07.0 +07.0
+09.0 +09.0 +09.0 +09.0 +09.0
Summary for Dec: Hours Maximum Minimum Weekday 225 11 7 Weekend 65 9 4 Next month will be: Dec Total Hours for Employee #10145: 3105 Employee: 10146 10146 0.45 Brown, Robert Phone: (212) 555-1112 Hired: 10/23/1991
Month Jan
Week 1 2 3 4 5
Mon 8 8 8 8 8
--------------------- Hours Worked ---------------------~~ Tue Wed Thu Fri Sat Sun Weekday Weekend Total Maximum 11 10 9 7 2 5 +45.0 +07.0 +52.0 +11.0 11 10 9 7 3 5 +45.0 +08.0 +53.0 +11.0 11 10 9 7 4 5 +45.0 +09.0 +54.0 +11.0 11 10 9 7 5 5 +45.0 +10.0 +55.0 +11.0 11 10 9 7 6 5 +45.0 +11.0 +56.0 +11.0 Hours Maximum 225 45 4 4 4 4 8 8 8 8 12 12 12 12 13 12 11 10 Minimum 11 6 9 9 9 9 +42.0 +42.0 +42.0 +42.0 Average 7 2 +22.0 +21.0 +20.0 +19.0
Minimum +07.0 +07.0 +07.0 +07.0 +07.0
Average +09.0 +09.0 +09.0 +09.0 +09.0
Summary for Jan: Weekday Weekend Next month will be: Feb 1 11 2 11 3 11 4 11 Page: 4
9 4 +64.0 +63.0 +62.0 +61.0 +12.0 +12.0 +12.0 +12.0 +04.0 +04.0 +04.0 +04.0 +08.0 +08.0 +08.0 +08.0
Feb 7 7 7 7
Start: Current:
September 28, 2002 01:57:09 September 28, 2002 01:57:53
1-16
Introduction
CHAPTER
USING REPORT PAINTER
This topic contains information about how to create reports using the Report Painter tool in the Construction Workbench of AppBuilder. Use the Report Painter to design reports on the workstation that are printed on the mainframe (in a batch or CICS environment) or on a workstation in Java. At execution time, the Report Writer couples the report format you define in Report Painter with a driver rule you code in Rule Painter. The driver rule reads the data and controls the reports logic to produce the report. There are several steps involved in writing a report: Starting Report Painter Creating a Report Hierarchy Editing a Report Adding Visual Elements to a Report In the Construction Workbench you can also customize some aspects of Report Painter using the Workbench Options. Select Tools > Workbench Options and select the Report Painter tab. Refer to the Development Tools Reference Guide for a description of these Workbench Options. The settings are saved when you close the Construction Workbench.
Starting Report Painter

In the Construction Workbench, to start Report Painter, open a report object in the hierarchy (or create a report object if there is not one already) and double click on the report object. A Report Painter window opens in the tools area to the right. Refer to Figure 2-1 for a typical setup of the Construction Workbench, with the hierarchy window on the left and the Report Painter window on the right. There is no need for the Output window to be displayed. The figure shows a query of the repository for the next report object to display in the hierarchy window.
Figure 2-1
BluePhoenix AppBuilder
Construction Workbench with Report Painter Menus that relate to Report objects Toolbar for inserting objects in hierarchy Report Painter window in tools area showing sections and fields and visual elements Typical report hierarchy Open new report in hierarchy
2-1
Creating a Report Hierarchy
Creating a Report Hierarchy

The Report Painter is a formatting tool rather than an application building tool, so you must define a report and its contents in the repository. This is done in the Hierarchy window of the Construction Workbench. Start by inserting a Report entity then adding to it the sections and other entities needed. The result of the procedure detailed below is very similar to the hierarchy displayed in Figure 2-2.
Note
You must construct a Report in the hierarchy window before you can format the report and add objects in the Report Painter window.
To create the hierarchy: 1. 2. 3. 4. 5. 6. 7. 8. Navigate to the Hierarchy window of the Construction Workbench. Click on the Repository tab. Insert a Report entity either by selecting Report from the Insert menu. Name the report. Underneath the Report, insert a Section by selecting Section from the Insert menu. Name the section. Select the Section and select Relationship Properties. Edit the relationship properties as needed. Add a child View to the section and name it. Add fields as children to the view and name them. Commit your changes and begin Editing a Report.
A typical report contains the following sections: Header section printed at the top of each page of a report, typically contains such information as the company name and the field headings Regular sections typically display information extracted from the application database Break sections separate the reports regular sections and typically calculates data from a regular section Footer section printed at the bottom of each page of a report, typically displays summary information and the page number
Figure 2-2 Example Report hierarchy
Report object has Section that has View that has Fields
A Report typically has several sections. Each Section has one View that has several Fields.
2-2
Using Report Painter
Editing a Report
Editing a Report
Once you have a Report in the Hierarchy, you can begin adding items to the report, such as fields and visual elements. This includes: Selecting a Section Setting Page Properties Setting Section Properties Adding and Modifying Fields Displaying Additional Tools Some of these properties can be set by selecting the right-click menu in the Report Painter. See Figure 2-3.
Figure 2-3 Right-click properties menu
For information on object properties and line properties, refer to Adding Visual Elements to a Report.
Selecting a Section
When you begin to work on the report, you work on one section at a time. In the Report Painter, select the section of the report by clicking on the Section button or by clicking in the Section area itself. See Figure 2-4 for a typical section layout.
Figure 2-4 Report section layout
Section Area Section Buttons selected Section turns white
Section Bar
2-3
Editing a Report
Setting Page Properties

You can also set certain properties that apply to the entire report. This includes the size of the page (Page Size and Line Width), the type of printer, and the orientation of the page (Portrait or Landscape). In the Report Painter window, right-click and select Report Properties. The properties dialog appears as shown in Figure 2-5. This information is also available (with a different type of dialog box) when you select a Report object in the Hierarchy diagram and select Properties.
Figure 2-5 Report properties dialog
Table 2-1 Setting Page Size
Report properties Description Specify the number of lines (for Generic printer) or inches (for 3800 printer) in a page of the report. Default is 60. See Printer type. Specify the number of characters (for Generic printer) or inches (for 3800 printer) of the width of the page. Default is 72. The maximum value is 999 for Generic printer and 100 for 3800 printer. See Printer type. Specify the position of the left margin number of characters (for Generic printer) or inches (for 3800 printer). Specify the position of the top margin in units of number of lines (for Generic printer) or inches (for 3800 printer). The type of mainframe printer on which the report is printed. The choices are Generic and 3800. Default is Generic. For Generic, all sizing fields are in characters/lines. The orientation of the page (applies to 3800 printers only). Choices are Landscape and Portrait. Default is Portrait. Landscape prints the report rotated 90 degrees so that the top and bottom correspond to the long edges of the page and Portrait prints the report with the top and bottom corresponding to the short edges of the page.
Line Size
Left Margin Top Margin Printer type
Orientation
Click OK when done to save the settings.
2-4
Editing a Report
Setting Section Properties

In the Report Painter window, right-click and select Section Properties. The properties dialog appears as shown in Figure 2-6. This is only available from the Report Painter window; if you select the Section object in the Hierarchy diagram and select Properties, a different dialog box is displayed.
Figure 2-6 Section properties dialog
Table 2-2 Setting
Report properties Description Not an editable property. For display only. The length of the section in number of lines. The maximum value is 190 for a Generic printer and 100 for a 3800 printer. (For choice of printers, see Setting Page Properties.) The width in either number of characters or number of inches. The maximum is 999 for a Generic printer and 100 for a 3800 printer. (For choice of printers, see Setting Page Properties.) The number of columns in a multicolumn layout. If greater than one, the report is printed in a multicolumn format using the ordering defined in the Ordering convention. Default is 1. The default font for the entire section. A drop-down list of fonts include the fonts available; this list depends on the printer. The font names are mainframe font names and fonts must be non-proportional. The font selected on the workstation is as close as possible to the mainframe font. You can also change the font of a particular line within a section by Setting Section Line Font. See Figure 2-7 for an example of horizontal and vertical numbering assuming that the number of columns (the value specified in Repetition) is three. The sections are printed either in horizontal order or vertical order. Default is Horizontal.
Section name Lines
Width
Repetition
Font
Ordering convention
For multicolumn printing, the sections can be arranged horizontally or vertically. The example in Figure 2-7 shows the two possibilities for a three-column report with nine sections.
Figure 2-7 Multicolumn section ordering Vertical ordering 1 2 3 4 5 6 7 8 9
Horizontal ordering 1 4 7 2 5 8 3 6 9
2-5
Editing a Report
Setting Section Line Font

In the Report Painter window, right-click and select Line attributes. The line font dialog appears as shown in Figure 2-8.
Figure 2-8 Line font dialog
Table 2-3 Setting
Line font Description Displays the default font for this section. Not an editable property from this window. To change the default for the entire section, refer to Setting Section Properties. Select the font for this line of the section.
Section Default Change Font
Adding and Modifying Fields

To add a field to a section, insert a Field to a View in the hierarchy. To modify the field, you can double-click and edit the Field specifications. Beyond the properties of the field entity, you can modify the Field specifications by double-clicking on the field in the Report Painter window. The Field specifications dialog is displayed as in Figure 2-9.
Figure 2-9 Field specifications dialog
2-6
Editing a Report
The field name is grayed out; it is for display purposes only and is not editable from this window. (To change the field name, select the Field object in the Hierarchy diagram and select Properties.) The choices in the Function drop-down list are summarized in Table 2-4. The choice of functions depends on the type of field.
Table 2-4 Function Avg () Center () Copy () CopyCurrent () Count () Date () Left () Max () Min () Right Set display() Sum Time Field Functions Description Calculates the average of the values of the parameters Centers the display of data in the field (for VARCHAR fields) Prints the most recently conversed parameters Prints the currently conversed value Displays the number of times the parameter appears Displays the parameter in the date format specified in the Date/Time Template Justifies the display of data in the field to the left margin (for VARCHAR fields) Calculates the maximum value of the parameters Calculates the minimum value of the parameters Justifies the display of data in the field to the right margin (for VARCHAR fields) Select the sets that appear in the display Adds together the parameters and displays the total Displays the parameter in the time format specified in the Date/Time Template
Select a function, then click Add parameters to select the fields on which to perform functions. This displays the report window in which you can select the fields to load as the parameters on which the function is performed. An example window is shown in Figure 2-10. The tree is shown expanded. Select a field and click OK. This adds the field to the parameters box. If you want to remove the parameters, click Reset parameters.
Figure 2-10 Example fields window (for adding parameters)
If the Date or Time functions are selected, the Date/Time Template option is available. Choose from the formats in Table 2-5 and Table 2-6. (The characters in these formats are defined in Table 2-7 and Table 2-8.) If the function is Set Display, you can select a set using the Lookup sets button. Use the sets dialog to select a set that then appears in this field.
2-7
Editing a Report
If the function is something other than Date or Time, you can specify how the data in the field are displayed in the Picture Clause field. If a picture definition is in the repository, it defaults to that value and the Use repository picture clause box is checked. Values can be any given in Edit Picture Characters in Chapter 8, Formatting Fields. A period must be followed by a nine; for example, $999.99 specifies a dollars and cents format. Changes you make to the Picture Clause field are immediately reflected in the report. You can select any of these options for the Display Style. Select Skip to print the field only if it differs from its previous value. Select Underline to underline the field whenever it is printed. Click OK when done to save the settings.
Displaying Additional Tools

These tools can be used to help with arrangement of objects on the page: Ruler Alignment Bar
Ruler
Select Ruler from the pop-up menu (or View > Ruler) to display a ruler across the top of the report that you can use to calculate where objects are on the page. The ruler markings are in either inches or characters, depending on the printer you select in the Setting Page Properties. You can also right-click in Report Painter (in one of the displayed sections) for this option.
Alignment Bar
Select Alignment Bar from the pop-up menu (or View > Alignment Bar) to display a vertical line on the left side of the report that you can use to align objects in a column. You can move the alignment bar by placing the cursor on the line, pressing the mouse button and dragging the line to the desired position. You can also right-click in Report Painter (in one of the displayed sections) for this option.
Placement Units
Select View > Object Placement to set the units for placement of visual elements (such as grid line and grid box) dimensions. The units can be pixels (Pixels), dots per inch (DPI), or characters (Chars).
2-8
Adding Visual Elements to a Report

You can also add other visual elements to a report. These include: Adding and Modifying Text Adding and Modifying Date or Time Adding and Modifying Page Number Adding and Modifying a Grid Box Adding or Modifying a Grid Line In general, to add an element, first select the Section in the Report Painter window (either by clicking the Selection button or clicking in the Selection area itself). Then, select an element by either using the toolbar (as shown Figure 2-11) or by selecting the element from the Insert menu. In general, to modify an element, select the element by clicking on it in the Report Painter window, right-click, and select Object Properties. You can also double-click on the element. The properties dialog, which differs depending on the element, is displayed. When done modifying the properties, click OK. In general, to remove an element from a section, select the element and select Edit > Clear or press the Delete key.
Inserting Elements
To add a visual element or information to the report, you insert a specific type of report element. Use the Insert menu in the Construction Workbench or the Report Painter toolbar. Use the Report Painter toolbar to insert visual elements or fields into a Section of a Report. To display the toolbar select it from the Toolbars menu. The toolbar is shown in Figure 2-11.
Figure 2-11 Page number Text Vertical line Report Painter report element toolbar
Box Field Date or Time Horizontal line
Status Bar Indications

For those visual elements that you can insert either by the Insert menu or the toolbar, the size and location (coordinates) of the element is displayed in the status bar at the bottom of the window.
Figure 2-12 Coordinates and size in status bar
element coordinate location
size of element
2-9
Adding and Modifying Text

You can add text to place static information such as a label or a heading to a report. To add text: 1. 2. 3. 4. 5. 6. 7. Click on the section in which you want to add the text (either the Section button or the Section area). Select Insert > Text from the Construction Workbench menu. In the Report Painter window, move the cursor to the place in the Section area where the text should appear. Click to place it. It cannot, like other elements, span lines; it must be in one line or another. The text element has the default TEXT value. To change it, double-click on that text element. (Or click the text element and from the right-click menu, select Object Properties.) In the Label Properties dialog, change the text. If you want the text to appear underlined, check the Underline box. Click OK when done. The modified text element appears. To move the text element, click and drag it to any position on any line in the Section area.
Editing text
Figure 2-13
3 5
Report 51G-F8
Adding and Modifying Date or Time

You can add a date or time field to a section in a report. To add a date or time field: 1. 2. 3. 4. 5. Click on the section in which you want to add the date or time (either the Section button or the Section area). Select Insert > Date/Time from the Construction Workbench menu. In the Report Painter window, move the cursor to the place in the Section area where the text should appear. Click to place it. It cannot, like other elements, span lines; it must be in one line or another. The date or time element has the default value. To change it, double-click on that text element. (Or click the text element and from the right-click menu, select Object Properties.) In the Date/Time Properties dialog (shown in Figure 2-14), change the format. Click OK when done. The modified date or time format appears. When the report prints, the actual date or time is printed. To move the date or time element, click and drag it to any position on any line in the Section area.
6.
2-10
Figure 2-14
Date or Time element properties
The possible formats for date are listed in Table 2-5 and for time are listed in Table 2-6. Select Current to print the date or time that the report job actually prints; select Startup to print the date or time that the report job was submitted for printing. You may specify the format.
Table 2-5 Date formats Example 04/09/2003 April 09, 2003 4/9/03 4-9 4-03 20030409 Friday, April 9th, 2003 Today is Friday 9/4/03 09/04/2003 9-4 2003/April/9th 2003.April.9th 2003-April-9th
Date format %0m/%0d/%Y %M %0d, %Y %m/%d/%y %m-%d %m-%y %0c%0y%0m%0d %W %M %D, %Y Today is %W %d/%m/%y %0d/%0m/%Y %d-%m %Y/%M/%D %Y.%M.%D %Y-%M-%D
Table 2-6
Time formats Example 02:09:08 02:09 02:09 PM 14:09 02:09:08 PM 14:09:08 02-09-08 PM 14-09-08 02 PM Two nine eight PM Time is two PM The Time is 2-9-8 PM
Time format %0h:%0m:%0s %0h:%0m %0h:%0m %x %0t:%0m %0h:%0m:%0s %x %0t:%0m:%0s %h-%m-%s %x %t-%m-%s %h %x %H %M %S %x Time is %H %x The Time is %h-%m-%s %x
The individual characters used in Date Format and Time Format are listed in Table 2-7 and Table 2-8
Table 2-7
Date format characters Description Day (numeric) with leading zero Day (numeric) Day (numeric with suffix) with leading zero Day (numeric with suffix) Day (word) Month (numeric) with leading zero Month (numeric) Month (word) Year, last two digits Year, all four digits Example 09 9 09th 9th Friday 04 4 April 03 2003
Date character %0d %d %D %0D %W %0m %m %M %y %Y
Table 2-8
Time format characters Description Seconds (numeric) with leading zero Seconds (numeric) Seconds (word) Minutes (numeric) with leading zero Minutes (numeric) Minutes (word) Hour (numeric) with leading zero Hour (numeric) Hour (word) Twenty-four time Hour (numeric) Twenty-four time Hour (numeric) with leading zero AM or PM Example 08 8 Eight 04 4 Four 02 2 Two 14 14 PM
Time character %0s %s %S %0m %m %M %0h %h %H %t %0t %x
2-12
Adding and Modifying Page Number

You can add a page number to a section of a report. To add a page number: 1. 2. 3. Click on the section in which you want to add the page number (either the Section button or the Section area). Select Insert > Page from the Construction Workbench menu. In the Report Painter window, move the cursor to the place in the Section area where the page number should appear. Click to place it. It cannot, like other elements span lines; it must be in one line or another. The page number element simply says PAGE in the Report Painter. When printing, the actual page number appears. To change its appearance, double-click on that element. (Or click the element and from the right-click menu, select Object Properties.) In the Label Properties dialog, if you want the text to appear underlined, check the Underline box. Click OK when done. To move the page number element, click and drag it to any position on any line in the Section area.
4.
5. 6.
Adding and Modifying a Grid Box

You can add a grid box to a section of a report. To add a grid box: 1. 2. 3. Click on the section in which you want to add the box (either the Section button or the Section area). Select Insert > Box from the Construction Workbench menu. In the Report Painter window, move the cursor to the place in the Section area where the box should appear. Click to place it.
You can modify a grid box. To modify a grid box: 1. Resize it by grabbing an anchor point (any of the small black boxes in the corners and sides) and drag it to a new location. (Or change the height and width in the properties dialog.) The box can span lines in a section. Change properties of the lines of the box by double-clicking on that box element. (Or click the text element and from the right-click menu, select Object Properties.) In the grid box properties dialog, modify the properties. See Figure 2-15. You can set the line thickness (style) and size (height and width). The units are set by View > Object Placement.
Box properties dialog
2.
Figure 2-15
3. 4.
Click OK when done. The modified box element appears. To move the box element, click and drag it to any position on any line in the Section area.
2-13
Adding or Modifying a Grid Line

You can add a horizontal or vertical grid line to a section of a report. To add a grid line: 1. 2. Click on the section in which you want to add the line (either the Section button or the Section area). Select Insert > Horizontal line or Insert > Vertical line from the Construction Workbench menu. The cursor changes with a line. Click to place the line.
Grid line placement
Figure 2-16
You can modify the grid line. 1. Change the length of the line by clicking on an anchor point (either of the small black boxes at either end of the line) and dragging it to a new location. You can also change the length by editing the properties. Change properties of the grid line by double-clicking on that grid line element. (Or click the text element and from the right-click menu, select Object Properties.) In the grid box properties dialog, modify the properties. See Figure 2-17. You can set the line thickness (style) and size (height and width). The units are set by View > Object Placement.
Grid line properties
2.
Figure 2-17
3. 4.
Click OK when done. The modified box element appears. Change the position of the line by clicking on the middle of the line (off of the anchor points) and drag to the new location.
2-14
CHAPTER
DEVELOPING REPORT SECTIONS
This topic contains information about reports and sections, how they fit into the AppBuilder information model, the data stored with reports and sections, and their relationships. This is the foundation for subsequent topics that describe in-depth selected features, such as derived data and break processing. The work of adding and defining reports and sections is done in Report Painter. This topic includes: Report Contains Sections Sections as Units of Print Section Views After creating a report (with sections) in the Construction Workbench (in the Hierarchy window), you open the report in Report Painter and edit the sections.
Report Contains Sections

This topic includes: Report and Section Entities Report Properties Report Relationship Properties
Report and Section Entities

In the AppBuilder information model, the report entity has a name and a system ID associated with it, as well as data, which Report Painter lets you modify. In this model, a rule converses a report and a report contains a section. The Contains relationship between a report entity and its section entities defines the printed reports layout areas. We say that a report contains its component sections. (For details, refer to the Information Model Reference Guide.) From a report and the sections it comprises, the AppBuilder environment generates code that your rules code can call to print reports, section by section. As with the Rule Uses a Rule and the Rule Converses a Window relationships, the AppBuilder environment infers the Rule Converses a Report relationship from the rules call to the report in its Rules Language code. You do not have to manually create the relationship with the Enterprise Repository interface. The data printed in a section come from the fields
3-1
of a view owned by the section. Such views are referred to as section views. The relationship between a section and its section view is the same Owns relationship that connects rules, components, and windows with their views.
Report Properties
Table 3-1 summarizes the properties of a report.
Table 3-1 Property Page Size Report entity properties Description Number of lines (for Generic printer) or inches (for 3800 printer) per report page. Default is 60 (for Generic printer) or 11.0 (for 3800 printer). Refer to Printer Type. Number in characters (for Generic printer) or inches (for 3800 printer) for the width of the page. Default is 72 (for Generic printer) or 8.0 (for 3800 printer). This can be any positive number up to 999 (for Generic printer) and up to 99.9 (for 3800 printer), but you probably set it to either 80 or 132 columns or 80 columns, depending on your printers paper size. Refer to Printer Type. Number of blank spaces in characters or inches between the left side of the printers printable area and the report text. Must be less than the page width value. Number of blank spaces in characters or inches between the top of the printers printable area and the report text. Must be less than the total lines value. Type of mainframe printer the report is to be printed on. The two available options are Generic and 3800. If the printer is set to Generic, sizing fields are in characters (for line width) or lines (for page length). If the printer is set to 3800, sizing fields are in inches/10 specification. The default is Generic. How the report is printed on the page if the Printer option is set to 3800. It is inactive for Generic printers. In Java mode, it is active for all printers. For Landscape, the report is printed so that the long sides of the page are at the top and bottom. For Portrait, the report is printed so that long sides of the page are at the left and right sides. The default is Portrait. Saves the changes to the Edit Report pop-up window. Closes the Edit Report Information pop-up window without saving changes.
Line Size
Left Margin
Top Margin
Printer Type
Orientation
Save Cancel
3-2
Developing Report Sections
Report Relationship Properties

Table 3-2 summarizes the properties of a Report Contains Section relationship.
Table 3-2 Property Parent Name Child Name Report relationship properties Description Name of the report that converses the section. Name of the section that you are currently working with. Sequence in which you want the sections to appear within the Report Painter tool. If you associate the smallest number to the header section and the largest one to the footer, you see the header section on top and the footer section at the bottom. For internal use only. Available options: Break Section, Footer Section, Header Section, Regular Section. Default is Regular Section. Determines where the section is placed on the page. Available options: End Page, First Page, Last Page, Next Page, Same Page, Whole Page. Default is Same Page. Applies only to break sections. Ordinarily, all break sections are printed after the last regular section in a report is conversed (End-of-Report). This option disables printing of a break section at End-of-Report. Available options: Printed, Not Printed. Default is Printed. Describes the sequence of how break sections appear in the report. See Chapter 5, Creating Subheaders and Chapter 6, Creating Break Sections Default is 0. Specifies the name of the field where the break is to occur. See Chapter 6, Creating Break Sections Specifies the view qualifiers (in PL/I style) to determine the explicit break field. Thus BREAK_FIELD of VIEW_1 of VIEW (AppBuilder style) translates to VIEW.VIEW_1 or just VIEW_1 in the Break Qualifier field. This field is designed to specify an offset to the particular section you are working with, relative to the left margin of the entire report. That is, if the report left margin is 4 and the left margin in the Report/Section Relationship Property box is 3, then the actual left margin for this section 4 + 3 = 7. Default is 0.
Sequence Number
Separator ID Section Type
Page Placement
Print Options
Break Sequence Number
Break Field
Break Qualifier
Left Margin
3-3
Sections as Units of Print

This topic includes: Section Summary Types of Sections Consistency Conditions Kinds of Data in a Section
Section Summary
A section represents the unit of print for a report. Whenever Report Writer prints a portion of your report, it prints one or more entire sections. A section cannot be blank. It must contain at least one data or text field, which must be at least one character in size. The section that represents a layout of data in a report to be conversed is analogous to the panel that represents the layout of a window to be conversed. This layout information includes items such as the coordinate points at which certain labels and variable fields are to be printed. It also contains functional relationships that describe how certain print fields are to be derived from others, such as by summing certain values (see Chapter 7, Using Derived Data).
Types of Sections
A report can contain four categories of sections: Header and Subheader Sections Regular Sections Break Sections Footer Sections A report generally has more than one section attached to it. For reasons described below in the paragraphs on regular sections, you want to attach at least one regular section to your report. If you want a header and footer section for each page, you already have three sections, and if you want to implement items such as totals and subtotals, you need some break sections as well. The type of section depends on what data are entered in the Report Painter relationship properties pop-up window. This box lets you modify the properties of a section relative to a report. Note that a section SECTION_NAME can be a break section in REPORT_1 and a regular section in REPORT_2. (The properties of a report, its sections, and their relationships can also be modified in the Hierarchy window.) An example is shown in Figure 3-1 that shows the various sections.
3-4
Figure 3-1
Report sections on report layout

Staff List Employee: 10145 Department: Phone: (212) 555-1111 Month Jan Jan Jan Jan Jan Week 1 2 3 4 5
Header Regular section EMPNAME
Adams, Andrea Sales Hired: 02/01/1986 Mon 8 8 8 8 8 Tue 11 11 11 11 11 Hours: 225 45 11 11 11 11 11 9 9 9 9 9 Hours: 184 22 476
Summary for Jan: Weekday Weekend Feb Feb Feb Feb Feb 1 2 3 4 5
Summary for Feb: Weekday Weekend Total hours for emp #10145 PAGE 1
Break section TOTALHRS Footer
Start: September 28, 1990 01:57:09 Current: September 28, 1990 01:57:21
Header and Subheader Sections

You can specify one (but not more than one) header section for your report. Whenever an event occurs that causes Report Writer to skip to the next page, the header section appears on top of the next page. Refer to Chapter 4, Setting Page Placement Options for details. Data cannot be directly conversed to a header. This section type, however, can contain derived data. A subheader section is first and foremost a regular section. If you gave that section the subheader property by entering a non-zero value in the Break Sequence Number entry, then this section, under certain conditions, extends the header portion of your report (see Chapter 5, Creating Subheaders for details). You must converse a subheader at least once for it to appear in the report.
Regular Sections
Regular sections are the least glamorous but most important sections of a report. Any data that a rule wants to communicate to a report can only find its way there by means of a CONVERSE REPORT report_name SECTION regular_sect_name
3-5
statement where regular_sect_name must denote a regular section. A section is regular because you specified regular section as the section type in the Report Painters relationship dialog box. You may have noticed that subheader sections also have the regular section type. Then what is the relationship between regular sections and subheader sections? The answer is that subheader sections are regular sections that behave differently only if a page eject occurs. (See Chapter 4, Setting Page Placement Options and Chapter 5, Creating Subheaders for details.)
Regular versus Derived Data

Data that is conversed to a report through regular sections is called regular data. The opposite of regular data is derived data, which is obtained by transforming regular data through functional relations. (See Chapter 7, Using Derived Data for more information.)
Break Sections
Break sections are printed whenever certain regular data change. Together with the capability to implement sums and other kinds of derived data with functional relations, break sections let you implement totals and subtotals (see Chapter 6, Creating Break Sections and Chapter 7, Using Derived Data for more information). You do not directly converse a break section.
Footer Sections
You can specify one (but not more than one) footer section for your report. Whenever an event occurs that causes Report Writer to skip to the next page, the footer section appears at the bottom of the page. Refer to Chapter 4, Setting Page Placement Options for details. Data cannot be directly conversed to a footer. This section type, however, may contain derived data.
Consistency Conditions
The type of section depends on what information is entered in the Report Painter relationship properties dialog box, which stores the properties of a section relative to a report. This implies that a section name can be a break section in one report and a regular section in another. When looking at the entire collection of Break Sequence Number entries for all sections of type Regular, watch for these: There must not be more than one section with the same non-zero number The sequence of numbers should read 00 01 02 without gaps If you have changed some section view structure and there is a break section with break fields that refers to a modified section view, do not forget to update the break field qualifier.
Kinds of Data in a Section

A section may include the following kinds of data:
3-6
Section Views
Fields and static text objects to be printed Specification of functions or parameters that make up the functional relations in derived data (see Chapter 7, Using Derived Data for details) Picture clauses (see Chapter 8, Formatting Fields) Skip and underline features (see Chapter 8, Formatting Fields).
Section Views
Sections contain variable data and descriptive labels (text objects) to be printed. Whereas anything you type directly onto the section canvas becomes a text object, the universe of variable data that you can print in a section is much more restricted. More specifically, with the exception of page numbers, system date/time objects, and grid lines, you must select the variable data from the section view attached to your section (see Chapter 10, Generating Reports). In other words, a section is not required to have a view attached to it, but without a section view you can display only labels, date, time, page number, and grid lines. On the mainframe, grid lines are supported only for 3800 printers. On the workstation in Java, grid lines are supported for both the 3800 and generic printers. The Section Owns Section View relationship is one to one; that is, a section can have zero or one section view attached to it. Conversely, one view may be a section view to zero, one, or more sections. Those sections need not all belong to the same report and they do not need to have the same section type. Section views are to sections what window views are to panels. Section views (or at least regular section views) are the transport medium by which data move from a rule to the printer when the section is conversed. Window views are the transport medium by which data journey from a window to the screen whenever the window is conversed. You cannot have list boxes (arrays) in section views. A section can have only one view, which must be unique in that report. However, child views can be included in the section view.
3-7
Section Views
3-8
CHAPTER
SETTING PAGE PLACEMENT OPTIONS
This topic describes how to use the various page placement options in Report Writer to control page eject processing and page placement options. Familiarity with these useful options is important because, in page break processing or subheaders, it is possible to print several sections with a single CONVERSE REPORT statement. This topic includes: Page Eject Events Page Placement Options
Page Eject Events

Whenever Report Writer gains control from a rule through a CONVERSE REPORT statement, as shown below, it implies the printing of a regular_sect_name section and possibly some other sections as well, depending on the specifications set. CONVERSE REPORT report_name SECTION regular_sect_name For example, if a break condition is satisfied, then one or more break sections are printed. If one or more subheaders are specified, they also are printed. (See Chapter 5, Creating Subheaders and Chapter 6, Creating Break Sections for more detail.) Whenever a section is to be printed as a result of the above CONVERSE REPORT statement (whether regular_sect_name or subheader), Report Writer first determines whether or not there is enough room on the current page for the section, and also for the footer section, if there is one. If not, a page eject event, or simply a page eject, occurs. Running out of space is not the only reason for a page eject. A page eject can be forced, for example, by specifying the Page Placement option for a section. To specify page placement options with Report Painter, see Page Placement Options. A page eject always has the following effects: Print the footer section (if defined) Skip to the next page Increase the page number by one or reset it to one, depending on the page placement option (see Page Placement Options) Print the header section (if defined) Print the appropriate subheaders (if defined and previously conversed at least once) To print subheader sections, see Chapter 5, Creating Subheaders. If you are developing a Java application, refer to Page Eject Event in Java.
4-1
Page Placement Options
Page Eject Event in Java

With the CONVERSE REPORT START statement, Report Writer determines whether it is possible to print any section on the page; it determines whether there is enough room for a section, taking into account height of header and footer sections (if any). If there is not enough space to print any section, Report Writer issues an error and further printing is cancelled. However, this does not mean exiting from the rule; instead, all calls to this report produce no result. Rule execution flow then continues. Before printing any section, Report Writer determines if there is enough free space left on a page to print this section. Free space is determined by these conditions: enough space on a real, physical page (measured in printer native units) enough space on a virtual page where page size is specified in the Report properties during design time If any of these conditions is not true, page eject occurs. Note that the report page size could be specified either in characters or inches/10 (depending on the printer type). For character specification, free space is determined by calculating the total number of lines for all conversed sections, taking into account the number of lines of header and footer. For the inches/10 specification, the section height in PELS (points at 240 DPI resolution) is used, which could differ from the real section height because fonts that are used at run time differ from fonts that are used at design time. Other reasons for page eject remain the same (as in page placement options).

Report Writer has the page placement options listed in Table 4-1. In the following paragraphs, each option is described for the following statement: CONVERSE REPORT report_name SECTION regular_sect_name Assume in the following discussion that regular_sect_name is tagged with the currently discussed placement option.
4-2
Table 4-1 Property
Page placement options Description No page eject event forced before or after the printing of a section, unless there is no more room on the page. With this page placement property, a page eject is forced before a section is printed.The page number is increased. A page eject is not forced after the printing of the section. If the driver rule executes the CONVERSE statement, a page eject is not induced for the break sections printed before regular_sect_name. Those break sections have their own page eject options. Forces a page eject after printing a section. Contrast with Next Page option that forces a page eject before printing a section.Otherwise, End Page and Next Page function identically. Forces a page eject both before and after printing a section with this property. The page number increases. If CONVERSE is executed and Whole Page is specified for regular_sect_name then the break sections printed prior to regular_sect_name are separated from regular_sect_name through page eject processing. This acts like a combination of Next Page and End Page. Section is printed on the first page of a new report. That is, a page eject takes place before the section is printed. First Page differs from Next Page in that the page number is not increased, but rather, reset to one. Note that if a CONVERSE statement is executed, the break sections are printed before the page eject takes place. That is, the break sections belong to the old report. Section is printed on the last page of the old report. Page eject takes place after the section is printed. Last Page differs from End Page only in that the page number is not increased, but reset to one. Note that Last Page does not imply the end of the report.
Same Page
Next Page
End Page
Whole Page
First Page
Last Page
Page Placement Option in Java

The page placement option is not taken into account when printing break sections by CONVERSE REPORT END. Also, it is not taken into account when printing subheaders (as subheaders, not as regular sections by CONVERSE REPORT SECTION statement).
4-3
4-4
CHAPTER
CREATING SUBHEADERS
This topic covers another useful report mechanism: the subheader. Under certain conditions a regular section reg_section, with a positive subheader (break) sequence number associated with it, is repeated between the header section and the top-most conversed section of a page. It is repeated in the sense that its data are identical to those in the last occurrence of reg_section that was conversed to the report. Like break sections, subheaders are ordered in a hierarchy and may appear under the appropriate circumstances. This topic includes: Extending Header Section with Subheaders Specifying Subheader Sections Printing Subheaders in a Hierarchy Changing Subheader Hierarchies at Run Time Handling Gaps in Subheader Hierarchy Printing Subheader in Sequence Inheriting Data in Subheader
Extending Header Section with Subheaders

Imagine a report that prints sales transactions for all customers of a given business. Suppose that the data for retail customers and wholesale customers are so different that you create two regular sections, retail_cust_sect and wholesale_cust_sect, to cope with those differences. A big customer may have many more transactions with your business than fits on a single page. Therefore, you may have pages that show the sales transaction data, but nothing about the customer that they relate to. To tie customer data to transaction data on each page, you could expand the header section to show information about the customer. The problem with this approach is that you would need three different header sections: One for retail customer data One for wholesale customer data Another in case the section that caused a page eject is itself a customer section and you do not want that customer information to appear twice in a row Subheader sections can act as flexible extensions of the header section.
5-1
Specifying Subheader Sections
For example, to use subheader sections as extensions of the header section, we set up two subheader sections: retail_cust_sect wholesale_cust_sect This means that their previously conversed occurrence is repeated on top of subsequent pages, unless the regular section that triggered the page break event is itself a customer section.
Specifying Subheader Sections

A regular section becomes a part of the subheader hierarchy simply by giving it a positive (non-zero) subheader (break) sequence number that you specify in Report Painter when painting the Report Contains a Section relationship properties. The menu entry is denoted Seq Number: (Brks or Subheader).
Printing Subheaders in a Hierarchy

Imagine that your sales transactions are grouped for each customer by product category. Suppose there are so many sales per category left that you want to repeat the current level of customer data and product category data on top of each page whenever a sales transaction triggered the page break. If the page break is triggered by a product category, then you would, of course, want to see only the current customer data repeated on top. In other words, you want two hierarchies, 01 retail_cust_sect 01 wholesale_cust_sect 02 product_category 02 product_category with the following properties: If any of the 01-level customer sections triggers a page eject, no subheaders are floated underneath the header section. If the 02-level section product_category triggers a page eject, the 01-level customer subheader is floated underneath the header section. If any regular section that is not part of the hierarchy triggers a page eject, all subheaders are floated underneath the header section. Of course there are some implicit assumptions about the order in which the driver rule converses the data to the report. It is assumed that the sales transaction data follow the product category to which they belong, and that the product categories are conversed after the customer to which they belong. Otherwise, you would not have higher-level data to be floated to the top of the next page.
5-2
Creating Subheaders
Changing Subheader Hierarchies at Run Time
Changing Subheader Hierarchies at Run Time

Report Writer lets you specify only one subheader hierarchy. You can trick AppBuilder software into thinking that your report has more than one hierarchy by altering the subheader sequence numbers of sections by means of the following statement in the driver rule for the report: CONVERSE REPORT report_name SECTION regular_section_name SUBHEADER subheader_seq_nbr This statement changes the current subheader sequence number of regular_section_name to the constant or variable subheader_seq_nbr. You would implement the two hierarchies described earlier by issuing the statements CONVERSE REPORT report_name SECTION retail_cust_sect SUBHEADER 0 CONVERSE REPORT report_name SECTION wholesale_cust_sect SUBHEADER 1 whenever a change from retail_cust_sect to wholesale_cust_sect occurred. You would issue those two statements just before issuing the CONVERSE REPORT report_name SECTION wholesale_cust_sect which actually gets the wholesale customer data to the report. Setting a subheader sequence number to zero actually reverts a subheader section to an ordinary regular section and vice versa: setting a subheader sequence number to a positive value makes the regular section a subheader. On the other hand, your rule executes the statements CONVERSE REPORT report_name SECTION wholesale_cust_sect SUBHEADER 0 CONVERSE REPORT report_name SECTION retail_cust_sect SUBHEADER 1 whenever a change from wholesale_cust_sect to retail_cust_sect occurred. Issue those two statements just before issuing the CONVERSE REPORT report_name SECTION retail_cust_sect statement, which gets the retail customer data to the report. The other statement that allows you to influence the subheader hierarchy of your report is: CONVERSE REPORT report_name SUBHEADER subheader_seq_nbr OFF This statement resets to zero the subheader sequence numbers of all subheader sections whose value is greater than or equal to subheader_seq_nbr. For more information on controlling subheader hierarchy levels from within rules, see the Rules Language Reference Guide.
Handling Gaps in Subheader Hierarchy
Handling Gaps in Subheader Hierarchy

Follow these two steps when creating your subheaders: Number your subheader sections so that each one has a different subheader sequence number. Make sure that all subheader sequence numbers are numbered in sequence 01 02 03 without any intermittent gaps. Gaps in your subheader sequence do not cause your report to fail. The effect is that the subheader sections prints with gaps. Gaps in subheaders are not supported. Reports with such gaps may behave differently in future releases. For example, if subheaders exist with sequence numbers 1, 2, 5, 6, 8, and if the regular section that caused page eject processing has subheader sequence number 6 in the subheader hierarchy, then the following subheader sections print following the header: Subheader Section 1 Subheader Section 2 Subheader Section 5
Gaps in Subheader Hierarchy in Java

Gaps in the subheader hierarchy are filled with the section with the minimum subheader level. For example, if subheaders exist with sequence numbers 1, 2, 5, 6, 8, and if the regular section that caused page eject processing has subheader sequence number 6 in the subheader hierarchy, then the following subheader sections print following the header since subheader section 1 has the smallest subheader level. Subheader Section 1 Subheader Section 2 Subheader Section 1 Subheader Section 1 Subheader Section 5
5-4
Creating Subheaders
Printing Subheader in Sequence
Printing Subheader in Sequence

A regular section with a positive subheader sequence number associated to it floats between the header section and the topmost non-header section of a page if certain conditions are met. We gave an informal description of those conditions in conjunction with the sales transaction report example. This now is a more precise formulation of the printing sequence algorithm: Let REG_SUBH_01 be the 01-level subheader. Let REG_SUBH_02 be the 02-level subheader. -----------------------------------------------Let REG_SUBH_N be the N-level subheader. Let REG_01, , REG_M be regular sections (without any subheader sequence numbers associated with them). What happens after a page break depends on the following factors: Were any subheader regular sections conversed previously? Is the regular section that caused the page break plain or subheader? Table 5-1 shows what happens. In this table, nn and mm stand for any positive number.
Table 5-1 Regular subheader None At least one REG_SUBH_nn At least one REG_SUBH_nn Subheader hierarchy printing sequence
Page eject REG_mm REG_mm REG_SUBH_mm
Conversed previously
Caused by
Result No subheader appears
Subheaders appear in Subheaders appear in
Highest nn is NHI
Sequence 01, 02, ... , NHI Sequence 01, 02, ... , mm1
Subheaders float below the header section if it exists. After the header and the subheader hierarchy are printed, you might get next a regular section (which appears because it was conversed and not because it is repeated as a subheader) or you might get a break section (see Chapter 6, Creating Break Sections for information).
Inheriting Data in Subheader

If a regular section reg_section is floated as a subheader, it inherits the data from the previously conversed occurrence of reg_section. This is true without exception. Even a Page Number object on reg_section show the old (and definitely incorrect) value.
5-5
Subheader Data
Subheader Data
If a regular section reg_section is repeated as a subheader then its data are identical to those at the time of the last converse of reg_section. See Chapter 4, Setting Page Placement Options for more information.
5-6
Creating Subheaders
CHAPTER
CREATING BREAK SECTIONS
Break processing is one of the major features of Report Writer. You can specify, with any break section, a condition tied to a change in certain regular views. Whenever this condition happens, this break section is printed together with all its subordinate breaks. The exciting thing about this feature is that the rule does not have to watch over the break conditions. Report Writer minds them for you, and it also figures out how to handle any derived data, such as totals and subtotals, that have turned up since the previous break. (Learn more about derived data in Chapter 7, Using Derived Data.) This topic includes: Specifying a Break Section Specifying Break Condition Avoiding Ambiguous Break Conditions Handling Issues of a Single Break Handling Other Aspects of Break Sections Ending a Report For an example of break processing with three levels, see the EMPHRS report discussed in Chapter 1, Introduction or the General Example given in this topic.
6-1
Specifying a Break Section
Specifying a Break Section

To specify a break section, you must edit the relationship properties (in the Report Owns Section relationship pop-up window) from the Hierarchy diagram: Specify the Break Section as the section type. Specify a non-zero positive number as the break sequence number. Specify a name for the break field. This should be the name and not the system ID of the field. Specify the break fields highest level view in the break qualifier entry field. This should be the name and not the system ID of the view. Specifying the name field_name in the break field and the string qual_1 as the break qualifier entry field is interpreted as a break condition for field_name OF qual_1 in a sense explained further below.
Specifying Break Condition

For each break section brk_sect you must specify a condition that triggers printing brk_sect and all higher level breaks. Specify for brk_sect a break field with zero or more break qualifiers with Report Painter (see Chapter 10, Generating Reports). At runtime the break is triggered when, during the course of a CONVERSE REPORT report_name SECTION regular_sect_name statement, the following occurs: a field in the section view, attached to regular_sect_name that matches the break condition (in a sense detailed further below), has changed its value. Zero, one, or more fields belonging to the regular data of report_name can be candidates for such a match. Thus, the combination of break field and break qualifiers is very different from specifying of an ordinary field, say, within rule source. Such a field: Exists within its context (the data universe of the rule if you edit a rule). Is uniquely qualified within that context: If the reference is A of B of C, some of the qualifiers may have been omitted. The important point is that there are no two fields A, each of which has the same higher level qualifiers B and C. Neither of those two properties necessarily pertains to break fields. The reason is that typically you may want to specify the condition for a break as follows: Print the break section that summarizes customer information whenever the customer ID field customer_ID changes. Do so regardless of whether the customer is buying bonds or stock or both. Report Writer lets you specify only one break field per break section. The way out of this dilemma is to simply define the break field as customer_ID. Report Writer prints the customer summary information
6-2
Avoiding Ambiguous Break Conditions
whenever any field named customer_ID changes its value because any regular data item with this field name matches the break condition customer_ID (see Avoiding Ambiguous Break Conditions below). But what if there also is a customer_ID field for other investments and the customer summary information section should pertain to stocks and bonds only? You are out of luck unless you redesign the layouts of your section views. One solution would be to create a view entity stock_or_bond in the repository. You can then make this view a qualifier for the stock or bond customers but not for the other customers. Define your break field as customer_ID and choose stock_or_bond as a break qualifier.

Break fields can be specified ambiguously so that a wider range of conditions can be covered. Ambiguous qualification means that the user cannot be limited to picking the fields from a menu where they appear with fulland thus uniquequalification. Parameters for a functional relationshipsuch as SUM, CENTER, COPYare chosen by menu choices from all regular data. It is guaranteed that there is only one match, as long as the regular section views for the report are not altered later on. Rather, it is necessary to give you the opportunity to specify the break condition in free-form format. It is important to note that this gives you the opportunity to enter invalid data. Because Report Painter itself cannot interpret the break conditions, it is up to you to figure out what regular data matches the ambiguously qualified field when you create the report. A field F matches an ambiguous reference if: F is regular (belongs to a regular section view) The ambiguous reference represents a partial qualification for F For example, assume that the regular data for a report consist of the two section views (indentation means fields or subviews) shown in Figure 6-1.
Figure 6-1 Example section view hierarchy
6-3
Let's consider the following break conditions: 1. 2. 3. 4. Fld_1 OF B_VW Fld_1 OF SV1 Fld_2 OF SV2 Fld_3
for some function F, then the matches shown in Table 6-1 occur. In this table, the Field column contains the field specifications in Rules Language style. The Break Field and Break Qualifier columns show what should be entered in same-named fields of Report Contains Section relationship properties dialog. Note that the Break Qualifier specification differs from the Rules Language OF style; views are specified in reverse order delimited by commas. An example is shown in Figure 6-2.
Table 6-1 Field Fld_1 OF B_VW OF A_VW OF SV1 Fld_1 OF B_VW OF SV2 Fld_1 OF C_VW OF SV1 Fld_2 OF B_VW OF SV2 Fld_2 OF D_VW OF SV2 Fld_3 OF SV1 Fld_3 OF D_VW OF SV2 Figure 6-2 Field to break condition matches Break Field Fld_1 Fld_1 Fld_1 Fld_2 Fld_2 Fld_3 Fld_3 Break Qualifier SV1.A_VW.B_VW SV2.B_VW SV1.C_VW SV2.B_VW SV2.D_VW SV1 SV2.D_VW
Report Contains Section relationship properties example
Fld_1 SV1.A_VW.B_VW
6-4
Handling Issues of a Single Break
Handling Issues of a Single Break

In theory, Report Writer supports up to nine break sections in your report, which should be more than sufficient for all your needs. The break condition for a break section break_sect not only induces the printing of break_sect, but of break sections with a higher break sequence as well. But even in the case of a single break section there are some interesting issues to be discussed: What gets printed and in what order? If a page eject event happens, where are subheaders printed? What happens to derived data in the break section? What happens to derived data in the header and footer section? This is the standard sequence of events that occur if the data in the section section_view of a regular section section_name trigger a break for the break section break_sect in the course of a statement: CONVERSE REPORT report_name SECTION section_name 1. 2. Determine whether break_sect and section_name are both printed on the current page or whether a page eject event occurred. If no page eject event occurs, first the break section prints. Afterwards the regular section prints. Any derived data in those sections stemming from functional relationships are updated according to the description in Chapter 7, Using Derived Data If one or more page eject events occur, the print sequence of footer header subheader(s) happens at the appropriate places (see Chapter 4, Setting Page Placement Options). Derived data in footer and header sections are updated as discussed in Chapter 7, Using Derived Data Derived data are never updated in subheaders.
3.
Handling Other Aspects of Break Sections

Other aspects of break sections include: Derived Data in Break Sections Break Sections Hierarchy
Derived Data in Break Sections

Generally speaking, derived data y = F (x1, x2,...) do not reflect the data stemming from the currently conversed section. A notable exception is data derived through COPYCURR. See Chapter 7, Using Derived Data for details.
6-5
Break Sections Hierarchy

The EMPHRS report presented in Chapter 1, Introduction had three break sections: 1. 2. 3. LTOTEMP, which had a break sequence number 01 and a break condition department TOTALHRS, which had a break sequence number 02 and a break condition employee MONTHHRS, which had a break section number 03 and a break condition month
In other words, there is a break section hierarchy or break hierarchy similar to the existence of a subheader hierarchy, shown below:
01 LTOTEMP 02 TOTALHRS 03 MONTHHRS department employee month
See Chapter 5, Creating Subheaders for details. The break hierarchy in EMPHRS must work so that a break in the condition for TOTALHRS not only invokes the printing of TOTALHRS, but prior to that, also initiates the printing of MONTHHRS, because the report is organized so that data is sorted by weekly work hours, within a month, within employee, and within department. In other words, the hierarchy means that the item with the bigger break sequence number breaks within the item with the smaller break sequence number. You want to print MONTHHRS data whenever the weekly work hours for an employee conversed through the regular section EMPTIME switch to a new month. You want to print TOTALHRS data which summarize work hours for the employee over all months whenever a different employee is conversed through the regular section EMPNAME. But before showing the employee summary data you also want to print the employees monthly summary data for the last month. And finally, you want to print LTOTEMP data which summarize work hours for all employees of a department over all months whenever a different department is conversed through the regular section LEMPDEPT. But before showing the department summary data you also want to print the summary data of its last employee and, before that, the summary data of the employees last month. In other words, a break on a certain level is supposed to print not only the 01-level break section or 02level section that caused the break, but also all lower level break sections, in a bottom up fashion, meaning that the lower level breaks, that represent the most detail, appear before the higher level ones. General Example Here is an example problem and solution. General Problem Your data is organized as follows: field_01 occurrences are divided into field_02 occurrences which are divided into field_03 occurrences which are divided into ... up to field_NN occurrences which represent the most detailed level.
6-6 Creating Break Sections
You want to print a summary of field_nn data whenever a change occurs for either of field_01 or field_02 or field_nn-1. In other words, whenever a change occurs for field_kk, then you want to print summaries for field_ kk+1, field_kk+2, , field_ NN-1, field_NN. You want the break sections printed bottom up; that is, the lower levels ought to be printed before the higher ones. At the very end of the report, you also want to print a summary of all the field_01 data preceded by the summaries of the lower levels where, from a functional point of view, the level becomes lower as the suffix nn of field_nn increases. General Solution Assume that you used Report Painter to create the following break hierarchy: 01 brk_sect_01 02 brk_sect_02 03 brk_sect_03 ... NN brk_sect_NN brk_cond_01 brk_cond_02 brk_cond_03 brk_cond_NN <- highest break level
<- lowest break level
brk_sect_mm with associated break section number mm has a higher break level than another break section brk_sect_nn with associated break sequence number nn, if the number mm is smaller than the number nn. You must design your break section numbers according to the following criteria: Each break section must have a break sequence number and break condition attached to it The highest break level must be 01 You must not have any gaps in the break sequence number sequence These criteria must be satisfied even if your report possesses only one single break section. A break on level nn prints brk_sect_NN brk_sect_NN-1 brk_sect_nn+1 brk_sect_nn in exactly that sequence. For example, a break at level 4 prints any breaks defined for level 9, 8, 7, 6, 5, 4 in exactly that order. If changes in a regular section view affect more than one break condition, the break takes effect on the highest break level among those associated with one of those break conditions. At the end of the report, that is, when the driver rule executes, a CONVERSE REPORT report_name END statement prints all break sections as if an 01-level break occurred. The break sections for which the Not Printed option is selected are not printed. (See Ending a Report.)
6-7
Ending a Report
Ending a Report
Under ordinary circumstances ending a report means that all break sections are printed after that last regular section was conversed. The rationale is that break sections usually summarize information pertaining to previously conversed regular datafor example, totals and subtotals. But sometimes you may not want to print one or several break sections when doing final processing. You would not want to print, for example, a break section which anticipates data for the next customer or the next employee to be processed. You can control whether or not you want a break section to be printed at end-of-report by choosing the Printed or Not Printed Print option in the section relationship properties in Report Painter.
6-8
CHAPTER
USING DERIVED DATA
Derived data are of central importance for Report Writer. Without them, this tool would be reduced to little more than a paint facility that spares you from counting columns and a mechanism that decides when to eject a page. Reports deal with the following kinds of data: Text (constant data) Regular data (conversed to the report by means of a CONVERSE REPORT SECTION statement) Derived data (constructed from regular data by means of certain functions, such as SUM, COUNT, and CENTER) This topic includes: Overview of Report Data Break Sections without Derived Data Functional Dependencies Derived Data in Regular and Break Sections Derived Data Classified by Function Name Table 7-1 lists the functions available in Report Writer.
Table 7-1 Report Writer functions Functions AVERAGE COUNT MAX MIN SUM COPY COPYCURR CENTER DATE LEFT RIGHT TIME STARTUP DATE STARTUP TIME CURRENT DATE CURRENT TIME PAGE NUMBER Function type
Mathematical Functions
Copy Functions
Formatting Functions
Miscellaneous Functions
7-1
Overview of Report Data
Overview of Report Data

Figure 7-1 shows an example of text fields as labels for variable data.
Figure 7-1 Text fields and variable data
.-----------------------------------------------------. | | | Page: 21 Start: September 28, 1990 01:57:09 | | Current: September 28, 1990 02:00:4 | | | '-----------------------------------------------------'
The items Page:, Start:, and Current: function as labels for the data that denote the current page number, the date and time when the report was submitted, and the date and time when this page was printed. If you do not count text as true data, most of the data in a report are passed on to it from a rule by means of a CONVERSE REPORT report_name SECTION section_name statement. Remember that section_name must be a regular section (see Chapter 3, Developing Report Sections). Such a CONVERSE statement makes the contents of the section view associated with section_name available to the report_name report and (after a processing such as page eject or printing break sections) finally results in printing section_name. The other kind of data that appears on a report is derived data. In the EMPHRS sample report (refer to Derived Data) we wanted to print the sum of all hours that an employee worked whenever a break occurred on EMPLOYEE_ID. As you recall, this was implemented with a break section, MONTHHRS, with break field employee_ID and using this algorithm: Algorithm for Month-Hours (*) TOTAL1 OF MNTHHRSI = SUM (MONDAY OF EMPTIMEI, TUESDAY OF EMPTIMEI, WEDNESDAY OF EMPTIMEI, THURSDAY OF EMPTIMEI, FRIDAY OF EMPTIMEI)
The meaning of the above is that the TOTAL1 OF MNTHHRSI field is accumulating contributions in order of: + + + + MONDAY OF EMPTIMEI TUESDAY OF EMPTIMEI WEDNESDAY OF EMPTIMEI THURSDAY OF EMPTIMEI FRIDAY OF EMPTIMEI
whenever the EMPTIME regular section is conversed to EMPHRS. If a break eventually occurs that involves printing MONTHHRS, TOTAL1 OF MNTHHRSI is printed as part of MONTHHRS and the SUM for TOTAL1 OF MNTHHRSI is reset to zero. The important point is that TOTAL1 OF MNTHHRSI is not part of the regular data that the report rule knows about. TOTAL1 OF MNTHHRSI is derived from regular data and the construction algorithm is Algorithm for Month-Hours.
7-2
Using Derived Data
Break Sections without Derived Data
The report extract in Figure 7-2 shows you a LEMPDEPT section followed by an EMPNAME section, followed by five EMPTIME sections, and then followed by a MONTHHRS break section.
Figure 7-2 Monthly total in EMPDEPT
324 Sales
Department:
Employee:
10145
10145
0.45
Adams, Andrea
Phone:
(212) 555-1111
Hired: 02/01/1986
--------------------Month Jan Week 1 2 3 4 5 Mon 8 8 8 8 8 Tue 11 11 11 11 11 Wed 10 10 10 10 10 Thu 9 9 9 9 9 Fri 7 7 7 7 7 Sat 2 3 4 5 6
Hours Worked Sun 5 5 5 5 5 Weekday +45.0 +45.0 +45.0 +45.0 +45.0
----------------------Weekend +07.0 +08.0 +09.0 +10.0 +11.0 Total +52.0 +53.0 +54.0 +55.0 +56.0 Maximum +11.0 +11.0 +11.0 +11.0 +11.0 Minimum +07.0 +07.0 +07.0 +07.0 +07.0 Average +09.0 +09.0 +09.0 +09.0 +09.0
Summary for Jan: Weekday Weekend Next month will be:
Hours 225 45 Feb
Maximum 11 6
Minimum 7 2
Average 9 4
Break Sections without Derived Data

Non-regular sections without derived data are essentially useless. By its very nature, a break section or header or footer does not hold any data conversed from a rule. This kind of section is printed not by a CONVERSE REPORT report_name SECTION section_name statement, but because the Report Writer determined that a condition, such as a page eject, must take effect or that a (regular) section was conversed with data that induces break processing for some break section.
Functional Dependencies
Derived data are specified through a functional relationship with specific dependencies. The relationship between: TOTAL1 OF MNTHHRSI and MONDAY OF EMPTIMEI, TUESDAY OF EMPTIMEI, etc. as shown in the Algorithm for Month-Hours, is reminiscent of math functions such as: y = F(x) In this notation, F is a function, x is an argument or a parameter, and y is called the derived value or function value of x. Report Writer enables you to derive a field from more than one argument. You can specify a break section containing a field y that accrues all conversed fields x1, x2, x3: y = SUM (x1, x2, x3)
7-3
Functional Dependencies
In other words, derived data are specified through a functional relationship of the form y = F (x1, x2, x3,...) where y and x1, x2, x3,... represent fields field name OF qualifying_view_1 OF qualifying_view_2 OF... For a description of data items and how they are qualified, refer to the Rules Language Reference Guide. There are certain properties common to all functional dependencies. These common properties are: Derived Value Function Differences Parameters Derived Value Assume that the section section_name you are currently working with contains a functional relation (for instance, the relation between TOTAL1 OF MNTHHRSI and MONDAY OF EMPTIMEI, TUESDAY OF EMPTIMEI, etc.). The derived value y of that functional relation belongs to the section view sect_view connected to section_name. To have it appear in a functional relationship implies that y has been painted at a certain spot of the section with certain row and column coordinates. It also implies that the display format of y either is derived from its data type as defined to the repository, or is overridden by Report Painter with a value specified in the picture clause field of the field detail entry screen. With respect to those properties, derived values are no different from ordinary non-derived data (regular data or text) painted on a section. The data type of the derived value must be compatible with the function. For example, the derived value of the COUNT function must be numeric, and the derived value of the CENTER function must be of type CHAR or VARCHAR. A field cannot derive a value from itself. A field is not allowed to be a parameter to itself for a function. Function Differences Functions can have zero, one, or more parameters. Some, such as COPY, need exactly one parameter, whereas others, such as SUM, accept one or several parameters. PAGE NUMBER and the CURRENT and STARTUP DATE/TIME functions are examples of derived data that do not depend on any parameters. Incidentally, the mechanism in Report Painter to place any of those into a section is different from the others; you do not have to pick y from section_view, but rather you can pick the appropriate object selection. For example, you simply place a PAGE NUMBER object into row 2 and column 71 of section_name and the function value y of the relation y = PAGE NUMBER is hidden from the user.
7-4
Using Derived Data
Derived Data in Regular and Break Sections
Parameters The function parameters are the most complex part of a functional dependency. As is true for the derived value, the data type of the parameter(s) must be compatible with the function. Example: The arguments of the SUM function must all be numeric and the single argument of the CENTER function must be of type CHAR or VARCHAR. Only regular data are admissible as parameters. This is not an undue restriction because you can derive data only from regular datathat is, data that were conversed from a rule. You can select a function for y from within the field detail entry screen. When you select a function such as AVERAGE for your section view field y, the default parameter that is chosen for you by the tool is again y. (Note that there may be qualifying views involved.) Usually, y is not a valid choice (for reasons explained in Derived Data in Regular and Break Sections). Report Painter fully qualifies the arguments chosen.

Exactly how a field is derived from its arguments depends on the specific function involved. The following paragraphs detail what happens during the course of conversing a regular section for each individual function. The most complicated functional relations are probably those that involve arithmetic functions, such as AVERAGE or SUM, because the derived value can be altered during the course of many converses. Eventually the section prints because a break condition is triggered when the derived value belongs to a break section, or because a page eject event is triggered from a header or footer section. Regular sections, whether they are printed normally or as floating subheaders, are much simpler because the derived value is not constantly reevaluated before printing. The section below describes the general principles underlying evaluating and printing functional relations, depending on what type of section the derived value is attached to. Assume for the following that a functional relation y OF sect_View = F (x1, x2, x3,...)
is defined for your report. The following are possible: Case 1: y belongs to a break section Case 2: y belongs to a footer section Case 3: y belongs to a header section Case 4: y belongs to a regular section Case 5: y belongs to a floating subheader Case 1: y belongs to a break section The value or values that belong to the occurrence whose conversing induced the printing are not reflected in the printing. For example, in the case of a SUM functional relation, the sum of x1 + x2 +... of the currently conversed regular section is not added to y before printing. Rather, those x values are used to reset y properly after printing.
7-5
Derived values in break sections are generally supposed to reflect a property belonging to the old status of the break condition and not to the changed status that is already reflected in the currently conversed regular section. See Chapter 6, Creating Break Sections for greater detail. Case 2: y belongs to a footer section Again, the value or values that belong to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, those x values are used to reset y properly after printing. Derived values in footer sections are generally supposed to reflect a property belonging to the previous page and not to the new page on which the currently conversed regular section appears. See Chapter 4, Setting Page Placement Options for further details. Case 3: y belongs to a header section The value or values that belong to the occurrence whose conversing induced the printing are reflected in the printing. Usually, y is reset to zero or spaces after printing. Derived values in header sections are generally supposed to reflect a property belonging to the new page on which the currently conversed regular section appears and not to the previous page. See Chapter 4, Setting Page Placement Options for further details. Case 4: y belongs to a regular section Again, the value or values that belong to the occurrence whose conversing induced the printing are reflected in the printing, and y is usually reset to zero or spaces after printing. Derived values in regular sections are generally supposed to reflect a property that does not ignore the currently conversed values. In the simplest case, all the x values belong to the same section as y. Functional relation processing does not need to memorize anything that concerns prior converses. There are some relations like this in the EMPHRS sample report. For example: TOTAL2 OF EMPTIMEI = SUM (SATURDAY OF EMPTIMEI, SUNDAY OF EMPTIMEI) You might think that this is more trouble than it is worth. You could as well execute the statement MAP SATURDAY OF EMPTIMEI + SUNDAY OF EMPTIMEI TO TOTAL2 OF EMPTIMEI prior to CONVERSE REPORT EMPHRS SECTION EMPTIME and achieve the same effect. However, if EMPTIME is used as a regular section in several reports, the instruction to print the sum of Saturdays and Sundays work hours is stored centrally with the EMPTIME entity, which is charged with printing this kind of data. It is not stored with the driver rule, which governs the flow of data to be printed in the report. Case 5: y belongs to a floating subheader Report Writer remembers what the entire section looked like when it was conversed for the last time, and this is exactly what you get. Note that y is not reset in any way just because it was printed in a subheader.
7-6
Using Derived Data
Derived Data Classified by Function Name
Derived Data Classified by Function Name

In the following example, y, x1, x2,... represent fields field_name OF qualifying_View_1 OF qualifying_View_2 OF... For a description of data items and how they are qualified see the Rules Language Reference Guide. The following two sections describe how functions, such as SUM or COPYCURR, handle data and what happens in the course of a CONVERSE REPORT report_name SECTION section_name statement to a field y that is derived from regular data through a functional relationship such as y = F (x1, x2,...). The functions include: Mathematical Functions Formatting Functions Copy Functions Miscellaneous Functions Implicitly these sections also tell you what happens if y belongs to a break section and a break for that break section is triggered. Each of the detailed descriptions specifies that some event does or does not take place until the section that contains y is printed. If y belongs to the regular section section_name, y is printed immediately as the result of the above converse statement. But if y belongs to a header or footer or break section, printing occurs only as a result of a selected few converse statements. These statements are those that result in a page eject event if y belongs to a header or footer (see Chapter 4, Setting Page Placement Options), or if a break condition is triggered for a break section that ranks higher than the one that y belongs to (see Chapter 6, Creating Break Sections).
These are the arithmetic functions: AVERAGE COUNT SUM MAXIMUM MINIMUM
7-7
Mathematical Functions in Java

Report Writer for Java uses Java decimal calculation logic (calculator arithmetic) for AVERAGE, SUM, MIN, MAX and integer for COUNT functions. Thus, the results of these functions may differ from ones on the mainframe (that uses COBOL arithmetic). This concerns overflow conditions and precision (scale) calculation logic.
AVERAGE
The AVERAGE function looks like this: y = AVERAGE (x1, x2, x3,...) At initialization of the report, y is set to zero. Whenever a regular section section_ID with section view section_view is conversed, all fields in section_view that are matched by any of x1, x2, x3,... are accumulated into a temp field, say temp_sum, which is internal to Report Writer and is not accessible to the application programmer. The number of matches that occurred during this converse is added into another temporary field, say temp_count. temp_sum and temp_count accrue data until the section with this reference is printed. At this time y is given the following value: y = temp_sum/temp_count If not, a single match occurred between two printings of y, and y is set to zero. Whether or not the function value y incorporates the data x1, x2, x3,... of the currently conversed section depends on the section type of y. Case 1: y = belongs to a regular section or a header The value of y incorporates the arguments x1, x2, x3,..., and y is reset to zero after printing. Imagine, for example, that y, x1, x2, x3 all belong to the regular section sect_view and that the xarguments have no match outside sect_view. Then each converse of sect_name sets y to (x1 + x2 + x3)/3. Case 2: y = belongs to a break section or footer The value or values belonging to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, temp_sum is reset after printing to the sum of all fields in that section_view occurrence that match any of the parms x1, x2, x3,..., and temp_count is reset to the number of matches for that occurrence. All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to zero if printing is induced. Note that, in a sense, you can say that: Average = SUM / COUNT
COUNT
The COUNT function looks like this: y = COUNT (x1, x2, x3,...)
7-8
Using Derived Data
At initialization of the report, y is set to zero. Whenever a regular section section_ID with section view section_view is conversed, any field in section_view that is matched by any of x1, x2, x3,..., increases y by 1. The value of y is increased until the section with this reference is printed. Case 1: y belongs to a regular section or header The value of y incorporates the arguments x1, x2, x3,..., and y is reset to zero after printing. Imagine, for example, that y, x1, x2, x3 all belong to the regular section sect_view and that the xarguments have no match outside sect_view. Then each converse of sect_name sets y to 3. Case 2: y belongs to a break section or footer The value or values belonging to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, y is reset after printing the number of matches in that section_view occurrence for any of the parms x1, x2, x3,.... All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to zero if printing is induced.
SUM
The SUM function looks like this: y = SUM (x1, x2, x3,...) At initialization of the report, y is set to zero. Whenever a regular section section_ID with section view section_view is conversed, then any field in section_view that is matched by any of x1, x2, x3,... is summed into y. The value of y accrues data until the section with this reference is printed. Case 1: y belongs to a regular section or header The value of y incorporates the arguments x1, x2, x3,..., and y is reset to zero after printing. Imagine, for example, that y, x1, x2, x3 all belong to the regular section sect_view and that the xarguments have no match outside sect_view. Then each converse of sect_name sets y to x1 + x2 + x3. Case 2: y belongs to a break section or footer The value or values belonging to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, y is reset after printing the sum of all fields in that section_view occurrence that match any of the parms x1, x2, x3,.... All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to zero if printing is induced.
MAXIMUM
The MAXIMUM function looks like this: y = MAX (x1, x2, x3,...)
7-9
Let MINVALUE denote the smallest value that y can hold. At initialization of the report, y is set to MINVALUE. Whenever a regular section section_ID with section view section_view is conversed, any field in section_view that is matched by any of x1, x2, x3,... is compared to y. If the largest value of those fields exceeds the current y for this particular CONVERSE REPORT statement, y is replaced with that value. This kind of processing continues during subsequent converses until the section with this reference is printed. Case 1: y belongs to a regular section or header The value of y incorporates the arguments x1, x2, x3,..., and y is reset to MINVALUE after printing. Imagine, for example, that y, x1, x2, x3 all belong to the regular section sect_view and that the xarguments have no match outside sect_view. Then each converse of sect_name sets y to the largest of x1, x2, x3. Case 2: y belongs to a break section or footer The value or values belonging to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, y is reset to MINVALUE after printing the largest of all fields in that section_view occurrence that match any of the parms x1, x2, x3,.... All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to MINVALUE if printing is induced.
MINIMUM
The MINIMUM function looks like this: y MIN (x1, x2, x3,...) Let MAXVALUE denote the largest value that y can hold. At initialization of the report, y is set to MAXVALUE. Whenever a regular section section_ID with section view section_view is conversed, any field in section_view that is matched by any of x1, x2, x3,... is compared to y. If the smallest value of those fields is less than the current y for this particular CONVERSE REPORT statement, y is replaced with that value. This kind of processing continues during subsequent converses until the section with this reference is printed. Case 1: y belongs to a regular section or header The value y incorporates the arguments x1, x2, x3,.... The value of y is reset to MAXVALUE after printing. Imagine, for example, that y, x1, x2, x3 all belong to the regular section sect_view and that the x-arguments have no match outside sect_view. Then each converse of sect_name sets y to the smallest of x1, x2, x3. Case 2: y belongs to a break section or footer The value or values belonging to the occurrence whose conversing induced the printing are not reflected in the printing. Rather, y is reset to MAXVALUE after printing the smallest of all fields in that section_view occurrence that match any of the parms x1, x2, x3,.... All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to MAXVALUE if printing is induced.
7-10 Using Derived Data
These are the formatting functions: CENTER DATE LEFT RIGHT TIME
CENTER
The CENTER function looks like this: y = CENTER (x) At initialization of the report, y is set to blanks. Whenever a regular section section_ID with section view section_view is conversed, the field in section_view, which is matched by x, is considered the source for this CENTER statement. Centering removes all leading and trailing blanks from x. The result is mapped to y and centered by moving half of the trailing blanks to the front. If a picture override is specified for y, it takes precedence over its repository-defined storage type. If the storage size of y is less than the length of x with its leading and trailing blanks removed, then y contains the leftmost characters of the stripped version of x. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent CONVERSE REPORTSECTION statements may alter the value of y repeatedly until a converse prints section_ID. Case 1: y belongs to a regular section or footer The value of x is first centered into y and then printed. Afterward y is reset to spaces. Case 2: y belongs to a break section or header The old y is printed and then x is centered into y. All cases If none of the fields in section_view match any of the arguments, y remains unchanged if printing is not induced, and y is reset to spaces if printing is induced.
DATE
The DATE function looks like this: y = DATE (x) Eleven date formats are available to reports. Refer to Adding and Modifying Date or Time in Chapter 2, Using Report Painter. When working within Report Painter, select one by checking the DATE function and a formatting template. In this document these functions are referred to as DATE.
7-11
The function DATE is a formatting function that takes an integer-valued argument x and transform it into a character string according to a formatting template. At initialization of the report, y is set to blanks. Whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this DATE statement and is converted to y as described above. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORTSECTION statements can alter the value of y repeatedly until a converse prints section_ID. Case 1: y belongs to a regular section or header The value of y is first set to DATE(x) and then printed. Afterward y is reset to spaces. Case 2: y belongs to a break section or footer The old y is printed and then y is set to DATE(x). All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to spaces if printing is induced.
LEFT
The LEFT function looks like this: y = LEFT (x) When the report is initialized, y is set to blanks. Whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this LEFT statement. LEFT stands for left justification and removes all leading blanks from x. The result is mapped into y. If a picture override is specified for y, it takes precedence over its repository-defined storage type. If the storage size of y is less than the length of x with its leading blanks removed, y contains the leftmost characters of the stripped version of x. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORT SECTION statements can alter the value of y repeatedly until a converse prints section_ID. Case 1: y belongs to a regular section or header The value of x is first left justified into y and then printed. Afterward y is reset to spaces. Case 2: y belongs to a break section or footer: The old y is printed and then x is left justified into y. All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to spaces if printing is induced.
7-12
Using Derived Data
RIGHT
The RIGHT function looks like this: y = RIGHT (x) When the report is initialized, y is set to blanks. Whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this RIGHT statement. RIGHT stands for right justification and shifts x to the right until all trailing blanks are gone. The result is mapped into y. If a picture override is specified for y, it takes precedence over its repository-defined storage type. If the storage size of y is less than the length of x with its trailing blanks removed, y contains the leftmost characters of the stripped version of x. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORT SECTION statements may alter the value of y repeatedly until a converse prints section_ID. Case 1: y belongs to a regular section or header The value of x is first right justified into y and then printed. Afterward y is reset to spaces. Case 2: y belongs to a break section or footer The old y is printed and is right justified into y. All Cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to spaces if printing is induced.
TIME
The TIME function looks like this: y = TIME (x) Twelve time formats are available to reports. Refer to Adding and Modifying Date or Time in Chapter 2, Using Report Painter. When working within Report Painter, select one of them by checking the TIME function and a formatting template. In this document, they are referred to as TIME. The TIME function takes an integer-valued argument x and transform it into a character string according to a formatting template. When the report is initialized, y is set to blanks. Whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this TIME statement and converted to y as described above. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORT SECTION statements can alter the value of y repeatedly, until a converse prints Section_ID. Case 1: y belongs to a regular section or header The value of y is first set to TIME(x) and then printed. Afterwards y is reset to spaces. Case 2: y belongs to a break section or footer The old y is printed and then y is set to TIME(x).
7-13
Copy Functions
All cases If none of the fields in section_view matches any of the arguments, y remains unchanged if printing is not induced, and y is reset to spaces if printing is induced.
Copy Functions
There are two copy functions: COPY COPYCURR
COPY
The COPY function looks like this: y = COPY (x) y is set equal to x in the following sense: whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this COPY statement, and y is set equal to its value. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORT SECTION statements can alter the value of y repeatedly until a converse prints section_ID. In this case, the old y is printed, and then x is copied into y. See the next example below, which contrasts both COPY and COPYCURR functionality in the context of break processing.
COPYCURR
The copy current (COPYCURR) function looks like this: y = COPYCURR (x) y is set equal to x in the following sense: whenever a regular section section_ID with section view section_view is conversed, the field in section_view that is matched by x is considered the source for this COPY statement, and y is set equal to its value. If there is no match within section_view, y remains unchanged as a result of this converse. Subsequent converse REPORT SECTION statements can alter the value of y repeatedly, until a converse prints section_ID. In this case, x is copied into y before printing. In other words, the currently conversed value of x is printed, rather than the most recently conversed value, as is the case with the use of COPY. See the examples below which contrasts both COPY and COPYCURR functionality in the context of break processing. Example: COPY vs. COPYCURR Assume you have a section cust_data that looks like this: Customer: Name: cust_ID cust_name
7-14
Using Derived Data
Phone Number: Balance:
cust_phone cust_bal_amt
If your purpose is to use cust_data as a break section that, for example, summarizes cust_bal_amt SUM (.....) where the arguments for SUM are appropriate dollar figures from regular section views, you would specify cust_ID cust_name cust_phone cust_bal_amt COPY COPY COPY SUM (cust_ID of...) (cust_name of...) (cust_phone of...) (.....)
On the other hand, if the above functions as a header section where cust_bal_amt is not derived from previous converses but directly specified as regular data, then you would write: cust_ID cust_name cust_phone cust_bal_amt COPYCURR COPYCURR COPYCURR COPYCURR (cust_ID of...) (cust_name of...) (cust_phone of...) (cust_bal_amt of...)
Otherwise if a page eject event is triggered when customer Smith is conversed, but the previously conversed customer is Jones, the header data still refer to Jones, even though none of the other data on the page related to him.
These are the miscellaneous functions: STARTUP DATE and CURRENT DATE STARTUP TIME and CURRENT TIME PAGE NUMBER
7-15
STARTUP DATE and CURRENT DATE

The start date (ST_DATE) and current date (CU_DATE) functions looks like this: y = ST_DATE y = CU_DATE
There are eleven date formats for both the startup date function and the current date function. Refer to Adding and Modifying Date or Time in Chapter 2, Using Report Painter. When working within Report Painter, select one of them by checking a formatting template. In this document, the startup date function is referred to as ST_DATE, and the current date function is referred to as CU_DATE. Note that you do not select startup and current dates for a field y of the section, but that you rather drop a date object on the section canvas. ST_DATE retrieves the system date at the time the report startsthe time at which the CONVERSE REPORT... START statement executesand CU_DATE retrieves the system date at approximately the time that the section prints.
STARTUP TIME and CURRENT TIME

The start time (ST_TIME) and current time (CU_TIME) functions looks like this: y = ST_TIME y = CU_TIME
There are twelve time formats for startup time functions and current time functions. Refer to Adding and Modifying Date or Time in Chapter 2, Using Report Painter. When working within Report Painter, select one of them by checking a formatting template. In this document the startup time function is referred to as ST_TIME, and the current time function is referred to as CU_TIME. You do not select startup and current times for a field y of the section; instead you drop a time object on the section canvas. The function ST_TIME retrieves the system time at the time the report starts (the time the CONVERSE REPORT START executes), and the function CU_TIME retrieves the system time at approximately the time that the section prints.
PAGE NUMBER
The page number (PAGE) function looks like this: y = PAGE The PAGE function shares the following properties with startup and current date/time functions: It does not accept any arguments. It is not associated with a section view field y, but rather dropped as a PAGE NUMBER object onto the section canvas. The value of y is the page number of the report. Page numbering for reports starts with one.
Caution
Subheader data always represents information from a previous printing of the section. So if the PAGE NUMBER object appears in a subheader you see a misleading page number. Do not use the page function in sections that are used as subheaders.
7-16
Using Derived Data
CHAPTER
FORMATTING FIELDS
Report Writer knows the format in which a field is to be printed by either the default value derived from its data type or how you override the default with Report Painter. You can even associate a dynamic edit picture with that field and determine at runtime how you want it to be printed. Topics include: Picture Clause Edit Picture Characters Dynamic Edit Pictures Other Formatting Features Refer to the System Components Reference Guide for information on CDYNPIC, a system component that handles dynamic picture editing. The formatting system component CDYNPIC is not implemented in Java because dynamic pictures support does not need this component.
Picture Clause
The Picture Clause field permits you to specify an Edit Picture that lets you format data with leading dollar signs, floating signs, explicit decimal point and the like. Even though they can look quite similar, such Edit or Display Pictures are in strong contrast to the Internal or Storage Picture that is offered as one of the data types. The reason for this is that Edit Pictures, such as Z,ZZZ,ZZZ.99, deal with formatting data the way the user would like them to appear, whereas Storage Pictures, such as S9999999V99, determine how data are stored in variables during internal processing such as mapping them between fields. (Refer to the Rules Language Reference Guide for information about PIC data types in local declarations and refer to Enterprise Application Guide for information about the field edit screen in the Enterprise Repository).
8-1
Edit Picture Characters

The Picture clause must consist exclusively of Edit Picture characters. Edit Picture characters contain a combination of any of the characters summarized in Table 8-1. Restrictions for Java applications are summarized in Edit Picture Characters in Java.
Table 8-1 Edit Picture characters
Edit Picture character
Meaning Echoes $ (Floating Character) Echoes any digit (19) and replaces 0 with <space> (Floating Character) Check protection character to avoid leading spaces (Floating Character) Precedes negative numbers with a minus (-). Nothing is printed for positive numbers. (Floating Character or Sign Character) Precedes negative numbers with a minus (-). Precedes positive numbers with a plus (+). (Floating Character or Sign Character) Echoes any digit (0 - 9) Echoes decimal point: at most one per Picture Echoes , Echoes /; useful for date formatting Empty space
$ Z * -
+ 9 . , /
( ) S CR DB
Can have any number inside to repeat a character (Repetition Clause) Precedes negative numbers with a minus (-). Nothing is printed for positive numbers. (Sign Character) Negative numbers get a CR suffix. Nothing is printed for non-negative numbers. (Sign Character) Negative numbers get a DB suffix. Nothing is printed for non-negative numbers. (Sign Character)
Floating Character
Floating characters have the following property: if you specify them several times in a row, possibly garnished with separation characters, such as commas or decimal points (this construct is called a floating field), this field holds up to as many digits as there are floating characters. At runtime, if there are fewer digits than there are floating characters, the leftmost excessive characters are replaced with spacesincluding the Insertion Characters inside that left area. See Table 8-1 for a list of floating characters. See Table 8-3 for examples of how these are used to create floating fields. If the Picture clause is $Z,ZZZ,ZZZ.99 and the field value is 1234.56, Z,ZZZ,ZZZ is a floating field. The three leftmost Z values together with the , that they surround are unused and replaced with four blanks. The resulting formatted value is $_ _ _ _1,234.56 (where _ = blank space).
8-2
Formatting Fields
Repetition Clause
A character that may be specified several times in a row can be followed by a number nn enclosed in parentheses. This is an abbreviated form of an edit picture. Note that nn specifies how many times the preceding edit picture character is supposed to appear. Some examples of Repetition clauses are shown in Table 8-2.
Table 8-2 Examples of Repetition clauses i... is equivalent to this Result $ZZZZ9.99 $Z9999.99
Repetition clause ... $Z(4)9.99 $Z9(4).99
There is a special Picture clause of the form &VPnnn that serves as placeholders for dynamic edit pictures. (See Dynamic Edit Pictures for details.)
Trailing Blank
An Edit Picture may have trailing blanks.
Insertion Character
Insertion characters are ., ,, / or and can be inserted between other characters. Only one decimal point, ., is allowed.
Sign Character
You cannot have both a plus (+) and a minus (-) in the same Edit Picture clause. Unless (+) or (-) is a floating field in the Picture clause, specify one (+) or (-). You can have only one CR or DB in the Edit Picture. You cannot have both, and either must be specified at the very end. Plus (+) or minus (-) can coexist with either CR or DB but they cannot appear as suffixes in this case. The first sign character (+, - or S) cannot be preceded by 9, Z, or *, unless it happens to the right of the decimal point. If the picture does not contain a decimal point, the first sign character cannot be preceded by $, 9, Z, or *, unless its the very last character (such as 999- or 999+). If a decimal point is present and the first sign occurs to the left of the decimal, it cannot be preceded by $, 9, Z, or *.
Edit Picture Characters in Java

Report Writer runtime uses AppBuilder runtime format routines, so edit picture characters and edit picture formats are the same as in the section on Character String Functions in the Rules Language Reference Guide. The repetition clause and floating characters are not supported.
8-3
Dynamic Edit Pictures
Examples A floating field is built from one of the Floating Characters by repeating it zero or more times and mixing it with any combination of Insertion Character, subject to the other validation rules. A floating field cannot be preceded by 9 or Z or *. A picture cannot contain more than one floating field. Table 8-3 shows some examples of floating fields.
Table 8-3 Picture 9999.99 zzzz.99 $$$$$.99 $ZZZZ.99 $****.99 ++,+++ ++,+++ ++,+++ ,,,$$$,999CR $$$,999CR $$$,999DB $$$,999DB Examples of floating fields Sample value 0001.23 0001.23 0001.23 0001.23 0001.23 1234 0123 -1234 1234 0123 -1234 98765 -98765 98765 -98765 Edited result 0001.23 1.23 $1.23 $1.23 $***1.23 +1,234 +123 -1,234 1,234 123 -1,234 $98,765 $98,765CR $98,765 $98,765DB

Typically, you may want to format derived data such as the sum of an amount, say report_name_amt, to appear within a break section. Because the rule that drives the report does not know when that break occurs, the rule must have a way to relate to the report at runtime what the format of report_name_amt should look like if it is printed then. This question arises, for example in the context of multi-currency support, where you would like to print a sum of Japanese yen with a scale other than a sum of U.S. dollars. Dynamic edit pictures is a way to change the Picture format of a section view field implemented within Report Writer. National Language Support (NLS) is not provided for dynamic edit pictures. Not all types of fields can be dynamically displayed. These are the restrictions: The field in question must be numeric. If the field is regular, it must be specified in the section view with integer format in the sense that its type is either Smallint or Integer or PIC'S9999999' (with no virtual decimal point V) or DEC(n, 0) (scale is zero). If the field is derived through a functional relation y = F (x1, x2, x3, ...), F must be one of the arithmetic functions AVERAGE, COUNT, MAX, MIN, SUM. Unless you deal with COUNT which is always an integer value, all the parameters x1, x2, x3,... must be integer values as defined in condition C.
8-4
Formatting Fields
The first two restrictions mean that you pass a number as a number sequence of digits and a scale value to place the decimal point. This allows you to process both numbers with large integer portion and small fractional portion (such as Japanese yen) and numbers with relatively small integer portion and large fractional portion (such as British pound sterling) at the same time, even though AppBuilder numeric fields have a precision restriction of 15 digits.
Dynamic Edit Pictures in Java

Dynamic edit pictures are fully implemented. You specify or modify them as described with only one difference: because of differences in implementation, return code (COMPLETE OF HPSETVPO) is always 0. Data (both derived and regular) are not formatted at the time of an HPSETVP call (because it is unknown at this time), so this component just sets the format for this data and the format is used when data are printed to the page. Thus, the return code is always 0 (Successfully formatted). The formatting system component CDYNPIC is not implemented in Java because dynamic pictures support does not need this component.
Example
For this example of dynamic edit pictures, assume that the information in Table 8-4 holds.
Table 8-4 Report names Name of report An amount field in a regular section May be derived, for example, disp_amt = SUM ( report_name_amt)
Report_name report_name_amt disp_amt
(See Chapter 7, Using Derived Data for details on the SUM function.) Report Painter accepts a PIC specification of &VPnnn where nnn represents a sequence of three digits. Examples are &VP743 or &VP456. Suppose you want to communicate to the report RXYZ that &VP456 should be PIC '+ZZZZ999.99' from now on. This is accomplished by the HPSETVP system component invoked at runtime from the rule driving the report. The component uses this input 01 HPSETVPI 03 KEY_LONG_NM char(30) 03 VPTAG char(16) 03 VPICTURE char(30) 03 VPSCALE smallint and returns this output 01 HPSETVPO 03 COMPLETE integer VPICTURE contains a PIC specification such as +ZZZZ999.99. COMPLETE returns one of the return codes shown in Table 8-5. *> *> *> *> Long name; here: Report_name <* here: VP456 <* here: +ZZZZ999.99 <* See below <*
8-5
Table 8-5
HPSETVP component return codes Description Successfully formatted Scale is more than the maximum length Input contains non-digits Input contains scientific notation Input amount is negative even though the picture clause does not contain a sign The picture does not cover input amount (an overflow condition occurred)
Return code 0 1 2 3 5 6
The & of &VPnnn is not specified in VPTAG. If RXYZ has eight multi-currency fields, three of which have the identical tag VP743, then all three fields are associated at any given time with the same PIC specification. Now we explain the role of the VPSCALE of HPSETVPI input to HPSETVP. Remember that numeric arguments to be dynamically formatted must be supplied to Report Writer as integers. While you process one kind of data, you can set VPSCALE accordingly, say zero for Japanese yen or four for British pound sterling. In the latter case all the data that you supply as integers are summed, averaged, minimized, or maximized as integers, but the result is divided by 10,000 before it is printed according to VPICTURE. See Table 8-6 for VPSCALE values.
Table 8-6 VPSCALE values Description No scale Value in field divided by 10 Value in field divided by 100 Value in field divided by 1000
VPSCALE value 0 1 2 3
8-6
Formatting Fields
Other Formatting Features

This section deals with some miscellaneous formatting features of Report Writer: Skipping Fields Underlining Fields and Text
Skipping Fields
You can skip the printing of a field as long as its value remains unchanged. Mark the Skip check box for any field to be printed in a section during your Report Painter session to specify that it should be printed only if it differs from its previous value. If a field is defined with both the skip and the underline formats, the field is skipped, but the underline still occurs. The notion of being different is based on the section rather than the section view in the following sense: whenever the value of a skip field remains unchanged during consecutive printings of the section, then it is printed only for the first time but not for all consecutive times. If the skip field skip_field appears in two regular sections section_1 and section_2 which own the same section view and if the sequence of converses is as follows: MAP 1 TO skip_field MAP 2 TO skip_field MAP X TO skip_field where X is a numeric field then X appears if X is 1 X does not appear if X is 2 This is the rationale: in the first case, the value of skip_field remains constant during two consecutive printings of section_1 but its value changed from 2 to 1 during two consecutive converses, and we do not skip. In the second case, however, the value of skip_field changed from 1 to 2 during two consecutive printings of section_1 but its value remains constant during two consecutive converses, and we skip. You can skip derived data, but you cannot skip text (labels). CONVERSE .... section_1 CONVERSE .... section_2 CONVERSE .... section_1
Underlining Fields and Text

For any field or text to be printed in a section you can mark the Underline check box during your Report Painter session and thus specify that this entry is to be underlined whenever it is printed. Any item that can be skipped can also be underlined at the same time.
8-7
8-8
Formatting Fields
CHAPTER
DEFINING DRIVER RULES
Rules can drive a report. A single rule does not necessarily drive a report. Subrules can subcontract part of the work such as retrieving and conversing lower-level data. This section summarizes the different things that can be done with a driver rule. These include: Printing a Report Feeding Data to a Regular Section Starting a Report Ending a Report Reassigning a Section Subheader Level Getting Data from a Report
Printing a Report
There are two ways you can print reports on the mainframe. The first way is batch printing, and the second is CICS printing. The method you choose determines the syntax of the rules code you write to control the printing. Rules can control the printing of reports by conversing section data to that report. The CONVERSE REPORT command comes in the following flavors: CONVERSE REPORT report_name START CONVERSE REPORT report_name PRINTER printer_name START *>For CICS printing only<* CONVERSE REPORT report_name SECTION section_name CONVERSE REPORT report_name SECTION section_name SUBHEADER subheader_level CONVERSE REPORT report_name SUBHEADER subheader_level OFF CONVERSE REPORT report_name END Because reports can be executed in batch mode or in CICS on the mainframe, the rules execution environment must be specifically set to BATCH or CICS depending on which printing method you choose. Rule syntax differs between the two environments. If the incorrect execution environment is specified, then a syntax error occurs. Correct syntax for both types of reports is described in Starting a Report.
9-1
Feeding Data to a Regular Section
Generally speaking, the same driver rule might be used to print a report on a workstation in Java mode, but if your CONVERSE REPORT START contains a PRINTER clause, you usually must set the printer name to another name, the name of the workstation printer. Java Report Writer supports the CONVERSE REPORT START statement with and without the PRINTER parameter. Refer to Printing a Report in Java in Chapter 10, Generating Reports for more information.
Feeding Data to a Regular Section

If you have worked with batch rules before, you know how to retrieve data from external sources: DB2 databases through the use of SQL ASISENDSQL constructs Flat files through the use of system components such as HPREAD With your own components to access your data stores CONVERSE REPORT R2 START SQL ASIS DECLARE CSR2 CURSOR FOR SELECT TIME_IN, TIME_OUT, TYPE, YEAR, AMOUNT, CONS_RATE, DAY, DEPT_#, EMP_NAME, HRS, MONTH, MONTH_# FROM HPSDV.EMPREP ORDER BY DEPT_#, TYPE DESC, EMP_NAME, YEAR, MONTH_#, DAY ENDSQL SQL ASIS OPEN CSR2 ENDSQL SQL ASIS FETCH CSR2 INTO :R2V1.R2_TIME_IN, :R2V1.R2_TIME_OUT, :R2VQ.R2_TYPE, :R2V1.R2_YEAR, :R2V1.R2_AMOUNT, :R2V1.R2_CONS_RATE, :R2V1.R2_DAY, :R2V1.R2_DEPT_NO, :R2V1.R2_EMP_NAME, :R2V1.R2_HRS, :R2V1.R2_MONTH, :R2V1.R2.MONTH_NO ENDSQL SQL ASIS CLOSE CSR2 ENDSQL CONVERSE REPORT R2 SECTION R2REG CONVERSE REPORT R2 END Being able to retrieve the data that is to appear on the report in the correct sequence is a big step towards creating a report application. In reports, formatted data is conversed to the screen, one panel at a time, just as in workstation applications. Whenever you want a section to be printed, converse it to the report through this statement: CONVERSE REPORT report_name SECTION regular_sect_name The CONVERSE REPORTSECTION: 1. 2. 3. Transfers control to the report with name report_name. Communicates the data in the section view related to the section with name section_name to the report report_name. Causes the report to do its internal processing, which entails some or all of the following: Processes page eject including subheaders (see Chapter 4, Setting Page Placement Options and Chapter 5, Creating Subheaders)
9-2 Defining Driver Rules
Starting a Report
Updates data derived partially or entirely from section_names Section View (see Chapter 7, Using Derived Data) Processes page breaks (see Chapter 6, Creating Break Sections) Prints regular section section_name 4. Returns the AppBuilder Report Communication Area (RPTCA) to the rule (see RPTCA Fields).
Only regular sections can be conversed.
Starting a Report
Conversing regular sections is by far the most important thing that you do in a rule with respect to reports. But before you can converse the first section to the report, you must tell Report Writer that you are about to begin printing a report. This tells the AppBuilder environment to initialize its global work areas, which store items such as derived data, the current page and line number, and many other fields across many section converses. The commands for starting a report targeted for batch printing differ from the command for starting a report targeted for CICS printing, in that CICS reports require printer information. For a batch report, the start statement is as follows: CONVERSE REPORT report_name START CICS reports require a four-character printer designation at the end of the command: CONVERSE REPORT report_name PRINTER printer_name START For a Java report, you can use both statements to start a report. The PRINTER clause is optional. Refer to Printing a Report in Java in Chapter 10, Generating Reports for more information If printing the report is distributed over more than one rule in your process, issue the start statement only once for the entire report and not once per rule. This start command sets up global storage for report_name which is needed in all of the other CONVERSE REPORT report_name statements. Note that any subsequent issuing of CONVERSE REPORT report_name START restarts the report by resetting the page and line number to one.
9-3
Ending a Report
Ending a Report
To end a report, execute the command CONVERSE REPORT report_name END after any other statement of the form CONVERSE REPORT report_name is issued. If printing the report is distributed over more than one rule in your process, issue this statement only once for the entire report and not once per rule. CONVERSE REPORT report_name END releases the global storage that was allocated for report_name in the corresponding converse report report_name START statement. It also prints the final break sections. If you forget to issue the CONVERSE REPORT report_name END statement, you usually do not abend (abort end) or receive any other clue from the AppBuilder environment, but your report is missing the final break sections.
Reassigning a Section Subheader Level

Subheaders are regular sections that are repeated at the beginning of each page according to their subheader level number that denotes their position in the subheader hierarchy. In other words, the page layout is: Header section Subheader section 1 Subheader section 2 Subheader section N, where N depends on what regular section causes the page eject Other regular sections and break sections Footer section For each particular page, the last subheader section depends on what regular section causes the page eject. (For more detailed information on subheaders see Chapter 5, Creating Subheaders) At the rules execution you can dynamically alter the subheader level number of a regular section by issuing either of the CONVERSE REPORT statements described below. Given a report named report_name and regular section named section_name, the statement CONVERSE REPORT report_name SECTION regular_sect_name SUBHEADER nnn where nnn is a numeric field or literal or symbol
9-4
Defining Driver Rules
Getting Data from a Report
This statement tells the report that, from now on, section_name has subheader sequence number nnn. This remains true until a subsequent statement of the above kind redefines that number, the report ends, or the following statement is issued: CONVERSE REPORT report_name SUBHEADER mmm OFF This statement resets to zero any subheader sequence number that is at least as big as mmm. In other words, any regular section with subheader sequence number greater than or equal to mmm loses the subheader property. Note that mmm can be a numeric literal, set symbol, or field.

When executing a CONVERSE REPORT statement, the rule temporarily relinquishes control to that report. When the report finishes processing that statement, it returns information to the calling rule by means of the system view RPTCA, which is also known as the AppBuilder report communication area. For example, the report returns to the rule on which page and line the next section is to be printed. You can view the report communication area in the Enterprise Repository like any other view. Do not modify RPTCA; certain programs in the AppBuilder environment reference its members for internal processing. The RPTCA fields are read-only for your rule. Although mapping data to the RPTCA does not flag any error during preparation, it has no effect because RPTCA is routinely cleared whenever the report regains control.
RPTCA Layout
The layout of the AppBuilder communications area is shown below. DCL RW_CODE CHAR (04); SRC_LINE_NO SMALLINT; RW_TEXT CHAR (30); RW_PAGE_NBR SMALLINT; RW_LINE_NBR SMALLINT; RW_LOWEST_BRK_LVL SMALLINT; RW_LAST_SECT_PRT_S CHAR (08); RW_LAST_SECT_PRT_L CHAR (30); RW_PAGE_BRK SMALLINT; RW_ABS_PAGE_NBR SMALLINT; RPTCAVIEW CONTAINS RW_CODE, SRC_LINE_NO, RW_TEXT, RW_PAGE_NBR, RW_LINE_NBR, RW_LOWEST_BRK_LVL, RW_LAST_SECT_PRT_S, RW_LAST_SECT_PRT_L, RW_PAGE_BRK, RW_ABS_PAGE_NBR; ENDDCL
If you are not familiar with the above syntax, refer to the topic on local declarations in the Rules Language Reference Guide.
RPTCA Fields
Table 9-1 defines the RPTCA fields.
Table 9-1 RPTCA field definitions Description Return code. Unused. Detail description associated with RW_CODE. Page number where printing resumes. PAGE is reset to 1 after each FIRST PAGE or LAST page eject. Line number where printing resumes. Lowest break level sequence number (zero if this converse did not trigger a break). System ID of last section printed. Name of last section printed. Number of page breaks N since previous converse (of the same report). Same as RW_PAGE_NBR but cumulative across FIRST PAGE and LAST PAGE page ejects.
Field name
RW_CODE SRC_LINE_NO RW_TEXT RW_PAGE_NBR RW_LINE_NBR RW_LOWEST_BRK_LVL RW_LAST_SECT_PRT_S RW_LAST_SECT_PRT_L RW_PAGE_BRK RW_ABS_PAGE_NBR
9-6
Defining Driver Rules
CHAPTER
10
GENERATING REPORTS
Once you have created a report in Report Painter and Report Writer, you are ready to generate the report. For C and COBOL, you generate the reports on the mainframe. For Java, you generate the report on the workstation. If you are generating a report in Java, be sure to read the section on C and COBOL for better understanding of the process. The explanation of reports in Java assumes that you have read the C and COBOL section. The information on report generation includes: Generating a Report in C or COBOL Generating a Report in Java
Generating a Report in C or COBOL

To generate a report for C or COBOL on the mainframe, follow these procedures: Preparing a Report on the Mainframe Printing a Report on the Mainframe Handling Report Errors
Preparing a Report on the Mainframe

After you define the relationships between the rule, reports, sections, views and fields using the Hierarchy window in the Construction Workbench, you paint the reports with the Report Painter tool. Then upload these new objects to the Enterprise Repository. Note that section data, such as the coordinates of fields and text objects, are not stored in the repository tables. Instead, they are stored in separate section files that you can access only through the Report Painter. Therefore select Files when uploading to the Enterprise Repository. After uploading, the next step is preparing the report on the mainframe. The following procedures outline the preparation process. (For detailed information, refer to the Enterprise Application Guide.) 1. 2. 3. 4. Log on to the mainframe TSO region and invoke the AppBuilder environment by choosing HPS from the ISPF/PDF Primary Option Menu. Choose option 1 for ER (enterprise repository) on AppBuilder menu. Select Reports from the Entities menu. List the report instances either by name or by system ID. Tab to the menu bar of the report you want to prepare. Invoke the Prepare method on the report by entering PR next to the report.
10-1
This submits a batch job that generates COBOL code and links that code to the AppBuilder batch run-time environment, or to the CICS run-time environment, depending on how you intend to print the report and how you have written your rules.
Understanding the Generating Process

Preparing a report (see Chapter 3, Developing Report Sections) initiates the sequence of events shown in Figure 10-1.
Figure 10-1 High-level flow diagram for generating report Generate Report Bind File Report Bind File
Repository
Section File
Report Generator
Error Listing
COBOL Code
The enterprise repository information (such as what sections are tied to the report, the page length, each sections type, and section view layouts) is extracted into the report bind file which usually resides at &PREFIXU..&LEVELU.DDXFILE.report_systemid Example: SS0009.USER1.DDXFILE.AFXSVY Each section in the report is contained in: &PREFIXU..&LEVELU..SECTLIB(section_systemid) Example: SS0009.USER1.SECTLIB(AFXTVY) The Report Generator program takes this file along with all section files that were created by Report Painter and produces COBOL code to be linked into the batch run-time environment. A listing is produced as the first segment of the results method. Figure 10-2 shows what happens in greater detail
10-2
Generating Reports
Figure 10-2
More detailed flow of generating report
Repository: Reports, Sections, Views, Fields
Report Bindfile
Error Listing
Symbol Table
GENERATE REPORT BINDFILE
CREATE SYMBOL TABLE
GENERATE CODE (Modified Code Generator)
COBOL Code
Section File GENERATE RULES CODE (Temporary)
Rules Code
The section file and the report bind file data are extracted into a symbol table where they are crossreferenced in many ways for quick retrieval and update. Special lists are built that keep track of which regular data match what break conditions and enter functional relations as arguments. If there are no severe errors during input checking, rules source pseudocode is produced. A modified version of code generation processes the rule source to produce COBOL code that represents the report program.The files that play a role in the flow of data depicted here are documented in the following section. The source (RWSRC) and COBOL (XFER) files for the report are in: &PREFIX..&LEVELU..RWSRC.report_systemid Example: SS0009.USER1.RWSRC.AGXSVY &PREFIXU..&LEVELU..XFER.report_systemid Example: SS0009.USER1.XFER.AGXSVY The workstation-based syntax checker does not have the Generate code and Generate Rules code steps.
10-3
Printing a Report on the Mainframe

Report Writer supports the all points addressable (APA) feature that the IBM mainframe provides through the Print Services Facility (PSF). However, Report Writer also allows you to specify a character-based report. Both features are described below. APA Features In the Construction Workbench with a report open in the Report Painter window, right-click to view Report Properties. When the Report Properties dialog is displayed, select 3800 from the drop-down Printer list. Set the orientation of the printed report to be either portrait (long dimension vertical) or landscape (long dimension horizontal) using the Orientation radio buttons. Character-based Features In the Construction Workbench with a report open in the Report Painter window, right-click to view Report Properties. When the Report Properties dialog is displayed, select Generic using the drop-down Printer list. Set the orientation of the printed report to be either portrait or landscape using the Orientation radio buttons. If a report is targeted for CICS printing, then it is not necessary to write JCL to print it. Proper preparation of the report on the mainframe causes the report to automatically be printed at run time when the conversing rules are executed. JCL for Batch Reports To run batch rules and reports, you must write JCL. Certain restrictions and specifications apply depending on your configuration. When running a report (running the rule that converses the report), the JCL depends on whether or not the data is obtained with SQL ASIS statements from DB2 tables. There is also a slight difference between reports created for PSF and reports created for generic printers. The PSF-enabled reports need an additional //PAGEDEF DD card. Any JCL needed to run a report needs a //SYSID DD card where SYSID is the system ID of the report to be run. It denotes the file to which the printed data is to be written. With the exception of the //xyzrpt DD card and the //PAGEDEF DD card, the JCL is similar to that needed to run a batch rule accessing such resources as DB2 tables. Examples of JCL dealing with the different specific configurations include: Example 1 - generic print features Example 2 - APA features Example 3 - with APA under PSF Example 4 - without PSF Example 5 - switchable fonts or grid lines
10-4
Generating Reports
Example 1 The following sample JCL is used to run a report with generic print features that accesses a DB2 table. The HPSBATCH program (the AppBuilder batch run-time program) invokes the batch rule with system ID RPLR901 that by itself or in subrules issues diverse CONVERSE REPORT statements, each of which usually results in writing a single section occurrence to the file allocated as //report_system_ID (in this example: //HPLR900). Note that HPSBATCH is referenced indirectly by means of the RUN PROG statement towards the end of the JCL. RUN PROG(HPSBATCH) + PLAN(WRPLR901) + PARM('RPLR901') //SS0029U JOB (NA2,HPS),'LIVSCHITZ', MSGLEVEL=(1,1),CLASS=1,MSGCLASS=X,NOTIFY=SS00 29,TIME=(0,59) //* /*ROUTE PRINT PNAV //* //DB2BATCH EXEC PGM=IKJEFT01,DYNAMNBR=50,REGION=4096K //INPUT DD DUMMY //* //* The //SYSOUT data set contains a flow trace indicating the order //* the processes in the report is executed. This is a //* convenience for developers trying to figure out why their data //* is not printed as expected. The output generated is huge (more //* than 10 lines per each Section to be printed) and the data set //* should usually be dummied out.: //* //SYSOUT DD DUMMY //OUTPUT DD SYSOUT=A //* //* HPLR900 is the system ID of the report that is to be run. //* All data is "printed" into this file.: //* //HPLR900 DD DSN=SS0029.REPORT.HPLR900, // DISP=(OLD,CATLG,KEEP), // SPACE=(TRK,(1,1),RLSE),UNIT=SYSDA, // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=3990) //* //STEPLIB DD DSN=SYS1.DB2.DSNLOAD,DISP=SHR // DD DSN=DB2NAS.ALL.LOAD,DISP=SHR // DD DSN=NA.EDC.SEDCLINK,DISP=SHR // DD DSN=NA.EDC.SIBMLINK,DISP=SHR // DD DSN=NA.COBOLII.COB2LIB,DISP=SHR // DD DSN=HPSREP.USER.BATCH.LOADLIB,DISP=SHR // DD DSN=NA.CV3F.NTTRLOAD,DISP=SHR //HPLR900 DD SYSOUT=A,DCB=(RECFM=FA,BLKSIZE=133) //VIEWFILE DD DSN=NAVHP.HPSREP.BATCH.VIEWDEF,DISP=SHR //SYSPROC DD DSN=DB2NAS.ALL.SYSPROC,DISP=SHR // DD DSN=ISR.ISRCLIB,DISP=SHR // DD DSN=NA.CMDPROC,DISP=SHR //SYSHELP DD DSN=SYS1.HELP,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=* //SYSABOUT DD SYSOUT=* //SYSDBOUT DD SYSOUT=* //SYSUDUMP DD DUMMY //PLIDUMP DD SYSOUT=* //SYSTSIN DD * DSN RUN PROG(HPSBATCH) + PLAN(WRPLR901) + PARM('RPLR901') END /* // Example 2 The following JCL initiates the batch rule REMPINF (system ID) to run a report with APA features. This rule or one of its subrules issues a CONVERSE REPORT statement that usually results in writing a single section occurrence to the file allocated as //report_short_name (in this example, //HEMPLST). //SS0029R JOB (NA2,HPSD),'IGORL',CLASS=1,MSGCLASS=X, // MSGLEVEL=(1,1),CLASS=1,MSGCLASS=X,NOTIFY=SS01 15,TIME=(0,59) /*ROUTE PRINT PNAV //* //RUNBATCH EXEC PGM=HPSBATCH,REGION=2048K,PARM='REMPINF' //STEPLIB DD DSN=HPSREP.USER1.BATCH.LOADLIB,DISP=SHR // DD DSN=HPSREP.WIP.LOADLIB,DISP=SHR // DD DSN=NA.EDC.SEDCLINK,DISP=SHR // DD DSN=NA.EDC.SIBMLINK,DISP=SHR // DD DSN=NA.COBOLII.COB2LIB,DISP=SHR //SYSIN DD DUMMY //INPUT DD DUMMY //OUTPUT DD SYSOUT=A //* //* HEMPLST is the short name of the AppBuilder //* report that is to be run. //* All data is "printed" into this file.: //* //HEMPLST DD DSN=SS0029.REPORT.HEMPLST, // DISP=OLD //* //* We suggest you allocate the above data set as //* (FBA and LRECL=177 are mandatory! //* //* SPACE=(TRK,(5,5)),UNIT=SYSDA, //* DCB=(RECFM=FBA,LRECL=177,BLKSIZE=3540) //* //* The following //PAGEDEF card is the only item //* needed to produce PSF-enabled reports //* that use APA features such as grid lines //* switchable fonts. If you omit it, you have //* perfect sample JCL for "generic printer" reports. //* //PAGEDEF DD DSN=SS0029.PAGEDEF(P1EMPLST),DISP=OLD
10-6
Generating Reports
//* SAMPLE PARAMETERS FOR PAGE DEFINITION PDS //* SPACE=(TRK,(5,5)),UNIT=SYSDA, //* DCB=(RECFM=VBM,LRECL=8205,BLKSIZE=8209) //* //* The SYSOUT data set contains a flow trace //* indicating in which order //* the "processes" in the report is //* executed. This is a convenience for //* developers trying to figure out why //* their data are not printed as expected. //* The output generated is huge (more than //* 10 lines per each Section to be printed) //* and the data set should usually be dummied out. //SYSOUT DD DUMMY //SYSPRINT DD SYSOUT=* //VIEWFILE DD DSN=NAVHP.HPSREP.BATCH.VIEWDEF,DISP=SHR //SYSABOUT DD SYSOUT=* //SYSDBOUT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //PLIDUMP DD SYSOUT=* //* Example 3 The following sample JCL is used to print a report with APA features under PSF. Note that the specification of a default SBCS (single-byte character set) font and a default DBCS (double-byte character set) font in the CHARS(,) option of the //SYSUT2 DD card is necessary. Table 10-1 shows the correspondences between what is seen when using the Report Painter tool and what must be provided in the print JCL.
Table 10-1 Fonts with SBCS and DBCS Font Mincho 6-pitch Mincho 7.5-pitch Gothic 10-pitch Mincho10-pitch Gothic 15 pitch Mincho (small) Mincho (medium) I Mincho (medium) II Mincho (large) I Mincho (large) II SBCS N20N N16N H12N N12N N18N N24N N32N DBCS M40F M32F G24F M24F G16F M36F M48B M48X M64B M64X
10-7
Japanese MRI translation might change the DBCS fonts to something completely different. //SS0029P JOB (NA2,HPSD),'IGORL',CLASS=1,MSGCLASS=X, // TIME=(0,3),REGION=4096K,NOTIFY=SS0029 /*JOBPARM ROOM=GGGG //COPY EXEC PGM=IEBGENER //* FORMDEF IS DEFAULT //* PAGEDEF IS A MEMBER 'P1EMPLST' OF //* 1)SYSTEM PAGEDEF LIBRARY FOR PSF 1.3 //* 2)USER PAGEDEF LIBRARY FOR PSF 2.1 //OUTPUT1 OUTPUT FORMDEF=0101,PAGEDEF=EMPLST,CKPTPAGE=30 //* USERLIB=SS0029.AFP.PDEFLIB for PSF 2.1 //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=SS0029.REPORT.HEMPLST,DISP=SHR //SYSUT2 DD SYSOUT=A,DCB=(RECFM=FBA,LRECL=177,BLKSIZE=354 0), // BURST=Y,FREE=CLOSE,OUTPUT=*.OUTPUT1, // CHARS=(GB10,M40F) Example 4 If you do not need PSF support, you can print a report with a generic printer in a simple IEBGENER job. You can also allocate //report-system_ID as SYSOUT=A and combine running and printing the report into a single task. Example 5 If your report uses switchable fonts or grid lines but no PSF printer is available, you must change the execution environment to Mainframe Batch and prepare again. The Report Generator ignores instructions pertaining to APA features, and the report runs. The reports vertical alignment may look unacceptable because substituting a font of one size for another destroys the original arrangement. If your report has only generic print features but you want (for performance reasons) to print it to a 3800 printer, you must retarget it to Portrait 3800 Printer and prepare it again.
10-8
Generating Reports
Handling Report Errors

This topic includes: System Notification TE Method Report Generator Flow Trace Report Generator Flow Trace Details
System Notification
The system notifies you when the preparation is completed. You can then invoke the results method on the same report by entering RES next to the report. Depending on the particular situation, you can get one or more of the following results: A screen stating there are no errors and the preparation succeeded. A screen that lists the outcome of the Report Writer generator source and error listing. For example, a section file can be missing for the report. A sample error listing is shown in Figure 10-3.
Figure 10-3 Listing of Prepare entities and their source
******************************************************************************* * * * H. P. S. R E P O R T W R I T E R G E N E R A T O R Page 1 * * Version 3 Rel 3 Mod 18 Source & Error Listing * * 9-26-90 * * Report: hplr900 4:41 PM * * * ******************************************************************************* Section: SECTION_LPLR9F_FOR_RW_HPLR900 ( LPLR9F ) ------------------------------------------------(001, 040) PROB_NO OF BREAK_2_HPLR901 (PROB_NO OF VPLR9F) S-21140 This parameter does not belong to any regular input view
(001, 040) TOTAL1 (TOTAL1) S-21141 There are problems with the Function COUNT 2 SEVERE ERROR(S) DETECTED.
The error listing provides the report name and the name and system ID of each section that has errors. In the example shown in Figure 10-3, the section SECTION_LPLR9F_FOR_RW_HPLR900 with system ID LPLR9F has a field with the name TOTAL1 to be printed at column 40 of row 1. The field is engaged in the following functional relation: TOTAL1=COUNT (PROB_NO OF BREAK_2_HPLR901) The arguments x1, x2,... of functional relations must match regular section data. Message S-21140, which was printed for this parameter, states that it does not belong to any regular data. Report Writer also offers a debug facility for reports that do not prepare successfully. The job step that scans the input to the Report Writer for consistency is named HPSCG. The return code could be one of those shown in Table 10-2.
10-9
Table 10-2 Debug (HPSCG job step) return codes Return code 0 4 8 12 Description Clean preparation Informational messages were generated Warnings are generated Severe errors were detected
If the number is higher than 12, you should scan the output in the RWLOG section of your prepare job. There are two ways to debug your report if it prepares successfully but the output printout shows different results: TE Method and the Report Generator Flow Trace.
TE Method
This method is applicable for any batch rule. The TE method gives access to the following: Section view data before any CONVERSE REPORT statement. Each line the report program prints. This program uses the HPWRITE batch component to set internal breakpoints. Whether the point of execution reached CONVERSE ReportSTART. Whether the point of execution reached CONVERSE ReportEND.
Report Generator Flow Trace

The COBOL code generated is highly structured. Each task, such as printing a section or determining page eject events, is performed as a subroutine. When a subroutine is about to execute, the Report Writer writes a statement of the form ..cgdebug...ENTERING WRITE-TO-FILE... to the //SYSOUT DD data set. If the flow trace reads //SYSOUT DD DUMMY then no trace output is produced. The trace can go to the hold queue or be printed by changing the previous statement to: //SYSOUT DD SYSOUT=* The output can also be sent to a data set by specifying a DSN parameter. Refer to Report Generator Flow Trace Details for more information.
10-10
Generating Reports
Report Generator Flow Trace Details

The flow trace was developed for internal debugging of the report generator. If you understand the underpinnings of Report Writer, a flow trace can help determine run-time problems with your report because many of the trace headings are very descriptive. It is also helpful to you as the application user because it helps you detect logical errors in your report design. The following is an annotated example of a flow trace. The ..cgdebug statements belong to the trace. The indented text below represents comments. ..cgdebug...ENTERING START-REPT... CONVERSE ... START was encountered ..cgdebug...ENTERING RSET-ALL-TMPS... ..cgdebug...ENTERING RSET-SUBHDR-LEVEL... ..cgdebug...ENTERING DO-SECT-LPLR9B3S... Section LPLR9B3S (short name) was conversed ..cgdebug...ENTERING SET-CURR-PRT-LEV... ..cgdebug...ENTERING UPDT-HDR-LPLR9B3S... Updating of derived data in the header with arguments in regular Section LPLR9B3S ..cgdebug...ENTERING PAGE-BREAK-YES-NO... ..cgdebug...ENTERING PRT-HDR... Printing of the header Section occurs down the line ..cgdebug...ENTERING UPDT-PDT-LPLR9A... ..cgdebug...ENTERING RSET-TMPS-LPLR9A... ..cgdebug...ENTERING WRITE-TO-FILE... The Section to be printed (the header in this case) is printed ..cgdebug...ENTERING UPDT-FTR-LPLR9B3S... ..cgdebug...ENTERING UPDT-REG-LPLR9B3S... ..cgdebug...ENTERING UPDT-BRK-LPLR9B3S... Updating of derived data in the footer, in Section LPLR9B3S itself and in the header with arguments in regular Section LPLR9B3S ..cgdebug...ENTERING NOT-FST-LPLR9B3S... ..cgdebug...ENTERING UPDT-PDT-LPLR9B3S... ..cgdebug...ENTERING PRT-SECT-LPLR9B3S... Printing of the regular Section occurs down the line ..cgdebug...ENTERING RSET-TMPS-LPLR9B3S... ..cgdebug...ENTERING WRITE-TO-FILE... The Section conversed is printed ..cgdebug...ENTERING RET-GLOBALS... Report Writer populates RPTCA ..cgdebug...ENTERING DO-SECT-LPLR9B3C... A new regular Section was conversed ..cgdebug...-------------------- -..cgdebug...-------------------- -..cgdebug...-------------------- -..cgdebug...ENTERING END-REPT... CONVERSE ... END is executed ..cgdebug...ENTERING PRT-BRKSECTS... Printing of break Sections is imminent ..cgdebug...ENTERING PRT-FTR... ..cgdebug...ENTERING UPDT-PDT-LPLR9D... ..cgdebug...ENTERING RSET-TMPS-LPLR9D... ..cgdebug...ENTERING SPACE-FTR... ..cgdebug...ENTERING WRITE-TO-FILE... ..cgdebug...ENTERING RET-GLOBALS... Rule processing complete.
A D(nnn) parameter has been activated for HPSRW for debugging information which contains both prepare time and run-time information. This flag activates debugging code with a level L<=nnn where nnn can be 001, 002, 003, and so on. D is equivalent to D(1). The level codes L are not part of a published interface and may be changed by BluePhoenix, usually by adding more traces. Prepare time information on the workstation is equivalent to a report syntax check. Traces embedded into the .CR source files (the source that belongs to the genuine RPMG code) is written to RWLOG.LOG. Traces embedded into the Code Generator. C sources currently go to STDOUT of RWSYN.EXE. You can find prepare time information on the mainframe in the following DDnames of job step HPSCG: //RWLOG //ERR DD DD SYSOUT=* SYSOUT=*
With regard to run-time information, you currently get all of the run-time traces with level 1 and none with level 0. When entering any rule source process which was generated into the RWSRC file, the system executes a COBOL DISPLAY statement which displays the name of that PROC. (Versions of Report Writer prior to Seer*HPS 5.2.04 generated this trace unconditionally.) Whenever a report rule passes control to the report via a CONVERSE REPORT statement, the run-time trace indicates the following: Report name, which is important for driver rules which converse more than one single report Line number from where invoked Other parameters Level 1 includes generation of the run-time trace and the prepare time trace. These traces are so sparse in comparison to the parser trace, that we encourage running reports with it as a default until the application is ready for migration into production. In production, prepare the reports again without the D(nnn) parameter for the sake of efficiency.
10-12
Generating Reports
Generating a Report in Java

With Java support, reports can be designed and prepared on the Windows workstation. This topic describes how to work with Report Writer in a Java environment on the workstation. Since much of the operation is the same as Report Writer on the mainframe, this topic summarizes only the differences between Java and mainframe operation. Be sure to read Generating a Report in C or COBOL before proceeding. Generating a report in Java includes: Understanding Differences in Java Preparing a Report in Java Printing a Report in Java
Understanding Differences in Java

Since much of the operation is the same as Report Writer on the mainframe, understanding the differences between Java and mainframe operation is essential. The differences include: Break Condition in Java Error Handling in Java Font Control in Java Page Size in Java Section Left Margin Specification in Java SETDISPLAY Function in Java Skipping Fields in Java
Break Condition in Java

The break condition is resolved to real fields during report preparation. If break conditions produce no actual fields, a warning is issued and no break condition is generated for the section.
Error Handling in Java

Preparation Time Errors If report contain errors, the rule owning the report fails to prepare. Error messages are included in the rule's listing. There are a few preparation time messages such as: Error 99990 The lookup set <lookup set name> of SETDISPLAY function of the report not found. A SETDISPLAY function on one of the report's sections refers to a lookup set that cannot be found. Error 99991 Report refers to view or field "<view/field name>" which does not exists. Owner section of "<section name>" not found. A report generation facility cannot find a section to which a particular break field belongs. This might be caused by changes in the report data hierarchy without having changed the break field specification. Warning 13191 No actual fields matched specified break condition "<break condition>" in section <section name> of <report name> report.
10-13
The bind file processor generates this error in the case of no fields having a name equal to the specified break field. Debugging Rules with Reports RuleView could be used to debug rules conversing reports: trace execution flow, inspect RPTCA fields' values, etc. There are several run-time messages, generated by Report Writer run-time support library. They concern: Page size problems Section data consistency Function parameters consistency PRINT_POINT_SIZE specifications
Font Control in Java

While the mainframe supports only fixed-width fonts, most modern printers and operating systems support many fonts and most of those fonts are not fixed-width. In the Report Writer for Java, you can configure fonts by modifying the font.ini file, which allows you to change font size, font attributes, and even the font name. You can change some properties that define the font (such as font face name, size, and style properties) in the font mapping. You can also change an optional PRINT_POINT_SIZE property, which can be defined for each font which is used in Report Writer and Report Painter. Refer to the Development Tools Reference Guide appendix for an explanation of font mapping and the font.ini file.
Page Size in Java

The report page size specification has no effect on the selection of the paper size for report printing. The paper size is determined by the DEFAULT_PAGE_SIZE setting. The page size defined for a report in the Construction Workbench does affect the printing of the report for Page Eject Event in Java in Chapter 4, Setting Page Placement Options.
Section Left Margin Specification in Java

You can specify the left margin for a section measured in characters. In order to recalculate this value into printer-native coordinates, this formula is used: nativeMargin = charMargin*(charPageWidth/nativePageWidth) where charMargin is the left margin for the section in characters, nativeMargin is the margin in native units, charPageWidth is the page width (or line size) in characters, and nativePageWidth is the page width (or line size) in printer-native units. The result of charPageWidth/nativePageWidth represents the width of one character. If a 3800 printer is specified in the report properties and the report size is measured in INCHES/10, the AVERAGE_CHAR_SIZE setting in the appbuilder.ini file is used to recalculate the left margin from character units to printer native ones. In this case, nativeMargin = charMargin*averageCharWidth where averageCharWidth is the width of an average character, specified in AVERAGE_CHAR_SIZE.
10-14 Generating Reports
SETDISPLAY Function in Java

If a lookup set specified for the SETDISPLAY function does not exist for some reason (for example, the set is deleted after a report is created), an error message is issued during rule preparation.
Skipping Fields in Java

If a field is defined with both the skip and the underline formats, the field is skipped along with underline, since there is nothing to underline.
Preparing a Report in Java

To prepare a report on the workstation in Java, in the Construction Workbench, prepare the rule owning the report. You do not prepare the report by itself. For information on preparing objects, refer to the Deploying Applications Guide. The information in Chapter 9, Defining Driver Rules is valid for Java development too; you do not have to change anything in the report driver rule, except the PRINTER clause, if your driver rule has one (see Printing a Report in Java).
Printing a Report in Java

To print a report on the workstation in Java, in the Construction Workbench, execute the rule that converses the report. The report is printed to the printer specified by one of these: PRINTER clause of the CONVERSE REPORT START statement MEDIA setting of appbuilder.ini dialog if the DISPLAY_SETUP_DIALOG setting was set to TRUE For Java, the CONVERSE REPORT START can have an optional PRINTER clause, which specifies the printer name, in the usual form. For example: CONVERSE REPORT MyReport PRINTER \\myserver\printer1 START This overrides the MEDIA setting in the appbuilder.ini file.
10-15
10-16
Generating Reports
APPENDIX
A
Table A-1
SUPPORTED PAGE FORMATS
Table A-1 lists the supported page formats for Report Writer in Java. This list can also be found in Java 1.3 API specifications, class PageAttributes.MediaType.
Page formats
Page Format A A0 A1 A10 A2 A3 A4 A5 A6 A7 A8 A9 B B0 B1 B10 B2 B3 B4 B5 B6 B7 B8 B9 C
Description MediaType instance for Engineering A, 8 1/2 x 11 in. Alias for ISO_A0. Alias for ISO_A1. Alias for ISO_A10. Alias for ISO_A2. Alias for ISO_A3. Alias for ISO_A4. Alias for ISO_A5. Alias for ISO_A6. Alias for ISO_A7. Alias for ISO_A8. Alias for ISO_A9. MediaType instance for Engineering B, 11 x 17 in. Alias for ISO_B0. Alias for ISO_B1. Alias for ISO_B10. Alias for ISO_B2. Alias for ISO_B3. Alias for ISO_B4. Alias for ISO_B5. Alias for ISO_B6. Alias for ISO_B7. Alias for ISO_B8. Alias for ISO_B9. MediaType instance for Engineering C, 17 x 22 in.
A-1
Table A-1
Page formats
Page Format C0 C1 C10 C2 C3 C4 C5 C6 C7 C8 C9 D E ENV_10 ENV_10X13 ENV_10X14 ENV_10X15 ENV_11 ENV_12 ENV_14 ENV_6X9 ENV_7X9 ENV_9 ENV_9X11 ENV_9X12 ENV_INVITE ENV_ITALY ENV_MONARCH ENV_PERSONAL EXECUTIVE FOLIO INVITE INVITE_ENVELOPE INVOICE ISO_2A0 ISO_4A0 ISO_A0 ISO_A1
Description Alias for ISO_C0. Alias for ISO_C1. Alias for ISO_C10. Alias for ISO_C2. Alias for ISO_C3. Alias for ISO_C4. Alias for ISO_C5. Alias for ISO_C6. Alias for ISO_C7. Alias for ISO_C8. Alias for ISO_C9. MediaType instance for Engineering D, 22 x 34 in. MediaType instance for Engineering E, 34 x 44 in. Alias for NA_NUMBER_10_ENVELOPE. Alias for NA_10X13_ENVELOPE. Alias for NA_10X14_ENVELOPE. Alias for NA_10X15_ENVELOPE. Alias for NA_NUMBER_11_ENVELOPE. Alias for NA_NUMBER_12_ENVELOPE. Alias for NA_NUMBER_14_ENVELOPE. Alias for NA_6X9_ENVELOPE. Alias for NA_7X9_ENVELOPE. Alias for NA_NUMBER_9_ENVELOPE. Alias for NA_9X11_ENVELOPE. Alias for NA_9X12_ENVELOPE. Alias for INVITE_ENVELOPE. Alias for ITALY_ENVELOPE. Alias for MONARCH_ENVELOPE. Alias for PERSONAL_ENVELOPE. MediaType instance for Executive, 7 1/4 x 10 1/2 in. MediaType instance for Folio, 8 1/2 x 13 in. Alias for INVITE_ENVELOPE. MediaType instance for Invitation Envelope, 220 x 220 mm. MediaType instance for Invoice, 5 1/2 x 8 1/2 in. MediaType instance for ISO/DIN & JIS 2A0, 1189 x 1682 mm. MediaType instance for ISO/DIN & JIS 4A0, 1682 x 2378 mm. MediaType instance for ISO/DIN & JIS A0, 841 x 1189 mm. MediaType instance for ISO/DIN & JIS A1, 594 x 841 mm.
A-2
Supported Page Formats
Table A-1
Page formats
Page Format ISO_A10 ISO_A2 ISO_A3 ISO_A4 ISO_A5 ISO_A6 ISO_A7 ISO_A8 ISO_A9 ISO_B0 ISO_B1 ISO_B10 ISO_B2 ISO_B3 ISO_B4 ISO_B4_ENVELOPE ISO_B5 ISO_B5_ENVELOPE ISO_B6 ISO_B7 ISO_B8 ISO_B9 ISO_C0 ISO_C0_ENVELOPE ISO_C1 ISO_C1_ENVELOPE ISO_C10 ISO_C10_ENVELOPE ISO_C2 ISO_C2_ENVELOPE ISO_C3 ISO_C3_ENVELOPE ISO_C4 ISO_C4_ENVELOPE ISO_C5 ISO_C5_ENVELOPE ISO_C6 ISO_C6_ENVELOPE
Description MediaType instance for ISO/DIN & JIS A10, 26 x 37 mm. MediaType instance for ISO/DIN & JIS A2, 420 x 594 mm. MediaType instance for ISO/DIN & JIS A3, 297 x 420 mm. MediaType instance for ISO/DIN & JIS A4, 210 x 297 mm. MediaType instance for ISO/DIN & JIS A5, 148 x 210 mm. MediaType instance for ISO/DIN & JIS A6, 105 x 148 mm. MediaType instance for ISO/DIN & JIS A7, 74 x 105 mm. MediaType instance for ISO/DIN & JIS A8, 52 x 74 mm. MediaType instance for ISO/DIN & JIS A9, 37 x 52 mm. MediaType instance for ISO/DIN B0, 1000 x 1414 mm. MediaType instance for ISO/DIN B1, 707 x 1000 mm. MediaType instance for ISO/DIN B10, 31 x 44 mm. MediaType instance for ISO/DIN B2, 500 x 707 mm. MediaType instance for ISO/DIN B3, 353 x 500 mm. MediaType instance for ISO/DIN B4, 250 x 353 mm. Alias for ISO_B4. MediaType instance for ISO/DIN B5, 176 x 250 mm. Alias for ISO_B5. MediaType instance for ISO/DIN B6, 125 x 176 mm. MediaType instance for ISO/DIN B7, 88 x 125 mm. MediaType instance for ISO/DIN B8, 62 x 88 mm. MediaType instance for ISO/DIN B9, 44 x 62 mm. MediaType instance for ISO/DIN C0, 917 x 1297 mm. Alias for ISO_C0. MediaType instance for ISO/DIN C1, 648 x 917 mm. Alias for ISO_C1. MediaType instance for ISO/DIN C10, 28 x 40 mm. Alias for ISO_C10. MediaType instance for ISO/DIN C2, 458 x 648 mm. Alias for ISO_C2. MediaType instance for ISO/DIN C3, 324 x 458 mm. Alias for ISO_C3. MediaType instance for ISO/DIN C4, 229 x 324 mm. Alias for ISO_C4. MediaType instance for ISO/DIN C5, 162 x 229 mm. Alias for ISO_C5. MediaType instance for ISO/DIN C6, 114 x 162 mm. Alias for ISO_C6.
A-3
Table A-1
Page formats
Page Format ISO_C7 ISO_C7_ENVELOPE ISO_C8 ISO_C8_ENVELOPE ISO_C9 ISO_C9_ENVELOPE ISO_DESIGNATED_LONG
Description MediaType instance for ISO/DIN C7, 81 x 114 mm. Alias for ISO_C7. MediaType instance for ISO/DIN C8, 57 x 81 mm. Alias for ISO_C8. MediaType instance for ISO/DIN C9, 40 x 57 mm. Alias for ISO_C9. MediaType instance for ISO Designated Long, 110 x 220 mm.
ISO_DESIGNATED_LONG_ENVE Alias for ISO_DESIGNATED_LONG. LOPE ITALY ITALY_ENVELOPE JIS_B0 JIS_B1 JIS_B10 JIS_B2 JIS_B3 JIS_B4 JIS_B5 JIS_B6 JIS_B7 JIS_B8 JIS_B9 LEDGER LEGAL LETTER MONARCH MONARCH_ENVELOPE NA_10X13_ENVELOPE NA_10X14_ENVELOPE NA_10X15_ENVELOPE NA_6X9_ENVELOPE NA_7X9_ENVELOPE NA_9X11_ENVELOPE NA_9X12_ENVELOPE NA_LEGAL NA_LETTER NA_NUMBER_10_ENVELOPE Alias for ITALY_ENVELOPE. MediaType instance for Italy Envelope, 110 x 230 mm. MediaType instance for JIS B0, 1030 x 1456 mm. MediaType instance for JIS B1, 728 x 1030 mm. MediaType instance for JIS B10, 32 x 45 mm. MediaType instance for JIS B2, 515 x 728 mm. MediaType instance for JIS B3, 364 x 515 mm. MediaType instance for JIS B4, 257 x 364 mm. MediaType instance for JIS B5, 182 x 257 mm. MediaType instance for JIS B6, 128 x 182 mm. MediaType instance for JIS B7, 91 x 128 mm. MediaType instance for JIS B8, 64 x 91 mm. MediaType instance for JIS B9, 45 x 64 mm. MediaType instance for Ledger, 11 x 17 in. Alias for NA_LEGAL. Alias for NA_LETTER. Alias for MONARCH_ENVELOPE. MediaType instance for Monarch Envelope, 3 7/8 x 7 1/2 in. MediaType instance for North American 10 x 13 in. MediaType instance for North American 10 x 14 in. MediaType instance for North American 10 x 15 in. MediaType instance for North American 6 x 9 in. MediaType instance for North American 7 x 9 in. MediaType instance for North American 9 x 11 in. MediaType instance for North American 9 x 12 in. MediaType instance for North American Legal, 8 1/2 x 14 in. MediaType instance for North American Letter, 8 1/2 x 11 in. MediaType instance for North American #10 Business Envelope, 4 1/8 x 9 1/2 in.
A-4
Table A-1
Page formats
Page Format NA_NUMBER_11_ENVELOPE NA_NUMBER_12_ENVELOPE NA_NUMBER_14_ENVELOPE NA_NUMBER_9_ENVELOPE NOTE PERSONAL PERSONAL_ENVELOPE QUARTO STATEMENT TABLOID
Description MediaType instance for North American #11 Business Envelope, 4 1/2 x 10 3/8 in. MediaType instance for North American #12 Business Envelope, 4 3/4 x 11 in. MediaType instance for North American #14 Business Envelope, 5 x 11 1/2 in. MediaType instance for North American Med#9 Business Envelope, 3 7/8 x 8 7/8 in. Alias for NA_LETTER. Alias for PERSONAL_ENVELOPE. MediaType instance for 6 3/4 envelope, 3 5/8 x 6 1/2 in. MediaType instance for Quarto, 215 x 275 mm. Alias for INVOICE. Alias for LEDGER.
A-5
A-6
Index
INDEX
A
alignment bar 2-8 All Points Addressable (APA) 10-4 ambiguous break conditions 6-3 appbuilder.ini file 1-4 argument 7-3, 7-9 arithmetic function average 7-8 in report 7-7, 7-8 maximum 7-10 minimum 7-10 sum 7-9 average, arithmetic function 7-8
C
CDYNPIC 8-1, 8-5 center formatting function 7-11 character floating 8-2 insertion 8-3 sign 8-3 condition, break 1-10 consistency conditions 3-6 CONVERSE 6-2, 7-2, 9-1 CONVERSE REPORT START statement 9-2 coordinates of element 2-9 copy 7-14 copy function types 7-14 copy 7-14 copy vs. copycurrent 7-14 copycurrent 7-14 copycurrent 7-14 creating reports 10-1 current date 7-16 customize Report Painter 2-1
B
batch 9-2 box properties 2-13 box, adding 2-13 break condition 1-10, 6-2 field 3-3, 6-2 hierarchy 1-10, 6-6 processing 6-2 qualifiers 3-3, 6-2 sequence number 3-3 break condition in Java 10-13 break conditions ambiguous 6-3 break field qualifier updating 3-6 break section about 1-2, 3-6 general 1-10 in derived data 7-5 in report 2-2 NOPRINT option 6-7 break sequence number 3-6
D
data derived 1-2, 1-11 regular 1-2, 6-3 date current 7-16 format 2-7, 2-10 formatting function 7-11 function 2-7, 2-10 startup 7-16 Date/Time Properties 2-7, 2-10 Date/Time Template 2-7 debugging report 10-10 default font (for section) 2-5, 2-6 defining break field 6-2 dependency, functional 7-4
Index
derived data 1-11 about 1-2 display alignment bar 2-8 ruler 2-8 driver rule 1-1 about 1-2 dynamic edit pictures 8-4, 8-5
E
edit picture about 8-1 characters 8-3 formats 8-3 Edit Picture characters 8-2 eject, page 4-1 element coordinates and size 2-9 grid box 2-13 grid line 2-14 page number 2-13 properties 2-10 status bar 2-9 toolbar 2-9 End Page placement option 4-3 ending a report 9-4 entity about 1-2 entity type 1-3 about 1-2 error syntax 9-1 error handling in Java 10-13 event, page eject 4-1
floating character 8-2 field 8-2, 8-4 flow trace 10-10, 10-11 font line 2-6 section default 2-5, 2-6 font control in Java 10-14 font.ini file 10-14 footer section 2-2, 3-4, 7-6 about 1-2, 3-6 format page A-1 print 8-1 system component 8-1, 8-5 variable 8-5 formatting function see also function center 7-11 date 7-11 left 7-12 right 7-13 time 7-13 function see also formatting function page 7-16 parameter 7-4 parameters 2-7 selecting 2-7 functional dependency 7-4 functions mathematical 7-7 functions, mathematical 7-8
G
gaps in subheader hierarchy 5-4 grid line adding 2-14 printer support 3-7 properties 2-14 using 10-8
F
field break 3-3 date and time 2-10 floating 8-2, 8-4 skipping 8-7, 10-15 specifications 2-6, 2-7 temp 7-8 text 7-2 underlining 8-7 field specifications 2-6 file appbuilder.ini 1-4 font.ini 10-14 report bind 10-3 section 10-3 First Page placement option 4-3
H
handling errors in reports 10-9 header section 2-2, 3-4, 7-6 about 1-2, 3-5 hierarchy 1-10 break 6-6 creating 2-2 horizontal line 2-14 HPSETVP 8-6
Index
I
information model 1-3, 3-1 about 1-2 report in 3-1 insertion character 8-3
margin, left 3-3 mathematical functions, See arithmetic function maximum arithmetic function 7-10 minimum arithmetic function 7-10 multicolumn printing 2-5
N J
Java break condition 10-13 configuring Report Writer 1-4 dynamic edit pictures 8-5 edit picture characters 8-3 font control 10-14 gaps in subheader hierarchy 5-4 handling error 10-13 mathematical functions 7-8 page eject 4-2 page placement option 4-3 page size 10-14 printing report 1-5, 10-15 report grid lines 3-7 report page orientation 3-2 Report Writer support for CONVERSE REPORT START 9-2 section left margin 10-14 SETDISPLAY function 10-15 skipping fields 10-15 starting report 10-15 JCL for batch reports 10-4 next page placement option 4-3 placement property 1-9 NOPRINT break section option 6-7 number break sequence 3-3 sequence 3-3
O
object about 1-2 property 1-2 option End Page placement 4-3 First Page placement 4-3 Last Page placement 4-3 Next Page placement 4-3 Whole Page placement 4-3 options in Report Painter 2-1 orientation (of report) 2-4 orientation (report) 3-2
P L
label properties 2-10 Last Page placement option 4-3 left formatting function 7-12 left margin (of report) 2-4, 3-3 left margin (report) 3-2 line adding 2-14 font of section 2-6 horizontal or vertical 2-14 properties 2-14 size of page 2-4 size of section 10-14 line size (report) 3-2 page eject event 4-1, 4-2 page formats A-1 page function 7-16 page length (report) 2-4 page number 2-13 page orientation (report) 3-2 page placement property 3-3 page placement option 4-3 End Page 4-3 First Page 4-3 Last Page 4-3 next page 4-3 Whole Page 4-3 page placement property 1-9 page settings 2-4 page size (report) 2-4, 3-2, 10-14 page width 2-4, 10-14 page width (report) 3-2 parameter, specifying 7-5 parameters of field function 2-7
M
mainframe printing report 1-5 margin calculation 10-14
Index
picture dynamic edit 8-4 edit picture 8-1 internal or storage 8-1 picture character CR 8-3 DB 8-3 Picture Clause field 8-1 preparing reports 10-1, 10-2 print format 8-1 print option 3-3 printer support for grid lines 3-7 type 2-4 printing report 10-4 from mainframe 1-5 from workstation 1-5 in Java 10-15 with generic printer 10-8 processing break 6-2 page eject 4-1 properties next page 1-9 Report 2-3 Section 2-5, 2-6 PSF-enabled report 10-4
Q
qualifier, break 3-3
R
regular data 6-3 about 1-2 regular section about 1-2, 3-5 as unit of print 3-5 in derived data 7-5 multiple 1-7 relationship about 1-2 between report and section 3-1 relationship type about 1-2 relationships 1-3 repetition clause 8-3
report about 1-2 bind file 10-3 creating 10-1 debugging 10-10 differences in Java 10-13 ending 9-4 entities 1-3 handling errors 10-9 JCL 10-4 preparing 10-1, 10-2 printing 10-4, 10-15 properties 2-3 starting in Java 10-15 with APA features 10-6 with APA features under PSF 10-7 Report Communication Area (RPTCA) 9-5 report entity 3-1 Report Generator 10-2 about 1-1 flow trace 10-10, 10-11 report hierarchy 2-1, 2-2 report page settings 2-4 report page size 10-14 Report Painter about 1-1 options 2-1 override defaults 8-1 toolbar 2-9 report section break 2-2 footer 2-2 header 2-2 selecting 2-3 Report Writer about 1-1 mainframe 1-5 workstation 1-5 reports and sections consistency conditions 3-6 right formatting function 7-13 RPTCA layout 9-5 Rule Converses a Report relationship 3-1 Rule Converses a Window relationship 3-1 Rule Uses a Rule relationship 3-1 ruler, displayed 2-8 rules 1-1 to 1-8, 8-4, 9-1
Index
S
section 3-2 as unit of print 3-4 break 1-2, 7-5 file 10-3 footer 1-2, 7-6 header 1-2, 7-6 header and footer 3-6 kinds of data in 3-6 line font 2-6 properties 2-5, 2-6 regular 1-2, 7-5, 7-6 regular vs. derived 3-6 Section View 1-10 settings 2-5 subheader 1-2, 3-5, 3-6, 9-4 type 3-3, 3-4 view 1-2, 3-7 section ID 7-9 Section Owns Section View relationship 3-7 section type break 1-10, 3-4, 3-6 footer 3-4, 3-6 header 3-4, 3-5 regular 1-7, 3-4, 3-5 subheader 3-4 section view about 3-2, 3-7 in example 1-6, 6-3 sequence number 3-3 break 3-3 in report 3-3 SETDISPLAY function 10-15 settings field 2-6 line 2-6 page 2-4 section 2-5 sign character 8-3 sign, character 8-3 size of element 2-9 of page 10-14 skipping fields 8-7, 10-15 specifying parameter 7-5 starting reports in Java 10-15 startup date 7-16 status bar 2-9 subheader gaps in hierarchy 5-4 subheader section 3-4, 9-4 about 1-2, 3-5
sum, arithmetic function 7-9 supported page formats A-1 switchable fonts 10-8 syntax 9-1 system component CDYNPIC 8-1, 8-5
T
TE method 10-10 temp field 7-8 text field 7-2 time format 2-7, 2-10 formatting function 7-13 function 2-7, 2-10 toolbar 2-9 Report Painter 2-9 top margin (of report) 2-4 top margin (report) 3-2 trace, Report Generator flow 10-10, 10-11 trailing blanks in Edit Picture 8-3 types of sections 3-4
U
underline 2-10 underlining field 8-7 units of elements in report 2-13, 2-14 uploading 10-1
V
variable format 8-5 vertical alignment 10-8 vertical line 2-8, 2-14 view, section 1-2 VPSCALE 8-6
W
Whole Page placement option 4-3 width of page (report) 3-2 Workbench Options 2-1
Index
Index

App Builder Creating Reports

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

App Builder Creating Reports

Diunggah oleh

Hak Cipta:

Format Tersedia

BluePhoenix AppBuilder 2.1.

Creating Reports Guide

BluePhoenix AppBuilder 2.1.0 Creating Reports Guide April, 2003

AppBuilder 2.1.0 Creating Reports Guide

Using Report Painter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Developing Report Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

AppBuilder 2.1.0 Creating Reports Guide

Setting Page Placement Options

Creating Subheaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Creating Break Sections

Using Derived Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

AppBuilder 2.1.0 Creating Reports Guide

Formatting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Defining Driver Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

10 Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Supported Page Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1 Index

AppBuilder 2.1.0 Creating Reports Guide

AppBuilder 2.1.0 Creating Reports Guide

AppBuilder 2.1.0 Creating Reports Guide

Report-Related Entity Types

Report-Related Entity Types

Configuration Settings for Reports

Configuration Settings for Reports

10. Run the report.

Steps 9 and 10 are required for a batch report.

These steps are discussed in more detail throughout this documentation.

AppBuilder 2.1.0 Creating Reports Guide

Multiple Regular Sections

Multiple Regular Sections

Multiple Regular Sections

-- -Total -- --- --- --

-- -hours -- --- --- --

-- -- -- -- -- -- -- -worked for this employee -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- --- -- -- -- -- -- -- -- -- -- --

Multiple Regular Sections

Page Placement Property

AppBuilder 2.1.0 Creating Reports Guide

Header Regular section EMPNAME

Regular section EMPTIME

Break section MONTHRS

Regular section EMPTIME

Break section MONTHRS Break section TOTALHRS Footer

AppBuilder 2.1.0 Creating Reports Guide

Example Report EMPHRS, page 1 of 4

Maximum +11.0 +11.0 +11.0 +11.0 +11.0

Minimum +07.0 +07.0 +07.0 +07.0 +07.0

Average +09.0 +09.0 +09.0 +09.0 +09.0

+12.0 +12.0 +12.0 +12.0

+04.0 +04.0 +04.0 +04.0

+08.0 +08.0 +08.0 +08.0

Hours 168 82 Mar 11 10 11 10 11 10 11 10 11 10 Hours 225 40 Apr 11 10 11 10 11 10 11 10 11 10

September 28, 2002 September 28, 2002

AppBuilder 2.1.0 Creating Reports Guide

Report EMPHRS, page 2 of 4

+11.0 +11.0 +11.0 +11.0 +11.0

+07.0 +07.0 +07.0 +07.0 +07.0

+09.0 +09.0 +09.0 +09.0 +09.0

September 28, 2002 September 28, 2002

Report EMPHRS, page 3 of 4

Maximum +12.0 +12.0 +12.0

Minimum +05.0 +05.0 +05.0

Average +08.0 +08.0 +08.0

+11.0 +11.0 +11.0 +11.0 +11.0

+07.0 +07.0 +07.0 +07.0 +07.0