Preface

The following topics contain additional information about this guide and other important links:

Documentation Topics

  • Overview
  • Using the Help
  • Document Conventions
  • Documentation Accessibility
  • Related Documents
  • Send Feedback About This Guide

Oracle Links

  • Oracle Insurance
  • Oracle Support

© Copyright 2011, Oracle and/or its affiliates. All rights reserved. Legal notices.


Overview

Welcome to the Rules Reference for Oracle Documaker. 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 section discusses the following topics:

  • Rules Overview
  • Types of Rules


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, the system can also produce output in Adobe Acrobat PDF format.

Note With the release of version 12.0, support for Image Editor and other legacy development tools ended.


Types of Rules

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

Job level rules

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.

Form set level rules

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.

Section level rules

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 section level rules, see Section Rules Reference.

Field level rules

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 field level rules, see Field Rules Reference.

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.


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 section you will find information about:

  • Using the Job Definition Table
  • Multi-Step Processing
  • Single-Step Processing
  • GenData WIP Transaction Processing
  • Processing Import Files
  • Rules Used in Single-Step Processing
  • Rules Used for 2-up Printing

For reference information on individual rules, see Job and Form Set Rules Reference.


Using the Job Definition Table

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 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 the Documaker Administration Guide.

Multi-step processing AFGJOB.JDT file

<Base Rules>

;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***;

;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 section in the base system uses these section level rules:

<Base Image Rules>

;RULStandardImageProc;;Always the first section 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 the Documaker Administration Guide.

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:

< 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, PrintFormset, and NoGenTrnTransactionProc.

Single-step processing AFGJOB.JDT file

When you use single-step processing, where the GenData program runs the GenTrn 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 section in the base system uses this section level rule:

<Base Image Rules>

;StandardImageProc;;Always the first section level rule;

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, section, 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

This job level rule initializes WIP Transaction Processing and 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 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.

GVM2GVM

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

WIPImageProc

This section level rule replaces the RULStandardImageProc or StandardImageProc rule in the AFGJOB.JDT file and tells the GenData program to bypass section data processing.

WIPFieldProc

This field level rule replaces the RULStandardFieldProc or 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.
Note Before the ability to add data to recipient batch records was added 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 section or form/section
  • Constant value
  • Data from an existing INI built-in functions, such as ~DALRun
  • Data from a custom written INI function

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 section. You can also enter a section name root. A section name root is the first part of a name. For instance, MAILER is the root name for sections with names such as MAILER A, MAILER_B, or MAILERS.
Req * | A semicolon 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 semicolon 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 RCBMapFromINI function warning messages

Use the WarnOnLocate option to suppress the following warning message from the RCBMapFromINI function:

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 information

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

Item | Description
Input fetypes | D or d = date N or n = number
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 section defined in the Image option in the RecipMap2GVM control group does not name a section, the feature is disabled for all transactions.
  • If the section 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 sections with the same name in the form set, the form specified in the Form option is used to identify the section to use. If the Form option is omitted, the first section found in the current form set is used.
  • The system assumes the specified section contains all of the unique data except for a constant value or data gathered from an INI built-in function.
  • If more than one recipient is assigned to the section, 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.

Mailer cover pages

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

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

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
  • BatchingByRecipINI
  • BatchingByPageCountINI

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:

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

You run the GenData program using a simplified AFGJOB.JDT file which contains an 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>

;WIPImageProc;;;

<Base Field Rules>

;WIPFieldProc;;;

Using the BatchingByRecipINI rule

You run the GenData program using a simplified AFGJOB.JDT file which contains the 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 BatchingByPageCountINI rule

You run the GenData program using a simplified AFGJOB.JDT file which contains the BatchingByPageCountINI 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 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
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

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


Processing Import Files

The GenData program can import and process these types of export files created by Documaker Workstation:

  • 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
    • ImportNAPOLFile
    • ImportXMLFile
  • Multiple transactions (one or more export files appended in a single file) using the appropriate import extract rule in a simplified AFGJOB.JDT.
    • ImportExtract
    • ImportNAPOLExtract
    • ImportXMLExtract
Note Create a separate AFGJOB.JDT file for this process, instead of updating an existing one by commenting out rules and adding new one.

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.

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.

Using Documaker Workstation

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

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


Rules Used in Single-Step Processing

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 a brief description.

Note You can find more information, including a detailed description of how processing occurs, in the Documaker Administration Guide.

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

Rule

Description

BatchingByRecipINI

Use this rule to send transactions to a batch you specify using INI options.

BatchByPageCount

Use this rule to send a transaction’s form set to a specified 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 batch based on the number of printed pages created when the system processes the transaction.

BuildMasterFormList

Use this rule to load the FORM.DAT file into an internal 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

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

Use this rule to set the cache the system uses to store 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.

NoGenTrnTransactionProc

Use this rule when you use the GenData program by itself to 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 contain page ranges and total page counts for each recipient batch file.

PaginateAndPropagate

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

PrintFormset

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

ProcessQueue

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

StandardFieldProc

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

StandardImageProc

This rule tells the system to process each section triggered by the SETRCPTB.DAT file.

WriteNAFile

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

WriteOutput

Use this rule to create the POLFILE.DAT file.

WriteRCBWithPageCount

Use this rule to write page counts for each recipient.


Rules Used for 2-up Printing

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 Rules Used in Single-Step Processing 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 the Documaker Administration Guide.

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

Rule | Description
AddLine | (Optional)Use this form set level rule to add a line record, such as for OMR marks, to the AFP record list built by the MergeAFP rule.
AddTextLabel | (Optional) Use this form set level rule to add a text label record to the AFP record list built by the MergeAFP rule.
GetRCBRec | Use this form set level rule to set the current recipient batch file. This rule initializes the current recipient batch file, if necessary.
InitMerge | Use this job level 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 | Use this job level rule to open NA and POL files.
MergeAFP | Use this form set level rule to initialize input files. This rule populates the AFP record list, retrieves comment (RCB) records, and terminates the input files.
OMRMarks | (Optional) Use this job level rule to generate OMR marks on 2-up documents printed on any AFP printer that supports 2-up printing.
ParseComment | (Optional) Use this form set level rule to parse comment records into the GVM variable.
PrintData | Use this form set rule to print the form set. This rule is used for handling 2-up printing on AFP and compatible printers.
ProcessRecord | Use this form set rule to switch between print files as 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.


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 section serves as a reference to job and form set rules. For information on the rules which apply to sections and fields, see Section Rules Summary or Field Rules Summary.

This section discusses rules included in the base system and supported by the support group. For information on custom rules, contact your Professional Services representative.

This section includes the JDT Rules Reference .


JDT Rules Reference

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.

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 batch | 2 | IfRecipUsed | na
Add a line record, such as for OMR marks, to the AFP record list | 2 | AddLine | na
Add a text label record to the AFP record list | 2 | AddTextLabel | na
Add data from the extract list into global variables | 2 | Ext2GVM | na
Add OMR marks on 1-up or on 2-up documents | 1 | OMRMarks | na
Add all of the functionality of running the GenPrint program | 1 | GenPrint | na
Append a global variable to an extract file | 2 | AppendGblToExtr | na
Append the NAFILE.DAT file data records for the current form set into an existing NAFILE.DAT file | 2 | WriteNAFile | na
Assign form sets to specific batches | 2 | AssignToBatch | na
Assign the recipients from a specific form to the other forms in a form set | 2 | MergeRecipsFromForm | na
Build a form candidate list | 2 | PXCandidateList | na
Build a form list by loading the FORM.DAT file into an internal linked list within the GenData program | 1 | BuildMasterFormList | na
Bypass all section processing | 2 | ForceNoImages | na
Change the printer tray during processing. | 2 | SetOverflowPaperTray | na
Check a field’s value against another value for transactions currently in the generic linked list of objects | 2 | BatchByPageCount | na
Check for zero font IDs | 2 | CheckZeroFontID | na
Copy NA_Offset and POL_Offset into GVM variables | 2 | CreateRecordList | na
Copy the data from a given GVM variable into another GVM variable | 2 | GVM2GVM | na
Create a global variable | 1 | CreateGlbVar | na
Create a print file that contains a set of forms filtered by form name, form description, or recipient name | 2 | ServerFilterFormRecipient | na
Create a list of printers, batches, and buffers for the comment (RCB) records | 1 | InitMerge | na
Create a POL file when doing 2-up printing | 2 | WriteOutput | na
Create and populate a list of records which contain page ranges and total page counts for each recipient batch file | 1 | PageBatchStage1InitTerm | na
Create the recipient batches when running in two-step mode | 2 | WriteRCBFiles | na
Define an overflow variable | 1 | SetOvFlwSym | yes
Delete records from an extract list | 2 | DelExtRecords | na
Dump an extract list to a file | 2 | DumpExtList | na
Dump an extract list to a file by transaction | 2 | DumpExtractListToFile | na
Exclude transactions from being processed in one- and two-step mode processing | 1 | BuildExcludeList | na
Execute a DAL script | 2 | PostTransDAL | na
Execute a DAL script | 2 | PreTransDAL | na
Execute a DAL script if certain conditions are met | 2 | PXTrigger | na
Execute a user function | 1 | RunUser | na
Execute specific transactions for testing purposes | 2 | RULTestTransaction | na
Execute regional date processing (RDP) rules on forms. | 2 | RegionalDateProcess | na
Extract a form set from a DAP archive using an extract file. | 2 | LoadFormsetFromArchive | na
Get a print batch name from an extract file | 2 | SetOutputFromExtrFile | na
Get memory allocation information | 1, 2 | AllocDebug | na
Get the company (Key1 field) from the extract data | 2 | GetCo | na
Get the current date and use it as the run date | 2 | GetRunDate | na
Get the line of business (Key2 field) from the extract data | 2 | GetLOB | na
Import a single transaction from a combined NA/POL file | 2 | ImportNAPOLFile | na
Import a single transaction from a standard import file | 2 | ImportFile | na
Import an extract file | 2 | ImportExtract | na
Import an XML extract file | 2 | ImportXMLExtract | na
Import an XML file | 2 | ImportXMLFile | na
Import multiple transactions from a combined NAPOL extract file | 2 | ImportNAPOLExtract | na
Initialize input files for AFP printers | 2 | MergeAFP | na
Initialize resources such as input and output files | 1 | JobInit1 | na
Initialize the overflow feature | 1 | InitOvFlw | yes
Initialize the system for using the ConvertWIP rule | 1 | InitConvertWIP | na
Load a table into a link list | 1 | LoadListFromTable | na
Load and initialize all forms | 2 | BuildFormList | na
Load entries from the SETRCPTB.DAT file based on the Key fields and transaction type | 2 | LoadRcpTbl | na
Load extract data into memory for each transaction | 2 | LoadExtractData | na
Load printer and recipient batch information | 1 | InitPrint | na
Load text tables into the text table list | 1 | LoadTextTbl | na
Load the field rules from the MASTER.DDT file into an internal linked list | 2 | LoadDDTDefs | na
Load the table files listed in the tables list file | 1 | LoadTblFiles | na
Maintain the exact data printed without Library Manager | 2 | InlineImagesAndBitmaps | na
Map data you are importing | 2 | ImageMapImportData | na
Nest overflow within overflow | 2 | RULNestedOverFlowProc | yes
Open NA and POL files | 1 | InitPageBatchedJob | na
Paginate the form set and merge field data, page ranges, and total pages | 2 | PaginateAndPropagate | na
Parse comment records into the GVM variable field data | 2 | ParseComment | na
Print form sets—for multi-step processing | 2 | PrintData | na
Print form sets—for single-step processing | 2 | PrintFormset | na
Process a queue | 1 | ProcessQueue | na
Process each field triggered by the SETRCPTB.DAT file—for multi-step processing | 1 | RULStandardFieldProc | na
Process each field triggered by the SETRCPTB.DAT file—for single-step processing | 2 | StandardFieldProc | na
Process each field triggered by the SETRCPTB.DAT file—for WIP Transaction Processing | 2 | WIPFieldProc | na
Process each section triggered by the SETRCPTB.DAT file—for multi-step processing | 1 | RULStandardImageProc | na
Process each section triggered by the SETRCPTB.DAT file—for single-step processing | 1 | StandardImageProc | na
Process each section triggered by the SETRCPTB.DAT file—for WIP Transaction Processing | 1 | WIPImageProc | na
Process each transaction listed in the extract file | 2 | RULStandardTransactionProc | na
Process the extract file and create information created in both the GenTrn and GenData steps | 2 | NoGenTrnTransactionProc | na
Process the groups (Key1, Key2 combinations) that exist in the form set, as opposed to only a single set of keys specified in the TRNFILE.DAT file | 2 | ProcessTriggers | na
Process WIP transactions manually approved or rejected in Documaker Workstation | 2 | WIPTransactions | na
Register the MapFromImportData rule which the system then uses instead of the NoOpFunc rule | 2 | ReplaceNoOpFunc | na
Remove forms from form sets | 2 | FilterForm | na
Remove forms from form sets based on recipients | 2 | FilterRecip | na
Replace the LoadRcpTbl and RunSetRcpTbl rules in implementations created by Documaker Studio | 2 | RunTriggers | na
Replace the RULStandardBaseProc rule when you use IDS to run Documaker | 1 | ServerJobProc | na
Reset the overflow feature | 2 | ResetOvFlw | yes
Reset the pRPS structure after the GVM variables have been remapped. | 2 | ResetDocSetNames | na
Restart the GenData program | 1 | RestartJob | na
Restart the GenData program | 2 | RULCheckTransaction | na
Run a user function | 1 | RunUser | yes
Run Documaker Server from another application via an XML job ticket | 1 | TicketJobProc | na
Run specified entries in the set recipient table | 2 | RunSetRcpTbl | na
Run the GenArc program as part of single-step processing | 2 | Archive | na
Run the GenArc program as part of single-step processing | 1 | InitArchive | na
Run the GenWIP process to transfer transactions into WIP | 2 | ConvertWIP | na
Send a transaction to a batch based on the number of pages the system generates when it processes the transaction | 2 | BatchingByPageCountINI | na
Send transactions to a batch based on data in the extract file | 2 | BatchingByRecipINI | na
Send a transaction to a specific print batch based on the number of page count for each recipient of all form sets the system generates when it processes the transaction | 2 | BatchingByPageCountPerRecipINI | na
Send a transaction to the manual batch when specified field errors occur | 1 | ErrorHandler | na
Send a transaction to WIP when the system sees that a field designated as Required does not contain data | 2 | RequiredFieldCheck | na
Set the amount of memory you want the system to use to store the information in Key fields (speed processing of complex forms) | 1 | InitSetRecipCache | na
Set the copy count for all forms except those listed | 2 | SetRecipCopyCount2 | na
Set the copy count for all forms specified | 2 | SetRecipCopyCount | na
Set the current recipient batch file | 2 | GetRCBRec | na
Sort RCB batches before they are printed (so you can call a sort program to rearrange the order of the RCB files) | 1 | SortBatches | na
Specify a job definition file | 1 | StandardFieldProc | na
Specify a print batch file for all recipients | 2 | AssignBatWithTbl | na
Specify multiple XDBs to use across multiple key combinations | 2 | MultipleDataDictionaryFiles | na
Specify the codes the system should look for in WIP Transaction Processing | 1 | MergeWIP | na
Specify the text in the header of the error file | 1 | SetErrHdr | na
Switch between print files when doing 2-up printing | 2 | ProcessRecord | na
Terminate an XDB instance and free memory | 1 | Dictionary | na
Translate error information | 1 | TranslateErrors | na
Use an XML extract file | 2 | UseXMLExtract | na
Use an XML extract file | 2 | XMLFileExtract | na
Write out forms which contain descriptions of the other forms in the form set | 2 | FormDescription | na
Write transactional information into each page of the print stream | 1 | InstallCommentLineCallback | na
Write out full NA and POL information as well as certain export field information | 2 | DocumentExport | na
Write the page count for each recipient when doing 2-up printing | 2 | WriteRCBWithPageCount | na
Write the POL set to the POLFILE.DAT file | 2 | UpdatePOLFile | na


AddLine

Use this form set level 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.

See also

  • MergeAFP


AddTextLabel

Use this form set level rule to add a text label record to the AFP record list built by the MergeAFP rule. This rule is used in 2-up printing.

Syntax

;AddTextLabel;;Text,XPos,YPos,Orientation,Font;

Parameter

Description

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;

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

See also

  • MergeAFP
  • Rules Used for 2-up Printing


AllocDebug

Use this rule to get information on the number of memory bytes allocated and freed each time there is new maximum value of allocates not being freed. This rule outputs its error messages to the LOGFILE.DAT file instead of the ERRFILE.DAT file. You can use this rule to find cumulative memory allocations not reported as leaks.

The AllocDebug rule is unique in that you can use it at any level in the AFGJOB.JDT file because it is designed to run in all three processing states during rule Pre- and Post-processing.

You can place this rule in the <Base Rules>, <Base Form Set Rules>, <Base Image Rules>, and <Base Field Rules> sections in the AFGJOB.JDT file.

Syntax

;AllocDebug;;;

Example

;AllocDebug;;;


AppendGblToExtr

Use this form set level rule to append a global variable to the extract file. You can use this rule to place selected fields in the trigger file into an extract file.

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


Archive

Use this form set level rule along with the InitArchive rule, to run the GenArc program as part of single-step processing.

The InitArchive rule checks the INI options in the Trigger2Archive control group, initializes the database, opens the APPIDX.DFD and CAR files, and perform other steps to initialize archive.

The Archive rule then unloads the current form set and converts field data for archive using the INI options in the Trigger2Archive control group.

Syntax

;Archive;2;;

Example

Here is an example:

< Base Form Set Rules >

;Archive;2;;

See also

  • InitArchive


AssignBatWithTbl

Use this form set level rule to specify the print batch file for all recipients based on data found in the extract list.

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.


AssignToBatch

Use this form set level rule to identify form sets from a particular source and place those form sets into a special batch for review purposes. For instance, you can use this rule to identify policies from a particular agent, operator, or branch and place those policies into a special batch.

Note You can insert several AssignToBatch rules in the base rules file (AFGJPB.JDT). All that return true will be placed in the appropriate recipient batch.

Syntax

;AssignToBatch;;(parameters);

Parameter

Description

Name

The recipient batch name to which the transaction should be assigned.

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

…

…

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.

See also

  • IfRecipUsed


BatchByPageCount

Use this form set level rule to check the value of a field supplied for processing against that for transactions currently in the linked list of objects. These transactions are populated by the CreateRecordList rule. This rule is also used with multi-mail processing.

If the field has changed, the system writes the records to the recipient batch file, based on the total page count for all recipients of all form sets in the set of transactions. If you omit the parameter, the system writes records in the generic linked list of objects to the appropriate recipient batch files, based on the page count for the individual records.

If you are using multi-mail, the system updates the TotPage field of the recipient batch record to reflect the total page count for all recipients of all transactions in the multi-mail transaction set.

Note Keep in mind this rule calculates the page count at the transaction level, not the recipient level.

Syntax

;BatchByPageCount;;(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 PageBatchStage1InitTerm, CreateRecordList, and WriteRCBWithPageCount rules.

Example

;BatchByPageCount;;MMField=MM_Field;

In this example, the system uses the multi-mail code defined in each transaction for batching purposes. The system checks the value in each transaction against that for transactions currently a VMMList, which is populated by CreateRecordList rule.

If the field has changed, the records are written to the recipient batch based on the total page count for all recipients for all form sets in the entire set of transactions.

Note Because the end of a multi-mail transaction set is not known until after the following transaction, each multi-mail transaction set (or each transaction, in the non multi-mail situation) is written out during processing of the following transaction.

See also

  • Rules Used for 2-up Printing
  • BatchingByPageCountINI
  • BatchingByPageCountPerRecipINI
  • BatchingByRecipINI
  • CreateRecordList
  • PageBatchStage1InitTerm
  • PrintFormset
  • WriteRCBWithPageCount


BatchingByPageCountINI

Use this form set level rule to send a transaction to a specific print batch based on the number of pages the system generates when it processes the transaction.

Note The BatchingByPageCountINI rule uses the total page count regardless of recipient and not a specific recipient page count.

Syntax

;BatchingByPageCountINI;;;

You specify which transactions are assigned to the print batch using INI options in these control groups:

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 group

This control group must contain these INI options:

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

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.

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 Appendix: Condition Tables and the Record Dictionary.

Batch Name

You can specify the batch name by specifying the recipient name, the batch 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.
  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 group

This control group must include at least one entry for each unique batch name in the 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 group

You define the name for this control group, such as Page1. You must have a 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 group

You define the name for this control group, such as Page1Prt. This control group must 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

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
 | .\Batch\Page1 | .\Print\Page1Prt.pcl
 | .\Batch\Pages2 | .\Print\Pages2Prt.pcl
 | .\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

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.

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.

See also

  • Rules Used for 2-up Printing
  • BatchByPageCount
  • BatchingByRecipINI
  • KickToWip
  • Move_It
  • WriteRCBWithPageCount


BatchingByPageCountPerRecipINI

Use this form set level rule to send a transaction to a specific print batch based on the number of page count for each recipient of all form sets the system generates when it processes the transaction.

Syntax

;BatchingByPageCountPerRecipINI;;;

You specify which transactions are assigned to the print batch using INI options in these control groups:

  • BatchingByRecip
  • Print_Batches
  • PrinterInfo
  • BatchFileName (You can define the name of this control group.)
  • PrintedOutputFile (You can define the name of this control group.)

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

BatchingByRecip control group

This control group must contain these INI options:

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

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.

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.

?XDB token - a token name that equates to a named item in the XDB.

=GVM (expression) - returns the value of a GVM symbol named in the expression.

=DAL (expression) - returns the value of a DAL script named in the expression.

=(expression) - returns the value of a DAL symbol represented in the expression.

BatchName

You can specify the batch name by specifying the recipient name, the batch 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, as shown here:

“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, as shown here:

“batch1”

Use the pipe symbol (|) to indicate separate items concatenated together, as shown here:

print1|print2

Recipients

You can specify recipients by using a keyword (All) or by listing 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.
  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 group

This control group must include at least one entry for each unique batch name in the 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 group

You define the name for this control group, such as AllOnePageBatch. You must have 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.

PrintedOutputFile control group

You define the name for this control group, such as Printer1. This control group must 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
  • Scenario 2
  • Scenario 3
  • Scenario 4
  • Scenario 5


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 >

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


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

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


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

Printer = Printer2

Printer = Printer3

Printer = Printer4

Printer = PDefault


Scenario 4

Like the Scenario 3, 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;;

;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

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

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:

< 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

Printer = Printer2

Printer = Printer3

Printer = Printer4

Printer = PDefault


BatchingByRecipINI

Use this form set level rule to send transactions to a batch you specify based on data in the extract file and conditions and recipients specified using INI options.

Syntax

;BatchingByRecipINI;;;

You pass parameters for this rule using the BatchingByRecip control group in your FSISYS.INI or FSIUSER.INI file. Make sure this control group is in the INI file and includes these options:

  • DefaultBatch
  • Batch_Recip_Def

The DefaultBatch option has only one parameter, a literal name such as Default. Do not enclose it in quotation marks.

The syntax for the Batch_Recip_Def option is shown here:

Condition; ”BatchName”; Recipient

Parameter

Description

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.

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

where

  • 4 is the position in the extract file at which the search begins
  • 1234567; is the data in the extract file you want the system to search for
  • Batch1 is the batch name, which you must set up this name under Print_Batches
  • INSURED is the recipient name, which you must set up under RECIP_NAMES

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

Batch_Recip_Def = true;"BATCH2";INSURED

where

  • true indicates to put all recipients named INSURED into BATCH2
  • Batch2 is the batch name, which you must set up this name under Print_Batches
  • INSURED is the recipient name, which you must set up under RECIP_NAMES

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.

See also

  • BatchByPageCount
  • BatchingByPageCountINI
  • PrintFormset
  • SetOutputFromExtrFile
  • Search Criteria
  • Using Condition Tables
  • Using the Record Dictionary for Variables


BuildExcludeList

Use this job level rule to selectively exclude transactions from being processed in one- and two-step mode processing.

You must include this rule in the AFGJOB.JDT file because neither one- nor two-step mode executes the GenTran program which processes transactions during multi-step processing.

Note You must define the transactions to be excluded in a file specified by the Exclude option in the Data control group. In addition, this rule does not remove excluded transactions from the extract file as would occur in multi-step processing.

Syntax

;BuildExcludeList;;;

Example

Assume your master resource library has the following items defined. Your FSIUSER.INI file looks like this:

< Data >

Exclude = Exclude.dat

You have a file named JONES.DAT in DefLib. This file contains:

Example

30,Jones

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.


BuildFormList

Use this form set level rule to load and initialize all forms that the processing of extract data could possibly produce.

Note You can use the LoadFormsetFromArchive rule to replace the BuildFormList, LoadRcpTbl, and RunSetRcpTbl rules in the AFGJOB.JDT file.

Syntax

;BuildFormList;;;

There are no parameters for this rule.

This rule loads the entire form set into a master form set list and creates the duplicate list which is altered during processing. The system only creates the master form set list the first time it executes this rule. Subsequent calls to this rule delete the existing duplicate form set (in the working form set) and recreate it from the master form set list.

This rule makes sure the extract data exists and resets all form recipient copy counts to zero (0). It also loads the set recipient table data from file into a list. This file is defined in the SetRcpTb option in the Data control group.

Note This rule erases the list of data from the SETRCPTB file.

Example

;BuildFormList;;;

See also

  • LoadFormsetFromArchive
  • LoadRcpTbl
  • RunSetRcpTbl


BuildMasterFormList

Use this job level rule to load the FORM.DAT file into an internal linked list used by 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.

Syntax

;BuildMasterFormList;;KeyCount;FORM.DAT

Parameter

Description

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.

See also

  • RunSetRcpTbl


CheckZeroFontID

Use this form set level rule to see if the form set has any fields with a zero font ID. The rule will produce an error or warning for any fields it finds which have font IDs equal to zero. You can then correct the font ID problems and restart the processing cycle.

Syntax

;;CheckZeroFontID;;Message;

Parameter | Description
Message | Enter E if you want to see error messages. Leave this parameter blank if you want to see warning messages.

Example

This example produces error messages:

;CheckZeroFontID;;E;

This example produces warning messages:

;CheckZeroFontID;;;

The error or warning message includes information about the form, section, 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>


ConvertWIP

Use this form set level rule to see if the current transaction is assigned to the MANUAL.BCH file. If it is, the rule adds the record to WIP and unloads the contents of the POLFILE.DAT and NAFILE.DAT files into new files with unique names.

The system generates unique form set IDs using a globally unique identifier (GUID) for the new files. This helps to make sure form set IDs created for WIP records do not clash even if multiple applications are generating WIP records, such as if you had multiple IDS servers generating WIP.

You can then view these WIP records using Documaker Workstation or Print Preview, which is part of the Internet Document Server (IDS).

Using this rule eliminates the need to run the separate GenWIP process to transfer transactions into WIP.

Note You must have separate licenses to run Documaker Workstation and IDS. Contact your sales representative for more information.

Syntax

;ConvertWIP;;;

Example

;ConvertWIP;2;;

The order in which you place the ConvertWIP rule is important. Place it in front of the PrintFormset, WriteOutput, and WriteNAFile rules, as shown here:

;NoGenTrnTransactionProc;2;required to combine GenTran/GenData;

;ConvertWIP;2;;

;PrintFormset;2;;

;WriteOutput;2;;

;WriteNAFile;2;;

The PrintFormset rule is required to combine the GenData and GenPrint processes into a single step.

See also

  • InitConvertWIP


CreateGlbVar

Use this job level rule to create a global variable which can be used by all code in the system. You specify the type and size of the variable. List all instances of this rule at the beginning of the AFGJOB.JDT file.

Syntax

;CreateGlbVar;;;

Note This rule resets the global variable created during pre-processing.

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.


CreateRecordList

Use this form set level rule to copy the NA_Offset and POL_Offset into global variables.

This rule calculates page counts for each recipient and sends transactions to error, manual, and previously assigned (such as Braille) batches, as necessary. This rule also appends RCB comment records for all other transactions into a generic linked list of objects.

This rule writes out the recipient batch records for error, manual, and previously assigned batches.

Note If the current record will be appended to the generic linked list of objects, this rule takes care of filling in a number of fields in the recipient batch record. These fields would normally be filled in by a call to the RULUpdateRecips function. The RULUpdateRecips function is inappropriate for page count batching, which is why the fields are filled in manually.

Syntax

;CreateRecordList;;;

Example

;CreateRecordList;;;


DelExtRecords

Use this form set level rule to search the extract data list and delete all data records which match the search mask you specify.

For instance, you can use this rule to remove data records that are confidential, out of date, or should never be processed on the form.

To use this rule, you must add it to the AFGJOB.JDT file after the extract data is loaded but before the extract data is used for mapping or other purposes.

Syntax

;DelExtRecords;;;

Example

This example deletes all extract records which contain the text RECTYPE1 at offset 1, and KEY1 at offset 50.

;DelExtRecords;;1,RECTYPE1,50,KEY1;

Note Be sure that the search mask is specific enough to avoid deleting more records than intended.


Dictionary

Use this job level rule to terminate an XDB instance and free memory. You only include this rule if you also used the GlobalFld rule.

Syntax

;Dictionary;;;

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;

See also

  • GlobalFld


DocumentExport

Use this form set level rule to write full NA and POL information as well as certain export field information. You can control how the export information the rule generates is formatted and you can specify which fields should be included.

Syntax

;DocumentExport;;;


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 lengths

Fixed length records are always the same. In a fixed length record, all field data has a 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.

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, length, and format

Build a table with this information:

  • 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 and formats

Once you have identified the fields that comprise the export record, you have to define 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 for more information.

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

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

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:

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 attributes

An octothorp (#) tells the system to suppress leading zeros for the following format 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.


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
 | “Monday, March 01”.
 | “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 width. | Right align.
+ | Prefixes the output value with a sign (+ or –) if the output value is of a signed type. | Sign appears only for negative signed values (–).
0 | Adds zeros until the minimum width is 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. | No padding.
blank (' ') | Prefixes the output value with a blank if the output value is signed and positive; the blank is ignored if both the blank and + flags appear. | No blank appears.
# | When used with the f format, the # flag forces the output value to contain a decimal point in all cases. | Decimal point appears only if digits follow it.

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


DumpExtList

Use this form set level rule to dump the extract list to a file. The result provides information about the generic linked list of objects, such as its handles and the information contained in each element.

The file the system creates is a flat text file which shows only text values—binary data is written as spaces to preserve placement.

Syntax

;DumpExtList;;(Name);

Parameter | Description
Name | Name of the file to which the extract records will be written.
Note Only use this rule for test purposes, so you can inspect the contents of the extract data list. The use of this rule slows processing in proportion to the size of the extract data list.

Example

;DumpExtList;;ExtrListDump.txt;


DumpExtractListToFile

Use this form set level rule to dump the extract list to a file. This rule is helpful if you are debugging and you want to see what is currently in the extract list.

Syntax

;DumpExtractListToFile;;(parameters);

Parameter | Description
Name | Name of the file to which the extract records will be written.
Flag | The append flag. Enter Y to append the records for each transaction to the file plus a header. Enter N to only create a dump file for the last transaction.

Example

;DumpExtractListToFile;;ExtrDump.txt,Y;

For each transaction in the extract file, the system appends to the EXTRDUMP.TXT file a transaction header plus the contents of each record in the transaction. Here is an example of this file:

*************************************************

==> Extract data for:

TransactionId:<Patch399>

GroupName1:<CWNG>

GroupName2:<CIS>

GroupName3:<>

External Form Name:<>

Transaction Type:<>

**************************************************

Patch399 HEADER CWNGCIS Patch # …

Patch399 GVM1 Morris Sandra …

…

…

**************************************************

==> Extract data for:

TransactionId:<Patch400>

GroupName1:<CWNG>

GroupName2:<CIS>

GroupName3:<>

External Form Name:<>

Transaction Type:<>

**************************************************

Patch400 HEADER CWNGCIS Patch # …

Patch400 GVM1 Bob Jane …

…

…

Note The Y option can create a very large file, depending on the size of the extract file.


ErrorHandler

Use this job level rule to send transactions to the manual batch when specified field errors occur. This lets normal processing continue if errors occur.

Syntax

;ErrorHandler;;;

Use the following INI option to identify the field errors which cause a transaction to be sent to the manual batch:

< Error2Manual >

(CurrentError) = (NextError1),..,(NextErrorN),(M)

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


Ext2GVM

Use this form set level rule to add data from the extract list into previously defined global variables. To use the rule, you must add it to the AFGJOB.JDT file after the extract data is loaded.

You can also use this rule to get data into the NEWTRN.DAT file during GenData processing instead of using Trn_Fields. To do this you define a field for the data to be mapped in the TRNDFDFL.DFD file and then use the Ext2GVM rule to map the data from extract file to the NEWTRN.DAT file.

Syntax

;Ext2GVM;;(parameters);

You can use these parameters with this rule:

Parameter | Description
SearchMask | One or more pairs of offsets and data (search criteria) in a comma-delimited list.
DataLocation | The offset and length of the data in the extract record.
GVMName | The name of the GVM variable where the data will be stored.
SuppressFlag | Enter S to suppress error messages if the search mask is not found in a transaction. The default is blank, which tells the system not to suppress error messages.

Example

The following example locates the extract record that matches the search mask (1, D1) and moves the value found at position 21 for a length of 5 to the global variable TestVar. In addition, it suppresses the error messages if the search mask is not found in the transaction.

<Base Rules>

... ...

... ...

;CreateGlbVar;;TestVar,CHAR_ARRAY,5;

... ...

<Base Form Set Rules>

... ...

;Ext2GVM;;1,D1 21,5,TestVar,S;

... ...

Note Refer to the DAL Reference for information on these related DAL functions: GVM, HaveGVM, and SetGVM.


FilterForm

Use this form set level rule to remove all forms from a form set except those that match the filter criteria you specify.

See also

;FilterForm;;;

You can use these INI options with this rule:

< FilterForms >

Form =

FilterByForm =

Option | Description
Form | Use this option to specify the search location for form filter criteria. All occurrences of the data specified in the data are used for filtering. You can specify the search location as an XML search string or as a flat file search mask.
FilterByForm | (Optional) Use this option to turn the rule on or off by transaction. If you specify this option, the rule looks for a value of TRUE at that specified search location. If TRUE is not found, the filter logic is not executed. If you omit this option, the rule is always executed.

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:

/* 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;;

;FilterForm;2;;

/* Every section in this base uses these rules. */

<Base Image Rules>

;WIPImageProc;;

/* Every field in this base uses these rules. */

<Base Field Rules>

;RULWIPFieldProc;;

See also

  • FilterRecip


FilterRecip

Use this form set level rule to remove all forms from a form set except those that match the recipient filter criteria you specify.

Syntax

;FilterRecip;;;

You can use these INI options with this rule:

< FilterRecip >

Recip =

FilterByRecip =

Option | Description
Recip | Use this option to specify the search location for the Recip filter criteria. All occurrences of the data specified in the data are used for filtering. You can specify the search location as an XML search string or as a flat file search mask.
FilterByRecip | (Optional) Use this option to turn the rule on or off by transaction. If you include this option, the rule looks for a value of TRUE at the specified search location. If TRUE is not found, the filter logic is not executed. If you omit this option, the rule is always executed.

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:

/*  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;;
;FilterRecip;2;;
/* Every section in this base uses these rules. */
<Base Image Rules>
;WIPImageProc;;
/* Every field in this base uses these rules. */
<Base Field Rules>
;RULWIPFieldProc;;

See also

  • FilterForm


ForceNoImages

Place this rule in your AFGJOB.JDT file to bypass all section processing. This rule prevents any section level rules from executing.

For instance, you could use this rule if the form set for each transaction is created and mapped by a higher level rule which removes the necessity for executing section or field level rules.

You can also use this rule in 2-up printing to return the msgNO_MORE_IMAGES message.

Syntax

;ForceNoImages( )

There are no parameters for this rule.

This rule prevents errors if you have no section level rules.

Example

< Base Image Rules >

;ForceNoImages;;

See also

  • ImportNAPOLExtract
  • Rules Used for 2-up Printing


FormDescription

Use this form set level rule to write out a form or several forms, which contain descriptions of the other forms included in the form set. You can also specify a DAL script you want the system to execute to get the actual descriptions to use.

Note This capability exists in Documaker Workstation. This rule provides the capability to Documaker Server.

Syntax

;FormDescription;;NoOverflow;

Parameter | Description
NoOverflow | (Optional) This parameter tells the system not to overflow the form description line section if there are not enough Form Description Line fields to include the maximum number of selected forms. Keep in mind that if this parameter is turned on and there are more forms than there are Form Description Line fields, some of the descriptive information may be lost. The default is the system will overflow to accommodate all selected forms.

Keep in mind...

  • Place this rule after the UpdatePOLFile rule if you are running in multi-step mode. For single- and two-step mode, place the rule after the PaginateAndPropagate rule.
  • The names of Form Description Line variable fields must begin with FORM DESC LINE. You can include multiple lines of these fields on a form by varying the field’s name, such as FORM DESC LINE #002, FORM DESC LINE #003, and so on.
  • For each form in a form set (and optionally for each Key2 grouping), the system will assign to a Form Description Line field a text description of that form. Only one text description is assigned to each From Description Line field.
  • Form description lines do not wrap the description to succeeding lines. If a text is longer than the field’s representation, the text can extend beyond page boundaries or into undesirable areas. Make sure the Form Description Line fields can contain the longest description. Smaller fonts generally allow more characters per line.
  • Any form can contain Form Description Line fields. You can place form description lines on separate forms. You can also place forms with these fields among other fields, graphics, and so on.
  • The placement of the form in the FORM.DAT file is important. Only those forms placed after the first form which contains a FORM DESC LINE field will be included in the listed forms. Please note the first form, which contains the form description lines, is not included in the list.

INI options

You can use these INI options to tell the system how to represent form group lines on form description lines.

< FormDescTable >

IncludeKey2 = No

BoldKey2 = No

Key2Prefix =

Key2PostInc = 0

IncludeDuplicateForms = No

IncludeFormName = No

StartFromFirstForm =

ColumnFormat = No

ExludedForm =

IncludeFormDesc =

< FormDescription >

Script =

Option

Description

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 1 Automobile Coverage

Form 2 Homeowner 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.

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.

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/10) 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/10)");

Below is an example of the description lines generated without calling DAL script.

DEC Page Common Policy Declarations

END Page Endorsement Page

CG DEC General Liability Declarations

Here is an example of the output when you call the DAL script:

DEC Page Common Policy Declarations (11/10)

END Page Endorsement Page (11/10)

CG DEC General Liability Declarations (11/10)

See also

  • PaginateAndPropagate
  • UpdatePOLFile


GenPrint

Use this job level rule to add all of the functionality of running the GenPrint program. Anything you can do with the GenPrint program can be done using this rule. For instance, you can use this rule to print the same recipient batch multiple times while running in single-step mode, giving you the same recipient batch processing capabilities available in multi-step mode. For instance, this rule lets run in single-step mode and print the same batch in multiple formats, such as a PDF batch for electronic delivery and a Metacode batch for mail.

Syntax

GenPrint ()

There are no parameters for this rule.

Note The PrintFormset rule works differently from the GenPrint program, while the GenPrint rule offers the same functionality. To use the GenPrint rule, add it to the AFGJOB.JDT file instead of the PrintFormset rule.

Keep in mind...

  • You cannot use the RestartJob rule with the GenPrint rule.
  • You cannot use the DelayFileWrite option with the MergeWIP rule.

Example

Here is an example:

<Base Rules>

;RULStandardJobProc;;Always the first job level rule;

;SetErrHdr;;***:------------------------------------------------;

;SetErrHdr;;***: Feature 1931 - GenPrint rule example ;

;SetErrHdr;;***:------------------------------------------------;

;JobInit1;;;

;GenPrint;;;

Always place the GenPrint rule immediately after the JobInit1 rule in your AFGJOB.JDT file.

Creating multiple print batches

You can assign a recipient batch to multiple print batch files during GenPrint processing. This lets you print the same batch in multiple formats, such as in PDF and Metacode format. Here is an example:

< Print_Batches >

BATCH1 = Batch1.bch

BATCH2 = batch2.bch

BATCH3 = Batch1.bch

In this example, Batch1.bch will be printed by both print BATCH1 and print BATCH3.

Setting up banner processing

This rule also supports transaction and batch banner processing. To set up banner processing, you must set the appropriate GVMs before each instance of the class recipient is printed. Use the RecipMap2GVM control group to set the GVMs. See Writing Unique Data Into Recipient Batch Records for more information.

Processing under IDS

To support IDS processing, the system lets you hold the batch, NA, and POL files in a list until the GenPrint rule has executed. To tell the system to hold the batch, NA, and POL files, include the following INI option:

< RunMode >

DelayedFileWrite = Yes

See also

  • MergeWIP
  • PrintFormset
  • RestartJob


GetCo

Use this form set level rule to get the company code (Key1 field) from the extract data, and get its equivalent value from the INI file for use by the system.

Syntax

;GetCo;;;

This rule gets the company code (Key1 field) from the extract data using the GetRecord search criteria specified in the data field. This rule also sets the company—stored in the master transaction set—to the value defined in the INI file. In the INI file, this value is stored in the Key1Table control group under the option name which equals the value returned by GetRecord.

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

See also

  • GetLOB
  • Search Criteria


GetLOB

Use this form set level rule to get the line of business (from the Key2 field) code from the extract data, and to get its equivalent value from the INI file for use by the system.

Syntax

;GetLOB;;;

This rule gets the line of business (Key2 field) code from the extract data using the GetRecord search criteria specified in the data field. This rule also sets the line of business—stored in the master transaction set—to the value defined in the INI file. In the INI file, this value is stored in the Key2Table control group under the option name which equals the value returned by GetRecord.

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

See also

  • GetCo
  • Search Criteria


GetRCBRec

Use this form set level rule to set the current recipient batch file. This rule initializes the current recipient batch file, if necessary.

This rule also sets the first printer for the current batch to be the current printer and retrieves the next record from the current recipient batch file.

Syntax

;GetRCBRec;;;

Example

;GetRCBRec;;;

See also

  • Rules Used for 2-up Printing


GetRunDate

Use this form set level rule when there is no value in the transaction extract lines that can be used as the run date. This rule gets the current date and treats it as the run date. It then reformats the date based on the format you specify in the format mask.

The rule assumes the GVM variable RunDate is the name of the variable where the date is stored. The RunDate variable is created if it does not exist. GVM variables are automatically created from the fields defined in your TRNDFDFL.DFD file, or by using the rule that explicitly creates GVM variables. If you omit the variable from being created in one of these methods, this rule creates it for you.

Syntax

;GetRunDate;;;

The parameters you can include are the various date formats supported by FmtDate rule. The default format is D4 (YYYYMMDD).

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

Format Masks

There are two types of format masks, pre-defined types 1-9 and A-Q and user-defined format arguments. If the pre-defined formats meet your needs, use them, otherwise, create a user-defined format. For information on using pre-defined format types, see Using Pre-defined Date Formats.

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.

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

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.

See also

● FmtDate


GVM2GVM

Use this form set level rule to copy the data from one GVM variable to another GVM variable.

You specify the two variables using INI options, for example:

< Trigger2WIP >
  Company = Key1
  LOB = Key2

The contents of the Company variable is copied to Key1.

The contents of the LOB variable is copied to 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.

See also

  • MergeWIP
  • WIPFieldProc
  • WIPImageProc
  • WIPTransactions
  • GenData WIP Transaction Processing


IfRecipUsed

Use this form set level rule to place a form set in a recipient batch if the recipient name matches the one you specify with this rule. For instance, if the form is triggered and the recipients are set to receive a copy of those sections, a copy of the sections that make up the form are copied to the specified batches.

Syntax

;IfRecipUsed;;;

There are no parameters for this rule.

Example

;IfRecipUsed;;BATCH1=INSURED;

If the recipient name placed in the data area (such as INSURED) is used in this form set, the system assigns this form set to the recipient batch named in the data area (such as BATCH1).

You can place multiple AssignToBatch rules in the AFGJOB.JDT file. All that return true will be placed in the appropriate recipient batch. You can assign several recipients to a single batch. This is useful if the recipients receive very few forms or you only want to manage a small number of batch files.

You must place this rule in the AFGJOB.JDT file before the BuildFormList rule.

Note Powertyping takes precedence over all AssignToBatch assignments, and errors take precedence over powertyping.

See also

  • AssignToBatch
  • BuildFormList
  • SetOutputFromExtrFile


ImageMapImportData

Use this form set level rule with the ImportFile or ImportExtract rule to map the data you are importing. You can also use this rule with any other rule, such as a custom rule, that fills in field dictionary values (like the standard V2 import methods).

Normally, when you use this type of import, you would replace the NoOpFunc rule to do mapping via the DDT files, or you would use the MapFromImportData rule on each field in the DDT file.

If, however, you have two environments — one that does imports and one that does regular batch processing — you may not want to maintain two sets of DDT files. Therefore, you could use this rule if you do not plan to execute any field level rules.

Syntax

;ImageMapImportData;;;

This rule loads the section and tries to get the data dictionary value of each field created during the import. If you do not want the field level rules to execute in the DDT file, use the JDT rule that skips field processing. Here is an example:

<Base Image Rules>

;StandardImageProc;3;;

;ImageMapImportData;3;;

<Base Field Rules>

;WIPFieldProc;4;No field processing;

Note While the assumption is that you use this rule when you want to skip normal field processing, there is no requirement that you do so. If you omit the WIPFieldProc rule, the field level rules will execute. Depending on the rules you have assigned to your fields, this may cause errors, or may override the data that was actually imported.

Standard data importing can supply field data at various levels, such as: form set global, form global, and image local.

Each occurrence of a field with the same name and declared using the form set global scope will normally have the same value. Form global scope applies to similarly defined fields only within a given form. Image local scope means the field is specific to that section.

Import files sometimes specify all field data at the section level and do not separate out form set or form global data. This rule first tries to get each field's data at the dictionary scope level defined in the FAP file. If a form set or form global value cannot be found for a field, a second search is done at the section level.

Note This approach supports both types of import files — those that specify all data at the section level and those that separate out data at the appropriately defined scope levels.

See also

  • ImportExtract
  • ImportFile
  • WIPFieldProc
  • MapFromImportData
  • NoOpFunc


ImportExtract

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

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

2. 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.
  • 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 a section (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 transactions with embedded export files

In this example, the extract file is made up of normal transactions with embedded export files. This example imports information from an extract file named IMPORT.DAT 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:

  • 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 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…

…

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

…

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 appended export files

In this example, the extract file is made up of one or more appended export files. This 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;…

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

See also

  • MapFromImportData
  • NoOpFunc
  • ReplaceNoOpFunc
  • ImportFile
  • ImportNAPOLExtract


ImportFile

Use this form set level rule to import transactions (via a standard export file) from Documaker Workstation into GenData. This rule outputs the transaction to an NAFILE.DAT file which can then be used by the GenData program.

Note You can import multiple export files if you use the SCH option.

Syntax

ImportFile;;option;

There are several ways to specify the import file in the option parameter:

Option | Description
FILE = file name | Enter the name and path of the import file.
INI = INI control group, option | Enter the INI control group and option in which the import file is defined.
SCH = offsetofmask, <searchmask> offsetofdata, lengthofdata | This indicates the file name is contained in a record of the extract file. The offsetofmask is the offset of the 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 a section (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.

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)

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;

…

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;

…

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;

…

See also

  • MapFromImportData
  • ReplaceNoOpFunc
  • RULNestedOverFlowProc
  • ImportNAPOLExtract
  • ImportNAPOLFile
  • ImportExtract


ImportNAPOLExtract

Use this form set level rule to import an extract file into the GenData program that is made up of:

1. Typical transactions with one or more combined WIP/NA/POL export files from Documaker Workstation embedded into each transaction This illustration shows transactions with embedded WIP/NA/POL export files:

Transaction 1

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

2. 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.
  • For each field that comprises a section (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 transactions with embedded WIP/NA/POL files

In this example, the extract file is made up of normal transactions with embedded WIP/NA/POL export files. This example imports information from an extract file named IMPORT.DAT which is comprised of transactions with embedded WIP/NA/POL export 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\

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

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

;ImportNAPOLExtract;;;

;LoadRcpTbl;;;

;RunSetRcpTbl;;;

…

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 appended WIP/NA/POL files

In this example, the extract file is made up of one or more appended WIP/NA/POL export files. This example imports information from an extract file named IMPORT.DAT 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;;;

/* 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

See also

  • MapFromImportData
  • NoOpFunc
  • ReplaceNoOpFunc
  • ImportFile
  • ForceNoImages
  • RULNestedOverFlowProc


ImportNAPOLFile

Use this form set level rule to import a single transaction, stored in a WIP/NA/POL export file, from Documaker Workstation into the GenData program.

Note If you use the SCH option, you can import multiple Documaker Workstation WIP/NA/POL export files.

Syntax

;ImportNAPOLFile;;option;

There are several ways to specify the import file in the option parameter:

Option | Description
FILE = file name | Enter the name and path of the import file.
INI = INI control group, option | Enter the INI control group and option in which the import file is defined.
SCH = offsetofmask, <searchmask> offsetofdata, lengthofdata | This indicates the file name is contained in a record of the extract file. The offsetofmask is the offset of the 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 a section (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.
  • 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

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;

…

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\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;

…

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;

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

;ImportNAPOLFile;;GVM=Import_File;

See also

  • ImportFile
  • ImportExtract
  • ImportNAPOLExtract
  • ImportNAPOLFile


ImportXMLExtract

Use this form set rule to import a file which consists of one or more XML transactions into the GenData program for processing. Using this file, the GenData program creates the recipient batch, NAFile, POLFile, and NewTrn files that you can print, archive, or both using the GenPrint and GenArc programs.

Note If you are running Documaker from IDS, use the ImportXMLExtract rule to bring in XML in standard Documaker XML format, such as from Documaker Workstation or iDocumaker. Use the UseXMLExtract rule to convert a loaded extract file into an XML tree, which you can then use to query data.

You append multiple export files to create the import XML file. The export files are created using the Documaker Workstation XML Export option. This illustration shows an example file comprised of export files appended to one another:

Transaction 1

<?xml version="1.0"?>
<Document Type="Oracle Universal" Version="5.0">
<DocSet>
<ArcEffectiveDate></ArcEffectiveDate>
<Library Name="Oracle Insurance"></Library>
<Key1 Name=”Company”>SkyInsur</Key1>
<KeyY2 Name=”Lob”>Package Policy</Key2>
<TransactionID Name="PolicyNum">1010j</TransactionID>
…
…

Transaction 2

<?xml version="1.0"?>
<Document Type="Oracle Universal" Version="5.0">
<DocSet>
<ArcEffectiveDate></ArcEffectiveDate>
<Library Name="Oracle Insurance"></Library>
<Key1 Name=”Company”>SkyInsur</Key1>
<KeyY2 Name=”Lob”>Package Policy</Key2>
<TransactionID Name="PolicyNum">1110j</TransactionID>
…
…

Transaction 3

<?xml version="1.0"?>
<Document Type="Oracle Universal" Version="5.0">
<DocSet>
<ArcEffectiveDate></ArcEffectiveDate>
<Library Name="Oracle Insurance"></Library>
<Key1 Name=”Company”>SkyInsur</Key1>
<KeyY2 Name=”Lob”>Package Policy</Key2>
<TransactionID Name="PolicyNum">1210j</TransactionID>
…
…

Syntax

ImportXMLExtract;;option;

Option | Description
SP | Include the SP option to suppress the pagination portion of the import. This lets you run rules and other form set manipulations before calling a rule to paginate the form set, such as the PaginateAndPropogate rule.
Note You can only use this rule for single-step processing.

Keep in mind...

  • Create a simplified AFGJOB.JDT file when you use this rule and omit these rules:
    • LoadRcpTbl
    • LoadExtractData
    • RunSetRcpTbl
    • CreateGlbVar
    • LoadDDTDefs
    • 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 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 omitted from the XML file, processing stops. Here is an example:

    < XMLTags2GVM >
    Key1 = Key1, Req
    Key2 = Key2, Req
    KeyID = TransactionID, Opt

Example

Assume you have the following items defined in your master resource library. See XML File Format 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;;;

…

…

See also

  • ImportXMLFile
  • PaginateAndPropagate
  • Processing Import Files


ImportXMLFile

Use this form set rule to import an XML file into GenData for processing. Using this file, the GenData program creates recipient batch, NAFile, POLFile, and NewTrn files that you can print, archive, or both using the GenPrint and GenArc programs.

The export file to be used as import was created using the Documaker Workstation XML Export function that produces a file in the Documaker Standard XML format.

Syntax

;ImportXMLFile;;option;

Option

Description

SP

Include the SP option to suppress the pagination portion of the import. This lets you run rules and other form set manipulations before calling a rule to paginate the form set, such as the PaginateAndPropogate rule.

You must place this option before the FILE option. Here is an example:

;ImportXMLFile;;SP,SCH=11,FILENAME 20,20;

This example suppresses the pagination of the import of the file designated by this search mask.

TF

Enter TF to truncate fields to the field length defined by the FAP file. Make sure you specify this parameter before FILE option.

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

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

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 multiline 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;

…


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

…


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;


XML File Format

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

Keep in mind...

  • DAPOPTIONS should have a value of M for multi-page sections (FAP files). There are other section options, but only M is applicable in XML.
  • Use DAPINSTANCE to provide a page number for multi-page sections. If the section 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.

See also

  • ImportXMLExtract
  • PaginateAndPropagate
  • Processing Import Files


InitArchive

Use this job level rule along with the Archive rule, to run the GenArc program as part of single-step processing.

The InitArchive rule checks the INI options in the Trigger2Archive control group, initializes the database, opens the APPIDX.DFD and CAR files, and perform other steps to initialize archive.

The Archive rule then unloads the current form set and converts field data for archive using the INI options in the Trigger2Archive control group.

Syntax

;InitArchive;2;;

Example

Here is an example:

< Base Rules >

;InitArchive;1;;


InitConvertWIP

Use this job level rule to perform the initialization necessary for the ConvertWIP rule. You use this rule when you want to include the GenWIP process in single-step mode.

Syntax

;InitConvertWIP;;;;

Example

;InitConvertWIP;1;;


InitMerge

Use this job level rule to create a list of printers, batches, and buffers for the RCB comment records. This rule also creates a list to hold AFP records and AFP fonts. After the system finishes running the rule, it deletes everything the rule created.

Syntax

;InitMerge;;;

Note The recipient batch files are not used at this stage. The batch list must be created beforehand so the system will know which print files belong together. The skipping batch message is an artifact of the batch file loading process.

Example

;InitMerge;;;

See also

  • Rules Used for 2-up Printing


InitOvFlw

Use this job level rule to initialize the overflow feature. Overflow symbols are created to keep track of the number of records processed. The overflow symbol is one of the parameters that would be initialized.

Syntax

;InitOvFlw;;;

When processing an overflow form, the overflow count must be reset back to zero, if not the processing will start with the second record in the extract.

When finished, this rule turns off the system’s overflow feature which frees resources used when using the overflow feature and overflow variables.

Example

;InitOvFlw;;;

See also

  • WriteOutput
  • ResetOvFlw
  • SetOvFlwSym
  • IncOvSym
  • OvActPrint
  • OvPrint


InitPageBatchedJob

Use this job level rule to open NA and POL files. This rule installs the section level callback function for inserting recipient batch records into the AFP print stream as AFP comment records.

When finished, this rule restores the original callback function and closes the NAFILE.DAT and POLFILE.DAT files.

Syntax

;InitPageBatchedJob;;;

Example

;InitPageBatchedJob;;;

See also

  • Rules Used for 2-up Printing


InitPrint

Use this job level 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.

This rule also places a structure containing all of the above information into the GVM variable RULPRT.

Syntax

;InitPrint;;;

When finished, this rule closes any open print files.

Example

;InitPrint;;;

See also

  • PrintFormset
  • NoGenTrnTransactionProc
  • Rules Used for 2-up Printing
  • Rules Used in Single-Step Processing


InitSetRecipCache

Use this job level rule to set the cache the system will use to store 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.

You can use this rule to improve processing performance for complex forms. This rule has no affect on the processing speed for static forms.

This rule is also used in multi-step processing to enhance performance.

Note If you omit this rule, the system does not set aside memory for the Key1 and Key2 fields. If this rule causes any problems with your implementation, you can remove it from the AFGJOB.JDT file.

Syntax

;InitSetRecipCache;;Key1,Key2;

Parameter

Description

Key1
Key2

For Key1 and Key2, enter the amount of memory you want to set aside for storing the information contained in those fields. These fields are typically used to store information such as the company name and line of business.

You can enter any number from one (1) to 500. The default is five (5).

If you enter a zero (0), a negative number, or a number greater than 500, the system ignores your entry and defaults to five.

Example

;InitSetRecipCache;;10,15;

This example sets the cache for the Key1 field to 10 and sets the cache for the Key2 field to 15.


InlineImagesAndBitmaps

Use this form set level rule if you do not want to use Library Manager to maintain forms and graphics but still need to retrieve the exact data that was printed. This rule lets you inline all FAP files and embed graphics into the NA file.

Note Keep in mind the size of the NA file and archive will grow significantly if you use this rule. Furthermore, the performance of the GenData, GenPrint, and GenArc programs will degrade significantly if you use this rule.

Syntax

;InlineImagesAndBitmaps;;;

Use this rule only when necessary and when performance and the size of the output are not issues.

This rule loads all sections and graphics and ignores the LoadFAPBitmap and LoadCordFAP INI options. There are no parameters for this rule.

The return values are: msgSUCCESS or msgFAIL.

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


InsNaHdr

The InsNAHdr rule is a legacy rule that few installations would ever need to use. This rule has no affect unless you also include this INI option:

< RunMode >

NAUnload = No

Note Do not set the NAUnload option to No unless you are specifically directed to do so by Oracle Insurance services or support personnel.

The InsNaHdr rule and this option tells the system the NAFILE.DAT file will not be unloaded in a single process. Instead, it will be unloaded a piece at a time. Specifically, the system unloads the section header into the NAFILE.DAT file before the remainder of the section is processed.

Using this rule implies that you will create the NAFILE.DAT file as the form set is being processed, instead of waiting until after the process has completed and creating the NAFILE.DAT file in one step.

Syntax

InsNaHdr( )

There are no parameters for this rule. This rule builds the NA header and appends it to NAFILE.DAT file.

Example

;InsNaHdr;3;;


InstallCommentLineCallback

Use this job level rule during the AFP printing process to write transactional information into each page of the print stream. The information is written using AFP comment records and contains the recipient batch record information — the same information written into recipient batch files for each transaction.

Before adding the recipient batch record information as a comment record on each page, this rule also calculates and updates several GVM variables and structures that can be used by other rules which are executed during the print process. The values updated include the number of pages in each batch and the current page within the print stream.

The CurPage and TotPage GVM variables must be declared within the recipient batch record definition. Here is an example:

< FIELD:CurPage >

INT_TYPE = LONG

EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM

EXT_LENGTH = 10

< FIELD:TotPage >

INT_TYPE = LONG

EXT_TYPE = CHAR_ARRAY_NO_NULL_TERM

EXT_LENGTH = 10

Normally, the CurPage variable reflects the current page number within the print stream. This is not necessarily the same as the page number that might actually print on the document. The TotPage variable reflects the total number of pages within a given transaction. Depending the other rules in use during the process, the value or meaning of these GVM variables can vary.

The comment information written into the print stream can serve multiple purposes, such as to later facilitate 2-up printing. During a 2-up printing process, you sometimes need to know whether the page on the left and the page on the right are from the same or different transactions. By having the recipient batch record information written into each page, it is possible to query that information and make the appropriate determination. You can use the ParseComment rule during the 2-up printing process to reconstruct the associated GVM variables in memory from the recipient batch record information stored in these comment records.

Syntax

; InstallCommentLineCallback;1; ;

This rule has no parameters.

Example

; InstallCommentLineCallback;1; ;

See also

  • ParseComment


JobInit1

Use this job level rule to initialize resources such as input files, output files, and tables.

Syntax

;JobInit1;;;

This rule opens the log file, opens the extract file, creates the NA and POL files, opens forms set file, and opens and initializes recipient batch files. When finished, this rule closes the files it opened during the pre-processing stage.

Example

;JobInit1;;;


LoadDDTDefs

Use this job level rule to load the field rules from the MASTER.DDT file into an internal linked list. You must include this rule in the AFGJDT.JDT file if your field level rules are defined in the MASTER.DDT file.

This rule is used with the Master field level rule.

Syntax

;LoadDDTDefs;;;

If you have variable fields that you use on most of your forms, such as Name and Address fields, you can use the MASTER.DDT file to store these variable field mappings.

If you use the MASTER.DDT file, add the Master rule to all variable fields on the section. The Master rule tells the system to look in the MASTER.DDT file for mapping information for those variable fields.

Using the MASTER.DDT file is helpful if you need to make a change to the variable field mapping because you only have to make changes once in the MASTER.DDT file. It’s also helpful when you are setting up complicated rules since you only have to map the fields once. Test your mappings in the MASTER.DDT file before you copy them to other variable field mappings.

Example

;LoadDDTDefs;;;


LoadExtractData

Use this form set level rule to load extract data into memory for each transaction. You must include this rule if any subsequent rules will search for or use extract data.

You must include this rule if:

  • You are executing the GenTrn, GenData, and GenPrint programs as separate processes (multi-step processing), and
  • Subsequent rules will search for or use extract data

If you omit this rule from the AFGJOB.JDT for multi-step processing, you will receive these error messages:

DM10702: Warning in BuildFormList(): No extract records.

VMMCountList(pRPS->ExtractListH) = 0. Processing will continue.

DM12018: Error in RPDoBaseFormsetRulesForward(): Unable to <BUILDFORMLIST>().

Note Do not include this rule if you are using the NoGenTrnTransactionProc rule. Doing so will cause the GenData program to go into a processing loop.

Syntax

;LoadExtractData;;;

Example

<Base Form Set Rules>

;RULStandardTransactionProc;;;

;LoadExtractData;;;

;ResetOvFlw;;;

;IfRecipUsed;;BATCH1=INSURED;

;IfRecipUsed;;BATCH2=COMPANY;

;IfRecipUsed;;BATCH3=AGENT;

;BuildFormList;;;

;LoadRcpTbl;;;

;UpdatePOLFile;;;

;RunSetRcpTbl;;;

;ProcessQueue;;PostPaginationQueue

See also

  • NoGenTrnTransactionProc


LoadFormsetFromArchive

Use this form set level rule to extract a form set from a DAP archive based on archive keys stored in a standard extract file.

Note You can use the LoadFormsetFromArchive rule to replace the BuildFormList, LoadRcpTbl, and RunSetRcpTbl rules in the AFGJOB.JDT file.

Because the LoadFormsetFromArchive rule loads a complete form set, it is usually not necessary to execute the section and field level rules. To skip section and field rule processing it is necessary to specify the appropriate rules in the AFGJOB,JDT file. See the example below. If required, the loaded form set can be modified using other transaction level rules or DAL scripts.

Syntax

;LoadFormsetFromArchive;;;

There are no parameters for this rule, but you can use these INI options:

< LoadFormsetFromArchive >

Key =

DisplayFields =

TempFile =

Debug =

Option

Description

Key

Use this option to build the search request for the APPIDX. You can specify multiple Key options if necessary. The first transaction that matches the values for the fields is extracted from archive.

You can specify the Key search value as an XML or standard flat file search mask, such as (1, HEADER). Here is another example:

Field(UNIQUEID) Search(!/Form/UNIQUEID) OFFSET(1) Length(40)

If the keys are not unique, the extracted matching transaction can be arbitrary.

DisplayFields

(Optional) Use this option to specify a list of archive index fields you want printed to the log file and console as the system processes the transaction.

TempFile

(Optional) Use this option for debugging purposes. If you include this option, the system writes the NA and POL files to the temp file model name you specify.

For example, if you specify TEMP.TXT, the NA and POL files are written to TEMPNA.TXT and TEMPPOL.TXT, respectively.

Debug

(Optional) Enter Yes to have the system write debug information into the log file.

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 section in this base uses these rules. */

<Base Image Rules>

;WIPImageProc;;

/* Every field in this base uses these rules. */

<Base Field Rules>

;RULWIPFieldProc;;

See also

  • BuildFormList
  • LoadRcpTbl
  • RunSetRcpTbl


LoadListFromTable

Use this job level rule to load a table specified in your FSISYS.INI file’s Data control group into a link list and place the handle of the list into the GVM variable you specify.

Syntax

;LoadListFromTable;;;

This rule has these parameters:

Parameter | Description
GVM_LISTNAME | The name of the GVM variable in which the handle of the list should be stored.
INI_TABLE_OPTION | The name of the option in the Data control group in the INI file you want the system to load. This option should specify the name of the table.
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.


LoadRcpTbl

Use this form set level rule to load entries from the SETRCPTB.DAT file based upon the current Key1 field (such as company), Key2 field (such as line of business), and the transaction type.

Note You can use the LoadFormsetFromArchive rule to replace the BuildFormList, LoadRcpTbl, and RunSetRcpTbl rules in the AFGJOB.JDT file.

Only those entries in the SETRECPTB.DAT file that match the Key1, Key2, and transaction type will be loaded and processed. By loading only those that match, the processing becomes more efficient.

Syntax

;LoadRcpTbl;;;

Example

;LoadRcpTbl;;;

See also

  • BuildFormList
  • LoadFormsetFromArchive
  • RunSetRcpTbl


LoadTblFiles

Use this job level rule to load one or more text tables listed in the tables list file, which is defined in the FSISYS.INI file’s Data control group, in the TblFile option.

This rule lets you make available many table files for use by Documaker Server. These table files can contain lists of codes, abbreviations, and addresses which might be hard to maintain in a large extract file.

Syntax

;LoadTblFiles;;;

This rule frees memory resources used to store the tables. Here is an example of the TblFile option:

< Data >

TblFile = .\deflib\TblFile.Dat

Example

;LoadTblFiles;;;

This example loads all the tables listed in the tables list file defined in the INI file. The table data can then be accessed using the MovTbl rule.

See also

  • MovTbl


LoadTextTbl

Use this job level rule to load all specified text tables into the text table list for use by field level rules. All text tables should be listed in the text table listing file, which is defined in the FSISYS.INI file’s Data control group, in the TextTbl option.

This rule loads all defined tables and makes them available for use by Documaker Server. These text files can contain paragraphs and messages which might be hard to maintain in a large extract file.

Syntax

;LoadTextTbl;;;

When finished, this rule erases the text table list. Here is an example of the TextTbl option:

< Data >

TextTbl = TextTbl.Dat

Example

;LoadTextTbl;;;


MergeAFP

Use this form set level rule to initialize input files. This rule populates the AFP record list, retrieves RCB comment records, and terminates the input files.

This rule also initializes output files, and writes out the AFP record list, adding end page and end document records as necessary. The rule then terminates these output files.

Syntax

;MergeAFP;;;

Example

;MergeAFP;;;

See also

  • Rules Used for 2-up Printing


MergeRecipsFromForm

Use this form set level rule to assign the recipients from a specific form to the other forms in a form set. This lets you reduce the number of recipient triggers when all recipients receive the majority of the forms in the form set.

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)

Z Flag

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.


MergeWIP

Use this job level rule to initialize GenData WIP Transaction Processing. This rule creates a transaction memory list to which it adds transactions from the WIP file that have status codes which match those in the rule’s parameters.

The status codes identified by this rule do not have to be identified by the WIPTransactions rule. You can include status codes for transactions that you want to delete from the WIP file. Transactions with status codes not including in this rule’s parameters remain in the WIP file when processing finishes.

These other rules are also used when you run WIP Transaction Processing:

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

WIP selection performance during batch processing

The system automatically limits the result sets queried from DBMS systems by the MergeWIP rule to the rule's parameters for the STATUSCODEs to significantly improve 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 transactions

The MergeWIP rule can check a date field in the WIP index to determine whether to 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
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 message

Instead of returning an error if it comes across an empty WIP list when merging WIP, 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

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.

See also

  • GVM2GVM
  • WIPFieldProc
  • WIPImageProc
  • WIPTransactions
  • GenData WIP Transaction Processing


MultipleDataDictionaryFiles

Use this form set level rule to specify multiple data dictionaries (XDBs) to use across multiple Key1/Key2 combinations. You can specify which item (Key1, Key2) or combination of items determines the switch. If the database is not found in the list of possibilities, the system loads the default XDB, as specified by the original INI option.

Syntax

;MultipleDataDictionaryFiles;2;parameters;

You specify the parameters based on which key tells the system when to switch from one data dictionary to another. You can use the keys individually or in any combination.

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

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.


NoGenTrnTransactionProc

Use this form set level rule when you use the GenData program by itself to execute the GenTrn and GenData steps. In that processing environment, this rule, processes the extract file and creates the information normally created in both the GenTrn and GenData steps.

When combined with the InitPrint and PrintFormset rules, it creates the output files created during the GenPrint step.

Note Do not use this rule if you are running the GenTrn, GenData, and GenPrint programs as separate processes. Do not use this rule with the LoadExtractData rule. Doing so will cause the GenData program to go into a processing loop.

This rule replaces the RULStandardTransactionProc rule in a single-step implementation.

Syntax

;NoGenTrnTransactionProc;;;

This rule loads extract file records for the current transaction into memory. To use this rule, you must add the following options in your FSISYS.INI or FSIUSER.INI file:

< Data >

TrnFile = <CONFIG:~Platform > TrnFile

< CONFIG:PC >

TrnFile = NUL

...or else include a TRNFILE.DAT file, which you can leave empty.

Example

;NoGenTrnTransactionProc;;;

See also

  • RULStandardTransactionProc
  • InitPrint
  • PrintFormset
  • LoadExtractData
  • StandardFieldProc
  • StandardImageProc
  • Rules Used in Single-Step Processing


OMRMarks

Use this job level rule to generate OMR marks on 1-up documents printed on any supported base system printer or on 2-up documents printed on any AFP printer that supports 2-up printing.

OMR marks are used to indicate ZIP code change, demand feed, inserts and so on. OMR marks are solid boxes placed on a page.

The rule loops through the pages of the form set and creates special sections for each page with the required OMR marks. The OMR marks are based on special settings in your FSISYS.INI or FSIUSER.INI file. The INI file settings use special global variable names, rule names, and conditions to trigger specific OMR marks.

Syntax

;OMRMarks;;Cond(LetterOMR);

Parameter | Description
Cond | (Optional) Indicates special conditions exist for printing OMR marks.
LetterOMR | (Optional) Refers to the data in the Condition table (CONDTBL). The true or false for this condition triggers the printing of the set of OMR marks for particular transaction.

Place this rule after the WriteNAFile rule in the AFGJOB.JDT file.

Note

  • Keep in mind the OMRMarks rule is a post process rule. This means that pagination and propagation takes place before the rule is called. So, this rule goes back through the form set after the forms have been created and places a mark on each page.
  • You must include the PaginateAndPropagate rule after the OMRMarks rule because, during post processing, the system executes the rules in the JDT file from bottom to top.

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.

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),Right(t,b,l,r)) | Top, bottom, left, and right coordinates for the page in FAP units (1 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.
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

See also

  • PaginateAndPropagate
  • Rules Used in Single-Step Processing
  • Rules Used for 2-up Printing
  • JDT Rules Reference
  • Using Condition Tables


PageBatchStage1InitTerm

Use this job level rule 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

See also

  • Rules Used for 2-up Printing
  • BatchByPageCount
  • WriteRCBWithPageCount
  • JDT Rules Reference


PaginateAndPropagate

Use this form set level rule to paginate the form set and merge in or propagate field data.

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

As the system checks the body sections 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 section that is already determined to fit on the page.

With mode 1, the system increases the limit and reevaluates the section 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.

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 sections. When a body section exceeds this lower limit, the system splits the logical page into two pages.

The section that exceeds the limit and all following sections are moved up and to the second page. Sections on the first page marked as copy-on-overflow are copied to the second page. Sections 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.

See also

  • CanSplitImage
  • Rules Used for 2-up Printing
  • Rules Used in Single-Step Processing
  • PrintFormset


ParseComment

Use this form set level rule when merging two AFP print streams in a 2-up printing process. This rule parses the recipient batch record information written as an AFP comment into each printed page back into the GVM variables associated with the recipient batch DFD. You would do this, for example, if you need to know whether the page on the left and right side (as accomplished through 2-up printing) are from the same transaction.

For this rule to be useful, the appropriate comment records, matching the recipient batch record DFD, must have been added to the print streams that are being merged in the 2-up printing process. A rule such as InstallCommentLineCallback is used during the original print step is an example.

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 )

See also

  • InstallCommentLineCallback


PostTransDAL

Use this form set level rule in the AFGJOB.JDT file to execute a DAL script on the POST_PROC_A message. The PostTransDAL rule executes after other form set rules and section level rules.

You can use this rule to handle follow up tasks after form set rules and section rules are executed. For example, you can use this rule to clear or change GVM and internal DAL variables.

Syntax

;PostTransDAL;;string;

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

Although you can use DAL to access almost any form set or section 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.

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);

See also

  • PostImageDAL
  • PreImageDAL
  • PreTransDAL


PreTransDAL

Use this form set level rule in the AFGJOB.JDT file to execute a DAL script on the PRE_PROC_A message. The PreTransDAL rule executes before other form set rules and before section rules.

You can use this rule to handle setup tasks which should occur before form set rules and section rules are executed. For example, you can use this rule to initialize GVM and internal DAL variables.

Syntax

;PreTransDAL;;string;

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

Although you can use DAL to access almost any form set or section 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

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

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.

See also

  • PostImageDAL
  • PostTransDAL
  • PreImageDAL


PrintData

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

Syntax

;PrintData;;;

Note The section handler installed by the InitPageBatchedJob rule is called during the printing stage. If you want to make any modifications to the recipient batch record, you must do so before this point.

Example

;PrintData;;;

See also

  • Rules Used for 2-up Printing


PrintFormset

Use this form set level rule when you use the GenData program by itself to execute GenTrn and GenPrint processes (single-step processing). In that processing environment, this rule, when combined with the InitPrint rule, prints form sets.

Note Do not use this rule if you are running the GenTrn, GenData, and GenPrint programs as separate processes.

Syntax

;PrintFormset;;;

This rule checks the recipients for the form set and then identifies the print batch in which this form set should be included. It then prints the form set.

This rule has no parameters.

When you use this rule, you must also include a BatchByPageCount or BatchingByRecipINI rule to produce print batches and the final print stream. If you omit either of these rules, you’ll get the following error message:

Unable to <PRINTFORMSET>()

Note You must define the BatchingByRecip control group to pass parameters to this rule. Use this control group to specify the batch names and search criteria (conditions) for the batches. If you receive this error message, also check the condition.

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

See also

  • BatchByPageCount
  • BatchingByRecipINI
  • InitPrint
  • Single-Step Processing
  • PaginateAndPropagate


ProcessQueue

Use this job level rule to process the queue you specify.

Syntax

;ProcessQueue;;(Queue);

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

See also

  • Single-Step Processing
  • Rules Used for 2-up Printing


ProcessRecord

Use this form set level rule to switch between print files as 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.

Syntax

;ProcessRecord;;;

Example

;ProcessRecord;;;

See also

  • Rules Used for 2-up Printing


ProcessTriggers

Use this form set level rule to process the groups (Key1, Key2 combinations) that exist in the form set, as opposed to only a single set of keys specified in the TRNFILE.DAT file.

Note This rule replaces the LoadRcpTbl and RunSetRcpTbl rules. You can replace those two rules with this one even if you are not using multiple lines of business (Key2s) in your document.

Syntax

;ProcessTriggers;;;

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.

Support

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

See also

  • BuildFormList
  • LoadRcpTbl
  • RunSetRcpTbl
  • RunTriggers


PXCandidateList

Use this form set level rule to build the form candidate list, based on the Form Candidate List DAL Trigger, and determine if the requested DAL script in the AFGJOB.JDT file should be evaluated.

The PXCandidateList rule acts as a functional equivalent for the PreTransDAL rule. The PXCandidateList rule executes the DAL script specified in the calling AFGJOB entry.

The DAL script then builds the State Loc table and returns control to the PXCandidateList rule. This rule next processes each of the State Loc table records against the FED table to build a Form Candidate list and a Consolidated Form State Loc table.

Note The PXCandidateList and PXTrigger rules support Policy Xpress FED processing. These rules act as replacements for the PreTransDAL and DALTrigger rules when you are doing Policy Xpress FED-specific processing.

Syntax

PXCandidateList

Example

In this example, the rule calls a DAL script named Xpress_create():

;PXCandidateList;;Xpress_create();

The called DAL script then builds the State Loc and Form tables. Using these tables, the rule then builds a list of all possible forms for a given transaction. This form list is used by the PXTrigger rule to determine if the requested DAL trigger should be executed.


INI Options

You can use these INI options with this rule:

Option | Description
StateLocTable | (Optional) Enter the name of the state location table. The default is T_St_Loc.
FormLocTable | (Optional) Enter the name of the form location table. The default is T_FM_Loc.
FedTable | (Optional) Enter the name of the FED table. The default is T_F_List.
FedTable | (Optional) Enter the name of the FED table. The default is pxfed.
StatLocTableDFD | (Optional) Enter the name of the state location table DFD file. If you omit the path, the file is written to the deflib directory. The default is T_St_Loc.dfd.
FormTableDFD | (Optional) Enter the name of the form table DFD file. If you omit the path, the file is written to the deflib directory. The default is T_F_List.
FedTableDFD | (Optional) Enter the name of the FED table DFD file. If you omit the path, the file is written to the deflib directory. The default is pxfed.dfd.
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

See also

● PXTrigger
● Input Tables
● The Policy Xpress FED Processing Flow


PXTrigger

Use this form set level rule to execute a DAL script if certain conditions are met. The PXTrigger rule replaces the DALTrigger rule. This rule is executed as part of RunSetRcpTable processing.

Note The PXCandidateList and PXTrigger rules support Policy Xpress FED processing. These rules act as replacements for the PreTransDAL and DALTrigger rules when you are doing Policy Xpress FED-specific processing.

This rule does not call the requested DAL script unless the requested form is in the form candidate list. The rule performs a look up using the requested SetRecip entry form name against the Form Candidate List table.

If the form is not found, the requested DAL script is not executed and the rule returns a trigger count of zero (0).

If the form is found, the rule unloads from the Consolidate Form State Loc table the StateLoc records into the FormStateLoc memory table based on the SetRecip entry form name.

Once the records are unloaded, the PXTrigger rule executes the requested DAL script. If the appropriate debug options are set, the FormStateLoc table and FormsList are unloaded to flat files.

Syntax

;DOCU;CA;CAINIT;;NBS;INSURED(1);;0;0;0;1;;PXTrigger;CAINIT;


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


The Policy Xpress FED Processing Flow

Policy Xpress FED Processing Flow

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.

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 auto validation

If the Transaction Type is PCH, the date evaluation is executed using 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 validation

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.

Property lines validation

If the Transaction Type is PCH, the date evaluation is executed using 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 validation/compare

The passed date is subjected to a trivial date validation.

The date must be in a CCYY-MM-DD format. The day can not be zero (0) 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.

See also

  • PXCandidateList


RegionalDateProcess

Use this job level rule to execute regional date processing (RDP) rules on forms. You create the RDP rules via Documaker Studio.

Note See the Documaker Studio User Guide for more information on creating RDP rules.

In the U.S. insurance industry, certain forms must comply with a regional authority (usually a state) to be approved for use within that area. The process of getting approval to use forms in each location is often referred to as submitting for state compliance.

Because of the various jurisdictions involved, you may have a form which is accepted by some states, but not by others. Alternatively, the form might be accepted by multiple states, but as of different dates. And to add another layer of complexity, states specify which document date must be used when activating this form.

To understand this last point, consider that almost all insurance policies have a date when coverage becomes effective – typically referred to as the policy effective date. Likewise, a policy usually has a written date that identifies when the document was actually drawn up. It is not unusual for the written date to be different from the policy effective date. For instance, you might buy your hurricane insurance today (the written date), but the policy does not become effective for 30 (or more) days. Each regional authority specifies which date determines the compliance of a given form.

This necessity to only activate the use of a form in a given region after a specific date complicates the creation of trigger conditions. Not only do you have to consider the typical transaction information that would cause you to include the form, you also have to calculate the various details to comply with the regional authorities described above.

To help you more easily manage this process, Studio lets you define regional date processing (RDP) rules that you can assign to each form. Part of the support is accomplished in Studio by defining the appropriate regional tests for each form. The remaining part occurs during the batch transactional process via the RegionalDateProcess rule.

Syntax

RegionalDateProcess;;;

There are no parameters for this rule.

Place this rule before any rule that calls the base triggering functionality, such as the RunSetRcpTbl rule. RDP rules operate as a filter that aids the normal triggering process by eliminating forms which do not meet the necessary criteria.

RDP rules are defined in group form files and assigned to individual forms. RDP rules are optional and only those forms containing one or more such rules are subject to this filtering process.

If a form has one or more RDP rules defined, these are evaluated during execution of this rule. The execution proceeds like this:

First, the system locates and evaluates the date search token associated with the rule. The resulting date value obtained from the transaction data is compared against the date range provided in the rule. If the date value is out of range, the form is flagged for possible elimination and execution moves to the next RDP rule.

If the date value is within the valid range, the next step is to iterate through the region search tokens associated with the rule and evaluate each. Each region search token might yield multiple hits. The system cross-references this list of values against the inclusion and exclusion list provided in the rule. If there is an intersection between the two lists, the rule is considered satisfied and the system moves to the next RPD rule. If the search token results in no matches for the list, then the system continues with the next search token until all search tokens are exhausted.

If the rule completes execution of the regional search tokens without finding any matches for the defined set, the form is flagged for possible elimination.

Each RDP rule executes in this manner which means that at the point where one rule considers the form eligible, no further RDP rules are execute on that form. Instead, RDP processing will immediately move to the next form.

If all RDP rules for a given form consider the form ineligible, then the form remains flagged with this state and is skipped during the subsequent triggering job rule process.

INI options

You can enter Yes for the RegionalDateProcess option to turn on debugging if you run into problems. Here is an example:

< Debug_Switches >

RegionalDateProcess = Yes

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.

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

See also

  • Documaker Studio User Guide


ReplaceNoOpFunc

Use this job level rule to register the MapFromImportData rule which the system will then use in place of the NoOpFunc rule.

Syntax

;ReplaceNoOpFunc;;;

There are no parameters for this rule. You typically use this rule with the following import rules:

  • ImportFile
  • ImportExtract
  • ImportNAPOLFile
  • ImportNAPOLExtract
Note Use this rule if any of the DDT files for your sections are set to use the NoOpFunc rule. If you use the MapFromImportData rule instead of the NoOpFunc rule, you do not have to use this rule.

See also

  • RULNestedOverFlowProc


RequiredFieldCheck

Use this form set level rule to have the GenData program send a transaction to WIP when it sees that a field designated as Required does not contain data.

If you include this rule in the AFGJOB.JDT file and the system finds a required field with no data...

  • You receive a message (Warning 20030) that lists the fields that are missing data — or as many as will fit into the message.
  • The GenData program sends the transaction to manual batch (WIP)
  • You receive a message indicating the transaction has been assigned to a manual batch

You can see the results on the console when using Documaker Server or in the Output are when using Studio’s Test manager. Here is an example from Studio’s Output area, which shows the GenData Errors tab:

  • The second warning line lists the fields missing data.
  • The last warning line indicates the transaction is being sent to manual batch.

Keep in mind the RequiredFieldCheck rule ignores these fields:

  • A field defined with the No User Edit attribute
  • An X or Space field, because having no data is valid in this case
  • A page number field or another print-time generated field that has a name that begins with a tilde (~)
  • A Send Copy To field

Syntax

;RequiredFieldCheck;;;

There are no parameters for this rule.

Example

Place this rule in the AFGJOB.JDT file so it runs after the data is mapped but before batch assignments are made, similar to how you would place the IfRecipUsed rule.

<Base Form Set Rules>

;NoGenTrnTransactionProc;;;

;LoadExtractData;;;

;RunTriggers;;;

;UpdatePOLFile;;;

;WriteNaFile;;;

;BatchingByRecipINI;;;

;RequiredFieldCheck;;;

;PaginateAndPropogate;;;


ResetDocSetNames

Use this form set level rule to reset the pRPS structure after the GVM variables have been remapped.

Syntax

;ResetDocSetNames;;;

Normally, after it loads the transaction, the system uses the options in the DocSetNames and Trn_Fields control groups to map GVM variables into the pRPS structure for GroupName1, GroupName2, and TransactionID. There are other fields, but GroupName1, GroupName2, and TransactionID are the primary ones.

When you use the MergeWIP rule, or an rule that imports the document field information normally mapped by the transaction rule, you may need to use the GVM2GVM rule to map the options in the Trigger2WIP control group back to GVM variables. Because the names of the Key1 and Group1 fields sometimes differ, this means the mapping occurs too late to also be mapped to the pRPS structure member. Therefore, you must use the ResetDocSetNames rule to reset the pRPS structure after the GVM variables have been remapped.

When you use the Ext2GVM rule to get the values for GroupName1, GroupName2, and GroupName3, especially in an XML implementation, be sure to include the MapBeforeReset parameter to re-map the RPS structures. With the parameter, this rule gets the GroupName values from global memory and converts them into the long values using the Key1Table andKey2Table control groups. This is typically used to convert company codes to company names and so on.

Here is an example:

;UseXMLExtract;;;

;Ext2GVM;;!/Forms/Key1 1,10,Company;

;Ext2GVM;;!/Forms/Key2 1,15,LOB;

;ResetDocSetNames;;ConvertBeforeReset;

To avoid using this rule, make sure the primary keys are defined the same way in these DFD files:

  • TRNDFDFL.DFD
  • RCBDFDFL.DFD
  • WIP.DFD

Example

Here is an example:

< Base Form Set Rules >

;WIPTransactions;;BATCHPRINT;

;GVM2GVM;;Trigger2Wip;

;ResetDocSetNames;;;


ResetOvFlw

Use this form set level rule to reset the overflow feature.

Syntax

;ResetOvFlw;;;

This rule resets or reinitializes all of the overflow variables. In general, the overflow symbol will keep track of record counts as the extract is processed. When an overflow variable is defined, the system adds it to an overflow symbols list. This list contains several attributes for each symbol. This rule resets those attributes to the default values assigned when you initially defined the overflow symbol.

Example

;ResetOvFlw;;;

See also

  • InitOvFlw
  • IncOvSym
  • OvActPrint
  • OvPrint
  • WriteOutput


RestartJob

Use this job level rule to open the restart file (RSTFILE) and reset the EXTRFILE, TRNFILE, NEWTRN, NAFILE, POLFILE, and batch files at the broken transaction. The RestartJob should be first base rule.

Note If the restart file does not exist, the system skips this rule.

Syntax

;RestartJob;;;

You can set up the GenData program to restart itself at a particular transaction if it encounters a failure. To accomplish this, the system uses a restart file. You use INI options to set up the restart file.

Note This rule does not apply if you are using single-step processing.

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;

See also

  • GenPrint


RULCheckTransaction

Use this form set level rule to save the files necessary for restarting the GenData program. This rule should be the first base form set rule.

Syntax

;RULCheckTransaction;;;

The rule saves the EXTRFILE offset, TRNFILE offset, NEWTRN offset, NAFILE offset, POLFILE offset, and batch file offsets into a restart (RSTFILE) file. You can set up the GenData program to restart at a particular transaction if it encounters a failure. To accomplish this, the system uses a restart file. Use INI options to set up the restart file.

Note This rule does not apply if you are using single-step processing.

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

See also

  • RestartJob


RULNestedOverFlowProc

Use this form level rule to nest overflow within overflow. The nested overflow can occur on as many levels as necessary. This lets you use the system as a reporting tool. The only requirement is that the data occur in order.

This rule lets you create groups that contain group headers (lead sections), subordinate sections (list sections), and group footers (following sections).

Syntax

;RULNestedOverFlowProc;;;

Insert this rule in the AFGJOB.JDT file just after the RunSetRcpTbl rule.

To specify how the nesting occurs, you must create a file named OVERFLOW.DAT. You can create this file using any ASCII editor. By default, the system looks for this file in the DefLib directory, however, you can specify a different path and file name as the second parameter. Here is an example:

;RULNestedOverFlowProc;;c:\fap\dll\newfile.dat;

OVERFLOW.DAT file format

The file format for the OVERFLOW.DAT file is as follows:

;LeadIMG;LeadMask;ListIMGInfo;ListMask;FollIMGInfo;

Parameter

Description

LeadIMG

The group header inserted by normal triggering rules or by a previous call to the NestedOverflowProc rule. The group header is the section name without the extension of the lead section.

LeadMask

The search mask that originally triggered the lead section, in this syntax:

Offset,Record

Offset is the offset into the extract file. Record is the specific search key.

ListIMGInfo

Information about the subordinate section that overflows beneath the group header section. The format is the same as is in the FORM.DAT file:

SecName|SecAtts<Recip1(CpyCnt),Recip2(CpyCnt),…>

SecName is the name of the section without the extension.

SecAtts are the attributes of the section (using the flags used in the FORM.DAT file such as D=data entry and print, S=same page, W=can grow, and so on.

RECIP1 is the recipient name.

CPYCNT is the recipient copy count.

Normally, you should set the attributes to DS. (D=data entry and print and S=same page). This information should not exceed 255 characters.

ListMask

(Optional) The search mask which triggers occurrences of the subordinate section beneath the group header section. Use this syntax:

Offset, Record

Where...

Offset is the offset into the extract file.

Record is the specific search key.

If you omit this parameter, only one section is inserted.

FollIMGInfo

(Optional) Information about the group footer section which, if specified, is inserted after the last subordinate section for the current group. The format is the same as is in the FORM.DAT file:

SecName|SecAtts<Recip1(CpyCnt),Recip2(CpyCnt),…>

SecName is the name of the section without the extension.

SecAtts are the attributes of the section (using the flags used in the FORM.DAT file such as D=data entry and print, S=same page, W=can grow, and so on.

RECIP1 is the recipient name.

CPYCNT is the recipient copy count.

Normally, you should set the attributes to DS. (D=data entry and print and S=same page). This information should not exceed 255 characters.

Before this rule is called, the lead section should already be in the form set—either through normal section triggering or by placing another call to this rule on a previous line.

The system begins by reading the OVERFLOW.DAT file line by line. The system finds the first occurrence of the lead section in the form set and then finds the first occurrence of the lead mask in the extract file.

It then counts the number of list masks between the first and second lead mask. Next, the system inserts the number of list sections after the first lead section and then inserts the follow section.

The system continues going through the form set inserting the number of list sections in between the nth and (n+1)th lead sections, according to the number of list masks in the extract file in between the (n)th and (n+1)th lead masks.

When it reaches the last lead section, the system counts the remaining list section masks after the last lead mask and inserts the appropriate number of list sections. Lastly, it inserts the following section, if specified.

Note The following section and the list masks are optional. If there is no list mask, only one list section will be inserted.

Example

This example shows how to generate list sections subordinate to lead sections. In this example Record1 is the lead mask, and Record2 is the list mask.

LeadImage is the lead section and ListImage is the list section. The rule would count three Record2s between the two Record1s. If Record1 is actually the fifth Record1 in the extract file for the current transaction, the system would find the fifth LeadImage in the form set and insert three ListImages after this LeadImage.

Also, there is only one recipient, Recip1.

.

.

.

000000001RECORD1 data1

000000001RECORD2 data2

000000001RECORD2 data3

000000001RECORD3 data4

000000001RECORD4 data5

000000001RECORD4 data6

000000001RECORD2 data7

000000001RECORD1 data8

. . . .

. . . .

. . . .

The example below shows the line in the overflow file. In the first example, the corresponding line in the overflow file for the previous example would appear as shown here:

;LEADIMAGE;10,RECORD1;LISTIMAGE|DS<RECIP1(1)>;10,RECORD2;;

The next example shows how to add a following section. If a following section was needed, the line from the file would look as shown here. Assume the following section is named FOLLOWIMAGE:

;LEADIMAGE;10,RECORD1;LISTIMAGE|DS<RECIP1(1)>;10,RECORD2;FOLLOWIMAGE|DS<RECIP1(1)>;

This following example shows how to add another recipient. If a second recipient (with copy count of 3) was specified for the list section but not for the following section, the line would appear as shown here. Assume the second recipient is Recip2:

;LEADIMAGE;10,RECORD1;LISTIMAGE|DS<RECIP1(1),RECIP2(3)>;10,RECORD2;FOLLOWIMAGE|DS<RECIP1(1)>;

This example shows how to change the section attributes. So far the section attributes were set as DS—data entry and print and same page. If the list section was dynamic, you must add the W (can grow) attribute. The line would now look as shown here:

;LEADIMAGE;10,RECORD1;LISTIMAGE|DSW<RECIP1(1),RECIP(2)>;10,RECORD2;FOLLOWIMAGE|DS<RECIP1(1)>;

The example also shows nested/recursive functionality by iteration because this rule builds upon previous lines. This lets you have unlimited amounts of overflow within overflow.

Here are some points to consider concerning insertion logic:

  • Reverse insertion logic when inserting different list sections after the same lead section.

Because of the nature of insertions, if two lines in the overflow file use the same lead section, the list section in the second line is inserted before the list section on the first line. This requires a sort of reverse logic when creating the overflow.

  • In order insertion below the lead section.

Consider two different sections 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);;

The sections 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 sections are not inserted in the order of list search masks in the extract file but in the reverse order of the occurrence of list sections 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.

See also

  • RunSetRcpTbl


RULStandardFieldProc

You must include this form set level rule in the AFGJOB.JDT file as the first field rule. This rule tells the system to process each field on all of the sections triggered by the SETRCPTB.DAT file.

Note This rule is used in multi-step processing. The StandardFieldProc rule is used in single-step processing.

Syntax

;RULStandardFieldProc;;;

There are no parameters for this rule.

Example

;RULStandardFieldProc;;;

See also

  • Using the Job Definition Table


RULStandardImageProc

You must include this form set level rule in the AFGJOB.JDT file as the first section rule. This rule tells the system to process each section triggered by the SETRCPTB.DAT file.

Note This rule is used in multi-step processing. The StandardImageProc rule is used in single-step processing.

Syntax

;RULStandardImageProc;;;

There are no parameters for this rule.

Example

;RULStandardImageProc;;;

See also

  • Using the Job Definition Table


RULStandardJobProc

You must include this rule as the first job level rule in the AFGJOB.JDT file.

Syntax

;RULStandardJobProc;;;

There are no parameters for this rule.

Example

;RULStandardJobProc;;;

See also

  • ServerJobProc


RULStandardTransactionProc

You must include this form set level rule in the AFGJOB.JDT file as the first transaction level rule. This rule tells the system to process each transaction listed in the extract file.

Note Do not use this rule if you are using single-step processing. You only use this rule if you are not using the NoGenTrnTransactionProc rule.

Syntax

;RULStandardTransactionProc;;;

There are no parameters for this rule.

Example

;RULStandardTransactionProc;;;

See also

  • Single-Step Processing
  • NoGenTrnTransactionProc


RULTestTransaction

Use this form set level debugging rule before the RULStandardTransactionProc rule to have the system look for an INI group like the one shown below and execute only the transactions specified there.

Syntax

;RULTestTransaction;;;

The numbers shown below are sequence numbers, not transaction IDs. If you define the Test control group, the system will skip any transaction number not specified in the control group.

< Test >

TransactionRecordNumber = 1 ; do transaction 1

TransactionRecordNumber = 5 ; and transaction 5

Example

;RULTestTransaction;;;

See also

  • RULStandardTransactionProc


RunSetRcpTbl

Use this form set level rule to run all entries in the set recipient table which pertain to the current GroupName1, GroupName2, and TransactionType to generate the form set for the current transaction.

Note You can use the LoadFormsetFromArchive rule to replace the BuildFormList, LoadRcpTbl, and RunSetRcpTbl rules in the AFGJOB.JDT file.

For more information on setting recipients and copy counts, see the Documaker Administration Guide.

Syntax

;RunSetRcpTbl;;;

Place this rule in the AFGJOB.JDT file, after the BuildFormList rule.

Example

;BuildFormList;;;

;RunSetRcpTbl;;;

This example tells the system to process the SETRCPTB.DAT file to determine which forms and sections it should include in the POLFILE.DAT file for each recipient.

See also

  • BuildFormList
  • LoadFormsetFromArchive
  • LoadRcpTbl
  • Using the Job Definition Table


RunTriggers

Use this form set level rule to replace the LoadRcpTbl and RunSetRcpTbl rules in implementations created by Documaker Studio.

Syntax

;RunTriggers;;;

There are no parameters for this rule.

Note This rule is only available if you are running Documaker Studio. If you do not use Documaker Studio, see ProcessTriggers.

The RunTriggers rule represents an improved triggering process tailored for the file structure implemented with Documaker Studio. This process removes some of the complexity and improves performance.

For instance, in the old triggering process, if your form trigger asked for three copies of a form and then you processed the section triggers, only the last copy of the form was affected by the section triggers. The first two copies, would have been static based upon the default section configuration in the FORM.DAT file. Using the RunTriggers rule, each copy of the form will process section triggers. This means each form can differ from the prior one — assuming your section triggers check unique information to achieve that goal.

See also

  • LoadRcpTbl
  • RunSetRcpTbl
  • ProcessTriggers


RunUser

Use this job level rule to execute a user function. You can use this rule to run a user function such as GetRecsUsed, IncRecsUsed, or ResetRecsUsed, to manipulate an overflow variable. This rule lets you manipulate an overflow variable without immediately making use of it in a field mapping.

Syntax

;RunUser;;;

Example

Overflow variables are variables you can use when a rule is searching an extract record using a search mask. You can use the overflow variable to vary the occurrence of the record you are searching for.

Typically, the AFGJOB.JDT file contains this rule:

;ResetOvFlw;;;

which resets all overflow variables to zero at the beginning of each transaction. The RunUser rule lets you reset to zero at any time during field processing by running the ResetRecsUsed user function via the RunUser rule.

See also

  • ResetOvFlw


ServerFilterFormRecipient

Use this form set level rule with the DPSPrint object in IDS to generate a print file that contains a set of forms which will be filtered by

  • Form name
  • Form description
  • Recipient name

Syntax

;ServerFilterFormRecipient;;;

The following attachment variables are created if these properties of the DPSPrint object are not null, in other words...

  • 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

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


ServerJobProc

Use this job level rule when you use the Internet Document Server (IDS) to run Documaker. This rule replaces the RULStandardJobProc rule.

Note You must have a license to both IDS and Documaker to use this rule. For more information on setting up IDS and Documaker, see the Internet Document Server Guide.

Syntax

;ServerJobProc;;;

Insert this rule in the AFGJOB.JDT file as the first rule.

This rule looks for a job ticket file in the current working directory and loads it as an XML file. All of the values on the XML tree are added to or updated in the INI options. After Documaker finishes processing, the rule checks the status. If there are errors, it returns a no more bases return code on the next iteration. This terminates Documaker.

This rule uses a polling technique—sleep a while and check for the file existence— which you can configure using INI options. The rule loads the job ticket and sets INI options used when running subsequent rules. On the post message, this rule creates a job log XML tree and writes it to disk. If any necessary values are missing from the XML job ticket, these values are generated and changed (or appended) in the INI context.

On RP_PRE_PROC_B, this rule creates a semaphore (gendata), which makes it possible for the IDS RPDCheckRPRun rule to detect the status of Documaker when the next processing job starts.

This rule stays in waiting status and checks for the existence of job ticket file (JOBTICKET.XML) and the rpdrunrp semaphore. As soon as the job ticket file is detected, this rule loads it onto the XML tree and uses the contents of the XML tree to update INI options in memory.

If the rule does not detect the rpdrunrp semaphore, the rule terminates Documaker by returning a msgNO_MORE_BASES return code. It also creates a GVM variable (DSISERV) so the CUSInitPrint rule can re-initialize printers after the job process is complete. This GVM variable can be used by any of the Documaker rules to detect if the Documaker is running under IDS, if different logic is needed.

On RP_POST_PROC_B, the rule writes out the job log file and removes the job ticket file. If the RULServerJobPRoc option is set to Yes, a copy of the file will be obtained for debugging purposes.

INI options

< Data >

DataPath =

ExtrFile =

MsgFile =

ErrFile =

LogFile =

DBLogFile =

NAFile =

POLFile =

NewTrn =

< PrinterInfo >

Printer =

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

See also

  • RULStandardJobProc


SetErrHdr

Use this job level rule to define the header information used in the error file if an error occurs during the processing of a transaction. You can use any global variable (GVM) in the text defined to the system.

Syntax

;SetErrHdr;;Token:Text;

Parameter | Description
Token | A string of characters used to denote the beginning and end of a global variable name. Use a colon (:) to terminate the token string of characters. To substitute a global variable into the text, surround the name of the global variable with the token string. Be sure to use a string of unique characters for the token that are not defined in the text. For example, you could use '***'. You cannot use a colon (:) in the TOKEN string.
Text | A text string. The text string may include embedded tokens and global variables. Do not start the text string with a colon (:).
Note Use a colon (:) to separate the token from the text. You must use a token even if there are no embedded global variables in the text string.

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.


SetOutputFromExtrFile

Use this form set level rule to extract a print batch name from an extract file for each transaction. This capability is typically used with the MultiFilePrint callback function so you can get a print batch name from the extract file for one or more recipients per transaction.

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, GenData, and GenPrint)

When processing using the GenTran, GenData, and GenPrint programs, you must set 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.

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 processing without the PrinfFormset rule and with GenPrint)

When you use single-step processing but omit the PrintFormset rule and instead use the GenPrint program, you must include the Print control group options:

< Print >

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.

Single-step (GenData only)

When you use single-step processing, the system does not use a callback function. 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.

See also

  • Single-Step Processing
  • BatchingByRecipINI
  • IfRecipUsed
  • WriteNAFile
  • WriteOutput
  • WriteRCBFiles
  • WriteRCBWithPageCount


SetOverflowPaperTray

Use this form set level rule with the FormName INI option to change the printer tray selection during transaction processing.

This rule lets you print the first page of a form set on a special paper and the rest on different stock. For example, the first page of a utility bill is typically printed on perforated stock while the rest of the bill is printed on non-perforated stock.

Syntax

;SetOverflowPaperTray;;

There are no parameters for this rule.

The FormName option is required:

< OverflowPaperTray >

FormName = Tray#

Option | Description
FormName | Enter the name of the form on the left and the tray you want used for the subsequent pages on the right. To specify the tray, you can only enter trays 1-9. See the example below.

Here is an example:

< OverflowPaperTray >

Gas Bills = Tray4

Water Bills = Tray4

Elec Bills = Tray4

Keep in mind...

  • You must include the PaginateAndPropagate rule in your AFGJOB.JDT file for the SetOverflowPaperTray rule to work correctly.
  • When running in single- or two-step mode, place these rules in this order after the WriteOutput and WriteNAFile rules:.

; SetOverflowPaperTray;;

;PaginateAndPropagate;;

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.
  • 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 sections, 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)>;

POLFILE.DAT file:

;RP10;CIS;UtilBill;Utility;R;;\

billhdrp|FDLONX <Customer>/\ page 1 - from Lower/tray 2 (L)

billsum |RDLSN <Customer>/\

billftr |RDLSN <Customer>/\

billhdrp|RDLONX <Customer>/\ page 2 - from Lower/tray 2 (L)

billrwtr|RDLSN <Customer>/\

billsere|RDLS <Customer>/\

billstbr|RDLSN <Customer>/\

billhdrp|RD4ONX <Customer>/\ page 3 - from tray 4 (4)

billrswr|RDLSN <Customer>/\

billcwt3|RDLSN <Customer>/\

billhdrp|RD4ONX <Customer>/\ page 4 - from tray 4 (4)

blchart |RDLS <Customer>;

\ENDDOCSET\ BillHead

Here is a simplex printing example:

Assume your FORM.DAT file specifies simplex printing, lower/tray 2 for all sections, 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:

;RP10;CIS;InsurBill;NW Company;N;;\

insuhdr |DLONX <Customer(1)>/\

insuintr|DLS <Customer(1)>/\

insurate|DLOS <Customer(1)>/\

insusign|DLS <Customer(1)>;

POLFILE.DAT file:

;RP10;CIS;InsurBill;NW Company;R;;\

insuhdr |FDLONX <Customer>/\ page 1 - from Lower/tray 2 (L)

insuintr|DLS <Customer>/\

insurate|DLOS <Customer>/\

insuhdr |FD4ONX <Customer>/\ page 2 - from tray 4 (4)

insurate|DLOS <Customer>/\

insuhdr |FD4ONX <Customer>/\ page 3 - from tray 4 (4)

insusign|DLS <Customer>/\

\ENDDOCSET\ InsurHead

See also

  • PaginateAndPropagate
  • WriteNAFile
  • WriteOutput


SetOvFlwSym

Use this job level rule to define an overflow variable for the overflow feature for use by the various field level rules using overflow. This rule adds the specified overflow variable to the overflow symbols list. You must use the InitOvFlw rule before you use this rule.

Syntax

;SetOvFlwSym;;OverflowSymbol, SectionName, MaxRecords;

Parameter | Description
OverflowSymbol | Name of the overflow symbol defined in the SetOvFlwSym rule.
SectionName | Name of the section that contains the fields on which overflow processing will occur.
MaxRecords | Defines the maximum number of overflow records to be processed for the section per page of output.

Example

;SetOvFlwSym;;Symbol,SectionName,10;

This example tells the system to define an overflow variable named Symbol for use with the section named SectionName, 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 section set to five.

See also

  • WriteOutput
  • InitOvFlw
  • ResetOvFlw
  • IncOvSym
  • OvActPrint
  • OvPrint
  • SetOvFlwSym


SetRecipCopyCount

Use this form set level rule in the AFGJOB.JDT file to set the number of copies for a particular recipient for all forms except those specified.

Syntax

;SetRecipCopyCount;;;

This rule includes these parameters:

;RULE;LEVEL;RECIPIENT,COPYCOUNT,FORM1,FORM2,...FORMn;

Where FORM1, FORM2, and FORMn are the names of the forms to exclude from the copy count you specify using this rule.

Note This rule tests to see if the parameter value is a constant number. If not, it assumes the parameter names a GVM variable. It then uses the GVM variable to get the copy count.

Example

;SetRecipCopyCount;;IO,,DOC016,DOC018;

;SetRecipCopyCount;;I,3,DOCERR;

See also

  • SetRecipCopyCount2


SetRecipCopyCount2

Use this form set level rule in the AFGJOB.JDT file to set the copy count for a particular recipient for all forms specified.

Note Version 10.1, Patch 109 changes the way the SetRecipCopyCount2 rule handles copy counts. Before this patch, the rule excluded the forms specified in the rule's parameters. With this patch and in subsequent versions, this rule includes those forms and changes the forms' copy counts.

Syntax

;SetRecipCopyCount2;;(parameters);

Parameter | Description
Recipient | Enter the name of the recipient for whom the copy count will be set.
Number | Enter the number you want to set the copy count to.
Name | Enter the name of the forms for which the copy count should be set. If you have multiple forms, separate each name with a comma.

You must place this rule after the BuildFormList rule in the AFGJOB.JDT file.

Note This rule tests to see if the parameter value is a constant number. If not, it assumes the parameter names a GVM variable. It then uses the GVM variable to get the copy count.

Example

;SetRecipCopyCount2;;Customer,2,QADesc1,QADesc2,QADesc3;

The copy count for recipient, Customer, is set to two (2) for forms: QADesc1, QADesc2, and QADesc3.

< Base Rules >

;RULStandardJobProc;;;

…

…

<Base Form Set Rules>

;RulStandardTransactionProc;;;

…

…

;BuildFormList;;;

;SetRecipCopyCount2;;CUSTOMER,2,Patch399;

…

…

See also

  • SetRecipCopyCount


SortBatches

Use this job level rule to sort RCB batches before they are printed. This rule provides a way for you to call an external sort program to rearrange the order of the recipient batch files (RCB files).

Note The SortBatches rule is not available for z/OS implementations.

Syntax

;SortBatches;;;

The SortBatches rule provides two ways to sort batches:

  • Sorting with a 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.

  • Sorting with Multiple Keys

Use this method when you need to create a sort command with a repeating pattern for each sort field.

Note Sorting with multiple keys is not available for the Windows platform.

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.


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

OTSort by OptTech is a third-party sort utility. Here is an example of how you could set the SortCommand options to execute OTSort with the SortBatches rule:

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

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:

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

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

...


StandardFieldProc

You must include this form set level rule in the AFGJOB.JDT file if you are running in single-step mode. The StandardFieldProc rule should be the first field level rule in your AFGJOB.JDT file.

This rule tells the system to process each field on all of the sections triggered by the SETRCPTB.DAT file.

Note

  • If you use StandardFieldProc in your AFGJOB.JDT file, you must also include the WriteNAFile rule.
  • This rule is used in Single-Step Processing. TheRULStandardFieldProc 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;;;

See also

  • WriteNAFile


StandardImageProc

This rule is a form set level rule which you must include in the AFGJOB.JDT file. This rule is used when you are using running in single-step mode and should be the first section level rule.

This rule tells the system to process each section triggered by the SETRCPTB.DAT file.

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 section. If there are no more sections, 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 section, the rule checks to see if the section has a corresponding DDT file and, if so, loads into memory the section and field rules included in that file.

Example

;StandardImageProc;;;


TicketJobProc

Use this job level rule to run Documaker Server from another application by providing an XML job ticket. The results are returned in an XML job log file. The layout of these XML files is the same as those used by Docupresentment to run Documaker.

Specify the name of the job ticket to the GenData program on the command line using this parameter:

/jticket=

The default is JOBTICKET.XML. To prevent the job ticket file from being removed once the system finishes processing, include this INI option:

< Debug >

TicketJobProc = Yes

Specify the name of the resulting job log file using this command line parameter:

/jlog=

The default is JOBLOG.XML.

Syntax

;TicketJobProc;;;

There are no parameters for this rule. You must include this rule as the first job level rule in the AFGJOB.JDT file. This rule replaces the RULStandardJobProc rule.

Note Documaker must be set up in single step mode. Only the GenData program is executed.

For a single-transaction job process, you receive recipient information if you have this option set:

< PrintFormset >

MultiFilePrint = No

Example

;TicketJobProc;;;

See also

  • RULStandardJobProc


TranslateErrors

Use this rule to extract error information from the message file and translate it into an error file using the message INI file, named TRANSLAT.INI, with group standard as the translation key. The system reads errors from the MSGFILE.DAT file, translates them, and places the translated error messages in the ERRFILE.DAT file.

Note Using this rule can slow processing by creating additional tasks for the system to perform at the end of the processing cycle.

Syntax

;TranslateErrors;;;

Example

;TranslateErrors;;;


UpdatePOLFile

Use this form set level rule to write the names of the forms to the POLFILE.DAT file. This list of forms, and the sections that comprise those forms, is sometimes called the POL set.

Note

  • Do not use this rule when you are doing 2-up printing on AFP printers. In that situation, you use the PaginateAndPropagate and WriteOutput rules instead.
  • Do not use this rule when you use the GenData program by itself to execute the GenTrn, GenData, and GenPrint steps.

Syntax

;UpdatePOLFile;;;

This rule writes the POL set to the POLFILE.DAT file, deletes the duplicate form set, updates the TRN file, and updates the recipients.

Example

;UpdatePOLFile;;;

See also

  • Rules Used for 2-up Printing


UseXMLExtract

Use this form set level rule when the extract list loaded by the transaction is also the source of the XML tree.

Note

The extract list and the XML tree are separate items. Even if you are only using an XML file as the source of the transaction, there will be two copies of the information in memory — one as the extract list and one as the XML tree.

If you are running Documaker from IDS, use the ImportXMLExtract rule to bring in XML in standard Documaker XML format, such as from Documaker workstation or iDocumaker. Use the UseXMLExtract rule to convert a loaded extract file into an XML tree, which you can then use to query data.

Syntax

;UseXMLExtract;;

Each XML transaction must begin with the XML declaration. The system assumes each transaction is a separate entity and requires that each transaction begin with an XML declaration.

Keep in mind that you will not be able to load this appended file as one large XML file. The system does not load the entire file before it processes the first transaction. Instead, it loads one transaction and then processes that transaction. Make sure there are line feeds between transactions. The line feed requirement is not an XML issue, but rather tells the system where one transaction ends and the next begins.

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

;UseXMLExtract;;;

For single or two-step mode, place the XMLFileExtract rule after the NoGenTrnTransactionProc rule, as shown here:

;NoGenTrnTransactionProc;;

;UseXMLExtract;;;

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.

Use these INI options with this rule:

  • In the TRN_File control group, set the MaxExRecLen option to the optimal read size for your system. If you set this too large, it will consume too many resources. If you set it too small, it will perform too many reads. Check with your system administrator for guidance on setting this option.

< TRN_File >

MaxExRecLen =

  • In the Data control group, make sure the ExtrFile option points to the location of your XML file. Here is an example:

< Data >

ExtrFile = .\extract\Sample.xml

  • In the ExtractKeyField control group, set the SearchMask option as shown here:

< ExtractKeyField >

SearchMask = 1,<?xml

  • In the RunMode control group, include the XMLExtract option as shown here:

< RunMode >

XMLExtract = Yes

  • 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

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 section for which you created the overflow symbol.

Also, remember to include the IncOvSym rules at the section level to increment the values to the next index. When doing overflow within overflow, you may also have to include an additional dummy section to do the IncOvSym for the symbol that represents the outer-most loop index.

See also

  • Ext2GVM
  • LoadExtractData
  • IncOvSym
  • XMLFileExtract


WIPFieldProc

Use this form set level rule in place of the RULStandardFieldProc or StandardFieldProc rule in the AFGJOB.JDT file when you are using GenData WIP Transactions Processing. Using this rule tells the GenData program to bypass normal field processing.

Note You cannot include in the AFGJOB.JDT file this rule and the RULStandardFieldProc or StandardFieldProc rule.

These other rules are also used when you run WIP Transaction Processing:

  • 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;;;

See also

  • GenData WIP Transaction Processing


WIPImageProc

Use this form set level rule in place of the RULStandardImageProc or StandardImageProc rule in the AFGJOB.JDT file when you are using GenData WIP transactions processing. Using this rule tells the GenData program to bypass normal section processing.

Note You cannot include in the AFGJOB.JDT file this rule and the RULStandardImageProc or StandardImageProc rule.

These other rules are also used when you run WIP Transaction Processing:

  • 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;;;

See also

  • GenData WIP Transaction Processing


WIPTransactions

Use this form set level rule to process WIP transactions (manually approved or rejected in Documaker Workstation) in place of the RULStandardTransactionProc or NoGenTrnTransactionProc rules.

This rule processes WIP transactions and places them into batch files for GenPrint and GenArc processing. To specify which transactions, you use codes which you define in the Status_CD control group. If a WIP transaction has a status code that is not among the list of codes to be processed, the system deletes the transaction and WIP file.

The parameters for this rule are the status codes for which the user needs to process WIP transactions. The codes are located in the Status_CD control group. If you are using more than one status code, separate the codes with commas, as shown here:

Approved,Accepted

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;

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.

See also

  • GenData WIP Transaction Processing
  • Changing the WIP Status


WriteNAFile

Use this form set level rule to append the NAFILE.DAT file data records for the current form set into an existing NAFILE.DAT file.

When you use the NoGenTrnTransactionProc rule, which replaces the RULStandardProc rule in the performance JDT, you must include the WriteNAFile rule to write the data (records) to the NAFILE during the GenData step.

In addition, you must also include the WriteOutput rule to write the data (records) to the POLFILE.DAT and NEWTRN.DAT files during the GenData step.

Syntax

;WriteNAFile;;;

There are no parameters for this rule.

Example

;WriteNAFile;;;

If an error occurs, the system returns this message:

Error in WriteNaFile: Unable to PurgeOutput(pRPS).

See also

  • SetOutputFromExtrFile
  • NoGenTrnTransactionProc
  • Single-Step Processing


WriteOutput

Use this form set level rule to create the POL file when executing single and two-step processing.

You also use this rule when you are using the GenData program by itself to execute the GenTrn, GenData, and GenPrint processing steps.

Syntax

;WriteOutput;;;

Note If you use this rule, do not use the UpdatePOLFile rule.

Example

;WriteOutput;;;

See also

  • Rules Used for 2-up Printing
  • SetOutputFromExtrFile
  • Single-Step Processing


WriteRCBFiles

Use this form set level rule to create the recipient batches when running in two-step mode. This mode is similar to single-step processing but omits the PrintFormset rule and instead uses the GenPrint program.

Note Studio includes the WriteRCBFiles rule in the default AFGJOB.JDT file that Test manager produces.

Syntax

;WriteRCBFiles;;;

There are no parameters for this rule.

Example

;WriteRCBFiles;;;

Here is an example of a AFGJOB.JDT file you could 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 and WriteNAFile rules.

See also

  • SetOutputFromExtrFile
  • WriteNAFile
  • WriteOutput


WriteRCBWithPageCount

Use this form set level rule to write the page count for each recipient. This rule is typically use for handling 2-up printing on AFP and compatible printers. This rule is also used for multi-mail processing.

Syntax

;WriteRCBWithPageCount;;;

There are no parameters for this rule.

You must include the following data in your RCBDFDFL.DFD file when you use this rule:

< Fields >

....

....

FieldName = CurPage

FieldName = TotPage

FieldName = AccumPage

......

......

< FIELD:CurPage >

INT_Type = LONG

EXT_Type = CHAR_ARRAY_NO_NULL_TERM

EXT_Length = 10

Key = N

Required = N

< FIELD:TotPage >

INT_Type = LONG

EXT_Type = CHAR_ARRAY_NO_NULL_TERM

EXT_Length = 10

Key = N

Required = N

< FIELD:AccumPage >

INT_Type = LONG

EXT_Type = CHAR_ARRAY_NO_NULL_TERM

EXT_Length = 10

Key = N

Required = N

Example

;WriteRCBWithPageCount;;;

This rule gets a pointer to the global variable NA_Offset. If the pointer is NULL, the system returns this message to the error file:

Error in WriteRCBWithPageCount: RCB field NA_Offset not found.

The rule then assigns the pointer it retrieved to the pRPS->POL_Offset and gets a handle to the print batch list. It then loops through this list to free the contents of the corresponding PRINT_BATCH structure if that print batch has been assigned a recipient.

The rule then checks the handle to the counter list. This handle is a global handle created by the PageBatchStage1InitTerm rule. If the handle is equal to VMMNULLHANDLE, the system returns this message to the error file:

Error in WriteRCBWithPageCount: PageBatchStage1InitTerm has not been called

The rule then checks the handle to the list of transaction records for the current batch. This handle is a global handle also created by the PageBatchStage1InitTerm rule. If this handle is equal to VMMNULLHANDLE, the system returns this message to the error file:

Error in WriteRCBWithPageCount: PageBatchStage1InitTerm has not been called

The rule then sets recipient page counts. If an error occurs, the system returns this message to the error file:

Error in WriteRCBWithPageCount:Failed to set recipient page counts

Next, the rule gets the handle of the global recipient list for the current form set and loops through the recipient list to add page counts to the GVM. The rule also gets the pointer to global variable TotPage. If this pointer is NULL, the system returns this message to the error file:

Error in WriteRCBWithPageCount: RCB field TotPage not found

Then rule then gets the handle to the print batch and recipient lists and loops through these lists. Finally, the rule loops through the list of page counts. If it cannot get the handle to the given page count, the system returns this message to the error file:

Error in WriteRCBWithPageCount: Cannot locate batch <Batch Name>.

See also

  • Rules Used for 2-up Printing
  • BatchByPageCount
  • BatchingByPageCountINI
  • PageBatchStage1InitTerm
  • SetOutputFromExtrFile


XMLFileExtract

Use this form set level rule when the extract list loaded by the transaction contains the name of an external file source for the XML tree.

Note The extract list and the XML tree are separate items. Even if you are only using an XML file as the source of the transaction, there will be two copies of the information in memory — one as the extract list and one as the XML tree.

Syntax

;XMLFileExtract;;parameter;

For the parameter, you can use one of the following:

  • FILE=<filename>

Where filename is the name of the XML file, including path information.

  • INI=group,option

Where group and option are defined in the INI files

  • SCH=offsetofmask,<searchmask> offsetofdata,lengthofdata
Parameter | Description
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;

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

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


Adding Section and Field Rules

This section discusses adding section and field level rules. These rules link the section's variable fields to external data.

Note You create variable fields using Documaker Studio. For more information, see the Documaker Studio User Guide.

The section and field level rules are executed during data generation and merger procedures. This occurs in Documaker Server.

In this section you will find information about:

  • Storing Rule Information
  • Formatting Data
  • Search Criteria
  • Overflow and User Functions

For reference information on individual rules, see Section Rules Summary and Section Rules Summary.


Storing Rule Information

Documaker Studio stores sections in a FAP file, along with the section and field rule assignments you assign to it. This differs from the way rule information was stored using the older document creation tool, Image Editor.

Image Editor stored sections in a FAP file which only contain the section’s objects and object attributes. The Image Editor stored section and field rule assignments in a separate file, called a data definition table (DDT) file. While DDT files originally offered high performance, advanced formatting needs made it necessary for the FAP files to be available at runtime to handle dynamic composition.

With the release of version 11.0 and the introduction of Documaker Studio’s FOR file, section and field-level rules previously stored in the DDT file are, in Studio implementations, either unnecessary or are stored in the FAP file. Having section 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 issues.

Note With the release of version 12.0, support for Image Editor and other legacy development tools ended.


Formatting Data

The system provides several ways to format dates and numbers using the FmtDate, RunDate, SysDate, DateFmt, and FmtNum rules. The system includes several pre-defined formats from which you can choose and you can set up format arguments to handle any special needs.

The topics in this section explain your options.

Note TheDateFmt rule accepts a mask which includes an input and an output format.


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 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 (/).

This example shows the date format as it looks in the FAP file. The easiest way to enter date formats is through Studio, on the field’s Properties window.

Studio will then create the date format in the FAP file for you.

When you choose Date Format as the type, you can choose from this list of date formats. The table also shows the corresponding date format code Studio creates in the FAP file:

In the Format field, select this format | To see this code in the FAP file | To get dates formatted as shown below (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 |
YY/M/D | 7 | 13/1/2
bM/bD/YY | 8 |
bD/bM/YY | 9 |
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
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 (use only if the year is in current century) | 2 (a “2” appears in the FAP file)
Only a two-digit year such as 01/01/13 (if you enter anything other than a two-digit year, you will receive an error) | 3 (a “3” appears in the FAP file)
A four-digit year such as 01/01/2013 | 4 (a “4” appears in the FAP file)
Only a four-digit year such as 01/01/2013 (if you enter anything other than a four-digit year, you will receive an error) | 5 (a “5” appears in the FAP file)
The year as entered without changing it | Default (a blank space appears in the FAP file)

2-digit years

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.

Century cut-off dates

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:

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 field’s Properties window in Studio.

When you choose the format in Studio, the system lets you choose from a list of examples, such as:

+$ZZZZZZZZZ9.99

$$ZZ,ZZZ,ZZZ,ZZZ

$ZZZZZZZZZ9.99CR

$*ZZZZZZZZZZZ.ZZ

Suppressing decimals with the FmtNum Rule

The FmtNum rule can use a pre-defined numeric format to suppress decimals. The 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
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 option with the FmtNum Rule

Use the ZeroText option to insert text you define instead of the zero value, if the result is zero.

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

Inputting Information

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.

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
 | 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 Studio, enter this information in the Locale field on the field’s Properties window. 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:

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

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.

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

=()

This retrieves the contents of a DAL variable that is, by default, the root name of the source name of the current field. For example, assume, the current 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.


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 section and field rules use calls to GetRecord, search criteria is often needed wholly or as part of the data field.

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.


Overflow and User Functions

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 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. 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 with the field level rules. You must define all overflow symbols using the SetOvFlwSym rule, which is a job level rule stored in the AFGJOB.JDT file.

The second part is the name of a form, which is retrieved from the form file (FOR) specified in the INI file.

The third part is the overflow symbol itself.

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 (/).

Here is an example:

@GETRECSUSED,DETAILS,Symbolnm/11,DETAILREC;N;N;N;


Section Rules Reference

Section rules help you control how data is processed and generated to fill a field on a form.

Note This section serves as a reference to the section rules. For information on the rules which apply to fields, see Field Rules Reference. For information on the rules which apply to jobs and form sets, see Adding Job and Form Set Rules.

This section discusses rules included in the base system and supported by the Oracle Documaker support staff. For information on custom rules, contact your Services representative.

For a summary of these rules, see Section Rules Summary.


Section Rules Summary

The following pages list and explain the various section rules you can use. The rules are discussed in alphabetical order on the pages following this table.

You can also see information about the section rules while using Studio when you select the rule on the Rule Properties window:

The following table lists the rules discussed in this section.

To… | Use this rule | AFGJOB | Files | INI | Overflow
Add a page break before the system begins processing the current section | PaginateBeforeThisImage | no | no | no | na
Add PDF or TIFF files as bitmap images | AddMultiPageBitmap | no | yes | yes | na
Add sections to the current form set based on conditions in the SETRCPTB.DAT file | SetRecipFromImage | no | yes | no | na
Add TIFF images contained in a single TIFF file to a form set | * AddMultiPageTIFF | no | yes | yes | na
Allow a chart’s series data to be retrieved via reference to variable fields defined on the same section | FieldVarsToChartSeries | no | no | no | na
Check to see if the FAP file is loaded, and if not, load the FAP file | * CheckImageLoaded | no | yes | yes | na
Create a GVM variable from fields in a section | Field2GVM | no | no | no | na
Create a temporary extract list which contains similar records in a transaction | CreateSubExtractList | no | no | no | na
Create custom axis labels for a chart | SetCustChartAxisLabels | no | no | no | na
Define the first section in a group of sections | GroupBegin | no | no | no | yes
Define the last section in a group of sections | GroupEnd | no | no | no | yes
Delete a page from a form set | DontPrintAlone | no | no | no | na
Delete a specific occurrence of a section | DelImageOccur | yes | no | no | na
Execute a DAL script | PostImageDAL | yes | yes | no | na
Execute a DAL script | PreImageDAL | yes | yes | no | na
Get data from extract records and include it as series data in a chart | CreateChartSeries | no | yes | no | na
Identify the segments of sections that can be dynamically split. | CanSplitImage | yes | no | no | na
Increment an overflow variable (AFGJOB is used in legacy implementations) | IncOvSym | no | no | no | yes
Merge data for embedded variable fields in a text area with text | * TextMergeParagraph | no | no | yes | na
Move and align field text so the data elements are connected. | ConnectFields | no | no | no | na
Move sections from the current page to a page you specify | MoveMeToPage | yes | no | no | na
Remove a series from a chart if the series contains no data | PurgeChartSeries | no | no | no | na
Remove series data from the series you specify | DeleteDefaultSeriesData | no | no | no | na
Remove the white space from between fields (works with XML input) | RemoveWhiteSpace | no | no | no | na
Reset an overflow variable | ResetOvSym | yes | no | no | yes
Reset section dimensions | ResetImageDimensions | no | no | yes | na
Set group options | SetGroupOptions | no | no | no | yes
Set the dimensions of a section | * SetImageDimensions | no | no | no | na
Set the section overlay/page segment X and Y coordinates using FAP units | SetOrigin | no | no | no | na
Set the section overlay/page segment X and Y coordinates using inches | SetOriginI | no | no | no | na
Set the section overlay/page segment X and Y coordinates using millimeters | SetOriginM | no | no | no | na
Set the send copy to variable | SetCpyTo | no | no | no | na
Span a field’s width between two other fields, filling in with a fill character | SpanAndFill | no | no | no | na
* - Indicates this is a legacy rule that may be found in older implementations. INI - Indicates if there are INI options associated with this rule. AFGJOB - Indicates if there are AFGJOB.JDT file implications to this rule. Files - Indicates if external supporting files (other than extract records) can be used with this rule. Overflow - Indicates if this rule supports overflow. XML - Indicates if this rule accepts XML input.


AddMultiPageBitmap

Use this section level rule to import files as bitmap images. If the file consists of multiple pages, the system inserts the first page on the triggering form or section. For each subsequent page in the file, the system generates additional pages and appends them to the form after the triggering section.

See Using the Type Option for information on importing specific file types.

Note When you use this rule with TIFF files, it performs the same task and works just like the AddMultiPageTIFF rule. The first TIFF in the file is inserted on the triggering form/section. Subsequent TIFF images trigger additional pages which are appended to the form after the page which contains the first TIFF image.

Syntax

AddMultiPageBitmap (Options)

For the Options parameter, this table describes your choices:

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 usable file name is used.

Make this option the first rule parameter.

Use one of the following options (DAL, File, GVM, or SRCH) to specify the file name.

File(file name)

Enter the name and path of the file you want to import.

See Using the File Option for more information.

DAL(script name)

Enter the name of the DAL script you want to execute to return the name of the file you want to import. You must enter the name of a script file or DAL library routine. Do not include DAL statements.

See Using the DAL Option for more information.

SRCH(search criteria name data)

The name and path of the file you want to import is contained in a record in the file specified by the ExtrFile option in the Data control group.

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.

See Using the SRCH Option for more information.

GVM(variable name)

Enter the GVM variable name that contains the name and path of the file you want to import. The GVM variable data is mapped by some other means before this rule is executed.

See Using the GVM Option for more information.

Embed

(Optional) If you are importing TIFF or PDF files, include Embed to add the image data into the NA file. This is necessary when the file that contains the scanned images is temporary and you need to archive the NA/POL information. Upon retrieval, if you have not embedded the bitmap information directly into the form set, you will not be able to view or reprint the original images. The default is No.

Keep in mind that embedding bitmap data can make the resulting NA file much larger and also affects the size of the archives generated.

The Embed option is automatically set for files that are not in TIFF or PDF format.

Only (Odd or Even)

(Optional) By default, all images in the file are included. Only 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.

The default is position 0,0 within the image.

MM(top,left)

(Optional) Specifies the coordinate for the top-left corner of the bitmaps, in millimeters.

The default is position 0,0 within the image.

Top(top,left)

(Optional) Specifies the coordinate for the top-left corner of the bitmaps, in FAP units (2400 per inch).

The default is position 0,0 within the image.

Type

Optional) If you are importing TIFF or PDF files, 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. If the system cannot find a TIFF or PDF file, it attempts to automatically detect the file type. Including this option will speed processing.

You can also include this option if the target directory contains both TIFF and PDF files. For instance, if the directory contains import1.tif and import1.pdf, the TIFF file is included by default. If you want to include the PDF file, use the Type option.

See Using the Type Option for more information.

Scale(height[in|mm],width[in|mm])

(Optional) Use this option to resize the loaded graphics while maintaining the aspect ratio (height to width), so the graphic fits within the provided height and width dimensions.

If you only provide the height or width, the system sizes the graphic to fit that dimension and automatically calculates the other dimension to preserve the aspect ratio.

See Using the Scale Option for more information.

Crop(height[in|mm],width[in|mm])

(Optional) Use this option to remove all parts of the graphic that extend beyond the specified distances from the top left corner. If you omit one of the arguments, the graphic is not modified in that dimension.

See Using the Crop Option for more information.

Keep in mind:

  • In z/OS environments, you can import TIFF files or import only the bitmap data contained in PDF files. Under z/OS, this rule imports the bitmaps contained in the PDF file, puts them at the position you specified with the position options (IN, MM, or TOP) and scales them to fit the page.

Importing bitmap data from inside PDF files is useful because some fax drivers take TIFF data and place it inside a PDF file. Therefore, by reading the bitmap data from the PDF file, you are importing all the valuable information in that file.

  • You can specify several AddMultiPageBitmap rules, but realize that each subsequent rule reuses the document pages added by previous rules.

For instance, suppose you have declared two rules. The first has a 4-page file. The second has a 5-page file.

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

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

  • Use the following options to set the resolutions at which files are imported.

< BitmapLoaders >

PDFImportDPI =

WMFImportDPI =

VectorGraphicImportDPI =

Option | Description
PDFImportDPI | Enter the resolution in dots per inch (DPI) at which you want to import PDF files. The default is 100 DPI.
WMFImportDPI | (Optional) Enter the DPI (dots per inch) at which you want to import raster graphics. The default is 100. The maximum DPI is 2400.
VectorGraphicImportDPI | (Optional) Enter the DPI (dots per inch) at which you want to import vector graphics. The default is 100. The maximum DPI is 2400.
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.

Setting the OPT option

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.

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

Note Remember 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 file 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.


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 PDF files to the form set. Each image in the PDF file causes a duplicate of the original FAP file 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.


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


Using the Type Option

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.

The system also automatically detects and imports the following file types:

Description | Extension
Adobe Flash 6.x and 7.x “text only” | .SWF
Adobe Photoshop | .PSD
Adobe Postscript (PS) | .PS
CCITT Group 3 Fax | .FAX
CompuServe Graphic Interchange Format | .GIF
Encapsulated PostScript | .EPS
Extensible Markup Language | .XML
HP Graphics Language | .HPG
Hypertext Markup Language | .HTM, .HTML
Microsoft Excel | .XLS
Microsoft Outlook Messages | .MSG
Microsoft Powerpoint | .PPT
Microsoft Word | .DOC
MIME-encoded email | .EML
OS/2 and Windows bitmap, cursor, and icon files | .BMP
Paintbrush | .DCX .PCX
Portable Bitmap/Graymap/Pixmap | .PBM, .PGM, .PPM
Portable Network Graphics | .PNG
Rich Text Format | .RTF
Text, including ANSI, UTF-8, and EBCDIC | .TXT
Windows Enhanced Metafile | .EMF
Windows Metafile | .WMF
X-Windows Pixmap | .XPM
The level of support varies from format to format.

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:

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. The full list of supported formats is not yet available on Windows 64-bit systems or on z/OS. On AIX and HPUX, you must have an X Window System available.


Using the Scale Option

The Scale option resizes the loaded graphics, maintaining the aspect ratio (height to width), so the graphic fits within the provided height and width dimensions. If you only provide the height or width, the system sizes the graphic to fit that dimension and automatically calculates the other dimension to preserve the aspect ratio. For example (assuming the imported graphic is originally 8 ½” x 11”), this rule...

AddMultiPageBitmap SRCH(1,AddMultiPageBitmap,40,.\tif_srch 40,19), SCALE(4in)

tells the system to scale the graphic so that it is 4 inches high and 3.09 inches wide. This rule...

AddMultiPageBitmap SRCH(1,AddMultiPageBitmap,40,.\tif_srch 40,19),SCALE(4in,3in)

tells the system to scale the graphic to 3.88 inches tall and 3 inches wide, because if it scaled the height to be 4 inches, while maintaining the aspect ratio, the width would exceed the specified 3 inches. This rule...

AddMultiPageBitmap SRCH(1,AddMultiPageBitmap,40,.\tif_srch 40,19),SCALE(,5in)

tells the system to scale the graphic to 6.47 inches tall and 5 inches wide.

Keep in mind...

  • If you omit the height, you must include a comma (,) as a placeholder.
  • If no units, such as inches (in) or millimeters (mm), are provided, the system assumes your entry is in FAP units (2400 per inch).
  • Do not include both the Scale and Crop options. If you include both options, the system ignores the Crop option and only uses the Scale option.


Using the Crop Option

The Crop option removes all parts of the graphic that extend beyond the specified distances from the top left corner. If you omit one of the arguments, the graphic is not modified in that dimension. For example, this rule...

AddMultiPageBitmap SRCH(1,AddMultiPageBitmap,40,.\tif_srch 40,19),CROP(100mm,80mm)

tells the system to only include in the print stream an area of the graphic that is 100 mm tall by 80 mm wide, beginning in the top, left corner.

This rule...

AddMultiPageBitmap SRCH(1,AddMultiPageBitmap,40,.\tif_srch 40,19),CROP(12000)

tells the system to only include the top five inches (12000 FAP units) of the full-width graphic in the print stream.

Keep in mind...

  • If no units, such as inches (in) or millimeters (mm), are provided, the system assumes your entry is in FAP units (2400 per inch).
  • Do not include both the Scale and Crop options. If you include both options, the system ignores the Crop option and only uses the Scale option.


AddMultiPageTIFF

Note Beginning with version 11.3, the AddMultiPageTIFF rule was replaced by the AddMultiPageBitmap rule. If the system comes across the AddMultiPageTIFF rule, it auto ma ti ally runs the AddMultiPageBitmap rule.

Use this section level 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/section. 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.

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 name)

Enter the name of the DAL script you want to execute to return the 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 name)

Enter the GVM variable name that contains the name and path of the TIFF file. The GVM variable data is mapped by some other means before this rule is executed.

SRCH(search criteria name data)

The name and path of the TIFF file is contained in a record in the file specified by the ExtrFile option in the Data control group.

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.

Embed

(Optional) Include Embed to add the image data in the NA file. This is necessary when the file that contains the scanned images is temporary and you need to archive the NA/POL information. Upon retrieval, if you have not embedded the bitmap information directly into the form set, you will not be able to view or reprint the original images. The default is No.

Keep in mind that embedding bitmap data can make the resulting NA file much larger and also affects the size of the archives generated.

Only (Odd or Even)

By default, all images in the multipage TIFF file are included. Only 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).

Type

(Optional) 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.

Including this option will speed processing. You can also include this option if the target directory contains both TIFF and PDF files.

Keep in mind:

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
  • You can only include one of the section 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 section).

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


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 file to be appended to the form. This duplicate contains the bitmap image.

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:

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.

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.

Note Remember 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 file 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.


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

…

…

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.


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


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.

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:

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.

Using the File option with the Type option

This example imports the T_FILE.PDF file from the PDF_File directory. Using this file, 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 file 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.

Using the DAL option with the Type 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 PDF file to the form set. Each image in the PDF file causes a duplicate of the original FAP file 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.

Using the SCH option with the Type 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 PDF files to the form set. Each image in each PDF file causes a duplicate of the original FAP file 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.

Using the GVM option with the Type 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 images contained in the PDF file to the form set. Each image in the PDF file causes a duplicate of the original FAP file 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.

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

See also

  • AddMultiPageBitmap


CanSplitImage

Use this section level rule to identify the segments of sections (images) that can be dynamically split.

Syntax

CanSplitImage (Debug)

Parameter | Description
Debug | Optional. Include this parameter to tell the system to include debug information about when and how the section is split in the LOG.DAT file.

Keep in mind:

  • You must include the PaginateAndPropagate rule in the AFGJOB.JDT file. The PaginateAndPropagate rule looks for the CanSplitImage indicator. Without this rule, sections are paginated normally.
  • If the print driver produces output for a non-edge printer, such as PCL, you must have a header and footer that are copied on overflow. Otherwise, the data that falls into the non-print area is lost.
  • Text area objects must be flagged as Can span pages or the section is not split.
  • Text area sections that are greater 26,400 FAP units must be defined as Custom in the Paper Type field on the Page Properties tab. To add information to one of these sections, increase the paper height on the Page Properties tab to accommodate the increased size before you add the new information. Otherwise, the system may create a multipage section, which is not supported.
  • Text areas that are multipage sections are not supported.
  • This rule cannot split a section that includes a text area with an inserted file object.
  • This rule is not supported when you are using a group rule. The group pagination logic does not check for split sections, nor does it call the section split logic.

This table shows how each type of object is handled within a text area:

Object |
Different fonts | Yes
Borders | Yes.
Background shading | Yes
Bullets or numbers | No
Columns | Yes
Boxes | Yes *
Fields | Yes
Files | No
Graphics (LOG, BMP, TIF, and PNG files) | Yes *
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 section:

  1. The system loads the section and flags it as inline.
  2. The system duplicates the section. The new section follows the original section.
  3. The system moves up the bottom of the original section to just above the footer.
  4. The system moves the objects from the original section to the new section if the bottom of the object extends beyond the bottom of the original section.
  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 section is not set to Can Grow.
  • The system creates the new text area in the new section 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 section. All objects are moved up as much as possible but maintain their relative positions.
  • The system then moves the section 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 section to its minimum size and turns the Can Span attribute back on. Pagination continues as usual with two sections, instead of one.

Here are some examples that show what happens when a text area with a border is split:

Shaded areas are split in a similar manner:

See also

  • PaginateAndPropagate


CheckImageLoaded

Use this section level rule to see if the FAP file is loaded, and if not, load the FAP file. You would typically use this rule if there is information needed in the FAP file that is not present in the DDT file, such as bar code information, or variable field rotation information.

Note This rule is not necessary if you are developing resources in Documaker Studio. This rule was created for and used in the older, legacy Documaker development tools. In a Studio environment, the system manages the functionality implemented via these rules automatically and offers improved performance. If you are importing a legacy MRL that includes this rule, Studio will ignore it.

By default, the GenData program loads FAP files. If the LoadCordFAP option is turned on, the GenData program loads all FAP files. Avoid turning on this INI option as it slows performance. For example, make sure this option is set in the FSISYS.INI file as follows:

< RunMode >

LoadCordFAP = No

The GenData program should only write information about dynamic data, such as variables, into the NAFILE.DAT file from the DDT files. You can do this more efficiently by loading the DDT files instead of the FAP files.

There are, however, situations which require you to load FAP files. This rule and the TextMergeParagraph rule handle these situations. These rules let you load data for a single FAP file. Keep in mind that the TextMergeParagraph rule affects a single FAP file while the LoadCordFAP option affects all FAP files.

Since, in some cases, you must load FAP files, the system includes utilities which let you pre-compile FAP files and FXR files. By pre-compiling these files into CFA (FAP) and CFX (FXR) files, you can speed performance by eliminating parsing operations. The system is set up to use pre-compiled FAP and FXR files. You can see this setting in the FSISYS.INI file:

< RunMode >

CompiledFAP = Yes

To turn off this setting, change the Yes to No. For best results leave it set to Yes.

Note Using this rule slows performance. Use only as necessary.

Syntax

CheckImageLoaded ()

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

Rotated fields

If you have a section (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.

See also

  • TextMergeParagraph


ConnectFields

Use this section level rule to move and align field text so the data elements appear to be connected.

Note Previously, this rule was known as the ConcatFields rule. You can use either spelling.

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.

Including NO in Movement Parameters

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 section (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.
  • 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 bar code or multiline text fields. If you try to name such a field, you will get an error. This rule does not handle rotated fields.

See also

  • Move_It
  • SpanAndFill


CreateChartSeries

Use this section level rule to get data from extract records and include it as series data in a chart. The system uses the data exactly as it exists in the extract record. There is a syntax you can use to create a search mask which will search for and get an extract record. You can also specify where in that record the data resides. Additionally, you must specify the chart and series to which the data will be added.

Typically, you will use the DeleteDefaultSeriesData before you use this rule. You should always use the PurgeChartSeries after you use this rule.

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 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 (,).

See also

  • FieldVarsToChartSeries
  • Search Criteria


CreateSubExtractList

Use this section level rule to process multiple items of the same type within a single transaction. This rule produces a temporary extract list which contains each record of the same type within a transaction.

The temporary extract list is based on the search mask and key you define. The system can then populate variable fields using the data in the temporary extract list.

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


DeleteDefaultSeriesData

This section level rule removes all unnamed series data from the specified set of series in a chart. If there are no series specified, this rule removes all series for the chart.

This rule is designed for the special circumstance where unnamed series data may have been defined for the chart during composition, but this series data is not used in every production. In other words, the series data is dynamically created as the result of running rules such as the CreateChartSeries or FieldVarsToChartSeries rules.

Syntax

DeleteDefaultSeriesData (Chart,Series,...;

The first semicolon-delimited field contains the rule name. The second semicolon-delimited field should contain one or more comma-delimited items. The first item must always be a chart name. Any successive items must be series names that belong to that chart.

See also

  • CreateChartSeries
  • FieldVarsToChartSeries


DelImageOccur

Use this section level rule to delete a specific occurrence of a section on a form.

Syntax

DelImageOccur (Occurrence,Form,KillSpace)

Parameter

Description

Occurrence

The section occurrence to delete. Positive numbers indicate the count is from the beginning. Negative numbers indicate the count is from the end.

Form

The form name. If there are multiple sections, separate the section names with commas, such as

form1,form2,form3

If you specify a form name, the rule only works on those forms. If you omit the form names, the rule affects all forms that include the section.

KillSpace

(Optional) If you include this parameter, the system removes the space after the specified occurrence of the section.

If you include this parameter, you must include it before the form name. Here is an example:

DelImageOccur 1,KillSpace

DelImageOccur 1,KillSpace,Form1

Any form specified before the KillSpace parameter is not affected by this parameter. Consider this example:

DelImageOccur 1,Form1,KillSpace,Form2,Form3

The first occurrence of the current section in Form1 is removed but the space where this section was placed is not removed. However, the first occurrence of the current section is removed from From2 and From3. Furthermore, the system also removes the space after the specified occurrence of the section.

To use this rule, you must also add the following rule to the AFGJOB.JDT file:

;ProcessQueue;;PostPaginationQueue;

Add this rule after the RunSetRcpTbl rule. You can omit the rule level number.

See also

  • ProcessQueue
  • RunSetRcpTbl


DontPrintAlone

Use this section level rule if you need to delete a page from a form set and there is only one section on that page.

Syntax

DontPrintAlone ( )

If, when the system determines pagination, it determines the section is the only section on the page, the system omits the page from the printed output.

See also

  • PaginateBeforeThisImage


Field2GVM

Use this section level rule to create a GVM variable from the fields in the current section. For instance, you can use this rule to store the system date for later use.

Syntax

Field2GVM (FieldName,GVMName)

Parameter | Description
FieldName | Name of the field on the current section 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 section. 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.


FieldVarsToChartSeries

Use this section level rule to allow a chart's series data to be retrieved via references to the section’s variable fields. Since Documaker Server does no field propagation, as would an entry system, you must handle field propagation.

You can assign a name for the series data in the FAP file definition. You can then use the series data name to associate the series with a variable field with the same name. This rule propagates data mapped to a variable field into series data with the same name. What this rule does that the CreateChartSeries rule cannot is manipulate extract data before it is assigned to a series.

Syntax

FieldVarsToChartSeries ( )

Typically, you will need to use the DeleteDefaultSeriesData rule before you use this rule. Always use the PurgeChartSeries rule after you use this rule, as a means of cleanup. If you find incorrect data in a chart, you may be missing one of these rules.

Note Use Studio to select the fields the system will then use to assign the minimum, maximum, increment/label, and tick mark values. See the Documaker Studio User Guide.

See also

  • CreateChartSeries
  • DeleteDefaultSeriesData
  • PurgeChartSeries
  • Move_It
  • MoveNum


GroupBegin

Use this section level rule to define the first section in a group of sections. A group is a set of sections delimited by a begin section and an end section that is processed as a single unit.

Using this rule, you specify which sections are grouped on the printed pages. Each GroupBegin rule must have a corresponding GroupEnd rule. With these rules you can:

  • Expand boxes to surround a section group with user-defined margins
  • Keep a group of sections together on a page
  • Paginate vertically with headers, footers, and overflow sections 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 sections in the group. The Margin parameter lets you define the extra space to be added between the edge of the section 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

Here is an example:

GroupBegin Box(Margin(20,20,20,20))

The section would look like this:

The section 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 a section group and sets the margin to 20 FAP units between the outer edge of the section 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 sections (groups) together on pagination. The GroupPagination parameters are:

Parameter | Description
MinImagesOnCurrent | Defines the minimum number of sections required on the current page. The default is zero (0). This rule counts all sections triggered in the group, even if a section has no size. It totals the section sizes to determine the minimum number of sections which can be placed in the remaining space on the page. If a section has no size or is flagged as view only, the section is placed on the page.
MinImagesOnNext | Defines the minimum number of sections required for new and next page. The default is one (1).
NeverSplit | Requires that all sections 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 sections appear on the current page, and a minimum of three sections 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 section is defined as the header for the group and is to be copied on overflow. Plus the fourth section is defined as the footer for this group.


Using the List Function

A list is a column of data on a section that is populated by the BldGrpList rule.

The List function works with the BldGrpList rule to print sections 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 a section. When pagination occurs, if the number of lines printed on the first page is less than the MinLines amount, the entire section is moved to the second page.
MinLinesCont | Defines the minimum number of lines to be printed on the last page of a section. 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.


Using the StayTogether Function

Use this function if you do not want the group of sections 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 sections 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 sections you want to organize into columns, the results will not be what you expect.


Using the Column Function

Use the Column group function to create wrapping or and straight columns.

Creating wrapping columns

Use the Wrap parameter to create newspaper style columns where the column 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.

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.

Column function parameters

Here is a list of the parameters you can use with the Column function.

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

Balanced( )

The balanced sub-parameters determine how sections are processed if there is less than a full page of sections. The default is Left.

Left

Use this sub-parameter to equally divide the sections 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 sections to a column until there is no more room in that column on that page. The system then places remaining sections 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 sections 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 section 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.

Keep in mind these requirements and restrictions when defining groups:

  • Each GroupBegin section must have a corresponding GroupEnd section. Either of these sections can be a blank section.
  • If you are using conditional sections, make sure the triggers in the SETRCPTB.DAT file for the GroupBegin and GroupEnd sections are the same.
  • Group footers do not have to be defined as the first section 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 a section contains both a GroupBegin rule and a SetGroupOptions rule, the GroupBegin rule must come first.
  • When a section contains both a GroupEnd rule and a SetGroupOptions rule, the SetGroupOptions rule must come first.
  • Variable field data inside overflow group header sections will propagate to the new page during group pagination if the field scope is set to Form.

You must set all group pagination section options (footer, header, and copyonoverflow) using the SetGroupOptions rule.

See also

  • GroupEnd
  • BldGrpList
  • SetGroupOptions


GroupEnd

Use this section level rule to define the last section in a group of sections. This rule triggers the formatting of gathered data into section lists, or columns. Vertical pagination occurs while the system processes this rule.

Syntax

GroupEnd ( )

There are no parameters for this rule.

See also

  • GroupBegin
  • SetGroupOptions


IncOvSym

Use this section level rule to increment an overflow variable. The overflow variable is a counter that tracks of the number of overflow values processed for a section. This overflow variable is incremented as records are processed and as the overflow increases.

This rule increments the overflow symbol you specify in the data field. Use the ResetOvSym rule to reset the variable for the next transaction that might overflow.

Syntax

IncOvSym (OverflowVAR,SectionName,X)

Use the X parameter to limit the IncOvSym rule to a single execution and also determine when the rule is executed. You control the execution of the rule by including the X parameter, as shown here:

Parameter

Description

OverflowVAR

Specify the overclow symbol.

SectionName

Specify the name of the section.

X

(Optional) Here you specify when the system should execute the IncOvSym rule by choosing one of these options:

F - Tells the system to execute the IncOvSym rule after the first page.

L - Tells the system to execute the IncOvSym rule after the last page.

1-9 - Tells the system to execute the IncOvSym rule after the corresponding page. For instance, enter 3 to tell the system to execute the rule after the third page.

Keep in mind you can enter only one option. If you enter more than one character, the system evaluates the first character and ignores the rest.

If the requesting section is not a multipage section, the system ignores this parameter. If you enter a character other than F, L, or 0-9, an error message appears. If you enter zero (0), nothing happens because there is never a page zero.

Note Be sure to thoroughly test your environment when you use this parameter. Different results are created depending on the number of pages in the FAP file, the type of overflow, when pagination occurs, and type of data fields on the different pages in the FAP file.

See also

  • Overflow and User Functions
  • PurgeChartSeries
  • SetImageDimensions
  • ResetOvSym


MoveMeToPage

Use this section level rule to move the entire page the section resides on to a designated page.

Syntax

MoveMeToPage (PageNumber)

Parameter | Description
PageNumber | Page number to which the sections will be moved. To move sections to the last page, enter zero (0).

If you use the rule, you must have the following set in the AFGJOB.JDT:

;ProcessQueue;;PaginationQueue;

This rule only works with forms that have multiple pages.


PaginateBeforeThisImage

Use this section level rule to force the system to perform a pagination before it processes this section. Normally, pagination does not occur until the system has finished processing the entire form set - meaning that all data is complete.

If pagination occurs because an earlier section exceeded a page boundary, the internal references for page coordinates are reset for the page that now contains this section.

This rule makes it possible for a section or field rule that occurs later to know what page the section (or field) occupies. You can also use this rule if you want to know how much of the page is occupied so you can conditionally include or exclude data. If you waited until normal pagination would occur, it would be after all normal section and field level rules had been executed and it would be too late.

Syntax

PaginateBeforeThisImage ( )

There are no parameters for this rule. This rule is sometimes used with the ResetImageDimensions and DontPrintAlone rules.

See also

  • ResetImageDimensions
  • DontPrintAlone


PostImageDAL

Use this section level rule to execute a DAL script on the POST_PROC_B message. The PostImageDAL rule executes after all field level rules are run.

You can use this rule to handle follow-up tasks after the section and field level rules are executed.

Syntax

PostImageDAL (String)

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

Although you can use DAL to access almost any form set or section 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 section 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.

See also

  • PreImageDAL
  • PostTransDAL
  • PreTransDAL


PreImageDAL

Use this section level rule to execute a DAL script on the PRE_PROC_B message. The PreImageDAL rule executes before section or field level rules.

You can use this rule to handle setup tasks which should occur before section and field level rules are executed.

Syntax

PreImageDAL (String)

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

Although you can use DAL to access almost any form set or section 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 section 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.

See also

  • PostImageDAL
  • PostTransDAL
  • PreTransDAL


PurgeChartSeries

Use this section level rule to remove a series from a chart which contains no series data. The cleanup performed by this rule affects all charts on the section. If a series is defined for a chart, but there is no data to fill that series, in most cases you would not want to include the empty series in the chart.

A series may exist but contain no series data because you may need to add series data on an as provided basis. For instance, the customer extract data may contain a variable number of records containing data that goes into a chart. Each of these records may contain data for a single series.

The FAP file would be designed to accommodate the maximum number of series that could be included. If the extract data does not contain records to build the maximum number of series the chart can accommodate, you may want to exclude those series from the chart. This eliminates white space on the chart.

Syntax

PurgeChartSeries ( )

You typically use this rule with the CreateChartSeries or FieldVarsToChartSeries rules. Always place this rule after any rule which gathers chart data.

See also

  • CreateChartSeries
  • FieldVarsToChartSeries


RemoveWhiteSpace

Use this section level rule to remove the white space from between fields. This rule works similarly to the SetAddr rules, but is not address specific.

Syntax

RemoveWhiteSpace (Field1,Field2,Field3;/NoWarning)

The parameters to this rule should include a list of fields that should exist on the section. Because fields are typically not created when no data maps, you must load the section to make sure the empty fields exist.

Separate the fields in the list with commas. Each subsequent field with data will be mapped into the earliest named prior field that did not contain data.

This rule moves field data from one field to a prior named field to compress out the space between the fields. Typically, you would use this rule to compress the vertical space, as in address lines, but the rule does not really care whether the space is vertical or horizontal.

Unlike the SetAddr type rules, this rule does not actually map the original data. You must use field mapping rules, like Move_It, to do that. Also note that only the data moves between the fields. The location of each physical field remains the same.

Also, unlike the SetAddr rules, you do not have to compress the space up. If you specify the fields in the reverse vertical order, you can compress the space down.

Using the NoWarning parameter

If the system cannot locate the field, you get a warning. If you include the NoWarning parameter, however, you can suppress the warning. Add this parameter after the last field in the list. Use a forward slash (/) to separate it from the previous parameter and end it with a semicolon (;). This parameter is optional. Here is an example:

RemoveWhiteSpace PAGE1_FIELD1,PAGE1_FIELD2,PAGE1_FIELD3, PAGE1_FIELD4/NoWarning

The warning message includes addition information to help you resolve the problem:

DM10190: Warning in <REMOVEWHITESPACE>: Unable to locate field <FieldName> in image <ImageName>.

This rule does not work with bar code fields or multiline text fields.

If the system cannot locate the listed field and the section is a multipage section and you omitted the NoWarning parameter, you get message DM10189. If you included the NoWarning parameter, you get message DM10190. Here are some examples:

DM10189: Warning in <REMOVEWHITESPACE>: Unable to locate field <FieldName> on page <PageNo> of a multi-page image <ImageName>.

DM10190: Warning in <REMOVEWHITESPACE>: Unable to locate field <FieldName> in image <ImageName>.

Note

  • Naming the same field to move more than once in the parameters may cause unreliable results. The final location of a field's data is determined by the last movement of that field.
  • This rule does not work with bar code type fields or multiline text fields.


ResetImageDimensions

Use this section level rule to reset the top or bottom dimensions of the current section based on the parameters you specify. This rule makes the objects on the section fit under the bottom of the header, over the top of the footer, or compresses the section to the smallest height possible, including all of its objects.

Syntax

ResetImageDimensions (NewSize)

Parameter

Description

NewSize

Choose one of these options:

FooterTop - Makes the objects on the section fit over the top of the footer by resetting the bottom dimensions.

HeaderBottom - Makes the objects on the section fit under the bottom of the header by resetting the top dimensions.

MinHeight - Resizes the section to occupy the least amount of space. No objects are omitted or resized, but unused space is removed.

LastField - Resizes the section to occupy the least amount of space. Only the fields with data are examined when the system looks for the lowest point on the section. Use this option on sections that have only fields or no objects lower than the last few fields you expect to map
Note The parameters are not case sensitive.

In legacy implementations, where only DDT files were loaded and not FAP files, fields are the only objects on a section the ResetImageDimension rule recognizes. That meant section 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 section is moved to a position below the lowest mapped field on the section. This is what you want in situations where the next section should be placed immediately below where the last field was mapped. For instance, assume you have a small section 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 section below where the last field was mapped. Here is an example:

ResetImageDimension LastField

Note Depending upon your print or display method, changing the bottom of the section 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 section 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 >

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 sections that would use the ResetImageDimension rule.

Note Depending upon your print or display method, changing the bottom of the section 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 section in sequence on the same page.

Also note that the term last field refers to the lowest field mapped on a section 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 section.

See also

  • SetImageDimensions
  • PaginateBeforeThisImage


ResetOvSym

Use this section level rule to reset an overflow variable during the processing of a document set. Use this rule on the section level if you can not wait until the job level rule, ResetOvFlw, resets the entire set of overflow variables.

Syntax

ResetOvSym (OverflowSymbol,SectionName)

Parameter | Description
OverflowSymbol | The name of the overflow symbol defined in the SetOvFlwSym rule.
SectionName | The name of the section that contains the fields on which overflow processing will occur.

See also

  • PurgeChartSeries
  • IncOvSym
  • OvActPrint
  • OvPrint
  • SetImageDimensions


SetCpyTo

Use the section level rule to set the value of the SendCopyTo variable to a field in the FAP file that definitely contains data.

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.

See also

  • Mk_Hard


SetCustChartAxisLabels

Use this section level rule to take data values that have been mapped to variable fields and use them as custom axis labels on a chart.

Syntax

SetCustChartAxisLabels (ChartName,FieldNames)

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


SetGroupOptions

Use this section level rule to set group options similar to forms. This rule lets you define the section as a header or footer and lets you specify whether or not the section should be copied onto the overflow section if overflow occurs.

Syntax

SetGroupOptions (Header,Footer,CopyOnOverFlow)

Parameter | Description
Header | Defines the sections that appear before the group.
Footer | Defines the sections that appear after the group.
CopyOnOverflow | Defines the sections 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 a section contains both a GroupBegin rule and a SetGroupOptions rule, the GroupBegin rule must come first.
  • When a section contains both a GroupEnd rule and a SetGroupOptions rule, the SetGroupOptions rule must come first.
  • You must set all group pagination section options (footer, header, and CopyOnOverflow) using the SetGroupOptions rule.


SetImageDimensions

Use this section level rule on forms which are made up of floating sections.

This rule is not necessary if you are developing resources in Documaker Studio. This rule was created for and used in the older, legacy Documaker development tools.

In a Studio environment, the system manages the functionality implemented via these rules automatically and offers improved performance. If you are importing a legacy MRL that includes this rule, Studio will ignore it.

The system automatically inserts this rule for you if you save your DDT file in Image Editor. If you later resize the section, go to Image Editor and save the DDT file again to have the system update the section dimensions.

If you used the SetOrigin rule, the system automatically includes this rule in the section level rules section of your DDT file.

Note Always let the system take care of this rule for you.

See also

  • SetOrigin
  • ResetImageDimensions


SetOrigin

Use this section level rule to set the section overlay/page segment X and Y coordinates. Using this rule, you specify where the page segment will be placed on the printed page.

You can also use the SetOriginI and SetOriginM rules. SetOriginI works just like SetOrigin except you enter X and Y coordinate information in inches, instead of FAP units. There are 2400 FAP units per inch.

SetOriginM works just like SetOrigin except you enter X and Y coordinate information in millimeters. There are approximately 98 FAP units per millimeter.

Use the SetOrigin rule if you prefer to enter these coordinates in FAP units.

Syntax

;SetOrigin (Fixed,X,Y,Form,Store,ImageName)

Parameter

Description

FIXED

(Optional) Anchors the section at the specified X and Y coordinates. This must be the first parameter listed. See Fixing a section’s position for more information.

X

Sets the X coordinate. This determines the section’s horizontal position.

Y

Sets the Y coordinate. This determines the section’s vertical position.

Form

(Optional) The form name on which the section exists. This parameter lets you define more than one SetOrigin rule for a section and specify which one applies based on the name of the form.

Store( )

(Optional) This parameter lets you store the current section 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 a section 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 section’s top left coordinate. (supports overflow)
Max | Relative to the last section’s maximum edge. For example, Rel+0,Max+600 would position the current section ¼ inch below the last section. (supports overflow)
Mpg | Relative to any section at the maximum edge. For example, Abs+0,Mpg+600 places the current section ¼ inch below the lowest object currently on the page. (does not support overflow)
T2T | Top edge is placed relative to the last section’s top edge. (Similar to Rel)
T2B | Top edge is placed relative to the last section’s bottom edge. (Similar to Max+)
B2T | Bottom edge is placed relative to the last section’s top edge. (Similar to Max-)
 | Bottom edge is placed relative to the last section’s bottom edge.
L2L | Left edge is placed relative to the last section’s left edge. (Similar to Rel)
L2R | Left edge is placed relative to the last section’s right edge. (Similar to Max+)
R2L | Right edge is placed relative to the last section’s left edge. (Similar to Max-)
R2R | Right edge is placed relative to the last section right edge.
Ctr | X/Y dimensions are centered on the last section’s X/Y dimensions.

Fixing a section’s position

The SetOrigin rule lets you designate a section as a fixed section. Fixed sections cannot be moved from their set position.

You declare a section to be fixed by including FIXED as the first parameter of the section's SetOrigin rule. Regardless of when the section is triggered, it will keep the coordinates assigned to it throughout pagination.

Fixed sections can also be designated as CopyOnOverflow sections. This will cause the fixed section 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 a section that will always be on the page. Do not anchor the fixed section relative to a section that can overflow onto a new page. If you do, the fixed section 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.

See also

  • SetOriginI
  • SetOriginM
  • SetImageDimensions


SetOriginI

Use this section level rule to set the section overlay/page segment X and Y coordinates. Using this rule, you specify where the page segment will be placed on the printed page.

You can also use the SetOrigin and SetOriginM rules. SetOrigin works just like this rule except you enter X and Y coordinates in FAP units, instead of inches. There are 2400 FAP units per inch.

SetOriginM works just like this rule except you enter X and Y coordinates in millimeters. There are approximately 25.4 millimeters per inch.

Syntax

SetOriginI (Fixed,X,Y,Form,Store(),ImageName)

Parameter | Description
FIXED | (Optional) Anchors the section at the specified X and Y coordinates. This must be the first parameter listed. See Fixing a section’s position for more information.
X | Sets the X coordinate for a section. This determines the section’s horizontal position.
Y | Sets the Y coordinate for a section. This determines the section’s vertical position.
Form | (Optional) The form name on which the section exists. This parameter lets you define more than one SetOrigin rule for a section and specify which one applies based on the name of the form.
Store( ) | (Optional) This parameter lets you store the current section 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 from any page in the form set.

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 section’s top left coordinate. (supports overflow)
Max | Relative to the last section’s maximum edge. For example, Rel+0,Max+.25 would position the current section ¼ inch below the last section. (supports overflow)
Mpg | Relative to any section at the maximum edge. For example, Abs+0,Mpg+.25 places the current section ¼ inch below the lowest object currently on the page. (does not support overflow)
T2T | Top edge is placed relative to the last section’s top edge. (Similar to Rel)
T2B | Top edge is placed relative to the last section’s bottom edge. (Similar to Max+)
B2T | Bottom edge is placed relative to the last section’s top edge. (Similar to Max-)
 | Bottom edge is placed relative to the last section’s bottom edge.
L2L | Left edge is placed relative to the last section’s left edge. (Similar to Rel)
L2R | Left edge is placed relative to the last section’s right edge. (Similar to Max+)
R2L | Right edge is placed relative to the last section’s left edge. (Similar to Max-)
R2R | Right edge is placed relative to the last section right edge.
Ctr | X/Y dimensions are centered on the last section’s X/Y dimensions.

See also

  • SetOrigin
  • SetOriginM
  • SetImageDimensions


SetOriginM

Use this section level rule to set the section overlay/page segment X and Y coordinates. Using this rule, you specify where the page segment will be placed on the printed page.

You can also use the SetOrigin and SetOriginI rules. SetOrigin works just like this rule except you enter X and Y coordinates in FAP units, instead of millimeters. There are approximately 98 FAP units per millimeter.

SetOriginI works just like this rule except you enter X and Y coordinates in inches. There are approximately 25.4 millimeters per inch.

Syntax

SetOriginM (Fixed,X,Y,Form,Store(),ImageName)

Parameter | Description
FIXED | (Optional) Anchors the section at the specified X and Y coordinates. This must be the first parameter listed. See Fixing a section’s position for more information.
X | Sets the X coordinate for a section. This determines the section’s horizontal position.
Y | Sets the Y coordinate for a section. This determines the section’s vertical position.
Form | (Optional) The form name on which the section exists. This parameter lets you define more than one SetOrigin rule for a section and specify which one applies based on the name of the form.
Store( ) | (Optional) This parameter lets you store the current section 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 from any page in the form set.

Specify the X and Y coordinates using a combination of the following parameter prefixes plus the addition or subtraction of measurements you specify in millimeters. Here are the prefixes you can use:

Prefix | Description
Abs | Absolute page position based on millimeters. (supports overflow)
Rel | Relative to the last section’s top left coordinate. (supports overflow)
Max | Relative to the last section’s maximum edge. For example, Rel+0,Max+1 would position the current section 1 millimeter below the last section. (supports overflow)
Mpg | Relative to any section at the maximum edge. For example, Abs+0,Mpg+1 places the current section 1 millimeter below the lowest object currently on the page. (does not support overflow)
T2T | Top edge is placed relative to the last section’s top edge. (Similar to Rel)
T2B | Top edge is placed relative to the last section’s bottom edge. (Similar to Max+)
B2T | Bottom edge is placed relative to the last section’s top edge. (Similar to Max-)
B2B | Bottom edge is placed relative to the last section’s bottom edge.
L2L | Left edge is placed relative to the last section’s left edge. (Similar to Rel)
L2R | Left edge is placed relative to the last section’s right edge. (Similar to Max+)
R2L | Right edge is placed relative to the last section’s left edge. (Similar to Max-)
R2R | Right edge is placed relative to the last section right edge.
CTR | X/Y dimensions are centered on the last section’s X/Y dimensions.

See also

  • SetOrigin
  • SetOriginI
  • SetImageDimensions


SetRecipFromImage

Use this section level rule to conditionally add sections to the current form set based on conditions in the SETRCPTB.DAT file. You set up parameters which instruct the rule to generate a new set of keys (Key1, Key2, and TranID).

A new set of items from the current SETRCPTB.DAT file is generated and those items are run through the RunSetRcp feature to generate a temporary form set. This temporary form set is merged with the current form set to create the final form set.

Note With version 11.3, Documaker Studio lets you create subforms. Using subforms you can include forms within forms which eliminates the need to use the SetRecipFromImage rule. This simplifies triggering and populating data on sections when you are processing repeating patterns of hierarchical or nested data. Previously, you had to use the SetRecipFromImage rule, the sub extract rules, and overflow symbols to achieve the same result.

Syntax

SetRecipFromImage (Key1,Key2,TranID,AtEnd)

Parameter | Description
Key1 | Value
Key2 | Value
TranID | Value to set new key values
AtEnd | If you set this parameter to True, the system adds the forms in the order you listed in your FORM.DAT file. The default is False, which tells the system to load the form backwards from the way it is referenced in the FORM.DAT file.

The string $(Key1) within value equals the current transaction’s Key1 value. $(Key2) equals the current transaction’s Key2 value. $(TranID) equals the current transaction ID.

See also

  • CreateSubExtractList


SpanAndFill

Use this section level rule to take a field and span its width between two other fields, filling the field with a fill character.

Syntax

SpanAndFill (SpanField,LeftField,RightField)

Parameters | Description
SpanField | Enter the name of the field you want to span. This field must be the first parameter.
LeftField | Enter the field you want to be on the left.
RightField | Enter the field you want to be on the right.
Note This rule does not move the field vertically. Only the width and horizontal location are changed.

The filler character is used to span the width between the end of the text in the left field and the beginning of the text in the right field. If either field is empty, the left coordinate of the field is used.

You can use any rule to map the fill character into the SpanField. For example, you can use the HardExst rule to map a character such as a period or asterisk. Only the first character of the mapped data is used as the filler character. If no data is found in the SpanField, the system uses periods (.) as the fill character.

Note You may want to use the JustFld rule on your right-most field to make sure the field is right justified.

Keep in mind...

  • 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 the entire contents and will not remove space from the fields.
  • This rule loads the section (FAP or compiled FAP) if it is not already loaded.
  • The font ID assigned to the SpanField is used for calculating the number of characters required to fill the width of the field.
  • If there is fractional space remaining, the system place the extra white space to the left of the SpanField.

See also

  • ConnectFields


TextMergeParagraph

Use this section level rule to merge data for embedded variable fields in a text area with text. The Move_It or MoveNum rules are most often used with this rule to move data from the extract file into embedded variable fields. The system then rewraps the text area

Note This rule is not necessary if you are developing resources in Documaker Studio. This rule was created for and used in the older, legacy Documaker development tools. In a Studio environment, the system manages the functionality implemented via these rules automatically and offers improved performance. If you are importing a legacy MRL that includes this rule, Studio ignores it.

The system writes the FAP information into the NAFILE.DAT file, which is used by the GenPrint program. If a section includes this rule, the Can Grow attribute setting in the section’s FORM.DAT file must match the text area’s Can Grow attribute in the FAP file.

Note If you include the Can Grow attribute for a multiline text field, be aware the field can both grow and shrink, depending on the data. If you do not want the text area to change sizes, turn off the Can Grow attribute.

Using this rule can slow performance, so use it only as necessary. If you must use this rule, it is better not to mix other objects with the text area in this FAP file. The more objects are mixed, the worse your performance, because all of the information about these objects will be written to NAFILE.DAT file also. If these objects are separated into another FAP file, they can be part of the compiled overlay and need not be loaded into the NAFILE.DAT file.

Performance is affected even more if you include graphics in the FAP file and you are sending the data stream to an AFP printer. This is because the LoadFAPBitmap option in the RunMode control group is set to Yes and is needed to print the graphics. This INI option also affects performance. Avoid it as much as possible.

Note System variables, such as Send Copy To, cannot be used as an embedded variable field text area.

Syntax

TextMergeParagraph( )

No parameters are necessary. Only include this rule if your section has embedded variable fields in a text area.

See also

  • CheckImageLoaded
  • Move_It
  • MoveNum


Field Rules Reference

Field rules help you control how data is processed and generated to fill a field on a form.

Note This section serves as a reference to the field rules. For information on the rules which apply to sections, see the Section Rules Reference. For information on the rules which apply to jobs and form sets, see Adding Job and Form Set Rules.

This section discusses rules included in the base system and supported by the Oracle Documaker support staff. For information on custom rules, contact your Services representative.

For a summary of these rules, see the Field Rules Summary.


Field Rules Summary

The following pages list and explain the various field rules you can use. The rules are discussed in alphabetical order on the pages following this table.

You can also see information about the field rules while using Studio when you select the rule on the field’s Properties window:

The following table lists the rules discussed in this section.

To… | Use this rule | AFGJOB | Section | Files | INI | Overflow | XML
Add a placeholder which causes no operation to occur (used in testing) | NoOpFunc | no | no | no | no | na | no
Add a variable from more than one occurrence of a particular record type | AccumulateVariableTotal | no | no | no | no | na | no
Add two or more fields and insert the result into a new field | MoveSum | no | no | yes | yes | na | yes
Call a DAL function | If | no | no | yes | yes | no | no
Concatenate strings and place the result in the field you specify | ConCat | no | no | no | no | yes | no
Copy alphanumeric data from a table using the source record field as a key | TblLkUp | no | no | yes | yes | yes | no
Copy and format numeric data in an extract record | MoveNum | no | no | no | no | yes | yes
Copy data from an external record into the output buffer | Move_It | no | no | no | no | yes | yes
Copy data from an SAP Raw Data Interface (RDI) extract file | SAPMove_It | no | no | yes | no | yes | yes
Copy data from the table list of records into the output buffer | MovTbl | no | no | no | yes | na | no
Copy data if a source record exists | MoveExt | no | no | yes | no | yes | no
Count the total number of overflow records that could be processed per transaction | OvPrint | no | yes | no | no | yes | no
Create lists of data for populating section lists or columns | BldGrpList | yes | no | no | no | na | no
Display the difference between two dates | DateDiff | no | no | no | no | na | no
Draw an underline beneath a variable field | UnderlineField | no | yes | no | no | yes | no
Emulate TerSub entry functionality | TerSubstitute | no | no | no | no | yes | no
Execute the MoveNum rule if an external record is found | MNumExt | no | no | yes | no | yes | no
Force a transaction to manual batch (WIP) | KickToWip | no | no | no | yes | na | yes
Force a transaction to manual batch (WIP) | PowType | no | no | no | yes | na | no
Format a date | * DateFmt | no | no | yes | no | yes | no
Format a date (for international localities) | FmtDate | no | no | no | no | yes | yes
Format a number | FmtNum | no | no | no | no | yes | yes
Format the system date | SysDate | no | no | no | no | yes | no
Get a text table item based on a key from the source field name concatenated with data retrieved from the source record | TblText | yes | no | yes | yes | yes | yes
Get data from an extract record, look up the data in a table, and copy the table data to the destination field | LookUp | yes | no | yes | yes | na | no
Get information from an extract file based on conditions you specify | DAL | no | no | yes | yes | yes | yes
Get information from an extract file based on conditions you specify | If | no | no | yes | yes | no | no
Get the current system date | FfSysDte | no | no | no | no | yes | no
Get the run date from the TRNFILE.DAT file and format it using the mask you specify | RunDate | no | no | yes | no | na | no
Have the system format the data when it maps it to a field | AnyToAny | no | no | no | no | na | no
Insert a specific value | Mk_Hard | no | no | no | no | na | no
Insert a value in a field only if a record is found in the extract data using the search criteria you specify | HardExst | no | no | no | no | yes | no
Justify a field (right, left, or center) | JustFld | no | no | no | yes | yes | yes
Map fields in the XDB database | * XDB | no | no | yes | no | na | no
Map fields in the XDD database | XDD | no | no | yes | yes | na | yes
Print information in a field if the data matches the numeric value you specify | PrtIfNum | no | no | yes | no | na | no
Print information in a field if the data matches the string you specify | PrintIf | no | no | yes | no | yes | no
Process multipage sections | * EjectPage | no | no | no | no | na | no
Replace the NoOpFunc rule | MapFromImportData | no | no | no | yes | na | no
Report the actual number of overflow records that could be processed per transaction | OvActPrint | no | no | no | no | yes | no
Retrieve a message from an extract file | MessageFromExtr | no | no | yes | yes | yes | no
Retrieve and format a string | LookUp | no | no | yes | no | yes | no
Select the largest value of multiple packed decimal fields located on the same record to populate a variable field | CompBin | no | no | no | no | na | no
Speed the processing of fields used repeatedly throughout a form set | GlobalFld | no | no | yes | no | na | no
Store and retrieve subsequent lines of a multiple line address | SetAddr | no | no | no | no | yes | no
Store and retrieve subsequent lines of a multiple line address and also format the city, state, and 10-digit postal code | SetAddr2 | no | no | no | no | yes | no
Store and retrieve subsequent lines of a multiple line address and combine address lines two and three | SetAddr3 | no | no | no | no | yes | no
Tell the system the field has been mapped to the master DDT file | Master | no | no | yes | no | na | no
Translate a numeric ISO state code into the actual state name | SetState | no | no | yes | no | yes | no
* - Indicates this is a legacy rule that may be found in older implementations. AFGJOB - Indicates if there are AFGJOB.JDT file implications to this rule. Section - Indicates if this rule depends on a section rule. Files - Indicates if external supporting files (other than extract records) can be used with this rule. INI - Indicates if there are INI options associated with this rule.Overflow - Indicates if this rule supports overflow. XML - Indicates if this rule accepts XML input.


TEst

You are here: Field Rules Reference > Field Rules Summary > AccumulateVariableTotal

AccumulateVariableTotal

Use this field level rule 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’s Properties window in Studio. Separate each option with a comma.

Option

Description

- (one dash)

If the number is negative, this option places a minus sign (-) in the left most position. For example, if the format mask is (9.2,12.2,C,$,-), the result is: “- $2,100.00”.

- - (two dashes)

If the number is negative, this option places a minus sign (-) immediately 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

CS2

CS731

Enter one of these options to indicate the checksum method.

The system appends a check digit (mod 10) of 0 through 9 to the end of the 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 Checksum Methods.

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.

See also

  • Using Condition Tables
  • Using the Record Dictionary for Variables
  • Field Rules Summary


AnyToAny

Use this field level rule to have the system format the data when it maps it to a field. This rule uses XDD (Extract Data Dictionary) format as the source format and whatever you specify as the target field format for the output.

Compared with prior mapping rules, using this rule reduces development effort as the data for a given field in the extract file only requires one instance in the XDD, regardless of its output formatting requirements. Using this rule also enhances performance because data for each field only has to be loaded once, rather than multiple times if multiple output formats are needed.

For example, in version 11.5 you must define two fields in the XDD if you want to display a date as both MM/DD/YYYY and Month Day, Year in the MRL. In version 12.0 and later, you can use this rule to handle both formats. This lets you define the Date field once in the XDD, describing the format of the data found in the extract. Any field used on a section that uses the AnyToAny rule and maps from this single XDD member is then formatted based on what you specified as the format of the field.

Note When you use this rule, the system uses the locale of the destination field. For instance, if you have a date field that specifies a locale of CAD (French Canadian), the resulting text will be in French. If the destination field has a locale of EUR and a currency symbol is needed, the system uses the Euro (€).

Syntax

AnyToAny ()

There are no parameters for this rule.

You can use this rule several ways. For instance, you can...

● Create a field using the AnyToAny rule and specify the XDD member to link to using the Source Name field.
● Use the XDD rule and then set the Rule field in the XDD member to AnyToAny.

Regardless of how you use the AnyToAny rule, it must be linked to an XDD member. The XDD member must then contain the mapping information, data type, and format.

The rule maps data as shown in this table. The top row represents the input data type defined in the XDD while the first column shows the destination field type.

Destination Field Type | Input Data Type
 | Alphanumeric | Numeric | Date | Time
Alphabetic | Removes non-alphabetic characters | Not supported1
Alphanumeric | Mapped without changes
Numeric | Changes to numeric, omits non-numeric characters. | Converts to the format specified for the field. | Not supported1
(Y)es (N)o | The Yes and No values are mapped, other values are ignored. | 0 (zero) = No, anything else = Yes. Can only have numeric characters in the input data. Only looks at the first character of input data. | Not supported1
Bar code | The input data must match the selected bar code type. |  | Not supported1
Date | The input data must match the destination format. |  | Converts to the format specified for the field. | Not supported1
Int'l alphabetic | Removes non-alphabetic characters | Not supported1
Int'l alphanumeric | Mapped without changes
Int'l alphabetic uppercase | Removes non-alphabetic characters and uppercases the alphabetic characters. | Not supported1
Int'l alphanumeric uppercase | Uppercases the alphabetic characters | Mapped without changes | Uppercases the alphabetic characters | Mapped without changes
Multiline | Mapped without changes
Table only | Checks the input value against those defined for the table. |  | Not supported1
Time | The input data must match destination format. |  | Not supported1 | Converts to the format specified for the field.
Upper alphabetic | Removes non-alphabetic characters and uppercases the alphabetic characters. | Not supported1
Upper alphanumeric | Uppercases the alphabetic characters | Mapped without changes | Uppercases the alphabetic characters | Mapped without changes
X or Space | The X and Space values are mapped. All other values are ignored. | 0 (zero) = Space, anything else = X. Can only have numeric characters in the input data. Only looks at the first character of input data. | Not supported1
Custom | Not supported1
1 Use another rule to map the field. If you use the AnyToAny rule in this scenario, the field will be blank and you will get a warning message.

Example

AnyToAny ()

See also

  • XDD
  • Field Rules Summary


BldGrpList

Use this field level rule to build lists of data you can use to populate section lists or columns during GroupEnd processing for each transition. This rule lets you specify which data will be collected in the list for GroupEnd processing.

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.

Including in AFGJOB.JDT

You must include the following rule in the AFGJOB.JDT file to clear the queues created by the BldGrpList rule after it processes each transaction:

;ProcessQueue;;PostPaginationQueue;

For more information, see ProcessQueue.

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

Use this function to retrieve data from multiple extract records that meet the search mask criteria. The multiple records define the array data that is used to populate fields on the section. 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:

31 39 41

RG00000028030219281501 CWIARRAY0400.0011.1122.2233.3344.44

RG00000028030219281501 CWIARRAY0499.9688.4534.2176.4504.05

Using the MultiOccur function

Use this function to retrieve data from multiple extract records that meet the search criteria for each transition, which is used to populate the fields on the section. The MultiOccur sub parameters are:

Parameter | Description
Search | Search masks used to locate the extract records that contain the data to populate the 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))Rule(Move_It)

Parameter | Description
BldGrpList;MultiOccur | Calls BldGrpList rule using the MultiOccur function.
(Search(31,CWICURR,39,~90,39,~95,39,~99) | Searches the extract records for CWICURR at offset 31 and 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

See also

  • GroupBegin
  • GroupEnd
  • Move_It
  • MoveNum
  • ProcessQueue


CompBin

Use this field level rule to select the largest value of multiple packed decimal fields located on the same record to populate a variable field.

For each given offset in the data section, the source offset is set and the MoveNum rule is called. The highest value is kept in a buffer. After comparing all numbers, the system copies the highest number into the variable field. There are two optional parameters:

  • Compare the largest value with the given value. If it is larger, return it. If smaller, use option two.
  • Take the field with the index specified in the next parameter. If the second parameter is not specified, return a SKIP message.
Note The system ignores the fields of the entry which usually contain the source offset and the source length. Instead, the system uses the offset and length specified in the data section. The search criteria and the extract field descriptors must be delimited by a single space. No other spaces are allowed.

Example

You could make the following entries in Studio in the Rule section of the field’s Properties window:

In this field... | Enter...
Rule | CompBin
Destination offset | 1
Source name | REC-MAXFINE
Source offset | 45
File | *
Length | 6
Record | *
Required | *
Overflow Multiplier | *
Overflow | *
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.


ConCat

Use this field level rule to concatenate two or more text strings contained in an extract record and place the result in a field you specify. This rule supports overflow.


DAL

Use this field level rule to get information from an extract file if certain conditions are met. In addition, this rule lets you call most of the DAL functions.

The DAL rule is similar to the IF rule except it returns only data, not another rule. For more information, see If.

You can specify a DAL script name by adding Call ("scriptname") in the Data field. It would look like this:

Call ("script.dal")

It is also possible to specify the rule data for the DAL rule in an external file. Name the file to include with a leading ampersand (&) in the data area, as shown here:

&data.inc

This loads the file, data.inc, from the current directory and inserts its contents into the rule’s data area. Note that the file should contain a single line, just as it would appear if you had typed the data directly into the rule data parameter. Also, if the include file is not in the current directory, the name must specify the correct path to locate the file.

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.

Changes in Version 11.4

Version 11.4 changed the way entries that specify a DAL rule are processed in the Extract Dictionary (XDD).

Normally, the ancestry Data fields are appended together to form a complete data representation for a field. When using the DAL rule, this behavior was often undesired. Now, the system assumes that the entry specifying the DAL rule contains all the data information required to resolve the necessary field value and ignores any values specified by an ancestor.

See also

  • If


DateDiff

This field level rule lets you display the difference between two dates. The dates do not have to be in the same format in the extract file, but the format of each must be supported. (The valid formats 1,7,10,11 will be described later.)

The dates and their formats are separated by a comma (,) and are defined in the Data field of the rule. For formats supporting a two-digit year, the 20th century (19xx) is assumed for date difference calculations. Date differences as a result of using this rule are not true in the sense that they are calculated under the following guidelines. These are sometimes referred to as bankers dates.

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


DateFmt

Note You should use the FmtDate, instead of this rule. This rule is included in this version of the system only for legacy system support.

Use this field level rule to format a date retrieved from an extract record based on the mask you select. A list of date masks appears below. This rule supports overflow.

Date masks

ID | Source | Destination | Also supported by FmtDate
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
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.

See also

  • FmtDate
  • Formatting Data
  • Field Rules Summary


EjectPage

Note This rule is only included in this version of the system for legacy system support. Master resource libraries (MRLs) created with Documaker Studio do not need this rule.

Use this field level rule to process multi-page FAP files (sections). With multi-page sections, when the section is added to the form set only one section object is created. When the section gets loaded, the system creates the other sections.

Syntax

EjectPage( )

This rule makes sure the pre- and post-section level processing is run for each section of the multi-page FAP file, not just the pre-processing on the first section and the postprocessing on the last.

When you run the FAP2MET utility on a multi-page FAP file, the utility creates a MET file for each page. In the DDT file, you should then make an entry for the FAP file and add an EjectPage rule for each additional page that makes up the form. The system knows by the EjectPage rules to look for additional FAP files for this form.


FfSysDte

Use this field level rule to get the current date from the system and place that date in the destination field. This rule supports overflow.

There are several output formats you can specify by entering a format ID in the rule’s Data field. Here's a list of the format IDs you can use:

ID | Output Format
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
Note Place the format ID immediately after the rule. This differs from other rule masks.

See also

  • SysDate
  • Formatting Data


FmtDate

Use this field level rule to format dates for different localities. This rule supports overflow. The mask for the FmtDate rule takes these values:

  • input fetype
  • input format mask
  • output fetype
  • output format mask

Format Masks

There are two types of format masks, pre-defined types 1-9 and A-Q and user-defined format arguments. If the pre-defined formats meet your needs, use them, otherwise, create a user-defined format. For information on using pre-defined format types, see Using Pre-defined Date Formats.

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.

You can enter up to 80 characters in the mask.

See also

  • DateFmt
  • Formatting Data
  • Field Format Types (fetypes)


FmtNum

Use this field level rule to format amounts for different localities. This rule supports overflow. The mask area takes these values:

  • input fetype
  • output fetype
  • output format mask

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.

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 USD (United States, English). See Field Format Types (fetypes) for a list of the supported localities. If your defined fetype is not one that is supported, the system uses USD.

Left justifying numbers

You can include the L parameter to left justify numbers after they have been formatted. This parameter is the fourth optional flag in the Mask field. For example, if you have this format mask

n,n,"z,zzz,zzz,zzz,zz9.99",L

and the extract data has an amount such as 123456.99, the system uses this rule to read the amount and formats this number to produce the result, 123,459.99. The rule will then left justify the field. Below is an example of the result with and without the L parameter.

Without the L parameter:

n,n,"z,zzz,zzz,zzz,zz9.99"

123,456.99

With the L parameter:

n,n,"z,zzz,zzz,zzz,zz9.99",l

123,456.99

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.

See also

  • Using Pre-defined Numeric Formats
  • Suppressing decimals with the FmtNum Rule
  • Using the ZeroText option with the FmtNum Rule
  • JustFld


GlobalFld

Use this field level rule to speed the processing of fields used repeatedly throughout a form set.

Frequently a field rule is called to retrieve the same record over and over, which slows batch processing. Using this rule helps you avoid unnecessary repetition and therefore speeds processing.

Note The name of the field in the FAP file (the field name in the XDB file) and the source name of the field in the XDB file must be identical for this rule to work correctly.

Syntax

GlobalFld ( )

To use this rule, you must have an XDB.DBF file. You set up the XDB file as shown in the examples below.

The Record field column in an XDB record can be just about anything. If you are importing the fields from a file, the system defaults the record field to the name of the source file you are importing.

If you import the fields from a COBOL Copybook, the record column field is assigned the name of the higher level group that owns the field.

Keep in mind that you cannot use the GlobalFld rule if the field data is not going to be global in scope. For instance, overflow and sub-extract situations where you expect the next occurrence of the field to get a different result are not candidates for the GlobalFld rule.

The SourceFile record member is not used in looking up XDB records. XDB records are looked up by the destination field name alone.

Note When using the GlobalFld Rule, the XDB record replaces the entire record. Remember, it is a global field, therefore the assumption is that all references to the field are identical. If you want to make common rule definitions, but override certain members in individual files, use the MASTER.DDT file instead of the GlobalFld rule.

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.

See also

  • Dictionary


HardExst

Use this field level rule to place a value into a field only if a record is found in the extract data using the search criteria you specify in the data field. This rule supports overflow.

Syntax

HardExst ( )

For instance, you could use this rule to see if there is a record in an extract file that corresponds to a field designating whether or not the applicant is a home owner. If the data exists in the extract record, the rule could then place an X in the Home Owner field.

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.

Search masks and overflow

Overflow affects how 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 this search mask:

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

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.

See also

  • JustFld
  • Mk_Hard
  • Search Criteria


If

Use this field level rule to get information from an extract file if certain conditions are met. In addition, the IF rule lets you call most of the DAL functions. For more information, see the FieldRule function in the DAL Reference.

You can specify a file name by adding &filename in the Data field.

The IF rule supports the FieldRule function to call every field rule in the IF rule. The FieldRule function requires as many parameters as are required for a field level rule. Not all fields must contain data, but you must include the correct number of delimiters.

Here is a list of field rule parameters. An asterisk indicates the parameter is generally required, depending on the rule you are using. If you leave a parameter blank, be sure to include two colons as delimiters (::) to indicate the parameter is blank.

Parameter | Description
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 |
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")

Using Curly Braces { }

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.

For more detailed information on writing DAL scripts and using DAL functions, see the DAL Reference.

See also

  • DAL


JustFld

Use this field level rule to justify (left, right, or center) a variable field by modifying its field coordinates.

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’s Properties window. The coordinates are specified as shown here:

The top coordinate is specified in the Vertical field. The bottom coordinate is the entry in the Vertical field, plus the entry in the Height field.

The left coordinate is specified in the Horizontal field. The right coordinate is the entry in the Horizontal field, plus the entry in the Width field.

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.

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 ofthe 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 option

Use of the LoadCordFAP option also affects the JustFld rule. The following table shows 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.

See also

  • ConCat
  • FfSysDte
  • FmtDate
  • FmtNum
  • Mk_Hard
  • Move_It
  • MoveExt
  • MoveNum
  • MoveSum
  • SAPMove_It
  • LookUp
  • TblLkUp
  • TblText
  • Overflow and User Functions


KickToWip

Use this field level rule 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 ( )

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.


LookUp

Use this field level rule to take data from an extract record. Next, use the data as a key name to look up the key data in a table. Then, copy the table data to the destination field. You must specify the offset of the key name in the data field, as well as the offset and length of the key data in the data field. This rule uses the same table as the MovTbl rule.

Syntax

LookUp ( )

You can use one or more files to keep the tables used by this rule. You must list each table (file) in the TABLEFILE.DAT file. The table list file must be in the following format:

TABLEFILENAME1.EXT <crlf>

TABLEFILENAME2.EXT <crlf>

where each table is listed on a single line followed by a carriage return/line feed.

The format of the tables is key name followed by key data. The key need not be a specific length. The data can also be any length, which allows a single table or group of table files to contain table entries of varying lengths.

You specify the table list file using the TblFile option under the Data control group in the FSISYS.INI file.

For example, suppose a form contains the names and numbers of agents for calling purposes, but these names and numbers change on a regular basis. For this situation you could create a text table called AGENTS.TBL which contains entries such as...

AGENT001 JOE MILLER <crlf>

and another table, called AGENTPHO.TBL, with phone number entries such as...

AGENT001PHONE404 111-2222 <crlf>

You could then make these tables available to Documaker Server by including them in the files specified in the Data control group of the FSISYS.INI file, as shown here:

< Data >

TblFile=.\deflib\TblFile.Dat

You must load the tables into memory before the system can use them. To do this, include these rules in the AFGJOB.JDT file:

;CreateGlbVar;1;TblLstH,PVOID;

;LoadTblFiles;1;;

See also

  • MovTbl
  • TblLkUp


MapFromImportData

Use this field level rule to map imported data from an internal dictionary to a field, as opposed to mapping from an extract file. Normally, you use this rule with either the ImportFile or ImportExtract rules, however, you can use this rule with any preceding rule that fills in field dictionary values.

By default, this rule checks for a dictionary value starting with the section dictionary, then the form dictionary, and finally the form set (global) dictionary. The search ends as soon as the rule finds a value for the field.

If no dictionary entry is found for the field, the field remains blank. Use the Required flags in the rule definition to control whether an empty field is considered an error.

Note For some legacy implementations, this rule was registered under the name NoOpImp.

If you do not use this rule, you must use the ReplaceNoOpFunc rule and make sure that all of the fields for each file are set to NoOpFunc.

Syntax

MapFromImportData ( )

You can use the optional INDEX parameter to specify a particular dictionary instance of the field to use. This is only useful if you use the ImportFile or ImportExtract rules to import form set data.

For the ImportFile rule, to support field instances you must include this INI option:

< ImportFile >

IndexDuplicateFields = Yes

For the ImportExtract rule, to support field instances you must include this INI option:

< ImportExtract >

IndexDuplicateFields = Yes

Normally, duplicate field entries found in the import file are ignored. If, however, you enter Yes, each instance is stored in a separate dictionary entry.

Note Field instance (indexing) only applies to field data stored in the form set (global) dictionary.

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.

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 section within the current form as the instance index. For example, if this field is contained on the third copy of section on the current form, then get the third instance of field data.
IMGFSET | Use the occurrence of this section within the entire form set as the instance index. For example, if this is the fifth occurrence of this section within the form set (without considering what forms contain the other copies of this section), 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 sections 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.

See also

  • NoOpFunc
  • ReplaceNoOpFunc
  • ImportExtract
  • ImportFile


Master

Use this field level rule to tell the system the field has been mapped in the MASTER.DDT (data definition table) file. Use this rule when you have variable fields which are used on multiple sections.

Instead of mapping these identical variable fields, like Name and Address, each time they are used, you can map them once in the MASTER.DDT file and then map the individual fields to the Master rule. This tells the system to look in the MASTER.DDT file for the complete mapping information for those variable fields.

Syntax

Master ( )


MessageFromExtr

Use this field level rule to retrieve a message from an extract file and place the message into a field on the form. Default formatting information comes from the definition of the field which you set up using Studio. Specific formatting information is embedded within the message using tags. This rule can also contain variable blocks of text.

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.


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 section. In the section (FAP file), you define the field to which the message is attached as a multiline 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 for Variables. 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 section (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.

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.

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

Do not 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>

<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

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

0 1 2 3 4 5 6 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


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.

Record Dictionary information is divided into two sections:

  • Record section, which describes the records
  • Variable Definition section, which describes the fields contained in the records

For more information about the Record Dictionary, see Using the Record Dictionary for Variables.

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)

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)

INI options

You must use the Name option to define the name of the Record Dictionary.

< DataDictionary >

Name = (file name of the Record Dictionary)

Place the Record Dictionary file in your DEFLIB directory.

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)

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)

*

*

==============================================================

See also

  • Using Condition Tables
  • Using the Record Dictionary for Variables


Mk_Hard

Use this field level rule to insert or hard code a value into a variable field. For instance, you can use this rule to place an X in a check box or to insert the text Same as above in a field on a form.

Syntax

Mk_Hard ( )

See also

  • HardExst
  • SetCpyTo


MNumExt

Use this field level rule 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.

See also

  • MoveNum
  • Using Pre-defined Numeric Formats


Move_It

Use this field level rule to move text from an extract record to the output buffer. This rule supports overflow. The format mask can contain these options:

Format

Description

B

Used for mapping a large data buffer with more than 1024 bytes into a multiline text field.

In flat file (non-XML) extract data, the size of the data buffer is limited to the value in the MaxExtRecLen option in your INI file.

Here is an example, based on mapping data from an XML extract file:

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

T

Include this flag to format the text in title case. This flag tells the system to capitalize the first letter in each word in the string and lowercase the rest of the letters in each word. See the Specifying Title Case - Example for more information.

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.

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.

Notes

  • 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 multiline variable field, make sure destination length is greater than one (1). Otherwise, no data will be mapped. This happens because when you create a multiline variable field, its length is zero (0) and its destination length 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 symbols

Let’s assume you have variable fields that represent amounts. The extract data is pre-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.

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.

Specifying Title Case - Example

Here is an example of how you can specify the T (title case) format flag in an extract dictionary definition.

Add the T format flag in the Mask field. Be sure to separate multiple format flags with commas:

You can also specify this format flag in the field's rule mapping in the Section manager by adding the T format flag in the Mask field:

Note The Section manager example shows the T format flag used with the XDD rule. The presumption is that when the dictionary element is found, the resulting rule will be the Move_It rule. Adding the T format flag here overrides any mask defined in the XDD definition.

Here are some examples of what happens when you include the T format flag:

This text | Is changed to
11 paces ferry road | 11 Paces Ferry Road
SAM DOE | Sam Doe
Marquis de Lafayette | Marquis De Lafayette
George O’Brien | George O’brien
This is the Title Case Option | This Is The Title Case Option

Keep in mind:

  • In some cases, the use of this formatting flag can result in unwanted changes.
  • The T format flag will work on Unicode text that has upper and lower equivalents. If the text characters are for a language that does not have such distinctions, like certain Asian character sets, then those Unicode characters will not be modified.
  • You can enter several format flags in the Mask field of the Move_It rule. If you include conflicting format flags, the last one determines the results. For instance, if you specify both this flag and the Uppercase format flag (T,U) in that order, the result is upper cased, because the U is the last flag specified.

See also

  • MoveExt
  • Extracting data
  • Search Criteria


MoveExt

Use this field level rule to move text from a specific external extract record to the output buffer if a specific external record is found. This rule calls the Move_It rule if the specified extract record is found. This rule supports overflow.

A string in the format mask that is preceded by a dollar sign ($) is used as a sprintf format for output data. You cannot use this feature with a format mask ID.

User functions let data move 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, and follow the syntax described below.

In this example the user function name is GetRecsUsed. It has two parameters FormName, and VAR. The slash (/) denotes the end of the parameter list and the start of the search criteria.

MoveExt @GETRECSUSED,FormName,VAR/17,00,15,B

See also

  • Move_It
  • Search Criteria


MoveNum

Use this field level rule to move numeric data from an extract record to the output field and, if necessary, reformat the data. This rule supports overflow.

The numeric data this rule handles is limited to 15 significant digits. This is a total of all the digits, both to the right and left of the decimal. Here are some examples:

999,999,999,999,999.

.999,999,999,999,999

999,999,999.999,999

The system tries to honor almost any format you supply, but when a conversion has to occur, it can only guarantee 15 significant digits in the result.

The first part of the format mask must contain the input numeric format (X.Y) followed by the output numeric format (X.Y), where X is the size of the number, including any commas, currency symbols, and decimal places, and Y is the number of digits after the decimal. For example, a simple format mask can look like this:

10.2,15.2

This tells the system the input string consists of ten characters and the last two characters are decimals, such as 1234567890. The output string should consist of 15 characters, including two decimals.

To format the output, you can also include any of the following format options after the output numeric format (separate each option with a comma).

Format mask

Mask

Description

-

(one dash) If the number is negative, this option places a minus sign (-) in the left most position. For example, if the format mask is (9.2,12.2,C,$,-), the result is: “- $2,100.00”.

--

(two dashes) If the number is negative, this option places a minus sign (-) immediately before the amount. For example, if the format 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. 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.

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

CS2

CS731

Enter one of these options to indicate the checksum method.

The system appends a check digit (mod 10) of 0 through 9 to the end of the 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 Checksum Methods.

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

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.

-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

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

Checksum Methods

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.

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.

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.

Note You can use format E to stop the calculation when the search condition is false.

See also

  • MNumExt
  • Search Criteria


MoveSum

Use this field level rule to add two or more fields and insert the result into a new field.

This rule uses the Record Dictionary table to get the search criteria, offset, length and type for the variables specified in the Data field. It then performs an addition on the information retrieved from extract file. The output sum is formatted according to the format specified in the format mask.

To apply this rule, you must define the record, offset, length, and type for the variables in the Record Dictionary table. For more information about the Record Dictionary, see Using the Record Dictionary for Variables. An example of the Record Dictionary table is as follows:

* This is the Record Dictionary table

<Records>

Account = Search(PMSP0200,17)

<Variables>

TBAL = Record(Account) Offset(18) Length(12) Type(Zone) Precision(2)

TBAL2 = Record(Account) Offset(38) Length(8) Type(Zone) Precision(2)

The name of the data dictionary file must be defined in the DataDictionary control group as shown here:

< DataDictionary >

Name = DataDict.Tbl

The path for the table files must also be defined in the MasterResource control group as shown here:

< MasterResource >

TablePath = .\MstrRes\TblLib\


MovTbl

This field level rule works similarly to the Move_It rule, except records are taken from the table list of records stored in memory instead of the extract records list from which many of the other rules get data.

One or more files may be used to keep tables used by this rule. Each table (file) must be listed in the table list file specified in the Data control group with the name TBLFILE. This table file list file must be in the following format:

TABLEFILENAME1.EXT <crlf>

TABLEFILENAME2.EXT <crlf>

Each table file name is listed on a single line followed by a carriage return/line feed. The format of the table itself is a key name followed by key data. The key need not be a specific length nor the data, which allows for a single table or group of table files to contain table entries of varying lengths.

For example, suppose a form contains the names and numbers of agents for calling purposes, but these names and numbers change on a regular basis, this situation lends itself to the use of text tables. A table might be created called AGENTS.TBL that contains table entries such as the following:

AGENT001 JOE MILLER <crlf>

and another table called agentpho.tbl with phone number entries such as:

AGENT001PHONE404 111-2222 <crlf>

You could then make these tables available to Documaker Server by including them in the file specified by the TblFile setting in the FSISYS.INI file.

You specify the table file name in the Data control group of the FSISYS.INI file as follows:

< Data >

TblFile = .\deflib\TblFile.Dat

These tables must first be loaded into memory before the system can use them. To do so, the following rules must be in the AFGJOB.JDT file:

;CreateGlbVar;1;TblLstH,PVOID;

;LoadTblFiles;1;;

See also

  • Move_It
  • LookUp
  • TblLkUp


NoOpFunc

This field level rule is useful when you are developing new forms because it lets you map all fields and systematically test each field by replacing the NoOpFunc rule with the actual rule you want to use.

If a particular field level rule keeps failing, you can use NoOpFunc to temporarily replace the original rule and process the form without error until you can evaluate and solve the problem.

Note The field on the form will be blank after processing with this rule.


OvActPrint

Use this field level rule to report the actual number of overflow records that could be processed per transaction for the overflow section.

Syntax

OvActPrint (Section,OvSymbol)

Parameter | Description
Section | Name of the overflow section
OvSymbol | Name of the overflow symbol defined by the SetOvFlwSym rule

For instance, assume an overflow section 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.

See also

  • Overflow and User Functions
  • PurgeChartSeries
  • SetImageDimensions


OvPrint

Use this field level rule to report the maximum number of overflow records that could be processed per transaction for the overflow section.

Syntax

OvPrint (Section,OvSymbol)

Parameter | Description
Section | Name of the overflow section
OvSymbol | Name of the overflow symbol defined by the SetOvFlwSym rule

For instance, assume an overflow section 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.

See also

  • IncOvSym
  • SetImageDimensions


PowType

Use this field level rule to force a transaction to manual batch (WIP). The PowType rule sets the manual batch flag to true. To edit the field associated with the PowType rule in the Entry system, you must set the required flag to operator for the field.

Syntax

PowType ( )

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.


PrintIf

Use this field level rule to determine what text should be placed into the output buffer. The PrintIf rule compares a character string from the extract record to the character string specified in the user-defined condition contained in the data field.

This rule does not support comparison of data strings that contain all numeric characters. This rule does supports overflow.

Note The PrtIfNum rule does support comparison of data strings that contain all numeric characters.

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.

See also

  • JustFld
  • PrtIfNum


PrtIfNum

This field level rule is similar to the PrintIf rule. The difference is the PrtIfNum rule compares the data to a number while PrintIf compares data to a character string.

A MoveNum action is performed on the value from the extract record and the resulting value is compared to the value in the user-defined conditions to determine what text should be placed in the output buffer. This rule supports overflow processing.

A user-defined condition is comprised of one or more user-defined definitions separated by a colon (:). A user-defined definition is comprised of these two items separated by an equal sign (=):

  • This item is comprised of a logical operator and numeric value to be used in the comparison. The logical operators supported are:
Operator | Description
= | equal to
> | 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.
  • 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.

Defining the MoveNum parameters

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.

See also

  • MoveNum
  • PrintIf


RunDate

Use this field level rule to get the run date from the transaction data (TRNFILE.DAT file) and format that date using the mask you specify.

The mask on the RunDate rule supports the following syntax:

A number (between 1 and 10 for compatibility with prior releases) and this format: DinFmt:outFmt

The D indicates a date conversion using the new method. Here is a list of the date formats you can choose:

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 formats which consists of a format character, optional date separator, and an optional year size (2 or 4). | outFmt is also a standard date format for the destination field and is separated from the inFmt by a colon (:).

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.

Note The run date is typically stored in YYYYMMDD format and therefore does not require any locale information on the input format.

See also

  • Formatting Data


SAPMove_It

Use this field level rule for a Move_It type of operation on an SAP Raw Data Interface (RDI) extract file. This rule supports overflow.

Format mask

The format mask can consist of these options:

C Center the text

R Right justify the text (for non-proportional fonts only)


SetAddr

Use this field level rule to store and retrieve subsequent lines of a multiple line address. This rule is useful if you are setting up an address which may have three or four lines of information. For instance, some addresses include a suite or apartment number. If one of the middle address lines is missing, the SetAddr rule will format the address to omit any white space or blank lines. This rule supports overflow.

The first time the rule is called, the format mask field must contain an F. This initializes the function and loads the address lines into an array. The system then returns the first line of the address data. Subsequent address variable fields should contain an N in the format mask field and return the next available non blank address line from the array.

The data element should contain the parameters necessary to get the multiple lines that make up the entire address record. Use of overflow with this rule only pertains to calls which have the format mask field set to F.

The data element has two parts, the first is the search criteria to get the extract record which contains the address information. The second part, separated from the first by a space, consists of offset,length pairs of address information.

When the address table is built, if one of the address lines consists of all blanks no entry is made in the address table. This lets you remove blank lines in an address.

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.
S | Suppresses the state from the last address line.
U | Converts the data returned by the rule into uppercase.

See also

  • SetAddr2
  • SetAddr3


SetAddr2

Use this field level rule to store and retrieve subsequent lines of a multiple line address. This rule is similar to the SetAddr rule in that it also omits blank lines from an address. The SetAddr2 rule, however, also formats the city, state, and postal code and adds a dash if you have a 10-digit ZIP code (ZIP+4). For instance, this rule automatically formats the city, state, and ZIP code as follows:

AtlantaGA 30333 (one space between state and ZIP code)

You can also specify additional formatting. For instance '^,','^' in the Data field (where ^ represents a space) tells the system to format the text as shown here:

Atlanta, GA 30333 (one space between the comma and the state, two spaces between the state and ZIP code)

In addition, you can also specify an S flag in the Data field to tell the system to suppress the state from the last address line. If you include this flag, the text is formatted as shown here:

Atlanta, 30333 (state code is suppressed)

The first time you call this rule, the format mask field must contain an F. This initializes the function and loads the lines of the address into an array. The system then returns the first line of the address data. Subsequent address variable fields should contain an N in the format mask field and return the next available non blank address line from the array.

The data element contains the parameters necessary to get the address record. The last three fields (city, state, postal code) are stored in one field. The various address data element mapping comes from the first record's data element (after the record mapping). This rule supports overflow.

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.

See also

  • SetAddr
  • SetAddr3


SetAddr3

Use this field level rule to handle a three-line address with six components, as shown here:

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

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.

See also

  • SetAddr
  • SetAddr2


SetState

Use this field level rule to translate a numeric ISO code retrieved from an extract record into its equivalent state text. This rule supports overflow.

State table

Code | State | Code | State | Code | State
01 | Alabama | 54 | Alaska | 02 | Arizona
03 | Arkansas | 04 | California | 05 | Colorado
06 | Connecticut | 07 | Delaware | 08 | District of Columbia
09 | Florida | 10 | Georgia | 52 | Hawaii
11 | Idaho | 12 | Illinois | 13 | Indiana
14 | Iowa | 15 | Kansas | 16 | Kentucky
17 | Louisiana | 18 | Maine | 19 | Maryland
20 | Massachusetts | 21 | Michigan | 22 | Minnesota
23 | Mississippi | 24 | Missouri | 25 | Montana
90 | Nationwide | 26 | Nebraska | 27 | Nevada
28 | New Hampshire | 29 | New Jersey | 30 | New Mexico
31 | New York | 32 | North Carolina | 33 | North Dakota
34 | Ohio | 35 | Oklahoma | 36 | Oregon
37 | Pennsylvania | 58 | Puerto Rico | 38 | Rhode Island
39 | South Carolina | 40 | South Dakota | 41 | Tennessee
42 | Texas | 43 | Utah | 44 | Vermont
45 | Virginia | 46 | Washington | 47 | West Virginia
48 | Wisconsin | 49 | Wyoming |  |


StrngFmt

Use this field level rule to format a string retrieved from an extract record, based on a given format string. The StrngFmt rule is useful for formatting Social Security numbers and phone numbers. This rule supports overflow.


SysDate

Use this field level rule to format the system date. Using this rule you can format the system date for different localities. This rule supports overflow.

The mask area for the SysDate rule takes these values:

  • output fetype
  • output format mask

Format Masks

There are two types of format mask, pre-defined types 1-9 and A-Q and user-defined format arguments. If the pre-defined formats meet your needs, use them, otherwise, create a user-defined format. For information on using pre-defined format types, see Using Pre-defined Date Formats.

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.

Example

Assume the system date is 03-01-2009, which is a Monday, and the time is 11:57 am.

The format mask of:

d, “4/4

formats the system date using format 4, with month spelled out, such as March 1, 2009.

To produce a Canadian French date, such as mars 1, 2009, use the following format mask:

DCAD, “4/4

The following format, which uses format arguments, will produce the same output:

dCAD, “%B %#d, %Y

Format arguments let you include the day of the week, hour, minute, second, and so on. This table shows you the results using various formats:

Format | Result
%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
 | 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

See also

  • FfSysDte
  • Field Format Types (fetypes)
  • Formatting Data


TblLkUp

Use this field level rule to find the record in a table file that matches the first specification you supply. After the system finds that record, it uses the offset you specify to get a key. It then uses the key to look up a final record and return the result.

Specify the table file you want to use in the FSISYS.INI file, as shown here:

< Data >

TblFile=.\deflib\TBLFILE.DAT

Keep in mind that all tables you specify in the TBLFILE.DAT file are loaded into memory sequentially. This is then used to search for the final record. If your search mask and key are not unique, you may end up with an incorrect result.

For instance, in the TBLFILE.DAT file you could see a list of the files similar to this one:

.\deflib\ADETAILS.TBL

.\deflib\AGENTINFO.TBL

.\deflib\AQUESTION.TBL

.\deflib\FDETAILS.TBL

Specify the source file you want the system to search in the File field by entering a number that represents the position of the file in the list. For instance, if you want a field to look something up in the AGENTINFO.TBL file, you would enter two (2) in the File field.

Note The Record property is not part of the XDD layout. If you leave the File property equal to zero (0), the system uses the table index value in the XDD.

Here is an example:

You can use the Mask field to specify a default look up value. It is not a standard mask like that used in the Move_It rule.

Note The size of a table row is set in the MaxExtRecLen option in the Trn_File control group. The maximum size is 1024 characters.

To use this rule, these rules must be in the AFGJOB.JDT file:

;CreateGlbVar;1;TblLstH,PVOID;

;LoadTblFiles;1;;

See also

  • LookUp
  • MovTbl
  • XDD


TblText

Use this field level rule to get a text table item based on a key built from the source field name concatenated with the data retrieved from the source record. This rule supports overflow. Keep in mind these considerations, which pertain to the external ASCII text table referenced by this rule.

  • Keys can be up to 12 characters in length.
  • The key begins in position 1 in the text file.
  • The returned text begins in position 14 in the text file.
  • Only the first occurrence of the match is returned to the caller.

Each data line in the text table file must follow the following format:

KEY;ENTRY

where KEY is a value of up to 12 characters, padded right with spaces. ENTRY is the text data associated with the key entry.

Note All support for this rule resides in a single table file. You specify the name of this file in the FSISYS.INI file in the TEXTTBL option in the Data control group.


TerSubstitute

Use this field level rule to emulate TerSub entry functionality. You add this rule to a multiline text field that has been designated as one which can grow.

Syntax

TerSubstitute (Key1,Key2,FormName,Recipient)

Parameter | Description
Key1 | Enter the name of Key1, such as Key1=AccountNo.
Key2 | Enter the name of Key2, such as Key2=Name.
FormName | Enter the name of the form, such as FormName=XYZ.fap
Recipient | Enter the name of the recipient, such as Recipient=Agent.
Note For all parameters, you can use the names of GVM variables instead of actual values.

The text to include in TerSubstitution is stored in the text areas of the sections. The sections are listed in the FORM.DAT file under a dummy Key1, Key2, and FormName. The rule finds the entry in the FORM.DAT file for the Key1,Key2,FormName parameters and uses the text from any sections with the supplied recipient.


UnderlineField

Use this field level rule to draw an underline beneath a variable field.

The system does not store the line in the NAFILE.DAT file. Instead, it turns on the underline attribute (U) in the option field of the NAFILE record. You will not see the underline in the NAFILE.DAT file.

Syntax

UnderlineField (FieldName)

To underline multiple variable fields, you must make an entry for each field.

Note This rule does not work with sections which have the copy on overflow attribute enabled.


XDB

Use this field level rule to tell the system the field has been mapped in the XDB database. Use this rule when you have variable fields which are used on multiple sections.

Note You should use the XDD, instead of this rule. This rule is included in this version of the system only for legacy system support.

Syntax

XDB ( )

Instead of mapping these identical variable fields, like Name and Address, each time they are used, you can map them once in the XDB database and then map the individual fields to the XDB rule. This tells the system to look in the XDB database for the complete mapping information for those variable fields.

Keep in mind, however, that these fields do not exist in the dictionary:

  • SrcFile (source file)
  • SrcRec (source record number)

The SrcFile is saved as a number, not an actual file name. It is used in the TblLkup rule and becomes the index to use to find the table you want to look into for this rule.

So, if you want to use the TblLkup rule, you must define this source file variable within the field map definition.

Similarly, to reference a specific source record, you must define SrcRec in the field’s mapping. For example, you may have an overflow detail record which is identified by 1,Detail. For a certain field, however, you want the data from the second detail record to be mapped. In this case, the mapping for this particular field must contain a SrcRec. Otherwise, the data from the first record will be used.

Mapping

You can include an asterisk (*) to tell the system to add a space before it concatenates the search masks. This makes the XDB and token lookup more flexible and lets you use XML for parent/child mapping.

The child can also be another search mask or XPath, instead of just being the rule parameter. To maintain the same search mask for the Child as that shown in the above example, however, you must add an asterisk (*) in front of the Child's data if it was used as a rule parameter.

You must also set up a correct search mask (XPath) syntax if a child's parent references another parent.

Note The use of an asterisk was added in version 11.0. Prior to this change, the system automatically added a comma for you. To make this work for all implementations, the system cannot assume a comma is always needed. For example, an XML implementation would not want a comma added before the two XPaths are appended together.
Name | Parent | Rule | Data
Child1 | Parent2 | PrintIf | *A=Accident:C=Casualty
Child2 | Parent1 | Move_It | ,35,ZZZ
Parent2 | Parent1 |  | ,20,ABC
Parent1 |  |  | 1,HEADREC

Child1 - 1,HEADREC,20,ABC A=Accident:C=Casualty

Because there is no asterisk in Child2's data, the complete search mask for Child2 becomes:

1,HEADREC,35,ZZZ.

Here is an example for the XML implementation:

Name | Parent | Rule | Data
Child1 | Parent2 | PrintIf | *A=Accident:C=Casualty
Child2 | Parent1 | Move_It | /JHI
Parent1 |  |  | !/ABC
Parent2 | Parent1 |  | /DEF

In this example, the mapping for Child1 becomes:

!/ABC/DEF A=Accident:C=Casualty

The mapping for Child2 becomes:

!/ABC/JHI

In addition, you can name a parent within each child. The way you specify this is similar to the way used for token lookup — the Data field contains necessary information. Here is an example:

?Child/Parent

For the XDB rule, the source field name would contain this set up without a question mark. Here is an example:

;0;0;Child/Parent1;0;0;Child;0;20;;XDB;;N;N;N;N;7577;2273;11114;

Name | Parent | Rule | Data
Child | Parent1 | PrintIf | *A=Accident:C=Casualty
Child | Parent2 | Move_It | /JHI
Parent1 |  |  | !/ABC
Parent2 |  |  | !/ABC/DEF

The mapping for Child/Parent1 is:

!ABC A=Accident:C=Casualty

The mapping for Child/Parent2 is:

!/ABC/DEF/JHI

See also

  • Formatting Data with the = Operator
  • TblLkUp


XDD

Use this field level rule to tell the system the field has been mapped in the XDD database. Use this rule when you have variable fields which are used on multiple sections.

Note The XDD and XDB rules are synonymous. When encountered in a Studio MRL, the XDD is used from the library. If these rules are used in a MRL that is legacy-based, the XDB database is used.

Syntax

XDD ( )

Instead of mapping these identical variable fields, like Name and Address, each time they are used, you can map them once in the XDD database and then map the individual fields to the XDD rule. This tells the system to look in the XDD database for the complete mapping information for those variable fields.

Mapping

You can include an asterisk (*) to tell the system to add a space before it concatenates the search masks. This makes the XDD rule and the token lookup more flexible and lets you use parent/child mapping.

The child can also be another search mask or XPath, instead of just being the rule parameter. To maintain the same search mask for the Child as that shown in the above example, however, you must add an asterisk (*) in front of the Child's data if it was used as a rule parameter.

You must also set up a correct search mask (XPath) syntax if a child's parent references another parent.

Note The use of an asterisk was added in version 11.0. Prior to this change, the system automatically added a comma for you. To make this work for all implementations, the system cannot assume a comma is always needed. For example, you would not want a comma added before the two XPaths are appended together.
Name | Parent | Rule | Data
Child1 | Parent2 | PrintIf | *A=Accident:C=Casualty
Child2 | Parent1 | Move_It | ,35,ZZZ
Parent2 | Parent1 |  | ,20,ABC
Parent1 |  |  | 1,HEADREC

Child1 - 1,HEADREC,20,ABC A=Accident:C=Casualty

Because there is no asterisk in Child2's data, the complete search mask for Child2 becomes:

1,HEADREC,35,ZZZ.

Here is an example:

Name | Parent | Rule | Data
Child1 | Parent2 | PrintIf | *A=Accident:C=Casualty
Child2 | Parent1 | Move_It | /JHI
Parent1 |  |  | !/ABC
Parent2 | Parent1 |  | /DEF

In this example, the mapping for Child1 becomes:

!/ABC/DEF A=Accident:C=Casualty

The mapping for Child2 becomes:

!/ABC/JHI

In addition, you can name a parent within each child. The set up is similar to that used for token lookup. When using token lookup, the data's portion contains the set up for this. Here is an example:

?Child/Parent

For the XDD rule, the source field name would contain this set up without a question mark.

Name | Parent | Rule | Data
Child | Parent1 | PrintIf | *A=Accident:C=Casualty
Child | Parent2 | Move_It | /JHI
Parent1 |  |  | !/ABC
Parent2 |  |  | !/ABC/DEF

The mapping for Child/Parent1 is:

!ABC A=Accident:C=Casualty

The mapping for Child/Parent2 is:

!/ABC/DEF/JHI

Example

You could make the following entries in Studio in the Rule section of the Field Options panel:

In this field... | Enter...
Rule | XDD
Destination Offset | *
Source Name | Name
Source Offset | *
File | *
Length | *
Record | *
Required | *
Overflow Multiplier | *
Overflow | *
Mask | *
Data | *
* No entry is required unless you intend to override the setting that will be inherited when the source field is found in the XDD.

The source file is saved as a number, not an actual file name. It is used in the TblLkup rule and becomes the index to use to find the table you want to look into for this rule. So, if you want to use the TblLkup rule, you must define the source file using the File field under Rule properties.

Note The Record property is not part of the XDD layout. If you leave the File property equal to zero (0), the system uses the table index value in the XDD.

Similarly, to reference a specific source record, you must define SrcRec in the field’s mapping. For example, you may have an overflow detail record which is identified by 1,Detail. For a certain field, however, you want the data from the second detail record to be mapped. In this case, the mapping for this particular field must contain a SrcRec. Otherwise, the data from the first record will be used.

Note SrcRec is only necessary if you know the specific instance of the data that you wish to use. Typical overflow can be mapped in the XDD and does not involve the SrcRec mapped at the field level.

See also

  • Formatting Data with the = Operator
  • TblLkUp


Appendix: Condition Tables and the Record Dictionary

In this appendix, you will find information about...

  • Using Condition Tables
  • Using the Record Dictionary for Variables
  • Record Dictionary Rules


Using Condition Tables

Condition tables provide a simple and efficient way to set conditions. The system reads the conditions from an input file and then uses those conditions to trigger sections. When the system receives a file of conditions which are used by the rules, it then...

  • Compiles the conditions for evaluation
  • Evaluates the conditions for each transaction


Setting Up the INI Files

To use the Condition tables, you must make these changes to your FSISYS.INI file.

  • Enter the path for your table files in the MasterResource control group. Use the TablePath option to define your table files path:

< MasterResource >

TablePath = \T4\UtilTest\MstrRes\TblLib\

  • Enter the name of your Condition table file in the Tables control group. Use the Conditions option to define the Condition table’s file name:

< Tables >

Conditions = CondTbl.tbl


Using a Record Dictionary File

Condition tables use the Record Dictionary to resolve variables. See the Using the Record Dictionary for Variables for more information.

Here is an example from the Record Dictionary:

* These are the Record definitions

<Records>

Account = Search(61,02)

MeterRead = Search(61,03) Repeating

Detail = Search(61,18) Repeating

* These are the variable definitions

<Variables>

ACSA = Record(Account) Offset(487) Length(10) Type(Zone) Format(14.2,C)

BMV1 = Record(Message) Offset(159) Length(15) Type(Char)

DTV1 = Record(Detail) Offset(181) Length(18) Type(Zone) Format(18.2,C)

CustomerType = Record(Detail) Offset(100) Length(1) Type(Char)

BIGTEST = Record(Detail) Offset(253) Length(18) Type(Zone) Format(18.2,C)

RPN(BIGTEST 5 * 30.55 + DTV3 + DTV5 -)


Creating a Conditions File

Conditions consist of combinations of comparisons, parentheses, and ANDs, and ORs to verify the correct results. Conditions are stated in this format:

ConditionName : {valid conditions}

Conditions can use the following:

  • Variable names from the Record Dictionary
  • Quoted strings
  • Numeric constants
  • Comparison operators, such as <, >, =, <=, >=, <>, !=, !<, and !>
  • ANDs
  • ORs
  • Parentheses ( )
  • Reserved words, such as ZERO and SPACES

Here are some examples:

Cond1 : ACSA > 9900 OR (ACSC = 4173 AND DTAT = ZERO)

Cond2 : (DTV1 = 3936.50 OR DTAT > 1) AND (DTV1 > -2 OR DTAT = 0)

Cond3 : (BMV1 <> SPACES AND ( DTVM1 = "CREDIT" OR DTAT > 0 AND BMV1 = "PAYMENT"

Cond4 : CustomerType = "A"

Note The variables used above are defined in the Record Dictionary example.


Occurrence Counting

Occurrence counting uses the following format:

OccurName : OCCURRENCE(RecordName,ConditionName) MAX(Count)

Here is an example:

Occur1 : OCCURRENCE(Detail,Cond4)

The record Detail and the condition Cond4 are used above as defined in the previous examples. The occurrence condition Occur1 is driven by the record named Detail. The record must be of Repeating type.

The condition Cond4 references the variable CustomerType. CustomerType is defined on the Detail record. There must be a connection between the record and a variable in the condition for the occurrence count to work correctly.

<Conditions>

MSG1 : LNPRTY < 10000

MSG2 : LNPRTY >= 10000

MSGTRGR1 : Occurrence(Message, MSG1)

totcurrchrg : DTLSECTION = "01" and LNPRIORITY != 00625

totamtdb : TOTAL >= 0 AND BBFLAG = "N"

env : EDIVERT ="0"

emitgrapha : GRAPHTRUE = "28" AND SCALETRUE = "29" AND BUDBLTRUE = "N"

*Triggers grouping for Tariff, Rider and Detail records

IAMBDTLA : DTLKeyProd = TARKeyProd and DTLTarSeqNo = TARTarSeqNo

REMAINDER : USAGEREM != 0

REGTARIFF : Occurrence(Tariff, REGBUS)

REGBUS : CDBUS != "0700" and CDBUS != "0100"

Setting a maximum count to return

Include the MAX parameter if you want to set a maximum count to be returned. Here is an example of the format for occurrence counting. Here is an example:

Occur1 : OCCURRENCE(Detail,Cond4) MAX(5)

Assume Cond4 is defined as shown here:

Cond4 : CustomerType = "A"

The occurrence condition Occur1 is driven by the record named Detail. The record must be of Repeating type.

Condition tables and the RecipCondition rule

One example of using Condition tables is to call the RecipCondition rule. In the SETRCPTB.DAT file, call the rule, as shown here:

;ORACLE;REGION2;REG;;01;;;M0;0;0;0;;RecipCondition;Cond1;

;ORACLE;REGION2;REG;;01;;;M0;0;0;0;;RecipCondition;Occur1;


Using the Record Dictionary for Variables

The Record Dictionary lets you define and access variables easily and efficiently. Variables are loaded from the extract file according to their definitions in the Record Dictionary file. You can use the Record Dictionary any time you need data from the extract list. The data can be in a numeric, character, or date format.

The Record Dictionary definitions are loaded from a text file. The variables can be referenced by name once the dictionary file has been loaded. For instance, used with Condition tables, any variable in the Record Dictionary can be used in a conditional evaluation.


Setting Up the Record Dictionary

Enter the path for your table files under the MasterResource control group in the FSISYS.INI file. Use the TablePath option to define your table files path:

< MasterResource >

TablePath = \T4\UtilTest\MstrRes\TblLib\

Enter the name of your Record Dictionary file in the DataDictionary control group. Use the Name option to define the Record Dictionary file name:

< DataDictionary >

Name = DataDict.Tbl


Record Dictionary File

The Record Dictionary must be populated with the variables you want to use. The file consists of two parts:

  • <Records> section
  • <Variables> section

Records

The record parameters are defined in the format:

RecordName = SEARCH(Column,SearchMask) {Repeating}

Parameter | Description
RecordName | The name that future references to this record will use.
Column | The column number that will be searched.
SearchMask | The text to look for in the column.
Repeating | (Optional) Can be set for any record that is of repeating type. You must set this flag when you are using the pointer to reference multiple records.

Variables

The variable parameters are defined using this format:

VariableName = Record(RecordName) GVM(GVM_Variable) Offset(Offset)
Length(Length) Type(TypeVariable) Format(FormatFlags)
Rule(RuleName) Data(RuleData) Precision(Precision)
RPN(RPN Equation)

Parameter | Description
VariableName | The name future references to this variable will use. A variable name begins with an alpha character and can consist of up to 30 characters.
RecordName | The previously defined record (from the Record section) on which this variable will be found.
GVM_Variable | The name of the global variable to use.
The RecordName and GVM_Variable parameters are mutually exclusive.
Offset | The offset into the record where the data is located.
Length | The length of the data.
TypeVariable | (Optional) Char, Num, Zone, or Packed. Char is character data. Character data can be any string of alphanumeric characters and symbols. Num is numeric data. Numeric data can have a sign in front and a decimal place. Zone is zoned decimal. Zoned decimal looks like a numeric value except the sign is added to the last digit. Packed is packed decimal. Packed decimal is a binary format used mainly on z/OS systems.
FormatFlags | (Optional) Similar to the flags used with MoveNum rule except the input flags, such as input length and precision, S, and B, are not needed.
RuleName | (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 specify them. If you omit the rule, the Move_It rule functionality is the default.
RuleData | (Optional) Any required rule data for the RuleName entry.
Precision | (Optional) The number of decimal places for a numeric variable.
RPN Equation | Reverse Polish Notation function. See the RPN Function section below.
Note Include a single space between variable parameters. A carriage return indicates the end of the variable definition. If you omit the length of a GVM-based Record Dictionary variable in the Record Dictionary entry, the system uses the length of the source GVM variable.


RPN Function

The RPN (Reverse Polish Notation) function handles mathematical operations in the Record Dictionary. The RPN function is used as a parameter of a variable in the Record Dictionary. Use Reverse Polish Notation to express your equation. Any variables that are referenced must be previously defined in the Record Dictionary.

  • Compile the RPN equation into a linked list.
  • Retrieve information from Record Dictionary for each variable.
  • Evaluate the equation and return the resulting value.

Use the format:

RPN(valid RPN equation)

A valid RPN equation can include: variables, numeric constants, arithmetic operators (+,-,*,/,%), and several functions (MOD, ABS, DUP, SWAP, POW, SQRT, CEIL, FLOOR). When using a function, place a ‘#’ sign before the function name (example: #MOD). This distinguishes a function name from a variable name.

RPN can also be used with date format variables. This can be useful when adding to a date or calculating an age. Here are some examples:

  • BIGTEST = Record(Detail) Offset(253) Length(18) Type(Zone) Format(18.2,C) RPN(BIGTEST 5 * 30.55 + DTV3 + DTV5 -)
  • LittleTEST = Type(NUM) RPN(BIGTEST 5 * ) Format(18.2,C)
  • SumTest = Type(num) RPN(BigTest LittleTest + #ABS)

RPN or Reverse Polish Notation is an arithmetic method that performs calculations from left to right. A stack is created to hold numeric values until an operation is performed. For instance, a simple equation such as “ 1 + 2 ” would be represented as “ 1 2 + ”. During computation, the stack would first hold “1”, then it would be given “2”. When the “+” is reached, the “1” and “2” are taken off the stack and added together. A slightly more complicated equation such as “ (1 + 2 ) * 5 “ would be represented as “ 1 2 + 5 * ”.

Note No parentheses are needed in RPN logic.

Available RPN functions

These are the available functions in RPN. When using them, remember to place a “#” sign in front of the function name. This distinguishes a function name from a variable name.

Function | Description
ABS | References the most recent value and returns the absolute value of that number.
CEIL | Returns the next largest integer value of a number (round up).
DUP | Creates a duplicate of the top value in the stack.
FLOOR | Returns the next smallest integer value of a number (round down).
MAX | Compares the top two values on the stack and returns the larger.
MIN | Compares the top two values on the stack and returns the smaller.
MOD | Performs a division with the top two values on the stack and returns the remainder.
POW | Removes the top two values in the stack. Calculates the first to the power of the second.
SQRT | Returns the square root of the number.
SWAP | Removes the top two values in the stack and replaces them in reverse order.


Record Dictionary Rules

You can use the following rules to reference the Record Dictionary and its contents. The system loads variables from the extract file based on the variable definitions in the Record Dictionary file.

You can use the Record Dictionary any time you need data from the extract list. The data can be in a numeric, character, or date format.


Base_FromDataDictToGVM

Use this rule to copy a Record Dictionary value into a global variable. Place this rule in the AFGJOB.JDT file.

Syntax

;Base_FromDataDictToGVM;; GVM(GlobalVariableName) DATA(DataDictVariableName);

Example

;Base_FromDataDictToGVM;;GVM(STATION1) DATA(OMR1);


FromDataDict

Use this rule to get data from variable fields from the Record Dictionary.

Syntax

;FromDataDict;DataDictVariableName {MoreOptionalVariables};;

Example

;0;0;KWH-ON-COM;0;0;KWH-ON-COM;0;10;;FromDataDict;ComkWh "and " ComkWh2;N;N;N;N;2446;1218;16229;


FromDataDictToGVM

Use this rule to copy a Record Dictionary value into a global variable. Place this rule in the JDT file.

Syntax

;Base_FromDataDictToGVM;; GVM(GlobalVariableName) DATA(DataDictVariableName);

Example

;Base_FromDataDictToGVM;;GVM(STATION1) DATA(OMR1);


Image_FromDataDictToGVM

Use this section level rule to copy a Record Dictionary value into a global variable.

Syntax

;Base_FromDataDictToGVM;; GVM(GlobalVariableName)DATA(DataDictVariableName);;

Example

;Base_FromDataDictToGVM;;GVM(STATION1)DATA(OMR1);;


IncDataDictRecPtr

Use this section level rule to increment to the next occurrence of a Record Dictionary record.

Syntax

;IncDataDictRecPtr;RecordName {,MoreOptionalRecords};;

Example

;IncDataDictRecPtr;Tariff , Tarriff2;;


PosDataDictRecPtr

Use this section level rule to advance the record pointer until the condition is true.

Syntax

;PosDataDictRecPtr;Record(RecordName) Cond(ConditionName);;

Example

;PosDataDictRecPtr;Record(Meter) Cond(CompareMeterTariff);;


PostIncDataDictRecPtr

Use this section level rule to increment to the next occurrence of a Record Dictionary record.

Syntax

;PostIncDataDictRecPtr;RecordName {,MoreOptionalRecords};;

Example

;PostIncDataDictRecPtr;Tariff , Tarriff2;;


PostPosDataDictRecPtr

Use this section level rule to advance the record pointer until the condition is true.

Syntax

;PosDataDictRecPtr;Record(RecordName) Cond(ConditionName);;

Example

;PostPosDataDictRecPtr;Record(Meter) Cond(CompareMetrTarif);;


PreIncDataDictRecPt

Use this section level rule to increment to the next occurrence of a Record Dictionary record.

Syntax

;PreIncDataDictRecPtr;RecordName {,MoreOptionalRecords};;

Example

;PreIncDataDictRecPtr;Tariff , Tarriff2;;


PrePosDataDictRecPtr

Use this section level rule to advance the record pointer until the condition is true.

Syntax

;PosDataDictRecPtr;Record(RecordName) Cond(ConditionName);;

Example

;PrePosDataDictRecPtr;Record(Meter)Cond(CompareMeterTariff);;


ResetDataDictRecPtr

Use this rule to reset the pointer of a Record Dictionary record.

Syntax

;ResetDataDictRecPtr;RecordName;;

Example

;ResetDataDictRecPtr;Meter;;


Using the Help

Using the Help involves:

  • viewing (opening) the help
  • searching the help
  • adding a help topic to a Favorites list


Viewing the Help

The online help contains the following tabs in the lower left corner:

  • Contents – click this tab to display the Table of Contents of the help
  • Index – click this tab to display the index; from there, you can click any index term to display its topic
  • Search – click this tab to search the help: see Searching the Help
  • Favorites – click this tab to display any topics or search strings that you have saved as a “Favorite”; Favorites are similar to web bookmarks: see Adding a Help Topic to Favorites


Searching the Help

You can search the online help for topics containing specific words.

To search the online help

  1. Click the Search tab.
  2. Enter the word(s) to search on. If you enter more than one word, topics containing either word will be displayed in the search results.
  3. Click the List Topics button.

The search results are displayed. They are ranked in order based on the number of times the search word appears in the topic.

  4. To sort the search results by rank or title, click on the Rank or Title column heading respectively.
  5. Double-click a topic to display it.

The topic is displayed with all the occurrences of the search term highlighted.


Adding a Help Topic to Favorites

You can add a help topic to a collection of Favorites to quickly refer to it later.

To add a help topic to Favorites

  1. With a help topic open, click the Favorites tab.
  2. Click Add.

The topic is added to the list of Favorites.

  3. To view your current Favorites, click the Favorites tab.

Any favorite topics are displayed.

To display a favorite topic, double-click it.

To delete a Favorite, single-click the item in the Favorites tab, then click the Remove button at the bottom of the pane.


Related Documents

You can view the documentation for all Oracle Insurance applications on the Oracle Technology Network.

Finding Topics on OTN

You can use your favorite search engine to find topics in the Documaker documentation set on OTN.

For example, to find information on the Documaker Add-In for Microsoft Word, you could enter:

Oracle Documaker + Documaker Add-In

For information about Documaker’s MET2FAP utility, you could enter:

Oracle Documaker + MET2FAP

Review your search engine’s documentation for advanced searching tips and techniques.


Oracle Insurance

View the Oracle Insurance site for complete information on all Oracle Insurance products and solutions


Oracle Support

If you have any questions about the installation or use of our products, please visit the My Oracle Support website or call 800. 223.1711.


Send Feedback

You are here: Send Feedback

Send Feedback About This Guide

Your feedback helps us improve this guide. Please click the link below to email your feedback.

Send feedback about this guide

Please note:

  • If you are commenting about a specific topic, please include its title in your message.
  • We will review your feedback but you may not receive a direct response.
  • If your feedback is not documentation-related, or you have any questions about the installation or use of our products, please visit the My Oracle Support web site.


Document Conventions

The following text conventions are used in this document:

Convention | Description
bold | Indicates information you enter.
italic | Indicates book titles, emphasis, or placeholder variables for which you supply particular values.
monospace | Indicates commands, URLs, code in examples, and text that appears on the screen.


Documentation Accessibility

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

TTY Access to Oracle Support Services

Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.


Legal Notices

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

Hazardous Applications Notice

This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

Trademark Notice

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Third Party Content, Products, and Services Disclaimer

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.