0% found this document useful (0 votes)

24 views550 pages

Rul Book

The document is a Rules Reference guide for Documaker Server version 11.3, detailing the rules for managing jobs, form sets, images, and fields. It includes sections on adding job and form set rules, image and field rules, and references for various commands and processing options. The guide serves as a comprehensive resource for users to control how information is processed and outputted in Documaker Server.

Uploaded by

deepgame1996

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

24 views550 pages

Rul Book

Uploaded by

deepgame1996

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 550

Start

Documaker

Rules Reference
version 11.3
Skywire Software, L.L.C. Phone: (U. S.) 972.377.1110
3000 Internet Boulevard (EMEA) +44 (0) 1372 366 200
Suite 200 FAX: (U. S.) 972.377.1109 Notice

Frisco, Texas 75034 (EMEA) +44 (0) 1372 366 201

www.skywiresoftware.com
Support: (U. S.) 866.4SKYWIRE
(EMEA) +44 (0) 1372 366 222
[email protected]

PUBLICATION COPYRIGHT NOTICE

Copyright © 2008 Skywire Software, L.L.C. All rights reserved.
Printed in the United States of America.
This publication contains proprietary information which is the property of Skywire Software or its subsidiaries. This
publication may also be protected under the copyright and trade secret laws of other countries.

TRADEMARKS
Skywire® is a registered trademark of Skywire Software, L.L.C.
Docucorp®, its products (Docucreate™, Documaker™, Docupresentment™, Docusave®, Documanage™, Poweroffice®,
Docutoolbox™, and Transall™) , and its logo are trademarks or registered trademarks of Skywire Software or its subsidiaries.
The Docucorp product modules (Commcommander™, Docuflex®, Documerge®, Docugraph™, Docusolve®, Docuword™,
Dynacomp®, DWSD™, DBL™, Freeform®, Grafxcommander™, Imagecreate™, I.R.I.S. ™, MARS/NT™, Powermapping™,
Printcommander®, Rulecommander™, Shuttle™, VLAM®, Virtual Library Access Method™, Template Technology™, and
X/HP™ are trademarks of Skywire Software or its subsidiaries.
Skywire Software (or its subsidiaries) and Mynd Corporation are joint owners of the DAP™ and Document Automation
Platform™ product trademarks.
Docuflex is based in part on the work of Jean-loup Gailly and Mark Adler.
Docuflex is based in part on the work of Sam Leffler and Silicon Graphic, Inc.
Copyright © 1988-1997 Sam Leffler.
Copyright © 1991-1997 Silicon Graphics, Inc.
Docuflex is based in part on the work of the Independent JPEG Group.
The Graphic Interchange Format© is the Copyright property of CompuServe Incorporated. GIFSM is a Service Mark property
of CompuServe Incorporated.
Docuflex is based in part on the work of Graphics Server Technologies, L.P.
Copyright © 1988-2002 Graphics Server Technologies, L.P.
All other trademarks, registered trademarks, and service marks mentioned within this publication or its associated software are
property of their respective owners.

SOFTWARE COPYRIGHT NOTICE AND COPY LIMITATIONS

Your license agreement with Skywire Software or its subsidiaries, authorizes the number of copies that can be made, if any,
and the computer systems on which the software may be used. Any duplication or use of any Skywire Software (or its
subsidiaries) software in whole or in part, other than as authorized in the license agreement, must be authorized in writing by
an officer of Skywire Software or its subsidiaries.

PUBLICATION COPY LIMITATIONS

Licensed users of the Skywire Software (or its subsidiaries) software described in this publication are authorized to make
additional hard copies of this publication, for internal use only, as long as the total number of copies does not exceed the total
number of seats or licenses of the software purchased, and the licensee or customer complies with the terms and conditions of
the License Agreement in effect for the software. Otherwise, no part of this publication may be copied, distributed,
transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language, in any form or by
any means, electronic, mechanical, manual, or otherwise, without permission in writing by an officer of Skywire Software or
its subsidiaries.

DISCLAIMER
The contents of this publication and the computer software it represents are subject to change without notice. Publication of
this manual is not a commitment by Skywire Software or its subsidiaries to provide the features described. Neither Skywire
Software nor it subsidiaries assume responsibility or liability for errors that may appear herein. Skywire Software and its
subsidiaries reserve the right to revise this publication and to make changes in it from time to time without obligation of
Skywire Software or its subsidiaries to notify any person or organization of such revision or changes.
The screens and other illustrations in this publication are meant to be representative, not exact duplicates, of those that appear
on your monitor or printer.
Contents

Chapter 1, Introduction

2 Rules Overview

3 Types of Rules

Chapter 2, Adding Job and Form Set Rules

6 Using the Job Definition Table

6 Multi-Step Processing
7 Single-Step Processing
9 GenData WIP Transaction Processing
10 Writing Unique Data Into Recipient Batch Records
16 Sample AFGJOB.JDT Files and INI Options

21 Processing Import Files

24 Rules Used in Single-Step Processing

26 Rules Used for 2-up Printing

Chapter 3, Job and Form Set Rules Reference

28 JDT Rules Reference

36 AddLine
37 AddTextLabel
39 AllocDebug
40 AppendGblToExtr
41 Archive
42 AssignBatWithTbl
43 AssignToBatch
45 BatchByPageCount
47 BatchingByPageCountINI
53 BatchingByPageCountPerRecipINI
56 INI File Examples
66 BatchingByRecipINI

iii
69 BuildExcludeList
70 BuildFormList
71 BuildMasterFormList
72 CheckZeroFontID
73 ConvertWIP
74 CreateGlbVar
75 CreateRecordList
76 DelExtRecords
77 Dictionary
78 DocumentExport
78 Defining Export Options
78 Defining the Export Record
80 Format Flags
81 Defining the Export Record Header
81 Date Formats
84 Freeform Formats
86 Using Locale Information
86 Format Specification Flags
88 DumpExtList
89 DumpExtractListToFile
90 ErrorHandler
91 Ext2GVM
92 FilterForm
94 FilterRecip
96 ForceNoImages
97 FormDescription
101 GetCo
102 GetLOB
103 GetRCBRec
104 GetRunDate
105 GVM2GVM
106 IfRecipUsed
107 ImageMapImportData
109 ImportExtract
114 ImportFile
119 ImportNAPOLExtract
124 ImportNAPOLFile
128 ImportXMLExtract

iv
132 ImportXMLFile
134 Using the TF Option
134 Using the File Option
135 Using the INI Option
135 Using the SCH Option
136 Using the GVM Option
137 XML File Format
138
139 InitArchive
140 InitConvertWIP
141 InitMerge
142 InitOvFlw
143 InitPageBatchedJob
144 InitPrint
145 InitSetRecipCache
146 InlineImagesAndBitmaps
147 InsNaHdr
148 InstallCommentLineCallback
149 JobInit1
150 LoadDDTDefs
151 LoadExtractData
152 LoadFormsetFromArchive
154 LoadListFromTable
155 LoadRcpTbl
156 LoadTblFiles
157 LoadTextTbl
158 MergeAFP
159 MergeRecipsFromForm
160 MergeWIP
164 MultipleDataDictionaryFiles
166 NoGenTrnTransactionProc
167 OMRMarks
171 PageBatchStage1InitTerm
172 PaginateAndPropagate
174 ParseComment
175 PostTransDAL
177 PreTransDAL
179 PrintData

v
180 PrintFormset
182 ProcessQueue
183 ProcessRecord
184 ProcessTriggers
185 PXCandidateList
185 INI Options
187 PXTrigger
189 Input Tables
190 The Policy Xpress FED Processing Flow
192 RegionalDateProcess
195 ReplaceNoOpFunc
196 ResetDocSetNames
197 ResetOvFlw
198 RestartJob rule
199 RULCheckTransaction
200 RULNestedOverFlowProc
204 RULStandardFieldProc
205 RULStandardImageProc
206 RULStandardJobProc
207 RULStandardTransactionProc
208 RULTestTransaction
209 RunSetRcpTbl
210 RunTriggers
211 RunUser
212 ServerFilterFormRecipient
214 ServerJobProc
217 SetErrHdr
218 SetOutputFromExtrFile
221 SetOverflowPaperTray
224 SetOvFlwSym
225 SetRecipCopyCount
226 SetRecipCopyCount2
227 SortBatches
227 Specifying Key fields
228 Sorting with a Single Key
228 Sorting with Multiple Keys
229 INI Options
230 Replacement Strings

vi
233 StandardFieldProc
234 StandardImageProc
235 TicketJobProc
236 TranslateErrors
237 UpdatePOLFile
238 UseXMLExtract
239 Mapping Fields
240 Overflow in XML
241 WIPFieldProc
242 WIPImageProc
243 WIPTransactions
245 WriteNAFile
246 WriteOutput
247 WriteRCBFiles
248 WriteRCBWithPageCount
250 XMLFileExtract
251 Mapping Fields
252 Overflow in XML

Chapter 4, Adding Image and Field Rules

254 Storing Rule Information

255 Using the Data Definition Table

257 Setting Up the MASTER.DDT File

259 Using the Master DDT Editor
259 Using the File Menu
261 Using the Edit Menu
263 Using the Move Menu

265 Assigning Rules with the Image Editor

265 Adding Image Rules
267 Changing an Image Rule
267 Deleting an Image Rule
268 Assigning Field Rules
268 Using the Edit DDT Tab
271 Changing a Field Rule
271 Deleting a Field Rule
272 Using the Edit DDT Window

vii
273 Assigning a Rule
275 Displaying Rule Reports
275 Image Report
275 View Rules Report
276 View Compare Report

278 Formatting Data

278 Using Pre-defined Date Formats
281 Using Pre-defined Numeric Formats
283 Setting Up Format Arguments
285 Field Format Types (fetypes)
287 Formatting Data with the = Operator

290 Search Criteria

291 Overflow and User Functions

Chapter 5, Image and Field Rules Reference

294 Image and Field Rules Reference

301 AccumulateVariableTotal
304 AddMultiPageBitmap
307 Using the File Option
308 Using the DAL Option
309 Using the SRCH Option
309 Using the GVM Option
310 Using the Type Option
311 AddMultiPageTIFF
314 Using the File Option
315 Using the DAL Option
315 Using the SCH Option
316 Using the GVM Option
316 Using the Type Option
320 BldGrpList
323 CanSplitImage
326 CheckImageLoaded
327 CompBin
330 ConCat
331 ConnectFields
334 CreateChartSeries

viii
336 CreateSubExtractList
338 DAL
340 DateDiff
342 DateFmt
345 DeleteDefaultSeriesData
346 DelImageOccur
347 DontPrintAlone
348 EjectPage
349 FfSysDte
351 Field2GVM
353 FieldVarsToChartSeries
355 FmtDate
356 FmtNum
358 GlobalFld
361 GroupBegin
361 Using the Box Function
362 Using the GroupPagination Function
364 Using the List Function
364 Using the StayTogether Function
365 Using the Column Function
373 GroupEnd
374 HardExst
378 If
380 Examples
384 IncOvSym
385 JustFld
390 KickToWip
391 Suppressing Warning Messages
392 LookUp
394 MapFromImportData
397 Master
398 MessageFromExtr
399 Creating Messages
402 Using the Record Dictionary
406 Mk_Hard
408 MNumExt
411 Move_It
416 MoveExt

ix
418 MoveMeToPage
419 MoveNum
427 MoveSum
429 MovTbl
431 NoOpFunc
433 OvActPrint
435 OvPrint
437 PaginateBeforeThisImage
438 PostImageDAL
440 PowType
441 Suppressing Warning Messages
442 PreImageDAL
444 PrintIf
446 PrtIfNum
449 PurgeChartSeries
450 RemoveWhiteSpace
452 ResetImageDimensions
454 ResetOvSym
455 SetGroupOptions
456 RunDate
459 SAPMove_It
461 SetAddr
464 SetAddr2
467 SetAddr3
470 SetCpyTo
471 SetCustChartAxisLabels
473 SetImageDimensions
474 SetOrigin
478 SetOriginI
480 SetOriginM
482 SetRecipFromImage
484 SetState
486 SpanAndFill
488 StrngFmt
490 SysDate
492 TblLkUp
494 TblText

x
496 TerSubstitute
499 TextMergeParagraph
500 UnderlineField
501 XDB
504 XDD

Using Condition Tables and the Record Dictionary

508 Using Condition Tables

508 Setting Up the INI Files
508 Using a Record Dictionary File
509 Creating a Conditions File
510 Occurrence Counting

511 Using the Record Dictionary

511 Setting Up the Record Dictionary
511 Record Dictionary File
513 RPN Function

515 Record Dictionary Rules

515 Base_FromDataDictToGVM
515 FromDataDict
515 FromDataDictToGVM
515 Image_FromDataDictToGVM
516 IncDataDictRecPtr
516 PosDataDictRecPtr
516 PostIncDataDictRecPtr
516 PostPosDataDictRecPtr
516 PreIncDataDictRecPt
517 PrePosDataDictRecPtr
517 ResetDataDictRecPtr

519 Index

xi
xii
Chapter 1
Introduction
Welcome to the Rules Reference for Documaker
Server. This guide serves as a reference to the various
rules you can use to control how the system handles
jobs, form sets, sections (images), and fields.
This chapter discusses the following topics:

• Rules Overview on page 2

• Types of Rules on page 3

1
Chapter 1
Introduction

RULES OVERVIEW You can use rules to control how information is merged onto forms, how that
information is then processed, and how the information and those forms are output.
This guide serves as a reference to those rules.
Documaker Server uses resources you create using Documaker Studio or the older
tool, Image Editor, to process information and forms. This processing includes merging
external data onto forms, processing data according to rules you set up, creating print-
ready files, archiving data and forms, and, if applicable, sending incomplete forms to
Documaker Workstation for completion by a user.
Forms can be completed using Documaker Workstation when user input is required or,
if all of your information can be extracted from external data sources, Documaker
Server can be set up to process forms without requiring user input.
Documaker Server can create print-ready files for a variety of printer languages
including AFP, PostScript, PCL, and Xerox Metacode printers. In addition, using Oracle
Insurance’s Internet Document Server, the system can produce output in Adobe
Acrobat PDF format.

2
Types of Rules

TYPES OF RULES The GenData program processes these types of rules, based on this hierarchy:

• Job level rules (level 1)

These rules define actions the system should perform for each job or work activity,
such as producing a complete form set. Job level rules are global rules used to
apply procedures and rules to all jobs, form sets, and forms. Most of these rules
are designed to initialize, open, and close section (FAP) files, bitmap files, and
data files; however, some specialized functions do exist.
Job level rules are stored in the Job Definition Table (AFGJOB.JDT). For more
information on job level rules, see Adding Job and Form Set Rules on page 5.

• Form set level rules (level 2)

These rules let you construct and manipulate forms into form sets. Form set level
rules affect the form set as a whole, not the individual components which make up
the form set.
Form set level rules are stored in the Job Definition Table (AFGJOB.JDT). For more
information on job level rules, see Adding Job and Form Set Rules on page 5.

• Section level rules (level 3)

These rules define actions to perform on single sections within a form, based on a
specific transaction. Form or section (image) level rules affect the section as a
whole, not the individual fields and objects which make up the section or form.
For more information on job level rules, see Job and Form Set Rules Reference on
page 27.

• Field level rules (level 4)

These rules define actions to perform on the variable fields in a section. Field level
rules provide mapping, masking, and formatting information for each variable
field on a form.
For more information on job level rules, see Job and Form Set Rules Reference on
page 27.

NOTE: Only memory limits the number of rules you can add to a section, however,
having a large number of forms associated with a single section can be difficult
to maintain.

3
Chapter 1
Introduction

4
Chapter 2
Adding Job and Form Set
Rules
Job and form set rules help you control how a
processing job is run and how the system processes
the various form sets.
The rules which apply to the job and form set are
stored in the AFGJOB.JDT file, which is called the job
definition table, or JDT file. You add these rules directly
into that file using a text editor.
In this chapter you will find information about:

• Using the Job Definition Table on page 6

• Multi-Step Processing on page 6
• Single-Step Processing on page 7
• GenData WIP Transaction Processing on page 9
• Processing Import Files on page 21
• Rules Used in Single-Step Processing on page 24
• Rules Used for 2-up Printing on page 26
For reference information on individual rules, see Job
and Form Set Rules Reference on page 27

5
Chapter 2
Adding Job and Form Set Rules

USING THE JOB The rules which apply to the job and form set are stored in the job definition table,
which is called the AFGJOB.JDT or JDT file. You edit this file using a text editor. When
DEFINITION TABLE editing the AFGJOB.JDT file, you can use these types of delimiters:

Use this delimiter… To…

backslash and asterisk (/*) Denote comments

comma (,) Separates the data that comprises a parameter

semi-colon (;) Separates parameters

The base system uses the rules in the JDT file when you run the main batch system
programs (GenTrn, GenData, GenPrint, GenWIP, and GenArc). You can run these
programs several ways:

• Multi-step processing
• Single-step processing
• WIP transaction processing
For multi-step processing, you run each program separately. With single-step
processing, you run the GenData program using rules to perform the tasks handled by
the GenTrn and GenPrint programs. The AFGJOB.JDT files differ for each approach.
Examples of each approach follow.
WIP transaction processing lets you add or merge WIP transactions manually approved
or rejected into a GenData processing run. These transactions can be processed as new
transactions or appended to an master resource library (MRL) already processed by the
GenData program.

MULTI-STEP PROCESSING
Multi-step processing lets you run each batch system program in turn and check the
log and error messages after each step. You can learn more about the system flow and
the input and output files for each processing step in Chapter 2 of the Documaker
Server System Reference.

Multi-step processing <Base Rules>

AFGJOB.JDT file ;RULStandardJobProc;1;Always the first job level rule;
;SetErrHdr;;*:;
;SetErrHdr;;*:------------------------------------------------;
;SetErrHdr;;*: FormMaker Data Generation (Base);
;SetErrHdr;;*: ;
;SetErrHdr;;***: Transaction: ***PolicyNum***;
;SetErrHdr;;***: Symbol: ***Symbol***;
;SetErrHdr;;***: Module: ***Module***;
;SetErrHdr;;***: State: ***State***;
;SetErrHdr;;***: Company Name (after INI conversion):
***Company***;
;SetErrHdr;;***: Line of Business (after INI conversion):
***Lob***;
;SetErrHdr;;***: Trans Type: ***TransactionType***;
;SetErrHdr;;***: Run Date: ***RunDate***;

6
Using the Job Definition Table

;SetErrHdr;;*:------------------------------------------------;
;CreateGlbVar;;TXTLst,PVOID;
;CreateGlbVar;;TblLstH,PVOID;
;JobInit1;;;
;LoadDDTDefs;;;
;InitOvFlw;;;
;LoadTextTbl;;;
;LoadTblFiles;;;
;SetOvFlwSym;;CGDECBDOVF,QGDCBD,1;
;BuildMasterFormList;;4;

Every form set in the base system uses these form set level rules:
<Base Form Set Rules>
;RULStandardTransactionProc;;Always the first transaction level
rule;
;LoadExtractData;;;
;GetCo;;11,HEADERREC 35,3;
;GetLOB;;11,HEADERREC 40,3;
;ResetOvFlw;;;
;IfRecipUsed;;BATCH1=INSURED;
;IfRecipUsed;;BATCH2=COMPANY;
;IfRecipUsed;;BATCH3=AGENT;
;BuildFormList;;;
;LoadRcpTbl;;;
;UpdatePOLFile;;;
;RunSetRcpTbl;;;

Every image in the base system uses these image level rules:
<Base Image Rules>
;RULStandardImageProc;;Always the first image level rule;
;InsNAHdr;;;

Every field in the base system uses this field rule:

<Base Field Rules>
;RULStandardFieldProc;;Always the first field level rule;

SINGLE-STEP PROCESSING
To enhance performance, you can combine the execution and functionality of the
GenTrn and GenData steps into a single step. Combining these steps enhances
performance by reducing the number of times files have to be opened and closed
during processing. For more information, see Chapter 2 of the Documaker Server
System Reference.
To combine the GenTrn and GenData steps, you place the NoGenTrnTransactionProc
rule in under the <Base Form Set Rules> header in your AFGJOB.JDT file, along with
several other rules. To then combine the GenData and GenPrint steps, add the
following rule under the <Base Rules> header in your AFGJOB.JDT file:
;InitPrint;;;

and add this rule below the <Base Form Set Rules> header in your AFGJOB.JDT file:
;PrintFormset;;;

To use single-step processing, change the TrnFile option in the FSISYS.INI file to NUL,
as shown below:

7
Chapter 2
Adding Job and Form Set Rules

< Data >

TrnFile = NUL
Once you have added the rules to your AFGJOB.JDT file and FSISYS.INI file, run the
GenData program as you normally would and it will execute the GenTrn and GenPrint
processing steps.
For more information on these rules, see InitPrint on page 144, PrintFormset on page
180, and NoGenTrnTransactionProc on page 166.

Single-step processing When you use single-step processing, where the GenData program runs the GenTrn
AFGJOB.JDT file and GenPrint processes as a single step, you use the following AFGJOB.JDT file. This file
is also called the performance mode JDT file:
<Base Rules>
;RULStandardJobProc;1;Always the first job level rule;
;SetErrHdr;;*:------------------------------------------------;
;SetErrHdr;;*: FormMaker Data Generation (Base);
;SetErrHdr;;*: ;
;SetErrHdr;;***: Transaction: ***ACCOUNTNUM***;
;SetErrHdr;;***: Company Name (after ini conversion): ***Company***;
;SetErrHdr;;***: Line of Business (after ini conversion): ***LOB***;
;SetErrHdr;;***: Run Date: ***RunDate***;
;SetErrHdr;;*:------------------------------------------------;
;JobInit1;;;
;CreateGlbVar;;TXTLst,PVOID;
;CreateGlbVar;;TblLstH,PVOID;
;InitOvFlw;;;
;SetOvFlwSym;;SUBGROUPOVF,SUBGROUP,5;
;BuildMasterFormList;;4;
;PageBatchStage1InitTerm;;;
;InitSetrecipCache;;;
/* the following is required to run GenData/GenPrint as single
step.*/
;InitPrint;;;

Every form set in the base system uses these form set level rules:
<Base Form Set Rules>
;NoGenTrnTransactionProc;;First transaction level rule when omitting
GenTrn;
;ResetOvFlw;;;
;BuildFormList;;;
;LoadRcpTbl;;;
;RunSetRcpTbl;;;
/* the following is required to run GenData/GenPrint as single
step.*/
;PrintFormset;;;
;WriteOutput;;;
;WriteNaFile;;;
;WriteRCBWithPageCount;;;
;ProcessQueue;;PostPaginationQueue;
;PaginateAndPropagate;;;
;BatchingByRecipINI;;;

Every image in the base system uses this image level rule:
<Base Image Rules>
;StandardImageProc;;Always the first image level rule;

8
Using the Job Definition Table

Every field in the base system uses this field level rule:
<Base Field Rules>
;StandardFieldProc;;Always the first field level rule;

GENDATA WIP TRANSACTION PROCESSING

GenData WIP Transaction Processing lets you process WIP transactions based on their
status code. The transactions are created by one of these processes:

• Executing the GenWIP program after the GenData program to process the
transactions in the manual batch. Then using Documaker Workstation to:
Manually view a transaction and update any required data. Then use the WIP,
Save option to save the transaction with a status code such as: Approved or
Accepted.
Manually view a transaction and then use the WIP, Save option to save the
transaction with a status code of Rejected.
Manually view a transaction, update any required data, and save the
transaction using the File, Complete, Batch Print option. This assigns a Batch
Print status code to the transaction.
• Creating a new transaction using Documaker Workstation and then using the WIP,
Save or File, Complete, Batch Print option to save it with a status code such as
Approved, Accepted, or Rejected.
You can then process these transactions as:

• New transactions
• Transactions appended to an existing MRL recipient batch, NewTrn, NA, and POL
files created by a prior run of the GenData program
GenData WIP Transaction Processing creates new recipient batch, NewTrn, NA, and
POL files which you can print, archive, or both using the GenPrint and/or GenArc
programs.
To do this, you execute the GenData program using a simplified AFGJOB.JDT file that
contains rules to replace the existing form set, image, and field rules. In addition, you
must add two rules.
Here is a list of the rules used for GenData WIP Transaction Processing. All of these
rules are required in the simplified AFGJOB.JDT file.

Rule Description

MergeWIP on This job level rule initializes WIP Transaction Processing and
page 160 specifies the status codes for the transactions added or appended
to a newly-created NA and POL list.

WIPTransactions This form set level rule replaces the RULStandardTransactionProc

on page 243 or NoGenTrnTransactionProc rule in the AFGJOB.JDT file and starts
form set processing.
It also identifies the status codes for transactions to be processed.
The status codes specified in this rule’s parameters can include any
or all of the status codes specified for the MergeWIP rule.

9
Chapter 2
Adding Job and Form Set Rules

Rule Description

GVM2GVM on This form set rule to copies GVM variable data from the WIP.DBF file
page 105 into GVM variables needed by the GenData program. Use the
Trigger2WIP control group options to define GVM variable names

WIPImageProc on This image level rule replaces the RULStandardImageProc or

page 242 StandardImageProc rule in the AFGJOB.JDT file and tells the
GenData program to bypass image data processing.

WIPFieldProc on This field level rule replaces the RULStandardFieldProc or

page 241 StandardFieldProc rule in the AFGJOB.JDT file and tells the GenData
program to bypass field data processing.

NOTE: All WIP file transactions added to the transaction memory list by the MergeWIP
rule are deleted from the WIP file after processing. You can remove specific
transaction types, such as Rejected, by including the status code in the
parameters for the MergeWIP rule and omitting it in the parameters for the
WIPTransactions rule.

WRITING UNIQUE DATA INTO RECIPIENT BATCH RECORDS

The GenData program lets you add unique data to recipient batch records before they
are written to the recipient batch files. The recipient batch record data and format is
defined by the GVM variable definitions in the RCBDFDFL.DAT file.
You can use this capability if you need to add...

• Address information or other field level information to the batch record, which is
typically unique for each recipient.
• Recipient information that is not handled by normal field mapping from the
transaction DFD to the recipient batch DFD.
• Cumulative or calculated information not available until the document is nearly
completed.

Understanding the System Before this feature was implemented in version 10.2, the recipient batch records were
identical except for the recipient code field which contains a unique identifier assigned
to a given recipient. If additional recipient data was required, you had to write a custom
rule.

Use the options in the RecipMap2GVM control group to set up this capability. Data that
can be added to the recipient batch record can be:

• Contents of a variable field on the specified image or form/image

• Constant value
• Data from an existing INI built-in functions, such as ~DALRun
• Data from a custom written INI function

10
Using the Job Definition Table

Here is an example of the RecipMap2GVM control group:

< RecipMap2GVM >
Form =
Image =
Req =
Opt =

Option Description

Form (Optional) Enter the name of the form.

Image Enter the name of the image. You can also enter an image name root.
An image name root is the first part of a name. For instance, MAILER is the root
name for images with names such as MAILER A, MAILER_B, or MAILERS.

Req * A semi-colon delimited string that contains one of the following:

- GVM variable name; variable field name; optional formatting information
- GVM variable name; blank character (space); constant value
- GVM variable name; INI built-in function

Opt * A semi-colon delimited string that contains one of the following:

- GVM variable name; variable field name; optional formatting information
- GVM variable name; blank character (space); constant value
- GVM variable name; INI built-in function

* = Repeat for each GVM variable you are setting up.

Suppressing Use the WarnOnLocate option to suppress the following warning message from the
RCBMapFromINI function RCBMapFromINI function:
warning messages
Cannot locate image root named/image
Here is an example:
< RecipMap2GVM >
WarnOnLocate = No

Option Description

WarnOnLocate Enter No if you want to suppress this warning message from the
RCBMapFromINI function:
Cannot locate image root named/image
The default is Yes.

Optional formatting You can add optional formatting information as a parameter of the Opt INI option. This
information formatting information is comprised of four items separated by commas.

Item Description

Input fetypes D or d = date

N or n = number

11
Chapter 2
Adding Job and Form Set Rules

Item Description

Input format mask Date - see the FmtDate rule in the Rules Reference.
Number – see the FmtNum rule in the Rules Reference.

Output fetypes D or d = date

N or n = number

Output format mask Date - see the FmtDate rule in the Rules Reference.
Number – see the FmtNum rule in the Rules Reference.

Here are some formatting examples:

d,”1/4”, d, “4/4”

This converts an input date, mmddyyyy, into month name dd, yyyy, such as February
17, 2009.
n, nCAD, nUSD, “$zzz,zz9.99”

This converts an input numeric value in Canadian French format into a value in United
States format.
Keep in mind...

• For the Req option, if the data is missing an error occurs and the transaction is
send to the error batch.
• For the Opt option, if the data is missing the system stores an empty string in the
GVM variable.
• A RCB GVM variable cannot be restored to its original or default value after it has
been changed using this method.
• Any RCB GVM variable not assigned using this method retains the value originally
set during the transaction processing.
• Some RCB GVM variables should never be changed using this mapping technique.
These include:
TRN_Offset
NA_Offset
POL_Offset
• If the image defined in the Image option in the RecipMap2GVM control group does
not name an image, the feature is disabled for all transactions.
• If the image defined in the Image option is missing from the form set being
processed, the GVM data is not changed. Depending on where the GVM data is
mapped, this could mean data from the prior transaction will still be in the GVM
variables.
• If there are multiple images with the same name in the form set, the form specified
in the Form option is used to identify the image to use. If the Form option is
omitted, the first image found in the current form set is used.
• The system assumes the specified image contains all of the unique data except for
a constant value or data gathered from an INI built-in function.

12
Using the Job Definition Table

• If more than one recipient is assigned to the image, all recipient batch records
receive the same added data.

Example This example creates a mailer cover page for each insured, agent, and/or company
recipient per transaction. The cover page is created using banner page processing
which occurs during GenPrint processing. Examples of the three different mailer cover
pages are as follows.

Insureds Jill Smith Suzy Smith

11111 Oak Circle Morris Fanelli
Suite 999 99934 Oak Circle
Smryna, FL 12345 Suite 999
Smartburg, WI
99999

Jill Smith Suzy Smith

Agents Martin Short Agent David Miller Agent
963 Atlantic 999 Green Dolphin
Boulevard Street
Suite 1250 Suite 1200
Miami, FL 30202 Miami, FL 30202

Suzy Smith
Jill Smith

Company Sampco, Inc.

316 N.E. 3rd Avenue
Pompano Beach, FL
33333

This example assumes that the:

• Agent and company recipient batch files are sorted (agent number and company
name, respectively) before the GenPrint program runs. This sorting allows for the
creation of only one mailer cover page per unique agent and company.
• Unique information is contained on the form/image, Dec Page/Q1MDC1.

13
Chapter 2
Adding Job and Form Set Rules

• The FSIUSER.INI file includes these control groups and options:

< RecipMap2GVM >
Form = Dec Page
Image = Q1MDC1
Opt = Name1;Insured Name;
Opt = Name2;Insured Name2;
Opt = Address1;Address Line1;
Opt = Address2;Address Line2;
Opt = CityCounty;prtvalue;
Opt = AgentName;Agent Name;
Opt = AgentID; Agent ID;
Opt = OfficeAddress;Office Address;
Opt = TownandState;Town And State;
< Printer >
PrtType = PCL
EnableTransBanner = True
EnableBatchBanner = False
TransBannerBeginScript= PreTrans
TransBannerEndScript= PstTrans
TransBannerBeginForm= ;BANNER;TRANSACTION;TRANS HEADER;
TransBannerEndForm = ;BANNER;TRANSACTION;TRANS TRAILER;
< DALLibraries >
LIB = Banner

BANNER.DAL The DefLib directory contains this DAL script:

* This script obtains the required unique data from the recipient
* batch record and stores it on the mailer form.

BeginSub PreTrans

blank_gvm = Pad(" ",41," ")

SetGVM("NameA" ,blank_gvm,,"C",41)
SetGVM("NameB" ,blank_gvm,,"C",41)
SetGVM("AddressA" ,blank_gvm,,"C",41)
SetGVM("AddressB" ,blank_gvm,,"C",41)
SetGVM("CityCounty1" ,blank_gvm,,"C",41)
If Trim(RecipName()) = "INSURED" Then
SetGVM("NameA" ,GVM("Name1") ,,"C",41)
SetGVM("NameB" ,GVM("Name2") ,,"C",41)
SetGVM("AddressA" ,GVM("Address1") ,,"C",41)
SetGVM("AddressB" ,GVM("Address2") ,,"C",41)
SetGVM("CityCounty1" ,GVM("CityCounty"),,"C",41)
GoTo exit:
End

last_agent_id = last_agent_id
If Trim(RecipName()) = "AGENT" Then
If last_agent_id != Trim(GVM("AgentID")) Then
last_agent_id = Trim(GVM("AgentID"))
SetGVM("NameA" ,GVM("AgentName") ,,"C",41)
SetGVM("NameB" ,GVM("OfficeAddress") ,,"C",41)
SetGVM("AddressA" ,GVM("TownandState") ,,"C",41)
GoTo exit:
Else

14
Using the Job Definition Table

SuppressBanner()
GoTo exit :
End
End

last_company_name = last_company_name
If Trim(RecipName()) = "COMPANY" Then
If Trim(GVM("Company")) != last_company_name Then
last_company_name = Trim(GVM("Company"))
If Trim(GVM("Company")) = "SAMPCO" Then;
SetGVM("NameA" ,"Sampco, Inc." ,,"C",41)
SetGVM("NameB" ,"316 N.E. 3rd Avenue" ,,"C",41)
SetGVM("AddressA" ,"Pompano Beach, FL 33333" ,,"C",41)
GoTo exit:
ElseIf Trim(GVM("Company")) = "FSI"
SetGVM("NameA" ,"FSI Inc." ,,"C",41)
SetGVM("NameB" ,"222 Newbury St." ,,"C",41)
SetGVM("AddressA" ,"Northwest City, FL 99999" ,,"C",41)
GoTo exit:
End
Else
SuppressBanner()
GoTo exit:
End
End
exit:
EndSub

BeginSub PstTrans
EndSub

15
Chapter 2
Adding Job and Form Set Rules

The RCBDFDFL.DAT file contains the following GVM variable definitions which are
defined in the RecipMap2GVM control group:

• Name1
• Name2
• Address1
• Address2
• CityCounty
• AgentName
• AgentID
• OfficeAddress
• TownAndState
Here are two recipient batch records from this example:
SAMPCOLB12234567SCOM1FLT1 B2199802232234567890 0 22560
******001 3724 452Jill Smith Morris
11111 Oak Circle Suite 999 Smyrna,
FL 12345 Martin Short Agent 963 Main Street,
Suite 1250 Miami, FL 30202

FSI CPP4234567FSIM1WIT1 B3199802234234567890 0 30360

******001 4667 565Suzy Smith Morris
99934 Oak Circle Suite 999 SmartBurg,
WI 99999 David Miller Agent 999 Main Street,
Suite 1200 Miami, FL 30202

Sample AFGJOB.JDT Files and INI Options

Shown below are examples of simplified AFGJOB.JDT files and the INI options you use
to process WIP transactions for specified recipients using these rules:

• IfRecipUsed on page 106

• BatchingByRecipINI on page 66
• BatchingByPageCountINI on page 47

Assume each example has these INI options:

< Status_CD >
Approved = AP
BatchPrint = BP
Rejected = RJ

Also assume the first two examples have the following INI options defined in the
FSISYS.INI or FSIUSER INI file.
These options define the recipient batch names:
< Print_Batches >
Insured = .\batch\Insured
Agent = .\batch\Agent
Company = .\batch\Company

These options define the output printer names:

16
Using the Job Definition Table

< PrinterInfo >

Printer = InsuredPrt
Printer = AgentPrt
Printer = CompanyPrt

These options define the output printer names for each recipient batch. You must have
a control group for each recipient batch.
< Insured >
Printer = InsuredPrt
< Agent >
Printer = AgentPrt
< Company >
Printer = CompanyPrt

These options define the print-ready output file name for each recipient name:
< InsuredPrt >
Port = .\Print\Insured.PCL
< AgentPrt >
Port = .\Print\Agent.PCL
< CompanyPrt >
Port = .\Print\Company.PCL

Using the IfRecipUsed You run the GenData program using a simplified AFGJOB.JDT file which contains an
rule IfRecipUsed rule for each recipient. This example places print-ready output for each
recipient in the following files:

Recipient Output file

Insured INSURE.PCL

Agent AGENT.PCL

Company COMPANY.PCL

Transactions with status codes defined in the WIPTransactions rule are appended to an
existing MRL recipient batch, NewTrn, NA, and POL files or are appended to newly-
created recipient batch, NewTrn, NA, and POL files. These files can be printed, archived,
or both using the GenPrint and GenArc programs.
All transactions with a Rejected or an Approved status code are deleted from the WIP
file. Here is an example of the AFGJOB.JDT file. Note that the Rejected status code is
omitted from the WIPTransactions rule.
<Base Rules>
;RulStandardJobProc;;;
;MergeWIP;;Approved,Rejected;
;JobInit1;;;
<Base Form Set Rules>
;WIPTransactions;;Approved;
;GVM2GVM;;Trigger2WIP;
;IfRecipUsed;;Batch1=Insured;
;IfRecipUsed;;Batch2=Company;
;IfRecipUsed;;Batch3=Agent;
;UpdatePOLFile;;;
<Base Image Rules>

17
Chapter 2
Adding Job and Form Set Rules

;WIPImageProc;;;
<Base Field Rules>
;WIPFieldProc;;;

Using the You run the GenData program using a simplified AFGJOB.JDT file which contains the
BatchingByRecipINI rule BatchingByRecipINI rule. The BatchingByRecip control group contains an option for
each recipient. Define this control group in the FSISYS.INI or FSIUSER.INI file. This
example places print-ready output for each recipient in the following files:

Recipient Output file

Insured INSURE.PCL

Agent AGENT.PCL

Company COMPANY.PCL

Transactions with status codes defined in the WIPTransactions rule are appended to an
existing MRL recipient batch, NewTrn, NA, and POL files or are appended to newly-
created recipient batch, NewTrn, NA, and POL files. These files can be printed, archived,
or both using the GenPrint and GenArc programs.
All transactions with a Rejected or Batch Print status code are deleted from the WIP file.
Here is an example of the AFGJOB.JDT file. Note that the Rejected status code is omitted
from the WIPTransactions rule.
<Base Rules>
;RULStandardJobProc;1;;;
;JobInit1;;;
;MergeWIP;;BatchPrint,Rejected;
;InitSetrecipCache;;;
<Base Form Set Rules>
;WIPTransactions;;BatchPrint;
;WriteOutput;;;
;WriteNaFile;;;
;BatchingByRecipINI;;;
<Base Image Rules>
;WIPImageProc;;;
<Base Field Rules>
;WIPFieldProc;;;

Using the You run the GenData program using a simplified AFGJOB.JDT file which contains the
BatchingByPageCountINI BatchingByPageCountINI rule. The BatchingByRecip control group contains an option
rule for each recipient. Define this control group in the FSISYS.INI or FSIUSER.INI file.
This example places print-ready output for each recipient into the following files based
on the number of pages in each transaction processed.

File Description

INSOVER3.PCL Insured with more than three pages

INSUNDR4.PCL Insured with less than three pages

18
Using the Job Definition Table

File Description

AGIOVER3.PCL Agent with more than three pages

AGIUNDR4.PCL Agent with less than three pages

CTROVER3.PCL Company with more than three pages

CTRUNDR3.PCL Company with less than three pages

Transactions with status codes defined in the WIPTransactions rule are appended to an
existing MRL recipient batch, NewTrn, NA, and POL files or are appended to newly-
created recipient batch, NewTrn, NA, and POL files. These files can be printed, archived,
or both using the GenPrint and GenArc programs.
All transactions with a Rejected or Batch Print status code are deleted from the WIP file.
Here is an example of the AFGJOB.JDT file. Note that the Rejected status code is omitted
from the WIPTransactions rule.
<Base Rules>
;RulStandardJobProc;;;
JobInit1;;;
;MergeWIP;;BatchPrint,Rejected;
;InitSetrecipCache;;;
<Base Form Set Rules>
;WIPTransactions;;BatchPrint;
;GVM2GVM;;Trigger2WIP;
;WriteOutput;;;
;WriteNaFile;;;
;BatchingByPageCountINI;;;
;WriteRCBWithPageCount;;;
;ProcessQueue;;PostPaginationQueue;
;PaginateAndPropagate;;;
<Base Image Rules>
;WIPImageProc;;;
<Base Field Rules>
;WIPFieldProc;;;

Here are the INI options used with the BatchingByPageCountINI rule:
< BatchingByRecip >
DefaultBatch = Default
Batch_Recip_Def= True;"InsOver3";Insured
Batch_Recip_Def= True;"InsUndr4";Insured
Batch_Recip_Def= True;"AgiOver3";AddLinsd
Batch_Recip_Def= True;"AgiUndr4";AddLinsd
Batch_Recip_Def= True;"CtrOver3";CertHld
Batch_Recip_Def= True;"CrtUndr4";CertHld
< Print_Batches >
InsOver3 = .\batch\InsOver3
InsUndr4 = .\batch\InsUndr4
AgiOver3 = .\batch\AgiOver3
AgiUndr4 = .\batch\AgiUndr4
CtrOver3 = .\batch\CtrOver3
CtrUndr3 = .\batch\CtrUndr4

19
Chapter 2
Adding Job and Form Set Rules

Default = .\batch\Default
< PrinterInfo >
Printer = InsOver3Prt
Printer = InsUndr4Prt
Printer = AgiOver3Prt
Printer = AgiUndr4Prt
Printer = CtrOver3Prt
Printer = CrtUndr4Prt
Printer = DefaultPrt
< InsOver3 >
Printer = InsOver3Prt
PageRange = 4,999
< InsUndr4 >
Printer = InsUndr4Prt
PageRange = 1,3
< AgiOver3 >
Printer = AgiOver3Prt
PageRange = 4,999
< AgiUndr4 >
Printer = AgiUndr4Prt
PageRange = 1,3
< CtrOver3 >
Printer = CtrOver3Prt
PageRange = 4,999
< CrtUndr4 >
Printer = CrtUndr4Prt
PageRange = 1,3
< Default >
Printer = DefaultPrt
< InsOver3Prt >
Port = .\Print\InsOver3.PCL
< InsUndr4Prt >
Port = .\Print\InsUndr4.PCL
< AgiOver3Prt >
Port = .\Print\AgiOver3.PCL
< AgiUndr4Prt >
Port = .\Print\AgiUndr4.PCL
< CtrOver3Prt >
Port = .\Print\CtrOver3.PCL
< CrtUndr4Prt >
Port = .\Print\CrtUndr4.PCL
< DefaultPrt >
Port = .\Print\Default.PCL

20
Processing Import Files

PROCESSING The GenData program can import and process these types of export files created by
Documaker Workstation:
IMPORT FILES
• Standard export
• WIP/NA/POL export
• XML export
The transactions exported to a file can be created by:

• Executing the GenWIP program after the GenData program to process any
transactions in the manual batch. You then use Documaker Workstation to view
the transaction and update any required data. Finally, you use the File, Complete,
Export Data option to create the export file.
• Creating a transaction using Documaker Workstation. You then use the File,
Complete, Export Data option to create the export file.
• Creating a transaction using iPPS.
You can then process the export files as a:

• Single transaction using the appropriate import file rule in a simplified

AFGJOB.JDT. For instance, you would use one of these rules:
ImportFile on page 114
ImportNAPOLFile on page 124
ImportXMLFile on page 132
• Multiple transactions (one or more export files appended in a single file) using the
appropriate import extract rule in a simplified AFGJOB.JDT.
ImportExtract on page 109
ImportNAPOLExtract on page 119
ImportXMLExtract on page 128

NOTE: Create a separate AFGJOB.JDT file for this process, instead of updating an
existing one by commenting out rules and adding new one.

21
Chapter 2
Adding Job and Form Set Rules

Here are some GenData import file processing scenarios:

Using Documaker Server You run the GenData program using an extract file and then execute the GenWIP
program to process any transactions in manual batch. These transactions are then
added to the WIP file.

Extract
file GenData GenWIP
Documaker
Workstation

WIP

Export
GenData file

GenPrint GenArc

NOTE: Transactions in the manual batch file were placed there because they were
flagged to go to manual batch, missing required field data, or were flagged as
KickToWIP.

You then open the WIP transactions using Documaker Workstation, make necessary
changes, and use the File, Complete, Export File option to create the export file.
After you finish, you run GenData Import File Processing using simplified AFGJOB.JDT
and INI files. Using the export file as an import file, the GenData program then creates
new recipient batch, NewTrn, NA, and POL files which you can print, archive, or both
using the GenPrint and GenArc programs.

22
Processing Import Files

Using Documaker You create new transactions using Documaker Workstation and then use the File,
Workstation Complete, Export File option to create the export file.

Documaker
Workstation

Export
file GenData

GenPrint GenArc

You then use GenData Import File Processing to create new recipient batch, NewTrn,
NA, and POL files. These files can be printed, archived, or both using the GenPrint and
GenArc programs.

NOTE: For information on setting up Documaker Workstation, see the Documaker

Workstation Supervisor’s Guide.

Using iPPS You create a transaction using iPPS that is then processed by GenData Import File
Processing to produce PDF files. These files can be viewed on-line and printed.

iPPS

Export
file GenData

GenPrint GenArc

23
Chapter 2
Adding Job and Form Set Rules

RULES USED IN Specific rules are used to combine the execution and functionality of the GenTrn,
GenData, and GenPrint programs into a single step. These rules are listed below, with
SINGLE-STEP a brief description.
PROCESSING
NOTE: You can find more information, including a detailed description of how
processing occurs, in Chapter 2 of the Documaker Server System Reference.

Here’s a list of the rules required for single-step processing.

Rule Description

BatchingByRecipINI on Use this rule to send transactions to a batch you specify

page 66 using INI options.

BatchByPageCount on Use this rule to send a transaction’s form set to a specified

page 45 print batch based on the number of printed pages plus the
multi-mail code defined in the transaction.

BatchingByPageCountINI Use this rule to send a transaction’s form set to a specified

on page 47 batch based on the number of printed pages created when
the system processes the transaction.

BuildMasterFormList on Use this rule to load the FORM.DAT file into an internal
page 71 linked list within the GenData program. You must include
this rule in the AFGJOB.JDT file because the RunSetRcpTbl
rule is dependent on the list this rule creates.

InitPrint on page 144 Use this rule to load printer and recipient batch information.
This rule sets up PRTLIB data, initializes print options, and
loads a table which contains page totals for recipient batch
files.
Use this rule when you run the GenData program by itself to
execute GenTrn and GenPrint processes. This rule, when
combined with the PrintFormset rule, prints form sets.

InitSetRecipCache on Use this rule to set the cache the system uses to store
page 145 recipient information in memory. With this rule you can tell
the system the amount of memory to set aside and use for
storing information in the Key1 and Key2 fields, often used
to store the company and line of business.

NoGenTrnTransactionPr Use this rule when you use the GenData program by itself to
oc on page 166 execute the GenTrn and GenData steps. When combined
with the InitPrint and PrintFormset rules, it creates the
output files created during the GenPrint step.

PageBatchStage1InitTerm Use this rule to create and populate a list of records which
on page 171 contain page ranges and total page counts for each
recipient batch file.

PaginateAndPropagate on Use this rule to paginate the form set and merge in or
page 172 propagate field data.

PrintFormset on page Use this rule when you run the GenData program by itself to
180 execute GenTrn and GenPrint processes. This rule, when
combined with the InitPrint rule, prints form sets.

24
Rules Used in Single-Step Processing

Rule Description

ProcessQueue on page Use this rule to process the queue you specify. This rule
182 loops through the list of functions for the queue you specify
and then frees the queue when finished.

StandardFieldProc on This rule tells the system to process each field on all of the
page 233 images triggered by the SETRCPTB.DAT file. If you use the
StandardFieldProc rule is in your JDT, you must also include
the WriteNAFile rule.

StandardImageProc on This rule tells the system to process each image triggered
page 234 by the SETRCPTB.DAT file.

WriteNAFile on page 245 Use this rule to append the NAFILE.DAT file data records for
the current form set into an existing NAFILE.DAT file.

WriteOutput on page 246 Use this rule to create the POLFILE.DAT file.

WriteRCBWithPageCount Use this rule to write page counts for each recipient.
on page 248

25
Chapter 2
Adding Job and Form Set Rules

RULES USED FOR The following descriptions will help familiarize you with the rules that are required to
perform the 2-up printing process. All of the rules listed in the topic, Rules Used in
2-UP PRINTING Single-Step Processing on page 24 are required for 2-up printing, plus the additional
rules listed below.

NOTE: You can find more information, including a detailed description of how
processing occurs, in Chapter 2 of the Documaker Server System Reference.

Here’s a list of the additional rules you can use for 2-up printing.

Rule Description

AddLine on page 36 (Optional) Use this form set level (level 2) rule to add a line
record, such as for OMR marks, to the AFP record list built by
the MergeAFP rule.

AddTextLabel on page (Optional) Use this form set level (level 2) rule to add a text
37 label record to the AFP record list built by the MergeAFP rule.

GetRCBRec on page 103 Use this form set (level 2) level rule to set the current recipient
batch file. This rule initializes the current recipient batch file, if
necessary.

InitMerge on page 141 Use this job level (level 1) rule to create a list of printers,
batches, and buffers for the comment (RCB) records. This rule
also creates a list to hold AFP records and AFP fonts.

InitPageBatchedJob on Use this job level (level 1) rule to open NA and POL files.
page 143

MergeAFP on page 158 Use this form set level (level 2) rule to initialize input files. This
rule populates the AFP record list, retrieves comment (RCB)
records, and terminates the input files.

OMRMarks on page 167 (Optional) Use this job level (level 1) rule to generate OMR
marks on 2-up documents printed on any AFP printer that
supports 2-up printing.

ParseComment on page (Optional) Use this form set level (level 2) rule to parse
174 comment records into the GVM variable.

PrintData on page 179 Use this form set (level 2) rule to print the form set. This rule is
used for handling 2-up printing on AFP and compatible
printers.

ProcessRecord on page Use this form set (level 2) rule to switch between print files as
183 necessary when printing 2-up forms on an AFP printer. This
rule updates the page count for current print file and loads and
merges the form set.

26
Chapter 3
Job and Form Set Rules
Reference
Job and form set rules help you control how a
processing job is run and how the system processes
the various form sets.
The rules which apply to the job and form set are
stored in the AFGJOB.JDT file, which is called the job
definition table, or JDT file. You add these rules directly
into that file using a text editor.

NOTE: This chapter serves as a reference to job and

form set rules. For information on the rules
which apply to images and fields, see Job and
Form Set Rules Reference on page 27.

This chapter discusses rules included in the base

system and supported by the support group. For
information on custom rules, contact your Professional
Services representative.
In this chapter you will find information about:

• JDT Rules Reference on page 28

27
Chapter 3
Job and Form Set Rules Reference

JDT RULES The following pages list and explain the various job and form set rules you can use. The
rules are discussed in alphabetical order on the pages following this table.
REFERENCE The following table lists the rules by function in the first column. The Level column
indicates whether the rule is a job level rule (1) or a form set level rule (2) in the
AFGJOB.JDT file.
The Overflow column indicates the rules which support the overflow feature. The
overflow features allow extract data to flow onto an additional page if needed.

To… Level Use this rule Overflow

add a form set to a recipient 2 IfRecipUsed on page 106 na

batch

add a line record, such as for 2 AddLine on page 36 na

OMR marks, to the AFP
record list

add a text label record to the 2 AddTextLabel on page 37 na

AFP record list

add data from the extract list 2 Ext2GVM on page 91 na

into global variables

add OMR marks on 1-up or on 1 OMRMarks on page 167 na

2-up documents

append a global variable to 2 AppendGblToExtr on page 40 na

an extract file

append the NAFILE.DAT file 2 WriteNAFile on page 245 na

data records for the current
form set into an existing
NAFILE.DAT file

assign form sets to specific 2 AssignToBatch on page 43 na

batches

assign the recipients from a 2 MergeRecipsFromForm on na

specific form to the other page 159
forms in a form set

build a form candidate list 2 PXCandidateList on page 185 na

build a form list by loading 1 BuildMasterFormList on page na

the FORM.DAT file into an 71
internal linked list within the
GenData program

bypass all image processing 2 ForceNoImages on page 96 na

specified in the DDT file

28
JDT Rules Reference

To… Level Use this rule Overflow

change the printer tray 2 SetOverflowPaperTray on na

during processing. page 221

check a field’s value against 2 BatchByPageCount on page na

another value for 45
transactions currently in the
generic linked list of objects

check for zero font IDs 2 CheckZeroFontID on page 72 na

copy NA_Offset and 2 CreateRecordList on page 75 na

POL_Offset into GVM
variables

copy the data from a given 2 GVM2GVM on page 105 na

GVM variable into another
GVM variable

create a global variable 1 CreateGlbVar on page 74 na

create a print file that 2 ServerFilterFormRecipient on na

contains a set of forms page 212
filtered by form name, form
desc description, or recipient
name

create a list of printers, 1 InitMerge on page 141 na

batches, and buffers for the
comment (RCB) records

create a POL file when doing 2 WriteOutput on page 246 na

2-up printing

create and populate a list of 1 PageBatchStage1InitTerm on na

records which contain page page 171
ranges and total page counts
for each recipient batch file

create the recipient batches 2 WriteRCBFiles on page 247 na

when running in two-step
mode

define an overflow variable 1 SetOvFlwSym on page 224 yes

delete records from an 2 DelExtRecords on page 76 na

extract list

dump an extract list to a file 2 DumpExtList on page 88 na

dump an extract list to a file 2 DumpExtractListToFile on na

by transaction page 89

29
Chapter 3
Job and Form Set Rules Reference

To… Level Use this rule Overflow

exclude transactions from 1 BuildExcludeList on page 69 na

being processed in one- and
two-step mode processing

execute a DAL script 2 PostTransDAL on page 175 na

execute a DAL script 2 PreTransDAL on page 177 na

execute a DAL script if certain 2 PXTrigger on page 187 na

conditions are met

execute a user function 1 RunUser on page 211 na

execute specific transactions 2 RULTestTransaction on page na

for testing purposes 208

execute regional date 2 RegionalDateProcess on page na

processing (RDP) rules on 192
forms.

extract a form set from a DAP 2 LoadFormsetFromArchive on na

archive using an extract file. page 152

get a print batch name from 2 SetOutputFromExtrFile on na

an extract file page 218

get memory allocation 1, 2 AllocDebug on page 39 na

information

get the company (Key1 field) 2 GetCo on page 101 na

from the extract data

get the current date and use 2 GetRunDate on page 104 na

it as the run date

get the line of business (Key2 2 GetLOB on page 102 na

field) from the extract data

import a single transaction 2 ImportNAPOLFile on page na

from a combined NA/POL file 124

import a single transaction 2 ImportFile on page 114 na

from a standard import file

import an extract file 2 ImportExtract on page 109 na

import an XML extract file 2 ImportXMLExtract on page na

128

import an XML file 2 ImportXMLFile on page 132 na

30
JDT Rules Reference

To… Level Use this rule Overflow

import multiple transactions 2 ImportNAPOLExtract on na

from a combined NAPOL page 119
extract file

initialize input files for AFP 2 MergeAFP on page 158 na

printers

initialize resources such as 1 JobInit1 on page 149 na

input and output files

initialize the overflow feature 1 InitOvFlw on page 142 yes

initialize the system for using 1 InitConvertWIP on page 140 na

the ConvertWIP rule

load a table into a link list 1 LoadListFromTable on page na

154

load and initialize all forms 2 BuildFormList on page 70 na

load entries from the 2 LoadRcpTbl on page 155 na

SETRCPTB.DAT file based on
the Key fields and
transaction type

load extract data into 2 LoadExtractData on page 151 na

memory for each transaction

load printer and recipient 1 InitPrint on page 144 na

batch information

load text tables into the text 1 LoadTextTbl on page 157 na

table list

load the field rules from the 2 LoadDDTDefs on page 150 na

MASTER.DDT file into an
internal linked list

load the table files listed in 1 LoadTblFiles on page 156 na

the tables list file

maintain the exact data 2 InlineImagesAndBitmaps on na

printed without LIbrary page 146
Manager

map data you are importing 2 ImageMapImportData on na

page 107

nest overflow within 2 RULNestedOverFlowProc on yes

overflow page 200

31
Chapter 3
Job and Form Set Rules Reference

To… Level Use this rule Overflow

open NA and POL files 1 InitPageBatchedJob on page na

143

paginate the form set and 2 PaginateAndPropagate on na

merge field data, page page 172
ranges, and total pages

parse comment records into 2 ParseComment on page 174 na

the GVM variable field data

print form sets—for multi- 2 PrintData on page 179 na

step processing

print form sets—for single- 2 PrintFormset on page 180 na

step processing

process a queue 1 ProcessQueue on page 182 na

process each field triggered 1 RULStandardFieldProc on na

by the SETRCPTB.DAT file— page 204
for multi-step processing

process each field triggered 1 StandardFieldProc on page na

by the SETRCPTB.DAT file— 233
for single-step processing

process each field triggered 1 WIPFieldProc on page 241 na

by the SETRCPTB.DAT file—
for WIP Transaction
Processing

process each image 1 RULStandardImageProc on na

triggered by the page 205
SETRCPTB.DAT file—for
multi-step processing

process each image 1 StandardImageProc on page na

triggered by the 234
SETRCPTB.DAT file—for
single-step processing

process each image 1 WIPImageProc on page 242 na

triggered by the
SETRCPTB.DAT file—for WIP
Transaction Processing

process each transaction 2 RULStandardTransactionPro na

listed in the extract file c on page 207

process the extract file and 2 NoGenTrnTransactionProc na

create information created in on page 166
both the GenTrn and
GenData steps

32
JDT Rules Reference

To… Level Use this rule Overflow

process the groups (Key1, 2 ProcessTriggers on page 184 na

Key2 combinations) that
exist in the form set, as
opposed to only a single set
of keys specified in the
TRNFILE.DAT file

process WIP transactions 2 WIPTransactions on page 243 na

manually approved or
rejected in Documaker
Workstation

register the 2 ReplaceNoOpFunc on page na

MapFromImportData rule 195
which the system then uses
instead of the NoOpFunc rule

remove forms from form sets 2 FilterForm on page 92 na

remove forms from form sets 2 FilterRecip on page 94 na

based on recipients

replace the LoadRcpTbl and 2 RunTriggers on page 210 na

RunSetRcpTbl rules in
implementations created by
Documaker Studio

replace the 1 ServerJobProc on page 214 na

RULStandardBaseProc rule
when you use IDS to run
Documaker

reset the overflow feature 2 ResetOvFlw on page 197 yes

reset the pRPS structure 2 ResetDocSetNames on page na

after the GVM variables have 196
been remapped.

restart the GenData program 1 RestartJob rule on page 198 na

restart the GenData program 2 RULCheckTransaction on na

page 199

run a user function 1 RunUser on page 211 yes

run Documaker Server from 1 TicketJobProc on page 235 na

another application via an
XML job ticket

run specified entries in the 2 RunSetRcpTbl on page 209 na

set recipient table

33
Chapter 3
Job and Form Set Rules Reference

To… Level Use this rule Overflow

run the GenArc program as 2 Archive on page 41 na

part of single-step
processing

run the GenArc program as 1 InitArchive on page 139 na

part of single-step
processing

run the GenWIP process to 2 ConvertWIP on page 73 na

transfer transactions into
WIP

send a transaction to a batch 2 BatchingByPageCountINI on na

based on the number of page 47
pages the system generates
when it processes the
transaction

send transactions to a batch 2 BatchingByRecipINI on page na

based on data in the extract 66
file

send a transaction to a 2 BatchingByPageCountPerReci na

specific print batch based on pINI on page 53
the number of page count for
each recipient of all form sets
the system generates when it
processes the transaction

send transactions to the 1 ErrorHandler on page 90 na

manual batch when specified
field errors occur

set the amount of memory 1 InitSetRecipCache on page na

you want the system to use 145
to store the information in
Key fields (speed processing
of complex forms)

set the copy count for all 2 SetRecipCopyCount2 on na

forms except those listed page 226

set the copy count for all 2 SetRecipCopyCount on page na

forms specified 225

set the current recipient 2 GetRCBRec on page 103 na

batch file

sort RCB batches before 1 SortBatches on page 227 na

they are printed (so you can
call a sort program to
rearrange the order of the
RCB files)

34
JDT Rules Reference

To… Level Use this rule Overflow

specify a job definition file 1 StandardFieldProc on page na

233

specify a print batch file for 2 AssignBatWithTbl on page 42 na

all recipients

specify multiple XDBs to use 2 MultipleDataDictionaryFiles na

across multiple key on page 164
combinations

specify the codes the system 1 MergeWIP on page 160 na

should look for in WIP
Transaction Processing

specify the text in the header 1 SetErrHdr on page 217 na

of the error file

switch between print files 2 ProcessRecord on page 183 na

when doing 2-up printing

terminate an XDB instance 1 Dictionary on page 77 na

and free memory

translate error information 1 TranslateErrors on page 236 na

use an XML extract file 2 UseXMLExtract on page 238 na

use an XML extract file 2 XMLFileExtract on page 250 na

write out forms which 2 FormDescription on page 97 na

contain descriptions of the
other forms in the form set

write transactional 1 InstallCommentLineCallbac na

information into each page of k on page 148
the print stream

write out full NA and POL 2 DocumentExport on page 78 na

information as well as certain
export field information

write the page count for each 2 WriteRCBWithPageCount on na

recipient when doing 2-up page 248
printing

write the POL set to the 2 UpdatePOLFile on page 237 na

POLFILE.DAT file

35
Chapter 3
Job and Form Set Rules Reference

AddLine
Use this form set level (level 2) rule to add a line record, such as for OMR marks, to the
AFP record list built by the MergeAFP rule.

Syntax ;AddLine;;Top,Bottom,Left,Right;

Parameter Description

Top location of the top edge of the line

Bottom location of the bottom edge of the line

Left location of the left edge of the line

Right location of the right edge of the line

NOTE: The parameter values are all in absolute FAP coordinates. No shifting is done,
which lets you place the marks anywhere on the printable area of the paper.

Example ;AddLine;;600,1200,600,1000;
This example tells the system to draw a line ¼ inch from the left edge of the page, down
¼ inch from the top of the page, for a length of ½ inch, with a width of a ¼ inch.

Text The text to be added.

XPos The x coordinate of the text.

YPos The y coordinate of the text.

Orientation The optional text rotation (0, 90, 180, or 270 degrees).

Font The AFP code font file name of the font to be used.
Make sure the font has been defined in the font cross-reference (FXR) file
and the font has already been used in a field, text label, or text area on that
form set.
In some situations, you may want to add a hidden field which uses the font
you specify in this parameter of the AddTextLabel rule.

NOTE: Enter the XPos and YPos values in absolute FAP coordinates. No shifting
occurs, which lets you place the marks anywhere on the printable area of the
paper.

Example ;AddTextLabel;;Preliminary,600,600,90,X0DACOBF;

This example tells the system to write the text, Preliminary, on each page beginning ¼
inch down from top of page and ¼ inch in from the left page edge. The system rotates
the text 90 degrees and uses Courier bold 16 pitch as the font.
Here is another example:
;AddTextLabel;;=DAL("page_1.dal"),5740,4500,0,X0DATIN9;
;AddTextLabel;;=DAL("page_1_barcode"),1800,35200,90,X0BC4N9P;

This example includes this DAL script:

BeginSub Page_1
#page_cnt = #page_cnt
page_number = "*8080000001A00000" & #page_cnt & "S*"
#page_cnt += 1
Return(page_number)
EndSub

These rules tell the system to execute the DAL script named page_1 to get the dynamic
data that will be placed on each page beginning 4500 FAP units down from top of the
page and 5740 FAP units in from the left page edge using the Times Roman 9 pitch font.
Here is another example:
;AddTextLabel;;=DAL("page_1_barcode"),1800,35200,90,X0BC4N9P;

37
Chapter 3
Job and Form Set Rules Reference

This example includes this DAL script:

BeginSub Page_1_barcode
Return(new_barcode_left)
EndSub

This rule tells the system to execute the DAL script named page_1_barcode to get the
data will be placed on each page beginning 35200 FAP units down from top of the page
and 1800 FAP units in from the left page edge rotated down 90 degrees. The dynamic
data will be displayed as a 3x9 barcode.

Syntax ;MYW32->AppendGblToExtr;2;ExtractFile_Key,GBL_Var GBL_Var ...GBL_Var;

In the data field, enter the name of the key the extract record should append to and the
names of all global variables you want to appended to it.
You define the maximum length of the extract file record using this INI option:
< TRN_File >
MaxExtRecLen =
If you are appending multiple GVM variables and are using an extract file key, the
accumulated length should not exceed the maximum extract record length defined in
the MaxExtRecLen option.

NOTE: If you enter the string NOHEADER as the ExtractFile_Key, the system appends
global variables to the extract list without a header key.

If the accumulated length exceeds MaxExtRecLen, the rule fails and issues the
following error:
Error in AppendGblToExtr(): Global variable <> exceeds maximum
length. Check MaxExtRecLen in INI group <TRN_FILE>

Example ;AppendGblToExtr;;;

Example Here is an example:

< Base Form Set Rules >
;Archive;2;;

Syntax ;MYW32->AssignBatWithTbl;2;ASSNBTCH.TBL,1,XYZ (D) (I,B,S1,H);;

In the data field, enter the name of the file which contains the batch assignment table.
Entering the full path is optional.
After the file name, specify the search mask which if found tells the system to add the
recipients (D) to the batch. If no record is found that matches the mask, recipients
I,B,S1 and H are added to the batch.
The first set of parentheses contains the recipient list of draft recipients, the second set
contains all other recipients the implementation uses.
The syntax for the batch assignment table is as follows. This is a small example with
three entries, you can include more.
;BATCH2;*;;
;BATCH1;1,123;;
;BATCH3;1,456;;
(more lines could follow)

There are three semicolon-delimited fields, the first is a batch name, the second is a
search mask which will be run against the extract data list for a possible match. The
search mask field consists of one or more offset,data pairs. If there is data from
different records, delimit the search masks by entering a pipe symbol (|).

Example ;BATCH1;1,123|1,546,18,XXX;HO,I,B1,B2;
The first record who’s search mask matches a record in the extract data, moving from
top to bottom through the list, will be used to determine the batch name for the
processing of that transaction.
There must always be an entry which has an asterisk (*) as its search mask. This is the
default batch the system uses if no matches are found. You must specify a default
batch.
In the third field you can enter a set of recipient codes delimited by commas. If you
enter this information, the system will only print forms for the recipients you specify.
Note that the printed recipients will be a subset of the recipients specified.

NOTE: This rule can produce errors if it is run before the form set is created. You must
place this rule after any rule which is used to build the form set. Normally, you
would use the BuildFormList rule to build the form set.

Delimiter An equal sign (=). This is required.

Search mask One or more pairs of offsets and data (search criteria) in a comma
delimited list. Here is an example:
;AssignToBatch;;Manual=1,Patch399,31,AssignToBatch;
This example searches the records of each transaction for the string
Patch399 at offset 1 and the string AssignToBatch at offset 31. If a match
is found then this transaction will be assigned to the Manual batch.

This table explains the order in which rules are assigned to recipient batches:

Batch Order of precedence

Error If an error occurs that causes the batch assignment of the transaction.

Manual If the POWType rule exists in any triggered image.

Manual If the KickToWIP rule exists and its condition are met.

xxxxxx AssignToBatch rule assignment if the rule exists and its search criteria is met.

xxxxxx Base form set rules such as: IfRecipUsed, BatchingByPageCountINI,

BatchingByRecipINI, and so on.

Example Here is an excerpt from an AFGJOB.JDT file:

<Base Rules>
;RULStandardJobProc;;;
…
…
<Base Form Set Rules>
;RulStandardTransactionProc;;;
…
…
;AssignToBatch;;Manual=1,Patch399,31,GVM,190,AssignToBatch;
;IfRecipUsed;2;Batch1=Customer;

43
Chapter 3
Job and Form Set Rules Reference

…
…
Any transaction that has a record that matches the search criteria (character strings:
'Patch399' at offset 1, 'GVM' at offset 31 and ' AssignToBatch' at offset 190) will be
assigned to the Manual batch.

Control Group Description

BatchingByRecip The name is defined by the system, as shown here.

Print_Batches The name is defined by the system, as shown here.

PrinterInfo The name is defined by the system, as shown here.

Batch File Name You define the name of this control group.

Printed Output File You define the name of this control group.

You must have these control groups in your FSISYS.INI or FSIUSER.INI file.

BatchingByRecip control This control group must contain these INI options:
group
< BatchingByRecip >
DefaultBatch = DefaultOutput
Batch_Recip_Def =

Use the DefaultBatch option to assign a name to the default batch, such as
DefaultOutput. Do not enclose the name in quotation marks.
Use the Batch_Recip_Def option to define the conditions the system will use to
determine which batch it should choose for each transaction. The syntax for the
Batch_Recip_Def option is shown here:
Condition; ”BatchName”; Recipient

You can define a series of these options to specify all of the conditions necessary to
determine the desired batching for your transactions.

NOTE: For a complete description of error and manual batches, see the Documaker
Server System Reference.

47
Chapter 3
Job and Form Set Rules Reference

Parameter Description

Condition This lets you specify a condition that must be satisfied before the
transaction is assigned to the print batch and recipients. You can use the
True keyword to set the condition:
True - Enter this keyword to specify that the condition must always be true.
This tells the system to send the form set to the specified print batch if the
recipient is specified in the recipient list for the batch.
You can also use these user-defined options instead of the keyword:
Search mask – the search mask consists of one or more offset, data pairs.
See Search Criteria on page 290.
Error - if the error batch flag is set by another rule, send the form set to the
specified print batch (if the form’s recipient is specified in the recipient list
for the batch). For example, an error occurs if the Host Required field is set
on a Move_It rule and the data is missing.
Manual - if the manual batch flag is set by another rule, send the form set
to the specified print batch (if the recipient is specified in the recipient list
for the batch). You could also use the KickToWip rule.
Condition name - a condition name defined in the condition table. See
Using Condition Tables and the Record Dictionary on page 507.

Batch You can specify the batch name by specifying the recipient name, the batch
Name name, or using a batch name defined in the Record Dictionary.
Recipient name - use one of the names contained in the Recip_Names
control group as batch name. Enclose this name in quotes, such as
“customer”.
Batch name - a batch name extract from the extract file. The format is a
comma-delimited field: a search mask followed by a blank space and then
an offset, followed by the length of name to use.
Dict( ) – a batch name defined in the Record Dictionary. Enclose this name
in quotes, such as “batch1”.
Use the pipe symbol (|) to indicate separate items concatenated together,
such as print1|print2.

Recipients You can specify recipients using a keyword (All) or you can list specific
recipients.
All - Enter this keyword to tell the system to use all recipients in the
Recip_Names control group.
list - a list of recipient names. If you list the names, separate each recipient
with a comma or space, such as customer,agent.

The system processes the information in this order:

1 If the conditions are met, the print batch you specified is used as the batch for the
form set, provided the form set’s recipients are specified in the recipient list for the
batch. In addition, the system writes the batch record for the form set to the
batches for the specified recipients.
2 If a transaction does not meet the condition for the first Batch_Recip_Def option,
the system continues through the series of Batch_Recip_Def options until the
condition for a Batch_Recip_Def option is met.

48
BatchingByPageCountINI

3 If a transaction does not meet any of the Batch_Recip_Def criteria, the transaction
is placed in the batch specified in the DefaultBatch option. If the DefaultBatch
option is not defined, an error occurs. The order in which you list the
Batch_Recip_Def options determines how the system determines recipient
batches. Put the most likely batches first. Use the All keyword rather than listing
all recipients when appropriate.

Print_Batches control This control group must include at least one entry for each unique batch name in the
group BatchingByRecip control group.
< Print_Batches >
Batch name = .\batch\page1

Option Description

Batch name You define the name and path for each batch file, such as .\batch\page1.

PrinterInfo control group This control group must include an entry for each unique batch file name listed in the
Print_Batches control group. This control group has the following option:
< PrinterInfo >
Printer = Page1Prt

Option Description

Printer You define the name for each batch file listed in the Print_Batches control
group, such as Page1Prt.

BatchFileName control You define the name for this control group, such as Page1. You must have a
group BatchFileName control group for each batch name option defined in the Print_Batches
control group. This control group must include at least two options. The options are
shown here:
< Page1 >
Printer = (file name)
PageRange = 1,3

Option Description

Printer You define the name for the printed output file, such as Page1Prt.

PageRange The minimum and maximum number of pages, separated by a comma.

The example above show one as the minimum with three as the
maximum.

PrintedOutputFile control You define the name for this control group, such as Page1Prt. This control group must
group include as a minimum one option. There must be a PrintedOutputFile control group for
each printer option defined in each BatchFileName control group, as shown here:
< Page1Prt >
Port = .\print\page1prt.pcl

49
Chapter 3
Job and Form Set Rules Reference

Option Description

Port You define the name and path for the printed output file, such as
print\page1prt.pcl.

Example This single-step processing example sends transactions to print batches based on the
number of printed pages the system generated as it processed each transaction. The
following INI settings and JDT rules tell the system to place the transaction form sets it
generates into specific print batches and printed output files based on the page counts.

If the transaction has... Print_Batches Printed Output File

1 page .\Batch\Page1 .\Print\Page1Prt.pcl

2 to 3 pages .\Batch\Pages2 .\Print\Pages2Prt.pcl

4 to 10 pages .\Batch\Pages4 .\Print\Pages4Prt.pcl

more the 10 pages .\Batch\DefaultOutput .\Print\Default.pcl

Here is an example of the AFGJOB.JDT file:

/* JDT Rules showing use of BatchingByPageCountINI rule */
<Base Rules>
;RULStandardJobProc;;Always the first job level rule;
….
…
;InitSetrecipCache;;;
;InitPrint;;; required to execute GenData/GenPrint as single step;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;first transaction level rule when not
using GenTrn;
…
…
;PrintFormset;;; required to execute GenData/GenPrint as single step;
;WriteOutput;;;
;WriteNaFile;;;
;CreateRecordList;;;
;WriteRCBWithPageCount;2;;
;BatchingByPageCountINI;2;;
;ProcessQueue;;PostPaginationQueue;
;PaginateAndPropagate;;;
…
…

Here are examples of the FSISYS.INI file control groups and options:
< BatchingByRecip >
DefaultBatch = DefautOutput
Batch_Recip_Def= True;"Page1";All
Batch_Recip_Def= True;"Pages2";All
Batch_Recip_Def= True;"Pages4";All
< Print_Batches >
DefaultOutput = .\Batch\DefaultOutput

50
BatchingByPageCountINI

Page1 = .\Batch\Page1
Pages2 = .\Batch\Pages2
Pages4 = .\Batch\Pages4
< PrinterInfo >
Printer = DefaultOutputPrt
Printer = Page1Prt
Printer = Pages2Prt
Printer = Pages4Prt
< DefaultOutput >
Printer = DefaultOutputPrt
< Page1 >
Printer = Page1Prt
PageRange = 1,1
< Pages2 >
Printer = Pages2Prt
PageRange = 2,3
< Pages4 >
Printer = Pages4Prt
PageRange = 4,10
< DefaultOutputPrt >
Port = .\Print\DefaultOutputprt.pcl
< Page1Prt >
Port = .\Print\Page1Prt.pcl
< Pages2Prt >
Port = .\Print\Pages2Prt.pcl
< Pages4Prt >
Port = .\Print\Pages4Prt.pcl

In addition to selecting by page count, this rule also has all of the functionality of
BatchingByRecipINI rule. Here is an example of how you set it up:
< BatchingByRecip >
Batch_Recip_Def= 30,5;"BATCH1";ALL
Batch_Recip_Def= 51,1;"BATCH2";ALL
Batch_Recip_Def= 30,2;"BATCH3";ALL
Batch_Recip_Def= True;"BATCH4";ALL
Batch_Recip_Def= True;"BATCH5";ALL
< Batch1 >
Printer = Printer1
PageRange = 1,9999
< Batch2 >
Printer = Printer2
PageRange = 1,9999
< Batch3 >
Printer = Printer3
PageRange = 1,9999
< Batch4 >
Printer = Printer4
PageRange = 1,6
< Batch5 >
Printer = Printer5
PageRange = 7,9999

The first Batch_Recip_Def option tells the system to place into BATCH1 all recipients
which have a 5 at offset 31. If a transaction does not meet the first condition, processing
continues through the INI list. Processing stops once the appropriate batch is found.

51
Chapter 3
Job and Form Set Rules Reference

Therefore, if no condition is met by the third option, the transaction is assigned to

BATCH4 or BATCH5 based on the page count. If the page count is less than seven, it is
assigned to BATCH4. If the page count is sever or greater, it is assigned to BATCH5.
The order in which you list the Batch_Recip_Def options determines how the system
determines recipient batches. Put the most likely batches first. Use All rather listing all
recipients when appropriate.
Keep in mind that when using this rule in this manner you should always include the
PageRange parameter in each group, even if the batch is not associated with page
counts.

The system processes the information in this order:

54
BatchingByPageCountPerRecipINI

1 If the conditions are met, the print batch you specified is used as the batch for the
form set, provided the form set's recipients are specified in the recipient list for the
batch. In addition, the system writes the batch record for the form set to the
batches for the specified recipients.
2 If a transaction does not meet the condition for the first Batch_Recip_Def option,
the system continues through the series of Batch_Recip_Def options until the
condition for a Batch_Recip_Def option is met.
3 If a transaction does not meet any of the Batch_Recip_Def criteria, the transaction
is placed in the batch specified in the DefaultBatch option. If the DefaultBatch
option is not defined, an error occurs. The order in which you list the
Batch_Recip_Def options determines how the system determines recipient
batches. Put the most likely batches first. Use the All keyword rather than listing
all recipients when appropriate.

Print_Batches control This control group must include at least one entry for each unique batch name in the
group BatchingByRecip control group.
< Print_Batches >
Batch name = ..\batch\AllOnePageBatch.bch

Option Description

Batch name You define the name and path for each batch file, such as
..\batch\AllOnePageBatch.bch

PrinterInfo control group This control group must include an entry for each unique batch file name listed in the
Print_Batches control group.
< PrinterInfo >
Printer = Printer1

Option Description

Printer You define the name for each batch file listed in the Print_Batches control
group, such as Printer1.

BatchFileName control You define the name for this control group, such as AllOnePageBatch. You must have
group a BatchFileName control group for each batch name option defined in the
Print_Batches control group. This control group must include at least these two
options. The options are shown here:
< AllOnePageBatch >
Printer = (file name)
PageRange = 1,1

Option Description

Printer You define the name for the printed output file, such as Printer1.

PageRange Enter the minimum and maximum number of pages, separated by a

comma. The example above shows one as the minimum and the
maximum.

55
Chapter 3
Job and Form Set Rules Reference

PrintedOutputFile control You define the name for this control group, such as Printer1. This control group must
group include as a minimum one option. There must be a PrintedOutputFile control group for
each printer option defined in each BatchFileName control group, as shown here:
< Printer1 >
Port = ..\PrintFiles\AllOnePageBatch.PCL

Option Description

Port You define the name and path for the printed output file, such as
..\PrintFiles\AllOnePageBatch.PCL

INI File Examples

Here are examples of the FSISYS.INI file control groups and options for several
different scenarios

Scenario 1 In this scenario, we will be showing how to set up a True condition. This tells the system
to send the form set to the specified print batch if the recipient is specified in the
recipient list for the batch. Here is an example from the FSISYS.INI file:
< BatchingByRecip >
DefaultBatch = Default
Batch_Recip_Def = True;"INSURED1PAGE";INSURED
Batch_Recip_Def = True;"COMPANY1PAGE";COMPANY
Batch_Recip_Def = True;"AGENT1PAGE";AGENT
Batch_Recip_Def = True;"INSUREDMULTIPAGE";INSURED
Batch_Recip_Def = True;"COMPANYMULTIPAGE";COMPANY
Batch_Recip_Def = True;"AGENTMULTIPAGE";AGENT
Batch_Recip_Def = Manual;"MANUAL";ALL
Batch_Recip_Def = Error;"ERROR";ALL

For each recipient, all one-page form sets go into one batch as shown here:
< Insured1Page >
Printer = Printer1
PageRange = 1,1
< Company1Page >
Printer = Printer2
PageRange = 1,1
< Agent1Page >
Printer = Printer3
PageRange = 1,1

All forms sets with two or more pages for each recipient go into a different batch, as
shown here:
< InsuredMultipage >
Printer = Printer4
PageRange = 2,99999
< CompanyMultipage >
Printer = Printer5
PageRange = 2,99999
< AgentMultipage >
Printer = Printer6
PageRange = 2,99999
< Default >

56
BatchingByPageCountPerRecipINI

Printer = PDefault

Form sets that need to go into WIP are in the manual batch:
< Manual >
Printer = Printer7
PageRange = 1,99999
Form sets with errors go into the error batch:
< Error >
Printer = Printer8
PageRange = 1,99999

This excerpt shows how to set the Print_Batches, PrinterInfo, and PrintedOutputFile
control groups:
< Print_Batches >
Default = default.bch
Insured1Page = insured1page.bch
Company1Page = company1page.bch
Agent1Page = agent1page.bch
InsuredMultipage = insuredmultipage.bch
CompanyMultipage = companymultipage.bch
AgentMultipage = agentmultipage.bch
Manual = manual.bch
Error = error.bch
< Printer1 >
Port = data\insured1page.pcl
< Printer2 >
Port = data\company1page.pcl
< Printer3 >
Port = data\agent1page.pcl
< Printer4 >
Port = data\insuredmultipage.pcl
< Printer5 >
Port = data\companymultipage.pcl
< Printer6 >
Port = data\agentmultipage.pcl
< Printer7 >
Port = data\manual.pcl
< Printer8 >
Port = data\error.pcl
< PDefault >
Port = data\pdefault
< PrinterInfo >
Printer = Printer1
Printer = Printer2
Printer = Printer3
Printer = Printer4
Printer = Printer5
Printer = Printer6
Printer = Printer7
Printer = Printer8
Printer = PDEFAULT

57
Chapter 3
Job and Form Set Rules Reference

Scenario 2 This scenario defines two simple conditions in a condition table based on information
in the data dictionary. In the condition table two conditions are set which define the
two company types, representing the two different company transactions in the extract
file. Condition 1 (Cond1) searches for an S for Sampco company transactions. Condition
2 (Cond2) searches for an F for FSI company transactions. This scenario creates
batches for recipients by company and page count. The data dictionary and condition
table for this scenario are shown below:
From the data dictionary:
<Records>
Header = Search(11,HEADERREC)
<Variables>
CompanyType = Record(Header) Offset(1) Length(1) Type(Char)

From the condition table:

< Conditions >
Cond1 : CompanyType = "S"
Cond2 : CompanyType = "F"

From the FSISYS.INI file:

< BatchingByRecip >
DefaultBatch = Default
Batch_Recip_Def = COND(Cond1);"SAMPCO1PAGE";INSURED
Batch_Recip_Def = COND(Cond1);"SAMPCOMULTIPAGE";INSURED
Batch_Recip_Def = COND(Cond2);"FSI1PAGE";INSURED
Batch_Recip_Def = COND(Cond2);"FSIMULTIPAGE";INSURED
Batch_Recip_Def = Manual;"MANUAL";ALL
Batch_Recip_Def = Error;"ERROR";ALL
< Default >
Printer = PDefault

For each recipient, all one-page form sets for each company go into a separate batch
as shown here:
< Sampco1Page >
Printer = Printer1
PageRange = 1,1
< FSI1Page >
Printer = Printer3
PageRange = 1,1

For each recipient, all form sets with two or more pages go into a separate batch for
each company as shown here:
< SampcoMultipage >
Printer = Printer2
PageRange = 2,99999
< FSIMultipage >
Printer = Printer4
PageRange = 2,99999

Form sets that go to WIP are put into the manual batch:
< Manual >
Printer = Printer5
PageRange = 1,99999

58
BatchingByPageCountPerRecipINI

Form sets with errors go into the error batch:

< Error >
Printer = Printer6
PageRange = 1,99999

This excerpt shows how to set the Print_Batches, PrinterInfo, and PrintedOutputFile
control groups:
< Print_Batches >
Default = default.bch
Sampco1Page = sampco1page.bch
SampcoMultipage = sampcomultipage.bch
FSI1Page = fsi1page.bch
FSIMultipage = fsimultipage.bch
Manual = manual.bch
Error = error.bch
< Printer1 >
Port = data\sampco1page.pcl
< Printer2 >
Port = data\sampcomultipage.pcl
< Printer3 >
Port = data\fsi1page.pcl
< Printer4 >
Port = data\fsimultipage.pcl
< Printer5 >
Port = data\manual.pcl
< Printer6 >
Port = data\error.pcl
< PDEFAULT >
Port = data\pdefault
< PrinterInfo >
Printer = Printer1
Printer = Printer2
Printer = Printer3
Printer = Printer4
Printer = Printer5
Printer = Printer6
Printer = PDefault
< Tables >
Path = .\tables\
Recipient = reciptbl.dat
Conditions = condition.tbl
< DataDictionary >
Name = datadict.tbl
< SymLookup >
MaxCache = 1000
LeastFrequent = Yes

59
Chapter 3
Job and Form Set Rules Reference

Scenario 3 This scenario looks for a token from the XDB to send form sets to agent batches. Here
is an excerpt from the FSISYS.INI file:
< BatchingByRecip >
DefaultBatch = Default
Batch_Recip_Def = ?AGENT NAME;"AGENTNAME1PAGE";AGENT
Batch_Recip_Def = ?AGENT NAME;"AGENTNAMEMULTIPAGE";AGENT
Batch_Recip_Def = Manual;"MANUAL";ALL
Batch_Recip_Def = Error;"ERROR";ALL

If the token is not found, the system sends form sets to the Default batch:
< Default >
Printer = PDefault

If a token is found, the system sends all one-page transactions to an Agent batch
specifically for one-page form sets:
< AgentName1Page >
Printer = Printer1
PageRange = 1,1

If a token is found, the system sends all transactions that are more than one page to an
Agent batch designed to hold forms sets that consist of two or more pages:
< AgentNameMultipage >
Printer = Printer2
PageRange = 2,99999

Form sets that go to WIP are put into the manual batch:
< Manual >
Printer = Printer3
PageRange = 1,99999

Form sets with errors go into the error batch:

< Error >
Printer = Printer4
PageRange = 1,99999
This excerpt shows how to set the Print_Batches, PrinterInfo, and PrintedOutputFile
control groups:
< Print_Batches >
Default = default.bch
AgentName1Page = agentname1page.bch
AgentNameMultipage = agentnamemultipage.bch
Manual = manual.bch
Error = error.bch
< Printer1 >
Port = data\agentname1page.pcl
< Printer2 >
Port = data\agentnamemultipage.pcl
< Printer3 >
Port = data\manual.pcl
< Printer4 >
Port = data\error.pcl
< PDefault >
Port = data\pdefault
< PrinterInfo >
Printer = Printer1

60
BatchingByPageCountPerRecipINI

Printer = Printer2
Printer = Printer3
Printer = Printer4
Printer = PDefault

Scenario 4 Like the previous scenario, this scenario sends form sets to agent batches depending
on the number of pages. This scenario, however, uses a GVM variable as the condition
and an XML extract file. In the AFGJOB.JDT, you must first create the global variable you
are going to use for the condition. In this scenario, it is called AGT1. To create it, use the
CreateGlbVar rule. Then, use the Ext2GVM rule to map the data to the GVM variable
named AGT1. This rule is placed after the LoadExtractData rule in the AGFJOB.JDT file.
If the GVM variable (AGT1) holds a value, the condition is considered true and the
transaction is written to the appropriate batch by the page count. If the GVM variable
(AGT1) does not hold a value, the condition is considered false and the transaction will
be written to the Default batch. Here is an example:
/* This base (this implementation) uses these rules. */
<Base Rules>
;RULStandardJobProc;1;Always the first job level rule;
;SetErrHdr;1;*:;
;SetErrHdr;1;*:------------------------------------------------;
;SetErrHdr;1;*: FormMaker Data Generation (Base);
;SetErrHdr;1;*: ;
;SetErrHdr;1;***: Transaction: ***PolicyNum***;
;SetErrHdr;1;***: Symbol: ***Symbol***;
;SetErrHdr;1;***: Module: ***Module***;
;SetErrHdr;1;***: State: ***State***;
;SetErrHdr;1;***: Company Name (after ini conversion):
***Company***;
;SetErrHdr;1;***: Line of Business (after ini conversion):
***Lob***;
;SetErrHdr;1;***: Trans Type: ***TransactionType***;
;SetErrHdr;1;***: Run Date: ***Rundate***;
;SetErrHdr;1;*:------------------------------------------------;
;CreateGlbVar;1;TXTLst,PVOID;
;CreateGlbVar;1;TblLstH,PVOID;
;CreateGlbVar;1;AGT1,CHAR_ARRAY,15;
;JobInit1;1;;
;LoadDDTDefs;1;;
;InitOvFlw;1;;
;LoadTextTbl;1;;
;LoadTblFiles;1;;
;SetOvFlwSym;1;CGDECBDOVF,Q1GDBD,5;
;BuildMasterFormList;1;4;
<Base Form Set Rules>
;RULStandardTransactionProc;2;Always the first transaction level
rule;
;LoadExtractData;2;;
;GetCo;2;11,HEADERREC 35,3;
;GetLOB;2;11,HEADERREC 40,3;
;Ext2Gvm;2;!/COMPANY/FORMS/FORM/SECTION/FIELDS/AGENTNAME 1,15,AGT1;
;ResetOvFlw;2;;
;BuildFormList;2;;
;LoadRcpTbl;2;;
;UpdatePOLFile;2;;
;RunSetRcpTbl;2;;

61
Chapter 3
Job and Form Set Rules Reference

;BatchingByPageCountPerRecipINI;;;

Here is an example of the FSISYS.INI file:

< BatchingByRecip >
DefaultBatch = Default
Batch_Recip_Def = =GVM("AGT1"),;"AGENTNAME1PAGE";AGENT
Batch_Recip_Def = =GVM("AGT1"),;"AGENTNAMEMULTIPAGE";AGENT
Batch_Recip_Def = Manual;"MANUAL";ALL
Batch_Recip_Def = Error;"ERROR";ALL
< Default >
Printer = PDefault

If the GVM variable holds a value, the system sends all one-page transactions to an
Agent batch specifically for one-page form sets:
< AgenName1Page >
Printer = Printer1
PageRange = 1,1
If the GVM variable holds a value, the system sends all transactions that are more than
one page to an Agent batch designed to hold form sets that consist of two or more
pages:
< AgentNameMultipage >
Printer = Printer2
PageRange = 2,99999

Form sets that go into WIP are put in the manual batch:
< Manual >
Printer = Printer3
PageRange = 1,99999
Form sets with errors go into the error batch:
< Error >
Printer = Printer4
PageRange = 1,99999

This excerpt shows how to set the Print_Batches, PrinterInfo, and PrintedOutputFile
control groups:
< Print_Batches >
Default = default.bch
AgentName1Page = agentname1page.bch
AgentNameMultipage = agentnamemultipage.bch
Manual = manual.bch
Error = error.bch
< Printer1 >
Port = data\agentname1page.pcl
< Printer2 >
Port = data\agentnamemultipage.pcl
< Printer3 >
Port = data\manual.pcl
< Printer4 >
Port = data\error.pcl
< PDefault >
Port = data\pdefault
< PrinterInfo >
Printer = Printer1

62
BatchingByPageCountPerRecipINI

Printer = Printer2
Printer = Printer3
Printer = Printer4
Printer = PDefault

Scenario 5 Like scenario 4, this scenario sends form sets to agent batches depending on the
number of pages. This scenario, however, uses a DAL script called agent.dal to set the
condition along with using an XML extract file. In the AFGJOB.JDT, we must use a
PreTransDAL to call the DAL script to set the condition. In this scenario, it is called
AGT1. This rule is placed after the RunSetRcpTbl rule in the AGFJOB.JDT file. Once the
DAL script set a value to the DAL variable, the condition is considered true and the
transaction is written to the respective batch for the Batch_Recip_Def condition by
page count. If the DAL script does not set a value to the DAL variable, the condition is
considered false and the transaction is written to the Default batch instead. Here is an
example:
/* This base (this implementation) uses these rules. */
<Base Rules>
;RULStandardJobProc;1;Always the first job level rule;
;SetErrHdr;1;*:;
;SetErrHdr;1;*:------------------------------------------------;
;SetErrHdr;1;*: FormMaker Data Generation (Base);
;SetErrHdr;1;*: ;
;SetErrHdr;1;***: Transaction: ***PolicyNum***;
;SetErrHdr;1;***: Symbol: ***Symbol***;
;SetErrHdr;1;***: Module: ***Module***;
;SetErrHdr;1;***: State: ***State***;
;SetErrHdr;1;***: Company Name (after ini conversion):
***Company***;
;SetErrHdr;1;***: Line of Business (after ini conversion):
***Lob***;
;SetErrHdr;1;***: Trans Type: ***TransactionType***;
;SetErrHdr;1;***: Run Date: ***Rundate***;
;SetErrHdr;1;*:------------------------------------------------;
;CreateGlbVar;1;TXTLst,PVOID;
;CreateGlbVar;1;TblLstH,PVOID;
;JobInit1;1;;
;LoadDDTDefs;1;;
;InitOvFlw;1;;
;LoadTextTbl;1;;
;LoadTblFiles;1;;
;SetOvFlwSym;1;CGDECBDOVF,Q1GDBD,5;
;BuildMasterFormList;1;4;
<Base Form Set Rules>
;RULStandardTransactionProc;2;Always the first transaction level
rule;
;LoadExtractData;2;;
;GetCo;2;11,HEADERREC 35,3;
;GetLOB;2;11,HEADERREC 40,3;
;ResetOvFlw;2;;
;BuildFormList;2;;
;LoadRcpTbl;2;;
;UpdatePOLFile;2;;
;RunSetRcpTbl;2;;
;PreTransDAL;;Call("agent.dal");
;BatchingByPageCountPerRecipINI;;;

63
Chapter 3
Job and Form Set Rules Reference

Here is an example of the FSISYS.INI file:

< BatchingByRecip >
Batch_Recip_Def = =DAL("AGT1"),;"AGENTNAME1PAGE";AGENT
Batch_Recip_Def = =DAL("AGT1"),;"AGENTNAME1PAGE";AGENT
Batch_Recip_Def = Manual;"MANUAL";ALL
Batch_Recip_Def = Error;"ERROR";ALL
DefaultBatch = Default

If the DAL variable holds a value, the system sends all one-page transactions to an
Agent batch specifically for one-page form sets:
< AgentName1Page >
Printer = Printer1
PageRange = 1,1
If the DAL variable holds a value, the system sends all transactions that are more than
one page to an Agent batch designed to hold form sets that consist of two or more
pages:
< AgentNameMultipage >
Printer = Printer2
PageRange = 2,99999

If the DAL variable does NOT hold a value, the condition is considered false and the
transaction is sent to the Default batch.
< Default >
Printer = PDefault

Form sets that go into WIP are put in the manual batch:
< Manual >
Printer = Printer3
PageRange = 1,99999

Form sets with errors go into the error batch:

64
BatchingByPageCountPerRecipINI

Printer = Printer1
Printer = Printer2
Printer = Printer3
Printer = Printer4
Printer = PDefault

Condition You can use these keywords:

COND
A condition name defined in the condition table.
Error
If the error batch flag is set by another rule, send the form set to the
specified batch (if the form’s recipient is specified in the recipient list for
the batch). For example, an error occurs if the Host Required field is set on
a Move_It rule and the data is missing.
Manual
If the manual batch flag is set by another rule; send the form set to the
specified batch (if the recipient is specified in the recipient list for the
batch). An example of another rule you could use is the KickToWip rule.
True
The condition is always true; send the form set to the specified batch (if
the recipient is specified in the recipient list for the batch).
Search mask
The search mask consists of one or more offset,data pairs.

Batch name Batch name from the extract file. The format is a comma-delimited field: a
search mask followed by a blank space and then an offset, followed by the
length of name to use. Keep in mind the batch name is limited to eight
characters. You can use these keywords:
Recip_Name means to use the names contained in the Recip_Names
control group as batch names
Dict( ) – The batch name defined in the Record Dictionary. Enclose this
name in quotes, such as “Batch1”.
Use the pipe symbol (|) to indicate separate items concatenated together.

Recipients Enter All for all recipients or list the recipient names. If you list the names,
separate each recipient with a comma or space.

66
BatchingByRecipINI

If the conditions are met, the batch you specified is used as the batch for the form set,
provided the form set’s recipients are specified in the recipient list for the batch. In
addition, the system writes the batch record for the form set to the batches for the
specified recipients.
If a transaction does not meet the first condition, processing continues through the INI
list. Processing stops once the appropriate batch is found.
If a transaction does not meet one of the Batch_Recip_Def criteria, the system places
it in the default batch. If you do not define the DefaultBatch option, an error occurs.
The order in which you list the Batch_Recip_Def options determines how the system
determines recipient batches. Put the most likely batches first. Use All rather than
listing all recipients when appropriate.

Example For this example, assume you have this rule in the AFGJOB.JDT file:
;BatchingByRecipINI;;;
And these INI options:
< BatchingByRecip >
DefaultBatch = default
Batch_Recip_Def = 4,1234567;"BATCH1";INSURED
Batch_Recip_Def = true;"BATCH2";INSURED
Batch_Recip_Def = true;"BATCH5";COMPANY AGENT

The DefaultBatch option tells the system that any output which has not already been
sent to a batch by one of the Batch_Recip_Def options should be placed in the default
batch:
DefaultBatch = default

You must set up the batch name under the Print_Batches control group.
The first Batch_Recip_Def option tells the system to place into BATCH1 any output
which goes to the INSURED recipient and has 1234567 beginning at position 4 in the
extract file:
Batch_Recip_Def = 4,1234567;"BATCH1";INSURED

Batch_Recip_Def = 4, 1234567; “BATCH1”; INSURED

You must set up the recipient

under RECIP_NAMES

You must set up the batch

name under Print_Batches

The data in the extract file you

want the system to search for

The position in the extract file

at which the search begins

The next Batch_Recip_Def option tells the system to place all recipients named
INSURED into BATCH2:

67
Chapter 3
Job and Form Set Rules Reference

Batch_Recip_Def = true;"BATCH2";INSURED

Batch_Recip_Def = true; “BATCH2”; INSURED

You must set up the recipient

under RECIP_NAMES

You must set up the batch

name under Print_Batches

Put all recipients named

INSURED into BATCH2

This Batch_Recip_Def option follows the same syntax as the earlier examples, but
shows how you can use the pipe symbol to place two segments on one line:
Batch_Recip_Def = true;”BATCH”|”5”;COMPANY AGENT

The last Batch_Recip_Def option tells the system to place all recipients named
COMPANY and AGENT into the concatenated name BATCH5.
As shown earlier, you have to specify the batch name under Print_Batches and the
recipient name under RECIP_NAMES.

Your AFGJOB.JDT file looks like this:

<Base Rules>
;RulStandardJobProc;;;
;JobInit1;;;
;BuildMasterFormList;;4;
;BuildExcludeList;;;
…
<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
…

Your extract file looks like this:

RG1001 HEADER CWNGCIS 030201 Roberts J
…
RG1002 HEADER CWNGCIS 030201 Brown T
…
RG1003 HEADER CWNGCIS 030201 Jones M
…
RG1004 HEADER CWNGCIS 030201 Smiths K
…
RG1005 HEADER CWNGCIS 030201 Jones L
…

In this example the system processes all of the transactions except RG1003 and
RG1005. These transactions are excluded because the search mask criteria (35,Jones)
defined in the EXCLUDE.DAT file was found in both transactions.

KeyCount This is a required integer that must be set to 4.

FORM.DAT List the FORM.DAT files you want the system to load. This lets you load
multiple FORM.DAT files and have them appear in memory as if they came
from one large FORM.DAT file.
If you do not specify the FORM.DAT file name, the system looks for the
master resource library settings to find the correct file to load.

Example ;BuildMasterFormList;1;4;
The KeyCount parameter determines the number of items in the FORM.DAT line
considered part of the form set key. The system organizes the form set list based on the
number of items specified by the KeyCount parameter, minus one.
For example, the RPEX1 FORM.DAT file contains as its first two lines:
;SAMPCO;LB1;DEC PAGE;;R;;qsname|...
;SAMPCO;LB1;LETTER;;RD;;qsname|D...

This rule compares the lines to determine if an item is already in the list after finding
the 4th (KeyCount) semicolon in each line and comparing up to the lesser position.
These lines would be compared up to the following point:
;SAMPCO;LB1;DEC PAG;
;SAMPCO;LB1;LETTER;

NOTE: The KeyCount parameter should be one more than the number of keys in the
FORM.DAT file to allow for the leading semicolon. Do not change the KeyCount
parameter unless the library uses a different number of keys.

Example This example produces error messages:

;CheckZeroFontID;;E;

This example produces warning messages:

;CheckZeroFontID;;;

The error or warning message includes information about the form, image, and field:

Message Description

DM30059 <Error> in CheckZeroFontID: zero font ID: form <PXWORKSHT> image

<PXPOLICY> field <ESTFONTID>

DM30059 <Warning> in CheckZeroFontID: zero font ID: form <PXWORKSHT> image

<PXPOLICY> field <TESTFONTID>

Example ;CreateGlbVar;;VARIABLENAME, VARTYPE, VARSIZE;

You can create each global variable as shown below. VARIABLENAME is an arbitrary
name of the variable which will be created, VARTYPE is the type of variable to create,
and VARSIZE is an optional size of the variable to create.
The variable types are:

• SHORT
• LONG
• DOUBLE
• FLOAT
• LONG DOUBLE
• CHAR_ARRAY
• PVOID
The following example creates a character array of 20 bytes named MYCHARARRAY.
Remember that the array should be large enough to include the null terminating
character if it contains strings.
;CreateGLBVar;1;MYCHARARRAY,CHAR_ARRAY,20;

The next example creates a variable named MYLONGVAR that is a LONG:

;CreateGlbVar;1;MYLONGVAR,LONG;
Notice that no size was included so the variable size will be a single long value.

Example Here is an example of how you would use this rule:

/* JDT Rules for One Step Batching By Recipient */
/*
*/
<Base Rules>
;RULStandardJobProc;;;
;SetErrHdr;;***:------------------------------------------------;
;SetErrHdr;;***: Oracle Insurance
;SetErrHdr;;***: Company Name: ***Company***;
;SetErrHdr;;***: Application: ***Application***;
;SetErrHdr;;***: Account #: ***Account_Number***;
;SetErrHdr;;***:------------------------------------------------;
;JobInit1;;;
;CreateGlbVar;;RCBBatchName,CHAR_ARRAY,32;
;InitOvFlw;;;
;SetOvFlwSym;;MTROVF,qaIMTROV,1;
;SetOvFlwSym;;RTEOVF,qaIRTEOV,1;
;Dictionary;;;
;BuildMasterFormList;1;4;
;PageBatchStage1InitTerm;;;
;InitSetrecipCache;;;
;InitPrint;;required to execute gendata/genprint as single step;

Defining Export Options

You use these options in the ImpExpCombined control group to control this rule:
< ImpExpCombined >
File =
Path =
Ext =
AppendedExport =

Option Description

File Enter the name you want to assign to the file. If you omit this name,
the user must specify it.

Path Enter a path to indicate where the file should be written. The default
is the current working directory. If you include the File option and the
file name contains a path, that path overrides this option.

Ext Enter the extension you want to use. The default is DS. If you include
the File option and the file name includes an extension, that
extension overrides this option.

AppendedExport If you enter Yes, the data on the current form set data is appended to
the existing file. The default is No.

Defining the Export Record

You must know the format of the record you intend to export. This includes having a list
of all the fields that comprise the record and the lengths and formats of those fields.
If you omit fields from the ImpExpCombined control group, the export record will
contain the information specified for the Trigger2WIP control group in the order it is
listed. The default layout is a fixed record length. If the fields are omitted from both the
ImpExpCombined and Trigger2WIP control groups, an error occurs.
Surround each field element within the export record with field separators. This helps
input systems parse the field information. The default field separators are quotation
marks (“), as shown here:
WIP = “data”“data”“data”

Fixed or variable record Fixed length records are always the same. In a fixed length record, all field data has a
lengths known (output) size that must be generated. Adding all the field lengths together,
generally equals the fixed record length. (Remember to add two separator strings for
each field to determine the actual length.)
Variable record length output typically means that some or all of the data element will
not adhere to a fixed size.

78
DocumentExport

With variable length records, you often need a marker that identifies where each field
element begins and ends. These elements are typically constant —meaning each field
begins and ends with the same value. This is the purpose of the field separator
mentioned previously. The field separator defaults to a quotation mark (“), but you can
specify any string of up to 39 characters.
Delimiting the fields is often necessary because the importing program needs to
recognize where fields begin and end within the variable record. Although a fixed
length record may not always require field separators, there is no harm caused by
using them.

Listing the field source, Build a table with this information:

length, and format
• Each field that will be contained within each record
• Any length requirements of the field data
• Any special formatting requirements for writing the data to the output record.
With a fixed length record layout, each field has a specific length. In variable length
records, a field may have no specific length requirement or may have a minimum or a
maximum length requirement or both. Note the length requirements for each field.
Finally, note any special formatting requirements for each field. When composing this
information, keep in mind that the manner in which the data is formatted within the
export record may be different that the export record requirement. This would include
information such as the following:

• Should the data be left or right justified in the output?

• For date fields, what format should be used (such as Month/Day/Year or Year/
Month/Day)?
• For numeric data, should values include or not include commas, dollar signs, and
so on?
• Should a decimal number be converted to integers (should 41.1 written as 41)?
• Should integers be written as decimals (41 becomes 41.00)?
• Is there constant or filler data that should be written for a given export record field
that will not be derived from a form set field? For example, you might want to write
a given value into all records for a certain field because the importing program
requires such a value.

Defining the export fields Once you have identified the fields that comprise the export record, you have to define
and formats these fields and the formats required to build the defined record layout.
The record layout for the record must be defined in the INI file, in this control group:
< ImpExpCombined >

For each field that should be exported to the export record line, you must include a line
in the INI file. You may export as many fields as necessary. Each line must begin with
the FIELD= statement and has the following syntax.
FIELD = GVM Fieldname;formatstring

You can omit the GVM Fieldname from any record location that must contain constant
or filler information not derived from the actual export record. See Format Specification
Flags on page 86 for more information.

79
Chapter 3
Job and Form Set Rules Reference

The formatstring is optional. If you include it, be sure to precede it with a semicolon.
Whatever occurs after the semicolon is used to modify the field data in a specific
manner. You can use format string flags to increase or decrease the data to a
predetermined size or convert the data from one value format to another.
If a named export field is not followed by the format string, the format is derived
internally by querying the GVM definition and will yield a constant string length result.

Specifying the format If the output record area for a definition is a filler area — meaning that the output data
is predetermined and not part of the export data — you can omit the field name. If you
omit the field name in this manner, you must specify a format or nothing is written to
the output record.
Constant data is often used to write header or trailer information to variable length
records to help the importing system recognize where the record begins and ends.
Also, you can use this method to write additional characters or data between fields
such as, for example, if you need to include a comma between each field data element
of a variable length record. Here are some examples:
FIELD = Key1;%-3.3s
FIELD = ;,
FIELD = KeyID;%-10.10s

In the first case, the value from Key1 is formatted as three characters in the output data.
This constant text value of a comma is written next, followed by 10 characters from
KeyID. If you assume Key1 contains BOB and KeyID contains 123456789, the result is
as follows:
WIP = “BOB”“,”“123456789 ”
Notice that each field, whether constant or not, contains field separators. Also notice
that the data for KeyID was padded to 10 characters even though the actual value only
contained nine characters.

Converting dates Date format conversions are specified using the D as the first character. The D is
followed by the input format specifier for the data, a semicolon, and the format
specification for output. Here is an example:
FIELD=CREATETIME;DX;D4

This example names the field CREATETIME. The D following the semicolon tells the
system to retrieve this field and convert it from the format defined as X into the output
format, D4. X represents the hexadecimal character format. D4 is a standard
YYYYMMDD format without separators.

Format Flags
If you are familiar with C programming, the data conversions provided with format flags
will be familiar. Essentially, the printf function format definitions for %s, %f, and %d
are supported with some limitations.
Remember that most export record data and other internal data is usually text.
Therefore, to convert to a numerical format of %f or %d, the form set data must be
deformatted internally and then converted into the required format.
The output written to the exported record is formatted as text. Here are some
examples:
FIELD = DESC;%d

80
DocumentExport

FIELD = ORIGUSER;%-32.32s
FIELD = APPDATA;%8.2f
These examples use format flags. The first example retrieves the value of the field
DESC (the description) then converts that value into an integer (losing any decimal
portion it might have had) and outputs it as an integer value. If the data was not a
number, the result is zero (0).
The second example writes exactly 32 characters for the value taken from ORIGUSER.
If the field value does not contain 32 characters, it is padded with spaces. Note also the
use of the dash (-) indicator. This tells the system to left justify the field. If you omit the
dash, the system pads the data with spaces on the left, right justifying it.
The last example demonstrates a floating point output with two decimal places. The
field value is converted into a floating point number. The system then applies the
format you specify and rounds the value if it contained more than two decimal places.

Defining the Export Record Header

The export record header occurs at the beginning of each export record output.
< ImpExpCombined >
WIPHeader = WIP=
Separator = ”

Option Description

WIPHeader Enter the text for the header. You can enter as much text as you like, but
avoid exceeding 1024 characters in the entire export record line. The
default is WIP.

Separator Enter the text value used to separate fields. The default is a quotation
mark (“). If a variable record layout is being used for WIP information,
field separators are essential. You can enter up to 39 characters. Choose
a separator that is not likely to appear in any of the data you intend to
output.

Date Formats
Standard date format You can enter dates in a variety of formats. The date format has three possible
components or characters. The first character specifies the order of the date. The
second character specifies the type of separator character for the date. The third
character specifies the length of the year.

Date order The first character in the date format indicates the order of the date and whether the
month should be numeric or alphabetic. The first character must be a digit from 1 to 9
or an alphabetic character. The default order is format 1. The following table lists your
options:

Format Date order Description

1 MM/DD/YY Month-Day-Year with leading zeros

(02/17/2009)

81
Chapter 3
Job and Form Set Rules Reference

Format Date order Description

2 DD/MM/YY Day-Month-Year with leading zeros

17/02/2009

3 YY/MM/DD Year-Month-Day with leading zeros

2009/02/17

4 Month D, Yr Month name-Day-Year without leading zeros (February 17,

2009)

5 bM/bD/YY Month-Day-Year with leading zeros replaced with spaces

( 2/17/2009)

6 bD/bM/YY Day-Month-Year with leading zeros replaced with spaces

(17/ 2/2009)

7 YY/bM/bD Year-Month-Day with leading zeros replaced with spaces

(2009/ 2/17)

8 M/D/YY Month-Day-Year with leading zeros suppressed

(12/8/2009)

9 D/M/YY Day-Month-Year with leading zeros suppressed

(17/2/2009)

A YY/M/D Year-Month-Day with leading zeros suppressed

(2009/8/9)

B MMDDYY Month-Day-Year with no separators

(02172009)

C DDMMYY Day-Month-Year with no separators

(17022009)

D YYMMDD Year-Month-Day with no separators

(20090217)

E MonDDYY Month name abbreviated-Day-Year with leading zeros

(Feb072009)

F DDMonYY Day-Month name abbreviated-Year with leading zeros

(07Feb2009)

G YYMonDD Year-Month name abbreviated-Day with leading zeros

(2009Feb07)

H day/YY Day of year (counting consecutively from January 1)-Year

(48/2009)

I YY/day Year-Day of Year (counting consecutively from January 1)

(often called the Julian date format) (2009/48)

J D, Month Yr Day- Month name-Year without leading zeros (7, February

2009)

82
DocumentExport

Format Date order Description

K Yr, Month D Year-Month name-Day without leading zeros (2009

January 5)

L Mon-DD-YY Month name abbreviated-Day-Year with leading zeros

(Feb-17-2009)

M DD-Mon-YY Day-Month name abbreviated-Year with leading zeros (02-

Feb-2009)

N YY-Mon-DD Year-Month name abbreviated-Day with leading zeros

(2009-Feb-17)

X XXXXXXXX An eight-character hexadecimal representation

Separators The second character in the date format indicates the separator to use in the date. If
you omit the separator character, the system includes a forward slash (/). You can
choose from these separator characters:

Character Example

/ 02/17/2009

- 02-17-2009

. 02.17.2009

, 02,17,2009

b (blank) 02 17 2009

You specify the separator character by including it as the second character in the date
format. For example, if you enter 5-, you specify date format 5 with a dash as a
separator character. The date appears as 02-17-2009. If you enter 5b, you specify date
format 5 with blanks or spaces as a separator. Your date appears as 02 17 2009.

Year length The third character in the date format specifies the year length. The year must appear
as either two or four digits. Enter 2 for a two digit year or 4 for a four digit year.
You can omit the year length character from a date format. If you do not specify the year
length, the system uses the length of the original entry. For example, if you enter a date
as 10/30/09 and do not specify a length, the system retains 05. If you enter 10/30/
2009, the system retains 2009.
If you enter 5-2, you specify date format 5, a dash (-) as a separator character and a two-
digit year. Your date appears as _9-11-09. If you enter 5-4, your date appears as _9-11-
2009.

83
Chapter 3
Job and Form Set Rules Reference

NOTE: If you do not enter a separator character the year length specification is the
second digit in the date format. For example, if you enter 54, you specify date
format 5 and a four-digit year. Since the separator character is not specified
the default character (/) applies. Your date appears as _9/11/2009.

Avoid two-digit year representations. For example, if you enter 5/2, you specify
date format 5 and a two-digit year. Your date appears as 9/11/09.

Freeform Formats
The format argument consists of one or more codes; each formatting code is preceded
by a percent sign (%). Characters not prefixed with a percent sign copied unchanged to
the output buffer. Any character following a percent sign is not recognized as a valid
format code is copied unchanged to the destination. Therefore, you can enter %% to
include the percent sign in the resulting output string.
You can use these format codes:

Code Description

%d Day of month as decimal number (01 – 31)

%H Hour in 24-hour format (00 – 23)

%I Hour in 12-hour format (01 – 12)

%m Month as decimal number (01 – 12)

%M Minute as decimal number (00 – 59)

%p Current locale's AM/PM indicator for 12-hour clock

%S Second as decimal number (00 – 59)

%y Year without century, as decimal number (00 – 99)

%Y Year with century, as decimal number

%A Weekday name, such as Tuesday

%b Abbreviated month name, such as Mar

%B Full month name, such as March

%j Day of year as decimal number, such as 001–366

%w Weekday as decimal number, such as 1 – 7 with Sunday as 1

%@xxx Specify language locale (Where xxx identifies one of the supported
languages. For example. A format of %@CAD%A might produce mardi, the
French word for Tuesday.)

Here are some examples:

84
DocumentExport

Format Output

%m-%d-%Y 01-01-2009

The year is %Y. The year is 2009.

Born %m/%d/%y at %I:%M %p Born 01/01/09 at 11:57 PM

Additional format An octothorp (#) tells the system to suppress leading zeros for the following format
attributes codes. This flag is recognized on these formats and is ignored on all other format codes
not listed here.
%#d, %#H, %#I, %#j, %#m, %#M, %#S, %#w

For example, if %d outputs 01, using %#d the output will become 1.

NOTE: This flag only affects the format code that specifies it. Any subsequent codes
that are numeric are not affected unless they also specify the flag.

Enter a greater than symbol (>) to uppercase the resulting text. This flag is only
recognized on these format codes:
%>p, %>A, %>b, %>B
For example, if %A results in Tuesday, %>A produces TUESDAY.

NOTE: This flag only affects the format code that specifies it. Any subsequent codes
that have text are not affected unless those also specify the flag.

Enter a less than symbol (<) to lowercase the resulting text. This flag is valid for the
following codes and ignored on all others:
%<p, %<A, %<b, %<B

For example, if %b results in Mar, %<b produces mar.

NOTE: This flag only affects the format code that specifies it. Any subsequent codes
that have text are not affected unless they also specify the flag.

Enter <> to capitalize the first letter of the resulting text. This flag is valid for the
following codes and ignored on all others:
%<>p, %<>A, %<>b, %<>B

For example, if %p results in AM, %<>p produces Am.

NOTE: This flag only affects the format code that specifies it. Any subsequent codes
that have text are not affected unless they also specify the flag.

85
Chapter 3
Job and Form Set Rules Reference

Using Locale Information

When you use the %@xxx in the format string, the xxx represents a code that identifies
one of our supported language locales.
Until a locale format code is encountered in the format string, the default locale
(typically USD which is US English) is in effect. Once a locale format code is found, the
locale specified remains in effect until another locale indicator is encountered.
For example: suppose the input date is 03-01-2009 (USD). This table shows the output
from various formats:

Enter To output

“ %A, %B %d” “Monday, March 01”.

“%@CAD%A %@CAD%A, %B %d” “lundi, mars 01”

“%A, %@CAD%B %d” “Monday, mars 01”

“%@CAD%A, %@USD%B %d” “lundi, March 01”

Format Specification Flags

The format specification, which consists of optional and required fields, is shown here:
%[Flags][Width][.Precision]Type
Each field of the format specification is a character or a number which specifies a
format option. The simplest format specification contains only the percent sign and a
type character, such as: %s. If a percent sign is followed by a character that has no
meaning as a format field, that character is simply copied to the output. For example,
to print a percent sign, enter %%.
The optional fields, which appear before the Type character, control other aspects of
the formatting, as follows:

Type Enter s, f, or d for this export function.

Flags Use these flags to control justification of the output and the printing of signs, blanks,
decimal points, and octal and hexadecimal prefixes. More than one flag can appear in
a format specification.

Flag Description Default

– Left aligns the result within the given field Right align.
width.

+ Prefixes the output value with a sign (+ or –) if Sign appears only for
the output value is of a signed type. negative signed values
(–).

0 Adds zeros until the minimum width is No padding.

reached. If a zero and a minus appear (-0), the
system ignores the zero. If you include a zero
with an integer format (d), the system ignores
the zero flag.

86
DocumentExport

Flag Description Default

blank (' ') Prefixes the output value with a blank if the No blank appears.
output value is signed and positive; the blank
is ignored if both the blank and + flags appear.

# When used with the f format, the # flag forces Decimal point appears
the output value to contain a decimal point in only if digits follow it.
all cases.

Width Here you can control the minimum number of characters printed. If the number of
characters in the output value is less than the width you specify, the system adds
blanks to the left or the right of the values — depending on whether the flag for left
alignment is specified — until the minimum width is reached. If you prefix the width
with a zero (0), the system adds zeros until the minimum width is reached (not useful
for left-aligned numbers).
Your entry for width never causes a value to be truncated. If the number of characters
in the output value is greater than the width you specify, or if you omit the width, all
characters of the value are printed (subject to the .Precision specification).

.Precision This optional number specifies the maximum number of characters printed for all or
part of the output field, or the minimum number of digits printed for integer values.
For format s, the precision specifies the maximum number of characters to print.
Characters in excess of precision are not printed. Characters are printed until a null
character is encountered.
For format f, the precision specifies the number of digits after the decimal point. If a
decimal point appears, at least one digit appears before it. The value is rounded to the
appropriate number of digits. The default precision is six (6); if the precision is zero (0),
or if a period (.) appears without a number following it, no decimal point is printed.
For format d, the precision specifies the minimum number of digits to be printed. If the
number of digits in the argument is less than the precision value, the output value is
padded on the left with zeros. The value is not truncated when the number of digits
exceeds the precision. The default precision is one (1).

CurrentError The error that just occurred.

NextError1 The error caused by the CurrentError failure. This continues through the
list of errors until the last one.

M This tells the system to send the transaction to the manual batch.

Errors Here is a sample set of error messages which would appear if a field error occurred:

Error Description

DM10513 Error in SetAddr(): Empty RuleParms for SetAddr.

DM12051 Error in RPProcessOneField(): Unable to <SETADDR>().

DM12048 Error in RPProcessFields(): Unable to RPProcessOneField(pRPS)

<ADDR3>. Processing will NOT continue for image <q1addr>. See INI
group:< GenDataStopOn > option: FieldErrors.

DM12083 Error in RPProcessOneImage(): Unable to RPProcessFields(pRPS).

DM12074 Error in RPProcessImages(): Unable to RPProcessOneImage(pRPS)

<q1addr>. Skipping the rest of the Images for this form. See INI group:<
GenDataStopOn > option:ImageErrors.

Example Here is an example of the FSISYS.INI file:

< Error2Manual >
10513 = 12051, 12048, 12083, 12074
< GenDataStopOn >
FieldErrors = No

Add this rule to the < Base Rules > section in the AFGJOB.JDT file:
;ErrorHandler;;;

If field error DM10513 occurs, it will cause these errors: DM12051, DM12048, DM1283,
and DM12074. This function sends these transactions to the manual batch for user-
entry, continues processing, and then creates a blank field in the NAFILE.DAT file.

Here is an example of how you can use the Form option:

Form = 1,HEADER 20,8 (Offset,Match Offset,Length)

In the following example, assume you have this INI setting:

< FilterForm >
Form = !/transaction/PrintForm

And this transaction data:

<transaction>
…
<PrintFrom>FormA</PrintForm>
<PrintForm>FormB</PrintForm>
…
</transaction>

Only forms FormA and FormB will remain in the form set after the filtering process is
complete.

Example Here is an example AFGJOB.JDT file:

92
FilterForm

;BatchingByRecipINI;2;;
;FilterForm;2;;
/* Every image in this base uses these rules. */
<Base Image Rules>
;WIPImageProc;;
/* Every field in this base uses these rules. */
<Base Field Rules>
;RULWIPFieldProc;;

Here is an example of how you can use the Recip option:

Recip = 1,HEADER 20,8 (Offset,Match Offset,Length)

Filtering is performed using all data that matches the search criteria. Assume you have
this INI setting:
< FilterRecip >
Recip = !/transaction/PrintRecip
And this transaction data:
<transaction>
…
<PrintRecip>Insured</PrintRecip>
<PrintRecip>Agent</PrintRecip>
…
</transaction>

Only recipients Insured and Agent will remain in the form set after the filtering process
is complete.

Example Here is an example AFGJOB.JDT file:

94
FilterRecip

;WriteNaFile;2;;
;BatchingByRecipINI;2;;
;FilterRecip;2;;
/* Every image in this base uses these rules. */
<Base Image Rules>
;WIPImageProc;;
/* Every field in this base uses these rules. */
<Base Field Rules>
;RULWIPFieldProc;;

Example < Base Image Rules >

;ForceNoImages;;

FormDescTable control group

IncludeKey2 Enter Yes to enable Key2 descriptions. By default, the form

description lines only contain descriptions of the forms.
Optionally, you can include descriptions for form groups, such
as lines of business. These form groups are called Key2s.

BoldKey2 Use this option to present Key2 descriptions in a bold font.

The system determines which font to use by querying the font
defined on the field and selecting its bold equivalent. The
fonts of normal Form Description Lines fields (not assigned a
Key2 name) are changed to their non-bold counterparts.

Key2Prefix Enter the text you want to appear before each Key2
description line. The system automatically adds a single
space after the text. By default, this option is blank and does
not affect the description lines.
For instance, if you enter Form Applicable – the system
prefixes all Key2 descriptions with that text. The output might
look like this:
Form Applicable — General Liability Coverage

Key2PostInc Use this option to add blank lines between Key2 descriptions
the form descriptions. For example, if you include Key2
descriptions, and set this option to one, you out put might
look like this:
Form Applicable – General Liability Coverage

Form 1Automobile Coverage

Form 2Homeowner Coverage

IncludeDuplicateForms If you want the system to include duplicate forms, set this
option to Yes. The system excludes the duplicate forms from
the form description lines as a default.

IncludeFormName Enter No if you want to suppress the form name from the form
description lines. By default, the system includes the form
names.

98
FormDescription

Option Description

StartFromFirstForm Enter Yes if you want the system to include forms starting
from the first form. By default, only forms placed after the first
form that contains a FORM DESC LINE field are included in the
list of forms.
Note that the form that contains the form description lines is
not included in the list unless this option is turned on.

ColumnFormat By default, the system writes out the form description lines in
a columnar format with the form name on the left and pads the
text based on the longest form name. To have the system
write out the form description lines in a non-columnar format,
set this option to No. If set to No, the system adds the form
description to the end of the form name, separated by two
spaces.

ExcludedForm To exclude a certain form from the form description lines,

enter the name of the form you want to exclude. Here is an
example:
ExludedForm = Form Applicable
To exclude multiple forms, include a separate ExcludedForm
option for each form, as shown here:
ExludedForm = Form1
ExludedForm = Form2
ExludedForm = Form3

IncludeFormDesc Set this option to No if you want to suppress the description

from the form description lines. The system includes the form
description by default.
Do not set this option and the IncludeFormName option to No.
If you do, the system writes the form description without the
form name

FormDescription control group

Script The name of DAL script you want the system to execute.

99
Chapter 3
Job and Form Set Rules Reference

Example This example shows how you can call a DAL script to customize the description placed
in the Form Description Line fields. To use this functionality, make sure you have the
Script option set up in the FormDescription control group:
< FormDescription >
Script = AddDate.DAL

Now suppose you want to add (11/03) to the end of each description line. You would set
up the Script option to call the DAL script that contains the logic to do so. Here is an
example of the DAL script:
FName = FormName( )
FDesc = FormDesc( )
return(FName & " " & FDesc & " (11/03)");

Below is an example of the description lines generated without calling DAL script.
DEC PageCommon Policy Declarations
END PageEndorsement Page
CG DECGeneral Liability Declarations

Here is an example of the output when you call the DAL script:
DEC PageCommon Policy Declarations (11/03)
END PageEndorsement Page (11/03)
CG DECGeneral Liability Declarations (11/03)

Example ;GetCo;;17,PMSP0200 125,3;

In this example, the system searches the extract data for the first record that meets the
GetRecord search criteria of having PMSP0200 at offset 17. From this record, the
system extracts three characters at position 125, and uses those characters to look up
the company in the INI file. It is this equivalent value from the INI file that should be
used in files such as the form set definition file, as well as the set recipient table file.
These files are defined in the Data control group with the names FORMDAT and
SETRCPTB respectively. For example, if the three characters at position 125 were ABC,
the associated line in the Key1Table control group would look something like:
< Key1Table >
ABC = THE ABC FRUIT COMPANY

Example ;GetLOB;;17,PMSP0200 100,3;

In this example the system searches the extract data for the first record which meets
the GetRecord search criteria of having PMSP0200 at offset 17. From this record, the
system extracts three characters at position 100, and uses those characters to look up
the line of business in the INI file. It is this value in the FSISYS.INI file which should be
used in files such as the FORM.DAT file, as well as the set recipient table.
These files are defined in the Data control group with the names FORMDAT and
SETRCPTB respectively. For example, if in the FSISYS.INI file the three characters at
position 100 were CFR, the associated line in the Key2Table control group would look
something like:
< Key2Table >
CFR = COMMERCIAL FIRE

User-defined format arguments consist of one or more codes, each preceded

by a percent sign (%). For more information on user-defined format masks, see
Setting Up Format Arguments on page 283.

There is no limit to the length of the mask you create.

On success, msgSUCCESS is returned. If the system encounters a fatal error, msgFAIL

is returned.

Example Here are some examples:

;GetRunDate;;J;

If the system date is 20090217, the date format returned will be 17 February, 2009.
;GetRunDate;;;

If the system date is 20090217, the date format returned will be 20090217.
;GetRunDate;;;

If the system date is 2-17-2009, the date format returned will be 20090217.
;GetRunDate;;J;

If the system date is 2-17-2009, the date format returned will be 17 February, 2009.

The contents of ...is copied into

< Trigger2WIP >
this variable... this variable
Company = Key1
LOB = Key2

Syntax ;GVM2GVM;;ControlGroup;

Parameter Description

ControlGroup Specify the name of the control group in the INI file that defines the
variables.

NOTE: Although this rule was created for use with GenData WIP Transaction
Processing, you can also use it to map a group of GVM variables from one name
to another name.

For GenData WIP Transaction Processing, this rule copies GVM data from the WIP.DBF
file into GVM variables for GenData execution. You define the GVM variables in the
Trigger2WIP control group.
Assume the FSISYS.INI or FSIUSER.INI file has these options:
< Trigger2WIP >
Company = Key1
LOB = Key2

Example Here is an example:

;GVM2GVM;;Trigger2WIP;

This example copies the contents of the Key1 and Key2 GVM variables found in the
WIP.DBF file into the GenData Company and LOB GVM variables.

NOTE: Powertyping takes precedence over all AssignToBatch assignments, and

errors take precedence over powertyping.

WIPFieldProc on page 241

MapFromImportData on page 394
NoOpFunc on page 431
JDT Rules Reference on page 28

108
ImportExtract

ImportExtract
Use this form set level rule (level 2) to import an extract file into GenData that is
comprised of:

• Typical transactions in an extract file which have one or more Documaker

Workstation export files embedded in each transaction. This illustration shows
transactions with embedded export files:

Transaction 1
<record1, field1>, <field 2>, <field 3>, <field4>, <field5>
<record2, field1>, <field 2>, <field 3>, <field4>, <field5>

Export file 1 containing data associated with transaction 1.

Transaction 1 (continued
<record3, field1>, <field 2>, <field 3>, <field4>, <field5>
<record4, field1>, <field 2>, <field 3>, <field4>, <field5>

Transaction 2
<record1, field1>, <field 2>, <field 3>, <field4>, <field5>
<record2, field1>, <field 2>, <field 3>, <field4>, <field5>

Export file 2 containing data associated with transaction 2.

Transaction 2 (continued
<record3, field1>, <field 2>, <field 3>, <field4>, <field5>
<record4, field1>, <field 2>, <field 3>, <field4>, <field5>

• One or more appended Documaker Workstation export files. This illustration

shows an extract file comprised of export files appended to one another:

Export file 1.

Export file 2.

Export file 3.

Export file 4.

Export file 5.

Syntax ;ImportExtract;;;
Although there are no parameters for this rule. Keep in mind:

• Specify the extract file name to be imported via the Data control group using the
ExtrFile option.
• In the Trn_File control group, set MaxExtRecLen option to the length of the longest
record in extract file.
• Only use the SearchMask option in the ExtractKeyField control group; do not use
the Key option.

109
Chapter 3
Job and Form Set Rules Reference

• To create minimum information, such as Key1, Key2, Key ID, and so on, in the
TRNFILE.DAT file for each transaction, you must define for each information item,
the field name, offset, and length in the Trn_Fields control group. This definition
associates the option fields in the Trn_Fields control group to the corresponding
entries in the transaction DFD file (TRNDFDFL.DFD).
• For each field that comprises an image (whose data comes from the export data),
you must create or have a DDT record whose field rule is set to one of the following
field rules
MapFromImportData
NoOpFunc
If you use the NoOpFunc rule for any field rule associated with the export data, you
must insert the ReplaceNoOpFunc rule in the <Base Rules> section of the
AFGJOB.JDT file.

• You must place the ImportExtract rule in the <Base Form Set Rules> section of the
AFGJOB.JDT file after the BuildFormList rule or any custom rule that creates a form
set.
• If the import extract file consists of only Documaker Workstation export files; do
not include the LoadRcpTbl and RunSetRcpTbl or GetCo and GetLOB rules in your
AFGJOB.JDT file.
• If the import extract file is comprised of normal transaction data records plus one
or more embedded Documaker Workstation export files; you must include the
LoadRcpTbl and RunSetRcpTbl or GetCo and GetLOB rules in your AFGJOB.JDT file.

Example Here are some examples which show how this rule works:

Extract file made up of In this example, the extract file is made up of normal transactions with embedded
transactions with export files. This example imports information from an extract file named IMPORT.DAT
embedded export files which is comprised of typical transactions and embedded export files. Using this
information, the system creates GenData files which are input to GenPrint. The
GenPrint program then creates the print output files. Keep in mind:

110
ImportExtract

Here is a sample extract file:

SCO1234567HEADERREC00000030198 SCOM1FP WAT1I1B119990223 804-
345-87…
SCO1234567FRMLSTREC0000010110 SCO FP T1 89999987
041598… SCO1234567PRODNMREC00000David Miller
000666666600000444...
SCO1234567PRODADREC00000100 Main Street, Suite 1200 Miami,
FL 30202…
…
;SAMPCO;LB1;EXPORT FILE # 1;NB;P ;associated w Transaction # 1;
\NA=\;SAMPCO;LB1;LETTER2;
\NA=q1snam\
\NA=q1fl2a\
DATE\October 12, 2000
LESSEE_NAME\Morris Sander
LESSEE_addr\3200 Windy Hill Road
LESSEE_city\Atlanta, GA 30339
\NA=q1b302\
\NA=q1ba36\
\NA=q1ba32\
\NA=q1sal1\
SCO1234567COVERGREC00000SPC 25000 250 Coverage Item 2…
SCO1234567GENRALREC000001 1 3 1 0
Liability1Liability2Liability3Libility4 …
…
;SAMPCO;LB1;EXPORT FILE # 2;NB;P ;associated w Transaction # 1;
\NA=\;SAMPCO;LB1;CHARTS;
\NA=q1cht\
…
SCO999567HEADERREC00000030198 SCOM1FP WAT1I1B119990223 804-
345-87…
SCO9994567FRMLSTREC0000010110 SCO FP T1 89999987
041598…
…

Here is a sample DDT file:

<Image Field Rules Override>
;0;0;Date;0;0;Date;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_Name;0;9;Lessee_Name;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_addr;0;25;Lessee_addr;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_city;0;25;Lessee_city;0;25;; MapFromImportData;;N;N;N;…
Here is a sample AFGJOB.JDT file:
<Base Rules>
…
/* Every form set in this base uses these rules. */
<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportExtract;;;
;LoadRcpTbl;;;
;RunSetRcpTbl;;;
…

111
Chapter 3
Job and Form Set Rules Reference

Here is a sample INI file:

< Data >
ExtrFile = Import.dat
< ExtractKeyField >
SearchMask = 1,SCO
< Trn_Fields >
Key1 = 1,3,N
Key2 = 40,2,N
KeyID = 4,7,N
< Trn_File >
BinaryExt = N
MaxExtRecLen = 120

Extract file made up of In this example, the extract file is made up of one or more appended export files. This
appended export files example imports information from an extract file named IMPORT.DAT which is
comprised of one or more appended export files. Using that information, the system
then creates GenData files which are input to GenPrint. The GenPrint program then
creates the print output files. Keep in mind:

• The ReplaceNoOpFunc rule is required in the AFGJOB.JDT file because one of the
fields in the sample DDT uses the NoOpFunc rule
• The options in the Trn_Fields control group are based on items in the export data
• The LoadRcpTbl and RunSetRcpTbl rules not required
Here is a sample extract file:
;CWNG;CIS;1;NB;Export File # 1 ;;
\NA=\;CWNG;CIS;CWFBILL;
\NA=QAIBANCD\
BANNER CODE\001
BANNER CODE TXT\CWNG Company A
\NA=QAIGRAPH\
ACTUAL GJ 1\Nov
\NA=\;CWNG;CIS;CWFCRD3;
\NA=CWFCRD3\
…
;CWNG;CIS;1;NB;Export File # 2 ;;
\NA=\;CWNG;CIS;CWFBILL;
\NA=QAIBANCD\
BANNER CODE\002
BANNER CODE TXT\CWNG Company B
\NA=QAIGRAPH\
ACTUAL GJ 1\Nov
\NA=\;CWNG;CIS;CWFCRD3;
\NA=CWFCRD3\
…

Here is a sample DDT file:

<Image Field Rules Override>
;0;0;Banner Code;75;3;Banner
Code;0;3;;MapFromImportData;31,ACCTNUM;…
;0;0;Banner Code Txt;0;11;Banner Code Txt;0;11;;noopfunc;31,Banner
Code;…

112
ImportExtract

Here is a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportExtract;;;
…

Here is a sample INI file:

< Data >
ExtrFile = Import.dat
< ExtractKeyField >
SearchMask = 2,CWNG
< Trn_Fields >
Key1 = 2,4,N
Key2 = 7,3,N
KeyID = 16,20,N
< Trn_File >
BinaryExt = N
MaxExtRecLen = 120

SCH = offsetofmask, This indicates the file name is contained in a record of

<searchmask> offsetofdata, the extract file. The offsetofmask is the offset of the
lengthofdata search mask, offsetofdata is the offset where the file
name starts, and lengthofdata is the length of the file
name.

GVM = GlobalVariableName GlobalVariableName defines the GVM that contains the

file name and path information.

The INI and FILE options normally import the same file for each transaction. The SCH
and GVM options let you import a different file for each transaction.
Keep in mind:

• For each field that comprises an image (whose data comes from the combined
standard export file), you must create or have a DDT record with the field rule set
to one of these field rules:
MapFromImportData
NoOpFunc
If you use the NoOpFunc rule for any field rule associated with the standard export
file, you must insert the ReplaceNoOpFunc rule in the <Base Rules> section of the
AFGJOB.JDT file.

• Place the ImportFile rule in the <Base Form Set Rules> section of the AFGJOB.JDT
file after the BuildFormList rule or any custom rule that creates a form set.
• Do not include the LoadRcpTbl, RunSetRcpTbl, GetCo, or GetLOB rules in your
AFGJOB.JDT file.

114
ImportFile

Assume you have the following items defined in your master resource library. Keep in
mind:

• The ReplaceNoOpFunc rule is required in the AFGJOB.JDT file because one of the
fields in the sample DDT uses the NoOpFunc rule.
• Trn_Fields control group options are based on items in the first record of the
combined WIP/NA/POL Export data file.
• The LoadRcpTbl and RunSetRcpTbl or GetCo and GetLOB rules are not required if
this information was assigned from the imported file. It may, however, be
necessary to use other rules, such as the Field2GVM rule, to move data from the
imported form set fields to relevant GVM variables.
Here is a sample import file named IMPORT.DAT file:
;SAMPCO;LB1;EXPORT FILE # 1;NB;P ;;
\NA=\;SAMPCO;LB1;LETTER2;
\NA=q1snam\
\NA=q1fl2a\
DATE\October 12, 2000
LESSEE_NAME\Morris Sander
LESSEE_addr\3200 Windy Hill Road
LESSEE_city\Atlanta, GA 30339
\NA=q1b302\
\NA=q1ba36\
\NA=q1ba32\
\NA=q1sal1\

Here is a sample DDT file:

;0;0;Date;0;0;Date;0;25;; NoOpFunc;;N;N;N;…
;0;0;Lessee_Name;0;9;Lessee_Name;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_addr;0;25;Lessee_addr;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_city;0;25;Lessee_city;0;25;; MapFromImportData;;N;N;N;…

Here are sample INI settings:

< TRN_Fields >
Key1 = 2,6,N
Key2 = 32,2,N
KeyID = 13,18,N
< TRN_File >
BinaryExt = N
MaxExtRecLen= 120
< ExtractKeyField >
SearchMask = 2,SAMPCO
< Data >
ExtrFile = xxxxx (see the import file example above)

115
Chapter 3
Job and Form Set Rules Reference

Example The following examples illustrate the different ways you can define the import file
when you use this rule.

Using the File option This example imports information from a file named IMPORT.DAT in the \import
directory and uses that information to create the GenData files which the GenPrint
program uses to create the print output files.
Here is an excerpt from a sample AFGJOB.JDT file:
<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportFile;;File=.\Import\Import.dat;
…

Using the INI option This example imports information based on the Import_File option in the Import_Data
control group. Using this information, the GenData program creates the files the
GenPrint program uses to create the print output files.
Here are the sample INI settings:
< Import_Data >
Import_File = .\Import\Import.dat\

Here is an excerpt from a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportFile;;INI=Import_Data,Import_File;
…

116
ImportFile

Using the SCH option This example imports multiple Documaker Workstation export files based on the
content of a line in the extract file. Using this information, the GenData program creates
the files the GenPrint program uses to create the print output files.
Here is an excerpt from a sample extract file named EXTRFILE.DAT:
;CWNG;CIS;1;NB;W ;; TXT .\Import\impt1file.dat
;CWNG;CIS;1;NB;W ;; TXT .\Import\impt2file.dat
…

For this example, use these INI options:

< Data >
ExtrFile= extrfile.dat
< TRN_Fields >
Key1 = 2,4,N
Key2 = 7,3,N
KeyID = 35,22,N
< ExtractKeyField >
SearchMask= 2,CWNG

Here is an excerpt from a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportFile;2;SCH=30,TXT 35,21;
…

117
Chapter 3
Job and Form Set Rules Reference

Using the GVM option This example imports data from an import file based on a GVM variable called
Import_File. Using this information, the GenData program creates the files the GenPrint
program uses to create the print output files. Any valid GVM variable can be used no
matter how it is created or assigned.
Here is an excerpt from a sample AFGJOB.JDT file:
<Base Rules>
....
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportFile;;GVM=Import_File;
…

WIP/NA/POL export file containing data associated with transaction 1.

Transaction 1 (continued
<record3, field1>, <field 2>, <field 3>, <field4>, <field5>
<record4, field1>, <field 2>, <field 3>, <field4>, <field5>

Transaction 2
<record1, field1>, <field 2>, <field 3>, <field4>, <field5>
<record2, field1>, <field 2>, <field 3>, <field4>, <field5>

WIP/NA/POL export file containing data associated with transaction 2.

Transaction 2 (continued
<record3, field1>, <field 2>, <field 3>, <field4>, <field5>
<record4, field1>, <field 2>, <field 3>, <field4>, <field5>

One or more appended WIP/NA/POL export data files from Documaker Workstation.
This illustration shows an extract file comprised of WIP/NA/POL files appended to one
another:

WIP/NA/POL export file 1

WIP/NA/POL export file 2

WIP/NA/POL export file 3

WIP/NA/POL export file 4

WIP/NA/POL export file 5

Syntax ;ImportNAPOLExtract;;;
Although there are no parameters for this rule. Keep in mind:

• Specify the extract file name, which contains the import information for each
transaction, in the ExtrFile option of the Data control group. This is the normal way
to define the name of the extract file.
• Only use the SearchMask option in the ExtractKeyField control group; do not use
the Key option.

119
Chapter 3
Job and Form Set Rules Reference

• For each field that comprises an image (whose data comes from the combined
WIP/NA/POL export data), you must create or have a DDT record whose field rule
is set to one of the following field rules
MapFromImportData
NoOpFunc
If you use the NoOpFunc rule for any field rule associated with the WIP/NA/POL
export data, you must insert the ReplaceNoOpFunc rule in the <Base Rules>
section of the AFGJOB.JDT file.

• You must place the ImportNAPOLExtract rule in the <Base Form Set Rules> section
of the AFGJOB.JDT file after the BuildFormList rule or any custom rule that creates
a form set.
• If the import extract file is comprised of normal transaction data records plus one
or more embedded Documaker Workstation combined WIP/NA/POL export files;
you can include the LoadRcpTbl and RunSetRcpTbl or GetCo and GetLOB rules in
your AFGJOB.JDT file. You may need to use other rules, like Field2GVM, to move
data from the imported form set fields to relevant GVM variables.
• To process without using DDT files, substitute the ForceNoImages rule for the
RULStandardImageProc rule.

Example Here are some examples which show how this rule works:

Extract file made up of In this example, the extract file is made up of normal transactions with embedded WIP/
transactions with NA/POL export files. This example imports information from an extract file named
embedded WIP/NA/POL IMPORT.DAT which is comprised of transactions with embedded WIP/NA/POL export
files files. Using this information, the system creates standard GenData files which are input
to the GenPrint program. The GenPrint program then creates the print output files.
Keep in mind:

• The ReplaceNoOpFunc rule is not required in the AFGJOB.JDT file because no fields
in the sample DDT file use the NoOpFunc rule
• The options in the Trn_Fields control group are based on items in the first record
of the typical transaction data
• The LoadRcpTbl and RunSetRcpTbl rules are required to load and run the recipient
table
Here is a sample extract file:
SCO1234567HEADERREC00000030198 SCOM1FP WAT1I1B119990223 804-
345-87…
SCO1234567FRMLSTREC0000010110 SCO FP T1 89999987
041598… SCO1234567PRODNMREC00000David Miller
000666666600000444...
SCO1234567PRODADREC00000100 Main Street, Suite 1200 Miami,
FL 30202…
…
WIP="SAMPCO ""LB1 ""NAPOL FILE # 1 ""NB ""P" associated w
Transaction # 1"
;SAMPCO;LB1;LETTER2;Second Letter;RD;;q1snam|D3<Insured>/
q1fl2a|D3S<Insured>/q1b302|D3S<Insured>/q1ba36…;
\ENDDOCSET\
\NA=q1snam,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=0,PA=1,OPT=D3\
\ENDIMAGE\

120
ImportNAPOLExtract

\NA=q1fl2a,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=3360,PA=1,OPT=D3S\
FDate;235;3913;12012;;;\January 1, 2000
FLessee_NAME;235;4806;12012;G;;\Morris Sander
FLessee_addr;235;5212;12012;G;;\3200 Windy Hill Road
FLessee_city;235;5636;12012;G;;\Atlanta, GA 30339
\ENDIMAGE\
…
\ENDFORM\
\ENDDOCSET\
SCO1234567COVERGREC00000SPC 25000 250 Coverage Item 2…
SCO1234567GENRALREC000001 1 3 1 0
Liability1Liability2Liability3Libility4 …
…
WIP="SAMPCO ""LB1 ""NAPOL FILE # 2 ""NB ""P" associated w
Transaction # 1"
;SAMPCO;LB1;CHARTS;Form q1cht;RD;;q1cht|D5<Insured>;
\ENDDOCSET\
\NA=q1cht,LN=1,DUP=OFF,SIZE=L,TRAY=U,X=0,Y=0,PA=1,OPT=D5\
FFORMSET PAGE NUM;17656;25740;16008;PF;;\
FFORMSET PAGE NUM OF;18408;25740;16008;PF;;\
\ENDFORM\
\ENDDOCSET\
…
SCO999567HEADERREC00000030198 SCOM1FP WAT1I1B119990223 804-
345-87…
SCO9994567FRMLSTREC0000010110 SCO FP T1 89999987
041598…
…

Here is a sample DDT file:

Here is a sample AFGJOB.JDT file:

<Base Rules>
…
/* Every form set in this base uses these rules. */
<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLExtract;;;
;LoadRcpTbl;;;
;RunSetRcpTbl;;;
…

Here is a sample INI file:

< Data >
ExtrFile = Import.dat
< ExtractKeyField >
SearchMask = 1,SCO
< Trn_Fields >
Key1 = 1,3,N

121
Chapter 3
Job and Form Set Rules Reference

Key2 = 40,2,N
KeyID = 4,7,N
< Trn_File >
BinaryExt = N
MaxExtRecLen= 120

Extract file made up of In this example, the extract file is made up of one or more appended WIP/NA/POL
appended WIP/NA/POL export files. This example imports information from an extract file named IMPORT.DAT
files which is comprised of one or more appended WIP/NA/POL export data files. Using that
information, the system then creates GenData files which are input to GenPrint. The
GenPrint program then creates the print output files. Keep in mind:

• The ReplaceNoOpFunc rule is required in the AFGJOB.JDT file because one of the
fields in the sample DDT file uses the NoOpFunc rule
• The options in the Trn_Fields control group are based on items in the first record
of the WIP/NA/POL export file
• The LoadRcpTbl and RunSetRcpTbl rules not required
Here is a sample extract file:
WIP="SAMPCO ""LB1 ""NAPOL FILE # 1 ""NB ""P"
;SAMPCO;LB1;LETTER2;Second Letter;RD;;q1snam|D3<Insured>/
q1fl2a|D3S<Insured>/q1b302|D3S<Insured>/q1ba36…;
\ENDDOCSET\
\NA=q1snam,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=0,PA=1,OPT=D3\
\ENDIMAGE\
\NA=q1fl2a,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=3360,PA=1,OPT=D3S\
FDate;235;3913;12012;;;\January 1, 2000
FLessee_NAME;235;4806;12012;G;;\Morris Sander
FLessee_addr;235;5212;12012;G;;\3200 Windy Hill Road
FLessee_city;235;5636;12012;G;;\Atlanta, GA 30339
\ENDIMAGE\
…
\ENDFORM\
\ENDDOCSET\
WIP="SAMPCO ""LB1 ""NAPOL FILE # 2 ""NB ""P"
;SAMPCO;LB1;CHARTS;Form q1cht;RD;;q1cht|D5<Insured>;
\ENDDOCSET\
\NA=q1cht,LN=1,DUP=OFF,SIZE=L,TRAY=U,X=0,Y=0,PA=1,OPT=D5\
FFORMSET PAGE NUM;17656;25740;16008;PF;;\
FFORMSET PAGE NUM OF;18408;25740;16008;PF;;\
\ENDFORM\
\ENDDOCSET\

Here is a sample DDT file:

<Image Field Rules Override>
;0;0;Date;0;0;Date;0;25;; NoOpFunce;;N;N;N;…
;0;0;Lessee_Name;0;9;Lessee_Name;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_addr;0;25;Lessee_addr;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_city;0;25;Lessee_city;0;25;; MapFromImportData;;N;N;N;…

Here is a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

122
ImportNAPOLExtract

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLExtract;;;
…

Here is a sample INI file:

< Data >
ExtrFile = Import.dat
< ExtractKeyField >
SearchMask = 1,WIP
< Trn_Fields >
Key1 = 1,3,N
Key2 = 6,6,N
KeyID = 26,20,N
< Trn_File >
BinaryExt = N
MaxExtRecLen= 120

SCH = offsetofmask, This indicates the file name is contained in a record of

GVM = GlobalVariableName GlobalVariableName defines the GVM that contains the

file name and path information.

The INI and FILE options normally import the same file for each transaction. The SCH
and GVM options let you import a different file for each transaction.
Keep in mind:

• For each field that comprises an image (whose data comes from the combined
WIP/NA/POL export data), you must create or have a DDT record with the field rule
set to one of these field rules:
MapFromImportData
NoOpFunc
If you use the NoOpFunc rule for any field rule associated with the combined WIP/
NA/POL export data, you must insert the ReplaceNoOpFunc rule in the <Base
Rules> section of the AFGJOB.JDT file.

• Place the ImportNAPOLFile rule in the <Base Form Set Rules> section of the
AFGJOB.JDT after the BuildFormList rule or any custom rule that creates a form set.
• The LoadRcpTbl and RunSetRcpTbl or GetCo and GetLOB rules are not required
unless you use the SCH option.
Assume you have the following items defined in your master resource library. Keep in
mind:

• The ReplaceNoOpFunc rule is required in the AFGJOB.JDT file because one of the
fields in the sample DDT uses the NoOpFunc rule.

124
ImportNAPOLFile

• Trn_Fields control group options are based on items in the first record of the
combined WIP/NA/POL Export data file.
Here is a sample combined WIP/NA/POL import file named IMPORT.DAT:
WIP="SAMPCO ""LB1 ""NAPOL FILE # 1 ""NB ""P"
;SAMPCO;LB1;LETTER2;Second Letter;RD;;q1snam|D3<Insured>/
q1fl2a|D3S<Insured>/q1b302|D3S<Insured>/q1ba36…;
\ENDDOCSET\
\NA=q1snam,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=0,PA=1,OPT=D3\
\ENDIMAGE\
\NA=q1fl2a,LN=1,DUP=OFF,SIZE=C,TRAY=U,X=0,Y=3360,PA=1,OPT=D3S\
FDate;235;3913;12012;;;\January 1, 2000
FLessee_NAME;235;4806;12012;G;;\Morris Sander
FLessee_addr;235;5212;12012;G;;\3200 Windy Hill Road
FLessee_city;235;5636;12012;G;;\Atlanta, GA 30339
\ENDIMAGE\
…
\ENDFORM\
\ENDDOCSET\

Here is a sample DDT file:

<Image Field Rules Override>
;0;0;Date;0;0;Date;0;25;; NoOpFunc;;N;N;N;…
;0;0;Lessee_Name;0;9;Lessee_Name;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_addr;0;25;Lessee_addr;0;25;; MapFromImportData;;N;N;N;…
;0;0;Lessee_city;0;25;Lessee_city;0;25;; MapFromImportData;;N;N;N;…
Here are sample INI settings:
< TRN_Fields >
Key1 = 1,3,N
Key2 = 6,6,N
KeyID = 26,20,N
< TRN_File >
BinaryExt = N
MaxExtRecLen= 120
<ExtractKeyField>
SearchMask = 1,WIP=
< Data >
ExtrFile = xxxxx

125
Chapter 3
Job and Form Set Rules Reference

Example The following examples illustrate the different ways you can define the import file
when you use this rule.

Using the File option This example imports information from the IMPORT1.DAT file in the \import directory
and uses that information to create the GenData files which the GenPrint program uses
to create the print output files.
Here is an excerpt from a sample AFGJOB.JDT file:
<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLFile;;File=.\Import\Import1.dat;
…

Here is an excerpt from a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLFile;;INI=Import_Data,Import_File;
…

126
ImportNAPOLFile

Using the SCH option This example imports multiple WIP/NA/POL export files based on the content of a line
in the extract file. Using this information, the GenData program creates the files the
GenPrint program uses to create the print output files.
Here is an excerpt from a sample extract file named EXTRFILE.DAT:
;CWNG;CIS;1;NB;W ;; TXT .\Import\impt1file.dat
;CWNG;CIS;1;NB;W ;; TXT .\Import\impt2file.dat
…

For this example, use these INI options:

< Data >
ExtrFile= extrfile.dat
< TRN_Fields >
Key1 = 2,4,N
Key2 = 7,3,N
KeyID = 35,22,N
< ExtractKeyField >
SearchMask = 2,CWNG

Here is an excerpt from a sample AFGJOB.JDT file:

<Base Rules>
…
;ReplaceNoOpFunc;;;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLFile;2;SCH=30,TXT 35,22;

/* Every form set in this base uses these rules. */

<Base Form Set Rules>
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLFile;;GVM=Import_File;

KeyID = TransactionID, Opt

Example Assume you have the following items defined in your master resource library. See XML
File Format on page 137 for an example of an import file in the standard XML file format.
Here is an example of the INI options you need in your FSISYS.INI file:
< Data >
AFGJOBFile = .\deflib\afgjob.jdt
ExtrFile = .\extract\extrfile.xml
< ExtractKeyField >
SearchMask = 1,<?xml
< Key1Table >
XML = XML
< Key2Table >
XML = XML
< KeyIDTable >
XML = XML
< Trigger2Archive >
Key1 = Key1
Key2 = Key2
KeyID = KeyID
RunDate = RunDate
< TRN_Fields >
Key1 = 3,3,N
Key2 = 3,3,N
KeyID = 3,3,N
< TRN_File >
BinaryExt = N
MaxExtRecLen= 175
< XMLTags2GVM >
Key1 = Key1,Req
Key2 = Key2,Req
KeyID = TransactionID,Opt

Here is an excerpt from a sample AFGJOB.JDT file:

< Base Rules >
;RULStandardJobProc;;;
…
< Base Form Set Rules >
;NoGenTrnTransactionProc;;;
;BuildFormList;;;
;ImportXMLExtract;;;
…
…

FILE Enter the name and path of the import file.

INI Enter the INI control group and option in which the import file is defined.
Separate the control group and option with a comma.

SCH Enter the search criteria and the file name data, separated by a space.
The name of the file, including its path, that you want to import should be
contained in the record in the file indicated by the ExtrFile option in the Data
control group.
The search criteria are one or more comma delimited data pairs, offsets and
character string, used as the search mask for finding the record in the
specified file.
The file name data is a comma delimited data pair that defines the offset and
length of the file name in the record defined by the search criteria parameter.

GVM Enter the global variable name (GVM) that contains the file name and path
information.

Keep in mind:

• Create a simplified AFGJOB.JDT file when you use this rule. For instance, omit these
rules:
LoadRcpTbl
LoadExtractData
RunSetRcpTbl
CreateGlbVar
LoadDDTDefs

132
ImportXMLFile

InitOvFlw
SetOvFlwSym
ResetOvFlw
• Use the NoGenTrnTransactionProc rule because the XML file has no transaction
information on the first line.
• Place the ImportXMLExtract rule in the <Base Form Set Rules> section of the
AFGJOB.JDT file after the BuildFormList rule or any custom rule that creates a form
set.
• In the TRN_File control group, set MaxExtRecLen option to the length of the
longest record in the import file.
• In the TRN_Fields control group, include only the Key1, Key2, and KeyID options.
Set these options to dummy data, because the GVM variables are set to the data
values in the XMLTags2GVM control group during processing.
• If you load an XML or a V2 import file as the extract file, it must conform to the
extract file rules. This means that you must set the MaxExtRecLen and BinaryExt
INI options appropriately.
• Define the XMLTags2GVM control group in your FSISYS.INI file as shown here:
< XMLTags2GVM >
GVM = XMLTag, (Req/Opt)

Where GVM is the name of the GVM variable and XMLTag is the tag name in the
XML file. Include Req or Opt to specify whether it is required or optional. If it is
required and is not present in the XML file, processing will terminate. Here is an
example:
< XMLTags2GVM >
Key1 = Key1, Req
Key2 = Key2, Req
KeyID = TransactionID, Opt

Example These examples show the different ways you can define the import file when you use
this rule. Assume you have the following items defined in your master resource library.
For an example of the standard XML file format, see XML File Format on page 137.
Here are sample INI settings in your FSISYS.INI file:
< Data >
AFGJOBFile = .\deflib\afgjob.jdt
ExtrFile = .\extract\dummy.dat
< ExtractKeyField >
SearchMask = 1,XML_FILE_NAME
< Key1Table >
XML = xml
< Key2Table >
XML = xml
< KeyIDTable >
XML = xml
< Trigger2Archive >
Key1 = Key1
Key2 = Key2
KeyID = KeyID

133
Chapter 3
Job and Form Set Rules Reference

RunDate = RunDate
< TRN_Fields >
Key1 = 1,3,N
Key2 = 5,5,N
KeyID = 10,4,N
< TRN_File >
BinaryExt = N
MaxExtRecLen = 175
< XMLTags2GVM >
Key1 = Key1,Req
Key2 = Key2,Req
KeyID = TransactionID,Opt

Here is a sample of the DUMMY.DAT file, pointed to by the ExtrFile option in the Data
control group in your FSISYS.INI file.
0 1
1 5
XML_FILE_NAME This is a dummy extract file.

Using the TF Option

Use the TF (Truncate Field) option to truncate fields to their FAP defined field length.
Make sure you specify this parameter before FILE option. Here are some examples:
This example will truncate the fields lengths:
;ImportXMLFile;;TF,SCH=1,XML_FILE_NAME 15,55;
These examples truncate fields and suppress pagination:
;ImportXMLFile;;SP,TF,SCH=1,XML_FILE_NAME 15,55;
;ImportXMLFile;;TF,SP,SCH=1,XML_FILE_NAME 15,55;

This example does not truncate fields or suppress pagination:

;ImportXMLFile;;SP

NOTE: No formatting is allowed on the multi-line text field when you include the TF
option.

Using the File Option

This example imports the F_FILE.XML file from the \export directory. Using this file, the
GenData program creates the recipient batch, NA, POL, and NewTrn files needed for
GenPrint and GenArc processing.
Here is an excerpt from a sample AFGJOB.JDT file using the File option:
< Base Rules >
;RULStandardJobProc;;;
…
< Base Form Set Rules >
;NoGenTrnTransactionProc;;;
;BuildFormList;;;
;ImportXMLFile;;File=.\Export\F_File.xml;
…

134
ImportXMLFile

Using the INI Option

This example imports the F_INI.XML file from the \export directory. Using this file, the
GenData program creates the recipient batch, NA, POL, and NewTrn files needed for
GenPrint and GenArc processing.
In addition to the INI options defined previously, you must also include the this option:
< Import_Data >
Import_File = .\Export\F_File.xml\

Here is an excerpt from a sample AFGJOB.JDT file:

< Base Rules >
;RULStandardJobProc;;;
…
< Base Form Set Rules >
;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;ImportNAPOLFile;;INI=Import_Data,Import_File;
…

Using the SCH Option

This example imports XML files (F_SCH1.XML, F_SCH2.XML, and F_SCH3.XML) based
on the content of a line in the file pointed to by the ExtrFile option in the Data control
group. Using these files, the GenData program creates the recipient batch, NA, POL,
and NewTrn files needed for GenPrint and GenArc processing.
This INI option differs from the one defined in the assumed MRL definition:
< Data >
ExtrFile = .\extract\F_Sch.DAT
Here is an excerpt from the F_SCH.DAT file in the \extract directory which contains an
entry (path and file name) for each XML file to import:
XML_FILE_NAME .\export\F_SCH1.xml
XML_FILE_NAME .\export\F_SCH2.xml
XML_FILE_NAME .\export\F_SCH3.xml
…

NOTE: This option lets you import and process multiple XML files because of the way
the file name and path are specified—one file per entry in the file specified in
the ExtrFile option in the Data control group.

Here is an excerpt from a sample AFGJOB.JDT file:

< Base Rules >
;RULStandardJobProc;;;
…
< Base Form Set Rules >
;NoGenTrnTransactionProc;;;
;BuildFormList;;;
;ImportXMLFile;2;SCH=1,XML_FILE_Name 15,19
…

135
Chapter 3
Job and Form Set Rules Reference

Using the GVM Option

This example imports data from a XML file based on file name contained in the GVM
variable called Import_File. Using this file, the GenData program creates the recipient
batch, NA, POL, and NewTrn files needed for GenPrint and GenArc processing.
Any valid GVM variable can be used no matter how it is created or assigned.
This example creates the GVM variable, ImportXMLFile_GVM, by including this INI
option and adding its definition to the TRNDFDFL.DFD file:
< GentrnDummyFields >
ImportXMLFile_GVM = .\export\F_GVM.xml

Here is an excerpt from a sample AFGJOB.JDT file:

< Base Rules >
;RULStandardJobProc;;;
…
< Base Form Set Rules >
;NoGenTrnTransactionProc;;;
;BuildFormList;;;
;ImportXMLFile;;GVM=ImportXMLFile_GVM;

136
ImportXMLFile

XML FILE FORMAT

Here is an example of the format of the XML file the system creates:

<?xml version="1.0" encoding="UTF-8"?>

<DOCUMENT TYPE="RPWIP" VERSION="10.2">
<DOCSET NAME="">
<FIELD NAME="POLICY NBR">P1234-1</FIELD>
<FIELD NAME="RENEWAL NBR">1234-2</FIELD>
<FIELD NAME="AGENT'S NBR">6789</FIELD> Form set
<FIELD NAME="EFFECT DATE">10/1/02</FIELD> global data
<FIELD NAME="EXPIRE DATE">10/1/03</FIELD>
<FIELD NAME="INSURED NAME">John A. Doe</FIELD>
<FIELD NAME="ADDR1">2345 Anystreet</FIELD>
<FIELD NAME="CITY">Anytown</FIELD>
<FIELD NAME="STATE">GA</FIELD>
<FIELD NAME="ZIP CODE">30339</FIELD>
Group <FIELD NAME="BUSINESS DESC1">Business</FIELD>
<FIELD NAME="BUSINESS DESC2">Personal</FIELD>
<FIELD NAME="BUSINESS DESC3">Property</FIELD>
<FIELD NAME="DATE">09/27/02</FIELD>
Form global <GROUP NAME="" NAME1="DOCUCORP PACKAGE" Form
fields NAME2="PROFESSIONAL INSURANCE">
<FORM NAME="Professional Dec">
<DESCRIPTION>Professional Declarations
</DESCRIPTION>
<FIELD NAME="FORM LINE1">Form Letter</FIELD>
<RECIPIENT NAME="AGENT" COPYCOUNT="1"/> Recipient
Page
<RECIPIENT NAME="HOME OFFICE" COPYCOUNT="1"/> information
<RECIPIENT NAME="INSURED" COPYCOUNT="1"/>
<SHEET>
<PAGE>
Multi-page form <SECTION NAME="profdec"/>
</PAGE>
</SHEET>
</FORM>
<FORM NAME="Form Letter">
<DESCRIPTION>Form Letter</DESCRIPTION>
Multi-page image <RECIPIENT NAME="AGENT" COPYCOUNT="1"/>
Image local
<RECIPIENT NAME="HOME OFFICE" COPYCOUNT="1"/> fields
<RECIPIENT NAME="INSURED" COPYCOUNT="1"/>
<SHEET>
<PAGE>
<SECTION NAME="let~tbl">
<FIELD NAME="Coverage">Automobile</FIELD>
<FIELD NAME="Extra">
<P><FONT SIZE="12"
Multi-line field FACE="Univers ATT" COLOR="#FF0000">Text in
multiline variable field.</FONT>
</P>
</FIELD>
</SECTION>
</PAGE>

137
Chapter 3
Job and Form Set Rules Reference

<PAGE>
<SECTION NAME="let~tbl">
<DAPINSTANCE VALUE="2"/>
Indicates a
<DAPOPTIONS VALUE="M"/>
second page
</SECTION>
</PAGE>
</SHEET>
</FORM>
</GROUP>
</DOCSET>
</DOCUMENT>

Keep in mind...

• DAPOPTIONS should have a value of M for multi-page FAP images. There are other
FAP image options, but only M is applicable in XML.
Use DAPINSTANCE to provide a page number for multi-page FAP images. If the
image does not span multiple pages, omit the DAPINSTANCE value.

• When you have multiple XML transactions within a single file, separate each
transaction with a line feed. This is a requirement of Documaker software, not the
XML parser.
• Although you do not have to include line feeds inside the XML for a transaction, we
suggest you add a line feed after each element tag. This makes it easier to read the
file and helps in debugging your XML. A message like
Line 255, column 8, syntax is incorrect

is easier to diagnose than

Line 1, column 156780, syntax is incorrect.

Example Here is an example:

< Base Rules >
;InitArchive;1;;

Example Here is an example:

;InlineImagesAndBitmaps;;;
This rule must be placed (run) before the NAFILE.DAT and POLFILE.DAT files are
unloaded and after the pagination rules. Here are some examples of how you would set
up your AFGJOB.JDT file:

For single-step execution <Base Form Set Rules>

;NoGenTrnTransactionProc;;;
;ResetOvFlw;;;
;BuildFormList;;;
;LoadRcpTbl;;;
;RunSetRcpTbl;;;
;PrintFormset;;;
;WriteOutput;;;
;WriteNaFile;;;
;InlineImagesAndBitmaps;;;
;BatchingByRecipINI;;;
;PaginateAndPropagate;;;

For multi-step execution <Base Form Set Rules>

;RULStandardTransactionProc;;;
;LoadExtractData;;;
;ResetOvFlw;2;;
;IfRecipUsed;;BATCH1=INSURED;
;BuildFormList;;;
;LoadRcpTbl;;;
;RunSetRcpTbl;;;
;UpdatePOLFile;;;
;InlineImagesAndBitmaps;;;

Example <Base Form Set Rules>

;RULStandardTransactionProc;;;
;LoadExtractData;;;
;ResetOvFlw;;;
;IfRecipUsed;;BATCH1=INSURED;
;IfRecipUsed;;BATCH2=COMPANY;
;IfRecipUsed;;BATCH3=AGENT;
;BuildFormList;;;
;LoadRcpTbl;;;
;UpdatePOLFile;;;
;RunSetRcpTbl;;;
;ProcessQueue;;PostPaginationQueue

Example Here is an example AFGJOB.JDT file:

/* JDT Rules for Single-Step Processing Batching By Recipient. */
<Base Rules>
;RULStandardJobProc;1;Always the first job level rule;
;JobInit1;1;;
;InitPrint;1;required to execute gendata/genprint in single step;
/* Every form set in this base uses these rules. */
<Base Form Set Rules>
;NoGenTrnTransactionProc;2;;
;LoadFormsetFromArchive;2;;
;PrintFormset;2;;
;WriteOutput;2;;
;WriteNaFile;2;;
;BatchingByRecipINI;2;;
/* Every image in this base uses these rules. */
<Base Image Rules>
;WIPImageProc;;
/* Every field in this base uses these rules. */
<Base Field Rules>
;RULWIPFieldProc;;

COMMENT_CHARACTER A single character which indicates the comment character.

Lines beginning with this character are not loaded into the
link list.

Example ;LoadListFromTable;;POLTYPES FORM_SCHED_POL_TYPE *;

If your FSISYS.INI file has these settings:
< Data >
TablesPath = ..\MSTRRES\TABLES\
Form_Sched_POL_Type= POLTYPE.TBL

The LoadListFromTable rule loads the POLTYPE.TBL file into a list whose handle is
stored in a GVM variable named POLTYPES. Any line in the file that starts with an
asterisk (*) is omitted from the list.

Syntax ;MergeRecipsFromForm;;FormName, Z flag;

Parameter Description

FormName The name of the form from which the recipient names are copied. The
other forms in that form set are assigned these recipients, if they're not
already there.
The form name you specify can occur multiple times in the form set and
the unique recipient names from all copies are assigned to the
remaining forms in the form set.

Z flag If you want the system to copy recipients with a zero copy count, enter
the character Z (or z). The default is blank.

Example ;MergeRecipsFromForm;;Mailer Form;

Assume that before processing, the recipients for this form set are set up as follows:

• Standard Form A - RECIPS=(Home Office)

• Standard Form B - RECIPS=(Home Office)
• Mailer Form - RECIPS=(Home Office, Agent 1)
After using this rule to process the form set, the recipients for each form are now set to:

• Standard Form A - RECIPS=(Home Office, Agent 1)

• Standard Form B - RECIPS=(Home Office, Agent 1)
• Mailer Form - RECIPS=(Home Office, Agent 1)

NOTE: If you want the system to copy recipients with a zero copy count, use the Z flag
(it’s not case sensitive). Here is an example:

;MergeRecipsFromForm;2;FormName,Z;.
The system ignores that recipient and does not copy it to the other forms in the
form set if the copy count is set to zero for a recipient and the Z flag is omitted.

• WIPTransactions – This rule replaces the RULStandardTransactionProc or

NoGenTrnTransactionProc rules in the AFGJOB.JDT file. This rule starts GenData
WIP Transaction Processing at the form set level. It also identifies the status codes
for the transactions in the WIP file that are processed. The status codes can be a
subset or all of the status codes identified on the MergeWIP rule or none.
• GVM2GVM - This rule copies GenData execution data from the Trigger2WIP INI
control group.
• WIPImageProc – This rule replaces the RULStandardImageProc or
StandardImageProc rule.
• WIPFieldProc – This rule replaces the RULStandardFieldProc or StandardFieldProc
rule.
Using these rules in a simplified AFGJOB.JDT file and with appropriate INI files, GenData
WIP Transaction Processing adds the transactions from a WIP file to a transaction
memory list. It then processes the transactions from the memory list, appending the
data from the WIP file to the MRL recipient batch, NewTrn, NA, and POL files. If these
files do no exist, it creates them. Each transaction in the memory list is deleted from
the WIP file after it is processed.

NOTE: If you are using the MergeWIP rule with the BatchingByRecipINI rule, be sure
to use the =DAL and =GVM operators. For more information, see Formatting
Data with the = Operator on page 287. The MergeWIP rule gets all of its data
from WIP, not an extract file.

Syntax ;MergeWIP;;StatusCode1,StatusCode2,...;

Parameter Description

StatusCode Use the StatusCode parameters to define the status codes of the
transactions in the WIP file you want to add to the memory list. Identify
the status codes you want to included in the Status_CD control group.
Here is an example:
< Status_CD >
Accepted = AC
Approved = AP
BatchPrint = BP
Rejected = RJ

160
MergeWIP

WIP selection The system automatically limits the result sets queried from DBMS systems by the
performance during batch MergeWIP rule to the rule's parameters for the STATUSCODEs to significantly improve
processing query speeds when this rule is run against large WIP index tables.
When the WIP index table is in a DBMS, the appropriate WHERE clause for the
STATUSCODE is added to the query automatically. A separate query for each
STATUSCODE provided to the MergeWIP rule is used to retrieve the WIP list.
To improve performance on very large WIP tables, add an index on the DBMS WIP index
table on the STATUSCODE column to avoid full table scans. An index on the WIP index
table on the CURRUSER and STATUSCODE columns can also improve the performance
of other queries to the WIP index table when the query to build a WIP list for a specific
user is performed.

Using dates to select The MergeWIP rule can check a date field in the WIP index to determine whether to
transactions insert the WIP record into the batch. By default the field name is ScheduleDate. You can
use this INI option to change the name of the field that is used:
< MergeWIP >
ScheduleDateFieldName = ScheduleDate

If the data in the field is eight bytes, the system assumes the date is in YYYYMMDDD
format. If the data in the field is 14 bytes, the system assumes a YYYYMMDDhhmmss
format. You can change the format the MergeWIP rule expects for the date using this
INI option:
< MergeWIP >
ScheduleDateFieldFormat = D4%1

You can combine date and time formats into one string separated by percent signs (%).
This table shows the date formats:

Enter For this format

1 MM/DD/YY 99/99/99 (default)

2 DD/MM/YY 99/99/99

3 YY/MM/DD 99/99/99

4 Month DD, YY Month DD, YYYY

5 MM/DD/YY ZZ/ZZ/ZZ

6 DD/MM/YY ZZ/ZZ/ZZ

7 YY/MM/DD ZZ/ZZ/ZZ

8 MM/DD/YY LZ/LZ/LZ

9 DD/MM/YY LZ/LZ/LZ

A YY/MM/DD LZ/LZ/LZ

B MMDDYY ZZZZZZ

C DDMMYY ZZZZZZ

161
Chapter 3
Job and Form Set Rules Reference

Enter For this format

D YYMMDD ZZZZZZ

E MonDDYY MonZZZZ

F DDMonYY ZZMonZZ

G YYMonDD ZZMonZZ

H DOY/YY ZZZ/ZZ

I YY/DOY ZZ/ZZZ

J DD Month, YY DD Month, YYYY

K YY, Month DD YYYY, Month DD

L Mon-DD-YY Mon-ZZ-ZZ

M DD-Mon-YY ZZ-Mon-ZZ

N YY-Mon-DD ZZ-Mon-ZZ

O Mon DD, YY Mon DD, YYYY

P DD Mon, YY DD Mon, YYYY

Q YY, Mon DD YYYY, Mon DD

R Month Month

This table shows the time formats:

Enter For this format

1 HH:MM:SS 99:99:99(default)(24 hour)

2 HH:MM:SS XM 99:99:99 XM (12 hour)

3 HH:MM 99:99 (24 hour)

4 HH:MM XM 99:99 (12 hour)

Returning a warning Instead of returning an error if it comes across an empty WIP list when merging WIP,
message the system can issue a warning. To have the system issue a warning instead of an error,
set the WIPWarnOnEmpty option to Yes, as shown here:
< RunMode >
WIPWarnOnEmpty = Yes

162
MergeWIP

Changing the WIP Status You can tell the system not to delete WIP records and files during the MergeWIP/
WIPTransactions process if an error occurs, but instead change the WIP status to
something you define.
This way, if an error occurs during batch processing, the WIP will still exist in its normal
place. But since its status has changed, the system will not include it in the next batch
run. You can then examine the transaction to determine what caused the error.
Use the following INI option to set up the transaction error code you want to use:
< Status_CD >
TransErrCode = E

Option Description

TransErrCode You can enter up to two characters, numbers or both for the transaction
error code.

Example Here is an example:

;MergeWIP;; Approved, Accepted, Rejected;
This example adds to the memory list the transactions in the WIP file which have these
status codes: Approved, Accepted, and Rejected. Those codes must be specified in the
Status_CD control group.

Example Here are some examples:

Example This tells the system to switch XDBs

;MultipleDataDictionaryFiles;2;Key2; Based on the Key2 field

;MultipleDataDictionaryFiles;2;Key1,Key2; Based on the Key1, Key2 combination

You specify XDB files using the MultiDataDict control group. For each XDB file, use an
INI option similar to the one shown here:
< MultiDataDict >
File = FileName;IDFormat

Option Description

File For FileName, include the full file name and path followed by a semicolon. The
IDFormat is based on the parameters you supplied to the rule.
Note: In the first example below, the IDFormat would be Key2Value, for the
second example, it would be Key1Value;Key2Value.

Based on the first example, assume Key2 has these possible values:
CAR, BOAT, and MISC
with corresponding XDBs of:
CARXDB.DBF, BOATXDB.DBF, and MISCXDB.DBF
The AFGJOB.DAT file would contain:
;MultipleDataDictionaryFiles;2;Key2;

The INI file would contain:

< MultiDataDict >
File = CARXDB.DBF;CAR
File = BOATXDB.DBF;BOAT
File = MISCXDB.DBF;MISC

Thus whenever the Key2 ID changed to one of these values, the appropriate XDB would
be loaded.
Based on the second example, assume Key1 has these possible values:
LIFE and VEHICLE

164
MultipleDataDictionaryFiles

Assume Key2 has these possible values:

Under the VEHICLE Key1 CAR, BOAT, MISC

Under the LIFE Key1 SINGLE, MARRIED

The AFGJOB.DAT file would contain:

;MultipleDataDictionaryFiles;2;Key1,Key2;

The INI file would contain:

< MultiDataDict >
File = CARXDB.DBF;VEHICLE;CAR
File = BOATXDB.DBF;VEHICLE;BOAT
File = MISCXDB.DBF;VEHICLE;MISC
File = SINGXDB.DBF;LIFE;SINGLE
File = MARRXDB.DBF;LIFE;MARRIED

Whenever the Key1 and Key2 combination changed to one of these values, the system
would load the appropriate XDB.

Example Here is an example from the Condition table (CONDTBL):

< Conditions >
LetterOMR: LetterCode = "0006" or LetterCode = "0039" or
LetterCode = "0040"

Here is an example from the record dictionary definition:

< Variables >
LetterCode = GVM(CD-LTR-TYPE) Length(4) Type(Char)

LetterCode is a global variable with the name, CD-LTR-TYPE. This variable has a type of
Char (character) and a length of four. In this example, any time the condition is true, the
system prints OMR marks on the page created for the transaction it is processing.
You must update your FSISYS.INI or FSIUSER INI files as follows.

167
Chapter 3
Job and Form Set Rules Reference

Enter the path for your table files in the MasterResource control group. Use the
TablePath option to define the table file’s path.
< MasterResource >
TablePath = \deflib\

Enter the file name of your Condition table in the Tables control group. Use the
Conditions option to define the Condition table’s file name.
< Tables >
Conditions = CondTbl
Create the OMR_Params control group with all necessary options in your FSISYS.INI or
FSIUSER INI file.
Here is an example of INI settings for 1-up printing:
< OMR_Params >
Mark = Cord(2100, 2140, 300, 1000), RuleParms(INSERT2),
Rule(FlagFromGVM), When(All)
Mark = Cord(4200, 4240, 300, 1000), Rule(Always), When(All)
Mark = Cord(2100, 2140, 700, 1300), Rule(Always), When(All)
Mark = Cord(6300, 6340, 700, 1300), RuleParms(A-AND-C),
Rule(Always), When(All), Cond(ac)

Here is an example of INI settings for 2-up printing:

< OMR_Params >
Mark =
Cord(Left(2100,2140,300,1000),Right(2100,2140,32500,33200)),
RuleParms(Insert2),Rule(FlagFromGVM),Page(B), When(All)
Mark = Cord(Left(4200,4240,300,1000),
Right(4200,4240,32500,33200)), Rule(Always),Page(B), When(All)
Mark = Cord(Left(2100, 2140, 700, 1300), Right(2100, 2140, 32500,
33200)), Rule(Always),Page(B), When(All)

Parameter Description

Mark Definition for each OMR mark. You need a definition for each OMR
mark that can be generated on a page. For instance if eight is the
maximum number of OMR marks per page, you need eight mark
definitions in this control group.

Cord(t,b,l,r) Top, bottom, left, and right coordinates for the page in FAP units (1
inch = 2400 FAP units) for 1-up printing.

Cord(Left(t,b,l,r), Top, bottom, left, and right coordinates for the page in FAP units (1
Right(t,b,l,r)) inch = 2400 FAP units) for 2-up printing. Left is for the left side and
right is for the right side of the 2-up paper.

Page() Indicates which sides to print: Both or B = both left and right; Left or
L = left side only; Right or R = right side only.

Rule() The name of the OMR rule to execute.

RuleParms() The Input parameter to the rule, as specified in the Rule() parameter.

168
OMRMarks

Parameter Description

When(All) When to print on pages:

All - print on all pages of the transaction output.
FirstOnly – only print on the first page of transaction output.
LastOnly – only print on the last page of the transaction output.
ExceptFirst - print on all pages except the first page.
ExceptLast - print on all pages except the last page.

Cond() Condition, if true, then print OMR mark.

The OMR rules are:

Rule Description

Always Always generate the OMR mark.

Cond() You can use condition logic for one OMR mark or for the whole set.
Here is an example: Cond(ac)

DivertPage Generates the OMR mark only for a special divert page. This only
applies to 2-up printing. If you use this rule, you must also define the
DivertOpt and DivertOMR options in the TwoUp control group.

FlagFromGVM Generates the OMR mark if the GVM variable defined in the
RuleParms is set to zero (0) or one (1).
You control generation based on data in an extract record (using the
Ext2GVM or Field2GVM rules) or based on a DAL script which uses
the SetGVM function.
The GVM variable must be in the RCBDFDFL and TRNDDFDFL files.

ZipCodeChange Generates the OMR mark only when the ZIP code has changed. You
must define the parameter associated with this rule as a global
variable or else define it in the RCBDFDFL.DAT file.

< TwoUp >

CounterTbl = Counter.tbl
LMargin = 0
LShift = -240
RShift = 16560
DivertOpt = No
DivertOMR = OMR20
PageSize = 40800

OMR marks are not supported in these situations:

• In 1-up printing when you have multiple copies of the same form
• In 2-up printing when you are printing duplex

JDT Rules Reference on page 28

Using Condition Tables on page 508

170
PageBatchStage1InitTerm

PageBatchStage1InitTerm
Use this job level rule (level 1) to create and populate a list of records which contain
page ranges and total page counts for each recipient batch file.
This rule is typically used for handling 2-up printing for AFP and compatible printers.
This rule is also used with multi-mail processing.
This rule creates a list (populated in another rule) to contain the recipient batch records
for a multi-mail transaction set. The rule then writes out the recipient records for the
final multi-mail transaction set and writes out the total page counts for each recipient
batch.

• Fields must be added to the RCBDFDFL.DFD file for the file containing the total
page counts for the recipient batches. Do not remove or change the BatchName
and RecordCount fields.
• The name of the file containing page counts should be specified in the CounterTbl
option of the TwoUp control group.
• Because the end of a multi-mail set is not signaled until the following transaction,
you must write out the recipient records for the final transaction set at the job
level.

Syntax ;PageBatchStage1InitTerm;;(MMField);

Parameter Description

MMField (Optional) Name of the INI option in the Trn_Fields control group which
defines where the multi-mail code will be found in each transaction.

NOTE: If you use this rule, you must also use the BatchByPageCount and
WriteRCBWithPageCount rules.

Example If you omit the MMField parameter, the system uses standard batching by page count,
as shown below:
;PageBatchStage1InitTerm;;;
If you include the MMField parameter, the system uses batching by multi-mail
processing, as shown below:
;PageBatchStage1InitTerm;;MMField=MM_Field

Syntax ;PaginateAndPropagate;Debug FooterMode;

Parameter Description

Debug If you include this parameter, the system writes debug information
about pagination to the log file.
For performance reasons, you would not typically use this option unless
directed by support.

FooterMode This parameter controls how the footers are treated in regards to
pagination. You can enter 0, 1, or 2. The default is zero (0) which is the
standard way the rule handles footers.

Normally this rule is placed in the Base Form Set Rules section of the AFGJOB.JDT file
at or near the end of the rule list. This location is important because you want the rule
to execute as one of the first steps of transaction post-processing. Place this rule after
the PrintFormset rule in the Base Form Set Rules section of the AFGJOB.JDT file when
running in single-step mode.
This rule is a post-process rule, meaning that initial pagination and propagation takes
place before the rule is called. This rule then goes back through the form set.

Example Here are some examples:

;PaginateAndPropagate;;
;PaginateAndPropagate;2,Debug FooterMode(2);
;PaginateAndPropagate;2,FooterMode(1);

NOTE: The PaginateAndPropagate rule looks for the CanSplitImage indicator. If

missing, images are paginated in the standard method.

Footer modes 1 and 2 search the logical page for footers marked as copy-on-overflow
and then determine the upper limit of those footers. That point becomes the lower limit
of the body images.
As the system checks the body images to determine if they exceed the lower limit, it
raises the lower limit if there is another footer with a higher limit. This prevents the a
large footer at the bottom of a long logical page from affecting pages on which it does
not appear.
Modes 1 and 2 differ in how they handle an overlap when a footer is encountered that
raises the lower limit above a body image that is already determined to fit on the page.
With mode 1, the system increases the limit and reevaluates the image on that page. It
also lets the second from the last page have a large area reserved with nothing printed.
With mode 2, the system moves the footer to the next page so the footer can appear on
a page by itself.

172
PaginateAndPropagate

With mode zero (0), the default, the system searches the logical page for all footers and
determines the upper limits of the footers. That becomes the lower limit of the body
images. When a body image exceeds this lower limit, the system splits the logical page
into two pages.
The image that exceeds the limit and all following images are moved up and to the
second page. Images on the first page marked as copy-on-overflow are copied to the
second page. Images on the second page marked as copy-on-overflow are copied back
to the first page. The system then searches the second page for all footers, determines
the upper limit of that footer, and continues the process.

NOTE: Previously, this rule was known as the PaginateAndPropogate rule. You can
use either spelling.

Syntax ParseComment; ;Side;

Parameter Description

Side You can enter Left or Right or omit this parameter.

Including Left or Right specifies that you want the system to parse the
comment record from either the left or right side. The system parses the
data from the comment record into the first (primary) instance of the
associated GVM variables.
If you omit this parameter, the associated variables from both sides are
parsed and stored. The left side comment data is parsed into the first
(primary) instance of the associated GVM variables. The right side
comment data is parsed into the second instance of the associated GVM
variables.

Example This example shows how to use this rule to access the specific occurrences of RCB
comment records retrieved from AFP files.
;ParseComment;;Left;
;PreTransDal;;MyScript;
;ParseComment;;Right;
;PreTransDAL;;MyScript;

If you include the Side parameter, be sure to finish using the values from one record
before parsing the other record, because this method replaces the primary instance of
the GVM variable data. This example also shows that you can use a DAL script to
manipulate the parsed GVM variables.
If you want to use a DAL script and get data from both sides (omitting the Side
parameter), you would specify two (2) as the optional second parameter to the GVM
function to access the second (right side) set of data.
LeftData = GVM( name )
RightData = GVM( name, 2 )

String A character string that contains a DAL function or DAL script.

Although you can use DAL to access almost any form set or image field, keep in mind
those fields may not exist, depending on where you place this rule in the transaction
job rule list. And, unlike the DAL or IF rules, there is no return value from the execution
of a transaction level DAL script.
Use this form to get extract data if the script is contained in the rule data. You cannot
use this form in external script files.
A = {1,MIS257 138,1}
Where A is a DAL variable you wish to assign. The bracketed {} item can be almost any
standard search mask supported by the Get Record infrastructure. In this case,
1,MIS257 is the search criteria. If the record is found, the system takes the data from
position 138, length 1 as indicated by 138,1.
This method also lets you specify an occurrence of the record by including a hyphen
with a numeric value, such as -n, after the data length. Here is an example:
A = {1,MIS257 138,1-5}
Here the function searches for the 5th occurrence of the 1,MIS257 record. If you omit
the occurrence, the system returns the first one found. If it cannot find the requested
record, the system assigns the variable an empty “” value.

NOTE: To specify multiple DAL statements in the rule data area, separate the DAL
statements using two colons (::). Normally, semicolons separate DAL
statements, but this character is illegal in the rule data area.

Example ;PostTransDAL;;Call("posttran.dal");
This example executes the Call DAL function which executes the DAL script contained
in the POSTTRAN.DAL file in the DefLib directory specified in your MRL.
;PostTransDAL;;If HaveGVM("main_address") Then
SetGVM("main_address", "25 Brown St.", , “C”, 20)::End;

In this example, the system checks to see if the GVM variable (main_address) exists. If
not, it creates a character array GVM variable (main_address) 20 characters is length
and stores the character string (25 Brown Street) in the array.

175
Chapter 3
Job and Form Set Rules Reference

Here is another example:

Suppose you want any transaction that contains the following XML tag with a value of
N to be processed and printed, but not archived:
INVOICE/DOCUMENT_ID/ARCHIVE

To accomplish this, add the following to the AFGJOB.JDT file:

;PostTransDAL;;a = {!/INVOICE/DOCUMENT_ID/ARCHIVE 1,1}::If a="N"
Then a="Y":: Else a="N":: End::SetGVM("SentToManualBatch", a, ,"C",
2);

String A character string that contains a DAL function or script.

Example ;PreTransDAL;; trans_id={1,PrePost 1,8}::Chain("pretrans.dal");

This example sets the internal DAL variable, trans_ID, to the first eight-characters from
the transaction record that matches the search mask: 1,PrePost. Then the Chain DAL
function executes the DAL script in the PRETRANS.DAL file in the DefLib directory
specified in your MRL.
;PreTransDAL;;If (HaveGVM("main")) Then SetGVM("main_address", "25
Brown St.", , “C”, 20)::End;

177
Chapter 3
Job and Form Set Rules Reference

In this example, DAL checks to see if the GVM variable (main_address) exists. If not, it
creates a character array GVM variable (main_address) 20 characters in length and
stores the character string (25 Brown Street) in the array.

Example Here is an example:

;PrintFormset;;;
You can also use the PrintFormset rule to create multiple print files when you run the
GenData program in single-step mode to produce PDF or RTF output with multiple
transactions. This capability is related to running Documaker under IDS (see the
Internet Document Server Guide for more information). To do this, add the
PrintFormset control group and these options to your INI file:
< PrintFormset >
MultiFilePrint = Yes
LogFileType = XML
LogFile = (log file name and path)

Option Description

MultiFilePrint Set this option to Yes to allow multiple file print.

The MultiFilePrint option should only be used with the PDF, RTF, HTML,
and XML print drivers.

LogFileType Specifies the type of the log file. Enter XML for an XML file. Any other
entry results in a text file.

180
PrintFormset

Option Description

LogFile Specifies the name of the log file. Include the full path. If you omit the
path, the system uses DATAPATH. If you omit this option, the system
creates a file named TMP.LOG.
If you enter XML in the LogFileType option and a different extension
here, the system uses XML.

NOTE: You must place this rule before the PaginateAndPropagate rule in the Base
Form Set Rules section of the AFGJOB.JDT file when running in single-step
mode. When running in multi-step mode, use the MultFilePrint callback
functionality.

The log file that is created is either a semicolon-delimited text file, formatted like the
file created by the MultiFilePrint callback function or an XML file. Here is an example of
the layout of the XML file:
<?xml version="1.0" encoding="UTF-8" ?>
- <LOGFILE>
- <TRANSACTION INSTANCE="1">
<BATCH NAME="Logical Batch Name">.\data\BATCH1.BCH</BATCH>
<GROUP1 NAME="Company">SAMPCO</GROUP1>
<GROUP2 NAME="Lob">LB1</GROUP2>
<TRANSACTIONID NAME="PolicyNum">1234567</TRANSACTIONID>
<TRANSACTIONTYPE NAME="TransactionType">T1</TRANSACTIONTYPE>
<RECIPIENT NAME="INSURED">INSUREDS COPY</RECIPIENT>
<FILE>DATA\0rDcP7WxytE8ECp5jexhWXVqkV840Vw_F-GykT_VMfd.PDF</FILE>
</TRANSACTION>
- <TRANSACTION INSTANCE="2">
<BATCH NAME="Logical Batch Name">.\data\BATCH2.BCH</BATCH>
<GROUP1 NAME="Company">SAMPCO</GROUP1>
<GROUP2 NAME="Lob">LB1</GROUP2>
<TRANSACTIONID NAME="PolicyNum">1234567</TRANSACTIONID>
<TRANSACTIONTYPE NAME="TransactionType">T1</TRANSACTIONTYPE>
<RECIPIENT NAME="COMPANY">COMPANY COPY</RECIPIENT>
<FILE>DATA\0v3l7pBdVqHceoRL5hf2xqjJ7WMxiRVO9U70iFiIcne.PDF</FILE>
</TRANSACTION>
</LOGFILE>

Use the options in the DocSetNames control group to determine which XML elements
are created. The values in this control group are the same as those written to a recipient
batch or TRN file.

Queue The name of the queue you want to process.

This rule loops through the list of functions for the queue you specify and then frees
the queue when finished.

Example ;ProcessQueue;;PostPaginationQueue;
This example tells the system to process the PostPaginationQueue.

There are no parameters for this rule.

Place this rule after the BuildFormList rule in your AFGJOB.JDT file. Insert this rule after
any import rule that might be used to create the starter document. For instance, insert
the BuildFormList rule first, followed by your import rule, and then include the
ProcessTriggers rule to add additional forms or assign recipient counts to the forms
included via the import.
This rule does not trigger the Key2 (lines of business), however, if there are multiple
lines of business defined at the point where triggering begins, this rule processes the
triggers in each group. One way to define multiple groups is via an import file.

NOTE: The ProcessTriggers rule was added to support multiple lines of business
during the triggering process. Normally, the RunSetRcpTbl file only supports
the main (Key1+Key2) setting identified with the transaction. The
ProcessTriggers rule, however, will process all defined lines of business (each
Key1+Key2 combination) at trigger time. This means if you use an import rule
to create the transaction, you can have multiple lines of business in batch
processing and trigger additional forms and images. You can use the
ProcessTriggers rule with both Documaker Studio and the legacy tools.

If you are only using the Studio implementation model, you may want to use
the RunTriggers rule.

CLDebug (optional) This option turns on debugging. The default is No.

CLDebugFile (optional) Enter the name of the debug file. If you omit the path, the
file is written to the data directory. The default is cldebug.dat.

DumpCandList (optional) Enter Yes to have the system write the form candidate list
details into the debug file. The default is No.
To enable this option, you must also set the CLDebug option to Yes.

DumpFrmStTable (optional) Enter Yes to tell the system to write the Form-State Loc
table records to the debug file. The default is No.
To enable this option, you must also set the CLDebug option to Yes.

DumpFrmStLocEnt (optional) This tells the system to write the unloaded (by the
PXTrigger rule) State Loc entries for the form. The default is No.
To enable this option, set the CLDebug option to Yes.

DBTable:”Table” (optional) Enter the name of the table handler. The default table
handler for all tables is MEM.

Fed_Processing (optional) Enter No to bypass FED processing. The default is Yes.

Form_List Use this control group to enable form list processing.

Option Description

Form_List (optional) Enter Yes to enable form list processing. The default is No.

XPTranslateLOB The LOB (GROUP NAME 2) determines the type (Commercial Auto, Property Lines,
Personal Lines) of FED processing. If you are using a non-standard LOB, use the
XPTranslateLOB control group to translate the LOB to a standard LOB code. Here are
the standard LOB codes:

Line of Business Code

Commercial Auto CA, CU, GL, CRIM, PR, BM, INMARC

Property Lines BP, CP, CM

Personal Lines HO, PP, DFire, DL, UMBRP, INMRP, PM

Returns Trigger Count

(0 for not triggered)

PXTrigger

188
PXTrigger

Input Tables
State loc table Here are the required fields for the state location table.

Field Type Length Notes

Form Char 36

State Char 8

PolicyEffectiveDate Char 10 CCYY-MM-DD

PolicyWrittenDate Char 10 CCYY-MM-DD

ControllingState Char 2

Location Char 8

SubLocation Char 8

LocationAddrDate Char 10 CCYY-MM-DD

TransactionEffectiveDate Char 10 CCYY-MM-DD

ProgramCd Char 6

FED table Here are the required fields for the FED table.

Field Type Length Notes

FormNumber Char 36

FormProcessingType Char 1

EffectiveDateSourceCD Char 2 “PE” or “PW”

EffectiveDate Char 10 CCYY-MM-DD

WithdrawalDate Char 10 CCYY-MM-DD

189
Chapter 3
Job and Form Set Rules Reference

The Policy Xpress FED Processing Flow

Rules Processor
AFGJOB

PXCandidateList

Execute DAL
Script

State Loc
Xpress_create()
Table

Return Control

PXCandidateList FED Table

Consolidated
Form
Form State
Candidate List
Loc Table

FED processing For each State Loc Record, a query is executed against the FED table using the LOB,
State, and, if populated, the ProgramCd. Each of the returned FED records are then
evaluated to determine if they are valid for the current State Loc table row.

FED record validation For form list processing, the FED record must have a FormProcessingType of R.
The FED record validation date compares are based on the LOB groups defined above.
If a LOB is not found in the standard groups (and is not translated to a standard LOB)
the Commercial Auto compare is executed by default. The specific date validation/
compares are explained below.

190
PXTrigger

For each FED record that passes validation, its FormNumber is added to the form
candidate list (if the form does not already exist) and a row is inserted into the Form
State Loc table (FormNumber plus the current State Loc Record).

Validation Description

Commercial If the Transaction Type is PCH, the date evaluation is executed using
auto validation the State Loc record's TransactionEffectiveDate.If the Transaction Type
is not equal to PCH, the date evaluation is based on the FED records
EffectiveDateSourceCd value.
If the EffectiveDate SourceCd is PE, the date evaluation is executed
using the State Loc record's PolicyEffectiveDate. Otherwise, the date
evaluation is executed using the State Loc Record's PolicyWrittenDate.

Personal lines If the EffectiveDate SourceCd is PE, the date evaluation is executed
validation using the State Loc record's PolicyEffectiveDate. Otherwise, the date
evaluation is executed using the State Loc Record's PolicyWrittenDate.

Property lines If the Transaction Type is PCH, the date evaluation is executed using
validation the State Loc record's LocationAddrDate. If the transaction type is not
equal to PCH, the date evaluation is based on the FED records
EffectiveDateSourceCd value.
If the EffectiveDate SourceCd is PE, the date evaluation is executed
using the State Loc record's PolicyEffectiveDate. Otherwise, the date
evaluation is executed using the State Loc Record's PolicyWrittenDate.

Date The passed date is subjected to a trivial date validation.

validation/ The date must be in a CCYY-MM-DD format. The day can not be zero (0)
compare or greater than 31. The month can not be zero (0) or greater than 12. The
year can not be zero (0).
If the passed date passes validation, the system compares it to the Fed
Entries Withdrawal Date and the Effective Date. If the passed date is
falls before the Withdrawal Date and after the Effective Date, the date
compare is passed.

Here's an example trace file produced by setting the RegionalDateProcess option to

Yes:
1. Thu Sep 11 14:38:14.678 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
2. Thu Sep 11 14:38:14.678 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
3. Thu Sep 11 14:38:14.866 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
4. Thu Sep 11 14:38:14.866 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
5. Thu Sep 11 14:38:14.975 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION> IS excluded.
6. Thu Sep 11 14:38:14.975 2008 pid=00029776 RDP Form <PREMIUM
CONFIRMATION 06152008> IS excluded.
7. Thu Sep 11 14:38:14.991 2008 pid=00029776 RDP Form <MEDICAL
HISTORY USING MEDBODY1> IS excluded.

193
Chapter 3
Job and Form Set Rules Reference

Example Here is an example of how you would use this rule:

<Base Form Set Rules>
;NoGenTrnTransactionProc;2; single step;
;ResetOvFlw;2;;
;BuildFormList;2;;
;RegionalDateProcess;2;;
;RunSetRcpTbl;2;;
;WriteOutput;2;;
;WriteNaFile;2;;
;BatchingByRecipINI;2;;
;PaginateAndPropagate;2;;

Example Here is an example:

< Base Form Set Rules >
;WIPTransactions;;BATCHPRINT;
;GVM2GVM;;Trigger2Wip;
;ResetDocSetNames;;;

The restart file stores checkpoint information at specified intervals. If an error is

encountered, the program resets itself and then checks each transaction until it
isolates the transaction causing the error.
The restart file is removed at the end of a successful run. If the file exists at the start of
a GenData run, the system assumes a restart is necessary and will open and read the
file. The checkpoint information lets the system set internal pointers and output files
in such a way that it can begin at that transaction.
You also use the RULCheckTransaction rule to restart the GenData program.
To use the restart feature, you should also set the following INI options:
< GenDataStopOn >
BaseErrors = Yes
TransactionErrors = Yes
ImageErrors = Yes
FieldErrors = Yes

Example Here is an example:

;RestartJob;1;Always the first base rule;

The restart file stores checkpoint information at specified intervals. If an error is

encountered, the program resets itself and then checks each transaction until it
isolates the transaction causing the error.
The restart file is removed at the end of a successful run. If the file exists at the start of
a GenData run, the system assumes a restart is necessary and will open and read the
file. The checkpoint information lets the system set internal pointers and output files
in such a way that it can begin at that transaction. You also use the RestartJob rule to
restart the GenData program.

INI options These offsets are updated in the post process after a specific number of transactions.
You specify the number of transactions using the CheckCount option. You define the
Restart file and the and check count in the Restart control group:
< Restart >
RstFile =
CheckCount =

Option Description

RstFile Enter the name of the restart file. If you omit this option, the system uses
RSTFILE.RST (DD:RSTFILE for z/OS) as the file name.
The system uses the DataPath option in the Data control group to
determine where to create the restart file. The default location is the
current working directory.

CheckCount Enter a number to specify the number of transactions to process before

updating the offsets. For instance, if you specify two hundred (200), the
system processes two hundred transactions, updates the offsets,
processes two hundred more transactions, and so on. The default is 100.
You can also use the /cnt command line option with the GenData program
to override the CheckCount option. Here is an example:
gendaw32 /cnt=10

Example Here is an example:

;RULCheckTransaction;2;Always the first form set rule;

• In order insertion below the lead image.

Consider two different images triggered by two different masks that occur in the
extract file and the overflow file in the following manner:
(extract file)
000000001LEADREC
000000001LISTREC1
000000001LISTREC2
000000001LISTREC1
(overflow file: note reverse insertion logic)
;LEADIMAGE;10,LEADREC;LISTIMAGE2|DSW<RECIP(1);;
;LEADIMAGE;10,LEADREC;LISTIMAGE1|DSW<RECIP(1);;

202
RULNestedOverFlowProc

The images would be inserted after LEADIMAGE in the following order:

LISTIMAGE2…LISTIMAGE1…LISTIMAGE1

However the POLFILE.DAT file would look as follows:

…/LEADIMAGE|DSW<RECIP>/LISTIMAGE1|DSW<RECIP>/LISTIMAGE1|DSW
<RECIP>/LISTIMAGE2|DSW<RECIP>/...

This excerpt demonstrates that the images are not inserted in the order of list
search masks in the extract file but in the reverse order of the occurrence of list
images in the overflow file.

NOTE: If while processing the rule the system encounters invalid lines in the overflow
file, it ignores those lines and adds log entries into the log file. The system then
continues processing.

• DPSPrint.Forms creates DPRFORMNAME

• DPSPrint.FormDescription creates DPRFORMDESCRIPTION
• DPSPrint.Recipients creates DPRRECIPIENTNAME
The input can be a list, with items separated by commas. Here are the search
conditions you can use:

• End with * , STARTS WITH

• Start with *, CONTAINS
• Text alone, EQUALS
While executing the DPSPRT request from the DPSPrint object, the RPDCreateJob rule
creates the DPRFORMNAME, DPRFORMDESCRIPTION, and DPRRECIPIENT tags in the
job ticket.
< ReqType:DPSPRT >
function = atcw32->ATCLogTransaction
function = atcw32->ATCLoadAttachment
function = atcw32->ATCUnloadAttachment
function = dprw32->DPRSetConfig
function = dsijrule->JavaRunRule,;com/docucorp/ids/rules/
dps;DPS;global;duplicateAttach;,RV,CUSTOMERBATCH,
O,PRINTOUTPUTFILE,O
function = rpdw32->RPDCheckRPRun
function = rpdw32->RPDCreateJob
function = rpdw32->RPDProcessJob

Once job ticket is created, Documaker processes the job. Documaker reads the job
ticket and creates a GVM variable with this name:
DPRFORMNAME, DPRFORMDESCRIPTION, and DPRRECIPIENTNAME.
The ServerFilterFormRecipient rule looks for the GVM name DPRFORMNAME,
DPRFORMDESCRIPTION, and DPRRECIPIENTNAME and filters out the mismatch
condition.
Here is an example in Visual Basic:
Private Sub CmdPrint_Click()
Dim oDPSVar As New DPSPrint
Dim oDPSIDS As New DPSIDS
oDPSVar.inputFile = FldInputFile.Text

212
ServerFilterFormRecipient

oDPSVar.configurationName = FldConfig.Text
oDPSVar.outputFile = FldOutputFile.Text
oDPSVar.outputPath = FldOutputPath.Text
oDPSVar.printerType = FldPrinterType.Text
oDPSVar.Forms = "ABC,DEF*,*XYZ"
oDPSIDS.send oDPSVar
FinalOutput.Text = oDPSVar.outputPath + oDPSVar.outputFile
End Sub

All form names that equal ABC or start with DEF or contain XYZ are included in the final
print file.
If all inputs (DPRFORMNAME, DPRFORMDESCRIPTION and DPRRECIPIENTNAME) exist,
the recipient name is evaluated first and the form name and form description are
evaluated later.

NOTE: Include this rule in the AFGJOB.JDT file after the LoadRcpTbl rule.

Here is an excerpt from the AFGJOB.JDT file:

/* Every form set in this base uses these rules. */
<Base Form Set Rules>
;NoGenTrnTransactionProc;;required to combine gentrn/gendata into
single step;
;BuildFormList;;;
;LoadRcpTbl;;;
;ServerFilterFormRecipient;;;
;RunSetRcpTbl;;;
;PrintFormset;;required to combine gendata/genprint into single
step;
;WriteOutput;;;required to combine gentrn/gendata into single step;
;WriteNaFile;;;required to combine gentrn/gendata into single step;
;BatchingByPageCountINI;;;
;ProcessQueue;;PostPaginationQueue;
;PaginateAndPropagate;;FooterMode(2) Debug;

Example ;ServerFilterFormRecipient;;;

INI options < Data >

DataPath =
ExtrFile =
MsgFile =
ErrFile =
LogFile =
DBLogFile =
NAFile =
POLFile =
NewTrn =
< PrinterInfo >
Printer =

214
ServerJobProc

< Printer >

Port =
< Print_Batches >
Batch1 = batch1.bch
< IDSServer >
SleepingTime =
GENSemaphoreName =
RPDSemaphoreName =
< Debug >
RULServerJobProc =
< PrintFormSet >
MultiFilePrint =
LogFileType =
LogFile =

Option Description

Data control group

DataPath Used as the default path if you omit PrintPath.

ExtrFile Enter the name and path of the extract file.

MsgFile Enter the name and path of the message file.

ErrFile Enter the name and path of the error file.

LogFile Enter the name and path of the log file.

DBLogFile Enter the name and path of the DB log file.

NAFile Enter the name and path of the NA file.

POLFile Enter the name and path of the POL file.

NewTrn Enter the name and path of the NewTrn file.

PrinterInfo control group

Printer Enter the designated printers for print batches.

Printer control group

Port Enter the name of the print batch file for each designated
printer. Note the group name is defined by the printer option in
the PrinterInfo control group.

Print_Batches control group

Batch1 Then name of the batch file.

IDSServer control group

SleepingTime Enter the amount of time in milliseconds you want the system to
wait before it checks for a job ticket. The default is 1000 (1
second).

215
Chapter 3
Job and Form Set Rules Reference

Option Description

GENSemaphoreName Enter the name of the semaphore. The default is gendata.

RPDSemaphoreName Enter the name of the semaphore. The default is rpdrunrp.

Debug control group

RULServerJobProc Enter Yes to get a copy of the job ticket file before the system
removes it.

PrintFormSet control group

MultiFilePrint Enter Yes to generate multiple print files which use 46-byte
unique names.
To identify which recipients are in which print batch, enter No or
omit this option.This causes the PrintFormSet rule to save the
printer for the print batch along with its recipient information.
The ServerJobProc rule then adds three new tags for each print
batch file and adds them to the JOBLOG.XML file.
For example, for the print batch file on PRINTER1, the system
creates these new tags:
<PRINTER1RECIP>Insured</PRINTER1RECIP>
<PRINTER1CODE>001</PRINTER1CODE>
<PRINTER1DESC>Insured Copy</PRINTER1DESC>
The MultiFilePrint option should only be used with the PDF, RTF,
HTML, and XML print drivers.

LogFileType Specify the type of print log file, such as XML or TEXT.

LogFile Enter the name and path of the print log file. If you omit the
extension, the system uses the LogFileType option to determine
the extension.

Input file JOBTICKET.XML

Output file JOBLOG.XML

Example ;SetErrHdr;;: Transaction: PolicyNum***;

;SetErrHdr;;***:Company Name: ***Company***;

This example substitutes the global variables, PolicyNum and Company, into the error
file header information. If the global variable PolicyNum was equal to MVF10002 and
Company was equal to ABC Insurance Company, the text output to the error file would
be:
Transaction: MVF10002
Company Name: ABC Insurance Company

To add lines to the header, use the rule multiple times. Each time you use the rule, the
system adds a line to the header, which you will see in the error file (ERRFILE.DAT).

NOTE: The global variable names must be spelled exactly as they are defined to the
system.

Syntax ;SetOutputFromExtrFile;;RecordMask PrintBatchName;

Parameter Description

RecordMask This tells the system to locate a specific record line.

PrintBatchName This tells the system to get the print batch name that begins in a
specific location and save it to a global variable.

You must include the BatchingByRecipINI or the IfRecipUsed rule before this rule in the
AFGJOB.JDT file. If you include the BatchingByRecipINI rule, also include these options:
< BatchingByRecip >
Batch_Recip_Name = 39,FILENAME001;"Batch1";INVESTOR
Batch_Recip_Name = 39,FILENAME002;"Batch2";COMPANY
Batch_Recip_Name = 39,FILENAME003;"Batch3";AGENT

Make sure that FILENAME001,FILENAME002 and FILENAME003 exist at offset=39 in

the records. You can see that the mask FILENAME001 is composed of FILENAME and
Recipient code 001. So make sure INI control group is set.
To use multiple recipients, each transaction records should contain print multiple print
batch names. Here is an example:
FUND/INVESTOR/TEMPLATE/TEMPLATE_LEVEL/INVESTOR_ID\JPMP0355 98PL X
FUND/INVESTOR/TEMPLATE/TEMPLATE_LEVEL/
FILENAME001\JPMP0355\JPMP035598PRP031501.pdf
FUND/INVESTOR/TEMPLATE/TEMPLATE_LEVEL/
FILENAME002\JPMP0356\JPMP035598PRP031502.pdf
FUND/INVESTOR/TEMPLATE/TEMPLATE_LEVEL/
FILENAME003\JPMP0357\JPMP035598PRP031503.pdf

The record mask should match the parameters for the SetOutputFromExtrFile rule and
the INI options. The setup for this rule varies, depending on the mode you are running
in.

3-step (GenTran, When processing using the GenTran, GenData, and GenPrint programs, you must set
GenData, and GenPrint) the INI options for the GenPrint program as shown here:
< Print >
RCBDFDField = PDFNAME
CallBackFunc = MultiFilePrint
MultiFileLog = ..\data\MFP.LOG

You can use the CUSMultiFilePrint function instead of the MultiFilePrint function, if you
want to control the file name.
The CUSMultiFilePrint function is a print callback function that creates a new output file
for each recipient and creates a log record of each. This is similar to the MultiFilePrint
callback function in GenPrint except it gives you more control over the name of the file
and supports long file names.

218
SetOutputFromExtrFile

The system assumes you will use a built-in INI function to create a unique file name
each time. This is important because the callback function cannot assign the first file
name. You can use a DAL function to assign the first file name. Here is an example of
the INI options:
< Printer1 >
Port = ~DALRUN Batch1Files.dal
< Print >
CallbackFunc = CUSMultiFilePrint

Here is an example of a DAL script:

#counter = #counter
file_name = "cusmultifileprint" & #counter & ".pdf"
#counter = #counter+1
return (file_name)

Please note that this function is used for multi-step processing only.

2-step (Single-step When you use single-step processing but omit the PrintFormset rule and instead use
processing without the the GenPrint program, you must include the Print control group options:
PrinfFormset rule and
< Print >
with GenPrint)
RCBDFDField = PDFNAME
CallBackFunc = MultiFilePrint
MultiFileLog = ..\data\MFP.LOG

Here is an example of the AFGJOB.JDT file you would use:

;NoGenTrnTransactionProc;2;required to combine GenTran/GenData;
;WriteRCBFiles;2;;
;ResetOvFlw;2;;
;BuildFormList;2;;
;LoadRcpTbl;2;;
;RunSetRcpTbl;2;;
;BatchingByRecipINI;2;;;
;SetOutputFromExtrFile;2;35,FILENAME 47,128,PDFNAME;
;WriteOutput;2;;
;WriteNaFile;2;;
;ProcessQueue;2;PostPaginationQueue;
;PaginateAndPropagate;2;;

Be sure to include the WriteOutput, WriteNAFile, and WriteRCBFiles rules.

219
Chapter 3
Job and Form Set Rules Reference

Single-step (GenData When you use single-step processing, the system does not use a callback function.
only) Instead, it uses the MultiFilePrint INI option in the PrintFormset control group.
In single-step mode, you must have these INI options:
< PrintFormset >
RCBDFDField = PDFNAME
MultiFilePrint = Yes
LogFileType = Text (or XML)
LogFile = mfp.log

NOTE: The MultiFilePrint option should only be used with the PDF, RTF, HTML, and
XML print drivers.

Here is an example of the AFGJOB.JDT file you would use:

;NoGenTrnTransactionProc;2;required to combine GenTran/GenData;
;ResetOvFlw;2;;
;BuildFormList;2;;
;LoadRcpTbl;2;;
;RunSetRcpTbl;2;;
;SetOutputFromExtrFile;2;35,FILENAME 47,128,PDFNAME;
;WriteOutput;2;;
;WriteNaFile;2;;
;BatchingByRecipINI;2;;
;PrintFormset

Example ;SetOutputFromExtrFile;2;39,FILENAME 51,128,PDFNAME;

In this example, 39,FILENAME is a record mask which tells the system to locate the
record line that includes string FILENAME at offset 39. The text, 51,128,PDFNAME tells
the system to get the print batch file name at offset 51 in maximum length of 128 and
save it to a global variable named PDFNAME. Note that PDFNAME must be defined in
the RCBDFDFL.DFD file as a field.

When running multi-step mode, although UpdatePOLFile rule does pagination,

you must still include the PaginateAndPropagate rule in your AFGJOB.JDT file, as
pagination is needed before the SetOverflowPaperTray rule executes and before
the NA and POL files are updated. Here is how the rules should be placed:
;UpdatePolfile;;
;SetOverflowPaperTray;;
;PaginateAndPropagate;;

• In duplex printing mode, the first page prints on stock from the original specified
paper tray (for instance, containing perforated paper). If an overflow condition
occurs and additional pages are printed; because you are duplexing, the first
overflow page will print on the backside of the first page (on the perforated paper).
The system redirects any additional overflow pages (pages 3, 4, and so on) to the
paper tray you specify using the OverflowPaperTray control group.

221
Chapter 3
Job and Form Set Rules Reference

• In simplex printing mode, the first page prints on stock from the original specified
paper tray (for instance, pre-printed color letter head). If an overflow condition
occurs, additional pages are printed on stock from the redirected paper tray you
specify using the OverflowPaperTray control group.
• This rule will not work when printing in duplex mode and the first page is set as a
back page.

Example Let’s assume your FORM.DAT file specifies duplex printing, tray 2 for all images, and
this INI option:
< OverflowPaperTray >
UtilBill = tray4

This tells the system to use stock from tray 2 to print the first two pages (duplex) and
stock from tray 4 for the subsequent pages 3 and 4 (duplex). Here are examples of the
FORM.DAT and POLFILE.DAT files:
FORM.DAT file:
;RP10;CIS;UtilBill;Utility;N;;\
billhdrp|FDLONX <Customer(1)>/\
billsum |RDLS <Customer(1)>/\
billftr |RDLS <Customer(1)>/\
billrwtr|RDLS <Customer(1)>/\
billsere|RDLS <Customer(1)>/\
billstbr|RDLS <Customer(1)>/\
billrswr|RDLS <Customer(1)>/\
billcwt3|RDLS <Customer(1)>/\
blchart |RDLS <Customer(1)>;

Here is a simplex printing example:

Assume your FORM.DAT file specifies simplex printing, lower/tray 2 for all images, and
this INI control group:
< OverflowPaperTray >
InsurBill = tray4

This tells the system to use the stock from tray 2 to print the first page and stock in tray
4 for the subsequent pages 2 and 3. Here are examples of the FORM.DAT and
POLFILE.DAT files:
FORM.DAT file:

222
SetOverflowPaperTray

Syntax ;SetOvFlwSym;;OverflowSymbol, ImageName, MaxRecords;

Parameter Description

OverflowSymbol Name of the overflow symbol defined in the SetOvFlwSym rule.

ImageName Name of the image that contains the fields on which overflow
processing will occur.

MaxRecords Defines the maximum number of overflow records to be processed

for the image per page of output.

Example ;SetOvFlwSym;;Symbol,ImageName,10;
This example tells the system to define an overflow variable named Symbol for use
with the image named ImageName, which has a maximum records per page of 10.
Another example of this rule is:
;SetOvFlwSym;;CGDECBDOVF,Q1GDBD,5;
This example tells the system to define an overflow variable named CGDECBDOVF for
use with the form Q1GDBD, which has the maximum records per image set to five.

NOTE: The SortBatches rule is not available for z/OS implementations.

Syntax ;SortBatches;;;
The SortBatches rule provides two ways to sort batches:

• Single key
This is the default sort for running under Windows. This sort command uses the
Windows command line sort and builds an RCB file with a prepended sort key. Use
this method if the external sort program uses a single sort field.

• Multiple keys
Use this method when you need to create a sort command with a repeating pattern
for each sort field.
Depending on the size of the recipient batch file, performance can be affected. The
larger the input file, the slower the performance.
The SortBatches rule performs the required initial logic before the main job execution
and executes the external sort program after execution. Place this rule immediately
before the JobInit1 rule in your AFGJOB.JDT file, as shown here:
;RULStandardJobProc;;Always the first job level rule;
;SetErrHdr;;***:------------------------------------------------;
...
;SortBatches;;;
;JobInit1;;;

Specifying Key fields

Define the key fields for the sort in SortBatches control group. Any field defined in the
RCB DFD file can be used as a sort field. Each batch can have its own sort fields defined.
You can also define a default sort (“SortDefault)”. If you do not define a default sort,
you must define a sort for each batch file written.
Here is the format of a SortBatches INI entry:
Batch Abbreviation = Field Name (A or D; Ascending or Descending)

Separate field references with semi-colons (;).

Here is an example:
< SortBatches >
SortDefault = ACCOUNT_NUMBER(A);COMPANY(A);FEAT_DESCR (A)
RegPrt = FEAT_DESCR(A);ACCOUNT_NUMBER(A)
In this example, the batch RegPrt will be sorted by CUSTOMER_NAME, FEAT_DESCR
and ACCOUNT_NUMBER. All other batches will be sorted by COMPANY, FEAT_DESCR
and ACCOUNT_NUMBER.

227
Chapter 3
Job and Form Set Rules Reference

Sorting with a Single Key

To make it easier to set up and to support external sorts with only one key, a sort file
with the with single key prepended is written and sorted by the external sort program
when you use the BuildSortKey option. The batch file is written in the specified order
without the prepended keys. The descending option (d) does not work with an external
sort that does not support binary sorting.
Here is an example of how to set up your INI options for a single key sort. You specify
the format of the external sort command using the options in the SortBatchOptions
control group. This example calls the Windows command line sort:
< SortBatchOptions >
BuildSortKey = Yes
SortCommand = SORT **SourceFile** /t **WorkPath** /o
**TargetFile**

NOTE: The default for the BuildSortKey option is Yes on Windows and No on other
platforms.

This is the default sort for running under Windows. “**SourceFile** /t **WorkPath** /
o **TargetFile**” are replacement strings that are replaced with the appropriate values
when the command line string is created. See Replacement Strings on page 230 for a
complete list of available replacement strings.
These SortBatchOptions would produce the following sort command:
SORT .\data\REGPRT.tmp /t .\data\ /o .\data\REGPRT.wrk

Sorting with Multiple Keys

When you sort with multiple keys, the system does not use an interim file with a
prepended key. Instead it writes a temporary batch file for input into the external sort.
The SortCommand specified here calls a GNU Sort:
< SortBatchOptions >
BuildSortKey = No
SortCommand = sort -o **TargetFile** *{[[ ]] -k **FieldOffset**,
**FieldLength** }* **SourceFile**

The data between the “*{“ and “}*” (in bold) is replicated for each sort field specified
in the sort batches entry. The data between the “[[“ and “]]” is used as a field
separators.
SortCommand = sort -o **TargetFile** *{[[ ]] -k **FieldOffset**,
**FieldLength** }* **SourceFile**

**FieldOffset** and **FieldLength** are replacement strings you can use inside a
repeating section. See Replacement Strings on page 230 for a complete list of available
replacement strings.
Given the sample INI values defined above and the sample RCB DFD file definition, the
generated sort command would appear as follows:
sort -o .\data\AGENT.wrk -k 1,22 -k 23,4 -k 27,45 .\data\AGENT.tmp

Sorting with an OptTech OTSort by OptTech is a third-party sort utility. Here is an example of how you could set
Sort the SortCommand options to execute OTSort with the SortBatches rule:

228
SortBatches

< SortBatchOptions >

BuildSortKey = No
SortCommand = OTSW32D **SourceFile** **TargetFile** /
S(*{[[,]]**FieldOffset**,**FieldLength**,**FieldType**,**SortType**
}*)

INI Options
You can use these INI options with this rule:
< SortBatches >
BatchFileName =
SortDefault =
< SortBatchesOptions >
BuildSortKey =
SortCommand =
LogSortCommand =
KeepOrgFile =
ZeroBasedOffsets =
< SortBatchSortTypes >
a =
b =
< SortBatchFieldTypes >
Long =
Char_Array =

Defining the sort Use the options in the SortBatches control group to specify the name of the batch file and
the fields you want to sort by.

Option Description

BatchFileName Enter the name of the batch file.

SortDefault Enter the fields you want to sort by plus A for an ascending sort or
D for a descending sort. The default is:
ACCOUNT_NUMBER(A);COMPANY(A);FEAT_DESCR (A)

Sorting options You specify all processing options for the SortBatches rule in the SortBatchOptions
control group.
< SortBatchOptions >
BuildSortKey =
LogSortCommand =
KeepOrgFile =
ZeroBasedOffsets =

229
Chapter 3
Job and Form Set Rules Reference

Option Description

BuildSortKey Enter Yes to specify single key processing. The default on Windows
is Yes. The default on UNIX is No.

LogSortCommand Enter Yes to send a copy of the sort command and associated sort
options to the trace log file. The default is No.

KeepOrgFile Enter Yes to write the original batch files in an unmodified format.
The sorted batch files are written with an SRT extension. The default
is No.

ZeroBasedOffsets Enter Yes to use zero based offsets. The default is No.

Overriding the sort type By default, the field-level sort type is written as a for ascending and d for descending.
You can override these default values using the SortBatchSortTypes control group:
< SortBatchSortTypes >
a = Replacement_Ascending_Type
d = Replacement_Descending_Type

Overriding the field type Field types are based on the internal field type defined in the RCB DFD (INT_TYPE). By
default their types are set to c for character fields or n for numeric fields, but you can
override these values. In the example below, fields defined as LONG have a field type
of “num” and fields defined as CHAR_ARRAY have a field type of “char”.
< SortBatchFieldTypes >
Long = num
Char_Array = char

Replacement Strings
Here is a list of the non-repeating section replacement strings:

Replacement string Description

TargetFile The sort target file.

SourceFile The source file name.

Key Length The sort field length.

BeginOffset The sort field begin offset.

EndOffset The sort field end offset.

WorkPath The location for temporary file (uses DataPath).

Here is a list of the repeating section replacement strings:

230
SortBatches

Replacement string Description

FieldOffset The field offset in the RCB file.

FieldLength The field length.

FieldType The field type (c or n based on INT_TYPE, values can be

overridden).

SortType The Sort type (a or d, values can be overridden).

RCB file layout Here is the RCB file layout used in these examples:
< FIELDS >
FIELDNAME = ACCOUNT_NUMBER
FIELDNAME = FEAT_DESCR
FIELDNAME = COMPANY
FIELDNAME = APPLICATION
FIELDNAME = CUSTOMER_NAME
FIELDNAME = TRN_Offset
FIELDNAME = X_Offset
FIELDNAME = NA_Offset
FIELDNAME = POL_Offset
...

< FIELD:COMPANY >

INT_TYPE = CHAR_ARRAY
INT_LENGTH = 5
EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM
EXT_LENGTH = 4
KEY = Y
REQUIRED = Y

< FIELD:APPLICATION >

INT_TYPE = CHAR_ARRAY
INT_LENGTH = 4
EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM
EXT_LENGTH = 3
KEY = Y
REQUIRED = Y

< FIELD:ACCOUNT_NUMBER >

INT_TYPE = CHAR_ARRAY
INT_LENGTH = 23
EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM
EXT_LENGTH = 22
KEY = Y
REQUIRED = Y

< FIELD:FEAT_DESCR >

INT_TYPE = CHAR_ARRAY
INT_LENGTH = 46
EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM
EXT_LENGTH = 45
KEY = N

231
Chapter 3
Job and Form Set Rules Reference

REQUIRED = N

< FIELD:CUSTOMER_NAME >

INT_TYPE = CHAR_ARRAY
INT_LENGTH = 37
EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM
EXT_LENGTH = 36
KEY = N
REQUIRED = N
...

This rule is used in single-step processing. The RULStandardFieldProc rule is

used in multi-step processing.

Syntax ;StandardFieldProc;;;
There are no parameters for this rule.
If the field has not yet been loaded, this rule loads it and then determines what type of
field it is. If the field is not a text area, this rule sets the field data. If field is not a bar
code or a text area, the rule sets field text.
If the field is a bar code, this rule validates and stores the bar code data. If there is an
error with the data, the system writes a warning message to the error file, sends the
transaction to the manual batch and continues the processing run.

Example ;StandardFieldProc;;;

NOTE: This rule is used in single-step processing. The RULStandardImageProc rule is

used in multi-step processing.

Syntax ;StandardImageProc;;;
There are no parameters for this rule.
This rule sets the next image. If there are no more images, the system returns the
message; msgNO_MORE_IMAGES.
If an error occurs, the system writes the following message in the error file and returns
an error code:
Error in StandardImageProc(): Unable to SetNextImage(pRPS).
If it finds another image, the rule checks to see if the image has a corresponding DDT
file and, if so, loads into memory the image and field rules included in that file.

Example ;StandardImageProc;;;

• When running NoGenTrnTransactionProc (single or two-step mode) and the INI

option is set to load the XML file, so there is no need to place XMLFileExtract rule
in the AFGJOB.JDT file. Doing so makes the system load the XML file twice.

Mapping Fields
You can map TRN_Fields fields using the Ext2GVM rule or by using XPath.

Using Ext2GVM When you use the Ext2GVM rule to get key information, make sure you only include the
Key1, Key2, and KeyID options it the TRN_Fields control group. Set these options to
dummy data, because the GVM variables are set to the data values during GenData
processing.
To re-map these values from the global variables you get using Ext2GVM rule to the
RPS structures (GroupName1, GroupName2, and GroupName3), include this rule in the
AFGJOB.JDT file:
ResetDocsetNames;;ConvertBeforeReset;

The ConvertBeforeReset parameter gets the GroupName values from global memory
and converts them to the long values using the Key1Table and Key2Table control
groups.
Here is an example of the INI options:
< TRN_File >
Company = 3,3,N
LOB = 3,3,N
PolicyNum = 3,3,N

Here is an excerpt from the AFGJOB.JDT file:

;Ext2GVM;;!/Forms/Key1 1,10,Company;
;Ext2GVM;;!/Forms/Key2 1,15,LOB;
;Ext2GVM;;!/Forms/PolicyNum 1,12,PolicyNum;
;ResetDocsetNames;;ConvertBeforeReset ;

Using XPath When you use XPath to map to the fields in the TRN_Fields control group, be sure to
place an exclamation mark (!) in front of the XPath. Here is example:
< TRN_Fields >
Company = !/Forms/Key1
LOB = !/Forms/Key2
PolicyNum = !/Forms/PolicyNum
RunDate = !/Forms/RunDate;DM-4;D4

239
Chapter 3
Job and Form Set Rules Reference

The format for the options in the TRN_Fields control group is:
(Field in the transaction DFD file) = XPath;Field Format

Although the exclamation mark (!) is not part of the actual search routine, the XML path
search must begin with an exclamation mark. Do not specify whether a field is a key.
The system does not support a multiple (search) keys with the XML implementation.
To selectively exclude transactions, place the XPath with a leading exclamation mark
of what you want to exclude in your exclude file. Here is an example:
!/Forms[PolicyType="OLD"]

Overflow in XML
Here is how overflow works in XML. First, the system scans the search text to see if a
replacement is needed for the overflow value. Here is one approach:
@GETRECSUSED,IMAGE1,STARS/!/Forms/Form/Car[****]/Driver

The system inserts the current overflow value, then performs the actual XML search for
the requested XPath.
With the following approach, you can omit the use of @GETRECSUSED to declare which
overflow variable to use and instead include the overflow name directly into the XPath,
as shown here:
!/Forms/Form/Car[**INDEX**]/Driver
This method lets you support overflow within overflow.
Be aware that with either method, you still have to declare and use the overflow
variables. The difference is that for the second method [**OverFlowSymbol**], the
form name has to be XML, while for the first example [****], the form name is the actual
name of the image for which you created the overflow symbol.
Also, remember to include the IncOvSym rules at the image level in the DDT file to
increment the values to the next index. When doing overflow within overflow, you may
also have to include an additional dummy image to do the IncOvSym for the symbol
that represents the outer-most loop index.

• WIPTransactions – This rule replaces the RULStandardTransactionProc or

NoGenTrnTransactionProc rules in the AFGJOB.JDT file. This rule starts GenData
WIP Transaction Processing at the form set level. It also identifies the status codes
for the transactions in the WIP file that are processed. The status codes can be a
subset or all of the status codes identified on the MergeWIP rule or none.
• GVM2GVM - This rule copies GenData execution data from the Trigger2WIP INI
control group.
• WIPImageProc – This rule replaces the RULStandardImageProc or
StandardImageProc rule.
• MergeWIP - This rule initializes GenData execution of WIP Transaction Processing
at the job level. It creates a memory list and adds the transactions from the WIP
file that match the status codes in its parameters.
Using these rules in a simplified AFGJOB.JDT file and with appropriate INI files, GenData
WIP transaction processing adds the transactions from a WIP file to a transaction
memory list. It then processes the transactions from the memory list, appending the
data from the WIP file to the MRL recipient batch, NewTrn, NA, and POL files. If these
files do no exist, it creates them. Each transaction in the memory list is deleted from
the WIP file after it is processed.

Syntax ;WIPFieldProc;;;
There are no parameters for this rule.

Example ;WIPFieldProc;;;

• WIPTransactions – This rule replaces the RULStandardTransactionProc or

NoGenTrnTransactionProc rules in the AFGJOB.JDT file. This rule starts GenData
WIP Transaction Processing at the form set level. It also identifies the status codes
for the transactions in the WIP file that are processed. The status codes can be a
subset or all of the status codes identified on the MergeWIP rule or none.
• GVM2GVM - This rule copies GenData execution data from the Trigger2WIP INI
control group.
• MergeWIP - This rule initializes GenData execution of WIP Transaction Processing
at the job level. It creates a memory list and adds the transactions from the WIP
file that match the status codes in its parameters.
• WIPFieldProc – This rule replaces the RULStandardFieldProc or StandardFieldProc
rule.
Using these rules in a simplified AFGJOB.JDT file and with appropriate INI files, GenData
WIP Transaction Processing adds the transactions from a WIP file to a transaction
memory list. It then processes the transactions from the memory list, appending the
data from the WIP file to the MRL recipient batch, NewTrn, NA, and POL files. If these
files do no exist, it creates them. Each transaction in the memory list is deleted from
the WIP file after it is processed.

Syntax ;WIPImageProc;;;
There are no parameters for this rule.

Example ;WIPImageProc;;;

NOTE: Do not use this rule with the RULStandardTransactionProc or

NoGenTrnTransactionProc rule.

The following rules are also used with this rule:

• MergeWIP - specifies the codes to look for

• GVM2GVM - copies the data from one GVM variable to another
• WIPImageProc - used in place of RULStandardImageProc or StandardImageProc
• WIPFieldProc - used in place of RULStandardFieldProc or StandardFieldProc
Using these rules in a simplified AFGJOB.JDT file and with INI options, you can input or
merge WIP transactions (manually approved or rejected in Documaker Workstation)
into a GenData processing run as new data or data appended to an existing GenData
processed MRL (one that already has NEWTRN.DAT, NAFILE.DAT, and POLFILE.DAT
files). These new or merged transactions can then be printed, archived, or both.
For instance, a typical use of these rules would is to take the results of a GenData run
(NEWTRN.DAT, NAFILE.DAT, POLFILE.DAT, and print batch files) and process those files
using the GenWIP program. You then open in the Documaker Workstation transactions
sent to WIP and manually approve or reject them. Next, you run those WIP transactions
(form sets) through the GenData process. The result is files ready for the GenPrint and
GenArc programs.

Syntax ;WIPTransactions;;StatusCode1,StatusCode2,...;
Use the StatusCode parameters to define the status codes you want the system to use
as it selects the WIP transactions to process.
After a transaction is processed, the system deletes it from the WIP list.
If you include a slash (/) before the StatusCode parameter, it tells the system not to
delete the transactions with that status after it processes then, but instead assign
them a new status. Here is an example:
;WIPTransactions;;APPROVED,FINAL,/PRINTED;

243
Chapter 3
Job and Form Set Rules Reference

In this example, the slash (/) tells the system to process WIP transactions with an
APPROVED or FINAL status and then change their status to PRINTED. The WIP
transactions are not deleted.

Example ;WIPTransactions;;Approved;
Here is an example of how to define the codes in the Status_CD control group:
< Status_CD >
Approved = AP
Rejected = RJ

If the batch system does not need to process transactions with a certain code, such as
Rejected, omit that code from the parameter list for this rule. When the system
encounters a code not on the list, it deletes that transaction.

Here is an example of a AFGJOB.JDT file you could use:

Be sure to include the WriteOutput and WriteNAFile rules.

offsetofmask the offset of the search mask

offsetofdata the offset where the path and the file name start

lengthofdata the length of the file name

• GVM=<globalvariablename>
Where globalvariablename is the name of a GVM that contains the file name.
Here are examples of how you can use this rule:
;XMLFileExtract;2;FILE=SAMPCO.XML;
;XMLFileExtract;2;INI=Group,Option;
;XMLFileExtract;2;SCH=11,FILENAME 20,20;
;XMLFileExtract;2;GVM=FileNameVar;

Keep in mind...

• Begin each XML transaction with the XML declaration.

• In the RunMode control group, set the XMLExtract option as shown here:
< RunMode >
XMLExtract = Yes

• You place the rule in different locations in the AFGJOB.JDT file, depending on the
mode in which you are running. For multi-step mode, place the XMLFileExtract rule
after the LoadExtractData rule, as shown here:
;LoadExtractData;;
;XMLFileExtract;2;FILE=SAMPCO.XML;

250
XMLFileExtract

For single or two-step mode, place the XMLFileExtract rule after the
NoGenTrnTransactionProc rule, as shown here:
;NoGenTrnTransactionProc;;
;XMLFileExtract;2;FILE=SAMPCO.XML;

• Remember that the system decides whether to search the extract list or the XML
tree by checking to see if the search mask starts with an exclamation mark (!). The
exclamation mark indicates that this is an XML path string. The system ignores the
exclamation mark when it performs the XML path search.
To preserve the space when mapping data, use two exclamation marks (!!).
Otherwise, the system assumes it should remove the leading white space.

• When running NoGenTrnTransactionProc (single or two-step mode) and the INI

option is set to load the XML file, so there is no need to place XMLFileExtract rule
in the AFGJOB.JDT file. Doing so makes the system load the XML file twice.

Mapping Fields
You can map the fields listed in the TRN_Fields control group using either offset/
length, XPath, or a combination of both methods. In the RunMode control group, be
sure to set these INI options:

Option Description

XMLExtract Enter Yes to tell the system you are using the XML file.

XMLFileExtract Enter Yes to tell the system your extract file contains a list of
pointers pointing to the XML file to be processed.

XMLFileExtractName Use this option to tell the system how to find your XML file. Enter
the method you use to point to your XML file. This should be
exactly the same as how you would set up the rule parameter for
the XMLFileExtract rule in your AFGJOB.JDTfile.

Here is an example:
< RunMode >
XMLExtract = Yes
XMLFileExtract = Yes
XMLFileExtractName = SCH=1,XML 20,60

Also set the TRN_Fields options as shown in this example:

< TRN_Fields >
Company = !/Forms/Key1
PolicyNum = !/Forms/PolicyNum
RunDate = !/Forms/RunDate;DM-4;D4
LOB = 30,15,N
Cust_Name = 46,30,N

The format for the options IN the TRN_Fields control group is:
(Field in the transaction DFD file) = XPath;Field Format
(Field in the transaction DFD file) = offset, length, Key;Field Format

251
Chapter 3
Job and Form Set Rules Reference

An XML path search must begin with an exclamation mark (!). The exclamation mark is
not part of the actual search routine. Do not specify whether a field is a key. The system
does not support a multiple (search) keys with the XML implementation.
To selectively exclude transactions, use either an offset/SearchMask, the XPath, or a
combination of the two in your exclude file. Here is an example:
!/Forms[PolicyType="OLD"]
20,ABC

This method lets you support overflow within overflow.

Be aware that with either method, you still have to declare and use the overflow
variables. The difference is that for the second method [**OverFlowSymbol**], the
form name has to be XML, while for the first example [****], the form name is the actual
name of the image for which you created the overflow symbol.
Also, remember to include the IncOvSym rules at the image level in the DDT file to
increment the values to the next index. When doing overflow within overflow, you may
also have to include an additional dummy image to do the IncOvSym for the symbol
that represents the outer-most loop index.

NOTE: You create variable fields using Documaker

Studio or the Image Editor. For more
information, see the Documaker Studio User
Guide or the Docucreate User Guide.

The image and field level rules are executed during

data generation and merger procedures. This occurs in
Documaker Server.
This chapter explains how to add, remove, and edit
rule assignments. It also explains how to generate
information reports. You should only set up rules if you
fully understand mapping procedures, rules, and if you
are using Documaker Server.
In this chapter you will find information about:

• Storing Rule Information on page 254

• Using the Data Definition Table on page 255
• Setting Up the MASTER.DDT File on page 257
• Assigning Rules with the Image Editor on page
265
• Formatting Data on page 278
• Search Criteria on page 290
• Overflow and User Functions on page 291
For reference information on individual rules, see
Chapter 5, Image and Field Rules Reference on page
294.

253
Chapter 4
Adding Image and Field Rules

STORING RULE Documaker Studio stores you image in a FAP file, along with the image and field rule
assignments you assign to it. This differs from the way rule information was stored in
INFORMATION the older document creation tool, Image Editor.
The Image Editor stores your image in a FAP file. FAP files created with Image Editor
only contain the image's objects and object attributes. The Image Editor stores image
and field rule assignments in a separate file, called a data definition table (DDT) file.

One Image Two Files

xxxxxxxxx Image 1
xxxxxxxxx
xxxxxxxxx contains image objects
FAP File and attributes
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxx xxxx
contains rule
DDT File assignments

Remember, as you assign rules with the Image Editor you affect the DDT file, not the
FAP file.
While DDT files were created to achieve a higher degree of performance in simpler
implementations, advanced formatting capabilities made it necessary for the FAP files
to be available at runtime to handle dynamic composition and the DDT file approach
became less of an advantage, and even a stumbling block within some
implementations.
With the release of version 11.0 and the introduction of Documaker Studio’s FOR file,
image and field-level DDT rules previously stored in the DDT file are, in Studio
implementations, either unnecessary or are stored in the FAP file. Having image level
rules (such as SetOrigin) in the FOR file makes it easier to do visual form design. Having
field level rules in the FAP file eliminates synchronization worries.

254
Using the Data Definition Table

USING THE DATA The system stores your image and field level rule assignments in a separate, semi-
colon delimited file called a data definition table (DDT). This file contains all the rule
DEFINITION TABLE assignments that apply to a specific image. The system creates the DDT file and stores
it in the master resource library.

NOTE: The Image Editor stores the image in a FAP file and it stores the image rule
assignments in a DDT file. The file names correspond, but the extensions
differ, for example, IMAGE.FAP and IMAGE.DDT. Storing information
separately makes it easier to apply and modify rules. This also helps the
system process your information faster.

You can set up image and field rules directly in the DDT file using any ASCII text editor
or you can use the Image Editor to make the same assignments. For information on
using the Image Editor, see Assigning Rules with the Image Editor on page 265.
In the DDT file examples below, each semicolon delimited field represents a distinct
piece of variable field formatting, mapping, or data information. There are several
levels of rules:

• Field Rules - Field rules affect individual fields on an image. These rules are stored
in the DDT file, along with the image rules. You run field level rules by including
the rule in an image's DDT file under the <Image Field Rules Override> section.
• Image Rules - Image rules are stored in the DDT file. These rules affect specific
images. Image rules associate the rule name with the data required by the rule.
You run image level rules by including the rule in an image's DDT file under the
<Image Rules> section.
Here is an example of the DDT file format:
<Image Rules>
;IMAGERULE;IMAGERULEDATA;
;IMAGERULE;IMAGERULEDATA;

<Image Field Rules Override>

;#1;#2;#3;#4;#5;#6;#7;#8;#9;#10;#11;#12;#13;#14;#15;#16;#17;#18

Where:
In the <Image Rules> section:
IMAGE the Image rule name
IMAGERULEDATA the data required by the Image rule

255
Chapter 4
Adding Image and Field Rules

In the <Image Field Rules Override> section:

#1 the source file number
#2 the source record index number in the record section
#3 the source field name
#4 the source field offset
#5 the source field length
#6 the destination field name
#7 the destination field offset
#8 the destination field length
#9 the field format mask
#10 the field rule name (DDT rule)
#11 the data for the field rule
#12 flag 1 (not required)
#13 flag 2 (host required)
#14 flag 3 (operator required)
#15 flag 4 (either required)
#16 x offset
#17 y offset
#18 font

Line #11 contains the data for the field rule. This data varies, depending on the rule. The
data can consist of the following, in the order shown below:
Search Criteria, Extract Field Descriptors, Additional Parameters
For some rules, the data field (#11) is empty, such as for the Master and KickToWip
rules. For other rules, the data field can consist of only search criteria, such as for the
SetState or Move_It rules (when used without overflow data).
Each item must be separated by a single space—no other spaces are allowed. If the
rule supports overflow, you should place the overflow data before the search criteria.

NOTE: For details about overflow, see Overflow and User Functions on page 291. For
more information about search criteria, see Search Criteria on page 290.

The way the delimiters are used in rules is almost the same. There are four types of
delimiters, as shown here:

Delimiter Description

space A single space separates different groups of data as mentioned above.

backslash (/) A backslash separates overflow data and other data.

colon (:) A colon separates conditions in rules such as PrintIf and PrtIfNum. It is
also used to separate two dates in the rule, such as in the DateDiff rule.

comma (,) A comma is used in search criteria to delimit offset and data. It is also
used to separate extract field descriptors, such as offset and length.

256
Setting Up the MASTER.DDT File

SETTING UP THE The MASTER.DDT file helps you save time by letting you set up common fields used on
many forms. For instance, if you have a field called Name which appears on many
MASTER.DDT forms, you can use the MASTER.DDT file to set it up once and then use that information
FILE as necessary.
For instance, suppose you have an image named MYIMAGE.FAP, which has a
corresponding DDT file named MYIMAGE.DDT.
In MYIMAGE.DDT you have a field called Name. For the Name field, you select the rule,
Master. This tells the system to look in the MASTER.DDT file for a field called Name and
use the settings for length, rule, mask, data, and so on, stored there.
To use this capability, follow these steps:
1 Select the Edit, Master DDT option in Docucreate to open the MASTER.DDT file and
map the extract data to the variable fields in the MASTER.DDT file.
2 In the individual DDT files, enter either blank or master in the Rule field. The
variable name must be the same in the master and subordinate DDT files.
3 In the AFGJOB.JDT file, add this rule:
;LoadDDTDefs;;;

Taking precedence If a field in the FAP file is specified in the master DDT, the system uses the information
in the master DDT.
When using the master DDT during rules processing, every field defined in a DDT file
will fill in any blank item (or zero in the case of numeric items) from the matching
master template for that field. So any field rule component that you leave blank, or
zero, will be filled in from the master DDT if that field is declared within the master DDT.
Image DDT lines that specify Master as the rule or have no rule specified also accept
the rule from the master DDT. But like all other DDT rules, if a rule name other than
Master is specified in the DDT, it will be used. Here are some examples.
Suppose the master DDT contains these lines:

;0;0;NAME;25;50;NAME;0;50;;move_it;11,INSNAMREC;N;N;N;N;0;0;15412
;0;0;PRICE;15;10;FINAL

Now suppose the image DDT contains these lines.

;0;0;NAME;0;0;;0;0;;master;;;;;;12400;2340;0
;0;0;PRICE;0;0;PRICE;0;10;;movenum;;N;N;N;N;13330;1900;12310
;0;0;LOCATION;75;50;LOCATION;0;50;;move_it;;N;N;N;N;14100;2100;0
;0;0;STATE;0;0;;0;0;;;;;;;;0;0;0

After the master template is applied, the image DDT rules would look like this:

;0;0;NAME;25;50;NAME;0;50;;move_it;11,INSNAMREC;N;N;N;N;12400;2340;15
412
;0;0;PRICE;15;10;PRICE;0;10;C,10.2;movenum;11,INSNAMREC;N;N;N;N;13330
;1900;12310

Note the items in bold.

257
Chapter 4
Adding Image and Field Rules

The rule line for field NAME was basically blank in the DDT and specified Master as the
rule. Therefore, any item left blank, or zero, was filled in from the matching NAME field
in the master DDT. In addition, the rule name of Master was replaced with the rule
name from the template.
The rule line for field PRICE does not specify the Master rule. Note, however, that the
zero and blank items were still filled in from the master template. In this example, that
included the source offset and length, the field rule flags, and the search mask data.
Also look at the required flags. In the master DDT for this field, these items are
specified as ;N;Y;N;N; but because the image DDT was not left blank for those items
(;N;N;N;N;), they did not get copied and were left intact. Also note that the Source Field
name FINAL PRICE was not copied into the image DDT line, because data PRICE already
occupied that space on the image DDT line.
For the field LOCATION, nothing about the Image DDT line changed because the field
does not occur in the master DDT.
For the field STATE, nothing on the DDT line changes because it does not appear in the
master DDT. But unlike the field LOCATION, because the rule name was specifically
declared as Master, it was expected to be found in the Master. This will cause an error
indicating that the field was missing in the master DDT.

258
Setting Up the MASTER.DDT File

USING THE MASTER DDT EDITOR

You can use the Master DDT Editor to work with your master DDT file. This tool only
edits the Master DDT file. You cannot use it to edit other DDT files.
The Master DDT Editor presents the information stored in the Master DDT file in a
spreadsheet-like format, as shown below. You can use the various menu options to
view a report, save your work, make changes, move assignments up or down, and
perform other tasks.
The following topics discuss the tasks you can perform using the menu option for the
Master DDT Editor.

Using the File Menu

The File menu options let you save your changes, generate a report that documents all
field rule assignments in the master DDT file, or exit the Master DDT Editor. To display
the File menu, choose File. The File menu appears.

Saving your work The system saves your work as you move through the rows displayed on screen. You
can also use the Save option to save all of the additions, changes and deletions you
make to rule assignments in the Master DDT file.
To save rule assignments, choose File, Save.

Viewing the Rules Report The View Rules Report option shows you a listing of all fields in the DDT file and
pertinent information about each field. The listing shows the information in a tabular
fashion. The variable fields' offsets, lengths, assigned rules, and data requirements
appear.

259
Chapter 4
Adding Image and Field Rules

The system creates this report from data stored in memory when you open the Master
DDT Editor. To view the Rules Report, choose File, View Rules Report. The Rules Report
appears.

Image name
To close the
report, click
here.

Variable fields

Offsets and lengths Rules

After you finish viewing the rules report information, you can close the report by double
clicking on the icon in the top left corner of the window.

Exiting the Master DDT To exit the Master DDT Editor, choose File, Exit.
Editor

260
Setting Up the MASTER.DDT File

Using the Edit Menu

The Edit menu options let you change, insert, copy, or delete rows, and retrieve rule
assignments. To display the Edit menu, choose Edit. The Edit menu appears.

Changing rule Use the Edit, Change option to display the Change window. From this window you can
assignment settings quickly change all of the information for a rule.

You can also access the Change window by double clicking on the row number to the
left of the destination name. This window contains the same fields you see on the
editor window—it's just another way to make changes to an existing rule.
From this window, you can use the Next and Prev buttons to move from row to row.

261
Chapter 4
Adding Image and Field Rules

You can also click Reset to return the various properties back to the original settings.
This however does not revert back to changes made before the file was saved. The
Cancel button also resets the properties, but exits the window too.
Click Ok to save your changes and exit the window.

Inserting a row The Insert Row option lets you insert a blank rule assignment record at the end of the
list. Use Insert Row if you have deleted a rule assignment and you want to add it back
to the rule assignment list or if you want to add more rule assignments.
In very unique situations you can use this option to execute a variable field level rule
without attaching the rule to a field in the image. If you need to execute a rule without
attaching it to an image field, consult your system administrator.
To insert a rule assignment, choose Edit, Insert Row. The Master DDT Editor adds a
blank rule assignment record to the end of the list. The record appears in red. For each
assignment, you must make entries in the Destination Name and Rule fields.

Coping a row The Copy Row option lets you copy an existing rule assignment record to the end of the
list. Use Copy Row if you want to base a new rule assignment on an existing rule
assignment.
To copy a rule assignment, click the variable field row that you want to copy. Choose
Edit, Copy Row. The Master DDT Editor copies the highlighted row and adds it to the
end of the list.

Deleting a row The Delete Row option lets you remove a rule assigned to a field. You remove the field
and its assigned rule from the DDT file not from the FAP file.
1 To delete a rule assignment, click the variable field for which you want to delete a
rule. Choose Edit, Delete Row. The Confirm Delete message appears.
2 Click Yes or No to confirm or cancel the delete.

Retrieving information The Retrieve option lets you retrieve a record from the data dictionary for use in a rule
from the data dictionary assignment. When you choose this option the system creates a list of all the source
name entries in the data dictionary.
After selecting the Retrieve option, you can copy source information from the data
dictionary into your rule assignment. The Master DDT Editor places the information
from the Source Name, Source Offset, Source Length, Record, Required, Rule, Mask,
and Data fields into the current row. The destination name, destination length, and
destination offset information are not copied.

262
Setting Up the MASTER.DDT File

1 To retrieve source information, click within the row assignment where you want to
place source information. Choose Edit, Retrieve. The Retrieve from Dictionary
window appears.

2 Click the source record that you want to retrieve as a rule assignment.

3 Click Ok. The Master DDT Editor places the information from the source record into
the rule assignment.

Using the Move Menu

The Move menu lets you change the sequence of rule assignments. The row number for
the variable field indicates its sequence number. The sequence number defines the
order that the system processes the rule.
To display the Move menu, choose Move. The Move menu appears.

263
Chapter 4
Adding Image and Field Rules

Using the Up option The Up option lets you move a rule assignment up one sequence number at a time. Use
Up when you want to alter the order in which a rule is executed during processing.
To move a rule assignment up, click the variable field rule assignment you want to
move up. Choose Move, Up. The rule assignment moves up one sequence number.

Using the Down option The Down option lets you move a rule assignment down one sequence number at a
time. Use Down when you want to alter the order in which a rule is executed during
processing.
To move a rule assignment down, click the variable field rule assignment you want to
move down. Choose Move, Down. The rule assignment moves down one sequence
number.

264
Assigning Rules with the Image Editor

ASSIGNING RULES Although you can enter rules directly into the DDT file, you will probably find it easier
to set up your image and field level rules as you create the image.
WITH THE IMAGE
You set up image level rules using the Image Properties window. Similarly, you set up
EDITOR field level rules using the field’s Properties window.

ADDING IMAGE RULES

To insert image rules, follow these steps:
1 With the image open, select the Format, Image Properties option. The Image
Properties window appears.

No DDT file has been created

for this image or the option to
automatically update the
DDT file is turned off.
Click here to create or load a
DDT file.

If you have no rules for the image and the option to automatically update the DDT
file is turned off, the system shows the Load DDT button. This lets you create a DDT
file for the image, into which you can add rules.
Also, if you have rules for the image and the option to automatically update the
DDT files is turned off, the system shows the Load DDT button.

NOTE: To turn on or off the option to automatically update the DDT file, choose
Options, Editor Properties while in the Image Editor. Then select the Save tab.

265
Chapter 4
Adding Image and Field Rules

If you have already created and opened a DDT file for the image or the option to
automatically update the DDT file is turned on, the Load DDT button is unavailable
and you see an additional tab named Image Rules, as shown on the following
window.

A DDT file exists and has

been opened for this
image or the option to
automatically update the
DDT file is turned on.
Click here to add,
change, or delete image
rules.

2 Either click the Load DDT button to create or load a DDT file or click the Image
Rules tab. The Image Rules tab appears.

The system assigns a default

sequence number for you.
You can change this number
to change the order in which
the rule appears in the DDT
file and is executed by the
system.

3 On the Image Rules tab, the system automatically assigns the next available
sequence number for you. You can change the sequence number if necessary. Use
the following fields to set up the rule’s parameters.

Field Description

Sequence The number you enter in this field determines where the rule is placed
in the DDT file and the order in which it is processed.

Rule Use this field to select the image rule you want to insert.

Data Enter data necessary to process the rule. Refer to the rule descriptions
for more information about the data necessary for individual rules.

4 Once you set up the information for the rule, click Insert to add the rule to the DDT
file.

266
Assigning Rules with the Image Editor

Changing an Image Rule

The Change button on the Image Rules tab lets you change a rule and its information.
For instance, you can use this button to make changes to the data required for the rule.
1 To make changes to an image rule, select the Image Rules tab. A window similar
to the one shown below appears.

Here you can see the data for

All of the image rules for the the SetOrigin rule.
image are shown here.
Click a rule to substitute
another rule or make
changes to a rule’s sequence
or data.

2 Click the rule you want to change.

To change the sequence of the rule, enter a new number in the Sequence field.
To assign a different rule, select a rule in the Rule field.
To change the data for a rule, click in the Data field and enter the new data.

3 Click Change to record your changes. Click Reset to cancel your changes. Click
Cancel to cancel your changes and return to the Image Editor.

Deleting an Image Rule

Use the Delete button to remove an image level rule assignment. The system removes
the rule from the DDT file. The FAP file is not affected.
1 Select the Image Rules tab and then click the rule you want to delete.
2 Click Delete and then click Yes or No to confirm or cancel the delete.

NOTE: Once you click Delete, you cannot click Reset to cancel the deletion.

267
Chapter 4
Adding Image and Field Rules

ASSIGNING FIELD RULES

You can assign rules to fields two ways:

• Using the Edit DDT tab on the field’s Properties window.

• Using the Edit DDT window.
Using the Edit DDT tab lets you work with a single field, while the Edit DDT window lets
you work with all of the fields on the image at the same time. Choose the approach that
best fits your working habits.

Using the Edit DDT Tab

To insert field rules using the Edit DDT tab, follow these steps:
1 With the image open, double click on the variable field or click once and select the
Format, Object Properties option from the main menu.

NOTE: As with any object. you can also click on the variable field to select it and then
right click to choose the Object Properties option from a pop-up menu.

The field’s Properties window appears.

No DDT file has been

created and opened for
this image or the option to
automatically update the
DDT file is turned off.
Click here to create or load
a DDT file.

NOTE: To turn on or off the option to automatically update the DDT file, choose
Options, Editor Properties while in the Image Editor. Then select the Save tab.

268
Assigning Rules with the Image Editor

If you have already created a DDT file for the image or the option to automatically
update the DDT file is turned on, the Load DDT button is unavailable and you see
an additional tab named Edit DDT, as shown on the following window.

A DDT file exists and has

been opened for this
image or the option to
automatically update the
DDT file is turned on.
Click here to add,
change, or delete a field
rule.

2 Either click the Load DDT button to create or load a DDT file or click the Edit DDT
tab. The Edit DDT tab appears.

The name of the Destination

field is set on the General
tab. This name serves as the
default for the name of the You can enter data for the
source field. rule in this field or you can
click here to enter the data in
a larger window.
Click the Explain Rule button
to see a description of the
rule selected in the Rule
field.
Click the Edit DDT button to
work with a spreadsheet-like
list of all the field rules for
this image.

3 On the Edit DDT tab, use the following fields to supply information about the
destination field.

Field Description

Offset Indicates the position in which the data begins in the destination field.
This field is not a required field.

Length Required. Indicates the number of characters in the destination field.

The system automatically fills this field based on the length of the
variable field.

4 On the Edit DDT tab, use the following fields to define the source field.

269
Chapter 4
Adding Image and Field Rules

Field Description

Name Name of the source field. You can enter the source name by entering
the name or by clicking the Name button. This button lets you retrieve
and insert source names and associated source information from the
data dictionary file. Assigning a source name to specific source
information gives you a shortcut retrieval method and eliminates
having to re-enter source information.
Use the Same Field Name button to make the name you enter here
apply to the destination field. If you changed the name on the Edit DDT
window, you can click this button to tell the system to change that
name to the one you entered on this tab.
This is not a required field.

Offset Required. Indicates the position in which the source field data begins.

Length Required. Number of characters in the source field.

File Number of the source file. Specify the number of the table file in the
TBLFILE.DAT file you want to use as the data source.

Record Number of the source record. This number tells the system which
record to retrieve from the source file.

Required Select one of the following options. These options control whether
data must merge in the image's variable field during the merge
procedure.
Not required at processing time. Missing data does not result in an
error message.
Host Required from a source data file during a batch run. Missing data
results in an error message and the system places the form set in the
error batch. Print the error batch to review and correct any errors.
Operator Required as a manual entry in the WIP. Missing data results
in a warning message and the document is kicked to WIP.
Either Required as a manual entry in WIP. Missing data results in a
warning message and the document is kicked to WIP.

Rule Select the name of the rule to execute. This is a required field. See
Image and Field Rules Reference on page 294 for a list and brief
description of the rules from which you can choose.

Mask If required, enter the mask necessary to execute the rule.

Data Enter the data required to execute the rule. Click Edit Data to enter the
data in the Edit DDT Data window. This gives you a larger window in
which to make your entries.

5 When you finish entering the information for the field, click Update FDB to update
the field database with any applicable information. Click Ok to finish and close the
Properties window. Click Reset to cancel your entries. The system saves your
entries when you save the image.

270
Assigning Rules with the Image Editor

Understanding the System The Field Database Editor lets you store and retrieve variable field information to make
setting up and creating images faster and more consistent. The field database contains
a record for each unique variable field. Each record contains information such as the
field name, font, type, and so on. No DDT information is stored in the field database.

Changing a Field Rule

To make changes to a field rule, simply double-click the field and select the Edit DDT
tab. Then change the various fields as necessary.
Click Ok to finish and close the Properties window, Reset to cancel your changes, or
Update FDB to update the field database with any applicable information.
If you need to make changes to several field rules, there are two ways to do this.

• You can double click one of the fields, select the Edit DDT tab, make your changes,
and then use the Next and Prev(ious) buttons to move to the next variable field
which requires changes.
• You can click the Edit DDT button on the Edit DDT tab and make all of your changes
from the Edit DDT window.

NOTE: If you are making changes to several fields and using the Next and Prev
buttons to move from field to field, be aware that Next and Prev save your
changes to a field. If you click Reset, the system only cancels your changes for
the current field.

Deleting a Field Rule

You delete field rules from the Edit DDT window. To display this window, double click
on any field other than the one you want to delete and select the Edit DDT tab from the
Properties window. Then click the Edit DDT button. The Edit DDT window appears.

This is the assignment for the

current field. On most screens,
it appears in green. You cannot
delete the assignment for a
field if it’s the field you are
working with.
To delete a rule assignment for
another field, click the row and
then click Delete.

271
Chapter 4
Adding Image and Field Rules

Click the row you want to delete and then click Delete. The system removes the rule
assignment from the DDT file and the field from the FAP file to make sure both files are
in sync.

NOTE: The Automatically Update DDT option does not affect deletions.

USING THE EDIT DDT WINDOW

You can enter field rule information for a specific field on the Edit DDT tab or you can
use the Edit DDT window to work with all the fields on an image at once. To display this
window, double click a variable field, select the Edit DDT tab, and then click the Edit
DDT button. The Edit DDT window appears.

With the exception of the

Destination Length, the
columns on this window
correspond to the fields on
the Edit DDT tab—it’s just a
different way to present the
information.

Click on these buttons to

select a field. For example,
click here to select FIELD #10.

These drop downs let you

select from a list. For
example, click here to
retrieve source field
information from the data
dictionary.

NOTE: The columns on this window were resized to show all of the fields. You can
resize any column in the window.

The first column lists the fields that exist on the image, or FAP file. This column always
remains visible on the window. Use the scroll bar at the bottom of the window to scroll
left or right and display other columns.

272
Assigning Rules with the Image Editor

ASSIGNING A RULE
The Edit DDT window lets you quickly and easily assign rules to the variable fields. You
simply move from column to column and row to row to make your rule assignments.
You can also change destination names.
When you select a new row, any changes you made to a previous row are saved in
memory but not written to the DDT file. The information is saved when you save the
image.
1 To assign a rule, highlight the variable field you want to assign a rule to by clicking
on it. The field name automatically defaults for you in the Destination Name field.
This is the image field that receives data during processing. Do not change this
name.
2 Enter the offset for the destination field in the Offset field. This field indicates the
beginning position of a piece of data in a variable field. For example, if you need
the data to be indented or offset in the variable field once processing has occurred,
you would enter that offset in this field.
3 Enter the length for the destination field in the Length field. The system defaults
to the variable field’s length.
4 Enter the name of the source field in the Source Name field or click the drop down
arrow to retrieve source field information from the data dictionary. Assigning a
source name to specific source information eliminates having to re-enter source
information.
5 Enter the offset for the source field in the Offset field. This indicates the first
position of the data in the extract file.
6 Enter the length for the source field in the Length field. This indicates the length of
the data in the extract file.
7 If you are using the TblLkUp rule, specify the number of the table file in the File
field. Table file information is stored in the TBLFILE.DAT file. This file tells the
system where to find individual table (TBL) files. Here is an example:
.\DEFLIB\AGENCY.TBL
.\DEFLIB\COMPCODE.TBL

This information is used by the TblLkUp rule. The system looks at the number in
the File field to determine which TBL file to use. Based on the search mask
information, the system then looks in that TBL file for the text.

NOTE: If you are not using the TblLkUp rule, no entry is required in this field.

8 Enter the record number in the Record field. The record number tells the system
which record to retrieve from the source file—a one (1) means the first record
found, a two (2) means the second record, and so on.
9 Select one of these options in the Required field. Data requirements control
whether data must merge into the field during the merge procedure.

273
Chapter 4
Adding Image and Field Rules

Option Description

Not Not required at print time. Missing data does not result in an error
message.

Host Required from a source data file during a batch run. Missing data results
in an error message and the document kicks to the error batch.

Operator Required as a manual entry in the WIP module. Missing data results in a
warning message and the document is kicked to WIP.

Either Required as manual entry in the WIP module. The system first tries to fill
the field with data from the extract file. If the data is missing, the system
kicks the document to WIP and creates a warning message.

NOTE: By customizing your INI file settings, you can have the system send all
transactions it could not process to a specific file, commonly called the error
batch (ERROR.BAT). You can print the error batch after Documaker Server
finishes. Transactions listed in this file are not sent to WIP or archived. These
transactions must first be corrected before they can be sent to WIP or archive.
For information about error batches, refer to the Documaker Server System
Reference.

10 Select a rule from the list in the Rule field. See Image and Field Rules Reference on
page 294 for a list and brief description of the rules from which you can choose.
11 If a mask is required during the processing of the rule, enter the mask in the Mask
field.
12 Enter the data in the Data field. The data string is the information that points to the
record location that identifies the record in the extract file.
After you make all the rule assignments, click OK to return to the Properties window.
Click Reset to undo your changes and display the Properties window. Click Cancel to
undo your changes and close the Properties window.

274
Assigning Rules with the Image Editor

DISPLAYING RULE REPORTS

You can generate a report that documents all field rule assignments in the current DDT
file. You can also generate a report that compares all fields in the image's DDT file to
all fields in the image's FAP file.
To view these reports, first select the Reports option from the Image Editor’s Tools
menu. This option shows you the available reports.

NOTE: These reports are only available if the DDT file has been loaded. If the image
has no DDT file or if the DDT file has not been loaded, these reports are
unavailable.

Image Report
The Image Report option lets you view a listing of fonts used, image dimensions,
variable field information, and so on. This report does not include information about
rules.

View Rules Report

The View Rules Report option lets you view a listing of all fields in the DDT file and
pertinent information about each field. The Image Editor shows the information in a
tabular fashion. The variable fields' offsets, lengths, assigned rules and data
requirements appear.
The system creates this report from data stored in memory when you open the Image
Editor. The system creates the report as a text file and then displays it using your
default text editor, such as Notepad.

275
Chapter 4
Adding Image and Field Rules

Name of the image

Variable fields

Offsets and lengths Rules

After you finish viewing the rules report information, you can use Notepad to save,
print, edit, or perform other tasks. For instance, you can...

• Save the report by choosing File, Save.

• Print the report by choosing File, Print.
• Close the report by double clicking on the icon in the top left corner of the window.

View Compare Report

The View Compare Report option lets you view and compare a listing of all the fields
stored in the image's FAP file with all the fields in the image's DDT file. Differences
between the two files appear in the report.
The system displays a message stating that the rules (DDT) file will be saved before
running the report. Click Ok to save the DDT file and create the report. Click Cancel to
return to the Image Editor.
The system creates the report as a text file and then displays it using your default text
editor, such as Notepad.
The report provides the names of variable fields found in the image (FAP) file but not
found in the DDT file. The fields' offsets, lengths, rules, and data flags also appear.

276
Assigning Rules with the Image Editor

Name of the image

You can use this report to locate fields that need to be mapped or to make sure variable
field lengths are long enough to contain the data described by the destination length
in the DDT file.
After you finish viewing the compare report information, you can use Notepad to save,
print, edit, or perform other tasks. For instance, you can...

• Save the report by choosing File, Save.

• Print the report by choosing File, Print.
• Close the report by double clicking on the icon in the top left corner of the window.

277
Chapter 4
Adding Image and Field Rules

FORMATTING The system provides several ways to format dates and numbers using the FmtDate,
RunDate, SysDate, DateFmt, and FmtNum rules. The system includes several pre-
DATA defined formats from which you can choose and you can set up format arguments to
handle any special needs.
The following topics explain your options.

NOTE: The DateFmt rule accepts a mask which includes an input and an output
format. See DateFmt on page 342, for more information.

USING PRE-DEFINED DATE FORMATS

In this example...
d,"1/4",
…the d indicates it is a date format, as opposed to a number format (n). The first digit
(1) indicates the date format (MM/DD/YY). The forward slash (/) indicates the
separator character (/) and the third digit (4) indicates the number of digits in the year.
See DateFmt on page 342 for the complete list of date formats.

NOTE: Because of year 2000 considerations, use four-digit years.

In cases where you do not need a separator, such as format 4 or B, you can specify the
date as “4/2” for format 4 with a two-digit year. The system ignores the slash (/).

NOTE: This example shows the date format as it looks in the FAP file. The easiest way
to enter date formats is through the Image Editor, on the Attributes tab of the
variable field’s Properties window. The Image Editor will then create the date
format in the FAP file for you. The following discussion is based on using the
Image Editor to select the date format.

278
Formatting Data

When you choose Date Format as the type, you can choose from this list of date formats
in the Image Editor on the Attributes tab of the field’s Properties window. The table also
shows the corresponding date format code the Image Editor creates in the FAP file:

In the Format field, To see this code To get dates formatted as shown below
select this format in the FAP file (all examples are for January 2, 2013)

MM/DD/YY 1 01/02/13 (default)

DD/MM/YY 2 02/01/13

YY/MM/DD 3 13/01/02

Month D, Yr 4 January 2, 2013

M/D/YY 5 1/2/13

D/M/YY 6 2/1/13

YY/M/D 7 13/1/2

bM/bD/YY 8 1/ 2/13 (space before 1/ and 2/)

bD/bM/YY 9 2/ 1/13 (space before 2/ and 1/)

YY/bM/bD A 13/ 1/ 2

MMDDYY B 010213

DDMMYY C 020113

YYMMDD D 130102

MonDDYY E Jan0213

DDMonYY F 02Jan13

YYMonDD G 13Jan02

DAY/YY H 002/13

YY/DAY I 13/002

D Month, Yr J 02 January, 2013

Yr, Month D K 2013, January 02

Mon-DD-YYYY L Jan-02-2013

DD-Mon-YYYY M 02-Jan-2013

YYYY-Mon-DD N 2013-Jan-02

279
Chapter 4
Adding Image and Field Rules

In the Format field, To see this code To get dates formatted as shown below
select this format in the FAP file (all examples are for January 2, 2013)

Mon DD, YYYY O Jan 02, 2013

DD Mon, YYYY P 02 Jan, 2013

YYYY, Mon DD Q 2013, Jan 02

(hexadecimal) X Eight-character hexadecimal

representation of the system date. Valid
dates range from 12/31/1969 to 01/18/
2038. Valid dates may differ depending
on the type of machine (PC or host) and
the type of CPU chip.

These date formats affect processing in Documaker Workstation, not Documaker

Server.

Here is a list of the separators you can choose from in the Separators field on the
Attributes tab of the variable field’s Properties window.

In the Separator field, choose... To use this character as the separator...

00/00/00 (default) / (a slash appears in the FAP file)

00-00-00 - (a dash appears in the FAP file)

00.00.00 . (a period appears in the FAP file)

00,00,00 , (a comma appears in the FAP file)

00 00 00 blank (a “b” appears in the FAP file)

In the Year Size field on the Attributes tab of the variable field’s Properties window, you
can choose from these options...

To use... Select...

a two-digit year such as 01/01/13 2 (a “2” appears in the FAP file)

(use only if the year is in current
century)

only a two-digit year such as 01/ 3 (a “3” appears in the FAP file)
01/13 (if you enter anything other
than a two-digit year, you will
receive an error)

a four-digit year such as 01/01/ 4 (a “4” appears in the FAP file)

2013

280
Formatting Data

only a four-digit year such as 01/ 5 (a “5” appears in the FAP file)
01/2013 (if you enter anything
other than a four-digit year, you
will receive an error)

The year as entered without Default (a blank space appears in the FAP file)
changing it

NOTE: You can force 2-digit years when you use the FmtDate rule, even if doing so
means the date may not be interpreted correctly when it is compared to the
century cut-off date. To force a 2-digit year, you must specify the output format
as “1/3” instead of “1/2”. Here is an example:

;0;0;DRVR-BIRTH-DT;1022;8;DRVR-BIRTH-DT;0;8;d,"B4",d,"1/3";
FmtDate;5,DRVRREC01,;N;N;N;N;3367;3600;11011;
The 3 is a format mask (normally used for input) which means 2-digits and only
2-digits.

Understanding the System The century cut-off date is used to determine the century for 2-digit years. This date
defaults to 50, but you can change it using this INI option:
< Control >
DateFMT2To4Year =
Anything less than or equal to the cut-off year is considered to fall in the current
century. For instance using the default of 50, 13 would be interpreted as 2013. Anything
greater than the cut-off year is considered to fall in the previous century. For instance,
again using the default of 50, 88 would be interpreted as 1988.
This is important when you have to determine the years or days between two dates.
There is a scenario where the system overrides a 2-digit year output. This only happens
when the input has 4-digits and the output has 2-digits and the resulting 2-digit output
does not yield the same results when read in again.
For instance, suppose your input is 01/01/1927 and the cutoff year is 50. Normally any
2-digit year with a value less than 50 is considered part of the current century. So if the
system outputs the data as 01/01/27 and then tries to read this date back in, you would
get 01/01/2025 and not 01/01/1927.
The system changes its normal behavior because it is designed to be able to read its
own output and come up with the result originally provided in the original input.
If, however, you specifically tell the system you only want two digits, you will get that
output, but the system may not be able to read it back in and get the same results.

USING PRE-DEFINED NUMERIC FORMATS

For numbers, you can use these format masks:

281
Chapter 4
Adding Image and Field Rules

To... Use...

place a number in that space (0-9) 9

place any number except a zero Z

indicate the number is an amount $

place a currency symbol to the right of the amount (the second $$

$indicates which symbol)

place a minus sign (-) beside the amount if it is negative -

place a minus (-) or plus (+) sign beside the amount +

indicate a credit (accounting format) CR

indicate a debit (accounting format) DB

indicate a debit (accounting format) ()

include an asterisk ($999)

place a percent sign (%) after the number %

You determine whether the minus (-) or plus (+) signs appear before or after the
amount when you choose the field's format on the Attributes tab of the Properties
window in the Image Editor.
When you choose the format in the Image Editor, the system lets you choose from a list
of examples, such as:
+$ZZZZZZZZZ9.99
$$ZZ,ZZZ,ZZZ,ZZZ
$ZZZZZZZZZ9.99CR
$*ZZZZZZZZZZZ.ZZ

Suppressing Decimals The FmtNum rule can use a pre-defined numeric format to suppress decimals. The
with the FmtNum Rule format is 0 (zero). You can only use this format after the decimal and at the end of the
value. You cannot place format code 9 or Z after you specify the zero (0) format code.
Here are some examples of how the Z format and the zero (0) format work together.

Format Z,ZZZ.0Z Format: Z,ZZZ.00 Format Z,ZZZ.Z0

Input = 9999.00 Input = 9999.00 Input = 9999.00

Output = 9,999 Output = 9,999 Output = 9,999

Input = 9999.90 Input = 9999.90 Input = 9999.9

Output = 9,999.90 Output = 9,999.9 Output = 9,999.9

282
Formatting Data

Format Z,ZZZ.0Z Format: Z,ZZZ.00 Format Z,ZZZ.Z0

Input = 9999.09 Input = 9999.09 Input = 9999.09

Output = 9,999.09 Output = 9,999.09 Output = 9,999.09

If you have decimals and you want to see two decimal places, you should use the first
format style shown (ZZZ.0Z). With this format style, an input value of 1.1 will yield 1.10.
If you use ZZZ.00 and input 1.1, you will get 1.1. In most cases, the values using format
Z will be displayed. However, if you are using Z,ZZZ.0Z format, Z will be suppressed if
the Z value contains zero and if the value next to the decimal is suppressed.
The values using the zero (0) format will be displayed unless it is zero. However, the
zero will be displayed if it is followed by another decimal position with a format of Z. If
there is another decimal position that follows and it has a format of zero (0) and the
value is also zero, both zeros will be suppressed along with the decimal. Lastly, if the
input value contains more decimal places than the output value, the number will be
truncated.

Using the ZeroText Use the ZeroText option to insert text you define instead of the zero value, if the result
Option with the FmtNum is zero. Here is an excerpt from a DDT file:
Rule
;0;0;FmtNum Field;10;12;FmtNum
Field;1;20;n,n,"$zz,zzz,zzz,zzz,zz9.99";fmtnum;1,ABC
ZeroText("INCL");N;N;N;N;7399;2675;11010;

Add the ZeroText option after the search mask. It should be preceded by a space. Place
the text you want to print inside quotation marks and parentheses, as shown in the
excerpt.

SETTING UP FORMAT ARGUMENTS

The FmtDate, RunDate, and SysDate rules let you design the format of the output. You
tell the system how to format the output using format arguments. Format arguments
consists of one or more codes, separated by a percent sign (%).
Characters that do not begin with a percent sign are copied unchanged to the output
buffer. This lets you include static text. Any character following a percent sign that is
not a format code is copied unchanged to the destination. For example, to include a
percent sign in the output, add two percent signs (%%).
You can enter up to 80 characters in the mask and you can use these format codes:

Code Description

%A Name of the weekday, such as Tuesday

%w Number of the weekday, (Sunday is 1, Saturday is 7)

%b Month abbreviation, such as Mar

%m Month number, (January is 1, December is 12)

%B Month name, such as November

283
Chapter 4
Adding Image and Field Rules

Code Description

%d Number of the day of the month (01 – 31)

%j Number of the day of the year (001 – 366)

%Y Year with the century, such as 2013

%y Year without the century, such as 13

%H Hour in 24-hour format (00 – 23)

%I Hour in 12-hour format (01 – 12)

%M Minute (00 – 59)

%S Second (00 – 59)

%p Current locale's AM/PM indicator for 12-hour clock

%@xxx xxx identifies the locale. For example, %@CAD%A might produce mardi,
the Canadian French word for Tuesday. The default locale is USD, which is
US English. Once it finds a local format, the system uses that locale until
it finds another locale indicator.

# Suppress leading zeros for the following format codes. The system
recognizes this flag only with these formats:
%#d, %#H, %#I, %#j, %#m, %#M, %#S, %#w

> Uppercase the resulting text. The system recognizes this flag only with
these formats:
%>p, %>A, %>b, %>B

< Lowercase the resulting text. The system recognizes this flag only with
these formats:
%<p, %<A, %<b, %<B

<> Capitalize the first letter of the resulting text. The system recognizes this
flag only with these formats:
%<>p, %<>A, %<>b, %<>B

* - This flag only affects the format code that specifies it. Any subsequent codes that have
text are not affected unless they also include the flag.

Understanding the System Keep in mind the system can only work with the information it receives as input.
The formats for week, hour, minute, AM, and PM (%A,%w,%H,%I,%M,%S, %p) are
useful with the SysDate rule, but do not make sense for RunDate and FmtDate rules
since those rules seldom see week or time information as an input.
Furthermore, you would not want to use the zero suppress format option (#) on input—
especially if there are no separators in the data. For instance, the date indicated by
010109 or 1/1/09 is clear, but 1109 could indicate several things.

284
Formatting Data

For example, assume the date is 03-01-2009, which was a Monday, and the time is
11:57 am. This table shows you results using various formats.

Example Output

%m-%d-%Y 03-01-2009

The year is %Y. The year is 2009.

Born %m/%d/%y at %I:%M %p Born 03/01/09 at 11:57 AM

%d 01

%#d 1

%A Monday

%>A MONDAY

%b Mar

%<b mar

%p AM

%<>p Am

%A, %B %d Monday, March 01

%@CAD%A %@CAD%A, %B %d lundi, mars 01

%A, %@CAD%B %d Monday, mars 01

%@CAD%A, %@USD%B %d lundi, March 01

FIELD FORMAT TYPES (FETYPES)

An fetype defines the field format type. You can have an input and an output fetype. For
example, an input fetype with the FmtNum rule tells the system where the decimal
goes in the number. The output fetype tells the system how to format the output
amount. An fetype can consist of either one or four characters.

NOTE: In Image Editor, you can display the Properties window for a variable field and
then click the Attributes tab to enter this information in the Locale field. For the
Locale field, you pick from a list of countries/languages, instead of entering
one of the codes shown in the following table. The Locale field only appears if
you chose Date Format, Numeric, or (Y)es or (N)o format in the Type field.

The first character of an fetype defines the field format type. There are several types
defined in the system such as a d for dates and an n for numbers. You can add three
additional characters to override the default locale, which is the United States
(English). Here is a list of the currently supported localities:

285
Chapter 4
Adding Image and Field Rules

For this country And this language Use this code in the FAP file:

Argentina Spanish ARS

Australia English AUD

Austria German ATS

Belgium Dutch BED

Belgium French BEF

Bolivia Spanish BOB

Brazil Portuguese BRC

Canada English CAN

Canada French CAD

Chile Spanish CLP

Columbia Spanish COP

Denmark Danish DKK

Ecuador Spanish ECS

European Union English EUR

France French FRF

Finland Finnish FIM

Germany German DEM

Guatemala Spanish GTQ

Iceland Icelandic ISK

Indonesia Indonesian IDR

Italy Italian ITL

Ireland English IEP

Liechtenstein German CHL

Luxembourg French FLX

Luxembourg German LUF

286
Formatting Data

For this country And this language Use this code in the FAP file:

Mexico Spanish MXN

The Netherlands Dutch NLG

New Zealand English NZD

Norway Norwegian NOK

Panama Spanish PAB

Paraguay Spanish PYG

Peru Spanish PES

Portugal Portuguese PTE

South Africa English ZAR

Spain Spanish ESP

Sweden Swedish SEK

Switzerland German CHF

Switzerland French CHH

Switzerland Italian CHI

United Kingdom English GBP

United States English USD

Uruguay Spanish UYU

Venezuela Spanish VEB

FORMATTING DATA WITH THE = OPERATOR

You can include an equals sign (=) in the data area of field-level rules, such as Move_It
and MoveNum, so those rules can format data returned by the = operation.

NOTE: The system lets you use the = operator to reference GVM and DAL expressions
before it rebuilds XPath search masks.The format is as follows:

=XXX(expression)
where XXX is one of the supported ways of finding data from a symbol, such as
DAL or GVM.

287
Chapter 4
Adding Image and Field Rules

This table shows your options:

This usage Tells the system to

=() Return the contents of the DAL variable named the same as the
root name of the current source name of the current DDT field-level
rule.

=("constant") Return the value of the DAL variable that is named by the string
constant.

=GVM(variable) Return the value of the DAL variable whose name is stored in the
specified DAL variable.

=(expression) Resolve the DAL expression and use the result as the name of a
DAL variable to access and return the value

=GVM() Return the value of the GVM variable named the same as the root
name of the current source name of the current DDT field-level rule.

=GVM("constant") Return the value of the DAL variable that is named by the string
constant.

=(variable) Return the value of the GVM variable specified by the contents of
the named DAL variable.

=GVM(expression) Resolve the DAL expression and then use the result as the name of
a GVM variable to access and return the value.

=DAL() Execute a DAL script named the same as the root name of the
current source name of the current DDT field-level rule and return
the results.

=DAL("constant") Execute the DAL script named by the string constant and return the
results.

=DAL(variable) Execute the DAL script named by the contents of the specified DAL
variable and then return the results.

=DAL(expression) Resolve the DAL expression and use the results as the name of a
DAL script to execute, and then return the results in XPATH.

Here are some examples:

=(....)

Retrieves the value of a DAL variable specified by a DAL expression

=("ABC")

Returns the contents of the DAL variable ABC.

=(ABC)

Returns the contents of some other DAL variable that is specified by the contents of the
DAL variable ABC.
=("A" & "B" & "C")
Returns the same result as the ABC example — the contents of the DAL variable ABC.
=()

288
Formatting Data

This retrieves the contents of a DAL variable that is, by default, the root name of the
source name of the current DDT field. For example, assume, the current DDT field has
destination name MYFIELD #003 and the source name MYFIELD #003, then...
=()

Means to return the contents of the DAL variable MYFIELD. This is useful because it lets
you write general purpose XDB rules.
=DAL(...)

Returns the results returned by DAL script named by the expression. For example,
assume a DAL script named ABC.DAL contains:
MYVARIABLE = 100
RETURN(MYVARIABLE)

Then, =DAL(“ABC”) returns 100.

Formatting imported data The system lets you load data from a standard import file in XML, V2, or DS format.
During this process, the system creates a form set and loads the imported data onto
the fields on the appropriate forms.
To be able to use the various formatting rules when you have no extract file, include the
following rule mask symbolic lookup operators. These operators, which begin with an
equals sign (=), provide a way to access the contents of a variable field as if it were
found in an extract file. For instance...

This operator Tells the system to

=@() Return the contents of the variable field that is the same as the
current source field name.

=@(expression) Evaluate the DAL expression to get the name of the variable field
and then get its contents.

NOTE: For more information, see also information about the @ function in the DAL
Reference.

289
Chapter 4
Adding Image and Field Rules

SEARCH CRITERIA The GetRecord function lets the system get data records from an extract list. It searches
the extract list for particular records based on search criteria formatted as shown here:
offset,data offset,data (and so on)

The search criteria is defined by one or more pairs of offsets and data. The number of
pairs is limited by the size of the data field in a MEM_DDT_REC. All offsets are based
on the first character in a record being character 1 (base 1)—not character zero (0).
It is not necessary for offsets to increase from left to right, but it makes for better
readability. It is necessary, however, to specify your search string in the correct case.
Searches are performed in a case-sensitive manner.
Because many of the image and field rules use calls to GetRecord, search criteria is
often needed wholly or as part of the data field in the DDT file.
Here are some examples:

This search criteria Finds the record...

20,HeaderRec with the text HeaderRec starting at offset 20.

10,ABC 50,XYZ with ABC at offset 10 and XYZ at offset 50.

11,~ABC 25,Header that has a string starting at offset 11 which is not equal (~) to ABC
and is equal to Header at offset 25

11,(Electric,Pwr) that has a string starting at offset 11 which is equal to Electric or

Pwr.

290
Overflow and User Functions

OVERFLOW AND Many of the rules support the use of overflow symbols and user functions which work
together. An overflow symbol can be thought of as a block of memory that holds a
USER FUNCTIONS counter. This counter, or overflow variable, tracks the number of records processed
which helps the system determine which record to start with after it handles an
overflow situation.
To use overflow, you must include specific data in the DDT file. This overflow data
consists of the…

• @GetRecsUsed function
• Name of the form
• Overflow symbol
The @GetRecsUsed function is a function the rule runs to access information about a
pre-defined overflow symbol. The overflow symbol is stored in the DDT file with the
field level rules. You must define all overflow symbols using the SetOvFlwSym rule,
which is a job level rule (level 1) stored in the AFGJOB.JDT file.
The second part is the name of a form, which is retrieved from the form definition file
(FORM.DAT) specified in the INI file.
The third part is the overflow symbol itself.
The format of these data items in the DDT data field are as follows:
;@GETRECSUSED,FORMNAME,SYMBOL/ADDITIONAL_DATA;

NOTE: The first three data items are separated by commas. These items are separated
from the rest of the data that the rule requires by a forward slash (/).

Example @GETRECSUSED,DETAILS,Symbolnm/11,DETAILREC;N;N;N;

291
Chapter 4
Adding Image and Field Rules

292
Chapter 5
Image and Field Rules
Reference
Image and field rules help you control how data is
processed and generated to fill a field on a form.

NOTE: This chapter serves as a reference to the

image and field rules. For information on the
rules which apply to jobs and form sets, see
Adding Job and Form Set Rules on page 5.

This chapter discusses rules included in the base

system and supported by the Support Services Group.
For information on custom rules, contact your
Professional Services representative.
For a summary of these rules, see Image and Field
Rules Reference on page 294.

293
Chapter 5
Image and Field Rules Reference

IMAGE AND FIELD The following pages list and explain the various image and field rules you can use. The
rules are discussed in alphabetical order on the pages following this table.
RULES REFERENCE
NOTE: You can also see information about the image and field rules while using
Studio when you select the rule on the Rule Properties window.

When you select a rule,

information about that
rule appears here:

If you are using Image Editor, select the Help, Explain Rule option.

294
Image and Field Rules Reference

The following table lists the rules discussed in this chapter by type (job, image, or field
level rule) and purpose.
The Level column indicates whether the rule is an image level rule (3) or a field level
rule (4). The Overflow column indicates the rules which support the overflow feature.
The overflow features allow extract data to flow onto an additional page if needed.

To… Level Use this rule Overflow

add a page break before the 3 PaginateBeforeThisImage na

system begins processing the on page 437
current image

add images to the current form 3 SetRecipFromImage on na

set based on conditions in the page 482
SETRCPTB.DAT file

add TIFF images contained in a 3 AddMultiPageTIFF on na

single TIFF file in a form set page 311

allow a chart’s series data to be 3 FieldVarsToChartSeries na

retrieved via reference to on page 353
variable fields defined on the
same image

check to see if the FAP file is 3 CheckImageLoaded on na

loaded, and if not, load the FAP page 326
file

create a temporary extract list 3 CreateSubExtractList on na

which contains similar records in page 336
a transaction

create a GVM variable from fields 3 Field2GVM on page 351 na

in an image

create custom axis labels for a 3 SetCustChartAxisLabels na

chart on page 471

define the first image in a group 3 GroupBegin on page 361 yes

of images

define the last image in a group 3 GroupEnd on page 373 yes

of images

delete a page from a form set 3 DontPrintAlone on page na

347

delete a specific occurrence of an 3 DelImageOccur on page na

image 346

draw an underline beneath a 3 UnderlineField on page na

variable field 500

295
Chapter 5
Image and Field Rules Reference

To… Level Use this rule Overflow

execute a DAL script 3 PostImageDAL on page na

438

execute a DAL script 3 PreImageDAL on page na

442

get data from extract records and 3 CreateChartSeries on na

include it as series data in a chart page 334

import PDF or TIFF files as bitmap 3 AddMultiPageBitmap on na

images. page 304

increment an overflow variable 3 IncOvSym on page 384 yes

map fields in the XDB database 4 XDB on page 501 na

map fields in the XDD database 4 XDD on page 504 na

merge data for embedded 3 TextMergeParagraph on na

variable fields in a text area with page 499
text

move and align field text so the 3 ConnectFields on page na

data elements are connected. 331

move images from the current 3 MoveMeToPage on page na

page to a page you specify 418

remove a series from a chart if 3 PurgeChartSeries on page na

the series contains no data 449

remove series data from the 3 DeleteDefaultSeriesData na

series you specify on page 345

remove the white space from 3 RemoveWhiteSpace on na

between fields. page 450

reset an overflow variable 3 ResetOvSym on page 454 yes

reset image dimensions 3 ResetImageDimensions na

on page 452

set group options 3 SetGroupOptions on yes

page 455

set the dimensions of an image 3 SetImageDimensions on na

page 473

set the image overlay/page 3 SetOrigin on page 474 na

segment X and Y coordinates
using FAP units

296
Image and Field Rules Reference

To… Level Use this rule Overflow

set the image overlay/page 3 SetOriginI on page 478 na

segment X and Y coordinates
using inches

set the image overlay/page 3 SetOriginM on page 480 na

segment X and Y coordinates
using millimeters

set the send copy to variable 3 SetCpyTo on page 470 na

span a field’s width between two 3 SpanAndFill on page 486 na

other fields, filling in with a fill
character

Field Level Rules

add a placeholder which causes 4 NoOpFunc on page 431 na

no operation to occur (used in
testing)

add a variable from more than 4 AccumulateVariableTotal na

one occurrence of a particular on page 301
record type

add two fields and insert the 4 MoveSum on page 427 na

result into a new field

call a DAL function 4 If on page 378 na

concatenate strings and place 4 ConCat on page 330 yes

the result in the field you specify

copy alphanumeric data from a 4 TblLkUp on page 492 yes

table using the source record
field as a key

copy and format numeric data in 4 MoveNum on page 419 yes

an extract record

copy data from an external record 4 Move_It on page 411 yes

into the output buffer

copy data from an SAP Raw Data 4 SAPMove_It on page 459 yes
Interface (RDI) extract file

copy data from the table list of 4 MovTbl on page 429 na

records into the output buffer

copy data if a source record 4 MoveExt on page 416 yes

exists

297
Chapter 5
Image and Field Rules Reference

To… Level Use this rule Overflow

count the total number of 4 OvPrint on page 435 yes

overflow records that could be
processed per transaction

create lists of data for populating 4 BldGrpList on page 320 na

image lists or columns

display the difference between 4 DateDiff on page 340 na

two dates

emulate TerSub entry 4 TerSubstitute on page yes

functionality 496

execute the MoveNum rule if an 4 MNumExt on page 408 yes

external record is found

force a transaction to manual 4 KickToWip on page 390 na

batch (WIP)

force a transaction to manual 4 PowType on page 440 na

batch (WIP)

format a date 4 DateFmt on page 342 yes

format a date (for international 4 FmtDate on page 355 yes

localities)

format a number 4 FmtNum on page 356 yes

format the system date 4 SysDate on page 490 yes

get a text table item based on a 4 TblText on page 494 yes

key built from the source field
name concatenated with the data
retrieved from the source record

get data from an extract record, 4 LookUp on page 392 na

look up the data in a table, and
copy the table data to the
destination field

get information from an extract 4 If on page 378 yes

file based on conditions you
specify

get information from an extract 4 DAL on page 338 yes

file based on conditions you
specify

get the current system date 4 FfSysDte on page 349 yes

298
Image and Field Rules Reference

To… Level Use this rule Overflow

get the run date from the 4 RunDate on page 456 na

TRNFILE.DAT file and format it
using the mask you specify

insert a specific value 4 Mk_Hard on page 406 na

insert a value in a field only if a 4 HardExst on page 374 yes

record is found in the extract data
using the search criteria you
specify

justify a field (right, left, or 4 JustFld on page 385 na

center)

print information in a field if the 4 PrtIfNum on page 446 na

data matches the numeric value
you specify

print information in a field if the 4 PrintIf on page 444 yes

data matches the string you
specify

process multi-page images 4 EjectPage on page 348 na

replace the NoOpFunc rule 4 MapFromImportData on na

page 394

report the actual number of 4 OvActPrint on page 433 yes

overflow records that could be
processed per transaction

retrieve a message from an 4 MessageFromExtr on yes

extract file page 398

retrieve and format a string 4 StrngFmt on page 488 yes

select the largest value of 4 CompBin on page 327 na

multiple packed decimal fields
located on the same record to
populate a variable field

speed the processing of fields 4 GlobalFld on page 358 na

used repeatedly throughout a
form set

store and retrieve subsequent 4 SetAddr on page 461 yes

lines of a multiple line address

store and retrieve subsequent 4 SetAddr2 on page 464 yes

lines of a multiple line address

store and retrieve subsequent 4 SetAddr3 on page 467 yes

lines of a multiple line address

299
Chapter 5
Image and Field Rules Reference

To… Level Use this rule Overflow

tell the system the field has been 4 Master on page 397 na
mapped to the master DDT file

translate a numeric ISO state 4 SetState on page 484 yes

code into the actual state name

300
AccumulateVariableTotal

AccumulateVariableTotal
Use this field level rule (level 4) when you need to sum a variable from more than one
occurrence of a particular record type. This rule only works with the Record Dictionary.

Syntax output format;AccumulateVariableTotal;Record( ) Variable ( ) Cond ( );;

Parameter Description

Record Name of the record pointer defined in the Records group of the Record
Dictionary file (entitled DataDict). This record pointer defines the column
to search, the text to look for in the starting column, and option flags.

Variable Name of the variable pointer defined in the Variables group of the Record
Dictionary. This variable pointer defines offset into the record where the
data to be accumulated is located, the length and type of the data, and
formatting flags.

Cond (Optional) Name of the condition defined in the Conditions group of the
Condition table. The condition consist of combinations of comparisons,
parenthesis, ANDs, and ORs to verify the correct results.

To format the output, you can also include any of the following format options in the
Mask field on the Field Options window in Studio or in the Mask field on the Edit DDT
tab of the field’s Properties window in Image Editor. Separate each option with a
comma.

Option Description

- (one If the number is negative, this option places a minus sign (-) in the left most
dash) position. For example, if the format mask is (9.2,12.2,C,$,-), the result is: “-
$2,100.00”.

-- (two If the number is negative, this option places a minus sign (-) immediately
dashes) before the amount. For example, if the format equal is (9.2,12.2,C,$,--), the
result is “ -$2,100.00”, with a full length of 12.

+ Tells the system to always include a sign with all numbers.

% Appends a percent sign (%) at the end of the number.

$ Adds a dollar sign. Cannot be the first character in the format mask. This
limitation arises from the Move_It format option, where a dollar sign ($) in
the first character of the mask means to perform a sprintf.

C Adds commas.

C** Adds commas if in US English format or spaces if in Canadian French format.

CR Appends CR to the end of the number.

CS1 Enter one of these options to indicate the checksum method.

CS2 The system appends a check digit (mod 10) of 0 through 9 to the end of the
CS731 number. This is typically used in accounting to make sure a number, such as
an account number, is correct by performing a formula on each digit. For
details, see the discussion on page 423.

301
Chapter 5
Image and Field Rules Reference

Option Description

D Dollars (a combination of B, C, and $. You must modify

GEN_FMT_FmtMaskSaysBinary to recognize this format.)

E Stops a calculation if the search condition is false. The Move_It rule may
return a null output buffer if:
- no record was found; a record was found, but the search mask contained a
pairing (offset,data) which extended past the end of the record
- a record was found, but the mapped data was blank.

F Adds a dollar sign ($) and places it in the first position. If the value is
negative, it moves the minus sign (-) to the last position.

L Left justifies the number.

-L (or --) Tells the system to use a floating negative sign on negative values.

+L (or++) Tells the system to use a floating sign and to always show that sign.

Lang Selects a language for spelling out the number. This flag is used with the V
flag and mask parameters. Here is an example: US, CFR.

M Money (This format is a combination of formats C and $.)

N Leaves the output buffer blank if the number is zero or negative.

NM Adds a minus sign (-) to the number.

P Print leading zeros. You cannot use this format with $, -, C, and F.

P** Prints leading zeros if used without character or symbol enclosed with single
quote.

SLZ Suppresses leading zeros. For example, 00.25 becomes .25.

T Used with the NegText, Text, and ZeroText data options. Adds text before or
after a number. Use the less than (<) symbol for inserting before, the greater
than (>) symbol for inserting after. Use the comma as a separator. You can
also use this option to place currency symbols before or after amounts. For
instance, T>£ places the British pound sterling symbol (ALT+0163) before an
amount.

V Spells out the numeric value in US English.

X Adds an x before the number.

Z Prints a number even if it is zero.

Z2 Prints two zeros.

Image Editor example Assume the content of the Record Dictionary is as follows:
<Records>
Detail = Search(61,18) Repeating
TotalDtl = Search(61,18,96,~00625,101,(01,02)) Repeating
Usage = Search(61,08) Repeating

302
AccumulateVariableTotal

RTP = Search(61,21) Repeating

<Variables>
DTAT = Record(Detail) Offset( 163) Length(10) Type(Zone)
Format(14.2,C,Z) Precision(2)
DTAT$ = Record(Detail) Offset( 163) Length(10) Type(Zone)
Format(14.2,C,Z,$) Precision(2)

And you add this rule to the DDT file:

;0;0;DetailTotal;0;15;DetailTotal;0;15;10.2,14.2,C,Z,$;AccumulateVa
riableTotal;Record(Detail) Variable(DTAT$)
Cond(Type);N;N;N;N;25947;15921;16006;

Each time this rule encounters a record which matches the search criteria (18 starting
in column 61), it accumulates a total for the variable DTAT$ (the data found at offset 163
for a length of 10 formatted to the specification stated in the variable description).
The conditional parameter (Cond(Type)) is an optional parameter defined in the
Condition Table. This parameter is used to limit your search criteria.

• The system supports these types of TIFF images:

Type Description

Type 1 uncompressed

Type 2 Huffman

Type 3 CCITT group 3 FAX

Type 4 CCITT group 4 FAX

Type 5 LZW

Type 32773 Packbits

• When importing TIFF or PDF files, keep in mind you can only include one of the
image positioning parameters, Top, In, or MM. The value specified is relative to the
FAP file's origin as specified by a SetOrigin rule. If there are more than one
positioning parameters, subsequent definitions override prior ones.
If you omit the positioning parameters, the default top/left coordinate is taken
from the margin defined for the FAP file. If the FAP file is not loaded and the
margins are unknown, the default is 0,0 (aligned with the top of the image).

• For TIFF and PDF files, if either the LoadFAPBitmap option or the Embed parameter
are set to Yes, the bitmap is loaded into memory. If neither are enabled, the system
opens the file to get the bitmap size, resolution, and number or pages, but the
bitmap data is not loaded. The system then assumes all of the bitmap images are
the same size as the first image in the file.
For single step mode, set LoadFAPBitmap option to Yes.

306
AddMultiPageBitmap

• You can use the PDFImportDPI option to set the resolution at which PDF files are
imported.
< BitmapLoaders >
PDFImportDPI =

Option Description

PDFImportDPI Enter the resolution in dots per inch (DPI) at which you want to
import PDF files. The default is 100 DPI. A higher DPI gives you
better fidelity, but the import process will take longer and the
output files will be larger.

Example These examples show how you can define the file to import when you use this rule.
Assume that your MRL has these sub-directories which contain these PDF files:

Directory File name

PDF_DAL A_DAL.PDF

PDF_File A_FILE.PDF

PDF_GVM A_GVM.PDF

PDF_SRCH A_SRCH.PDF

Using the File Option

This example imports the A_FILE.PDF file from the PDF_File directory. Using this file,
the GenData program adds the PDF images contained in the single PDF file to the form
set. Each image in the PDF file causes a duplicate of the original FAP image to be
appended to the form. This duplicate contains the bitmap image.
Here is an excerpt from a sample DDT file using the File option:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageBitmap;Opt(Y), File(.\PDF_FILE\A_File.pdf);;
…

307
Chapter 5
Image and Field Rules Reference

NOTE: Keep in mind that if the OPT option is set to No, which is the default, the system
expects you to provide a file name, otherwise you get an error.

If you set the OPT option to Yes, this tells the system that if the data for the file
name is not provided it should skip to the next rule without creating an error
message. Setting OPT to Yes simply tells the system that if no file name is
provided, regardless of the mapping method you are using, it should not be
considered an error. Here is an example:

;AddMultiPageBitmap;OPT(Y), SRCH(1,PDF 10,25);

You get no error if the PDF record does not exist in the extract file or if there is
PDF record but as offset 10 for 25 bytes, there is nothing but spaces. If the
OPT(Y) option is omitted, you get one of these messages, depending on your
situation:

SRCH() A record matching the search mask <1,PDFF> could not be

located.
SRCH() Filename location within search record <1,PDF> is blank.
Offset <10,> Length <25>.

Here is another example:

;AddMultiPageBitmap;OPT(Y), GVM(PDF_GVM);

If PDF_GVM contains no data and the OPT(Y) option is specified, you get no
error. If the OPT(Y) option is omitted, the system generates an error similar to
this one:

GVM(<PDF_GVM>) Global variable does not exist or is empty.

Here is another example:

;AddMultiPageBitmap;OPT(Y), DAL(AddPDF.dal);
If processing the AddPDF.dal script results in an empty string and the OPT(Y)
option is specified, you get no error. If the OPT(Y) option is omitted, the system
generates an error similar to this one:

DAL(<AddPDF.dal>) script returned no result or result was blank.

The thing to remember is that if no data exists and the OPT option is set to Yes,
no error message appears.

Using the DAL Option

This example executes the PDF_NAME.DAL DAL script which returns the file name,
F_DAL.PDF. Using this file name, the GenData program adds the images contained in
the single PDF file to the form set. Each image in the PDF file causes a duplicate of the
original FAP image to be appended to the form. This duplicate contains the bitmap
image. Only the odd images in the PDF file are included because the Only option is set
to Odd.
Here is an excerpt from a sample DDT file:
/* This image uses these rules */
Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;

308
AddMultiPageBitmap

;AddMultiPageBitmap;DAL(PDF_DAL.dal),Only(ODD);;
…

Using the SRCH Option

This example imports PDF files (F_SCH1.PDF, F_SCH2.PDF, and F_SCH3.PDF) based on
the content of lines in the file designated by the ExtrFile option in the Data control
group. Using this file, the GenData program adds the images contained in the three
PDFF files to the form set. Each image in the PDF file causes a duplicate of the original
FAP image to be appended to the form. This duplicate contains the bitmap image. The
bitmap images are embedded in the NA file because the Embed option is set to Yes.
Here is an example of the extract file records pointed to by the ExtrFile option:
0 1
1 1
SCOxxxxxxxHEADERREC
…
…
PDF_File_Name .\PDF\F_SCH1.PDF
…
…

NOTE: This option lets you import and process multiple PDF files because of the way
the file name and path are specified — one file per entry in the file pointed to
by the ExtrFile option.

Here is an excerpt from a sample DDT file:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageBitmap;SRCH(1,PDF_File_Name 15,17),Embed(Y);;

Using the GVM Option

This example imports a PDF file based on file name contained in the GVM variable
called PDF_File_GVM. Using the PDF file name and path in the GVM variable, the
GenData program adds the PDF images contained in the single PDF file to the form set.
Each image in the PDF file causes a duplicate of the original FAP image to be appended
to the form. This duplicate contains the bitmap image.

NOTE: Keep in mind you can use any valid GVM variable, no matter how it is created
or assigned.

To create the PDF_File_GVM variable, you would include the following INI option in
your FSISYS.INI file and add its definition in the TRNDFDFL.DFD file.
< GenTrnDummyFields >
PDF_File_GVM = .\PDF_gvm\A_GVM

Here is an excerpt from a sample DDT file:

/* This image uses these rules */

309
Chapter 5
Image and Field Rules Reference

<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageBitmap;GVM(PDF_File_GVM);;

Using the Type Option

You can use the Type option to specify the type of file you want to import to speed
processing. Enter T (TIFF) or P (PDF). If you omit this option, the system first looks for
TIFF files. If it cannot find a TIFF file, it looks for a PDF file. Keep in mind:

• Pages imported from a PDF file are placed at coordinates (0,0) in the output by
default. You can use the position options (IN, MM, or TOP) to specify another
position.
• You can specify several AddMultiPageBitmap rules, as shown here, but realize
that each subsequent rule reuses the document pages added by previous rules.
Here is an example:
<Image Rules>
…
;AddMultiPageBitmap;DAL(PDF_DAL.dal),Only(ODD),TYPE(P);
;AddMultiPageBitmap;DAL(PDF_DAL.dal),Only(ODD),TYPE(P);
…

Assume the first PDF file contains four pages and the second PDF file contains five
pages.
After executing the two rules, there will be five pages in the form. The first four
pages will have two images each (one from the first rule and one from the second)
and the final page will contain the last image from the 5-image PDF file.
Be aware that the placement of those bitmap images on the page can make them
overlap.

NOTE: This rule supports long file names on 32-bit Windows operating systems.

See AddMultiPageBitmap on page 304 for more information.

Use this image level (level 3) rule to include multiple TIFF images contained in a single
TIFF file in a form set. The first TIFF in the file is inserted on the triggering form/image.
Subsequent TIFF images trigger additional pages which are appended to the form after
the page which contains the first TIFF image.
This rule can also extract TIFF, JPEG, or bitmap images from PDF files. For instance, if
you have a PDF file that includes scanned images, typically in TIFF format, you can use
this rule to extract those images from the PDF file.

NOTE: For more information on using this rule to extract TIFF, JPEG, or bitmaps images
from PDF files, see Using the Type Option on page 316.

Syntax ;AddMultiPageTIFF;Options;;
For the Options parameter, you have these options:

Option Description

Opt (Optional) Enter Yes to indicates this rule is optional and you do not
want error messages generated if the file naming parameters fail to
produce a valid name. The default is No.
This option lets you use multiple named parameters. The first
parameter that provides a TIFF file name is used, but if the name of the
TIFF file returned by the search criteria is blank, the system ignores it
and does not generate an error.
Make this option the first rule parameter.

DAL(script Enter the name of the DAL script you want to execute to return the
name) name of the TIFF file you want to import. You must enter the name of a
script file or DAL library routine. Do not include DAL statements.

File(file name) Enter the name and path of the TIFF file to import.

GVM(variable Enter the GVM variable name that contains the name and path of the
name) TIFF file. The GVM variable data is mapped by some other means
before this rule is executed.

311
Chapter 5
Image and Field Rules Reference

Option Description

SRCH(search The name and path of the TIFF file is contained in a record in the file
criteria name specified by the ExtrFile option in the Data control group.
data) The search criteria are one or more comma-delimited data pairs,
offsets, and character strings, used to as the search mask to find the
record in the file you specified.
The name data is a comma-delimited data pair that defines the offset
and length of the file name in the record defined by the search criteria.
Separate the search criteria and name data by a space.

Only (Odd or By default, all images in the multi-page TIFF file are included. Only
Even) include this option to specify that you want only the odd or even
numbered images. You can use this option to reduce the size of the
output when you know blank pages are included in the scanned
images on every other page.
Choose Odd when you know that the first image is not blank. This
includes images 1, 3, 5, and so on.
Choose Even to start with the second image. This includes images 2, 4,
6, and so on.
If you include both Only (Odd) and Only (Even), you exclude all images.

IN(top,left) (Optional) Specifies the coordinate for the top-left corner of the
bitmaps, in inches.

MM(top,left) (Optional) Specifies the coordinate for the top-left corner of the
bitmaps, in millimeters.

Top(top,left) (Optional) Specifies the coordinate for the top-left corner of the
bitmaps, in FAP units (2400 per inch).

Keep in mind:

• The system supports these types of TIFF images:

Type Description

Type 1 uncompressed

Type 2 Huffman

312
AddMultiPageTIFF

Type Description

Type 3 CCITT group 3 FAX

Type 4 CCITT group 4 FAX

Type 5 LZW

Type 32773 Packbits

• You can only include one of the image positioning parameters, Top, In, or MM. The
value specified is relative to the FAP file's origin as specified by a SetOrigin. If
there are more than one positioning parameters, subsequent definitions override
prior ones.
If you omit the positioning parameters, the default top/left coordinate is taken
from the margin defined for the FAP file. If the FAP file is not loaded and the
margins are unknown, the default is 0,0 (aligned with the top of the image).

• If either the LoadFAPBitmap option or the Embed parameter are set to Yes, the
bitmap is loaded into memory. If neither are enabled, the system opens the TIFF
file to get the bitmap size, resolution, and number or pages, but the bitmap data
is not loaded. The system then assumes all of the bitmap images will be the same
size as the first image in the file.
For single step mode, set LoadFAPBitmap option to Yes.

• If you include several options that serve similar purposes, the last one to provide
a result is used.
• You can specify several AddMultiPageTIFF rules, as shown here, but realize that
each subsequent rule reuses the document pages added by previous rules.
<Image Rules>
…
;AddMultiPageTIFF;DAL(TIF_DAL.dal),Only(ODD);
;AddMultiPageTIFF;DAL(TIF_DAL.dal),Only(ODD);
…

For instance, suppose you have declared two rules. The first has a 4-page TIFF. The
second has a 5-page TIFF.
After executing the two rules, there will be five pages in the form. The first four
pages will have two images each (one from the first rule and one from the second)
and the final page will contain the last image from the 5-page TIFF.
Be aware that the placement of those bitmap images on the page can make them
overlap.

NOTE: This rule supports long file names on 32-bit Windows operating systems.

Image Editor example These examples show how you can define the TIFF file to import when you use this rule.
Assume that your MRL has these sub-directories which contain these TIFF files:

313
Chapter 5
Image and Field Rules Reference

Directory File name

TIF_DAL T_DAL.TIF

TIF_File T_FILE.TIF

TIF_GVM T_GVM.TIF

TIF_SRCH T_SRCH.TIF

Using the File Option

This example imports the T_FILE.TIF file from the TIF_File directory. Using this file, the
GenData program adds the TIFF images contained in the single TIFF file to the form set.
Each image in the TIFF file causes a duplicate of the original FAP image to be appended
to the form. This duplicate contains the bitmap image.
Here is an excerpt from a sample DDT file using the File option:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTiff;Opt(Y), File(.\TIF_FILE\T_File.tif);;
…

NOTE: Keep in mind that if the OPT option is set to No, which is the default, the system
expects you to provide a file name, otherwise you get an error.

;AddMultiPageTiff;OPT(Y), SRCH(1,TIFF 10,25);

You get no error if the TIFF record does not exist in the extract file or if there is
TIFF record but as offset 10 for 25 bytes, there is nothing but spaces. If the
OPT(Y) option is omitted, you get one of these messages, depending on your
situation:

SRCH() A record matching the search mask <1,TIFF> could not be

located.

314
AddMultiPageTIFF

SRCH() Filename location within search record <1,TIFF> is blank.

Offset <10,> Length <25>.

Here is another example:

;AddMultiPageTiff;OPT(Y), GVM(TIFF_GVM);

If TIFF_GVM contains no data and the OPT(Y) option is specified, you get no
error. If the OPT(Y) option is omitted, the system generates an error similar to
this one:

GVM(<TIFF_GVM>) Global variable does not exist or is empty.

Here is another example:

;AddMultiPageTiff;OPT(Y), DAL(AddTiff.dal);

If processing the AddTiff.dal script results in an empty string and the OPT(Y)
option is specified, you get no error. If the OPT(Y) option is omitted, the system
generates an error similar to this one:

DAL(<AddTiff.dal>) script returned no result or result was blank.

The thing to remember is that if no data exists and the OPT option is set to Yes,
no error message appears.

Using the DAL Option

This example executes the TIF_NAME.DAL DAL script which returns the file name,
F_DAL.TIF. Using this file name, the GenData program adds the TIFF images contained
in the single TIFF file to the form set. Each image in the TIFF file causes a duplicate of
the original FAP image to be appended to the form. This duplicate contains the bitmap
image. Only the odd images in the TIFF file are included because the Only option is set
to Odd.
Here is an excerpt from a sample DDT file:
/* This image uses these rules */
Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;DAL(TIF_DAL.dal),Only(ODD);;
…

Using the SCH Option

This example imports TIFF files (F_SCH1.TIF, F_SCH2.TIF, and F_SCH3.TIF) based on the
content of lines in the file designated by the ExtrFile option in the Data control group.
Using this file, the GenData program adds the TIFF images contained in the three TIFF
files to the form set. Each image in the TIFF file causes a duplicate of the original FAP
image to be appended to the form. This duplicate contains the bitmap image. The
bitmap images are embedded in the NA file because the Embed option is set to Yes.
Here is an example of the extract file records pointed to by the ExtrFile option:
0 1
1 1
SCOxxxxxxxHEADERREC
…
…

315
Chapter 5
Image and Field Rules Reference

TIF_File_Name .\tiff\F_SCH1.tif
…
…

NOTE: This option lets you import and process multiple TIFF files because of the way
the file name and path are specified—one file per entry in the file pointed to by
the ExtrFile option.

Here is an excerpt from a sample DDT file:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;SRCH(1,TIF_File_Name 15,17),Embed(Y);;

Using the GVM Option

This example imports a TIFF file based on file name contained in the GVM variable
called TIFF_File_GVM. Using the TIFF file name and path in the GVM variable, the
GenData program adds the TIFF images contained in the single TIFF file to the form set.
Each image in the TIFF file causes a duplicate of the original FAP image to be appended
to the form. This duplicate contains the bitmap image. Note the Top option is set to
0,400. This sets the top/left coordinate for each bitmap to 0,400 FAP units.

NOTE: Keep in mind you can use any valid GVM variable, no matter how it is created
or assigned.

To create the TIFF_File_GVM variable, you would include the following INI option in
your FSISYS.INI and add its definition in the TRNDFDFL.DFD file.
< GenTrnDummyFields >
TIFF_File_GVM = .\tif_gvm\T_GVM

Here is an excerpt from a sample DDT file:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;GVM(TIFF_File_GVM),Top(0,400);;

Using the Type Option

Use the Type option to tell the AddMultiPageTIFF rule that the target image is a PDF file
which contains TIFF, JPEG, or bitmap images. The first image found in the PDF file is
inserted on the triggering form or image. Subsequent images in the PDF file trigger
additional pages which are appended in the order in which they appear in the PDF file.

NOTE: If the PDF file contains anything else, such as text, those items will be
discarded. Only TIFF, JPEG, and bitmap images are added.

316
AddMultiPageTIFF

Keep in mind:

• The images in the PDF file are sized to fit the defined page dimensions for the form,
beginning at coordinates 0,0 in the output.
• If you include several options that serve similar purposes, the last one to provide
a result is used.
• You can specify several AddMultiPageTIFF rules, as shown here, but realize that
each subsequent rule reuses the document pages added by previous rules. Here
is an example:
<Image Rules>
…
;AddMultiPageTIFF;DAL(PDF_DAL.dal),Only(ODD),TYPE(P);
;AddMultiPageTIFF;DAL(PDF_DAL.dal),Only(ODD),TYPE(P);
…

Assume the first PDF file contains four TIFF images. The second PDF file contains
five TIFF images.
After executing the two rules, there will be five pages in the form. The first four
pages will have two TIFF images each (one from the first rule and one from the
second) and the final page will contain the last TIFF image from the 5-image PDF
file.
Be aware that the placement of the images on the page can make them overlap.

NOTE: This rule supports long file names on 32-bit Windows operating systems.

Image Editor example These examples show how you can define the PDF file to import when you use this rule.
Assume that your MRL has these sub-directories which contain these PDF files:

Directory File name

PDF_DAL T_DAL.PDF

PDF_File T_FILE.PDF

PDF_GVM T_GVM.PDF

PDF_SRCH T_SRCH.PDF

Using the File option with This example imports the T_FILE.PDF file from the PDF_File directory. Using this file,
the Type option the GenData program adds the images in the PDF file to the form set. Each image in the
PDF file causes a duplicate of the original FAP image to be appended to the form. This
duplicate contains the image from the PDF file. If the T_FILE.PDF file does not exist, no
error messages appear because the OPT option is set to Yes.
Here is an excerpt from a sample DDT file using the File option:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;File(.\PDF_File\T_File.PDF),Opt(Y,P),TYPE(P);;
…

317
Chapter 5
Image and Field Rules Reference

Using the DAL option with This example executes the PDF_NAME.DAL DAL script which returns the file name,
the Type option F_DAL.PDF. Using this file name, the GenData program adds the images contained in
the PDF file to the form set. Each image in the PDF file causes a duplicate of the original
FAP image to be appended to the form. This duplicate contains the image from the PDF
file. Only the odd-numbered images in the PDF file are included because the Only
option is set to Odd.
Here is an excerpt from a sample DDT file:
/* This image uses these rules */
Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;DAL(PDF_DAL.dal),Only(ODD),TYPE(P);;
…

Using the SCH option with This example imports PDF files (F_SCH1.PDF, F_SCH2.PDF, and F_SCH3.PDF) based on
the Type option the content of lines in the file designated by the ExtrFile option in the Data control
group. Using this file, the GenData program adds the images contained in the three PDF
files to the form set. Each image in each PDF file causes a duplicate of the original FAP
image to be appended to the form. This duplicate contains the image from the PDF file.
The images from the PDF files are embedded in the NA file because the Embed option
is set to Yes.
Here is an example of the extract file records pointed to by the ExtrFile option:
0 1
1 1
SCOxxxxxxxHEADERREC
…
…
PDF_File_Name .\PDF\F_SCH1.PDF
…
…

NOTE: This option lets you import and process multiple PDF files because of the way
the file name and path are specified—one file per entry in the file pointed to by
the ExtrFile option.

Here is an excerpt from a sample DDT file:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;SRCH(1,PDF_File_Name 15,17),Embed(Y),TYPE(P);;

Using the GVM option This example imports a PDF file based on file name contained in the GVM variable
with the Type option called PDF_File_GVM. Using the PDF file name and path in the GVM variable, the
GenData program adds the images contained in the PDF file to the form set. Each image
in the PDF file causes a duplicate of the original FAP image to be appended to the form.
This duplicate contains the image from the PDF file.

NOTE: Keep in mind you can use any valid GVM variable, no matter how it is created
or assigned.

318
AddMultiPageTIFF

To create the PDF_File_GVM variable, you would include the following INI option in
your FSISYS.INI and add its definition in the TRNDFDFL.DFD file.
< GenTrnDummyFields >
PDF_File_GVM = .\PDF_gvm\T_GVM

Here is an excerpt from a sample DDT file:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;0,0,26400,20400,0,0,0,0;
;AddMultiPageTIFF;GVM(PDF_File_GVM),TYPE(P);;

Syntax BldGrpList; ListFunction (ListParameter (ListSubParameter)) Rule (FieldRule) Data

(FieldRuleParameters);
This rule lets you use one of these list functions:

• Array
• MultiArray
• MultiOccur
For each list function you can specify the Rule( ) and Data( ). These parameters let you
specify any standard field level rule that can be used to format the data gathered with
this rule, such as the MoveNum and Move_It rules.

NOTE: You must include the following rule in the AFGJOB.JDT file to clear the queues
created by the BldGrpList after it processes each transaction:

;ProcessQueue;;PostPaginationQueue;
For more information, see ProcessQueue on page 182.

Using the Array function This list function retrieves data from the first extract record encountered that meets the
search mask criteria in a transaction. The data defined as an array in the record is used
to populate fields on the image. The sub parameters for this function are:

Parameter Description

Search Search masks used to locate the extract record which contains the array
of data.

Count The offset and length of the field which contains the number of entries in
the array.

Entry The offset for the start of the array data and length of each data entry in
the array.

Here is an example of the Array function:

BldGrpList; Array (Search (31, CWIARRAY), Count (39, 2), Entry (41,
5)) Rule (MoveNum) Data ( );

Parameter Description

BldGrpList; Array Calls the BldGrpList rule using the Array function.

Search(31, 68, 14, 2) Searches for an extract record with 68 in offset 31 and 2 in
offset 14.

320
BldGrpList

Parameter Description

Count(39, 2) The field at offset 39 for a length of 2 in the extract record

contains the number of entries in the array.

Entry(41, 11) The array starts in offset 41 in the extract record and each
entry is 11 characters long.

Rule(MoveNum) Data( ) The MoveNum rule is called using the parameters defined by
Data ( ). If there are no Data parameters, you do not have to
define a Data sub parameter.

Here is an example of a record from a transaction:

31 39 41
RG00000028030219281501 CWIARRAY0400.0011.1122.2233.3344.44

Using the MultiArray Use this function to retrieve data from multiple extract records that meet the search
function mask criteria. The multiple records define the array data that is used to populate fields
on the image. The MultiArray sub parameters are:

Parameter Description

Search Search masks used to locate the extract records which contain the array
of data.

Count The offset and length of the field which contains the number of entries in
the array.

Entry The offset for the start of the array data and length of each data entry in
the array.

Here is an example of the MultiArray function:

BldGrpList; MultiArray (Search (1, CWIARRAY, 14, ~90), Count (38, 1),
Entry (41, 11)) Rule (MoveNum) Data ( );

Parameter Description

BldGrpList;MultiArray Calls the BldGrpList rule using the MultiArray function.

Search(1, CWIARRAY, 14, ~90) Searches the extract records for each transaction with
CWIARRAY in offset 1 and which is not equal to (~) 90 in
offset 14.

Count(38, 1) The field at offset 38 for a length of 1 in the extract

record contains the number of entries in the array

Entry(41, 11) The array starts in offset 41 in the extract record and
each entry is 11 characters long.

Rule (MoveNum) Data ( ) Calls the MoveNum rule using the sub parameters
defined by Data ( ). If there are no Data parameters, you
do not have to define a Data sub parameter.

Here is an example of a record from a transaction:

321
Chapter 5
Image and Field Rules Reference

31 39 41
RG00000028030219281501 CWIARRAY0400.0011.1122.2233.3344.44
RG00000028030219281501 CWIARRAY0499.9688.4534.2176.4504.05

Using the MultiOccur Use this function to retrieve data from multiple extract records that meet the search
function criteria for each transition, which is used to populate the fields on the image. The
MultiOccur sub parameters are:

Parameter Description

Search Search masks used to locate the extract records that contain the
data to populate the image field.

Field The offset and length of the data in the extract record.

Here is an example of the MultiOccur function:

BldGrpList;
MultiOccur(Search(31,CWICURR,39,~90,39,~95,39,~99),Field(41,38))Rul
e(Move_It)

Parameter Description

BldGrpList;MultiOccur Calls BldGrpList rule using the MultiOccur function.

(Search(31,CWICURR,39, Searches the extract records for CWICURR at offset 31 and

~90,39,~95,39,~99) offset 39 which is not equal to 90, 95, or 99 for each
transaction.

Field(41, 38) Collects data from extract record starting at offset 41 for 38
positions.

Rule(Move_It) Calls the Move_It rule to collect the data.

Here is an example of records from a transaction:

31 39 41
RG00000022030219281501 CWICURR 02 ENERGY CHARGE 4.93
RG00000023030219281501 CWICURR 03 FIXED CHARGE 14.00
RG00000024030219281501 CWICURR 04 REVENUE FEE 2.10
RG00000025030219281501 CWICURR 90 21.03
RG00000026030219281501 CWICURR 95 1.47
RG00000027030219281501 CWICURR 99 22.50

Different fonts Yes

Borders Yes.

Background shading Yes

Bullets or numbers No

Columns Yes

Boxes Yes *

Fields Yes

Files No

Logos (LOG, BMP, TIF, and PNG files) Yes *

323
Chapter 5
Image and Field Rules Reference

Object Supported

Charts Yes *

Vectors Yes *

Shaded areas Yes

Bar codes Yes *

Lines Yes *

Boxes Yes *

* If the object falls on the page to be split, the system moves it to the next page.

Here is how the system splits the image:

1 The system loads the image and flags it as inline.

2 The system duplicates the image. The new image follows the original image.
3 The system moves up the bottom of the original image to just above the footer.

4 The system moves the objects from the original image to the new image if the
bottom of the object extends beyond the bottom of the original image.
5 If the object is a text area and is defined as Can Span, the system splits the text
area, as described here:

The system makes sure the original image is not set to Can Grow.
The system creates the new text area in the new image and copies the object
from the original text area into the new text area.
The system creates a list of the text areas to divide and repositions all objects
moved to the new image. All objects are moved up as much as possible but
maintain their relative positions.
The system then moves the image down as far as the objects are moved up.
This preserves the relative position of the objects.
The system turns on the Can grow and shrink attribute and turns off the Can
span pages attributes in the text areas earlier saved in the list. It then resizes
the new image to its minimum size and turns the Can Span attribute back on.
Pagination continues as usual with two images, instead of one.
Here are some examples that show what happens when a text area with a border is
split:

324
CanSplitImage

Header

Line 1 - This text

area has a border
Page 1

Page 2
Line 1 - This text
area has a border
Footer

Shaded areas are split in a similar manner:

Header

Line 1 - This text

area has a border
Page 1

Line 1 - This text

Page 2
area has a border
Footer

NOTE: Using this rule slows performance. Use only as necessary.

Syntax ;CheckImageLoaded;;;
The CheckImageLoaded image rule checks to see if the FAP file associated with the DDT
file has already been loaded into memory. If the FAP file has not been loaded, the
CheckImageLoaded rule loads it.

Image Editor example ;CheckImageLoaded;;;

Rotated fields If you have an image (FAP file) which contains four variable fields, each with a different
rotation and the fields are not rotated when you run the GenPrint program, make sure
you include the CheckImageLoaded rule. This rule is required in this situation.

Bar code variables If you are using the EAN (European Article Numbering) system to represent bar code
variables and you are using the Move_It rule to map the bar code variable field to your
data, include the CheckImageLoaded rule if your LoadCordFAP option is set to No.

In this field... Enter...

Rule CompBin

Destination offset 1

Source name REC-MAXFINE

Source offset 45

File *

Length 6

Record *

Required *

Mask 11.0,18.0,B

Data 100,XYZ 45,4,67,4

* no entry required for this field in this example

The rule compares the packed decimals on the locations 45-4 bytes and 67-4 bytes in
the record identified by a XYZ at location 100 and returns the highest value.

327
Chapter 5
Image and Field Rules Reference

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name MAXFINE

Offset 1

Length 6

Source name REC-MAXFINE

Offset 45

Length 4

File *

Record *

Required *

Rule CompBin

Mask 11.0,18.0,B

Data 100,XYZ 45,4,67,4

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-MAXFINE;45;4;MAXFINE;1;6;11.0,18.0,B;CompBin;100,XYZ
45,4,67,4;;;;;

The rule compares the packed decimals on the locations 45-4 bytes and 67-4 bytes in
the record identified by a XYZ at location 100 and returns the highest value.
Here's another example:

In this field... Enter...

Destination name MAXFINE

Offset 1

Length 6

Source name REC-MAXFINE

Offset 45

Length 4

File *

328
CompBin

Record *

Required *

Rule CompBin

Mask 11.0,18.0,B

Data 100,XYZ 45,4,67,4 500,1

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-MAXFINE;45;4;MAXFINE;1;6;11.0,18.0,B,CompBin;100,XYZ
45,4,67,4 500,1;;;;;

The example compares the packed decimals on the locations 45-4 bytes and 67-4 bytes
in the record identified by a XYZ at location 100 and returns the highest value if it is
larger than 500. If it is not larger, the system returns the data from the first offset/
length pair (45,4).

In this field... Enter...

Destination name POL NUMBER

Offset 1

Length 15

Source name REC-POL NUMBER

Offset 30

Length 12

File *

Record *

Required *

Rule ConCat

Mask *

Data 17,PMSP0200 30,3,33,7,40,2

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;;REC-POL NUMBER;30;12;POL NUMBER;1;15;;ConCat;17,PMSP0200
30,3,33,7,40,2;;;;;

This rule tells the system to get the first occurrence of a record matching the search
criteria of PMSP0200 at offset 17. The output consists of 12 characters retrieved from
three locations. The 14 character output consists of three characters from offset 30,
seven characters from offset 33, and two more characters from offset 40, as well as a
single space between the first and second and the second and third fields.
The mask is used for character compression of concatenated fields. The default is one
space. You can enter zero (0) or any positive value—just make sure the destination
length can accommodate the spacing of the fields.

Syntax ConnectFields F=FixedField L=LeftField R=RightField;;

Parameter Description

F Enter the name of the field you want used as the fixed field. The system will
move the other fields in relation to this field. The system does not move the
fixed field. The first field you list in the rule’s parameters is always
considered the fixed field.

L Enter the names of the fields you want moved to the left of the fixed field.

R Enter the names of the fields you want moved to the right of the fixed field.

You must enter a fixed field and at least one field to move to the left or right side of the
fixed field. By default, the system places the other fields one space character from the
fixed field, unless you indicate that you do not want spacing between the fields.

NOTE: Include the word No after the movement parameters (L or R) to tell the system
not to add spacing between the two fields. For example,

F=FIELD1,RNO=FIELD2
tells the system to place the contents of FIELD2 immediately after to the end of
FIELD1 with no intervening spaces.

As the system places another field next to the fixed field, the fixed rectangle grows.
This lets you define additional fields based upon where the last field was added.
Keep in mind...

• This rule does not move fields vertically. Fields are only moved horizontally.
• This rule loads the image (FAP or compiled FAP) if it is not already loaded.
• If you use the Move_It rule, or other rules that support right justification by
padding the data with spaces, your results will be incorrect. This rule calculates
the width of a field based upon its entire contents and does not remove any white
space in the field.
• If you specify a field which does not contain data or is invalid, then no space, or
space holder, is included.
• Do not try to move the same field multiple times. The final location of a given
field's data is determined by the last movement of that field.

331
Chapter 5
Image and Field Rules Reference

• The field you specify as the fixed field, cannot be included as one of the fields to
be moved.
• This rule does not work with barcode or multi-line text fields. If you try to name
such a field, you will get an error. This rule does not handle rotated fields.

Image Editor example For these examples assume FIELD1 contains ABC, FIELD2 contains DEF, and FIELD3
contains XYZ. With this rule in the DDT file:
;ConnectFields;F=FIELD1,R=FIELD2;;

The result is:

ABC DEF

With this rule in the DDT file:

;ConnectFields;F=FIELD1,L=FIELD2,R=FIELD3;;

The result is:

DEF ABC XYZ

Here, the rule appended FIELD2 to the left side of FIELD1 and appended FIELD3 to the
right of FIELD1. Note, that in this example, it is difficult to see that the fixed field,
FIELD1, did not move. FIELD2 and FIELD3 moved to align with FIELD1. During this
operation, FIELD1 did not move at all.
With this rule in the DDT file:
;ConnectFields;FIELD1,LNO=FIELD2,RNO=FIELD3;;
The result is:
DEFABCXYZ

This rule is defined similar to the last one but uses the No space parameter.
With this rule in the DDT file:
;ConnectFields;F=FIELD1,R=FIELD2,R=FIELD3;;
The result is:
ABC DEF XYZ

Notice there are two fields appended to the right of the fixed field. The first one
appended expanded the rectangle which allows the next one to append after the last.
With this rule in the DDT file:
;ConnectFields;F=FIELD1,R=FIELD2,F=FIELD2,R=FIELD3;;

The result is:

ABC DEF XYZ

Notice that the result of this rule is the same as the previous example. In this case, the
fixed field was changed to FIELD2 after FIELD2 had been moved adjacent to FIELD1.
Then FIELD3 was moved adjacent to FIELD2 in its new location.

332
ConnectFields

With this rule in the DDT file:

;ConnectFields;F=FIELD1,R=FIELD2,R=FIELD2;;

The result is:

ABC DEF

This example illustrates one of the earlier cautions. In this case, FIELD2 is defined to
move twice. Since the operations are sequential, the field is first moved adjacent to
FIELD1. This movement expands the fixed rectangle used by subsequent movements.
When the field is named again, it moves relative to the current rectangle, making the
field appear farther to the right a distance equal to the size of the text in the field plus
the width of two spaces.

Syntax CreateChartSeries (Chart)(Series)(SearchMask)(DataDefinitions)

Parameter Description

Chart The name of the chart (as defined in the FAP file) to which the series
data will be added.

Series The name of the series that data is to be added to. If the series is not
defined in the FAP, a default series is created.

SearchMask The search mask to be used to find the extract record from which data
is retrieved. The search mask should contain one or more offset,data
pairings. For example, if you want to find the extract record with the
text HEADERREC at offset 20 (base 1), the search mask would be
20,HEADERREC. Additional offset length pairings can be appended.
For example:
20,HEADERREC,50,XYZ
means find the record with HEADERREC at offset 20 and XYZ at offset
50. See the topic Search Criteria on page 290 for more information.

DataDefinitions One or more offset,length pairings used to obtain data values from the
extract record defined by the search mask. For example, if five data
values existed at offsets 110, 120, 130, 140 and 150 each one 10
characters in length, the DataDefinitions field would look like this:
110,10 120,10 130,10 140,10 150,10.
There is a space between each offset,length pair, unlike the
SearchMask which has all its offset,data pairs separated by a comma
(,).

Image Editor example <Image Rules>

;CreateChartSeries;{VBarChart}{Ser1}{11,TESTXXREC,25,2}{30,10 40,10
50,10 60,10};
;CreateChartSeries;{VBarChart}{Ser2}{11,TESTXXREC,25,3}{30,10 40,10
50,10 60,10};
;CreateChartSeries;{VBarChart}{Ser3}{11,TESTXXREC,25,4}{30,10 40,10
50,10 60,10};
;PurgeChartSeries;;

This example gets data for three different chart series in the same chart. The chart
name is VBarChart and the three data series are Ser1, Ser2, and Ser3.

334
CreateChartSeries

The series data for series Ser1 is retrieved from the record found with search mask
11,TESTXXREC,25,2. There are four series data values which are added to this series,
each one 10 characters in length. These are found at offsets 30, 40, 50 and 60 in the
extract record.
The series data values are added to the series, one after another, in the order that they
are listed in this rule. Series data for series Ser2 and Ser3 are created in similar
manner, but get data from other extract data records.
If multiple data items are contained in a single record, it is best to use the rule as
described above where the extract data record is searched for only once.
In the following example, we see the extract data records searched individually. If each
series data value is contained in a unique extract data record then there is no choice
but to search for each individually. Here is an example:
;CreateChartSeries;{VBarChart}{Ser1}{11,TESTAAREC,25,2}{30,10};
;CreateChartSeries;{VBarChart}{Ser1}{11,TESTBBREC,25,2}{40,10};
;CreateChartSeries;{VBarChart}{Ser1}{11,TESTCCREC,25,2}{50,10};
;CreateChartSeries;{VBarChart}{Ser1}{11,TESTDDREC,25,2}{60,10};
;CreateChartSeries;{VBarChart}{Ser2}{11,TESTEEREC,25,3}{30,10};
;CreateChartSeries;{VBarChart}{Ser2}{11,TESTFFREC,25,3}{40,10};
;CreateChartSeries;{VBarChart}{Ser2}{11,TESTGGREC,25,3}{50,10};
;CreateChartSeries;{VBarChart}{Ser2}{11,TESTHHREC,25,3}{60,10};
;CreateChartSeries;{VBarChart}{Ser3}{11,TESTIIREC,25,4}{30,10};
;CreateChartSeries;{VBarChart}{Ser3}{11,TESTJJREC,25,4}{40,10};
;CreateChartSeries;{VBarChart}{Ser3}{11,TESTKKREC,25,4}{50,10};
;CreateChartSeries;{VBarChart}{Ser3}{11,TESTLLREC,25,4}{60,10};

NOTE: The CreateSubExtractList rule is used with the SetRecipFromImage rule.

Syntax ;CreateSubExtractList; Search( ) Keys( );;

;CreateSubExtractList; From( ) To ( );;
;CreateSubExtractList; Drop;;
;CreateSubExtractList; Append;;

Parameter Description

Search Defines a search criteria; see Search Criteria on page 290.

Keys This variable defines the scope of the search:

Keys((offset1,length1),(offset2,length2),….(offsetN,lengthN))

From( ) To ( ) The From(mask) includes the record specified in the from mask. The
To(mask) indicates where to stop. The To(mask) does not include the
record specified in the To(mask).

Drop This parameter drops the temporary sub-extract list that was created and
removes the records from the cached extract records for that transaction.
You will no longer have access to these records.

Append This parameter adds the temporary sub-extract list that was created to
the end of the extract list.

Image Editor example In the following example, the CRTSUB image triggers the CreateSubExtracList rule.
Here is an excerpt from the CRTSUB.DDT file:
<Image Rules>
;CreateSubExtractList;Search(1,18) Keys((24,10));
The first line creates a list based on the defined search criteria. The Keys variable
defines the scope of the search. In this example, Keys=Service Number. Each time the
service number changes, the system begins a new grouping.
Once a list of records has been grouped by this rule, a second form (sub-form) is called
and processed against that group of data. A unique key, such as a LOB key, must define
each sub-form called by this rule.
The second line in the DDT file defines the key for the sub-form it will call. Key2 triggers
the appropriate sub-form. In this example, CRTSUB calls on LOB2. Therefore, each sub-
group of data created by CRTSUB will be used to process all of the images in LOB2. And,
unless otherwise specified, the LevelCheck value should always be set to zero.

336
CreateSubExtractList

Here is an example of a FORM.DAT file:

Like all forms under a separate line of business in a form set, a sub-form called by the
CreateSubExtracList must have a trigger in the SETRCPTB.DAT file. You have to make
sure you have a unique trigger for the image that calls the CreateSubExtractList rule.
Otherwise, you will end up with a repeating group of data (see the sample extract file
below.) Here is an example:
;COMPANY;LOB;TEST;;;;;0;0;0;0;;
;COMPANY;LOB;TEST;CRTSUB;;CUSTOMER;1,18,9,HEADER,16,ELEC11;1;1;0;1;
;
;COMPANY;LOB;TEST;IMAGE1;;CUSTOMER;;0;0;0;1;1,18,16,ELEC11;
;COMPANY;LOB2;TEST;;;CUSTOMER;;0;0;0;0;;
;COMPANY;LOB2;TEST;IMAGE2;;CUSTOMER;;0;0;0;1;1,18,16,ELEC11;
;COMPANY;LOB2;TEST;IMAGE3;;CUSTOMER;1,18,16,ELEC11;1;1;0;1;;
;COMPANY;LOB2;TEST;IMAGE4T;;CUSTOMER;;0;0;0;1;1,18,16,ELEC11;
;COMPANY;LOB2;TEST;ENDSUB3;;CUSTOMER;;0;0;0;1;1,18,16,ELEC11;

NOTE: You must set up the calling image for overflow so the CreateSubExtractList rule
is recalled and can group the next set of records. If you do not set up overflow,
the system processes only the first group of records for the first key field. Also
note the form name TEST does not change.

Image Overflow Sub-form called

CRTSUB.FAP Yes LOB2;TEST

Here is an excerpt of the extract file:

01SAMPCO STARTR ELEC01
18SAMPCO HEADER ELEC11 1111111111
18SAMPCO DETAIL ELEC11 1111111111
18SAMPCO DETAIL ELEC11 1111111111
18SAMPCO DETAIL ELEC11 1111111111
18SAMPCO HEADER ELEC11 2222222222
18SAMPCO DETAIL ELEC11 2222222222
18SAMPCO DETAIL ELEC11 2222222222
02SAMPCO END ELEC02

The DDT file corresponding to the last image in the sub-form called by this rule must
contain either Drop or Append. In this example the last image is IMAGE5.FAP. This lets
the rule knows that it has reached the end of the form. Here is an excerpt from the
IMAGE5.DDT file:
<Image Rules>
;CreateSubExtractList;DROP;

NOTE: If the include file is in DefLib, then change &data.inc to &deflib\data.inc.

If you encounter this error message:

DM10558: Error in GetFieldRuleData(): Condition exceeds buffer length

This means the content of your include file is too large to fit into the rule data area. To
resolve this problem, place the data in a DAL script file and use the CALL or CHAIN
command to execute the DAL script.

Image Editor example Here is an example:

;0;0;AUTONUREC-TOT;90;9;TOTAL PREMIUM;0;10;;dal;
$A = {11,AUTONUREC 25,9}::
$B = {11,AUTONUREC 35,9}::
$C = {11,AUTONUREC 45,9}::
$D = {11,AUTONUREC 55,9}::
$E = {11,AUTONUREC 65,9}::
$F = {11,AUTONUREC 75,9}::
$DENOM = 100.00::
$RESULT1 = ($A + $B + $C + $D + $E + $F)::
$RESULT2 = ($RESULT1 / $DENOM)::
if ($RESULT2=0)::
RETURN("0.0")::
ELSE::
RETURN($RESULT2)::
END::
;N;N;N;N;15373;16426;12012;

338
DAL

NOTE: You can use curly braces { } to tell the system to apply a search mask before
executing the DAL script. Here is an example:

$A = {11,AUTONUREC 25,9}::

The use of curly braces is not part of DAL syntax, but rather is a Documaker
Server notation that is preprocessed before the DAL script is executed.

Please note that you can only use curly braces in this manner if the DAL script
is written into the rule data area. External DAL script files cannot contain such
syntax. To retrieve extract data within an external DAL script file, you have to
use the GETDATA function.

• Month =30 days

• Year = 360 days
You must also specify the output format and output format data in the format mask of
the rule. (The only valid format and data currently supported is 1 3 / 3.)

Syntax FORMATMASK;rule;RULEDATA;...
The FormatMask must be in the form of:
OUTPUTFORMAT OUTPUTFORMATDATA

where OUTPUTFORMATDATA varies, depending on the output format. You must

separate these parameters with a space.
OUTPUTFORMAT. Shows the difference between the two dates, in months and days. The
only output format is 1. You must separate these parameters with a space.
OUTPUTFORMATDATA. The OutputFormatData must be in the form of:
MONTHLENGTH SEPARATORSTRING DAYLENGTH

For example, if you enter 3 / 3 and there are 365 days difference, the output would be
012/005. Here is an example:
1 3 / 3(1 is OUTPUTFORMAT)

The RULEDATA consists of two groups of search criteria and extract field descriptors for
the two dates. These two groups of data are separated by a colon (:). Within each
group, search criteria and extract field descriptors are separated by a single space.
Within search criteria, offset and length are separated by a comma (,). Extract field
descriptors are also separated by a comma (,).
The RULEDATA must be in this form:
RECOFFSET1,RECDATA1 OFFSET1,LENGTH1,DATEFORMAT1:RECOFFSET2,RECDATA2
OFFSET2,LENGTH2,DATEFORMAT2

Parameter Description

RECOFFSET1 The record offset of first date.

RECDATA1 The search data for record of first date.

0FFSET1 The offset of first date in record.

LENGTH1 The length of first date in record.

*DATEFORMAT1 The format of first date.

340
DateDiff

Parameter Description

RECOFFSET2 The record offset of second date

RECDATA2 The search data for record of second date

OFFSET2 The offset of second date in record

LENGTH2 The length of second date in record

*DATEFORMAT2 The format of second date

* The format you specify here must be supported.

You can use these formats:

Enter For this format:

1 MM/DD/YY

7 YYYY-MM-DD

8 Julian_AD date 1 through 1000034 (01/01/0001 – 12/31/2738)

10 Month Date, Year (such as February 17, 2002)

11 MMDDYYYY

NOTE: The data for the two dates is separated by a colon (:). Here is a RULEDATA
example: 1,TRANS 73,10,7:1,TRANS 83,10,7

Image Editor example ;1 3 / 3;DateDiff;1,TRANS 73,10,7:1,TRANS 83,10,7;...

Understanding the System The input to the DateDiff rule can be any of the supported date formats. The system
converts each format to the Julian_AD date and then returns the difference.
Julian_AD dates are simply the number of days since 1 AD. 1 AD is presumed to be 01/
01/0001 because there was no year 0000. That’s why the millennium does not actually
start until 2001. For example, 730179 is Julian_AD for 02/29/2000.

1 YYMMDD MMDDYY yes

2 YYYYMMDD MMDDYYYY yes

3 YYYYMMDD MMDDYY yes

4 YYMMDD MM-DD-YY yes

5 YYMMDD MM/DD/YY yes

6 YYYYMMDD MM-DD-YY yes

7 YYYYMMDD MM/DD/YY yes

8 MMDDYY MM-DD-YY yes

9 MMDDYY MM/DD/YY yes

10 YYYMMDD MM/DD/YY yes

11 MMDDYYYY Month D, YYYY yes

12 MMDDYYYY Mon D, YYYY no

13 MMDDYYYY MONTH D, YYYY no

14 YYYY-MM-DD Month D, YYYY yes

15 YYYY-MM-DD Mon D, YYYY no

16 YYYY-MM-DD MM/DD/YY yes

17 DD/MM/YY Mon D, YYYY no

18 DD/MM/YY Month D, YYYY yes

19 DD/MM/YY MM/DD/YY yes

342
DateFmt

ID Source Destination Also supported by FmtDate

21 YYYY-MM-DD Month DD, YYYY no

22 DD/MM/YY Month DD, YYYY no

23 MM/DD/YY Month DD, YYYY no

24 YYMM MM/YY no

25 MM/DDYY Month DD, YYYY no

26 DD/MM/YY Mon DD, YYYY yes

27 YYYY-MM-DD MM/DD/YYYY yes

Destination formats with a single letter, such as D, indicate that the system will omit
leading zeros or spaces. Also, please note that Month indicates both upper- and
lowercase letters will be used while MONTH indicates only uppercase letters will be
used. Mon indicates the month will be abbreviated, in upper- and lowercase letters.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name EFFECTIVEDATE

Offset 1

Length 10

Source name REC-EFFECTIVEDATE

Offset 75

Length 6

File *

Record 2

Required *

Rule DateFmt

Mask 4

Data 17,PMSP0200

* no entry required for this field in this example

343
Chapter 5
Image and Field Rules Reference

In the DDT file, this information looks like this:

;;2;REC-
EFFECTIVEDATE;75;6;EFFECTIVEDATE;1;10;4;DateFmt;17,PMSP0200;;;;;

This rule gets the second occurrence of a record in the extract list which has PMSP0200
starting at its 17th character. It then takes the six characters starting at location 75
(which should be of the format YYMMDD since we are using format mask 4). The
DateFmt rule will reformat the date to be MM-DD-YY before placing the date in the
output buffer.
This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name EFFECTIVEDATE

Offset 1

Length 10

Source name REC-EFFECTIVEDATE

Offset 75

Length 6

File *

Record 2

Required *

Rule DateFmt

Mask 4

Data @GETRECSUSED,FORMABC,OVSYM/17,PMSP0200

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;2;REC-EFFECTIVEDATE;75;6;EFFECTIVEDATE;1;10;4;DateFmt;
@GETRECSUSED,FORMABC,OVSYM/17,PMSP0200;;;;;

Delete series data for SERIES1 and SERIES3

;DeleteDefaultSeriesData;MYCHART,SERIES1,SERIES3;

Image Editor example ;DelImageOccur;3,form1,form2;;

This example removes the third occurrence of the current image on form1 and form2.
;DelImageOccur;-2;;

This example removes the second-to-last occurrences of the current image for all
forms.

M month only, output formatted as MM

D day only, output formatted as DD

Y year only, output formatted as YY

MS month spelled out

MS1 month spelled out, followed by the two-digit year. (24 June 02)

MS2 month spelled out, followed by the date and a four-digit year (February 17,
2002)

Default no option specified in the data field, will use the format MM/DD/YY

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name DATE

Offset 1

length 20

Source name REC-DATE

Offset *

Length *

File *

Record *

Required *

Rule FfSysDte

Mask *

349
Chapter 5
Image and Field Rules Reference

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-DATE;;;DATE;1;20;;FfSysDte;;;;;;

This example places the current system time stamp in the destination field, according
to the default format of MM/DD/YY.

NOTE: Place the format ID immediately after the rule. This differs from other rule
masks.

Syntax Field2GVM; FieldName, GVMName

Parameter Description

FieldName Name of the field on the current image from which the data is retrieved.

GVM name Name of the GVM variable in which the retrieved data will be stored.

You can use this rule to output data into one of the batches or the NEWTRN.DAT file if
the GVM variable name matches the field name in the DFD file.
GVM variables are essential part of Documaker Server. For example, the fields in the
NEWTRAN.DAT file, or in recipient batch records are all GVM variables during runtime.
This rule lets you take data from a field and place the data into a GVM variable. If that
GVM variable happened to be one of the fields in a recipient batch record, it would be
written out to the RCB file.
You can also use the \O parameter to identify fields the system should consider as
optional.To flag a field as optional, include \O at the end of the field name. Here is an
example:
;Field2GVM;Date\O,CurrentDate,DTE_CLOSED,DTEACCTCLSD;
This example will not generate an error if Date cannot be located on the image. An error
will be generated if DTE_CLOSED is missing.
If the system cannot find a field marked as optional, it will not change the destination
GVM variable. This behavior supports situations where you map any of several fields
that could be generated to the same GVM variable.
Note, that this rule creates a GVM variable if necessary. Therefore, be sure to check the
spelling of the GVM variable name if you intend to use one created by a prior process.
Otherwise, a new variable is created.
Keep in mind...

• If the GVM variable you specify does not exist, it will be created. This differs from
other rules which expect you to have defined the GVM variable by some other
means. This means that if you misspell the variable name, you will not get an error
because a GVM variable will be created for that name.
• Designating a field as optional does not change the value of the GVM variable if
the field is missing. The system does not clear the GVM variable of data just
because a field is missing.

Image Editor example Here is an example from a DDT file:

;Field2GVM;BANNER TEXT #002,DATAOUT;;

The data contained in the BANNER Text #002 field is retrieved and stored in the GVM
variable called DATAOUT.

351
Chapter 5
Image and Field Rules Reference

You can also use this rule to place the system date in the NEWTRN.DAT file. To do this,
in the FAP file you create a field, such as System_Date, which will always be triggered.
You then add a field name, such as SystemDate in the TRNDFDFL.DFD file. Next, add...
Field2GVM,System_Date,SystemDate

in the DDT file and use the SysDate rule to place system date in the System_Date field.
This will place the system date in the NEWTRN.DAT file.
If you then want to place the system date into archive, define a field, such as DAPDate,
in the APPIDX.DFD file and add...
< Trigger2Archive >
dapdat = systemdate

Once the system date is in APPIDX.DBF file, you can display it by adding...
< AfeArchiveDisplay >
Field = dapdata,DD%m/%d/%Y

User-defined format arguments consist of one or more codes, each preceded

by a percent sign (%). For more information on user-defined format masks, see
the Setting Up Format Arguments on page 283.

You can enter up to 80 characters in the mask.

Image Editor example Assume the data in extract file is 04/01/2001 (which is fixed type 1 – MM/DD/YYYY) and
you want to convert it to April 1, 2001 (which is Mon D, Yr), use this DDT format mask:
d,”1/4”,d,”4/4”
To produce a Canadian French date, add the CAD locality code, as shown here:
d,”1/4”,dCAD,”4/4”

To produce a date such as Apr 1, 2001 (format -- Mon D, Yr which does not fall into any
fixed type), use the following DDT format mask.
d,”1/4”,d,”%b %#d, %Y”
Here is another example:
;0;0;datefield1;80;6;datefield1;0;12;d,”B”,d,”4/
4”;FmtDate;11,HEADERREC;N;N;N;;;;;

With the L parameter:

n,n,"z,zzz,zzz,zzz,zz9.99",l
123,456.99

356
FmtNum

Like the Move_It and MoveNum rules, this type of left justification simply removes
leading spaces. It does not provide a positional justification as is provided by the
JustFld rule.

Source Name InsuredName

Source File QMDCL.DDT

Record QMDCL

Offset 25

Length 30

Field Name InsuredName

Required Not

Rule Move_It

Mask

Data 11,INSNAMREC

And make these entries in the QMDC1.DDT file, using the Edit DDT tab of the field’s
Properties window in Image Editor:

Field Enter

Destination Name InsuredName

OffSet 0

Length 30

SourceName InsuredName

OffSet 0

Length 0

File 0

Record 0

Required Not

Rule GlobalFld

Mask

Data

359
Chapter 5
Image and Field Rules Reference

When the system executes this rule, it first checks the Dictionary rule by the field name
key. If the record exists, it returns the value—here InsuredName. If not, it looks into
XDB and gets the original field rule, such as Move_It.
Then the system executes the field rule to get the value and returns it. Finally, it stores
the record in the dictionary. The next time that record is required, the system gets the
value from the dictionary.

NOTE: After you run the GlobalFld rule, you must run the Dictionary rule to terminate
the XDB and free memory.

• Expand boxes to surround an image group with user-defined margins

• Keep a group of images together on a page
• Paginate vertically with headers, footers, and overflow images at the group level
• Paginate horizontally with left and right margins that can contain lists
• Format fields with currently used rules
• Create nested groups
• Vary row heights by the tallest field size or set a standard height for all rows
• Pre-define the spacing between rows
• Set a minimum number of lines to be left on the first or last page
• Create a columnar layout

Syntax GroupBegin;GroupFunction(parameters(sub parameters))

The group functions include:

• Box
• GroupPagination
• List
• StayTogether
• Column

Using the Box Function

Use this function to expand the first box defined in the group to fit around all images in
the group. The Margin parameter lets you define the extra space to be added between
the edge of the image and the box edges. The Margin sub parameters are:

Parameter Description

Left Left margin size in FAP units

Top Top margin size in FAP units

Right Right margin size in FAP units

Bottom Bottom margin size in FAP units

361
Chapter 5
Image and Field Rules Reference

Here is an example:
;GroupBegin; Box(Margin(20,20,20,20));;

The image would look like this:

The image must include a box that will be expanded by the GroupBegin rule’s Box
function around the text, as shown below:

This example expands the box around an image group and sets the margin to 20 FAP
units between the outer edge of the image and the outer edge of the box. There are
2400 FAP units per inch.

Using the GroupPagination Function

Use this group function to define the requirements for keeping certain images (groups)
together on pagination. The GroupPagination parameters are:

Parameter Description

MinImagesOnCurrent Defines the minimum number of images required on the current

page. The default is zero (0).
This rule counts all images triggered in the group, even if an
image has no size. It totals the image sizes to determine the
minimum number of images which can be placed in the
remaining space on the page.
If an image has no size or is flagged as view only, the image is
placed on the page.

362
GroupBegin

Parameter Description

MinImagesOnNext Defines the minimum number of images required for new and
next page. The default is one (1).

NeverSplit Requires that all images within the group must remain together
on same page—pagination can never occur within the group.
The default is No.

CheckNextPage Requires that the next page be checked to confirm that the
entire group cannot fit on the next page before splitting can
occur. The default is No.

The following example requires that a minimum of two images appear on the current
page, and a minimum of three images appear on any subsequent pages. This example
also requires that the next page be checked to confirm that the entire group cannot fit
on the next page before splitting can occur. In addition, the second image is defined as
the header for the group and is to be copied on overflow. Plus the fourth image is
defined as the footer for this group.
Here’s an excerpt from the DDT file for the first image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,936,19718,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
;GroupBegin;GroupPagination(MinImagesOnCurrent(2),MinImagesOnNext(3
));
… … …

Here’s an excerpt from the DDT file for the second image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,1142,19718,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
;SetGroupOptions;header,copyonoverflow;
Here’s an excerpt from the DDT file for the third image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,357,19699,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
… … … …

Here’s an excerpt from the DDT file for the fourth image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,621,6124,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
…. … … …
;SetGroupOptions;footer;
;GroupEnd;;

363
Chapter 5
Image and Field Rules Reference

Using the List Function

A list is a column of data on an image that is defined as a single field in the data
definition table (DDT) and is populated by the BldGrpList rule.
The List function works with the BldGrpList rule to print images containing lists, or
columns, side by side in rows. The tallest field in the row and the GroupBegin:List
parameters, MinSpacing and AddSpacing, determine the row height. The List sub
parameters are:

Parameter Description

AddSpacing Adds additional spacing in FAP units between rows of data. There are
2400 FAP units per inch.

MinSpacing Defines the minimum size in FAP units for each row of data.

MinLines Defines the minimum number of lines to be printed on the first page of
an image. When pagination occurs, if the number of lines printed on
the first page is less than the MinLines amount, the entire image is
moved to the second page.

MinLinesCont Defines the minimum number of lines to be printed on the last page of
an image. When pagination occurs, if the number of lines printed on
the last page is less than the MinLinesCont amount, lines are taken
from the preceding page to meet the minimum.

Here is an example:
GroupBegin;List (MinSpacing(800) AddSpacing(200) MinLines(12)
MinLinesCont(5) );;
; GroupBegin;List(AddSpacing(65));;

This example causes 65 FAP units to be inserted between the groups of images.

Using the StayTogether Function

Use this function if you do not want the group of images to be split between pages and
overflow onto a new page if there is room on the current page for the entire group. The
dimensions of the group of images cannot be larger than the dimensions of the page.

NOTE: Also keep in mind that you cannot nest a StayTogether with a column to keep
the column section together. If you try to use a StayTogether over all the
images you want to organize into columns, the results will not be what you
expect.

Here is an example:
;GroupBegin;StayTogether;;

This example keeps a group of images together when overflow forces them onto a new
page.

364
GroupBegin

Using the Column Function

Use the Column group function to create wrapping or and straight columns.

Creating wrapping Use the Wrap parameter to create newspaper style columns where the column
columns contents flow from the top of a column to the bottom and then to the top of the next
column. All columns have the same width and the same amount of space between
them. There are a fixed number of columns on the page.

The contents of this newspaper columns. You

column flows into the can see examples of
next column as these columns in
necessary. newspapers or
These columns are magazines.
sometimes called

Creating straight columns Use the Straight parameter to create columns whose contents do not flow from one
column to the next. Instead, these columns are not connected and run parallel to one
another. Straight columns are paginated independently. If the contents of one column
exceed the page, the remaining contents appear in that same column on a second
page. All the usual overflow, header, and footer considerations still apply.

365
Chapter 5
Image and Field Rules Reference

The contents of this These two columns run

column never flow into parallel to one another.
the next column.
They are sometimes
When you fill all of the called
space available to this
column on a page,

Page 1

any remaining content parallel columns or side-

flows to the next page. by side columns.

Page 2

Column function Here is a list of the parameters you can use with the Column function.
parameters
Parameter Description

Wrap Indicates the text in the columns will wrap. No other parameters are
required. Wrapping is done by default, unless you use the Multiple or
Straight parameter.

Straight Indicates the text will not be wrapped from one column to the next. No
other parameters are required.
The image definition controls the width and separation of the
columns. When you use straight columns, you define the starting
columns with a GroupBegin and the ending column with an GroupEnd.

366
GroupBegin

Parameter Description

Balanced( ) The balanced sub-parameters determine how images are processed if

there is less than a full page of images. The default is Left.
Left
Use this sub-parameter to equally divide the images between the
columns on the page. If there is a remainder, the left most column will
be the longest column.
Unbalanced
Use this sub-parameter to add images to a column until there is no
more room in that column on that page. The system then places
remaining images in the second column of that same page. The
system repeats this process until all columns on the page are filled.
The system then places any remaining images in the first column of
the next page and continues filling the columns in this manner.

ColCount( ) Defines how many columns will be on a page. You must enter a
positive number.

ColSeparation( ) Defines, in FAP units, how much space is between columns. You must
enter a positive number. The default is zero. There are 2400 FAP units
per inch.

ColWidth( ) Defines, in FAP units, the width of each column. If you omit the width,
the system uses the width of the widest image in the group. You
cannot enter a negative number. There are 2400 FAP units per inch.

Single Indicated there will be a single straight column on the page. Single is
the default unless you specify Multiple.

Multiple Indicates there will be multiple straight columns on the page. You
must embed the straight groups within a group. You do this using the
Multiple group parameter.

Debug Use this parameter to write column-processing information into the

log file for debugging purposes.

Keep in mind that...

• Wrap and Straight are mutually exclusive.

• Multiple and Single are mutually exclusive.
• Straight is mutually exclusive with Balanced, ColCount, ColWidth, and
ColSeparation.
• Multiple is mutually exclusive with Wrap, Straight, Balanced, ColCount, ColWidth,
and ColSeparation.
• You cannot nest a Wrap within a Wrap, Straight, or Multiple.
• You cannot nest a Straight within a Wrap or Straight.
• You cannot nest a Straight within a Multiple.
• You cannot nest a Multiple within a Multiple.

367
Chapter 5
Image and Field Rules Reference

Example 1: Wrapped Assume you have a long list of narrow images which you want to flow down the page
balanced columns until they reach the bottom of the page. The next image should appear at the top of the
second column on that page.
In addition, you want the images to move over to the right so they do not overlap the
images in the first column and you want to repeat this layout until there are three
columns of images.
The columns should be 6000 FAP units wide, balanced as much as possible, and
separated by 1/4 inch (600 FAP units) gap. Each image is 1800 x 5200 FAP units. Image
margins are 600 FAP units for the top, bottom, left, and right. The text area is 4000 FAP
units in width and can grow and shrink. Up to two hundred characters of data can be
moved into each text area.
Based on this criteria, here is an excerpt from the DDT file for the first image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;…
;SetOrigin;Rel+0,Max+0
;GroupBegin;Column(Wrap Balanced(Left) ColCount(3) ColWidth(6000)
ColSeparation(600));
…

Here are excerpts from the DDT file for the second image:
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;…
;SetOrigin;Rel+0,Max+0;
;IncOvSym;QAICOL2ASYM,QAICOL2A;
;TextMergeParagraph;;
….

/* The following fields override the lower level definitions for this
image only.*/
<Image Field Rules Override>
;0;1;Column Input Area A;40;200;Column Input Area A; 0;200;;Move_It;
@GETRECSUSED,QAICOL2A,QAICOL2ASYM/
31,MOVEITA;N;N;N;N;650;1020;12110;

After the last image, the column ends with:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;…
;SetOrigin;Rel+0,Max+0;;
;GroupEnd;;;
This is how the image should look:

368
GroupBegin

Example: 2 - Multiple Assume you have three columns of images which you want to output as straight
straight columns columns. When either of the columns runs into a page footer or off the bottom of the
page, you want the images continued on the next page.
The data in the extract file is contained in three separate groups of continuous overflow
records, which may have up to two hundred characters of information.

Column anchor point Column anchor point Column anchor point

Record 1, column 1 Record 1, column 2 Record 1, column 3
Record 2, Column 1 Record 2, Column 2 Record 2, Column 3
Record 3, column 1 Record 3, column 2 Record 3, column 3
Record 4, column 1 Record 4, column 2 Record 4, column 3
Record 5, column 1 Record 5, column 2 Record 5, column 3
--- --- ---
End of column 1 End of column 2 End of column 3

Based on this criteria, here is a sample solution:

/* Excerpt from the DDT file for the first column anchor point. */
<Image Rules>
;SetImageDimensions;98,0,2098,6600,600,600,600,600;
;SetOrigin;Abs+0,Abs+0,,Store(VAR1);
;GroupBegin;Column(Debug Multiple );
;GroupBegin;Column(Straight);

/* Excerpt from the DDT file for the second column anchor point. */

<Image Rules>
;SetImageDimensions;98,0,2098,6600,600,600,600,600;
;SetOrigin;VAR1.right+600,VAR1.top+0,,Store(VAR2);;
;GroupBegin;Column(Straight);

/* Excerpt from the DDT file for the third column anchor point. */

<Image Rules>
;SetImageDimensions;98,0,2098,6600,600,600,600,600;
;SetOrigin;VAR2.right+600,VAR2.top+0;;
;GroupBegin;Column(Straight);

369
Chapter 5
Image and Field Rules Reference

/* Excerpt from the DDT file for the first column image*/

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;
;SetOrigin;Abs+0,Max+0;
;IncOvSym;QAICOL2C11SYM,QAICL2C1;
;TextMergeParagraph;;;

<Image Field Rules Override>

;0;1;Column Input Area C1;40;200;Column Input Area
C1;0;200;;Move_It;@GETRECSUSED,QAICL2C1,QAICOL2C11SYM/
31,MOVEITC1;N;N;N;N;733;917;16010;

/* Excerpt from the DDT file for the second column image */

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;
;SetOrigin;VAR1.right+600,Max+0;;
;IncOvSym;QAICOL2C21SYM,QAICL2C2;
;TextMergeParagraph;;;

<Image Field Rules Override>

;0;1;Column Input Area C2;40;200;Column Input Area
C2;0;200;;Move_It;@GETRECSUSED,QAICL2C2,QAICOL2C21SYM/
31,MOVEITC2;N;N;N;N;733;917;16010;

/* Excerpt from the DDT file for the third column image */

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;
;SetOrigin;VAR2.right+600,Max+0;;
;IncOvSym;QAICOL2C31SYM,QAICL2C3;
;TextMergeParagraph;;

<Image Field Rules Override>

;0;1;Column Input Area C3;40;200;Column Input Area
C3;0;200;;Move_It;@GETRECSUSED,QAICL2C3,QAICOL2C31SYM/
31,MOVEITC3;N;N;N;N;733;917;16010;

/* Excerpt from the DDT file for the End of the first column. */

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;
;SetOrigin;Abs+0,Max+1200;
;GroupEnd;;

/* Excerpt from the DDT file for the End of the second column. */

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;

370
GroupBegin

;SetOrigin;VAR1.right+600,Max+1200;;
;GroupEnd;;

/* Excerpt from the DDT file for the End of the third column. */

<Image Rules>
;SetImageDimensions;98,0,1749,6634,600,600,600,600;
;SetOrigin;VAR2.right+600,Max+1200;;
;GroupEnd;;;
;GroupEnd;;;

Here is an excerpt from the FORM.DAT file:

Here is an excerpt from the SETRCPTB.DAT file:

;CWNG;CIS;QaiColD;;;Customer;;0;0;0;0;11,HEADER,31,030167994401;
;CWNG;CIS;QaiColD;QAICLST1;;Customer;;0;0;0;1;31,MOVEITMC1;
;CWNG;CIS;QaiColD;QAICL2C1;;Customer;31,MOVEITC1;1;0;0;1;;
;CWNG;CIS;QaiColD;EndCol1;;Customer;;0;0;0;1;31,MOVEITMEND;
;CWNG;CIS;QaiColD;QAICLST2;;Customer;;0;0;0;1;31,MOVEITMC2;
;CWNG;CIS;QaiColD;QAICL2C2;;Customer;31,MOVEITC2;1;0;0;1;;
;CWNG;CIS;QaiColD;EndCol2;;Customer;;0;0;0;1;31,MOVEITMEND;
;CWNG;CIS;QaiColD;QAICLST3;;Customer;;0;0;0;1;31,MOVEITMC3;
;CWNG;CIS;QaiColD;QAICL2C3;;Customer;31,MOVEITC3;1;0;0;1;;
;CWNG;CIS;QaiColD;EndCol3;;Customer;;0;0;0;1;31,MOVEITMEND;

Keep in mind these requirements and restrictions when defining groups:

• Each GroupBegin image must have a corresponding GroupEnd image. Either of

these images can be a blank image.
• If you are using conditional images, make sure the triggers in the SETRCPTB.DAT
file for the GroupBegin and GroupEnd images are the same.
• Group footers do not have to be defined as the first image as form footers in the
form definition file (FORM.DAT).
• Do not use an absolute Y coordinate for a group header or group footer.
• When an image contains both a GroupBegin rule and a SetGroupOptions rule, the
GroupBegin rule must come first.
• When an image contains both a GroupEnd rule and a SetGroupOptions rule, the
SetGroupOptions rule must come first.
• Variable field data inside overflow group header images will propagate to the new
page during group pagination if the field scope is set to Form.
You must set all group pagination image options (footer, header, and copyonoverflow)
using the SetGroupOptions rule.

SetGroupOptions on page 455

Image and Field Rules Reference on page 294

372
GroupEnd

GroupEnd
Use this image level rule (level 3) to define the last image in a group of images. This
rule triggers the formatting of gathered data into image lists, or columns. Vertical
pagination occurs while the system processes this rule.

Syntax GroupEnd( )
There are no parameters for this rule.

Image Editor example ;GroupEnd;;

This example causes the group of images defined with a GroupBegin rule to be ended
and triggers the formatting for those images.

In this field... Enter...

Destination name CHECK BOX

Offset *

Length 1

Source name REC-CHECK BOX

Offset *

Length *

File *

Record *

Required *

Rule HardExst

Mask *

Data 17, PMSP0200 X

* no entry required for this field in this example

374
HardExst

In the DDT file, this information looks like this:

;;;REC-CHECK BOX;;;CHECK BOX;;1;;HardExst;17,PMSP0200 X;;;;;

This example puts an X into the destination buffer for the field named CHECK BOX if a
record is found in the extract list using the search criteria of 17,PMSP0200.

NOTE: Source offset and length do not apply to this rule.

Keep in mind that the HardExst rule, when working with overflow, does not return data
in the same order the search criteria appears in the extract file.
For example, suppose you want to return the value X in a variable field called CHECKBX
based on the search criteria:
11,AUTOREC,40,CHECKBX

The variable field is set up for overflow.

;0;1;CHECKBX;0;0;CHECKBX;0;0;;hardexst;@GETRECSUSED,OVFSYM1,MYIMAGE
/11,AUTOREC,40,CHECKBX X;;;;

In the extract file, there are five occurrences of 11,AUTOREC. The first, third, and fifth
occurrence of 11,AUTOREC does not have the value CHECKBX at offset 40 but
the second and fourth occurrences of 11,AUTOREC do have CHECKBX at offset 40.
SCO12345678AUTOREC
SCO12345678AUTOREC CHECKBX
SCO12345678AUTOREC
SCO12345678AUTOREC CHECKBX
SCO12345678AUTOREC
The system does not leave the first, third, and fifth occurrences of the variable field
blank and populate the second and fourth occurrence.
The system finds the two occurrences of 11,AUTOREC,40,CHECKBX, populates the first
two occurrences of the variable field with the value X, and leaves the last three
occurrences of the field blank.

Search masks and Before version 10.1, the HardExst rule did not support overflow. Overflow affects how
overflow the search mask is used. Keep in mind that the rule uses the entire search mask, not
just part of it. In this way, the HardExst rule differs from the PrintIf rule.
For example, if you specify a search mask like
11,DETAILREC,28,Y
it appears that the system checks to see if the record contains a Y in the 28th position.
Instead, this mask really tells the system to find a row with DETAILREC at offset 11 and
with a Y in the 28th position. This may sound like the same thing, but it is not.
Before the rule supported overflow, the answer could only be Yes or No—either you
have such a record in your extract file or you don’t. For example, suppose you have
these rows in an extract file:
HEADERREC0
DETAILREC0Y

And, suppose you specify the HardExst rule without overflow and with this search mask
1,DETAILREC,11,Y

375
Chapter 5
Image and Field Rules Reference

In this case, the answer would be Yes—you do have such a record.

Now suppose you have these rows in your extract file and you are still not using
overflow with the rule:
HEADERREC0
DETAILREC0N
DETAILREC0Y

The HardExst rule, even without overflow, will find the record that matches the search
mask. Therefore, the answer is still Yes—you do have a row with DETAILREC at offset 1
and a Y in offset 11.
If you introduce overflow the result does not change. There is still only one record that
has DETAILREC at offset 1 and a Y in offset 11. The first overflow variable will have the
value you assign, while all the rest will not.
Although it may seem like you are searching for DETAILREC and you want to know if
there is a Y in the 11th position, this is not what you are specifying. You are specifying
that a row must have both criteria to match.
That is the difference between the PrintIf rule (which also now supports overflow) and
the HardExst rule. For the PrintIf rule, you would use a less specific search mask of
1,DETAILREC and then use the if part of the rule to determine if the row contains the
value you want. There are two records that match the less specific search mask of
1,DETAILREC. The first does not have a Y in the designated position, but the second
does.
What you have to note is that the HardExst rule, like any other rule, uses the entire
search mask to find matching rows—not just part of the mask. Therefore, only use the
HardExst rule in overflow conditions to determine how many matching rows are
found—rather than to try to find out if a row does or does not match the criteria.

How data is returned The HardExst rule with overflow does not return data in the same order that the search
criteria appears in the extract file. For example, suppose you would like to return the
value X in a variable field named CHECKBX based on this search criteria:
11,AUTOREC,40,CHECKBX
The variable field is set up for overflow.
;0;1;CHECKBX;0;0;CHECKBX;0;0;;hardexst;@GETRECSUSED,OVFSYM1,MYIMAGE
/11,AUTOREC,40,CHECKBX X;;;;

In the extract file, assume there are five occurrences of 11,AUTOREC. The first, third,
and fifth occurrence of 11,AUTOREC does not have CHECKBX in offset 40 but the second
and fourth occurrence of 11,AUTOREC does have CHECKBX at offset 40.
SCO12345678AUTOREC
SCO12345678AUTOREC CHECKBX
SCO12345678AUTOREC
SCO12345678AUTOREC CHECKBX
SCO12345678AUTOREC
The system does not leave the first, third, and fifth occurrences of the variable field
blank and populate the second and fourth occurrence. The system finds the two
occurrences of 11,AUTOREC,40,CHECKBX, populates the first two occurrences of the
variable field with X, and leaves the last three occurrences of the field blank.

376
HardExst

File number (required by TblLkUp)

Record number (required for overflow)

Source field name (required by TblText)

Source field offset *

Source field length *

Destination field name *

Destination field offset

Destination field length *

Format mask *

Field rule name *

Rule parameters * (also called “data”)

Flag1 (also called “not required”)

Flag2 (also called “host required”)

Flag3 (also called “operator required”)

Flag4 (also called “either required”)

X position

378
If

Parameter Description

Y position

Font ID

The IF rule and overflow You can use overflow variables if the field-level rule you used supports overflow.
Generally, the IF rule does not support overflow—it can only be supported through the
use of the FieldRule function. Here is an example. Suppose you want to move multiple
lines of text from N number of specific external extract records to the output buffer
when the HEADERREC record (at offset 11) contains an F in position 1.
For this scenario, you could use the FieldRule function to call the MoveExt rule and use
the standard IF rule to do the rest. The DAL script for this example would look like this:
CON={11,HEADERREC 1,1}:: A=FIELDRULE("::0::1::E::45::4::PREM/OPS
RATE1::0::4::::moveext::@GETRECSUSED,QCPVR5,OVSYM1/
11,CLSSCDREC::N::N::N::N::::::::")::if(CON='F')::return("^" & A &
"^")::end ;N;N;Y;N;12461;2119;16010

Overflow variables used in the search mask have a syntax which looks like this:
@GETRECSUSED,CPDEC1,CPDEC1OVF/11,CLSSCDREC

Writing DAL scripts Keep in mind that writing DAL scripts is like coding rules. You must write the script
using the correct syntax and make sure you correctly handle the variables you use. This
table shows the different types of variables:

Type Description

A String variable. Use quotation marks for comparisons with this variable.

$A Numeric variable with decimal places. Omit the quotation marks and include
only numbers.

#A Numeric variable without decimal places. Omit the quotation marks and include
only numbers.

In an IF condition, the data type of the variable on the left side of the operator
determines the data type used during the comparison. This means the variable/
number/string on the right is converted to the data type of the variable/number/string
on the left. After this conversion occurs, the comparison is performed.
If you encounter this error message:
DM10558: Error in GetFieldRuleData(): Condition exceeds buffer length

Use this statement:

CALL("logo.dal")

379
Chapter 5
Image and Field Rules Reference

NOTE: You can use curly braces { } to tell the system to apply a search mask before
executing the DAL script. Here is an example:

$A = {11,AUTONUREC 25,9}::

The use of curly braces is not part of DAL syntax, but rather is a Documaker
Server notation that is preprocessed before the DAL script is executed.

For more detailed information on writing DAL scripts and using DAL functions,
see the DAL Reference.

Examples
Here are some examples which will help you understand how you can use the IF rule.
While the IF rule can be very useful, its use affects performance. For production
purposes, you may want to use other rules and triggers to perform the same tasks.

Image Editor example 1 Suppose you want to print the town and state information on the form only if a record
PRODADREC at offset 11 contains a string of four characters of 0000 starting at position
20. The town and state information is stored in the extract file record PRODADREC
starting at position 65 for 25 characters. You want to trim off any trailing spaces or
characters for the town and state information.
You can define a variable to be used in the IF rule with the following syntax:
{search criteria variable attribute}

The search criteria and the variable attributes are separated by one space. The search
criteria is a series of offset and data pairs. You can have as many pairs as you want to
define, as long as they refer to the same record.
The variable attributes are offset and length for the variable you want to define. The
offset of the variable must be for the same record as the search criteria.
The return statement does not support the DAL function. Therefore, the variable must
be trimmed first, before it can be used in the return statement. For this example, we will
define two variables, A and B:
A={11,PRODADREC 20,4} and B={11,PRODADREC 65,25}

The complete script for the IF rule in the semicolon-delimited field would look like this:
::A={11,PRODADREC 20,4}::B={11,PRODADREC 65,25}::
if(A='0000')::B=TRIM(B)::RETURN("^" & B & "^")::END::

Image Editor example 2 Suppose you want the transaction sent to WIP when the record PRODAREC, at offset 11,
contains a string of four characters (0000) starting at position 20. And, you always want
the system to get 25characters of data from PRODAREC, starting at position 65.
Furthermore, you want the system to remove any trailing spaces.

380
If

For this scenario, you would use the FieldRule DAL function to call the KickToWIP rule
and use the standard IF rule to do the rest. The script for this example would look like
this:
::A={11,PRODAREC 20,4}::B={11,PRODAREC 65,25}:: if(A='0000')::
FIELDRULE("::0::1::TOWN_STATE::55:9:REC-TOWN_STATE::0::25::::
KICKTOWIP::::N::N::Y::N::3001::5602::11010::")::END::B=TRIM(B)::
RETURN("^" & B & "^")::END::

Image Editor example 3 For a record where there SUN at offset 23; if 00308 is found in this record at offset 54
and LIFE at offset 80, then put Indiana into the variable named StateCode, else put
OutOfState into the variable.
The DDT file should look like this:
;0;0;StateCode;;;StateCode;;10;;if;A={23,SUN 54,5}::B={23,SUN
80,4}::if((A='00308') AND
(B='LIFE'))::RETURN("^Indiana^")::ELSE::RETURN("^OutOfS
tate^")::END::;;;;;2128;11592;5;

(Syntax for A or B in this example is “offset,data offset,length”)

Image Editor example 4 For a record with SUN at offset 23; if 00308 is found in this record at offset 54, then put
Indiana into the variable named StateCode, else if 00400 is found, then put Georgia
into it, else put OutOfState into it.
The DDT file should look like this:
;0;0;StateCode;;;StateCode;;10;;IF;A={23,SUN
54,5}::IF(A='00308')::RETURN("^Indiana^")::
elseif(A='00400')::RETURN("^Georgia^"):ELSE::RETURN("^OutOfState^")
::END ::;;;;;2128;11592;5;

Image Editor example 5 For a record where there is a SUN at offset 23; if 00308 is found in this record at offset
54 and LIFE at offset 80, then put the data from the offset 63 for 8 bytes in the record
where MOON is found at offset 23 into the variable called StateCode.
The DDT file should look like this:
;0;0;StateCode;;;StateCode;;10;;IF;A={23,SUN 54,5}::B={23,SUN
80,4}::IF((A='00308') AND (B='LIFE'))::RETURN("^{23,MOON
63,8}^")::END::;;;;;2128;11592;5;

Image Editor example 6 This example shows how to specify the occurrence of a record.
In every place where you want to use variable data from the extract file, specify a string
like the one shown here:
{1,MIS257 138,10-5}

In this string, 1,MIS257 is the search mask. If the record is found, the function takes ten
characters starting from position 138. The -5 tells the function to search for the fifth
occurrence of the 1,MIS257 record. If you omit the -5, the function searches for the first
occurrence.

Image Editor example 7 This example shows you how to use the Trim function with the IF rule:
;0;0;TOWN AND STATE;65;25;TOWN AND STATE;0;40;;IF;A={11,PRODADREC
20,4}::B={11,PRODADREC 65,25}::IF(A='0000')::B=TRIM(B)::RETURN("^"
& B & "^")::END::;N;N;N;N;

381
Chapter 5
Image and Field Rules Reference

Note that the Trim function does not work in the Return statement. Also, make sure you
define a variable first, and then trim the variable after the IF statement and before the
Return statement. This is the only way it works.

NOTE: Similarly, the JCenter function works the same way.

Image Editor example 8 If you are using the Trim function in an IF rule and you can get either the first or second
portions of the Return statement, but not both, this example may help you understand
how the system works.
For instance, the following statement…
Y={1,MODELDES 94,45}::if((A='ACV') AND B='1'))::Y=TRIM(Y)::return
("{1,VUNITNBR 112,20} + {1,VUNITNBR 81,10}")::elseif((A='APV') AND
(C='1')) or ((A='APA') AND (C='1'))::return("^"&Y&"^ + {1,MODELDES
49,45}")::end;N;N;N;N;2719;9699;16008

…returns the value of Y only.

There are two types of errors in this DDT file example. One was a logic error in the IF
rule. The Y was trimmed in the IF branch where Y was never used. The elseif branch
used Y, but the Y was not trimmed there.
The other errors were syntax errors. The correct syntax is as follows:
Y={1,MODELDES 94,45}::if((A='ACV') AND (B='1'))::X={1,VUNITNBR
112,20}::Z={1,VUNITNBR 81,10}::return("^" & X & "" & Z &
"^")::elseif((A='APV') AND (C='1')) or ((A='APA') AND
(C='1'))::Y=TRIM(Y)::return("^" & Y & "^+{1,MODELDES
49,45}")::end::;N;N;N;N;2719;9699;16008

This example tells the system that…

• if you have a variable A=ACV and a variable B=1, then trim the data from the
record, where there is VUNITNBR at position 1, for 20 bytes starting at position 112
and the data from the same record for 10 bytes starting at position 81.
• if (variable A=APV and variable B=1) or (variable A=APA and variable C=1), then
trim the data from the record, where there is MODELDES at position 1, for 45 bytes
starting at position 94, and combine this data with the data from the same record
for 45 characters starting at position 49.
The system does not allow (“{offset,data offset,length} + {offset,data offset,length}”)
in one Return statement. You must define the variables first and use the variables in
the Return statement, as shown above.

Image Editor example 9 This example shows you how to format a date from YYYYMMDD to MM/DD format. To
do this, you would need to include the IF rule in your DDT file. The syntax is shown here:
;IF;A={11,POLICYREC 21,8}::B=( sub(date2date( A, "D4"), 1,
5))::return("^" & B & "^")::end::;

A={11,POLICYREC 21,8} is just an example. The syntax is…

Variable Name = {offset,data offset,length}
In this example, it means that variable A is equal to 8-byte characters starting at
position 21 for a record in the extract which meets the search criteria of the string of
POLICYREC, which is found at position 11.

382
If

Image Editor example 10 If, in the extract file, you have a date in this format…
YYYYMMDD

…and would like to reformat it as…

MM/DD/YYYY

…here is how to do it:

NOTE: Format options 1 through 27 provide many format choices you can use, but
these options truncate the year into a two-digit year, such as MM/DD/YY.

No format in the DateFmt rule handles this task, but you can use the IF rule to reformat
the date. Assuming that the date in the EXTRFILE.DAT file is located at offset 77 in a
record with FMMDECREC at offset 11, here is the syntax for the IF rule:
IF;A={11,FMMDECREC 77,8}::B=(sub(date2date(A
,"D4"),1,10))::return("^" & B & "^")::END::;

Image Editor example 11 To format a salutation so you can have the text Dear, a space, and then a variable field
followed by a comma, use this syntax:
If; A={1,Criteria 10,5}::RETURN(“^”&TRIM(A)&”,”&”^”)

The result is something similar to:

Dear XXXX,

Image Editor example 12 This example shows how the IF rule can support overflow by using the FieldRule within
the IF rule. In this case, the FmtNum rule is used to get the locale and Trim is used to
left-justify the text.

NOTE: In this example the locale is the Netherlands, so the text is in Dutch.

Since the FmtNum rule uses double quotes “-ZZZ,ZZZ,ZZZ.ZZ”, the FieldRule must use
single quotes (' ') to avoid parsing errors. Note the semicolons (;) within the FieldRule
are replaced with double colons (::).
Assume the image name is IMGNAME and overflow symbol is OVFSYM:
;0;0;KORTOT-Totaalkorting-Bed;92;10;KORTOT-Totaalkorting-
Bed;0;0;;if;val=fieldrule('::0::0::KORTOT-Totaalkorting-
Bed::92::10::KORTOT-Totaalkorting-Bed::0::0::n,nNLG,"-
ZZZ,ZZZ,ZZZ.ZZ"::fmtnum::@GETRECUSED,IMGNAME,OVFSYM/
18,KORTOT::N::N::N::N::0::0::0')::return("^"&TRIM(val)&"^");N;N;N;N
;0;0;0;

Image Editor example ;IncOvSym;OVERFLOWVAR,IMAGENAME;;

This rule increments the overflow variable OVERFLOWVAR by 1 for the form called
IMAGENAME.

Syntax JustFld (Mode,Cord,XPos,Achr,Rota,Font,NoClip,Rule)

This rule calls either the Move_It, MoveNum, FmtDate, FfSysDte, MoveSum, ConCat,
TblLkUp, SAPMove_It, MoveExt, FmtNum, TblText, Mk_Hard, StrngFmt rules, or other
similar rules.
The first parameter used by the JustFld rule must be the Mode parameter. Here is a
discussion of the parameters:

Parameter Description

Mode Enter L (left), R (right), or C (center). If you omit this parameter, this rule
will call the Move_It rule and generate an error message.
You must also include the Cord or Xpos parameter. The other
parameters are optional.
The mode parameters (left, right, and center) tell the system to remove
leading and trailing blanks before it justifies the data. Use the NoClip
parameter if you do not want the system to do this.

Cord Enter the top, bottom, left, and right coordinates to define where the
field appears on the page.
In Studio, you specify a field’s coordinates on the Field Properties
window.
In Image Editor, you use the General tab of the Properties window. The
coordinates are specified as shown here:
• The top coordinate is specified in the Y field. The bottom coordinate
is the entry in the Y field, plus the entry in the Height field.
• The left coordinate is specified in the X field. The right coordinate is
the entry in the X field, plus the entry in the Width field.
In the DDT file, each coordinate must be in FAP units (2400 per inch) and
separated by commas. Here is an example:
CORD=113,441,5714,9314

XPos Enter the X coordinate used to align the field. If Mode=R this will be the
right most position of the field, likewise if Mode=C this will be the center
of the field. Here is an example:
MODE=R,XPOS=5000
If the data is 12345, character 5 will be at position 5000.

Achr Enter a string of characters found in the data and used to align the field.
When you use this parameter, you must define the XPos parameter,
otherwise the system ignores the Achr parameter. With the correct
setup, the rule aligns the field so the characters you specify in this
parameter overlay the XPos. You can include up to 10 characters in the
string. Here is an example:
MODE=R, XPOS=5000, ACHR=.
If the data is 123.45, the decimal will be at position 5000.

385
Chapter 5
Image and Field Rules Reference

Parameter Description

Rota Specifies the field rotation. Enter 0,90,180, or 270. For example:
ROTA=270
This tells the system to rotate the field 270 degrees.

Font Specifies the font ID. Here is an example:

FONT=11010

NoClip Tells the system not to remove trailing spaces from the field.

Rule Enter the name of the rule you want to use to load the data from the
extract file. If you omit this parameter, the system uses the Move_It rule.
You can choose from any of the date function rules, such as FmtDate,
FfSysDte, MoveSum, ConCat, TblLkUp, SAPMove_It, MoveExt, FmtNum,
TblText, Mk_Hard, StrngFmt, and so on.
For instance, enter MoveNum to have the JustFld rule call the MoveNum
rule. This lets you use the formatting capabilities of the MoveNum rule.
Here is an example:
MODE=R,XPOS=5000,RULE=MoveNum,FONT=11010

Be sure to separate the parameters in the data area with commas.

Essentially, you first define the necessary information as though you were not using
the JustFld rule, but were going to use the underlying rule to get the data. Then, at the
end of the list of parameters, add the Mode parameter and follow with any other JustFld
rule parameters you need—including the Rule parameter if you want to use a rule other
than Move_It.

Errors If the call to the rule fails, this rule returns an error. If you omit the Mode parameter,
this rule calls the Move_It rule and generates an error. The Mode parameter separates
the portion of the data parameter passed to the specified rule.

Using the LoadCordFAP Use of the LoadCordFAP option also affects the JustFld rule. The following table shows
option how this INI option affects this rule:

If set to... Then...

Yes The system gets the coordinates (Cord), font (Font), and rotation (Rota) from
the FAP file.

No You must define the coordinates, font, and rotation using the Cord, Font, and
Rota parameters. Otherwise the field will not be positioned properly.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name qaij10ab

Offset 0

386
JustFld

In this field... Enter...

Length 15

Source name qaij10

Offset 21

Length 15

File *

Record *

Required *

Rule JustFld

Mask Optional, see the discussion of the rule you specified.

Data 11,JUSTRIGHTA,MODE=R,CORD=12800,13288,5000,10760,FONT
=11016,ROTA=0,CLIP,XPOS=5000,ACHR=.

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;qaij10;21;15;qaij10ab;0;15;;JustFld;11,JUSTRIGHTA,MODE=R,CORD=
12800,13288,5000,10760,FONT=11016,ROTA=0,CLIP,XPOS=5000,ACHR=.;N;N;
N;N;5000;13288;11016;

This example shows all possible parameters, as they would appear in the DDT file.
Here are some other examples of how to use the JustFld rule:
This example shows how the DDT file would look if you enter a mask and data value for
the MoveNum rule:
'12.2,12.2,M,S,R,Z,SLZ,T'
'43,Gval NegText("" R"),mode=L,FONT=16116, ROTA=0, Rule=MoveNum'.
;0;0;k1;53;12;k1;0;15;12.2,12.2,M,S,R,Z,SLZ,T;JustFld;43,Gval
NegText("" CR"), mode=L,FONT=16116,ROTA=0,RULE=MoveNum;
N;N;N;N;4999;2500;16116;

NOTE: The data value for the MoveNum rule must follow the search mask for the
JustFld rule. Include a space to separate the parameters.

Here is an example of how you would use a DDT line to map a field using the Move_It
rule:
;0;0;FIELD;30;10;FIELD;0;10;;move_it;11,TVBR2DREC,25,1;N;N;N;N;1977
;3763;11006;

If the then decided to right-justify the data using the JustFld rule. Simply change the
DDT line as shown here:
;0;0;FIELD;30;10;FIELD;0;10;;JustFld;11,TVBR2DREC,25,1,MODE=R,XPOS=
5000;N;N;N;N;1977;3763;11006;

387
Chapter 5
Image and Field Rules Reference

Notice that most of the line did not change. You simply changed the rule name from
Move_It to JustFld and appended the JustFld parameters, starting with the Mode
parameter. In this example, the Rule parameter was omitted because the default rule
used by JustFld is Move_It.
Now assume you are using the DDT line to map a numeric field using the MoveNum
rule:
;0;1;PRM;25;9;PRM;0;;12;9.2,12.2,C;movenum;11,AREC;N;N;N;N;13082;34
72;12012;

If you decide that you want the result of this to be right-justified, you could change the
line as shown here:
;0;1;PRM;25;9;PRM;0;;12;9.2,12.2,C;JustFld;11,AREC,MODE=R,RULE=Move
Num,XPOS=14500;N;N;N;N;13082;3472;12012;

Again notice that most of the line did not change. You simply changed the rule from
MoveNum to JustFld and then included the Rule=MoveNum parameter after the
Mode=R parameter.
If you want the number to be decimal-aligned over the X position instead of right-
justified, include the ACHR parameter.
Here is an example of using a rule other than the Move_It and MoveNum rules:
;1;0;TBL;0;48;TBL;0;48;;TblLkUp;11,HDRREC 53,1 1,CLCODE,12
20,11;N;N;N;N;7831;24236;12012;

Although the TblLkUp rule has more information in the rule parameter area than the
typical Move_It or MoveNum rule might have, the same approach is used to convert to
using the JustFld rule:
;1;0;TBL;0;48;TBL;0;48;;JustFld;11,HDRREC 53,1 1,CLCODE,12
20,11,Mode=R,Rule=TblLkUp,XPOS=11000 ;N;N;N;N;7831;24236;12012;

The JustFLd parameters are appended to the end of the existing rule parameters,
starting with Mode. Then the Rule parameter names the original rule (TblLkUp) and the
other JustFld rule parameters further control the resulting output.
This example demonstrates how to use the JustFld rule in an overflow situation using
the @GetRecsUsed function.
<Image Rules>
...
;IncOvSym;JOVF,QAIJUST1;
...
...
<Image Field Rules Override>
;0;1;qaij1;53;15;qaij1;0;15;;JustFld;@GETRECSUSED,QAIJUST1,JOVF/
43,JUSTRIGHT,MODE=R,FONT=16116,ROTA=0,CLIP,XPOS=5000,ACHR=.;N;N;N;N
;724;727;16114;

MoveExt on page 416

MoveNum on page 419
MoveSum on page 427
SAPMove_It on page 459
StrngFmt on page 488
TblLkUp on page 492
TblText on page 494
Overflow and User Functions on page 291
Image and Field Rules Reference on page 294

389
Chapter 5
Image and Field Rules Reference

KickToWip
Use this field level rule (level 4) to force a transaction to manual batch (WIP). You can
use the KickToWIP rule for situations when data is not available in the extract file or the
data changes, requiring entry by a data entry operator. This rule makes those fields
available for entry.

Syntax KickToWip( )

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name ADDR1

Offset *

Length *

Source name INSNAMEREC-INSNAME1

Offset *

Length *

File *

Record *

Required Operator

Rule KickToWip

Mask *

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;INSNAMEREC-
INSNAME1;0;0;ADDR1;0;0;;KickToWip;;N;N;Y;N;87;1406;12010

The KickToWip rule tells the system to set the manual batch flag to true. Also, to edit
the field associated with the KickToWip rule in the Entry module of Documaker, you
must set the Required field to Operator.
In this example, the operator required flag for the field INSNAMEREC-INSNAME1 must
be set if this field is to be editable in the entry system when retrieved from manual
batch.

390
KickToWip

Suppressing Warning Messages

Use the ShowWIPWarning option to suppress the Sent to Manual Batch warning
messages:
< RunMode >
ShowWIPWarning = No

Option Description

ShowWIPWarning Enter No to suppress warning messages included the error logs

when using the KickToWIP or POWType rules, or the KickToWIP
DAL function.
The default is Yes, which tells the system to include the
messages in the error logs.

In this field... Enter...

Destination name TEXT01

Offset 1

Length 80

Source name REC-TEXT01

392
LookUp

In this field... Enter...

Offset 100

Length 5

File *

Record 2

Required *

Rule LookUp

Mask *

Data 17,PMSP0200 1 14,80

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;2;REC-TEXT01;100;5;TEXT01;1;80;;LookUp;17,PMSP0200 1 14,80;;;;;

This example searches for the second extract record matching the search criteria of
17,PMSP0200. It then takes the five characters at offset 100 in the extract record and
uses them as a key name into the table data.
The table data is searched for a match with the five characters from the extract record
starting at offset 1, the first character of each table entry. If a match is found, the key
data of 80 characters starting at offset 14 are copied into the destination field.

The parameter value to specify indexing has this syntax:

INDEX(option,...)

Where option is a keyword that indicates how to calculate the dictionary instance to
use or a constant value to use as the index.

394
MapFromImportData

Here is a list of the keywords you can use:

Keyword Description

FORM Use the occurrence of this form as the instance index. For example, if this
field is contained on the second copy of this form, then get the second
instance of field data.

IMG Use the occurrence of this image within the current form as the instance
index. For example, if this field is contained on the third copy of image on
the current form, then get the third instance of field data.

IMGFSET Use the occurrence of this image within the entire form set as the instance
index. For example, if this is the fifth occurrence of this image within the
form set (without considering what forms contain the other copies of this
image), then get the fifth instance of field data.

FLD Use the occurrence of this field within the current form as the instance
index. For example, if this field is the third occurrence within the same
form, then get the third instance of field data.

FLDFSET Use the occurrence of this field within the entire form set as the instance
index. For example, if this is the tenth occurrence of this field within the
entire form set (without considering what forms and images contain the
other copies of this field), then get the tenth instance of field data.

A successful return does not indicate whether the field was assigned a value.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name Issue

Offset 0

Length 8

Source name Issue

Offset 0

Length 8

File *

Record *

Required flags *

Rule MapFromImportData

Mask *

* no entry required for this field in this example

395
Chapter 5
Image and Field Rules Reference

In this field... Enter...

Data Keywords if desired

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;ISSUE;0;0;ISSUE;0;8;;MapFromImportData;;N;N;N;N;1167;652;1201;

The above example would try to map the field by querying the image dictionary first;
then the form dictionary, and finally the global dictionary.
Suppose you had this line in the DDT file:
;0;0;ISSUE;0;0;ISSUE;0;8;;noopimp;INDEX(IMG);N;N;N;N;1167;652;1201;

This example would use the occurrence number of this image on the form to index the
global dictionary for this field.

In this field... Enter...

Destination name NAME

Offset *

Length *

Source name REC-NAME

Offset *

Length *

File *

Record *

Required *

Rule Master

Mask *

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-NAME;;;NAME;;;MASTER;;;;;;15960;4000;17200;

In the AFGJOB.JDT file, you must use this rule:

;LoadDDTDefs;1;;

In this field... Enter...

Destination name The field name

Offset The offset within a record where the key can be found

Length The length of the key

Source name *

Offset *

Length *

File *

Record *

Required *

Rule MessageFromExtr

Mask The field, defined in the Record Dictionary, contains the

grouping code. For more information about the Record
Dictionary, see Using the Record Dictionary on page 511.

Data The record, defined in the Record Dictionary, contains the

message key.

* no entry required for this field in this example

In the DDT file, this information could look like this:

<Image Field Rules Override>
;0;0;ExplChrg;323;38;
ExplChrg;0;0;;MessageFromExtr;Detail;N;N;N;N;338;18551;16008;
;0;0;Mess;238;93;Mess;0;0;MsgLinePriority;MessageFromExtr;Message;N
;N;N;N;338;25975;16112;

For this rule, the main components are the message, the message tags, the Record
Definition Dictionary, and the INI options. These components are discussed in the
following topics.

398
MessageFromExtr

Creating Messages
The message is the text retrieved from the extract file. This text can contain message
tags which control how the text is formatted. The tags control the justification, spacing,
font, variable insertion and other functions. All formatting information is contained in
the tags, which serve as a mark-up language. The message itself is straight text. The
message is a single line or record with a maximum length of 2000 bytes.

Setting up the field You attach this rule to a field in the image’s DDT file. You can do this by editing the DDT
file in a text editor or by using Image Editor. In the image (FAP file), you define the field
to which the message is attached as a multi-line text field.
If you also select the Can Grow option for the field, the system combines all messages
with the same group code in this field, letting the field grow to accommodate the entire
message. If you do not select the Can Grow option, the system only includes the
messages that fit within the defined area for the field. Messages that would not fit are
ignored.

Adding messages The system adds messages in the order they appear in the extract file or database. It
tests every message to see if the message fits in the available space. All the messages
of a group must fit in the available space or none of the messages appear.

Grouping messages You can group and format messages as a single message by including a group code.
You define grouping codes in the Record Dictionary. For more information about the
Record Dictionary, see Using the Record Dictionary on page 511. All the messages in a
group are treated as a single message. Group codes cannot be blank. All messages
comprising a group must be located together in the extract list.

Formatting messages The formatting information you select for the field serves as the default formatting
information for all messages, so make sure you set up the field in the image (FAP file)
to use the default font you want for all messages.
Message tags override the default formatting you set up for the field and let you control
the appearance of the message text. You can add tags to the text of the message to
describe and control the justification, spacing, fonts and other formatting information.
The tags affect all text which follows the tag. You can also use message tags to insert
variable data fields.

NOTE: Place the variable (VAR) tag within the text where you want the system to
insert the variable.

Tags are enclosed within brackets (< >). The text between the brackets describes the
formatting action or the reference to the variable name referenced in the Record
Dictionary. The tag itself does not appear in the formatted text.

399
Chapter 5
Image and Field Rules Reference

The following table describes the tags you can use:

Tag Description

<Justify:value> You can enter Left, Right, or Center to have the system left, right, or
center-justify the text. If you omit the value, the system uses the
previously defined justification. You can abbreviated tags if the line
size is limited.
For example, <J:L> or <Justify:L> provides left justification and
<J:C> or <Justify:C> provides center justification.
Note: If the justification tag is in the message—not the first entry on
the line—then you must insert the carriage return tag before the
justification tag. For example, this message places the word, age, to
the right of the second line:
<CR><Justify:Right>Age

<Font:value> You can enter any valid font ID (00000-99999) or Default. The value
is a numeric reference to the font cross reference file (FXR) font ID.
If the value is left blank, the system uses the previously defined font
ID.
For example, <Font:16210> changes the text to the font identified
with font ID 16210 in the FXR file while <Font> changes the font back
to the default font as font defined in the FAP file.
You cannot abbreviate this tag.

<Var:var-name> var-name refers to a variable name defined in a Record Dictionary.

The Definition Dictionary describes the variable data. The
description defines each record and the fields within each record,
such as the record name, offset, length, format, and so on. It does
not include formatting information, such as the font ID.
You can abbreviate this tag as <V:var-name>.
For example, <V:DTAT> references the variable DTAT as defined in
the Record Dictionary and <VAR:DTV1> references the variable DTV1
as defined in the Record Dictionary

<Spacing:value> You can enter Single, Double, or a numeric value in FAP units (2400
per inch in place of value). Single indicates the following text should
be single-spaced. Double indicates the following text should be
double-spaced. A numeric value tells the system the number of FAP
units to use for spacing. If you omit the value, the system returns to
the previously defined spacing.
You cannot abbreviate this tag.
The spacing option you choose applies to the entire message
grouping. You cannot change spacing within a grouping (a single
message).
For example, <Spacing:Double> tells the system to double space
the message lines within the message or message group while
<Spacing> returns the spacing to the default format.
Note: If you change spacing in the text of a message—not the first
items in the message—you must insert a carriage return tag before
the spacing tag. For example, this changes spacing to double lines:
<CR><Spacing:Double>

400
MessageFromExtr

Tag Description

<Tab> Use the Tab tag to have the system indent the text from the left
margin by a specified number of FAP units. You can abbreviate the
tag to <T> if the line size is limited.
You can justify the text relative to the tabbed position by specifying
Left, Center, or Right. You can abbreviate the tags by using the first
character (L, C, or R) if the line size is limited. The default is to left
justify the text.
You can also use different types of fill (leader) characters if the text
does not fill the entire space. You can use these leader characters:
no leader (spaces), dashes (---), periods (…), or underlines (___).
Except for no leader, you can abbreviate the tags using the first
character if the line size is limited. For no leader, you must use the
word nolead for spaces. Spaces are the default fill characters.

<CR> This tag tells the system to insert a hard return (carriage return), or
forced line break. For example, Residential <CR> rate will look like
this:
Residential
rate
You cannot abbreviate this tag.

Here are some examples using the Tab tag…

<CR><T:9600,Left,nolead>Tabbing in 4 inches with no leader.
<CR><T:9600,Left,dash>Tabbing in 4 inches with dashes.
<CR><T:9600,Left,period>Tabbing in 4 inches with periods.
<CR><T:9600,Left,underline>Tabbing in 4 inches with underline.

01 2 3 4 65 7 8
Tabbing in 4 inches with no leader.
-----------------Tabbing in 4 inches with dashes.
……………………………………………Tabbing in 4 inches with periods.
_________________Tabbing in 4 inches with underline.

<CR><T:9600,C,D>4"dashes & text centered.

<CR><T:9600,R,P>4"periods & text right.

0 1 2 3 4 5 6 7 8
----------------4" dashes & text centered.
.…………………………………….4" periods & text right.

Here is another example. The following tags...

<Justifiy:Center><Font:23712>Example<CR><Justify><Font>This is a
sample message.<CR>Name<Justify:Right>Age

... produce this message:

Example
This is a sample message.
Name Age

401
Chapter 5
Image and Field Rules Reference

Using the Record Dictionary

The Record Dictionary provides the information for identifying and locating records and
fields within records. The Record Dictionary is an ASCII file you can create using any
ASCII editor. Used with the Condition table, any variable in the Record Dictionary can
be used in a conditional evaluation. For more information about the Condition table,
see Using Condition Tables on page 508.
Record Dictionary information is divided into two sections:

• the Record section, which describes the records

• the Variable Definition section which describes the fields contained within the
records
For more information about the Record Dictionary, see Using the Record Dictionary on
page 511.

Record definition syntax Record Name = Search(Column, Search Mask) {Repeating}

Parameter Description

Record Name The name the record will use in the future. A record name begins with
an alpha character and can have a maximum of 30 characters. You can
have only one description for a given record name. Record names are
not case sensitive—you cannot define both BASE and Base.

Search Keyword

Column Starting column number to search.

Search Mask Text to search for in the record columns.

Repeating (Optional) Keyword used to indicate there may be multiple records of

that type in a transaction.

Here are some examples:

< Records >
Message = Search(61,01) Repeating
Account = Search(61,02)

402
MessageFromExtr

Variable definition syntax Variable = Record(name) Offset(n) Length(n) Type(x)

Variable = GVM(name) Offset(n) Length(n) Type(x)
Variable = Record(name) Offset(n) Length(n) Type(x) Rule(name)
Format(flags)
Variable = Record(name) Offset(n) Length(n) Type(x) Format(flags)
Precision(n)

Parameter Description

Variable The name future references to this variable will use. A variable name
begins with an alpha character and can have a maximum of thirty (30)
characters.

Record(name) (Optional) Identifies the record in which this variable will be found. This
parameter is mutually exclusive when using GVM.

GVM(name) (Optional) The name of the global variable to use. This parameter is
mutually exclusive when using Record. Also keep in mind a rule is not
necessary with the global variable.

Offset The offset into the record where the data is located.

Length The length of the data.

Type(x) (Optional) May be either Char, Num, Zone, or Packed.

Char is character data. Can be any string of alphanumeric characters
and symbols.
Num is numeric data. Can have a sign in front and a decimal place.
Zone is zoned decimal. Looks like a numeric value except the sign is
added to the last digit.
Packed is packed decimal. A binary format used mainly on z/OS
systems.

Format(flags) (Optional) Similar to the flags used with the MoveNum rule except the
input flags (such as input length and precision, S, and B) are not
needed.

Rule(name) (Optional) You can include any field rule such as DateFmt or SetAddr2.
The Move_It and MoveNum rules are inherent to the Record Dictionary,
so you do not need to call them. If you omit a rule, the Move_It rule
functionality is the default.

Precision(n) (Optional) The number of decimal places for a numeric variable.

Here are some examples:

< Variables >
MSGTYPE = Record(Message)Offset(41) Length(1) Type(Char)
MSGGID = Record(Message)Offset(37) Length(2) Type(Zone)
GRPHID = Record(Graph) Offset(31) Length(8) Type(Packed)
PRTCOND1 = Record(Graph1) Offset(31) Length(8) Type(Num) Format(C)
PRTCOND2 = Record(Graph2) Offset(31)Length(8)Type(Num)Precision(5)
Total = Record(Address)Offset(50)Length(50)Rule(SetAddr2)

* OMR

RCBBATCH = GVM(RCBBatchName)Length(32)Type(Char)

403
Chapter 5
Image and Field Rules Reference

INI options This INI option is required. Place the Record Dictionary file in your DEFLIB directory.
< DataDictionary >
Name = (file name of the Record Dictionary)

Sample Record Dictionary Here is a sample Record Dictionary definition:

*
* This is the Record Dictionary
*
* These are the Records
* The only parameter is the record search mask. This can only be
* used for non-repeating records.
<Records>
Message = Search(61,01) Repeating
Account = Search(61,02)
MeterRead = Search(61,03) Repeating
Detail = Search(61,18) Repeating
*
*
* These are the variable definitions
* The required fields:
* Record name defined in the above section
* Offset into the record where the data begins
* Length of the data
* Optional fields:
* Formatting routine (data as is will be the default)
* Type or input format (not currently used)
<Variables>
***** The following are examples. All white space is ignored. ****
*
* AcctNum = Record(Header) Offset(4) Length(15) Type(Char)
* MessageText = Record(Message) Offset(53) Length(38) Type(Char)
* CompanyCode = Record(Header) Offset(24) Length(2) Type(Char)
* CustomerName = Record(Client) Offset(22) Length(21) Type(Char)
* NoticeDate = Record(Client) Offset(79) Length(8) Type(Num)
Rule(Date) Format( )
* CashReceived = Record(Client) Offset(313) Length (10) Type(Zone)
Rule(MoveNum) Format(10.2,13.2,$,S-)
*
ACSA = Record(Account) Offset(487) Length(10) Type(Zone)
Rule(MoveNum) Format(10.2,14.2,S-,C)
ACSC = Record(Account) Offset(497) Length(10) Type(Zone)
Rule(MoveNum) Format(10.2,14.2,S-,C)
ACBB = Record(Account) Offset(436) Length(10) Type(Zone)
Rule(MoveNum) Format(10.2,14.2,S-,C)
BMV1 = Record(Message) Offset(159) Length(15) Type(Char)
BMV2 = Record(Message) Offset(174) Length(15) Type(Char)
BMV3 = Record(Message) Offset(189) Length(15) Type(Char)
BMV4 = Record(Message) Offset(204) Length(15) Type(Char)
BMV5 = Record(Message) Offset(219) Length(15) Type(Char)
DTAT = Record(Detail) Offset(163) Length(10) Type(Zone)
Rule(MoveNum) Format(10.2,14.2,S-,C)
DTV1 = Record(Detail) Offset(181) Length(18) Type(Zone)
Rule(MoveNum) Format(18.8,18.2,S-,C)
DTV2 = Record(Detail) Offset(199) Length(18) Type(Zone)
Rule(MoveNum) Format(18.8,18.2,S-,C)

404
MessageFromExtr

DTV3 = Record(Detail) Offset(217) Length(18) Type(Zone)

Rule(MoveNum) Format(18.8,18.2,S-,C)
DTV4 = Record(Detail) Offset(235) Length(18) Type(Zone)
Rule(MoveNum) Format(18.8,18.2,S-,C)
DTV5 = Record(Detail) Offset(253) Length(18) Type(Zone)
Rule(MoveNum) Format(18.8,18.2,S-,C)
DTVM1 = Record(Detail) Offset(271) Length(15) Type(Char)
DTVM2 = Record(Detail) Offset(286) Length(15) Type(Char)
DTVM3 = Record(Detail) Offset(301) Length(15) Type(Char)
*
***The following is the grouping that is defined for messaging*
*
MsgLinePriority = Record(Message) Offset(96) Length(5) Type(Zone)
*
*
==============================================================

In this field... Enter...

Destination name CHECK BOX

Offset *

Length 1

Source name REC-CHECK BOX

Offset *

Length *

File *

Record *

Required *

Rule Mk_Hard

Mask *

Data X

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;;REC-CHECK BOX;;;CHECK BOX;;1;;Mk_Hard;X;;;;;

This example puts an uppercase X into the destination buffer for the field named
CHECK BOX. This field has a destination length of one character, and begins at offset 1
by default (since none was specified).

NOTE: Source offset and length have no significance to this rule since the source text
is coming from the Data field in the mapping.

SetCpyTo on page 470

Image and Field Rules Reference on page 294

407
Chapter 5
Image and Field Rules Reference

MNumExt
Use this field level rule (level 4) to perform the function of the MoveNum rule if an
external record is found. Enter the external record search criteria after the MoveNum
search criteria in the Data field. You can also enter a calculation after the external
search criteria. This rule supports overflow.
The format mask must contain the input numeric format, followed by the output
numeric format. These formats are in the form of X.Y, where X is the size of the number,
including any commas, currency symbols, and decimal points, and Y represents the
number of digits after the decimal point, such as:
10.2,12.2

The first pairing of X.Y describes the input. The second pairing describes the output. In
this example, 10.2 is the description of the data in the extract record and the output for
this would be 12 digits before and two digits after the decimal.
The format mask can contain any of these formats after the output numeric format:

Format Description

L Left justify the number

C Add commas

B Translate BCD number to decimal

Z Print number even if it equals zero (0)

$ Add a dollar sign ($)

NOTE: You cannot use the dollar sign ($) as the first character in the format mask
because this conflicts with the use of this character in the Move_It rule.

The data may contain a calculation to be performed upon the number obtained from the
extract record. The calculation must be separated from the search criteria by a space,
enclosed in parentheses, and contain spaces to separate each element (including
parentheses) in the equation string.
An X in the calculation is replaced by the value moved from the extract file. You must
place parentheses around each operator and its accompanying operands.

NOTE: This rule does not support an OR condition in the search mask. You can,
however, run multiple searches.

408
MNumExt

Image Editor example 1 If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name 1PAYAMT

Offset *

Length 18

Source name REC-1PAYAMT

Offset 64

Length 6

File *

Record *

Required *

Rule MNumExt

Mask 6.0, 11. 2, B

Data 17,PMSPAR01 17,PMSP0200,99,0 ( ( X * 50 ) + 2.50 )

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-1PAYAMT;64;6;1PAYAMT;;18;6.0,11.2,B;mnumext;17,PMSPAR01
17,PMSP0200,99,0 ( ( X * 50 ) + 2.50 );N;N;N;N;

The move occurs only if the record defined by the external search criteria is found. If
not found, zero is used in place of X.
If the external extract record matching the search format 17,PMSP0200 and 99,0 is
found, the current record defined by the search format 17,PMSPAR01 is searched to get
the numeric data from offset 64 for length 6.
The six-character BCD value located at offset 64 is then multiplied by 50. The system
adds 2.50, as specified by the operation ( ( X * 50 ) + 2.50 ), before copying the result
to the destination field. The destination field can contain up to 11 characters, including
the decimal point and two characters after.

409
Chapter 5
Image and Field Rules Reference

Image Editor example 2 This example shows the use of a user function and overflow symbol. If you make the
following entries on the Edit DDT tab of the field’s Properties window in Image Editor:

In this field... Enter...

Destination name TOTAL PREM

Offset *

Length 12

Source name TOTAL PREM

Offset 87

Length 6

File *

Record 1

Required *

Rule MNumExt

Mask 11.0,7.2,$,L

Data @GETRECSUSED,FORMABC,OVSYM/17,PMSPAR01
17,PMSP0200,99,0 ( ( X * 50 ) + 2.5 )

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;1;TOTAL PREM;87;6;TOTAL PREM;;12;7.2,11.0,$,L;MNumExt;
@GETRECSUSED,FORMABC,OVSYM/17,PMSPAR01 17,PMSP0200,99,0 ( ( X * 50 )
+ 2.5 );N;N;N;N;

B Used when mapping XML extract data. Here is an example:

;0;0;FIELD;0;1024;FIELD;0;1024;B;move_it;!/
descendant::My_Extract_Data/
FIELD.xml();N;N;N;N;3715;2899;11010;

C Centers the data.

D Converts the data returned by the rule into lowercase.

F Converts to sentence style where the first character is capitalized and the
remaining characters are lowercased.

G If you include this flag, the system always returns the data at the source length
and ignores the destination length.
If you omit the G flag, the Move_It rule returns data truncated to either the
source or destination length, whichever is shorter.
For instance, if you use the Move_It rule with a source length of 20 and a
destination length of 19, including the G flag returns 20 characters. Omitting
the G flag returns 19 characters.
If you include the ChkDestLenExceeded option in the RunMode control group
and set the option to Yes, the system reports any occurrence where the
destination length is less than the source length.

L Left justifies the data.

K Removes leading and tailing spaces.

N Searches for the next record in the transaction list instead of starting with the
first record. For example, assume the current transaction has five records (A,
B, C, D, and E) and the last record processed is C. If the next rule is Move_It and
it has the N flag set, the D record will be searched instead of starting at the top
(record A). When you include the Move_It rule and you are using overflow
(@UserFuncName options) do not use the N flag.

R Right justifies the data (for non-proportional fonts only).

SR Same record flag. This flag is similar to the N (next record) flag except it
assumes the data is in the record returned by the previous Move_it rule.
Note that SR only applies to the prior execution of a Move_It rule. You must
have at least one Move_It rule without the SR flag before you can add a
Move_It rule which uses this flag.

U Converts the data returned by the rule into uppercase.

$ A string proceeded by a dollar sign ($) is used as a sprintf format for the output
data.

411
Chapter 5
Image and Field Rules Reference

Format Description

8 Indicates the extract data for this field is stored in UTF-8 format. UTF-8
(Unicode Transformation Format, 8-bit encoding form) is a format for writing
Unicode data in text files. See Using Unicode Support for more information.

Blank Default, trims trailing spaces.

NOTE: Before version 10.0, this rule did not permit multiple flags. Beginning with
version 10.0, flags are executed in sequence, thus the particular order may
cause a difference in the formatted string output. When you use multiple
format mask flags, use a comma as a separator.

Do not use C, R, or L with K. The system intentionally skips K after C, R, or L is

mapped. If K occurs before C, R, or L, it will not affect C, R, or L mapping.

For example, if a K flag occurs first, the system clips the heading and tailing spaces and
then formats the string. If a K flag occurs second in the format string, the system
formats the string and then clips the heading and trailing spaces.
You can do some interesting things by handling the flags in sequence, you can clip (K)
the input data, format ($) the string, right justify (R) the result, and format ($) it again.
On the other hand, you can do some things that don't make sense, like center justify
(C) the data and then clip (K) the result. This sequence negates the center justification.
The same applies to right (R) and left justification (L) if you put a K in the format
afterwards.
Furthermore, what order would you expect R, C, and L applied especially when mixed
with the format ($)? Just like the clip flag (K), if you right justify (R) first and then format
($), you will likely get different results than if you format ($) first and then right justify
(R).

NOTE: If you apply this rule to a multi-line variable field, make sure destination length
is greater than one (1). Otherwise, no data will be mapped. This happens
because when you create a multi-line variable field, its length is zero (0) and
its destination length in the DDT file is also set to zero. While some rules, such
as the Mk_Hard rule, map data even if the destination length is zero, the
Move_It rule will not.

Handling currency Let’s assume you have variable fields that represent amounts. The extract data is pre-
symbols formatted as character text (left justified), which represents the correct currency
format. Unfortunately, the extract data does not include the currency symbol. You have
to add the currency symbol.
Depending on the nationality, the currency symbol can appear at the beginning of the
amount, like the dollar sign, or it can appear at the end of the amount, such as FF for
French Francs.
Beginning with version 10.0, you can use a format of K,$%sFF to add the currency
symbol.

412
Move_It

The K would come first to indicate the space before and after the input data should be
removed, then FF would be appended.
So K,$%sFF is not the same as $%sFF,K. The former clips the input data before the
format is applied. The latter clips the data after the format has been applied.
For currency symbols that appear at the beginning of the data, such as British pound
sterling, you could use the Move_It rule with a format mask of $£%s. This works
because trailing spaces are trimmed. For currency symbols at the end of the data, this
will not work.

User functions The Move_It rule supports the use of @UserFuncName functions. User functions let you
move data from the source record to the output buffer based on the outcome of a user-
defined function. User functions and their parameters are specified in the data field
before the search criteria.

413
Chapter 5
Image and Field Rules Reference

Image Editor example In this example, the user function name is GetRecsUsed and has two parameters. FORM
NAME and VAR; / denote the end of the parameter list and the start of the search
criteria.
;Move_It;@GETRECSUSED,FORM NAME,VAR/17,00,15,B;;;;;
If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name POLNUMBER

Offset 1**

Length 10

Source name REC-POLNUMBER

Offset 50

Length 10

File *

Record * (generally not required unless you are also using overflow)

Required *

Rule Move_It

Mask *

Data 17,PMSP0200

* no entry required for this field in this example

**if you set the offset field to zero (0), the system automatically defaults to 1.

In the DDT file, this information looks like this:

;;;REC-POLNUMBER;50;10;POLNUMBER;1;10;;Move_It;17,PMSP0200;;;;;

This rule gets the first occurrence of a record matching the search criteria of PMSP0200
at offset 17. From the extract record, ten characters from offset 50 are moved to the
output buffer (which also happens to be 10 characters in length).

414
Move_It

This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name POLNUMBER

Offset 1

Length 10

Source name REC-POLNUMBER

Offset 50

Length 10

File *

Record 1 (required with overflow)

Required *

Rule Move_It

Mask *

Data @GETRECSUSED,FORMABC,OVSYM/17,PMSP0200

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;1;REC-
POLNUMBER;50;10;POLNUMBER;1;10;;Move_It;@GETRECSUSED,FORMABC,OVSYM/
17,PMSP0200;;;;;

In this field... Enter...

Destination name POLNUMBER

Offset 1

Length 10

Source name REC-POLNUMBER

Offset 50

Length 10

File *

Record *

Required *

Rule MoveExt

Mask *

Data 17,PMSP0200 17,IPMSR01,99,T1

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;;REC-POLNUMBER;50;10;POLNUMBER;1;10;;MoveExt;17,PMSP0200
17,IPMSR01,99,T1;;;;;

416
MoveExt

The move only occurs if the record defined by the external search criteria is found. If
the extract record matching the search format 17,IPMSR01,99,T1 is found, the record
defined by the search format 17,PMSP0200 is searched to get the text from offset 50
for the length of 10 characters.
This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name POLNUMBER

Offset 1

Length 10

Source name REC-POLNUMBER

Offset 50

Length 10

File *

Record 1

Required *

Rule MoveExt

Mask *

Data @GETRECSUSED,FORMABC,OVSYM/17,PMSP0200
17,IPMSR01,99,T1

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;1;REC-
POLNUMBER;50;10;POLNUMBER;1;10;;MoveExt;@GETRECSUSED,FORMABC,OVSYM/
17, PMSP0200 17,IPMSR01,99,T1;;;;;

Image Editor example ;MoveMeToPage;;3;

This example moves the image to the third page of the form set.
;MoveMeToPage;;0;

This example moves the image to the last page of the form set.

+ Tells the system to always include a sign with all numbers.

% Appends a percent sign (%) at the end of the number.

$ Adds a dollar sign. The dollar sign cannot be the first character in the
format mask. This limitation arises from the Move_It format option, where
a dollar sign ($) in the first character of the mask means to perform a
sprintf.

419
Chapter 5
Image and Field Rules Reference

Mask Description

A Removes the trailing spaces after an extract value if the input data type is
neither BCD nor Packed Decimal. For example, assume the data value is
“100000 “ (a one followed by five zeros and two spaces).
If you omit this flag and select a 12.2 output format with commas, the
value generated will be “ 100,000.00”. If you include this flag, the result
will be “ 1,000.00”.

B Translates a BCD number into a decimal. If the data is in EBCDIC format,

use this flag instead of the BA flag.

BA Translates a BCD number into a decimal. Use this flag for ASCII signed
numbers.

C Adds commas to the output.

C** Adds commas if the data is in US English format or spaces if the date is in
Canadian French format.

CR Appends CR (credit) to the end of the number.

CS1 Enter one of these options to indicate the checksum method.

CS2 The system appends a check digit (mod 10) of 0 through 9 to the end of the
CS731 number. This is typically used in accounting to make sure a number, such
as an account number is correct by performing a formula on each digit. For
details, see the discussion on page 423.

D Dollars (a combination of B, C, and $). You must modify

GEN_FMT_FmtMaskSaysBinary to recognize this format.

E Stops a calculation if the search condition is false. The Move_It rule may
return a null output buffer if: no record was found; a record was found, but
the search mask contained a pairing (offset,data) which extended past the
end of the record; or a record was found, but the mapped data was blank.

F Add a dollar sign ($) and place it in the first position. If the value is
negative, move the minus sign (-) to the last position.

G Tells the MoveNum rule not to use the Move_It rule to get the data from
the extract file. See Extracting data on page 426 for more information.

L Left justifies the number in the variable field.

-L (or --) Tells the system to use a floating negative sign on negative values.

+L (or Tells the system to use a floating sign and to always show that sign.
++)

Lang Selects a language for spelling out the number. This flag is used with the
V flag and mask parameters. Here is an example: US, CFR.

M Money (This format is a combination of formats C and $.)

420
MoveNum

Mask Description

N Leave the output buffer blank if the number is zero or negative.

NM Adds a minus sign (-) to the number.

-O Places a negative sign outside the right side of the field definition. This
allows positive and negative numbers to right align on the page if you use
a fixed font. Here is an example using this input format: 10.2,10.2,-O:
input data: 0000009.99
-000012.25
output: 12345678901234567890
**********
9.99
12.25-

On Sets the output field size to n and overrides the output size of the field.
Here is an example using this input format: 10.2,10.2,O8:
input data: 0000009.99
-000012.25
output: 12345678901234567890
**********
9.99
-12.25

input format: 10.2,10.2,O12

input data: 0000009.99
-000012.25
output: 12345678901234567890
**********
9.99
-12.25

P Print leading zeros. You cannot use this format with $, -, C, and F.

Pn Pads the output zeroes to n total width. This parameter only works with
whole numbers, not decimals. Here is an example using this input format:
10.0,10.0,P4:
input data: 0000000001
0000000025
0000012345
output: 12345678901234567890
**********
0001
0025
12345

P** Prints leading zeros if used without character or symbol enclosed with
single quote.

R Tells the system to retain the minus sign (-) if the result is less than zero.
Use with signed numbers.

421
Chapter 5
Image and Field Rules Reference

Mask Description

-R Places a negative sign on the right side of the field (within the field). Here
is an example using this input format: 10.2,10.2,-R:
input data: 0000009.99
-000012.25
output: 12345678901234567890
**********
9.99
12.25-

R** Retains the sign when translating a signed data value into decimal. Use
with the S flag.

S Translates signed data to a decimal.

SLZ Suppress leading zeros. For example, 00.25 becomes .25.

T Adds text before or after a number. Use the less than (<) symbol for
inserting before, the greater than (>) symbol for inserting after. Use the
comma as a separator.
Use with the NegText, Text, and ZeroText data options.
You can also use this option to place currency symbols before or after
amounts. For instance, T>£ places the British pound sterling symbol
(ALT+0163) before an amount.

TA Same as T>

TB Same as T<

SP Same as E

V Spells out the numeric value in US English.

X Adds X to the front of the number.

Z Print a number even if it is zero.

Z2 Prints two zeros.

For example…

Input string Format mask Output string

1234567890 10.2,15.2,C,$,L $12,345,678.90

…tells the system to take a ten-character input string with two decimals (10.2) and
output it as a 15-character string with two decimals (15.2), commas (C), a dollar sign
($), and left-justified (L).
This rule respects the number of decimals in the source. For instance, if you have the
number “ 1.2" defined as using a mask of 6.2, the system outputs 1.20 instead of 0.12.

422
MoveNum

Understanding the System The MoveNum and AccumulateVariableTotal rules support three checksum methods.
These methods only work on the integer portion of a number. The system ignores the
decimal portion of the number.
CS1 works from right to left. CS2 works from left to right. These two algorithms are
exactly the same except for the direction in which they work. The calculation works like
this:
The odd number digits are multiplied by 2. If that result is greater than 9, then 9 is
subtracted from the value. The result is added to the sum. The even number digits
are simply added to the sum.
Once all the digits values have been summed, the total is divided by 10. The
remainder of this division is subtracted from 10 and that becomes the check-digit.
If the resulting value is 10, then zero (0) will be the check-digit.
Here are some examples. In all cases, assume the value is 346,100.99.
The CS1 calculation works like this: (notice the digits are addressed backwards)
(0 x 2) + 0 + (1 x 2) + 6 + (4 x 2) + 3
0 + 0 + 2 + 6 + 8 + 3 = 19
( 19 mod 10) = 9
10 - 9 = 1

The resulting number will be 346,100.991.

The CS2 calculation works like this:
(3 x 2) + 4 + ((6 x 2)-9) + 1 + (0 x 2) + 0
6 + 4 + 3 + 1 + 0 = 14
(14 mod 10) = 4
10 - 4 = 6

The resulting number will be 346,100.996

Note that in the CS1 example, the third digit—an odd number digit—is multiplied by 2
and exceeds 9. Therefore 9 is subtracted from that result before proceeding to the next
number).
CS731 is the other checksum method. This method works from left to right. Unlike the
other two methods which use an even/odd multiplier, this method has three
multipliers. The first digit is multiplied by 7, the next by 3, and the next by 1. This
process is repeated until all digits have been multiplied. Unlike the other methods, it
does not matter if a the result of a digit multiplication exceeds 9.
CS731 calculation works like this:
(3 x 7) + (4 x 3) + (6 x 1) + (1 x 7) + (0 x 3) + (0 x 1)
21 + 12 + 6 + 7 + 0 + 0 = 46
(46 mod 10) = 6
10 - 6 = 4

The resulting number will be 346,100.994

Data The data can contain a calculation to be performed on the number in the extract record.
Separate the calculation from the search criteria with a space, enclosed in
parentheses. Use spaces to separate each element (including parentheses) in the
equation string.

423
Chapter 5
Image and Field Rules Reference

An X in the calculation is replaced by the value moved from the extract record. You must
place parentheses around each operator and its accompanying operands.

NOTE: If you have zeros in your extract file, the MoveNum rule converts these zeros
into blanks unless you include the Z option.

Option Description

NegText If the value is negative, this option lets you insert user-defined text before
and/or after the negative value.

RPN (x) Allows a calculation to be performed using reverse Polish notation.

Text Lets you print text before and after the number.

X Adds X to the front of the number.

ZeroText If the result is zero, this option lets you insert user-defined text instead of
the zero value.

Image Editor example This example...

;0;0;AMOUNT;75;10;AMOUNT;0;10;10.2,10.2,T;MoveNum;11 HEADERREC
Text("French $" "FF");N;N;N;N;

...produces: French $ 123FF.

This example...
;0;0;AMOUNT;75;10;AMOUNT;0;10;10.2,10.2,T;MoveNum;11 HEADERREC
NegText("" "CR");N;N;N;N;

...produces: 123 CR.

This example...
;0;0;AMOUNT;75;10;AMOUNT;0;10;10.2,10.2;MoveNum;11 HEADERREC
ZeroText("ZERO");N;N;N;N;

...produces ZERO if the number is 0 (zero).

This example...
;0;0;AMOUNT;75;10;AMOUNT;0;10;10.2,10.2;MoveNum;11 HEADERREC RPN(X X
+ 2 /) "FF");N;N;N;N;

...produces the number if it is a positive number.

If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name TOTALPREM

Offset *

Length 12

424
MoveNum

In this field... Enter...

Source name REC-TOTALPREM

Offset 87

Length 6

File *

Record *

Required *

Rule MoveNum

Mask 11.0,7.2,$,L

Data 17,PMSP0200 ( ( X * .50 ) + 2.50 )

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-
TOTALPREM;87;6;TOTALPREM;;12;7.2,11.0,$,L;MoveNum;17,PMSP0200 ( ( X
* .50 ) + 2.50 );N;N;N;N;

This example takes the numeric value represented by the six characters at offset 87 in
the record found using the search criteria of 17,PMSP0200. That value is then
multiplied by .50.
Then the system adds 2.50, left justifies the output, and adds a leading dollar sign ($).
The numeric output can contain up to 11 characters before the decimal point, and zero
(0) after.
This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name TOTALPREM

Offset *

Length 12

Source name REC-TOTALPREM

Offset 87

Length 6

File *

425
Chapter 5
Image and Field Rules Reference

Record 1

Required *

Rule MoveNum

Mask 11.0,7.2,$,L

Data @GETRECSUSED,FORMABC,OVSYM/17,PMSP0200 ( ( X * .50 ) +

2.50 )

* no entry required for this field in this example

Extracting data Typically, the MoveNum rule uses the Move_It rule to get numeric data from the extract
record before formatting the numeric data. The Move_It rule only copies the least
number of characters possible. If the destination length is shorter than the source
length, this means that the destination length is used instead of the source.
Normally, this is fine with numeric processing because extract files typically contain
unformatted data. For example, you might pick up 123456 and turn it into
$$$$$1,234.56 or some other valid format. In these cases, the destination is almost
always longer than the source length.
There are cases, however, where the extract data is already formatted in some fashion
that’s longer than the expected destination. For example 00000001234 might appear
in the extract and yet the desired format expected for output is known to never exceed
6.2, such as 9999.99.
In this case, if you use the Move_It rule to get the data the result would be 0000000
because the destination length is only seven characters—shorter than the 11 character
source length.
The G flag tells the MoveNum rule not to call the Move_It rule and instead use an
alternate function that retrieves the entire source length before it formats the data for
the destination length.
In the DDT file, this information looks like this:
;0;1;REC-TOTALPREM;87;6;TOTALPREM;;12;7.2,11.0,$,L;MoveNum;
@GETRECSUSED,FORMABC,OVSYM/17,PMSP0200 ( ( X * .50 ) + 2.50 )
;N;N;N;N;

The system substitutes zero (0) for X and calculates the format when the search
condition is not met.

NOTE: You can use format E to stop the calculation when the search condition is false.

In this field... Enter...

Destination name NEW_BAL

Offset 0

Length 15

Source name NEW_BAL

Offset 0

Length 0

File 0

Record 0

Required *

Rule MoveSum

Mask 15.2

427
Chapter 5
Image and Field Rules Reference

In this field... Enter...

Data TBAL,TBAL2

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0; NEW_BAL;0;0;NEW_BAL;0;15;15.2;MoveSum;TBAL,TBAL2;N;N;N;N;

This rule tells the system to look up the variable TBAL in the Record Dictionary table
named DATADICT.TBL located in the TblLib directory. Then the system gets from the
EXTRFILE.DAT file the first occurrence of a record matching the search criteria of
PMSP0200 at offset 17 as defined in Account under < Records >.
The output consists of 12 characters from offset 18. It is a zoned decimal with two
position precision. The same procedure is applied to the second variable TBAL2. The
system gets from the EXTRFILE.DAT the first occurrence of a record matching the search
criteria of PMSP0200 at offset 17 as defined in Account under < Records >.
The output consists of eight characters from offset 38. It is a zoned decimal with two
position precision. Finally, these two numbers are added and the result is stored in the
variable NEW_BAL. The length of the sum number is 15 and the precision is two
decimals.

In this field... Enter...

Destination name AGENTNAME1

Offset 1

Length 30

Source name REC-AGENTNAME1

Offset 10

Length 20

File *

Record *

Required *

Rule MovTbl

Mask *

Data 1,AGENT001

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-AGENTNAME1;10;20;AGENTNAME1;1;30;;MovTbl;1,AGENT001;;;;;

Here, the system will find a maximum of 20 characters at offset 10 in the first record in
the table with a key value of AGENT001 at offset 1. It then moves the information to the
destination field.

In this field... Enter...

Destination name DESTNAME

Offset *

Length *

Source name SRCNAME

Offset *

Length *

File *

Record *

Required *

Rule NoOpFunc

Mask *

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;;;SRCNAME;;;DESTNAME;;;;NoOpFunc;;;;;;

431
Chapter 5
Image and Field Rules Reference

NOTE: When you use the NoOpFunc rule, many of the fields which would otherwise be
required for processing are not needed. If, however, any of the other fields
contain data, this will not affect the operation of the NoOpFunc rule. The
system lets the NoOpFunc rule replace any rule on an existing line in a DDT file.

Syntax OvActPrint (Image, OvSymbol)

Parameter Description

Image Name of the overflow image

OvSymbol Name of the overflow symbol defined by the SetOvFlwSym rule

For instance, assume an overflow image can handle five overflow records before being
forced to another page and a transaction contains seven overflow records. This rule
would state the output as 7—five for the first page, plus two for the second page.
This rule supports only automatic overflow.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name INC

Offset *

Length 15

Source name REC-INC

Offset *

Length *

File *

Record *

Required *

Rule OvActPrint

Mask *

Data FORMABC,ITEMSYM **

* no entry required for this field in this example

** The data field contains a form name and overflow symbol, separated by a comma.

433
Chapter 5
Image and Field Rules Reference

The information in the DDT file will look like this:

;0;0;REC-INC;0;0;INC;0;15;;OvActPrint;FORMABC,ITEMSYM;;;;;

This example outputs to a destination field the actual number of overflow records
processed for the form/overflow symbol combination of FORMABC, ITEMSYM.

Syntax OvPrint (Image, OvSymbol)

Parameter Description

Image Name of the overflow image

OvSymbol Name of the overflow symbol defined by the SetOvFlwSym rule

For instance, assume an overflow image can handle five overflow records before being
forced to another page and a transaction contains seven overflow records. This rule
would state the output as 10—five for the first page, plus five for the second page.
This rule works with the IncOvSym rule.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name INC

Offset *

Length 15

Source name REC-INC

Offset *

Length *

File *

Record *

Required *

Rule OvPrint

Mask *

Data FORMABC,ITEMSYM**

* no entry required for this field in this example

**The data field contains a form name and overflow symbol, separated by a comma.

435
Chapter 5
Image and Field Rules Reference

In the DDT file, this information looks like this:

;0;0;REC-INC;0;0;INC;0;15;;ovprint;FORMABC,ITEMSYM;;;;;

This example counts the maximum number for the overflow records used for the form,
overflow symbol combination of FORMABC, ITEMSYM.

Image Editor example ;PaginateBeforeThisImage;;;

String A character string that contains a DAL function or DAL script.

Where A is a DAL variable you wish to assign. The bracketed {} item can be almost any
standard search mask supported by the Get Record infrastructure. In this case,
1,MIS257 is the search criteria. If the record is found, the system takes the data from
position 138, length 1 as indicated by 138,1.
This method also lets you specify an occurrence of the record by including a hyphen
with a numeric value, such as -n, after the data length. Here is an example:
A = {1,MIS257 138,1-5}

Here the function searches for the 5th occurrence of the 1,MIS257 record. If you omit
the occurrence, the system returns the first one found. If it cannot find the requested
record, the system assigns the variable an empty “” value.

Image Editor example ; PostImageDAL;;Chain("posttran.dal");

This example executes the Chain DAL function which then executes the DAL script
contained in the POSTTRAN.DAL file in the DefLib directory specified in your MRL.
; PostImageDAL;;If HaveGVM("main_address") Then
SetGVM("main_address", "25 Brown St.", , “C”, 20)::End;

In this example, the system checks to see if the GVM variable (main_address) exists. If
not, it creates a character array GVM variable (main_address) 20 characters in length
and stores the character string (25 Brown Street) in the array.

438
PostImageDAL

In this field... Enter...

Destination name ADDR1

Offset *

Length 40

Source name INSNAMEREC-INSNAME1

Offset *

Length *

File *

Record *

Required Operator

Rule PowType

Mask *

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;INSNAMEREC-
INSNAME1;0;0;ADDR1;0;40;;PowType;;N;N;Y;N;87;1406;12010

In this example, the operator required flag for the INSNAMEREC-INSNAME1 field must
be set if you want this field to be editable in the entry system when it is retrieved from
manual batch (WIP).

440
PowType

Suppressing Warning Messages

Use the ShowWIPWarning option to suppress the Sent to Manual Batch warning
messages:
< RunMode >
ShowWIPWarning = No

Option Description

ShowWIPWarning Enter No to suppress warning messages included the error logs

when using the KickToWIP or POWType rules, or the KickToWIP
DAL function.
The default is Yes, which tells the system to include the
messages in the error logs.

String A character string that contains a DAL function or DAL script.

Image Editor example ; PreImageDAL;; service_id={1,PrePost,22,Elect

1,8}::Call("postimage.dal");

This example executes the Call DAL function which executes the DAL script contained
in the POSTIMAGE.DAL file in the DefLib directory in your MRL.
This example sets the internal DAL variable, service _id, to the first eight-characters in
the transaction record that match the search mask:
1,PrePost,22,Elect

Then the Call DAL function executes the DAL script in the POSTIMAGE.DAL file, which
resides in the DefLib sub-directory in your MRL.

442
PreImageDAL

; PreImageDAL;;If (HaveGVM("main")) Then SetGVM("main_address", "25

Brown St.", , “C”, 20)::End;

The user-defined condition is comprised of one or more user-defined definitions

separated by a colon (:). A user-defined definition is comprised of two parameters
separated by an equal sign (=). User-defined definition parameters contains the...

• Character string to be compared against

• Character string to be placed in the output buffer, if the comparison is true
Here are some examples:
Inc=Extra premium due to age is included.
Exc=Age premium has been excluded.
Y=Age premium is not applicable.
Inc=Age premium is included.:Exc=Age premium excluded.:Y=N/A

You can use these format flags:

Flag Description

C Center

R Right justify

The system justifies the data by adding spaces in front of the text. If you are using a
proportional font, do not use these flags to align the data. Use the JustFld rule for that.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name PREMB1

Offset *

Length 4

Source name REC-PREMB1

Offset 285

444
PrintIf

In this field... Enter...

Length 1

File *

Record *

Required *

Rule printif

Mask *

Data 17,ASBLCPL1 Y=INCL:N=EXCL

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-PREMB1;285;1;PREMB1;;4;;PrintIf;17,ASBLCPL1
Y=INCL:N=EXCL;N;N;N;N;

This will put INCL into the field if record ASBLCPL1 offset 285 length 1 = “Y”, or EXCL if
record ASBLCPL1 offset 285 length 1 = “N”.

NOTE: Separate the record search criteria and the user-defined condition criteria
using a blank space in the data field of the rule.

> greater than

< less than

<> not equal to

Blank (default) No comparison occurs, text is moved to output buffer

• Character string (inside quotation marks) to be placed in the output buffer if the
comparison is true.
Here are some examples of user-defined conditions:
=40="He is forty years old."
The logical operator is equal to, the numeric value is 40, and the character string if the
comparison is true is He is forty years old.
>50="He is greater than 50 years old."

The logical operator is greater than, the numeric value is 50, and the character string if
the comparison is true is He is greater than 50 years old.
<30="He is less than 30 years old."

The logical operator is less than, the numeric value is 30, and the character string if the
comparison is true is He is less than 30 years old.
<>20="He is not 20 years old."

The logical operator is not equal to, the numeric value is 20 and the character string if
the comparison is true is He is not 20 years old.
=40.0="Forty years old.":>50="Greater than 50":<30="Less than
30.":<>20.00="Is not 20.":29="29 years old."
This user-defined condition is comprised of five user-defined definitions.

• If the value from the extract record is equals to 40.0, the string Forty years old. is
moved to the output buffer.

446
PrtIfNum

• If the value from the extract record is greater than 50, the string Greater than 50 is
moved to the output buffer.
• If the value from the extract record is less than 30.0, the string Less than 30 is
moved to the output buffer.
• If the value from the extract record is not equal to 20.00, the string Is not 20 is
moved to the output buffer.
• In this definition, the logical operator does not exist so no comparison is made. If
one of the other four user-defined condition is not true, the string 29 years old. is
moved to the output buffer.

NOTE: You must define the MoveNum parameters (format mask) in the PrtIfNum rule
mask field. As a minimum, you must define the MoveNum input numeric format
(X.Y) followed by the output numeric format (X.Y).

If data (offset, length) does not exist for the search mask, the value returned to
PrtIfNum for the comparison is zero (0). Therefore, you may want to include a
zero compare in the user-defined conditions.

For example, suppose you left the No check box blank if the data is three and
an X if the data is a one, two, or four. These user-defined conditions...

=3=” “: <>3=”X”

would not produce the desired results if the data was missing (blank). These
conditions...

=0=” “:=3=” “: <>3=”X”

would insert a blank if the data was missing.

Image Editor example If you want a six-character packed decimal located at offset 200 in a record identified
by an XYZ at location 100, and base it on the numeric value, you would do the following:

• If it equals 40, print MIDDLE AGE

• If less than 40, print YOUNGSTER
• Otherwise (default) print SENIOR
Your entries on the Edit DDT tab on the field’s Properties window would look similar to
the following:

In this field... Enter...

Destination name AGEDESC

Offset 1

Length 18

Source name REC-AGEDESC

Offset 200

447
Chapter 5
Image and Field Rules Reference

In this field... Enter...

Length 6

File *

Record *

Required *

Rule prtifnum

Mask 11.0, 18.0, B

Data 100,XYZ =40=”MIDDLE AGE”:<40=”YOUNGSTER”:”SENIOR”

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-AGEDESC;200;6;AGEDESC;1;18;11.0,18.0,B;PrtIfNum;100,XYZ
=40="MIDDLE AGE":<40="YOUNGSTER":"SENIOR";;;;;

NOTE: A space separates the record search mask “100,XYZ” and the following logic.

Further suppose you name the fields in this order,

;RemoveWhiteSpace;FIELD_A,FIELD_B,FIELD_C,FIELD_D;

FIELD_A does not move because there is no earlier named field. FIELD_B and FIELD_C
are empty. The data from FIELD_D will move to FIELD_B — the earliest field that is still
empty. The result is:
FIELD_A = ABCDEFG
FIELD_B = TUVWXYZ
FIELD_C =
FIELD_D =

Now suppose you specify the field parameters like this:

;RemoveWhiteSpace;FIELD_D,FIELD_C,FIELD_B,FIELD_A;

The result is:

FIELD_A =
FIELD_B =
FIELD_C = ABCDEFG
FIELD_D = TUVWXYZ

NewSize Choose one of these options:

FooterTop - Makes the objects on the image fit over the top of the footer by
resetting the bottom dimensions.
HeaderBottom - Makes the objects on the image fit under the bottom of the
header by resetting the top dimensions.
MinHeight - Resizes the image to occupy the least amount of space. No
objects are omitted or resized, but unused space is removed.
LastField - Resizes the image to occupy the least amount of space. Only the
fields with data are examined when the system looks for the lowest point
on the image. Use this option on images that have only fields or no objects
lower than the last few fields you expect to map

The parameters are not case sensitive.

Understanding the System In legacy implementations, where only DDT files were loaded and not FAP files, fields
are the only objects on an image the ResetImageDimension rule recognizes. That
meant image bottoms were most likely being assigned at the last mapped field. In
subsequent releases and because of new features and the new Studio model of
development, FAP files are loaded during batch runs. Therefore, to get behavior similar
to what you had in legacy implementations, you must either change the
ResetImageDimension rules to use the LastField parameter, or use the
RID_LastMapField INI option to change the behavior of the MinHeight parameter.
When you use the LastField option, the bottom of the image is moved to a position
below the lowest mapped field on the image. This is what you want in situations where
the next image should be placed immediately below where the last field was mapped.
For instance, assume you have a small image used for addresses. It can contain up to
eight lines, but depending upon the address only two or three lines might be used and
you would like to set the bottom of the image below where the last field was mapped.
Here is an example:
<Image Rules>
;ResetImageDimension;LastField;

NOTE: Depending upon your print or display method, changing the bottom of the
image with this parameter could mean that any objects below this point will
not be visible and may not print. Or it could mean those objects will simply
overprint the next image in sequence on the same page.

You can also use the RID_LastMapField INI option to change the MinHeight parameter
to work like the new LastField option described above.
< RunMode >

452
ResetImageDimensions

RID_LastMapField = Yes

(RID is an abbreviation for ResetImageDimension.)

The default is No. Enter Yes if you want to modify the behavior of the MinHeight
parameter on all images that would use the ResetImageDimension rule.

NOTE: Depending upon your print or display method, changing the bottom of the
image with this option could mean that any objects below this point will not be
visible and may not print. Or it could mean those objects will simply overprint
the next image in sequence on the same page.

Also note that the term last field refers to the lowest field mapped on an image and not
the physical sequence in which the fields are mapped. The lowest field is the one that
is the greatest distance from the top of the image.

Image Editor example This example shows a DDT file excerpt:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,298,15965,0,600,0,480;
;SetOrigin;REL+0,MAX+0;
;PaginateBeforeThisImage;;
;ResetImageDimensions;MinHeight;
;DontPrintAlone;;

This example resets the image dimensions to occupy the least amount of space.

Syntax ;ResetOvSym;OverflowSymbol, ImageName;;

Parameter Description

OverflowSymbol The name of the overflow symbol defined in the SetOvFlwSym rule.

ImageName The name of the Image that contains the fields on which overflow
processing will occur.

Image Editor example ;ResetOvSym;;Symbol_A,Image_AA;

This example tells the system to reset the overflow variable named Symbol_A which is
used in the image named Image_AA.

Syntax SetGroupOptions; (Header or Footer), CopyOnOverFlow;;

Parameter Description

Header Defines the images that appear before the group.

Footer Defines the images that appear after the group.

CopyOnOverflow Defines the images that are copied to the new page if group
pagination splits the group.

NOTE: The header and footer parameters are mutually exclusive.

Keep in mind...

• When an image contains both a GroupBegin rule and a SetGroupOptions rule, the
GroupBegin rule must come first.
• When an image contains both a GroupEnd rule and a SetGroupOptions rule, the
SetGroupOptions rule must come first.
• You must set all group pagination image options (footer, header, and
CopyOnOverflow) using the SetGroupOptions rule.

Image Editor example This DDT file excerpt defines this image as the header which should be copied to the
new pages if the group pagination splits the group because of overflow.
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,1142,19718,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
;GroupBegin;GroupPagination();;
;SetGroupOptions;header,copyonoverflow;

This DDT file excerpt defines this image as the footer which should be copied to the
new pages if the group pagination splits the group because of overflow.
/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,1142,19718,0,0,0,0;
;SetOrigin;Rel+0,Max+100;
;GroupBegin;GroupPagination();;
;SetGroupOptions;footer,copyonoverflow;

Enter To take a date in this format... And output it in this format...

1 YYMMDD MMDDYY

2 YYYYMMDD MMDDYYYY

3 YYYYMMDD MMDDYY

4 YYMMDD MM-DD-YY

5 YYMMDD MM/DD/YY

6 YYYYMMDD MM-DD-YY

7 YYYYMMDD MM/DD/YY

8 MMDDYY MM-DD-YY

9 MMDDYY MM/DD/YY

10 YYYMMDD MM/DD/YY

D inFmt is one of the standard date outFmt is also a standard date format for
formats which consists of a format the destination field and is separated
character, optional date separator, from the inFmt by a colon (:).
and an optional year size (2 or 4).

For compatibility with prior releases, masks (1 through 10) and the destination formats
with a single letter, such as D, indicate the system will omit leading zeros or spaces.
Also, please note that Month indicates both upper- and lowercase letters are used
while MONTH indicates only uppercase letters are used. Mon indicates the month will
be abbreviated in upper- and lowercase letters.

Using locales If you use one of the standard formats, use the @XXX (without the percent). For
example, D44@CAD is the standard format for Month DD, YYYY in Canadian French. If
you are creating your own format, use %@???. For instance, D%@CAD%B %#d, %Y
yields the same result as the standard format D44@CAD.
Keep in mind that the run date is typically stored in YYYYMMDD format and therefore
does not require any locale information on the input format.

456
RunDate

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name Date

Offset *

Length 10

Source name REC-Date

Offset *

Length *

File *

Record *

Required *

Rule RunDate

Mask DM-4:44

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-Date;0;0;Date;0;10;DM-4:44;RunDate;;N;N;N;N;
So, if your RunDate extract (Input) field is in the format DD-Mon-YYYY and you want a
form (output) field to have the format Month D, YYYY, you would define the mask like
this:
DM-4:44

The D tells the system what conversion method to use. M-4 indicates the input format
is DD-Mon-YYYY. And 44 indicates the output format is Month D, YYYY.
Or, if you have used the new TRN_FIELDS conversion support to have the GenTrn
program change the RunDate to YYYYMMDD, you can use this mask definition:
DD4:44

Here everything is the same except the input format of D4, which indicates YYYYMMDD
as the format of RunDate.

457
Chapter 5
Image and Field Rules Reference

Here is another example:

If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name DATE

Offset *

Length 8

Source name REC-DATE

Offset *

Length *

File *

Record *

Required *

Rule RunDate

Mask 6

Data *

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;0;REC-DATE;0;0;DATE;0;8;6;RunDate;;N;N;N;N;

Format mask The format mask can consist of these options:

C Center the text
R Right justify the text (for non-proportional fonts only)

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter...

Destination name CAUFVD_P-MATNR

Offset 0

Length 10

Source name CAUFVD_P-MATNR

Offset 173

Length 3

File *1

Record 1 (generally not required unless you are also using overflow)

Required *1

Rule SAPMove_It

Mask *1

Data 42,CAUFVD_P-MATNR

*1 means that no entry is required for this example

In the DDT file, this information looks like this:

;;;Caufvd_P-Matnr;173;3;Caufvd_P-Matnr;0;10;;SAPMove_It;42,
Caufvd_P-Matnr;;;;;

In this example, the rule gets the first occurrence in the extract file of a record matching
the search criteria of CAUFVD_P-MATNR at offset 173. From the extract record, 3
characters (which contains the length of the data that will follow it) are moved to the
output buffer.
The rule then reads the extract record again, this time from offset 176, and copies x
characters (where x is the 3-byte length that was just read) from the extract record to
the output buffer (which in this case is defined to be 10 characters in length).

459
Chapter 5
Image and Field Rules Reference

This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name CAUFVD_P-MATNR

Offset 0

Length 10

Source name CAUFVD_P-MATNR

Offset 173

Length 3

File *1

Record 1 (required for overflow)

Required *1

Rule SAPMove_It

Mask *1

Data @GETRECSUSED,S4TOP,S4TOPOVF/42,CAUFVD_P-MATNR

*1 means that no entry is required for this example

In the DDT file, this information looks like this:

;;1;Caufvd_P-Matnr;173;3;Caufvd_P-Matnr;0;10;;SAPMove_It;
@GetRecsUsed,S4Top,S4TopOvf/42,Caufvd_P-Matnr;;;;;

S Suppresses the state from the last address line.

U Converts the data returned by the rule into uppercase.

Image Editor example For example, if an address record contained four fields such as name, P.O. Box, city &
state, and ZIP code and these four data items were loaded into the table, if P.O. Box
was empty, only the other three items would be loaded into the table.

NOTE: An address line cannot exceed 256 characters.

When the address table items are retrieved, the first three contain data and the fourth
returns nothing. This lets you print the address on successive lines without having a
blank line in the middle where the P.O. Box would be.
If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field... Enter for field 1... Enter for field 2... Enter for field 3...

Destination name ADDRESS1 ADDRESS2 ADDRESS3

Offset 1 1 1

461
Chapter 5
Image and Field Rules Reference

In this field... Enter for field 1... Enter for field 2... Enter for field 3...

Length 50 50 50

Source name REC-ADDRESS1 * *

Offset * * *

Length * * *

File * * *

Record * * *

Required * * *

Rule SetAddr SetAddr SetAddr

Mask F N N

Data 17,ADDRECORD * *
35,40,75,40,115,40

* no entry required for this field in this example

In the DDT file, this information looks like this for the first variable field:
;0;0;REC-ADDRESS1;;;ADDRESS1;1;50;F;SetAddr;17,ADDRECORD
35,40,75,40,115,40;;;;;

The example above fills the address table and copies the first address line to the
destination field. The first record matching the search criteria of 17,ADDRECORD is
obtained and from it three separate entries are made into the address table. The first
is the 40 characters starting at offset 35 of the record, the second for 40 characters
starting at offset 75, and the last for 40 characters starting at offset 115.
To get the second and third address lines from the table, subsequent calls to the
SetAddr rule must be made using format mask N, with nothing in the data field:
;0;0;ADDRESS2;;;ADDRESS2;1;50;N;SetAddr;;;;;;
;0;0;ADDRESS3;;;ADDRESS3;1;50;N;SetAddr;;;;;;

NOTE: In this example, the city, state, and ZIP code are together in the extract file and
would be found by the entry for field 3. If the city, state, and ZIP are not
formatted, see the SetAddr2 rule.

This example shows the use of a user function and overflow symbol:

In this field... Enter...

Destination name ADDRESS1

462
SetAddr

In this field... Enter...

Offset 1

Length 50

Source name REC-ADDRESS1

Offset *

Length *

File *

Record 1

Required *

Rule SetAddr

Mask F

Data @GETRECSUSED,FORMABC,OVSYM/17,ADDRECORD
35,40,75,40,115,40

* no entry required for this field in this example

In the DDT file, this information looks like this:

;0;1;REC-ADDRESS1;;;ADDRESS1;1;50;F;SetAddr;@GETRECSUSED,
FORMABC,OVSYM/17,ADDRECORD 35,40,75,40,115,40;;;;;

NOTE: An address line cannot exceed 256 characters.

Here are the optional format mask parameters you can use:

Parameter Description

C Converts to sentence style where the first character is capitalized and the
remaining characters are lowercased.

D Converts the data returned by the rule into lowercase.

U Converts the data returned by the rule into uppercase.

Image Editor example If you make the following entries on the Edit DDT tab of the field’s Properties window
in Image Editor:

In this field… Enter for field 1… Enter for field 2… Enter for field 3…

Destination name ADDRESS1 ADDRESS2 ADDRESS3

Offset 0 0 0

464
SetAddr2

In this field… Enter for field 1… Enter for field 2… Enter for field 3…

Length 30 30 25

Source name REC-ADDRESS1 REC-ADDRESS2 REC-ADDRESS3

Offset 45 65 0

Length 20 20 0

File * * *

Record * * *

Required * * *

Rule SetAddr2 SetAddr2 SetAddr2

Mask F N N

Data 11,INSADRREC * *
25,20,45,
20,65,9,75,3,78,10
',',5,’-'

* no entry required for this field in this example

In the DDT file, this information looks like this for the three variable fields:
;0;0;REC-ADDRESS1;45;20;ADDRESS1;0;30;F;SetAddr2;11,INSADRREC
25,20,45,20,65,9,75,3,78,10 ',',5,’-';;;;;
;0;0;REC-ADDRESS2;65;20;ADDRESS2;0;30;N;SetAddr2;;;;;
;0;0;REC-ADDRESS3;0;0;ADDRESS3;0;25;N;SetAddr2;;;;;

The first set of offsets (25,20) is for address line 1. The second set of offsets (45,20) is
for address line 2. The third set of offsets (65,9,75,3,78,10) is for address line 3, which
is normally used for the city (65,9), state or province (75,3), and postal code (78,10).

NOTE: Use a single space to separate the offsets from the format parameters (‘,’,5,’-’).

For the third line of address data, this example uses “11,INSADRREC” as the search
criteria and “65,9,75,3,78,10”as the data mapping parameters. These parameters are
used to format the city, state or province, and postal code: ', ',5,'-'. The comma (,) is
placed between city and state or province. The dash (-) is placed after the 5th position
in the postal code.
If the mapping parameters are: ',','5','-' or ',','5',' ' and the input data from the extract
data contains a ZIP code of nine digits with a dash, then:

Input Output

12345-6789 12345-6789

465
Chapter 5
Image and Field Rules Reference

Input Output

12345-0000 12345 (without the dash)

12345-(four spaces) 12345 (without the dash)

If the mapping parameters are: ',','5','-' or ',','5',' ' and the input data from the extract
data contains a ZIP code of nine digits without a dash, then:

Input Output

123456789 12345-6789

123450000 12345 (without the dash)

12345 12345 (without the dash)

• Address1 (placed on line 1)

• Address2 (placed on line 2)
• Address3 (placed on line 2)
• City (placed on line 3)
• State (placed on line 3)
• ZIP (placed on line 3)
Address1 is required. Address1 is handled using the Move_It rule.
Address2 and Address3 are placed on line 2. The components of line 2 can vary. If both
Address2 and Address3 exist, both are placed on line 2 with the delimiter passed in by
the rule. If only one exists, no delimiter is used. If neither Address2 or Address3 exists,
the line 3 (City, State and ZIP) is moved up to line 2.
Line 3 contains the City, State and ZIP code with a comma placed between the city and
state, and a space added after the state and before the ZIP code. The ZIP code is
formatted based on the format flag.
This rule is similar to the SetAddr2 rule. If Address2 or Address3 are not applicable, the
remaining lines move up into their places. The City, State, and ZIP always remain on the
same line.

NOTE: An address line cannot exceed 256 characters.

The format mask must contain one of these options:

Option Description

F Initializes the function, fills the addr_ln array with the address components,
builds the address lines, and returns the first line from the addr_ln array. The
first time you call this rule the format mask field must contain an F.

N Returns the next available non-blank address line from the addr_ln array. This
mask is required for all subsequent SetAddr3 calls.

The various address data element mappings come from the first field rule record's Data
element (after the record mapping).
The rule expects five fields to be mapped. If one is missing you will receive an error.
This rule also assumes all address components are in the same record.

467
Chapter 5
Image and Field Rules Reference

Here are the format parameters you can use:

Parameter Description

C Converts to sentence style where the first character is capitalized and the
remaining characters are lowercased.

D Converts the data returned by the rule into lowercase.

U Converts the data returned by the rule into uppercase.

Image Editor example Here are some examples based on this sample data:

Component Text

Address1 Oracle Insurance

Address2 3353 Peachtree Road

Address3 Suite II - 900

City Atlanta

State GA

ZIP 30326

If all fields have data, the layout looks like this:

Oracle Insurance
3353 Peachtree Road
Atlanta, GA 30326
If Address3 does not print, the layout should look like this:
Oracle Insurance
3353 Peachtree Road
Atlanta, GA 30326
If Address2 does not print, the layout should look like this:
Oracle Insurance
Suite II - 900
Atlanta, GA 30326
If Address2 and Address3 do not print, the layout should look like this:
Oracle Insurance
Atlanta, GA 30326
Here are the DDT file entries for a SetAddr3 rule that has record address elements in
the following locations:

Element Description

100,30 The field offset and length for the addr2 field

468
SetAddr3

Element Description

130,30 The field offset and length for the addr3 field

160,18 The field offset and length for the city field

178,3 The field offset and length for the state field

181,9 The field offset and length for the ZIP field

', ' The format used between the city and state and between addr2 and addr3

Y The ZIP format flag. If Y and the ZIP field is 9 positions, a dash appears after
the fifth position. If N or the field is not 9 positions, it is mapped as is.

NOTE: The Mask field in the first SetAddr3 rule would contain the character F. The
Data field for this rule would contain the following:

100,30,130,30,160,18,178,3,181,9 ', 'Y

The Mask field for the second and third SetAddr3 rules would contain the
character N and the Data field would be blank.

Here is how it looks in the DDT file:

;0;0;ADDRESS LINE1;70;30;ADDRESS
LINE1;0;30;;Move_It;1,001;N;N;N;N;2412;2147;11011;
;0;0;ADDRESS LINE2;0;0;ADDRESS LINE2;0;30;F;SetAddr3;
100,30,130,30,160,18,178,3,181,9 ', 'Y;N;N;N;N;2400;2566;11011;
;0;0;ADDRESS LINE3;0;0;ADDRESS
LINE3;0;30;N;SetAddr3;;N;N;N;N;10488;2566;11011;

Syntax SetCpyTo (FieldName)

If the SendCopyTo variable contains a value, the GenPrint program will print at the
bottom of a form the following text:
Send copy to ######

where ###### is the current recipient name.

Since the field you specify for this rule must contain data for the system to print the text
Send copy to on the form, you will typically map the field with the Mk_Hard rule in the
DDT file.

Image Editor example ;SetCpyTo;ExampleField;;

In this example, if ExampleField contains data, the system will print the text Send copy
to on the form.

ChartName Name of the chart

FieldNames Names of the variable fields you want to use as custom axis labels

This rule tells you if there are discrepancies in the number of axis labels you create
using this rule and the number the system would create on its own.

NOTE: The system creates place holder labels if you do not specify enough labels and
ignores others if you specify to many.

Image Editor example Here is an example, shown in a DDT file excerpt:

/* This image uses these rules */
<Image Rules>
;SetImageDimensions;98,0,6960,7029,0,600,0,0;
;SetOrigin;ABS+0,MAX+0;
;CusSetDynamicScaleAxis;Chart(CHART1), Search(51,GRFMTHYR),
Min(82,6), Max(88,6), Increment (94,6);
;SetCustChartAxisLabels;CHART1,Axis1,Axis2,Axis3,Axis4,Axis5,Axis6,
Axis7,Axis8,Axis9,Axis10,Axis11,Axis12,Axis13;
;FieldVarsToChartSeries;;

/* These fields override the lower level definitions for this */

/* image only. */
<Image Field Rules Override>
;0;0;Axis1;61;1;Axis1;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;6367;4958;16
006;
;0;0;Axis2;62;1;Axis2;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;6427;4564;16
006;
;0;0;Axis3;63;1;Axis3;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2884;4324;16
006;
;0;0;Axis4;64;1;Axis4;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2884;4324;16
006;
;0;0;Axis5;65;1;Axis5;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;16
006;
;0;0;Axis6;66;1;Axis6;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;16
006;
;0;0;Axis7;67;1;Axis7;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;16
006;
;0;0;Axis8;68;1;Axis8;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;16
006;
;0;0;Axis9;69;1;Axis9;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;16
006;
;0;0;Axis10;70;1;Axis10;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4351;
16006;

471
Chapter 5
Image and Field Rules Reference

;0;0;Axis11;71;1;Axis11;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;
16006;
;0;0;Axis12;72;1;Axis12;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;
16006;
;0;0;Axis13;73;1;Axis13;0;1;;Move_It;51,GRFMTHYR;N;N;N;N;2886;4326;
16006;

X Sets the X coordinate for an image. This determines the image’s

horizontal position.

Y Sets the Y coordinate for an image. This determines the image’s vertical
position.

Form (Optional) The form name on which the image exists. This parameter lets
you define more than one SetOrigin rule for an image and specify which
one applies based on the name of the form.

Store( ) (Optional) This parameter lets you store the current image coordinates in
prefix-name variables for later use. The syntax is:
Store(prefix-name variable)
For Windows, the coordinates are stored in:
prefix-name.left, prefix-name.right, prefix-name.top,
and prefix-name.bottom
The stored coordinates can be referenced by any subsequent SetOrigin
rule used to place an image on the same form.

The X and Y coordinates are specified using a combination of the following parameter
prefixes plus the addition or subtraction of FAP units. There are 2400 FAP units per
inch. Here are the prefixes you can use:

Prefix Description

Abs Absolute page position based on 2400 units per inch. (supports overflow)

Rel Relative to the last image’s top left coordinate. (supports overflow)

474
SetOrigin

Prefix Description

Max Relative to the last image’s maximum edge. For example, Rel+0,Max+600
would position the current image ¼ inch below the last image. (supports
overflow)

Mpg Relative to any image at the maximum edge. For example, Abs+0,Mpg+600
places the current image ¼ inch below the lowest object currently on the page.
(does not support overflow)

T2T Top edge is placed relative to the last image’s top edge. (Similar to Rel)

T2B Top edge is placed relative to the last image’s bottom edge. (Similar to Max+)

B2T Bottom edge is placed relative to the last image’s top edge. (Similar to Max-)

B2B Bottom edge is placed relative to the last image’s bottom edge.

L2L Left edge is placed relative to the last image’s left edge. (Similar to Rel)

L2R Left edge is placed relative to the last image’s right edge. (Similar to Max+)

R2L Right edge is placed relative to the last image’s left edge. (Similar to Max-)

R2R Right edge is placed relative to the last image right edge.

Ctr X/Y dimensions are centered on the last image’s X/Y dimensions.

Image Editor example ;SetOrigin;Abs+0,Abs+1200;;

This example sets the origin for the image to the X, Y values of 0, 1200.

NOTE: There are no spaces between Abs+0,Abs+1200.

;SetOrigin;Rel+0,Max+0;;

This example shows you how to set up an image, which will print after the image, which
precedes it. You define the order of the images which make up a form in the FORM.DAT
file using the Form Set Manager. The GenData program reads this information as it
builds the print batches.
For instance, suppose IMAGE_A appears on two separate forms in the form set:
FORM_1 and FORM_2.
;SetOrigin;ABS+0,ABS+0,FORM_1
;SetOrigin;ABS+0,ABS+2400,FORM_2

This example places the image at coordinate 0,0 when it appears on FORM_1 and an
inch (0,2400) down the page when it appears on FORM_2.
Here is another example:
;SetOrigin;Abs+0,Abs+12000,Image1,Store(var1);;
This example sets the origin for Image1 to zero (0) FAP units for the X value (from the
edge of form) and 12000 FAP units for the Y value (5 inches down form the top of the
form). Plus, it stores the image coordinates into the prefix-name variable VAR1.

475
Chapter 5
Image and Field Rules Reference

Here is another example:

;SetOrigin;Rel+0,VAR1.bottom+600;;

In this example, the current image would be positioned such that its left edge would be
at the same x coordinate of the previous image's left edge but the top of the image
would be 1/2 inch below the saved coordinates of a previous image—its coordinates
were saved in the variable VAR1 using this rule:
;SetOrigin;x+n,y+n,external form name,Store(var1);;

Here is another example:

;SetOrigin;Img1.right+600,Img1.bottom-1200;;

This example places the current image’s top left corner ¼ inch to the right and ½ inch
up from Img1’s bottom right corner.
Here is another example:
;SetOrigin;Rel+0,Max+300;; (same as L2L+0,T2B+300)

In this example the current image is placed 1/4 inch below the previous image. The
images are aligned with their left edges.
Here is another example:
;SetOrigin;Rel+0(IMG1),Max+300;; (same as L2L+0(IMG1),T2B+300)

In this example the current image is placed 1/4 inch below the previous image. The left
edge of the current image is aligned with the left edge of image IMG1.
Here is another example:
;SetOrigin;Max+600,Rel+0;; (same as L2R+600,T2T+0)

The current image is placed 1/2 inch to the right of the previous image. The images are
aligned with their top edges.
Here is another example:
;SetOrigin;Abs+0,Mpg+600;;

The current image is placed 1/4 inch below the lowest object currently positioned on
the page. The current image is aligned with the left edge of the page.
Here is another example:
;SetOrigin;Ctr+0,Max+0;; (same as Ctr+0,T2B+0)

The current image is centered immediately below the previous image.

Here is another example:
;SetOrigin;Ctr+0,Ctr+0;;

The current image is centered above the previous image.

Here is another example:
;SetOrigin;Ctr+0(IMG1),Ctr+0(IMG1);;

The current image is centered above IMG1.

Here is another example:
;SetOrigin;FIXED,ABS+2400,ABS+9731;
This fixes the current image at the coordinates 2400, 9731. Even if it is the last image
triggered, the system will fix the image at those coordinates.

476
SetOrigin

Fixing an image’s position The SetOrigin rule lets you designate an image as a fixed image. Fixed images cannot
be moved from their set position.
You declare an image to be fixed by including FIXED as the first parameter of the
image's SetOrigin rule. Regardless of when the image is triggered, it will keep the
coordinates assigned to it throughout pagination.
Fixed images can also be designated as CopyOnOverflow images. This will cause the
fixed image to be copied onto subsequent pages at the same coordinates as those
used for the first page.
The SetOrigin rule should always define the X,Y coordinates as an absolute position or
a position relative to an image that will always be on the page. Do not anchor the fixed
image relative to an image that can overflow onto a new page. If you do, the fixed image
will never move to the second page. Instead, it will always appear on the first page with
coordinates that place it below the bottom of the page.
Here is an example of how you would use the FIXED parameter:
;SetOrigin;Fixed,X,Y,Form,Store(),ImageName;;

NOTE: You must use the SetImageDimensions rule when you use this rule.

X Sets the X coordinate for an image. This determines the image’s

horizontal position.

Y Sets the Y coordinate for an image. This determines the image’s vertical
position.

Form (Optional) The form name on which the image exists. This parameter lets
you define more than one SetOrigin rule for an image and specify which
one applies based on the name of the form.

Specify the X and Y coordinates using a combination of the following parameter

prefixes plus the addition or subtraction of measurements you specify in inches. Here
are the prefixes you can use:

Prefix Description

Abs Absolute page position based on inches. (supports overflow)

Rel Relative to the last image’s top left coordinate. (supports overflow)

Max Relative to the last image’s maximum edge. For example, Rel+0,Max+.25
would position the current image ¼ inch below the last image. (supports
overflow)

478
SetOriginI

Prefix Description

Mpg Relative to any image at the maximum edge. For example, Abs+0,Mpg+.25
places the current image ¼ inch below the lowest object currently on the page.
(does not support overflow)